Database Development
The importance of proper database design cannot be overstated. Remember Y2K? That was a systemic database design error that cost countless millions to correct. A simple decision at the design stage (should I use four digits for year, or only two) has profound downstream consequences.
"The only constant is change."
Whether your database consists of people, products, documents or other data, the design must be flexible enough to adapt to changing needs. Changing needs are at the very core of a properly designed database. For example:
You have a member database and each member has a home phone number. A new member joins and she winters in Ft. Lauderdale for 5 months each year. She has two home phone numbers. These days it is not uncommon to have multiple home, work, cell, pager numbers - each with specific contact instructions. A properly designed database takes this in stride. Poor database design responds in one of two ways: "No" or "Expensive."
Expertise Required
There is a lot more to a database than a spreadsheet. There is no better example of this than the following partial definition of a proper database design:
Third normal form (3NF) requires that the table be in 2NF, and that there be no non-trivial functional dependencies of non-key attributes on something other than a superset of a candidate key. A table is in 3NF if none of the non-primary key attributes is a fact about any other non-primary key attribute. In summary, all non-key attributes are mutually independent (i.e. there should not be transitive dependencies). Thus, any relation in which all the attributes are prime attributes (part of some key) is guaranteed to be in at least 3NF.
Thankfully, you do not need to know any of the science of database design. That's where we come in. The Imaginary Landscape team of database experts begins each database project with an understanding of the business goals. This translates into an initial visual design of the database, including the relationsip of data to each other. Each database is designed to industry standards and anticipates changing needs.
Example Database Visual Design
The benefits of a properly designed database are numerous and include:
Low Maintenance Costs
A properly designed database results in low maintenance costs. One of its primary goals is to eliminate repetitive data (same information in multiple places). If you have to make a change, you make it in a single place and it is changed throughout the database. Poor design means you must seek every instance and make the change, which is more expensive.
Higher Accuracy
Following on the above example, if data is repeated it might be misspelled. A common example would be the town name Oak Brook. Sometimes it is spelled incorrectly as Oakbrook. If your database contains both versions and you search for "Oak Brook," you'll miss any entry with "Oakbrook." Quickly, you'll begin to distrust your data.
Faster Speed
A properly designed database is fast and efficient. This is extremely important when delivering data over the Internet. Site visitors will leave your site if your pages are sluggish and your browser "spinning" awaiting a database query.
Future Flexibility
Accommodating another phone number, additional addresses, more product categories or other attributes is the hallmark of good design. It keeps future development costs down and allows you to react to changing conditions.
Imaginary Landscape utilizes a variety of relational database management systems, including:
- MySQL
- PostgreSQL
- Microsoft SQL Server
Each database is industry standard and fully ANSI and ODBC compliant.
Normalized Design
Imaginary Landscape designs all databases to the 3NF standard. This notation, known as the Third Normal Form is the generally accepted design standard for relational databases as described by E.F (Ted) Codd in his general theory of data management. It is a set of rules, increasing in complexity, that guides the creation of properly designed databases.
Additional Information
For more information on proper database design, please read our white paper, entitled "Seven Rules for Proper Database Design."
