Sei sulla pagina 1di 498

The Evolution of Database

Technology

Duration: 2 hours

© UCSC
Detailed Syllabus
1. The Evolution of Database Technology (2hrs.)

1. Data
Information
Database
Database management system
Database system
Data processing and data management
Increasing use of data as a corporate resource

2. File oriented systems:


Meeting the need for random access processing
Limitations of Traditional File Systems:
Data redundancy
Inadequate data manipulation capabilities
Program-data dependency
Data independence
© UCSC
Main References

• Database Management and Design by GW Hansen


and JV Hansen.

• Fundamentals of Database Systems by


Ramez Elmasri, Shamkant B. Navathe.

© UCSC
Components of Database System
Environment

© UCSC
Components of Database System
Environment
• Hardware
Set of physical devices on which a database resides.
Can range from a PC to a network of computers.

• Software
– database management system (DBMS)
– operating system
– application programs
– User Interface
• Data
– Used by the organization and a description of this
data called the schema.
© UCSC
Components of Database System
Environment
• Data
–A representation of facts, concepts or instructions
in a formalised manner suitable for communication,
interpretation or processing by human beings or by
automatic means.

–Raw data which is unprocessed


Text, colours, symbols, shapes, graphics, images,
temperatures, sound, video or other facts and figures
are data suitable for processing.

© UCSC
Components of Database System
Environment

– E.g. Person or Employee or Customer


– name, address, phone, date of birth,
designation, department, salary,
– employee no, photograph

© UCSC
Components of Database System
Environment
• Procedures
Instructions and rules that should be applied to the design
and use of the database.

• People
Two different types of people (end-users and
practitioners) are concerned with the database.
End-Users
– are the ‘clients’ of the database, who need
information from the database to carry out their
duties.
e.g. Executives, managers, staff, clerical personnel

© UCSC
Components of Database System
Environment - People
Practitioners
– people responsible for the database
system and its associated application
software.
e.g. Data and Database administrators,
Database designers, Application
developers.

© UCSC
Information
• Information
•Knowledge derived from data.
•Processed or organised or summarised
data.
Eg:-
•Process Date of Birth ->Age
•Process Salary (all) ->Highest paid
employee
•Process all -> No of employees
•Process all -> Employees working for © UCSC
Why use a Database?

• Many people collect things


– How about you?
• If you collect any thing, you probably are familiar
with some of the problems of managing a collection
– e.g. stamps, photos, paper cuttings
• One way to keep track of a collection is to create a
database

© UCSC
Why Database Technology?
The need to manipulate large collection of data for
frequent used data queries and reports.

E.g. Collection of information on library books


Queries:
– List of books written by a particular author
– List of books about a particular subject
– Borrowing a book
– Reserving a book for borrowing

© UCSC
Examples of Database Applications

• Purchases from the supermarket


• Purchases using your credit card
• Booking a holiday at the travel agents
• Using the Internet
• Studying at university

© UCSC
Manual Systems – Information on
library books

• Before and during most of last century, libraries


used card catalogues stored in drawers of special
cabinets
– cards with typed book information
e.g. the title index has one card for every book in
the library

© UCSC
File-Based Systems
• Collection of application programs that perform
services for the end users (e.g. reports).

• Each program defines and manages its own data.

Personnel Application Employee file


Name, Address, NID number, Designation

Payroll Application Payroll file


Name, Address, Hours worked, Pay rate

© UCSC
Data Redundancy

Personnel
Application Employee file
Name, Address, NID , Designation

Payroll
Payroll file
Application
NID, Name, Address, Hours worked, Pay rate

Benefit
Benefit files
Application
Name, Address, Insurance, Pension plan

© UCSC
Limitations of File-Based
Approach
• Separation and isolation of data
– Each program maintains its own set of data.
– Users of one program may be unaware of
potentially useful data held by other programs.

• Duplication of data
– Same data is held by different programs.
– Wasted space and potentially different values
and/or different formats for the same item.

© UCSC
Limitations of File-Based
Approach
• Data dependence
– File structure is defined in the program code.

• Incompatible file formats


– Programs are written in different languages, and so
cannot easily access each other’s files.

• Fixed Queries/Proliferation of
application programs
– Programs are written to satisfy particular functions.
– Any new requirement needs a new program.

© UCSC
Database Approach
• Arose because:
– Definition of data was embedded in application
programs, rather than being stored separately and
independently.
– No control over access and manipulation of data
beyond that imposed by application programs.

• Result:
– the database and Database Management System
(DBMS).

© UCSC
Database
• Shared collection of logically related data (and a
description of this data), designed to meet the
information needs of an organization.

• System catalog or data dictionary provides description


of data (metadata) to enable program–data
independence.

• Logically related data comprises entities, attributes, and


relationships of an organization’s information.

© UCSC
Database Management System
(DBMS)

• A software system that enables users to


define, create, and maintain the database
and that provides controlled access to this
database.

© UCSC
Database Approach
Personnel
Application
File 1
Payroll
DBMS File 2
Application
File 3
Benefit
Application

e.g. Integrated human resources database


• Employees: Name, Address, NID number,
Designation
• Payroll: Hours worked, Pay rate
• Benefit: Insurance, Pension plan
© UCSC
Data Hierarchy

Database

Entities/objects
File File File
Field

Record Record Record Byte Byte Byte

Field Field Field


Bit Bit Bit
attributes

© UCSC
Data Hierarchy

Employee (Empno, Name, Designation, Salary,


Depart)
1 De SilvaManager 50000 Personnel
2 Perera Secretary 15000 Personnel
3 Dias Salesman 25000 Sales
Department (Depart, Manager, Dept Addr, Dept Phone)

Personnel De Silva Colombo 589123


Sales Alwis Kandy 987275
…. …. …. ….

© UCSC
Data Hierarchy
(Empno, name, designation,
salary,department)
2 Perera Record r
Manag 35,000
Personnel e
Field 1 Field 2 Field 3 Field 4

Byte
•A single character (letter, number, symbol) is represented using a
group of bits, E.g. 10101010 letter J in ASCII

Bit
•The smallest unit of data, E.g. 0 or 1
© UCSC
Database Architecture

Duration: 3 hours

© UCSC
Detailed Syllabus
2. Database Architecture
1. Components of a Database Management System:
Data Dictionary (importance, contents)
Meta data
Data security and integrity
Concurrent access
User-oriented data query and reporting
Application development facilities
2. Database Systems:
ANSI/SPARC Three-level Architecture
Conceptual model, Logical model, Physical model
External view, Conceptual view, Internal view of
data

© UCSC
Detailed Syllabus Contd.
1.2.3. Data specification and access mechanisms:
Data Definition Language (DDL)
Sub-Schema DDL (SDDL)
Data Manipulation Language (DML)
End users, Database Administrator
Functions, Capabilities of DBMS
Advantages and disadvantages

© UCSC
Data Dictionary/System Catalog

• A subsystem that keeps track of the


definitions of data items in the database
which includes
•Elementary-level data items
(fields/attributes),
•group and record-level data structures, and
•files or relational tables.

© UCSC
Meta Data

• Data that describe the properties or characteristics of


other data.
• Some of these properties include the name of the data
item, data type, length, minimum and maximum
allowable values (where appropriate), rules or
constraints and a brief description of each data item.
• Metadata allow database designers and users to
understand what data exist, what the data mean.
• Data without clear meaning can be confusing,
misinterpreted or erroneous.

© UCSC
Meta Data
•E.g. Employee
Name Type Length Min Max Description
EmpNo Number 9 Employee No.
Name Character 30 Employee Name
Dept Character 10 Dept. No.
Salary Number 8 5000 60000 Employee Salary

• Employee No. (ID) unique

© UCSC
Three-Level Architecture
• All users should be able to access same
data but have a customized view of the
data.

• A user’s view is immune to changes made


in other views.

• Users should not need to know physical


database storage details (e.g. indexing or
hashing). © UCSC
3 Level ANSI/SPARC Architecture
• External level
– User’s view of the database.
• Conceptual level
– Describes what data is stored in the database
and the relationships among the data.
• Internal
– Describes how the data is stored in the
database.

© UCSC
Three-level ANSI/SPARC
architecture
User 1 User 2 User 3

External Level View 1 View 2 View 3

Conceptual conceptual schema


Level

Internal Internal schema


Level

Physical data
Databases
organisation
© UCSC
Data Independence and the ANSI-
SPARC Three-Level Architecture

© UCSC
Internal Level
• The physical representation of the
database on the computer to achieve
optimal runtime performance and storage
space utilization.

- Covers data structures and file


organisations used to store data on
the storage device.
- Storage space allocation for data and
indexes.

© UCSC
Conceptual Level
• This level contains the logical structure
of the entire database. Provides a
complete view of the data requirements
of the organization that is independent of
any storage considerations.

• The conceptual level represents:


– All entities, their attributes and their
relationships
– The constraints on the data
– Security and integrity information
© UCSC
External Level
• Describes the part of the database that is
relevant to the user.

• The external view include only the entities,


attributes or relationships in the ‘real world’
that the user is interested in.

• Different views have different


representations of the same data.

© UCSC
External Level
• External Views Allow to
– hide unauthorised data
• e.g. salary, dob
– provide user view
• e.g. view employee name,
designation, department data taken
from employee and department
files
– derive new attributes
• e.g. age derived from dob or nid
© UCSC
External Level
• External Views Allow to
– change unit of measurement
• e.g. show age in years or months
– define security levels
• e.g. update access to employee
file read-only to department file

© UCSC
Objectives of Three-Level
Architecture
• DBA should be able to change database
storage structures without affecting the
users’ views.

• DBA should be able to change


conceptual structure of database without
affecting all users.

© UCSC
Physical Level
• Managed by the operating system under
the direction of the DBMS.

• Consist of items only the OS knows.

© UCSC
Differences between Three Levels of
ANSI-SPARC Architecture

© UCSC
2007, UCSC
Mapping between Levels

• DBMS map or translate from one level


to another.
– External  Conceptual
External schema is related to the
conceptual schema
– Conceptual  Internal
Conceptual schema is related to the
internal schema.

© UCSC
Data Independence

• Logical Data Independence


– Refers to immunity of external schemas to
changes in conceptual schema.
– Conceptual schema changes (e.g.
addition/removal of entities).
– Should not require changes to external
schema or rewrites of application programs.

© UCSC
Data Independence
• Physical Data Independence
– Refers to immunity of conceptual schema to
changes in the internal schema.
– Internal schema changes (e.g. using different
file organizations, storage structures/devices).
– Should not require change to conceptual or
external schemas.

© UCSC
Database Approach
• Data definition language (DDL).
– Permits specification of data types, structures and
any data constraints.
– All specifications are stored in the database.

• Data manipulation language (DML).


– General enquiry facility (query language) of the
data.

© UCSC
Database Approach
• Controlled access to database may
include:
– A security system.
– An integrity system.
– A concurrency control system.
– A recovery control system.

• A view mechanism.
– Provides users with only the data they want or need
to use.
© UCSC
Views
• Allows each user to have his or her own
view of the database.

• A view is essentially some subset of the


database.

• Benefits include:
– Provide a level of security;
– Provide a mechanism to customize the
appearance of the database;
© UCSC
Database Languages
• Data Definition Language (DDL)
– Allows the DBA or user to describe and
name entities, attributes, and relationships
required for the application
– plus any associated integrity and security
constraints.

© UCSC
Database Languages

• Data Manipulation Language (DML)


– Provides basic data manipulation operations on
data held in the database.

• Non-Procedural DML
– allows user to state what data is needed rather than
how it is to be retrieved.
• Procedural DML
– allows user to tell system exactly how to manipulate
data.

© UCSC
Database Applications
Databases range from those for a
single user with a desktop computer
to those on mainframe computers
with thousands of users.
– Personal databases
– Workgroup databases
– Departmental databases
– Enterprise databases

© UCSC
Personal databases
Designed to support one user with a
stand alone PC.

E.g. a sales person keeping track of


this customer information with contact
details.

© UCSC
Workgroup databases

A relatively small team of people (less


than 25) who collaborate on the same
project or application.

E.g. a team of engineering designers


maintain versions of the artifact that
they design.

© UCSC
Departmental databases

A department is a functional unit of an


organisation. It is larger than a
workgroup.
Department databases are designed to
support the various functions and
activities of a department.

E.g. a personnel database that is


designed to track data concerning
employees, jobs, skills and job
assignments. © UCSC
Enterprise databases
An enterprise is one whose scope is
the entire organisation or enterprise.
Such databases are intended to
support organisation-wide operations
and decision making.

E.g. a large health care organisation


that operates a group of medical
centre's including hospitals, clinics and
nursing homes.
© UCSC
Enterprise databases
An enterprise database does support
information needs from many
departments. The most important type
of enterprise database today is called a
data warehouse.
• Data warehouse
– An integrated decision support database
whose content is derived from the various
operational databases.

© UCSC
Database Approach -Advantages
• Improved maintenance through
program-data independence

• Minimal data redundancy

• Improved data consistency

• Improved data sharing

• Increased productivity
© UCSC
Advantages
• Enforcement of standards
• Improved data integrity
• Improved data accessibility and
responsiveness
• Improved security
• Increased concurrency

© UCSC
Improved maintenance through Program-
Data/Data Independence
• The separation of data descriptions (metadata) from
the application programs that use the data.
This simplifies database application maintenance.

• In the database approach data descriptions are


stored in a central location called the data dictionary.
This property allows an organisation’s data to
change and evolve (within limits) without changing
the application program that process the data.

© UCSC
Minimal Data Redundancy
• Data files are integrated into a single, logical
structure. Each primary fact is recorded
(ideally) in only one place in the database.
• E.g. Employee data not with the payroll and
benefit files.

Note: Data redundancy is not eliminated


entirely. Some data items will appear in more
than one place (e.g. employee no.) to
represent the relationship with others.

© UCSC
Improved Data Consistency
• By eliminating (or controlling) data
redundancy, we greatly reduce the
opportunities for inconsistency.
E.g. employee address is stored only
once and hence we cannot have
disagreement on the stored values.
• Also, updating data values is greatly
simplified and have avoided the wasted
storage space.
© UCSC
Improved Data Sharing
• A database is designed as a shared
corporate resource and can be shared by all
authorised users. In this way more users
share more of the data.
E.g. employee data common to payroll,
benefit applications will be shared among
different users.

New applications can be built on the existing


data in the database.
© UCSC
Increased Productivity
• A major advantage of the database approach
is that it greatly reduces the cost and time for
developing new business applications.

– Programmer could concentrate on the specific


functions required for the new application,
without having to worry about design or low-level
implementation details; as related data has
already been designed and implemented.

– DBMS provides many of the standard functions


(e.g. forms and report generations) that the
programmer would normally have to write in a file-
based application DBMS.

© UCSC
Enforcement of Standards
• When the database approach is implemented
with full management support, the database
administration function should be granted
single-point authority and responsibility for
establishing and enforcing data standards.

• Standards include naming conventions, data


quality standards and uniform procedures
for accessing, updating and protecting data.

© UCSC
Improved Data Integrity
• Integrity can be expressed in terms of
constraints, which are consistency
rules that the database is not permitted
to violate.

Eg: A member of staff’s salary cannot


be greater than 60,000.

© UCSC
Improved Data Accessibility and
Responsiveness
• With relational database, end users
without programming experience can
often retrieve and display data, even
when it crosses traditional departmental
boundaries.

• English-like query language SQL and


query tools such as Query-By-Example
provide such facilities.
© UCSC
Improved Security
• DBMS can be used to enforce database
security. This may take the form of user
names and passwords to identify people
authorised to use the database.

• The access that the authorised user is


allowed on the data can also be restricted
by the operation type (retrieval, delete,
update, insert).

© UCSC
Increased concurrency
• Many DBMSs allow users to undertake
simultaneous operations on the database.
The DBMS implements a concurrency
control mechanism that prevents database
accesses from interfering with one
another.

© UCSC
Disadvantages of DBMSs
• Complexity
• Size
• Cost of DBMS
• Additional hardware costs
• Cost of conversion
• Performance
• Higher impact of a failure

© UCSC
Users of a Database
System

Duration: 2 hours

© UCSC
Functions of a DBMS
• Data Storage, Retrieval, and Update.
• A User-Accessible Catalog.
• Transaction Support.
• Concurrency Control Services.
• Recovery Services.
• Authorization Services.
• Integrity Services.
• Utility Services.

© UCSC
Components of
Database Manager (DM)

© UCSC
Components of DB Manager
• Catalog Manager: The catalog manager
manages access to and maintain the system
catalog.
System Catalog
• Repository of information (metadata)
describing the data in the database.
• Typically stores:
– Names of authorized users;
– Names, types, and sizes of data items in
the database;
– Names of relationships
– Constraints on each data item;
© UCSC
System Catalog
– data items accessible by a user and the type of
access allowed (e.g. insert, delete, update or
read access).
– External, conceptual and internal schemas and
the mappings between the schemas.

• Used by modules such as Authorization


Control and Integrity Checker.

© UCSC
System Catalog - Advantages
• Maintains control over the data as a
resource.
• Helps other users understand the
purpose of the data.
• Communication is simplified.
• Identifies the user/s who own or access
the data.
• Security can be enforced.
• Integrity can be ensured
© UCSC
Components of DB
Manager
• Authorization Control
This module checks that the user has the
necessary authorization to carry out the
required operation.

• Integrity Checker
For an operation that changes the database,
the integrity checker checks that the
requested operation satisfies all necessary
integrity constraints.
© UCSC
Components of DB Manager

• Scheduler – Responsible for ensuring that


concurrent operations on the database
proceed without conflicting with one
another. It controls the relative order in
which the transaction operations are
executed .

• Recovery Manager – Ensures that the


database remains in a consistent state in
the presence of failure.
© UCSC
Introduction to
Relational Database Model

Duration : 1hr

© UCSC
Detailed Syllabus
2.1. Introduction to Relational Data Model
Review of database models
Definition of Relation
Attribute
Tuple
Domain
Instance
Cardinality
Degree
Schema
Constrains

© UCSC
The Relational Model
•Relational Model [Properties]
– Each relation (or table) in a database has a
unique name
– An entry at the intersection of each row and
column is atomic (or single-valued);
– there can be no multi-valued attributes in a
relation
– Each row is unique;
– no two rows in a relation are identical
– Each attribute (or column) within a table has a
unique name
© UCSC
The Relational Model
•Properties Cont’d
– The sequence of columns (left to right) is
insignificant;
– the columns of a relation can be
interchanged without changing the meaning
or use of the relation
– The sequence of rows (top to bottom) is
insignificant;
– rows of a relation may be interchanged or
stored in any sequence

© UCSC
The Relational Model...
• The relational model of data has three major
components:
 Relational database objects
allows to define data structures
 Relational operators
allows manipulation of stored data
 Relational integrity constraints
allows to defines business rules and
ensure data integrity
© UCSC
The Relational Objects
• Location
Accounting
– Most RDBMS can have multiple
– locations, all managed by the
Accounts Accounts
– same database engine
Receivable Payable

Corporate Accounting
Marketing Database

Sales Advertising Marketing Purchasing


© UCSC
The Relational Objects
• Location

Client Applications
Database Server

Multi-user
© UCSC
The Relational Objects...
• Database
– A set of SQL objects Database Server
Update Trigger
BEGIN
Client Application Table T
...
UPDATE T SET Insert Trigger
BEGIN
INSERT INTO T ...
DELETE FROM T Delete Trigger
CALL STPROG Stored Table A BEGIN
Procedure ...
BEGIN Table B
...

© UCSC
The Relational Objects...
• Database
– A collection of tables and associated
indexes
Index

Employee Product

Files
Department Customer

© UCSC
The Relational Objects...
• Relation
– A named, two dimensional table of data
• Database
– A collection of databases, tables and
related objects organised in a structured
fashion.
– Several database vendors use schema
interchangeably with database

© UCSC
Relational Objects...
Data is presented to the user as tables:
 Tables are comprised of rows and a
fixed number of named columns.

Table
Column 1 Column 2 Column 3 Column 4
Row
Row
Row

© UCSC
Relational Objects...
Data is presented to the user as tables:
 Columns are attributes describing an entity.
Each column must have an unique name and
a data type.
Employee
Name Designation Department
Row
Row
Row

Structure of a relation (e.g. Employee)


Employee(Name, Designation, Department)
© UCSC
Relational Objects...
Data is presented to the user as tables:
 Rows are records that present
information about a particular entity
occurrence

Employee
Name Designation Department
Row De Silva Manager Personnel
Row Perera Secretary Personnel
Row Dias Manager Sales

© UCSC
Relational model terminology
• Row is called a ‘tuple’
• Column header is called an ‘attribute’
• Table is called a ‘relation’
• The data type describing the type of values that can
appear in each column is called a ‘domain’
• Eg:- Names : the set of names of persons
Employee_ages : value between 15 & 80 years old The
above is called ‘logical definitions of domains’.
A data type or format can also be specified for each
domain.
Eg: The employee age is an integer between 15 and 80
© UCSC
Characteristics of relations
• Ordering of tuples
– Tuples in a realtion don’t have any particular
order. How ever in a file they may be
physically ordered based on a criteria, this is
not there in relational model
• Ordering of values within tuple
– Ordering of values within a tuple are
unnecessary, hence a tuple can be
considered as a ‘set’.
– But when relation is implemented as a file
attributes may be physically ordered
• Values in a tuple are atomic © UCSC
Relational constraints
• Domain constraints
– specifies that the value of each attribute ‘A’ must be
an atomic value. And from the specified domain
• Key constraints
– There is a sub set of attributes of a relational schema
with the property that no two tuples should have the
same combination of values for the attributes.
– Any such subset of attributes is called a ‘superkey’
– A ‘superkey’ can have redundant attributes. A key is a
minimul superkey
– If a realtion has more than one key, they are called
candidate keys
– One of them is chosen as the primary key
© UCSC
Concepts of Keys

Duration : 2hrs

1
Detailed Syllabus
2.2. Concepts of Keys
Candidate key
Primary key
Alternate key
Composite key
Surrogate key
Foreign key
2.3. Fundamental Integrity Rules
Entity Integrity
Referential Integrity
Domain Constraints
Key Constraints
2
Relational Objects
Keys

• Primary Key: An attribute (or


combination of attributes) that uniquely
identifies each row in a relation.
– Employee(Emp_No, Emp_Name,
Department)
• Composite Key: A primary key that
consists of more than one attribute
– Salary(Emp_No, Eff_Date, Amount)
3
Relational Objects
Data is presented to the user as tables:
 Each table has a primary key. The
primary key is a column or combination
of columns that uniquely identify each
row of the table. Salary
Employee E-No Eff-Date Amt
E-No E-Name D-No 179 1/1/98 8000
179 Silva 7 857 3/7/94 9000
857 Perera 4 179 1/6/97 7000
342 Dias 7 342 28/1/97 7500
Primary Key Primary Key
4
Relational Objects
Data is presented to the user as tables:
 The cardinality of a table refers to the
number of rows in the table. The
degree of a table refers to the number
of columns.
Salary
E-No Eff-Date Amt
Salary Table 179 1/1/98 8000
Degree =3 857 3/7/94 9000
Cardinality = 4 179 1/6/97 7000
342 28/1/97 7500
5
Entity integrity, referential
integrity/foreign keys
• Entity integrity constraint specifies that no
primary key can be null
• The referential integrity constraint is specified
between two relations and is used to maintain
the consistency among tuples of the two
realtions
• Informally what this means is that a tuple in one
relation that refers to another relation must refer
to an existing tuple.
• To define referential integrity we use the concept
of foreign keys. 6
Relational Objects
Relationship
• Foreign Key: An attribute in a relation
of a database that serves as the
primary key of another relation in the
same database
– Employee(Emp_No, Emp_Name,
Department)
– Department(Dept_No, Dept_Name, M_No)
=== works for ==>
7
Relational Objects
Data is presented to the user as tables:
 A foreign key is a set of columns in
one table that serve as the primary key
in another table
Employee Department
E-No E-Name D-No D-No D-Name M-No
179 Silva 7 4 Finance 857
857 Perera 4 7 Sales 179
342 Dias 7 Primary Key
Primary Key Foreign Key

Recursive foreign key: A foreign key in a relation that


references the primary key values of that same relation 8
Department
Relational Objects... D-No D-Name M-No

Employee 4 Finance 857


E-No E-Name D-No
7 Sales 179
Primary Key Foreign Key
179 Silva 7
857 Perera 4
342 Dias 7
Primary Key Foreign Key Salary
E-No Eff-Date Amt
179 1/1/98 8000
857 3/7/94 9000
Rows in one or more tables are 179 1/6/97 7000
associated with each other solely 342 28/1/97 7500
through data values in columns Foreign Key
(no pointers). Primary Key
9
Relational Objects
• Index
– An ordered set of pointers to the data in the
table

Employee
E-Name Pointer E-No E-Name D-No
De Silva 179 Silva 7
Dias 857 Perera 4
Perera 342 Dias 7
Silva 719 De Silva 5

10
Index: Employee Name
Employee
E-Name Pointer E-No E-Name D-No
Alwis 179 Silva 7
Bandara 857 Perera 4
Costa 342 Dias 7
De Silva 719 De Silva 5
Dias 587 Alwis 4
Opatha 432 Costa 6
Peiris 197 Zoysa 2
Perera 875 Peiris 4
Silva 324 Vaas 7
Vaas 917 Bandara 3
Wickrama 785 Opatha 2
Zoysa 234 Wickrama 1

11
Search: Employee Dias
E-Name Pointer
Alwis
Bandara
• Index Costa
De Silva
Improves Dias
Opatha
performa Peiris
nce. Perera
Silva
Access to Vaas
data Wickrama
Zoysa
is faster
12
Ensures uniqueness.
Search: Employee Dias A table with unique fields
in the index cannot have
two rows with the same
• Index Opatha values in the column or
columns that form the
index key.

Costa Silva

Bandara Dias Perera Wickrama

13
Search: Employee Dias
. De Silva . Perera .

. Bandara . . . Opatha . . . Vaas . .

. Alwis . . . Costa . . . Dias . . . Peiris . . . Silva . . . Wickrama


. Zoysa .

14
Relational Database
STORE INVENTORY STORE
Store Name | City Store Name | Part No | Quantity Store 1 | Colombo
Store 2 | Kandy
ORDERS
INVENTORY
Store Name | Part No | Vendor No | Order No | Quantity
Store 1 | P1 | 50
Store 1 | P3 | 20
PART VENDOR Store 2 | P2 | 100
Part No | Description Vendor No | Vendor Name Store 2 | P1 | 30

ORDERS PART VENDOR


Store 1 | P3 | 3428 | 0052 | 10 P1 | Printer 3428 | East West
Store 2 | P2 | 3428 | 0098 | 7 P2 | Diskette 5726 | DMS
Store 2 | P3 | 3428 | 0098 | 15 P3 | Disk Drive
Store 2 | P4 | 5726 | 0099 | 1 P4 | Modem

15
Relational Algebra

Traditional Set Operations

© UCSC
Relational Algebra

Detailed Syllabus

• Union
• Intersection
• Difference
• Cartesian Product

© UCSC
Relational Algebra

Relational Algebra

• Relational algebra is a formal language


associated with the relational model.

• Informally, relational algebra is a (high-level)


procedural language.

© UCSC
Relational Algebra

Relational Algebra
• Relational algebra operations work on one
or more relations to define another relation
without changing the original relations.

• Both operands and results are relations, so


output from one operation can become
input to another operation.

• Allows expressions to be nested, just as in


arithmetic. This property is called closure.
© UCSC
Relational Algebra

Relational Algebra
• Five basic operations in relational algebra:
Selection, Projection, Cartesian product,
Union, and Set Difference.

• These perform most of the data retrieval


operations needed.

• Also have Join, Intersection, and Division


operations, which can be expressed in terms
of 5 basic operations. © UCSC
Relational Algebra

Relational Algebra Operations

© UCSC
Relational Algebra

Sequence of Operations
• We may want to apply several relational algebra
operations one after the other.
e.g. Retrieve the first name, last name and salary
of all employees who work in department no. 5

We can write the operation as a single relational


algebra operation by nesting the operations
e.g.
Fname,Lname,Salary (Dno=5 ( Employee))

© UCSC
Relational Algebra

Sequence of Operations
• Or we can apply one operation at a time and
create intermediate result relations.

DEP5_EMPS  (Dno=5 ( Employee))


RESULT  Fname,Lname,Salary(DEP5_EMPS)

© UCSC
Relational Algebra

Union
• RS
– Union of two relations R and S defines a
relation that contains all the tuples of R, or
S, or both R and S, duplicate tuples being
eliminated.
– R and S must be union-compatible.

• If R and S have I and J tuples, respectively,


union is obtained by concatenating them into
one relation with a maximum of (I + J) tuples.
© UCSC
Relational Algebra

Student
Fname Lname
Kapila Dias
Nimal Perera Union
Stu-Inst
Ajith Silva
Rohan Mendis Fname Lname
Kapila Dias
Nimal Perera
Instructor Ajith Silva
FN LN Rohan Mendis
Sunil De Silva Sunil De Silva
Kamal Soysa Kamal Soysa
Saman Silva Saman Silva
Kapila Dias
Nimal Perera Stu-Inst = Student  Instructor
© UCSC
Relational Algebra

Example
• Retrieve the EmpNo of all employees
who either work in department 5 or directly
supervise an employee who works in
department 5.

© UCSC
Relational Algebra

Example
DEP5_EMPS  (Dno=5 ( Employee))
RESULT1  EmpNo(DEP5_EMPS)
RESULT2(EmpNo)  SuperNo(DEP5_EMPS)
RESULT  RESULT1  RESULT2

© UCSC
Relational Algebra

Set Difference
• R–S
– Defines a relation consisting of the
tuples that are in relation R, but not in
S.
– R and S must be union-compatible.

© UCSC
Relational Algebra

Student
Fname Lname
Kapila Dias Stu-Inst Difference
Nimal Perera
Fname Lname
Ajith Silva Ajith Silva
Rohan Mendis Rohan Mendis

Instructor Stu-Inst = Student - Instructor


FN LN Inst-Stu = Instructor - Student
Sunil De Silva Inst-Stu
Kamal Soysa Fname Lname
Saman Silva Sunil De Silva
Kapila Dias Kamal Soysa
Nimal Perera Saman Silva

© UCSC
Relational Algebra

Intersection
• RS
– Defines a relation consisting of the set of all
tuples that are in both R and S.
– R and S must be union-compatible.

• Expressed using basic operations:


R  S = R – (R – S)

© UCSC
Relational Algebra

Student
Fname Lname
Kapila Dias
Nimal Perera Intersection
Ajith Silva
Rohan Mendis

Stu-Inst
Instructor Fname Lname
FN LN Kapila Dias
Sunil De Silva Nimal Perera
Kamal Soysa
Saman Silva
Kapila Dias
Nimal Perera Stu-Inst = Student  Instructor

© UCSC
Relational Algebra

Union, Intersection and Difference


• Both Union and Intersection are commutative
R  S = S  R and R  S = S  R

Either operation can be applied to any number of


relations
R  (S  T) = (R  S)  T and
(R  S)  T = R  (S  T)

Difference operation is not commutative


R–S≠ S-R
© UCSC
Relational Algebra

Cartesian product
• RXS
– Defines a relation that is the concatenation
of every tuple of relation R with every tuple of
relation S.

• Creates a single table from two tables.

• If R has nR tuples and S has nS tuples then R X S


will have nR*nS tuples.

© UCSC
Relational Algebra

Employee Department
E-No E-Name D-No
D-No D-Name M-No
179 Silva 7 4 Finance 857
857 Perera 4 7 Sales 179
342 Dias 7
Emp-Info
E-No E-Name D-No D-No D-Name M-No
179 Silva 7 4 Finance 857
857 Perera 4 4 Finance 857
342 Dias 7 4 Finance 857
179 Silva 7 7 Sales 179
857 Perera 4 7 Sales 179
342 Dias 7 7 Sales 179
Emp-Info = Employee  Department
© UCSC
Relational Algebra

Special Relational
Operations

© UCSC
Relational Algebra

Detailed Syllabus
Special Relational Operations
Select or Restrict
Project
Join
Different Types of Join
Theta join
Equi-join
Natural join
Outer join
Divide

© UCSC
Relational Algebra

Selection (or Restriction)


• predicate (R)
– Works on a single relation R and defines a
relation that contains only those tuples
– (rows) of R that satisfy the specified
– condition (predicate).

– Produces a horizontal subset of a table.

© UCSC
Relational Algebra

Example - Selection (or


Restriction)
• List all employees working for department
No. 7.

Employee Sales Employee


E-No E-Name D-No E-No E-Name D-No
179 Silva 7 179 Silva 7
857 Perera 4 342 Dias 7
342 Dias 7

Sales-Emp = D-No=7 (Employee)


© UCSC
Relational Algebra

Projection
• col1, . . . , coln(R)
– Works on a single relation R and defines a
relation that contains a vertical subset of R,
extracting the values of specified attributes
and eliminating duplicates.

– Produces a vertical subset of a table

© UCSC
Relational Algebra

Example - Projection
• Produce a list of employees showing only
E-No and E-Name.

Employee Employee Names


E-No E-Name D-No E-No E-Name
179 Silva 7 179 Silva
857 Perera 4 857 Perera
342 Dias 7 342 Dias

Emp-Names = E-No, E-Name (Employee)


© UCSC
Relational Algebra

Sequence of Operations
We may want to apply several relational algebra
operations one after the other.
e.g. Retrieve the first name, last name and salary
of all employees who work in department no. 5

We can write the operation as a single relational


algebra operation by nesting the operations
e.g.
Fname,Lname,Salary (Dno=5 ( Employee))

© UCSC
Relational Algebra

Sequence of Operations
Or we can apply one operation at a time and
create intermediate result relations.

DEP5_EMPS  (Dno=5 ( Employee))


RESULT 
Fname,Lname,Salary(DEP5_EMPS)

© UCSC
Relational Algebra

Join Operations
• Join is a derivative of Cartesian product.

• Equivalent to performing a Selection, using


join
predicate as selection formula, over
Cartesian product
of the two operand relations.

© UCSC
Relational Algebra

Join Operations
One of the most difficult operations to
implement
efficiently in an RDBMS and one reason
why
RDBMSs have intrinsic performance
problems.

The general form of a join operation on two


relations R(A1,A2,….,An) and
S(B1,B2,….,Bm) is
R <join condition> S © UCSC
Relational Algebra

Join Operations
• A general join condition is of the form
<condition> AND <condition> AND….. AND
<condition>
• Where each condition is of the form Ai  Bj.
– Ai is an attribute of R, Bj is an attribute of S.
– Ai and Bj have the same domain and
–  is one of the comparison operators {=, <,
<=,>,>=,≠}
– A join operation with such a general join condition
is called theta join. © UCSC
Relational Algebra

Join Operations
• The most common use of JOIN involves
join conditions with equality (=)
comparisons only.

• This is known as EQUIJOIN.

• In the result of an EQUIJOIN we always


have one or more pairs of attributes that
have identical values in every tuple. © UCSC
Relational Algebra

Example - Join Operations

Dept_Mgr DName DNo MgrId …. Fname Lname EId …

Sales 5 123 …. aaa xxx 123 …

Acct 4 345 …. bbb yyy 345 …

Admin 1 678 …. ccc zzz 678 …

A new operation called Natural join denoted by * is


created to get rid of the second attribute.
© UCSC
Relational Algebra

Join Operations
• A new operation called Natural join denoted by
* is created to get rid of the second attribute.
• Outer join
• To display rows in the result that do not
have matching values in the join column, use
Outer join.
• R S
– (Left) outer join is join in which tuples from R that do
not have matching values in common columns of S
are also included in result relation.

© UCSC
Relational Algebra

Join Operations
• Outer join example
List all employee names and the departments
that they manage if they happen to manage
a department.

Temp  Employee empId = mgrId


Department

Result  Fname, Lname,Dname(Temp)


© UCSC
Relational Algebra

Division Operation
• RS R A B S A
a1 b1
– Defines a relation over the a1
a2 b1
attributes C that consists a2
a3 b1
of set of tuples from R that a3
a4 b1
match combination of
a1 b2
every tuple in S.
a3 b2
a2 b3 T B

a3 b3 b1
a4 b3 b4
a1 b4
a2 b4
a3 b4
© UCSC
Relational Algebra

Division Operation
• Division example
Retrieve the names of employees who work on all
projects that ‘Sunil Silva’ works on.
Sunil  Fname=‘Sunil’ and Lname=‘Silva’ (
Employee)
Sunil_Pnos  Pno(Works_on
empId=EssnSunil)
Temp  Essn,Pno(Works_on)
Result1(empId)  Temp  Sunil_Pnos
Result  Fname,Lname(Result1 * Employee)
© UCSC
Relational Algebra

Simple and Complex Queries


using Relational Algebra

© UCSC
Relational Algebra

Company DB Schema
• Employee(Fname,Minit,Lname,Empid,Bda
te,
Address,Sex,Salary,SuperNo,Dno)
• Department(Dnum,Dname,Mgrid,Mgrdate)
• Works_on(Essn,Pno,Hours)
• Project(Pnumber,Pname,Plocation,Dnum)
• Dependent(Essn,DepenName,Sex,Bdate,
Relationship)
• Dept_locations(dnum,Location)
© UCSC
Relational Algebra

Example
• Retrieve the name and address of all
employees who work for the ‘Research’
department.
Research_Dept  Dname = ‘Research’(Department)
Research_Emps  (Research_Dept
Dnum=DnoEmployee)
Result  πFname,Lanme,Address(Research_Emps)

© UCSC
Relational Algebra

Example
• For every project located in ‘Colombo’ list
the project number, the controlling
department number and the dept manager’s
last name, address and b’date.
Colombo_Projs  Plocation = ‘Colombo’(Project)
Contr_Dept(Colombo_Projs Dnum=Dnumber Department)
Proj_Dept_Mgr (Contr_Dept MgrId=Empid Employee)
ResultπPnumber,Dnum,Lanme,Address,Bdate(Proj_Dept_Mgr)

© UCSC
Relational Algebra

Example
• Find the names of employees who work on
all the projects controlled by dept. no. 5
Dept5_Projs(Pno) πPnumber (Dnum = 5(Project))
Emp_Proj(Empid,Pno)πEssn,Pno ( Works_on)
Result_Emp_Empid(Emp_Proj÷Dept5_Proj)
ResultπLname,Fname(Result_Emp_Empid*Employee)

© UCSC
Relational Algebra

Examples
• Make a list of project numbers for projects
that involve an employee whose last name
is ‘Perera’ either as a worker or as a
manager of the dept. that controls the
project.

© UCSC
Relational Algebra

Examples
• Perera(Essn)  πEmpid (Lname = ‘Perera’ (Employee))

• Perera_Worker_Proj  πPno (Works_on * Perera)

• MgrsπLname, Dnum(Employee Empid = MgridDepartment)

• Perera_Managed_DeptsπDnum(Lname = ‘Perera’ (Mgrs))

• Perera_Mgr_Projs(Pno)πPnumber(Perera_Managed_
Depts * Project)

• Result  (Perera_Worker_Proj U Perera-Mgr_Projs)


© UCSC
Relational Algebra

Examples
• Retrieve the name of employees who have
no dependents.
All_emps  π SSN(Employee)
Emps_with_deps(SSN)  πESSN(Dependent)
Emps_without_deps(All_emps –
Emps_with_deps)
Result  πLname, Fname (Emps_without_deps *
Employee)

© UCSC
Relational Algebra

Examples
• List the names of managers who have at
least one dependent.

Mgrs(SSN)  π MGRSSN(Department)
Emps_with_deps(SSN) 
πESSN(Dependent)
Mgrs_with_deps  (Mgrs ∩
Emps_with_deps)
Result  πLname, Fname (Mgrs_with_deps *
Employee)

© UCSC
Structured Query Language

Duration : 1hr

© UCSC
Detailed Syllabus

• 4.1.Structured Query Language (SQL)


Introduction to SQL standards: SQL86, SQL89 and
SQL92.

© UCSC
What Is SQL?
• A relational database language
It is not a programming language but a
comprehensive database sub-language
language for controlling and interacting with a
database management system.
• NOT a DBMS
• A powerful data manipulation language
– It has capabilities for:
• Insertion
• Update
• Deletion
• Query
• Protection
© UCSC
What Is SQL?
• Also designed for end users

• Non-procedural
– We have to show ‘what is needed’ and not
‘how’, like in ‘relational algebra’
– Is similar more to ‘relational calculus’

• Used in two ways:


– Interactive
– Programmatic: Dynamic / Embedded

© UCSC
Role of SQL
• A database programming
SQL
Relational
DBMS
language
• A database administration
language
• A client/server language
SystemCatalog User Tables
• A distributed database
language

© UCSC
Role of SQL
• It is vendor independent.
• If a user was dissatisfied with a particular DBMS he could
switch products easily without much overhead, as both
would follow the same language standard.
• Client applications relatively portable.
• Programmer skills are portable.
• Supports many different client processes -- end-users,
applications, developers, etc.
• Database servers use SQL to request services from each
other.

© UCSC
Standard versions
of SQL
• SQL-86 or SQL1
• SQL-92 or SQL2
• SQL-99 or SQL3

(will extend SQL with object oriented and other


recent developments, such as XML)

© UCSC
Creating SQL Databases and
Tables

Duration : 3hrs

© UCSC
Detailed Syllabus

2. Creating SQL Databases and Tables (3hrs.)


1. Creating a Database: CREATE DATABASE, Creating a
database schema; Database options: Connect, Disconnect,
Select, Close, Create, Drop.
2. Defining tables and views: CREATE TABLE, ALTER TABLE,
DROP TABLE.
3. Specifying integrity constraints: PRIMARY KEY, UNIQUE,
NOT NULL, CHECK, Referential Integrity constraints (Cyclic,
Self-referencing, Multiple path) FOREIGN KEY (CASCADE,
RESTRICT, NULIFIES), DEFAULT.
4. Creating indexes: CREATE INDEX, DROP INDEX.

© UCSC
Data Manipulation using
SQL

• Define a relational database


schema in SQL

© UCSC
SCHEMA
• Early versions did not include this concept of a relational
database schema, all tables were considered part of the
same schema.
• This concept is used in SQL2 to group tables and other
constructs that belong to the same database
application.

© UCSC
• A schema is composed of
– A schema name
– Authorization identifier (To indicate user-account
who own the schema)
– Schema elements (tables,
constraints,views,domans etc…)
– CREATE SCHEMA COMPANY
AUTHORIZATION SMITH

• CREATE TABLE COMPANY.EMPLOYEE…


Will make the employee table part of the company
schema.

© UCSC
Data Manipulation using
SQL

• Explain basic elements in the


structure of an SQL
information schema

© UCSC
SQL Basics

• Data Definition Language (DDL)

• Data Manipulation Language (DML)

• Data Control Language (DCL)

© UCSC
SQL Basics
Data Definition Language (DDL)
CREATE TABLE Adds new table
DROP TABLE Removes existing tables
ALTER TABLE Modifies structure of tables
CREATE VIEW Adds a new view
DROP VIEW Removes a view
CREATE INDEX Build an index for a column
DROP INDEX Removes an index
CREATE SYNONYM Defines an alias for a database object
DROP SYNONYM Remove an alias
COMMENTS Describes a table or column
LABEL Defines a title for a table or column

DDL defines the database: Physical Design


© UCSC
Data Manipulation Language (DML)
SELECT Retrieves data
INSERT Adds new rows of data
DELETE Removes row of data
UPDATE Modifies existing data

More Data Manipulation


DECLARE Defines a cursor for query
EXPLAIN Describes data access for a query
OPEN Opens a cursor to retrieve query results
FETCH Retrieves a row of query
CLOSE Closes a cursor

DML load the database: Implementation


© UCSC
SQL Basics (cont’d)
Data Control Language (DCL)

GRANT Gives user access privileges


REVOKE Removes privileges
COMMIT Ends current transaction
ROLLBACK Aborts current transaction

DCL control the database: Maintenance

© UCSC
SQL Basics
•ANSI/ISO SQL Keywords

– ANSI/ISO specifies standard SQL keywords


which cannot be used to name databases
objects like tables, columns and users.

Note: Keywords used may varies with the different implementations


of SQL

© UCSC
Example of some
keywords

ALL COUNT FOUND MAX PRIVILEGES


AND CREATE FROM MIN REFERENCE
AVG DEFAULT GO NOT ROLLBACK
BEGIN DELETE GRANT NULL SELECT
BETWEEN DISTINCT GROUP NUMERIC SET
BY END HAVING OF SQL
C EXEC IN OR TABLE

© UCSC
Data Manipulation using
SQL

• Creating a Database:
– CREATE DATABASE, Creating a
database schema; Database options:
Connect, Disconnect, Select,
Close, Create, Drop.

© UCSC
SQL for Data Definition
SQL lets a user define the structure and
organisation of the stored data and relationships
among the stored data items.
• Commands:
– CREATE
– DROP
– ALTER

• SQL also allows for:


– Definition of indexes to make table access
faster
– Control of physical storage by DBMS
© UCSC
Command: CREATE
Function: Define new objects ( database, schema,
location, table, index and views)
• CREATE DATABASE Initial allocation of storage space to
contain database objects (not in
SQL-92)
• CREATE SCHEMA define a portion of a database that a
particular user owns
• CREATE LOCATION defines the location of the database
(distributed systems)
• CREATE TABLE defines a new table
• CREATE INDEX defines an index that enables rapid access
• CREATE VIEW defines logical table from one or more tables
or views. © UCSC
Data Manipulation using
SQL

• Defining tables and views:


CREATE TABLE, ALTER TABLE, DROP
TABLE

© UCSC
Command: CREATE TABLE
Function: Defines a new table and its columns
CREATE TABLE table-name (column-definition)
(primary-key-definition)
(foreign-key-definition)
(uniqueness-constraint)
(check-constraint)
• column definition:column-name data-type
{NOT NULL} {WITH DEFAULT}
• primary-key: PRIMARY KEY (column-name)
• foreign-key: FOREIGN KEY {rel-name} (column-
name)
• REFERENCES table-name
• {ON DELETE [RESTRICT, CASCADE, SET NULL]}
• uniqueness: UNIQUE (column-name)
• check CHECK (expression)
© UCSC
Examples of ANSI/ISO SQL Data Types
Note: Data types may varies in
different implementations of SQL

D a ta T yp e D e s c rip tio n
C H A R (length ) F ixed le ngth ch aracte r strings
C H A RA C T E R
IN T Integer num bers
IN T E G E R
S M ALLIN T S m a ll in teger num b ers
N U M E R IC (precision,scale ) Integ e r o r D e c im a l n u m b e rs
N U M B E R (precision,scale )
DE C IM AL(precision, scale )
DE C (precision,scale )
FLO AT (precision ) F loating po ints num b ers
R EAL Low -precision floa tin g po in t no.
D O U B LE P R E C IS IO N H ig h-precisio n floating po int no.

© UCSC
• Examples of Extended Data Types

-Variable-length character strings (VARCHAR)


-Money Amount (MONEY / CURRENCY)
– Dates and Times (DATE / TIMESTAMP)
– Boolean Data (LOGICAL)
– Long Text (LONG / TEXT)
– Unstructured Data (RAW)
– Asian Characters

• Data type differences across SQL implementations is one barrier to


portability

© UCSC
Data Manipulation using
SQL

• Specifying integrity
constraints: PRIMARY KEY,
UNIQUE, NOT NULL, CHECK,
Referential Integrity
constraints (Cyclic, Self-
referencing, Multiple path)
FOREIGN KEY (CASCADE, RESTRICT,
NULIFIES), DEFAULT.

© UCSC
SQL for Data Integrity- Data Integrity
Value of Stored Data can be lost in many ways:
– Invalid data added to data base
– Existing data modified to a incorrect value
– Changes made lost due to system error or power failure
– Changes partially applied

Types of integrity constraints:


– Required Data (NOT NULL)
– Validity Checking (CHECK)
– Entity Integrity (PRIMARY KEY & NOT NULL)
– Referential Integrity (FOREIGN KEY)
– Business Rules (ASSERTION, TRIGGER)
– Consistency (CASCADE, RESTRICT, SET NULL)

© UCSC
NULL Values:What are Null values?
• Null values provides a systematic way of handling missing
or inapplicable data in SQL.

• It is inevitable that in real-world, some data are missing,


not yet known or do not apply.

• Null value is not a real data value.

Special Handling
• Null values require special handling by SQL and the
DBMS. Null values can be handled inconsistently by
various SQL products
• Example: How do we handle null values in summaries like
SUM, AVERAGE, etc.?
© UCSC
Referential Integrity
Referential integrity constraints define the rules for associating rows with
each other, i.e. columns which reference columns in other tables:
Every non-null value in a foreign key must have a corresponding
value in the primary key which it references.
A row can be inserted or a column updated in the dependent table only if (1)
there is a corresponding primary key value in the parent table, or (2) the
foreign key value is set null.

Dept-No Emp-No Dept-No


D1 D7
D3 ?
D2 D1
D7 INSERT ROW D3
Department (Parent Table) ?
D7
UPDATE COLUMN D2
Employee(Dependent Table)

© UCSC
Referential Integrity

Deleting parent rows

Dept-No
D1 Emp-No Dept-No
D3 DELETE ROW D7
D2 ?
D7 CASCADE D1
Department (Parent Table) D3
RESTRICT
?
SET NULL D7
D2
Employee(Dependent Table)

© UCSC
Database designers must explicitly declare the effect if a
delete from the parent table on the dependent table:

CASCADE deletes associated dependent rows

RESTRICT will not allow delete from the parent table if there are
associated dependent rows.

SET NULL sets the value of associated dependent columns to


null values.

SET DEFAULT

© UCSC
• Employee(Emp_No, NID, Address, Salary, Gender, DOB,
First_Name, Mid_Initials, Last_Name, Dept_No, Supervisor)

CREATE TABLE Employee


(Emp_No CHAR(5) NOT NULL,
NID CHAR(10),
Address VARCHAR(50),
Salary DEC(7,2) CHECK (Salary >= 0),
Gender CHAR(1) CHECK (Gender IN (‘M’, ’F’)),
DOB DATE,

© UCSC
• Employee(Emp_No, NID, Address, Salary, Gender,
DOB, First_Name, Mid_Initials, Last_Name, Dept_No,
Supervisor)

First_Name CHAR(10),
Mid_Initials CHAR(10),
Last_Name CHAR(15) NOT NULL,
Dept_No CHAR(2) NOT NULL,
Supervisor CHAR(5),
PRIMARY KEY (Emp_No),
FOREIGN KEY (Dept_No) REFERENCES Department,
FOREIGN KEY (Supervisor) REFERENCES Employee);

© UCSC
Dependent(Emp_No, Depd_Name,Gender, DOB, Relation)

CREATE TABLE Dependent


(Emp_No CHAR(4) NOT NULL,
Depd_Name CHAR(15) NOT NULL,
Gender CHAR(1) CHECK (Gender IN (‘M’, ’F’)),
DOB DATE NOT NULL,
Relation VARCHAR(15),
PRIMARY KEY (Emp_No, Depd_Name),
FOREIGN KEY (Emp_No) REFERENCES Employee
ON DELETE CASCADE);

CONSTRAINT Dependent_PK
PRIMARY KEY (Emp_No, Depd_Name)
CONSTRAINT Dependent_FK FOREIGN KEY (Emp_No)
REFERENCES Employee (Emp_No)
© UCSC
Single-field constraint:

CONSTRAINT name
{PRIMARY KEY | UNIQUE | NOT NULL |
REFERENCES foreign-table [(foreignfield1, foreignfield2)]}

Multiple-field constraint:
CONSTRAINT name
{PRIMARY KEY (primary1[, primary2 [, ...]]) |
UNIQUE (unique1[, unique2 [, ...]]) |
NOT NULL (notnull1[, notnull2 [, ...]]) |
FOREIGN KEY (ref1[, ref2 [, ...]]) REFERENCES
foreign-table [(foreignfield1 [, foreignfield2 [, ...]])]}

© UCSC
Data Manipulation using
SQL

• Creating indexes: CREATE INDEX,


DROP INDEX

© UCSC
Command:CREATE
Create Index Command

CREATE [UNIQUE] INDEX index-name


ON table-name (field [ASC|DESC][, field [ASC|DESC], ...])
[WITH { PRIMARY | DISALLOW NULL |
IGNORE NULL }]

Example
– CREATE UNIQUE INDEX Dept_Name_IDX ON
Department (Dept_Name)

– CREATE INDEX Name_IDX ON Employee (Last_Name)

– CREATE INDEX Emp_Name_IDX ON Employee


(First_Name, Mid_Initials, Last_Name)
© UCSC
Command:DROP
Function
– Remove (erase) an existing object that is no
longer needed
DROP Command
DROP [table-name | index-name | view-name ]

Example
– DROP TABLE Dependent
– DROP INDEX Name_IDX
– DROP VIEW Emp_VIEW
Note: Most RDBMSs will ensure that users dropping different
kinds of objects must possess the authority (privileges)
© UCSC
Command:ALTER
Function
– Change the definition of an existing table.
ALTER TABLE table-name { option(s) }
{ADD column-name data-type {NOT NULL} {WITH DEFAULT},
|DELETE column-name [ , ....]
|RENAME old-column-name new-column-name [ , ....]
|MODIFY column-name column-type
|UNIQUE KEY key-name (column-list)
– |PRIMARY KEY key-name (column-list)
– |FOREIGN KEY [constraint-name ] (column-
list) REFERENCES
table-name
– [ON DELETE {RESTRICT | CASCADE | SET
NULL} ]
– |DROP PRIMARY KEY
– |DROP FOREIGN KEY constraint-name ]
– |DROP KEY key-name ]
– |DROP CHECK } © UCSC
Example

• Adding a Column
ALTER TABLE Project
ADD Proj_Manager CHAR(5)

• Changing Primary or Foreign Key


ALTER TABLE Department
DROP PRIMARY KEY
PRIMARY KEY (Dept_Name)
FOREIGN KEY (Manager) REFERENCES Employee

© UCSC
Selecting Data

Duration : 8 hrs

© UCSC
Detailed Syllabus
3. Selecting Data
1. Queries: SELECT Statement.

2. Single Table: all columns (*), selecting specific columns (RA project
operation), unique values (DISTINCT), Executing multiple statements (;),
WHERE clause (RA select operation), Including or excluding rows (=, !=),
Relational Operators (=, !=, >, >=, <, <=), Identifying Null values (IS NULL),
Where clause keywords (AND, OR, [NOT] BETWEEN, [NOT] IN, IS [NOT]
NULL, [NOT] LIKE, ORDER BY, Arithmetic Operators (+, -, *, /),
Expressions, Display Labels, Aggregate Functions: COUNT, SUM, AVG,
MAX, MIN, GROUP BY, HAVING.

3. Multiple Table: RA join and product operations, Natural Join, Multiple


Table Joins, Aliases for table names, Outer Join, UNION.

4. Functions: Arithmetic (ROUND, TRUNC), String (TO_CHAR, UPPER,


LOWER, Sub strings, Concatenation, TRIM), Date and Time (DAY,
MONTH, YEAR, DATE, CURRENT).

5. Sub queries: Nested Select Statement, Values returned by sub queries


(single value, a list of values), EXISTS, Correlated nested queries.

© UCSC
Referential Integrity
SQL data definition for defining referential integrity constraints
Parent table:
CREATE TABLE DEPARTMENT
(DEPT-NO CHAR(3),
other column definitions
PRIMARY KEY (DEPT-NO) );
Dependent table:
CREATE TABLE EMPLOYEE
( EMP-NO CHAR(5),
DEPT-NO CHAR(3)
other column definitions
PRIMARY KEY (EMP-NO),
FOREIGN KEY DEPT-N-FK (DEPT-NO)
REFERENCES DEPARTMENT
ON DELETE SET NULL) );
© UCSC
Defining referential integrity rules in the SQL DDL
is known as declarative referential integrity

Declarative referential integrity simplifies application


programming and enables enforcement at the database
server level, eliminating the possibility of programming
errors

User Defined Integrity


User defined integrity constraints can be enforced by the database
server using triggers and stored procedures.

© UCSC
Triggers and stored procedures are user written
routines which are stored and executed under the
control of the database server.
They are often coded in proprietary procedural
extensions to SQL, e.g. Sybase's Transact SQL or
Oracle's PL/SQL.

SQL for Data Manipulation


Manipulation
SQL allows a user or an application program to update
the database by adding new data, removing old data, and
modifying previously stored data.
© UCSC
Retrieval
SQL allows a user or an application program
to retrieve stored data from the database
and use it.

• Most Commonly Used Commands


– SELECT INSERT
– UPDATE DELETE

© UCSC
SQL for Data Manipulation
-High-level Language for data manipulation
-It does not require predefined navigation path

-It does not require knowledge of any key items

-It is uniform language for end-users and


programmers

-It operates on one or more tables based on set


theory, not on a record at a time.

© UCSC
Command: SELECT
Function
– Retrieves data from one or more rows. Every
SELECT statement produces a table of query
results containing one or more columns and zero
or more rows.
SELECT {[ALL, DISTINCT]}
[(select-item,), i]

• FROM (table specification,)


• {WHERE (search condition)}
• {GROUP BY (group-column,)}
• {HAVING (search condition)}
• {ORDER BY (sort specification,)}
© UCSC
Project Selected Columns Employee Names
E-No E-Name
179 Silva
857 Perera
342 Dias
Employee SELECT E-No, E-Name
FROM Employee ;
E-No E-Name D-No
179 Silva 7
857 Perera 4
342 Dias 7
Employee Names
E-No E-Name
SELECT E-No, E-Name 342 Dias
857 Perera
FROM Employee
ORDER BY E-Name ;
179 Silva

© UCSC
Restrict Rows Sales Employee
E-No E-Name D-No
179 Silva 7
342 Dias 7

SELECT *
Employee FROM Employee
E-No E-Name D-No WHERE D-No = '7' ;
179 Silva 7
857 Perera 4
342 Dias 7
Sales Employee
E-No E-Name
SELECT E-No, E-Name
179 Silva
FROM Employee
342 Dias
WHERE D-No = '7' ;

Restrict Rows and Project Columns


© UCSC
EquiJoin
Employee
Department
E-No E-Name D-No
D-No D-Name M-No
179 Silva 7
857 Perera 4 4 Finance 857
7 Sales 179
342 Dias 7

Emp-Info
E-No E-Name D-No D-No D-Name M-No
179 Silva 7 7 Sales 179
857 Perera 4 4 Finance 857
342 Dias 7 7 Sales 179

SELECT Employee.*, Department.*


FROM Employee, Department
WHERE Employee.D-No = Department.D-No ;
SELECT E.*, D.*
FROM Employee E, Department D
WHERE E.D-No = D.D-No ;
© UCSC
Inner Join

SELECT E.*, D.*


FROM Employee E
INNER JOIN Department D ON E.D-No = D.D-No;

Outer Joins: Left, Right, Full

SELECT E.*, D.*


FROM Employee E LEFT OUTER JOIN Department D ON E.D-No = D.D-No;

© UCSC
Department
D-No D-Name M-No
Employee 2 Finance 850
E-No E-Name D-No 7 Sales 179
179 Silva 7
857 Perera 4
342 Dias 7

Emp-Info
E-No E-Name D-No D-No D-Name M-No
179 Silva 7 7 Sales 179
857 Perera 4 Null Null Null
342 Dias 7 7 Sales 179
© UCSC
Emp-Info
E-No E-Name D-No D-No D-Name M-No
Null Null Null 2 Finance 850

179 Silva 7 7 Sales 179

342 Dias 7 7 Sales 179

Right Outer Join


SELECT E.*, D.*
FROM Employee E RIGHT OUTER JOIN Department D
ON E.D-No = D.D-No;
Full Outer Join
SELECT E.*, D.*
FROM Employee E FULL OUTER JOIN Department D
ON E.D-No = D.D-No;

© UCSC
Cartesian Product
Department
D-No D-Name M-No
4 Finance 857
7 Sales 179
Employee
E-No E-Name D-No
179 Silva 7
857 Perera 4
342 Dias 7

Emp-Info
SELECT E-No E-Name D-No D-No D-Name M-No
E.*, D.*
179 Silva 7 4 Finance 857
FROM
857 Perera 4 4 Finance 857
Employee E, Department D
342 Dias 7 4 Finance 857
179 Silva 7 7 Sales 179
857 Perera 4 7 Sales 179
342 Dias 7 7 Sales 179

© UCSC
SQL Data Retrieval
Basic Search Conditions
Comparison
– Equal to =
– Not equal to != or <> or ^=
– Less than to <
– Less than or equal to <=
– Greater than to >
– Greater than or equal to >=

© UCSC
SQL Data Retrieval
Basic Search Conditions (cont’d)
• Range ( [NOT] BETWEEN)

– expres-1 [NOT] BETWEEN expres-2 AND expres- 3

– Example: WEIGHT BETWEEN 50 AND 60

• Set Membership ( [NOT] IN)


– Example 1: WHERE Emp_No IN (‘E1’, ‘E2’, ‘E3’)

– Example 2: WHERE Emp_No IN (Select Emp_No


FROM Employee WHERE Dept_No=‘7’)

© UCSC
Basic Search Conditions (cont’d) :
• Pattern Matching ([NOT] LIKE)
– expres-1 [NOT] LIKE {special-register | host-
variable | string-constant}
– Example: WHERE Proj_Name LIKE
“INFORM%”

• Null Value (IS [NOT] NULL)


– Example: WHERE Proj_Name IS NOT
NULL

© UCSC
Compound Search Conditions
AND, OR and NOT
Example:
WHERE Proj_Name LIKE ‘INFORM%’ AND Emp_Name = ‘DIAS’

SQL Query Features


• Summary Queries
– Summarize data from the database. In general, summary queries use
SQL functions to collapse a column of data values into a single value
that summarizes the column. (AVG, MIN, MAX, SUM, COUNT..)

• Sub-Queries
– Use the results of one query to help define another query

© UCSC
Summarising Data
SELECT COUNT(*)
FROM Employee

Count(*)
Employee 5
E-No Job Salary D-No
179 Manager 20000 10
857 Clerk 8000 10
342 Clerk 9000 20
477 Manager 15000 30
432 Clerk 10000 30
SELECT AVG(Salary) AVG(Salary)
FROM Employee 12400
© UCSC
SELECT STATEMENT
May also contain
[GROUP BY [HAVING] ORDER BY]
GROUP BY
A result of a previous specified clause is grouped using the group
by clause.
e.g. SELECT d-no, AVG(salary)
FROM employee
GROUP BY d-no

Employee
E-No Job Salary D-No
179 Manager 20000 10 D-No AVG(Salary)
857 Clerk 8000 10 10 14,000
342 Clerk 9000 20 20 9,000
477 Manager 15000 30 30 12,500
432 Clerk 10000 30 © UCSC
[GROUP BY [HAVING] ORDER BY]

HAVING
Used for select groups that meet
specified conditions.

Always used with GROUP BY clause.


SELECT d-no, AVG(salary)
FORM employee
GROUP BY d-no
HAVING AVG(salary)>12000
Employee
E-No Job Salary D-No
179 Manager 20000 10
857 Clerk 8000 10 D-No AVG(Salary)
342 Clerk 9000 20 10 14,000
477 Manager 15000 30 30 12,500
432 Clerk 10000 30 © UCSC
Nested Queries
A sub query is SELECT statement that nest inside the WHERE
clause of another SELECT statement. The results are need in
solving the main query.
Get a list of all suppliers supplying part P2.
SELECT sname
FROM supplier
WHERE sno IN
(SELECT sno FROM supply WHERE pno = ‘P2’);

SELECT sname
FROM supplier, supply
WHERE supplier.sno = supply.sno and pno = ‘P2’;

SELECT ename , salary


FROM employee
WHERE salary = (SELECT MIN (salary) FROM employee)
© UCSC
Nested Queries Contd.
Sub queries with EXISTS
e.g. find all publishers who
publish business books

SELECT DISTINCT pub_name


FROM publishers
WHERE EXISTS
(SELECT * FROM title
WHERE pub_id = publishers.pub_id and type = “business”)

DISTINCT – will remove multiple occurrences

© UCSC
Data Insertion, Updating and
Deletion

Duration: 3 hrs

© UCSC
Detailed Syllabus
1. Inserting Data: INSERT INTO
[VALUES|SELECT] including a column list,
null values; obtaining values from a
SELECT.

2. Updating Data: UPDATE (selected columns,


selected rows, with a sub query).

3. Deleting Data: DELETE (all data, selected


data, with a sub query).

© UCSC
Command: INSERT

• Function
– Places data one or more rows into a table
– Data can also be downloaded from another
computer system or collected from other sites.

INSERT INTO table-name (column-name,),


| VALUES ([constant, NULL],)
or
| SELECT retrieval condition

© UCSC
Command: INSERT
i Single-Row Insert
INSERT INTO Employee (Emp_No, Emp_Name, Age,
Dept)
VALUES (‘E1’, ‘Dias’, 26, ‘PER’)

ii Multi-Row Insert
INSERT INTO Manager (Emp_No, Emp_Name, Age, Dept)
SELECT Emp_No, Emp_Name, Age, Dept
FROM Employee
WHERE Job = ‘Manager’

© UCSC
RESTRICT INSERT
Insert with referential
integrity
In Employee Table
CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code)

INSERT INTO Employee


VALUES (342, ‘Dias’, 26, ‘Sale’);
An employee can only be inserted if its department is
found in department table

© UCSC
RESTRICT INSERT
Department
Dept_Cod e Manager
Dep_Name
SAL Sales 179

FIN Finance 857

Employee
Emp_N o Emp_Nam e Age Dept
179 Silva 27 SAL
857 Perera 34 FIN
342 Dias 26 Sale ×
© UCSC
Command: UPDATE
• Function: Changes data in one or more rows of a
table
UPDATE table-name
SET (column-name = expression,),
WHERE search-condition

Example

UPDATE STUDCLASS
SET FEES = 1200 Selective Update
WHERE STUDNO = 1234

UPDATE STUDCLASS
SET FEES = 1200 Update All Rows

© UCSC
Command: UPDATE
Example
Update with Subquery
UPDATE Works_On
SET Hours = 12
WHERE Proj_No IN(SELECT Proj_No FROM Project
WHERE Proj_Name = ‘INFORMATION TECHNOLOGY’)

UPDATE Employee
SET Age = Age+1

© UCSC
RESTRICT UPDATE
Update with referential
integrity

In Employee Table
CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON UPDATE RESTRICT

UPDATE Department SET Dept_Code = ‘Sale’


WHERE Dept_Code = ‘SAL’
A department code can only be changed if it is not found in
employee table (i.e. no employees working for them)

© UCSC
RESTRICT UPDATE
Department
Dept_Code Dep_Name Manager

SAL
FIN
Sales
Finance
179
857
×

Employee
Emp_No Emp_Name Age Dept
179 Silva 27 SAL
857 Perera 34 FIN
342 Dias 26 SAL

© UCSC
CASCADE UPDATE
Update with referential integrity
In Employee Table
CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON UPDATE CASCADE

UPDATE Department SET Dept_Code = ‘Sale’


WHERE Dept_Code = ‘SAL’
Updating a department code will result in changing it in the
employee table (update with new department code for the
employees working for them)

© UCSC
CASCADE UPDATE
Department
Dept_Code Dep_Name Manager
Sale Sales 179
FIN Finance 857

Employee
Emp_No Emp_Name Age Dept
179 Silva 27 Sale
857 Perera 34 FIN
342 Dias 26 Sale

© UCSC
SET NULL UPDATE
Update with referential
integrity

In Employee Table

CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON UPDATE SET NULL

UPDATE Department SET Dept_Code = ‘Sale’


WHERE Dept_Code = ‘SAL’
Updating a department code will result in changing the
department code of their employees to NULL (only if NULL
values are allowed)

© UCSC
SET NULL UPDATE
Department
Dept_Code Dep_Name Manager

Sale Sales 179


FIN Finance 857

Employee
E m p _ N o E m p _ N a m e A ge D ep t
1 7 9 S ilv a 27 N U LL
8 5 7 P e re ra 3 4 F IN
3 4 2 D ia s 26 N U LL

© UCSC
SET DEFAULT UPDATE
Update with referential integrity

In Employee Table
CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON UPDATE
SET DEFAULT ‘XXX’

UPDATE Department SET Dept_Code = ‘Sale’


WHERE Dept_Code = ‘SAL’

Updating a department code will result in changing


the department code of their employees to a default
value
© UCSC
SET DEFAULT
UPDATE
Department
Dept_Code Dep_Name Manager
Sale Sales 179
FIN Finance 857

Employee
E m p _ No Emp_Name Age Dept
1 7 9 S i lv a 27 X X X
8 57 P e re ra 3 4 F IN
3 42 D i as 26 X X X

© UCSC
Command: DELETE
• Function: Removes one or more rows from a table
DELETE FROM table-name
{WHERE search-condition}

Example
DELETE FROM Employee Select Delete
WHERE Emp_No = ‘E1’

DELETE FROM Employee Delete All Rows

DELETE FROM Dependent Delete with Subquery


WHERE Emp_No = (SELECT Emp_No FROM Employee
WHERE Emp_Name = ‘Dias’)
© UCSC
RESTRICT DELETE
Delete with referential
integrity

In Employee Table

CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON DELETE RESTRICT

DELETE FROM Department


WHERE Dept_Code = ‘SAL’
A department can only be deleted if it is not found in employee
table (i.e. no employees working for them)

© UCSC
RESTRICT DELETE
Department
Dept_Code Dep_Name Manager

SAL Sales 179 ×


FIN Finance 857

Employee
Emp_No Emp_Name Age Dept
179 Silva 27 SAL
857 Perera 34 FIN
342 Dias 26 SAL

© UCSC
CASCADE DELETE
Delete with referential integrity

In Employee Table

CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON DELETE CASCADE

DELETE FROM Department


WHERE Dept_Code = ‘SAL’
Deleting a department will result in deleting it from the
employee table (delete employees working for them)

© UCSC
CASCADE DELETE
Department

Dept_Cod e Manager
Dep_Name
SAL Sales 179 ×
FIN Finance 857

Employee
Emp_No Emp_Name Age Dept
179 Silva 27 SAL ×
857 Perera 34 FIN
342 Dias 26 SAL ×
© UCSC
SET NULL DELETE
Delete with referential integrity

In Employee Table
CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON DELETE SET NULL

DELETE FROM Department


WHERE Dept_Code = ‘SAL’
Deleting a department will result in changing the
department of their employees in the employee table to
NULL (only if NULL values are allowed)

© UCSC
SET NULL DELETE
Department
Dept_Code Dep_Name Manager

SAL Sales 179


×
FIN Finance 857

Employee
E m p _ No E m p _ N am e A ge D e pt
1 7 9 S ilv a 27 N U L L
8 5 7 P erera 3 4 F IN
3 4 2 D ia s 26 N U LL

© UCSC
SET DEFAULT
DELETE
Delete with referential integrity

In Employee Table
CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON DELETE
SET DEFAULT ‘XXX’

DELETE FROM Department


WHERE Dept_Code = ‘SAL’
Deleting a department will result in changing the
department of their employees in the employee table to a
specified default value
© UCSC
SET DEFAULT DELETE
Department
Dept_Code D ep_Name Manager

SAL Sales 179 ×


FIN Finance 857

Employee
Emp_No Emp_Name Age Dept
1 7 9 S i lv a 27 X X X
8 5 7 P e re ra 3 4 F IN
3 4 2 D i as 26 X X X

© UCSC
Database Management
Systems
Views

Dr. Jeevani Goonetillake


UCSC

© 2010, University of Colombo School


of Computing
External Layer
View View View

Conceptual Layer
Base Tables

Physical Layer

Stored Tables ...


© 2010, University of Colombo School
of Computing
Table
Architecture
Conceptual Layer
Table

• The conceptual model is a logical


representation of the entire contents of the
database.
• The conceptual model is made up of base
tables.
• Base tables are “real” in that they contain
physical records.
© 2010, University of Colombo School
of Computing
Architecture Conceptual Layer
Department
Dept_Code Dep_Name Manager
SAL Sales 179
FIN Finance 857
Employee
Emp_No Emp_Name Designation DOB Dept
179 Silva Manager 12-05-74 SAL
857 Perera Accountant 01-04-67 FIN
342 Dias Programmer 25-09-74 SAL
Base Tables
© 2010, University of Colombo School
of Computing
Architecture
View
External Layer
View

• The external model represents how data is


presented to users.
• It is made up of view tables. View tables
are "virtual"-- they do not exist in physical
storage, but appear to a user as if they did

© 2010, University of Colombo School


of Computing
External Layer
Department_View
Dept_Code Dep_Name Manager
SAL Sales Silva
FIN Finance Perera
Employee_View
Emp_No Emp_Name Designation Age Dept
179 Silva Manager 27 SAL
857 Perera Accountant 34 FIN
342 Dias Programmer 26 SAL
© 2010, University of Colombo School
of Computing
View Tables
Emp_Personnel
External Layer
Emp_No Emp_Name Designation Age Dept
179 Silva Manager 27 Sales
857 Perera Accountant 34 Finance
342 Dias Programmer 26 Sales

View Tables
Department Employee
Dept_Code Dep_Name Manager Emp_No Emp_Name Designation DOB Dept
179 Silva Manager 12-05-74 SAL
SAL Sales 179
857 Perera Accountant 01-04-67 FIN
FIN Finance 857
342 Dias Programmer 25-09-74 SAL

Base Tables
© 2010, University of Colombo School
of Computing
What Are User views?
A view is a “Virtual Table”. In SQL terminology,
view is a single table that is derived from other
tables.
• User views
– Derived or virtual tables that are visible to
users
– Do not occupy any storage space
• Base Tables
– Store actual rows of data
– Occupy a particular amount of storage space
© 2010, University of Colombo School
of Computing
Characteristics of User views
• Behave as if it contains actual rows of data,
but in fact contains none.
• Rows are derived from base table or tables
from which the view is defined.
• Being virtual tables the possible update
operations that can be applied to views are
limited. However, it does not provide any
limitations on querying a view.

© 2010, University of Colombo School


of Computing
SQL and User Views
Creating a View

CREATE VIEW view-name


(list of attribute names, )
AS query

© 2010, University of Colombo School


of Computing
SQL User Views
• Column names specified must have the
same number of columns derived from the
query
• Data definitions for each column are derived
from the source table
• Columns will assume corresponding column
names in the source table. Names must be
specified for calculated or identical columns.

© 2010, University of Colombo School


of Computing
Specification of Views

Works_On1
Fname Lname Pname Hours

CREATE VIEW Works_On1 AS


SELECT Fname, Lname, Pname, Hours
FROM Employee, Project, Works_On
WHERE Essn = Empid
AND Pno = Pnumber ;

© 2010, University of Colombo School


of Computing
Specification of Views
Dept_Info

Dept_name No_Of_Emps Total_Sal

CREATE VIEW Dept_Info (Dept_Name,


No_Of_Emps, Total_Sal) AS
SELECT Dname, COUNT(*), SUM(Salary)
FROM Department, Employee
WHERE Dnumber = Dno
GROUP BY Dname ;
© 2010, University of Colombo School
of Computing
Specification of Views
• Retrieve the last name and first name of all
employees who work on ‘ProjectX’.

SELECT Fname, Lname


From Works_On1
WHERE Pname = ‘ProjectX’ ;

© 2010, University of Colombo School


of Computing
Why User views?
Benefits
Security
Protect data from unauthorized access.
Each user is given permission to access
the database via only a small set of
views that contain specific data the user
is authorized to see.

© 2010, University of Colombo School


of Computing
User views
Query Simplicity
Turning multiple table queries to single
table queries against views, by drawing data
from several tables. It provides flexible and
powerful data access capabilities.

© 2010, University of Colombo School


of Computing
User views
Query Simplicity contd.
It also improves productivity of end-user and
programmers by:
– Simplifying database access by presenting the
structure of data that is most natural to the user.
– Simplifying the use of routine and repetitive
statements

© 2010, University of Colombo School


of Computing
User views

Natural Interface
“Personalized” view of database structure, that
make sense for the user. Restructure or tailor
the way in which tables are seen, so that
different users see it from different
perspectives, thus allowing more natural
views of the same enterprise (e.g. item names)

© 2010, University of Colombo School


of Computing
User views
Insulation from change
Data independence - maintain independence
among different user views and between
each user view and the physical constructs.

A view can present a consistent image of


the database structure, even if the
underlying source tables are restructured.

© 2010, University of Colombo School


of Computing
User view Design Considerations

• User view design is driven by specific


application requirements

• User may be defined for individual user, or


a group of users, of the transaction or
application

© 2010, University of Colombo School


of Computing
Design Considerations
• User view may be defined to control and
restrict access to specific columns and/or rows
in one or more tables
• User views can be defined to help simplify
queries, application development and
maintenance
• User views may be derived from base tables
or other user views

© 2010, University of Colombo School


of Computing
Remove a User View

Drop a View
DROP VIEW view-name
E.g.
DROP VIEW Emp_Payroll

Removes only the definition of the view table.


Data that it used to retrieve is not affected.

© 2010, University of Colombo School


of Computing
View Implementation
• Two main approaches have been suggested for
efficiently implementing a view for querying.
• query modification
• view materialization

© 2010, University of Colombo School


of Computing
Query Modification

• Involves modifying the view query into a query on


the underlying base tables. For example:
SELECT Fname, Lname
From Works_On1
WHERE Pname = ‘ProjectX’ ;

SELECT Fname, Lname


From Employee, Project, Works_On
WHERE Empid = Essn AND Pno = Pnumber
AND Pname = ‘ProjectX’ ;
© 2010, University of Colombo School
of Computing
Query Modification

• The disadvantage of this approach is that it is


inefficient for views defined via complex
queries that are time consuming to execute.

© 2010, University of Colombo School


of Computing
View Materialization
• Involves physically creating a temporary view
table when the view is first queried and
• Keeping the table on the assumption that other
queries on the view will follow.
• An efficient strategy for automatically updating
the view table when the base tables are updated
must be developed – incremental update.
• The view is kept as long as it is being queried.

© 2010, University of Colombo School


of Computing
View Update
• Updating of views is complicated and can be
ambiguous.

• An update on a view defined on a single table without


any aggregate functions can be mapped to an update
on the underlying base table under certain conditions.

• For a view involving joins, an update operation may


be mapped to update operations on the underlying
base relations in multiple ways.

© 2010, University of Colombo School


of Computing
View Update
• Consider the view Works_On1 and issue command to update
the Pname attribute of ‘Sunil Perera’ from ‘ProductX’ to
‘ProductY’.

UPDATE Works_On1
SET Pname = ‘ProductY’
WHERE Lname = ‘Perera’ AND Fname = ‘Sunil’
AND Pname = ‘ProductX’;

This query can be mapped into several updates on the


base relations to give the desired update effect on the
view.

© 2010, University of Colombo School


of Computing
View Update
a) UPDATE Works_On
SET Pno = ( SELECT Pnumber
FROM Project
WHERE Pname = ‘ProductY’
WHERE Essn IN (SELECT Empid
FROM Employee
WHERE Lname = ‘Perera’ AND Fname = ‘Sunil’)
AND Pno = (SELECT Pnumber
FROM Project
WHERE Pname = ‘ProductX’ ) ;
b) UPDATE Project
SET Pname = ‘ProductY’
WHERE Pname = ‘ProductX’ ;

© 2010, University of Colombo School


of Computing
View Update
• A view update is feasible when only one possible
update on the base relations can accomplish the
desired update effect on the view.

• Whenever an update on the view can be mapped to


more than one update on the underlying base
relations, there must be a certain procedure for
choosing the desired update.

© 2010, University of Colombo School


of Computing
With Check Option
Migrating rows
When a row is altered such that it no longer satisfies WHERE
condition then it will disappear from the view. New rows will appear
within the as a result of update or insert statement. Rows that enter
or leave a view are called migrating rows.

• WITH CHECK OPTION clause of the CREATE VIEW statement


prohibits a row migrating out of the view.

• Ensures that if a row fails to satisfy WHERE clause of


defining query, it is not added to underlying base table

31
Eg:
CREATE VIEW Emp_View AS
SELECT *
FROM Employee
WHERE Dept = ‘SAL’
WITH CHECK OPTION

If we now attempt to update the Department of one of the rows


from SAL to FIN for example ;
UPDATE Emp_View
SET Dept = FIN
WHERE Emp_no = 179

This would cause the row to migrate from this view. But WITH
CHECK OPTION clause in the definition of the view prevents
this from happening

32
Limitations of User views

Restrictions on views processing


SELECT, INSERT, UPDATE and DELETE
statements may refer to views, but there are
a number of limitations.

Update may be possible for ‘simple’ views


but not ‘complex’ views.

33
Limitations
Performance
DBMS must translate queries against the
view to queries against the source tables.
These disadvantages means that we
cannot indiscriminately define and use
views instead of source tables.

34
Database Security
Duration: 2hrs

Introduction and characteristics of


user views

© UCSC
Detailed Syllabus

• Characteristics of user views.

• View definition and use: CREATE VIEW, DROP VIEW

• Database Security: GRANT, REVOKE

© UCSC
External Layer
View View View

Conceptual Layer

Base Tables

Physical Layer

Stored Tables ...

© UCSC
Architecture
Table

Conceptual Layer
Table

• The conceptual model is a logical


representation of the entire contents of the
database.
• The conceptual model is made up of base
tables.
• Base tables are “real” in that they contain
physical records.

© UCSC
Architecture
Conceptual Layer
Department
Dept_Code Dep_Name Manager
SAL Sales 179
FIN Finance 857
Employee
Emp_No Emp_Name Designation DOB Dept
179 Silva Manager 12-05-74 SAL
857 Perera Accountant 01-04-67 FIN
342 Dias Programmer 25-09-74 SAL
Base Tables
© UCSC
Architecture
View
External Layer
View

• The external model represents how data is


presented to users.
• It is made up of view tables. View tables
are "virtual"-- they do not exist in physical
storage, but appear to a user as if they did

© UCSC
External Layer
Department_View
Dept_Code Dep_Name Manager
SAL Sales Silva
FIN Finance Perera
Employee_View
Emp_No Emp_Name Designation Age Dept
179 Silva Manager 27 SAL
857 Perera Accountant 34 FIN
342 Dias Programmer 26 SAL
View Tables
© UCSC
Emp_Personnel External Layer
Emp_No Emp_Name Designation Age Dept
179 Silva Manager 27 Sales
857 Perera Accountant 34 Finance
342 Dias Programmer 26 Sales

Emp_Payroll
Emp_No Emp_Name Designation Dept_Name
179 Silva Manager Sales
857 Perera Accountant Finance
342 Dias Programmer Sales

© UCSC
Emp_Pay External Layer
Emp_No Emp_Name Designation Dept
179 Silva Manager SAL
857 Perera Accountant FIN
342 Dias Programmer SAL
View Tables
Employee Base Tables
Emp_No Emp_Name Designation DOB Dept
179 Silva Manager 12-05-74 SAL
857 Perera Accountant 01-04-67 FIN
342 Dias Programmer 25-09-74 SAL

© UCSC
Emp_Personnel External Layer
Emp_No Emp_Name Designation Age Dept
179 Silva Manager 27 Sales
857 Perera Accountant 34 Finance
342 Dias Programmer 26 Sales
View Tables

Department Employee
Dept_Code Dep_Name Manager Emp_No Emp_Name Designation DOB Dept
179 Silva Manager 12-05-74 SAL
SAL Sales 179
857 Perera Accountant 01-04-67 FIN
FIN Finance 857
342 Dias Programmer 25-09-74 SAL

Base Tables
© UCSC
User view Designed for Application
APPLICATION Program Program Program Program Program
PROGRAMS 1 2 3 4 5

APPLICATION Userview Userview Userview


USERVIEWS 1 2 3

BASE Table Table Table


TABLES 1 2 3

© UCSC
What Are User views?
A view is a “Virtual Table”
• User views
– Derived or virtual tables that are visible to
users
– Do not occupies any storage space
• Base Tables
– Store actual rows of data
– Occupies a particular amount of storage
space
© UCSC
Characteristics of User views

• Behave as if it contains actual rows of


data, but in fact contains none.
• Rows are derived from base table or
tables from which the view is defined.
• Like base tables, views can be queried,
updated, inserted into and deleted from,
with restrictions.

© UCSC
Characteristics of User views...

• Integrity constraints and triggers cannot


be defined explicitly for views
• Usually designed for end users thus
providing natural interfaces

© UCSC
Database Security
Duration: 2hrs

View Definition and Use

© UCSC
SQL and User Views
Creating a View

CREATE VIEW view-name


(column-name, )
AS query

© UCSC
SQL User Views
• Column names specified must have the
same number of columns derived from
the query
• Data definitions for each column are
derived from the source table
• Columns will assumed corresponding
column names in the source table.
Names must be specified for calculated
or identical columns.
© UCSC
Mechanics of Views
• A view's definition is represented by
storing in the data dictionary the text of
query that defines the view

CREATE VIEW Emp_View AS


SELECT Emp_No, Emp_Name, Age, Dept_Name
FROM Employee, Department
WHERE Emp.Dept = Dept.Dept_Code
and Dept.Dept_Code = ‘SAL’;

© UCSC
Emp_View External Layer
Emp_No Emp_Name Age Dept
179 Silva 27 Sales
342 Dias 26 Sales

View Tables
Base Tables
Department Employee
Dept_Code Dep_Name Manager Emp_No Emp_Name Designation DOB Dept
179 Silva Manager 12-05-74 SAL
SAL Sales 179
857 Perera Accountant 01-04-67 FIN
FIN Finance 857
342 Dias Programmer 25-09-74 SAL

© UCSC
User View Access

SELECT * FROM Emp_View


WHERE Designation=‘Programmer’

Emp_View
Emp_No Emp_Name Designation DOB Dept
179 Silva Manager 12-05-74 SAL ×
342 Dias Programmer 25-09-74 SAL

© UCSC
Types of User views

Selection (Horizontal or Row)

CREATE VIEW Sales_Employees AS


SELECT *
FROM Employee
WHERE Dept = ‘SAL’

© UCSC
Types of User views

Projection (Vertical or Column)

CREATE VIEW Emp_Info AS


SELECT Emp_No, Emp_Name, Designation
FROM Employee

© UCSC
Types of User views

Row/Column

CREATE VIEW Sales_Emp_Info AS


SELECT Emp_No, Emp_Name, Designation
FROM Employee
WHERE Dept = ‘SAL’

© UCSC
Types of User views

Summarised

CREATE VIEW Dept_Employees


(Dept_Code, No_Employees) AS
SELECT Dept, COUNT(*)
FROM Employee
GROUP BY Dept

© UCSC
Types of User views
Derive

CREATE VIEW Emp_Age_View AS


SELECT *, YEAR(CURRENT)-
YEAR(DOB) AS Age
FROM Employee
GROUP BY Dept

NOTE: CURRENT gives the system date


YEAR is a built in function: returns a four digit
integer that represent the year

© UCSC
Types of User views
Derive

CREATE VIEW Item_Price AS


SELECT *, Dol_Price*90 AS Rs_Price
FROM Items

© UCSC
Types of User views
Joined

CREATE VIEW Emp_Payroll AS


SELECT Emp_No, Emp_Name, Designation,
Dept_Name
FROM Employee E, Department D
WHERE E.Dept = D.Dept_Code

© UCSC
Why User views?
Benefits
4 Security
Protect data from unauthorized
access. Each user is given
permission to access the database
via only a small set of views that
contain specific data the user is
authorized to see.

© UCSC
User views
Benefits
4 Query Simplicity
Turning multiple table queries to
single table queries against views, by
drawing data from several tables. It
provides flexible and powerful data
access capabilities.

© UCSC
User views
Benefits
4 Query Simplicity contd.
It also improves productivity of end-user and
programmers by:
– Simplifying database access by presenting the
structure of data that is most natural to the user.
– Simplifying the use of routine and repetitive
statements
– Building up SELECT statements in several steps.

© UCSC
User views
Benefits
4 Natural Interface
“Personalized” view of database
structure, that make sense for the
user. Restructure or tailor the way
in which tables are seen, so that
different users see it from different
perspectives, thus allowing more
natural views of the same
enterprise (e.g. item names)

© UCSC
User views
Benefit
4 Insulation from change
Data independence - maintain
independence among different user
views and between each user view and
the physical constructs
A view can present a consistent image
of the database structure, even if the
underlying source tables are
restructured.

© UCSC
User views
Benefit

4 Data Integrity
DBMS can check data to ensure
that it meets specified integrity
constraints.

© UCSC
User view Design Considerations
• User view design is driven by specific
application requirements

• User may be defined for individual user,


or a group of users, of the transaction
or application

© UCSC
Design Considerations
• User view may be defined to control
and restrict access to specific
columns and/or rows in one or more
tables
• User views can be defined to help
simplify queries, application
development and maintenance
• User views may be derived from base
tables or other user views
© UCSC
Limitations of User views
Restrictions on views processing
SELECT, INSERT, UPDATE and
DELETE statements may refer to views,
but there are a number of limitations.
Update may be possible for ‘simple’
views but not ‘complex’ views.

© UCSC
Limitations

Performance
DBMS must translate queries against
the view to queries against the source
tables.
These disadvantages means that we
cannot indiscriminately define and use
views instead of source tables.

© UCSC
Remove a User View

Drop a View
DROP VIEW view-name
E.g.
DROP VIEW Emp_Payroll

Removes only the definition of the view table.


Data it used to retrieve is not effected.

© UCSC
Database Security
Duration: 2hrs

SQL Security

1
Database Security
Refers to protecting the database
from unauthorised or malicious use.

• Theft of information
• Unauthorised modification of data
• Unauthorised destruction of data

2
Database Security
A view is a mean of providing a user
with a personalised model of the
database.
It is also a useful way of limiting a
user’s access to various portions of
the database.
This simplifies system usage while
promoting security.
3
Types of View Access
• Read authorisation
– allows reading, but not
modification of data
• Insert authorisation
– allows insertion of new data,but no
modification of data
– insertion can be for some of the
visible attributes and the remaining
will take default or NULL values
4
Types of View Access
• Update authorisation
– allows modification of data but not
deletion
– modifications can be for some of the
visible attributes
• Delete authorisation
– allows deletion of data
• A user may be assigned all, none
or a combination of these types of
authorisation.
5
SQL for Data Control

Security and Access Control

• Commands:
– GRANT
– REVOKE

6
SQL for Data Control
Security and Access Control

• Based on three central objects:


– Users
– Database objects
– Privileges
(select, insert, update, delete,
references)
7
GRANT
• Function:
– Specify privileges for users on
database objects
GRANT <privilege list>
ON <relation or view>
TO <user list>

GRANT SELECT, GRANT UPDATE(Designation)


INSERT ON Employee
ON Employee TO Silva, Dias
TO Silva 8
GRANT
The SQL references privilege is granted
on specific attributes (as for update). This
allows a user to create relations that
reference an attribute (key) of a relation as
foreign key.
GRANT REFERENCES(Emp_No)
ON Employee
TO Silva
9
Command:REVOKE
• Function:
– Remove privileges from users on
database objects

REVOKE <privilege list>


ON <relation or view>
FROM <user list>

10
REVOKE
REVOKE SELECT
ON Employee
FROM Silva

REVOKE UPDATE(Designation)
ON Employee
FROM Silva

11
SQL-92
• The SQL-92 standard specifies a
primitive authorisation mechanism for
the database schema.
• Only the owner of the schema can
carry out any modification to the
schema.
creating or deleting relations, adding or
dropping attributes of relations, adding
or dropping indices.
12
Data Security

Dr.Jeevani Goonetillake
UCSC

© University of Colombo School of Computing


1
Introduction to Database Security Issues

• Types of Security
– Legal and ethical issues
– Policy issues
– System-related issues
– Multiple security levels

© University of Colombo School of Computing


2
Introduction to Database Security Issues

Threats to databases
- Loss of integrity
- Loss of availability
- Loss of confidentiality

Objectives to be considered when designing a


secure database application:
– Integrity
– Availability
– Secrecy

© University of Colombo School of Computing


3
Introduction to Database Security Issues

To protect databases against these types of


threats four kinds of counter measures can be
implemented :
▪ access control,
▪ inference control,
▪ flow control and
▪ encryption.

© University of Colombo School of Computing


4
Database Security and the DBA

• The DBA is the central authority for managing


a database system.

• DBA’s responsibilities include granting


privileges to users who need to use the system
and classifying users and data in accordance
with the policy of the organisation.

© University of Colombo School of Computing


5
Database Security and the DBA

• DBA-privileged commands include the commands


for performing the following types of actions:

– Account creation

– Privilege revocation
– Security level assignment

© University of Colombo School of Computing


6
Access Control
• A DBMS offers two main approaches to access
control:
– Discretionary access control
Govern the access of users to information on the basis of
user’s identity and predefined discretionary “rules” defined
by the security administrator
The rules specify, for each user and object in the system, the
types of access the user is allowed for the object
– Mandatory access control
Govern the access to the information by the individuals on
the basis of the classification of subjects and objects in the
system.
© University of Colombo School of Computing
7
Discretionary Access Control
The typical method of enforcing discretionary
access control in a database system is based
on the granting and revoking privileges.

© University of Colombo School of Computing


8
Types of Discretionary Privileges

• The account level: At this level, the DBA


specifies the particular privileges that each
account holds independently of the relations in
the database.

• The relation (or table level): At this level, the


DBA can control the privilege to access each
individual relation or view in the database.

© University of Colombo School of Computing


9
Account Level Privileges
The privileges at the account level apply to the
capabilities provided to the account itself and can
include
– CREATE SCHEMA or CREATE TABLE privilege, to
create a schema or base relation;
– CREATE VIEW privilege;
– ALTER privilege, to apply schema changes such as adding
or removing attributes from relations;
– DROP privilege, to delete relations or views;
– MODIFY privilege, to insert, delete, or update tuples;
– SELECT privilege, to retrieve information from the
database by using a SELECT query.

Not defined as part of SQL2


© University of Colombo School of Computing 10
Relation Level Privileges
• The second level of privileges applies to the relation
level, whether they are base relations or virtual (view)
relations.

• In SQL the following types of privileges can be


granted on each individual relation R:

– SELECT (retrieval or read) privilege on R : This gives the


account, the privilege to use the SELECT statement to
retrieve tuples from R.

– MODIFY privileges on R : This gives the account the


capability to modify tuples of R. In SQL this privilege is
further divided into UPDATE, DELETE, and INSERT
privileges to apply the corresponding SQL command to R.
© University of Colombo School of Computing
Relation Level Privileges

• REFERENCES privilege on R: This gives the account the


capability to reference relation R when specifying integrity
constraints. The privilege can also be restricted to specific
attributes of R.

© University of Colombo School of Computing


Modify Privilege
• Insert authorisation
– allows insertion of new data, but no
modification of data.
– insertion can be for some of the specified
attributes and the remaining will take default
or NULL values.

. Update authorisation
- allows modification of data but not deletion
- modifications can be for the specified
attributes. 13
© University of Colombo School of Computing
Modify Privilege

Delete authorisation
– allows deletion of data

• A user may be assigned all, none or a


combination of these types of authorisation.

© University of Colombo School of Computing


Discretionary Access Control
• In SQL2, the DBA can assign and owner to a whole
schema by creating the schema and associating the
appropriate authorization identifier with that schema,
using the CREATE SCHEMA command.

• The owner account holder can pass privileges on any


of the owned relation to other users by granting
privileges to their accounts.

© University of Colombo School of Computing


Example

Suppose that the DBA creates four accounts -- A1, A2, A3, and
A4-- and wants only A1 to be able to create base relations;
then the DBA must issue the following GRANT command in
SQL:

GRANT CREATETAB TO A1;

In SQL2 the same effect can be accomplished by having the


DBA issue a CREATE SCHEMA command as follows:

CREATE SCHEMA EXAMPLE AUTHORIZATIONA1;

© University of Colombo School of Computing


Example
User account A1 can create tables under the schema
called EXAMPLE.

Suppose that A1 creates the two base relations


EMPLOYEE and DEPARTMENT;
A1 is then owner of these two relations and hence all
the relation privileges on each of them.

© University of Colombo School of Computing


Granting Privileges
• GRANT command:
– Specify privileges for users on database objects.
GRANT <privilege list>
ON <relation or view>

GRANT UPDATE(Designation)
ON Employee
TO A2, A3
GRANT SELECT, INSERT
ON Employee
TO A2

© University of Colombo School of Computing 18


Revoking Privileges

• REVOKE Command:
– Remove privileges from users on database objects.

REVOKE <privilege list>


ON <relation or view>
FROM <user list>

© University of Colombo School of Computing


Revoking Privileges

REVOKE SELECT
ON Employee
FROM A2

REVOKE UPDATE(Designation)
ON Employee
FROM A2

© University of Colombo School of Computing


Revoking Privileges

• The revocation of a privilege from a user may cause


other users also to lose that privilege. This behavior is
called cascading of the revoke.

• The REVOKE statement may also specify


RESTRICT. In this case, an error is returned if there
are any cascading revokes, and the revoke action is
not carried out.

© University of Colombo School of Computing


Propagation of Privileges

• Whenever the owner A of a relation R grants a


privilege on R to another account B, the privilege can
be given to B with or without the GRANT OPTION.

• If the GRANT OPTION is given B can also grant that


privilege on R to other accounts.
GRANT SELECT ON Employee, Department TO B WITH
GRANT OPTION;

GRANT SELECT ON Employee TO C;

© University of Colombo School of Computing


Example
Suppose that A1 wants to give back to A4 a limited capability
to SELECT from the EMPLOYEE relation and wants to allow
A4 to be able to propagate the privilege.

The limitation is to retrieve only the NAME, BDATE, and


ADDRESS attributes and only for the tuples with DNO=5.

© University of Colombo School of Computing


Example
A1 has to create a view:
CREATE VIEW A4EMPLOYEE AS
SELECT NAME, BDATE,ADDRESS
FROM EMPLOYEE
WHERE DNO = 5;

After the view is created, A1 can grant SELECT on theview


A3EMPLOYEE to A4 as follows:

GRANT SELECT ON A4EMPLOYEE TOA4


WITH GRANT OPTION;

© University of Colombo School of Computing


Example
Finally, suppose that A1 wants to allow A4 to update
only the SALARY attribute of EMPLOYEE;

A1 can issue:

GRANT UPDATE ON EMPLOYEE (SALARY) TO A4;

© University of Colombo School of Computing


Example
• A bank maintains a database to keep track of
customer, branch, account and loan information.
corresponding bank relational schema is given below.

– Branch(BranchName, Code, City, Assets)


– Account(AcctNo, Balance, Acc-type, BranchName)
– Loan(LoanNo, Amount, Loan-type, BranchName)
– Customer(CustomerNo, Name, Address, Phone)
– C_A(CustomerNo, AcctNo)
– C_L(CustomerNo, LoanNo)
© University of Colombo School of Computing
Example
• Privileges are granted to users of the database as
described in the questions given below and as shown
in the authorisation diagram.

Sarath Prasad Pasan

DBA
Kapila

Aruna

© University of Colombo School of Computing


Example
1. User Sarath is able to retrieve the customer details
of each customer at the Colombo branch along with
his AcctNo and Balance and is able to update phone
and address information of each customer. Write
SQL statements to allow this.

2. Kapila is able to retrieve the name of each customer


who has a loan but does not have an account at the
bank.

© University of Colombo School of Computing


Example
3. Prasad is able to retrieve the following:
- AcctNo, the name and the account balance of each customer
who has a bank balance greater than Rs: 10,000 at the
Colombo branch in such account and
- LoanNo, the name and the loan amount of each customer at
the Colombo branch who only has loans but no accounts at
the bank.

4. To revoke the privileges of Sarath, the following command is


issued
REVOKE SELECT, UPDATE(Address, Phone) ON
customer_account FROM Sarath
RESTRICT;
Explain the impact of it on the users Prasad and Pasan.

© University of Colombo School of Computing


Role-based access control
(RBAC)
• Permissions are associated with roles, and
users are made members of appropriate roles
thereby acquiring the roles' permissions. This
greatly simplifies management of
permissions.

© University of Colombo School of Computing


Role-based access control
(RBAC)
• Roles are created for the various job functions in an
organization and users are assigned roles based on
their responsibilities and qualifications.
• Users can be easily reassigned from one role to
another.
• Roles can be granted new permissions as new
applications and systems are incorporated, and
permissions can be revoked from roles as needed.

© University of Colombo School of Computing


Creating a Role
CREATE ROLE product_manager;
CREATE ROLE hr_manager;

• A layer of security can be added to roles by


specifying a password, as in the following example:

CREATE ROLE overall_manager IDENTIFIED by


manager_password;

© University of Colombo School of Computing


Granting Privileges to Roles

• Both system and object privileges can be granted


to a role.
• A role can be granted to another role.

GRANT SELECT, INSERT, UPDATE, DELETE ON


Product TO product_manager;

GRANT CREATE USER TO hr_manager;

GRANT product_manager, hr_manager TO


overall_manager;

© University of Colombo School of Computing


Granting Roles to a User

• GRANT overall_manager TOA1;

To grant a role, you must


– have been granted the role with the ADMIN OPTION or
– have been granted the GRANT ANY ROLE system
privilege or
– you must have created the role.

• GRANT overall_manager TOA1


WITH ADMIN OPTION;

© University of Colombo School of Computing


Revoking Roles
• Revoking a Role from a User

The following statement revokes the role overall_manager


from the user A1:

REVOKE overall_manager FROM A1;

• Revoking a System Privilege from a Role

The following statement revokes the CREATE TABLE system


privilege from the overall_manager role:

REVOKE CREATE TABLE FROM overall_manager;

© University of Colombo School of Computing


Revoking Roles

• Revoking a Role from a Role

To revoke the role hr_manager from the role


overall_manager, issue the following statement:

REVOKE hr_manager FROM overall_manager;

© University of Colombo School of Computing


Dropping a Role
• Specify the name of the role to be dropped.
DROP ROLE hr_manager;

© University of Colombo School of Computing


Setting a Role
• A user who has been granted one or more roles
has to invoke the SET ROLE command to
enable or disable roles for the current user
session.
• If the role has a password, you must also specify
the password to enable the role by using the
IDENTIFIED BY clause.

© University of Colombo School of Computing


Setting a Role
• Example 1: To activate the role accountant having a
password
– SET ROLE accountant IDENTIFIED BY acct

• Example 2: To disable all roles granted to you for the


current session, issue the following statement:

– SET ROLE NONE

© University of Colombo School of Computing


Default Roles
• It is possible to provide a facility to set up a default
list of roles to be activated at the time of user login.
• This facility is enabled through the use of DEFAULT
ROLE clause of the ALTER USER command.

© University of Colombo School of Computing


Default Roles
• Example : To make accountant role as the default
active role for A1
– ALTER USER A1 DEFAULT ROLE accountant
• Example : To make all authorized roles for A1 part of
his default active role set except the auditor role
– ALTER USER Scott DEFAULT ROLE ALL EXCEPT
auditor;
• Example : To remove all roles from A1's default
active role set
– ALTER USER A1 DEFAULT ROLE NONE;

© University of Colombo School of Computing


Mandatory Access Control
• This is an all-or-nothing method: A user either has
or does not have a certain privilege.
• In many applications, and additional security
policy is needed that classifies data and users
based on security classes.
• This approach as mandatory access control,
would typically be combined with the
discretionary access control mechanisms.

© University of Colombo School of Computing


Mandatory Access Control
• In many applications, and additional security
policy is needed that classifies data and users
based on security classes.
• This approach as mandatory access control,
would typically be combined with the
discretionary access control mechanisms.

© University of Colombo School of Computing


Mandatory Access Control

Typical security classes are


top secret (TS),
secret (S),
confidential (C), and
unclassified (U),

where TS is the highest level and U the lowest:


TS ≥ S ≥ C ≥ U
© University of Colombo School of Computing
Mandatory Access Control

A multilevel relation schema R with n


attributes would be represented as

R(A1,C1,A2,C2, …, An,Cn,TC)

where each Ci represents the classification


attribute associated with attribute Ai.

© University of Colombo School of Computing


Mandatory Access Control

© University of Colombo School of Computing


Mandatory Access Control

A multilevel relation will appear to contain different


data to subjects (users) with different clearance
levels.
In some cases, it is necessary to store two or more
tuples at different classification levels with the same
value for the apparent key.
This leads to the concept of polyinstantiation where
several tuples can have the same apparent key value
but have different attribute values for users at
different classification levels.

© University of Colombo School of Computing


Polyinstantiation
• Polyinstantiation is a database technique that
allows the database to contain different tuples
with the same key but with different
classifications.

• Polyinstantiation occurs because of mandatory


policy.

© University of Colombo School of Computing


Statistical
Database Security (Inference Control)
• Statistical databases are used mainly to produce
statistics on various populations.
• The database may contain confidential data on
individuals, which should be protected from user
access.
• Users are permitted to retrieve statistical information
on the populations, such as averages, sums, counts,
maximums, minimums, and standard deviations.

© University of Colombo School of Computing


Statistical
Database Security

• A population is a set of tuples of a relation (table)


that satisfy some selection condition.
• Statistical queries involve applying statistical
functions to a population of tuples.

© University of Colombo School of Computing


Statistical
Database Security
• Statistical users are not allowed to retrieve individual
data, such as the income of a specific person.
Statistical database security techniques must prohibit
the retrieval of individual data.

• This can be achieved by prohibiting queries that


retrieve attribute values and by allowing only queries
that involve statistical aggregate functions such as
COUNT, SUM, MIN, MAX, AVERAGE, and
STANDARD DEVIATION. Such queries are
sometimes called statistical queries.
© University of Colombo School of Computing
Statistical
Database Security
• It is DBMS’s responsibility to ensure confidentiality
of information about individuals, while still providing
useful statistical summaries of data about those
individuals to users.
• Provision of privacy protection of users in a
statistical database is paramount.
• In some cases it is possible to infer the values of
individual tuples from a sequence statistical queries.
This is particularly true when the conditions result in
a population consisting of a small number of tuples.

© University of Colombo School of Computing


Database Systems1

Database Design Process

Duration: 12hrs

© UCSC
Database Systems1
Detailed Syllabus
1. Database Design Approach
1. Introduction: Benefits, Critical success factors, Where it fits into the
application development process, Approach
2. Data requirement analysis: Gain an understanding of the business;
Conceptual modeling: Identify the principal data objects, Diagram the data
objects using the entity-relationship (ER) approach, Resolve the conceptual
data model, Determine attribute specifications and data types, Verify the
conceptual data model through normalization; Logical model; Physical
model; Database Design tools.

2. ER Concepts and Terminology


1. The Role of ER Diagrams.
2. Three classes of objects: Entities, Relationships and Attributes.
3. Entities: Entity, Entity instance, Subtype and Super-type Entities, Strong
and weak entities, Generalization, specialization and aggregation.
4. Relationships: Connectivity (binary, n-array), (1:1, 1:N, M:N),
Determining the connectivity, Cardinality, Existence dependency
(mandatory, optional).
5. Attributes: Identifying attributes, Attribute types (identifier, descriptor),
Derived data, Domain, Composite attributes.
© UCSC
Database Systems1

6.3 Mapping Conceptual model into relational schema.


1. Regular, weak, generalized and specialized entities,
Relationship types, Multi-valued attributes.
2. Resolve the conceptual data model; Redundant Relationships;
Recursive Relationships; Resolving Relationships: 1:1, M:N.

4. Attribute Specifications and Data types.


1. Attribute names, Naming conventions, Avoid Synonyms and
Homonyms, Null Values, Entity integrity, Unique
Requirement.
2. Categories of Data Types: Character, Numeric, Variable
Character, Date, Serial, Money, Date-time, Interval.
3. Character: CHARACTER (CHAR); Numeric: INTEGER
(INT), SMALLINT, FLOAT, SMALLFLOAT, DECIMAL;
Variable Character: CHARACTER VARYING
(VARCHAR); Binary Large Object (BLOB): Text, Byte.
© UCSC
Database Systems1

• Database design and the creation of an entity relationship diagram


(also known as an "ERD" or data model) is an important yet
sometimes overlooked part of the application development lifecycle.
An accurate and up-to-date data model can serve as an important
reference tool for DBAs, developers, and other members of a JAD
(joint application development) team. The process of creating a data
model helps the team uncover additional questions to ask of end users.
Effective database design also allows the team to develop applications
that perform well from the beginning. By building quality into the
project, the team reduces the overall time it takes to complete the
project, which in turn reduces project development costs. The central
theme behind database design is to "measure twice, cut once".

© UCSC
Database Systems1

• Data modeling is essential to building a


well-functioning database. For a database
to support the activities of a business, it
needs a good blueprint and foundation: the
data model. A data model represents a
business' data.

© UCSC
Database Systems1

Effective database designers will keep in mind the


principles of normalization while they design a
database. Normalization is a database design
approach that seeks the following four objectives:

• minimization of data redundancy,

• minimization of data restructuring,

• minimization of I/O by reduction of transaction


sizes, and

• enforcement of referential integrity.

© UCSC
Database Systems1

• A poor database design can cripple an


application, producing problems with
redundancy, inaccuracy, consistency, and
concurrency of your data.

• Normalization is a process that serves to


reduce, if not eliminate, these problems with
data.

© UCSC
Database Systems1

Database Design
The database design process can be broken down into
four phases.

Phase 1 - Requirements Collection


and analysis phase
Phase 2 - Conceptual Design
Phase 3 - Logical Design
Phase 4 - Physical Design

© UCSC
Database Systems1

Database Design... Mini-world

Phase 1 - Requirements Collection


and Analysis phase
Functional Database
Requirements Requirements

Prospective database uses are


interviewed to understand and
document their data requirements.

From data view (e.g. ERD) rather


than functional view (e.g. DFD)
© UCSC
Database Systems1
Database
Database Design... Requirements

Phase 2 - Conceptual Design

This is high level description of


the structure of a database. E.g. Conceptual Design
E-R diagram

Concise description of the data


requirements of the users and
includes detailed descriptions of
the data, relationships and
constraints.
© UCSC
Database Systems1

Database Design... Conceptual Design

Phase 3 - Logical Design


This is the process of mapping
the database structure
Logical Design
developed in the previous phase
to a particular database model. ATTR1 ATTR2 A TTTR3 ATT R4 ATTR LLL 5

E.g. map E-R model to


Table

relational
ATTR1 ATTR2 AT TTR3 ATTR4

Table

ATTR1 AT A TT R 4 ATTR5

Specific to a database model, Table

but independent of a particular ATTR1

Table
ATTR2 A TTTR3 ATTRTR5

DBMS (product)
© UCSC
Database Systems1

Database Design... Logical Design

Phase 4 - Physical Design

Physical Design
This is the process of defining
structure that enables the
database to be queried in an
efficient manner.
E.g. index and hash file
design, data partition

© UCSC
Database Systems1

Phases of Mini-world

Database Design Requirements


Collection & Analysis
Functional
Database
Requirements
Requirements
Conceptual Design
Functional Analysis
High-level Transaction Conceptual
Specification Data Model
Logical Design
Application Program
Design Logical Data
Model
Transaction Physical Design
Implementation
Physical Data
Application Programs
Model © UCSC
Database Systems1

Types of Database Models


Traditional Hierarchical Network
Files Database Model Database Model

-------- 60s 70s 70s


--------
--------

Relational Object-oriented Object-relational


Database Model Database Model Database Model

----
---- ---- 80s 90s ----
---- 90s
----
----
----

© UCSC
Database Systems1

Types of Data Models

• Conceptual Data Model

ATTR1 ATTR2 A TTTR3 ATT R4 ATTR LLL 5

• Logical Data Model Table


ATTR1

Table
ATTR2 AT TTR3 ATTR4

• Physical Data Model Table

© UCSC
Database Systems1

Conceptual Data Model


• A data model representing the objects and
business rules that govern the operation of
an organisation
• Done by a Business Analyst
• Not constrained by access requirement and
technology

© UCSC
Database Systems1

Logical Data Model ATTR1


Table
ATTR2 A TTTR3 ATT R4 ATTR LLL 5

employee(empno, …)
• A set of data structures assembled
following rules that describe the processing
requirements (access paths) of the data in
terms of a logical database model
• Done by a Data Analyst
• Not constrained by technology (?)

© UCSC
Database Systems1

Physical Data Model create table Table


employee(empno …)

• A model prepared for the purpose of


implementing a database that runs under
the control of a particular DBMS
(product)
• Done by a DBA
• Constrained by Technology

© UCSC
Database Systems1

Systems Development Life Cycle (SDLC)


Project Project
Identification Initiation & Analysis
& Selection Planning

Physical Logical
Implementation Design Design

Maintenance Conceptual Data Model


Logical Database Design
Physical Database Design
© UCSC
Database Systems1

Database Development Activities


• Enterprise Modelling
• Conceptual Data Modelling
• Logical Database Design
• Physical Database Design and Creation
• Database Implementation
• Database Maintenance

© UCSC
Database Systems1

Enterprise Modelling

• Analyse current data processing


• Analyse the general business functions and
their database needs
• Justify need for new data and databases in
support of business

Project Identification & Selection


© UCSC
Database Systems1

Conceptual Data Modelling


• Identify scope of database requirements for
proposed information system
• Analyse overall data requirements for
business function(s) supported by database
• Develop preliminary conceptual data model
including entities and relationships
• Compare preliminary conceptual data
model with enterprise data model
Analysis
© UCSC
Database Systems1

Conceptual Data Modelling...


• Develop detailed conceptual data model,
including all entities, relationships,
attributes and business rules
• Make conceptual data model consistent with
other models of information system
• Populate repository with all conceptual
database specifications

Analysis
© UCSC
Database Systems1

Logical Database Design


• Analyse in detail the transactions, forms,
displays and inquires (data views) required
by the business functions supported by the
database
• Integrate database views into conceptual view
data model
• Identify data integrity and security
requirements, and populate repository
Logical Design
© UCSC
Database Systems1

Physical Database Design


• Define database to DBMS (often generated
from repository)
• Decide on physical organisation of data
• Design database processing programs

Physical Design
© UCSC
Database Systems1

Database Implementation
• Code and test database processing programs
• Complete database documentation and
training materials
• Install database and convert data from prior
systems

Implementation
© UCSC
Database Systems1

Database Maintenance
• Analyse database and database applications
to ensure that evolving information
requirements are met
• Tune database for improved performance
• Fix errors in database and database
applications and recover database when it is
contaminated
Maintenance
© UCSC
Database Systems1

Database Design Process

Duration: 12hrs

@ UCSC
Database Systems1

A mini-world example
• A Company is organised in to departments. Each
department has a number and an employee who
manages the department. We keep track of the
start date when that employee started managing
the department. A department may have several
locations.
• A department controls a number of projects. Each
of which has a name, a number and a single
location.

@ UCSC
Database Systems1

A mini-world example
• We store each employee’s name, national Id
number, address, salary, birth date and sex. An
employee is assigned to one department, but may
work on several projects, which are not
necessarily controlled, by the same department.
We keep track of the number of hours per week
that an employee works on each project. We also
keep track of the direct supervisor of each
employee.

@ UCSC
Database Systems1

A mini-world example

• We keep track of the dependants of each


employee for insurance purposes. We keep each
dependant’s name, sex, birth date and
relationship to the employee.

Such information is gathered from the mini-world


to perform Phase 1 of database design process.
i.e. Requirements Collection and Analysis Phase

@ UCSC
Database Systems1

Conceptual Design
All the requirements collected at Phase 1 are
analysed to create a Conceptual Schema.

This process is called the Conceptual Design.

We identify the entities, their attributes,


relationships and constraints (business rules).
The conceptual schema is used as a reference to
ensure that all user’s data requirements are met
and the requirements do not include any
conflicts.
@ UCSC
Database Systems1

Conceptual Design
Entities

Department

Employee

Project

Dependent
@ UCSC
Database Systems1

Conceptual Design
Relationships

A Department has Many Employees

An Employee works for A Department


@ UCSC
Database Systems1

one to many relationship

Department

Personnel Sales

Employee

Alwis Perera Silva


De Silva Ane Tom Jane Dias
Kate Pat
@ UCSC
Database Systems1

Relationships
• Relationship Type
– A meaningful association between association
between (or among) entity types
• Relationship Instances
– An association between (or among) entity
instances, where each relationship instance
includes exactly one entity from each
participating entity type
e.g. De Silva works for Personnel Department

@ UCSC
Database Systems1

Conceptual Design
Relationships

A Department has A Manager


(Employee)

An Employee manage A Department


@ UCSC
Database Systems1

one to one relationship


Department

Personnel Sales

Manager
(Employee)

De Silva Dias
@ UCSC
Database Systems1

Conceptual Design
Relationships

A Department controls Many Projects

A Project controlled by A Department


@ UCSC
Database Systems1

Conceptual Design
Relationships

An Employee works on Many Projects

A Project has Many Employees


@ UCSC
Database Systems1

many to many relationship


Project

Construction Delivery

Employee
1 relationship type
5 relationship instances

De Silva Perera Dias


@ UCSC
Database Systems1

Conceptual Design
Relationships

An Employee supervised by An Employee

An Employee supervise Many Employees

@ UCSC
Database Systems1

Conceptual Design
Relationships

An Employee has Many Dependants

A Dependant belongs to An Employee


@ UCSC
Database Systems1

Conceptual Design
Entities / Relationships??

A Company has Many Departments

A Department has Many Locations

@ UCSC
Database Systems1

Conceptual Design
Notations

Entity

Relationship

Attribute

@ UCSC
Database Systems1

Relationship Types
One to One

Company director Employee

One to Many

Company director Employee

Many to Many

Company director Employee

@ UCSC
Database Systems1

Cardinality Constraints
• Specifies the number of instances of one
entity that can (or must) be associated with
each instance of another entity
• Minimum Cardinality
– The minimum number of instances of one
entity that may be associated with each instance
of another entity
e.g. the minimum dependants for an employee is
zero

@ UCSC
Database Systems1
Cardinality Constraints
• Optional Participation
– when the number of participants in the
relationship is zero
• Mandatory Participation
– when the number of participants in the
relationship is one
• Maximum Cardinality
– The maximum number of instances of one
entity that may be associated with a single
occurrence of another entity
e.g. an Employee can have insurance policies for
at most two dependants (0:2)
@ UCSC
Database Systems1

Existence Conditions
One to One

Company director Employee

One to Many

Company director Employee

Many to Many

Company director Employee

@ UCSC
Database Systems1

Existence Conditions
One to One

Company director Employee

Dias

ABC Ltd. De Silva Perera


@ UCSC
Database Systems1

Existence Conditions
One to Many

Company director Employee

Dias

ABC Ltd.
De Silva Perera
@ UCSC
Database Systems1

Existence Conditions
Many to Many

Company director Employee

XYZ Ltd. Dias

ABC Ltd. De Silva Perera


@ UCSC
Database Systems1

supervise
works

Employee Department

manage

has control
works on

Dependent Project

@ UCSC
Database Systems1

E-R Modelling

1:1 Ma

1:N Ma

1:1 Op

1:N Op

Martin (Information Engineering)


@ UCSC
Database Systems1

E-R Modelling

1:1 Ma

1:N Ma

1:1 Op

1:N Op

Crow’s Foot
@ UCSC
Database Systems1

E-R Modelling (Alternate Notations)

1:1 Ma

1:N Ma

1:1 Op

1:N Op

Chen/Bachman
@ UCSC
Database Systems1

E-R Modelling (Alternate Notations)

1:1 Ma 1 1

1 N
1:N Ma

Optional not shown

Chen

@ UCSC
Database Systems1

E-R Modelling (Alternate Notations)

1:1 Ma

1:N Ma

1:1 Op

1:N Op

Reiner
@ UCSC
Database Systems1

E-R Modelling (Alternate Notations)

1:1 Ma 1,1 1,1

1:N Ma 1,N 1,1

0,1 1,1
1:1 Op

0,N 1,1
1:N Op

Datarun
@ UCSC
Database Systems1

E-R Modelling (Alternate Notations)

1:1 Ma

1:N Ma

1:1 Op

1:N Op

IRM
@ UCSC
Database Systems1

Using Relationship to Define Access Paths


Employee works Department

Can we tell which


Employees are
works on
assigned to a given control
Department?
Can we tell which Employees are
working on a given Project? Project

Can we tell which Employee work on Projects


that do not belong to their Department?
@ UCSC
Database Systems1

Detail Conceptual Data Model

@ UCSC
Database Systems1

Attributes
• Attribute
– A property or characteristic of an entity type
that is of interest to the organisation
• Simple Attribute
– An attribute that cannot be broken down into
smaller components
e.g. Emp No Emp No

@ UCSC
Database Systems1

Attributes Cont’d
• Multi-valued Attribute
– An attribute that may take on more than one value
for a given entity instance
e.g. Employee Skills, Qualifications Skills

• Composite Attribute
– An attribute that can be broken down into
First Name
component parts
Mid Initials
Name
Last Name

e.g. Address (Street, City, State, Postal Code)


Name (First Name, Middle Initials, Last Name)
@ UCSC
Database Systems1

Attributes Cont’d

• Stored Attribute
– An attribute whose valued is stored in the
database
• Derived Attribute
– An attribute whose values can be calculated
from related attribute values
e.g. Years Employed (using Employed Date)
Age (using Date of Birth)
Age

@ UCSC
Database Systems1

Identifier
• Identifier
– An attribute (or combination of attributes) that
uniquely identifiers individual instances of an
entity type
e.g. Emp No Employee Emp No

• Composite Identifier
– An identifier that consists of a composite
attribute
e.g. Flight Id (Flight No, Date) Flight No

Flight Flight Id
Date
@ UCSC
Database Systems1

Identifier
• Choose an identifier that will not change its value
over the life of each instance of the entity type
• Choose an identifier such that each instance of
the entity type, the attribute is guaranteed to have
valid values and not be null (or unknown)
• Avoid the use of so-called intelligent identifiers,
whose structure indicates classifications, etc.
• Consider substituting single-attribute identifiers
for large composite identifiers

@ UCSC
Database Systems1

Detailed Conceptual Design


Attributes

Department
Number Manager
Location Start date

Name Control Projects


Phone Employees work for

Number of Employees
@ UCSC
Database Systems1

Detailed Conceptual Design


Dept No unique identifier of a dept. Identifier
Dept Name name of a department Unique
Location location of a department Multi-valued
Phone phone no. of a department
Employees no. of employees in a dept. Derived
Dept No

Dept Name

Department Location
Phone
Employees
@ UCSC
Database Systems1

Detailed Conceptual Design


Project
Name Department Control
Number
Location Leader  Employee

Proj No unique identifier of a project Identifier


Proj Name name of a project Unique
Location location of a project
Proj No

Project Proj Name

Location
@ UCSC
Database Systems1

Detailed Conceptual Design


Employee

Name
Works for Department
National ID
Supervise Employee
Address
Salary
Emp No
Sex
Birth Date

@ UCSC
Database Systems1

Detailed Conceptual Design


Employee
Emp No unique identifier of an emp. Identifier
Emp Name name of an employee Composite
First Name first name of an employee
Mid Initials middle initials of an employee
Last Name last name of an employee
NID national id of an employee Unique
Address address of an employee
Salary salary of an employee
Gender sex of an employee
DOB birth date of an employee
@ UCSC
Database Systems1

Detailed Conceptual Design

First Name
Emp No
Mid Initials
Emp Name
Last Name
Employee NID
Address
Salary

Gender
DOB

@ UCSC
Database Systems1

Detailed Conceptual Design


Dependent
Name Sex Birth Date Relationship

Depd Name name of a dependent Part of Key


Gender sex of a dependent
DOB birth date of a dependent
Relation relationship of a dependent to an employee
Depd Name
Gender
Dependent DOB

Relation
@ UCSC
Database Systems1 First Name
Emp No
Mid Initials
NID Emp Name Location
Last Name
Dept Name
Address
supervise Phone
works Dept No

Start d
Employee Department

Salary Hours manage


Employees
Gender has control
DOB works on Proj No

Dependent Depd Name


Project
Gender
Relation DOB
Location Proj Name
@ UCSC
Database Systems1

Entity Types
• Strong (Regular) Entity
– An entity that exists independently of other
entity types
Employee

• Weak Entity
– An entity types whose existence depends on
some other entity
Dependent

@ UCSC
Database Systems1

Entity Types
• Identifying Owner
– The entity type on which the weak entity type
depends
e.g. Employee is the Owner of Dependent

• Identifying Relationship
– A relationship between a weak entity type and
its owner
has

@ UCSC
Database Systems1

Conceptual Design showing weak entities


supervise
works

Employee Department

manage

has control
works on

Dependent Project

@ UCSC
Database Systems1

Sample Entity Definitions


• Name: Department
Type: Regular
Definition: a department of an organisation
Identifier: Dept_No
• Name: Dependent
Type: Weak
Definition: a person who is a dependent of
an employee and entitle for insurance
Identifier: Depd_Name (partial only)
@ UCSC
Database Systems1

Sample Attribute Definitions


• Name: Emp_No
Domain: employee identities
Definition: unique identifier of an employee
Null: No
• Name: Emp_Name
Components: First_Name, Mid_Initials,
Last_Name
Definition: a partial identifier of a name
Null: No
@ UCSC
Database Systems1

Sample Relationship Definitions


• Name: Works_for
Type: binary 1:M
Definition: associates each employee with a
department
Constraint: each employee must be attached to a
department
Attributes: none

@ UCSC
Database Systems1

• Domain Constraints
– A specification of the characteristics of the data
values that can be associated with one or more
attributes

Sample Domain Constraints


• Name: Employee identities
Data Type: character
Length: 5
Allowable Characters: digits

@ UCSC
Database Systems1

Sample Domain Constraints Cont’d


• Name: Last name
Data Type: character
Max Length: 20
• Name: DOB
Data Type: date
Format: dd/mm/yyyy
dd = day
mm = month
yyyy = year
@ UCSC
Database Systems1

Associative Entity
• An entity type that associates the instances
of one or more entity types and contains
attributes that are peculiar to the
relationship between those entity instances

Certificate

@ UCSC
Database Systems1
Emp No Emp Name Course Id CName
Date Comp

30 4
Employee Completes Course

1 many to may relationship

Emp No Emp Name Date Comp Course Id CName

4 30
Employee Certificate Course

Cert No
2 one to many relationships
@ UCSC
Database Systems1

Associative Entity
• All of the relationships for the participating entity
types are “many” relationships
• The resulting associative entity type has
independent meaning to end users, and preferably
can be identified with a single-attribute identifier
• The associative entity has one or more attributes,
in addition to the identifier
• The associative entity participates in one or more
relationships independent of the entities related in
the associated relationships
@ UCSC
Database Systems1

Relationships
• Unary Relationship
– A relationship between the instances of a single entity
type
manages
e.g. Person is married to a Person (1:1)
Employee manages Employees (1:M)
Employee
• Binary Relationship
– A relationship between the instances of two entity
types

@ UCSC
Database Systems1

Relationships
• Ternary Relationship
– A simultaneous relationship among the instances of
three entity types S1 P1 W1 Land 10
S1 P1 W2 Sea 15
Part S1 P2 W1 Air 20
S2 P1 W1 Air 15
Shipping Mode
Vendor Supplies
Unit Cost

Warehouse

@ UCSC
Database Systems1

Relationships
• Ternary Relationship
– can be treated as two many to many relationships

Shipping Mode

Part

Supplies Warehouse
supply

Vendor
Unit Cost
@ UCSC
Database Systems1

Enhanced ERM
• Enhanced Entity-Relationship Model
– The model that has resulted from extending the
original E-R model with new modelling constructs

Most important modelling construct incorporated


is Supertype / Subtype relationships

Subtype
• A sub-grouping of the entities in an entity type that is
meaningful to the organisation and that shares common
attributes or relationships distinct from other sub-
grouping. e.g. Student  Graduate, Undergraduate
@ UCSC
Database Systems1

Enhanced ERM Cont’d


Supertype
• A generic entity type that has a relationship with one or
more subtypes. e.g. Student
Attribute Inheritance
• A property that subtype entities inherit values of all
attributes of the supertype
Generalisation
• The process of defining a more general entity type from
a set of more specialised entity types
Specialisation
• The process of defining one or more subtypes of the
supertype and forming supertype/subtype relationships
@ UCSC
Database Systems1

Employee

Secretary Engineer Manager Person

o
Vehicle

d Employee Student

Car Truck StudEmp

@ UCSC
Database Systems1

Database Design Process

Duration: 12hrs

© UCSC
Database Systems1
Logical Database Design
Mapping ERD to Relational
Transforming (mapping) E-R diagrams to
relations is a relatively straightforward
process with a well-defined set of rule

Step 1: Map Regular Entities


2: Map Weak Entities
3: Map Binary Relationships
4: Map Associated Entities
5: Map Unary Relationships
6: Map Ternary (and n-ary) Relationships
7: Map Supertype/Subtype Relationships
© UCSC
Database Systems1

1. Map Regular Entities


Each regular entity type in an ERD is
transformed into a relation.

Entity Relation
entity name relation name
simple attribute attribute of the relation
entity identifier primary key of relation
composite attribute component attributes
multi-valued attribute new relation with PK

© UCSC
Database Systems1
First Name
Emp No
Mid Initials Location
NID Emp Name
Last Name Dept Name
Address
Phone
Dept No

Department
Employee

Salary Employees
Employee (Emp_No, NID, Address,
Gender
Salary, Gender, DOB,
DOB
First_Name, Mid_Initials, Last_Name)
Department(Dept_No, Dept_Name, Phone)
FK/NN NN
Dept_Location(Dept_No, Location) © UCSC
Database Systems1

2. Map Weak Entities


Each weak entity type in an ERD is transformed
into a relation.

Entity Relation
entity name relation name
simple attribute attribute of the relation
owner entity identifier foreign key attribute
entity identifier (partial) composite key together
with PK of owner as FK
composite attribute component attributes
multi-valued attribute new relation with PK
© UCSC
Database Systems1

Emp No
Employee

has

Dependent Depd Name


Gender
Relation DOB

Dependent(Emp_No, Depd_Name, Gender, DOB, Relation)


FK/NN
Employee (Emp_No, ….)
© UCSC
Database Systems1

3. Map Binary Relationships


Procedure depends on both the degree of the
binary relationships and the cardinalities of
the relationships

• Map Binary One-to-Many Relationships


• Map Binary Many-to-Many Relationships
• Map Binary One-to-One Relationships

© UCSC
Database Systems1
Map Binary One-to-Many
Relationships
Create a relation for the two entity types
participating in the relationships (step 1)

include PK of the entity in the one-side of the


relationship as a foreign key in the relation of
the many side of the relationship

include any attributes of the relationship to


the relation of the many side

© UCSC
Database Systems1

Location
Dept Name
Phone
FK Dept No

Department(Dept_No,
Department
Dept_Name, Phone)

Employees
control
Proj No
Project(Proj_ No, Proj_Name,
Location, Dept_No) Project

NN Location Proj Name


© UCSC
Database Systems1
First Name Location
Emp No
Mid Initials
NID Emp Name Dept Name
Last Name
Address Phone
Dept No
works

Department
Employee
Employees
Salary

Gender Department(Dept_No, Dept_Name,


DOB Phone) FK

Employee(Emp_No, NID, Address, Salary, Gender,


DOB, First_Name, Mid_Initials, Last_Name,
Dept_No)
NN © UCSC
Database Systems1
Map Binary Many-to-Many
Relationships
Create a relation for the two entity types
participating in the relationships (step 1)

Create new relation and include PK of each


of the two participating entity types as FK.
These attributes become the PK (composite)

include any attributes of the relationship to


the new relation

© UCSC
Database Systems1 First Name
Emp No
Mid Initials FK/NN
NID Emp Name
Last Name
Address
Employee(Emp_No, NID, Address,
Salary, Gender, DOB, First_Name,
Mid_Initials, Last_Name, Dept_No)
Employee
Project(Proj_ No, Proj_Name,
Salary
Hours Location, Dept_No)
Gender works on FK/NN
DOB Works_On(Emp_No, Proj_No, Hours)

Project

Location Proj Name Proj No


© UCSC
Database Systems1
Map Binary One-to-One
Relationships
Specialised case of One-to-Many
Create a relation for the two entity types
participating in the relationships (step 1)

Include PK of one of the relations as a


foreign key of the other relation (include in
optional side of the relationship that has
mandatory participation in the 1:1)

include any attributes of the relationship to


the same relation
© UCSC
Database Systems1 First Name
Emp No
Mid Initials
NID Emp Name Location
Last Name
Dept Name
Address
Phone
Dept No

Start d
Employee Department

Salary manage
Employees
Gender
DOB Employee(Emp_No, NID, Address, FK
Salary, Gender, DOB, First_Name,
Mid_Initials, Last_Name, Dept_No)
NN
Department(Dept_No, Dept_Name, Phone, Manager
Start_D) © UCSC
Database Systems1

4. Map Associative Entities


Essentially the same steps as mapping M:N, except
if there is a special identifier for associative entity
Create new associative relation for the associative
entity and include PK of each of the two
participating entity types as FK. These attributes
become the PK (composite) if there is no identifier
assigned. Otherwise the PK is the identifier of
the associative entity
include any attributes of the relationship to the new
relation
© UCSC
Database Systems1
Emp No Emp Name Course Id CName
Date Comp

Employee Certificate Course

Certificate(Emp_No, Course_Id, Date_Comp)


FK/NN FK/NN
Emp No Emp Name Date Comp Course Id CName
Cert No

Employee Certificate Course

Certificate(Cert_No, Emp_No, Course_Id, Date_Comp)


FK/NN FK/NN © UCSC
Database Systems1

5. Map Unary Relationships


Procedure depends on both the degree of the
binary relationships and the cardinalities of
the relationships

• Map Unary One-to-Many Relationships


• Map Unary Many-to-Many Relationships
• Map Unary One-to-One Relationships

© UCSC
Database Systems1
Map Unary One-to-Many
Relationships
Create a relation for the entity type (step 1)

include PK of the entity as a foreign key


within the same relation

include any attributes of the relationship to


the relation of the many side

© UCSC
Database Systems1
First Name
Mid Initials
NID Emp Name
Last Name
Address supervise

Salary Emp No
Gender
Employee
DOB

Employee(Emp_No, NID, Address,


Salary, Gender, DOB, First_Name,
Mid_Initials, Last_Name, Dept_No,
Supervisor)
FK/Null
© UCSC
Database Systems1
Map Unary Many-to-Many
Relationships
Create a relation for the entity type (step 1)

Create new relation and include PK of the


entity type as FK twice. These attributes
become the PK (composite)

include any attributes of the relationship to


the new relation

© UCSC
Database Systems1

Quantity

contain Name
Item No

Item
Unit Cost

Item(Item_No, Name, Unit_Cost)

FK/NN
Component(Item_No, Component_No, Quantity)
FK/NN © UCSC
Database Systems1
Map Unary One-to-One
Relationships
Create a relation for the entity type (step 1)

include PK of the entity as a foreign key


within the same relation

include any attributes of the relationship to


the relation of the many side

© UCSC
Database Systems1
First Name
Mid Initials
NID Emp Name
Last Name
Address marry

Salary Emp No
Gender
Employee
DOB

Employee(Emp_No, NID, Address,


Salary, Gender, DOB, First_Name,
Mid_Initials, Last_Name, Dept_No,
Marry)
FK/Null
© UCSC
6. Map Ternary (and n-ary)
Database Systems1

Relationships
Convert a ternary relationship to an
associative entity

Create a new associative relation for the


associative entity. The default PK consists of
three PK attributes of the participating entity
types (in some cases additional attributes are
needed to form a PK) as FK

include any attributes of the relationship to


the new relation
© UCSC
Database Systems1

Part

Shipping Mode
Vendor Supplies
Unit Cost

Warehouse

Warehouse(warehouse_no, ….)
Vendor(vendor_no, ….)
Part(part_no, ….)
Supply(warehouse_no, vendor_no, part_no,
Shipping_mode, Unit_Cost)
© UCSC
Database Systems1

7. Map Supertype/Subtype
Relationships
The relational model does not directly
support supertype/subtype relationships

There are various strategies that database


designers can use to represent these
relationships with the relational data model

© UCSC

Potrebbero piacerti anche