Chapter Four Relational Data Model

Outlines:-

1) Relational Data Model. 2) Relational Data Integrity Constraints. 3) Transforming ER-Diagrams into ( Logical Design ) Relational Schemas.

Relational Data Model

The Relational Data Model was first introduced by IBMs E. Codd, the founder of relational theory, as a relational model of data for large shared data banks (Codd, 1970). The relational data model is based on the mathematical concept of a relation and has a solid theoretical foundation. The concept is physically represented as a relation or a table that stores data. The Relational Data Model consists of Three components: 1-Relational Data Structure: Where data is organized. 2-Data Manipulation: The operations used to manipulate data stored in the data structure. 3-Relational Data Integrity: The rules that maintain the integrity of data when manipulated.

Relational Data Structure

The main data structure that stores and organizes data in the relational data model is a Relation, a Two-dimensional Grid that holds data about the object that is represented in the Database. Every relation has a unique name and consists of a set of named columns and an arbitrary number of unnamed rows. In comparing a relation with the E-R model, we could say that a relation corresponds to an Entity type, its columns correspond to attributes of an entity, and the rows correspond to instances of an Entity Set. A Column of a relation is referred to as an Attribute, while a row is referred to as a Record or tuple. The number of Attributes in a relation is defined as a Degree, and the number of records in a relation is defined as a Cardinality Ratio.

Relational Data Structure [Continue]

We use the following short-hand notation to represent this relation: STUDENT (SSN, Name, Email, DeptName) The notation begins with the relation name followed by a series of attributes that are separated by commas and enclosed by parentheses. We use this compact notation, also called a Relational Schema, when we want to discuss a relation without referring to specific records.

Attribute or Column

Entity Type Relation or Table Row Entity Set

Data Manipulation
Once we build relations, we need a way to access and manipulate the data they contain. A Data Manipulation Language, such as Structured Query Language (SQL), supports and facilitates data access and manipulation. The following is an example of a SQL statement that updates the faculty relation. UPDATE TblFaculty SET Salary = Salary * 1.05 WHERE JoinDate < #1/1/2011# AND Salary < 70000

Relational Data Integrity Constraints

Relational data integrity constraints maintain data integrity when a manipulation language is used with data. Integrity constraints therefore allow us to incorporate business rules and constraints in the relational data model.

Relational Keys
Because no two records should be identical, we need to specify one or more attributes (defined as relational keys) that uniquely identify each record in a relation. We will now define some of the most important relational keys. Properties of a Relation 1- Each relation is uniquely identified by its name. 2- Each cell of a relation contains exactly one single (atomic) value. 3- Each record (all the attributes together) of a relation is unique. 4- Each attribute in a relation has a distinct name. 5- The values of an attribute are from the same domain. 6-The order of attributes is Irrelevant. Columns can be interchanged without changing the meaning of a relation. 7-The order of records is also Irrelevant. Rows can be interchanged without changing the meaning of a relation.

Relational Keys [Continue]

A Superkey: is a set of one or more attributes that uniquely identifies each record in a relation. Where: Tuple1 [ Superkey ] Tuple2 [ Superkey ], , Tuplen[ Superkey ] Consider the Student Relation. Any of the following sets of attributes from the following partial list can serve as a Superkey for this relation. Superkey1: (SSN, Name, Email, DeptName) Superkey2: (SSN, Name, DeptName) Superkey3: (Name, Email, DeptName) Superkey4: (SSN) SuperKey5: (Email) If we take all four attributes together, as designated in Superkey1, any record in the relation has unique values for these fields as a set. Likewise,Superkey4 (SSN) and Superkey5 (email) have unique values for each record. Conversely, the attributes Name and DeptName cannot serve by themselves as superkeys because neither attribute guarantees uniqueness.

Candidate and Primary Keys

It is clear from this example that a superkey might contain additional attributes that are not required for unique identification. However, efficient design requires a minimal number of attributes in the key. A candidate key, or a minimal superkey, has a minimum number of attributes. In other words, a candidate key is a superkey such that no proper subset of it can serve as a superkey for a relation. Therefore, both of these can serve as candidate keys. Candidatekey1: (SSN) Candidatekey2: (Email) While all candidate keys are minimal, we need only one key to satisfy the uniqueness property of records. The Primary Key is a candidate key that has been selected to identify unique records in a relation. In the student example, we choose Candidatekey1 as the primary key. Primarykey: (SSN)

Selection of a Primary Key

The First: the candidate key must be unique within its domain at all times, where the domain is defined as a set of allowable values. For example, the candidate key SSN has a domain of numbers ranging from 100000000 to 999999999 (nine digit numbers). Each social security number should have one unique value from this domain. The Second: guideline in the selection of a primary key is that the candidate key can never change. For example, while email addresses may be unique, students may change email addresses during the course of the school year. A students social security number, on the other hand, will never change. The Third : Finally, a candidate key cannot hold NULL values. The term NULL value does not mean zero. Instead, a NULL value designates a non-existing or unknown value.

Alternate Keys
Because of the relational property stating that a relation cannot have duplicates, we should always be able to find a primary key for a relation. In the least desirable situation, we might have to use all of the attributes of a relation. The candidate keys that are not selected for the primary key are called the Alternate Keys, and a key that has more than one attribute is called a Composite Key. As we mentioned in Chapter 3, a relationship is not explicitly defined in the relational data model. Instead, we use common attributes to enforce the relationships between two relations. Therefore, the same attribute can appear in more than one series of relations.

10

Foreign Key
For example, the Department relation has the attribute DeptName, which also appears in the Student relation to indicate that students belong to departments, the primary relationship between these two relations. The Foreign Key is an attribute or a set of attributes for a relation that serves as a candidate key of some (possibly the same) relation.
We represent the Primary key in the relational data model by underlining the attribute(s) and a Foreign Key by

italicizing the attribute(s). Therefore, in the following example, SSN serves as the primary key and DeptName as the foreign key of STUDENT. DeptName serves as the primary key and CollegeID as the foreign key of DEPARTMENT.
STUDENT (SSN, Name, Email, DeptName) DEPARTMENT (DeptName,Address, Phone, CollegeID)

1 1

Relational Data Integrity Constraints

The Relational Data Model includes several constraints and business rules that help maintain the Accuracy and Integrity of data that has been manipulated. In this section, we discuss Three Main Types of constraints: Domain Constraints, Entity Constraints, and Referential Constraints.

NULL
NULL simply means that the value is either unknown or is not applicable, and it allows us to handle incomplete or exceptional data. Many readers confuse NULL with the numeric value zero or with blank text; however, NULL only represents the absence of a value. For example, student fax numbers, occurs when there is no applicable data value for a particular attribute.

12

Domain Constraints
A Domain is the set of values that can be assigned to an attribute. The definition of a domain consists of the Domain Name, the Description, The Data Type, the Size, and other information related to Formatting and Ranges. For example, the attribute SSN has the following domain:

The domain constraint states that the values of an attribute must be from the same domain.

13

Entity Constraints
While assigning guidelines for the selection of the primary key, we mentioned that a candidate key that does not have NULL values is a good candidate for a primary key. Entity Constraints enforce this guideline as a constraint in the relational data model. Entity constraints ensure that every relation of a relational data model has a primary key and that the data values for the attributes of the primary key cannot be NULL. In the Student relation, for example, we cannot possibly enter a student record with no value for the SSN attribute. Because SSN is a primary key, it cannot contain a NULL value. However, suppose that we do have NULL values for primary key attributes. By definition, the primary key should still be able to uniquely distinguish records with NULL from the other records in the relation that do have values for the primary key.

14

Entity Constraints [Continue.]

Such a scenario implies that we can then drop the attribute with NULL values because the remaining attributes of the primary key should continue to uniquely identify records. If this is true, though, then we have found a new set of attributes (less than the number of attributes currently making up the primary key) for a candidate key. However, according to the definition of a primary key, no other set of attributes can uniquely identify tuples with fewer attributes than the primary key. Quite simply, this alternate set of attributes would, then, be the primary key. This contradiction tells us that, in the relational data model, the primary key can have NULL values.

15

Referential Constraints
The third integrity constraint pertains to foreign keys. Referential integrity constraints maintain consistency between two relations related to each other through the primary key-foreign key relationship. A Referential Integrity Constraint ensures that the foreign key values of a relation must match the primary key value of a (possibly the same) relation; otherwise, the value of a foreign key must be NULL. For example, consider the relationship between the Department and Student relations. The attribute DeptName is the foreign key in the Student relation and is the primary key in the Department relation. In keeping with the definition of a referential integrity constraint, the values for the DeptName attribute in the Student relation must match the values of the DeptName attribute in the Department relation, or they must be NULL.

16

Lets now see how the Referential Integrity Constraint maintains Data Consistency. We use the Department relation to store the information about all the universitys departments. When we add a new record to the Student relation, we should assign students to an existing department department relation). that is (from Assigning not in the a the Department

Department relation clearly results in data inconsistency. If we are not sure about the student's department, then constraints allow us to provisionally assign the NULL value to foreign key attributes.

17

Representation of Primary and Foreign Keys

We extend our notation for representing relations to the tabular graphical representation of relational schemas. A relation is represented in a tabular format by a list of attributes that begins with the primary key. A relation name appears above the box for each relation. This method allows us to clearly represent referential integrity constraints. We add an arrow starting from a foreign key attribute or attributes pointing to the associated primary key attribute(s) to represent the constraint.

Primary Key Foreign Key

18

Transforming ER Diagrams into Relational Schemas

Task 1: Transforming Regular Entities Regular entities are independent entities that represent real world objects, such as people, activities, or products. We represent these entities with a rectangular block in an ER-diagram. To transform any regular entity from an ER-diagram into a relational schema, we follow these steps: 1- Transform each regular entity type in an ER-diagram into a relation in the relational schema. 2- Assign the name of the relation to the entity in the ER-diagram. 3- Make each simple attribute of a regular entity an attribute of a relation. 4- Make the identifier of the regular entity type the primary key of a relation.

19

Transforming a Regular Entity.

Task 2: Transforming Composite Attributes When an entity type has Composite Attributes, we only have to make one change in the rules for the regular entity. We include simple attributes of a composite attribute in the relation.

Transforming a Composite Attributes

20

Task 3: Transforming Multi-Valued Attributes

We could add multiple values of a single record in a relation; however, this is prohibited by the properties of a relation. A relation has exactly one value for each of its cells. This feature demands a slightly different set of rules for multi-valued attributes: 1- Transform the regular entity as previously described; however, do not add a multi-valued attribute to the relation. 2- Create a new relation (one for each multi-valued attribute). The new relation gets two attributes: the primary key of the regular entity and the multi-valued attribute itself. The name of the new relation should be a logical name that reflects the meaning of the multi-valued attribute. 3- The primary key of this new relation is a Composite Key. Both of the attributes make up the primary key of this new relation.

21

Transforming Multivalued Attributes

Note : Database designers frequently use this decomposition technique, as it Reduces Data Redundancy and Eliminates Anomalies. For most of the remaining technique. transformations, we simply repeat the decomposition

22

Task 4: Transforming Unary Relationships. A) Transforming Unary (1-N) Relationships: do the following steps: 1- Transform the entity of a unary relationship as a regular entity described in Tasks 1-3. 2- Add a new attribute, the primary key of the same relation, as a foreign key. Draw an arrow that originates from the foreign key and points to the primary key. For example, Student Representative relationships:

N 1

Transforming a unary (1-M)relationship

23

B) Transforming Unary (M-N) Relationships: do the following steps: 1- Transform the entity of a unary relationship as a regular entity described in Tasks 1-3. 2- Create a new relation to represent the (M-N) relationship. Name the new relation to reflect the meaning of the relationship. 3- The new relation requires at least two attributes. The first attribute is the relations primary key, which represents the entity of a relationship. The second attribute represents the (M-N) relationship. The primary key of the entity relation migrates to the new relation. Therefore, in the case of a unary relationship, we get the same attribute twice as a foreign key in the new relation. 4- Draw referential integrity arrows for the foreign keys. Add the attributes on a (M-N) relationship for the new relation. 5- The primary key of a new relation is a composite key of foreign keys.

24

The Item is a regular entity with a unary (M-N) relationship, Contains, which represents the bill-of-material where items are assembled from other items. The relationship is many-to-many because an item can be assembled from one or more items, and, conversely, an item can be used to assemble one or more items.

N M

Transforming a unary (M-N) relationship

25

Task 5: Transforming Binary Relationships A) Transforming Binary (1-1) Relationships: 1-Create two relations, one for each entity in a binary relationship. 2-Transform each entity into a relation as a regular entity according to the process described in Tasks 1-3. 3-Include the primary key of one relation as a foreign key to the other relation. For one-to-one binary relationships, we can use minimum cardinalities to determine which relation should have a foreign key attribute. In such a pairing, the mandatory side migrates toward the optional side of the relationship. 4-Draw an arrow indicating the referential integrity constraint. 5-Any attributes of the relationship, as well as the foreign key, should migrate toward the optional side of a relationship.

26

Transforming a Binary (1-1) Relationship

B) Transforming Binary (1-M) Relationships: 1- Create two relations, one for each entity in a binary relationship. Transform each entity into a relation as a regular entity following the process described in Tasks 1-3. 2- Move the primary key of a relation on one side of the relationship toward the relation on the many sides of the relationship.

27

3- Draw an arrow indicating the existence of a referential integrity constraint. 4- Move any attributes on the relationship, along with the foreign key, toward the relation on the many sides of the relationship.

Transforming a Binary (1-M) Relationship

28

C) Transforming Binary (M-N) Relationships: 1- Create two relations, one for each entity in a binary relationship. Transform each entity into a relation as a regular entity following the process described in Tasks 1-3. 2- Create a third new relation to represent the many-to-many relationship. The name of the new relation should reflect the meaning of the relationship. 3- Move the primary key from both the relations (one for each entity in the relationship) to the new relation. Draw arrows for the referential integrity constraints. 4- The primary key of a new relation is a composite key with the foreign keys of relations. 5- Move any attributes of the relationship toward the third intermediate relation that represents the relationship.

29

Transforming a Binary (M-N) Relationship

30

Task 6: Transforming Ternary Relationships: 1- Create three relations, one for each entity in a ternary relationship. Transform each entity into a relation as a regular entity following the process described in Tasks 1-3. 2- Create a fourth relation that represents the ternary many-tomany relationship. The name of this new relation should reflect the meaning of the relationship. 3- Move the primary key from the first three relations (one for each entity in relationship) to the new relation. Draw arrows to signify referential integrity constraints 4- The primary key of a new relation is a composite key with its foreign keys. 5- Move any attributes on the relationship to this fourth relation.

31

Transforming a Ternary Relationship

32

Task 8: Transforming Weak Entities: In Chapter [ 3 ], we defined weak entities as those that cannot exist without another entity type. The weak entity depends on an entity called the identifying owner, or, simply, the owner. This relationship between a weak entity and its owner is called an identifying relationship. Weak entities have a partial key attribute or attributes, which, when combined with the primary key attribute(s) of its owner, provide the primary key for the weak entity. We can easily transform Weak Entities into a relational schema. To do so: 1- Create a relation for the owner entity type following the rules described in Tasks 1-3. 2- Create a new relation for a weak entity type and transform it to a regular entity.
33

3- Include the primary key of the owner relation as a foreign key in the weak entity relation. Draw an arrow indicating referential integrity constraint. 4- Make the primary key of a weak entity relation as the composite key formed by partial identifier attributes of a weak entity and a foreign key.

Transforming a Weak Entity

34

An ER Schema Diagram for the COMPANY Database

35

A Logical Design for the COMPANY Database

36