📘 Page 1: Outline of the Relational Model

This page sets the stage for the entire chapter by listing the core topics covered under the
relational model. These include:

●​ Structure of Relational Databases: Understanding how data is organized in tables.

●​ Database Schema: The blueprint of the database, defining its structure.
●​ Keys: Mechanisms to uniquely identify records.
●​ Schema Diagrams: Visual representations of database schemas.
●​ Relational Query Languages: Languages used to interact with relational databases.
●​ Relational Algebra: A procedural query language foundational to relational databases.

Each of these topics forms a pillar of relational database theory and practice. The outline
provides a roadmap for learners, ensuring they grasp both the theoretical underpinnings and
practical applications of relational databases.

📘 Page 2: Foundation of the Relational Model

The relational model is grounded in set theory, a branch of mathematics that deals with
collections of objects. This mathematical foundation gives the relational model its rigor and
consistency. A relation in this context is essentially a table, where each row represents a tuple
and each column represents an attribute. The model was introduced by Dr. E.F. Codd in 1970
while working at IBM, revolutionizing how data was stored and accessed. The strength of the
relational model lies in its formal structure, which allows for powerful querying, integrity
enforcement, and scalability. It abstracts the complexity of data storage and provides a clean,
logical framework for managing information.

📘 Page 3: Relational Model (1970)

This page elaborates on the structure of a relational database:

●​ Data is stored in tables, which are called relations.

●​ Each table has a heading (attributes) and a body (tuples).
●​ Attributes are columns and are unordered.
●​ Tuples are rows and are also unordered.
The relational model supports constraints and relationships between tables, enabling
complex data representations. Popular relational database systems like Oracle, DB2, and
Sybase implement this model. The abstraction of data into relations allows for modular design,
where each table represents a distinct entity or relationship, and operations can be performed
using relational algebra or SQL.

📘 Page 4: Terminology – Informal vs. Formal

Understanding the terminology is crucial:

●​ Table → Relation
●​ Row/Record → Tuple
●​ Column/Field → Attribute
●​ Number of Rows → Cardinality
●​ Number of Columns → Degree/Arity
●​ Unique Identifier → Primary Key
●​ Legal Values Set → Domain

This mapping helps bridge the gap between everyday usage and formal database theory. For
example, while developers may refer to “columns,” database theorists use “attributes.”
Recognizing these terms ensures clarity when reading documentation, writing queries, or
designing schemas.

📘 Page 5: Definitions in Relational Databases

A relational database is a collection of relations. Each relation has:

●​ An instance: The actual data (rows and columns).

●​ A schema: The structure, including the relation name and attributes.

Example:

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

Each row in the table is a tuple, and all rows are distinct, reinforcing the set-based nature of the
model. This distinction between schema and instance is vital—schemas define what data can
exist, while instances represent the current state of the data.
📘 Page 6: Instructor Relation Example
This page provides a concrete example of a relation named Instructor, with attributes:

●​ ID
●​ Name
●​ Department Name
●​ Salary

Each row represents a unique instructor. This example illustrates how real-world entities are
modeled in a relational database. The table format makes it easy to query, update, and analyze
data. It also sets the stage for understanding keys, constraints, and relationships.

📘 Page 7: Schema and Instance

A relation schema defines the structure:

instructor = (ID, name, dept_name, salary)

An instance is the actual data stored in the relation at a given time. It’s denoted as:

r(instructor)

Each row in the instance is a tuple. This separation allows databases to evolve—schemas can
remain constant while instances change over time. It also enables validation, ensuring that data
conforms to the defined schema.

📘 Page 8: Attributes and Domains

Each attribute has a domain, which is the set of allowed values. For example, the domain of
age might be integers between 0 and 120. Attributes are typically atomic, meaning they hold
indivisible values. The null value represents unknown or missing data and is part of every
domain. However, nulls complicate operations like comparisons and aggregations, requiring
special handling in query languages.
📘 Page 9: Null Values and Three-Valued Logic
Nulls introduce three-valued logic:

●​ True
●​ False
●​ Unknown (null)

Operations behave differently:

●​ null OR true → true

●​ null OR false → null
●​ true AND null → null
●​ false AND null → false
●​ NOT null → null

This logic ensures that queries involving nulls don’t produce misleading results. However, it also
adds complexity, especially in filtering and joining data.

📘 Page 10: Types of Attributes

Attributes can be:

●​ Atomic vs. Composite: Atomic are indivisible; composite can be broken down (e.g., full
name → first, middle, last).
●​ Single-valued vs. Multi-valued: Single holds one value; multi-valued can hold multiple
(e.g., registered courses).
●​ Derived: Computed from other attributes (e.g., age from birthdate).

Understanding these types helps in designing schemas that are both efficient and expressive.

📘 Page 11: Unordered Nature of Relations

In the relational model, order doesn’t matter:

●​ Tuples can be stored in any order.

●​ Queries should not rely on tuple order unless explicitly sorted.

This unordered nature aligns with set theory and ensures consistency across operations. It also
allows for optimization, as the DBMS can store and retrieve data in the most efficient way.
📘 Page 12: Database Schema vs. Instance
●​ Schema: Logical structure of the database.
●​ Instance: Snapshot of data at a specific time.

Example schema:

instructor(ID, name, dept_name, salary)

Example instance: A table with actual instructor data. This distinction is foundational for
understanding how databases evolve and how data integrity is maintained.

📘 Page 13–15: Keys – Superkey, Candidate Key, Primary

Key
●​ Superkey: Any set of attributes that uniquely identifies a tuple.
●​ Candidate Key: A minimal superkey (no unnecessary attributes).
●​ Primary Key: A chosen candidate key used as the main identifier.

Example:

Student(IDNo) → Candidate Key

Student(name, IDNo) → Superkey

●​ Composite Key: A key made of multiple attributes.

●​ Foreign Key: An attribute in one relation that references a primary key in another.

Keys ensure uniqueness, referential integrity, and efficient access.

📘 Page 16–17: Schema Diagram of University Database

This diagram visualizes the relationships between entities like:

●​ Student
●​ Instructor
●​ Course
 ●​ Department
●​ Section
●​ Teaches
●​ Takes
●​ Advisor
●​ Classroom
●​ Time Slot
●​ Prerequisite

Each entity has attributes and relationships, forming a normalized schema. This diagram helps
in understanding how data flows across the university system and supports complex queries like
course enrollment, instructor assignments, and student advising.

📘 Page 18: Relational Query Languages

Relational databases support:

●​ Procedural Languages: Specify how to retrieve data (e.g., relational algebra).

●​ Declarative Languages: Specify what data is needed (e.g., SQL).

“Pure” relational languages include:

●​ Relational Algebra
●​ Tuple Relational Calculus
●​ Domain Relational Calculus

These languages are equivalent in power, meaning they can express the same queries.
Relational algebra is foundational and consists of six basic operations, which will be explored in
depth in subsequent chapters.