Planning a database

[Sambucus]

Sorry if this is posted in the wrong section, I did carry out a search but couldn't quite get the answer I was looking for.

What I would like to know or to get tips on, is on planning a database. The part before the computer is even switched on.

As any tutorials I've seen deal with the programming and layout, not the overall concept.

Please point me in the right direction, I do know that I need a relationship database and not flat.

Even though I have plenty of time I would prefer working out what I need and how I should go about it before I start typing.

Thank you all in advance.

Yours, Charles

[VincentO'B]

Hi Sambucus

Its quite a wide field but for me the eureka moment was learning about Normalisation and Edgar F Codd.

Here is a Wikipedia article http://en.wikipedia.org/wiki/Database_normalization

[Fitch]

The Que "Using FileMaker" books, even the older editions, have a good chapter on how to think about entities and attributes.

[Sambucus]

Thank you very much for your help, I have ordered an earlier version of the book and I will take some time to look at the wikipedia page.

Yours, Charles

[Ertjie]

Hi Sambucus. I've been sitting with the same situation lately as i've been working on a really badly designed system. I've come to realise that planning your database is crucial. Some tips i can offer is to look into the topic of ERD - entity relationship diagrams. Should explain relationships, normalization etc. When planning the database try to think as global as possible. Think ahead, always ask what if the business grows or what will happen when the database grows. They might only need one or two of something now, but what will happen when they require 10 or 100? So design and build your DB to accomodate such eventualities. It is very important to understand how the business works, understand the business rules and the flow of data.Try and visualise the the flow of data and always ask what will happen when things dont go as planned. It might help looking into Use Cases and UML (Unified Modeling Language). Try to seperate things into seperate tables as much as possible without overdoing it of course. This will help make the system flexible and prevent troublesome changes later on. Hardcoding data in fields is always something that should trigger warning lights, although it has its time and place. The relationships themselves are also really important as it can change the whole dynamic of things, so think carefully about what will happen when you relate two tables on the specified fields. I'm not a pro (yet!) but these concepts made a difference to me. Hope it can help.