Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
© 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.
© UCSC
Components of Database System
Environment
© 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?
© UCSC
Why Database Technology?
The need to manipulate large collection of data for
frequent used data queries and reports.
© UCSC
Examples of Database Applications
© UCSC
Manual Systems – Information on
library books
© UCSC
File-Based Systems
• Collection of application programs that perform
services for the end users (e.g. reports).
© 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.
• 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.
© UCSC
Database Management System
(DBMS)
© UCSC
Database Approach
Personnel
Application
File 1
Payroll
DBMS File 2
Application
File 3
Benefit
Application
Database
Entities/objects
File File File
Field
© UCSC
Data Hierarchy
© 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
© UCSC
Meta Data
© 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
© UCSC
Three-Level Architecture
• All users should be able to access same
data but have a customized view of the
data.
© UCSC
Three-level ANSI/SPARC
architecture
User 1 User 2 User 3
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.
© 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.
© 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.
© UCSC
Physical Level
• Managed by the operating system under
the direction of the DBMS.
© UCSC
Differences between Three Levels of
ANSI-SPARC Architecture
© UCSC
2007, UCSC
Mapping between Levels
© UCSC
Data Independence
© 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.
© 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.
• 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
• 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.
© UCSC
Workgroup databases
© UCSC
Departmental databases
© UCSC
Database Approach -Advantages
• Improved maintenance through
program-data independence
• 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.
© 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.
© 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.
© 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.
© UCSC
Improved Data Integrity
• Integrity can be expressed in terms of
constraints, which are consistency
rules that the database is not permitted
to violate.
© 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.
© 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.
© 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
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
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
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
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
13
Search: Employee Dias
. De Silva . Perera .
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
15
Relational Algebra
© UCSC
Relational Algebra
Detailed Syllabus
• Union
• Intersection
• Difference
• Cartesian Product
© UCSC
Relational Algebra
Relational Algebra
© UCSC
Relational Algebra
Relational Algebra
• Relational algebra operations work on one
or more relations to define another relation
without changing the original relations.
Relational Algebra
• Five basic operations in relational algebra:
Selection, Projection, Cartesian product,
Union, and Set Difference.
© 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
© UCSC
Relational Algebra
Sequence of Operations
• Or we can apply one operation at a time and
create intermediate result relations.
© UCSC
Relational Algebra
Union
• RS
– 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.
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
© UCSC
Relational Algebra
Intersection
• RS
– Defines a relation consisting of the set of all
tuples that are in both R and S.
– R and S must be union-compatible.
© 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
Cartesian product
• RXS
– Defines a relation that is the concatenation
of every tuple of relation R with every tuple of
relation S.
© 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
© 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.
© UCSC
Relational Algebra
Example - Projection
• Produce a list of employees showing only
E-No and E-Name.
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
© UCSC
Relational Algebra
Sequence of Operations
Or we can apply one operation at a time and
create intermediate result relations.
© UCSC
Relational Algebra
Join Operations
• Join is a derivative of Cartesian product.
© 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.
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.
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.
Division Operation
• RS 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
© 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_Mgr_Projs(Pno)πPnumber(Perera_Managed_
Depts * Project)
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
© 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’
© 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
© UCSC
Creating SQL Databases and
Tables
Duration : 3hrs
© UCSC
Detailed Syllabus
© UCSC
Data Manipulation using
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
© UCSC
Data Manipulation using
SQL
© UCSC
SQL Basics
© 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
© UCSC
SQL Basics
•ANSI/ISO SQL Keywords
© UCSC
Example of some
keywords
© 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
© 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
© 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
© UCSC
NULL Values:What are Null values?
• Null values provides a systematic way of handling missing
or inapplicable data in SQL.
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.
© UCSC
Referential Integrity
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:
RESTRICT will not allow delete from the parent table if there are
associated dependent rows.
SET DEFAULT
© UCSC
• Employee(Emp_No, NID, Address, Salary, Gender, DOB,
First_Name, Mid_Initials, Last_Name, Dept_No, Supervisor)
© 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)
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
© UCSC
Command:CREATE
Create Index Command
Example
– CREATE UNIQUE INDEX Dept_Name_IDX ON
Department (Dept_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)
© 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.
© 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
© 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.
© UCSC
SQL for Data Manipulation
-High-level Language for data manipulation
-It does not require predefined navigation path
© 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]
© 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' ;
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
© 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
© 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)
© 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%”
© UCSC
Compound Search Conditions
AND, OR and NOT
Example:
WHERE Proj_Name LIKE ‘INFORM%’ AND Emp_Name = ‘DIAS’
• 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.
SELECT sname
FROM supplier, supply
WHERE supplier.sno = supply.sno and pno = ‘P2’;
© 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.
© 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.
© 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)
© UCSC
RESTRICT INSERT
Department
Dept_Cod e Manager
Dep_Name
SAL Sales 179
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
© 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
© 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
© UCSC
SET NULL UPDATE
Department
Dept_Code Dep_Name Manager
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’
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’
In Employee Table
CONSTRAINT Emp_Dep_FK
FOREIGN KEY (Dept) REFERENCES
Department(Dept_Code) ON DELETE RESTRICT
© UCSC
RESTRICT DELETE
Department
Dept_Code Dep_Name Manager
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
© 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
© UCSC
SET NULL DELETE
Department
Dept_Code Dep_Name Manager
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’
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
Conceptual Layer
Base Tables
Physical Layer
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.
Works_On1
Fname Lname Pname Hours
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)
Drop a View
DROP VIEW view-name
E.g.
DROP VIEW Emp_Payroll
UPDATE Works_On1
SET Pname = ‘ProductY’
WHERE Lname = ‘Perera’ AND Fname = ‘Sunil’
AND Pname = ‘ProductX’;
31
Eg:
CREATE VIEW Emp_View AS
SELECT *
FROM Employee
WHERE Dept = ‘SAL’
WITH CHECK OPTION
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
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
© UCSC
Detailed Syllabus
© UCSC
External Layer
View View View
Conceptual Layer
Base Tables
Physical Layer
© UCSC
Architecture
Table
Conceptual Layer
Table
© 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
© 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
© 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
© UCSC
Characteristics of User views...
© UCSC
Database Security
Duration: 2hrs
© UCSC
SQL and User Views
Creating a View
© 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
© 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
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
© UCSC
Types of User views
© UCSC
Types of User views
Row/Column
© UCSC
Types of User views
Summarised
© UCSC
Types of User views
Derive
© UCSC
Types of User views
Derive
© UCSC
Types of User views
Joined
© 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
© 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
© 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
• Commands:
– GRANT
– REVOKE
6
SQL for Data Control
Security and Access Control
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
• Types of Security
– Legal and ethical issues
– Policy issues
– System-related issues
– Multiple security levels
Threats to databases
- Loss of integrity
- Loss of availability
- Loss of confidentiality
– Account creation
–
– Privilege revocation
– Security level assignment
. 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
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 UPDATE(Designation)
ON Employee
TO A2, A3
GRANT SELECT, INSERT
ON Employee
TO A2
• REVOKE Command:
– Remove privileges from users on database objects.
REVOKE SELECT
ON Employee
FROM A2
REVOKE UPDATE(Designation)
ON Employee
FROM A2
A1 can issue:
DBA
Kapila
Aruna
R(A1,C1,A2,C2, …, An,Cn,TC)
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.
© UCSC
Database Systems1
© UCSC
Database Systems1
© UCSC
Database Systems1
© UCSC
Database Systems1
Database Design
The database design process can be broken down into
four phases.
© UCSC
Database Systems1
relational
ATTR1 ATTR2 AT TTR3 ATTR4
Table
ATTR1 AT A TT R 4 ATTR5
Table
ATTR2 A TTTR3 ATTRTR5
DBMS (product)
© UCSC
Database Systems1
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
----
---- ---- 80s 90s ----
---- 90s
----
----
----
© UCSC
Database Systems1
Table
ATTR2 AT TTR3 ATTR4
© UCSC
Database Systems1
© UCSC
Database Systems1
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
© UCSC
Database Systems1
Physical Logical
Implementation Design Design
© UCSC
Database Systems1
Enterprise Modelling
Analysis
© UCSC
Database Systems1
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
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
@ UCSC
Database Systems1
Conceptual Design
All the requirements collected at Phase 1 are
analysed to create a Conceptual Schema.
Conceptual Design
Entities
Department
Employee
Project
Dependent
@ UCSC
Database Systems1
Conceptual Design
Relationships
Department
Personnel Sales
Employee
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
Personnel Sales
Manager
(Employee)
De Silva Dias
@ UCSC
Database Systems1
Conceptual Design
Relationships
Conceptual Design
Relationships
Construction Delivery
Employee
1 relationship type
5 relationship instances
Conceptual Design
Relationships
@ UCSC
Database Systems1
Conceptual Design
Relationships
Conceptual Design
Entities / Relationships??
@ UCSC
Database Systems1
Conceptual Design
Notations
Entity
Relationship
Attribute
@ UCSC
Database Systems1
Relationship Types
One to One
One to Many
Many to Many
@ 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
One to Many
Many to Many
@ UCSC
Database Systems1
Existence Conditions
One to One
Dias
Existence Conditions
One to Many
Dias
ABC Ltd.
De Silva Perera
@ UCSC
Database Systems1
Existence Conditions
Many to Many
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
E-R Modelling
1:1 Ma
1:N Ma
1:1 Op
1:N Op
Crow’s Foot
@ UCSC
Database Systems1
1:1 Ma
1:N Ma
1:1 Op
1:N Op
Chen/Bachman
@ UCSC
Database Systems1
1:1 Ma 1 1
1 N
1:N Ma
Chen
@ UCSC
Database Systems1
1:1 Ma
1:N Ma
1:1 Op
1:N Op
Reiner
@ UCSC
Database Systems1
0,1 1,1
1:1 Op
0,N 1,1
1:N Op
Datarun
@ UCSC
Database Systems1
1:1 Ma
1:N Ma
1:1 Op
1:N Op
IRM
@ UCSC
Database Systems1
@ 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
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
Department
Number Manager
Location Start date
Number of Employees
@ UCSC
Database Systems1
Dept Name
Department Location
Phone
Employees
@ UCSC
Database Systems1
Location
@ UCSC
Database Systems1
Name
Works for Department
National ID
Supervise Employee
Address
Salary
Emp No
Sex
Birth Date
@ UCSC
Database Systems1
First Name
Emp No
Mid Initials
Emp Name
Last Name
Employee NID
Address
Salary
Gender
DOB
@ UCSC
Database Systems1
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
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
Employee Department
manage
has control
works on
Dependent Project
@ UCSC
Database Systems1
@ UCSC
Database Systems1
• Domain Constraints
– A specification of the characteristics of the data
values that can be associated with one or more
attributes
@ 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
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
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
Employee
o
Vehicle
d Employee Student
@ UCSC
Database Systems1
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
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
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
© UCSC
Database Systems1
Map Binary One-to-Many
Relationships
Create a relation for the two entity types
participating in the relationships (step 1)
© 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
Department
Employee
Employees
Salary
© 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
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
© UCSC
Database Systems1
Map Unary One-to-Many
Relationships
Create a relation for the entity type (step 1)
© UCSC
Database Systems1
First Name
Mid Initials
NID Emp Name
Last Name
Address supervise
Salary Emp No
Gender
Employee
DOB
© UCSC
Database Systems1
Quantity
contain Name
Item No
Item
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)
© UCSC
Database Systems1
First Name
Mid Initials
NID Emp Name
Last Name
Address marry
Salary Emp No
Gender
Employee
DOB
Relationships
Convert a ternary relationship to an
associative entity
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
© UCSC