DBMS SOLUTION

MODULE 1

Book: FUNDAMENTALS OF Database Systems: by RamezElmasri, Shamkant B. Navathe, 7th Edition

1.1 Define the following terms:

• Data: Raw facts that have meaning (e.g., name, age, marks).

• Database: Organized collection of related data.

• DBMS (Database Management System): Software used to manage and access databases (e.g., MySQL).

• Database System: DBMS + Database + Users + Applications.

• Database Catalog: Stores descriptions (metadata) about database structure.

• Program-Data Independence: Programs are not dependent on physical data storage.

• User View: Subset of the database visible to a user.

• DBA (Database Administrator): Person responsible for managing and controlling the database.

• End User: People who use the database through applications.

 • Canned Transaction: Predefined query executed by users (e.g., ATM balance inquiry).

• Deductive Database System: Combines logic programming with database concepts.

• Persistent Object: Data that exists beyond program execution.

• Meta-data: Data about data (e.g., table names, column types).

• Transaction-processing application: Application that executes many database transactions (e.g.,

banking system).

1.2 What four main types of actions involve databases?

1. Define: Specify data types, structures, and constraints.

2. Construct: Store data in the database.

3. Manipulate: Retrieve, insert, delete, or update data.

4. Share: Allow multiple users to access data concurrently.

1.3 Main characteristics of the database approach (vs. file systems):

• Data is shared and integrated.

• Data redundancy is minimized.

• Data consistency is maintained.

• Supports data independence.

• Uses a centralized DBMS, unlike scattered file systems.

• Provides security, concurrency control, and backup.

1.4 Responsibilities of DBA and database designers:

• DBA:

o Database storage management.

o Security, backup, and recovery.

o Monitoring performance.

• Database Designers:

o Identify data requirements.

o Design schema and relationships.

 o Decide data constraints.

1.5 Different types of database end users:

1. Casual users: Occasionally query data using ad-hoc queries.

2. Naive/Parametric users: Use canned transactions (e.g., bank clerks).

3. Sophisticated users: Use database tools and query languages.

4. Standalone users: Maintain personal databases.

Activities: Querying, updating, and generating reports.

1.6 Capabilities provided by a DBMS:

• Data definition and manipulation languages (DDL & DML)

• Transaction management

• Concurrency control

• Backup and recovery

• Security and authorization

• Data independence and integrity constraints

1.7 Difference between database systems and information retrieval systems:

Feature Database System Information Retrieval System

Data type Structured Unstructured (text, docs)

Query Exact match (SQL) Keyword-based search

Consistency High Less strict

Examples Banking, Inventory Google Search, Library catalog

1.8 Informal queries and updates (Figure 1.2 example):

Assume database has Employee, Department, Project tables.

Queries:

• List all employees in “IT” department.

• Find total salary of all employees.

Updates:
 • Add a new employee.

• Update department location.

• Delete a resigned employee.

1.9 Difference between controlled and uncontrolled redundancy:

• Controlled redundancy: Data duplicated for efficiency, with DBMS control (e.g., department name
stored once and referenced).

• Uncontrolled redundancy: Data repeated unnecessarily, causing inconsistency (e.g., same employee
data stored in multiple files).

1.10 Relationships among records (Figure 1.2 example):

• Employee → Department: Many-to-one (each employee belongs to one department).

• Department → Project: One-to-many (each department controls many projects).

• Employee → Project: Many-to-many (employees work on multiple projects).

1.11 Additional user views (Figure 1.2):

• Payroll view: Employee salary details.

• Project management view: Project deadlines and budgets.

• HR view: Employee personal and job information.

• Admin view: Access control and database maintenance.

1.12 Examples of integrity constraints (Figure 1.2):

• Entity integrity: Employee_ID cannot be NULL.

• Referential integrity: Dept_ID in Employee must exist in Department.

• Domain constraint: Salary > 0.

• Key constraint: Dept_ID uniquely identifies departments.

1.13 Systems better suited for file processing:

• Small standalone systems: e.g., personal address book.

 • Simple data storage: e.g., log files, temporary files.

• Real-time systems: e.g., embedded systems.

• Single-user applications: e.g., simple accounting software.

1.14. Consider Figure 1.2.

a. If the name of the ‘CS’ (Computer Science) Department changes to ‘CSSE’

(Computer Science and Software Engineering) Department and the corresponding

prefix for the course number also changes, identify the columns

in the database that would need to be updated.

b. Can you restructure the columns in the COURSE, SECTION, and

PREREQUISITE tables so that only one column will need to be updated?

1.14 (a)

If the CS department name changes to CSSE and the course-number prefix changes, these columns must be
updated:
 • STUDENT.Major — students whose major = CS must change to CSSE.

• COURSE.Department — the Department field for all CS courses.

• COURSE.Course_number — the course numbers that start with CS (e.g. CS1310, CS3320, CS3380) must
be updated to the new prefix.

• SECTION.Course_number — since SECTION stores the course number, those rows that reference CS
courses must be updated.

• PREREQUISITE.Course_number and PREREQUISITE.Prerequisite_number — both columns contain

course numbers and must be updated where the prefix changes.

(Other tables like GRADE_REPORT use Section_identifier and do not need changes.)

1.14 (b)

Yes. Restructure to avoid multiple updates by factoring department/prefix out of the course-number string
and using keys/foreign keys. Example design (short):

New tables / columns

• DEPARTMENT(dept_code PK, dept_name) — e.g. dept_code = 'CS', dept_name = 'Computer Science'.

• COURSE(course_id PK, dept_code FK → DEPARTMENT, course_num) — store numeric part separately

(course_num = 1310) not "CS1310".

• SECTION(section_id PK, course_id FK → COURSE, semester, year, instructor)

• PREREQUISITE(course_id FK, prerequisite_course_id FK) — both point to COURSE.course_id.

• STUDENT(..., major_dept_code FK → DEPARTMENT) — store major as dept_code FK.

Why this helps:

• The course prefix is stored once (in DEPARTMENT as dept_code or generated from it).

• If the department changes name/prefix, you update one place (the DEPARTMENT entry or its code
mapping) and all courses/sections/prerequisites continue to refer by keys — no string updates needed.

10 marks qs:

2.1. Define the following terms: data model, database schema, database state, internal schema, conceptual
schema, external schema, data independence,DDL, DML, SDL, VDL, query language, host language, data
sublanguage,database utility, catalog, client/server architecture, three-tier architecture,and n-tier architecture.
2.4. Describe the three-schema architecture. Why do we need mappings among schema levels? How do
different schema definition languages support thisarchitecture?

2.12. Think of different users for the database shown in Figure 1.2. What types of applications would each user
need? To which user category would each belong, and what type of interface would each need?
2.13. Choose a database application with which you are familiar. Design a schema and show a sample database
for that application, using the notation of Figures 1.2 and 2.1. What types of additional information and
constraints would you like to represent in the schema? Think of several users of your database, and design a
view for each.

2.14. If you were designing a Web-based system to make airline reservations and sell airline tickets, which
DBMS architecture would you choose from Section 2.5? Why? Why would the other architectures not be a
good choice?

2.15. Consider Figure 2.1. In addition to constraints relating the values of columns in one table to columns in
another table, there are also constraints that impose restrictions on values in a column or a combination of
columns within a table. One such constraint dictates that a column or a group of columns must be unique
across all rows in the table. For example, in the STUDENT table, the Student_number column must be unique
(to prevent two different students from having the same Student_number). Identify the column or the group
of columns in the other tables that must be unique across all rows in the table. ANS:

2.1 Define the following terms

Term Definition

Data Model A set of concepts for describing the structure of a database (e.g.,
relational model).

Database Schema Logical design or blueprint of the database showing tables, fields, and
relationships.

Database State Actual data stored in the database at a particular moment.

Internal Schema Describes physical storage structure and access paths.

Conceptual Schema Logical view describing all entities and relationships in the database.

External Schema User-specific view or subset of the database.

Data Independence Ability to change schema at one level without affecting other levels.

DDL (Data Definition Language) Used to define schema (CREATE, ALTER, DROP).

DML (Data Manipulation Used to manipulate data (INSERT, UPDATE, DELETE, SELECT).
Language)

SDL (Storage Definition Used to define internal schema (storage structures).

Language)

VDL (View Definition Language) Used to define external/user views.

Query Language Language to retrieve and manipulate data (e.g., SQL).

Host Language General-purpose language (like C, Java) in which SQL is embedded.

 Data Sublanguage Specialized part of a host language used to access data (like SQL
embedded code).

Database Utility Tools for backup, recovery, loading, reorganization, etc.

Catalog Metadata repository that describes database objects and schema.

Client/Server Architecture Database runs on a server, users interact via client applications.

Three-Tier Architecture Separates presentation, application logic, and database layers.

N-Tier Architecture Extended multi-layered version of three-tier for scalability and

modularity.

2.4 Describe the three-schema architecture. Why mappings are needed?

Three-Schema Architecture:

1. Internal Schema – Describes physical storage structure (how data is stored).

2. Conceptual Schema – Describes logical structure (entities, relationships, constraints).

3. External Schema – Describes user views (different for each group of users).

Mappings:

• External → Conceptual mapping: Links user view to conceptual schema.

• Conceptual → Internal mapping: Links logical structure to physical storage.

Need for Mappings:

• Provides data abstraction and data independence.

• Allows schema modification at one level without affecting others.

• Supports multiple user views and efficient data management.

Schema Definition Languages:

• DDL defines conceptual schema.

• VDL defines external schema (views).

• SDL defines internal schema.

2.12 Users for Figure 1.2 database and their applications

User Type Example Application Interface

Student Naive user View grades, register for courses Web form / student portal
 Instructor Parametric user Enter or update grades, manage Input forms
sections

Department Casual user Generate performance reports Query interface / reports

head

DBA Specialized user Backup, user management, tuning Command-line tools

Programmer Sophisticated Develop new student modules SQL API / programming

user IDE

2.13 Design a sample database and schema

Example Application: Library Management System

Tables:

Table Columns

BOOK Book_ID, Title, Author, Category

MEMBER Member_ID, Name, Dept, Phone

ISSUE Issue_ID, Book_ID, Member_ID, Issue_Date, Return_Date

Relationships:

• Each Member can issue many Books.

• Each Book can be issued by multiple members over time.

Constraints:

• Book_ID, Member_ID, and Issue_ID are unique.

• Return_Date ≥ Issue_Date.

User Views:

User View

Librarian All books issued, overdue list

Student Books borrowed by self

Admin Reports of most issued books, fines, etc.

2.14 Airline reservation DBMS architecture choice

Chosen Architecture:
 Three-Tier Architecture

Why:

• Separates user interface (web/app), business logic (reservation rules), and database (flight data).

• Enhances security, scalability, and maintenance.

• Multiple users can access the same system safely.

Why not others:

• Centralized system: Not scalable for many users.

• Client/Server: Heavy load on server with direct access.

• N-tier beyond 3: Adds unnecessary complexity.

Hence, three-tier architecture (Web UI → Application server → DBMS) is most suitable.

2.15 Uniqueness constraints in Figure 1.2

Table Column(s) that must be unique

STUDENT Student_number

COURSE Course_number

SECTION Section_identifier

GRADE_REPORT (Student_number, Section_identifier) pair (a student cannot have multiple grades for the
same section)

PREREQUISITE (Course_number, Prerequisite_number) pair (no duplicate prerequisite entry)

5marks:
2.2 Main categories of data models and their differences

Main categories of data models:

1. Conceptual / High-level models: Describe data in a way users understand (e.g., ER model).

2. Logical / Representational models: Describe data structure in DBMS (e.g., relational model).

3. Physical / Low-level models: Describe how data is stored in memory and disks.

Differences among major models:

Model Description Key Feature

Relational Model Data stored in tables (rows & columns) Simple structure, uses SQL

Object Model Data as objects with attributes and methods Supports inheritance & encapsulation

XML Model Data stored as hierarchical XML documents Suited for web data exchange

2.3 Difference between database schema and database state

Term Definition

Database The logical design or structure of the database (tables, fields, relationships). It rarely
Schema changes.

Database State The actual content (data) stored in the database at a particular time. It changes
frequently.

Example:
Schema = definition of STUDENT(Name, Roll, Dept)
State = actual rows like (‘Smith’, 17, ‘CS’)

2.5 Logical vs Physical Data Independence

Type Definition Example

Logical Data Change in conceptual schema does not Add a new field in a table without
Independence affect external schema. changing user views.

Physical Data Change in physical storage does not affect Moving data to SSD from HDD.
Independence conceptual schema.

Harder to achieve:
Logical data independence is harder because conceptual changes often affect user views and applications.

2.6 Procedural vs Nonprocedural DML

 Type Description Example

Procedural DML User specifies how to get data (navigational). Embedded SQL, Relational Algebra.

Nonprocedural DML User specifies what data to retrieve, not how. SQL SELECT statement.

Example:

• Procedural: Loop through records manually.

• Nonprocedural: SELECT * FROM STUDENT WHERE CLASS=2;

2.7 User-friendly interfaces and their users

Interface Type Description Typical Users

Menu-based Choose options from menus Naive users (bank clerks)

Form-based Fill in fields on screen Parametric users

Graphical (GUI) Icons, drag-drop, visual forms Casual users

Natural Language Query in English-like commands Casual users

Speech-based Voice commands Mobile app users

Web-based Browser-based interface Online users / students

2.8 Other computer system software DBMS interacts with

1. Operating System (OS) – for file management, memory, and I/O.

2. File System – for physical data storage.

3. Network Software – for client-server communication.

4. Application Programs – that use DBMS functions.

5. Compiler / Interpreter – for embedded SQL and query execution.

6. Utilities (Backup, Recovery) – for maintenance.

2.9 Two-tier vs Three-tier Client/Server Architecture

Architecture Description Example

Two-tier Client directly communicates with database server. Desktop application (e.g., MS Access).

Three-tier Client → Application Server → Database Server. Web apps (e.g., online banking).
Difference:
Three-tier adds a middle layer for business logic → increases security, scalability, and performance.

2.10 Types of database utilities and tools

Utility / Tool Function

Loading Utility Loads data from external files into database.

Backup Utility Creates backup copies of database.

Recovery Utility Restores database after crash.

Monitoring / Performance Tools Tracks query speed and resource use.

Data Reorganization Tools Rebuild indexes, compact data.

User Management Tools Manage user access and permissions.

2.11 Functionality in n-tier architecture (n > 3)

Additional Functionality:

• Divides application logic into more specialized layers (e.g., business, authentication, analytics).

• Improves scalability, security, and load balancing.

• Supports distributed deployment and modular development.

Example (4-tier):
Client → Web Server → Application Server → Database Server.
5 marks:

Perfect, Angshul — here are your short, clear, and full-mark answers (5 marks each) for DBMS Unit 3 (3.1
– 3.15) — written simply so you can revise and score full marks easily.

3.1 Role of a high-level data model in database design

• Provides a conceptual view of the data (entities, attributes, and relationships).

• Helps designers and users communicate without worrying about physical details.

• Used in conceptual design phase to capture real-world requirements.

• Example: ER (Entity-Relationship) Model is a high-level data model.

• Acts as a blueprint before converting to a logical model (like relational).

3.2 Cases where NULL values are appropriate

1. Unknown value: e.g., student’s phone number not yet provided.

2. Not applicable: e.g., middle name for someone who doesn’t have one.
 3. Not available: e.g., grade not yet assigned.

4. Missing by design: e.g., optional attribute left blank in form.

3.3 Definitions

Term Definition

Entity Real-world object with independent existence (e.g., Student).

Attribute Property of an entity (e.g., Name, Age).

Attribute Value Actual data value for an attribute (e.g., ‘John’ for Name).

Relationship Instance Association between specific entities (e.g., Student ‘John’ enrolled in ‘DBMS’).

Composite Attribute Attribute made up of smaller parts (e.g., Name → First, Last).

Multivalued Attribute Attribute with multiple values (e.g., Phone Numbers).

Derived Attribute Attribute derived from others (e.g., Age from DOB).

Complex Attribute Combination of composite and multivalued attributes.

Key Attribute Attribute that uniquely identifies an entity (e.g., Roll No).

Value Set (Domain) Set of all possible values an attribute can take.

3.4 Entity type vs Entity vs Entity set

Term Definition

Entity Type Collection of entities with same attributes (e.g., STUDENT).

Entity Set All entities of a type that exist in database (e.g., all student records).

Entity One specific instance (e.g., Student ‘Ravi’).

Difference:

• Entity type = structure/design

• Entity set = data collection

• Entity = single row/record

3.5 Difference between attribute and value set

Term Meaning

Attribute Describes a property of entity (e.g., Name).

Value Set / Domain Defines all possible valid values that attribute can take (e.g., Name domain = string).

3.6 Relationship type vs instance vs set

Term Meaning

Relationship Type General association between entity types (e.g., Enrolls).

Relationship Instance Specific link between entities (e.g., Ravi enrolled in DBMS).

Relationship Set Collection of all relationship instances of a type.

3.7 Participation role

• Role describes the part played by an entity in a relationship.

• Example: In relationship “Employee manages Department”,

o Employee plays role Manager, Department plays role Managed_Department.

• Need: When the same entity type participates more than once in the same relationship (to avoid
confusion).

3.8 Two alternatives for specifying structural constraints

1. (min, max) notation: Specifies minimum and maximum number of times an entity participates.

o Example: Employee (1,1) → manages → Department (1,N)

2. Cardinality ratio and participation: Specifies 1:1, 1:N, M:N and whether total or partial participation.

Advantage: (min,max) gives detailed control.

Disadvantage: Slightly more complex to read.

3.9 When can an attribute of a binary relationship be migrated?

• It can be migrated to one of the participating entity types only if the relationship is 1:1 or 1:N.

• Example: In 1:N relationship Department–Employee (manages),

o Attribute Start_Date can be stored in the Employee entity (N-side).

• For M:N relationships, migration is not possible.

3.10 When relationships are treated as attributes

• The value set becomes a set of references (keys) to related entities.

• Example: Manager_ID as an attribute in Employee refers to another Employee.

• This concept forms the basis of object-oriented and object-relational models, where relationships are
represented as object references.

3.11 Recursive relationship type

• A relationship where an entity type is related to itself.

• Example:

o Employee manages Employee (Manager–Subordinate).

o Course has prerequisite Course.

• It needs role names to differentiate the entities.

3.12 Concept of weak entity and related terms

• Used when an entity depends on another entity for its identification.

• Owner Entity Type: Entity on which weak entity depends (e.g., Department).

• Weak Entity Type: Cannot be uniquely identified without owner (e.g., Dependent).

• Identifying Relationship Type: Links weak entity to owner (e.g., Works_for).

• Partial Key: Attribute(s) that uniquely identify weak entities under the same owner (e.g.,
Dependent_Name).

3.13 Can identifying relationship be of degree > 2?

Yes.

• If the weak entity depends on more than one owner entity.

• Example: Assignment entity depends on both Course and Student.

o Relationship: (Student, Course, Assignment).

• Here, identifying relationship degree = 3.

3.14 Conventions for displaying an ER schema

• Entity types: Rectangles

• Attributes: Ovals

• Relationships: Diamonds

• Primary key: Underlined

• Multivalued attribute: Double oval

• Derived attribute: Dashed oval

• Weak entity: Double rectangle

• Identifying relationship: Double diamond

• Lines: Show connections and participation constraints.

3.15 Naming conventions for ER diagrams

• Entity names → singular nouns, e.g., Employee, Student

• Attribute names → meaningful and unique, e.g., Emp_ID, Name

• Relationship names → verbs or verb phrases, e.g., Works_for, Enrolls_in

• Use capitalization for entities and camelCase or underscores for attributes.

• Ensure consistency and clarity throughout the design.

10-Mark Questions (Database Design Exercises)

3.16. Uniqueness Constraints in the UNIVERSITY Database (Figure 3.20)

Which combinations of attributes have to be unique for each individual SECTION entity in the UNIVERSITY
database (shown in Figure 3.20) to enforce each of the following miniworld constraints:

a. During a particular semester and year, only one section can use a particular classroom at a particular
DaysTime value. b. During a particular semester and year, an instructor can teach only one section at a
particular DaysTime value. c. During a particular semester and year, the section numbers for sections offered
for the same course must all be different. d. Can you think of any other similar constraints?
To enforce each miniworld constraint, the following attribute combinations must be unique for each SECTION:

a. Only one section can use a particular classroom at a given DaysTime during a semester and year

Unique combination:
(Semester, Year, Building, RoomNo, DaysTime)

Reason:
Prevents two sections from occupying the same classroom at the same time.

b. An instructor can teach only one section at a given DaysTime during a semester and year

Unique combination:
(Semester, Year, Instructor_ID, DaysTime)

Reason:
Ensures that one instructor cannot teach two different classes at the same time.

c. Section numbers for the same course must be different in the same semester and year
 Unique combination:
(Course_Code, Semester, Year, SecNo)

Reason:
Prevents duplicate section numbers for the same course within one semester.

Other similar constraints:

• A student cannot register for two sections of the same course in one semester.
→ (Student_ID, Course_Code, Semester, Year) must be unique.

• A classroom cannot host two exams at the same DaysTime.

→ (Classroom, Date, DaysTime) must be unique.

3.17. Designing a Complex Attribute

Composite and multivalued attributes can be nested to any number of levels. Suppose we want to design an
attribute for a STUDENT entity type to keep track of previous college education.

Such an attribute will have one entry for each college previously attended, and each such entry will be
composed of:

• college name

• start and end dates

• degree entries (degrees awarded at that college, if any)

• transcript entries (courses completed at that college, if any)

Furthermore:

• Each degree entry contains the degree name and the month and year the degree was awarded.

• Each transcript entry contains a course name, semester, year, and grade.

Design an attribute to hold this information. Use the conventions in Figure 3.5.

Design an attribute for Previous_College_Education to record each college attended, with nested attributes for
degree and transcript details:

Previous_College_Education = {
(College_Name,
Start_Date,
 End_Date,
Degree = {
(Degree_Name, Degree_Month, Degree_Year)
},
Transcript = {
(Course_Name, Semester, Year, Grade)
}
)
}
Explanation:

• Previous_College_Education is multivalued (since a student can attend many colleges).

• Degree and Transcript are nested multivalued composite attributes.

• Format follows Figure 3.5 style of nested structure.

3.18. Alternative Design using Entity and Relationship Types

Show an alternative design for the attribute described in Exercise 3.17 that uses only entity types (including
weak entity types, if needed) and relationship types.

Convert the above attribute into entity types and relationship types for normalization:

Entities:

• STUDENT(Student_ID, Name, DOB, Major)

• COLLEGE(College_ID, Name, Location)

• DEGREE(Degree_Name, Month, Year)

• COURSE(Course_Name, Semester, Year, Grade)

Relationships:

• ATTENDED(STUDENT, COLLEGE, Start_Date, End_Date)

• EARNED(STUDENT, DEGREE, COLLEGE)

• COMPLETED(STUDENT, COURSE, COLLEGE)

Explanation:

• Each student attends one or more colleges.

 • Each degree is awarded by a college.

• Courses and grades are linked through a many-to-many relationship.

• This structure avoids data repetition and supports easy querying.

3.19. Extracting Requirements from an ER Diagram

Consider the ER diagram in Figure 3.21, which shows a simplified schema for an airline reservations system.

Extract from the ER diagram the requirements and constraints that produced this schema. Try to be as precise
as possible in your requirements and constraints specification.

Requirements extracted:

1. Airports: Each airport has a unique Airport_code, Name, City, and State.

2. Airplanes: Each airplane (identified by Airplane_ID) belongs to a specific Airplane_Type, with

Total_no_of_seats.

3. Airplane Type: Described by Type_name, Company, Max_seats.

4. Flights: Each flight (Flight_Number) consists of multiple Flight_Legs.

 5. Flight Leg: Each leg has unique Leg_no, Scheduled_dep_time, Scheduled_arr_time.

6. Leg Instance: Represents a specific occurrence of a leg on a certain Date, with attributes like
No_of_avail_seats.

7. Reservation: Each reservation links a customer (Customer_Name, Cphone) to a seat on a leg instance.

8. Seats: Each seat has a unique Seat_no within an airplane.

9. Airplanes are assigned to leg instances.

10. Each leg departs from and arrives at airports.

Constraints:

• One Airplane Type can be used by many Airplanes.

• Each Flight Leg has one Departure and one Arrival Airport.

• Each Leg Instance is an occurrence of a Flight Leg on one date.

• A Seat can be reserved only once per Leg Instance.

• Each Reservation is uniquely identified by (Customer_Name, Leg_Instance, Seat_no).

3.20. Designing an ER Schema for the Database Environment

In Chapters 1 and 2, we discussed the database environment and database users. We can consider many entity
types to describe such an environment, such as DBMS, stored database, DBA, and catalog/data dictionary.

1. Try to specify all the entity types that can fully describe a database system and its environment.

2. Then specify the relationship types among them.

3. Draw an ER diagram to describe such a general database environment.

Entities:

Entity Key Attributes Description

DBMS DBMS_ID, Name, Version Software managing databases

DATABASE DB_ID, Name, Size, Created_Date Stores data

DBA DBA_ID, Name, Contact Person managing database

USER User_ID, Name, Role End users or developers

CATALOG Catalog_ID, Description Stores metadata

APPLICATION App_ID, Name, Type Front-end software

STORAGE_DEVICE Device_ID, Type, Capacity Physical storage hardware

Relationships:

• DBA manages DATABASE (1:N)

• DATABASE uses DBMS (M:1)

• DATABASE has CATALOG (1:1)

• USER accesses DATABASE (M:N)

• APPLICATION connects_to DATABASE (M:N)

• DATABASE stored_on STORAGE_DEVICE (1:N)

Explanation:
This ER schema describes how the DBMS, databases, users, DBA, and hardware/software interact in a
complete database environment.

Note: সমস্ত ER diagram গুল ো chatgpt এর বোনোলনো, কিন্তু shape ভু আলে। entity থোিলব বক্স এ (eg DBMS ) , relation থোলি বরকি তে (eg
manages ) , attributes থোলি eclipse এ (eg name , version .. )। বোকি সব ঠিি ।

3.21. Designing an ER Schema for U.S. House Votes (Part 1)

Design an ER schema for keeping track of information about votes taken in the U.S. House of Representatives
during the current two-year congressional session.

The database needs to keep track of:

• U.S. STATE:
 o Name (e.g., ‘Texas’, ‘New York’, ‘California’).

o Region (Domain is {‘Northeast’, ‘Midwest’, ‘Southeast’, ‘Southwest’, ‘West’}).

• CONGRESS_PERSON:

o Name.

o District represented.

o Start_date when the congressperson was first elected.

o Political Party (Domain is {‘Republican’, ‘Democrat’, ‘Independent’, ‘Other’}).

• BILL (i.e., proposed law):

o Bill_name.

o Date_of_vote on the bill.

o Passed_or_failed (Domain is {‘Yes’, ‘No’}).

o Sponsor (the congressperson(s) who sponsored—that is, proposed—the bill).

The database also keeps track of how each congressperson voted on each bill (of Vote attribute is {‘Yes’, ‘No’,
‘Abstain’, ‘Absent’}). Draw an ER schema diagram for this application. State clearly any assumptions you make.

3.21 ER Schema for U.S. House Voting System

Entities:

Entity Attributes

STATE State_Name, Region {Northeast, Midwest, Southeast, Southwest, West}

CONGRESS_PERSON CP_ID, Name, District, Start_Date, Party {Republican, Democrat, Independent, Other}

BILL Bill_ID, Bill_Name, Date_of_Vote, Passed_or_Failed {Yes, No}

Relationships:

1. REPRESENTS:

o CONGRESS_PERSON → STATE (M:1)

o Each congressperson represents one district of a state.

2. SPONSORS:

o CONGRESS_PERSON ↔ BILL (M:N)

o A bill may have multiple sponsors.

 3. VOTES_ON:

o CONGRESS_PERSON ↔ BILL (M:N)

o Attribute: Vote {Yes, No, Abstain, Absent}

ER Diagram Summary:

• Entities: STATE, CONGRESS_PERSON, BILL

• Relationships: REPRESENTS, SPONSORS, VOTES_ON

• Attributes on relationships: Vote, Date_of_Vote.

• Primary keys: State_Name, CP_ID, Bill_ID.

Here are the provided questions with proper formatting, without any changes to the content.

Database Design Exercises (Cont.)

3.22. ER Schema Design for a Sports League

A database is being constructed to keep track of the teams and games of a sports league. A team has a
number of players, not all of whom participate in each game. It is desired to keep track of:

• The players participating in each game for each team.

• The positions they played in that game.

• The result of the game.

Design an ER schema diagram for this application, stating any assumptions you make. Choose your favorite
sport (e.g., soccer, baseball, football).

Assumptions (short):

• Sport: Soccer.

• A Team has many Players.

• A Game is between two teams (Home and Away) on a date.

• Not all players participate in a game.

• We must record for each player in a game: the position played and whether they started/substituted,
and the game result for the team.

• Players may belong to only one team at a time (if you prefer, can relax to many teams over seasons).

Exam-ready ER design (short):

• Entities: TEAM, PLAYER, GAME

• Relationship PLAYS_IN_GAME between PLAYER and GAME with attributes Position, Started (Y/N),
Minutes_Played.

• Relationship PARTICIPATES between TEAM and GAME with attribute Result (Win/Loss/Draw) and role
names Home/Away.

3.23. Analyzing an ER Diagram for a BANK Database (Figure 3.22)

Consider the ER diagram shown in Figure 3.22 for part of a BANK database. Each bank can have multiple
branches, and each branch can have multiple accounts and loans.

a. List the strong (nonweak) entity types in the ER diagram. b. Is there a weak entity type? If so, give its name,
partial key, and identifying relationship. c. What constraints do the partial key and the identifying relationship
of the weak entity type specify in this diagram? d. List the names of all relationship types, and specify the
(min, max) constraint on each participation. e. List concisely the user requirements that led to this ER schema
design. f. Suppose that every customer must have at least one account but is restricted to at most two loans at
a time, and that a bank branch cannot have more than 1,000 loans. How does this show up on the (min, max)
constraints?

a. Strong (nonweak) entity types:

• BANK, BANK_BRANCH, ACCOUNT, LOAN, CUSTOMER.

b. Weak entity type?

• Yes: ACCOUNT and LOAN are shown as weak w.r.t. BANK_BRANCH (in the textbook figure they are
depicted with identifying relationships ACCTS and LOANS from BANK_BRANCH).

o Example: For ACCOUNT weak-entity: partial key = Acct_no (unique only within branch),
identifying relationship = ACCTS (connects BANK_BRANCH → ACCOUNT).

Note: Some texts treat ACCOUNT/LOAN as regular entities with composite key (BranchNo, Acct_no); the book
shows them as weak.

c. What constraints do the partial key and identifying relationship specify?

• The partial key (Acct_no for ACCOUNT) by itself does not uniquely identify an account globally — it
identifies it within its owning branch. The identifying relationship ACCTS indicates that each ACCOUNT
must be identified together with the owning BANK_BRANCH (owner). So global key = (Branch_no,
Acct_no). Same for LOAN: (Branch_no, Loan_no).
d. List relationship types & (min,max) participation (from diagram):
(Use figure notation: e.g., BRANCHES between BANK and BANK_BRANCH is 1..N etc.)

• BRANCHES between BANK (1) and BANK_BRANCH (N):

o BANK: (1,1) participation; BANK_BRANCH: (1,N) w.r.t bank.

• ACCTS (identifying) between BANK_BRANCH and ACCOUNT:

o BANK_BRANCH: (1,1) — each account must belong to exactly one branch (owner), ACCOUNT:
(1,N) or (0,N) depending on whether account must exist with branch. In the figure, identifying
relation implies ACCOUNT depends on branch and participates (N).

• LOANS (identifying) between BANK_BRANCH and LOAN: similar to ACCTS.

• A_C between ACCOUNT and CUSTOMER (many-to-many ownership):

o ACCOUNT side: (1,N) or (M,N) depending on notation in fig (looks like M on customer side, N on
account side) → Usually: a CUSTOMER may have many ACCOUNTS (M), an ACCOUNT may have
many CUSTOMERS (N) (joint accounts).

• L_C between LOAN and CUSTOMER (many-to-many): similar.

(If teacher expects exact numeric (min,max) from figure: A_C is M:N, L_C is M:N. Identifying relationships
impose owner side (1) on branch.)

e. User requirements that led to this design (concise):

• Keep track of banks → branches (one bank has many branches).

• Track accounts and loans maintained per branch.

• Support joint accounts and multiple customers per loan → M:N between ACCOUNT/LOAN and
CUSTOMER.

• Need to store account balances, loan amounts, account/loan numbers (unique per branch).

• Store customer personal info (Ssn, Name, Phone, Addr).

f. If every customer must have ≥1 account, ≤2 loans, branch ≤1000 loans → (min,max) show-up:

• CUSTOMER participation in A_C (has account): (1, N) meaning min 1 (must have at least one account).

• CUSTOMER participation in L_C (has loan): (0, 2) or if at least possibly 0 loans: (0,2) (max 2).

• BANK_BRANCH participation in LOANS: (0, 1000) meaning a branch may have at most 1000 loans (min
maybe 0).

3.24. Supplying Constraints and Checking Redundancy (Figure 3.23)

Consider the ER diagram in Figure 3.23.

• Assume that an employee may work in up to two departments or may not be assigned to any
department.

• Assume that each department must have one and may have up to three phone numbers.

1. Supply (min, max) constraints on this diagram. State clearly any additional assumptions you make.

2. Under what conditions would the relationship HAS_PHONE be redundant in this example?

Given: Employee may work in up to two departments or may not be assigned to any. Each department must
have 1..3 phone numbers.

(min,max) constraints:

• WORKS_IN between EMPLOYEE and DEPARTMENT:

o EMPLOYEE side: (0,2) — an employee participates in 0 to 2 departments.

o DEPARTMENT side: (1,N) — a department can have many employees (min 1 employee
assumed).

• HAS_PHONE between EMPLOYEE and PHONE (in fig phone is shared with DEPARTMENT via CONTAINS):

o DEPARTMENT to PHONE: (1,3) — department must have at least 1 phone, at most 3.

o PHONE to DEPARTMENT: (0,1) — a phone belongs to one department (assuming phone

numbers unique per dept).

o EMPLOYEE to PHONE via HAS_PHONE: employee may have (0,N) phones (personal phones);
phone may be assigned to an employee (0,1) if phone is personal.

When is HAS_PHONE redundant?

• If PHONE is inherently an attribute of EMPLOYEE or DEPARTMENT (i.e., phone numbers stored as

multivalued attributes on those entities), the separate relationship HAS_PHONE is redundant.

• Also redundant if phone numbers are only department phones and employees are always associated
with departments — then employee phone can be resolved via department → phone without separate
HAS_PHONE.
3.25. Supplying Constraints and Analyzing Relationship Type (Figure 3.24)

Consider the ER diagram in Figure 3.24.

• Assume that a course may or may not use a textbook, but that a text by definition is a book that is used
in some course.

• A course may not use more than five books.

• Instructors teach from two to four courses.

1. Supply (min, max) constraints on this diagram. State clearly any additional assumptions you make.

2. If we add the relationship ADOPTS, to indicate the textbook(s) that an instructor uses for a course,
should it be a binary relationship between INSTRUCTOR and TEXT, or a ternary relationship among all
three entity types?

3. What (min, max) constraints would you put on the relationship? Why?

Given assumptions & constraints:

• A course may or may not use a textbook.

o COURSE participation in USES → (0,5) (min 0, max 5 textbooks per course).

• A text is always used by some course (text must be used): TEXT participation in USES → (1,N) (min 1).

• Instructors teach from 2 to 4 courses: INSTRUCTOR participation in TEACHES → (2,4); COURSE side:
each course may be taught by (1,N) instructors (depending on co-teaching).

Should ADOPTS be binary or ternary?

• ADOPTS captures the fact which instructor uses which text for which course. This is inherently ternary
if different instructors may adopt different texts for the same course or an instructor uses a different
text for different courses. So model as ternary: (INSTRUCTOR, COURSE, TEXT) with attribute(s) such as
Adopt_Year or Notes.

o If instead all instructors of a course use the same text(s), then ADOPTS can be modeled as
binary (COURSE — USES — TEXT) and a separate binary link INSTRUCTOR—TEACHES—COURSE
suffices. But to allow instructor-specific adoption, use ternary.

(min,max) for ternary ADOPTS (recommended):

 • INSTRUCTOR participation: (2,4) on TEACHES (as given); on ADOPTS: instructor may adopt 0..N texts
across courses → (0,N).

• COURSE participation in ADOPTS: course may have 0..5 adopted texts → (0,5) relative to course in
ADOPTS.

• TEXT participation: text must be used by at least one (if text definition implies used) → (1,N).

Short exam answer:

• Use ternary ADOPTS(INSTRUCTOR, COURSE, TEXT) if instructor-level adoption matters. Put cardinalities:
(INSTRUCTOR:0,N), (COURSE:0,5), (TEXT:1,N).

Database Design Exercises (Cont.)

3.26. Consider an entity type SECTION in a UNIVERSITY database, which describes the section offerings of
courses. The attributes of SECTION are Section_number, Semester, Year, Course_number, Instructor,
Room_no (where section is taught), Building (where section is taught), Weekdays (domain is the possible
combinations of weekdays in which a section can be offered {'MWF', 'M W', 'T T', and so on}), and Hours
(domain is all possible time periods during which sections are offered {'9-9:50 A.M.', '10-10:50 A.M.', ..., '3:30-
4:50 p.m.', '5:30-6:20 p.m.', and so on}). Assume that Section_number is unique for each course within a
particular semester/year combination (that is, if a course is offered multiple times during a particular
semester, its section offerings are numbered 1, 2, 3, and so on). There are several composite keys for section,
and some attributes are components of more than one key. Identify three composite keys, and show how they
can be represented in an ER schema diagram.

Given attributes (SECTION):

Section_number, Semester, Year, Course_number, Instructor, Room_no, Building, Weekdays,
Hours

Three useful composite keys (examples):

1. Key A (natural course-section key):

(Course_number, Semester, Year, Section_number)
— section number is unique per course within a semester/year.
 2. Key B (classroom-time key):
(Building, Room_no, Semester, Year, Hours)
— identifies the specific use of a room/time slot (useful to prevent room conflicts).
3. Key C (instructor-offering key):
(Instructor, Semester, Year, Course_number, Hours)
— identifies a particular offering taught by an instructor at a particular time.

Note: these three keys share attributes (Semester, Year, Course_number, Hours, etc.). Any of these can be
chosen as the primary key depending on design goals. Also enforce uniqueness constraints such as (Building,
Room_no, Semester, Year, Hours) unique to prevent double-booking.

3.27. Cardinality ratios often dictate the detailed design of a database. The cardinality ratio depends on the
real-world meaning of the entity types involved and is defined by the specific application. For the following
binary relationships, suggest cardinality ratios based on the common-sense meaning of the entity types.
Clearly state any assumptions you make.

Entity 1 Cardinality Ratio Entity 2

1. STUDENT SOCIAL_SECURITY_CARD
2. STUDENT TEACHER
3. CLASSROOM WALL
4. COUNTRY CURRENT_PRESIDENT
5. COURSE TEXTBOOK
6. ITEM (that can be found in an order) ORDER
7. STUDENT CLASS
8. CLASS INSTRUCTOR
9. INSTRUCTOR OFFICE
10. EBAY_AUCTION_ITEM EBAY_BID

For each pair I give a short assumption and the recommended cardinality ratio (format: Entity1 (min,max) —
(min,max) Entity2).

1. STUDENT — SOCIAL_SECURITY_CARD
o Assumption: Each student has at most one SS card; each SS card belongs to exactly one student.
o Cardinality: STUDENT (0..1) — (1..1) SOCIAL_SECURITY_CARD
(Or STUDENT (1,1) if all students must have an SS card.)
2. STUDENT — TEACHER
o Assumption: Students attend many teachers’ classes; a teacher teaches many students.
o Cardinality: STUDENT (0..N) — (0..N) TEACHER (i.e., M:N)
3. CLASSROOM — WALL
o Assumption: A classroom has several walls; a wall belongs to exactly one classroom.
o Cardinality: CLASSROOM (1..1) — (1..N) WALL (wall → classroom is many-to-one)
4. COUNTRY — CURRENT_PRESIDENT
o Assumption: A country has at most one current president; a president (as role) is for one
country.
 oCardinality: COUNTRY (0..1) — (1..1) CURRENT_PRESIDENT
(min 0 if some countries have no president; use (1..1) if always present)
5. COURSE — TEXTBOOK
o Assumption: A course may use 0..many textbooks; a textbook may be used by many courses.
o Cardinality: COURSE (0..N) — (0..N) TEXTBOOK (M:N)
6. ITEM (in an order) — ORDER
o Assumption: An order has many items; an item/product can appear in many different orders.
o Cardinality: ITEM (0..N) — (0..N) ORDER (M:N)
7. STUDENT — CLASS (enrollment)
o Assumption: Students enroll in many classes; a class has many students.
o Cardinality: STUDENT (0..N) — (0..N) CLASS (M:N)
8. CLASS — INSTRUCTOR
o Assumption: Typically each class is taught by one instructor, but an instructor teaches many
classes. (If co-teaching allowed, class→instructor could be M:N.)
o Cardinality (common case): CLASS (1..1) — (0..N) INSTRUCTOR
If co-teaching: CLASS (1..N) — (0..N) INSTRUCTOR (M:N)
9. INSTRUCTOR — OFFICE
o Assumption: Usually one instructor has one office (or none), an office may be assigned to at
most one instructor.
o Cardinality: INSTRUCTOR (0..1) — (0..1) OFFICE (or INSTRUCTOR (1..1) — (1..1)
OFFICE if all instructors must have offices)
10. EBAY_AUCTION_ITEM — EBAY_BID
o Assumption: An item can have many bids; a bid is placed for exactly one item.
o Cardinality: EBAY_AUCTION_ITEM (1..1) — (0..N) EBAY_BID (i.e., 1:N)

3.28. Consider the ER schema for the MOVIES database in Figure 3.25. Assume that MOVIES is a populated
database. ACTOR is used as a generic term and includes actresses. Given the constraints shown in the ER
schema, respond to the following statements with True, False, or Maybe. Assign a response of Maybe to
statements that, although not explicitly shown to be True, cannot be proven False based on the schema.
Justify each answer.

a. There are no actors in this database that have been in no movies. b. There are some actors who have acted
in more than ten movies. c. Some actors have done a lead role in multiple movies. d. A movie can have only a
maximum of two lead actors. e. Every director has been an actor in some movie.f. No producer has ever been
an actor.g. A producer cannot be an actor in some other movie. h. There are movies with more than a dozen
actors. i. Some producers have been a director as well. j. Most movies have one director and one producer. k.
Some movies have one director but several producers. l. There are some actors who have done a lead role,
directed a movie, and produced a movie. m. No movie has a director who also acted in that movie.

Interpreting the figure:

• PERFORMS_IN is M:N between ACTOR and MOVIE.

• LEAD_ROLE is a relationship between ACTOR and MOVIE with a cardinality constraint shown on the
ACTOR side as 2 (this indicates an actor can have at most 2 lead roles) and N on the MOVIE side (a
movie can have many lead actors).

• ALSO_A_DIRECTOR links ACTOR and DIRECTOR with 1..1 (shows every DIRECTOR corresponds to an
ACTOR — i.e., directors are also actors).

• ACTOR_PRODUCER connects ACTOR and PRODUCER with 1..1 (indicates producers are also actors in
this schema).

• DIRECTS is 1:N from DIRECTOR → MOVIE (each movie has one director; director may direct many
movies).

• PRODUCES is M:N between PRODUCER and MOVIE (a movie can have many producers and producers
can produce many movies).

Now answers:

a. There are no actors in this database that have been in no movies. → Maybe

• Justification: Schema doesn't show a mandatory minimum participation constraint requiring every
ACTOR to participate in PERFORMS_IN. Without an explicit minimum (e.g., 1), an actor may exist
without any performances. So we cannot prove "no actors with zero movies".

b. There are some actors who have acted in more than ten movies. → Maybe

• Justification: PERFORMS_IN is M:N with no shown upper bound on the number of movies an actor may
perform in; it allows >10, but schema does not force existence of such actors. So it's possible but not
guaranteed.

c. Some actors have done a lead role in multiple movies. → Maybe

• Justification: LEAD_ROLE has a numeric limit on the actor side (the diagram shows 2 near actor), which
suggests an actor can be lead in up to 2 movies. That allows “multiple” (i.e., more than one) but at
most 2. The schema permits it but doesn't guarantee at least one actor has done so. So answer is
Maybe.

d. A movie can have only a maximum of two lead actors. → False

• Justification: The LEAD_ROLE cardinality near the MOVIE side is N (no small upper bound shown), so a
movie can have many lead actors. Nothing in the diagram restricts movies to at most two leads.
e. Every director has been an actor in some movie. → True

• Justification: The ALSO_A_DIRECTOR relationship links DIRECTOR and ACTOR with 1..1 participation on
both sides (diagram indicates each DIRECTOR is associated with exactly one ACTOR), meaning every
director is an actor in the schema — so True.

f. No producer has ever been an actor. → False

• Justification: The ACTOR_PRODUCER relationship connects ACTOR and PRODUCER (the diagram
indicates overlap), so producers may also be actors. The schema allows/indicates producers as actors,
so the statement “no producer has ever been an actor” is false.

g. A producer cannot be an actor in some other movie. → False

• Justification: The schema allows a PRODUCER to be associated with ACTOR (via ACTOR_PRODUCER)
and actors perform in movies (PERFORMS_IN), so nothing prohibits a producer from acting in another
movie. So the statement is false.

h. There are movies with more than a dozen actors. → Maybe

• Justification: PERFORMS_IN has N on the movie side, so a movie can have many actors (including >12).
The schema allows it but does not guarantee at least one such movie exists -> Maybe.

i. Some producers have been a director as well. → Maybe

• Justification: The schema allows overlap: producer ↔ actor, director ↔ actor — if the same person is
linked to both roles (possible), then a producer could also be a director. The schema permits it but
doesn't force it -> Maybe.

j. Most movies have one director and one producer. → Maybe

• Justification: The schema shows DIRECTS as 1 director per movie (director side 1) but PRODUCES is
M:N (multiple producers allowed). The word “most” is a data/population-level claim (not enforced by
schema), so the schema cannot determine “most” -> Maybe.

k. Some movies have one director but several producers. → True

• Justification: DIRECTS indicates one director per movie; PRODUCES allows many producers per movie
(M:N). So the schema directly allows such movies -> True.

l. Some actors have done a lead role, directed a movie, and produced a movie. → Maybe

• Justification: The schema allows an actor to be a director and/or producer (via linking relationships)
and to have lead roles. It’s possible for a person to appear in all three roles, but schema does not force
existence. So Maybe.

m. No movie has a director who also acted in that movie. → False

• Justification: Nothing prevents a director to be an actor in the same movie (directors are actors per
schema). The diagram does not forbid a director appearing as actor in the movie they direct; thus the
statement is false.
Quick exam-writing tips (for these questions)

• For 3.26: Draw the SECTION box, list attributes, then write the 3 composite keys next to it and explain
why each is useful — 3–4 lines will get full marks. Include uniqueness constraints for room/time and
instructor/time.

• For 3.27: Give each pair a short assumption (1 line) and the cardinality in (min,max) form — very high-
yield.

• For 3.28: For each statement give one-word answer (True / False / Maybe) plus a one-line justification
referring to the diagram’s cardinalities or relationship presence.

Database Design Exercises (Cont.)

3.29. Drawing an Instance Diagram

Given the ER schema for the MOVIES database in Figure 3.25, draw an instance diagram using three movies
that have been released recently. Draw instances of each entity type: MOVIES, ACTORS, PRODUCERS,
DIRECTORS involved; make up instances of the relationships as they exist in reality for those movies.

Example movies: Oppenheimer (2023), Barbie (2023), Everything Everywhere All at Once (2022).

Instances

Entity type Instances (examples)

MOVIE Oppenheimer, Barbie, EEAAO

ACTOR Cillian Murphy, Margot Robbie, Michelle Yeoh, Ke Huy Quan

DIRECTOR Christopher Nolan, Greta Gerwig, Daniels

PRODUCER Emma Thomas, Margot Robbie (LuckyChap), Jonathan Wang

Relationships:

• Cillian Murphy PERFORMS_IN Oppenheimer and LEAD_ROLE Oppenheimer.

• Margot Robbie PERFORMS_IN Barbie and LEAD_ROLE Barbie.

• Michelle Yeoh and Ke Huy Quan PERFORM_IN EEAAO; Yeoh has LEAD_ROLE.

• Nolan DIRECTS Oppenheimer; Gerwig DIRECTS Barbie; Daniels DIRECT EEAAO.

• Emma Thomas PRODUCES Oppenheimer; Margot Robbie PRODUCES Barbie; Jonathan Wang PRODUCES
EEAAO.
3.30. Illustrating a UML Diagram for Exercise 3.16

Illustrate the UML diagram for Exercise 3.16. Your UML design should observe the following requirements: a. A
student should have the ability to compute his/her GPA and add or drop majors and minors. b. Each
department should be able to add or delete courses and hire or terminate faculty. c. Each instructor should be
able to assign or change a student’s grade for a course.

Note: Some of these functions may be spread over multiple classes.

Exam usage tips:

• In the exam, draw classes with attributes and listed methods (just the method names are usually
enough).

• Add associations and multiplicities. Mention that some methods could be implemented in
helper/service classes (Registrar, DeptOffice) if asked.

3.31. Building the ER Schema for the UNIVERSITY Database

Consider the UNIVERSITY database described in Exercise 3.16. Build the ER schema for this database using a
data modeling tool such as ERwin or Rational Rose.

ER schema same as Fig 3.20; entities: STUDENT, INSTRUCTOR, DEPARTMENT, COURSE, SECTION, COLLEGE.
Relationships: TEACHES, TAKES, OFFERS, EMPLOYS, HAS, CHAIR, DEAN.

3.32. Designing and Building an ER Diagram for a MAIL_ORDER Database

Consider a MAIL_ORDER database in which employees take orders for parts from customers. The data
requirements are summarized as follows:
 • The mail order company has employees, each identified by a unique employee number, first and last
name, and Zip Code.

• Each customer of the company is identified by a unique customer number, first and last name, and Zip
Code.

• Each part sold by the company is identified by a unique part number, a part name, price, and quantity
in stock.

• Each order placed by a customer is taken by an employee and is given a unique order number. Each
order contains specified quantities of one or more parts. Each order has a date of receipt as well as an
expected ship date. The actual ship date is also recorded.

Design an entity–relationship diagram for the mail order database and build the design using a data modeling
tool such as ERwin or Rational Rose.

Entities & Attributes

• EMPLOYEE (EmpNo PK, FName, LName, Zip)

• CUSTOMER (CustNo PK, FName, LName, Zip)

• PART (PartNo PK, PartName, Price, QtyInStock)

• ORDER (OrderNo PK, DateReceived, ExpectedShip, ActualShip)

• ORDER_LINE (Quantity) → bridge for ORDER–PART (M:N)

Relationships

• CUSTOMER places ORDER (1:M)

• EMPLOYEE takes ORDER (1:M)

• ORDER contains PART via ORDER_LINE (M:N)

3.33. Designing and Building an ER Diagram for a MOVIE Database

Consider a MOVIE database in which data is recorded about the movie industry. The data requirements are
summarized as follows:

• Each movie is identified by title and year of release. Each movie has a length in minutes. Each has a
production company, and each is classified under one or more genres (such as horror, action, drama,
and so forth). Each movie has one or more directors and one or more actors appear in it. Each movie
also has a plot outline. Finally, each movie has zero or more quotable quotes, each of which is spoken
by a particular actor appearing in the movie.

• Actors are identified by name and date of birth and appear in one or more movies. Each actor has a
role in the movie.

• Directors are also identified by name and date of birth and direct one or more movies. It is possible for
a director to act in a movie (including one that he or she may also direct).

• Production companies are identified by name and each has an address. A production company
produces one or more movies.

Design an entity–relationship diagram for the movie database and enter the design using a data modeling tool
such as ERwin or Rational Rose.

Entities

• MOVIE(Title, Year, Length, Plot, ProdCompanyName FK)

• ACTOR(Name, DOB)

• DIRECTOR(Name, DOB)

• PRODUCTION_COMPANY(Name, Address)

• GENRE(GenreName)

• QUOTE(QuoteText, SpokenBy → ACTOR, Movie → MOVIE)

Relationships

• PRODUCTION_COMPANY produces MOVIE (1:M)

• MOVIE has GENRE (M:N)

• MOVIE has DIRECTOR (M:N)

• MOVIE has ACTOR (M:N, attribute Role)

• QUOTE spoken by ACTOR in MOVIE

3.34. Designing and Building an ER Diagram for a CONFERENCE_REVIEW Database

Consider a CONFERENCE_REVIEW database in which researchers submit their research papers for
consideration. Reviews by reviewers are recorded for use in the paper selection process. The database system
caters primarily to reviewers who record answers to evaluation questions for each paper they review and make
recommendations regarding whether to accept or reject the paper. The data requirements are summarized as
follows:

• Authors of papers are uniquely identified by e-mail id. First and last names are also recorded.

• Each paper is assigned a unique identifier by the system and is described by a title, abstract, and the
name of the electronic file containing the paper.

• A paper may have multiple authors, but one of the authors is designated as the contact author.

• Reviewers of papers are uniquely identified by e-mail address. Each reviewer’s first name, last name,
phone number, affiliation, and topics of interest are also recorded.

• Each paper is assigned between two and four reviewers. A reviewer rates each paper assigned to him
or her on a scale of 1 to 10 in four categories: technical merit, readability, originality, and relevance to
the conference. Finally, each reviewer provides an overall recommendation regarding each paper.

• Each review contains two types of written comments: one to be seen by the review committee only
and the other as feedback to the author(s).

Design an entity–relationship diagram for the CONFERENCE_REVIEW database and build the design using a
data modeling tool such as ERwin or Rational Rose.
Entities

• AUTHOR (Email PK, FName, LName)

• PAPER (PaperID PK, Title, Abstract, FileName)

• REVIEWER (Email PK, FName, LName, Phone, Affiliation, Topics)

• REVIEW (ReviewID PK, TechMerit, Readability, Originality, Relevance, OverallRec, CommToCommittee,

CommToAuthor)

Relationships

• AUTHOR writes PAPER (M:N, one author is contact)

• PAPER assigned to REVIEWER (M:N → REVIEW as associative entity)

3.35. Building the ER Diagram for the AIRLINE Database

Consider the ER diagram for the AIRLINE database shown in Figure 3.21. Build this design using a data
modeling tool such as ERwin or Rational Rose. (practical qs)

Answer (summary):
Entities: AIRPORT, AIRPLANE_TYPE, AIRPLANE, FLIGHT, FLIGHT_LEG, LEG_INSTANCE, FARE, SEAT, RESERVATION.
Relationships: DEPARTURE_AIRPORT, ARRIVAL_AIRPORT, INSTANCE_OF, ASSIGNED, RESERVES, CAN_LAND,
LEGS, FARES.
Follow exactly Figure 3.21; can be implemented in any tool.
4.1. What is a subclass? When is a subclass needed in data modeling?

• A subclass is a subgroup (subset) of entities in a superclass that share some additional attributes or
relationships not common to all entities of the superclass.

• It is needed when some entities of a type have special properties or behaviors distinct from others.
Example: In an EMPLOYEE entity, if some are MANAGERS with extra attributes like Bonus, then
MANAGER is a subclass of EMPLOYEE.

4.2. Define the following terms

Term Definition

Superclass of a subclass The higher-level entity type from which a subclass inherits attributes and
relationships.

Superclass/Subclass The connection showing that every entity in a subclass is also a member of its
Relationship superclass.

IS-A Relationship Another name for the superclass/subclass link (e.g., Manager IS-A Employee).

Specialization The process of defining one or more subclasses from an existing entity type.

Generalization The reverse process—combining two or more entity types into a single,
higher-level superclass.

Category (Union type) A subclass with members coming from different superclasses. (e.g., OWNER is
a category of PERSON and COMPANY.)
 Specific (local) attributes Attributes defined only for the subclass.

Specific relationships Relationships that apply only to a subclass but not to its superclass.

4.3. Discuss the mechanism of attribute/relationship inheritance. Why is it useful?

• Inheritance means a subclass automatically receives all attributes and relationships of its superclass.

• Entities in a subclass thus have:

1. Attributes/relationships inherited from superclass, and

2. Additional (local) ones defined only for that subclass.

Usefulness:

o Promotes reusability and reduces redundancy.

o Ensures consistency (shared data need not be redefined).

o Makes hierarchical organization clearer.

4.4. Discuss user-defined and predicate-defined subclasses, and identify differences.

Type Definition Example

User-defined Formed explicitly by the modeler MANAGER subclass defined manually from
subclass based on application semantics. EMPLOYEE.

Predicate-defined Formed automatically by a condition EMPLOYEE with Salary > 1,00,000 forms
subclass (predicate) on attribute values. subclass HIGH_PAID_EMPLOYEE.

Difference:

• User-defined → created manually.

• Predicate-defined → created by applying a logical condition.

4.5. Discuss user-defined and attribute-defined specializations, and identify differences.

Type Definition Example

User-defined Defined explicitly by the designer, based Specializing EMPLOYEE into MANAGER,
specialization on real-world categories. ENGINEER, etc.

Attribute-defined Determined automatically based on the EMPLOYEE specialized by JobType

specialization value of an attribute (discriminator). attribute (values: ‘Manager’, ‘Engineer’,
etc.).
Difference:

• User-defined → designer decides.

• Attribute-defined → controlled by attribute value.

4.6. Discuss the two main types of constraints on specializations and generalizations.

1. Disjointness Constraint

o Determines whether an entity can belong to only one subclass (disjoint) or multiple subclasses
(overlapping).

o Example: CAR and TRUCK disjoint subclasses of VEHICLE; STUDENT and EMPLOYEE may overlap.

2. Completeness Constraint

o Specifies whether all entities in the superclass must belong to a subclass (total) or some may
not (partial).

o Example:

▪ Total → Every employee is either a manager or engineer.

▪ Partial → Some employees may not fit any subclass.

4.7. What is the difference between a specialization hierarchy and a specialization lattice?

Type Description

Hierarchy Each subclass has only one direct superclass. Forms a tree structure.

Lattice A subclass may have multiple superclasses (multiple inheritance). Forms a lattice structure.

Example:

• Hierarchy → PERSON → EMPLOYEE → MANAGER.

• Lattice → TEMP_EMPLOYEE subclass of both EMPLOYEE and CONTRACTOR.

4.8. What is the difference between specialization and generalization? Why not shown separately in
diagrams?

Concept Definition Direction

Specialization Top-down process of dividing a superclass into subclasses. From superclass →

subclasses
 Generalization Bottom-up process of combining multiple entity types into a From subclasses →
superclass. superclass

Why not shown separately:

• In EER diagrams, both appear the same visually (same notation for IS-A link).

• The difference lies only in the direction of design thinking, not in the structure itself.

4.9. How does a category differ from a regular shared subclass? What is a category used for? Give examples.

• A category (union type) is a special kind of subclass whose members come from two or more
superclasses that are not necessarily related.

• A shared subclass inherits from two or more superclasses that have a common ancestor.

Aspect Category Shared Subclass

Source Multiple unrelated superclasses Multiple related superclasses

To represent an entity that may belong to

Purpose To share properties of related superclasses
different types

OWNER is a category of PERSON and COMPANY TEMP_EMPLOYEE is a shared subclass of

Example
(either may own property). EMPLOYEE and CONTRACTOR.

Use: Categories are used when entities can belong to different, unrelated superclasses, e.g., ownership,
membership, or partnership relationships.
4.10. UML terms and their corresponding EER terms

UML Term Equivalent EER Concept Explanation

Object Entity instance A single occurrence of an entity.

Class Entity type Describes structure and behavior of objects.

Association Relationship type Link between two or more entity types.

Aggregation “Part-of” relationship Represented informally in EER by relationship

semantics.

Generalization Specialization / IS-A Defines superclass–subclass hierarchy.

Multiplicity Cardinality ratio Specifies how many instances can participate.

Attributes Attributes Describe properties of entity/relationship.

Discriminator Attribute-defined specialization Used to determine subclass membership.

Link Relationship instance A specific connection between entity instances.

Link attribute Relationship attribute Attribute that belongs to a relationship (not

entity).

Reflexive Recursive relationship Relationship among entities of same type.

association

Qualified Relationship with identifying Uses qualifier attribute to identify related objects.
association attribute

4.11. Differences between EER schema diagrams and UML class diagrams

Feature EER Schema Diagram UML Class Diagram

Basic element Entity type Class

Relationship Diamond shape Line with role names/multiplicity

Attributes Ellipses attached to entities Listed inside class box

Specialization “IS-A” triangle or lines Generalization arrow with open head

Multiplicity (min,max) notation UML uses 0..1, 1..*, etc.

Weak entity Shown with double rectangle Represented using composition/association

Aggregation Shown informally Represented with diamond (aggregation/composition)

Diagram purpose Data structure (static) Data + operations (static + behavior)

 Summary: UML is object-oriented, includes methods and behavior, while EER focuses purely on data
structure and relationships.

4.12. Data abstraction concepts and corresponding EER modeling concepts

Data Abstraction Concept EER Modeling Concept

Classification Entity types (classes)

Aggregation “Part-of” relationships

Generalization Superclass creation from subclasses

Specialization Subclass creation from a superclass

Instantiation Entity instances (objects)

These abstractions help in simplifying complex real-world data into structured models.

4.13. What aggregation feature is missing from the EER model? How can it be enhanced?

• Missing Feature:
The EER model lacks explicit aggregation — the ability to represent a relationship as an entity that can
participate in another relationship.

• Enhancement:
Add higher-order relationships or “relationship-as-entity” modeling (used in UML as
aggregation/composition) to show that one relationship forms part of another.

Example:
PROJECT aggregates EMPLOYEE and TASK relationships; representing this explicitly requires the concept of
aggregation/composition.

4.14. Similarities and differences between conceptual database modeling and knowledge representation
(KR)

Aspect Conceptual Modeling (EER) Knowledge Representation (KR)

Purpose Structuring data for databases Representing knowledge for reasoning

Basis Entities, attributes, relationships Objects, facts, rules, logic

Semantics Focus on structure and constraints Focus on inference and meaning

Implementation Used for database design Used in AI and expert systems

 Common ground Both use abstraction, hierarchy, generalization Both model real-world concepts

In short:
EER focuses on data storage and integrity, KR on reasoning and inference.

4.15. Similarities and differences between an ontology and a database schema

Aspect Ontology Database Schema

Purpose Represents concepts, meanings, and relationships in a Defines data structure for
domain for knowledge sharing. storage and retrieval.

Representation Conceptual, semantic (OWL, RDF). Logical, structural (SQL, ER).

Flexibility Open and extensible. Rigid and schema-bound.

Usage Semantic web, AI reasoning, interoperability. DBMS, application data

management.

Example Medical ontology (disease, symptom, treatment). Hospital database (tables:

patient, doctor).

Similarity: Both define entities, relationships, and attributes.

Difference: Ontology adds semantics and meaning, while a schema focuses on structure and constraints.

Here are the provided Extended Entity-Relationship (EER) design questions formatted clearly:

EER Schema Design Exercises

4.16. EER Schema Design Project

Design an EER schema for a database application that you are interested in. Specify all constraints that should
hold on the database.

Make sure that the schema has at least:

• Five entity types

• Four relationship types

• A weak entity type

• A superclass/subclass relationship

• A category

• An n-ary ($n > 2$) relationship type

Ans: Application: Online Learning Platform

Entities (5+):

1. STUDENT (Stud_ID, Name, Email, Phone)

2. INSTRUCTOR (Instr_ID, Name, Expertise, Email)

3. COURSE (Course_ID, Title, Credit_Hours)

4. ENROLLMENT (weak entity) – depends on STUDENT & COURSE

5. DEPARTMENT (Dept_ID, Name)

6. PAYMENT (Pay_ID, Amount, Date)

Relationships (4+):

1. TEACHES — INSTRUCTOR teaches COURSE (1:N)

2. BELONGS_TO — COURSE belongs to DEPARTMENT (N:1)

3. MAKES_PAYMENT — STUDENT pays PAYMENT (1:N)

4. ENROLLS — STUDENT enrolls in COURSE (via weak entity ENROLLMENT)

Superclass/Subclass:

• USER superclass → STUDENT and INSTRUCTOR subclasses.

Category:

• MEMBER category combining STUDENT and INSTRUCTOR (both can join events/community).

n-ary Relationship (n>2):

• PROJECT_TEAM(STUDENT, INSTRUCTOR, COURSE) — all three participate in projects.

Constraints:

• A COURSE must belong to one DEPARTMENT.

• Each STUDENT must have at least one ENROLLMENT.

• Each PAYMENT must be linked to a STUDENT.

• Each ENROLLMENT must have a valid STUDENT and COURSE.

• TEACHES and PROJECT_TEAM relationships are total participation for COURSE.

4.17. Modifying the BANK ER Schema with EER Concepts (Figure 3.22)

Consider the BANK ER schema in Figure 3.22, and suppose that it is necessary to keep track of different types
of ACCOUNTS and LOANS:

• ACCOUNTS include: SAVINGS_ACCTS, CHECKING_ACCTS, and others.

• LOANS include: CAR_LOANS, HOME_LOANS, and others.

Suppose that it is also desirable to keep track of:

• Each ACCOUNT’s TRANSACTIONS (deposits, withdrawals, checks, ...)

• Each LOAN’s PAYMENTS

Both TRANSACTIONS and PAYMENTS include the amount, date, and time.

Modify the BANK schema, using ER and EER concepts of specialization and generalization. State any
assumptions you make about the additional requirements.

Given: BANK schema (Figure 3.22)

We add specializations and weak entities for transactions & payments.

New Entities:

• SAVINGS_ACCOUNT, CHECKING_ACCOUNT ⟶ subclasses of ACCOUNT.

• CAR_LOAN, HOME_LOAN ⟶ subclasses of LOAN.

 • TRANSACTION (weak entity of ACCOUNT) — (Trans_ID, Amount, Date, Time, Type).

• PAYMENT (weak entity of LOAN) — (Pay_ID, Amount, Date, Time).

Assumptions:

• Each ACCOUNT has multiple TRANSACTIONS.

• Each LOAN has multiple PAYMENTS.

• Branch manages both ACCOUNTs and LOANs.

4.18. EER Schema for Olympic Facilities

The following narrative describes a simplified version of the organization of Olympic facilities planned for the
summer Olympics. Draw an EER diagram that shows the entity types, attributes, relationships, and
specializations for this application. State any assumptions you make.

The Olympic facilities are divided into sports complexes.

• Sports complexes are divided into one-sport and multisport types.

• Multisport complexes have areas of the complex designated for each sport with a location indicator
(e.g., center, NE corner, and so on).
 • A complex has a location, chief organizing individual, total occupied area, and so on.

• Each complex holds a series of events (e.g., the track stadium may hold many different races).

• For each event there is a planned date, duration, number of participants, number of officials, and so
on.

• A roster of all officials will be maintained together with the list of events each official will be involved
in.

• Different equipment is needed for the events (e.g., goal posts, poles, parallel bars) as well as for
maintenance.

• The two types of facilities (one-sport and multisport) will have different types of information. For each
type, the number of facilities needed is kept, together with an approximate budget.

Entities:

1. SPORTS_COMPLEX (Complex_ID, Name, Location, Area, Chief_Organizer)

2. FACILITY (Fac_ID, Budget, Count)

3. EVENT (Event_ID, Name, Date, Duration, No_Participants, No_Officials)

4. OFFICIAL (Off_ID, Name, Role)

5. EQUIPMENT (Equip_ID, Name, Type)

Relationships:

• HOLDS — SPORTS_COMPLEX holds EVENTs (1:N)

• USES — EVENT uses EQUIPMENT (M:N)

• ASSIGNED — OFFICIAL assigned to EVENT (M:N)

• HAS_FACILITY — SPORTS_COMPLEX has FACILITY (1:N)

Specialization:

• SPORTS_COMPLEX specialized into

o ONE_SPORT_COMPLEX

o MULTISPORT_COMPLEX (with attribute Location_Indicator for each sport area)

Category:

• RESOURCE category combining EQUIPMENT and FACILITY (both are resources used in events).
Constraints:

• Each EVENT belongs to one complex.

• Each OFFICIAL must be assigned to at least one EVENT.

• Each COMPLEX must have at least one FACILITY.

• EQUIPMENT may be shared across multiple EVENTS.

4.19. Identify all the important concepts represented in the library database case study described below. In
particular, identify the abstractions of classification (entity types and relationship types), aggregation,
identification, and specialization/generalization. Specify (min, max) cardinality constraints whenever possible.
List details that will affect the eventual design but that have no bearing on the conceptual design. List the
semantic constraints separately. Draw an EER diagram of the library database. Case Study: The Georgia Tech
Library (GTL) has approximately 16,000 members, 100,000 titles, and 250,000 volumes (an average of 2.5
copies per book). About 10% of the volumes are out on loan at any one time. The librarians ensure that the
books that members want to borrow are available when the members want to borrow them. Also, the
librarians must know how many copies of each book are in the library or out on loan at any given time. A
catalog of books is available online that lists books by author, title, and subject area. For each title in the
library, a book description is kept in the catalog; the description ranges from one sentence to several pages.
The reference librarians want to be able to access this description when members request information about a
book. Library staff includes chief librarian, departmental associate librarians, reference librarians, check-out
staff, and library assistants. Books can be checked out for 21 days. Members are allowed to have only five
books out at a time. Members usually return books within three to four weeks. Most members know that they
have one week of grace before a notice is sent to them, so they try to return books before the grace period
ends. About 5% of the members have to be sent reminders to return books. Most overdue books are returned
within a month of the due date. Approximately 5% of the overdue books are either kept or never returned. The
most active members of the library are defined as those who borrow books at least ten times during the year.
The top 1% of membership does 15% of the borrowing, and the top 10% of the membership does 40% of the
borrowing. About 20% of the members are totally inactive in that they are members who never borrow. To
become a member of the library, applicants fill out a form including their SSN, campus and home mailing
addresses, and phone numbers. The librarians issue a numbered, machine-readable card with the member’s
photo on it. This card is good for four years. A month before a card expires, a notice is sent to a member for
renewal. Professors at the institute are considered automatic members. When a new faculty member joins the
institute, his or her information is pulled from the employee records and a library card is mailed to his or her
campus address. Professors are allowed to check out books for three-month intervals and have a two-week
grace period. Renewal notices to professors are sent to their campus address. The library does not lend some
books, such as reference books, rare books, and maps. The librarians must differentiate between books that
can be lent and those that cannot be lent. In addition, the librarians have a list of some books they are
interested in acquiring but cannot obtain, such as rare or out-of-print books and books that were lost or
destroyed but have not been replaced. The librarians must have a system that keeps track of books that cannot
be lent as well as books that they are interested in acquiring. Some books may have the same title; therefore,
the title cannot be used as a means of identification. Every book is identified by its International Standard Book
Number (ISBN), a unique international code assigned to all books. Two books with the same title can have
different ISBNs if they are in different languages or have different bindings (hardcover or softcover). Editions of
the same book have different ISBNs. The proposed database system must be designed to keep track of the
members, the books, the catalog, and the borrowing activity.

Step 1: Key Concepts

Abstraction Examples

Entity Types MEMBER, BOOK, TITLE, COPY, STAFF, LOAN, CATALOG_ENTRY

Weak Entities COPY (depends on TITLE), LOAN (depends on MEMBER & COPY)

Relationships BORROWS, MAINTAINS, DESCRIBED_BY, WORKS_IN

Specialization/Generalization MEMBER specialized into PROFESSOR and REGULAR_MEMBER; STAFF

specialized into LIBRARIAN, ASSISTANT

Category (Union) PERSON category combining MEMBER and STAFF

Aggregation TITLE–COPY relationship aggregated into BOOK_AVAILABILITY

Identification BOOK identified by ISBN, MEMBER by Member_ID, COPY by (ISBN,

Copy_No)

Step 2: Important Constraints

• One TITLE → many COPY (1:N)

• Each COPY → one TITLE (N:1)

 • MEMBER can borrow ≤ 5 books at a time.

• LOAN has Date_Out, Due_Date, and Return_Date.

• PROFESSORS: loan period 3 months, grace 2 weeks.

• REGULAR_MEMBER: loan period 21 days, grace 1 week.

• TITLE identified by ISBN (unique).

• Some books (rare/reference) have Lendable = False.

• Each LOAN must involve one MEMBER and one COPY.

• BOOKS_IN_INTEREST list keeps non-available titles (rare/missing).

Step 3: Semantic Constraints

• 5% of members get overdue notices.

• 5% of books are permanently lost.

• Card validity = 4 years.

• Professors are auto-enrolled members.

Step 4: (min, max) Cardinalities

• MEMBER (1,N) — BORROWS — (0,1) COPY

• TITLE (1,N) — HAS — (1,1) COPY

• STAFF (1,N) — HANDLES — (0,N) LOAN

• TITLE (1,1) — DESCRIBED_BY — (1,1) CATALOG_ENTRY

Q 4.20 — Art Museum Database (p169)

Step 1: Key Entities

Entity Key Attributes Notes

ART_OBJECT Id_no, Title, Description, Year, Artist Superclass

PAINTING Paint_type, Drawn_on, Style Subclass of ART_OBJECT

SCULPTURE/STATUE Material, Height, Weight, Style Subclass of ART_OBJECT

OTHER_OBJECT Type, Style Subclass of ART_OBJECT

PERMANENT_COLLECTION Date_acquired, Status, Cost Subclass of ART_OBJECT

BORROWED_OBJECT From_Collection, Date_borrowed, Subclass of ART_OBJECT

Date_returned

ARTIST Name, DOB, DOD, Country_of_origin, Epoch, Each artist can have many art
Main_style objects
 EXHIBITION Name, Start_date, End_date Related to art objects on
display

COLLECTION Name, Type, Description, Address, Phone, Source of borrowed art

Contact_person

Step 2: Relationships

• ARTIST — CREATES → ART_OBJECT (1:N)

• ART_OBJECT — DISPLAYED_IN → EXHIBITION (M:N)

• BORROWED_OBJECT — BORROWED_FROM → COLLECTION (M:1)

• Each ART_OBJECT has Origin (country/culture) and Epoch attributes.

Step 3: Specializations

1. Type-based:
ART_OBJECT → PAINTING, SCULPTURE, OTHER_OBJECT

2. Ownership-based:
ART_OBJECT → PERMANENT_COLLECTION, BORROWED_OBJECT
(disjoint, total specialization)

Step 4: Constraints

• Each ART_OBJECT must belong to exactly one type subclass and one ownership subclass.

• Each EXHIBITION must include ≥ 1 ART_OBJECT.

• Each ART_OBJECT has ≤ 1 ARTIST.

• Each BORROWED_OBJECT must come from 1 COLLECTION.

 Design Notes (for justification):

• Multiple inheritance used: ART_OBJECT participates in two specializations.

• Disjointness applied to type-based specialization.

• Total specialization for ownership-based (every art object is either borrowed or permanent).

• COLLECTION acts as an external entity.

• Ensures flexibility to add new types later (e.g., “Digital Art”).

4.21. UML Representation of the SMALL_AIRPORT EER Schema (Figure 4.12)

Figure 4.12 shows an example of an EER diagram for a small-private-airport database; the database is used to
keep track of airplanes, their owners, airport employees, and pilots. From the requirements for this
database, the following information was collected: Each AIRPLANE has a registration number [Reg#], is of a
particular plane type [OF_TYPE], and is stored in a particular hangar [STORED_IN]. Each PLANE_TYPE has a
model number [Model], a capacity [Capacity], and a weight [Weight]. Each HANGAR has a number [Number],
a capacity [Capacity], and a location [Location]. The database also keeps track of the OWNERs of each plane
[OWNS] and the EMPLOYEEs who have maintained the plane [MAINTAIN]. Each relationship instance in OWNS
relates an AIRPLANE to an OWNER and includes the purchase date [Pdate]. Each relationship instance in
MAINTAIN relates an EMPLOYEE to a service record [SERVICE]. Each plane undergoes service many times;
hence, it is related by [PLANE_SERVICE] to a number of SERVICE records. A SERVICE record includes as
attributes the date of maintenance [Date], the number of hours spent on the work [Hours], and the type of
work done [Work_code]. We use a weak entity type [SERVICE] to represent airplane service, because the
airplane registration number is used to identify a service record. An OWNER is either a person or a
corporation. Hence, we use a union type (category) [OWNER] that is a subset of the union of corporation
[CORPORATION] and person [PERSON] entity types. Both pilots [PILOT] and employees [EMPLOYEE] are
subclasses of PERSON. Each PILOT has specific attributes license number [Lic_num] and restrictions [Restr];
each EMPLOYEE has specific attributes salary [Salary] and shift worked [Shift]. All PERSON entities in the
database have data kept on their Social Security number [Ssn], name [Name], address [Address], and
telephone number [Phone]. For CORPORATION entities, the data kept includes name [Name], address
[Address], and telephone number [Phone]. The database also keeps track of the types of planes each pilot is
authorized to fly [FLIES] and the types of planes each employee can do maintenance work on [WORKS_ON].
Show how the SMALL_AIRPORT EER schema in Figure 4.12 may be represented in UML notation. (Note: We
have not discussed how to represent categories (union types) in UML, so you do not have to map the
categories in this and the following question.)

Notes on mapping choices:

• PERSON is the superclass; PILOT and EMPLOYEE are subclasses.

• SERVICE is modeled as a class (was weak in EER). The PLANE_SERVICE relationship is an
association class between AIRPLANE and SERVICE (service instances are tied to an airplane).
• OWNS is modeled as an association class between OWNER and AIRPLANE with attribute pDate.
• WORKS_ON and FLIES are many-to-many associations between EMPLOYEE/PILOT and
PLANE_TYPE.
 • Category/union OWNER = PERSON ∪ CORPORATION is not modeled (per instruction).

4.22. UML Representation of the UNIVERSITY EER Schema (Figure 4.9)

Show how the UNIVERSITY EER schema in Figure 4.9 may be represented in UML notation.

1. Classes and Inheritance (Specialization)

• Entities $\rightarrow$ Classes: All EER entities (e.g., PERSON, DEPARTMENT, COURSE)
become UML Classes.
• Inheritance: The "is-a" relationships are shown using UML inheritance (a line with a hollow triangle
pointing to the superclass).
o FACULTY and STUDENT inherit from PERSON.
o GRAD_STUDENT inherits from STUDENT.

2. Relationships and Multiplicity

• Relationships $\rightarrow$ Associations: EER relationships (e.g., ADVISOR, BELONGS) become

UML Associations (lines between classes).
• Cardinality $\rightarrow$ Multiplicity: The EER $(min, max)$ constraints are converted into
standard UML multiplicity (e.g., 1:N becomes 1..*).
o Example: The ADVISOR association has 1 on GRAD_STUDENT and 0..* on FACULTY.

3. Complex Structures

• Association Class: The REGISTERED relationship between STUDENT and CURRENT_SECTION

has attributes (Grade), so it is mapped as an Association Class (e.g., REGISTRATION) to hold that
attribute.
• Multivalued Attributes: Attributes like Degrees are turned into a separate class (DEGREE) connected
by a 1:N association to the original class (GRAD_STUDENT).
• Weak Entity: SECTION is a class linked to its identifying entity (COURSE) via an association.
MODULE 2

Book: FUNDAMENTALS OF Database Systems: by RamezElmasri, Shamkant B. Navathe, 7th Edition

5.1. Definitions

Term Definition

Domain The set of all possible valid values an attribute can take (e.g., domain of “Age” is
integers 0–120).

Attribute A named column of a relation that represents a data field (e.g., Name, RollNo).

n-tuple A row or record in a relation, representing a single data item (n attributes).

Relation Schema The structure or definition of a relation, written as R(A1, A2, …, An), showing its
name and attributes.

Relation State The actual data or set of tuples present in a relation at a specific time.

Degree of a Relation The number of attributes (columns) in a relation.

Relational Database The collection of all relation schemas in a database.

Schema

Relational Database The current data (set of relation states) in the database at a specific moment.
State
5.2. Why are tuples in a relation not ordered?

• In the relational model, a relation is a mathematical set of tuples.

• Sets are unordered collections, meaning the order of tuples has no meaning.

• Tuple order does not affect query results or data interpretation — each tuple is uniquely identified by
its primary key, not its position.

5.3. Why are duplicate tuples not allowed in a relation?

• Each tuple in a relation must represent a unique real-world entity or fact.

• Allowing duplicates would violate the definition of a set in mathematics.

• Duplicate tuples make retrieval, updates, and integrity checking ambiguous and inefficient.

• The primary key constraint ensures all tuples are unique.

5.4. Difference between a Key and a Superkey

Aspect Superkey Key (Candidate Key)

A set of one or more attributes that can A minimal superkey — no proper subset can
Definition
uniquely identify a tuple. uniquely identify a tuple.

Redundancy May contain unnecessary attributes. Contains only essential attributes.

Example {RollNo, Name} if RollNo alone is unique. {RollNo} is the key.

5.5. Why designate a Primary Key?

• A primary key is chosen from candidate keys to:

1. Uniquely identify tuples in the relation.

2. Serve as a reference for other tables (foreign keys).

3. Enforce entity integrity — no two tuples can have the same key, and it cannot be NULL.

• It provides a standard reference for indexing, linking, and enforcing constraints.

5.6. Characteristics of Relations vs. Ordinary Tables

1. No duplicate tuples — each tuple is unique.

2. No ordering — tuples and attributes are unordered.

 3. Atomic values only — no repeating groups or composite fields.

4. Consistent data types — each attribute has a defined domain.

5. Unique column names — all attributes in a relation have distinct names.

6. Integrity constraints — entity and referential integrity must hold.

5.7. Reasons for NULL Values

NULL represents missing or inapplicable information. Common reasons:

1. Unknown value — the data exists but is currently unavailable.

2. Not applicable — attribute doesn’t apply (e.g., “SpouseName” for unmarried person).

3. Not yet assigned — value will be provided later (e.g., marks not yet entered).

4. Missing by design — optional data not required in every tuple.

5.8. Entity Integrity & Referential Integrity

Type Definition Importance

Ensures the primary key of a relation is unique and

Entity Integrity Prevents duplicate or unidentified tuples.
never NULL.

Ensures a foreign key value in one relation

Referential Maintains consistency between related
matches a primary key value in another (or is
Integrity tables (no “dangling references”).
NULL).

Example:
If Student(DeptNo) references Department(DeptNo), a student cannot belong to a non-existing department.

5.9. Define Foreign Key

• A foreign key is an attribute (or set of attributes) in one relation that refers to the primary key of
another relation.

• It is used to establish relationships between tables and enforce referential integrity.

Example:
Student(DeptNo) → foreign key referencing Department(DeptNo).

5.10. What is a Transaction? How it differs from an Update operation?

 Aspect Transaction Update Operation

Definition A logical unit of work that may contain one or more A single modification of data (e.g.,
operations (insert, update, delete) executed together. changing one field).

Property Must follow ACID (Atomicity, Consistency, Isolation, Doesn’t guarantee ACID properties.
Durability).

Example Transferring money between two accounts involves Changing a single account balance
multiple updates but forms one transaction. is one update operation.

5.11. Integrity Constraint Violations in Update Operations

Question:

Suppose that each of the following update operations is applied directly to the database state shown in Figure
5.6.
Discuss all integrity constraints violated by each operation and ways of enforcing them.
(a)

Insert:
<‘Robert’, ‘F’, ‘Scott’, ‘943775543’, ‘1972-06-21’, ‘2365 Newcastle Rd, Bellaire, TX’, M, 58000, ‘888665555’, 1>
into EMPLOYEE

Check:

• Super_ssn = 888665555 → Exists (James Borg).

• Dno = 1 → Exists (Headquarters).

Result:
No violation.
All referential and entity constraints satisfied.
Action: Insert allowed.

(b)

Insert:
<‘ProductA’, 4, ‘Bellaire’, 2> into PROJECT

Check:

• Pnumber = 4 → Already exists (Computerization).

• Dnum = 2 → Does not exist in DEPARTMENT.

Violations:

• Primary Key constraint (duplicate Pnumber).

• Referential Integrity (invalid Dnum).

Action: Reject insertion. Must give new project number & valid department.

(c)

Insert:
<‘Production’, 4, ‘943775543’, ‘2007-10-01’> into DEPARTMENT

Check:

• Dnumber = 4 → Already exists (Administration).

• Mgr_ssn = 943775543 → Does not exist in EMPLOYEE.

Violations:

• Primary Key constraint (duplicate department).

 • Referential Integrity (invalid manager).

Action: Reject insertion.

(d)

Insert:
<‘677678989’, NULL, ‘40.0’> into WORKS_ON

Check:

• Essn = 677678989 → Not in EMPLOYEE.

• Pno = NULL → Not allowed (foreign key).

Violations:

• Referential Integrity (invalid Essn).

• Entity Integrity (NULL in key field).

Action: Reject insertion.

(e)

Insert:
<‘453453453’, ‘John’, ‘M’, ‘1990-12-12’, ‘Spouse’> into DEPENDENT

Check:

• Essn = 453453453 → Exists (Joyce English).

• Dependent name “John” not repeated.

Result:
No violation.
Action: Insert allowed.

(f)

Delete:
WORKS_ON tuples with Essn = ‘333445555’

Check:

• Employee (Franklin Wong) still in EMPLOYEE.

• Deleting from WORKS_ON doesn’t affect others.

 Result:
No violation.
Action: Safe delete.

(g)

Delete:
EMPLOYEE tuple with Ssn = ‘987654321’ (Jennifer Wallace)

Check:

• Jennifer is Mgr_ssn for Department 4 (Administration).

• Also manages Projects 10, 20, 30.

Violations:

• Referential Integrity (referenced as manager in DEPARTMENT and PROJECT).

Action: Reject deletion or use ON DELETE SET NULL / CASCADE.

(h)

Delete:
PROJECT tuple where Pname = ‘ProductX’ (Pnumber = 1)

Check:

• WORKS_ON has tuples with Pno = 1.

Violations:

• Referential Integrity (dependent records in WORKS_ON).

Action:
Either delete dependent WORKS_ON tuples first, or use CASCADE DELETE.

(i)

Modify:
Mgr_ssn and Mgr_start_date in DEPARTMENT where Dnumber = 5
→ Mgr_ssn = 123456789, Mgr_start_date = 2007-10-01

Check:

• 123456789 exists (John Smith).

 Result:
No violation.
Action: Update allowed.

(j)

Modify:
Super_ssn of EMPLOYEE where Ssn = 999887777 → 943775543

Check:

• 943775543 does not exist in EMPLOYEE.

Violation:

• Referential Integrity (invalid supervisor ID).

Action: Reject modification or insert supervisor first.

(k)

Modify:
Hours in WORKS_ON where Essn = 999887777 and Pno = 10 → 5.0

Check:

• Tuple exists (Ramesh works on Pno 10).

• Hours = numeric, valid domain.

Result:
No violation.
Action: Update allowed.

Summary Table

Operation Violations Integrity Type Action

(a) None – Allowed

(b) Duplicate key, invalid dept Key + Referential Reject

(c) Duplicate key, invalid mgr Key + Referential Reject

(d) Invalid employee, NULL key Referential + Entity Reject

Operation Violations Integrity Type Action

(e) None – Allowed

(f) None – Allowed

(g) Manager deletion Referential Reject / Cascade

(h) Project referenced in WORKS_ON Referential Reject / Cascade

(i) None – Allowed

(j) Invalid supervisor Referential Reject

(k) None – Allowed

5.12. AIRLINE Database Update Example

Question:

Consider the AIRLINE relational schema (Figure 5.8).

Describe the update for entering a reservation and analyze constraints.
a. Operations for Reservation Update:

1. Check if Flight_number, Leg_number, and Date exist in LEG_INSTANCE.

2. Check available seats (Number_of_available_seats > 0).

3. Insert tuple into SEAT_RESERVATION:

<Flight_number, Leg_number, Date, Seat_number, Customer_name, Customer_phone>.

4. Decrease Number_of_available_seats in LEG_INSTANCE by 1.

b. Constraints to Check:

1. Key Constraints — primary keys (e.g., Seat_number unique for same flight leg & date).

2. Entity Integrity — no attribute forming a key can be NULL.

3. Referential Integrity —

o Flight_number & Leg_number in SEAT_RESERVATION → must exist in LEG_INSTANCE.

o Airplane_id in LEG_INSTANCE → must exist in AIRPLANE.

o Airport codes → must exist in AIRPORT.

4. Domain Constraints — correct data types (e.g., valid date, phone format).

5. Business Constraint — seat availability > 0.

c. Classify Constraints

Constraint Type

Unique Flight_number, Leg_number, Date Key constraint

Non-null keys Entity Integrity

Links (foreign keys) to other tables Referential Integrity

Seat availability rule User-defined / Business Rule

d. Referential Integrity Constraints on Schema:

1. FLIGHT.Leg_number → FLIGHT_LEG(Flight_number, Leg_number)

2. FLIGHT_LEG.Departure_airport_code → AIRPORT(Airport_code)

3. FLIGHT_LEG.Arrival_airport_code → AIRPORT(Airport_code)
 4. LEG_INSTANCE(Flight_number, Leg_number) → FLIGHT_LEG(Flight_number, Leg_number)

5. LEG_INSTANCE.Airplane_id → AIRPLANE(Airplane_id)

6. FARE.Flight_number → FLIGHT(Flight_number)

7. AIRPLANE.Airplane_type → AIRPLANE_TYPE(Airplane_type_name)

8. CAN_LAND.Airplane_type_name → AIRPLANE_TYPE(Airplane_type_name)

9. CAN_LAND.Airport_code → AIRPORT(Airport_code)

10. SEAT_RESERVATION(Flight_number, Leg_number, Date) → LEG_INSTANCE(Flight_number, Leg_number,

Date)

5.13. Candidate Keys for CLASS Relation

Question:

Relation:
CLASS(Course#, Univ_Section#, Instructor_name, Semester, Building_code, Room#, Time_period, Weekdays,
Credit_hours)

Identify candidate keys and explain when each is valid.

Possible Candidate Keys & Conditions

Candidate Key When Valid

Univ_Section# If every section number is unique across the university (typical

assumption).

(Course#, Semester, Univ_Section#) If section numbers are unique only within a course-semester
combination.

(Building_code, Room#, Time_period, If no two classes share the same room, time, and weekday
Weekdays) schedule.

(Instructor_name, Semester, If an instructor can teach only one class in a given time period
Time_period) per semester.

Summary:
Usually, Univ_Section# is the primary key (globally unique), while the others are alternate candidate keys
valid under certain scheduling rules.

Here are the provided database schema analysis and design questions formatted clearly:
5.14. Order-Processing Database

Consider the following six relations for an order-processing database application in a company:

• CUSTOMER(, Cname, City)

• ORDER(, Odate, , )

• ORDER_ITEM(, , Qty)

• ITEM(, Unit_price)

• SHIPMENT(, , )

• WAREHOUSE(, City)

Here, refers to total dollar amount of an order; Odate is the date the order was placed; and is the date an
order (or part of an order) is shipped from the warehouse. Assume that an order can be shipped from several
warehouses.

1. Specify the foreign keys for this schema, stating any assumptions you make.

2. What other constraints can you think of for this database?

5.14. (Order-processing schema)

Schema:
CUSTOMER(Cust#, Cname, City)
ORDER(Order#, Odate, Cust#, Ord_amt)
ORDER_ITEM(Order#, Item#, Qty)
ITEM(Item#, Unit_price)
SHIPMENT(Order#, Warehouse#, Ship_date)
WAREHOUSE(Warehouse#, City)

(a) Foreign keys (with assumptions)

• ORDER.Cust# → CUSTOMER.Cust#
Assume each order must belong to an existing customer.

• ORDER_ITEM.Order# → ORDER.Order#
Assume order items always reference an existing order.

• ORDER_ITEM.Item# → ITEM.Item#
Assume each ordered item exists in the item master.

• SHIPMENT.Order# → ORDER.Order#
Assume shipment always refers to a recorded order.
 • SHIPMENT.Warehouse# → WAREHOUSE.Warehouse#
Assume shipments are from known warehouses.

(Primary keys: CUSTOMER(Cust#), ORDER(Order#), ITEM(Item#), WAREHOUSE(Warehouse#),

ORDER_ITEM(Order#,Item#), SHIPMENT(Order#,Warehouse#,Ship_date) )

(b) Other useful constraints / business rules

• Ord_amt = SUM(Order_Item.Qty * Item.Unit_price) (business integrity — derived total).

• Qty > 0, Unit_price >= 0, Ord_amt >= 0 (domain constraints).

• Ship_date >= Odate (temporal constraint).

• ORDER_ITEM PK (Order#, Item#) — no duplicate same item row.

• If partial shipments allowed: track shipped quantities; ensure total shipped ≤ ordered qty.

• If an order may be shipped from multiple warehouses: SHIPMENT may have many rows per Order#.

• Referential actions: define ON DELETE/UPDATE behavior (RESTRICT, CASCADE, SET NULL).

5.15. Business Trip Database

Consider the following relations for a database that keeps track of business trips of salespersons in a sales
office:

• SALESPERSON(, Name, , )

• TRIP(, , , , , )

• EXPENSE(, , )

A trip can be charged to one or more accounts. Specify the foreign keys for this schema, stating any
assumptions you make.

Schema:
SALESPERSON(Ssn, Name, Start_year, Dept_no)
TRIP(Ssn, From_city, To_city, Departure_date, Return_date, Trip_id)
EXPENSE(Trip_id, Account#, Amount)

Foreign keys (with assumptions)

• TRIP.Ssn → SALESPERSON.Ssn
Assume each trip belongs to an existing salesperson.

• EXPENSE.Trip_id → TRIP.Trip_id
Assume Trip_id uniquely identifies a trip (Trip_id is primary key).

• EXPENSE.Account# → ACCOUNT.Account# (optional)

If accounts table exists, expenses reference valid account numbers.
Other constraints

• Return_date >= Departure_date (temporal constraint).

• Amount >= 0 (domain).

• Trip_id should be unique (or composite key: (Ssn, Trip_id) if Trip_id not global).

• A trip assigned only to existing accounts if account table present.

5.16. Student Enrollment Database

Consider the following relations for a database that keeps track of student enrollment in courses and the books
adopted for each course:

• STUDENT(, Name, Major, Bdate)

• COURSE(, Cname, Dept)

• ENROLL(, , Quarter, Grade)

• BOOK_ADOPTION(, Quarter, )

• TEXT(, , Publisher, Author)

Specify the foreign keys for this schema, stating any assumptions you make.

Schema:
STUDENT(Ssn, Name, Major, Bdate)
COURSE(Course#, Cname, Dept)
ENROLL(Ssn, Course#, Quarter, Grade)
BOOK_ADOPTION(Course#, Quarter, Book_isbn)
TEXT(Book_isbn, Book_title, Publisher, Author)

Foreign keys (with assumptions)

• ENROLL.Ssn → STUDENT.Ssn

• ENROLL.Course# → COURSE.Course#

• BOOK_ADOPTION.Course# → COURSE.Course#

• BOOK_ADOPTION.Book_isbn → TEXT.Book_isbn

• If TEXT used elsewhere, ensure TEXT.Book_isbn is PK.

Assumptions: (Ssn, Course#, Quarter) is PK of ENROLL; (Course#, Quarter, Book_isbn) PK of BOOK_ADOPTION.

Other constraints

• Grade domain (A–F or NULL).

• A student cannot enroll in same Course# & Quarter twice.

 • A course may adopt multiple books per quarter.

• Referential actions for deleting course/text (RESTRICT or cascade as policy).

5.17. Automobile Sales Database

Consider the following relations for a database that keeps track of automobile sales in a car dealership ( refers
to some optional equipment installed on an automobile):

• CAR(, Model, Manufacturer, Price)

• OPTION(, , Price)

• SALE(, , Date, )

• SALESPERSON(, Name, Phone)

1. First, specify the foreign keys for this schema, stating any assumptions you make.

2. Next, populate the relations with a few sample tuples, and then give an example of an insertion in the
SALE and SALESPERSON relations that violates the referential integrity constraints and of another
insertion that does not.

Schema:
CAR(Serial_no, Model, Manufacturer, Price)
OPTION(Serial_no, Option_name, Price)
SALE(Salesperson_id, Serial_no, Date, Sale_price)
SALESPERSON(Salesperson_id, Name, Phone)

Foreign keys (with assumptions)

• OPTION.Serial_no → CAR.Serial_no (each option row belongs to an existing car).

• SALE.Serial_no → CAR.Serial_no (sale must reference a sold car).

• SALE.Salesperson_id → SALESPERSON.Salesperson_id (sale must reference a salesperson).

Assumptions:

• CAR.Serial_no is PK; SALESPERSON.Salesperson_id is PK.

• OPTION PK = (Serial_no, Option_name).

• SALE PK could be (Salesperson_id, Serial_no, Date) or a separate Sale_id.

Sample tuples

CAR

• (C001, Corolla, Toyota, 20000)

• (C002, Civic, Honda, 22000)

OPTION

• (C001, Sunroof, 800)

• (C001, SportPackage, 1200)

SALESPERSON

• (S01, Alice, 555-1111)

• (S02, Bob, 555-2222)

SALE

• (S01, C001, 2025-03-10, 19500) — Alice sold C001.

Examples of inserts that violate / do not violate referential integrity

• Violating SALE insertion (FK violation):

INSERT INTO SALE VALUES ('S03', 'C002', '2025-03-11', 21500);
Reason: S03 not present in SALESPERSON → violates SALE.Salesperson_id FK.

• Non-violating SALE insertion:

INSERT INTO SALE VALUES ('S02', 'C002', '2025-03-11', 21500);
Reason: S02 exists and C002 exists → OK.

• Insertion into SALESPERSON cannot violate referential integrity (SALESPERSON has no FKs). It can
violate key uniqueness if Salesperson_id already exists:

o Violating SALESPERSON (key violation): INSERT INTO SALESPERSON VALUES ('S01','Charlie','555-

3333') when S01 exists → violates PK (not a referential integrity violation).

o Non-violating SALESPERSON: INSERT INTO SALESPERSON VALUES ('S03','Charlie','555-3333') →

OK.

5.18. Attribute Storage Decisions (SSN)

Database design often involves decisions about the storage of attributes. For example, a Social Security
number () can be stored as one attribute or split into three attributes (one for each of the three hyphen-
delineated groups of numbers in a Social Security number—XXX-XX-XXXX). However, Social Security numbers
are usually represented as just one attribute. The decision is based on how the database will be used. This
exercise asks you to think about specific situations where dividing the SSN is useful.

Situations where splitting helps:

1. Query by region/area code (AAA): If you need frequent queries grouped by the first 3 digits (area or
issuing region), splitting avoids expensive substring operations.

2. Partial indexing / range searches: If you index parts separately (e.g., index on first 3 digits), searches by
area are faster.
 3. Validation or formatting: If each part has different validation rules (e.g., group GG must be within
certain ranges), storing separately simplifies checks.

4. Masking/privacy: If you routinely display only last 4 digits, having parts stored separately makes
masking simpler.

5. Internationalization / storage constraints: If some systems store components differently or you need to
store non-digit separators, separate fields help integration.

6. Reporting / aggregate stats: If reports often group by the first/second group, separate attributes make
aggregation simpler.

When keep as single attribute:

• Simpler design, fewer columns, easier to enforce uniqueness, and typical use (lookup by full SSN) is
simple. Prefer single attribute unless you have real need above.
5.19. Consider a STUDENT relation in a UNIVERSITY database

Attributes: (Name, Ssn, Local_phone, Address, Cell_phone, Age, Gpa)

Example tuple:

Name Ssn Local_phone Address Cell_phone Age Gpa

George Shaw 123-45-6789 555-1234 123 Main St, Anytown, CA 94539 555-4321 19 3.75

(a) Identify the critical missing information from Local_phone and Cell_phone.

Answer:
The area code and country code are missing.
Without them, you cannot call someone outside the local area or from another state/province.

(b) Would you store this additional information in the same attribute or as new attributes?

Answer:
Better to add new attributes — e.g.,
Local_area_code, Cell_area_code, Country_code.
This makes it easier to validate, search, and handle international numbers.
Storing all in one field (e.g., “+1-555-1234”) can make querying difficult.

(c) Consider the Name attribute.

What are the advantages and disadvantages of splitting into (First_name, Middle_name, Last_name)?

Advantages:

• Easier searching, sorting, and filtering (e.g., by last name).

• Easier to store consistent formats (no confusion like “Shaw, George”).

Disadvantages:

• Complicates data entry (not everyone has a middle name).

• Requires extra columns and may introduce NULLs.

(d) General guideline for deciding between single and multiple attributes

Answer:
Split an attribute into multiple fields only if:
 • The parts are used independently in queries or reports.
Keep as a single field if it’s always used as a unit (e.g., full name for display).

(e) Student can have between 0 and 5 phones — suggest two design options.

Design 1:
Create a separate table:
STUDENT_PHONE(Ssn, Phone_type, Phone_number)

• One-to-many relationship between STUDENT and STUDENT_PHONE.

• Scalable and normalized.

Design 2:
Add multiple attributes:
Phone1, Phone2, Phone3, Phone4, Phone5

• Simpler but not normalized.

• Not recommended for large systems.

5.20. Use of SSN and surrogate keys

(a) Why use generated (surrogate) keys instead of natural keys?

Answer:
Because privacy laws prevent SSN usage, a Student_id (surrogate key) is used.
It’s unique, simple, and system-generated.

Possible natural key choices:

• (Name + Birthdate + Address) — but may change.

• (Email address) — often unique but can also change.

Hence, surrogate Student_id is more reliable.

(b) If you use last name in the key, what are the problems and solutions?

Problem:

• Last names can change (e.g., after marriage).

• This breaks referential integrity.

Solutions:
 • Use a surrogate key (Student_id) as the primary key.

• Keep name attributes separately for identification only.

• If name changes, just update the name field, not the key.

(c) Advantages and disadvantages of generated (surrogate) keys

Advantages:

• Guaranteed uniqueness and simplicity.

• Not affected by changes in real-world data (like name or SSN).

• Short and efficient for indexing and joins.

• Preserves privacy (no sensitive data used as key).

Disadvantages:

• Artificial; carries no real-world meaning.

• May make debugging harder since IDs don’t describe entities.

• Need extra constraints to ensure real-world uniqueness (e.g., no duplicate students with different IDs).

6.1. How do the relations (tables) in SQL differ from formal relations in Chapter 3? Why does SQL allow
duplicates?

Differences:

1. Duplicates:

o In formal relational model → all tuples are unique.

o In SQL → duplicates are allowed (by default) unless DISTINCT is used.

 2. Ordering:

o In formal model → tuples are unordered.

o In SQL → order can be defined using ORDER BY.

3. NULL values:

o Formal model → does not allow NULLs (every value must be atomic).

o SQL → allows NULL to represent unknown or missing values.

4. Terminology differences:

o Relation → Table

o Tuple → Row / Record

o Attribute → Column / Field

o Relation schema → Table definition

Why SQL allows duplicates:

Because SQL is based on multiset (bag) semantics, which makes operations more efficient and practical for
business queries, where duplicates can occur naturally (e.g., multiple employees with same salary).

6.2. List the data types allowed for SQL attributes.

Common SQL Data Types:

Numeric types

• INTEGER or INT – whole numbers

• SMALLINT – smaller range integers

• FLOAT / REAL / DOUBLE PRECISION – floating point numbers

• DECIMAL(p, d) or NUMERIC(p, d) – exact decimal values

Character types

• CHAR(n) or CHARACTER(n) – fixed length string

• VARCHAR(n) or CHARACTER VARYING(n) – variable length string

Date and time types

• DATE – stores date (YYYY-MM-DD)

• TIME – stores time (HH:MM:SS)

• TIMESTAMP – stores both date and time

 • INTERVAL – stores time interval

Other types (SQL extensions)

• BOOLEAN – true/false values

• BLOB – binary large object (e.g., image, file)

• CLOB – character large object (large text)

6.3. How does SQL implement entity integrity and referential integrity? What are referential triggered
actions?

Entity Integrity:

• Ensures primary key columns are unique and not NULL.

• Implemented by using:

• PRIMARY KEY(column_name)

→ e.g. Ssn CHAR(9) PRIMARY KEY

Referential Integrity:

• Ensures foreign key values exist in the referenced table.

• Implemented by using:

• FOREIGN KEY (Dept_no) REFERENCES Department(Dnumber)

Referential Triggered Actions:

• Specify what happens when a referenced record is updated or deleted.

Options:

1. ON DELETE CASCADE → delete child rows automatically

2. ON DELETE SET NULL → set foreign key to NULL

3. ON DELETE SET DEFAULT → set to default value

4. ON DELETE NO ACTION → reject deletion (default)

5. ON UPDATE CASCADE → update child rows when parent key changes

These triggered actions preserve consistency automatically.

6.4. Describe the four clauses in a simple SQL retrieval query. Which are required and which are optional?

Syntax:
SELECT [DISTINCT] column_list

FROM table_list

[WHERE condition]

[ORDER BY column_list];

1. SELECT clause (Required)

• Specifies the columns or expressions to display.

• Can use functions like AVG, COUNT, etc.

→ Example: SELECT Name, Salary

2. FROM clause (Required)

• Lists tables to retrieve data from.

→ Example: FROM Employee, Department

3. WHERE clause (Optional)

• Filters rows using conditions.

→ Example: WHERE Salary > 30000

4. ORDER BY clause (Optional)

• Sorts the result in ascending or descending order.

→ Example: ORDER BY Salary DESC

Additional optional clauses (in advanced queries):

• GROUP BY – group rows for aggregate functions.

• HAVING – apply condition to grouped data.

Required: SELECT, FROM

Optional: WHERE, ORDER BY (and others like GROUP BY, HAVING)

Here is the text formatted clearly, focusing on database constraints and SQL DDL (Data Definition Language)
statements:

SQL and Database Constraints Exercises

6.5. Constraints and DDL for the Basic Database

Consider the database shown in Figure 1.2, whose schema is shown in Figure 2.1.

1. What are the referential integrity constraints that should hold on the schema?

2. Write appropriate SQL DDL statements to define the database.

 Referential constraints that should hold
(based on Figure 1.2 entities: STUDENT,
COURSE, SECTION, GRADE_REPORT,
PREREQUISITE):

• SECTION.Course_number →
COURSE.Course_number

• GRADE_REPORT.Student_number →
STUDENT.Student_number

• GRADE_REPORT.Section_identifier →
SECTION.Section_identifier

• PREREQUISITE.Course_number →
COURSE.Course_number

• PREREQUISITE.Prerequisite_number →
COURSE.Course_number

DDL (example) — adjust datatypes as needed:

CREATE TABLE STUDENT (

Student_number INT PRIMARY KEY,

Name VARCHAR(100),

Class INT,

Major VARCHAR(50)

);

CREATE TABLE COURSE (

Course_number VARCHAR(20) PRIMARY KEY,

Course_name VARCHAR(200),

Credit_hours INT,

Department VARCHAR(50)

);
CREATE TABLE SECTION (

Section_identifier INT PRIMARY KEY,

Course_number VARCHAR(20) NOT NULL,

Semester VARCHAR(20),

Year INT,

Instructor VARCHAR(100),

FOREIGN KEY (Course_number) REFERENCES COURSE(Course_number)

ON UPDATE CASCADE ON DELETE RESTRICT

);

CREATE TABLE GRADE_REPORT (

Student_number INT NOT NULL,

Section_identifier INT NOT NULL,

Grade CHAR(2),

PRIMARY KEY (Student_number, Section_identifier),

FOREIGN KEY (Student_number) REFERENCES STUDENT(Student_number)

ON UPDATE CASCADE ON DELETE CASCADE,

FOREIGN KEY (Section_identifier) REFERENCES SECTION(Section_identifier)

ON UPDATE CASCADE ON DELETE CASCADE

);

CREATE TABLE PREREQUISITE (

Course_number VARCHAR(20) NOT NULL,

Prerequisite_number VARCHAR(20) NOT NULL,

PRIMARY KEY (Course_number, Prerequisite_number),

FOREIGN KEY (Course_number) REFERENCES COURSE(Course_number)

ON UPDATE CASCADE ON DELETE CASCADE,

FOREIGN KEY (Prerequisite_number) REFERENCES COURSE(Course_number)

 ON UPDATE CASCADE ON DELETE RESTRICT

);

Notes: ON DELETE policies are typical choices — you can tighten (RESTRICT) or loosen (CASCADE) depending
on policy.

6.6. Constraints and DDL for the AIRLINE Database

Repeat Exercise 6.5, but use the AIRLINE database schema of Figure 5.8.

Key referential constraints (from schema):

• FLIGHT_LEG(Flight_number, Leg_number) → FLIGHT(Flight_number) (i.e., flight leg references flight)

• FLIGHT_LEG.Departure_airport_code, FLIGHT_LEG.Arrival_airport_code → AIRPORT(Airport_code)

• LEG_INSTANCE(Flight_number, Leg_number, Date) → FLIGHT_LEG(Flight_number, Leg_number)

• LEG_INSTANCE.Airplane_id → AIRPLANE(Airplane_id)

• FARE.Flight_number → FLIGHT(Flight_number)

• AIRPLANE.Airplane_type → AIRPLANE_TYPE(Airplane_type_name)

• CAN_LAND(Airplane_type_name, Airport_code) references AIRPLANE_TYPE and AIRPORT

• SEAT_RESERVATION(Flight_number, Leg_number, Date) →

LEG_INSTANCE(Flight_number,Leg_number,Date)

DDL (compact):
CREATE TABLE AIRPORT (

Airport_code CHAR(6) PRIMARY KEY,

Name VARCHAR(100),

City VARCHAR(100),

State VARCHAR(50)

);

CREATE TABLE FLIGHT (

Flight_number VARCHAR(20) PRIMARY KEY,

Airline VARCHAR(100),

Weekdays VARCHAR(20)

);

CREATE TABLE FLIGHT_LEG (

Flight_number VARCHAR(20) NOT NULL,

Leg_number INT NOT NULL,

Departure_airport_code CHAR(6),

Scheduled_departure_time TIME,

Arrival_airport_code CHAR(6),

Scheduled_arrival_time TIME,

PRIMARY KEY (Flight_number, Leg_number),

FOREIGN KEY (Flight_number) REFERENCES FLIGHT(Flight_number)

ON UPDATE CASCADE ON DELETE CASCADE,

FOREIGN KEY (Departure_airport_code) REFERENCES AIRPORT(Airport_code),

FOREIGN KEY (Arrival_airport_code) REFERENCES AIRPORT(Airport_code)

);

CREATE TABLE AIRPLANE_TYPE (

Airplane_type_name VARCHAR(50) PRIMARY KEY,

 Max_seats INT,

Company VARCHAR(100)

);

CREATE TABLE AIRPLANE (

Airplane_id VARCHAR(20) PRIMARY KEY,

Total_number_of_seats INT,

Airplane_type VARCHAR(50),

FOREIGN KEY (Airplane_type) REFERENCES AIRPLANE_TYPE(Airplane_type_name)

ON UPDATE CASCADE ON DELETE RESTRICT

);

CREATE TABLE LEG_INSTANCE (

Flight_number VARCHAR(20) NOT NULL,

Leg_number INT NOT NULL,

Date DATE NOT NULL,

Number_of_available_seats INT,

Airplane_id VARCHAR(20),

Departure_airport_code CHAR(6),

Departure_time TIME,

Arrival_airport_code CHAR(6),

Arrival_time TIME,

PRIMARY KEY (Flight_number, Leg_number, Date),

FOREIGN KEY (Flight_number, Leg_number) REFERENCES FLIGHT_LEG(Flight_number, Leg_number)

ON UPDATE CASCADE ON DELETE CASCADE,

FOREIGN KEY (Airplane_id) REFERENCES AIRPLANE(Airplane_id),

FOREIGN KEY (Departure_airport_code) REFERENCES AIRPORT(Airport_code),

FOREIGN KEY (Arrival_airport_code) REFERENCES AIRPORT(Airport_code)

);
CREATE TABLE FARE (

Flight_number VARCHAR(20) NOT NULL,

Fare_code VARCHAR(10) NOT NULL,

Amount DECIMAL(10,2),

Restrictions VARCHAR(200),

PRIMARY KEY (Flight_number, Fare_code),

FOREIGN KEY (Flight_number) REFERENCES FLIGHT(Flight_number)

ON UPDATE CASCADE ON DELETE CASCADE

);

CREATE TABLE CAN_LAND (

Airplane_type_name VARCHAR(50) NOT NULL,

Airport_code CHAR(6) NOT NULL,

PRIMARY KEY (Airplane_type_name, Airport_code),

FOREIGN KEY (Airplane_type_name) REFERENCES AIRPLANE_TYPE(Airplane_type_name),

FOREIGN KEY (Airport_code) REFERENCES AIRPORT(Airport_code)

);

CREATE TABLE SEAT_RESERVATION (

Flight_number VARCHAR(20) NOT NULL,

Leg_number INT NOT NULL,

Date DATE NOT NULL,

Seat_number VARCHAR(10) NOT NULL,

Customer_name VARCHAR(200),

Customer_phone VARCHAR(20),

PRIMARY KEY (Flight_number, Leg_number, Date, Seat_number),

FOREIGN KEY (Flight_number, Leg_number, Date) REFERENCES LEG_INSTANCE(Flight_number, Leg_number,

Date)
 ON UPDATE CASCADE ON DELETE RESTRICT

);

Notes: seat reservation must reference an existing leg instance (date). Number_of_available_seats should be
checked as business rule when inserting reservations.

6.7. Referential Integrity Actions for the LIBRARY Database (Figure 6.6)

Consider the LIBRARY relational database schema shown in Figure 6.6.

Choose the appropriate action (reject, cascade, set to NULL, set to default) for each referential integrity
constraint, both for the deletion of a referenced tuple and for the update of a primary key attribute value in a
referenced tuple. Justify your choices.

Relevant relations from Figure 6.6:

BOOK(Book_id, Title, Publisher_name)
BOOK_AUTHORS(Book_id, Author_name)
PUBLISHER(Name, Address, Phone)
BOOK_COPIES(Book_id, Branch_id, No_of_copies)
BOOK_LOANS(Book_id, Branch_id, Card_no, Date_out, Due_date)
LIBRARY_BRANCH(Branch_id, Branch_name, Address)
BORROWER(Card_no, Name, Address, Phone)

Chosen actions (practical & justified):

 1. BOOK_AUTHORS.Book_id → BOOK.Book_id

o ON DELETE CASCADE — if a book is removed from catalog, delete author entries for that book.

o ON UPDATE CASCADE — if Book_id changes propagate.

Why: BOOK_AUTHORS only meaningful with its book.

2. BOOK.Publisher_name → PUBLISHER.Name

o ON DELETE SET NULL — if publisher removed, keep book record but null publisher (library still
holds book).

o ON UPDATE CASCADE — if publisher name changes propagate.

Why: publisher deletion should not force deletion of books.

3. BOOK_COPIES.Book_id → BOOK.Book_id

o ON DELETE CASCADE — if a book is removed, its copies entries should be removed.

o ON UPDATE CASCADE

Why: copies tied to the book.

4. BOOK_COPIES.Branch_id → LIBRARY_BRANCH.Branch_id

o ON DELETE RESTRICT — do not delete a branch if copies exist (must relocate/clear first).

o ON UPDATE CASCADE

5. BOOK_LOANS.Book_id → BOOK.Book_id

o ON DELETE RESTRICT — do not allow deleting a book that has current loan records (or move to
archive first).

o ON UPDATE CASCADE

Alternative: could cascade historical loans to archive, but safer to restrict.

6. BOOK_LOANS.Branch_id → LIBRARY_BRANCH.Branch_id

o ON DELETE RESTRICT — cannot delete branch with existing loans.

o ON UPDATE CASCADE

7. BOOK_LOANS.Card_no → BORROWER.Card_no

o ON DELETE RESTRICT — cannot delete borrower with outstanding loans.

o ON UPDATE CASCADE

Short justification:

• Use CASCADE for child tables that only make sense with the parent (authors, copies).
 • Use RESTRICT for entities where deletions would cause loss of important history or orphan loans
(loans, branches, borrowers).

• Use SET NULL for optional references (publisher) so book data remains.

6.8. SQL DDL for the LIBRARY Database (Figure 6.6)

Write appropriate SQL DDL statements for declaring the LIBRARY relational database schema of Figure 6.6.
Specify the keys and referential triggered actions.

CREATE TABLE PUBLISHER (

Name VARCHAR(200) PRIMARY KEY,

Address VARCHAR(300),

Phone VARCHAR(20)

);

CREATE TABLE BOOK (

Book_id VARCHAR(50) PRIMARY KEY,

Title VARCHAR(300),

Publisher_name VARCHAR(200),

FOREIGN KEY (Publisher_name) REFERENCES PUBLISHER(Name)

ON UPDATE CASCADE ON DELETE SET NULL

);

CREATE TABLE BOOK_AUTHORS (

Book_id VARCHAR(50),

Author_name VARCHAR(200),

PRIMARY KEY (Book_id, Author_name),

FOREIGN KEY (Book_id) REFERENCES BOOK(Book_id)

ON UPDATE CASCADE ON DELETE CASCADE

);
CREATE TABLE LIBRARY_BRANCH (

Branch_id INT PRIMARY KEY,

Branch_name VARCHAR(200),

Address VARCHAR(300)

);

CREATE TABLE BOOK_COPIES (

Book_id VARCHAR(50),

Branch_id INT,

No_of_copies INT,

PRIMARY KEY (Book_id, Branch_id),

FOREIGN KEY (Book_id) REFERENCES BOOK(Book_id)

ON UPDATE CASCADE ON DELETE CASCADE,

FOREIGN KEY (Branch_id) REFERENCES LIBRARY_BRANCH(Branch_id)

ON UPDATE CASCADE ON DELETE RESTRICT

);

CREATE TABLE BORROWER (

Card_no INT PRIMARY KEY,

Name VARCHAR(200),

Address VARCHAR(300),

Phone VARCHAR(20)

);

CREATE TABLE BOOK_LOANS (

Book_id VARCHAR(50),

Branch_id INT,

Card_no INT,

Date_out DATE,
 Due_date DATE,

PRIMARY KEY (Book_id, Branch_id, Card_no, Date_out),

FOREIGN KEY (Book_id) REFERENCES BOOK(Book_id)

ON UPDATE CASCADE ON DELETE RESTRICT,

FOREIGN KEY (Branch_id) REFERENCES LIBRARY_BRANCH(Branch_id)

ON UPDATE CASCADE ON DELETE RESTRICT,

FOREIGN KEY (Card_no) REFERENCES BORROWER(Card_no)

ON UPDATE CASCADE ON DELETE RESTRICT

);

6.9. Constraint Enforcement

1. How can the key and foreign key constraints be enforced by the DBMS?

2. Is the enforcement technique you suggest difficult to implement?

3. Can the constraint checks be executed efficiently when updates are applied to the database?

How enforced by DBMS:

• Primary keys / unique keys: enforced by maintaining unique indexes (B-tree or hash). Inserting or
updating a key checks the index for duplicates.

• Foreign keys: enforced by checking the referenced table (usually via index on referenced PK) when
inserting/updating/deleting child or parent. Many DBMSs maintain internal structures to check
existence quickly.

• Triggered actions: performed automatically by DBMS engine (cascading updates/deletes) or via user-
defined triggers where DBMS lacks FK features.

Difficulty to implement:

• Not difficult conceptually — core DBMS functionality. Implementation requires careful concurrency
control and locking to avoid race conditions.

Performance / Efficiency:

• With proper indexes on PKs and FKs, checks are efficient (logarithmic lookup).

• Bulk updates may be expensive if many cascading actions occur, but overall enforcement is efficient in
production systems.

6.10. SQL Queries on the COMPANY Database

Specify the following queries in SQL on the COMPANY relational database schema shown in Figure 5.5. Show
the result of each query if it is applied to the COMPANY database in Figure 5.6.

a. Retrieve the names of all employees in department 5 who work more than 10 hours per week on the
ProductX project. b. List the names of all employees who have a dependent with the same first name as
themselves. c. Find the names of all employees who are directly supervised by ‘Franklin Wong’.

a) Question:

Retrieve names of all employees in department 5 who work more than 10 hours/week on the ProductX
project.

SQL:

SELECT E.Fname, E.Minit, E.Lname

FROM EMPLOYEE E

JOIN WORKS_ON W ON E.Ssn = W.Essn

JOIN PROJECT P ON W.Pno = P.Pnumber

WHERE E.Dno = 5

AND P.Pname = 'ProductX'

AND W.Hours > 10;

Result (from Figure 5.6):

• John B Smith — (Essn 123456789, Hours 32.5 on Pno=1 ProductX)

• Joyce A English — (Essn 453453453, Hours 20.0 on Pno=1 ProductX)

So the rows returned:

Fname | Minit | Lname

------+-------+---------

John | B | Smith
Joyce | A | English

b) Question:

List the names of all employees who have a dependent with the same first name as themselves.

SQL:

SELECT DISTINCT E.Fname, E.Minit, E.Lname

FROM EMPLOYEE E

JOIN DEPENDENT D ON E.Ssn = D.Essn

WHERE E.Fname = D.Dependent_name;

Result (from Figure 5.6):

No employee has a dependent with the identical first name (compare EMPLOYEE Fname values with
DEPENDENT.Dependent_name values).
So result: (empty set)

c) Question:

Find the names of all employees who are directly supervised by ‘Franklin Wong’.

SQL:

SELECT E.Fname, E.Minit, E.Lname

FROM EMPLOYEE E

JOIN EMPLOYEE S ON E.Super_ssn = S.Ssn

WHERE S.Fname = 'Franklin' AND S.Lname = 'Wong';

Who is Franklin Wong? Franklin T Wong has Ssn = 333445555 (from Figure 5.6).

Employees with Super_ssn = 333445555 (Figure 5.6):

• John B Smith (Ssn 123456789)

• Ramesh K Narayan (Ssn 666884444)

• Joyce A English (Ssn 453453453)

Result rows:

Fname | Minit | Lname

-------+-------+-------------

John | B | Smith
Ramesh | K | Narayan

Joyce | A | English

6.11. Specify the updates of Exercise 3.11 using SQL update commands.

I don’t have the text of Exercise 3.11 in front of me. If you paste that exercise here I’ll convert each required
update precisely to SQL.
Meanwhile, here are examples of common update operations expressed in SQL so you can see the pattern and
adapt to your specific Exercise 3.11:

-- Example: insert a new student

INSERT INTO STUDENT (Student_number, Name, Class, Major)

VALUES (17, 'Johnson', 1, 'Math');

-- Example: update a student's major

UPDATE STUDENT

SET Major = 'CS'

WHERE Student_number = 17;

-- Example: delete a section

DELETE FROM SECTION

WHERE Section_identifier = 112;

-- Example: change a section's instructor

UPDATE SECTION

SET Instructor = 'King'

WHERE Section_identifier = 85;

If you paste Exercise 3.11 here I’ll rewrite those exact updates in SQL for you.

6.12. SQL queries on schema of Figure 1.2

Schema used:
STUDENT(Student_number, Name, Class, Major)
COURSE(Course_number, Course_name, Credit_hours, Department)
SECTION(Section_identifier, Course_number, Semester, Year, Instructor)
GRADE_REPORT(Student_number, Section_identifier, Grade)
PREREQUISITE(Course_number, Prerequisite_number)

(a) Retrieve names of all senior students majoring in 'cs'.

(Assuming Class = 4 means senior)

SELECT Name

FROM STUDENT

WHERE Class = 4

AND LOWER(Major) = 'cs';

(b) Retrieve names of all courses taught by Professor King in 2007 and 2008.

SELECT DISTINCT C.Course_name

FROM COURSE C

JOIN SECTION S ON C.Course_number = S.Course_number

WHERE S.Instructor = 'King'

AND S.Year IN (2007, 2008);

(c) For each section taught by Professor King, retrieve course number, semester, year, and number of
students who took the section.

SELECT S.Course_number,

S.Semester,

S.Year,

COUNT(G.Student_number) AS num_students

FROM SECTION S

LEFT JOIN GRADE_REPORT G

ON S.Section_identifier = G.Section_identifier
WHERE S.Instructor = 'King'

GROUP BY S.Course_number, S.Semester, S.Year;

(d) Retrieve the name and transcript of each senior student (Class = 4) majoring in CS.
(Transcript: course name, course number, credit hours, semester, year, grade)

SELECT ST.Name,

C.Course_number,

C.Course_name,

C.Credit_hours,

S.Semester,

S.Year,

G.Grade

FROM STUDENT ST

JOIN GRADE_REPORT G ON ST.Student_number = G.Student_number

JOIN SECTION S ON G.Section_identifier = S.Section_identifier

JOIN COURSE C ON S.Course_number = C.Course_number

WHERE ST.Class = 4

AND LOWER(ST.Major) = 'cs'

ORDER BY ST.Name, S.Year, S.Semester;

6.13. SQL update statements on Figure 1.2 schema

(a) Insert new student <'Johnson', 25, 1, 'Math'> — assuming columns are (Name, Student_number, Class,
Major):

INSERT INTO STUDENT (Name, Student_number, Class, Major)

VALUES ('Johnson', 25, 1, 'Math');

(b) Change the class of student with name 'Smith' to 2.

(If name not unique, better to use Student_number; using name as asked:)

UPDATE STUDENT

SET Class = 2

WHERE Name = 'Smith';

(c) Insert new course < 'Knowledge Engineering', 'cs4390', 3, 'cs' >:

INSERT INTO COURSE (Course_name, Course_number, Credit_hours, Department)

VALUES ('Knowledge Engineering', 'cs4390', 3, 'cs');

(d) Delete the record for the student whose name is 'Smith' and whose student number is 17:

DELETE FROM STUDENT

WHERE Name = 'Smith' AND Student_number = 17;

6.14. Design a small relational DB (brief)

Choice: Simple Online Bookstore — concise schema + example queries + suggested indexes.

DDL (concise):

CREATE TABLE CUSTOMER (

CustID INT PRIMARY KEY,

Name VARCHAR(200),

Email VARCHAR(200) UNIQUE,

City VARCHAR(100)

);

CREATE TABLE BOOK (

ISBN VARCHAR(20) PRIMARY KEY,

Title VARCHAR(300),

Publisher VARCHAR(200),

Price DECIMAL(8,2)

);

CREATE TABLE BOOK_AUTHOR (

ISBN VARCHAR(20),

Author VARCHAR(200),

PRIMARY KEY (ISBN, Author),

FOREIGN KEY (ISBN) REFERENCES BOOK(ISBN) ON DELETE CASCADE

);
CREATE TABLE ORDERS (

OrderID INT PRIMARY KEY,

CustID INT,

Odate DATE,

TotalAmt DECIMAL(10,2),

FOREIGN KEY (CustID) REFERENCES CUSTOMER(CustID) ON DELETE SET NULL

);

CREATE TABLE ORDER_ITEM (

OrderID INT,

ISBN VARCHAR(20),

Qty INT,

PriceEach DECIMAL(8,2),

PRIMARY KEY (OrderID, ISBN),

FOREIGN KEY (OrderID) REFERENCES ORDERS(OrderID) ON DELETE CASCADE,

FOREIGN KEY (ISBN) REFERENCES BOOK(ISBN)

);

Useful queries (examples):

1. SELECT * FROM BOOK WHERE Price < 20;

2. Customer order history: SELECT O.OrderID, O.Odate, I.ISBN, I.Qty FROM ORDERS O JOIN ORDER_ITEM I
USING (OrderID) WHERE O.CustID = ?;

3. Top-selling books: SELECT ISBN, SUM(Qty) FROM ORDER_ITEM GROUP BY ISBN ORDER BY SUM(Qty)
DESC;

Indexes to create:

• CREATE INDEX idx_book_title ON BOOK(Title); — for search by title

• CREATE INDEX idx_orders_cust ON ORDERS(CustID); — for customer order lookups

• PKs already indexed.

Implement on any SQL DBMS as needed.

6.15. EMP_SUPERFK with ON DELETE CASCADE ON UPDATE CASCADE — questions

Context: EMP_SUPERFK is FOREIGN KEY (Super_ssn) REFERENCES EMPLOYEE(Ssn) ON DELETE CASCADE ON

UPDATE CASCADE.

(a) What happens when DELETE EMPLOYEE WHERE Lname = 'Borg' is run on Figure 5.6 state?

• The DBMS finds employee(s) with Lname='Borg' (from Figure 5.6 that is James E Borg, Ssn =
888665555). Because of ON DELETE CASCADE, the DBMS:

1. Deletes the Borg row from EMPLOYEE.

2. Also deletes any employee rows whose Super_ssn = 888665555 (i.e., all direct subordinates of
Borg).

3. That cascading delete continues recursively: if those deleted employees are supervisors of
others, their subordinates are deleted as well.

• So a single delete may remove a whole subtree of employees who ultimately report (directly or
indirectly) to Borg.

(b) Is it better to CASCADE or SET NULL for EMP_SUPERFK ON DELETE?

• Recommendation: Use SET NULL or RESTRICT rather than CASCADE.

Reason: cascading deletes of employees is dangerous — deleting one manager could inadvertently
remove many employee records (loss of data). Better options:

o ON DELETE SET NULL → subordinates remain but their Super_ssn becomes NULL (no
supervisor); or

o ON DELETE RESTRICT (disallow delete unless supervisor relationship handled manually).

• Use CASCADE only if you truly intend to delete the entire reporting subtree when deleting a supervisor
— rare in HR scenarios.

6.16. Create EMPLOYEE_BACKUP to back up EMPLOYEE table (Figure 5.6)

Option A — copy structure + data (one-shot backup):

CREATE TABLE EMPLOYEE_BACKUP AS

SELECT * FROM EMPLOYEE;

(Works in many DBMS: PostgreSQL, SQLite, Oracle uses CREATE TABLE AS SELECT, MySQL supports CREATE
TABLE ... SELECT ... )

Option B — create table with same constraints then copy data:

CREATE TABLE EMPLOYEE_BACKUP (

Fname VARCHAR(50),
 Minit CHAR(1),

Lname VARCHAR(50),

Ssn CHAR(9) PRIMARY KEY,

Bdate DATE,

Address VARCHAR(300),

Sex CHAR(1),

Salary DECIMAL(10,2),

Super_ssn CHAR(9),

Dno INT

);

INSERT INTO EMPLOYEE_BACKUP

SELECT Fname, Minit, Lname, Ssn, Bdate, Address, Sex, Salary, Super_ssn, Dno

FROM EMPLOYEE;

Option C — schedule a repeating backup:

Use DBMS tools or cron jobs to run the CREATE TABLE AS SELECT periodically, or use INSERT INTO
EMPLOYEE_BACKUP SELECT ... to append historical snapshots with timestamp column.

7.1. Six clauses in SQL retrieval query

A full SQL SELECT query can include up to six clauses in this order:

1. SELECT –
o Specifies which attributes or expressions to display in the result.
o Can include aggregate functions, expressions, and the DISTINCT keyword.
o Required clause.
2. FROM –
o Lists the tables (and joins) from which the data is retrieved.
o May include aliases and JOIN conditions.
 o Required clause.
3. WHERE –
o Filters rows based on a condition (comparison, logical operators, IN, BETWEEN, LIKE, etc.).
o Optional.
4. GROUP BY –
o Groups rows with the same values in one or more columns for aggregate functions (SUM, AVG,
etc.).
o Optional.
5. HAVING –
o Applies a condition to groups formed by GROUP BY.
o Similar to WHERE, but used for aggregate conditions.
o Optional.
6. ORDER BY –
o Sorts the final result set by one or more columns, ascending or descending.
o Optional.

Required: SELECT, FROM

Optional: WHERE, GROUP BY, HAVING, ORDER BY

7.2. Conceptual order of execution of SQL query

Although written in the order

SELECT – FROM – WHERE – GROUP BY – HAVING – ORDER BY,
SQL conceptually executes in a different logical sequence:

1. FROM → Identify and join all tables.

2. WHERE → Apply row-level filters (select rows satisfying conditions).
3. GROUP BY → Form groups of remaining rows (if present).
4. HAVING → Filter groups that do not satisfy aggregate conditions.
5. SELECT → Choose columns or expressions to output (evaluate aggregates).
6. ORDER BY → Sort the final result rows.

So the conceptual execution order is:

FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY

7.3. Treatment of NULL values in SQL

1. In comparison operators:
o Any comparison with NULL (e.g., =, >, <, <>) yields UNKNOWN, not TRUE or FALSE.
o Rows with UNKNOWN in a WHERE condition are excluded from the result.
o Example:
o WHERE Salary > NULL -- always UNKNOWN
o To test NULLs, use IS NULL or IS NOT NULL.
2. In aggregate functions:
o COUNT, SUM, AVG, MIN, and MAX ignore NULL values (except COUNT(*) which counts all rows).
 o Example: If some salaries are NULL, AVG(Salary) averages only non-NULL salaries.
3. In grouping attributes:
o Rows with NULL values in grouping columns are treated as equal (all NULLs form one group).
o Example:
o GROUP BY Dept_no

— All tuples with Dept_no IS NULL belong to a single group labeled NULL.

Summary Table

Context NULL Treatment

Comparisons Evaluated as UNKNOWN; excluded unless IS NULL used
Aggregates Ignored (except COUNT(*))
Grouping All NULLs form one group

7.4. Discuss how each of the following constructs is used in SQL, and
options / uses (brief).
a. Nested queries (subqueries)

• What: A query inside another query (in WHERE, FROM, or SELECT).

• Options: scalar subquery (returns single value), row subquery, column subquery (IN), EXISTS/NOT
EXISTS, correlated subquery (refers to outer query).
• Useful for: filtering using results of another query, testing existence, computing values per-row.

b. Joined tables and outer joins

 • What: Combine rows from two or more tables.
• Options: INNER JOIN (only matching rows), LEFT/RIGHT OUTER JOIN (preserve left/right rows even if
no match), FULL OUTER JOIN (preserve both), cross join (cartesian). Also NATURAL JOIN and
USING.
• Useful for: retrieving related data from multiple tables in one result; outer joins keep unmatched rows
for reporting.

c. Aggregate functions and grouping

• What: SUM, AVG, COUNT, MIN, MAX operate on sets of rows. GROUP BY groups rows before aggregation;
HAVING filters groups.
• Options: grouping by one or many attributes, grouping sets, ROLLUP, CUBE (DBMS-specific).
• Useful for: totals, averages, counts per group (e.g., salary by department).

d. Triggers

• What: Stored procedures automatically executed on INSERT, UPDATE, or DELETE on a table.

• Options: BEFORE/AFTER triggers, row-level vs statement-level.
• Useful for: enforcing complex integrity rules, logging, maintaining derived data, cascading complex
actions.

e. Assertions and how they differ from triggers

• What: CREATE ASSERTION (SQL standard) expresses global constraints across database. Rarely
implemented.
• Difference: Assertions are declarative global constraints checked by DBMS; triggers are procedural and
tied to specific tables/events. Assertions should be checked always but may be expensive; triggers run
on specific events and can take actions.

f. The SQL WITH clause (Common Table Expressions — CTEs)

• What: Define named subqueries (temporary result sets) used by the main query.
• Options: non-recursive and recursive (WITH RECURSIVE).
• Useful for: clarity, reuse of subquery results, writing recursive queries (hierarchies).

g. SQL CASE construct

• What: Conditional expression (similar to if-then-else) inside SELECT, WHERE, etc.

• Options: CASE WHEN cond THEN val ... ELSE val END or CASE expr WHEN val THEN ....
• Useful for: conditional value generation, buckets, derived categories.
h. Views and their updatability

• What: Named queries stored as virtual tables (CREATE VIEW).

• Options: simple views (single base table) are often updatable; complex views (aggregates, joins,
DISTINCT, GROUP BY) usually not updatable. Some DBMS support INSTEAD OF triggers to make
complex views updatable.
• Useful for: security (restrict columns), convenience, hiding complexity, presenting derived data.

i. Schema change commands

• What: CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX, DROP INDEX, etc.
• Options: ALTER TABLE can add/drop columns, add constraints, rename columns (DBMS-specific
syntax).
• Useful for: evolving database structure; must consider data migration and constraints.

7.5. SQL queries on COMPANY (Figure 5.5) & results on Figure 5.6
(a) For each department whose average employee salary is more than $30,000, retrieve the department
name and the number of employees working for that department.

SQL:

SELECT D.Dname, COUNT(E.Ssn) AS num_employees

FROM DEPARTMENT D
JOIN EMPLOYEE E ON D.Dnumber = E.Dno
GROUP BY D.Dname
HAVING AVG(E.Salary) > 30000;

Evaluate on Figure 5.6:

Compute avg salary per department (from provided EMPLOYEE rows):

• Dept 1 (Headquarters) — employees: James Borg (salary 55000) → avg = 55000 → qualifies, count = 1
• Dept 4 (Administration) — Alicia(25000), Jennifer(43000), Ahmad(25000) → avg =
(25000+43000+25000)/3 = 31000 → qualifies, count = 3
• Dept 5 (Research) — John(30000), Franklin(40000), Ramesh(38000), Joyce(25000) → avg = 33250 →
qualifies, count = 4

Result rows:

Dname | num_employees
--------------+--------------
Headquarters | 1
Administration| 3
Research | 4
(b) Suppose we want the number of male employees in each department making more than $30,000,
rather than all employees (as in 7.5a). Can we specify this query in SQL? Why or why not?

Short answer: Yes — we can.

Two ways:

1. Filter then group (only departments with at least one male >30k):

SELECT D.Dname, COUNT(*) AS male_highpaid_count

FROM DEPARTMENT D
JOIN EMPLOYEE E ON D.Dnumber = E.Dno
WHERE E.Sex = 'M' AND E.Salary > 30000
GROUP BY D.Dname;

• This returns counts only for departments that have qualifying males. Departments with zero qualifying
males will be absent.

2. Conditional aggregation (returns zero for departments with none):

SELECT D.Dname,
SUM(CASE WHEN E.Sex='M' AND E.Salary>30000 THEN 1 ELSE 0 END) AS
male_highpaid_count
FROM DEPARTMENT D
LEFT JOIN EMPLOYEE E ON D.Dnumber = E.Dno
GROUP BY D.Dname;

• This returns every department, with 0 when none qualify.

Result on Figure 5.6 using conditional aggregation:

Check male employees with salary > 30000:

• Dept1: James Borg (M,55000) → count 1

• Dept4: male employees are Alicia F (F), Jennifer F, Ahmad M (25000) none >30000 → count 0
• Dept5: Franklin M (40000) and Ramesh M (38000) → count 2

So results (if you use conditional aggregation and include all departments):

Dname | male_highpaid_count
--------------+---------------------
Headquarters | 1
Administration| 0
Research | 2

Why it’s possible: SQL supports WHERE filtering and conditional aggregation (CASE) so this is easily
expressible.
7.6. (Queries on the database in Figure 1.2)

Given schema (from Fig 1.2): STUDENT(Student_number, Name, Class, Major), COURSE, SECTION,
GRADE_REPORT(Student_number, Section_identifier, Grade), etc.
(You provided Figure 1.2 earlier — I used its data.)

(a) Retrieve the names and major departments of all straight-A students (students who have a grade of A in
all their courses).

SQL:

SELECT S.Name, S.Major

FROM STUDENT S

WHERE NOT EXISTS (

SELECT 1

FROM GRADE_REPORT G

WHERE G.Student_number = S.Student_number

 AND G.Grade <> 'A'

);

Explanation: For each student ensure there is no grade that is not 'A'. (Also handles students with no grades —
they would be returned; to exclude those add AND EXISTS (SELECT 1 FROM GRADE_REPORT G WHERE
G.Student_number = S.Student_number).)

Result on the Figure 1.2 data you provided:

• No rows — there are no students who have A in every course.

(From the grade_report in the figure: student 17 has B and C; student 8 has a B among As.)

(b) Retrieve the names and major departments of all students who do not have a grade of A in any of their
courses.

SQL:

SELECT S.Name, S.Major

FROM STUDENT S

WHERE NOT EXISTS (

SELECT 1 FROM GRADE_REPORT G

WHERE G.Student_number = S.Student_number

AND G.Grade = 'A'

);

Explanation: Select students for whom there is no grade='A' row.

Result on Figure 1.2 data:

• Smith (Student_number = 17, Major = CS) — student 17 has grades B and C only.
(Student 8 has some A’s, so excluded.)

7.7. (Nested queries on COMPANY schema — Figure 5.5 — use Figure 5.6 data)

Schema: EMPLOYEE(Ssn,Fname,Minit,Lname,Salary,Super_ssn,Dno), DEPARTMENT(Dnumber,Dname,...),

WORKS_ON(Essn,Pno,Hours), PROJECT(Pnumber,Pname,Dnum), etc.

(a) Retrieve the names of all employees who work in the department that has the employee with the
highest salary among all employees.

SQL:

SELECT E.Fname, E.Minit, E.Lname

FROM EMPLOYEE E

WHERE E.Dno = (

SELECT Dno

FROM EMPLOYEE

WHERE Salary = (SELECT MAX(Salary) FROM EMPLOYEE)

LIMIT 1

);

Result using Figure 5.6:

• Highest salary = 55000 (James E Borg), Dno = 1. Employees in Dno=1:

James E Borg
So output:

James | E | Borg

(b) Retrieve the names of all employees whose supervisor's supervisor has Ssn = '888665555'.

SQL (self-join / nested):

SELECT E.Fname, E.Minit, E.Lname

FROM EMPLOYEE E

JOIN EMPLOYEE S ON E.Super_ssn = S.Ssn

JOIN EMPLOYEE SS ON S.Super_ssn = SS.Ssn

WHERE SS.Ssn = '888665555';

Result using Figure 5.6:

Employees whose supervisor is someone whose supervisor is 888665555 are:

• John B Smith (super = 333445555, and 333445555's super = 888665555)

• Ramesh K Narayan

• Joyce A English

So output rows:

John B Smith

Ramesh K Narayan

Joyce A English
(c) Retrieve the names of employees who make at least $10,000 more than the employee who is paid the
least in the company.

SQL:

SELECT E.Fname, E.Minit, E.Lname

FROM EMPLOYEE E

WHERE E.Salary >= (SELECT MIN(Salary) FROM EMPLOYEE) + 10000;

Figure 5.6 data: min salary = 25000. So threshold = 35000. Employees with salary >= 35000 are:

• Franklin T Wong (40000)

• Jennifer S Wallace (43000)

• Ramesh K Narayan (38000)

• James E Borg (55000)

Result:

Franklin T Wong

Jennifer S Wallace

Ramesh K Narayan

James E Borg

7.8. Specify the following views in SQL on the COMPANY schema (Figure 5.5)

Use CREATE VIEW statements.

(a) A view that has the department name, manager name, and manager salary for every department.

CREATE VIEW Dept_Manager AS

SELECT D.Dname AS Department,

M.Fname || ' ' || M.Minit || ' ' || M.Lname AS ManagerName,

M.Salary AS ManagerSalary

FROM DEPARTMENT D

LEFT JOIN EMPLOYEE M ON D.Mgr_ssn = M.Ssn;

(b) A view that has the employee name, supervisor name, and employee salary for each employee who
works in the 'Research' department.
CREATE VIEW Research_Employees AS

SELECT E.Fname || ' ' || E.Minit || ' ' || E.Lname AS EmployeeName,

S.Fname || ' ' || S.Minit || ' ' || S.Lname AS SupervisorName,

E.Salary

FROM EMPLOYEE E

LEFT JOIN EMPLOYEE S ON E.Super_ssn = S.Ssn

WHERE E.Dno = (SELECT Dnumber FROM DEPARTMENT WHERE Dname = 'Research');

(c) A view that has the project name, controlling department name, number of employees, and total hours
worked per week on the project for each project.

CREATE VIEW Project_Work_Summary AS

SELECT P.Pname AS ProjectName,

D.Dname AS ControllingDept,

COUNT(DISTINCT W.Essn) AS NumEmployees,

COALESCE(SUM(W.Hours),0) AS TotalHours

FROM PROJECT P

LEFT JOIN WORKS_ON W ON P.Pnumber = W.Pno

LEFT JOIN DEPARTMENT D ON P.Dnum = D.Dnumber

GROUP BY P.Pname, D.Dname;

(d) A view same as (c) but only for projects with more than one employee working on it.

CREATE VIEW Project_MultiEmp AS

SELECT P.Pname AS ProjectName,

D.Dname AS ControllingDept,

COUNT(DISTINCT W.Essn) AS NumEmployees,

COALESCE(SUM(W.Hours),0) AS TotalHours

FROM PROJECT P

LEFT JOIN WORKS_ON W ON P.Pnumber = W.Pno

LEFT JOIN DEPARTMENT D ON P.Dnum = D.Dnumber

GROUP BY P.Pname, D.Dname

HAVING COUNT(DISTINCT W.Essn) > 1;

7.9. Consider view DEPT_SUMMARY(D, C, Total_s, Average_s) defined as:

CREATE VIEW DEPT_SUMMARY(D, C, Total_s, Average_s) AS

SELECT Dno, COUNT(*), SUM(Salary), AVG(Salary)

FROM EMPLOYEE

GROUP BY Dno;

State which of the following queries/updates would be allowed on the view, and show the corresponding
base-relation query/result on the Figure 5.6 database.

(a) SELECT * FROM DEPT_SUMMARY;

Allowed? Yes — reading a view is always allowed.

Underlying result (computed from Figure 5.6):

Compute per Dno:

• Dno = 1 (Headquarters): count=1, sum=55000, avg=55000

• Dno = 4 (Administration): count=3, sum=25000+43000+25000 = 93000, avg=31000

• Dno = 5 (Research): count=4, sum=30000+40000+38000+25000 = 133000, avg=33250

Result rows (D, C, Total_s, Average_s):

1 | 1 | 55000 | 55000

4 | 3 | 93000 | 31000

5 | 4 | 133000 | 33250

(b)

SELECT D, C

FROM DEPT_SUMMARY

WHERE Total_s > 100000;

Allowed? Yes — projections and selections on a view are allowed.

Evaluation: From the computed rows above only Dno = 5 has Total_s > 100000.
Result:

D|C

--+--

5|4

About updates on this view:

• This is an aggregated view (GROUP BY). Updates (INSERT/UPDATE/DELETE) on such views are not
allowed (not updatable) because there is no one-to-one mapping to underlying base tuples. If you
attempted an update, the DBMS would reject it (unless you create INSTEAD OF triggers to handle it).

8.1. Operations of Relational Algebra and Their Purpose

Operation Purpose

SELECT (σ) Choose rows (tuples) that satisfy a condition.

PROJECT (π) Choose specific columns (attributes).

UNION (∪) Combine tuples from two union-compatible relations, removing duplicates.

INTERSECTION (∩) Return tuples common to both relations.

DIFFERENCE (−) Return tuples in one relation but not in the other.

CARTESIAN PRODUCT (×) Combine every tuple of one relation with every tuple of another.

JOIN (⋈) Combine related tuples from two relations based on a condition.

DIVISION (÷) Find tuples in one relation that are related to all tuples in another.

RENAME (ρ) Rename relation or attribute for clarity in complex queries.

8.2. What is Union Compatibility? Why Needed?

Union compatibility means:

• Two relations have the same number of attributes, and

• Corresponding attributes have the same domains (data types).

Why required:
The UNION, INTERSECTION, and DIFFERENCE operators compare tuples position-wise.
Hence, attributes must match in structure and meaning to produce valid results.
8.4. Types of Inner Join & Why Theta Join is Required

Types of Inner Join:

1. Theta Join (⋈θ) – Join where condition θ can use any comparison operator (=, <, >, ≤, ≥, ≠).

2. Equi-Join – A special theta join using only =.

3. Natural Join (⋈) – Equi-join that automatically joins on all common attribute names and removes
duplicates.

Why theta join is required:

It allows flexibility to join relations using non-equality conditions (e.g., salary > 30000 or date < 2025).

8.5. Role of Foreign Key in Joins

A foreign key creates a logical link between two relations:

• The foreign key attribute(s) in one relation refers to the primary key in another.

• Joins are typically done on this relationship (e.g., Employee.Dno = Department.Dnumber) to combine
related data.
Hence, foreign keys define meaningful join conditions between tables.

8.6. FUNCTION Operation

The FUNCTION operation applies built-in functions or aggregate operations (SUM, AVG, COUNT, MIN, MAX) to
attribute values in a relation.

Use:

• To compute summary information such as total salary, average marks, etc.

Example:
F = SUM(Salary)(EMPLOYEE) → returns total salary of all employees.

8.7. Difference between OUTER JOIN and INNER JOIN

Type Description

INNER JOIN Returns only matching tuples from both relations.

OUTER JOIN Returns matching tuples plus non-matching tuples from one or both relations.

LEFT OUTER JOIN Keeps all tuples from the left relation.

RIGHT OUTER JOIN Keeps all tuples from the right relation.
Type Description

FULL OUTER JOIN Keeps all tuples from both, filling NULLs for missing matches.

OUTER UNION vs UNION:

• UNION requires union-compatible relations (same attributes).

• OUTER UNION merges tuples with different but partially matching attributes, filling missing values with
NULLs.

8.8. Relational Calculus vs. Relational Algebra

Relational Algebra Relational Calculus

Procedural – Specifies how to get the result (sequence Non-procedural – Specifies what result is desired, not
of operations). how to get it.

Uses operators (σ, π, ⋈). Uses logical formulas (predicates).

Produces expressions on relations. Describes conditions tuples must satisfy.

Used for query optimization. Used for theoretical foundation of SQL.

Similarity: Both describe the same set of queries; they are relationally equivalent in power.

8.9. Tuple Relational Calculus vs. Domain Relational Calculus

Tuple Calculus (TRC) Domain Calculus (DRC)

Variables represent tuples. Variables represent individual attribute values (domains).

Example: `{t t ∈ EMPLOYEE ∧ t.Salary > 30000}`

Closer to SQL’s tuple-oriented form. Closer to Datalog / logical forms.

8.10. Existential (∃) and Universal (∀) Quantifiers

• Existential Quantifier (∃) – “There exists.”

Example: ∃t ∈ EMPLOYEE (t.Salary > 50000)
→ There exists an employee earning > 50000.

• Universal Quantifier (∀) – “For all.”

Example: ∀t ∈ EMPLOYEE (t.Salary > 0)
→ Every employee has a salary > 0.
8.11. Tuple Calculus Terms

Term Meaning

Tuple variable Symbol representing tuples of a relation.

Range relation Relation from which a tuple variable takes its values.

Atom Basic condition (e.g., t.Salary > 30000).

Formula Combination of atoms using logical connectives (∧, ∨, ¬).

Expression `{t

8.12. Domain Calculus Terms

Term Meaning

Domain variable Variable representing single attribute values.

Range relation Relation whose attributes supply possible values.

Atom Basic comparison between domain variables (e.g., x > y).

Formula Logical combination of atoms.

Expression `{<x₁,…,xₙ>

8.13. Safe Expression in Relational Calculus

An expression is safe if it produces a finite result that can be derived from existing database values.
Unsafe expressions could refer to infinite domains (e.g., {x | ¬(x ∈ EMPLOYEE)}).
SQL only allows safe expressions.

8.14. Relationally Complete Query Language

A query language is relationally complete if it can express all queries that can be formulated in relational
algebra.
Examples of relationally complete languages:

• SQL, Relational Calculus, Datalog, QUEL.

10marks::-
8.3.

Question: Discuss some types of queries for which renaming of attributes is necessary in order to specify the
query unambiguously.

Answer (short):
Renaming attributes (using AS in SQL or ρ in relational algebra) is required in queries such as:

1. Self-join — when joining a table to itself you must rename one copy so attributes (e.g., Employee.Ssn)
don’t conflict.

o Example: find employees and their supervisors: join EMPLOYEE as E and EMPLOYEE as S on
E.Super_ssn = S.Ssn — you need distinct names for E.Name and S.Name.

2. Join of relations with same attribute names — when two relations share attribute names but you want
to keep both (e.g., Course.Course_number and Prerequisite.Prerequisite_number), rename to avoid
ambiguity.

3. Union / set operations with different attribute names — before applying UNION you may need to
rename so column positions/types match.

4. Projection with expressions — when you compute expressions (Salary*1.1) you should give them a
name: SELECT Salary*1.1 AS NewSalary.

5. Nested queries / derived tables — when using a subquery in FROM you must name (alias) the derived
table and its attributes to reference them in outer query.

8.16.

Question: Specify the following queries on the COMPANY relational database schema (Figure 5.5) using
relational operators. Also show the result of each query as it would apply to the database state in Figure 5.6.

I’ll give a relational-algebra expression (brief) for each part, then the result computed from Figure 5.6.

Notation:
 • EMP, DEPT, WORKS_ON, PROJECT, DEPENDENT are the relation names.

• I use π (project), σ (select), × (cartesian), ⋈ (join), ρ (rename), γ (group/aggregate).

(a) Retrieve the names of all employees in department 5 who work more than 10 hours per week on the
ProductX project.

Relational-algebra expression:

π_{Fname,Minit,Lname} (

σ_{Dno=5 ∧ Hours>10 ∧ Pname='ProductX'} (

(EMP ⋈_{EMP.Ssn = WORKS_ON.Essn} WORKS_ON)

⋈_{WORKS_ON.Pno = PROJECT.Pnumber} PROJECT

Compute using Figure 5.6:

Projects: ProductX → Pnumber=1. WORKS_ON rows with Pno=1 are Essn 123456789 (32.5) and 453453453
(20.0). Both employees have Dno=5. Both >10 hours.

Result:

John B Smith

Joyce A English

(b) List the names of all employees who have a dependent with the same first name as themselves.

Relational algebra:

π_{E.Fname,E.Minit,E.Lname} (

σ_{E.Fname = D.Dependent_name} ( EMP ⋈_{EMP.Ssn = D.Essn} DEPENDENT D )

Compute on Figure 5.6: Compare employee first names to dependent names — no exact matches (Joy vs Joyce
not equal).

Result: empty set.

(c) Find the names of all employees who are directly supervised by ‘Franklin Wong’.

Relational algebra:
S = σ_{Fname='Franklin' ∧ Lname='Wong'}(EMP) ;

π_{E.Fname,E.Minit,E.Lname} ( EMP ⋈_{EMP.Super_ssn = S.Ssn} S )

(Or join EMP with a selection of EMP for Franklin.)

Compute on Figure 5.6: Franklin Wong has Ssn = 333445555. Employees with Super_ssn = 333445555 are Ssns
123456789 (John), 666884444 (Ramesh), 453453453 (Joyce).

Result:

John B Smith

Ramesh K Narayan

Joyce A English

(d) For each project, list the project name and the total hours per week (by all employees) spent on the
project.

Relational algebra (group/aggregate):

Result = γ_{Pname; SUM(Hours)→TotalHours} ( PROJECT ⋈_{PROJECT.Pnumber = WORKS_ON.Pno}

WORKS_ON )

π_{Pname, TotalHours} (Result)

Compute from Figure 5.6:

• ProductX (1): 32.5 + 20.0 = 52.5

• ProductY (2): 7.5 + 10.0 = 17.5

• ProductZ (3): 40.0 + 10.0 = 50.0

• Computerization (10): 10.0 + 10.0 + 35.0 = 55.0

• Reorganization (20): 10.0 + 15.0 + (NULL ignored) = 25.0 (NULL ignored in sum)

• Newbenefits (30): 30.0 + 5.0 + 20.0 = 55.0

Result rows:

ProductX | 52.5

ProductY | 17.5

ProductZ | 50.0

Computerization| 55.0

Reorganization| 25.0

Newbenefits | 55.0
(e) Retrieve the names of all employees who work on every project.

Relational algebra (division pattern):

Let AllP = π_{Pnumber}(PROJECT).
Let EmpProj = π_{Essn, Pno}(WORKS_ON).
Employees who work on all projects: π_{Essn} ( EmpProj ÷ AllP ) then join with EMP to get names.

Compute on Figure 5.6: projects set = {1,2,3,10,20,30}. No employee appears on all six project numbers.

Result: empty set.

(f) Retrieve the names of all employees who do not work on any project.

Relational algebra:

EmpNoProj = π_{Ssn}(EMP) − π_{Essn}(WORKS_ON)

π_{Fname,Minit,Lname} ( EMP ⋈_{EMP.Ssn = EmpNoProj.Ssn} EmpNoProj )

Compute: Every employee Ssn appears in WORKS_ON (check list) → none.

Result: empty set.

(g) For each department, retrieve the department name and the average salary of all employees working in
that department.

Relational algebra (group/aggregate):

DeptAvg = γ_{Dno; AVG(Salary)→AvgSal}(EMP)

Result = DeptAvg ⋈_{DeptAvg.Dno = DEPT.Dnumber} π_{Dname}(DEPT)

π_{Dname, AvgSal} (Result)

Compute using Figure 5.6:

• Dept 1 (Headquarters): avg = 55000

• Dept 4 (Administration): avg = (25000+43000+25000)/3 = 31000

• Dept 5 (Research): avg = (30000+40000+38000+25000)/4 = 33250

Result:

Headquarters | 55000

Administration | 31000

Research | 33250
(h) Retrieve the average salary of all female employees.

Relational algebra:

γ_{; AVG(Salary)→AvgFemale} ( σ_{Sex='F'}(EMP) )

Compute: female employees Alicia(25000), Jennifer(43000), Joyce(25000). Average = (25000+43000+25000)/3

= 31000.

Result: 31000

(i) Find names & addresses of employees who work on at least one project located in Houston but whose
department has no location in Houston.

Approach / RA (brief):

1. ProjHouston = σ_{Plocation='Houston'}(PROJECT)

2. EmpOnHoustonProj = π_{Essn}( WORKS_ON ⋈_{WORKS_ON.Pno = PROJECT.Pnumber} ProjHouston )

3. DeptHasHouston = π_{Dnumber}( σ_{Dlocation='Houston'}(DEPT_LOCATIONS) )

4. EmpDeptNoHouston = σ_{EMP.Dno ∉ DeptHasHouston}(EMP)

5. Result = π_{Fname,Lname,Address}( EmpDeptNoHouston ⋈_{EMP.Ssn = EmpOnHoustonProj.Essn}

EmpOnHoustonProj )

Compute with Figure 5.6 data: Projects in Houston: ProductZ (P3), Reorganization (P20). Employees working
on those projects: P3 → Essn 666884444 and 333445555; P20 → Essn 333445555, 987654321, 888665555.
Combined employees
{666884444(Ramesh,dno5),333445555(Franklin,dno5),987654321(Jennifer,dno4),888665555(James,dno1)}.
Departments that have Houston in DEPT_LOCATIONS: Dnumber 1 and 5 (Dept 5 has Bellaire, Sugarland,
Houston). So employees whose department has no location in Houston are those whose Dno ∉ {1,5} — that
leaves Dno 4 (Administration). Among the candidate employees above, only 987654321 (Jennifer) has Dno=4.

Result: Jennifer S Wallace — address: 291 Berry, Bellaire, TX.

(j) List the last names of all department managers who have no dependents.

Relational algebra:

MgrSSNs = π_{Mgr_ssn}(DEPARTMENT)

MgrsNoDeps = MgrSSNs − π_{Essn}(DEPENDENT)

π_{Lname}( EMP ⋈_{EMP.Ssn = MgrsNoDeps.Mgr_ssn} MgrsNoDeps )

Compute: DEPARTMENT managers: 333445555, 987654321, 888665555. Dependents exist for 333445555 and
987654321 (see DEPENDENT list). 888665555 (James Borg) has no dependents in DEPENDENT table.

Result: Borg

8.17.

Question: For the AIRLINE schema (Figure 5.8) specify queries in relational algebra.

I’ll give relational-algebra formulas for each part. I do not have a full instance of the AIRLINE data (you
showed the schema earlier but no instance with flight rows), so I will not produce numeric results unless you
provide the instance. If you want results, upload the airline instance (the data). For now I give RA expressions.

Let relations be: FLIGHT(Flight_number, Airline, Weekdays), FLIGHT_LEG(Flight_number, Leg_number,

Departure_airport_code, Scheduled_departure_time, Arrival_airport_code, Scheduled_arrival_time),
LEG_INSTANCE(Flight_number, Leg_number, Date, Number_of_available_seats, Airplane_id,
Departure_airport_code, Departure_time, Arrival_airport_code, Arrival_time) , FARE(Flight_number,
Fare_code, Amount, Restrictions), AIRPORT(Airport_code, City, State, Name), etc.
(a) For each flight, list the flight number, the departure airport for the first leg of the flight, and the arrival
airport for the last leg of the flight.

Relational algebra plan (conceptual):

1. FirstLeg = σ_{Leg_number = 1}(FLIGHT_LEG) — departure airport for leg 1.

2. LastLeg = γ_{Flight_number; MAX(Leg_number)→MaxLeg}(FLIGHT_LEG) then join FLIGHT_LEG with

that to get the actual last leg rows.

3. Result = π_{F.Flight_number, FL1.Departure_airport_code, FL2.Arrival_airport_code}( FLIGHT F ⋈

FirstLeg FL1 ⋈ LastLeg FL2 )

RA expression sketch:

FirstLeg = σ_{Leg_number=1}(FLIGHT_LEG)

MaxLegs = γ_{Flight_number; MAX(Leg_number)→MaxLeg}(FLIGHT_LEG)

LastLeg = MaxLegs ⋈_{MaxLegs.Flight_number = FLIGHT_LEG.Flight_number ∧ MaxLegs.MaxLeg =

FLIGHT_LEG.Leg_number} FLIGHT_LEG

Result = π_{Flight_number, FirstLeg.Departure_airport_code, LastLeg.Arrival_airport_code} ( FLIGHT ⋈ FirstLeg

⋈ LastLeg )

(b) List flight numbers and weekdays of flights or legs that depart from iah and arrive in lax.

RA (if considering legs):

Legs = σ_{Departure_airport_code='iah' ∧ Arrival_airport_code='lax'}(FLIGHT_LEG)

Result = π_{Flight_number, Weekdays} ( Legs ⋈ FLIGHT )

(If you also consider LEG_INSTANCE, replace FLIGHT_LEG by LEG_INSTANCE.)

(c) List flight number, departure airport code, scheduled departure time, arrival airport code, scheduled
arrival time, and weekdays of all flights or flight legs that depart from some airport in the city of Houston
and arrive in some airport in the city of Los Angeles.

RA sketch:

HoustonAirports = π_{Airport_code}( σ_{City='Houston'}(AIRPORT) )

LAirports = π_{Airport_code}( σ_{City='Los Angeles'}(AIRPORT) )

Legs = σ_{Departure_airport_code ∈ HoustonAirports ∧ Arrival_airport_code ∈ LAirports}(FLIGHT_LEG)

Result = π_{Flight_number, Departure_airport_code, Scheduled_departure_time, Arrival_airport_code,
Scheduled_arrival_time, Weekdays} ( Legs ⋈ FLIGHT )

(d) List all fare information for flight number co197.

RA:

Result = σ_{Flight_number='co197'}(FARE)

(e) Retrieve the number of available seats for flight number co197 on 2009-10-09.

RA (use LEG_INSTANCE):

Result = π_{Flight_number, SUM(Number_of_available_seats)} (

σ_{Flight_number='co197' ∧ Date='2009-10-09'}(LEG_INSTANCE)

(If you want per-leg, remove SUM and project Leg_number and Number_of_available_seats.)

8.18 — LIBRARY schema (Figure 8.14)

Relations:

BOOK(Book_id, Title, Publisher_name)

BOOK_AUTHORS(Book_id, Author_name)
PUBLISHER(Name, Address, Phone)
BOOK_COPIES(Book_id, Branch_id, No_of_copies)
BOOK_LOANS(Book_id, Branch_id, Card_no, Date_out, Due_date)
LIBRARY_BRANCH(Branch_id, Branch_name, Address)
BORROWER(Card_no, Name, Address, Phone)

(a) How many copies of the book titled The Lost Tribe are owned by branch 'Sharpstown'?

RA:

π_{No_of_copies} (

BOOK_COPIES ⋈_{BOOK_COPIES.Book_id = B.Book_id}

( σ_{Title='The Lost Tribe'}(BOOK) AS B )

⋈_{BOOK_COPIES.Branch_id = LB.Branch_id}

( σ_{Branch_name='Sharpstown'}(LIBRARY_BRANCH) AS LB )

Or aggregate total if multiple rows:

γ_{ } SUM(No_of_copies) ( BOOK_COPIES

⋈_{Book_id = (π Book_id of σ_{Title='The Lost Tribe'}(BOOK))}

⋈_{Branch_id = (π Branch_id of σ_{Branch_name='Sharpstown'}(LIBRARY_BRANCH))}

(b) How many copies of The Lost Tribe are owned by each branch?

RA:

BC = BOOK_COPIES ⋈ BOOK

Temp = σ_{Title='The Lost Tribe'}(BOOK) ⋈ BOOK_COPIES

Result = γ_{Branch_id; SUM(No_of_copies)→TotalCopies} ( Temp ⋈ LIBRARY_BRANCH )

π_{Branch_name, TotalCopies} ( Result ⋈ LIBRARY_BRANCH )

(c) Retrieve names of borrowers who do not have any books checked out.

RA (anti-join):

AllBorrowers = BORROWER

BorrowersWithLoans = π_{Card_no}( BOOK_LOANS )

Result = AllBorrowers − ( BORROWER ⋈_{BORROWER.Card_no = BOOK_LOANS.Card_no} BOOK_LOANS )

π_{Name}( Result )
(Or π_{Name}( BORROWER ⋈_{not exists BOOK_LOANS.Card_no = BORROWER.Card_no} ))

(d) For each book loaned from Sharpstown and whose Due_date = today, retrieve book title, borrower
name, borrower address.

RA (let Today be constant TODAY):

Loans = σ_{Branch_id = B.Branch_id ∧ Due_date = TODAY}(

BOOK_LOANS ⋈ LIBRARY_BRANCH B (σ_{Branch_name='Sharpstown'}(LIBRARY_BRANCH) AS B)

Res = π_{Title, BORROWER.Name, BORROWER.Address}(

Loans ⋈ BOOK ⋈ BORROWER

(e) For each branch, branch name and total number of books loaned out from that branch.

RA:

LoanCounts = γ_{Branch_id; COUNT(*)→NumLoans}( BOOK_LOANS )

Result = π_{Branch_name, NumLoans} ( LoanCounts ⋈ LIBRARY_BRANCH )

(f) Names, addresses, and number of books checked out for borrowers with >5 books checked out.

RA:

CountPerBorrower = γ_{Card_no; COUNT(*)→NumCheckedOut}( BOOK_LOANS )

Res = π_{BORROWER.Name, BORROWER.Address, NumCheckedOut} (

BORROWER ⋈ CountPerBorrower

Final = σ_{NumCheckedOut > 5}(Res)

(g) For each book authored (or coauthored) by Stephen King, retrieve the title and the number of copies
owned by branch 'Central'.

RA:

SK_Books = π_{Book_id}( σ_{Author_name='Stephen King'}(BOOK_AUTHORS) )

CentralBranch = π_{Branch_id}( σ_{Branch_name='Central'}(LIBRARY_BRANCH) )

Copies = BOOK_COPIES ⋈ CentralBranch

Res = π_{Title, No_of_copies} ( BOOK ⋈_{Book_id} ( SK_Books ⋈ BOOK_COPIES ⋈ LIBRARY_BRANCH ) )

-- aggregate if want total per book:

γ_{Book_id, Title; SUM(No_of_copies)→TotalCopies} ( BOOK ⋈ BOOK_COPIES ⋈
σ_{Branch_name='Central'}(LIBRARY_BRANCH) ⋈ BOOK_AUTHORS where Author_name='Stephen King' )

8.19 — Order-processing schema (Exercise 5.14)

Relations: CUSTOMER(Cust#, Cname, City)

ORDER(Order#, Odate, Cust#, Ord_amt)
ORDER_ITEM(Order#, Item#, Qty)
ITEM(Item#, Unit_price)
SHIPMENT(Order#, Warehouse#, Ship_date)
WAREHOUSE(Warehouse#, City)

(a) List Order# and Ship_date for orders shipped from Warehouse# = W2.

RA:

π_{Order#, Ship_date}( σ_{Warehouse#='W2'}(SHIPMENT) )

(b) Warehouse information from which customer named Jose Lopez was supplied (produce Order#,
Warehouse#).

RA:

CustID = π_{Cust#}( σ_{Cname='Jose Lopez'}(CUSTOMER) )

Orders = ORDER ⋈_{ORDER.Cust# = CustID.Cust#} CustID

Res = π_{Order#, Warehouse#} ( Orders ⋈_{Orders.Order# = SHIPMENT.Order#} SHIPMENT )

Simpler:

π_{O.Order#, S.Warehouse#}

( σ_{C.Cname='Jose Lopez'}(CUSTOMER) ⋈ CUSTOMER.Cust# = ORDER.Cust# ORDER O ⋈ O.Order# =

SHIPMENT.Order# SHIPMENT S )

(c) Produce listing Cname, No_of_orders, Avg_order_amt per customer.

RA:

CustOrders = γ_{Cust#, COUNT(Order#)→No_of_orders, AVG(Ord_amt)→Avg_order_amt}( ORDER )

Res = CustOrders ⋈ CUSTOMER -- to get Cname

π_{Cname, No_of_orders, Avg_order_amt}( Res ⋈ CUSTOMER )

(d) Orders that were not shipped within 30 days of ordering (Ship_date > Odate + 30).

RA (assuming date arithmetic supported conceptually):

LateShip = π_{Order#} ( σ_{Ship_date > Odate + 30} ( ORDER ⋈_{Order#.Order# = SHIPMENT.Order#}

SHIPMENT ) )
If an order is shipped multiple times (partial shipments) you might check MIN(Ship_date) per order.

(e) Order# for orders that were shipped from all warehouses that the company has in New York.

RA (division pattern):

NYWarehouses = π_{Warehouse#}( σ_{City='New York'}(WAREHOUSE) )

OrderWarehouses = π_{Order#, Warehouse#}( SHIPMENT )

OrdersAll = π_{Order#}( OrderWarehouses ÷ NYWarehouses )

8.20 — Salesperson trips schema (Exercise 5.15):

Relations: SALESPERSON(Ssn, Name, Start_year, Dept_no)

TRIP(Ssn, From_city, To_city, Departure_date, Return_date, Trip_id)
EXPENSE(Trip_id, Account#, Amount)

(a) Details of trips that exceeded $2,000 in expenses.

RA:

TripExpenses = γ_{Trip_id; SUM(Amount)→TotalExpense}( EXPENSE )

Res = TRIP ⋈_{TRIP.Trip_id = TripExpenses.Trip_id} σ_{TotalExpense > 2000}( TripExpenses )

-- project all TRIP attributes

π_{TRIP.*}( Res )

(b) Ssns of salespeople who took trips to Honolulu.

RA:

π_{Ssn}( σ_{To_city='Honolulu'}(TRIP) )

(c) Total trip expenses incurred by salesperson with SSN = '234-56-7890'.

RA:

TripsBySp = π_{Trip_id}( σ_{Ssn='234-56-7890'}(TRIP) )

Total = γ_{ ; SUM(Amount)→Total }( EXPENSE ⋈ TripsBySp )

Or

γ_{Ssn; SUM(Amount)} ( TRIP ⋈ EXPENSE ) and then σ_{Ssn='234-56-7890'}

8.21 — Student/course schema (Exercise 5.16)

Relations: STUDENT(Ssn, Name, Major, Bdate)

COURSE(Course#, Cname, Dept)
ENROLL(Ssn, Course#, Quarter, Grade)
BOOK_ADOPTION(Course#, Quarter, Book_isbn)
TEXT(Book_isbn, Book_title, Publisher, Author)

(a) Number of courses taken by all students named John Smith in Winter 2009 (Quarter = 'W09').

RA:

JS = π_{Ssn}( σ_{Name='John Smith'}(STUDENT) )

Res = γ_{Ssn; COUNT(Course#)→NumCourses}( σ_{Quarter='W09'}( ENROLL ⋈ JS ) )

-- If want names as well:

π_{Name, NumCourses}( Res ⋈ STUDENT )

(b) Textbooks (Course#, Book_isbn, Book_title) for CS courses that used > 2 books.

RA:

CScourses = π_{Course#}( σ_{Dept='CS'}(COURSE) )

Adopts = BOOK_ADOPTION ⋈ CScourses

Counts = γ_{Course#, COUNT(Book_isbn)→NumBooks}( Adopts )

Multi = σ_{NumBooks > 2}( Counts )

Res = π_{Course#, Book_isbn, Book_title} (

(BOOK_ADOPTION ⋈ TEXT) ⋈ Multi

(c) Departments that have all their adopted books published by 'Pearson Publishing'.

RA:

AllAdopts = π_{Dept, Book_isbn} ( COURSE ⋈ BOOK_ADOPTION ) -- course→dept

PearsonAdopts = π_{Dept, Book_isbn} ( COURSE ⋈ BOOK_ADOPTION ⋈ σ_{Publisher='Pearson

Publishing'}(TEXT) )

Res = π_{Dept} ( (AllAdopts ÷ (π_{Book_isbn}(AllAdopts))? ) ) -- conceptual:

Better: Dept s.t. set of Book_isbn for that dept ⊆ set of Book_isbn with Publisher='Pearson'

Use division-like check per dept:

For each dept D:

If π_{Book_isbn}( σ_{Dept=D}(AllAdopts) ) − π_{Book_isbn}( σ_{Dept=D}(PearsonAdopts) ) = ∅ then include D.

(Implementation: use grouping and checking counts: if count total adopted books = count adopted books
where publisher='Pearson'.)
8.22 — Table T1 and T2 (Figure 8.15)

T1 (P,Q,R):

(10, a, 5)

(15, b, 8)

(25, a, 6)

T2 (A,B,C):

(10, b, 6)

(25, c, 3)

(10, b, 5)

I’ll compute the operations you listed.

(a) T1 ⋈_{T1.P = T2.A} T2

Matches P=10 with T2 A=10 (two rows), and P=25 with A=25.

Result rows (attributes in order [P,Q,R,A,B,C]):

(10, a, 5, 10, b, 6)

(10, a, 5, 10, b, 5)

(25, a, 6, 25, c, 3)

(b) T1 ⋈_{T1.Q = T2.B} T2

Matches where Q = B: T1 Q values are a, b, a; T2 B values b, c, b. Matching pairs: T1 row (15,b,8) matches T2
rows (10,b,6) and (10,b,5).

Result:

(15, b, 8, 10, b, 6)

(15, b, 8, 10, b, 5)

(c) & (d) — (your list duplicated; I’ll assume you wanted natural join T1 ⋈ T2 if attributes aligned — but they
are different attribute names so natural join yields empty unless we rename. So skip duplicates.)

(e) T1 ∪ T2
Union is defined only for union-compatible relations. T1 and T2 have different schemas; direct UNION is not
defined. If you first rename columns to same names and align domains (e.g. treat A→P,B→Q,C→R and drop
mismatches), you could do (ρ_{P/A, Q/B, R/C}(T2)) ∪ T1 — but note data types: T1.Q has letters but T1.P
numeric etc. If we alias T2 to (P,Q,R) with types coerced, union rows would be:

After renaming T2 to (P,Q,R) (A→P,B→Q,C→R): rows become (10,b,6),(25,c,3),(10,b,5). Union with T1 rows
produces set:

(10,a,5)

(15,b,8)

(25,a,6)

(10,b,6)

(25,c,3)

(10,b,5)

(no duplicates removed across differing Q values).

But strictly speaking: UNION not allowed without making schemas compatible.

(f) T1 ⋈_{T1.P = T2.A AND T1.R = T2.C} T2

Matches both P=A and R=C: Check pairs:

• T1 (10,a,5) matches T2 (10,b,5) because P=10=A and R=5=C. Also matches T2 (10,b,6)? no (R 5 ≠ 6).

• T1 (25,a,6) vs T2 (25,c,3): R 6 ≠ 3 → no.

• T1 (15,b,8): no A=15 in T2 → no.

Result:

(10, a, 5, 10, b, 5)

8.23 — Car dealership (Exercise 5.17) — relations:

CAR(Serial_no, Model, Manufacturer, Price)

OPTION(Serial_no, Option_name, Price)
SALE(Salesperson_id, Serial_no, Date, Sale_price)
SALESPERSON(Salesperson_id, Name, Phone)

(a) For salesperson Jane Doe, list Serial#, Manufacturer, Sale_price for all cars she sold.

RA:
Jane = σ_{Name='Jane Doe'}(SALESPERSON)

SalesByJane = SALE ⋈_{SALE.Salesperson_id = Jane.Salesperson_id} Jane

Res = π_{Serial_no, Manufacturer, Sale_price} ( SalesByJane ⋈ CAR )

(b) Serial# and Model of cars that have no options.

RA:

CarsWithOptions = π_{Serial_no}( OPTION )

AllCars = CAR

Res = π_{Serial_no, Model}( AllCars − (AllCars ⋈_{AllCars.Serial_no = OPTION.Serial_no} OPTION) )

Equivalent:

Res = π_{Serial_no, Model}( CAR ) − π_{Serial_no, Model}( CAR ⋈ OPTION )

(c) Meaning of left outer join SALESPERSON ⟕ SALE (do not change order):

• A left outer join between SALESPERSON (left) and SALE (right) returns all SALESPERSON rows; for
salespersons with matching rows in SALE, it returns those combined rows; for salespersons with no
sales it returns the salesperson row with NULL in the sale columns.

• Example: If S03 (new salesperson) exists in SALESPERSON but has made no sales, SALESPERSON ⟕
SALE will contain an output row with S03 and NULL for Sale attributes. This is useful to list all
salespersons and their sales (if any).

(d) Write a RA query using selection and one set operation and explain.

Example RA:

(π_{Serial_no}( SALE )) − (π_{Serial_no}( OPTION ))

Explanation: Returns Serial numbers for cars that were sold but have no options (set difference between sold
cars and cars-with-options).

8.24 — Convert queries a,b,c,e,f,i,j of Exercise 8.16 into tuple calculus and domain calculus
You asked for seven queries from 8.16. I will give concise tuple calculus (TRC) and domain calculus (DRC) forms
for each. (I keep notation compact: tuple variables t, s, w, p, d, dep, prj etc.)

Recall 8.16 queries (a,b,c,e,f,i,j) — I restate each, then TRC and DRC.

Notation: EMP(e), WORKS_ON(w), PROJECT(p), DEPARTMENT(d), DEPENDENT(dep).

8.16(a) — names of employees in dept 5 who work >10 hours on ProductX.

TRC:

{ <e.Fname, e.Minit, e.Lname> |

EMP(e) ∧ e.Dno = 5 ∧ ∃w ( WORKS_ON(w) ∧ w.Essn = e.Ssn ∧ w.Hours > 10 ∧

∃p ( PROJECT(p) ∧ p.Pnumber = w.Pno ∧ p.Pname = 'ProductX' ) )

DRC: (domain variables: FN, MI, LN, SSN, DNO, PNO, H)

{ <FN,MI,LN> |

∃SSN, DNO ( EMP(SSN,FN,MI,LN, ..., DNO) ∧ DNO=5 ∧

∃PNO,H ( WORKS_ON(SSN,PNO,H) ∧ H>10 ∧

∃PNAME ( PROJECT(PNAME,PNO,...) ∧ PNAME='ProductX') ))

(Adapt attribute order to relation definitions.)

8.16(b) — employees who have a dependent with same first name as themselves.

TRC:

{ <e.Fname, e.Minit, e.Lname> |

EMP(e) ∧ ∃dep ( DEPENDENT(dep) ∧ dep.Essn = e.Ssn ∧ dep.Dependent_name = e.Fname )

DRC:

{ <FN,MI,LN> |

∃SSN ( EMP(SSN,FN,MI,LN,...) ∧

∃DNAME,BD,REL ( DEPENDENT(SSN,DNAME,...) ∧ DNAME = FN ) )

8.16(c) — names of employees directly supervised by 'Franklin Wong'.

TRC:

{ <e.Fname,e.Minit,e.Lname> |

EMP(e) ∧ ∃s ( EMP(s) ∧ s.Fname='Franklin' ∧ s.Lname='Wong' ∧ e.Super_ssn = s.Ssn )

}

DRC:

{ <FN,MI,LN> |

∃ESSN,SSN_S ( EMP(ESSN,FN,MI,LN, ..., Super_ssn) ∧

EMP(SSN_S,'Franklin',_, 'Wong',...,_) ∧ Super_ssn = SSN_S )

8.16(e) — employees who work on every project. (Division)

TRC:

{ <e.Fname,e.Minit,e.Lname> |

EMP(e) ∧ ∀p ( PROJECT(p) → ∃w ( WORKS_ON(w) ∧ w.Essn = e.Ssn ∧ w.Pno = p.Pnumber ) )

DRC:

{ <FN,MI,LN> |

∃SSN ( EMP(SSN,FN,MI,LN,...) ∧

∀PNO ( PROJECT(PNO,...) → ∃H ( WORKS_ON(SSN,PNO,H) ) ) )

8.16(f) — employees who do not work on any project.

TRC:

{ <e.Fname,e.Minit,e.Lname> |

EMP(e) ∧ ¬∃w ( WORKS_ON(w) ∧ w.Essn = e.Ssn )

DRC:

{ <FN,MI,LN> |

∃SSN ( EMP(SSN,FN,MI,LN,...) ∧ ¬∃PNO,H ( WORKS_ON(SSN,PNO,H) ) )

}
8.16(i) — names & addresses of employees who work on ≥1 project located in Houston but whose
department has no location in Houston.

TRC:

{ <e.Fname, e.Address> |

EMP(e) ∧ ∃w ∃p ( WORKS_ON(w) ∧ w.Essn = e.Ssn ∧ PROJECT(p) ∧ p.Pnumber = w.Pno ∧

p.Plocation='Houston' )

∧ ¬∃dl ( DEPT_LOCATIONS(dl) ∧ dl.Dnumber = e.Dno ∧ dl.Dlocation = 'Houston' )

DRC: similar with domain vars.

8.16(j) — last names of managers who have no dependents.

TRC:

{ <m.Lname> |

DEPARTMENT(d) ∧ m is EMP with m.Ssn = d.Mgr_ssn ∧ EMP(m) ∧ ¬∃dep ( DEPENDENT(dep) ∧ dep.Essn =

m.Ssn )

DRC: analogous.

8.25 — Convert 8.17 (airline RA queries) parts a–d into tuple and domain relational calculus
I’ll restate each and give TRC / DRC.

Let relations: FLIGHT(f), FLIGHT_LEG(fl), LEG_INSTANCE(li), AIRPORT(ap), FARE(fr).

8.17(a) — For each flight, list flight number, departure airport for first leg, arrival airport for last leg.

TRC:

{ <f.Flight_number, first.Departure_airport_code, last.Arrival_airport_code> |

FLIGHT(f) ∧

∃first ( FLIGHT_LEG(first) ∧ first.Flight_number = f.Flight_number ∧ first.Leg_number = 1 ) ∧

∃last ( FLIGHT_LEG(last) ∧ last.Flight_number = f.Flight_number ∧

 ∀x( FLIGHT_LEG(x) ∧ x.Flight_number = f.Flight_number → x.Leg_number ≤ last.Leg_number ) )

DRC: Replace tuple variables by domain variables (FlightNo, LegNo1, DepA, ...); quantifiers similarly express
existence and max leg number.

8.17(b) — Flight numbers & weekdays of flights or legs that depart iah and arrive lax.

TRC:

{ <fl.Flight_number, f.Weekdays> |

FLIGHT(f) ∧ FLIGHT_LEG(fl) ∧ fl.Flight_number = f.Flight_number ∧

fl.Departure_airport_code = 'iah' ∧ fl.Arrival_airport_code = 'lax' }

DRC: identical structure with domain vars.

8.17(c) — flight number, dep/arr airport and scheduled times and weekdays for legs departing from any
airport in Houston and arriving to any in Los Angeles.

TRC:

{ <fl.Flight_number, fl.Departure_airport_code, fl.Scheduled_departure_time, fl.Arrival_airport_code,

fl.Scheduled_arrival_time, f.Weekdays> |

FLIGHT_LEG(fl) ∧ FLIGHT(f) ∧ fl.Flight_number = f.Flight_number ∧

∃a1 ( AIRPORT(a1) ∧ a1.Airport_code = fl.Departure_airport_code ∧ a1.City = 'Houston' ) ∧

∃a2 ( AIRPORT(a2) ∧ a2.Airport_code = fl.Arrival_airport_code ∧ a2.City = 'Los Angeles' )

8.17(d) — all fare information for flight co197.

TRC:

{ <fr.*> | FARE(fr) ∧ fr.Flight_number = 'co197' }

8.17(e) — number of available seats for flight co197 on 2009-10-09.

TRC:

{ <li.Flight_number, li.Leg_number, li.Date, li.Number_of_available_seats> |

LEG_INSTANCE(li) ∧ li.Flight_number = 'co197' ∧ li.Date = '2009-10-09'

}

(If aggregate total across legs required, use grouping/aggregation; otherwise list per leg.)

8.26. Specify queries c, d, and f of Exercise 8.18 in both tuple and domain relational calculus.

Recall the relations (from 8.18 / your library schema):

• BOOK(Book_id, Title, Publisher_name)

• BOOK_COPIES(Book_id, Branch_id, No_of_copies)

• BOOK_LOANS(Book_id, Branch_id, Card_no, Date_out, Due_date)

• LIBRARY_BRANCH(Branch_id, Branch_name, Address)

• BORROWER(Card_no, Name, Address, Phone)

We’ll use tuple variables b, bc, bl, br, bo.

(c) Borrowers who do NOT have any books checked out.

Tuple relational calculus (TRC):

{ <bo.Name> |

BORROWER(bo) ∧ ¬∃bl ( BOOK_LOANS(bl) ∧ bl.Card_no = bo.Card_no )

Domain relational calculus (DRC) — domain vars Card, Name, Addr, Phone:

{ <Name> |

∃Card,Addr,Phone ( BORROWER(Card, Name, Addr, Phone) ∧ ¬∃BID,Br,DO,DD (

BOOK_LOANS(BID,Br,Card,DO,DD) ) )

(d) For each book loaned from Sharpstown and whose Due_date = TODAY, retrieve Title, borrower Name,
borrower Address.

Let constant TODAY be given.

TRC:

{ <book.Title, bo.Name, bo.Address> |

BOOK(book) ∧ BORROWER(bo) ∧ BOOK_LOANS(bl) ∧ LIBRARY_BRANCH(br)

∧ br.Branch_name = 'Sharpstown'

∧ bl.Branch_id = br.Branch_id
 ∧ bl.Book_id = book.Book_id

∧ bl.Card_no = bo.Card_no

∧ bl.Due_date = TODAY

DRC (domain vars):

{ <Title, BName, BAddr> |

∃Book_id,Pub,BrId,Card,DO,DD,BrName,BrAddr (

BOOK(Book_id, Title, Pub)

∧ LIBRARY_BRANCH(BrId, 'Sharpstown', BrAddr)

∧ BOOK_LOANS(Book_id, BrId, Card, DO, DD)

∧ BORROWER(Card, BName, BAddr, _)

∧ DD = TODAY

(f) For borrowers who have more than 5 books checked out, retrieve Name, Address, and number-of-books.

TRC (use counting expressed as existential of distinct loan tuples — standard safe way):

{ <bo.Name, bo.Address, n> |

BORROWER(bo) ∧

∃bl1,bl2,bl3,bl4,bl5,bl6 (

BOOK_LOANS(bl1) ∧ BOOK_LOANS(bl2) ∧ BOOK_LOANS(bl3) ∧ BOOK_LOANS(bl4) ∧ BOOK_LOANS(bl5) ∧

BOOK_LOANS(bl6)

∧ bl1.Card_no = bo.Card_no ∧ bl2.Card_no = bo.Card_no ∧ bl3.Card_no = bo.Card_no

∧ bl4.Card_no = bo.Card_no ∧ bl5.Card_no = bo.Card_no ∧ bl6.Card_no = bo.Card_no

∧ bl1.Book_id ≠ bl2.Book_id ∧ bl1.Book_id ≠ bl3.Book_id ∧ ... (all pairwise distinct book-instance identities)

∧ n = 6 OR n = (actual count) -- notionally n is the count; TRC is verbose for exact aggregate

}
(Practical note: expressing exact counts in pure TRC is cumbersome; you normally extend calculus with
aggregate operators or use a counting construct. The TRC above shows the “>5” test by proving existence of 6
distinct loan tuples.)

DRC (conceptual with aggregate):

{ <Name, Addr, Num> |

∃Card ( BORROWER(Card, Name, Addr, _) ∧ Num = COUNT( {L | BOOK_LOANS(L.Book_id, L.Branch_id, Card,

L.Date_out, L.Due_date) } ) ∧ Num > 5 )

(Again: standard DRC does not support COUNT; this uses a counting extension.)

Note: Pure TRC/DRC cannot express aggregates compactly without extensions — the usual approach is to
either exhibit existence of k distinct tuples (as above) or to assume a counting/aggregate extension.

8.27. In a TRC query with n tuple variables, what is the typical minimum number of join conditions? Why?
Effect of fewer join conditions?

Answer (short):

• Typical minimum: n − 1 join conditions (assuming you want a single connected join of n relations).
Reason: To connect n relations into one connected component (a join graph) you need at least n−1
edges (join conditions) — think of a tree connecting n nodes.

• Effect of fewer join conditions: If you supply fewer than n−1 join conditions the joined tuples may not
be fully connected — you get Cartesian product(s) between components, producing much larger result
sets and usually incorrect or semantically meaningless results. In short: missing join conditions →
unintended cartesian products/orphan rows and big performance cost.

8.28. Rewrite DRC queries that followed Q0 in Section 8.7 in abbreviated notation (Q0A style)

I don’t have the text of Section 8.7 or the specific Q0 queries in front of me. Please paste the original queries
from Section 8.7 (or allow me to access that page) and I will rewrite them in abbreviated notation (minimizing
domain variables and using constants).

(If you want, paste the small block of example queries and I’ll do the rewrite immediately.)

8.29. Tuple relational calculus expression for the “works on at least those projects that 123456789 works on”
query
Problem restatement: Return SSNs e.Ssn of employees e such that for every project x on which employee
123456789 works, e also works on x. Using the equivalence rules provided: (∀x)(P→Q) ≡ ¬∃x (P ∧ ¬Q) and (IF P
THEN Q) ≡ (¬P OR Q).

Let W(t) denote WORKS_ON(t) tuples with attributes (Essn,Pno,Hours). Let PROJECT(x) have x.Pnumber.

TRC (direct):

{ <e.Ssn> |

EMPLOYEE(e) ∧ ¬∃x (

PROJECT(x) ∧

( ∃w1 ( WORKS_ON(w1) ∧ w1.Essn = '123456789' ∧ w1.Pno = x.Pnumber ) )

∧ ¬∃w2 ( WORKS_ON(w2) ∧ w2.Essn = e.Ssn ∧ w2.Pno = x.Pnumber )

Explanation: There does not exist a project x such that 123456789 works on x but e does not — i.e. e works on
at least all projects 123456789 does.

(You can rewrite the inner condition using the given equivalences; I used the ¬∃ form.)

8.30. Specify relational-algebra operations in both TRC and DRC

For each I give short tuple-calculus and domain-calculus forms. Notation: relation R(A,B,C) fields named A,B,C;
S(C,D,E) etc.

(a) σ_{A = C}( R(A,B,C) ) — selection where attribute A equals attribute C in same tuple.

TRC:

{ r | R(r) ∧ r.A = r.C }

DRC:

{ <a,b,c> | R(a,b,c) ∧ a = c }

(b) π_{<A,B>}( R(A,B,C) ) — projection.

TRC:

{ <r.A, r.B> | R(r) }

DRC:

{ <a,b> | ∃c ( R(a,b,c) ) }
(c) Cartesian/product join R(A,B,C) ⋈ S(C,D,E) (theta/equi on C) — (natural-like join on C).

TRC:

{ <r.A, r.B, r.C, s.D, s.E> |

R(r) ∧ S(s) ∧ r.C = s.C

DRC:

{ <a,b,c,d,e> | R(a,b,c) ∧ S(c,d,e) }

(d) R(A,B,C) ∪ S(A,B,C) (union; schema-compatible).

TRC:

{ t | R(t) ∨ S(t) } -- t is a tuple with attributes (A,B,C)

DRC:

{ <a,b,c> | R(a,b,c) ∨ S(a,b,c) }

(e) R ∩ S (intersection)

TRC:

{ t | R(t) ∧ S(t) }

DRC:

{ <a,b,c> | R(a,b,c) ∧ S(a,b,c) }

(f) R = S (set equality: same tuples)

TRC: (both subset directions)

{ true | (∀t ( R(t) → S(t) )) ∧ (∀t ( S(t) → R(t) )) }

(When asking whether equality holds you'd use boolean formula; to return tuples, it's either R or S.)

DRC: analogous with domain variables.

(g) Cartesian product R(A,B,C) × S(D,E,F)

TRC:
{ <r.A, r.B, r.C, s.D, s.E, s.F> | R(r) ∧ S(s) }

DRC:

{ <a,b,c,d,e,f> | R(a,b,c) ∧ S(d,e,f) }

(h) Division R(A,B) ÷ S(A) (R has attributes A,B; S has A). Return B values that are associated with all A in S.
(Alternate form in your prompt: R(A,B) ÷ S(A))

TRC:

{ <b> |

∃r ( R(r) ∧ r.B = b ∧

¬∃s ( S(s) ∧ ¬∃r2 ( R(r2) ∧ r2.B = b ∧ r2.A = s.A ) )

(Conceptual: for b, for every a in S there exists r2 in R with (a,b).)

DRC:

{ <b> |

∀a ( S(a) → ∃ ( R(a,b) ) )

(Using a compact DRC style where R(a,b) is predicate.)

8.31. Suggest extensions to relational calculus to express: (a) aggregates & grouping; (b) outer joins; (c)
recursive closure queries.

Short suggestions:

• (a) Aggregates & grouping:

o Extend calculus with aggregate operators (COUNT, SUM, AVG, MIN, MAX) and a GROUP BY
construct. Syntax example in DRC: Num = COUNT({ t | R(t) ∧ t.attr = value }). Alternatively add
aggregate functions COUNT_GRP(group-attributes, expr) and allow HAVING-like predicates.

o Semantically this requires second-order constructs (quantifying over sets) or built-in aggregate
primitives.

• (b) OUTER JOIN:

o Add optional existence or nullable semantics: allow existential patterns where missing matches
produce tuples with NULL values. In calculus, represent as (∃s S(s) ∧ cond) ∨ (¬∃s S(s) ∧ cond2)
 and allow NULL placeholders; or add an OUTER_JOIN(R,S,on) operator returning tuples where
attributes from non-matching side are NULL.

• (c) Recursive closure (transitive closure):

o Add a fixed-point / recursion operator, e.g. TC(R, startAttr, endAttr) or WITH RECURSIVE style.
Formally include least-fixed-point operator lfp(F) to compute closure of a binary relation under
transitive composition. This is standard: add TC_x_y(R) returning reachable pairs.

8.32. Nested queries on Figure 5.5 (COMPANY) — specify using nested queries + show results on Figure 5.6.

These three are the same as earlier nested queries (we answered them before); I'll give a concise nested-RA
style and the result (we already computed using Figure 5.6).

(a) Names of employees who work in the department that has the employee with highest salary.

Relational algebra using nested query:

DeptOfMax = π_{Dno} ( σ_{Salary = MAX(π_Salary(EMPLOYEE))}(EMPLOYEE) )

Result = π_{Fname,Minit,Lname}( σ_{Dno ∈ DeptOfMax} (EMPLOYEE) )

Result (Figure 5.6): Highest salary = 55000 (James Borg), Dept = 1 → employees in dept 1: James E Borg.

(b) Names of employees whose supervisor’s supervisor has Ssn = '888665555'.

RA nested:

SupSup = π_{Ssn} ( σ_{Super_ssn = '888665555'}( EMPLOYEE ) ) -- supervisors whose supervisor is 888665555

Result = π_{E.Fname,E.Minit,E.Lname}( EMPLOYEE E ⋈_{E.Super_ssn = Sup.Ssn} Sup )

Result: John B Smith, Ramesh K Narayan, Joyce A English.

(c) Employees who make at least $10,000 more than the employee with the least salary.

RA nested:

MinSal = MIN( π_{Salary}(EMPLOYEE) )

Result = π_{Fname,Minit,Lname}( σ_{Salary >= MinSal + 10000}(EMPLOYEE) )

Figure 5.6: min=25000 → threshold 35000 → employees: Franklin T Wong, Jennifer S Wallace, Ramesh K
Narayan, James E Borg.

8.33. Logical conclusions — true/false

State whether the following are true or false:

a. NOT (P(x) OR Q(x)) → (NOT P(x) AND NOT Q(x))

• This is true. By De Morgan: ¬(P∨Q) is logically equivalent to ¬P ∧ ¬Q. So implication holds both ways.

b. NOT (∃x) (P(x)) → ∀ x (NOT (P(x)))

• This is true. ¬∃x P(x) is logically equivalent to ∀x ¬P(x).

c. (∃x) (P(x)) → ∀ x (P(x))

• This is false. Existence of some x satisfying P does not imply that P holds for all x.