As a computer science student, studying Database Management Systems (DBMS) is essential

because data is at the core of nearly every modern software application. From social media to
online banking, databases are the backbone that allows systems to store, manage, and retrieve
vast amounts of information reliably and securely. Understanding DBMS provides a
foundational skillset for building robust, scalable, and efficient software.
Importance for Computer Science and Engineering (CSE)
Core technical skills
Core Technical Skills from DBMS
1. Data Modeling and Design
o Learn to structure and organize data effectively.
o Use techniques like normalization to reduce redundancy and improve
consistency.
2. Efficient Data Retrieval
o Optimize database queries with indexing and other techniques.
o Ensures applications run fast and smoothly instead of being slow.
3. Transaction Management
o Understand and apply ACID properties (Atomicity, Consistency, Isolation,
Durability).
o Guarantees reliable and correct data operations, even during failures.
4. Concurrency Control
o Manage multiple users accessing/updating data at the same time.
o Prevents data conflicts and corruption in multi-user environments.
Real-world application development
 Nearly every application uses a database: Whether building a mobile app, a
website, or an enterprise system, you will almost certainly be interacting with a
database. DBMS knowledge is fundamental for a full-stack developer who needs to
manage both the front-end and back-end of an application.
 Career opportunities: A solid understanding of DBMS, including proficiency in
Structured Query Language (SQL) and an awareness of NoSQL alternatives like
MongoDB, opens up a wide range of career paths. This includes roles such as:
o Database Administrator (DBA)
o Back-end Developer
o Data Scientist or Analyst
o Big Data Engineer
Database
 A database is a collection of related data.
 Data means known facts that can be recorded and have meaning.
 Example: Names, phone numbers, and addresses of people you know.
 You can store this data in an address book, Microsoft Access, or Excel.
 Any collection of related data with meaning can be called a database.
 For example, even the words on a page of text can be seen as related data.
Properties of a Database:
1. A database represents a part of the real world. Any changes in the real world are
shown in the database.
2. A database is a logically organized collection of data with meaning. Random data
cannot be called a database.
3. A database is created for a specific purpose, with a set of users and applications in
mind.
Database Management System (DBMS)
 A DBMS is a collection of programs that allows users to create, manage, and
maintain a database.
 It is a general-purpose software system that supports:
o Defining the database → specifying data types, structures, and constraints.
o Constructing the database → storing the data on storage media controlled by
DBMS.
o Manipulating the database → querying (retrieving data), updating (reflecting
real-world changes), and generating reports.
o Sharing the database → enabling multiple users and applications to access the
data simultaneously.
DBMS Components and Functions
1. Database Catalog / Dictionary (Meta-data):
o Stores the database definition (data about data).
o Contains descriptions of structures, types, and constraints.
2. Application Interaction:
o Application programs send queries and requests to the DBMS.
o A query retrieves data, while a transaction may both read and write data.
3. Protection Features:
 o System Protection → safeguards against hardware/software failures or
crashes.
o Security Protection → prevents unauthorized or malicious access.
4. Maintenance Features:
o Supports long-term use (databases may last for many years).
o Allows the system to evolve when requirements change over time.
5. Complexity of DBMS:
o A DBMS is usually a very complex software system because it manages
many critical tasks.
o It is not always necessary to use a general-purpose DBMS; one could create
special-purpose DBMS software with custom programs, but it also requires a
lot of effort and complexity.

Example
The UNIVERSITY database example shows how data is organized into different files such as
STUDENT, COURSE, SECTION, GRADE_REPORT, and PREREQUISITE, each storing
specific types of information. Every file has a defined structure with data types (like numbers,
strings, or codes) to represent details clearly. Records from different files are linked, such as a
student’s record being related to their grades or courses with their prerequisites. This example
highlights how databases store structured data and maintain meaningful relationships among
different types of records to manage real-world information efficiently.
File Processing vs. Database Approach
 In traditional file processing:
o Each user/application creates and manages their own files.
o Example:
 Grade office keeps files on students and grades.
 Accounting office keeps files on fees and payments.
o Even though both use student data, they maintain separate files.
o This leads to:
 Data redundancy (same data stored multiple times).
 Wasted storage space.
  Extra effort to keep data up to date.
 In the database approach:
o A single shared repository stores all data.
o Data is defined once and then accessed by many users/applications.
o Data names/labels are standardized and used across queries, transactions, and
applications.
Main Characteristics of the Database Approach
1. Self-describing nature – The database contains both the data and its description
(meta-data).
2. Insulation between programs and data – Programs are separate from data; changes
in data structure don’t always require program changes.
3. Multiple views support – Different users can see the same data in different ways,
depending on their needs.
4. Data sharing and multiuser transaction processing – Many users and applications
can share and update the same database safely.
Self-Describing Nature of Database Systems
 A key feature of the database approach is that it stores not just the data, but also a
complete description of the database (structure + constraints).
 This description is stored in the DBMS catalog.
What the Catalog (Meta-data) Contains
 Structure of each file.
 Type and storage format of each data item.
 Constraints on the data.
 This information (called meta-data) describes the structure of the actual database.
Uses of the Catalog
 The DBMS software refers to it to understand the database structure.
 Users may also use it to find details about data organization.
 A general-purpose DBMS is not built for one specific database (e.g., university,
banking, company), so it uses the catalog to handle any type of database.
Example
 In a UNIVERSITY database, the catalog stores definitions of files like STUDENT,
COURSE, etc.
  When a request is made to access Name of a STUDENT, the DBMS looks into the
catalog to find where "Name" is located and how it is stored.

An example of a database catalog for the database

Insulation between Programs and Data, and Data Abstraction
Program-Data Independence
 In traditional file processing:
o The structure of data files is written inside application programs.
o Any change in file structure → all related programs must also be changed.
o Example: If a new field like Birth_date is added to STUDENT records, all
programs using STUDENT must be modified.
 In a DBMS:
o Data structure is stored separately in the DBMS catalog.
o Only the catalog needs to be updated if the structure changes.
o Programs do not need to be changed → they automatically work with the
updated structure.
Program-Operation Independence
Application programs only care about the interface (name + inputs).
Even if the implementation (the way the operation is written inside the DBMS)
changes, the programs using it do not need to be changed.
 Example:
 When you go to an ATM and press Withdraw 1000 Rs, you only care about the
operation name (Withdraw) and the input (1000 Rs).
 Inside the bank’s system, the implementation may change:
 Earlier it might have checked only balance.
 Later it may also check daily withdrawal limits, fraud detection, or OTP
verification.
 But as a user, you still use the same operation (Withdraw 1000 Rs) in the same
way.
 You don’t need to change how you interact with the ATM — only the internal
working changes.
Data Abstraction
 The feature that supports program-data independence and program-operation
independence.
 A DBMS shows a conceptual view of the data, hiding unnecessary storage or
implementation details.
 Data Models provide this abstraction by describing:
o Objects (entities)
o Properties (attributes)
o Relationships among them
 This makes databases easier to understand for users compared to low-level storage
details.
Multiple Views in a Database
 A database can be very large, but not every user needs to see everything.
 A view is like a “window” that shows only the data a user needs.
 The data shown in a view can be:
o Directly stored in the database.
o Or created (derived) from existing data.
 Users don’t need to know whether the data is stored or derived — they just use the
view.
Example
Imagine a school database that stores all student details: name, address, fees, grades,
attendance, etc.
  Teacher’s View: Can see only grades and attendance of students.
 Accountant’s View: Can see only fees paid and pending amounts.
 Student’s View: Can see their own timetable, grades, and results.
 Principal’s View: Can see a summary of everything (fees, results, attendance).
Database Administrators (DBA)
 In every organization, shared resources need someone to manage and control them.
 In a database environment, the main resources are:
1. The database itself.
2. The DBMS software and related tools.
Roles of a DBA
 Authorize access: Decide who can use the database and what they can do.
 Coordinate and monitor use: Make sure the database is used properly and
efficiently.
 Manage resources: Arrange necessary software and hardware for the database.
 Handle issues: Responsible for fixing or preventing problems like:
o Security breaches (unauthorized access).
o Poor system performance (slow response times).
DATA MODEL
Data abstraction means hiding low-level details of how data is stored and organized, while
showing only the important features that users need.
A data model provides the concepts needed for abstraction.
It describes the structure of the database, including:
 Data types (e.g., integer, varchar, date)
 Relationships (e.g., student–course, customer–account)
 Constraints (rules like primary key, foreign key).
1. High-Level / Conceptual Data Models
 Provide concepts close to how end-users think about data.
 Focus on real-world representation instead of computer storage.
 Core concepts:
o Entity → a real-world object (e.g., Employee, Project).
o Attribute → properties of entities (e.g., Name, Salary).
 o Relationship → associations between entities (e.g., Employee works-on
Project).
 Examples of conceptual models:
o Entity-Relationship (ER) Model – describes entities, relationships, and
attributes.
Purpose: To give a high-level abstraction of the database understandable by designers and
end-users.
2. Representational / Implementation Data Models
 Act as a bridge between conceptual and physical models.
 Hide storage details but are closer to how data is actually organized in computers.
 Used most frequently in commercial DBMSs.
 Represent data using record structures → often called record-based data models.
 Examples:
1. Relational Data Model
 Most widely used.
 Represents data as tables (relations) with rows (tuples) and columns
(attributes).
 SQL is the standard language.
2. Legacy Models (older but important historically):
 Network Model → represents data as records connected by links.
 Hierarchical Model → represents data in a tree structure.
 Advantages: Easy for programmers and end-users to understand.
 Limitation: Not as intuitive as conceptual models for non-technical users.
3. Object Data Models
 A newer family of higher-level implementation models.
 Closer to conceptual models but with more programming-oriented features.
 Combine object-oriented concepts with databases:
o Encapsulation (data + methods together).
o Inheritance (subclasses inherit properties/methods).
o Complex data types.
 Used heavily in software engineering (e.g., CAD, multimedia, real-time systems).
 Can be used both as:
 o High-level conceptual models (for design).
o Implementation models (for database systems).
4. Low-Level / Physical Data Models
 Concerned with how data is actually stored in the computer system.
 Provide concepts for:
o File organization → how records are stored on disk.
o Record formats → fixed-length or variable-length records.
o Record ordering → sequential, hashed, clustered.
o Access paths → methods to find records efficiently.
 Access Paths Example:
o Index – allows fast retrieval of data using a search key.
o Can be organized as:
 Linear list.
 Hierarchical/tree-structured (e.g., B+ trees).
 Hash tables.
 Audience: Mainly for database designers and system programmers, not end-users.
 Purpose: Ensures efficient storage, retrieval, and update operations.
Database Schema vs. Database State
1. Database Schema (Description of the Database)
 Definition: The schema is the overall description/blueprint of the database, defined
during database design.
 Characteristics:
o Describes the structure of the database (record types, data items, constraints).
o Does not change frequently (static in nature).
o Specified only once to the DBMS at design time.
o Stored as meta-data in the DBMS catalog.
o Also called the intension of the database.
 Schema Diagram:
o A visual representation of the schema.
o Shows record types and data items.
 o May include some constraints.
o Does not show actual data or all details (e.g., data types or complex
constraints).
2. Database State (Actual Data in the Database)
 Definition: The data stored in the database at a specific moment in time.
 Characteristics:
o Also called a snapshot, current set of occurrences, or instances.
o Changes frequently as new records are added, deleted, or updated.
o Every schema construct (e.g., STUDENT, COURSE) has a current set of
instances (actual rows/records).
 Examples:
o Adding a new student record → changes the database state.
o Updating a grade → changes the state again.
 Initial State: Empty database (no data) after schema definition.
 Current State: The state at any given time after updates.

The Three-Schema Architecture

The goal of the three-schema architecture, is to separate the user applications from the
physical database. In this architecture, schemas can be defined at the following three levels:
Internal Level (Physical Level)
 Definition:
Describes how data is actually stored in the computer system.
 Model Used: Physical Data Model.
  Details Captured:
o Record formats (fixed-length, variable-length).
o Data storage methods (heap, sequential files, hashing).
o Index structures (B+ tree, hash index).
o Pointers and access paths (used for fast retrieval).
o Placement of data on disk blocks, clusters, partitions.
 Audience: Database designers, system programmers (not end users).
 Purpose: Ensures efficient performance for storage, retrieval, and updates.
2. Conceptual Level (Logical Level)
 Definition:
Provides a global logical view of the entire database for the organization.
 Model Used: Representational (implementation) Data Model (most commonly
Relational Model).
 Details Captured:
o Entities, attributes, relationships.
o Data types and constraints (keys, cardinalities, referential integrity).
o Operations allowed (insert, update, delete, query).
 Hides:
o Details of physical storage (files, indexes, record formats).
 Process:
o Often designed first using a high-level conceptual model (e.g., ER diagram).
o Then mapped to a relational schema for implementation.
 Audience: Database administrators, system analysts.
 Purpose: Acts as a bridge between physical storage and user views.
3. External Level (View Level)
 Definition:
Provides different customized views of the database for different users or user
groups.
 Model Used: Representational Data Model (e.g., Relational tables for each view).
 Details Captured:
o Only the subset of data that the user requires.
o Hides unnecessary details.
  Examples:
o Student view: Transcript, enrolled courses, personal details.
o Faculty view: Course rosters, grades of students.
o Registrar view: Full student database including financial records.
 Advantages:
o Security: Users see only what they are authorized to see.
o Simplification: Users deal with only relevant data.
 Audience: End users, application programmers.
 Purpose: Provides user-friendly interaction with the database.

Logical Data Independence

 Meaning: Ability to change the conceptual schema without altering external
schemas or application programs.
 Why needed? Conceptual schema may change due to:
o Adding a record type or data item (e.g., adding “Email” attribute in
STUDENT).
o Removing a record type or data item (e.g., dropping a COURSE attribute).
o Modifying constraints (e.g., changing max enrollment in a course).
 Effect:
o External schemas/views remain unchanged.
 o Only view definitions and mappings are updated internally.
o Applications using views continue to work as before.
Key Benefit: Protects application programs from changes in logical database design.
2. Physical Data Independence
 Meaning: Ability to change the internal schema (storage details) without altering the
conceptual schema or external schemas.
 Why needed? Internal schema may change to:
o Improve performance by reorganizing physical files.
o Add new access paths (indexes, hashing, clustering).
o Change file organization (e.g., heap → B+ tree).
 Effect:
o Conceptual schema and external views remain unchanged.
o Queries and applications run without modification.
o Only execution performance changes (usually improves).
Key Benefit: Protects applications and logical schema from changes in physical storage
details.
Comparison

Aspect Logical Data Independence Physical Data Independence

Change conceptual schema without Change internal schema without

Definition
affecting external schemas or apps affecting conceptual schema or apps

Structure and constraints (logical Storage and access methods (physical

Focus
design) design)

Adding/removing entities, attributes, Adding indexes, reorganizing files,

Examples
constraints changing access paths

Who Database administrators and system

End-users and application programmers
Benefits? performance tuning

Relational Model
The relational model represents a database as a collection of relations (tables).
Relation (Table)
 A relation is the main structure used in the relational model.
 Represented as a table of rows and columns.
  Each table has:
o A name (e.g., STUDENT, COURSE).
o A set of columns (attributes) with names.
o A set of rows (tuples) containing actual data.
 Example:
STUDENT (Name, Student_number, Class)
Tuple (Row / Record)
 Each row in the table = tuple.
 Represents a single fact or entity instance.
Attribute (Column)
 Each column in the table = attribute.
 Describes a property/characteristic of the entity.
 All values in a column belong to the same data type.
Domain
 Each attribute has a domain = set of possible valid values.
 Example:
o Domain of Student_number → integers (positive).
o Domain of Name → strings (alphabets).
o Domain of Grade → {‘A’, ‘B’, ‘C’, ‘D’, ‘F’}.
o Employee_ages: Possible ages of employees in a company; each must be an
integer value between 15 and 80.
 Domains ensure data integrity (only valid values allowed).

Ordering of Tuples in a Relation

  A relation in the relational model is defined as a set of tuples (rows).
 Since a set has no inherent order, tuples in a relation do not have any fixed
sequence.
No Ordering in a Relation
 Mathematically, sets are unordered collections → order of elements does not matter.
 Similarly, in a relation:
 Tuples have no “first,” “second,” or “last” position.
 The logical meaning of the relation remains the same regardless of tuple order.
Example (STUDENT Relation)
 Suppose STUDENT relation has tuples like:
 (Rahul, 101, 20, CS)
 (Amit, 102, 21, EE)
 (Sneha, 103, 22, ME)
 These can be displayed:
 Ordered by Name (alphabetical).
 Ordered by Student_number.
 Ordered by Age.
Values and NULLs in Tuples (Relational Model)
Atomic Values (First Normal Form – 1NF)
 In the relational model, each value in a tuple must be atomic → indivisible.
 Not allowed:
o Composite attributes (e.g., Full Name = First Name + Last Name).
o Multivalued attributes (e.g., multiple phone numbers in a single field).
 Instead:
o Composite attributes → split into simple components (First_Name,
Last_Name).
o Multivalued attributes → represented in separate relations.
 Because of this rule, the relational model is sometimes called the Flat Relational
Model.
2. NULL Values
 A special value NULL is used in the relational model.
  Represents cases where:
1. Unknown value → value exists but not currently known.
 Example: Student’s home phone number not provided.
2. Not applicable (undefined) → attribute does not apply to this tuple.
 Example: Office phone for students who don’t have an office.
3. Exists but unavailable → value exists but not recorded yet.
 Example: Visa_status attribute applies only to foreign students, but left
NULL for local students.
3. Issues with NULLs
 NULL values create ambiguities in operations:
o Comparing NULLs is problematic → two NULLs do not mean the values are
equal.
 Example: If Student A and Student B both have NULL in “Address,” it
doesn’t mean they live at the same place.
o In arithmetic or aggregations (like SUM, AVG), NULLs may be ignored or
treated differently.
KEYS
Example Relation: STUDENT Table

RollNo Name Email Phone Course

101 Rahul [email protected] 9876543210 B.Tech

102 Ananya [email protected] 9123456789 B.Sc

103 Rohan [email protected] 9988776655 B.Com

104 Meera NULL 9811122233 B.Tech

1. Primary Key (PK)

 Unique identifier of each record.
 Cannot be NULL.
 Only one per table.
👉 In this table: RollNo is the Primary Key.
Because each student has a unique roll number.

2. Candidate Key
  All possible attributes that can uniquely identify a record.
👉 In this table, possible Candidate Keys are:
 RollNo (unique for every student).
 Email (unique, but Meera’s is NULL, so not reliable in practice).
 Phone (unique for every student).
📌 Candidate Keys = { RollNo, Email, Phone }

3. Alternate Key
 Candidate Keys other than the Primary Key.
👉 If we choose RollNo as Primary Key, then:
 Email and Phone become Alternate Keys.

4. Super Key
 Any set of attributes that can uniquely identify a record (Candidate Key + extra
attributes).
👉 Examples of Super Keys in this table:
 {RollNo}
 {Phone}
 {RollNo, Name}
 {RollNo, Email}
 {Phone, Course}
📌 All Candidate Keys are Super Keys, but not all Super Keys are minimal.

5. Composite Key
 A key made of two or more attributes used together to uniquely identify a record.
👉 Example:
 Suppose RollNo was not available, then (Name, Phone) together could uniquely
identify a student.
 (RollNo, Course) is also a composite key, though RollNo alone is already unique.

6. Foreign Key (FK)

  Refers to a Primary Key in another table.
 Ensures relationship between tables.
👉 In this single table, we don’t have a foreign key.
But if we create another table Marks(RollNo, Subject, Marks) → here RollNo will be a
Foreign Key referencing Student(RollNo).

7. Unique Key
 Similar to Primary Key: values must be unique.
 But unlike Primary Key, it can contain NULL (once).
👉 Example:
 Email can be a Unique Key.
 All students must have different emails, but Meera can have NULL.
 Entity-Relationship (ER) model
Conceptual modeling is a crucial phase in designing a successful database application.
A database application includes both the database and the programs that handle queries and
updates.
Example: A BANK database application manages customer accounts with programs for
deposits and withdrawals.
Database applications often have user-friendly GUIs (forms, menus) for end users (e.g., bank
tellers).
During conceptual database design the focus is on database structures and constraints.
The Entity-Relationship (ER) model is a widely used high-level conceptual data model for
database design.
ER model introduces basic data-structuring concepts and constraints for designing conceptual
schemas.
ER diagrams are the diagrammatic notation used to represent ER models.
 The ER model describes data as entities, relationships, and attributes.
 Design Choices for ER Conceptual Design
1. Entities and Their Attributes
 EMPLOYEE (Main entity)
Attributes: Fname, Minit, Lname, Bdate, Address, Salary, Sex, Ssn
→ Example of an entity with simple attributes (Name can be composite: Fname +
Minit + Lname).
 DEPARTMENT
Attributes: Name, Number, Locations
→ Locations is multivalued (a department can have multiple locations).
 PROJECT
Attributes: Name, Number, Location.
 DEPENDENT
Attributes: Name, Sex, Birth_date, Relationship.
Composite vs. Simple (Atomic) Attributes
 Composite Attribute → An attribute that can be divided into smaller sub-parts.
o Example in diagram: Name of EMPLOYEE → split into Fname, Minit,
Lname.
 o Each sub-attribute has meaning and can be stored separately.
 Simple (Atomic) Attribute → Cannot be divided further.
o Examples: Ssn, Salary, Sex, Bdate.
Single-Valued vs. Multivalued Attributes
 Single-Valued Attribute → Holds only one value for each entity instance.
o Example: An EMPLOYEE has only one Ssn, one Salary, one Address.
 Multivalued Attribute → Can have multiple values for each entity.
o Example: A DEPARTMENT can have multiple Locations (shown with a
double oval in the diagram).
Stored vs. Derived Attributes
 Stored Attribute → Directly stored in the database.
o Examples: Ssn, Salary, Name, Address, Hours.
 Derived Attribute → Value can be computed from other attributes, not stored
permanently.
o Example: Number_of_employees in DEPARTMENT → derived by counting
employees linked via WORKS_FOR.
o Represented by a dashed oval in ER diagrams.
NULL Values
 Used when attribute values are missing, unknown, or not applicable.
o Example:
 An EMPLOYEE without a supervisor → SUPERVISION relationship
= NULL.
 A PROJECT not yet assigned to an employee → WORKS_ON (Hours)
may be NULL.
 A DEPENDENT may not exist for some employees → relationship =
NULL.
Complex Attributes
 A nested combination of composite and multivalued attributes.
 Example (not explicitly shown in this diagram but can be inferred):
o Address could be modeled as a composite attribute (Street, City, State, Zip),
o and if an employee has multiple addresses (e.g., permanent and temporary),
then Address becomes complex (Composite + Multivalued).
 o In this diagram, Name (composite) and Locations (multivalued) together
illustrate the idea of complexity when combined.
Entity Types and Entity Sets
 Entity Type → A collection of similar objects described by the same attributes.
o In the diagram, the entity types are:
 EMPLOYEE (described by Fname, Minit, Lname, Ssn, Bdate,
Address, Salary, Sex)
 DEPARTMENT (Name, Number, Locations)
 PROJECT (Name, Number, Location)
 DEPENDENT (Name, Sex, Birth_date, Relationship)
 Entity Set → The actual collection of entities (instances) of an entity type in the
database at a given time.
o Example:
 EMPLOYEE set → all employees like John Smith, Mary Brown, etc.
 PROJECT set → all projects like Project X, Project Y.
Key Attributes of an Entity Type
 Key Attribute → An attribute (or combination) that uniquely identifies each entity in
the set.
o In the diagram:
 EMPLOYEE → Ssn (Social Security Number) is the primary key.
 DEPARTMENT → Number (Dept Number) is the key.
 PROJECT → Number (Project Number) is the key.
 DEPENDENT → Name is not enough; key is a combination of
(Employee Ssn + Dependent Name) since different employees can
have dependents with the same name.
Value Sets (Domains) of Attributes
 Value Set (Domain) → The set of possible values an attribute can take.
o In the diagram:
 EMPLOYEE →
 Ssn → domain = set of 9-digit numbers.
 Sex → domain = {Male, Female}.
 Salary → domain = positive real numbers.
  Bdate → domain = valid dates.
 DEPARTMENT →
 Number → domain = integers (unique dept numbers).
 Name → domain = strings of characters.
 Locations → domain = set of city names/addresses.
 PROJECT →
 Number → domain = integers (unique project IDs).
 Location → domain = set of city/location names.
 DEPENDENT →
 Birth_date → domain = valid dates.
 Relationship → domain = {Spouse, Son, Daughter, etc.}.

Degree of a Relationship Type

 Definition: Number of entity types participating in a relationship.
  In the diagram:
o Binary relationships (degree 2):
 WORKS_FOR (EMPLOYEE–DEPARTMENT)
 MANAGES (EMPLOYEE–DEPARTMENT)
 WORKS_ON (EMPLOYEE–PROJECT)
 CONTROLS (DEPARTMENT–PROJECT)
 DEPENDENTS_OF (EMPLOYEE–DEPENDENT)
o Recursive binary relationship:
 SUPERVISION (EMPLOYEE–EMPLOYEE).
o (No ternary relationship here, but degree ≥ 3 would mean 3+ entities).

Relationships as Attributes
 Sometimes relationships carry their own descriptive attributes.
 Examples in diagram:
o WORKS_FOR → attribute Start_date (when employee started in department).
o MANAGES → attribute Start_date (when manager started managing dept).
o WORKS_ON → attribute Hours (how many hours employee works on
project).
Role Names and Recursive Relationships
 Role Names: Distinguish multiple roles played by the same entity type in a
relationship.
 Example:
o In SUPERVISION, both entities are EMPLOYEE.
o Roles: Supervisor and Supervisee.
 Without role names, it would be unclear who supervises whom.
Cardinality Ratios for Binary Relationships
 Cardinality Ratio = Maximum number of relationship instances an entity can
participate in.
 Examples in diagram:
o WORKS_FOR → Many employees (N) work for one department (1) → N:1.
o MANAGES → One employee manages one department → 1:1.
 o CONTROLS → One department controls many projects → 1:N.
o WORKS_ON → Many employees work on many projects → M:N.
o DEPENDENTS_OF → One employee can have many dependents, but each
dependent belongs to only one employee → 1:N.
o SUPERVISION → One supervisor can supervise many employees, but each
employee has one supervisor → 1:N.
Participation Constraints and Existence Dependencies
 Total Participation: Every entity must participate in the relationship.
 Partial Participation: Some entities may not participate.
 In the diagram:
o WORKS_FOR: Total participation of EMPLOYEE (every employee must
work for a dept).
o MANAGES: Partial participation of EMPLOYEE (not every employee is a
manager).
o WORKS_ON: Partial participation (some employees may not work on any
project, some projects may not have employees assigned yet).
o DEPENDENTS_OF: Partial participation (not every employee has
dependents).
o SUPERVISION: Partial participation (not every employee supervises others
or is supervised).
 Existence Dependency: If an entity cannot exist without being related through a
relationship.
o Example:
 A DEPENDENT cannot exist without being related to an EMPLOYEE
→ existence dependent.
 A DEPARTMENT can exist without a manager initially (before
assignment) → not existence dependent.
Weak Entity Type (Definition)
 A weak entity type is one that cannot be uniquely identified by its own attributes
alone.
 It depends on a strong entity type (called its owner) for identification.
 It always participates in a total, identifying relationship with its owner.
 It usually has a partial key (an attribute that, combined with the owner’s key,
uniquely identifies it).
Weak Entity in the COMPANY ER Diagram
 DEPENDENT is a weak entity type.
o Attributes: Name, Sex, Birth_date, Relationship.
o Problem: Just knowing a dependent’s Name (e.g., “John”) is not unique, since
many employees could have dependents named John.
o To uniquely identify a dependent, we need:
 The owner’s key (Employee’s Ssn) + the dependent’s partial key
(Name).
 Identifying Relationship:
o DEPENDENTS_OF links DEPENDENT to EMPLOYEE.
o It is total participation (a dependent cannot exist without being related to
some employee).
o EMPLOYEE is the owner (strong entity).
o DEPENDENT is the weak entity.