Database Design for Business - Part 2 Instructing the designer
There are two elements to this first appoint the right designer and second communicate your database design ideas to them.
The database designer should understand your basic business processes and not try to add extra processes you do not do already, unless of course you are introducing new practices. To acheive this they should be prepared to visit you at your premises and look at existing practices and figure out how they will impliment your new system, assuming that they think they can. If they suggest that you need extra hardware or software ask them why they are needed.
If you communicate your design idea effectivly to the designer you can more easily set a fixed price. If your ideas are a bit vague so will the pricing. Write a detailed list of the differant elements that your idea requires.
(Customer List - Name, Adress,telephone, e-mail, Accounts ref,fax, delivery addresses, e-mail preferance,credit limit, etc,) Show the calculations that you need to do on the data, and do mock ups of the reports you would like.
The designer should be able to tell you when they can start your project and how long it will take. They should be available to train you and your staff if necessary. There will more then likely be some issues and unforseen circumstances that will need to be patched up when the system goes live. Will the database designer be able to offer remote assistance or onsite help?
Get the designer to show you some other projects they have completed. Try and see more then one designer! Some designers speciallise in differant industry sectors but this is not something that you should give to much weight to, as long as your designer understands your business processes.
Next we will look at the technology choices available in Part 3.
Labels: business, database design, database design for business
Database Design for Business - Part 1 Getting ready
Define and Refine and then Define againOk 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 node-net.comLabels: business, database design, database design for business
