Database Management

Relational Database Design

The Basic Idea Behind Relational Database Design

Relational Database Design

Traditional database design theory in the 1960's was complicated and dependent on the physical storage of data. E.F. Codd of IBM laid the foundations of a demarcation to more flexible ideas in 1970, when he outlined a paper on relational database design. The basic idea behind the model is that a database is a series of relations (unordered tables) that can be manipulated using non-procedural operations to yield ordered tables.

The relational model of database design uses the term attributes, relations, and tuples to refer to the respective more commonly known terms columns, tables, and rows. The physical representations for these terms are fields, files, and records respectively.

For relational database design, you take a real world system and model it in a database. This is accomplished by deciding which tables to create and which attributes (columns) each of them will contain.

Each such table is used to represent information about one thing in the real world. The things can be real world objects or events. Each table is made up of columns and rows. A row in a table must hold unique information. In the relational model, the uniqueness is guaranteed by designating a primary key. It is a column that contains unique values in a table. Each table must have only one primary key.

The columns in a table which are potential candidates for eligibility as a primary key are known as candidate keys. All other candidate keys in the table except the primary key are known as alternate keys.

There is no explicit rule for a decision on the designation of a primary key. However, the rule of minimality of columns and functional dependence needs to be taken into consideration while deciding the primary key. Columns that store the value of a counter form excellent candidates for eligibility as a primary key.

Every table that is related to another must also have a foreign key besides the primary key. The foreign key is used to establish the 'relation' between two related tables and is used to reference column values in the other table. The primary key and the foreign key derive their values from the same domain. A domain is simply a pool of values from which columns are populated with values. They are user-defined data types. Certain rules must be followed by the columns for operations to be performed on the columns.

Relations between tables can be of three types, one-one, one-many, and many-many. Although true one-one relationships occur rarely in the real world, they are made recourse to, to avoid performance and security constraints. They are also used when the limitation of 255 columns per table is to be crossed or when a table needs to be split up into two or more tables.

Migrating to relational database design also involves following the rules of normalization for tables to avoid data redundancy and those related to the integrity of data. Some of these rules may be database specific and this must be considered when you migrate.

Privacy Policy