AL-MUZZAMMIL 73 : 20

Indeed your Lord knows that you stand up in prayer, sometimes almost two-thirds of the night, and sometimes
half the night or sometimes a third of it – and also a group of those along with you; Allah keeps measure of the
night and day; He knows that you, O Muslims, will not be able to measure the night, so He has inclined towards
you with mercy – therefore recite from the Qur’an as much as is easy for you; He knows that soon some of you
will fall ill, and some will travel in the land seeking the munificence of Allah, and some will be fighting in Allah’s
cause; therefore recite from the Qur’an as much as is easy for you, and establish prayer and pay the obligatory
charity, and lend an excellent loan to Allah; and whatever good you send ahead for yourselves, you will find it
with Allah, better and having a great reward; and seek forgiveness from Allah; indeed Allah is Oft Forgiving,
Most Merciful.
DATA MODELLING

2 Relational data model, Attributes, ER Diagram,

schemas, relation instance, keys
Conceptual, Logical and Physical Modelling
DATA MODELING

 Documenting rules and policies of an

organization that govern data.

Data Modeling

Conceptual Data
Business Rules
Modeling
3

Chapter 3
BUSINESS RULES
 Statements that define or constrain some
aspect of the business

 Examples:
 Every student in the university must have one or
more faculty advisors
 Every student in the university must be assigned
to one discipline only.
 Is this a business rule?
 A student is any person who has applied for
admission or taken a course or training program 4
from any credit or noncredit unit of the university.
Chapter 3
CONCEPTUAL MODELING
 Entity-Relationship Model
 A logical representation of data for an
organization
 Expressed in terms of entities, attributes and
relationships

 Entity-Relationship Diagram
 A graphical representation of an entity-
relationship model

Chapter 3
 E-R MODEL CONSTRUCTS
 Entities:
 Entity instance–person, place, object, event, concept (often
corresponds to a row in a table)
 Entity Type–collection of entities (often corresponds to a
table)

 Relationships:
 Relationship instance–link between entities (corresponds to
primary key-foreign key equivalencies in related tables)
 Relationship type–category of relationship…link between
entity types

 Attribute–property or characteristic of an entity or

relationship type (often corresponds to a field in a table)
6

Chapter 3
Sample E-R Diagram (Figure 3-1)

Chapter 3
CLASS ACTIVITY
 Write business rules for the following ERD

Chapter 3
SOLUTION (CLASS ACTIVITY)
 A CUSTOMER may submit any number of ORDERs.
However, each ORDER must be submitted by exactly
one CUSTOMER.

 A SUPPLIER may supply many ITEMs. Each ITEM is

supplied by any number of SUPPLIERs.

 A SHIPMENT must include one(or more) ITEMs. An

ITEM may be included on several SHIPMENTs

 Each ITEM must be used in at least one PRODUCT.

Conversely, each PRODUCT must use one or more
ITEMs. 9

Chapter 3
 WHAT SHOULD AN ENTITY BE?
 SHOULD BE:
 An object that will have many instances in the database
 An object that will be composed of multiple attributes
 An object that we are trying to model
 SHOULD NOT BE:
 A user of the database system
 An output of the database system (e.g., a report)

10

Chapter 3
Figure 3-4 Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities
11

Chapter 3
DIFFERENCE BETWEEN
CONCEPTUAL, LOGICAL AND
PHYSICAL DATA MODEL
CONCEPTUAL DATA MODEL
 A conceptual data model identifies the highest-
level relationships between the different entities.
Features of conceptual data model include:
 Includes the important entities and the
relationships among them.
 No attribute is specified.

 No primary key is specified.

 The only information shown via the conceptual

data model is the entities that describe the data
and the relationships between those entities. No
other information is shown through the
conceptual data model.
Chapter 3
LOGICAL DATA MODEL
 A logical data model describes the data in as much detail as possible,
without regard to how they will be physically implemented in the database.
Features of a logical data model include:
 Includes all entities and relationships among them.
 All attributes for each entity are specified.
 The primary key for each entity is specified.
 Foreign keys (keys identifying the relationship between different entities) are
specified.
 Normalization occurs at this level.
 The steps for designing the logical data model are as follows:
 Specify primary keys for all entities.
 Find the relationships between different entities.
 Find all attributes for each entity.
 Resolve many-to-many relationships.
 Normalization.
 Comparing the logical data model with the conceptual data model, we see the
main differences between the two are:
 In a logical data model, primary keys are present, whereas in a conceptual data model,
no primary key is present.
 In a logical data model, all attributes are specified within an entity. No attributes are
specified in a conceptual data model.
 Relationships between entities are specified using primary keys and foreign keys in a
logical data model. In a conceptual data model, the relationships are simply stated, not
specified, so we simply know that two entities are related, but we do not specify what
attributes are used for this relationship.
Chapter 3
PHYSICAL DATA MODEL
 Physical data model represents how the model will be built in the database.
A physical database model shows all table structures, including column name,
column data type, column constraints, primary key, foreign key, and
relationships between tables. Features of a physical data model include:
 Specification all tables and columns.
 Foreign keys are used to identify relationships between tables.
 Denormalization may occur based on user requirements.
 Physical considerations may cause the physical data model to be quite different from
the logical data model.
 Physical data model will be different for different RDBMS. For example, data type for
a column may be different between MySQL and SQL Server.
 The steps for physical data model design are as follows:
 Convert entities into tables.
 Convert relationships into foreign keys.
 Convert attributes into columns.
 Modify the physical data model based on physical constraints / requirements.

 Comparing the physical data model with the logical data model, we see the
main differences between the two:
 Entity names become table names.
 Attributes become column names.
 Data type for each column is specified. Data types can be different depending on the
actual database being used.

Chapter 3
 DIFFERENCE BETWEEN CONCEPTUAL, LOGICAL
AND PHYSICAL DATA MODEL
Feature Conceptual Logical Physical

Entity Names ✓ ✓

Entity Relationships ✓ ✓

Attributes ✓

Primary Keys ✓ ✓

Foreign Keys ✓ ✓

Table Names ✓

Column Names ✓

Column Data Types ✓

Chapter 3
1
7

RELATION (LOGICAL DATA MODEL)

 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

Chapter 3
1
8

A RELATION

Chapter 3
1
9

CORRESPONDENCE WITH E-R MODEL

 Relations (tables) correspond with entity types

 Rows correspond with entity instances

 Columns correspond with attributes

 NOTE: The word relation (in relational

database) is NOT the same as the word
relationship (in E-R model)
Chapter 3
2
0

KEY FIELDS

 Keys are special fields that serve two main purposes:

 Primary keys are unique identifiers of the relation in
question. Examples include employee numbers, social security
numbers, etc. This is how we can guarantee that all rows are
unique
 Foreign keys are attribute in a relation of a database that
serves as the primary key of another relation in the same
database
 Keys can be simple (a single field) or composite (more
than one field)
 Keys usually are used as indexes to speed up the
response to user queries

Chapter 3
KEYS
 Super Key − A set of attributes (one or more)
that collectively identifies an entity in an entity
set.
 Candidate Key − A minimal super key is called
a candidate key. An entity set may have more
than one candidate key.

21

Chapter 3
Entity Sets, Attributes, Relationship Notation

Entity
Attribute
symbols
symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type
22 is
allowed
Chapter 3
ATTRIBUTES
 Attribute–property or characteristic of an entity or
relationship type
 Classifications of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single-Valued versus Multivalued Attribute
 Stored versus Derived Attributes
 Identifier Attributes

23

Chapter 3
Figure 3-7 A composite attribute

An attribute
broken into
component parts

Figure 3-8 Entity with multivalued attribute (Skill)

and derived attribute (Years_Employed)

Multivalued
an employee can have
Derived
more than one skill
from date
employed24and
current date
Chapter 3
IDENTIFIERS (KEYS)
 Identifier (Key)–An attribute (or
combination of attributes) that uniquely
identifies individual instances of an entity
type
 Simple versus Composite Identifier
 Candidate Identifier–an attribute that
could be a key…satisfies the requirements
for being an identifier

25

Chapter 3
 Figure 3-9 Simple and composite identifier attributes

The identifier is boldfaced and underlined

26

Chapter 3
CHARACTERISTICS OF IDENTIFIERS

 Will not change in value

 Will not be null

 No intelligent identifiers (e.g., containing locations or

people that might change)

27

Chapter 3
EXAMPLE
 Classify the following  Classifications of
attributes: attributes:
 First Name  Required versus Optional
 Full Name Attributes
 Years Employed  Simple versus Composite
Attribute
 Race
 Single-Valued versus
 Roll no
Multivalued Attribute
 Hobbies
 Stored versus Derived
 Date Employed Attributes
 Password  Identifier Attributes
 Today’s Date
 Last Name
28

Chapter 3
SOLUTION
 Classifications the following attributes:
 First Name – Simple, Required
 Full Name – Composite (FirstName. LastName)
 [Years Employed] – Derived (DateEmployed, Today’s Date)
 Race -- Simple
 Roll no – Identifier
 {Hobbies} – Multivalued, Optional
 Date Employed -- Simple
 Password – Simple, Required
 Today’s Date – Simple(Can be composite if dd-mm-yyyy)
 Last Name -- Simple

29

Chapter 3
 Logical Data Model: Mapping a regular entity

(a) CUSTOMER
entity type with
simple
attributes

(b) CUSTOMER relation

30

Chapter 3
 Logical Data Model: Mapping a composite attribute

(a) CUSTOMER
entity type with
composite
attribute

(b) CUSTOMER relation with address detail

31

Chapter 3
3
2 Logical Data Model: Mapping an entity with a multivalued attribute
(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

One–to–many relationship between original entity and new relation

Chapter 3
MORE ON RELATIONSHIPS
 Relationship Types vs. Relationship
Instances
 The relationship type is modeled as lines
between entity types…the instance is between
specific entity instances
 Two entities can have more than one type of
relationship between them (multiple
relationships)
 Associative Entity–combination of
relationship and entity

33

Chapter 3
Figure 3-10 Relationship types and instances

a) Relationship type

b) Relationship
instances

34

Chapter 3
CARDINALITY OF RELATIONSHIPS
 One-to-One
 One-to-Many
 Many-to-Many

35

Chapter 3
 CARDINALITY CONSTRAINTS

 Cardinality Constraints - the number of instances of one

entity that can or must be associated with each instance
of another entity
 Minimum Cardinality
 If zero, then optional
 If one or more, then mandatory
 Maximum Cardinality
 The maximum number

36

Chapter 3
Figure 3-17 Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have recorded

recorded for one and at least one history, and can
only one patient have many
37

Chapter 3
Figure 3-17 Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be An employee can be assigned

assigned to at least one to any number of projects, or
employee, and may be may not be assigned to any
assigned to many at all
38

Chapter 3
Figure 3-17 Examples of cardinality constraints (cont.)

a) Optional cardinalities

A person is is
married to at most
one other person,
or may not be
married at all

39

Chapter 3
Figure 3-21 Examples of multiple relationships

a) Employees and departments

Entities can be related to one another in more than one way

40

Chapter 3
Logical Data Model: Example of mapping a binary 1:1 relationship
a) In_charge relationship (1:1)

Often in 1:1 relationships, one direction is optional.

41

Chapter 3
Logical Data Model: Example of mapping a binary 1:1 relationship (cont.)

b) Resulting relations

Foreign key goes in the relation on the optional side,

Matching the primary key on the mandatory side
42

Chapter 3
Logical Data Model: Example of mapping a 1:M relationship
a) Relationship between customers and orders

Note the mandatory one

b) Mapping the relationship

Again, no null value in the

foreign key…this is because
of the mandatory minimum
cardinality
Foreign key 43

Chapter 3
DEGREE OF RELATIONSHIPS

Degree of a relationship is
the number of entity types
that participate in it
 Unary Relationship
 Binary Relationship
 Ternary Relationship
44

Chapter 3
 Degree of relationships – from Figure 3-2

Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each 45
other
Chapter 3
Figure 3-12 Examples of relationships of different degrees

a) Unary relationships

46

Chapter 3
 Logical Data Model: Mapping a unary 1:N relationship

(a) EMPLOYEE entity with

unary relationship

(b) EMPLOYEE
relation with
recursive foreign
key

47

Chapter 3
4
8 Logical Data Model: Mapping a unary M:N relationship

(a) Bill-of-materials
relationships (M:N)

(b) ITEM and

COMPONENT
relations

Chapter 3
Figure 3-12 Examples of relationships of different degrees (cont.)

b) Binary relationships

49

Chapter 3
 Figure 3-12 Examples of relationships of different degrees (cont.)

c) Ternary relationship

A ternary relationship is a simultaneous relationship among the instances of three entity types. A typical
business situation that leads to a ternary relationship is shown in Figure. In this example, vendors can supply
various parts to warehouses. The relationship Supplies is used to record the specific parts that are supplied by
a given vendor to a particular warehouse. Thus there are three entity types: VENDOR, PART, and 50
WAREHOUSE

Chapter 3
 Figure 5-14 Example of mapping a binary 1:1 relationship
a) In_charge relationship (1:1)

Often in 1:1 relationships, one direction is optional.

51

Chapter 3
ogical Data Model: Example of mapping a binary 1:1 relationship (con
b) Resulting relations

Foreign key goes in the relation on the optional side,

Matching the primary key on the mandatory side
52

Chapter 3
 Logical Data Model: Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with

associative entity

53

Chapter 3
 Logical Data Model: Mapping a ternary relationship (cont

b) Mapping the ternary relationship PATIENT TREATMENT

Remember This is why But this makes a It would be

that the treatment date very better to create a
primary key and time are cumbersome surrogate key
MUST be included in the key… like Treatment#
unique 54
composite
Chapter 3 primary key
 STRONG VS. WEAK ENTITIES, AND
IDENTIFYING RELATIONSHIPS
 Strong entities
 exist independently of other types of entities
 has its own unique identifier
 identifier underlined with single-line
 Weak entity
 dependent on a strong entity (identifying owner)…cannot exist on
its own
 does not have a unique identifier (only a partial identifier)
 Partial identifier underlined with double-line
 Entity box has double line

55

Chapter 3
 Identifying relationship

Strong entity Weak entity

Chapter 3 56
 Logical Data Model: Example of mapping a weak entity

b) Relations resulting from weak entity

NOTE: the domain constraint

for the foreign key should
NOT allow null value if
DEPENDENT is a weak
entity

Foreign key

Composite primary key

57

Chapter 3
 Example : Mapping E-R to Logical Data Model
Schema for four relations (Pine Valley Furniture Company)

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)

58
Class Activity :Draw E-R Diagram for the given scheema
Chapter 3
ASSOCIATIVE ENTITY (COMPOSITE
ENTITY / GERUND)

 The database relational model does not offer

direct support to many-to-many relationships,
even though such relationships happen
frequently in normal usage. The solution to this
problem is the creation of another table to hold
the necessary information for this relationship.
This new table is called an associative entity.

Chapter 3 59
 To create a relationship, a "child" entity must inherit
the primary key of a "parent" entity. However, in a
many-to-many relationship, neither entity is the
"parent" or the "child"; the relationship is
"unresolved". In order to work, these databases
require an additional construct to "resolve" the
relationship (which is why associative entities are
also referred to as "resolving entities").
 An associative entity can be thought of as both an
entity and a relationship since it encapsulates
properties from both. It is a relationship since it is
serving to join two or more entities together, but it is
also an entity since it may have its own properties.
The associative entity must have the primary keys of
both adjoining tables as identifiers, but may also
contain its own unique identifier and other 60

information
Chapter 3 about the relationship.
The following guidelines may be used when considering
the use of an associative entity:
 All relationships for the associative entity should be many.
 The associative entity could have meaning independent of
the other entities.
 The associative entity should not have an additional
identity column. The primary key should be a composite of
the primary keys from the referenced entities. If the
association is temporal, the transaction time may also be
part of this composite key. If other entities will be
referencing the associative entity and the composite of the
referenced primary keys creates a large byte width for the
associative entity's primary key, an exception may be made
for this rule and an identity column may be added and used
as the primary key.


Chapter 3 61
 Physical data model: of mapping an M:N relationship
a) Completes relationship (M:N)

The Completes relationship will need to become a separate relation

62

Chapter 3
 Physical data model: Example of mapping an M:N relationship (cont.)

b) Three resulting relations

Composite primary key

Foreign key New

Foreign key
intersection
relation

63

Chapter 3
 Physical data model: Example of mapping an associative entity
a) An associative entity

64

Chapter 3
 Physical data model: Example of mapping an associative entity (cont.)

b) Three resulting relations

Composite primary key formed from the two foreign keys

65

Chapter 3
Physical data model: Example of mapping an associative entity wi
an identifier
a) SHIPMENT associative entity

66

Chapter 3
Physical data model: Example of mapping an associative entity wi
an identifier (cont.)
b) Three resulting relations

Section C

Primary key differs from foreign keys

67

Chapter 3
CASE STUDY (DRAW E-R DIAGRAM)
 Major airlines companies that provide passenger services in Taiwan are: UniAir,
TransAsia Airways, Far Eastern Transport, Great China Airlines etc. Taiwan’s
Federal Aviation Administration (TFAA) keeps a database with lots of information
on all airlines. This information is made accessible to all airlines in Taiwan with the
intention of helping the Companies assess their Competitive position in the domestic
market. The information kept consists of:
 Each airline has an identification number, name of the contact person and telephone
number.
 For each aircraft identification number, capacity and model is recorded.
 Each employee has an employee identification number, name, address, birthday, sex,
position with the company and qualification.
Each airline keeps information about their buy/sell transactions (for example, selling an
airplane ticket is a sell transaction, paying for maintenance is a buy transaction). Each
transaction has a transaction identification number, date, description and amount of
money paid/received. Also Each Airline must have one or more employees. As far as
aircraft is concerned, one aircraft can be assigned to more than one airline as per flight
schedule / Route and one Airline can have multiple aircraft assigned at a particular
time.
(Assumption: one Airline can have multiple aircraft assigned at a particular time as its
not for a single airport. However airport enity should not be included while designing
ER)

Chapter 3 68
SOLUTION HINT
 Airline – Transaction 1 to M
 Airline – Employee 1 to M

 Airline – Aircraft M to M
 Associative Entity (Route)

69

Chapter 3
 PHYSICAL DATA MODELLING
70 Introduction to Terms: Implementation will be
covered in LAB
7
1

PHYSICAL DATABASE DESIGN

 Purpose–translate the logical description of data
into the technical specifications for storing and
retrieving data
 Goal–create a design for storing data that will
provide adequate performance and insure
database integrity, security, and recoverability

Chapter 3
7
2

DESIGNING FIELDS

Field:smallest unit of data in

database
Field design
 Minimize data storage
 Represent all possible values
 Controlling data integrity

Chapter 3
7
3

CHOOSING DATA TYPES

 CHAR–fixed-length character
 VARCHAR2–variable-length character
(memo)
 LONG–large number

 NUMBER–positive/negative number

 INTEGER–positive/negative whole number

 DATE–actual date

 BLOB–binary large object (good for

graphics, sound clips, etc.)
Chapter 3
Figure 6-2 Example code look-up table
(Pine Valley Furniture Company)

Code saves space, but costs

an additional lookup to
obtain actual value

74

Chapter 3
7
5

FIELD DATA INTEGRITY

 Default value–assumed value if no explicit
value
 Range control–allowable value limitations
(constraints or validation rules)
 Null value control–allowing or prohibiting
empty fields
 Referential integrity–range control (and null
value allowances) for foreign-key to primary-
key match-ups

Sarbanes-Oxley Act (SOX) legislates importance of financial data integrity

Chapter 3
7
6

BASIC DEFINITIONS
 Physical Record: A group of fields stored in adjacent
memory locations and retrieved together as a unit
 Page: The amount of data read or written in one I/O
operation
 Blocking Factor: The number of physical records
per page

 Rest of the physical data model aspects will be covered

in LAB

Chapter 3