Database Overview

Introduction
• The World is competitive and dynamic where good
and timely decisions are vital
• Accurate, relevant, timely information is the key to
good decision making
• Good decisions require good information derived
from good managed data
• Data management: focuses on proper generation,
storage, and retrieval of data
• Data is managed most efficiently when stored in a
database
 Definitions

Data: stored representations of meaningful objects and
events or

Referred to facts concerning objects and events that
could be recorded and stored on computer media

Structured: numbers, text, dates

Unstructured: images, video, documents

Information: data processed to increase knowledge in
the person using the data
 Definitions of Database

Def 1: Database is an organized collection of
logically related data

Def 2: A database is a shared collection of logically
related data that is stored to meet the requirements of
different users of an organization

Def 3: A database is a self-describing collection of
integrated records

Def 4: A database models a particular real world
system in the computer in the form of data
• Examples of Databases
– Banking: all transactions
– Airlines: reservations, schedules
– Universities: registration, grades
– Sales: customers, products, purchases
– Manufacturing: production, inventory, orders,
supply chain
– Human resources: employee records, salaries, tax
deductions
 Database Management System (DBMS)

• Database Management System (DBMS)

– is a software that enables easy creation, access,
and modification of databases
– for efficient and effective database
management
• Examples:
– Oracle
– DB2 (IBM)
– MS SQL Server
– MS Access
– Ingres
– PostgreSQL
– MySQL
 Database System

– is an integrated system of hardware,

software, people, procedures, and data
– that define and regulate the collection,
storage, management, and use of data
within a database environment
Database System Environment

 Hardware
 Software
- OS
- DBMS
- Applications
 People
 Procedures
 Data

Database Systems: Design, Implementation, & Management: Rob & Coronel

S511 Session 2, IU-SLIS

 Database Personnel
• End users • Database Administrator
– Use the database system to (DBA)
achieve some goal – Designs & manages the
• Application developers database system
– Write software to allow end • Database systems
users to interface with the programmer
database system – Writes the database software
itself
 Advantages of Databases
• The drawbacks of file system can be translated as
advantages of databases
• Drawbacks of using file systems to store data:
– Data redundancy and inconsistency
• Multiple file formats, duplication of information in different
files
– Difficulty in accessing data
• Need to write a new program to carry out each new task
– Data isolation — multiple files and formats
– Integrity problems
• Integrity constraints (e.g. account balance > 0) become part
of program code
• Hard to add new constraints or change existing ones
 Advantages of Databases
• Drawbacks of using file systems (cont.)
– Atomicity of updates
• Failures may leave database in an inconsistent state with partial
updates carried out
• E.g. transfer of funds from one account to another should either
complete or not happen at all
– Concurrent access by multiple users
• Concurrent accessed needed for performance
• Uncontrolled concurrent accesses can lead to inconsistencies
– E.g. two people reading a balance and updating it at the same time

– Security problems
• Database systems offer solutions to all the above
problems
DBS Development Lifecycle
STAGES OF DBS DEVELOPMENT
LIFECYCLE
 Database Planning

 Identifying how the stages can be completed in the most

effective & efficient way.

 During planning phase, four major activities are performed:

 Review and approve the database project request.

 Prioritize the database project request.
 Allocate resources such as money, people and tools.
 Arrange a development team to develop the database project.
 Database Planning

 Database planning should also include the

development of standards that govern how data will
be collected, how the format should be specified,
what necessary documentation will be needed.
 System Definition

 Identify System boundaries at a very high level,

e.g.:
 Current users.
 Current application areas.
Requirements Collection & Analysis

 Collecting and analyzing information about the part of

organization to be supported by the database system, and
using this information to identify users’ requirements of new
system.
Requirements Collection & Analysis
• Business requirements. These include high-level
statements of goals, objectives, and needs.
• Nonfunctional requirements describe the
general characteristics of a system. They are also
known as quality attributes.
• Functional requirements describe how a
product must behave, what its features and
functions.
 Database Design

 Creating a design for a database that will support

the enterprise’s mission statement and mission
objectives for the required database system.

 Main aims:
 To represent data and relationships required
by users and applications.
 To specify a design that meets performance requirements.
 Database Design

 Three main phases of DB design:

 Conceptual Database Design.
• Create a conceptual data model Independent of any implementation details.
 Logical Database Design.
• At this point you know which type of DBMS you will implementing in - e.g.
relational, object-oriented etc (but not the actual DBMS).
 Physical Database Design.
• Derive tables & constraints.
• Identify storage structures and access methods.
• Design security features.
 DBMS Selection

 Selection of an appropriate DBMS to support the

database system.

 Undertaken at any time prior to logical design.

 Main steps for selecting a DBMS:

 Define Terms of Reference of study;
 Shortlist two or three products;
 Evaluate products;
 Recommend selection and produce report.
 Application Design

 Design of user interface and application programs

that use and process the database.

 Database design and application design are

parallel activities.

 Includes two important activities:

 transaction design;
 user interface design.
 Prototyping

 Building working model of a database system to

evaluate how the final system will look and function.

 Purpose:

 to identify features of a system that work well, or are

inadequate;
 to suggest improvements or even new features;
 to clarify the users’ requirements;
 to evaluate feasibility of a particular system design.
 Implementation
• Hardware, DBMS software, and application
programs are installed
• Database is created that include:
– Creation of tables
– Create data entry forms
– Creation of relationships
– Creation of users accounts

Database Systems, 8th Edition

 Data Conversion and Loading

 Transferring any existing data into new database

and converting any existing applications to run on
new database.

 Only required when new database system is

replacing an old system.
 Testing

 Process of running the database system with

intent of finding errors.

 Use carefully planned test strategies and realistic

data.

 Demonstrates that database and application

programs appear to be working according to
requirements.
 Operational Maintenance

 Process of monitoring and maintaining database

system following installation.

 Operational Maintenance Activities:

 Monitoring performance of system.

 Maintaining and upgrading database application.
 Incorporating new requirements into DB application.
 The Entity Relationship Model
• Widely accepted and adapted graphical
tool for data modeling
• Introduced by Chen in 1976
• Graphical representation of entities and
their relationships in a database structure
The Entity Relationship Model
(continued)
• Entity relationship diagram (ERD)
– Uses graphic representations to model
database components
– Entity is mapped to a relational table
 Entity Sets
• An entity is an object that exists and is
distinguishable from other objects.
– Example: specific person, company, event, plant

• Entities have attributes

– Example: people have names and addresses

• An entity set is a set of entities of the

same type that share the same properties.
– Example: set of all persons, companies, trees.
 Entity Sets customer and loan
customer-id customer- customer- customer- loan- amount
name street city number
 Attributes
• An entity is represented by a set of
attributes, that is descriptive properties
possessed by all members of an entity
set.
Example:
customer = (customer-id, customer-name,
customer-street, customer-city)
loan = (loan-number, amount)
 Attributes
• Domain – the set of permitted values for
each attribute
• Attribute types:
– Simple and composite attributes.
– Single-valued and multi-valued attributes
• E.g. multivalued attribute: phone-numbers
– Derived attributes
• Can be computed from other attributes
• E.g. age, given date of birth
Composite Attributes
Relationship Set borrower
 Relationship Sets (Cont.)
• An attribute can also be property of a relationship set.
• For instance, the depositor relationship set between entity sets
customer and account may have the attribute access-date
 Degree of a Relationship Set

• Refers to number of entity sets that participate in a

relationship set.
• Relationship sets that involve two entity sets are binary
(or degree two). Generally, most relationship sets in a
database system are binary.
• Relationship sets may involve more than two entity
sets.
E.g. Suppose employees of a bank may have jobs
(responsibilities) at multiple branches, with different jobs at
different branches. Then there is a ternary relationship set
between entity sets employee, job and branch

• Relationships between more than two entity sets are

rare. Most relationships are binary.
 Mapping Cardinalities
• Express the number of entities to which another
entity can be associated via a relationship set.
• Most useful in describing binary relationship sets.
• For a binary relationship set the mapping cardinality
must be one of the following types:
– One to one
– One to many
– Many to one
– Many to many
 Mapping Cardinalities

One to one One to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
 Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
 E-R Diagrams

 Rectangles represent entity sets.

 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to relationship sets.
 Ellipses represent attributes
 Double ellipses represent multivalued attributes.
 Dashed ellipses denote derived attributes.
 Underline indicates primary key attributes (will study later)
E-R Diagram With Composite, Multivalued, and Derived
Attributes
Relationship Sets with Attributes
 Roles
• Entity sets of a relationship need not be
distinct
• The labels “manager” and “worker” are called roles; they specify how
employee entities interact via the works-for relationship set.
• Roles are indicated in E-R diagrams by labeling the lines that connect
diamonds to rectangles.
• Role labels are optional, and are used to clarify semantics of the
relationship
 Cardinality Constraints
• We express cardinality constraints by drawing either a directed
line (), signifying “one,” or an undirected line (—), signifying
“many,” between the relationship set and the entity set.
• E.g.: One-to-one relationship:
– A customer is associated with at most one loan via the
relationship borrower
– A loan is associated with at most one customer via borrower
 One-To-Many Relationship
• In the one-to-many relationship a loan is
associated with at most one customer
via borrower, a customer is associated
with several (including 0) loans via
borrower
 Many-To-One Relationships
• In a many-to-one relationship a loan is
associated with several (including 0)
customers via borrower, a customer is
associated with at most one loan via
borrower
Many-To-Many Relationship

• A customer is associated with

several (possibly 0) loans via
borrower
• A loan is associated with several
(possibly 0) customers via borrower
 Participation of an Entity Set in a Relationship
Set
 Total participation (indicated by double line): every entity in the entity
set participates in at least one relationship in the relationship set
 E.g. participation of loan in borrower is total
 every loan must have a customer associated to it via borrower
 Partial participation: some entities may not participate in any
relationship in the relationship set
 E.g. participation of customer in borrower is partial
 Alternative Notation for
Cardinality Limits
 Cardinality limits can also express participation constraints
 Keys
• A super key of an entity set is a set of one or
more attributes whose values uniquely
determine each entity.
• A candidate key of an entity set is a minimal
super key
– Customer-id is candidate key of customer
– account-number is candidate key of account.
– Although several candidate keys may exist, one
of the candidate keys is selected to be the
primary key.
E-R Diagram with a Ternary
Relationship
 Weak Entity Sets
• We depict a weak entity set by double
rectangles.
• We underline the discriminator of a
weak entity set with a dashed line.
• payment-number – discriminator of the
payment entity set
E-R Diagram for a Banking
Enterprise
Summary of Symbols Used in
E-R Notation
Summary of Symbols (Cont.)
Alternative E-R Notations
 Composite and Multivalued Attributes
 Composite attributes are flattened out by creating a separate
attribute for each component attribute
 E.g. given entity set customer with composite attribute name with
component attributes first-name and last-name the table corresponding
to the entity set has two attributes
name.first-name and name.last-name
 A multivalued attribute M of an entity E is represented by a separate
table EM
 Table EM has attributes corresponding to the primary key of E and an
attribute corresponding to multivalued attribute M
 E.g. Multivalued attribute dependent-names of employee is represented
by a table
employee-dependent-names( employee-id, dname)
 Each value of the multivalued attribute maps to a separate row of the
table EM
 E.g., an employee entity with primary key John and
dependents Johnson and Johndotir maps to two rows:
(John, Johnson) and (John, Johndotir)
 Representing Weak Entity Sets
 A weak entity set becomes a table that includes a column for
the primary key of the identifying strong entity set
 Representing Relationship Sets as
Tables
 Create a third table consisting of the attribute of the relationship
and the primary keys of the two Tables.
 one-to-many relationship sets

 Many-to-one and one-to-many relationship sets that are total

on the many-side can be represented by adding an extra
attribute to the many side, containing the primary key of the
one side
 E.g.: Instead of creating a table for relationship account-
branch, add an attribute branch to the entity set account
 Resolving many to many relationship
The key to resolve m:n relationships is to separate
the two entities and create two one-to-many (1:n)
relationships between them with a third intersect
entity. The intersect entity usually contains attributes
specifically the primary keys from both connecting
entities