Database Overview

1
 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

2
 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

3
 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 6
 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 8

 Database Personnel
• End users
– Use the database system to
achieve some goal
• Application developers
– Write software to allow end
users to interface with the
database system
• Database Administrator
(DBA)
– Designs & manages the
database system
• Database systems
programmer
– Writes the database software
itself
 Database Management Systems
• A database is a collection of • Examples:
information – Oracle
• A database management – DB2 (IBM)
system (DBMS) is the – MS SQL Server
software than controls that – MS Access
information – Ingres
– PostgreSQL
– MySQL
Advantages of databases
versus file systems

11
 Disadvantages of File system
• Data redundancy: Data redundancy refers to the duplication
of data, lets say we are managing the data of a college
where a student is enrolled for two courses, the same
student details in such case will be stored twice, which will
take more storage than needed. Data redundancy often
leads to higher storage costs and poor access time.
• Data inconsistency: Data redundancy leads to data
inconsistency, lets take the same example that we have
taken above, a student is enrolled for two courses and we
have student address stored twice, now lets say student
requests to change his address, if the address is changed at
one place and not on all the records then this can lead to
data inconsistency.
• Data Isolation: Because data are scattered in various files,
and files may be in different formats, writing new application
programs to retrieve the appropriate data is difficult.
 Disadvantages of File system
• Dependency on application programs: Changing files would lead
to change in application programs.
• Atomicity issues: Atomicity of a transaction refers to “All or
nothing”, which means either all the operations in a transaction
executes or none. For example: Lets say Steve transfers 100$ to
Negan’s account. This transaction consists multiple operations
such as debit 100$ from Steve’s account, credit 100$ to Negan’s
account. Like any other device, a computer system can fail lets
say it fails after first operation then in that case Steve’s account
would have been debited by 100$ but the amount was not
credited to Negan’s account, in such case the rollback of
operation should occur to maintain the atomicity of transaction.
It is difficult to achieve atomicity in file processing systems.
• Data Security: Data should be secured from unauthorised access,
for example a student in a college should not be able to see the
payroll details of the teachers, such kind of security constraints
are difficult to apply in file processing systems.
 Advantage of DBMS over file system
• There are several advantages of Database management
system over file system. Few of them are as follows:
• No redundant data: Redundancy removed by data
normalization. No data duplication saves storage and
improves access time.
• Data Consistency and Integrity: The root cause of data
inconsistency is data redundancy, since data normalization
takes care of the data redundancy, data inconsistency also
been taken care of as part of it
• Data Security: It is easier to apply access constraints in
database systems so that only authorized user is able to
access the data. Each user has a different set of access thus
data is secured from the issues such as identity theft, data
leaks and misuse of data.
 Advantage of DBMS over file system

• Privacy: Limited access means privacy of data.

• Easy access to data – Database systems
manages data in such a way so that the data is
easily accessible with fast response times.
• Easy recovery: Since database systems keeps
the backup of data, it is easier to do a full
recovery of data in case of a failure.
• Flexible: Database systems are more flexible
than file processing systems.
DBS Development Lifecycle

16
STAGES OF DBS DEVELOPMENT
LIFECYCLE

17
 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.

18
 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.

19
 System Definition

 Identify System boundaries at a very high level, e.g.:

 Current users.
 Current application areas.

20
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.

21
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.

23
 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.

24
 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.

25
 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.

26
 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.

27
 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 28

 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.

29
 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.

30
 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.

31
 Data models
– It is relatively simple representations, usually
graphical, of complex real-world data
structures
– Facilitate interaction among the designer, the
applications programmer, and the end user

32
 Rationales for Data Modeling
• Data is the foundation of modern information
systems enabled by data base technologies.
• Data in an organization exist and can be described
independently of how these data are used.
• Data should be managed as a corporate-wide
resource.
• The types of data used in an organization do not
change very much.
• Data have certain inherent properties which lead to
correct structuring.
Data Model Basic Building Blocks
• Entity - anything about which data are to be
collected and stored
• Attribute - a characteristic of an entity
• Relationship - describes an association among
entities
– One-to-many (1:M) relationship
– Many-to-many (M:N or M:M) relationship
– One-to-one (1:1) relationship
• Constraint - a restriction placed on the data

34
 Rules
• Brief, precise, and unambiguous
descriptions of a policies, procedures, or
principles within a specific organization
• Apply to any organization that stores and
uses data to generate information
• Description of operations that help to
create and enforce actions within that
organization’s environment

35
 Rules (continued)
• Must be rendered in writing
• Must be kept up to date
• Must be easy to understand
• Describe characteristics of the data as
viewed by the company

36
 The Evolution of Data Models
(continued)
• Hierarchical
• Network
• Relational
• Entity relationship
• Object oriented (OO)

37
 The Hierarchical Model
• Developed in the 1960s to manage large
amounts of data for complex
manufacturing projects
• Basic logical structure is represented by
an upside-down “tree”

38
The Hierarchical Model
(continued)

39
 The Hierarchical Model
(continued)
• The hierarchical structure contains levels,
or segments
• Depicts a set of one-to-many (1:M)
relationships between a parent and its
children segments
– Each parent can have many children
– each child has only one parent

40
 The Hierarchical Model
(continued)
• Advantages
– Many of the hierarchical data model’s features
formed the foundation for current data models

41
 The Hierarchical Model
(continued)
• Disadvantages
– Complex to implement
– Difficult to manage

42
 The Network Model

• Created to
– Represent complex data relationships
more effectively
– Improve database performance

43
The Network Model (continued)

• Network model has the entities which

are organized in a graphical
representation and some entities in the
graph can be accessed through several
paths
• It allows many to many relationship

44
 The Network Model
(continued)
• Disadvantages
– Too cumbersome
– Any structural change in the database
could produce havoc in all application
programs that drew data from the database

45
A Network Data Model

Questions:
1. Give examples of a child with many parents
2. List the children for each parents
 Object Model

• Object:
– observable entity in the world being modeled
– similar to concept to entity in the E/R model
• An object consists of:
– attributes: properties built in from primitive types
– relationships: properties whose type is a reference to some other object
or a collection of references
– methods: functions that may be applied to the object.
 Class

• Similar objects with the same set of properties and describing

similar real-world concepts are collected into a class.
• A class can be declared to be a subclass of another class.
• Subclasses inherit all the properties
– attributes
– relationships
– methods
from the superclass.
 Class Hierarchy

person

employee student

student grad undergrad

staff faculty assistant

QSTN: LIST THE ATTRIBUTES OF PERSON, STUDENT AND UNDERGRADUATE AND SHOW THE
CONCEPTS OF INHERITANCE
 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

50
The Entity Relationship Model
(continued)
• Entity relationship diagram (ERD)
– Uses graphic representations to model
database components
– Entity is mapped to a relational table

51
 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

55
Composite Attributes
 Relationship Sets
• A relationship is an association among
several entities
Example:
Hayes depositor A-102
customer entityrelationship set
account entity
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.

• Relationships between more than two entity sets are rare. Most relationships are
binary.
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
 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
 A many-to-many relationship set is represented as a table with
columns for the primary keys of the two participating entity sets, and
any descriptive attributes of the relationship set.
 E.g.: table for relationship set borrower
 Many-to-one and 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