DBMS All

Definition: Database Management Systems
• In general database is integrated collection of data in form of

table. It collects data of various organizations and interrelated to
each other having different meanings and results. A collection of
data stored in standard format makes easier to share, process,
add and design database. Different users can access same data
through a standard database.
• Thus, database is also defined as a collection of inter-related
relevant data stored together to serve multiple users through
multiple applications according to their requirements. A database
may have a single table or multiple tables with certain
relationship to each other. The individual fact arranged in table is
a cell where vertical collection of such cells is known as column
and horizontal is row. A database may represent real world in the
form of MINIWORLD or Universe of discourse.
Advantages of Database Management Systems
As per the development of software, hardware and
market demand, new concept of data handling was
considered about in 1960’s, Initially the following points
consider as advantages as:
Data independence; easy for application development; better
integrity and security; data management and administration,
concurrent access; cash recovery and queries; enforcement of
standard.
For detail application of DBMS following components are used.
*Solution of data redundancy
* Minimization of inconsistency problem
* Reduction of programming effort
* Better concept of data independence
* Evolution of concurrent access
* Different implementation concept of security
* Economic behavior of system
* Enforcement of standard
Drawbacks of Traditional File Based System
•Uncontrolled data duplication and redundancies
•wastes of space
•hard to update all files
•Inconsistent data
•Inflexibility
•Hard to change data
•Hard to change programs
•Limited data sharing
•Poor enforcement of standard
•Poor programmer productivity
•Excessive program maintenance
Review of RDBMS
Database Management System (DBMS)

 Collection of interrelated data
 Set of programs to access the data
 DBMS contains information about a particular enterprise
 DBMS provides an environment that is both convenient
and efficient to use.
 Database Applications:
 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
 Databases touch all aspects of our lives
Purpose of Database System
In the early days, database applications were built on top of
file systems
 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
Purpose of Database Systems (Cont.)
 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
Data Model Basic Building Blocks
 Entity
 Anything about which data will be collected/stored
 Attribute
 Characteristic of an entity
 Relationship
 Describes an association among entities
 One-to-one (1:1) relationship
 One-to-many (1:M) relationship
 Many-to-many (M:N or M:M) relationship
 Constraint
 A restriction placed on the data
Lecture : 2
Business Rules 9th June, 2010
 Brief, precise and unambiguous descriptions of

policies, procedures or principles within the
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
 Must be put in writing
 Must be kept up to date
 Sometimes external to the organization
 Must be easy to understand and widely
disseminated
 Describe characteristics of the data as viewed
by the company
Discovering Business Rules
 Company managers
 Policy makers
 Department managers
 Written documentation
 Procedures
 Standards
 Operations manuals
 Direct interviews with end users
Translating Business Rules to Data Model Components
 Standardize company’s view of data

 Communication tool between users and designers
 Allow designer to understand the nature, role and
scope of data
 Allow designer to understand business processes
 Allow designer to develop appropriate relationship
participation rules and constraints
 Promote creation of an accurate data model
 Nouns translate into entities
 Verbs translate into relationships among entities
 Relationships are bi-directional
The Evolution of Data Models
We will look briefly at each Model Type

The Hierarchical Model
 Developed in 1960s to manage large amounts of data for

complex manufacturing projects
 Logical structure represented as an upside-down “tree”
 Hierarchical structure contains levels or segments
 Depicts a set of one-to-many (1:M) relationships
 Between a parent and it’s children segments
 Each parent can have many children
 each child has only one parent
Hierarchical Model
 Advantages
 Many features form the foundation for current data
models
 Generated a large installed base of programmers
 Who developed solid business applications
 Disadvantages
 Complex to implement
 Difficult to manage
 Lacks structural independence
 Implementation limitations
 Lack of standards (Company vs Industry or Open)
The Network Model
 Resembles hierarchical model

 Difference child can have multiple parents
 Collection of records in 1:M relationships
 Set – Relationship of at least two record types
 Owner – Equivalent to the hierarchical model’s parent
 Member – Equivalent to the hierarchical model’s child
Network Model Terms
 Schema
 Conceptual organization of entire database
 As viewed by the database administrator
 Subschema
 Defines database as “seen” by the application programs
 Schema Data Definition Language (DDL)
 Enables database administrator to define schema components
 Subschema Data Definition Language (DDL)
 Allows applications to define database components to be used
 Data Management Language (DML)
 Defines the environment in which data can be managed
 Works with the data in the database
Network Model
 Advantages
 Represents complex data relationships better than
Hierarchical Model
 Improved database performance
 Impose a database “industry” standard
 Conference on Data Systems Languages (CODASYL)
 Database Task Group (DBTG)
 Disadvantages
 Too cumbersome
 Lack of “ad hoc” query capability
 Put heavy pressure on programmers
 Any structural change in the database could produce havoc
in all application programs that drew data from the database
The Relational Model
 Conceptually simple – Linked Tables

 Developed by Edgar F. Codd (IBM 1970 )
 Considered ingenious but impractical in 1970
 Computers lacked power to implement the relational model
 Today’s PCs run sophisticated relational databases
Relational Model – Tables
 Also called relations

 Matrix of row and column intersections
 Stores a collection of similar entities
 Resembles a file or spreadsheet
 Purely logical structure
 How data are physically stored is of no concern to
the user or the designer
 The source of a real database revolution
Relational Model – Relational Diagram
 Representation of
relational database’s
 Entities (Tables)
 Attributes within those
entities (Fields)
 Relationships between
those entities (Links)
Relational Model – RDBMS
 Relational Database Management System

 All the system components
 User interface
 Tables
 Method of querying the tables
 Performs same basic functions as

 Hierarchical and
 Network DBMS models
 Plus many other functions
 Most important –hides the complexities of the
relational model from the user
The Relational Model – SQL
 Structured Query Language (SQL)
 Allows ad hoc queries – questions of the data
 User can specify what must be done without
specifying how it must be done
 Dominance due in great part to its powerful
and flexible query language
 SQL-based relational database application:
 User interface
 A set of tables stored in the database
 SQL engine
Entity Relationship Model (ERM)
 Introduced by Peter Chen in 1976

 Widely accepted and adapted graphical tool for
data modeling
 Graphical representation of entities and their
relationships in a database structure
Entity Relationship Model – Terms
 Entity Relationship Diagram (ERD)

 Graphic representations to model database components
 Entity is mapped to a relational table
 Entity instance (or occurrence) – A row in table
 Entity set (table) – Collection of like entities
 Connectivity labels
 Diamond connected to related entities through a relationship line
 Types of relationships
ERM Notation Symbols
 Three symbols to represent element relationships

 Ring represents "zero"
 Dash represents "one"
 Crow's foot represents "more" or "many"
 Used in pairs to represent the four types of
relationships
 Ring and dash → zero or one
 Dash and dash → exactly one
 Ring and crow's foot → zero or more
 Dash and crow's foot → one or more
The Object Oriented (OO) Model
 Models both data and their relationships in a single

structure known as an object
 Object described by its factual content
 Like relational model’s entity
 Includes info about relationships between facts within
object and relationships with other objects
 Unlike relational model’s entity
Object Oriented Model – Terms
 Object-oriented data model (OODM)
 Semantic data model
 Basis of object-oriented database management system
(OODBMS)
 Evolved to allow an object to also contain all operations
 Object – abstraction of a real-world entity
 Basic building block for autonomous structures
 Attributes – properties of an object
 Class - objects that share similar
 Classes are organized in a class hierarchy
 Inheritance – an object within the class hierarchy
inherits the attributes and methods of class
Extended Relational Data Model (ERDM)
 Semantic data model

 Developed in response to increasing
complexity of applications
 Based heavily on relational model
 Relational DB response to OODM
 Primarily geared to business applications
 Typically scientific or engineering apps
 Object/relational database management
system (O/RDBMS)
 DBMS based on the ERDM
Object Role Modeling (ORM)
ORM
 Not to be confused with Object-relational mapping
 Provides a conceptual approach to modeling
 Models the application area or universe of discourse (UoD)
 Relevant set of entities that are being dealt with by quantifiers
 Requires a good understanding of the UoD
 Means of specifying this understanding in a clear, unambiguous
way
 Simplifies design process with natural language and intuitive
diagrams
 Can be populated with examples
 Evolved from the Natural language Information Analysis Method
 Mid-1970s
 G. M. Nijssen and Dr. Terry Halpin first joint papers in 1989
 Capable of capturing many business rules typically unsupported
in other popular data modeling notations
 Software tool support include Microsoft Visio for Enterprise
Architects, CaseTalk, Infagon and NORMA
Database Models and the Internet
 Internet drastically changed role and
scope of database market
 Growing need to manage unstructured
information
 The data found in today’s:
 Online documents
 Web pages
 Most modern DBMS incorporate
Internet-age technologies such as
Extended Markup Language (XML)
support
Data Models: Summary
 Each new data model capitalized on the
shortcomings of previous models
 Common characteristics:
 Conceptual simplicity without compromising the
semantic completeness of the database
 Represent the real world as closely as possible
 Representation of real-world transformations
(behavior) must comply with consistency and
integrity characteristics of any data model
Data Models: Summary
Lecture : 3
13th June, 2010
Levels of Abstraction
 Physical level describes how a record (e.g.,
customer) is stored.
 Logical level: describes data stored in database, and
the relationships among the data.
type customer = record
name : string;
street : string;
city : integer;
end;
 View level: application programs hide details of data
types. Views can also hide information (e.g., salary)
for security purposes.
View of Data
An architecture for a database system
Instances and Schemas
 Similar to types and variables in programming languages
 Schema – the logical structure of the database
 e.g., the database consists of information about a set of customers and
accounts and the relationship between them)
 Analogous to type information of a variable in a program
 Physical schema: database design at the physical level
 Logical schema: database design at the logical level
 Instance – the actual content of the database at a particular point in
time
 Analogous to the value of a variable
 Physical Data Independence – the ability to modify the physical
schema without changing the logical schema
 Applications depend on the logical schema
 In general, the interfaces between the various levels and components
should be well defined so that changes in some parts do not seriously
influence others.
Data Models
 A collection of tools for describing
 data
 data relationships
 data semantics
 data constraints
 Entity-Relationship model
 Relational model
 Other models:
 object-oriented model
 semi-structured data models

Older models: network model and hierarchical
model
Entity-Relationship Model
Example of schema in the entity-relationship model

Entity Relationship Model (Cont.)
 E-R model of real world

 Entities (objects)
 E.g. customers, accounts, bank branch
 Relationships between entities
 E.g. Account A-101 is held by customer Johnson
 Relationship set depositor associates customers with
accounts
 Widely used for database design
 Database design in E-R model usually converted to
design in the relational model (coming up next)
which is used for storage and processing
Relational Model Attributes
 Example of tabular data in the relational model
customer- customer- customer- account-

Customer
name street city number
-id
192-83-7465 Johnson
Alma Palo Alto A-101
019-28-3746 Smith
North Rye A-215
192-83-7465 Johnson
Alma Palo Alto A-201
321-12-3123 Jones
Main Harrison A-217
019-28-3746 Smith
North Rye A-201
A Sample Relational Database
SQL
 SQL: widely used non-procedural language
 E.g. find the name of the customer with customer-id 192-83-7465
select customer.customer-name
from customer
where customer.customer-id = ‘192-83-7465’
 E.g. find the balances of all accounts held by the customer with
customer-id 192-83-7465
select account.balance
from depositor, account
where depositor.customer-id = ‘192-83-7465’ and
depositor.account-number = account.account-
number
 Application programs generally access databases through one
of
 Language extensions to allow embedded SQL
 Application program interface (e.g. ODBC/JDBC) which allow SQL
queries to be sent to a database
Lecture : 4th
23 June 2010
Main goals
By the end of class you will have clear

concept about
1. Data independence.
2. DBMS architecture and explain what it
is designed to achieve.
3. Data Catalog and its role
4. Type of users
Data Independence
The goal of the 3-level architecture is to achieve data
independence:
Physical data independence:
• Ability to modify storage details (eg to improve
performance as amount of data grows) without
having to modify application programs.
Logical data independence:
• Ability to modify logical model without having to
modify application programs.
• Logical independence implies that changes in one
external view should not affect other external
views.
• Data independence allows systems to grow.
The ANSI-SPARC 3-level Architecture
pe n de n c e:
y s ic al i nde
ViewP1h View n g2s . . . . View n
n i se th i
Re -or ga
here… SQL … . w it h o
ut affec
anythin t in g
g
here.
Logical Level
Internal Level
View 1 View 2 . . . . View n
SQL … . w it h o
ut affec
anythin t in g
g
here.
Logical Level
Logical ind
Re-organi ependence
Internal Level se things :
here…
View 1 View 2 . . . . View n
SQL Logical ind

ependence
Re-organi :
se things
here…
Logical Level
Internal Level … . w it h o
ut affec
anythin t in g
g
here.
Data Independence: what’s the secret?
 Data Management that achieves data

independence uses..
A Data Catalog
Data Catalog
 Data catalog holds metadata (data about
data)
 DBMS uses metadata to ‘translate’
descriptions at one level to descriptions at the
next level.
 Catalog exist in different forms as System
caalog,
 Metadata:
 Names of tables
 Names of columns and their data types
 Names of indexes
 Names of files
 Names of views
 How these all relate to one another.
Analogy: Independence
 In your phone a Phone Number of Raju
Mishra has been stored as:
 Raju Mishra – 9841486419
 We can call Raju by selecting ‘Raju’ in
list of names.
 Now, Raju changed his cell number;
obviously you updated his phone number:

 Here, You can still call him by selecting
‘Raju’ in your list of names.

Use of Catalog
 Catalog holds name of a table ’Customer’ and
column names:
 cust_id, name, address, tel_no
 with datatypes
 char(4), char(30), char(60), char(15)
 and info. that Customer has an index called
cust_PK_idx, indexed on cust_id
 and info. that Customer records are stored in
file ‘CUST_PD’ which starts at address (44,3)
on disk D1.
DBMS use of catalog
Customer (cust_id char(4), name char(30), address
char(60), tel_no char(15))..
..has index ‘cust_PK_idx’ on cust_id..
..and is stored in ‘CUST_PD’ at address 44 on D1.
 Given query:
SELECT name FROM Customer
WHERE cust_id = ‘A112’
 DBMS will use cust_PK_idx to find the record with cust_id
= ‘A112’ and return bits 33-272 as the name required.
 This work is carried out by the ‘run time processor’
Data Independence
 Lots of things can change:
 The name or location of the file holding Customer
records
 The index can be removed or replaced
 The data types of the columns in Customer can be
changed (eg address becomes variable length)
 New columns can be added to ‘Customer’
SELECT name FROM Customer

WHERE cust_id = ‘A112’
 ..will still produce the same results
Database Languages
 A true 3-level DBMS would provide several
languages:
 Data Definition Language (DDL) to describe tables
etc at the logical (conceptual) level;
 Data Manipulation Language to allow data to be
inserted, updated etc.
 Storage Definition Language (SDL) to specify files,
indexes etc at the internal level.
 View Definition Language (VDL) to specify views at
the external level.
 SQL DOES ALL THIS.
 Data independence is not fully achieved.
Data Definition Language (DDL)
 Specification notation for defining the database schema
 E.g.
create table account (
account-number char(10),
balance integer)
 DDL compiler generates a set of tables stored in a data
dictionary
 Data dictionary contains metadata (i.e., data about
data)
 database schema
 Data storage and definition language
 language in which the storage structure and access methods used
by the database system are specified
 Usually an extension of the data definition language
Data Manipulation Language (DML)
 Language for accessing and manipulating
the data organized by the appropriate data
model
 DML also known as query language
 Two classes of languages
 Procedural – user specifies what data is
required and how to get those data
 Nonprocedural – user specifies what data is
required without specifying how to get those
data
 SQL is the most widely used query
language
Simplified DBMS Architecture
Schema Interactive DML
modification Queries statements
DDL Query DML

compiler processor Compiler
Runtime Database Processor
Transaction
Manager
Storage Manager
Database
& Catalog
Other requirements of a DBMS
 Concurrency control, backup and recovery
handled by a “transaction manager”;
 Security/privacy handled by a security
manager
 Query compiler/optimiser provides fast,
consistent performance.
 The catalog provides additional help:
 Ownership and read/write permissions;
 Integrity constraints
 Statistics on data volumes and frequencies of
access
Database Users
Users are differentiated by the way they expect to interact
with the system
 Application programmers – interact with system through
DML calls
 Sophisticated users – form requests in a database query
language
 Specialized users – write specialized database applications
that do not fit into the traditional data processing

framework
 Naïve users – invoke one of the permanent application
programs that have been written previously

 E.g. people accessing database over the web, bank tellers, clerical
staff
Database Administrator
 Coordinates all the activities of the database
system; the database administrator has a good
understanding of the enterprise’s information
resources and needs.
 Database administrator's duties include:
 Schema definition
 Storage structure and access method definition
 Schema and physical organization modification
 Granting user authority to access the database
 Specifying integrity constraints
 Acting as liaison with users
 Monitoring performance and responding to changes in
requirements
Transaction Management
 A transaction is a collection of operations that
performs a single logical function in a database
application
 Transaction-management component ensures
that the database remains in a consistent
(correct) state despite system failures (e.g.,
power failures and operating system crashes)
and transaction failures.
 Concurrency-control manager controls the
interaction among the concurrent transactions,
to ensure the consistency of the database.
Storage Management
 Storage manager is a program module that
provides the interface between the low-level
data stored in the database and the application
programs and queries submitted to the system.
 The storage manager is responsible to the
following tasks:
 interaction with the file manager
 efficient storing, retrieving and updating of data
Overall System Structure
Application Architectures
Two-tier architecture: E.g. client programs using

ODBC/JDBC to
communicate with a database
Three-tier architecture: E.g. web-based applications, and
applications built using “middleware”

Degrees of Data Abstraction
 Way of classifying data models
 Many processes begin at high level of
abstraction
 Proceed to an ever-increasing level of
detail
 Designing a usable database follows the
same basic process
Degrees of Data Abstraction
 American National
Standards Institute (ANSI)
 Standards Planning and
Requirements Committee
(SPARC)
 Developed standards 1970
 Framework for data
modeling based on degrees
of data abstraction:
 External
 Conceptual
 Internal
 Physical
The External Model
 Each end users’ view of the data environment

 Modeler subdivides requirements and constraints into
functional (Business unit’s) modules
 These can be examined within the framework of their
external models
External Model – Advantages
 Easy to identify specific data required to
support each business unit’s operations
 Facilitates designer’s job by providing
feedback about the model’s adequacy
 Creation of external models helps to identify
and ensure security constraints in the
database design
 Simplifies application program development
The Conceptual Model (1 of 2)
 Global view of the entire database

 Representation of data as viewed by the entire
organization
 Basis for identification and high-level description of
main data objects, avoiding details
The Conceptual Model (2 of 2)
 Software and hardware independent

 Independent of DBMS software
 Independent of hardware to be used
 Changes in either hardware or DBMS
software have no effect on the database
design at the conceptual level
 Most widely used conceptual model
is the Entity Relationship (ER) model
 Provides a relatively easily understood
macro level view of data environment
The Internal Model
 The database as “seen” by the DBMS

 Maps the conceptual model to the DBMS
 Depicts a specific representation of an internal model
 Logical independence
 Can change the internal model without affecting the conceptual model
The Physical Model
 Lowest level of abstraction
 Describes the way data are saved on
storage media such as disks or tapes
 Software and hardware dependent
 Requires database designers to have
a detailed knowledge of the hardware
and software used to implement
database design
 Physical independence
 Can change the physical model
without affecting the internal model
Degrees of Data Abstraction - Summary
Very Short
 DBMSs provide for data independence to help
the sharing of data;
 Sharing data presents greater demands in terms
of security, privacy, efficiency, integrity and
recovery;
 The DBMS Catalog plays a central role in
supporting many of these requirements.
 In a relational database the catalog is managed
by the ‘normal’ DBMS data management routines.
Self Evaluation
 Backup/recovery, security and integrity are all more
critical issues for databases than for files – do you
agree?
 What sort of changes might be needed at the
internal level during the lifetime of a database?
 Why is it so important to allow data to be shared by
applications?
 What costs are involved with data sharing in terms of
the complexity of DBMS software?
Lecture : 5
History of Relational Model 28th June, 2010
 1970 Paper by E.F. Codd “A Relational Model of Data

for Large Shared Data Banks” proposed relational
model
 System R, prototype developed at IBM Research Lab at
San Jose, California – late 1970s
 Peterlee Test Vehicle, IBM UK Scientific Lab
 INGRES, University of California at Berkeley
 System R results used in developing DB2 from IBM
and also Oracle
 Early microcomputer based DBMSs were relational -
dBase, R;base, Paradox
 Microsoft’s Access, now most popular microcomputer-
based DBMS, is relational
 Oracle, DB2, Informix, Sybase, Microsoft’s SQL
Server, MySQL - most popular enterprise DBMSs, all
relational
Advantages of Relational Model
 Based on mathematical notion of relation
 Can use power of mathematical abstraction
 Can develop body of results using theorem and proof
method of mathematics – results then apply to many
different applications
 Can use expressive, exact mathematical notation
 Theory provides tools for improving design
 Basic structure is simple, easy to understand
 Separates logical from physical level
 Data operations easy to express, using a few
powerful commands
 Operations do not require user to know storage
structures used
Data Structures
 Relations are represented physically as tables
 Tables are related to one another
 Table holds information about objects
 Rows (tuples) correspond to individual
records
 Columns correspond to attributes
 A column contains values from one domain
 Domains consist of atomic values
Properties of Tables
 Each cell contains at most one value
 Each column has a distinct name, the
name of the attribute it represents

 Values in a column all come from the
same domain
 Each tuple is distinct – no duplicate
tuples
 Order of tuples is immaterial
Example of Relational Model
 Student table tells facts about students
 Faculty table shows facts about faculty
 Class table shows facts about classes,
including what faculty member teaches

each
 Enroll table relates students to classes
Simple University Database
Class
Student
classNumber facId schedule room
stuId lastName firstName major credits
ART103A F101 MWF9 H221
S1001 Smith Tom History 90
CSC201A F105 TuThF10 M110
S1002 Chin Ann Math 36
CSC203A F105 MThF12 M110
S1005 Lee Perry History 3
HST205A F115 MWF11 H221
S1010 Burns Edward Art 63
MTH101B F110 MTuTh9 H225
S1013 McCarthy Owen Math 0
S1015 Jones Mary Math 42 MTH103C F110 MWF11 H225
S1020 Rivera Jane CSC 15 Figure 4.1(c) The Class Table
Figure 4.1(a) The Student Table
Enroll
Faculty stuId classNumber grade
S1001 ART103A A
facId name department rank S1001 HST205A C
F101 Adams Art Professor S1002 ART103A D
F105 Tanaka CSC Instructor S1002 CSC201A F
F110 Byrne Math Assistant S1002 MTH103C B
F115 Smith History Associate S1010 ART103A
F221 Smith CSC Professor
S1010 MTH103C
Figure 4.1(b) The Faculty Table
S1020 CSC201A B
S1020 MTH101B A
Figure 4.1(d) The Enroll Table
• Each row of Student table represents one student

• Each row of Class table represents one class
• Each row of Enroll represents relationship between one student and
one class
Mathematical Relations
 For two sets D1 and D2, the Cartesian
product,
D1 X D2 , is the set of all ordered pairs in
which the first element is from D1 and the
second is from D2
 A relation is any subset of the Cartesian
product
 Could form Cartesian product of 3 sets;
relation is any subset of the ordered triples so
formed
 Could extend to n sets, using n-tuples
Database Relations
 A relation schema, R, is a set of attributes
A1, A2,…,An with their domains D1, D2,…Dn
 A relation r on relation schema R is a set of
mappings from the attributes to their
domains
 r is a set of n-tuples (A1:d1, A2:d2, …, An:dn)
such that d1ε D1, d2 εD2 , …, dn εDn
 In a table to represent the relation, list the Ai
as column headings, and let the (d1, d2, …dn)
become the n-tuples, the rows of the table
Properties of Relations
 Degree: the number of attributes
 2 attributes - binary; 3 attributes - ternary;
n attributes - n-ary
 A property of the intension – does not
change
 Cardinality: the number of tuples
 Changes as tuples are added or deleted
 A property of the extension – changes often
 Keys
 Integrity constraints
Relation Keys
 Relations never have duplicate tuples, so you can always tell tuples
apart; implies there is always a key (which may be a composite of
all attributes, in worst case)
 Superkey: set of attributes that uniquely identifies tuples
 Candidate key: superkey such that no proper subset of itself is

also a superkey (i.e. it has no unnecessary attributes)
 Primary key: candidate key chosen for unique identification of

tuples
 Cannot verify a key by looking at an instance; need to consider
semantic information to ensure uniqueness
 A foreign key is an attribute or combination of attributes that is

the primary key of some relation (called its home relation)
Integrity Constraints
 Integrity: correctness and internal consistency
 Integrity constraints are rules or restrictions that

apply to all instances of the database
 Enforcing integrity constraints ensures only legal states

of the database are created
 Types of constraints
 Domain constraint - limits set of values for attribute
 Entity integrity: no attribute of a primary key can have a null
value
 Referential integrity: each foreign key value must match the
primary key value of some tuple in its home relation or be
completely null.
 General constraints or business rules: may be expressed
as table constraints or assertions
Representing Relational Database Schemas
 Can have any number of relation schemas
 For each relation schema list name of relation
followed by list of attributes in parentheses
 Underline primary key in each relation schema
 Indicate foreign keys (We use italics – arrows are
best)
 Database schema actually includes domains, views,
character sets, constraints, stored procedures,
authorizations, etc.
 Example: University database schema
Student (stuId, lastName, firstName, major, credits)
Class (classNumber, facId, schedule, room)
Faculty (facId, name, department, rank)
Enroll(stuId,classNumber,grade)
Lecture : 6
28th June, 2010
Representing Relational Database Schemas
 The outline of databases in conceptual and Internal
level with or without data nature is called schema.
 For each relation schema list name of relation followed
by list of attributes in parentheses
 Underline primary key in each relation schema
 Indicate foreign keys (We use italics – arrows are best)
 Database schema actually includes domains, views,
character sets, constraints, stored procedures,
authorizations, etc.
 Example: University database schema

Student (stuId, lastName, firstName, major, credits)
Class (classNumber, facId, schedule, room)
Faculty (facId, name, department, rank)
Enroll(stuId,classNumber,grade)
Query Languages
• A language that helps the user to request the data from
the database(s) is called query languages.
Typically, QLs have higher level of data, address,
naming, syntax and semantics abstractions than PLs.
QLs are of two types- procedural and non- procedural.
But most of the commercial databases includes
constructs and structures from both procedural and non
procedural types, for example SQL.
Relational Algebra believes on process where
relational calculus build up on the result or data.
The user’s query finally realizes or translated in the
form of relational algebraic expression.
Types of Relational Data Manipulation Languages
Procedural:
Proscriptive - user tells system how to
manipulate data - e.g. relational algebra
Non-procedural:
Declarative - user tells what data is needed, not
how to get it - e.g. relational calculus, SQL
Other types:
 Graphical: user provides illustration of data needed e.g. Query By Example (QBE)
 Fourth-generation: 4GL uses user-friendly environment to generate custom applications
 Natural language: 5GL accepts restricted version of English or other natural language
having both basic features as visioning and reasoning.
Relational Algebra
RA is a theoretical language with operators that apply to
one or more relations to produce a relation;
i.e. both operands (inputs) and results (outputs) are tables
 Calculation in relational algebra uses the expression form
called relational algebraic expression (RAE) with help of

the extensive operators.
 Operators are classified into 3 types
 Traditional set of relational algebraic operators

 Union, Set difference, intersection and Cartesian Product .
 Special relational algebraic operators

 Selection, Projection, join and divide
 Additional relational algebraic operators

 Rename, Semijoin, Semiminus, extend, summarize, tclose, group
and ungroup
SELECT Operation
 Applied to a single table, returns rows that meet a

specified predicate, copying them to new table.
 i.e. Unary operator, changes in cardinality as per the
condition meet on user given expression, maintains
the degree, sigma is used as symbol.
 Returns a horizontal subset of original table with the
syntax of
SELECT tableName WHERE condition [GIVING newTableName]
Symbolically,
[newTableName = ]  predicate (table-name)
 Predicate is called theta-condition, as in (table-name)
 Result table is horizontal subset of operand
 Predicate can have operators <, <=, , =, =, <>, (AND),
(OR),  (NOT)
SELECT Example
SELECT Student WHERE stuId = ‘S1013’ GIVING NCIT
NCIT=  STDID=‘S1013’ (Student)
Student
S1002 Chin Ann Math 36 Result
S1005 Lee Perry History 3 stuId lastName firstName major credits
S1010 Burns Edward Art 63 S1013 McCarthy Owen Math 0
S1015 Jones Mary Math 42
S1020 Rivera Jane CSC 15

SELECT Example
SELECT Class WHERE room = ‘H225’ GIVING TO Answer
Answer=  ROOM=‘H225’ (Class)
Class Answer
classNumber facId schedule room classNumber facId schedule room
ART103A F101 MWF9 H221 MTH101B F110 MTuTh9 H225
CSC201A F105 TuThF10 M110 MTH103C F110 MWF11 H225
CSC203A F105 MThF12 M110
HST205A F115 MWF11 H221
MTH103C F110 MWF11 H225
SELECT Student WHERE major= ‘Math’ AND credits > 30

 major=‘Math’ ^ credits > 30 (Student)
Student
S1001 Smith Tom History 90 stuId lastName firstName major credits

S1002 Chin Ann Math 36 S1002 Chin Ann Math 36
S1005 Lee Perry History 3 S1015 Jones Mary Math 42
PROJECT Operator
 It is unary operator acts on a single table and produces a table with
null relation to original relation as per the users’ requirement.
 Returns unique values in a column or combination of columns thus
maintain cardinality but changes the degree.
 General syntax is
PROJECT tableName OVER (colName,...,colName) [GIVING newTableName]
Symbolically
[newTableName =]  colName,...,colName (tableName)
PROJECT Example
PROJECT Student OVER major GIVING Temp
Temp =  major (Student)
Student
stuId lastName firstName major credits Temp
major
History
S1005 Lee Perry History 3 Math
S1010 Burns Edward Art 63 Art
S1013 McCarthy Owen Math 0 CSC
PROJECT Class OVER (facId, room)
 facId, room (Class) Contd.
Class
classNumber facId schedule room
facId room
ART103A F101 MWF9 H221 F101 H221
CSC201A F105 TuThF10 M110 F105 M110
CSC203A F105 MThF12 M110 F115 H221
HST205A F115 MWF11 H221 F110 H225
MTH103C F110 MWF11 H225
PROJECT and SELECT Combination Example

Want the names and student IDs of History majors
SELECT Student WHERE major = ‘History’ GIVING Temp
PROJECT Temp OVER (lastName, firstName, stuId) GIVING Result
Student Temp
S1002 Chin Ann Math 36 S1001 Smith Tom History 90
S1010 Burns Edward Art 63 S1005 Lee Perry History 3
Temp Result
stuId lastName firstName major credits lastName firstName stuId
S1001 Smith Tom History 90 Smith Tom S1001
S1005 Lee Perry History 3 Lee Perry S1005
Product and Theta-join
 Binary operations – apply to two tables
 Product: Cartesian product – cross-product of A and B – A TIMES B,
written A x B
 all combinations of rows of A with rows of B
 Degree of result is deg of A + deg of B
 Cardinality of result is (card of A) * (card of B)
 THETA join: TIMES followed by SELECT
A |x| B = (A x B)
Student X Enroll (Produce 63 tuples)
Student Enroll
stuId classNumber grade
stuId lastName firstName major credits S1001 ART103A A
S1001 Smith Tom History 90 S1001 HST205A C
S1002 ART103A D
S1002 CSC201A F
S1002 MTH103C B
S1010 Burns Edward Art 63 X S1010 ART103A
S1013 McCarthy Owen Math 0 S1010 MTH103C
S1020 CSC201A B
S1020 Rivera Jane CSC 15 S1020 MTH101B A
stuId lastName firstName major credits Enroll.stuId classNumber grade

S1001 Smith Tom History 90 S1001 ART103A A
… … … … …… … …
Equi-join and Natural Join
 EQUIJOIN formed when  is equality on column

common to both tables (or comparable columns)
 The common column appears twice in the result
 Eliminating the repeated column in the result
gives the NATURAL JOIN, usually called just
JOIN
A |x| B
EQUIJOIN Example
Student EQUIJOIN Enroll (Produce 9 tuples)
Equivalent to:
Student TIMES Enroll GIVING Temp3
SELECT Temp3 WHERE Student.stuId = Enroll.stuId
Student Enroll
stuId lastName firstName major credits stuId classNumber grade
S1001 ART103A A
S1002 Chin Ann Math 36 S1002 ART103A D
S1005 Lee Perry History 3 S1002 CSC201A F
S1010 Burns Edward Art 63 TIMES S1002 MTH103C B
S1013 McCarthy Owen Math 0 S1010 ART103A
S1015 Jones Mary Math 42 S1010 MTH103C
S1020 Rivera Jane CSC 15 S1020 CSC201A B
S1020 MTH101B A
stuId lastName firstName major credits Enroll.stuId classNumber grade

S1001 Smith Tom History 90 S1001 ART103A A
S1002 Chin Ann Math 36 S1002 MTH103C B
S1002 Chin Ann Math 36 S1002 CSC201A F
S1010 Burns Edward Art 63 S1010 MTH103C
S1010 Burns Edward Art 63 S1010 ART103A
S1020 Rivera Jane CSC 15 S1020 MTH101B A
NATURAL JOIN Example
Student JOIN Enroll or Student |X| Enroll
Equivalent to:
Student TIMES Enroll GIVING Temp3
SELECT Temp3 WHERE Student.stuId = Enroll.stuId GIVING Temp4
PROJECT Temp4 OVER (Student.stuId, lastName,, firstName, major, credits,
classNumber, grade)
Student Enroll
stuId lastName firstName major credits S1001 ART103A A
S1010 Burns Edward Art 63 TIMES S1002 MTH103C B
S1020 MTH101B A
stuId lastName firstName major credits classNumber grade

S1001 Smith Tom History 90 HST205A C
S1001 Smith Tom History 90 ART103A A
S1002 Chin Ann Math 36 MTH103C B
S1002 Chin Ann Math 36 CSC201A F
S1002 Chin Ann Math 36 ART103A D
S1010 Burns Edward Art 63 MTH103C
S1010 Burns Edward Art 63 ART103A
S1020 Rivera Jane CSC 15 MTH101B A
S1020 Rivera Jane CSC 15 CSC201A B
JOIN Example
Faculty JOIN Class or Faculty |X| Class

Faculty Class
facId name department rank classNumber facId schedule room
F101 Adams Art Professor
F105 Tanaka CSC Instructor ART103A F101 MWF9 H221
F110 Byrne Math Assistant |X| CSC201A
CSC203A
F105
F105
TuThF10
MThF12
M110
M110
F115 Smith History Associate
F221 Smith CSC Professor HST205A F115 MWF11 H221
MTH103C F110 MWF11 H225
facId name department rank class No schedule room

F101 Adams Art Professor ART103A MWF9 H221
F105 Tanaka CSC Instructor CSC203A MThF12 M110
F105 Tanaka CSC Instructor CSC201A TuThF10 M110
F110 Byrne Math Assistant MTH103C MWF11 H225
F110 Byrne Math Assistant MTH101B MTuTh9 H225
F115 Smith History Associate HST205A MWF11 H221
More Complicated Queries
Find classes and grades of student Ann Chin
SELECT Student WHERE lastName=‘Chin’ AND
firstName=‘Ann’ GIVING Temp1
Temp1 JOIN Enroll GIVING Temp2
PROJECT Temp2 OVER (classNo, grade) GIVING
Answer
classNo,grade((lastName=‘Chen’ ^ firstName=‘Ann’(Student))|X|
Enroll)
More Complicated Queries (cont.)
SELECT Student WHERE lastName=‘Chin’ AND firstName=‘Ann’ GIVING Temp1
Student Temp1
stuId lastName firstName major credits stuId lastName firstName major credits
S1001 Smith Tom History 90 S1002 Chin Ann Math 36
S1010 Burns Edward Art 63 Temp1 JOIN Enroll GIVING Temp2
Temp2 Enroll
stuId lastName firstName major credits classNumber grade stuId classNumber grade
S1002 Chin Ann Math 36 ART103A D S1001 ART103A A
S1002 Chin Ann Math 36 CSC201A F S1001 HST205A C
S1002 Chin Ann Math 36 MTH103C B S1002 ART103A D
S1002 CSC201A F
S1002 MTH103C B
S1010 ART103A
PROJECT Temp2 OVER (classNo, grade) S1010 MTH103C
GIVING Answer S1020 CSC201A B
S1020 MTH101B A
Answer
classNumber grade
ART103A D
CSC201A F
MTH103C B
More Complicated Queries (cont.)
Since we only need the stuId from Temp1, we can do a
PROJECT on Temp1 before we make the JOIN
classNo,grade(stuId(lastName=‘Chen’ ^ firstName=‘Ann’(Student))|X|
Enroll)
A third way is:

JOIN Student, Enroll GIVING Tempa
SELECT Tempa WHERE lastName=‘Chin’ AND firstName = ‘Ann’
GIVING Tempb
PROJECT Tempb Over (classNo, grade)
But it requires more work by the JOIN (produces 54 tubles), so is
less efficient
Semijoins and Outerjoins
 Left semijoin A|x B is formed by finding
A|x|B and projecting result onto attributes of A
 Result is tuples of A that participate in the join
 Right semijoin A x| B defined similarly; tuples of B that
participate in join
 Semijoin is not commutative
 Student LEFT-SEMIJOIN Enroll is different from Enroll LEFT-
SEMIJOIN Student
 Outerjoin is formed by adding to the join those tuples
that have no match, adding null values for the attributes
from the other table e.g.
A OUTER- EQUIJOIN B
consists of the equijoin of A and B, supplemented by the
unmatched tuples of A with null values for attributes of B
and the unmatched tuples of B with null values for
attributes of A
 Can also form left outerjoin or right outerjoin
Semijoins Example
Student LEFT-SEMIJOIN Enroll or Student |X Enroll
Enroll
Student
lastNam firstNam
stuId major credits S1001 ART103A A
e e
S1010 Burns Edward Art 63 |X S1002 MTH103C B
S1020 MTH101B A
stuId lastName firstName major

S1001 Smith Tom History
S1002 Chin Ann Math
S1010 Burns Edward Art
S1020 Rivera Jane CSC
Outerjoin Example
Student OUTERJOIN Faculty
Student Faculty
stuId lastName firstName major credits facId name department rank
F105 Tanaka CSC Instructor
OUTERJOIN F110 Byrne Math Assistant

S1001 Smith Tom History 90 F221 Smith CSC Professor
S1001 Smith Tom History 90 F115 Smith History Associate
F110 Byrne Math Assistant
Left-Outer-Equijoin Example
Student LEFT-OUTER-EQUIJOIN Faculty
Student
Faculty
S1005 Lee Perry History 3 LEFT-OUTER-EQUIJOIN

Right-Outer-Equijoin Example
Student RIGHT-OUTER-EQUIJOIN Faculty
Student Faculty
S1002 Chin Ann Math 36 LEFT-OUTER-EQUIJOIN

Division
 Binary operator where entire structure of one
table (divisor) is a portion of structure of the
other (dividend)
 Result is projection onto those attributes of
the dividend that are not in the divisor of the
tuples of dividend that appear with all the
rows of the divisor
 It tells which values of those attributes
appear with all the values of the divisor
Divide Example
Club DIVIDED BY Stu or Club  Stu
Club Stu
ClubName StuNumb StuLastName StuNumb StuLastName
Computing S1001 Smith S1001 Smith
Computing S1002 Chin S1002 Chin
Drama S1001 Smith S1005 Lee
Drama S1002 Chin
Drama S1005 Lee
Karate S1001 Smith
Karate S1002 Chin
Karate S1005 Lee
Club DIVIDED BY Stu
ClubName
Drama
Karate
Set Operations
 Tables must be union compatible –
have same basic structure
 Have the same degree
 Attributes in corresponding position have
same domain
 Third column in first relation must have same
domain as third column in second relation
Set Operations (cont.)
 A UNION B: set of tuples in either or both of
A and B, written A  B
 Remove duplicates
MainFac BarnchFac
FacID name department rank
F101 Adams Art Processor
 F101 Adams Art Processor
F110 Byre Math Assistant
F221 Smith CSC Processor
MainFac UNION BarnchFac

 A INTERSECTION B: set of tuples in both A
and B simultaneously, written A ∩ B
MainFac BarnchFac
∩ F101 Adams Art Processor
MainFac INTERSECTION BranchFac

 Difference or A MINUS B: set of tuples in A but not in B, written A – B
 MainFac - BranchFac
BarnchFac
-
MainFac FacID name department rank
FacID name department rank F101 Adams Art Processor
F101 Adams Art Processor F110 Byre Math Assistant
F105 Tanaka CSC Instructor F115 Smith History Associate
F221 Smith CSC Processor F221 Smith CSC Processor
MainFac MINUS BranchFac

 BranchFac - MainFac
BarnchFac MainFac
FacID name department rank FacID name department rank
F101
F110
Adams
Byre
Art
Math
Processor
Assistant - F101
F105
Adams Art
Tanaka CSC
Processor
Instructor
F115 Smith History Associate F221 Smith CSC Processor
MainFac MINUS BranchFac

Relational Calculus
 Formal non-procedural language
 Two forms: tuple-oriented () and
domain-oriented (given by Pirotte)

 Based on predicates, range and
bounded variables, wff, quantifiers and

qualifiers.

Tuple-oriented predicate calculus
 Uses tuple variables, which take tuples

of relations as values
 Query has form {S  P(S)}
 S is the tuple variable, stands for tuples of
relation
 P(S) is a formula that describes S
 Means “Find the set of all tuples, s, such
that P(S) is true when S=s.”

 Limit queries to safe expressions –
test only finite number of possibilities
Example Tuple-oriented Relational Calculus
Example 1: Find the names of all faculty members who are

Professors in CSC Department
{F.name | F  Faculty ^ F.department = ‘CSC’ ^ F.rank =
‘Professor’}
Example 2: Find the last names of all students enrolled in

CSC201A
{S.lastName | S  Student ^ EXISTS E (E  Enroll ^ E.stuId
= S.stuId ^ E.classNo = ‘CSC201A)}
Example 3: Find the first and last names of all students who are
enrolled in at least one class that meets in room H221.
{S.firstName, S.lastName | S  Student ^ EXISTS E(E 
Enroll ^ E.stuId = S.stuId ^ EXISTS C (C  Class ^
C.classNo = E.classNo ^ C.room = ‘H221’))}
Domain-oriented predicate calculus
 Uses variables that take their values from domains
 Query has form
{<x1,x2,...,xn>  P(x1,x2,...,xm )}
 x1,x2,...,xn are domain variables
 P(x1,x2,...,xm) is a predicate
 n<=m
 Means set of all domain variables x1,x2,...,xn for which
predicate P(x1,x2,...,xm) is true
 Predicate must be a formula
 Often test for membership condition, <x,y,z > X
Example Domain-oriented Relational Calculus
 Example 1: Find the name of all faculty members who are
professors in CSC Department
 {LN |  FI, DP, RK (<F1, LN, DP, RK>  Faculty ^ RK =
‘Professor’ ^ DP = ‘CSC’)}
 Example 2: Find the last names of all students enrolled in
CSC201A.
 {LN |  SI, FN, MJ, CR (<SI, LN, FN, MJ, CR>  Student ^  CN,
GR (<SI, CN, GR>  Enroll ^ CN = ‘CSC201A’))}
 Example 3: Find the first and last names of all students who
are enrolled in at least one class that meets in room H221.
 {FN, LN |  SI, MJ, CR (<SI, LN, FN, MJ, CR>  Student ^  CN,
GR (<SI, CN, GR>  Enroll ^  FI, SH, RM (<CN, FI, SH, RM> 
Class ^ RM = ‘H221’)))}
SI: stuId, LN: lastName, FN: firstName, MJ: major, CR: credits, CN: calssNo,
FI: facId, SH: schedule, RM: room, DP: department, RK: rank, GR: grade
Views
 External models in 3-level architecture are called
external views
 Relational views are slightly different
 Relational view is constructed from existing (base)
tables
 View can be a window into a base table (subset)
 View can contain data from more than one table
 View can contain calculated data
 Views hide portions of database from users
 External model may have views and base tables
Mapping ER to Relational Model
 Each strong entity set becomes a table
 Non-composite, single-valued attributes become attributes of table
 Composite attributes: either make the composite a single attribute
or use individual attributes for components, ignoring the
composite
 Multi-valued attributes: remove them to a new table along with
the primary key of the original table; also keep key in original
table
 Weak entity sets become tables by adding primary key of owner
entity
 Binary Relationships:
 1:M-place primary key of 1 side in table of M side as foreign key
 1:1- make sure they are not the same entity. If not, use either key as
foreign key in the other table
 M:M-create a relationship table with primary keys of related entities,
along with any relationship attributes
 Ternary or higher degree relationships: construct relationship
table of keys, along with any relationship attributes

DBMS All

Uploaded by

Copyright:

Available Formats

DBMS All

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DBMS All

Uploaded by

Copyright:

Available Formats

Definition: Database Management Systems

• In general database is integrated collection of data in form of

Database Management System (DBMS)

 Drawbacks of using file systems (cont.)

 Brief, precise and unambiguous descriptions of

 Standardize company’s view of data

We will look briefly at each Model Type

 Developed in 1960s to manage large amounts of data for

 Resembles hierarchical model

 Conceptually simple – Linked Tables

 Also called relations

 Relational Database Management System

 Performs same basic functions as

 Introduced by Peter Chen in 1976

 Entity Relationship Diagram (ERD)

 Three symbols to represent element relationships

 Models both data and their relationships in a single

 Semantic data model

Example of schema in the entity-relationship model

 E-R model of real world

customer- customer- customer- account-

By the end of class you will have clear

View 1 View 2 . . . . View n

View 1 View 2 . . . . View n

SQL Logical ind

 Data Management that achieves data

obviously you updated his phone number:

‘Raju’ in your list of names.

SELECT name FROM Customer

DDL Query DML

Runtime Database Processor

that do not fit into the traditional data processing

programs that have been written previously

Two-tier architecture: E.g. client programs using

applications built using “middleware”

 Each end users’ view of the data environment

 Global view of the entire database

 Software and hardware independent

 The database as “seen” by the DBMS

 1970 Paper by E.F. Codd “A Relational Model of Data

name of the attribute it represents

 Class table shows facts about classes,

including what faculty member teaches

• Each row of Student table represents one student

 Superkey: set of attributes that uniquely identifies tuples

 Candidate key: superkey such that no proper subset of itself is

 Primary key: candidate key chosen for unique identification of

 A foreign key is an attribute or combination of attributes that is

 Integrity constraints are rules or restrictions that

 Enforcing integrity constraints ensures only legal states

 Example: University database schema

called relational algebraic expression (RAE) with help of

 Traditional set of relational algebraic operators

 Special relational algebraic operators

 Additional relational algebraic operators

 Applied to a single table, returns rows that meet a

stuId lastName firstName major credits

S1001 Smith Tom History 90

S1002 Chin Ann Math 36 Result