Results 1 to 2 of 2
  1. #1
    Join Date
    Apr 2004
    Kingsland, Georgia

    Unanswered: Proper documentation

    Would anybody have either a link to or the name of a book that can help with "proper" database documentation? I want to make sure my databases are thoroughly explained in case someone has to take over for me, but i don't feel the ones i've put together so far (comprised mainly of screenshots of table design, relationships, and the code behind different reports/forms) is sufficient. Is there any standard/guideline on how to document these thing? Thanks for any help,

  2. #2
    Join Date
    Apr 2002

    Yes there are standard's procedures or rules to document the process of making a database, but i think there's no need, if you document your database like this:

    When you start to make a database, you sure had to audit the department or departments of the enterprise, to get relevant information of what process you are going to informatize, and what new process, if it is the case, you are going to create, this is the begining. Then you make the Cicle of Activities Diagram, that consists in making a diagram to ilucidate how the processes are working/interact and how they should work/interact in an informatic enviroment, now you're starting to document your database.

    The next step is to normalize variables and tables, that are related to the diagrams you made before, example: How many times the variable costumer appears in the system? and in what departments? And how many tables with that field do i have to create? This information is crucial for you to know how to relate the tables, and what do you need to relate them. In this step you're documenting the fields, the tables, the relationships and what information the departments will have in the future working with your database.

    After this, you will work and treat the information. Example: In department "A", they need to know: if the article is in stock; wich requests are active; how many material is needed, etc... So you will construct the querys to fit that requests for department "A", and you will document the fields, tables, functions and criteria you put into the querys.

    Then you work the interface with the user, say Forms and code. And document all, referring to querys or tables documented before if needed.

    To finish review and adjust some modifications you made that wasn't documented before and put the screen shots of the application to show how it works.

    Basically the process of making and documenting your database is this, of course that are standard rules to do it, but that belongs to professionals.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts