Fundamentals of Database System

Tutorial

FOR 5TH YEAR COMPUTER SCIENCE STUDENTS

2025 G.C/2017 E.C
 Database management system

 Database is a collection of related data.

 DBMS is software that manages and controls access to the database/ is software
that enables users to define, create, maintain, and control access to databases.
 ORACLE
 SQL Server
 DB2
 MySQL
 PostGres SQL
 ACCESS

 Database system is a collection of application programs that interact with the

database along with the DBMS and database itself
 Organize Data

A DBMS allows data to be stored in a structured format

(table-has rows (records) and columns (fields))
 Data Models: Common models include relational,
hierarchical, network, and object-oriented.
 Normalization: minimize redundancy and ensure data
integrity by organizing data into related tables.
 Schemas: Define the structure of the database, including
tables, fields, and relationships
 Maintaining Data

 DBMSs provide tools and mechanisms to ensure the data

remains accurate, up-to-date, and consistent over time.
 DataIntegrity Constraints: Rules like primary keys, foreign
keys, and unique constraints help maintain data correctness.
 Transactions:A sequence of operations treated as a single
unit, ensuring ACID properties (Atomicity, Consistency,
Isolation, Durability).
 Security:Role-based access control and encryption protect
sensitive data from unauthorized access.
 Retrieving Data Efficiently

 Efficient data retrieval is crucial for performance and usability.

 Structured Query Language (SQL): The standard language
for querying and manipulating relational databases.
 Indexes: Data structures that improve the speed of data
retrieval operations by reducing the need to scan entire tables.
 Query Optimization: DBMSs analyze queries and determine
the most efficient way to execute them.
 Principles of Database Design

 Designing a database is more than just storing data — it’s about structuring information
 so it is easy to access, maintain, and scale.
 A well-designed database improves performance, data integrity, and usability.
 1. Requirements Analysis and Specification
 Understand what data must be stored and how it will be used.
 Gather information about the organization's needs.
 Define requirements without considering how they will be implemented.
 2. Conceptual Design
 Use high-level conceptual data models like the Entity-Relationship (ER) model or
Enhanced ER (EER) model.
 Focus on the logical structure of the data, not physical storage.
 Identify entities, relationships, attributes, and constraints.
 …cont.

 3. Logical Design
 Mapthe conceptual model into a logical model supported by the chosen
DBMS, typically a relational model.
 Create relational schemas with tables, keys, and relationships.
 Ensure the design captures the semantics of the application accurately.
 4. Normalization
 Applynormalization rules (1NF, 2NF, 3NF, BCNF, 4NF, 5NF) to remove
redundancy and avoid update anomalies.
 Organize data into well-structured tables.
 Understand functional dependencies and multivalued dependencies.
 …cont.

 5. Physical Design
 Decide on storage structures, indexing, and access paths.
 Consider performance issues: query speed, storage efficiency,
transaction throughput.
 Use disk storage structures, B-trees, hashing, and buffering
techniques.
 6. ER/EER-to-Relational Mapping
 Systematic process for converting an ER/EER model into a relational
database schema.
 Maintain consistency between conceptual and relational models.
 …cont.

 7. Support for Data Integrity

 Define constraints such as primary keys, foreign keys, unique
constraints, and domain constraints.
 Enforce referential integrity between related tables.
 8. Transaction Management and Concurrency Control
 Ensure database consistency in multi-user environments.
 Support ACID properties (Atomicity, Consistency, Isolation, Durability).
 Prevent problems like lost updates, dirty reads, and deadlocks.
Summary
 Concepts to Real-World Database Design

 1. Requirements Collection and Analysis

 Understand the domain ("miniworld") to be modeled.
 Example: In the COMPANY case, departments, employees, projects, and
dependents are identified based on business needs​
 2. Conceptual Design Using ER/EER Models
 Represent real-world entities (e.g., EMPLOYEE, DEPARTMENT) and
relationships (e.g., WORKS_FOR, MANAGES) using Entity-Relationship (ER)
diagrams.
 EER extends this with specialization, generalization, and categories for more
complex modeling​
 …cont.

 3. ER to Relational Mapping
 TheER schema is systematically converted into a relational
schema using a 7-step mapping algorithm:
Regular entities → Tables
Relationships → Foreign keys or bridge tables
Multivalued/composite attributes → Separate tables or flattening
 Thismapping creates a normalized, implementable structure for real
databases
 …cont.

 4. Normalization and Schema Refinement

 Use functional dependencies and normal forms (1NF to 5NF)
to refine relations.
 Helps reduce redundancy and maintain data consistency in
practice
 5. Logical and Physical Design
 Logical design: implemented using a DBMS-specific data model
(usually SQL-based).
 Physical design: specifies indexes, storage structures, and access
paths for optimized performance .
 …cont.

 6. Implementation and Testing

 Load data into the DBMS.
 Test operations (queries, transactions) against the schema.
 Refine schema based on performance or new requirements.
 7. Application Design and Integration
 Build application interfaces (e.g., forms, APIs) that use the
database schema to serve user needs.
 Example: The COMPANY database could be linked to an HR
system or payroll processing.
 …cont.

Example: COMPANY Database Design Flow

 Miniworld Description
→ Employees work on projects, belong to departments, and may have dependents.
 ER Diagram Created
→ Entities: EMPLOYEE, PROJECT, DEPARTMENT
→ Relationships: WORKS_ON, MANAGES
 Relational Schema Derived
→ Tables: EMPLOYEE, PROJECT, DEPARTMENT, WORKS_ON, DEPENDENT
 Constraints Applied
→ Primary keys, foreign keys, NOT NULL, etc.
 Implemented in SQL
→ SQL DDL statements define the schema in a real RDBMS like MySQL or PostgreSQL.
 Designing Database Systems for Real-World
Scenarios
 1. Requirements Collection and Analysis
 Purpose: Understand the "miniworld" (the part of reality your database will represent).
 Methods: Interviews, questionnaires, studying forms/reports.
 Outcome: A complete list of entities, relationships, attributes, and functional requirements
 ​ xample: For a Company Database, you would gather information about employees, departments, projects,
E
supervisors, and dependents​
 2. Conceptual Design
 Tool: High-level modeling using ER (Entity-Relationship) or EER (Enhanced ER) diagrams.
 Activities:
 Identify entity types (e.g., Employee, Department).
 Define attributes (e.g., Employee name, SSN).
 Establish relationships (e.g., WORKS_FOR, MANAGES).
 Specify constraints (e.g., cardinality, participation)
 …cont.

 3. Logical Design (Data Model Mapping)

 Goal: Transform the conceptual schema into a logical schema for the DBMS (typically
relational).
 Steps:
 Map entities to tables.
 Map relationships using foreign keys or bridge tables.
 Flatten complex or multivalued attributes​
 Example: In the Company database, WORKS_ON relationship would map to a table storing
Employee-Project-Hours details.
 4. Normalization
 Objective: Eliminate redundancy and ensure integrity.
 Technique: Apply normal forms (1NF → 2NF → 3NF → BCNF → 4NF/5NF).

 …cont.

 5. Physical Design
 Focus: Storage, indexing, and performance optimization.
 Activities:
 Choose appropriate file organizations.
 Create indexes (e.g., B-trees, hash indexes).
 Plan access paths
 ​6. Application Program Design
 Task: Design transaction programs that interact with the database.
 Example: Applications for adding a new employee or recording hours worked
on a project​
 …cont.

 7. Testing, Evaluation, and Refinement

 Process:
 Test with sample data.
 Evaluate query performance.
 Adjust indexes, schema design if necessary.

 Real-World Example: COMPANY Database System​

 ts
n c ep
d co
n ce
d v a
A
 The main concepts of the object oriented
model
 Objects: Represent real-world entities with attributes (data) and methods (behavior).
 The main concepts of the Object-Oriented (OO) model are:
 1. Object Identity (OID)
 Each object has a unique, system-assigned identifier that is immutable
and independent of its attribute values.
 Example: A Student object with ID 101 remains the same even if their
name changes from "Ali" to "Ahmed".​
 2. Object Structure and Type Constructors
 Objects can have complex structures using type constructors like tuple,
set, list, array, and bag.
 Example: A Course object can have a set of enrolled students
 …cont.

 3. Encapsulation of Operations (Methods)

Objects encapsulate both data (attributes) and behavior
(methods).
Example: A BankAccount object has an attribute balance and a
method deposit(amount) to update the balance​
 4. Persistence
Objects are made persistent so they survive beyond the execution
of the creating program.
Example: A Book object created today in a library system remains
stored in the database and accessible next week.
 …cont.

 5. Type Hierarchies and Inheritance

 Classes can inherit attributes and methods from parent classes (single, multiple,
selective inheritance).
 Example: GraduateStudent inherits from Student and adds new attributes like
thesisTopic​.
 6. Polymorphism (Operator Overloading)
Methods can behave differently based on the object type.
 Example: The Area() method behaves differently for a Circle object (πr²) and a
Rectangle object (width × height)
 7. Object Query Language (OQL)
 OQL is the standard query language for querying object databases, defined by the
Object Data Management Group (ODMG).
 …cont.

 Its syntax is similar to SQL, but it adds support for object-oriented concepts like:
 Object identity
 Complex objects
 Inheritance and polymorphism
 Relationships and collections​
 Basic Syntax:
 SELECT: Defines what to retrieve.
SELECT <attributes>
FROM: Defines the collection to query and binds an
 FROM <iterator_variable> IN <collection>
iterator variable.
WHERE: Specifies the filtering condition
 WHERE <condition>;
 …cont.

 Simple Query
 Retrieve the names of all departments in the College of
Engineering:
select D.Dname
from D in DEPARTMENTS
where D.College = 'Engineering';
D is an iterator variable that ranges over all objects in
DEPARTMENTS.

 Database Recovery Methods During Failure

 Database systems must ensure durability (committed

transactions persist) and
 Atomicity (transactions are fully completed or fully aborted).
 Recovery techniques handle failures like:
 Transaction failures (e.g., deadlocks, integrity violations).
 System crashes (power loss, OS failure).
 Disk failures (storage corruption).
 …cont.

 Recovery Techniques
 1. Log-Based Recovery: Record all changes to the database in a log before
applying them.
 Example Recovery:
<T1, start>
Redo committed transactions
<T1, A, 100, 150> // T1 updates A from 100 → 150
<T2, start> (T1’s changes are reapplied).
<T2, B, 200, 250> // T2 updates B from 200 → 250
Undo uncommitted
<T1, commit>
transactions (T2’s changes are
CRASH! (T2 not committed)
rolled back).
 …cont.

 2. Checkpointing: Periodically save the database state to reduce recovery time.

 Steps:
 Write all modified buffer blocks to disk.

 Write a <checkpoint> record to the log.

<T3, C, 50, 80>
<checkpoint>
<T4, start> Recovery:

<T4, D, 120, 180> Only transactions after the last checkpoint (T4) need analysis.
CRASH!
 …cont.

 3.
Shadow Paging: Maintain two page tables (current and
shadow). On commit, switch to the shadow copy.
 Example
 Transaction modifies Page 1 (original = 100, new = 200).
 Original page table points to old data; shadow copy points to
updates.
 On commit, shadow becomes the new current table.
 On crash, discard shadow table (revert to pre-transaction
state).
 …cont.

 4. ARIES Algorithm: Advanced Recovery Algorithm used in modern DBMS (e.g.,

IBM DB2, PostgreSQL).
 Analysis: Identify dirty pages and active transactions at crash time.
 Redo: Reapply all changes (even uncommitted ones) to restore state.
 Undo: Roll back uncommitted transactions.
<T5, start>
<T5, E, 300, 400> Recovery:
<T6, start>
Redo: Reapply T5 and T6’s changes.
<T6, F, 500, 600>
<T5, commit> Undo: Roll back T6 (since it wasn’t committed).
CRASH!
 …cont.

 5. Replication: Maintain multiple copies (replicas) of the database across different

locations.
 If one database fails, another replica can take over.
 Pros: High availability and fault tolerance.
 Cons: Can be expensive to maintain.
 6. Backup and Restore
 Backup: Regularly save a copy of the database (full, incremental, or differential
backup).
 Restore: Reload the backup when a failure occurs.
 Pros: Simple and essential.
 Cons: May lose recent transactions not saved in the backup.
Summary
 Design a distributed database system in homogenous and
heterogeneous environments

 A distributed database system (DDBS) stores data across multiple

locations (nodes) while appearing as a single system to users.
 Homogeneous: All nodes use the same DBMS (e.g., all PostgreSQL).
 Heterogeneous: Nodes use different DBMS (e.g., PostgreSQL + Oracle
+ MongoDB).
 Key Challenges
 Data Fragmentation: How to partition data.
 Replication: How to duplicate data for fault tolerance.
 Query Processing: How to optimize queries across nodes.
 Transaction Management: How to ensure ACID properties.
 …cont.

 Homogeneous Distributed Database Design

 Components
 Global Schema: Unified view of all data.
 Fragmentation: Data split horizontally (by rows) or vertically (by columns).
 Replication: Copies of fragments stored on multiple nodes.
 Distributed Query Processor: Optimizes queries across nodes.
 Example: University Database: Distribute student and course tables across 3 nodes (same DBMS).
 1. Horizontal Fragmentation
 Node 1 (USA): student where dept_name = 'Comp. Sci'
 Node 2 (Europe): student where dept_name = 'Physics'
 Node 3 (Asia): student where dept_name = 'Biology‘
 2. Replication: Store a copy of course on all nodes for fault tolerance
 …cont.

 Heterogeneous Distributed Database Design

 Components
 Middleware: Integrates different DBMS (e.g., ODBC/JDBC, Apache Kafka).
 Wrappers: Translate queries between systems.
 Global Catalog: Metadata mapping for interoperability.
 Example: E-Commerce System
 Nodes:
 PostgreSQL: Customer orders (relational).
 MongoDB: Product catalog (document-based).
 Redis: Shopping cart (key-value store).
 Query processing strategies

 Query processing: converting a high-level SQL query into an efficient

execution plan.
 Key steps:
 Parsing & Translation: Convert SQL to relational algebra.
 Optimization: Generate and select the best execution plan.
 Evaluation: Execute the plan and return results.
 ia l
or
ut
f T
d o
En
he
T