Scribd
Upload
20 views17 pages

Chapter 4 Logical Database Design and The Relational Model Part

Uploaded by

ahmed
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
20 views17 pages

Chapter 4 Logical Database Design and The Relational Model Part

Uploaded by

ahmed
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 17

Logical Database Design and the

Relational Model
part 1

1
Objectives
Relational Model
– Requirement
– Primary and foreign keys
– Integrity constraints

2
Systems Development Life Cycle

Purpose–information requirements elicitation


Planning and structure
Deliverable–detailed design specifications
Analysis

Logical
Logical Design
Design

Physical Design

Database activity–
logical database design Implementation
(transactions, forms, displays, views,
data integrity and security) Maintenance
Typically map ER diagram to tables

3
Relation
• Definition: A relation is a named, two-dimensional table of
data
• Table consists of rows (records) and columns (attribute or
field)
• Requirements for a table to qualify as a relation:
– It must have a unique name
– Every attribute value must be atomic (not multivalued, not composite)
– Every row must be unique (can’t have two rows with exactly the same
values for all their fields)
– Attributes (columns) in tables must have unique names
– The order of the columns must be irrelevant
– The order of the rows must be irrelevant

NOTE: all relations are in 1st Normal form

4
Correspondence with E-R Model

 Relations (tables) correspond with entity types and


with many-to-many relationship types
 Rows correspond with entity instances and with many-
to-many relationship instances
 Columns correspond with attributes

 NOTE: The word relation (in relational database) is


NOT the same as the word relationship (in E-R
model)
5
Key Fields

• Keys are special fields that serve two main purposes:


– Primary keys are unique identifiers of a row in a relation.
Examples include employee numbers, social security
numbers, etc.
– This is similar to identifier attributes in ER diagram.
– It can be simple (a single field) or composite (more
than one field)
– How many primary keys can a table have?
• Each relation only has one primary key
– How many attributes can a primary key have?
• composite (more than one field(attribute)).
Key Fields (cont.)
• Foreign keys are used to represent relationships and
link tables
• Foreign means the key is copied from the primary key
of another table.

Cust-id cust-name OID Order-date Cust-id


1 Jones 1 ‘05/1/1’ 1
2 Smith 2 ‘05/2/1 1
Customer Orders
In the orders table, cust-id stores the id of customer who placed that order
E.g., Jones placed both orders
Orders.cust-id are just copies of cust-id in customer table who placed the order
7
Key Fields (cont.)

Cust-id cust-name OID Order-date Cust-id


1 Jones 1 ‘05/1/1’ 1
2 Smith 2 ‘05/2/1 1

Customer Orders

Orders.cust-id are just copies of cust-id in customer table who placed the order
There is no need to copy more information about customer in order table because
cust-id uniquely identifies a customer (so other information about that customer
can be located in customer relation given the cust-id)

8
Key Fields (cont.)

Other foreign keys?

9
primary and foreign keys for four relations

Primary Key
Foreign Key
(implements 1:N relationship
between customer and order)

Combined, these are a composite


primary key (uniquely identifies the
order line)…individually they are
foreign keys (implement M:N
relationship between order and product)

10
Integrity Constraints

• Domain Constraints
– Allowable values for an attribute.
• Entity Integrity
– No primary key attribute may be null. All
primary key fields MUST have data

11
Domain definitions enforce domain integrity constraints

12
Referential integrity

• Referential Integrity–rule states that any foreign key value (on


the relation of the many side) MUST match a primary key value
in the relation of the one side.
– For example: Delete Rules
• Restrict–don’t allow delete of “parent” side if related rows exist in
“dependent” side
• Cascade–automatically delete “dependent” side rows that correspond
with the “parent” side row to be deleted
• Set-to-Null–set the foreign key in the dependent side to null if
deleting from the parent side  not allowed for weak entities

13
Referential integrity (cont.)
• Referential Integrity example

Cust-id cust-name OID Order-date Cust-id


1 Jones 1 ‘05/1/1’ 1
2 Smith 2 ‘05/2/1 1
Customer Orders
In the orders table, cust-id must be the id of an existing customer.
E.g., if cust-id = 10, then we can not find the customer in customers table,
so how can we charge him or her?

14
Referential integrity

Referential
integrity
constraints are
drawn via arrows
from dependent to
parent table

15
SQL table definitions to show referential integrity implementation

Referential
integrity
constraints are
implemented with
foreign key to
primary key
references

16
Questions
• Can foreign key be NULL? YES, it can be NULL
– E.g. CID in orders table is null
• Can foreign key points to an non existing row in the primary
table? NO, it can't point to a non-existing primary key
– E.g. CID in orders table equals a CID that can not be found
in Customer table
CID Cust-name OID Order-date CID
1 Jones 1 ’05/1/1’ 1
2 Smith 2 ‘05/2/1’ 1

You might also like