UNIT-I

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

1. DBMS Application

2. DBMS Vs File Systems

3. View of DATA

4. DB Language (DML, DDL)

5. DB Users and Administrator

6. Data storage and Querying

7. DBMS Architecture

8. History of Database Systems

9. DB design and ER diagrams

10. Relationships & sets

11. Features of the ER model

12. Conceptual design with ER model

13. Large enterprises

14. Introduction to relational model

15. Enforcing integrity constraints

16. Logical Database Design

17. Logical Database Design

18. Introduction to Views

1. Database System Applications:

DBMS contains information about a particular enterprise

1. Collection of interrelated data

2. Set of programs to access the data
3. An environment that is both convenient and efficient to use
Database Applications:

1. Banking: all transactions

2. Airlines: reservations, schedules
3. Universities: registration, grades
4. Sales: customers, products, purchases
5. Online retailers: order tracking, customized recommendations
6. Manufacturing: production, inventory, orders, supply chain
7. Human resources: employee records, salaries, tax deductions
8. Databases touch all aspects of our lives

What Is a DBMS?

 A very large, integrated collection of data.

 Models real-world enterprise. Entities (e.g., students, courses) Relationships (e.g.,
Madonna is taking CS564)
 A Database Management System (DBMS) is a software package designed to store and
manages databases.
Why Use a DBMS?

 Data independence and efficient access.

 Reduced application development time.
 Data integrity and security.
 Uniform data administration.
 Concurrent access, recovery from crashes.
Why Study Databases??

 Shift from computation to information at the “low end”: scramble to webspace (a

mess!) at the “high end”: scientific applications
  Datasets increasing in diversity and volume. Digital libraries, interactive video, Human
Genome project, EOS project ... need for DBMS exploding
 DBMS encompasses most of CS OS, languages, theory, AI, multimedia, logic

2. Purpose of Database Systems:

In the early days, database applications were built directly on top of file systems

Drawbacks of using file systems to store data:

 Data redundancy and inconsistency

 Multiple file formats, duplication of information in different files
 Difficulty in accessing data
 Need to write a new program to carry out each new task
 Data isolation — multiple files and formats
 Integrity problems
 Hard to add new constraints or change existing ones
 Atomicity of updates

 Failures may leave database in an inconsistent state with partial updates carried out

 Example: Transfer of funds from one account to another should either complete or not
happen at all

 Concurrent access by multiple users

 Concurrent accessed needed for performance

 Uncontrolled concurrent accesses can lead to inconsistencies

 Example: Two people reading a balance and updating it at the same time

 Security problems

 Hard to provide user access to some, but not all, data

 Database systems offer solutions to all the above problems

 Files vs. DBMS:

 Application must stage large datasets between main memory and secondary storage
(e.g., buffering, page-oriented access, 32-bit addressing, etc.)
 Special code for different queries
 Must protect data from inconsistency due to multiple concurrent users
 Crash recovery
 Security and access control

3. View of Data:

An architecture for a database system :

4. Data Abstraction:
 Major purpose of dbms is to provide users with abstract view of data i.e. the system
hides cert ain details of how the data are stored and maintained. Since database system
users are not computer trained,developers hide the complexity from users through 3
levels of abstraction , to simplify user’s interaction with the system.
Levels of Abstraction

1) Physical level of data abstraction:

describes how a record (e.g., customer) is stored.This s the lowest level of abstraction which
describes how data are actually stored.
 2) Logical level of data abstraction:
This level hides what data are actually stored in the database and what relations hip exists
among them. describes data stored in database, and the relationships among the data.
type customer = recor

customer_id:string;
customer_name:string;
customer_stree:string;
customer_city : string;

end;

3) View Level of data abstraction:

View provides security mechanism to prevent user from accessing certain parts of database.
application programs hide details of data types. Views can also hide information (such as an
employee’s salary) for security purposes.

Summary

• DBMS used to maintain, query large datasets.

• Benefits include recovery from system crashes, concurrent access, quick application

development, data integrity and security.

• Levels of abstraction give data independence.

• A DBMS typically has a layered architecture.

• DBAs hold responsible jobs and are well-paid!

• DBMS R&D is one of the broadest, most exciting areas in CS.

5. Instances and Schemas:

Similar to types and variables in programming languages

Schema – the logical structure of the database

  Example: The database consists of information about a set of customers and accounts
and the relationship between them)Analogous to type information of a variable in a
program
Physical schema: database design at the physical level

Logical schema: database design at the logical level Instances and Schemas

Instance – the actual content of the database at a particular point in time alogous to the value
of a variable.

Physical Data Independence – the ability to modify the physi cal schema without
changing the logical schema .

Applications depend on the logical schema

In general, the interfaces between the various levels and components should be well defined so

that changes in some parts do not seriously influence others.

6. Data Models:

A collection of tools for describing

– Data
– Data relationships
– Data semantics
– Data constraints
– Relational model
– Entity-Relationship data model (mainly for database design)
– Object-based data models (Object-oriented and Object-relational)
– Semi structured data model (XML)
– Other older models:
o Network model
o Hierarchical model
1. A data model is a collection of concepts for describing data.
2. A schema is a description of a particular collection of data, using the a given data
model.
3. The relational model of data is the most widely used model today.
Main concept: relation, basically a table with rows and columns.
 Every relation has a schema, which describes the columns, or fields.

Example: University Database

Conceptual schema:

Students(sid: string, name: string, login: string, age: integer, gpa:real)

Courses(cid: string, cname:string, credits:integer)

Enrolled(sid:string, cid:string, grade:string)

Physical schema:

Relations stored as unordered files.

Index on first column of Students.

External Schema (View):

Course_info(cid:string,enrollment:integer)

Data Independence:

Applications insulated from how data is structured and stored.

Logical data independence: Protection from changes in logical structure of data.

Physical data independence: Protection from changes in physical structure of data.

7. Data base Languages:

Data Manipulation Language (DML):

• Language for accessing and manipulating the data organized by the appropriate data

Model.
• DML also known as query language
• Two classes of languages

Procedural – user specifies what data is required and how to get those data

Declarative (nonprocedural) – user specifies what data is required without specifying how to
 get those data

Data Definition Language (DDL):

• Specification notation for defining the database schema

Example: create table account (

account_number char(10),

branch_name char(10),

balance integer)

• DDL compiler generates a set of tables stored in a data dictionary

• Data dictionary contains metadata (i.e., data about data)

– Database schema

– Data storage and definition language

• Specifies the storage structure and access methods used

– Integrity constraints

• Domain constraints

• Referential integrity (e.g. branch_name must correspond to a valid

branch in the branch table)

– Authorization

8. Data Base Access from Application Programs:

• SQL: widely used non-procedural language

– Example: Find the name of the customer with customer-id 192-83-7465

select customer.customer_name
from customer
where customer.customer_id = ‘192-83-7465’

– Example: Find the balances of all accounts held by the customer with customer-
 Id 192-83-7465.
select account.balance
from depositor, account
where depositor.customer_id = ‘192-83-7465’ and
depositor.account_number = account.account_number

SQL: widely used non-procedural language

Example: Find the name of the customer with customer-id 192-83-7465

select customer.customer_name
from customer
where customer.customer_id = ‘192-83-7465’

Example: Find the balances of all accounts held by the customer with customer-id 192-83-7465
select account.balance
from depositor, account
where depositor.customer_id = ‘192-83-7465’ and
depositor.account_number = account.account_number

SQL

• Application programs generally access databases through one of

– Language extensions to allow embedded SQL

– Application program interface (e.g., ODBC/JDBC) which allow SQL queries to

be sent to a database.

9. Transaction Management:

• A transaction is a collection of operations that performs a single logical function in a

database application

• Transaction-management component ensures that the database remains in a

consistent (correct) state despite system failures (e.g., power failures and operating

system crashes) and transaction failures.

• Concurrency-control manager controls the interaction among the concurrent

transactions, to ensure the consistency of the database.

10. Data storage and Querying:

– Storage management
– Query processing
– Transaction processing
Storage Management

• Storage manager is a program module that provides the interface between the low-level

data stored in the database and the application programs and queries submitted to the

system.

• The storage manager is responsible to the following tasks:

– Interaction with the file manager

– Efficient storing, retrieving and updating of data

• Issues:

– Storage access

– File organization

– Indexing and hashing

Query Processing

1. Parsing and translation

2. Optimization
3. Evaluation
• Alternative ways of evaluating a given query

– Equivalent expressions

– Different algorithms for each operation

• Cost difference between a good and a bad way of evaluating a query can be enormous

• Need to estimate the cost of operations

– Depends critically on statistical information about relations which the database

must maintain

– Need to estimate statistics for intermediate results to compute cost of complex

expressions
11. Database Architecture:

The architecture of a database systems is greatly influenced by the underlying computer

system on which the database is running:

• Centralized

• Client-server

• Parallel (multiple processors and disks)

• Distributed

Overall System Structure

 Database Application Architectures:

12. Database Users and Administrators:

Database Users

Users are differentiated by the way they expect to interact with the system

• Application programmers – interact with system through DML calls

• Sophisticated users – form requests in a database query language

• Specialized users – write specialized database applications that do not fit into the

traditional data processing framework

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

previously

– Examples, people accessing database over the web, bank tellers, clerical staff
Database Administrator

• Coordinates all the activities of the database system

– has a good understanding of the enterprise’s information resources and needs.

• Database administrator's duties include:

– Storage structure and access method definition

– Schema and physical organization modification

– Granting users authority to access the database

– Backing up data

– Monitoring performance and responding to changes

– Database tuning.

13. History of Database Systems:

• 1950s and early 1960s:

– Data processing using magnetic tapes for storage

• Tapes provide only sequential access

– Punched cards for input

• Late 1960s and 1970s:

– Hard disks allow direct access to data

– Network and hierarchical data models in widespread use

– Ted Codd defines the relational data model

• Would win the ACM Turing Award for this work

• IBM Research begins System R prototype

 • UC Berkeley begins Ingres prototype

– High-performance (for the era) transaction processing

• 1980s:

– Research relational prototypes evolve into commercial systems

• SQL becomes industry standard

– Parallel and distributed database systems

– Object-oriented database systems

• 1990s:

– Large decision support and data-mining applications

– Large multi-terabyte data warehouses

– Emergence of Web commerce

• 2000s:

– XML and XQuery standards

– Automated database administration

– Increasing use of highly parallel database systems

– Web-scale distributed data storage systems

14. Introduction to Database Design:

• Conceptual design: (ER Model is used at this stage.)

– What are the entities and relationships in the enterprise?

– What information about these entities and relationships should we store in the

database?

– What are the integrity constraints or business rules that hold?

 – A database `schema’ in the ER Model can be represented pictorially (ER

diagrams).

– Can map an ER diagram into a relational schema.

15. ER Diagrams:

• Entity: Real-world object distinguishable from other objects. An entity is described (in

DB) using a set of attributes.

• Entity Set: A collection of similar entities. E.g., all employees.

– All entities in an entity set have the same set of attributes. (Until we consider

ISA hierarchies, anyway!)

– Each entity set has a key.

– Each attribute has a domain.

• Relationship: Association among two or more entities. E.g., Attishoo works in

 Pharmacy department.

• Relationship Set: Collection of similar relationships.

– An n-ary relationship set R relates n entity sets E1 ... En; each relationship in R

involves entities e1 E1, ..., en En

• Same entity set could participate in different relationship sets, or in

different “roles” in same set.

Modeling:

• A database can be modeled as:

– a collection of entities,

– relationship among entities.

15. Entities and Entity Sets:

• An entity is an object that exists and is distinguishable from other objects.

– Example: specific person, company, event, plant

• Entities have attributes

– Example: people have names and addresses

• An entity set is a set of entities of the same type that share the same properties.

– Example: set of all persons, companies, trees, holidays

 Example:Entity Sets customer and loan

16. Attributes:

• An entity is represented by a set of attributes, that is descriptive properties possessed by

all members of an entity set.

• Domain – the set of permitted values for each attribute

• Attribute types:

– Simple and composite attributes.

– Single-valued and multi-valued attributes

• Example: multivalued attribute: phone_numbers

– Derived attributes

• Can be computed from other attributes

• Example: age, given date_of_birth

• Composite Attributes

Mapping Cardinality Constraints

• Express the number of entities to which another entity can be associated via a relationship set.

• Most useful in describing binary relationship sets.

• For a binary relationship set the mapping cardinality must be one of the following

types:

– One to one

– One to many

– Many to one

– Many to many
Mapping Cardinalities:

Note: Some elements in A and B may not be mapped to any elements in the other set

Mapping Cardinalities

Note: Some elements in A and B may not be mapped to any elements in the other set
17. Relationships and Relationship Sets

• A relationship is an association among several entities

A relationship set is a mathematical relation among n  2 entities, each taken from

entity sets

• {(e1, e2, … en) | e1  E1, e2  E2, …, en  En}where (e1, e2, …, en) is a relationship

– Example:

(Hayes, A-102)  depositor

Relationship Set borrower

An attribute can also be property of a relationship set.

• For instance, the depositor relationship set between entity sets customer and account

may have the attribute access-date

Degree of a Relationship Set

• Refers to number of entity sets that participate in a relationship set.

• Relationship sets that involve two entity sets are binary (or degree two). Generally,

most relationship sets in a database system are binary.

• Relationship sets may involve more than two entity sets.

 Example: Suppose employees of a bank may have jobs (responsibilities) at

multiple branches, with different jobs at different branches. Then there is a

ternary relationship set between entity sets employee, job, and branch

• Relationships between more than two entity sets are rare. Most relationships are binary.
Weak Entities

• A weak entity can be identified uniquely only by considering the primary key of another

(owner) entity.

 Owner entity set and weak entity set must participate in a one-to-many

relationship set (one owner, many weak entities).

 Weak entity set must have total participation in this identifying relationship set.

Weak Entity Sets

• An entity set that does not have a primary key is referred to as a weak entity set.

• The existence of a weak entity set depends on the existence of a identifying entity set

 it must relate to the identifying entity set via a total, one-to-many relationship
 set from the identifying to the weak entity set

 Identifying relationship depicted using a double diamond

• The discriminator (or partial key) of a weak entity set is the set of attributes that

distinguishes among all the entities of a weak entity set.

• The primary key of a weak entity set is formed by the primary key of the strong entity

set on which the weak entity set is existence dependent, plus the weak entity set’s
discriminator.
• depict a weak entity set by double rectangles.

• underline the discriminator of a weak entity set with a dashed line.

• payment_number – discriminator of the payment entity set

• Primary key for payment – (loan_number, payment_number)

• Note: the primary key of the strong entity set is not explicitly stored with the weak

entity set, since it is implicit in the identifying relationship.

• If loan_number were explicitly stored, payment could be made a strong entity, but then

the relationship between payment and loan would be duplicated by an implicit

relationship defined by the attribute loan_number common to payment and loan
More Weak Entity Set Examples

• In a university, a course is a strong entity and a course_offering can be modeled as a

weak entity

• The discriminator of course_offering would be semester (including year) and

section_number (if there is more than one section)

• If we model course_offering as a strong entity we would model course_number as an

attribute.

Then the relationship with course would be implicit in the course_number attribute
ISA (`is a’) Hierarchies
Aggregation

• Relationship sets works_on and manages represent overlapping information

– Every manages relationship corresponds to a works_on relationship

• However, some works_on relationships may not correspond to any

manages relationships .So we can’t discard the works_on relationship

• Eliminate this redundancy via aggregation

– Treat relationship as an abstract entity

– Allows relationships between relationships

– Abstraction of relationship into new entity

• Without introducing redundancy, the following diagram represents:

– An employee works on a particular job at a particular branch

– An employee, branch, job combination may have an associated manager

 E-R Diagram with Aggregation

19. Conceptual Design with ER Model

• Design choices:

– Should a concept be modeled as an entity or an attribute?

– Should a concept be modeled as an entity or a relationship?

– Identifying relationships: Binary or ternary? Aggregation?

• Constraints in the ER Model:

– A lot of data semantics can (and should) be captured.

– But some constraints cannot be captured in ER diagrams.

Entity vs. Attribute

• Should address be an attribute of Employees or an entity (connected to Employees by a

relationship)?

• Depends upon the use we want to make of address information, and the semantics of the

data:

If we have several addresses per employee, address must be an entity

(since attributes cannot be set-valued).

If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given
city, address must be modeled as an entity (since attribute values are atomic).
Entity vs. Relationship
Binary vs. Ternary Relationships

• Previous example illustrated a case when two binary relationships were better than one

ternary relationship.

• An example in the other direction: a ternary relation Contracts relates entity sets Parts,

Departments and Suppliers, and has descriptive attribute qty. No combination of binary
relationships is an adequate substitute:
– S “can-supply” P, D “needs” P, and D “deals-with” S does not imply that D

has agreed to buy P from S.

– How do we record qty?

20.Conceptual Design for Large Enterprises:

Summary of Conceptual Design

• Conceptual design follows requirements analysis,

– Yields a high-level description of data to be stored

• ER model popular for conceptual design

– Constructs are expressive, close to the way people think about their applications.

• Basic constructs: entities, relationships, and attributes (of entities and relationships).

• Some additional constructs: weak entities, ISA hierarchies, and aggregation.

• Note: There are many variations on ER model.

• Several kinds of integrity constraints can be expressed in the ER model: key

constraints, participation constraints, and overlap/covering constraints for ISA

hierarchies. Some foreign key constraints are also implicit in the definition of a

relationship set.

– Some constraints (notably, functional dependencies) cannot be expressed in the

ER model.

– Constraints play an important role in determining the best database design for an

enterprise.

• ER design is subjective. There are often many ways to model a given scenario!

Analyzing alternatives can be tricky, especially for a large enterprise. Common choices
include:
– Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether

or not to use ISA hierarchies, and whether or not to use aggregation.

• Ensuring good database design: resulting relational schema should be analyzed and
 refined further. FD information and normalization techniques are especially useful.

21. Introduction to relational model:

Relational Database: Definitions

• Relational database: a set of relations

• Relation: made up of 2 parts:

– Instance : a table, with rows and columns.

#Rows = cardinality, #fields = degree / arity.

– Schema : specifies name of relation, plus name and type of each column.

• E.G. Students (sid: string, name: string, login: string, age: integer, gpa:

real).

• Can think of a relation as a set of rows or tuples (i.e., all rows are distinct).

Example Instance of Students Relation

sid name login age gpa

53666 Jones jones@cs 18 3.4
53688 Smith smith@eecs 18 3.2
53650 Smith smith@math 19 3.8

Cardinality = 3, degree = 5, all rows distinct

Do all columns in a relation instance have to be distinct?

Relational Query Languages

• A major strength of the relational model: supports simple, powerful querying of data.

• Queries can be written intuitively, and the DBMS is responsible for efficient evaluation.

– The key: precise semantics for relational queries.

– Allows the optimizer to extensively re-order operations, and still ensure that the

answer does not change.

The SQL Query Language

 Creating Relations in SQL

• Creates the Students relation. Observe that the type of each field is specified, and
enforced by the DBMS whenever tuples are added or modified.

CREATE TABLE Students (sid: CHAR(20), name: CHAR(20), login: CHAR(10), age: INTEGER,

gpa: REAL)

• As another example, the Enrolled table holds information about courses that students
take.

CREATE TABLE Enrolled (sid: CHAR(20), cid: CHAR(20), grade: CHAR(2))

22.Integrity Constraints (ICs) over Relations:

• IC: condition that must be true for any instance of the database; e.g., domain constraints.

• ICs are specified when schema is defined.

• ICs are checked when relations are modified.

• A legal instance of a relation is one that satisfies all specified ICs.

• DBMS should not allow illegal instances.

• If the DBMS checks ICs, stored data is more faithful to real-world meaning.

– Avoids data entry errors, too!

Primary Key Constraints

• A set of fields is a key for a relation if :

1. No two distinct tuples can have same values in all key fields, and

2. This is not true for any subset of the key.

– Part 2 false? A superkey.

– If there’s >1 key for a relation, one of the keys is chosen (by DBA) to be the

primary key.

• E.g., sid is a key for Students. (What about name?) The set {sid, gpa} is a superkey.
 Primary and Candidate Keys in SQL

• Possibly many candidate keys (specified using UNIQUE), one of which is chosen as

the primary key.

Foreign Keys, Referential Integrity

• Foreign key : Set of fields in one relation that is used to `refer’ to a tuple in another

relation. (Must correspond to primary key of the second relation.) Like a `logical
pointer’.
• E.g. sid is a foreign key referring to Students:

– Enrolled(sid: string, cid: string, grade: string)

– If all foreign key constraints are enforced, referential integrity is achieved, i.e.,

no dangling references.

– Can you name a data model w/o referential integrity?

• Links in HTML!

Foreign Keys in SQL

• Only students listed in the Students relation should be allowed to enroll for courses.

23. Enforcing Integrity constraints:

• Consider Students and Enrolled; sid in Enrolled is a foreign key that references

Students.

• What should be done if an Enrolled tuple with a non-existent student id is inserted?

(Reject it!)

• What should be done if a Students tuple is deleted?

– Also delete all Enrolled tuples that refer to it.

 – Disallow deletion of a Students tuple that is referred to.

– Set sid in Enrolled tuples that refer to it to a default sid.

– (In SQL, also: Set sid in Enrolled tuples that refer to it to a special value null,

denoting `unknown’ or `inapplicable’.)

• Similar if primary key of Students tuple is updated.

Referential Integrity in SQL

• SQL/92 and SQL:1999 support all 4 options on deletes and updates.

– Default is NO ACTION (delete/update is rejected)

– CASCADE (also delete all tuples that refer to deleted tuple)

– SET NULL / SET DEFAULT (sets foreign key value of referencing tuple)

Where do ICs Come From?

• ICs are based upon the semantics of the real-world enterprise that is being described in

the database relations.

• We can check a database instance to see if an IC is violated, but we can NEVER infer

that an IC is true by looking at an instance.

– An IC is a statement about all possible instances!

– From example, we know name is not a key, but the assertion that sid is a key is

given to us.

• Key and foreign key ICs are the most common; more general ICs supported too.

24. Querying Relational Data:

Formal Relational Query Languages

• Two mathematical Query Languages form the basis for “real” languages (e.g. SQL),

and for implementation:

– Relational Algebra: More operational, very useful for representing execution

plans.

– Relational Calculus: Lets users describe what they want, rather than how to

compute it. (Non-operational, declarative.)

Preliminaries

• A query is applied to relation instances, and the result of a query is also a relation

instance.

– Schemas of input relations for a query are fixed (but query will run regardless of

instance!)

– The schema for the result of a given query is also fixed! Determined by

definition of query language constructs.

• Positional vs. named-field notation:

– Positional notation easier for formal definitions, named-field notation more

readable.

– Both used in SQL

 • “Sailors” and “Reserves” relations for our examples.

• We’ll use positional or named field notation, assume that names of fields in query
results are `inherited’ from names of fields in query input relations.
25. Logical DB Design:

• Entity sets to tables:

Relationship Sets to Tables

• In translating a relationship set to a relation, attributes of the relation must include:

– Keys for each participating entity set (as foreign keys).

• This set of attributes forms a superkey for the relation.

– All descriptive attributes.

Review: Key Constraints

 • Each dept has at most one manager, according to the key constraint on Manages.

Translating ER Diagrams with Key Constraints

• Map relationship to a table:

– Note that did is the key now!

– Separate tables for Employees and Departments.

• Since each department has a unique manager, we could instead combine Manages and
Departments.
Review: Participation Constraints
 • Does every department have a manager?

– If so, this is a participation constraint: the participation of Departments in

Manages is said to be total (vs. partial).

• Every did value in Departments table must appear in a row of the

Manages table (with a non-null ssn value!)

Participation Constraints in SQL

• We can capture participation constraints involving one entity set in a binary

relationship, but little else (without resorting to CHECK constraints).

Review: Weak Entities

• A weak entity can be identified uniquely only by considering the primary key of another
(owner) entity.

– Owner entity set and weak entity set must participate in a one-to-many
relationship set (1 owner, many weak entities).

– Weak entity set must have total participation in this identifying relationship set.
Translating Weak Entity Sets

• Weak entity set and identifying relationship set are translated into a single table.

– When the owner entity is deleted, all owned weak entities must also be deleted.
Review: ISA Hierarchies

• Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity?

(Allowed/disallowed)

• Covering constraints: Does every Employees entity also have to be an Hourly_Emps or

a Contract_Emps entity? (Yes/no)

Translating ISA Hierarchies to Relations

• General approach:

– 3 relations: Employees, Hourly_Emps and Contract_Emps.

Hourly_Emps: Every employee is recorded in Employees. For hourly emps, extra info
recorded in Hourly_Emps (hourly_wages, hours_worked, ssn); must delete Hourly_Emps tuple
if referenced Employees tuple is deleted).

• Queries involving all employees easy, those involving just Hourly_Emps

 require a join to get some attributes.

• Alternative: Just Hourly_Emps and Contract_Emps.

– Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.

– Each employee must be in one of these two subclasses.

Review: Binary vs. Ternary Relationships

• What are the additional constraints in the 2nd diagram?

Binary vs. Ternary Relationships (Contd.)

• The key constraints allow us to combine Purchaser with Policies and Beneficiary with

Dependents.
 • Participation constraints lead to NOT NULL constraints.

26. Introduction To Views:

Views and Security

• Views can be used to present necessary information (or a summary), while hiding

details in underlying relation(s).

– Given YoungStudents, but not Students or Enrolled, we can find students s who

have are enrolled, but not the cid’s of the courses they are enrolled in.

• View Definition

• A relation that is not of the conceptual model but is made visible to a user as a “virtual
 relation” is called a view.

• A view is defined using the create view statement which has the form

create view v as < query expression >

where <query expression> is any legal SQL expression. The view name is represented

by v.

• Once a view is defined, the view name can be used to refer to the virtual relation that

the view generates.

• Example Queries

• A view consisting of branches and their customers

• Uses of Views

• Hiding some information from some users

– Consider a user who needs to know a customer’s name, loan number and branch

name, but has no need to see the loan amount.

– Define a view
(create view cust_loan_data as
select customer_name, borrower.loan_number, branch_name
from borrower, loan
where borrower.loan_number = loan.loan_number )

– Grant the user permission to read cust_loan_data, but not borrower or loan

• Predefined queries to make writing of other queries easier

– Common example: Aggregate queries used for statistical analysis of data

– Processing of Views

• When a view is created

– the query expression is stored in the database along with the view name
 – the expression is substituted into any query using the view

• Views definitions containing views

– One view may be used in the expression defining another view

– A view relation v1 is said to depend directly on a view relation v2 if v2 is used in

the expression defining v1

– A view relation v1 is said to depend on view relation v2 if either v1 depends

directly to v2 or there is a path of dependencies from v1 to v2

– A view relation v is said to be recursive if it depends on itself.

• View Expansion

• A way to define the meaning of views defined in terms of other views.

• Let view v1 be defined by an expression e1 that may itself contain uses of view
relations.

• View expansion of an expression repeats the following replacement step:

repeat
Find any view relation vi in e1
Replace the view relation vi by the expression defining vi
until no more view relations are present in e1

• As long as the view definitions are not recursive, this loop will terminate

• With Clause

• The with clause provides a way of defining a temporary view whose definition is

available only to the query in which the with clause occurs.

• Find all accounts with the maximum balance

with max_balance (value) as

select max (balance)
 from account
select account_number
from account, max_balance
where account.balance = max_balance.value

• Complex Queries using With Clause

• Find all branches where the total account deposit is greater than the average of the total

account deposits at all branches.

• Update of a View

• Create a view of all loan data in the loan relation, hiding the amount attribute

create view loan_branch as

select loan_number, branch_name
from loan

• Add a new tuple to loan_branch

insert into loan_branch

values ('L-37‘, 'Perryridge‘)

This insertion must be represented by the insertion of the tuple

('L-37', 'Perryridge', null ) into the loan relation

27. Destroying and Altering Tables and Views:

• Destroys the relation Students. The schema information and the tuples are deleted.

• Adding and Deleting Tuples

• Can insert a single tuple using:

• What if Policies is a weak entity set?

• Views

• A view is just a relation, but we store a definition, rather than a set of tuples.