exam 2 review dr. bernard chen ph.d. university of central arkansas

Exam 2 Review

Dr. Bernard Chen Ph.D.University of Central Arkansas

Relational Model Concepts The relational model represents the

database as a collection of relations

Each relation resembles a table of values

When a relation is thought of as a table of values, each row in the table represents a collection of related data values

Formal Terminology A row is called a tuple A column header is called an

attribute The table is called relation

Domain A Domain D is a set of atomic values.

Atomic means that each value in the domain is indivisible as far as the relational model is concerned

It means that if we separate an atomic value, the value itself become meaningless, for example:

SSN Local_phone_number Names Employee_ages

Domain Constrains Each attribute A must be an atomic

value from the dom(A)

The data types associated with domains typically include standard numeric data type for integers, real numbers, Characters, Booleans, fix-length strings, time, date, money or some special data types

Key Constrains A relation is defined as a set of tuples By definition, all elements of a set are

distinct This means that no two tuples can have

the same combination of values for all their attributes

Superkey: a set of attributes that no two distinct tuples in any state r of R have the same value

Every relation has at least one default superkey – the set of all its attributes

Key Constrains

A superkey can have redundant attributes, so a more useful concept is that of a KEY which has no redundancy

Key satisfied two constrains: Two distinct tuple in any state of the

relation cannot have identical values for the attributes in the key

It is a minimal superkey

Key Constrains For example, consider STUDENT

relation The attribute set {SSN} is a key of

STUDENT because no two student can have the same value for SSN

Any set of attributes that includes SSN – for example {SSN, Name, Age} – is a superkey

Entity Integrity Entity Integrity:

The primary key attributes PK of each relation schema R in S cannot have null values in any tuple of r(R).

This is because primary key values are used to identify the individual tuples.

t[PK] null for any tuple t in r(R) If PK has several attributes, null is not allowed in any of

these attributes Note: Other attributes of R may be constrained

to disallow null values, even though they are not members of the primary key.

Referential Integrity Constraint Referential Integrity Constraint is specified

between two relations and is used to maintain the consistency among tuples in the two relations

Informally define the constrain: a tuple in one relation must refer to an existing tuple in that relation

For example, the Dno in EMPLOYEE gives the department number for which each employee works, this number must match the Dnumber value in DEPARTMENT

Referential Integrity Constraint Tuples in the referencing

relation R1 have attributes FK (called foreign key attributes) that reference the primary key attributes PK of the referenced relation R2. A tuple t1 in R1 is said to reference a

tuple t2 in R2 if t1[FK] = t2[PK].

Displaying a relational database schema and its constraints Each relation schema can be displayed as a row of attribute

names The name of the relation is written above the attribute

names The primary key attribute (or attributes) will be underlined

A foreign key (referential integrity) constraints is displayed as a directed arc (arrow) from the foreign key attributes to the referenced table

Can also point the the primary key of the referenced relation for clarity

Next slide shows the COMPANY relational schema diagram

Referential Integrity Constraints for COMPANY database

Modification and Updates In this section, we concentrate on the

database Updates and Modification

There are threee basic operation: Insert, Delete and Modify Insert is used to insert a new tuple or tuples

in a relation Delete is used to delete tuples Update (or Modify) is used to change the

values of some attributes

Possible violations for each operation INSERT may violate any of the constraints:

Domain constraint: if one of the attribute values provided for the new tuple is

not of the specified attribute domain Key constraint:

if the value of a key attribute in the new tuple already exists in another tuple in the relation

Referential integrity: if a foreign key value in the new tuple references a primary

key value that does not exist in the referenced relation Entity integrity:

if the primary key value is null in the new tuple

Possible violations for each operation DELETE may violate only referential integrity:

If the primary key value of the tuple being deleted is referenced from other tuples in the database

Can be remedied by several actions: RESTRICT, CASCADE, SET NULL

RESTRICT option: reject the deletion CASCADE option: propagate the new primary key value into

the foreign keys of the referencing tuples SET NULL option: set the foreign keys of the referencing

tuples to NULL

One of the above options must be specified during database design for each foreign key constraint

Possible violations for each operation UPDATE may violate domain constraint and NOT NULL

constraint on an attribute being modified

Any of the other constraints may also be violated, depending on the attribute being updated:

Updating the primary key (PK): Similar to a DELETE followed by an INSERT Need to specify similar options to DELETE

Updating a foreign key (FK): May violate referential integrity

Updating an ordinary attribute (neither PK nor FK): Can only violate domain constraints

Chapter Outline ER-to-Relational Mapping Algorithm

Step 1: Mapping of Regular Entity Types Step 2: Mapping of Weak Entity Types Step 3: Mapping of Binary 1:1 Relation Types Step 4: Mapping of Binary 1:N Relationship Types. Step 5: Mapping of Binary M:N Relationship Types. Step 6: Mapping of Multivalued attributes. Step 7: Mapping of N-ary Relationship Types.

Mapping EER Model Constructs to Relations

Step 8: Options for Mapping Specialization or Generalization.

Step 9: Mapping of Union Types (Categories).

Step 1: Mapping of Regular Entity Types

Step 1: Mapping of Regular Entity Types. For each regular (strong) entity type E in

the ER schema, create a relation R that includes all the simple attributes of E.

Choose one of the key attributes of E as the primary key for R.

If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R.

Step 2: Mapping of Weak Entity Types

For each weak entity type W in the ER schema with owner entity type E, create a relation R & include all simple attributes (or simple components of composite attributes) of W as attributes of R.

Also, include as foreign key attributes of R the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s).

The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any.

Step 3: Mapping of Binary 1:1 Relation Types

For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R.

Step 3: Mapping of Binary 1:1 Relation Types

Foreign Key approach: Choose one of the relations-say S-and include a foreign key in S the primary key of T. It is better to choose an entity type with total participation in R in the role of S.

Example: 1:1 relation MANAGES is mapped by choosing the participating entity type DEPARTMENT to serve in the role of S, because its participation in the MANAGES relationship type is total.

Step 4: Mapping of Binary 1:N Relationship Types

For each regular binary 1:N relationship type R, identify the relation S that represent the participating entity type at the N-side of the relationship type.

Include as foreign key in S the primary key of the relation T that represents the other entity type participating in R.

Include any simple attributes of the 1:N relation type as attributes of S.

Step 5: Mapping of Binary M:N Relationship Types

For each regular binary M:N relationship type R, create a new relation S to represent R.

Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S.

Also include any simple attributes of the M:N relationship type (or simple components of composite attributes) as attributes of S.

Step 6: Mapping of Multivalued attributes

For each multivalued attribute A, create a new relation R.

This relation R will include an attribute corresponding to A, plus the primary key attribute K-as a foreign key in R-of the relation that represents the entity type of relationship type that has A as an attribute.

The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its simple components.

Step 7: Mapping of N-ary Relationship Types

For each n-ary relationship type R, where n>2, create a new relationship S to represent R.

Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types.

Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S.

Summary of Mapping constructs and constraints

Table 7.1 Correspondence between ER and Relational Models

ER Model Relational ModelEntity type “Entity” relation1:1 or 1:N relationship type Foreign key (or “relationship” relation)M:N relationship type “Relationship” relation and two foreign keysn-ary relationship type “Relationship” relation and n foreign keysSimple attribute AttributeComposite attribute Set of simple component attributesMultivalued attribute Relation and foreign keyValue set DomainKey attribute Primary (or secondary) key

Step8: Options for Mapping Specialization or Generalization

Option 8A: Multiple relations-Superclass and subclasses

Option 8B: Multiple relations-Subclass relations only

Option 8C: Single relation with one type attribute

Option 8D: Single relation with multiple type attributes

Option 8A: Multiple relations-Superclass and subclasses

Option 8B: Multiple relations-Subclass relations only

Option 8C: Single relation with one type attribute

Option 8D: Single relation with multiple type attributes

Step 9: Mapping of Union Types (Categories)

For mapping a category whose defining superclass have different keys, it is customary to specify a new key attribute, called a surrogate key, when creating a relation to correspond to the category

Step 9: Mapping of Union Types (Categories)

Step 9: Mapping of Union Types (Categories)

Create Table exampleCREATE TABLE student (StudentId CHAR (5), Last VARCHAR2 (15) CONSTRAINT student_last_nn NOT NULL, First VARCHAR2 (15) CONSTRAINT student_first_nn NOT

NULL, Street VARCHAR2 (25), City VARCHAR2 (15), State CHAR (2) DEFAULT 'NJ', Zip CHAR (5), StartTerm CHAR (4), BirthDate DATE, FacultyId NUMBER (3), MajorId NUMBER (3), Phone CHAR (10), CONSTRAINT student_studentid_pk PRIMARY KEY (StudentID));

NAMING RULES AND CONVENTIONS A table is an object that can store data

in an Oracle database.

When you create a table, you must specify

1. the table name, 2. the name of each column, 3. the data type of each column, 4. and the size of each column.

Data Types

When a table is created, each column in the table is assigned a data type.

Some important data types: Varchar2 Char Number

Types of Constraints

There are two types of constraints:

1. Integrity constraints: define both the primary key and the foreign key with the table and primary key it references.

2. Value constraints: define if NULL values are disallowed, if UNIQUE values are required, and if only certain set of values are allowed in a column.

Popular Constraint abbreviations

Primary Key pk Foreign Key fk Unique uk Check ck Not Null nn

Defining a Constraint A constraint can be created at the

same time the table is created, or it can be added to the table afterward. There are two levels where a constraint is defined:

Column level. Table level.

Column level A column-level constraint references a

single column and is defined along with the definition of the column. 

Any constraint can be defined at the column level except for a FOREIGN KEY and COMPOSITE primary key constraints.

Column datatype [CONSTRAINT constraint_name] constraint_typeExample:

Building VARCHAR2(7) CONSTRAINT location_building_nn NOT NULL

Table level A table-level constraint references one or more

columns and is defined separately from the definitions of the columns.

Normally, it is written after all columns are defined.

All constraints can be defined at the table level except for the NOT NULL constraint.

[CONSTRAINT constraint_name] constraint_typ (Column, . . .),

Example:CONSTRAIN location_roomid_pk PRIMARY KEY(Roomid)

The Primary Key Constrain The PRIMARY KEY constraint is also known

as the entity integrity constraint

It creates a primary key for the table. A table can have only one primary key constraint. 

If a table uses more than one column as its primary key (i.e., a composite key), the key can only be declared at the table level. 

The Primary Key Constrain

At the column level, the constraints is defined byDeptId NUMBER (2) CONSTRAINT dept_deptid_pk PRIMARY KEY,

At the table level, the constraint is defined byCONSTRAINT dept_deptid_pk PRIMARY KEY(DeptId),

The FOREIGN KEY Constraint The FOREIGN KEY constraint is also

known as the referential integrity constraint.

It uses a column or columns as a foreign key, and it establishes a relationship with the primary key of the same or another table. 

The FOREIGN KEY Constraint To establish a foreign key in a table, the

other referenced table and its primary key must already exist. 

Foreign key and referenced primary key columns need not have the same name, but a foreign key value must match the value in the parent table’s primary key value or be NULL

The FOREIGN KEY Constraint

At the table level ONLYCONSTRAINT student_facultyid_fk FOREIGN KEY(FacultyId)REFERENCES faculty (FacultyId),

The NOT NULL Constraint The NOT NULL constraint ensures that the

column has a value and the value is not a null value

A space or a numeric zero is not a null value

At the column level ONLY, the constraint is defined by:

Name VARCHAR2(15) CONSTRAINT faculty_name_nn NOT NULL,

The UNIQUE Constraint The UNIQUE constraint requires that every

value in a column or set of columns be unique.

At the column level, the constraint is defined by:DeptName VARCHAR2(12) CONSTRAINT dept_deptname_uk UNIQUE,

At the table level, the constraint is defined byCONSTRAINT dept_deptname_uk UNIQUE(DeptName),

The CHECK Constraint The CHECK constraint defines a condition that every row

must satisfy

At the column level, the constraint is defined byDeptId NUMBER(2) CONSTRAINT dept_deptid_cc

CHECK((DeptId >= 10) and (DeptId <= 99)),

At the table level, the constraint is defined by:CONSTRAINT dept_deptid_cc

CHECK((DeptId >= 10) and (DeptId <= 99)),

Viewing a Table’s Structure The SQL*Plus command to view a

table’s structure is DESCRIBE, which does not need a semicolon at the end because it is not a SQL statement.

SQL> DESCRIBE student