Chapter 1:

Review questions:
1.1 Definitions of Key Database Terms
1. Data: Raw facts and figures with no context on their own, which can
be processed to gain meaningful information.
2. Database: An organized collection of data that is stored and
accessed electronically, often structured in tables for easy querying
and updating.
3. DBMS (Database Management System): Software that manages
and facilitates interactions with databases, allowing users to create,
read, update, and delete data.
4. Database System: A combination of the DBMS, the database itself,
and the applications that interact with the database.
5. Database Catalog: A set of metadata that describes the structure
and definitions of objects (e.g., tables, indexes) within the database.
6. Program-Data Independence: The separation of data from
application logic, allowing changes in data structure without altering
the programs that use the data.
7. User View: A subset of the database tailored to meet the specific
needs of a user or group of users.
8. DBA (Database Administrator): The person responsible for
managing and maintaining the database system, including tasks like
backup, recovery, and access control.
9. End User: The individuals or applications that interact with the
database for retrieving, entering, or modifying data.
10. Canned Transaction: Predefined, repetitive queries or
transactions designed for standard operations, often used by non-
technical end users.
11. Deductive Database System: A database system with
capabilities to deduce or infer information from the stored data,
usually based on logic programming.
12. Persistent Object: Data objects that retain their state even
after the application that created them has ended, typically stored
in a database.
13. Meta-data: Data that describes other data, such as
information about data structure, format, and constraints.
 14. Transaction-Processing Application: Applications that
involve multiple operations on a database and ensure data integrity
and consistency even in concurrent usage.
1.2 Main Types of Actions Involving Databases
1. Defining the Database: Establishing the data structure, format,
and constraints (schema definition) that the database will follow.
2. Constructing the Database: Populating the database with initial
data to enable immediate use.
3. Manipulating the Database: Operations such as querying,
updating, and deleting data, allowing users to work with stored
information.
4. Sharing the Database: Allowing multiple users and applications to
access the data concurrently, requiring mechanisms to manage
transactions and ensure data integrity.
1.3 Characteristics of the Database Approach vs. Traditional File
Systems
The database approach organizes data independently from application
programs, which allows for better consistency, reduced redundancy, and
easier data sharing. In contrast, traditional file systems store data in files
within specific programs, making it harder to maintain consistency, share
data across applications, and manage data dependencies. The database
approach also offers program-data independence, multiple user views,
and higher security.
1.4 Responsibilities of the DBA and Database Designers
 DBA: Manages overall database maintenance, performance tuning,
backup, recovery, and ensuring data security and access control.
 Database Designers: Responsible for creating the data model,
structuring the schema, and ensuring efficient data storage,
integrity, and usability.
1.5 Types of Database End Users and Their Activities
1. Casual Users: Occasionally query the database, often using ad-hoc
queries.
2. Naive/Parametric Users: Rely on pre-built applications to perform
repetitive tasks, like data entry or transactions.
3. Sophisticated Users: Use complex querying, often analysts or
developers who understand database internals.
4. Standalone Users: Maintain personal databases and perform
regular tasks using packaged applications.
1.6 Capabilities Provided by a DBMS
A DBMS should offer:
 Data Definition and Storage: Defining, creating, and storing
structured data.
 Data Manipulation and Retrieval: Efficient querying, updating,
and modification capabilities.
 Transaction Management: Ensuring reliable, consistent, and
atomic processing of transactions.
 Concurrency Control: Managing simultaneous data access to
prevent conflicts.
 Backup and Recovery: Protecting data integrity and restoring
databases in case of failure.
 Security Management: Controlling access based on user roles and
permissions.
1.7 Differences Between Database Systems and Information
Retrieval Systems
Database systems are structured for transaction processing, with strict
data consistency, integrity, and structured querying (e.g., SQL). They
typically handle structured data with defined schemas. Information
retrieval systems, however, focus on retrieving relevant data from
unstructured sources, such as documents or multimedia, often using
keyword matching or search indexes instead of structured querying.
Identify some informal queries and update operations that you
would expect to apply to the database shown in Figure 1.2.
Example Informal Queries:
1. List the names of all students majoring in Computer Science.
o Query: Which students have "CS" as their major?
 2. Retrieve the course name and credit hours for all courses
taught in the Computer Science department.
o Query: Show all courses under the "CS" department along with
their credit hours.
3. Find the grades of student Smith in the Fall 2008 semester.
o Query: What are the grades of student Smith for courses he
took in Fall 2008?
4. List all the prerequisite courses for course CS3380.
o Query: What are the prerequisite courses required for
CS3380?
5. Retrieve the instructor's name for all sections offered in Fall
2008.
o Query: Which instructors are teaching in Fall 2008, and what
courses are they teaching?
6. Show the list of all students enrolled in the section of the
"Discrete Mathematics" course taught in Fall 2007.
o Query: Which students are enrolled in section 85 of the
MATH2410 course in Fall 2007?
Example Update Operations:
1. Change the major of student Brown to Mathematics.
o Update: Modify the major of Brown from "CS" to "MATH."
2. Add a new course "Algorithms" (course number CS4400, 4
credit hours) to the Computer Science department.
o Update: Insert a new record in the COURSE table for CS4400
with "Algorithms" as the course name and 4 credit hours
under the CS department.
3. Update the grade of student Brown in the section of "Data
Structures" from B to A.
o Update: Modify Brown's grade in section 102 from B to A in
the GRADE_REPORT table.
4. Remove student Smith from the section of "Database"
(section 135).
o Update: Delete Smith's enrollment (Student_number = 17)
from section 135 in the GRADE_REPORT table.
 5. Add a new section for the course "Intro to Computer
Science" (course number CS1310) for Spring 2009 with
instructor Johnson.
o Update: Insert a new section record in the SECTION table with
a new identifier, for course CS1310 in Spring 2009, taught by
Johnson.
What is the difference between controlled and uncontrolled
redundancy? Illustrate with examples.
- Uncontrolled Redundancy:
Uncontrolled redundancy occurs when the same data is duplicated across
multiple places without proper management. This often leads to
inconsistencies, data anomalies, and wasted storage space.
Changes to one copy of the data may not be reflected in other copies,
causing discrepancies.
 Example of Uncontrolled Redundancy: Suppose you have a
university database where student contact details are stored in
multiple places:
o In a student information file (e.g., name, phone number,
address).
o In a financial aid file.
o In an emergency contact file.
If a student changes their address, but the update is only applied to the
student information file and not to the financial aid or emergency contact
files, the database will have inconsistent and outdated information. This
leads to potential errors when contacting the student for financial or
emergency purposes.
- Controlled Redundancy:
Controlled redundancy is intentional and managed within a database
system to improve performance and ensure data consistency. It’s typically
done by having a primary source of truth for data, such as storing data in
one table and referencing it from other tables through foreign keys. The
DBMS ensures consistency between these tables by enforcing integrity
constraints.
 Example of Controlled Redundancy: In a relational database,
data normalization is used to reduce redundancy, but some
controlled redundancy can exist for performance reasons. For
instance, consider the following structure in a university database:
o A Student table stores each student's personal information.
 o A Grade_Report table stores grades along with a student
number that references the Student table (foreign key).
Here, the student number is duplicated in the Grade_Report table for
quick lookup, but the actual personal details of the student are only stored
once in the Student table. If a student's personal information is updated,
the change is made in one place, ensuring consistency. The redundancy is
controlled through foreign key relationships and ensures integrity
between the tables.
Key Differences:
 Uncontrolled Redundancy: Leads to data inconsistency, wasted
space, and update anomalies. Data changes in one place may not
reflect in others.
 Controlled Redundancy: Intentional, managed, and helps improve
efficiency without leading to data inconsistency. Referential integrity
is maintained by the DBMS.
Summary:
In a well-designed database, controlled redundancy is often necessary
for efficient querying and maintaining relationships between entities,
while uncontrolled redundancy is typically a sign of poor database
design and can lead to problems like data inconsistencies and anomalies.
Specify all the relationships among the records of the database
shown in Figure 1.2.
The database in Figure 1.2 consists of five entities or tables: STUDENT,
COURSE, SECTION, GRADE_REPORT, and PREREQUISITE. The
relationships among the records in this database can be described as
follows:
1. STUDENT – GRADE_REPORT Relationship:
 Type: One-to-Many (1
)
 Description: Each student can enroll in multiple sections (through
Section_identifier in the GRADE_REPORT table), but each entry in
the GRADE_REPORT table corresponds to only one student.
 Relationship: The Student_number field in the GRADE_REPORT
table is a foreign key that references the Student_number field in
the STUDENT table.
 Explanation: Each student can have multiple grade records (for
different sections) in the GRADE_REPORT table. However, each
grade report is associated with exactly one student.
2. COURSE – SECTION Relationship:
 Type: One-to-Many (1
)
 Description: A course can have multiple sections, but each section
belongs to one course.
 Relationship: The Course_number field in the SECTION table is a
foreign key that references the Course_number field in the
COURSE table.
 Explanation: A course such as "Discrete Mathematics" (MATH2410)
can be offered in different semesters and years, taught by different
instructors. Each section is a unique instance of a course being
taught.
3. SECTION – GRADE_REPORT Relationship:
 Type: One-to-Many (1
)
 Description: A section can have multiple students enrolled, but
each grade report entry refers to only one section.
 Relationship: The Section_identifier field in the GRADE_REPORT
table is a foreign key that references the Section_identifier field in
the SECTION table.
 Explanation: Each section can have many students enrolled in it,
and their grades are stored in the GRADE_REPORT table. However,
each grade record is associated with a single section.
4. COURSE – PREREQUISITE Relationship:
 Type: One-to-Many (1
)
 Description: A course can have multiple prerequisites, but each
prerequisite is associated with one course.
 Relationship: The Course_number field in the PREREQUISITE
table is a foreign key that references the Course_number field in
the COURSE table. Similarly, the Prerequisite_number field also
references the Course_number field in the COURSE table.
 Explanation: The PREREQUISITE table records the relationships
between courses and their prerequisites. For example, CS3380
(Database) has two prerequisites: CS3320 (Data Structures)
and MATH2410 (Discrete Mathematics). Each course can have
multiple prerequisite courses.
Summary of Relationships:
1. STUDENT – GRADE_REPORT: One student can have many grade
reports, but each grade report is for one student.
2. COURSE – SECTION: One course can have many sections, but each
section belongs to one course.
3. SECTION – GRADE_REPORT: One section can have many grade
reports (representing students' grades), but each grade report
corresponds to one section.
4. COURSE – PREREQUISITE: One course can have multiple
prerequisite courses, but each prerequisite is linked to one course.
These relationships define how the tables are connected and how data
flows across the database.
Give some additional views that may be needed by other user
groups for the database shown in Figure 1.2.
1. Instructor View:
Purpose: Instructors may need to view only the information relevant to
the courses they are teaching and the students enrolled in their sections.
 View:
o Course names, section identifiers, semester, year, and a list of
students enrolled in each section (with their grades).
o Instructor details are relevant only to the sections they are
teaching

2. Student View:

Purpose: Students need a view that allows them to see the courses they are enrolled in, the
sections they are taking, and their corresponding grades.

 View:
o Course name, section identifier, semester, year, and grade.
o The view will be filtered by the student’s ID (or student number).

3. Department Administrator View:

Purpose: Department administrators might want to manage courses, view enrollment

numbers, and check which instructors are assigned to each section.

 View:
o Course name, department, section identifier, semester, year, and instructor name.
Additionally, a count of students enrolled in each section can be provided.
4. Academic Advisor View:

Purpose: Academic advisors need a view of the courses a student has completed, the grades
they've received, and whether they've met the prerequisites for advanced courses.

 View:
o Student name, course name, section identifier, semester, year, grade, and
prerequisites for each course.

5. Registrar View:

Purpose: The registrar office needs to maintain records of student enrollments, courses
offered, and the grades students have received. This view would help in generating transcripts
and other academic records.

 View:
o Student name, course name, section identifier, semester, year, and final grades

6. Course Planning View:

Purpose: Academic planners or curriculum designers need a view to assess course offerings
and prerequisites to ensure that students are meeting the required course sequences.

 View:
o Course names, department, prerequisites, and the number of sections offered

Summary of User Views:

 Instructor View: Course sections, students enrolled, and their grades.

 Student View: Courses and sections the student is enrolled in, along with their grades.
 Department Administrator View: Course offerings, sections, enrollment, and instructors.
 Academic Advisor View: Student’s completed courses, grades, and prerequisites for future
courses.
 Registrar View: Complete academic records including courses, sections, and grades for all
students.
 Course Planning View: Course offerings, prerequisites, and number of sections offered.

Each of these views tailors the relevant data from the database to specific user needs while
ensuring users only access the data necessary for their roles.

Cite some examples of integrity constraints that you think can

apply to the database shown in Figure 1.2.
1. Primary Key Constraints:
Primary keys ensure that each record in a table is unique and not null.
 STUDENT Table:
o Constraint: Student_number must be unique and not null.
 o Example: Each student must have a unique Student_number,
so two students cannot have the same Student_number.
 COURSE Table:
o Constraint: Course_number must be unique and not null.
o Example: Every course must have a unique Course_number,
so there can't be two courses with the same number.
 SECTION Table:
o Constraint: Section_identifier must be unique and not null.
o Example: Each section of a course must have a unique
Section_identifier.
 GRADE_REPORT Table:
o Constraint: A composite primary key (Student_number,
Section_identifier) to ensure uniqueness of each grade entry.
o Example: Each student can be associated with a unique
section, but a student cannot have two grades for the same
section.
2. Foreign Key Constraints:
Foreign keys ensure that a record in one table must reference an existing
record in another table, enforcing referential integrity.
 SECTION – COURSE Relationship:
o Constraint: Course_number in the SECTION table must exist
in the COURSE table.
o Example: Each section must be linked to a valid course.
 GRADE_REPORT – STUDENT Relationship:
o Constraint: Student_number in the GRADE_REPORT table
must exist in the STUDENT table.
o Example: Every grade report must refer to a valid student.
 GRADE_REPORT – SECTION Relationship:
o Constraint: Section_identifier in the GRADE_REPORT table
must exist in the SECTION table.
o Example: Every grade report must refer to a valid section.
Give examples of systems in which it may make sense to use
traditional file processing instead of a database approach.
1. Simple, Small-scale Applications:
For small applications with limited data, where the overhead of setting up
and maintaining a database is unnecessary, file processing can be more
efficient.
 Example:
o Personal Contact Manager: A simple contact manager that
stores names, phone numbers, and addresses in a CSV or text
file. If only a handful of records are managed, the complexity
of a DBMS is overkill.
o Why: The data is minimal, and the operations (like adding,
editing, or deleting contacts) are straightforward. The
application would not benefit from complex features like query
optimization, indexing, or concurrency control.
2. Applications with Minimal Data Volume and Transaction Needs:
Applications that handle very small volumes of data and involve few
updates or queries can rely on traditional file systems for data storage.
 Example:
o Configuration Files for Software: Many software
applications store configuration settings in simple files
(like .ini or .conf files). These files contain parameters and
preferences, and they are only read and written infrequently.
o Why: Storing configuration in a database would add
unnecessary complexity. Reading and writing from a flat file is
efficient and simple for this purpose.
3. Systems with Fixed Data Structures:
If the data structure is fixed and well-known, and the system is unlikely to
undergo changes in how the data is stored or processed, file processing
may be adequate.
 Example:
o Embedded Systems: Many embedded systems (such as
those in consumer electronics, automotive controls, or
medical devices) store fixed-structure data (e.g., log files or
system parameters) in text or binary files.
o Why: These systems have very specific, predictable data
requirements and may not need the flexibility or overhead of
a database. File I/O is simpler and uses fewer resources in
constrained environments.
4. Single-user Applications:
In single-user environments where there is no need for multi-user access
or concurrent modifications, file systems can be simpler and more
appropriate.
 Example:
o Standalone Desktop Applications: Applications like a
simple to-do list manager or a personal finance tracker, where
only one user accesses the data at a time, might store data in
local files.
o Why: Since there's no need for concurrency control,
transaction management, or complex querying, a traditional
file-based approach can suffice.
5. Applications with Sequential Data Access:
For systems that primarily perform sequential access to data rather than
random access, traditional file systems can be more efficient.
 Example:
o Logging Systems: Systems that maintain logs (e.g., server
log files, audit trails) often append data sequentially. A text-
based log file or binary log is easy to implement and efficient
for these needs.
o Why: The data is mostly written sequentially, and there’s
typically no need for complex querying or relational
management. The simplicity of file processing is well-suited
for this task.
6. Temporary Data Storage:
If data needs to be stored temporarily, such as in buffer files or
intermediate storage that will not persist for long periods, file-based
storage is often more practical than setting up a database.
 Example:
o Temporary File Caching: Web browsers and operating
systems use file-based caches to store temporary data. These
are often written to disk for efficiency, but there is no need for
structured relational data management.
o Why: The data is transient, and performance is a priority. A
database system would introduce unnecessary complexity for
this temporary storage.
7. Systems with Performance Constraints:
In certain real-time or performance-critical applications where the system
needs to operate with minimal overhead, file processing can be more
efficient than a database system.
 Example:
o Real-time Systems: A flight control system or industrial
automation system that logs system metrics or events in real-
time may use file-based storage.
o Why: File processing can be faster and more predictable in
such environments, where the deterministic performance is
critical and the complexity of a DBMS might introduce latency.
8. Highly Specialized or Proprietary Systems:
In some cases, specialized systems may use file processing because the
nature of the data or the application is highly specific, making a database
unnecessary or even impractical.
 Example:
o Video Games: Some video games store player progress,
settings, or game world data in proprietary file formats (e.g.,
save files). The data structures are often tailored to the game
engine’s specific requirements.
o Why: Game data structures may be optimized for fast loading
and saving, and using a file-based system is often more
efficient than general-purpose database systems.
9. Legacy Systems:
Older systems that were developed before modern databases were widely
used may still rely on traditional file processing. Migrating such systems to
databases might not be worth the effort or cost.
 Example:
o Legacy Payroll Systems: Some older payroll systems still
use flat files or fixed-format text files to store employee
records and payroll information.
o Why: These systems were developed before relational
databases were prevalent, and they continue to work with flat
files. Rebuilding the system using a DBMS may not provide
enough benefit to justify the transition cost.
Summary:
In each of these cases, traditional file processing systems are favored due
to simplicity, lower overhead, or the nature of the application’s data
requirements. While databases offer significant advantages in terms of
data integrity, concurrency control, and flexibility, these benefits may not
be needed for small, single-user, or simple systems, or where
performance and resource constraints are critical.
Consider Figure 1.2. Selected Bibliography 29
a. If the name of the ‘CS’ (Computer Science) Department
changes to ‘CSSE’ (Computer Science and Software Engineering)
Department and the cor responding prefix for the course number
also changes, identify the col umns 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?
a. Identifying Columns that Need to Be Updated:
If the Computer Science (CS) department changes its name to
Computer Science and Software Engineering (CSSE) and the
corresponding prefix for the course numbers changes from CS to CSSE,
we would need to update the following columns in the database:
1. COURSE Table:
o Course_number: All courses with the prefix CS (e.g.,
CS1310, CS3320, CS3380) would need to be updated to CSSE
(e.g., CSSE1310, CSSE3320, CSSE3380).
o Department: The department value for the Computer
Science courses, currently listed as CS, would need to be
updated to CSSE.
2. SECTION Table:
o Course_number: All sections that reference courses with the
CS prefix would need to be updated to the new CSSE prefix.
3. PREREQUISITE Table:
o Course_number: Any course numbers with the CS prefix
would need to be updated to reflect the new CSSE prefix.
o Prerequisite_number: Similarly, any prerequisite courses
with the CS prefix would need to be updated to reflect the
new CSSE prefix.
In summary, these columns would require updates:
 COURSE Table: Course_number, Department
 SECTION Table: Course_number
 PREREQUISITE Table: Course_number, Prerequisite_number
b. Restructuring the Tables to Minimize Updates:
To reduce the number of columns that need to be updated in case of a
department or course prefix change, we can restructure the tables so that
the department and course prefix are stored separately. This way, only
the department name or course prefix needs to be updated in one place.
Proposed Restructuring:
1. COURSE Table:
o Split the Course_number column into two separate columns:
Course_prefix and Course_code.
o The Course_prefix column will store the department prefix
(e.g., CS, CSSE), and the Course_code column will store the
numeric part of the course number (e.g., 1310, 3320).
o The Department column remains, but it only needs to be
updated in one place when the department name changes.
Restructured COURSE Table:
Course_pr Course_c Credit_ho Departm
Course_name
efix ode urs ent

Intro to Computer
CS 1310 4 CS
Science

Data Structures CS 3320 4 CS

Discrete
MATH 2410 3 MATH
Mathematics

Database CS 3380 3 CS
2. SECTION Table:
o Add a Course_prefix column to store the department prefix
separately from the course code.
o This way, only the prefix needs to be updated when the
department changes.
Restructured SECTION Table:
Section_ident Course_pr Course_c Semes Yea Instruct
ifier efix ode ter r or

85 MATH 2410 Fall 07 King

Anderso
92 CS 1310 Fall 07
n
 Section_ident Course_pr Course_c Semes Yea Instruct
ifier efix ode ter r or

102 CS 3320 Spring 08 Knuth

112 MATH 2410 Fall 08 Chang

Anderso
119 CS 1310 Fall 08
n

135 CS 3380 Fall 08 Stone

3. PREREQUISITE Table:
o Similarly, split the Course_number and Prerequisite_number
into Course_prefix and Course_code.
o This restructuring ensures that only the Course_prefix column
needs to be updated if the department prefix changes.
Restructured PREREQUISITE Table:
Course_pr Course_c Prerequisite_p Prerequisite_
efix ode refix code
CS 3380 CS 3320
CS 3380 MATH 2410
CS 3320 CS 1310
Benefits of Restructuring:
 Now, if the department changes from CS to CSSE, only the
Course_prefix column in the COURSE, SECTION, and
PREREQUISITE tables needs to be updated.
 This reduces the number of updates required and simplifies future
changes, as course numbers and department names are decoupled.
In conclusion, by restructuring the tables, we ensure that only the prefix
needs to be updated, which simplifies maintenance and reduces the risk
of errors during updates.