Database Systems

Instructor:
Dr. Hamid Turab Mirza

Department of Computer Science

CUI, Lahore
 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
Data in context

Context helps users understand

data
Summarized data

Graphical displays turn data into

useful information that managers
can use for decision making and
interpretation
 Descriptions of the properties or
characteristics of the data, including data
types, field sizes, allowable values, and
data context
File Processing Systems
 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
 Problems with Data
Dependency
 Each application programmer must
maintain his/her 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
Old file processing systems at Pine Valley Furniture
Company
Duplicate Data
 Problems with Data
Redundancy
 Waste of space to have duplicate data
 Causes more maintenance headaches

 The biggest problem:

 Data changes in one file could cause

inconsistencies
 Compromises in data integrity
 SOLUTION:
The DATABASE Approach
 Central repository of shared data
 Data is managed by a controlling

agent
 Stored in a standardized,

convenient form
 Database Management
provide controlled System
 A software system that is used to create, maintain, and
access to user databases

Order Filing
System

Invoicing Central database

DBMS
System
Contains employee,
order, inventory,
pricing, and
Payroll
customer data
System

DBMS manages data resources like an operating system manages

hardware resources
 Advantages of the 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
Costs and Risks of the Database
Approach
 New, specialized personnel
 Installation and management cost
and complexity
 Conversion costs
 Need for explicit backup and
recovery
 Organizational conflict
 The Range of Database
Applications
 Personal databases
 Workgroup databases
 Departmental/divisional databases
 Enterprise database
Typical data
from a
personal
database
Workgroup database with wireless
local area network
Components of the Database Environment
 Components of the
Database Environment
 CASE Tools–computer-aided software engineering
 Repository–centralized storehouse of metadata
 Database Management System (DBMS) –
software for managing the database
 Database–storehouse of the data
 Application Programs–software using the data
 User Interface–text and graphical displays to
users
 Data/Database Administrators–personnel
responsible for maintaining the database
 System Developers–personnel responsible for
designing databases and software
 End Users–people who use the applications and
databases
 Elements of the Database
Approach
 Data models
 Graphical system capturing nature and relationship of data
 Enterprise Data Model–high-level entities and relationships
for the organization
 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
 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
Segment from enterprise data model

Enterprise data model

describes the high-
level entities in an
organization and the
relationship between
these entities
Segment of an Enterprise Data Model
One customer
may place many
orders, but each
order is placed by
a single customer
 One-to-many
relationship
One order has
many order lines;
each order line is
associated with a
single order
 One-to-many
relationship
One product can
be in many
order lines, each
order line refers
to a single
product
 One-to-many
relationship
 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
 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
 A Good Data Name is:
 Related to business, not technical,
characteristics
 Meaningful and self-documenting
 Unique
 Readable
 Composed of words from an approved
list
 Repeatable
 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
 Achieved by consensus
 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)
 Sample E-R Diagram - 1

Pine valley furniture company can purchase items

from a number of different suppliers, who then ship
the items to the manufacturer. The items are
assembled into products that are sold to customers
who order the products. Each customer order may
include one or more lines corresponding to the
Products appearing on that order.
Sample E-R Diagram •A SUPPLIER may supply many ITEMs (by
“may supply” we mean the supplier may not
supply any items). Each ITEM is supplied by
any number of SUPPLIERs (by “is supplied” we
mean must be supplied by at least one supplier).
•Each ITEM must be used in the assembly of at
least one PRODUCT, and may be used in many
products. Conversely, each PRODUCT must use
one or more ITEMs.
•A SUPPLIER may send many SHIPMENTs.
On the other hand, each shipment must be sent
by exactly one SUPPLIER.
•ASHIPMENT must include one (or more)
ITEMs. An ITEM may be included on several
SHIPMENTs.
•A CUSTOMER may submit any number of
ORDERs. However, each ORDER must be
submitted by exactly one CUSTOMER.
•An ORDER must request one (or more)
PRODUCTs. A given PRODUCT may not be
requested on nay ORDER, or may be requested
one one or more orders.
Basic E-R 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 is
allowed
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)
Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities
 Attributes
 Attribute–property or characteristic
of an entity or relationahip type
 Classifications of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single-Valued versus Multivalued
Attribute
 Stored versus Derived Attributes
 Identifier Attributes
 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
Characteristics of Identifiers
 Will not change in value
 Will not be null
 No intelligent identifiers (e.g.,
containing locations or people that
might change)
 A composite attribute

An attribute
broken into
component parts

Entity with multivalued attribute (Skill)

and derived attribute (Years_Employed)

Multivalued
an employee can have
Derived
more than one skill
from date
employed
and current
date
Simple and composite identifier attributes

The identifier is boldfaced and underlined

Simple example of time-stamping

This attribute
that is both
multivalued
and
composite
 Relationships
Examples of relationship types:

 A branch is managed by at most one manager

 A manager can manage at most one branch

 A transaction can update one account

 An account can be updated by many transactions

 A customer can own many accounts

 An account may be owned by more than one
customer
Relationship types and instances

a) Relationship type

b)
Relationship
instances
 Cardinality of Relationships
 One-to-One
 Each entity in the relationship will have exactly
one related entity
 One-to-Many
 An entity on one side of the relationship can
have many related entities, but an entity on
the other side will have a maximum of one
related entity
 Many-to-Many
 Entities on both sides of the relationship can
have many related entities on the other side
 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
Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have

recorded for one and recorded at least one
only one patient history, and can have
many
Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be An employee can be

assigned to at least assigned to any number
one employee, and of projects, or may not be
may be assigned to assigned to any at all
many
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
 Sample E-R Diagram – 2

ABC housing society is a medium sized local authority. One of the responsibilities of the
Society is the maintenance and repair of Society owned housing within its boundaries. The
authority wishes to develop an information system to monitor information on housing
repair work, a description of which is as follows:

“For the purpose of housing repair work, the society is divided into a number of areas.
Each area is subdivided into streets or roads, each street or road in likely to have a number
of houses along it. Details of each house are held, along with details of each instance of
repair work carried out to a specific house. Each area is maintained by a single repair team,
although a team may be responsible for more than one area. A repair team consists of a
number of employees, one of whom is designated the team supervisor. The team are
allocated a number of vehicles for use in their work, which are generally used by the
“owning” team only, although are occasionally “borrowed” by other Teams. Each team is
based at a maintenance depot, and in some cases, more than one team may be based at a
single depot”.
 Sample E-R Diagram - 2 (Entities
Identified)
ABC housing society is a medium sized local authority. One of the responsibilities of the
Society is the maintenance and repair of Society owned housing within its boundaries. The
authority wishes to develop an information system to monitor information on housing
repair work, a description of which is as follows:

“For the purpose of housing repair work, the society is divided into a number of areas.
Each area is subdivided into streets or roads, each street or road in likely to have a
number of houses along it. Details of each house are held, along with details of each
instance of repair work carried out to a specific house. Each area is maintained by a
single repair team, although a team may be responsible for more than one area. A repair
team consists of a number of employees, one of whom is designated the team supervisor.
The team are allocated a number of vehicles for use in their work, which are generally
used by the “owning” team only, although are occasionally “borrowed” by other Teams.
Each team is based at a maintenance depot, and in some cases, more than one team may be
based at a single depot”.
 Relation
 Definition: A relation is a named, two-dimensional
table of data
 Table consists of rows (records) and columns
(attribute or field)
 Requirements for a table to qualify as a
relation:
 It must have a unique name
 Every attribute value must be atomic (not multivalued, not
composite)
 Every row must be unique (can’t have two rows with
exactly the same values for all their fields)
 Attributes (columns) in tables must have unique names
 The order of the columns must be irrelevant
 The order of the rows must be irrelevant
 Correspondence with E-R
Model
 Relations (tables) correspond with entity types
and with many-to-many relationship types
 Rows correspond with entity instances and
with many-to-many relationship instances
 Columns correspond with attributes


NOTE: The word relation (in relational
database) is NOT the same as the word
relationship (in E-R model)
 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 identifiers that enable a dependent
relation (on the many side of a relationship) to refer to
its parent relation (on the one side of the relationship)
 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 (Discussed Latter)
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)
 Integrity Constraints
 Domain Constraints
 Allowable values for an attribute. See
Table 5-1
 Entity Integrity
 No primary key attribute may be null.
All primary key fields MUST have data
 Action Assertions
 Business rules.
Domain definitions enforce domain integrity constraints
 Integrity Constraints
 Referential Integrity–rule states that any foreign key
value (on the relation of the many side) MUST match a
primary key value in the relation of the one side. (Or the
foreign key can be null)
 For example: Delete Rules
 Restrict–don’t allow delete of “parent” side if related rows
exist in “dependent” side
 Cascade–automatically delete “dependent” side rows that
correspond with the “parent” side row to be deleted
 Set-to-Null–set the foreign key in the dependent side to null if
deleting from the parent side  not allowed for weak entities
Referential integrity constraints (Pine Valley Furniture)

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

Referential
integrity
constraints are
implemented with
foreign key to
primary key
references
Transforming EER Diagrams
into Relations
Mapping Regular Entities to Relations
1. Simple attributes: E-R attributes map
directly onto the relation
2. Composite attributes: Use only their
simple, component attributes
3. Multivalued Attribute–Becomes a
separate relation with a foreign key
taken from the superior entity
 Mapping a regular entity

(a) CUSTOMER
entity type with
simple
attributes

(b) CUSTOMER relation

 Mapping a composite attribute

(a) CUSTOMER
entity type with
composite
attribute

(b) CUSTOMER relation with address detail

 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

Transforming EER Diagrams
into Relations (cont.)
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
 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
 Example of mapping an M:N relationship
a) Completes relationship (M:N)

The Completes relationship will need to become a separate relation

Example of mapping an M:N relationship (cont.)
b) Three resulting relations

Composite primary key

Foreign key New

Foreign key
intersection
relation
Example of mapping a binary 1:1 relationship
a) In_charge relationship (1:1)

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

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
Transforming EER Diagrams
into Relations (cont.)
Mapping Unary Relationships
 One-to-Many–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
 Mapping a unary 1:N relationship

(a) EMPLOYEE entity with

unary relationship

(b) EMPLOYEE
relation with
recursive foreign
key
Mapping a unary M:N relationship

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

(b) ITEM and

COMPONENT
relations
Transforming EER Diagrams
into Relations (cont.)
Mapping Ternary (and n-ary)
Relationships
 One relation for each entity and
one for the associative entity
 Associative entity has foreign keys

to each entity in the relationship

 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with

associative entity
 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 composite
primary key