Q1. How do I design a database after
I have gathered all the information?
A1. Write down all the possible
scenarios in interacting with the database or application.
Q2. What do you mean by
scenarios?
A2. Every step a user most
perform in interacting with the software system.
Q3. Where do I get all the
scenarios?
A3. During the information gathering phase and during
observations when users interact with the prototype that you will build.
Q4. You mean we have to build a
prototype first and not just start building the database or the software
system?
A4. Absolutely! You will cycle
through the prototype several times before you start building.
Q5. Do I throw away my prototype
when I finish cycling through it?
A5. No! You will design it in
such a way that it is scalable to the real thing.
Q6. Ok, after I write down all
the scenarios what do I do next?
A7. Read each scenarios and
decide what is it that you need to keep track of. What are the entities and
what are the attributes of each entity that you need to keep track of that are
needed in the executions of scenarios
Q8. What if I miss some entities
or attributes or even scenarios?
A8. You will pick up the ones
you missed when you cycle through the prototype several time.
Q9. What about entities or
attributes that I come up with but are not needed in the execution of any
scenario, should I include them?
A9. NO! Do not include entities
or attributes of entities that are not needed, they can only complicate things.
Remember: keep it as simple as possible but not any simpler.
Q10. Do forms, the kind you fill
out in a doctor's office or employment application map directly into a table?
A10. Almost never! A doctor's
form would typically map into several related tables.
Q10. Can you give a good
example?
A10. Here is one the scenarios
and the corresponding database. Student Registration, SQL script file,
Registration Application