Results 1 to 7 of 7
  1. #1
    Join Date
    Jan 2010
    Posts
    10

    Unanswered: Checklist management database

    Hi everyone,

    I'm a bit more than a beginner regarding databases.

    Anyways, I'll explain the situation first. I have designed a physical checklist (around 300 questions and points) that my inspector will use during his random inspections to our showrooms and offices.

    The answers are in the following formats:

    1) yes or no
    2) points 1 to 4
    3) 0 or more employees (their individual employee numbers are inputted)

    I want to take this data and put it in a database (i imagine a web-form looking exactly like the paper form i would give him) so that I can analyse the data and compare between his repeated visits.

    I would like to analyze:

    1) the same question/answer across many different showrooms
    2) Taking the total number of points (y and n can also count) for EACH showroom and comparing it with OTHER showrooms.

    Basically this data would be used so that I can compare and see the progress that this inspector is making.


    I honestly do NOT know where to start. I have an extensive IT background but I never worked with databases on this scale before (which i know is not that advanced).

    Please someone advise, thank you.

    Kenan

  2. #2
    Join Date
    Aug 2008
    Posts
    147
    Start with some some Database design ,based on the relational model.The requirements you have are not particuarly complicated . If you're doing this work yourself , there are plenty of tutorials that will outline how to progress
    ---------------------------------
    www.sqlserver-dba.com
    www.dba-db2.com

  3. #3
    Join Date
    Dec 2009
    Location
    Antwerp (Belgium)
    Posts
    33
    From what I read you should be ok with one table. One field for the session (might be the date), one field for the showroom, and a field for each of the questions. And if I'm right, thne you may as well do it it in Excel.

    On the other hand, if, for example you would want to link more info to session, i.e. give it a date, the inspector's identification etc., and if you would want to add the address, the tel nr and the manager of the showrooms, then you would add a "master table" for the sessions and a "master table" for the showrooms and link (relate is the word) them to your main "questionnaire result" table.

    The key to this exercise is to determine (discover?) "operational information", i.e. information that is not redundant, and that is not computed anywhere else. That is the information you want to name and save in your tables. Via queries, forms and reports you produce the "non-operational" information.

    That process, of determining what your "operational information" is, is known to most of us as "normalization", although I'm sure you won't find it defined in this way, so don't quote me.

    Good luck.

  4. #4
    Join Date
    Jan 2010
    Posts
    10
    Thanks for the reply I've progressed since posting that thread but I'm stuck on one issue:

    I have one field (answer) that can have MORE than ONE answer, for example:

    question: Employee(s) who came in late:

    the answer could be 0, could be 1, or could be more than one.

    How do i set the relations and how will more than one answer go into one field?

  5. #5
    Join Date
    Dec 2009
    Location
    Antwerp (Belgium)
    Posts
    33
    If the number of employees can be either 0,1, or n, you should not have a problem, because you really have only one value for that field. I guess you figured that out yourself. So it's the names of the employees that you want to save.

    The normalized way of approaching this is to create a table that has the session, the showroom and an employee name. Depending on the circumstances, this could be cumbersome because you would have one table more to maintain. But it's doable.

    As far as relations are concerned, I guess at this stage, the easiest is to check outt he query builder. It's almost self explanatory. Onces you have it figured out, you might try to do data entry via the query you just built.

    You can also have the database save the relations. It's similar, but different . It really depends on how you are going to use your system. Are you going to do your data entry in the tables themselves and is the point of this really to make reports withs stat?, or is this the basis of something more sophisticated that will grow with time. I'm asking because I could be confusing you with things you may not need.

    Tell me how far you got.

  6. #6
    Join Date
    Jun 2007
    Location
    Maitland NSW,Australia
    Posts
    388
    Before you go too far, the the maximum number of fields in a table is 255, so you will need a table for your questions with each record for your question. This table would be linked to your other tables.

  7. #7
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Look in to either survey or quiz free examples. The database structure to support your "checklist" functionality is encompassed by a series of yes/no or multiple guess questions. That's a quiz...

    Surveys/quizes are very common just-after-hello-world tutorial topics.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

Posting Permissions

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