Database Development

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.  This can take many forms.

• The most universal interface is a web interface.  All that is needed on the client side is a web browser (such as Internet Explorer or Netscape, ...) and of course a valid logon to connect to the server.  No special software (such as MS Access or Oracle,...) has to be installed.
• In some instances complex graphs or calculations need to be derived from a data set.  The easies way to accomplish this is to export the required data, and import this file into a spreadsheet or reporting package.
• Another option is to create a custom application (compiled executable program) that is installed on the client desktop, and allows access into the database server.
• The user interface can also be created using a database program like Microsoft Access.  In this case, 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.

We will work with the client or their IT team to ensure the best possible results.

The data structure in the database 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 ...

Scalability is another issue when considering the initial design.  Everyone has at one time encountered the limitations of a software package...  "I wish I could add a second address in my organizer..." or "Why can't I keep track of more than 4 phone numbers per contact in this program?" If the programs in the previous examples had been built with scalability in mind, these problems would not have occurred!

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 still stored in DOS-based systems. If there is no export facility in the old database management system, then a small program can be created 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 corrupted old data!

Remember, if you can dream it, we can build it!