Database part3-

Course code: ITI131
Course title : Database
PART: 3
Prof. Taymoor Mohamed Nazmy
Dept. of computer science, faculty of computer science, Ain Shams uni.
Ex-vice dean of post graduate studies and research Cairo, Egypt
1

4
Database Design
Data
Modeling Refinement/
Normalization
SQL
Tables
E/R diagrams Relations
Files

Steps in Database Design
• Requirements Analysis
– user needs; what must database do?
• Conceptual Design
– high level description (often done w/ER model)
• Logical Design
– translate ER into DBMS data model
• Schema Refinement
– consistency, normalization
• Physical Design - indexes, disk layout
• Security Design - who accesses what, and how
5

6
Entity Relation (ER) Diagram
 1976 proposed by Peter Chen
 ER diagram is widely used in database design
 Represent conceptual level of a database system
 Describe things and their relationships in high level
 The diagram consists of a small set of symbols, there are
more than one notation model most important are for Chen
model symbols, and Crow’s Foot Model

(ER) model
• The entity-relationship (ER) model
– Basic constructs:
• Entities
• Relationships
• Attributes (of entities and relationships)
– Advanced constructs:
• Constraints
• Weak entities
• Aggregation
7

ERD Elements
• Entities
– Things about which you collect information
• Relationships
– Means of association between entities
• Identifiers
– Unique attributes of the entity
• Attributes
– Characteristic or property of the entity that is of
interest

9
9
Entity
►is a real-world object distinguishable or unique from other
objects.
►An entity can be a concrete or physical object like
employee, student, faculty, customer etc. Or it could also be
conceptual or abstract like transaction, order, course,
subjects etc.
►It can be thought of as a noun like student, employee etc.
►It is normally represented by a rectangle shape.

10
10
Relationship
►is a way of relating one entity to another.
Entities can therefore participate in a
relationship.
►it is commonly thought as a verb connecting
the entities or nouns.
►It is normally represented by a diamond shape.

11
11
Example of Entities with Relationship
Person belongs Location
Student enrolls Subject(s)
Faculty teaches Subject(s)

12
12
Types of Relationship
►One-to-One
►One-to-Many
►Many-to-Many

13
13
Types of Relationship
Student has ID
Division has Program
Student enrolls Subject
1 1
1 M
MM
One-to-One
One-to-Many
Many-to-Many

14
14
Types of Relationship (Crow Notation)
Student has ID
Division has Program
Student enrolls Subject
One-to-One
One-to-Many
Many-to-Many

Mapping Cardinalities
• One-to-One
• One-to-Many
• Many-to-One
• Many-to-Many
customer has account

Multicity Symbols
M-to-N1-to-1 1-to M M-to-1

17
17
Attribute
►Refers to the characteristic or basic fact or field of an
Entity or Relationship.
►For example a Student entity could have the following
attributes ID Number, Last Name, First Name, Address,
Birth Date etc.
►A relationship could also have an attribute for example an
Entity name Student enrolls (relationship) to a
Course/Program. Now, when you enroll you enroll on a
certain date so you will have an attribute of Enrollment
Date under Enroll relationship
►It is normally represented by a circle, but in some other
notation may be different.

18
Entity Set to Relation
Product
name category
price
Product(name, category, price)
name category price
gizmo gadgets $19.99

19
19
Example of Attributes
Student
ID No.
Lastname Firstname
Gender
Address
Birth date
Email
Note : A Primary Key is Underlined, in this case the ID No.

20
20
Student
ID No.
Lastname Firstname
Gender
Address
Birth date
Email
enrollsProgram
Enrollment
Date
Program ID
Name
Chairperson
has Faculty
ID No.
Lastname
Firstname

21
21
Student
ID No.
Lastname Firstname
Gender
Address
Birth date
Email
enrollsProgram
Enrollment
Date
Program ID
Name
Chairperson
has Faculty
ID No.
Lastname
Firstname

Note that
• Relationships: diamond (may or may not be
used), on a line showing the “cardinality” of
the relationship (1 to many), etc.
• Identifiers: Underlined text
• Attributes: It may be not shown

SUMMARY OF ER-DIAGRAM
CHEN NOTATION/SYMBOLES
Multicity Symbols

Weak Entity
• Weak Entity set: An entity set that does not
have enough attributes to form a primary key.
• it must use a foreign key in conjunction with
its attributes to create a primary key. The
foreign key is typically a primary key of an
entity it is related to.

Composite, Multi Valued, and Derived Attributes
Composite attributes:
Composite attributes can be divided into subparts. For example, an attribute
name could be structured as a composite attribute consisting of first-name,
middle-initial, and last-name.
Multivalued attributes:
There may be instances where an attribute has a set of values for a specific
entity. Consider an employee entity set with the attribute phone-number. An
employee may have zero, one, or several phone numbers, and different
employees may have different numbers of phones.
Derived attribute:
• The last category that attributes can be defined is called a derived attribute,
where one attribute is calculated from another attribute. The derived
attribute may not be stored in the database but rather calculated using
algorithm.

Strong Entity Relation:
ssno name
salary
employee
Employee(ssno name salary)
Key : ssno
ER to Relational Mapping

Online ER diagram creator
• https://erdplus.com/#/

Table: Employee
Employee
number
Name
Attributes

Table: Employee
Employee
number
Name Birth Date Age Salary
Key Attribute

Table: Employee
Employee
number
Name Address Age Salary
Composite
Attribute

Table: Employee
Employee
number
Multi Valued
Attribute

Table: Employee
Employee
number
Single Valued
Attribute

Table: Employee
Employee
number
Name Address Fax No /
Tele. No
Salary
Null Valued
Attribute

Table: Employee
Employee
number
Name Birth Date Age Salary
Derived

Employee
Attributes
Emp_no
Birth Date
Age
Salary
Name

Key
Attribute
Emp_no
Employee
Birth Date
Salary
Name

Employee
Multi valued
Attribute
Emp_no
Name
Salary
Name

Employee
Name
Street
Address
Area
City
Composite
Attribute

Employee
Emp_no
Birth Date
Age
Salary
Name
Derived
Attributes

Manager
Mno Name
Salary
Birth
Date
Department
Mno Dname
Works
11

Employee
Empno Name
Salary
Birth
Date
Department
Empno Dname
Works
1M

Employee
Empno Name
Salary
Project
PId Ptype
Works
NM
Start
date
End
date

ER Diagram Of Banking System
Bank
Bank
branch
Branches
Account
Acct no
Balance
Acc
Type
Accts Loans
Loan
Loan
no
Amount
Loan
Type
1 M
1
M
1
M
Bno Addr
Name
Code Addr

56
Step 1 Build Conceptual Data
• To build a conceptual data model of the data
requirements of the enterprise.
– Model comprises entity types, relationship types, attributes and
attribute domains, primary and alternate keys, and integrity
constraints.
• Step 1.1 Identify entity types
– To identify the required entity types.
• Step 1.2 Identify relationship types
– To identify the important relationships that exist between the
entity types.

57
• Step 1.3 Identify and associate attributes with entity or
relationship types
– To associate attributes with the appropriate entity or
relationship types and document the details of each
attribute.
• Step 1.4 Determine attribute domains
– To determine domains for the attributes in the data model
and document the details of each domain.

58
• Step 1.5 Determine candidate, primary, and
alternate key attributes
– To identify the candidate key(s) for each entity and if there is
more than one candidate key, to choose one to be the primary
key and the others as alternate keys.
• Step 1.6 Check model for redundancy
– To check for the presence of any redundancy in the model and to
remove any that does exist.
• Step 1.7 Validate conceptual model against user
transactions
– To ensure that the conceptual model supports the required
transactions.

Converting a text description into an E-R model:
Review the conceptual description of the business
area for nouns that describe the system, and to be an
entity.
Each entity type should have more than one
attribute.
Look for verbs to be the relation that connect the
entities. Determine the expect multiplicity between
entities.

Example: building ER diagram
for a university
A university consists of a number of departments. Each
department offers several courses.
A number of modules make up each course. Students enrol in a
particular course and take modules towards the completion of
that course.
Each module is taught by a lecturer from the appropriate
department, and each lecturer tutors a group of students
60

Example - Entities
A university consists of a number of departments.
Each department offers several courses.
A number of modules make up each course.
Students enrol in a particular course and take modules towards
the completion of that course.
Each module is taught by a lecturer from the appropriate
61

Example - Relationships
• A university consists of a number of departments. Each
department offers several courses.
• A number of modules make up each course.
• Students enrol in a particular course and take modules
towards the completion of that course.
• Each module is taught by a lecturer from the appropriate
62

Example - E/R Diagram
ModuleCourse
Department
Student
Lecturer
Entities: Department, Course, Module, Lecturer, Student
63

ModuleCourse
Department
Student
Lecturer
Offers
Each department offers several courses
64

ModuleCourse
Department
Student
LecturerIncludes
Offers
A number of modules make up each courses
65

ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Students enrol in a particular course
66

ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Takes
Students … take modules
67

ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Takes
Teaches
Each module is taught by a lecturer
68

ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Takes
Employs
Teaches
a lecturer from the appropriate department
69

ModuleCourse
Department
Student
LecturerIncludes
Offers
TutorsEnrols In
Takes
Employs
Teaches
each lecturer tutors a group of students
70

ModuleCourse
Department
Student
LecturerIncludes
Offers
TutorsEnrols In
Takes
Employs
Teaches
71

Converting ER diagrams into SQL

Class diagram
• The Unified Modeling Language (UML) was
designed for software engineering of large systems
using object-oriented (OO) programming languages.
• UML is a very large language; which can be
implemented for different tasks.
• http://www.tomjewett.com/dbdesign/dbdesign.php?p
age=models.html

76
ER vs. UML Terminology (Class diagram)
ER Diagram
Entity Type
Entity
Attribute
Domain
~ [Derived Attribute]
Relationship Type
Cardinality
• UML Class Diagram
• Class
• Object
• Attribute
• Domain
• Operation
• Association
• Multiplicities

Classes
ClassName
attributes
operations
A class is a description of a set of
objects that share the same attributes,
operations, relationships.
Graphically, a class is rendered as a
rectangle, usually including its name,
attributes, and operations in separate,
designated compartments.
The operation includes any calculations
such as average, account, sum ,max,
etc

ER vs. Class diagram
Employee
E#
FNAME LNAME
NAME
Employee
NAME:
FNAME
LNAME
…
Attributes
Methods
or
operation
Class

Example for class diagram for a database

82
Introduction
Relational Designing Levels
PersonbuysProduct
name
price name ssn
Conceptual Model:
Relational Model:
Normalization:
Eliminates anomalies
(inconsistence) by decomposing
tables, using Normalized forms

What is Normalization?
83
Normalization is the process of decomposing
unsatisfactory "bad" relations by breaking up their
attributes into smaller relations
The objective of normalization:
“to create relations where every dependency
is on the key, the whole key, and nothing but
the key”.
Normalization = Standardization. In database
means put the table in standard form.

84
Why the Normalization?
• To produce well-structured relations
– Any relational database should contain minimal
data redundancy and allows users to insert,
delete, and update rows without causing data
inconsistencies (anomalies).
– Data redundancy is a case within a database in
which the same piece of data is held in two
separate places.

• To make a normalized table you have to know
about the meaning of each attribute, and how it
can be uniquely connected to other one, and
what is the compromise to minimize number
of repeating values, in column and in rows or
in both, and what are the candid keys.
• It needs some practice to do it.

Anomalies and redundancy example
What if the supplier GlassCo moves to new address Olympia? Or what if
GlassCo become no more a supplier, how many fields needed to be
deleted. Also, there are many repeated data of this GlassCo.
Part# Description Supplier Address City State
100 Coil Dynar 45 Eastern Ave. Denver CO
101 Muffler GlassCo 1638 S. Front Seattle WA
102 Wheel Cover A1 Auto 7441 E. 4th
Street
Detroit MI
103 Battery Dynar 45 Estern Ave. Denver CO
104 Radiator United
Parts
346 Taylor Drive Austin TX
105 Manifold GlassCo 1638 S. Front Seattle WA
106 Converter GlassCo 1638 S. Front Seattle WA
107 Tail Pipe GlassCo 1638 S. Front Seattle WA

A Typical Spreadsheet File (unnormalized)
Emp No Employee Name Time Card No Time Card Date Dept No Dept Name
10 Thomas Arquette 106 11/02/2002 20 Marketing
99 Janice Smitty 10 Accounting
500 Alan Cook 107 11/02/2002 50 Shipping
500 Alan Cook 107 11/02/2002 50 Shipping
700 Ernest Gold 108 11/02/2002 50 Shipping
Unnormalized means There are multivalued attributes
or repeating groups

Breaking the file into 3 tables eliminate
the data redundancy (normalized tables)
EmpNo EmpFirstName EmpLastName DeptNo
10 Thomas Arquette 20
500 Alan Cook 50
700 Ernest Gold 50
99 Janice Smitty 10
TimeCardNo EmpNo TimeCardDate
106 10 11/02/2002
107 500 11/02/2002
108 700 11/02/2002
115 10 11/09/2002
116 700 11/09/2002
Table: Employees
Table: Time Card Data
DeptNo DeptName
10 Accounting
20 Marketing
50 Shipping
Table: Departments
Primary Key

90
Another Normalization Example
Name Credit Number City
Fred 123-45-6789 Seattle
Joe 987-65-4321 Westfield
Credit Number PhoneNumber
123-45-6789 206-555-1234
123-45-6789 206-555-6543
987-65-4321 908-555-2121
Anomalies have gone:
• No more repeated data
• Easy to move Fred to “Bellevue” (how ?)
• Easy to delete all Joe’s phone number (how ?)
Name Credit Number PhoneNumber City
Fred 123-45-6789 206-555-1234 Seattle
Fred 123-45-6789 206-555-6543 Seattle
Joe 987-65-4321 908-555-2121 Westfield

Why Normalized Tables?
• Save typing of repetitive data
• Increase flexibility to query, sort, summarize,
and group data (Simpler to manipulate data!)
• Avoid frequent restructuring of tables and
other objects to accommodate new data
• Reduce disk space

• How we can create normalized tables?
• Apply the normalization forms
• What are the normalization forms?

Types of normalization forms
93
The most important four normal forms are:
1NF is considered the weakest,
2NF is stronger than 1NF,
3NF is stronger than 2NF, and
BCNF ( Boyce Codd) is considered the strongest
Also,
any relation that is in BCNF, is in 3NF;
any relation in 3NF is in 2NF; and
any relation in 2NF is in 1NF.
For most business database design purposes, 3NF is
as high as we need to go in normalization process.

Normal Forms: requirements
• 1 NF – No multivalued attributes or repeating groups.
• 2 NF – 1 NF + no partial dependencies
• 3 NF – 2 NF + no transitive dependencies

Dependencies: Definitions
• Partial Dependency – when an non-key attribute is determined by a
part, but not the whole, of a COMPOSITE primary key.
• Name depend on part of the composite key (cust ID), but it does not
depend on the other part of the key (Order ID).
CUSTOMER
Cust_ID Name Order_ID
101 AT&T 1234
101 AT&T 156
125 Cisco 1250
Partial
Dependency
Dependency Diagram
composite key composite key

FULLAND PARTIAL FUNCTIONAL
DEPENDENCY
• Grade is fully functionally dependent on the primary key (ID,Course-
ID) because both parts of the primary keys are needed to determine Grade
• On the other hand both Name and Phone attributes are partially
dependent on the primary key, because only a part of the primary key
namely ID is needed to determine them and similarly Credit-Hours and
Course-Name can be determined using Course-ID .

Dependencies: Definitions
• Transitive Dependency – when a non-key
attribute determines another non-key attribute.
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Transitive
Dependency
Dependency Diagram

98
First Normal Form (1NF)
• To be in First Normal Form (1NF),
– Each table has a primary key: minimal set of attributes
which can uniquely identify a record
– The values in each column of a table are atomic (No
multi-value attributes allowed).
– There are no repeating groups: two columns do not
store similar information in the same table.

Example: Tables Violating First Normal Form
PART (Primary Key) WAREHOUSE
P0010 Warehouse A, Warehouse B, Warehouse C
P0020 Warehouse B, Warehouse D
PART
(Primary Key)
WAREHOUSE A WAREHOUSE B WAREHOUSE C
P0010 Yes No Yes
P0020 No Yes Yes
Really Bad Set-up!
Better,

Example: Table in First Normal Form
Fields contain smallest meaningful values
EmpID FName LName Manager Dept Sector Spouse Child1 Child2 Child3
285 Carl Carlson Smithers Eng. 6G
365 Lenny Smithers Marketing 8G
458 Homer Simpson Mr. Burns Safety 7G Marge Bart Lisa Maggie
EmpID Name Manager Dept Sector Spouse/Children
285 Carl
Carlson
Smithers Engineering 6G
458 Homer
Simpson
Mr. Burns Safety 7G Marge, Bart, Lisa, Maggie

Table in First Normal Form
EmpID FName LName Manager Department Sector Dependent
285 Carl Carlson Smithers Engineering 6G
458 Homer Simpson Mr. Burns Safety 7G Marge
458 Homer Simpson Mr. Burns Safety 7G Bart
458 Homer Simpson Mr. Burns Safety 7G Lisa
458 Homer Simpson Mr. Burns Safety 7G Maggie
EmpID Name Manager Dept Sector Spouse/Children
285 Carl
Carlson
Smithers Engineering 6G
458 Homer
Simpson
Mr. Burns Safety 7G Marge, Bart, Lisa, Maggie

105
Another 1NF Example
Cust_ID L_Name F_Name
Address
104 Suchecki Ray 123 Pond Hill Road, Detroit, 48161
Cust_ID SalesRep_Name Rep_Office Order_1 Order_2 Order_3
1022 Jones 412 10 14 19
Apply the 1NF to the following tables:

2NF and 3NF
• 2NF and 3NF needs to understand the relation
between the primary, composite, or candid
keys to the other attributes,

2nd Normal Form
• The requirements to satisfy the 2nd NF:
• There is no redundancy of data (all data is stored
in only one place).
– Any non-key field should be dependent on
the entire primary key.
– The resulting tables must be related to each
other by use of foreign key.

Age depended on part of the composite key Name,
but not depend on the other key part Subject

Example
Electric Toothbrush Models
Manufacturer Model Model Full Name
Manufacturer
Country
Forte X-Prime Forte X-Prime Italy
Forte Ultraclean Forte Ultraclean Italy
Dent-o-Fresh EZbrush
Dent-o-Fresh
EZbrush
USA
Kobayashi ST-60 Kobayashi ST-60 Japan
Hoch Toothmaster Hoch Toothmaster Germany
Hoch X-Prime Hoch X-Prime Germany
To make this table follow 2NF, it is necessary to have
two relations:
There is no primary key can be determined where the other
nonkey depend on it in the below table.

Manufacturer Manufacturer Country
Forte Italy
Dent-o-Fresh USA
Kobayashi Japan
Hoch Germany
Electric Toothbrush Manufacturers
Manufacturer Model Model Full Name
Forte X-Prime Forte X-Prime
Forte Ultraclean Forte Ultraclean
Dent-o-Fresh EZbrush Dent-o-Fresh EZbrush
Kobayashi ST-60 Kobayashi ST-60
Hoch Toothmaster Hoch Toothmaster
Hoch X-Prime Hoch X-Prime
Electric Toothbrush Models

112
Third Normal Form
• In order to be in Third Normal Form, a relation must first
fulfill the requirements to be in 2NF.
• Additionally, all attributes that are not dependent upon the
primary key must be eliminated. In other words, there
should be no transitive dependencies:
(No non-key fields are dependent on another non-key
field)
• Solution: non-key determinant with transitive
dependencies go into a new table; non-key
determinant becomes primary key in the new table
and stays as foreign key in the old table

Example: Bringing a Relation to 3NF
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID
111 Mary Jones 1
122 Sarah Smith 2
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
DEPARTMENT
Dept_ID Dept_Name
1 Acct
2 Mktg
Non key Dept Name dependt on Dept ID which is non key field in
the first table.

End of part 3
end of the Course
120

Database part3-

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Database part3-

Similar to Database part3- (20)

More from Taymoor Nazmy

More from Taymoor Nazmy (20)

Recently uploaded

Recently uploaded (20)

Database part3-