Course Outline

● Introduction to Database System

● Data Modeling ERD
● Relational Data Model
● Query Language : SQL
● Normalization
Introduction
DATABASE MANAGEMENT SYSTEM I
What is Data?

● Any fact that can be recorded or stored

● An Information in raw form
● E.g.
● Numbers
● Characters or text
● Images
● Videos
● Speech
● Etc.
What is Database?

● A database is a collection of related data.

● Data – unprocessed information.
● Information – processed data.
● Types of database
● Traditional Database
● Multimedia Database
● Geographic Information System
● Real-time Database
● Data Warehouse
Traditional Database

● The first databases were manual paper-based systems. Usually, paper records
were stored in filing cabinets.
● There were several problems associated with such databases:
● the storage of paper records was very bulky, often requiring several large filing
cabinets
● it was very easy to miss-file a paper record, or for records to be lost or damaged
● data was often duplicated in several records
● keeping records up-to-date was difficult and time consuming, and often resulted in
data inconsistency, where values were updated in one record but not in others
● many people were employed to maintain the records, which was costly
● searching for records was time consuming
● producing reports, such as sorted lists or data collated from several sources, was
extremely time consuming, if not impossible.
What is Database Management System?

● A DBMS is a software system designed to maintain

a database.
● Set of program which can define, construct and
manipulate data.
● We use a DBMS when?
● There is a large amount of data.
● Security and integrity of the data is important.
● Many user access the data concurrently.
Why Use a DBMS?

Access by a collection
● Without a DBMS we’d have : of ad hoc programs
in C++, Java, PHP, etc.
users of
the data

There is no control or
coordination of what
these programs do
data stored as bits on disks
organized as files with the data
Why Use a DBMS?

applications
● With a DBMS we have:

DBMS users of
the data

DBMS provides
control
data stored as bits on disks
organized as files and coordination to
protect the data.
What is Database System?

Database
+
Database Management System
= DATABASE SYSTEM
Database Functionality

Database Management System I

Persistence

● A DBMS provides
persistent objects, types and data structures

● persistent = having a lifetime longer than

the programs that use the data

● any information that fits the data model

of a particular DBMS
can be made persistent with little effort

● data model = concepts that can be used to describe the data

Concurrency

● A DBMS supports access by concurrent users

● concurrent = happening at the same time

● concurrent access, particularly writes (data changes),

can result in inconsistent states
(even when the individual operations are correct)

● the DBMS can check the actual operations of concurrent users,

to prevent activity that will lead to inconsistent states
 Access Control

● A DBMS can restrict access to authorized users

● security policies often require control that is more fine-grained than

that provided by a file system

● since the DBMS understands the data structure, it can enforce fairly
sophisticated and detailed security policies
● on subsets of the data
● on subsets of the available operations
Redundancy Control

● A DBMS can assist in controlling redundancy

● redundancy = multiple copies of the same data

● with file storage, it's often convenient to store multiple copies of the
same data, so that it's "local" to other data and applications

● this can cause many problems:

● wasted disk space
● inconsistencies
● need to enter the data multiple times
Complex Semantics

● A DBMS supports representation

of complex relationships and integrity constraints

● the semantics (meaning) of an application often

includes many relationships and rules
about the relative values of subsets of the data

● these further restrict the possible instances of the database

● relationships and constraints can be defined as part of the schema

Backup and Recovery

● A DBMS can provide backup and recovery

● backup = snapshots of the data particular times

● recovery = restoring the data to a consistent state
after a system crash

● the higher level semantics (relationships and constraints)

can make it difficult to restore a consistent state

● transaction analysis can allow a DBMS to reconstruct a consistent state from

a number of backups
Views and Interfaces

● A DBMS can support

multiple user interfaces and user views

● since the DBMS provides a well-defined data model and a persistent data
dictionary, many different interfaces can be developed to access the same
data

● data independence ensures that these UIs will not be made invalid by most
changes to the data

● new user views can be supported as new schemas defined against the
conceptual schema
Database Functionalities(Summary)

● persistent objects, types and data structures

● control of concurrent users
● controlling of redundancy
● restricting access (security)
● representation of complex relationships
and integrity constraints
● backup and recovery
● multiple user interfaces and user views
 Database Users and Roles
Database Management System I
 DBMS Roles

● Actors On the Scene

(people interested in the actual data):

● database administrators
● database designers
● systems analysts and application programmers
● end users
Actors on the Scene

● Database Administrators

● acquiring a DBMS
● managing the system
● acquiring HW and SW to support the DBMS
● authorizing access (security policies)
● managing staff, including DB designers
 Actors on the Scene(Cont.)

● Database Designers

● identifying the information of interested

in the Universe of Discourse (UoD)
● designing the database conceptual schema
● designing views for particular users
● designing the physical data layout and logical schema
● adjusting data parameters for performance
Actors on the Scene(Cont.)

● Systems Analysts and Application Programmers

(generic database developers)

● provide specialized knowledge to optimize database usage

● provide generic (canned) application programs
Actors on the Scene(Cont.)

● End Users

● casual users: ad-hoc queries

● naïve or parametric users: canned queries such as menus for a phone

company customer service agent

● sophisticated users: people who understand the system and the data and
use it in many novel ways

● standalone users: people who use personal easy-to-use databases for

personal data
DBMS Roles

● Actors Behind the Scene:

people who maintain the environment
but aren't interested in the actual data

● DBMS designers and implementers

● tools developers
● operators and maintenance personnel
● database researchers
Actors Behind the Scene

● DBMS designers and implementers

● work for the company that supplies the DBMS

(i.e. Microsoft , Oracle, Sybase, MySQL …)

● programmers and engineers

● design and implement the DBMS

Actors Behind the Scene(Cont.)

● Tools Developers

● design and implement DBMS add-ons or plug-ins

● may work for DBMS supplier or be independent

● kinds of tools: database design aids, performance monitoring tools, user and
designer interfaces
Actors Behind the Scene(Cont.)

● Operators and maintenance personnel

● run and maintain the computer environment in which a DBMS operates

● probably work for the database administrator (DBA)

Actors Behind the Scene(Cont.)

● Database Researchers

● academic or industrial researchers

● develop new theory, new designs, new data models and new algorithms to
improve future database management systems
DBMS Roles (Summary)
Actors On the Scene
(people interested in the actual data)
● database administrators
● database designers
● systems analysts and application
programmers
● end users
Actors Behind the Scene
people who maintain the
environment but aren't interested in the
actual data
● DBMS designers and implementers
● tools developers
● operators and maintenance personnel
● database researchers
Database Property

Database Management System I

ACID

● ACID (Atomicity, Consistency, Isolation, Durability)

● is a set of properties of database transactions intended to
guarantee validity even in the event of errors, power failures,
etc.
● In the context of databases, a sequence of database
operations that satisfies the ACID properties and, thus, can
be perceived as single logical operation on the data, is called
a transaction.
ACID

● Atomicity - requires that each transaction be "all or nothing”.

● if one part of the transaction fails, then the entire transaction fails, and the database
state is left unchanged.
● An atomic system must guarantee atomicity in each and every situation, including
power failures, errors and crashes.

● Consistency - ensures that any transaction will bring the database from one
valid state to another.
● Any data written to the database must be valid according to all defined rules, including
constraints, cascades, triggers, and any combination thereof.
● this does not guarantee correctness of the transaction in all ways the application
programmer might have wanted (that is the responsibility of application-level code),
but merely that any programming errors cannot result in the violation of any defined
rules.
ACID

● Isolation - property ensures that the concurrent execution of transactions results

in a system state that would be obtained if transactions were executed
sequentially, i.e., one after the other
● Providing isolation is the main goal of concurrency control
● Depending on the concurrency control method (i.e., if it uses strict - as opposed to
relaxed - serializability), the effects of an incomplete transaction might not even be
visible to another transaction.
● Durability - property ensures that once a transaction has been committed, it will
remain so, even in the event of power loss, crashes, or errors.
● for instance, once a group of SQL statements execute, the results need to be stored
permanently (even if the database crashes immediately thereafter).
● To defend against power loss, transactions (or their effects) must be recorded in a non-
volatile memory.
Data Modeling
DATABASE MANAGEMENT SYSTEM I
What is Data Modelling?

● why? to determine structure of database prior to implementation.

● in software engineering is the process of creating a data model for an
information system by applying certain formal techniques.
● a process used to define and analyze data requirements needed to support the
business processes within the scope of corresponding information systems in
organizations.
● 3 levels of data modelling
● Conceptual data model
● Logical data model
● Physical data model
3 Levels of Data Modelling

● The table below compares the different features:

Conceptual Data Model

● Identifies the highest-level relationship between the different

entities. Features of conceptual data model include:
● Important entities and the relationship among them
● No attribute is specified
● No primary key specified
Logical Data Model

● describes the data in as much detail as possible, without regard to how

they will be physical implemented in the database. Features of a logical
data model include:
● Includes all entities and relationships among them.
● All attributes for each entity are specified.
● The primary key for each entity is specified.
● Foreign keys (keys identifying the relationship between different entities) are
specified.
● Normalization occurs at this level.
Logical Data Model

● The steps for designing the logical data model are as follows:
1. Specify primary keys for all entities.
2. Find the relationships between different entities.
3. Find all attributes for each entity.
4. Resolve many-to-many relationships.
5. Normalization.
Logical Data Model

● The figure below is an example of a logical data model.

 Conceptual vs Logical Model

● Comparing the logical data model shown above with the conceptual data model
diagram, we see the main differences between the two:
● In a logical data model, primary keys are present, whereas in a conceptual data
model, no primary key is present.
● In a logical data model, all attributes are specified within an entity. No attributes are
specified in a conceptual data model.
● Relationships between entities are specified using primary keys and foreign keys in a
logical data model. In a conceptual data model, the relationships are simply stated,
not specified, so we simply know that two entities are related, but we do not specify
what attributes are used for this relationship.
Physical Data Model

● Physical data model represents how the model will be built in the database.
● A physical database model shows all table structures, including column name,
column data type, column constraints, primary key, foreign key, and relationships
between tables.
● Features of a physical data model include:
● Specification all tables and columns.
● Foreign keys are used to identify relationships between tables.
● Denormalization may occur based on user requirements.
● Physical considerations may cause the physical data model to be quite different from
the logical data model.
● Physical data model will be different for different RDBMS. For example, data type for a
column may be different between MySQL and SQL Server.
Entity Relationship Model

Database Management System I

ERD(Entity Relationship Model)

An entity relationship model, also called an entity-relationship (ER) diagram

● is based on the notion of real-world entities and relationships among them. While
formulating real-world scenario into the database model, the ER Model creates
entity set, relationship set, general attributes and constraints.

● ER Model is best used for the conceptual design of a database.

Mapping natural language

English grammar structure ER structure

Common Noun Entity type
Proper Noun Entity
Transitive Verb Relationship type
Intransitive Verb Attribute type
Adjective Attribute for entity
Adverb Attribute for relationship
Entity

ER Model is based on −
● Entities and their attributes.
● An entity in an ER Model is a real-world entity having properties called attributes.
Every attribute is defined by its set of values called domain.
● For example, in a school database, a student is considered as an entity.
● Student has various attributes like name, age, class, etc.
Entity Types

● Entity types →boxes

● Weak entity type → double box

EMPLOYEE DEPENDENT

Entity Weak Entity

Entity Types(Cont.)

● Entity types are similar to classes, they describe potential objects (entities) that will appear in the
database.
● Weak entity types describe dependent entities, entities that depend on other entities for identity.

EMPLOYEE DEPENDENT

Entity Weak Entity

Attributes

● Entities are represented by means of their properties, called attributes.

● All attributes have values.
● For example, a student entity may have name, class, and age as
attributes
Attributes

● Types of Attributes
● Simple attribute - Simple attributes are atomic values, which cannot be divided further.
● Composite attribute - Composite attributes are made of more than one simple attribute.
● Derived attribute - Derived attributes are the attributes that do not exist in the physical
database, but their values are derived from other attributes present in the database.
● Single-value attribute − Single-value attributes contain single value.
● Multi-value attribute - Multi-value attributes may contain more than one values.
Sets and Derived Attributes

● Multivalued attributes → double lined oval

● multivalued = set valued
● that there may be more than one value for the attribute.
● Derived attributes → dashed line ovals
● the attribute is computed from other data

Locations NumEmployees

Multivalued Derived
Attribute Attribute
Composite Attributes

● Composite attributes → tree

● composed of other attributes.
● used for a set of related attributes,
when the set is not a conceptual entity
● the composite doesn’t have identity … it doesn’t have a key

Address
City
ZipCode
Street State

Composite
Attribute
Attributes

● These attribute types can come together in a way like −

● simple single-valued attributes
● simple multi-valued attributes
● composite single-valued attributes
● composite multi-valued attributes
Attributes and Keys

● is a property of a given entity

● Attributes →ovals

● Key attributes → underlined name

● Partial key attributes →dotted underlined name

Age SSN Date

Attribute Key Attribute Partial Key

Attribute
Attributes and Keys(Cont.)

● Key attributes must be unique for each entity

● Keys are used to identify particular entities
● Partial keys are only partially unique
● used for weak entity types

Age SSN Date

Attribute Key Attribute Partial Key

Attribute
Entity Types and Attributes

● Attributes are connected to entity types by lines

Name EMPLOYEE Phone

EID
Name

DEPENDENT
Age
Entity Types and Entities

● Entities are instances of

an entity type.
Relationships

● For example, an employee works_at a department, a student enrolls in a course.

Here, Works_at and Enrolls are called relationships.
Relationships

● The association among entities is called a relationship.

● Relationships indicate a meaningful connection
between two entity types
● Relationships may have attributes,
but they cannot have key attributes.
● Identifying relationships connect a weak entity type
to some other entity type
● indicates where the weak entity gets a key
to complete its own partial key
Relationships

● Relationships → diamonds

● Identifying relationship → double diamond

WorksOn DependentOf

Relationship Identifying
Relationship
Relationships

● The association among entities is called a relationship.

● Like entities, a relationship too can have attributes.
● These attributes are called descriptive attributes.
● Degree of Relationship - The number of participating entities in a
relationship defines the degree of the relationship.
● Binary = degree 2
● Ternary = degree 3
● n-ary = degree
Mapping Cardinalities

● Cardinality defines the number of entities in one entity set, which can be
associated with the number of entities of other set via relationship set.
● One-to-one − One entity from entity set A can be associated with at most one entity of
entity set B and vice versa.
Mapping Cardinalities

● One-to-many − One entity from entity set A can be associated with more than
one entities of entity set B however an entity from entity set B, can be associated
with at most one entity.
Mapping Cardinalities

● Many-to-one − More than one entities from entity set A can be associated with at
most one entity of entity set B, however an entity from entity set B can be
associated with more than one entity from entity set A
Mapping Cardinalities

● Many-to-many − One entity from A can be associated with more than one entity
from B and vice versa
Example Schema
Name

DEPENDENT Age
DependentOf

EID
Name EMPLOYEE
Phone

Name
PROJECT
WorksOn Budget

StartDate
Participation and Cardinality

● Participation and cardinality define constraints on relationships

● Participation indicates whether an entity is required to take part in a relationship

● Cardinality ratios and structural constraints place limits on the number of entities
that may participate in a relationship
Participation Constraints

● Total participation → double or thick line

● indicates required participation
● Partial participation → thin line
● indicates optional participation
EMPLOYEE WorksFor DEPARTMENT

Total Participation

EMPLOYEE WorksOn PROJECT

Partial Participation
Participation Constraints

● Arrowheads can be used to indicate an upper bound of 1 for participation

X R Y

X must participate in exactly one R

X R Y

X may participate in at most one R

Cardinality Ratios

● Cardinality ratios specify the maximum number of relationship instances that an

entity may participate in
1 1
EMPLOYEE Manages DEPARTMENT

1:1 ratio
n 1
EMPLOYEE WorksFor DEPARTMENT

n:1 ratio
n m
EMPLOYEE WorksOn PROJECT

n:m ratio
Structural Constraints

● Structural constraints specify the minimum and maximum number of relationship

instances that an entity may participate in

(1,1) (4,n)
EMPLOYEE WorksFor DEPARTMENT

An employee must work for exactly 1 department.

A department must have at least 4 employees.

(0,1) (1,1)
EMPLOYEE Manages DEPARTMENT

An employee may manage at most 1 department.

A department must have exactly 1 manager.
Participation and Cardinality

● There’s generally numerous ways to express relationship constraint.

(0,N) optional participation in any

number of relationships
(0,1) optional participation in at
most one relationship
(1,N) required participation in at
least one relationship

(1,1) required participation in

exactly one relationship
Equivalent Notations

● An employee can manage at most one department.

● A department must have exactly one manager.

(0,1) (1,1)
EMPLOYEE Manages DEPARTMENT

1 1
EMPLOYEE Manages DEPARTMENT

EMPLOYEE Manages DEPARTMENT

Equivalent Notations

● An employee can manage at most one department.

● A department must have exactly one manager.

(1,1) (1,n)
EMPLOYEE WorksFor DEPARTMENT

n 1
EMPLOYEE WorksFor DEPARTMENT

EMPLOYEE WorksFor DEPARTMENT

 Relationship Instances

(1,1) (1,n)
EMPLOYEE WorksFor DEPARTMENT

● Each EMPLOYEE instance is connected to exactly

one WORKS_FOR instance.
● Each DEPARTMENT instance is connected to at least
one WORKS_FOR instance.
Relational Roles

● It is sometimes convenient to name an entity’s role in a relationship.

● particularly useful in recursive relationships
● removes ambiguity in direction of relationship

Supervision
supervisor supervisee

(0,N) (0,1)
EMPLOYEE
Recursive Relationship

Supervision

supervisor supervisee

(0,N) (0,1)
EMPLOYEE
Notation Summary
Sample
Sample Schema
ERD
Sample
Sample Schema
ERD
Sample
Sample Schema
UML
Design an ER schema for the following
enterprise:

Consider a Mail_Order Database in which employee takes order for parts from customers.
The data requirement are summarized as follows:
● The mail order company has employees, each identified by a unique employee number,
first and last name, and a zip code.
● Each customer of the company is identified by a unique customer number, first and last
name, and zip code.
● Each part sold by the company is identified by a unique part number, a part name, price,
and quantity in stock.
● Each order place by a customer is taken by an employee and is given a unique order
number. Each order contains specified quantities of one or more parts. Each order has a
date of receipt as well as expected ship date. The actual ship date is also recorded.