Chapter-3

Logical Database Design

Converting ER diagrams to Relational Schema

Introduction
The entire database and more particularly the modern database uses a very important data model called as the Relational Model. This model was proposed by Codd in the year 1970. During that time the popular models were only Network model and Hierarchical model.

Logical database design

Process of converting the conceptual model into an equivalent representation in the implementation model (relational/hierarchic/network etc.) We will focus on the relational model

Relational database design

Convert ER model into relational schema (a specification of the table definitions and their foreign key links) There are well defined rules for this conversion

Relation
The relational model represents the database as a collection of relations. Each relation resembles a simple table, having a set of rows and set of columns. Each relation consists of a relational schema and relational instance. The instance is nothing but a relation having a set of specific values for the records in the database at a particular time.

Example
Name
Prasad

RegNo
1BI99CS045

Addr
456, Koramangala

Phone
5567234

DBirth
23-Mar-67

GPA
8.9

Gaurav

1BI98CS012

2, J.C. Road

6623109

10-Dec-66

4.5

Ayswaria

1BI97CS044

12, K.S. Layout

6669456

04-Aug-65

9.0

BrName
VV Puram JC Road Jayanagar MG Road Gandhinagar

BrCity
Bangalore Mysore Bangalore Belgaum Belgaum

Assets
10034567 2390156 6784560 12445566 67888888

Relation - Definition
A relation R is a subset of the Cartesian product of the domains that define R R (dom(A1)) (dom(A2)) . . . (dom(An)) This actually gives the total number of tuples in the Cartesian product. R is represented as, R (A1, A2, . . ., An). The degree of a relation is the number of attributes that a relation has and the cardinality of the relation instance is the number of tuples in it.

RELATIONAL MODEL CONSTRAINTS

An integrity constraint is a restriction specified on a database schema. The term integrity refers to the accuracy or correctness of data in the database. Example: an attribute Marks in a Student relation can take values only from 0 to 100.

Domain Constraints
The domain constraints specifies the value of each attribute A that must be an atomic value from the domain dom(A). Example: The type integer may hold all the integer values may be allowed. Oracle allows VARCHAR2, NUMBER, CHAR, INTEGER, DATE, LONG, RAW, LONG RAW, BLOB, CLOB, BFILE.

Key Constraints
A key constraint is a declaration to specify a minimal set of attributes to find a tuple uniquely in a relation. Candidate Key: Definition Let K be a set of attributes of the relation R. Then, K is a candidate key if and only if it satisfies the following two conditions: (1) Uniqueness: No legal values of R ever contain two distinct tuples with the same value. (2) Irreducibility: No proper subset of K has the uniqueness property.

Eg-1: {Sid, Name} is not a candidate key, because this set properly contains the key {Sid} Eg-2: {BranchName, BranchCity} is not a candidate key

Key Constraints
Super Key A superset of a candidate key is a super key. A super key has the uniqueness property but not necessarily the irreducible property. Eg: {Sid, Name} is a super key Primary Key It is customary to have one of the candidate keys as the primary key of the relation. It is better to choose a primary key with minimal set of attributes. Eg: {SSN}, {RegNo}, {PartNo}, etc. Can the subset {CFirstName, CLastName, CPhone} form a primary key?

Key Constraints
Foreign Key A foreign key is a set of attributes of a relation, say, R2 whose values are required to match values of some primary key of some other relation R1. The foreign key constraint is necessary between any two relations to maintain the data consistency.
Eg: Employees(SSN, Name, .., DNo) Departments(DNumber, DName) DNo in Employees relation is called as foreign key. What happens when insertion, deletion, or modification is done to the records with the enforced constraints?

Converting ER diagrams to relational schema Converting Entity into RELATION/Table Converting Attributes into Column or table Converting Relationships into Attributes or tables

Converting Attributes to Columns

Each single-valued attribute becomes a column Derived attributes are ignored Composite attributes are represented by components Multi-valued attributes are represented by a separate table The key attribute of the entity type becomes the primary key of the table

ER to Relational mapping
Strong Entity to Table: For every strong entity E, create a table R that includes all the simple attributes of E.
Addr
Name Salary Sex BDate

SSN

Employees

Employees(SSN,Name,BDate,Addr,Sex,Salary)

Entity example

Address is a composite attribute Years of service is a derived attribute (calculated from DOJ & current date) Skill set is a multi-valued attribute Employee (E#, Name, Door_No, Street, City, Pincode, Date_Of_Joining) Emp_Skillset( E#, Skillset)

Converting weak entity types

E# ADDR REL E_NAME SAL D_NAME

Weak entity types are converted into a table of their own, with the primary key of the strong entity acting as a foreign key in the table This foreign key along with the key of the weak entity form the composite primary key of this table
The Relational Schema Employee (E# ,.) Dependant (E#, D_Name, Address,REL)

Converting Relationships
The way relationships are represented depends on the cardinality and the degree of the relationship The possible cardinalities are: 1:1, 1:M, N:M The degrees are: Unary Binary Ternary

Unary 1:1
Consider employees who are also a couple The primary key field itself will become foreign key in the same table

Employee( E#, Name,... Married_to)

Unary 1:N

The

primary key field itself will become foreign key in the same table Same as unary 1:1
Employee( E#, Name,,Manager)
PK FK

Unary M:N

There will be two resulting tables. One to represent the entity and another to represent the M:N relationship Employee( E#, Name,) Guarantor_of( Guarantor E#, Beneficiary E# )

Binary 1:1

Case 1:Combination of participation types The primary key of the partial participant(EMPLOYEE) will become the foreign key of the total participant. Employee( E#, Name,) Department (Dept#, Name,E#_Head)

Binary 1:1
1
1

Case 2: Uniform Participation types

The primary key of either of the participants can become a foreign key in the other Employee (E#,name) Chair( item#, model, location, used_by) (or) Employee ( E#, Name.Sits_on) Chair (item#,.)

Binary 1:N

The primary key of the relation on the 1 side of the relationship becomes a foreign key in the relation on the N side
FK Teacher (ID, Name, Telephone, ...)

Subject (Code, Name, ..., Teacher_ID)

Binary M:N

A new table is created to represent the relationship Contains two foreign keys one from each of the participants in the relationship The primary key of the new table is the combination of the two foreign keys Book (Acc#,Title) Employee (E#,Name,) Issue (Book#, E#)

Many-to-Many cardinality

Name SSN Addr

Hours PNumbere r N

PName PLocation

Employees

Works_O n

Projects

Works_On (SSN, PNo, Hours)

Ternary relationship

Ternary relationship represented by a new table The new table contains three foreign keys one from each of the participating Entities The primary key of the new table is the combination of all three foreign keys Prescription (Doctor#, Patient #,Medicine_Name)

Handling multi valued attribute

Each multi valued attribute should be translated into a table. Then the primary key for this table is nothing but the primary key of the participating entity.
DNumber
DName DNumberer Locations

DLocation

1
2 3 2

Bangalore
Belgaum Bangalore Chennai

Departments

Handling Generalization:
Tables to be created are: AccN o Balanc e Account (Method-1) 1. Account(AccNo, Balance) 2. SB(AccNo, Int_Amt) 3. FD(AccNo, Dep_Amt)
ISA

4. RD(AccNo, Rec_Amt) 5. CA(AccNo, Od)

SB

FD

RD

CA

Method-2:

SB(AccNo, Balance, Int_Amt)

Int_Amt
Dep_Am t Rec_Am t Od

FD(AccNo, Balance, Dep_Amt)

Handling Aggregation:
RegNo StdName

Students
CourseTiitle CourseId Credits

PName SSN

Attends

Professors

Teaches

Courses

Professors(SSN, PName) Courses(CourseId, CourseTitle, Credits) Students(RegNo, Stdname)

Attends(RegNo, CourseId, SSN)

Teaches(CourseId, SSN)

End of Chapter 3