Working with databases/Database design/Planning a database

Planning a Database
When creating a database, it is very important that you give some thought to how you will implement your database. You will need to consider things like which pieces of information you want to store, who is going to be using your database, etc.

Planning is not just a single decision at the beginning about what is going to happen – planning is a cyclical process of Design &rArr; Implement &rArr; Evaluate that feeds back into design. This process is repeated until the brief has been met. For your assessment, we will not be expecting you to create the “perfect plan” first time - but we will want to see that you understand and can document the above process.


 * Design
 * Decide the purpose of the database by looking at the brief (the list of everything that needs to be included in the database and everything that needs to be produced from the database) What facts do you need to keep track of? These facts will be used as fields in your database. (A field can be considered a snippet of information about a thing. For instance, if you wanted to create records about customers for your business, then we could create fields that contained information about their address, phone number, money owed, etc.)


 * Implement
 * Create your database, using your plan as a guide. We will cover the details of “how to” later in the book.


 * Evaluate
 * Try entering trial data into your database. Does the database behave as you would expect from your plan? Do the results it provides make sense? If not, then have at look at your original design and make changes to your database. This is a very important step, as usually once a database is full of information, it can be almost impossible to change the basic structure of it, without the risk of losing some or all of the information contained in it. Re-evaluate before you hand your database over to your client.

Decoding a brief
Before we get into the actual “how to” of creating a database, we need to look at the exercise of interpreting a brief.

Usually you’ll be presented with a situation where the client you are creating a database for is not a computer expert. They might have a list of things they’d like to record but might be a bit vague on the specifics. Or they might be organized and have a list written down. It will be up to you to try and interpret what is being asked of you.

We are going to work though an example of interpreting a brief, and then you can work though an example on your own. You will not be creating a database at this point.