2 RDBMS Database Design

System Development Cycle

System development transforms business information requirements into an operational database. For developing a reliable and high-performance database system, you should follow a system development cycle. A system development cycle is a top-down, systematic approach to database development. A system development cycle consists of five stages. These stages include: Strategy and Analysis Designing Building and Documentation Transition Production.

Figure 2-1. System development cycle Strategy and Analysis: In the first stage of a system development cycle, you analyze the entities and processes involved in the business. This is done by talking to users and managers of the existing or proposed system.

You can then build a model of this system by transferring the business information and requirements into an entity relationship model, which is a graphical representation of business information and rules.

Figure 2-2. Entity Relationship Model part 1 Designing: The second stage involves designing the database. For this purpose, you translate the entity relationship model into a database design plan. An Entity Relationship Models maps: Entities to Tables Attributes to Columns Relationships to Foreign keys Business rules to Constraints.

Figure 2-3. Entity Relationship Model part 2

Building and Documentation: In the third stage, you build and document the prototype system. You write and execute commands to create tables and other objects in the database. To support the use of the system, you also develop user documentation, help-screen text and operation manuals. Transition: The fourth stage is transition, and involves testing and refining of the prototype system. The prototype system is refined by adapting any existing data to the system prototype and testing the database for user acceptance. Production is the fifth stage of a system development cycle. In this stage, you roll out the production system to users. Simultaneously, you monitor the performance of the system and refine it as necessary.

Database Design: Guidelines

To design reliable, high-performance systems using the deliverables identified by an analysis, you follow certain guidelines. The guidelines to be followed when designing a relational database are: Optimizing Performance Supporting Integrated Applications Supporting Integration With Other Systems Documenting and Communicating the Design Providing Scalability Avoiding Reinventing the Wheel Optimizing Performance: the performance of a system is greatly impacted by the initial system design. The database design should not only reflect the business model, but should also incorporate a structure that will ensure optimal performance. Supporting Integrated Applications: the second guideline is that the database design should support integrated applications. A system is often developed by a team of developers who have different modes of working. A good database design reflects the business as a whole, and integrates the features needed by each application. Supporting Integration With Other Systems: a good design should also support the integration of one system with another. To meet new business needs, a client firm may want to integrate a new system with an existing system. A good database design must provide easy integration of such systems.

Documenting and communicating the Design: another guideline to follow when designing a relational database is to ensure documentation and communication of the design. The decisions about the design should be documented and communicated to other designers and developers. This will facilitate the development of application systems. Providing Scalability: to prevent future performance and limitation issues, the database should be designed to accommodate whatever changes are likely in data volume and user demand. Test the prototype design against suitable data and demands, and plan for potential growth. Avoid Reinventing the Wheel: finally, when designing a relational database, use any existing, successful design solutions. Some problems encountered while designing a database system have been successfully resolved by other designers, where ready-made solutions are available.

Entity Relationship Modelling Concepts

Producing a data model is the initial step in designing a database. System designers develop data models to explore ideas and improve their understanding of the business structure and its processes. Data models help communicate concepts. The objective of creating a data model is to include enough details for the development of a database system. The main representation of a data model is through an entity relationship diagram. You will identify the descriptions of the different components in this model.

Figure 2-4. Entity Relationship Model representing business specification

An entity relationship model is derived from business specifications or narratives. It is a graphical representation of business information needs and rules. An entity relationship model separates the information required by a business from the activities performed within the business. Although business activities can change, the type of information tends to remain constant. Therefore, the data structure of an entity relationship model remains constant. An entity relationship model is composed of three key components: Entities Attributes Relationships. An entity: represents a component of the business system about which information is to be provided or a discrete category or collection of related data. Some examples of an entity are customers, orders and employees. When documenting the model, the names of entities should be unique and in uppercase. A synonym can be specified within parentheses to be assigned to an entity as an optional name. The optional name should also be in uppercase. You represent an entity in an entity relationship diagram by using a box of any dimensions. Attributes: the second component of an entity relationship model is an attribute. An attribute describes an entity or a component of the business system. It contains specific information that should be known about an entity. For example, for the entity customer, the attributes are customer number, name and phone number. The conventions used to represent an attribute include using singular terms in lowercase. A number symbol (#) is also used to tag each attribute that is part of a unique identifier. A unique identifier is used to distinguish each occurrence of an entity. Each attribute in an entity relationship model is either optional or mandatory.

Figure 2-5. Attributes A mandatory attribute must have a value. This is indicated by an asterisk. An optional attribute that may be known, is marked with an o. For example, the value of the attribute customer number must be known and is marked by an asterisk. The value for the attribute phone number may be known and is marked with an o. Entity: the third component of the entity relationship model is a relationship. Each entity must have a relationship that represents an information requirement and a business rule. A relationship is a twodirectional association between two entities, or between an entity and itself.

Entity Relationship Models: Types

In a database design, each entity must have a relationship that represents the information requirements of a business. The relationships between entities are represented in an entity relationship diagram. An entity relationship diagram is drawn by using lines to connect rectangular boxes. Each rectangular box represents an entity. The lines connecting the boxes represent a relationship between entities. The connecting lines in an entity relationship diagram may be: Continuous Broken Half Continuous and the remaining half Broken

A continuous line, also referred to as a solid line, indicates that the relationship between the entities is compulsory. A broken line connecting entities indicates that the relationship is optional. A broken line is also called a dashed line. Half Continuous and the remaining half Broken: another type of relationship is indicated by using half the line as continuous and the remaining half as broken. This means that the relationship is compulsory for one of the related entities and optional for the other. All the optionally parameters are applicable in all types of entity relationships. There are three types of degree in a relationship: One-to-one Many-to-one Many-to-many.

Figure 2-6. Types of degrees in a Relationship One-to-One: in a one-to-one relationship, the entities have a degree of one and only one in both directions. This means that only one entity can be related to one other entity and vice versa. For example, a car can have only one driver at a time. Similarly, a driver can drive only one car at a time. A one-to-one relationship is rarely used.

Many-to-One: in a many-to-one relationship, the entities have a degree of one or more in one direction and a degree of one and only one in the other direction. One entity can be related to more than one entity but the reverse is not true. An example of a many-to-one relationship is the passengers in a plane. This type of relationship is commonly found. Many-to-Many: in a many-to-many relationship, the entities have a degree of one or more in both directions. This means that one entity can be related to more than one entity and vice versa. Such relationships are complex to implement. For example, an employee can have many skills. The same skill may be present in many employees. An entity that has many entities related to it is pictorially represented by three lines attached to the entity rectangle. This representation is known as a crow's foot. There are three entity relationship models based on degree in the relationship between entities: One-to-Many One-to-One Many-to-Many.

Figure 2-7. Types of Data Models One-to-Many: in the first model, each right entity must have one left entity and each left entity may have several right entities. This type of model represents a one-to-many relationship.

One-to-One: in the second entity relationship model, each left entity can have one right entity and each right entity must have one left entity. This type of model depicts a one-to-one relationship. Many-to-Many: finally, in the third entity relationship model, each left entity may have one or more right entities and each right entity may have one or more left entities. This type of model depicts a many-to-many relationship.

Normalization
Before designing a database, you need to eliminate the problem of data redundancy. You can do this by normalizing the data model. The theory of normalization is a study of relations, attributes and the interdependence of attributes. Using the normalization theory, you can design a database that minimizes data redundancy, reduces integrity problems and is easy to maintain. The normalization theory describes the arrangement of relations and attributes as normal forms. This is also referred to as the rules for normalization. The three commonly used normalization rules are: First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF) First Normal Form: in the first normalization rule referred to as the first normal form (1NF), each attribute in a table consists of a single value for an entity. An entity should not have attributes that represent repetitive values. For example, the table s_emp contains the details of employees, and the table s_dept contains department details. To avoid repetitive values, you do not store the department details in the s_emp table. You can retrieve the department details for an employee from the table s_dept. Second Normal Form: the second normalization rule is referred to as the second normal form (2NF). In this case, an attribute must depend upon the entire unique identifier of its entity. Third Normal Form: in the third normal form (3NF), a non-unique identifier attribute cannot be dependent upon another non-unique identifier attribute. This rule avoids many-to-many relationships, and makes precise joins possible between rows.

Database Design: Steps

In the database design stage, you produce the design specifications for a relational database. This includes definitions for relational tables, indexes and storage space. This paragraph introduces some useful planning steps in the design phase of a database.

Figure 2-8. Relationships between tables In the design phase of a database, to represent the database model, you use a database diagram. This diagram is similar to an entity relationship diagram. This diagram shows the various tables and the relationships between them. The names of primary and foreign keys are marked on the lines. Along with a database diagram you use a table instance chart. This chart shows the details of one table, its columns, keys, and data types.

Figure 2-9. Table instance chart There are four useful steps to derive a detailed table plan from the information in your entity model. These steps are: Map Entities to Tables Map Attributes to Columns Map Unique Identifiers to Primary Keys

Map Relationships to Foreign Keys

Map Entities to Tables: the first step in the design phase is to map the entities to tables. In the database model, each table is represented by a rectangular box. You create a table instance chart for a new table. The chart should contain the table name, the column names, the key types, the null and unique reference, foreign key information, the data type and maximum length of values in columns, and sample data. The name of the table is recorded at the top of the chart. When you assign a name to a table, you should be able to trace the table name to the entity name. When assigning column names, use short names. This will reduce the time required for SQL command parsing. The column names should be derived from the entity relationship model. For ease of access to the database and documentation, you should develop your own standards and naming convention for tables and columns. Map Attributes to Columns: in the second step of the database design phase, you map each attribute in the entity relationship model to a column in the table. The mandatory attributes, tagged with an asterisk, are mapped to the columns defined as NOT NULL (NN). You also add sample data to the table instance chart to display the contents of the table in a visual form. Map Unique Identifiers to Primary Keys: the third step in the design involves mapping the unique identifier (UID) in the entity relationship model to the primary key columns. You map a UID containing a single attribute to a single column primary key. The primary key type, not null and unique references are labelled as PK, NN and U respectively. Next, you map a UID that includes multiple attributes to a composite primary key and label the columns as NN and U1. Map Relationships to Foreign Keys: finally, map entity relationships to foreign keys. The relationships include many-to-one, one-to-one optional and one-to-one mandatory relationships. Drs. Leendert R.E. Hinds (l.hinds@hints.nl)