Anda di halaman 1dari 145

The Database

Environment
Mr. JEFFERSON I. CAADA
Instructor

IT500: INFORMATION TECHNOLOGY

Objectives

Definition of terms
Explain growth and importance of databases
Name limitations of conventional file
processing
Identify categories of databases
Explain advantages of databases
Identify costs and risks of databases
List components of database environment
Describe evolution of database systems

Chapter 1

IT500: INFORMATION TECHNOLOGY

Definitions
Database: organized collection of logically
related data
Data: stored representations of meaningful
objects and events
Structured: numbers, text, dates
Unstructured: images, video, documents

Information: data processed to increase


knowledge in the person using the data
Metadata:
data
that
describes
the
properties and context of user data
Chapter 1

IT500: INFORMATION TECHNOLOGY

Figure 1: Data in Context


Context helps users understand
data

Chapter 1

IT500: INFORMATION TECHNOLOGY

Figure 2: Converting data to information Summarized Data

Graphical displays turn data into useful


information that managers can use for
decision making and interpretation
Chapter 1

IT500: INFORMATION TECHNOLOGY

Table 1: Example Metadata for Class Roster

Descriptions of the properties or


characteristics of the data, including data
types, field sizes, allowable values, and
data context
Chapter 1

IT500: INFORMATION TECHNOLOGY

Disadvantages of File Processing


Program-Data Dependence
All programs maintain metadata for each file they
use
Duplication of Data
Different systems/programs have separate copies of
the same data
Limited Data Sharing
No centralized control of data
Lengthy Development Times
Programmers must design their own file formats
Excessive Program Maintenance
80% of information systems budget
Chapter 1

IT500: INFORMATION TECHNOLOGY

Problems with Data Dependency

Each application programmer must maintain their


own data
Each application program needs to include code
for the metadata of each file
Each application program must have its own
processing routines for reading, inserting,
updating and deleting data
Lack of coordination and central control
Non-standard file formats

Chapter 1

IT500: INFORMATION TECHNOLOGY

Duplicate Data

Figure 3: Three file processing systems at Pine Valley Furniture

Chapter 1

IT500: INFORMATION TECHNOLOGY

10

Problems with Data Redundancy


Waste of space to have duplicate data
Causes more maintenance headaches
The biggest problem:
When data changes in one file, could cause
inconsistencies
Compromises data integrity

Chapter 1

IT500: INFORMATION TECHNOLOGY

11

SOLUTION:
The DATABASE Approach

Central repository of shared data


Data is managed by a controlling agent
Stored in a standardized, convenient form

Requires a Database Management System (DBM


Chapter 1

IT500: INFORMATION TECHNOLOGY

12

Database Management System

A software system that is used to create, maintain, and


provide controlled access to user databases
Order Filing
System

Invoicing
System

Payroll
System

DBMS

Central database
Contains employee,
order, inventory,
pricing, and
customer data

DBMS manages data resources like an operating system manages


hardware resources

Chapter 1

IT500: INFORMATION TECHNOLOGY

13

Database Management System

Figure 4: Example of a DBMS Approach in a company

Chapter 1

IT500: INFORMATION TECHNOLOGY

14

Advantages of Database Approach

Program-data independence
Planned data redundancy
Improved data consistency
Improved data sharing
Increased application development
productivity
Enforcement of standards
Improved data quality
Improved data accessibility and
responsiveness
Reduced program maintenance
Improved decision support
Chapter 1

IT500: INFORMATION TECHNOLOGY

15

Costs and Risks of Database Approach


New, specialized personnel
Installation and management cost and
complexity
Conversion costs
Need for explicit backup and recovery
Organizational conflict

Chapter 1

IT500: INFORMATION TECHNOLOGY

16

Components of Database Environment

Chapter 1

IT500: INFORMATION TECHNOLOGY

17

Components of Database Environment


CASE
Toolscomputer-aided
engineering
Repositorycentralized
metadata

software

storehouse

of

Database Management System (DBMS)


software for managing the database
Databasestorehouse of the data
Application
Programssoftware using the data
Chapter 1
IT500: INFORMATION TECHNOLOGY

18

Components of Database Environment


User Interfacetext and graphical displays to
users
Data/Database
Administratorspersonnel
responsible for maintaining the database
System Developerspersonnel responsible for
designing databases and software
End Userspeople who use the applications and
databases
Chapter 1

IT500: INFORMATION TECHNOLOGY

19

Elements of the Database Approach


Data Model

Graphical model showing high-level


relationships for the organization

entities

and

Relational Databases

Database
technology
involving
tables
(relations)
representing
entities
and
primary/foreign
keys
representing relationships

Use of Internet Technology

Networks and telecommunications, distributed databases,


client-server and 3-tier architectures

Database Applications

Application programs used to perform database activities


(create, read, update, and delete) for database users

Chapter 1

IT500: INFORMATION TECHNOLOGY

20

Figure 5: Example of a DBMS Approach in a company

Chapter 1

IT500: INFORMATION TECHNOLOGY

21

One customer may


place many orders, but
each order is placed by
a single customer
One-to-many
relationship

Figure 5: Example of a DBMS Approach in a company

Chapter 1

IT500: INFORMATION TECHNOLOGY

22

One order has many order


lines; each order line is
associated with a single order
One-to-many
relationship

Figure 5: Example of a DBMS Approach in a company

Chapter 1

IT500: INFORMATION TECHNOLOGY

23

One product can be in many


order lines, each order line
refers to a single product
One-to-many
relationship

Figure 5: Example of a DBMS Approach in a company

Chapter 1

IT500: INFORMATION TECHNOLOGY

24

Therefore, one order involves


many products and one
product is involved in many
orders
Many-to-many
relationship

Figure 5: Example of a DBMS Approach in a company

Chapter 1

IT500: INFORMATION TECHNOLOGY

25

Figure 6: Four relations Order and Order line Tables

Relationships established in special columns that provide


links between tables
Chapter 1

IT500: INFORMATION TECHNOLOGY

26

Figure 7: Computer Systems for


Pine Valley Company

Client/server system
architecture

Chapter 1

IT500: INFORMATION TECHNOLOGY

27

Application program functions:


inserting new data, updating existing data,
deleting existing data, reading data for display
Chapter 1
IT500: INFORMATION TECHNOLOGY

28

Figure 8: Summary of Database Applications

Chapter 1

IT500: INFORMATION TECHNOLOGY

29

Figure 9: Typical Data from a


Personal Database

Chapter 1

IT500: INFORMATION TECHNOLOGY

30

Figure 10: Workgroup database with local area


network

Chapter 1

IT500: INFORMATION TECHNOLOGY

31

Figure 11: An enterprise data


warehouse

Chapter 1

IT500: INFORMATION TECHNOLOGY

32

Evolution of DB Systems

Flat files - 1960s - 1980s


Hierarchical 1970s - 1990s
Network 1970s - 1990s
Relational 1980s - present
Object-oriented 1990s - present
Object-relational 1990s - present
Data warehousing 1980s - present
Web-enabled 1990s - present

Chapter 1

IT500: INFORMATION TECHNOLOGY

33

Systems Development Life Cycle


Planning
Analysis
Logical Design
Physical Design
Implementation
Maintenance

Chapter 1

IT500: INFORMATION TECHNOLOGY

34

Systems Development Life Cycle


Purposepreliminary understanding
Deliverablerequest for study

Planning
Planning
Analysis

Logical Design
Physical Design

Database activity
early conceptual data
modeling

Chapter 1

Implementation
Maintenance

IT500: INFORMATION TECHNOLOGY

35

Systems Development Life Cycle


Purposethorough requirements
analysis
Deliverablefunctional system
specifications

Planning
Analysis
Analysis
Logical Design

Physical Design

Database activity
thorough conceptual data
modeling

Chapter 1

Implementation
Maintenance

IT500: INFORMATION TECHNOLOGY

36

Systems Development Life Cycle


Purposeinformation requirements
structure
Deliverabledetailed design specifications

Planning
Analysis

Logical Design
Logical
Design
Physical Design

Database activity
logical database
design

Chapter 1

Implementation
Maintenance

IT500: INFORMATION TECHNOLOGY

37

Systems Development Life Cycle


Purposedevelop technology
and organizational
specifications

Planning
Analysis
Logical Design

Deliverableprogram/data
structures, technology
purchases, organization
redesigns
Physical
Design
Physical Design

Database activity
physical database design
(physical data
organization, database
processing programs)
Chapter 1

Implementation
Maintenance

IT500: INFORMATION TECHNOLOGY

38

Systems Development Life Cycle


Purposeprogramming, testing,
training, installation,
documenting

Planning
Analysis
Logical Design

Deliverableoperational
programs, documentation,
training materials
Physical Design

Database activity
database implementation,
including coded programs,
documentation, installation
and conversion
Chapter 1

Implementation
Implementation
Maintenance

IT500: INFORMATION TECHNOLOGY

39

Systems Development Life Cycle


Purposemonitor, repair, enhance

Planning

Deliverableperiodic audits

Analysis
Logical Design

Physical Design

Database activity
database
maintenance,
performance
analysis and tuning,
error corrections
Chapter 1

Implementation
Maintenance
Maintenance

IT500: INFORMATION TECHNOLOGY

Modelling Data in the


Organization
Source: Modern Database Management 7th
Edition
Jeffrey A. Hoffer, Mary B. Prescott, Fred R.
McFadden
IT500: INFORMATION TECHNOLOGY

41

Enterprise Data Model


First step in database development
Specifies scope and general content
Overall picture of organizational data at
high level of abstraction
Entity-relationship diagram
Descriptions of entity types
Relationships between entities
Business rules

Chapter 1

IT500: INFORMATION TECHNOLOGY

42

Enterprise data model


describes the high-level
entities in an
organization and the
relationship between
these entities

Segment from enterprise data model


(Pine Valley Furniture Company)
Chapter 1

IT500: INFORMATION TECHNOLOGY

43

Information Systems Architecture


(ISA)

Conceptual blueprint for organizations desired


information systems structure
Consists of:

Data (e.g. Enterprise Data Model simplified ER


Diagram)
Processes data flow diagrams, process decomposition,
etc.
Data Network topology diagram
People

people
management
using
project
management tools (Gantt charts, etc.)
Events and points in time (when processes are
performed)
Reasons for events and rules (e.g. decision tables)
Chapter 1
IT500: INFORMATION TECHNOLOGY

44

Information Engineering
A data-oriented methodology to create and
maintain information systems
Top-down planning: a generic IS planning
methodology
for
obtaining
a
broad
understanding of the IS needed by the entire
organization
Four steps to Top-Down planning:
Planning
Analysis
Design
Implementation
Chapter 1

IT500: INFORMATION TECHNOLOGY

45

Information Systems Planning


Purpose: align information technology with
organizations business strategies
Three steps:
1. Identify strategic planning factors
2. Identify corporate planning objects
3. Develop enterprise model

Chapter 1

IT500: INFORMATION TECHNOLOGY

46

Identify Strategic Planning Factors


Organization
accomplish

goals

what

we

hope

to

Critical success factors what MUST work in


order for us to survive
Problem areas weaknesses we now have

Chapter 1

IT500: INFORMATION TECHNOLOGY

47

Identify Corporate Planning Objects


Organizational units departments
Organizational locations
Business functions groups of business
processes
Entity types the things we are trying to model
for the database
Information systems application programs
Chapter 1

IT500: INFORMATION TECHNOLOGY

48

Develop Enterprise Model


Functional decomposition
Enterprise data model
Planning matrixes

Chapter 1

IT500: INFORMATION TECHNOLOGY

49

Decomposition -breaking large tasks


into smaller tasks in a
hierarchical structure
chart

Example of process decomposition of an


order fulfillment function
Chapter 1

IT500: INFORMATION TECHNOLOGY

50

Planning Matrixes
Describe relationships between planning
objects in the organization
Types of matrixes:
Function-to-data entity
Location-to-function
Unit-to-function
IS-to-data entity
Supporting function-to-data entity
IS-to-business objective

Chapter 1

IT500: INFORMATION TECHNOLOGY

Data Entity
Types
Business
Function (users)

Customer
Product
Raw Material
Order
Work Center
Work Order
Invoice
Equipment
Employee

51

Business Planning
Product Development
Materials Management
Order Fulfillment
Order Shipment
Sales Summarization
Production Operations
Finance and Accounting

X X
X
X
X
X

X X
X
X X X X
X X X X X
X
X X
X
X
X X X X X
X X X X

X
X
X
X
X

Example business function-to-data entity


matrix
Chapter 1

IT500: INFORMATION TECHNOLOGY

X X
X
X
X X
X
X
X X
X X

52

Two Approaches to Database and


IS Development
SDLC

System Development Life Cycle


Detailed, well-planned development process
Time-consuming, but comprehensive
Long development cycle

Prototyping

Rapid application development (RAD)


Cursory attempt at conceptual data modeling.
Define database during development of initial
prototype
Repeat implementation and maintenance activities
with new prototype versions

Chapter 1

IT500: INFORMATION TECHNOLOGY

53

Systems Development Life


Cycle
Project Identification
and Selection

Project Initiation
and Planning
Analysis

Logical Design
Physical Design
Implementation
Maintenance

Chapter 1

IT500: INFORMATION TECHNOLOGY

54

Prototyping methodology and database development process

Chapter 1

IT500: INFORMATION TECHNOLOGY

55

Packaged Data Models


Model components that can be purchased,
customized, and assembled into full-scale data
models
Advantages
Reduced development time
Higher model quality and reliability
Two types:
Universal data models
Industry-specific data models

Chapter 1

IT500: INFORMATION TECHNOLOGY

56

CASE
Computer-Aided Software Engineering (CASE)
software tools providing automated support for
systems development
Three database features:
Data modeling entity-relationship diagrams
Code generation SQL code for table creation
Repositories knowledge base of enterprise
information

Chapter 1

IT500: INFORMATION TECHNOLOGY

57

Managing Projects
Project a planned undertaking of related activities
to reach an objective that has a beginning and an
end
Involves use of review points for:
Validation of satisfactory progress
Step back from detail to overall view
Renew commitment of stakeholders
Incremental commitment review of systems
development project after each development phase
with rejustification after each phase

Chapter 1

IT500: INFORMATION TECHNOLOGY

58

Managing Projects: People Involved

Systems analysts
Database analysts
Users
Programmers
Database/data administrators
Systems programmers, network administrators,
testers, technical writers

Chapter 1

IT500: INFORMATION TECHNOLOGY

59

Gantt Chart
Shows time estimates of tasks

Chapter 1

IT500: INFORMATION TECHNOLOGY

60

PERT Chart
Shows dependencies between tasks
Chapter 1

IT500: INFORMATION TECHNOLOGY

The Data Modelling

IT 500: INFORMATION TECHNOLOGY

62

Business Rules
Statements that define or constrain some
aspect of the business
Assert business structure
Control/influence business behavior
Expressed in terms familiar to end users
Automated through DBMS software

Chapter 1

IT500: INFORMATION TECHNOLOGY

63

A Good Business Rule is:


Declarative what, not how
Precise clear, agreed-upon meaning
Atomic one statement
Consistent internally and externally
Expressible structured, natural language
Distinct non-redundant
Business-oriented understood by business
people

Chapter 1

IT500: INFORMATION TECHNOLOGY

64

A Good Data Name is:


Related
to
business,
not
technical,
characteristics
Meaningful and self-documenting(refine)
Unique (distinct from other)
Readable
Composed of words from an approved list
Repeatable(different people or the same person
at different times should develop exactly or
almost the same names)

Chapter 1

IT500: INFORMATION TECHNOLOGY

65

Data Definitions
Explanation of a term or fact
Term word or phrase with specific meaning
Fact association between two or more terms
Guidelines for good data definition
Gathered in conjunction with systems requirements
Accompanied by diagrams
Iteratively created and refined(developing data
model test your understanding of the meaning of
data)
Achieved by consensus

Chapter 1

IT500: INFORMATION TECHNOLOGY

66

E-R Model Constructs


Entity instance person, place, object, event,
concept (often corresponds to a row in a table)
Entity type collection of entity instances
(often corresponds to a table)
Relationship instance link between entity
instances (corresponds to individual primary
key-foreign key value match)
Relationship type link between entity types
(primary key-foreign key link)

Chapter 1

IT500: INFORMATION TECHNOLOGY

67

Basic E-R notation


Entity
symbols

Attribute
symbols

A special entity
that is also a
relationship

Relationship
symbols

Relationship
degrees
specify number
of entity types
involved

Chapter 1

Relationship
cardinalities
specify how
many of each
entity type is
allowed

IT500: INFORMATION TECHNOLOGY

68

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)

Chapter 1

IT500: INFORMATION TECHNOLOGY

69

Inappropriate entities

ystem user

Chapter 1

System output

IT500: INFORMATION TECHNOLOGY

70

Appropriate entities

Chapter 1

IT500: INFORMATION TECHNOLOGY

71

Identifiers (Keys)
Identifier (Key) an attribute (or combination
of attributes) that uniquely identifies individual
instances of an entity type
Simple vs. Composite Identifier

Chapter 1

IT500: INFORMATION TECHNOLOGY

72

Characteristics of Identifiers
Will not change in value
Will not be null
No intelligent identifiers (e.g. containing
locations or people that might change)
Substitute new, simple keys for long, composite
keys

Chapter 1

IT500: INFORMATION TECHNOLOGY

73

Simple and composite identifier attributes

The identifier
is boldfaced
and
underlined

Chapter 1

IT500: INFORMATION TECHNOLOGY

74

Strong vs. Weak Entities, and


Identifying Relationships
Strong entity
exist independently of other types of entities
has its own unique identifier
identifier underlined with single-line
Weak entity
depends on a strong entity (identifying owner)
cannot exist on its own
does not have a unique identifier
Partial identifier underlined with double-line
Entity box has double line
Identifying relationship
links strong entities to weak entities
Chapter 1

IT500: INFORMATION TECHNOLOGY

75

Example of a weak identity and its identifying


relationship

Strong entity

Chapter 1

Weak entity

IT500: INFORMATION TECHNOLOGY

76

Relationships
Relationship Types vs. Relationship Instances
The relationship type is modeled as lines
between entity typesthe instance is between
specific entity instances
Two entities can have more than one type of
relationship between them (multiple relationships)

Chapter 1

IT500: INFORMATION TECHNOLOGY

77

Relationship types and instances


a) Relationship
type (Completes)

b)
Relationship
instances

Chapter 1

IT500: INFORMATION TECHNOLOGY

78

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

Chapter 1

IT500: INFORMATION TECHNOLOGY

79

Degree of relationships

One entity
related to
another of
the same
entity type
Chapter 1

Entities of
two
different
types
related to
each other

Entities of
three
different
types related
to each other

IT500: INFORMATION TECHNOLOGY

80

Cardinality of Relationships
One-to-One: Each entity instance in the
relationship will have exactly one related entity
instance
One-to-Many: An entity instance on one side
of the relationship can have many related entity
instances, but an entity instance on the other
side will have a maximum of one related entity
instance
Many-to-Many: An entity instance on either
side of the relationship can have many related
entity instances on the other side
Chapter 1

IT500: INFORMATION TECHNOLOGY

81

Unary Relationship

Examples of relationships of different degrees

Chapter 1

IT500: INFORMATION TECHNOLOGY

82

Binary Relationship

Examples of relationships of different degrees

Chapter 1

IT500: INFORMATION TECHNOLOGY

83

Ternary Relationship

Note: a relationship can have attributes of its own


Chapter 1

IT500: INFORMATION TECHNOLOGY

84

Cardinality Constraints
Cardinality Constraintsthe 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
Chapter 1

IT500: INFORMATION TECHNOLOGY

85

Examples of cardinality constraints

Chapter 1

IT500: INFORMATION TECHNOLOGY

86

Mandatory Cardinalities

A patient history is
recorded for one and
only one patient

Chapter 1

A patient must have


recorded at least one
history, and can have
many

IT500: INFORMATION TECHNOLOGY

87

One Optional, One Mandatory

A project must be
assigned to at least
one employee, and
may be assigned to
many

Chapter 1

An employee can be
assigned to any number
of projects, or may not be
assigned to any at all

IT500: INFORMATION TECHNOLOGY

88

Optional Cardinalities

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

Chapter 1

IT500: INFORMATION TECHNOLOGY

89

Cardinality constraints in a ternary relationship

Chapter 1

IT500: INFORMATION TECHNOLOGY

90

Associative Entities
An entity has attributes
A relationship links entities together

Chapter 1

IT500: INFORMATION TECHNOLOGY

91

Attributes
Attributeproperty or characteristic of an
entity or relationship type.
Classifications of attributes:
Simple versus Composite Attribute
Single-Valued versus Multivalued Attribute
Stored versus Derived Attributes
Identifier Attributes

Chapter 1

IT500: INFORMATION TECHNOLOGY

92

A composite attribute
An attribute
broken into
component
parts

Chapter 1

IT500: INFORMATION TECHNOLOGY

93

Simple Key Attribute

The key is underlined

Chapter 1

IT500: INFORMATION TECHNOLOGY

94

Composite Key Attribute

The key is composed


of two subparts

Chapter 1

IT500: INFORMATION TECHNOLOGY

95

A composite attribute
An attribute
broken into
component parts

Figure 2-8 Entity with multivalued attribute (Skill)


and derived attribute (Years Employed)

Multivalued
an employee can have
more than one skill

Chapter 1

Derived
from date
employed
and current
date
IT500: INFORMATION TECHNOLOGY

96

A binary relationship with an attribute

Here, the date completed attribute pertains


specifically to the employees completion of a
course. It is an attribute of the relationship
Chapter 1

IT500: INFORMATION TECHNOLOGY

97

An associative entity

Associative entity is like a relationship with an


attribute, but it is also considered to be an entity in
its own right
Note that the many-to-many cardinality between
entities in Figure 2-11a has been replaced by two
one-to-many relationships with the associative
Chapter 1
entity
IT500: INFORMATION TECHNOLOGY

The Relational Model

Source: Modern Database Management 7th


Edition
Jeffrey A. Hoffer, Mary B. Prescott, Fred R.
McFadden
IT500: INFORMATION TECHNOLOGY

99

Relation
Definition: A relation is a named, twodimensional table of data
Table: relation
Row: record
Column: attribute, field

Chapter 1

IT500: INFORMATION TECHNOLOGY

100

Properties of Relation
It must have a unique name
Every attribute value must be atomic (not multivalued)
Every row must be unique (cant 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 is irrelevant
The order of the rows is irrelevant

Chapter 1

IT500: INFORMATION TECHNOLOGY

101

Key Fields
Primary key: attribute(s) that
identifies each record
Ex: employee numbers, social
numbers, etc.

uniquely
security

Foreign key: attribute(s) 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
composite (more than one field)
Chapter 1

field)

IT500: INFORMATION TECHNOLOGY

or

102

Primary Key
Foreign Key

Combined, these are a


composite primary key
(uniquely identifies the order
line)individually they are
foreign keys

gure 1: Schema for four relations (Pine Valley Furniture Company


Chapter 1

IT500: INFORMATION TECHNOLOGY

103

Text Description of Relations


CUSTOMER
(Customer_ID, Customer_Name, Address, City, State,
Zip)
ORDER
(Order_ID, Order_Date, Customer_ID)
ORDER_LINE
(Order_ID, Product_ID, Quantity)
PRODUCT
(Product_ID, Product_Description, Product_Finish,
Standard_Price, Product_Line_ID)

Chapter 1

IT500: INFORMATION TECHNOLOGY

104

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

Chapter 1

IT500: INFORMATION TECHNOLOGY

105

igure 2: Domain definitions enforce domain integrity constraints

Chapter 1

IT500: INFORMATION TECHNOLOGY

106

Referential Integrity Constraints


Any foreign key value of a relation MUST match
a primary key value in the related relation
Referential integrity constraints apply to insert
(foreign key values) and delete (primary key
values) operation

Chapter 1

IT500: INFORMATION TECHNOLOGY

107

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

Figure 3: Referential integrity constraints


Chapter 1

IT500: INFORMATION TECHNOLOGY

108

Well-Structured Relations
A
relation
that
contains
minimal
data
redundancy and allows users to insert, delete,
and update rows without causing data
inconsistencies
Goal is to avoid anomalies
Insertion Anomaly adding new rows forces
user to create duplicate data
Deletion Anomaly deleting rows may cause
a loss of data that would be needed for other
future rows
Modification Anomaly changing data in a
row forces changes to other rows because of
duplication
Chapter 1

IT500: INFORMATION TECHNOLOGY

109

QuestionIs this a relation?

QuestionWhats the primary key?

Chapter 1

AnswerYes: Unique rows and no


multivalued attributes
AnswerComposite: EmpID

IT500: INFORMATION TECHNOLOGY

110

Anomalies in this Table


INSERTIONcant enter a new employee without
having the employee take a class
DELETION if we remove employee 140, we lose
information about the existence of a Tax Acc class
MODIFICATION giving a salary increase to
employee 100 forces us to update multiple records
Why do these anomalies exist?
Because there are two themes (entity types) in
this one relation. This results in data duplication
and an unnecessary dependency between the
entities

Chapter 1

IT500: INFORMATION TECHNOLOGY

111

Attributes
Attributeproperty or characteristic of an
entity or relationship type.
Classifications of attributes:
Simple versus Composite Attribute
Single-Valued versus Multivalued Attribute
Stored versus Derived Attributes
Identifier Attributes

Chapter 1

IT500: INFORMATION TECHNOLOGY

112

A composite attribute
An attribute
broken into
component
parts

Chapter 1

IT500: INFORMATION TECHNOLOGY

113

Simple Key Attribute

The key is underlined

Chapter 1

IT500: INFORMATION TECHNOLOGY

114

Composite Key Attribute

The key is composed


of two subparts

Chapter 1

IT500: INFORMATION TECHNOLOGY

115

A composite attribute
An attribute
broken into
component parts

Figure 2-8 Entity with multivalued attribute (Skill)


and derived attribute (Years Employed)

Multivalued
an employee can have
more than one skill

Chapter 1

Derived
from date
employed
and current
date
IT500: INFORMATION TECHNOLOGY

116

A binary relationship with an attribute

Here, the date completed attribute pertains


specifically to the employees completion of a
course. It is an attribute of the relationship
Chapter 1

IT500: INFORMATION TECHNOLOGY

117

An associative entity

Associative entity is like a relationship with an


attribute, but it is also considered to be an entity in
its own right
Note that the many-to-many cardinality between
entities in Figure 2-11a has been replaced by two
one-to-many relationships with the associative
Chapter 1
entity
IT500: INFORMATION TECHNOLOGY

Logical Database
Design

Source: Modern Database Management 7th


Edition
Jeffrey A. Hoffer, Mary B. Prescott, Fred R.
McFadden
IT 500: INFORMATION TECHNOLOGY

119

Transforming EER Diagrams into Relations


Mapping Regular Entities to Relations
Entity Relation (table)
Identifier Primary key
Composite attributes:
component attributes

Use

only

their

simple,

Multivalued Attribute: Becomes a separate


relation with a foreign key taken from the superior
entity

Chapter 1

IT500: INFORMATION TECHNOLOGY

120

(A) CUSTOMER entity type with composite attribute

) CUSTOMER relation with address detail

Figure 5: Mapping a composite attribute

Chapter 1

IT500: INFORMATION TECHNOLOGY

121

(A)

Multivalued attribute becomes a separate relation with foreign key

(B)

Onetomany relationship between original entity and new relation

Figure 6: Mapping an entity with a multivalued attribute


Chapter 1

IT500: INFORMATION TECHNOLOGY

122

Transforming EER Diagrams into Relations


Mapping Weak Entities
Becomes a separate relation with a foreign
key taken from the strong entity
Primary key composed of:
Partial identifier of weak entity
Primary key of identifying relation (strong
entity)

Chapter 1

IT500: INFORMATION TECHNOLOGY

123

A) Weak entity DEPENDENT

Figure 7: Example of mapping a weak entity

Chapter 1

IT500: INFORMATION TECHNOLOGY

124

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


Figure 7: Example of mapping a weak entity (cont.)

Chapter 1

IT500: INFORMATION TECHNOLOGY

125

Transforming EER Diagrams into Relations


MAPPING BINARY RELATIONSHIPS
One-to-Many: Primary key on the one side
becomes a foreign key on the many side
Many-to-Many: Create a new relation with the
primary keys of the two entities as its primary
key
One-to-One: Primary key on the mandatory side
becomes a foreign key on the optional side

Chapter 1

IT500: INFORMATION TECHNOLOGY

126

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
Figure 8 Example of mapping
a 1:M relationship
Chapter 1

IT500: INFORMATION TECHNOLOGY

127

) Completes relationship (M:N)

e Completes relationship will need to become a separate relation


Figure 9: Example of mapping an M:N relationship

Chapter 1

IT500: INFORMATION TECHNOLOGY

128

) Three resulting relations

Composite primary
key
Foreign
key

Foreign
key

New
intersectio
n relation

Figure 9: Example of mapping an M:N relationship (cont.)


Chapter 1

IT500: INFORMATION TECHNOLOGY

129

In charge relationship (1:1)

Often in 1:1 relationships, one direction is optional

Figure 10: Example of mapping a binary 1:1 relationship

Chapter 1

IT500: INFORMATION TECHNOLOGY

130

B) Resulting relations

Foreign key goes in the relation on the optional side,


matching the primary key on the mandatory side

Figure 10: Example of mapping a binary 1:1 relationship (cont.)

Chapter 1

IT500: INFORMATION TECHNOLOGY

131

Transforming EER Diagrams into Relations


MAPPING ASSOCIATIVE ENTITIES
Identifier Not Assigned: Default primary key for the
association relation is composed of the primary
keys of the two entities (as in M:N relationship)
Identifier Assigned: Primary key for the associative
relation is the assigned identifier and the primary
keys for the two participating entity types become
foreign keys in the associative relation

Chapter 1

IT500: INFORMATION TECHNOLOGY

132

(A) An associative entity

Figure 11: Example of mapping an associative entity

Chapter 1

IT500: INFORMATION TECHNOLOGY

133

B) Three resulting relations

Composite primary key formed from the two foreign


keys
Figure 11: Example of mapping an associative entity (cont.)

Chapter 1

IT500: INFORMATION TECHNOLOGY

134

SHIPMENT associative entity

Figure 12: Example of mapping an associative entity with


an identifier

Chapter 1

IT500: INFORMATION TECHNOLOGY

135

) Three resulting relations

Primary key differs from foreign


keys

Figure 12: Example of mapping an associative entity with an


identifier (cont.)

Chapter 1

IT500: INFORMATION TECHNOLOGY

136

Transforming EER Diagrams into Relations


MAPPING UNARY RELATIONSHIPS
One-to-Many: A recursive foreign key in the
same relation
Many-to-Many: Two relations:
One for the entity type
One for an associative relation in which the
primary key has two attributes, both taken
from the primary key of the entity

Chapter 1

IT500: INFORMATION TECHNOLOGY

137

(A) EMPLOYEE entity with unary


relationship

(B) EMPLOYEE relation with recursive


foreign key

Figure 13: Mapping a unary 1:N relationship


Chapter 1

IT500: INFORMATION TECHNOLOGY

138

(A) Bill-of-materials relationships


(M:N)

(B) ITEM and COMPONENT


relations

Figure 13: Mapping a unary 1:N relationship (cont.)


Chapter 1

IT500: INFORMATION TECHNOLOGY

139

Transforming EER Diagrams into Relations


MAPPING
TERNARY
RELATIONSHIPS

(AND

N-ARY)

One relation for each entity and one for the


associative entity
Apply the rules in mapping binary relationship
to each pair of entities in ternary relationship

Chapter 1

IT500: INFORMATION TECHNOLOGY

140

(A) PATIENT TREATMENT Ternary relationship with


associative entity

Figure 14: Mapping a ternary relationship


Chapter 1

IT500: INFORMATION TECHNOLOGY

141

Mapping the ternary relationship PATIENT TREATMENT

It would be
But this
This is why
better to
makes a very
treatment
create a
cumbersome
date and
surrogate
key
time are
key like
included in
Treatment#
the
composite
primary key
Figure 14: Mapping a ternary relationship (cont.)
Chapter 1
Remember
that the
primary
key MUST
be unique

IT500: INFORMATION TECHNOLOGY

142

Transforming EER Diagrams into Relations


MAPPING SUPERTYPE/SUBTYPE RELATIONSHIPS
One relation for supertype and for each subtype
Supertype attributes (including identifier and
subtype discriminator) go into supertype relation
Subtype attributes go into each subtype; primary
key of supertype relation also becomes primary
key of subtype relation
1:1 relationship established between supertype
and each subtype, with supertype as primary
table

Chapter 1

IT500: INFORMATION TECHNOLOGY

143

Chapter 1

Figure 15: Supertype/subtype


relationships

IT500: INFORMATION TECHNOLOGY

144

These are implemented as one-to-one


relationships

Chapter 1

Figure 15: Supertype/subtype


relationships (cont.)

IT500: INFORMATION TECHNOLOGY

-end of Lecture-

IT500: INFORMATION TECHNOLOGY