Chapter 5 Logical Database Design and the Relational Model

Introduction In the previous discussions, you have learned how to analyze the data maintained by organizations in which we determine user requirements for data and develop data models to represent those requirements. However, the data model developed during analysis directly avoided any ties to database technology. Before we can implement a database, the conceptual data model must be mapped into a data model that is compatible with the DBMS to be used. The activities of database design transform the requirements for data storage developed in the database analysis into specifications to guide database implementation. There are two forms of SPECIFICATIONS: o LOGICAL - maps the conceptual requirements into the data model associated with a specific DBMS. o PHYSICAL indicates all the parameters for data storage that are then input to database implementation, during which a database is actually defined using a DATA DEFINITION LANGUAGE. In this chapter, we will describe LOGICAL DATABASE DESIGN with emphasis on the relational data model. o LOGICAL DATABASE DESIGN is the process of transforming the conceptual data model (described in chapter 3 and 4) into a logical data model. o The basis for our discussion of LOGICAL DATABASE DESIGN is the use of RELATIONAL DATA MODEL since most DBMS in use today use this. o We will define important terms and concepts such as: RELATION PRIMARY KEY FOREIGN KEY ANOMALY NORMAL FORM NORMALIZATION FUNCTIONAL DEPENDENCY PARTIAL FUNCTIONAL DEPENDENCY TRANSITIVE DEPENDENCY o We will describe and illustrate the process of transforming an E-R model to the relational model. Many CASE tools support this transformation; however, it is important that you understand the underlying principles and procedures. o We will describe in detail the important concepts of normalization (the process of designing well-structured relations) o We will describe how to merge relations from separate logical design activities. E.g. different groups within a large project team while avoiding pitfalls in the process. o WE HAVE TO KEEP IN MIND OUR OBJECTIVE FOR THIS DISCUSSION TRANSLATE THE CONCEPTUAL DESIGN (represents an organizations requirements for data) into A LOGICAL DATABASE DESIGN that can be implemented on a chosen DBMS. The resulting DB must meet USER NEEDS for DATA SHARING, FLEXIBILITY, and EASE OF ACCESS.

The Relational Data Model First introduced in 1970 by E.F. Codd, then of IBM. Today RDMS have become the dominant technology for database management. It is based on mathematical theory and has a solid theoretical foundation. To simplify the concept, let us look into the three components: o DATA STRUCTURE Data are organized in the form of tables with rows and columns o DATA MANIPULATION Powerful operations (using SQL) are used to manipulate data stored in the relations. o DATA INTEGRITY- Facilities are included to specify business rules that maintain the integrity of data when they are manipulated.

The Relational Data Structure - Relation A relation is usually described as a table, which is organized in rows and columns. Each relation (or table) consists of a set of named columns and an arbitrary number of rows.

Relational database theory uses a different set of mathematical-based terms, which are equivalent, or roughly equivalent, to SQL database terminology. The table below summarizes some of the most important relational database terms and their SQL database equivalents. Relational term relation, base relvar derived relvar Tuple Attribute SQL equivalent table view, query result, result set row column

An attribute is a named column of a relation. Each row of a relation corresponds to a record that contains data (attribute) values for a single entity.

This is an example of a relation named EMPLOYEE1. This relation contains the following attributes describing employees: Emp_ID, Name, Dept_Name, Salary. The five rows correspond to five employees. The data given are sample data to illustrate the structure of EMPLOYEE1, even if we delete the rows it does not change the relation. The figure is an instance of the EMPLOYEE1 relation. We can express the structure of a relation using the shorthand notation: Name of the relation (names of the attributes) EMPLOYEE1(Emp_ID, Name, Dept_Name, Salary)

Relational Keys We must be able to store and retrieve a row of data in a relation based on the data values stored in that row. To achieve this goal, every relation must have a primary key. The PRIMAY KEY is an attribute (or combination of attributes) that uniquely identifies each row in a relation. We designate a primary key by underlining the attribute name. The concept of a primary key is related to the term identifier. The COMPOSITE KEY is a primary key that consists of more than one attribute. For example: ORDERLINE(Order_ID, Product_ID, Quantity) There are instances where we must represent the relationship between two tables or relations. This is accomplished through the use of foreign keys. A FOREIGN KEY is an attribute in a relation of a database that serves as the primary key of another relation in the same database. Let us consider the following relations: EMPLOYEE1(Emp_ID, Name, Dept_Name, Salary) DEPARTMENT(Dept_Name, Location, Fax) the attribute Dept_Name is a foreign key in EMPLOYEE1. It allows a user to associate any employee with the department to which he or she is assigned. We designate a foreign key by using a dashed underline.

Properties of Relations Not all tables are relations. Relations have several properties that distinguish them from nonrelational tables. - Every relation has a unique name. - Every attribute value is atomic (not multivalued, not composite) A table that contains one or more multivalued attributes in a relation. A table that contains one or more multivalued attributes is not a relation. Every row is unique (cant have two rows with exactly the same values for all their fields) Attributes (columns) in tables have unique names The order of the columns is irrelevant The order of the rows is irrelevant

A relational database consists of any number of relations. The STRUCTURE of the DATABASE is described through the use of a CONCEPTUAL schema, which is a description of the OVERALL LOGICAL STRUCTURE of the DATABASE. There are two common methods for expressing a logical schema: 1. Short text statements. 2. A graphical representation where relation is represented by rectangle containing the attributes for the relation

ADVISE: It is a good idea to create an instance of your relational schema with sample data to be able to check accuracy of your design, improve communications with users when discussing your design, use sample data to develop prototype applications and to test queries. Integrity Constraints The relational model includes several types of constraints, or business rules whose purpose is to facilitate maintaining the accuracy and integrity of data in the database. Types are: o Domain constraints A domain of possible values should be associated with every attribute All of the values that appear in a column of a relation must be taken from the same domain. A domain is the set of values that may be assigned to an attribute.

In the given example, it shows domain definitions for the domains associated with the attributes in Figure above.

Domain Definition for the attributes in Figure above

o Entity Integrity RULE: No primary key attribute may be null. All primary key fields MUST have data. The relational data model allows us to assign a null value to an attribute in situations where there is no applicable data value. A null is a value that may be assigned to an attribute when no other value applies or when the applicable value is unknown. o Referential Integrity A rule that maintains consistency among the rows of two relations. The rule states that if there is a foreign key in one relation, either each foreign key value must match a primary key value in another relation or the foreign key value must be null. o Action Assertions There are various techniques for defining and enforcing such rules.