3 Database

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
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
Figure 1: Data in Context

Context helps users understand
data
Chapter 1
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
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
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
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
Duplicate Data
Figure 3: Three file processing systems at Pine Valley Furniture
Chapter 1
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
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
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
13
Database Management System
Figure 4: Example of a DBMS Approach in a company
Chapter 1
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
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
16
Components of Database Environment
Chapter 1
17

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
18

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
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
20
Chapter 1
21
One customer may

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

lines; each order line is
associated with a single order
One-to-many
relationship
Chapter 1
23
One product can be in many

order lines, each order line
refers to a single product
One-to-many
relationship
Chapter 1
24
Therefore, one order involves

many products and one
product is involved in many
orders
Many-to-many
relationship
Chapter 1
25
Figure 6: Four relations Order and Order line Tables
Relationships established in special columns that provide

links between tables
Chapter 1
26
Figure 7: Computer Systems for

Pine Valley Company
Client/server system
architecture
Chapter 1
27
Application program functions:

inserting new data, updating existing data,
deleting existing data, reading data for display
Chapter 1
28
Figure 8: Summary of Database Applications
Chapter 1
29
Figure 9: Typical Data from a

Personal Database
Chapter 1
30
Figure 10: Workgroup database with local area

network
Chapter 1
31
Figure 11: An enterprise data

warehouse
Chapter 1
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
33
Systems Development Life Cycle

Planning
Analysis
Logical Design
Physical Design
Implementation
Maintenance
Chapter 1
34

Purposepreliminary understanding
Deliverablerequest for study
Planning
Planning
Analysis
Logical Design
Physical Design
Database activity
early conceptual data
modeling
Chapter 1
Implementation
Maintenance
35

Purposethorough requirements
analysis
Deliverablefunctional system
specifications
Planning
Analysis
Analysis
Logical Design
Physical Design
Database activity
thorough conceptual data
modeling
Chapter 1
Implementation
Maintenance
36

Purposeinformation requirements
structure
Deliverabledetailed design specifications
Planning
Analysis
Logical Design
Logical
Design
Physical Design
Database activity
logical database
design
Chapter 1
Implementation
Maintenance
37

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
38

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
39

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
Modelling Data in the

Organization
Source: Modern Database Management 7th
Edition
Jeffrey A. Hoffer, Mary B. Prescott, Fred R.
McFadden
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
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
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
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
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
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
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
48
Develop Enterprise Model

Functional decomposition
Enterprise data model
Planning matrixes
Chapter 1
49
Decomposition -breaking large tasks

into smaller tasks in a
hierarchical structure
chart
Example of process decomposition of an

order fulfillment function
Chapter 1
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
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
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
53
Systems Development Life

Cycle
Project Identification
and Selection
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Implementation
Maintenance
Chapter 1
54
Prototyping methodology and database development process
Chapter 1
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
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
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
58
Managing Projects: People Involved
Systems analysts
Database analysts
Users
Programmers
Database/data administrators
Systems programmers, network administrators,
testers, technical writers
Chapter 1
59
Gantt Chart
Shows time estimates of tasks
Chapter 1
60
PERT Chart
Shows dependencies between tasks
Chapter 1
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
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
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
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
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
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
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
69
Inappropriate entities
ystem user
Chapter 1
System output
70
Appropriate entities
Chapter 1
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
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
73
Simple and composite identifier attributes
The identifier
is boldfaced
and
underlined
Chapter 1
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
75
Example of a weak identity and its identifying

relationship
Strong entity
Chapter 1
Weak entity
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
77
Relationship types and instances

a) Relationship
type (Completes)
b)
Relationship
instances
Chapter 1
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
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
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
81
Unary Relationship
Examples of relationships of different degrees
Chapter 1
82
Binary Relationship
Examples of relationships of different degrees
Chapter 1
83
Ternary Relationship
Note: a relationship can have attributes of its own

Chapter 1
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
85
Examples of cardinality constraints
Chapter 1
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
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
88
Optional Cardinalities
A person is
married to at
most one other
person, or may
not be married
at all
Chapter 1
89
Cardinality constraints in a ternary relationship
Chapter 1
90
Associative Entities
An entity has attributes
A relationship links entities together
Chapter 1
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
92
A composite attribute
An attribute
broken into
component
parts
Chapter 1
93
Simple Key Attribute
The key is underlined
Chapter 1
94
Composite Key Attribute
The key is composed

of two subparts
Chapter 1
95
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
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
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
The Relational Model

Edition
McFadden
99
Relation
Definition: A relation is a named, twodimensional table of data
Table: relation
Row: record
Column: attribute, field
Chapter 1
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
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)
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
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
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
105
igure 2: Domain definitions enforce domain integrity constraints
Chapter 1
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
107
Referential
integrity
constraints are
drawn via
arrows from
dependent to
parent table
Figure 3: Referential integrity constraints

Chapter 1
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
109
QuestionIs this a relation?
QuestionWhats the primary key?
Chapter 1
AnswerYes: Unique rows and no

multivalued attributes
AnswerComposite: EmpID
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
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
112
An attribute
broken into
component
parts
Chapter 1
113
Simple Key Attribute
The key is underlined
Chapter 1
114
Composite Key Attribute
The key is composed

of two subparts
Chapter 1
115
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
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
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
Logical Database
Design

Edition
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
120
(A) CUSTOMER entity type with composite attribute
) CUSTOMER relation with address detail
Figure 5: Mapping a composite attribute
Chapter 1
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
122

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
123
A) Weak entity DEPENDENT
Figure 7: Example of mapping a weak entity
Chapter 1
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
125

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
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
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
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
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
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
131

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
132
(A) An associative entity
Figure 11: Example of mapping an associative entity
Chapter 1
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
134
SHIPMENT associative entity
Figure 12: Example of mapping an associative entity with

an identifier
Chapter 1
135
) Three resulting relations
Primary key differs from foreign

keys
Figure 12: Example of mapping an associative entity with an

identifier (cont.)
Chapter 1
136

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
137
(A) EMPLOYEE entity with unary

relationship
(B) EMPLOYEE relation with recursive

foreign key
Figure 13: Mapping a unary 1:N relationship

Chapter 1
138
(A) Bill-of-materials relationships

(M:N)
(B) ITEM and COMPONENT

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

Chapter 1
139

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
140
(A) PATIENT TREATMENT Ternary relationship with

associative entity
Figure 14: Mapping a ternary relationship

Chapter 1
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
142

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
143
Chapter 1
Figure 15: Supertype/subtype

relationships
144
These are implemented as one-to-one

relationships
Chapter 1
Figure 15: Supertype/subtype

relationships (cont.)
-end of Lecture-

3 Database

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

3 Database

Încărcat de

Drepturi de autor:

Formate disponibile

The Database

IT500: INFORMATION TECHNOLOGY

IT500: INFORMATION TECHNOLOGY

Information: data processed to increase

IT500: INFORMATION TECHNOLOGY

Figure 1: Data in Context

IT500: INFORMATION TECHNOLOGY

Figure 2: Converting data to information Summarized Data

Graphical displays turn data into useful

IT500: INFORMATION TECHNOLOGY

Table 1: Example Metadata for Class Roster

Descriptions of the properties or

IT500: INFORMATION TECHNOLOGY

Disadvantages of File Processing

IT500: INFORMATION TECHNOLOGY

Problems with Data Dependency

Each application programmer must maintain their

IT500: INFORMATION TECHNOLOGY

Figure 3: Three file processing systems at Pine Valley Furniture

IT500: INFORMATION TECHNOLOGY

Problems with Data Redundancy

IT500: INFORMATION TECHNOLOGY

Central repository of shared data

Requires a Database Management System (DBM

IT500: INFORMATION TECHNOLOGY

Database Management System

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

DBMS manages data resources like an operating system manages

IT500: INFORMATION TECHNOLOGY

Database Management System

Figure 4: Example of a DBMS Approach in a company

IT500: INFORMATION TECHNOLOGY

Advantages of Database Approach

IT500: INFORMATION TECHNOLOGY

Costs and Risks of Database Approach

IT500: INFORMATION TECHNOLOGY

Components of Database Environment

IT500: INFORMATION TECHNOLOGY

Components of Database Environment

Database Management System (DBMS)

Components of Database Environment

IT500: INFORMATION TECHNOLOGY

Elements of the Database Approach

Graphical model showing high-level

Use of Internet Technology

Networks and telecommunications, distributed databases,

Application programs used to perform database activities

IT500: INFORMATION TECHNOLOGY

Figure 5: Example of a DBMS Approach in a company

IT500: INFORMATION TECHNOLOGY

One customer may

Figure 5: Example of a DBMS Approach in a company

IT500: INFORMATION TECHNOLOGY

One order has many order

Figure 5: Example of a DBMS Approach in a company

IT500: INFORMATION TECHNOLOGY

One product can be in many

Figure 5: Example of a DBMS Approach in a company

IT500: INFORMATION TECHNOLOGY

Therefore, one order involves

Figure 5: Example of a DBMS Approach in a company

IT500: INFORMATION TECHNOLOGY

Figure 6: Four relations Order and Order line Tables

Relationships established in special columns that provide