Wednesday, September 12, 2007

Database Design for Business - Part 1 Getting ready

Define and Refine and then Define again

Ok so you have a problem that you think you can solve by getting a database written.

Well the first step in having your own database is to define the problem/task you want it to do. This requires more then an outline of the problem/task. As databases are just a method of dealing with various bits of information, this means looking at everypiece of information that you will need for your project. Where does the information come from? What calculations need to be done on this information? Where is this information going? Do we need to print anything? Are we publishing to a webserver?
At the early stage of development we need to look at how many users there will be on the system?
How many different transactions will we be recording? How critical the system will be when it is in place? This information will help us to decide which platform to use. By platform I mean the program you or your database designer will use to design your database. The platform or database management system (DBMS) is computer software designed for the purpose of managing databases. Typical examples of DBMSs include Oracle, DB2, Microsoft Access, Microsoft SQL Server, PostgreSQL, MySQL and FileMaker. DBMSs are typically used by Database designers in the creation of Database systems.

Here are the top 10 things to do if you are considering buying/building your own database.

Be realistic about the number of users, transactions, etc, and about how the workload will grow in the future. There is no point using a huge Rolls Royce engine when a small Honda will do, and equally a small Honda when you really need a big Jet engine.

Keep focused on exactly the immediate job it needs to do. Don't add unnecessary bells and whistles. The most successful databases are the ones that kill those little repetitive jobs that eat up you and your staffs time.

Format the data to a form that can be easily incorporated into your other systems.

Draw a diagram of how the data is collected and input
(Jim in the warehouse enters the incoming delivery details into a form on his computer, the database interrogates the clocking in machine, whatever.)
Continue the diagram to show what happens to this information
(Ann in accounts matches incoming invoices with Jim's delivery notes, The database works out wages based on a table of employees and their pay rates.)
Then show the output of the database
(A report is emailed to the MD to tell him the value of uninvoiced deliveries in the warehouse, the database sends weekly wage figures to the Payroll program for processing.)

Take a long look at the existing input procedures you are using (we are assuming they are successful) What parts of the process can be speeded up? (Is Jim in the warehouse having to type in the same address 30 times a day?) As a general rule ask the person doing the job currently what takes them the most time and invariably they will immediately describe the most boring and repetitive part of the job and is usually the first problem the database should address.

You already know the calculations you make on a daily basis and funny enough a lot of them are boring and repetitive no matter how fancy the mathematics is. So if your database can collect all the figures and variables you need for your calculations why not let it do the calculations for you.

Is the incoming information accurate? Does the database need to enforce any rules on the incoming data?

How many people will be using the system, Where are they using the system from? How secure is my information?

Different levels of access to reports and information.(Does Jim in the warehouse need to know what you are paying for stock?)

Know what benefits you are bringing to your company if the system works as you imagine. (Increases in productivity, lower costs, quicker process, and what that is worth in financial terms.)

If you do these things you are ready to start talking to a database designer in general terms about your project.

I will tackle this question in Part 2 Appointing a designer

Copyright 2007

No comments: