The database is the key to all corporate data and applications that make use of that data. Incorrect or careless database design techniques can have dramatic development and cost implications for companies that rely on their data.
"Database design is one of the most critical aspects of any total solution and is vital to success," says Anthony Swindells, MD of and chairman of the . Correct database design is key to ensuring that an IT solution is able to serve its purpose and to evolve as new technologies emerge.
"If the database is not correctly designed, there will be a negative domino effect throughout an organisation`s applications. A significant portion of every corporation`s IT spend is invested in the design process and, if done correctly, it will ensure the solution is able to adapt as the organisation and its markets evolve."
The design of applications must be based on three primary building blocks:
. a highly normalised database design, portable across technologies and allowing a migration path as technology changes;
. a core set of business logic objects, independent of user interface, to ensure a rapid migration of product if and when user interface wars demanded;
. a user interface designed independent of business logic that can be migrated rapidly to any appropriate format, GUI, HTML, Java, etc.
Other essential rules Swindells recommends for developing normalised databases, basic rules that many designers forgo even though they may seem standard practice to some, are firstly: "the key for uniquely identifying a record should not be an attribute of the entity the record represents. The use of unique object numbers facilitates the global application of the module and maximises reusability as information about an object is only ever held in one place. This allows attributes such as member number to be easily changed."
Secondly, he notes: "Each table in the database should describe one and only one kind of "object" or thing, and each record should contain information about a single one of these objects, and every field in a table should describe one fact about that object," Swindells continues. "A list of similar attributes (fields) within a table indicates that it is not normal."
Third, Swindells says every table should have a unique key. If non-key information is stored in more than one place, the database will not be normal. These rules are the basics behind normalisation, companies that follow them will find their database design will be normalised, although, as in all situations, certain rules may need to be broken for performance reasons.
Because of the time limits constraining development, most corporates would use one of the database design tools available on the market to assist in the design of the database. An important factor when considering which database design tool to select, is the level of integration with the database environments of choice. If this is inadequate, modifications could have to be made in more than one place, duplicating effort and resulting in the risk of losing control of the system - which leads to increased costs as developers spend more time on maintaining and debugging than on new development.
"A value-adding design tool should provide measurable differences in productivity gains, database portability, and integration with the chosen database environment," says Swindells. "It should also enforce standards and enshrine the concepts of simplicity of maintenance, system documentation, and reporting."
Share
Editorial contacts