Database design

In a majority of cases, the person designing a database is a person with expertise in database design, rather than expertise in the domain from which the data to be stored is drawn e.g. financial information, biological information etc.

This is because those with the necessary domain knowledge often cannot clearly express the system requirements for the database as they are unaccustomed to thinking in terms of the discrete data elements which must be stored.

(NOTE: A common misconception is that the relational model is so called because of the stating of relationships between data elements therein.

[3] Once the relationships and dependencies amongst the various pieces of information have been determined, it is possible to arrange the data into a logical structure which can then be mapped into the storage objects supported by the database management system.

In the case of relational databases the storage objects are tables which store data in rows and columns.

The way this mapping is generally performed is such that each set of related data which depends upon a single object, whether real or abstract, is placed in a table.

In the field of relational database design, normalization is a systematic way of ensuring that a database structure is suitable for general-purpose querying and free of certain undesirable characteristics—insertion, update, and deletion anomalies that could lead to loss of data integrity.

In such situations, often, portions of the document are retrieved from other services via an API and stored locally for efficiency reasons.

This step involves specifying the indexing options and other parameters residing in the DBMS data dictionary.

The following steps are suggestion of the data modeling process for Microsoft Access, a relational DBMS.

A sample entity–relationship diagram