Informal Design Guidelines

March 23, 2008 DB:EER Model - 1 1

 Objectives

„ Measuring the Quality of Relational Database Design +

„ Database Design Methodology +
„ Informal Design Guidelines for Relational Schema +

March 23, 2008 DB:EER Model - 1 2

 - Measuring the Quality of Relational Database Design

„ At logical level
„ How users interpret relation schemas and the meaning of
attributes?

„ At the physical level

„ How the tuples in a base relation are stored and updated.

March 23, 2008 DB:EER Model - 1 3

 - Database Design Methodology

„ A Bottom-Up Method
„ We start by identifying all the attributes then trying to group
attributes based on some relationships, to build relations.

„ A Top-Down Method
„ We start by identifying all the grouping of attributes into relations
and then analyze these relation to further decompose them to
produce better relations.

„ Note: The theory discussed in this chapter is applicable to both

these approaches, but is more practical when applied to top-
down approach .

March 23, 2008 DB:EER Model - 1 4

 - Informal Design Guidelines for Relational Schema

„ The four informal Guidelines to measures the quality of

relational schema design are:
„ Guideline 1: Semantic of Relation Attributes +

„ Guideline 2: Reducing the Redundant Values in Tuples +

„ Guideline 3: Reducing the Null Values in Tuples +

„ Guideline 4: Disallowing Generating Spurious Tuples +

March 23, 2008 DB:EER Model - 1 5

 -- Guideline 1: Semantic of Relation Attributes

„ Design a relational schema so that it is easy to explain

its meaning.

„ Do not combine attributes from multiple entity types

and relationship types into a single relation.

„ Intuitively, if a relation schema corresponds to one

entity type, or one relationship type, the meaning tends
to be clear

March 23, 2008 DB:EER Model - 1 6

 --- Example of Good Design …

EMPLOYEE DEPT_LOCATIONS
Ename SSN Bdate Address Dnumber Dnumber Dlocation

DEPARTMENT WORKS_ON
Dname Dnumber Dmgrssn SSN Pnumber Hours

PROJECT
Pname Pnumber Plocation Dnum

March 23, 2008 DB:EER Model - 1 7

 … --- Example of Good Design…

EMPLOYEE Ename SSN Ddate Address Dnumber

Salah 111 1965-01-09 Khobar 5
Wael 222 1955-12-08 Khobar 5
Zaher 333 1968-07-19 Dammam 4
Walid 444 1941-06-20 Dhahran 4
Nasser 555 1962-09-15 Jubail 5
Essam 666 1972-07-31 Khobar 5
Jabber 777 1969-03-29 Khobar 4
Bader 888 1937-11-10 Khobar 1

DEPARTMENT Dname Dnumber DMGRManager

Research 5 222
Administration 4 444
Headquarters 1 888

March 23, 2008 DB:EER Model - 1 8

 … --- Example of Good Design

WORKS_ON Ssn Pnumber Hours

PROJECT 111 1 32.5

Pname Pnumber Plocation Dnum 111 2 7.5

Product X 1 Dhahran 5 555 3 40.0

Product Y 2 Jubail 5 666 1 20.0

666 2 20.0
Product Z 3 Khobar 5
222 2 10.0
Computerization 10 Dammam 4
222 3 10.0
Reorganization 20 Khobare 1
222 10 10.0
Newbenefit 30 Dammam 4 222 20 10.0
333 30 30.0
333 10 10.0
DEPT_LOCATIONS Dnumber Plocation
777 10 35.0
1 Khobar
777 30 5.0
4 Dammam
444 30 20.0
5 Dhahran
444 20 15.0
5 Jubail 888 20 null
5 Khobar
March 23, 2008 DB:EER Model - 1 9
 --- Example of Bad Design

EMP_DEPT
Ename SSN Bdate Address Dnumber Dname DmgrSsn

Dept. Specific info.

Employee Related info.

Attributes which violate the guideline

EMP_PROJ
SSN Pnumber Hours Ename Pname LOcation

Employee Related to project

March 23, 2008 DB:EER Model - 1 10

 -- Guideline 2: Reducing The Redundant Values in Tuples

„ Design the base relation schemas so that no insertion, deletion, or

modification anomalies are present in the relation.

„ If any anomalies are present, note them clearly and make sure
that the programs that update the database will operate correctly.

„ Due to improper grouping of attributes into a relation schema, the

following problems are encountered.
„ Storage wastage +

„ Insert anomalies +

„ Delete anomalies +

„ Modification anomalies +

March 23, 2008 DB:EER Model - 1 11

 --- Storage Wastage

Redundant data

Ename SSN Ddate Address Dnumber Dname DMGRManager

Salah 111 1965-01-09 Khobar 5 Research 222
Wael 222 1955-12-08 Khobar 5 Research 222
Zaher 333 1968-07-19 Dammam 4 Administration 444
Walid 444 1941-06-20 Dhahran 4 Administration 444
Nasser 555 1962-09-15 Jubail 5 Research 222
Essam 666 1972-07-31 Khobar 5 Research 222
Jabber 777 1969-03-29 Khobar 4 Administration 444
Bader 888 1937-11-10 Khobar 1 Headquarters 888

EMP_DEPARTMENT
Solution

March 23, 2008 DB:EER Model - 1 12

 --- Insert Anomalies

EMP_DEPARTMENT
Ename SSN Ddate Address Dnumber Dname DMGRManager
Salah 111 1965-01-09 Khobar 5 Research 222
Wael 222 1955-12-08 Khobar 5 Research 222
Zaher 333 1968-07-19 Dammam 4 Administration 444
Walid 444 1941-06-20 Dhahran 4 Administration 444
Nasser 555 1962-09-15 Jubail 5 Research 222
Essam 666 1972-07-31 Khobar 5 Research 222
Jabber 777 1969-03-29 Khobar 4 Administration 444
Bader 888 1937-11-10 Khobar 1 Headquarters 888
Ali 999 1967-10-15 Dammam
6 Accounting 111

A null primary Key Newly inserted rows

Solution

March 23, 2008 DB:EER Model - 1 13

 --- Delete Anomalies

EMP_DEPARTMENT
Ename SSN Ddate Address Dnumber Dname DMGRManager
Salah 111 1965-01-09 Khobar 5 Research 222
Wael 222 1955-12-08 Khobar 5 Research 222
Zaher 333 1968-07-19 Dammam 4 Administration 444
Walid 444 1941-06-20 Dhahran 4 Administration 444
Nasser 555 1962-09-15 Jubail 5 Research 222
Essam 666 1972-07-31 Khobar 5 Research 222
Jabber 777 1969-03-29 Khobar 4 Administration 444
Bader 888 1937-11-10 Khobar 1 Headquarters 888

Deleting Borg. James will delete the only information of department 1 from the database

Solution

March 23, 2008 DB:EER Model - 1 14

 --- Modification Anomalies

Updating the manager of Smith to 444 will cause inconsistency

Ename SSN Ddate Address Dnumber Dname DMGRManager

Salah 111 1965-01-09 Khobar 5 Research 444
Wael 222 1955-12-08 Khobar 5 Research 222
Zaher 333 1968-07-19 Dammam 4 Administration 444
Walid 444 1941-06-20 Dhahran 4 Administration 444
Nasser 555 1962-09-15 Jubail 5 Research 222
Essam 666 1972-07-31 Khobar 5 Research 222
Jabber 777 1969-03-29 Khobar 4 Administration 444
Bader 888 1937-11-10 Khobar 1 Headquarters 888

EMP_DEPARTMENT
Solution

March 23, 2008 DB:EER Model - 1 15

 -- Guideline 3: Reducing Null Values in Tuples

„ If possible avoid placing attributes in a base relation

whose values may frequently be null. If nulls are
unavoidable, make sure they apply in exceptional cases
only and not to majority of tuples in a relation.
„ Problems with null values:
„ Waste of disk space
„ Problem of understanding the meaning of attributes
„ Problems in specifying JOIN operations
„ Problems in applying some aggregate functions
„ May have multiple interpretations (not applicable, unknown,
unavailable)

March 23, 2008 DB:EER Model - 1 16

 -- Guideline 4: Disallowing generating Spurious Tuples …

„ Make sure that the foreign keys refer to unique keys.

Lid Fname Lname Salary SID Sname Lname

1 Adel Adam 1000 ICS334 DB Adel
2 Aggel Hassan 1100 ICS434 OS Yahya
3 Adel Khaled 1200 ICS202 DS Adel

Lecturers Subjects
Which Adel is the teacher of DB

March 23, 2008 DB:EER Model - 1 17

 … -- Guideline 4: Disallowing generating Spurious Tuples

SELECT L.LID, L.Fname, S.Sname

Lid Fname Lname Salary
FROM lecturers L, Subjects S
1 Adel Adam 1000 Where S.Fname = L.Fname
2 Ageel Hassan 1100
3 Adel Khaled 1200
LID Fname Sname
Lecturers
1 Adel DB
2 Yahya OS
SID Sname Fname 3 Adel DB
ICS334 DB Adel 1 Adel DS
ICS434 OS Yahya 2 Adel DS
ICS202 DS Adel

Subjects

March 23, 2008 DB:EER Model - 1 18

 -- Guideline 4: Disallowing generating Spurious Tuples

„ Design relational schemas so that they can be joined with equality

conditions of attributes that are easier primary keys or foreign keys in a
way that guarantees that no spurious tuples are generated. Do not have
relations that contain matching attributes other than foreign key-primary
key combination. If such relations are unavoidable, do not join them on
such attributes, because the join may produce spurious tuples

EMP_PROJ1 SSN Pnumber Hours Pname Plocation

EMP_LOCS Ename Plocation

EMP_PROJ SSN Pnumber Hours Ename Pname Plocation

March 23, 2008 DB:EER Model - 1 19