A database usually consists of three parts:
The immediate and most obvious objective of database development is to make the most possible information available in the most user friendly format. The user interface is the most visible part of any database.
Most databases now use a GUI (Graphical User Interface) which makes inputting or retrieving data more intuitive. If the interface is a compiled computer program, it is usually a program separate from the actual database file which contains the data.
If the user interface is created using a database program like Microsoft Access, the database containing the data tables also contains the forms (the elements of the interface) and all of the programming to make the data accessible. These types of database programs are usually quite limited in features. If you need more exotic or complex functions, it is best to program them externally.
Normally, when complex functions are required of a database, one programs an externally programmed "shell". It is the shell which accesses the database (which now only contains the raw data and perhaps a few queries).
The advantage of a customized database inside an integrated database program is the presence of "wizards" that help you create some of the more everyday buttons and queries.
The data structure is the combination of all "tables" that will contain the actual data. Tables, records and fields are defined as part of the database design. A balance between flexibility, data size and redundancy (for security) must be achieved. To make the database as flexible as possible, the fields should be as large as possible, but this implies a larger data size, which then in turn make the database more cumbersome. To keep the data safe, there should be some redundancy built in, but once again this will increase the size ...
One of the most prominent questions when creating a new database is usually how to get the "legacy" data from the old database to the new software. Legacy data is often stored in DOS-based systems. If there is no export facility in the old database management system, then a small program can be created under DOS or Windows to interpret the old information and convert it to a format the new database can use.
An additional problem with legacy data is its integrity. By blindly transferring the old data, one is making the assumption that the data is correct, eg. there are no redundant, incomplete, or just plain incorrect records present. Just as a chain is only as strong as its weakest link, a database is only as strong as its weakest data. Therefore, the conversion software should also do some checking to ensure the quality of the data as it is being converted.
In some very rare cases, the old database may have become so corrupted that a manual audit may be required before proceeding. It does not pay to corrupt a new database management system with old data!
