WXGE 6101 DATABASE CONCEPTS & IMPLEMENTATIONS. Lesson Overview The Relational Model Terminology of...

WXGE 6101 DATABASE CONCEPTS & IMPLEMENTATIONS

Lesson Overview The Relational Model Terminology of relational model. Properties of database relations. Examples of Relations Transforming E-R Diagrams into the Relational

Model Representing 1:1 Relationship in the Relational Model Representing 1: M Relationship in the Relational Model Representing M: M Relationship in the Relational Model

The Relational Model

A relation is represented by a two-dimensional table.

The rows of the table (tuples) correspond to individual records and the columns correspond to attributes.

The column contains values of a single attribute. The domain of attributes is the allowable values

for that attribute.

Relational Data Model (cont…)

The relational model is based on the

mathematical notion of a relation. A relational model enables us to view data

logically rather than physically. A relation is physically represented as a table. These tables are used to hold information about

objects to be represented in the database.

Most popular data model Uses simple tables of columns and rows where

the columns represent fields and rows represent records

Application will have many linked tables 1 or more field can become a key field Key field is used to establish links to other tables Links allow you to access information contained

in related tables

Relational Data Model (cont…)

Relational Model Terminology A relation is a table with columns and rows.

Only applies to logical structure of the database, not the physical structure.

Attribute is a named column of a relation.

Domain is the set of allowable values for one or

more attributes.

Alternative Terminology for Relational Model

Relational Model Terminology Tuple is a row of a relation.

Relational Database is a collection of normalized relations with distinct relation names.

Properties of Relations

Relation name is distinct from all other relation names in the relational schema.

Each cell of relation contains exactly one atomic (single) value.

Each attribute has a distinct name.

Values of an attribute are all from the same domain.

Properties of Relations Each tuple is distinct; there are no

duplicate tuples.

Order of attributes has no significance.

Order of tuples has no significance, theoretically.

Both entity sets and relationship sets are shown as tables.

The STUDENT relation is represented by the STUDENT table.


The STUDENT table have columns for attributes STUID, STUNAME, MAJOR, and CREDITS.

A column contains values of a single attribute.

The STUID column contains only IDs of students.

The domain of attributes is the allowable values for that attribute.


STUID STUNAME MAJOR CREDITS S1015 Ibrahim Math 42 S1005 Isa History 56 S1001 Lim History 78 S1010 Adam CSC 90 S1002 Chin Art 36 S1013 Raju Math 0 S1020 Aisha CSC 80

STUDENT Relation

The column names at the top of the table corresponds to the attributes of the relations.

The values in the STUID column are all from the domain of STUID, other values are not permitted,e.g. student names will not be allowed.

Columns can be interchanged if we know from the column names which attribute each column represents.

STUDENT Relation

The table would remain the same if we place the CREDITS column before the MAJOR column.

There can be no duplicate rows because each individual student is represented just once.

The row S1005, Isa, History, 56 appears only once.

STUDENT Relation

The conceptual schema can be represented by E-R diagrams.

Objects which we would like to record are represented by entities.

The association between entities are reprsented by relationships.

Most of the relationship encountered in practical database mangement are of degree 2, i.e. they are binary.

Transforming E-R diagrams into the Relational Model

In transforming entities into the relational model we begin by defining a relation for each entity.

The name for the relation is the same as the name of the entity.

The attributes of the relation is the attribute of the relation.


The STUDENT entity contains the following attributes:

STUID, STUNAME, MAJOR, CREDITS, GRADE.

To define this entity with a relation we define a relation for the entity and place the attributes in it as columns.

If we know the attribute that identifies the entity, this attribute will become the key of the relation.


otherwise we must investigate the user requirements to determine what attribute or attributes can identify the entity.

In the case of STUDENT entity STUID is the key.

The keys are underlined in the following relation.


STUNAMESTUID GRADE

STUDENT

MAJORCREDITS

STUDENT (STUDENT (STUID,STUNAME, MAJOR, CREDITS, GRADE)

Representation of an Entity with a Relation

RELATION

ENTITY

In a 1:1 relationship one enity type is associated with no more than one entity of another type.

Suppose an employee is assigned exactly one company car and a car is assigned to exactly one employee.

This relationship is thus 1:1.

Representing 1:1 Relationships in the Relational Model

Representing a 1:1 relationship with the relational model is straightforward.

Each entity is represented with a relation.

The key of that relation is then placed in the other relation.

Thus for the 1:1 relationship EMPLOYEE-Car, the key of EMPLOYEE is placed in CAR and the key of CAR is placed in EMPLOYEE.


EMPLOYEE 1:11:1 CARCAR

1.EMPLOYEE (1.EMPLOYEE (EMPNOEMPNO, EMPNAME, EMPADD,SALARY, REGNO), EMPNAME, EMPADD,SALARY, REGNO)

CAR (CAR (REGNOREGNO, SERIALNO,COLOR, MAKE, MODEL), SERIALNO,COLOR, MAKE, MODEL)

2.EMPLOYEE (2.EMPLOYEE (EMPNOEMPNO, EMPNAME, EMPADD,SALARY), EMPNAME, EMPADD,SALARY)

CAR (CAR (REGNOREGNO, SERIALNO,COLOR, MAKE, MODEL, EMPNO), SERIALNO,COLOR, MAKE, MODEL, EMPNO)

oror


EMPNO is a foreign key in in CAR and REGNO is a foreign key in EMPLOYEE.

The key of either table can be placed in the other table.

When the foreign key EMPNO is placed in CAR we can navigate from EMPLOYEE to CAR.


Suppose we have an employee and we want to know the car that has been assigned to that employee.

We use EMPNO to look up the the employee’s row in EMPLOYEE.

From this row we obtain the REGNO of the car assigned to that employee.

We then use this key to look up the car data in CAR.


Suppose we want to know the employee that has been assigned to a particular car.

To get the car data, we use REGNO to obtain the car’s row in CAR.

From this row, we obtain the EMPNO of the employee that has been assigned this car.

We then use this key to look up the employee data in EMPLOYEE.


We can navigate from EMPLOYEE to CAR and CAR to EMPLOYEE using the appropriate design.

To go from CAR to EMPLOYEE we look up the row in the CAR relation having the given REGNO.

From this row we extract the the EMPNO and use this to access the employee data.


To go from EMPLOYEE to CAR we look up the row of EMPLOYEE having the given EMPNO.

From this row we extract the the REGNO and use this to access the car data.

Although the two designs are equivalent in concept they may be different in performance.


If a query in one direction is more common than a query in the other, we may prefer one design to the other.


The second type of binary relationship is 1:M in which an entity of one type can be related to many entities of another type.

This type of relationship is a parent child relationship.

Representing 1:M Relationships in the Relational Model

Consider the relationship between DEPT and EMPLOYEE.

This means that an employee can be attached with at most one department but a department can have more than one employees.

Thus DEPT is the parent and EMPLOYEE is the child.


Representing 1:M relationships is also simple.

First each entity is represented by a relation.

Then the key of the relation representing the parent entity is placed in the relation representing the child entity.

To represent the DEPT-EMPLOYEE relationship we place the key of DEPT, i.e. DNO in the EMPLOYEE relation.


1:M1:MDEPTDEPT EMPLOYEEEMPLOYEE

The 1:M Relationship of DEPT_EMPLOYEEThe 1:M Relationship of DEPT_EMPLOYEE

DNO DNO DNAME MGR DNAME MGR

ENO ENO ENAME EADD ENAME EADD DNODNO

Data-Structure Diagram Showing the Relational Representation Data-Structure Diagram Showing the Relational Representation of DEPT-EMPLOYEE. of DEPT-EMPLOYEE.


The relational scheme for the DEPT_EMPLOYEE relationship is :

DEPT (DNO, DNAME, MGR) EMPLOYEE (ENO , ENAME, EADD, DNO

). We can process this relationship in both

directions.


Given EMPNO we can look up the appropriate row in EMPLOYEE and get the DNO of the department from the row data.

To get the rest of the DEPT data we use the DNO obtained from EMPLOYEE to look up the appropriate row in DEPT.

To obtain all the employees name attached to a certain department we look up all rows in EMPLOYEE having the the department’s


DNO. The employee data is obtained from these rows.

In a 1:1 relationship it does not matter in which relation we store the foreign key.

In a 1:M relationship we store the key of the parent relation in the child relation.

Suppose we try to put the child’s key in the parent relation.


Attributes can only have single values. The DEPT relation can only store the record of

only one employee. The structure cannot be used to store the

“many” side of the 1:M relationship. Thus, we place the key of the parent relation in

the child relation.


Many-to-many relationship is a relationship where one entity type corresponds to many entities of the second type, and an entity of the second type corresponds to many entities of the first type.

STUDENT-COURSE is an M:M relationship.

Representing M:M Relationships in the Relational Model

A student can register for many courses and a course can be taken by many students.

M:M relationships cannot be represented by relations in the same way that 1:1 and 1:M relationships are.

First we define a relation for each of the entities; one relation for STUDENT and another relation for COURSE.


We cannot put the key of COURSE (CNO)in the STUDENT relation because there are many courses and multiple values are not allowed in the cells of a relation.

We have room only for one CNO so what do we do with the other courses that the student has registered for ?

The same problem will occur if we try to put the key of STUDENT(SNO) in COURSE.


We can readily store the key of the first course for which the student is registered.

We have no place to store the identifier of the second and subsequent courses .

The following table shows an incorrect representation of a M:M relationship.


SNO Other Data

S1002 ...

S1015 ...

S1003 ....

STUDENT Relation

CNO Other COURSE Data

SNO

10 .... S1002

10 .... S1003

30 ... S1003

20 ... S1015

30 ... S1015

COURSE Relation

In the table we have stored a row in the COURSE for each STUDENT registered for each course.

So there are two records for COURSE 10 and two records for COURSE 30.

We have duplicated the Course data and create modification anomalies.

If we change the Course 10’s schedule we will have to change all the rows involved. (Modification Anomaly)


How can we schedule a course until a student has registered for it ? (Insertion Anomaly)

What happens if Student S1015 drops out of course 20 ? (Deletion Anomaly)

The solution to this is to create a third relation that represents the relationship itself.

This relation will store the correspondence of students to courses


Such relations are called intersection relations.

Each row of the relation documents the intersection of a particular student with a particular course.

The data structure diagram for the following relationships is as follows:


SNOSNO SNAME MAJOR CREDITS SNAME MAJOR CREDITS

CNO CNAME ROOMCNO CNAME ROOM

SNOSNO CNOCNO

STUDENTSTUDENT

COURSECOURSE

Data Structure Diagram For STUDENT COURSE R’ship

The relationship from STUDENT to STUDENT-COURSE is 1:M.

The relationship from COURSE to STUDENT-COURSE is also 1:M.

The M:M relationship has been decomposed into two 1:M relationships.

The key of STUDENT-COURSE is the combination of the keys of both its parents.

STUDENT-COURSE Relationship

The key for an intersection relation is always the combination of parent keys.

The relational scheme is as follows: STUDENT (SNO, SNAME, MAJOR, CREDITS). COURSE (CNO, CNAME, ROOM) STUDENT-COURSE (SNO, CNO)

STUDENT-COURSE Relationship

A relation is represented by a two-dimensional table.

The rows of the table (tuples) correspond to individual records and the columns correspond to attributes.

The column contains values of a single attribute. The domain of attributes is the allowable values

for that attribute.

SUMMARY

Each cell of the table contains only one value.

The values in a column all come from the same attribute.

Each tuple is distinct there are no duplicate tuples

The order of columns/rows(tuples) is immaterial.

SUMMARY

Entities are transformed into the relational model by defining a relation for each entity.

The name for the relation is the same as the name of the entity.

The attributes of the relation is the attribute of the relation.

The attribute that identifies the entity becomes the key of the relation( keys are underlined ).

SUMMARY

In a 1:1 relationship each entity is represented with a relation.

The key of that relation is then placed in the other relation.

The key of one relation that is stored in a another relation is called a foreign key.

We use this key to navigate from one relation to another.

SUMMARY

In a 1:M relationships each entity is represented by a relation.

Then the key of the relation representing the parent entity is placed in the relation representing the child entity.

SUMMARY

M:M relationships cannot be represented by relations in the same way that 1:1 and 1:M relationships are.

We define a relation for each of the entities; one relation for STUDENT and another relation for COURSE.

Next we create a third relation that represents the relationship itself.

SUMMARY

This relation will store the correspondence of students to courses

The key of the intersection record is the combination of the keys of both its parents.

SUMMARY

WXGE 6101 DATABASE CONCEPTS & IMPLEMENTATIONS. Lesson Overview The Relational Model Terminology of...

Documents

Transcript of WXGE 6101 DATABASE CONCEPTS & IMPLEMENTATIONS. Lesson Overview The Relational Model Terminology of...