LECTURE 5

• Primary and Foreign Key definitions

• Rules of the Transformation from ERD to logical Relational
Database Design
• Literature
• [Barker II] Barker R., CASE*Method: Entity Relationship
Modelling, Addison-Wesley Pub. Comp., 1991
• [Date] Date C.J., An introduction to database systems, Addison-
Wesley Pub. Comp., 1986

GHJ - PWR 1
 THE BASIC TECHNIQUE OF LOGICAL
RELATIONAL DATABASE DESIGN FROM
AN ENTITY REALTIONSHIP MODEL

What is a database?
• A database is an organized collection of structured information, or
data, typically stored electronically in a computer system. A
database is usually controlled by a database management system
(DBMS). Together, the data and the DBMS, along with the
applications that are associated with them, are referred to as a
database system, often shortened to just database. [ORACLE]

GHJ - PWR 2
 TYPES OF DATABASES

• Relational databases: Relational databases became dominant in the 1980s.

Relational database technology provides the most efficient and flexible
way to access structured information.
• Object-oriented databases: Information in an object-oriented database is
represented in the form of objects, as in object-oriented programming.
• NoSQL databases: A NoSQL, or nonrelational database, allows
unstructured and semistructured data to be stored and manipulated (in
contrast to a relational database, which defines how all data inserted into
the database must be composed). NoSQL databases grew popular as web
applications became more common and more complex.
• Others: Data warehouses, Distrubuted, Graph, Documents/JSON, Self-
driving databases

GHJ - PWR 3
 RELATIONAL DATABASE

• A collection of tables that store particular sets of data is called a

relational database.
• The data that is stored in tables are organized logically for
particular requirements: minimize duplication, reduce data
anomalies, and strengthen data integrity.
• The father of relational databases is considered Edgar Frank „Ted”
Codd. He derives the conception of a relational database on the
basis of the principles of relational algebra (A Relational Model of
Data for Large Shared Data Banks, 1970).
• The Relational Database Management System (RDBMS) is the most
commonly used database format. Oracle Corporation created the
first commercial relational database in 1979 (Larry Ellison).

GHJ - PWR 4
 RELATION AS TWO-DIMENSIONAL
TABLE

• The relation, which is a two-dimensional table, is the primary unit

of storage in a relational database
• A relational database can contain one or more of these tables, with
each table consisting of a unique set of rows and columns.
• A single record is stored in a table as a row, or as a tuple
• Attributes of the data are defined in columns, or fields in a table.
• Each column has a unique name and the content within it must be
of the same data type

GHJ - PWR 5
 PRIMARY AND FOREIGN KEY
DEFINITIONS
• Tables can contain primary keys (PK) which differentiate records
from one to another
• The primary key of a relational table uniquely identifies each
record in a table
• It can either be a normal attribute that is guaranteed to be unique
(such as International Standard Book Number (ISBN) in a table with no
more than one record per book) or it can be generated by the DBMS
(such as a globally unique identifier)
• Primary keys may consist of a single attribute (column within a table)
or multiple attributes (columns) in combination
• A foreign key (FK) is a field (column) in a relational table that
matches the primary key column of another table
• the foreign key can be used to cross-reference tables
• the foreign keys generally define parent-to-child relationships
between tables.

GHJ - PWR 6
 PRIMARY (PK) AND FOREIGN KEY (FK)
PRESENTATION

Table name Primary key

Column Products
name PK symbol Types

PK code
name
desciption name
unit_of_measure
Foreign key FK1 types_code

Foreign key types_code column of Products table matches

the primary key code column of Types table

GHJ - PWR 7
 RULES OF TRANSFORMATION FROM ERD TO
LOGICAL RELATIONAL DATABASE DESIGN
[BARKER II, PP. F1-F10]

The basic technique of logical database design

A. Simple database design
B. Design for sub – types
C. Design for exclusive relationship

GHJ - PWR 8
 A. Step 1 and 2

Step 1
Each simple entity is translated to a table.
The plural form of the entity for the table name is recommended.

Step 2
Each attribute is translated into a candidate column of the same
name, at which time a more precise format may be chosen.
Optional attributes become null columns.
Mandatory attributes become not – null columns.

GHJ - PWR 9
 A. Step 3

• The components of the unique identifier of the entity become the

primary key of the table
• Remember that there may be more than one unique identifier for
an entity – the most used one is chosen
• When the ID is a combination of attributes and/or relationships:
• follow along the relationship and to create columns, use a copy of
the ID components of the entity at the far end of the relationship as a
part of a primary key
• this may be recursive until attributes are eventually found
• during this process, relationships end names and/or entity names
are used with attribute names to suggest ID names for use as parts of
foreign keys

GHJ - PWR 10
A. Step 4

• Many to one and one to one relationships become

foreign keys
• That is, create a copy of the ID of each referenced entity from
the one end and use as candidate columns
• Optional relationships create null columns
• Mandatory relationships create not-null columns

GHJ - PWR 11
A. Example 1. Simple database design

A simple entity is one which is not a sub – type or has sub – types of its own.

from
CONVEYANCE SPOT
# * number the source of # * code
to
oPOZYCJA ZAM
scheduled departure * name
time
the destination of
operated by

ID is a combination many to one mandatory relationship

of attribute and
relationship for

CARRIER within
# * code recursive many to one optional
* name relationship

GHJ - PWR
the parent of 12
A. Example 1. Simple database design

A primary key is a combination number column

and foreign key for carrier from identified relationship

SPOTS
Code not null PK CONVEYANCES
Name not null PK Number SPOTS
PK,FK1 Carrier_Code
PK Code
CARRIERS Scheduled_departure_time
Code not null PK FK2 From_Spot_Code Name

Name not null FK3 To_Spot_Code

Parent carrier code null FK

A foreign keys to spot
CONVEYANCES CARRIERS
Number not null PK
PK Code
Carrier code not null PK, FK
Scheduled null Name
departure time
FK1 Parent_Carrier_Code

From spot code not null FK

To spot code not null FK
A foreign key from recursive relationship qualified by
an entity and a relationship names
GHJ - PWR 13
 A VIEW DEFINITION

• is a logical virtual relation

• is a means of accessing a subset of the database
• is stored in a database written in a form definition using DDL (e.
g. SQL)
• may occur in the view definition of arithmetic expressions
operating on data from the same or other tables
• presented data format can be changed
• arises when the performance of its operations
• may be restricted to named columns, to specific rows
• may derive new columns

GHJ - PWR 14
 APPLICATION OF A VIEW

• give access to a combination of related tables and/or

another view
• presentation of the same data in different formats
• data access control
• additional level of integrity constraints

GHJ - PWR 15
 DATABASE DESIGN FOR SUB - TYPES

• An entity sub – type is simply an entity with its own attributes or

relationships, but it also inherits any attributes and/or
relationships from its parent entity, a super – type and so on up
the hierarchy of super – types
• For those of you who have used object – oriented data structures
with inheritance properties you will find the concept familiar
• In CASE*Method are two basic alternatives
• B.I. All in one table
• B.II. Tables for sub - types

GHJ - PWR 16
 B. I. ALL IN ONE TABLE – RULES

• Design process must be carried out for each sub-type and for each
of their sub-types and so on. A table is created for the outer super-
type entity and optional views may be created for each of the sub-
types.
• Step 1
• Create a table for the outer super-type entity
• Step 2
• As before (the rules A. 1,2,3,4), add to the table columns for attributes
and many to one and one to one relationships of the outer super-type
entity

GHJ - PWR 17
 B. I. ALL IN ONE TABLE – RULES CONT.

• Step 3
• Add to the table columns created for attributes and many to one,
and one to one relationships of the all the sub-types are made
null
• A mandatory attribute or relationship for one sub-type would
not be applicable for another
• The integrity condition enforced either by application software
or by a view with enforced ″check option”
• Step 4
• At least one extra not-null column must be added to this table to
indicate TYPE, and it becomes a part of the primary key
• Step 5
• A relational view may be created for each of the sub-types to
enable to access only the data they need, as specified at the
business level by business functions defining actions on entities
that are sub-types

GHJ - PWR 18
 B.I. EXAMPLE 2. DATABASE DESIGN FOR SUB-TYPES - ALL
IN ONE TABLE

JOB ORDER ITEM

Super-type entity for JOB
JOB ITEM # * code
* cost * name
shown on
Sub-types entity
OTHER ITEM
many to one mandatory relationship
o tax comment

# * number
o description
ID is a combination of attribute
part of and relationship

made up of

JOB ORDER
# * number Simple entity
* date
GHJ - PWR 19
B.I. EXAMPLE 2. DATABASE DESIGN FOR SUB-TYPES - ALL IN ONE
TABLE RULES

Primary key is a combination:

number column, and foreign key to job order from identified relationship,
and extra added column to indicate type relationship

JOB ORDER ITEMS JOB_ORDER_ ITEMS

number not null PK
PK number
job_order_number not null PK, FK PK,FK1 job_order_number
type not null PK PK type Foreign key to job
job_code null FK FK2 job_code
description null description
tax_comment null tax comment
JOBS
cost
cost null PK code

Type column with values: name

JOB_ORDER_I for the super-type,

JOB_I and OTHER_I for the sub-types
JOB_ORDERS

PK number
All columns from sub-types are made null Simple database rules
date

GHJ - PWR 20
B.I. 5. POSSIBLE RELATIONAL VIEWS, AS DEFINED
IN SQL

CREATE VIEW OTHER_ITEMS AS

SELECT job_order_number
number The relational views created
description for two sub-types from
tax_comment JOB_ORDER_ITEMS table
type
FROM JOB_ORDER_ITEMS
WHERE type =″OTHER_I”

CREATE VIEW JOB_ITEMS AS

SELECT job_order_number
number
description
cost The Type column to enable to
job_code distinguish between the
type subtypes of JOB ORDER
FROM JOB_ORDER_ITEMS ITEM entity
WHERE type =″JOB_I”
AND cost NOT NULL
AND EXISTS
GHJ - PWR 21
 B. II. TABLES FOR SUB – TYPES RULES

• Tables are created for sub-types to cover all possible instances. A

UNION view may also be created to enable you to process the super-
type.
• Where there are many levels of sub-typing it is normal to use the first
level down and create tables for all sub-types at that level. Views
could then be created for further sub-types.
• Step 1
• Create tables for all sub-types at the first level
• Step 2
• As before (the rules A. 1,2,3,4), add to each of table columns for attributes
and many to one, and one to one relationships of the appropriate sub-type
entity
• Step 3
• Where a sub-type is itself a super-type, optional candidate columns are
created for each sub-type (the rules B.I.3, 4)
• Step 4
• A relational view may be created for a super-type to enable access to all
data they need, as specified at the business level by business functions
defining actions on entity that is super-type
GHJ - PWR 22
 B.II. EXAMPLE 3. TABLES FOR SUB – TYPE

JOB ORDER ITEM

Super-type entity for JOB
JOB ITEM # * code
* cost * name
shown on
Sub-types entity
OTHER ITEM
many to one mandatory relationship
o tax comment

# * number
o description
ID is a combination of attribute
part of and relationship

made up of

JOB ORDER
# * number
* date Simple entity
GHJ - PWR 23
 B.II. EXAMPLE 3. TABLES FOR SUB – TYPES

JOB ITEMS
number not null PK Primary key is a combination „number” column
job_order_number not null PK, FK and foreign key for job order from identified
job_code not null FK relationship
cost not null
description null Foreign key to job
JOB ITEMS
OTHER ITEMS PK number
number not null PK PK,FK1 job_order number JOBS

job_order_number not null PK, FK FK2 job_code PK code

cost
description null description name
tax_comment null
JOB_ORDERS OTHER_ITEMS

PK number PK number
PK,FK1 job_order number
date
description
tax comment

Simple data base rules

GHJ - PWR 24
B.II. 4. RELATIONAL VIEW UNION, AS DEFINED IN
SQL

CREATE VIEW JOB_ORDER_ITEMS AS

SELECT * FROM JOB_ITEMS
UNION Columns connection
operation, from various
SELECT * FROM OTHER_ITEMS tables, without duplicating
columns of the same name

Note that * above is a shorthand, Relational views created for super-

which may be used with type JOB ORDER ITEM entity from
the ORACLE RDBMS to select all two tables
columns from the table

GHJ - PWR 25
 C. EXCLUSIVE RELATIONSHIP

• There are two basic methods of handling the

database design for use with exclusive relationship
• C.I. Common domain
• C.II. Explicit foreign keys

belongs to
ACCOUNT PERSON
# code
has got
# number
* date owned by ORGANIZATION
owner of # code

The arc – exclusive relationship

GHJ - PWR 26
 C.I. COMMON DOMAIN

• If the remaining foreign keys would all be in the

same domain than create two candidate columns
to implement the relationships

• Relationship identifier column – would be used to

distinguish between different relationships covered by
the exclusive arc
• Entity identifier column – would be used to hold values
for the unique identifier value of an entity at the far end
of the appropriate relationship

GHJ - PWR 27
 C.I. COMMON DOMAIN – EXAMPLE C.I

belongs to PERSON
ACCOUNT # code (char 13) Simple entity
has got
# number ORGANIZATION
* date # code (char 13)
owned by owner of

The same domain

Exclusive relationship - many to one mandatory

GHJ - PWR 28
 C.I. COMMON DOMAIN – SOLUTION FOR
EXAMPLE C.I

PERSONS

ACCOUNTS PK code

PK number
Column name for
relationship identifier Simple data
date
account belongs to base rules
owner_code ORGANIZATIONS
Column name for
PK code
entity identifier

ACCOUNTS
number integer 11 not null PK
date date not null
account_belongs_to char 1 not null (value ″P″ or ″O″)
owner_code char 13 not null FK
Both columns added are not null for these mandatory relationships,
owner_code column would take values for either PERSON or ORGANIZATION
GHJ - PWR 29
 C.II. EXPLICIT FOREIGN KEYS

If the resulting foreign keys would not be in the same domain

• Create an explicit foreign key column for each relationship
covered by the exclusive arc
• Make all the resulting columns null
• Application code must now enforce the integrity rule that only
one may be entered, and that one must be entered if
relationships are mandatory

GHJ - PWR 30
C.II. EXPLICIT FOREIGN KEYS – EXAMPLE C.II

belongs to PERSON
ACCOUNT # code (integer 8) Simple entity
has got
# number ORGANIZATION
* date # code (char 13)
owned by owner of

Not the same domain

Exclusive relationship - many to one mandatory

GHJ - PWR 31
C.II. EXPLICIT FOREIGN KEYS – SOLUTION FOR
THE EXAMPLE C.II

PERSONS
PK code
ACCOUNTS
Simple data
PK number
Foreign key: base rules
date
to person FK1 person_code
to organization FK2 organization_code ORGANIZATIONS

PK code

ACCOUNTS
number integer 11 not null PK
date date not null
person_code integer 8 null FK
organization_code char 13 null FK

Both forein key columns are null for these mandatory relationships,
only
GHJ one of them may be entered, never both
- PWR 32
LOGICAL STRUCTURE OF DATABASE TABLE
DEFINITIONE (1)

EMPLOYEE
# no
* name
* date of birth
* profession
o address

Table name/Entity name: EMPLOYEES/EMPLOYEE

Key Reference
# Column name Not null/Null Data type
(PK/FK) (table name)
1 no Not null numerical PK

2 name Not null char

3 date of birth Not null date

4 profession Not null char
5 address Null char
33

GHJ - PWR
LOGICAL STRUCTURE OF DATABASE TABLE
DEFINITIONE (2)

belongs to PERSON
ACCOUNT # code (integer 8)
has got
# number ORGANIZATION
* date # code (char 13)
owned by owner of

Table name/Entity name: ACCOUNTS/ACCOUNT

Key Reference
# Column name Not null/Null Data type
(PK/FK) (table name)
1 number Not null numerical PK

2 date Not null date

3 person_code Null numerical FK PERSONS

4 organization_code Null char FK ORGANIZARIONS
34

GHJ - PWR
 CASE TOOLS

• Database design with Entity Relationship Diagram (ERD) and

generating database schema can be made automatically with
CASE software, e.g.
• Database Visual ARCHITECT (DB-VA)
• Oracle Designer
• LBMS, or many other tools
• CASE tools also support reversing database to ERD

GHJ - PWR 35
 QUESTIONS TO HELP YOU L5
STUDY
1. What role does a primary key in the database play?
2. What role does a foreign key in the database play?
3. What elements does a database table consist of?
4. What groups of rules have been distinguished for the
transformation of ERD into a database?
5. When you transform an entity type into a database table, how
many tables are created?
6. After the entity type transformation, what kinds of columns in a
database table can arise?

GHJ - PWR 36
 QUESTIONS TO HELP YOU L5
STUDY CONT.
7. What becomes a unary relationship in a database table?
8. What becomes a binary relationship in a database table?
9. What becomes an identifying relationship in a database table?
10. What rules apply to an entity supertype and subtypes
transformation?
11. In the transformation of an entity supertype, what role the view
does play?
12. For the transformation of exclusive relationship, what are the
rules?

GHJ - PWR 37