DATABASE ASSIGNMENT 01

NAME: ASADULLAH AHMAD

ROLL NO: BCSF23M020
SECTION: CS
SUBMITTED TO: SIR ASIF SOHAIL

QUESTION NUMBER 1
PART 1 )

Explain Oracle architecture with appropriate diagram(s),

and suitable references.
Oracle Architecture: A Comprehensive Overview
 Oracle, a leading database management system, boasts a robust and intricate
architecture designed to deliver high performance, reliability, and scalability. Let's
delve into its key components:

1. Oracle Instance:

An Oracle instance is a collection of memory structures and background

processes that interact with a specific database. It's the runtime environment for the
database.

Key Components:

System Global Area (SGA):

Shared memory region accessed by all database processes.

Composed of:
Database Buffer Cache: Stores recently accessed data blocks.
Shared Pool: Stores shared SQL and PL/SQL code.
Large Pool: Allocates large memory chunks for specific operations.
Redo Log Buffer: Stores changes to the database before they're written to
disk.
Program Global Area (PGA):

Private memory area for each user process.

Used to store session-specific data, such as SQL statements, work areas, and
sort data.
 Background Processes:

DBWR (Database Writer): Writes dirty buffers from the SGA to data files.
LGWR (Log Writer): Writes redo log entries to the redo log files.
SMON (System Monitor): Performs recovery tasks, such as instance
recovery and media recovery.
PMON (Process Monitor): Monitors background and user processes,
restarting failed processes.
CKPT (Checkpoint): Synchronizes the database and redo log files.

2. Oracle Database:

The physical storage for the database, consisting of:

Data Files: Store the actual data.

Control File: Records the physical structure of the database.
Redo Log Files: Record changes made to the database.
Archive Log Files: Copies of redo log files for recovery purposes.
Oracle Architecture Diagram:
 geeksforgeeks.org
Oracle Architecture Diagram

3. Oracle Real Application Clusters (RAC):

Oracle RAC enables multiple database instances to share the same physical
database, improving performance and availability.

Key Features:

Global Cache: A shared memory pool for all instances.

Cluster Interconnect: High-speed network for communication between
instances.
 Cluster Synchronization Services (CSS): Manages cluster membership and
resource allocation.

4. Oracle Data Guard:

Oracle Data Guard provides high availability and disaster recovery by

maintaining standby databases.

Key Features:

Physical Standby Database: A complete copy of the primary database.

Logical Standby Database: A subset of the primary database.
Far Sync Replication: Replicates data to remote sites.

5. Oracle GoldenGate:

Oracle GoldenGate is a data integration and replication solution that enables

real-time data replication between heterogeneous databases.

Key Features:

Capture: Extracts data changes from source databases.

Deliver: Transmits data changes to target databases.
Map: Transforms data to match target database schemas.
References:
 Oracle Documentation: https://docs.oracle.com
Oracle Technical Architecture Diagrams:
https://docs.oracle.com/en/database/oracle/oracle-database/23/aliad/iad_home.html

QUESTION NUMBER 1(B)

Precisely discuss 12 rules of Dr. E.F. Codd related to relational databases.

SOLUTION:
Dr. E.F. Codd, the father of the relational database model, proposed 12 rules to
define a true relational database management system (RDBMS). These rules, often
referred to as "Codd's 12 Rules," are fundamental to the design and implementation
of relational databases.

Here's a breakdown of these rules:

The Information Rule: All data must be represented as values in cells of a table.
This ensures data integrity and consistency.
The Guaranteed Access Rule: Every data item must be logically accessible by
specifying a table name, primary key value, and column name. This guarantees
data accessibility and retrieval.
Systematic Treatment of Null Values: Null values (representing missing or
unknown data) must be handled consistently and systematically. This avoids
ambiguity and ensures data accuracy.
The Active Online Catalog Rule: The database system must maintain an online
catalog (metadata) that describes the database structure, including tables, columns,
data types, and constraints. This metadata is essential for database management
and optimization.
The Comprehensive Data Sub-language Rule: The database system must support a
data sub-language that allows users to define, manipulate, and control data. This
sub-language should be comprehensive and powerful, covering data definition,
data manipulation, query, update, and security.
The View Updating Rule: If a view is theoretically updatable, the system must
allow updates through the view. This ensures data consistency and simplifies data
management.
The High-Level Insert, Update, and Delete Rule: The system must support high-
level insert, update, and delete operations on data. This simplifies data
manipulation and reduces the risk of errors.
The Physical Data Independence Rule: Changes to the physical storage structure
should not impact the logical structure of the database. This allows for flexibility
and optimization without affecting applications.
The Logical Data Independence Rule: Changes to the logical structure of the
database (e.g., adding or removing columns) should not impact applications. This
promotes data evolution and flexibility.
The Integrity Independence Rule: Integrity constraints should be defined and
enforced by the database system, not by application programs. This ensures data
consistency and reliability.
The Distribution Independence Rule: The system should be able to distribute data
across multiple sites without affecting the logical view of the data. This enables
scalability and performance optimization.
The Nonsubversion Rule: The system should not allow users to bypass the integrity
and security mechanisms of the database.

This protects data integrity and security.

QUESTION NUMBER 1(C) :

Relational Keys

Relational keys are fundamental to the structure and organization of relational databases. They
identify rows uniquely and establish relationships between tables. Here are the primary types:

1. Primary Key:
 o A unique identifier for each row in a table.
o Cannot contain null values.
o Ensures data integrity by preventing duplicate records.

Example: Consider a Customers table:

| CustomerID (PK) | CustomerName | CustomerAddress

| |---|---|---| | C001 | Alice | 123 Main St | | C002 | Bob | 456 Elm St |

2. Candidate Key:
o Any column or combination of columns that can uniquely identify a row.
o A primary key is chosen from the candidate keys.

Example: In the Customers table, both CustomerID and a combination of

CustomerName and CustomerAddress could be candidate keys.

3. Super Key:
o A set of attributes that uniquely identifies a row.
o Includes all candidate keys and other non-key attributes that, when combined,
uniquely identify a row.
4. Alternate Key:
o Any candidate key that is not chosen as the primary key.

Data Integrity Rules

Data integrity rules ensure the accuracy, consistency, and reliability of data in a relational
database. Here are some key rules:

1. Entity Integrity:
o Ensures that each row in a table has a unique primary key value.
o Prevents duplicate records and maintains data consistency.
2. Referential Integrity:
o Maintains consistency between related tables.
o Ensures that foreign key values in one table reference valid primary key values in
another table.

Example: Consider a Orders table with a foreign key referencing the Customers table: |
OrderID (PK) | CustomerID (FK) | OrderDate | |---|---|---| | O001 | C001 | 2023-11-01 | |
O002 | C002 | 2023-11-02 |

The CustomerID in the Orders table must reference an existing CustomerID in the
Customers table.

3. Domain Integrity:
 oRestricts the values that can be entered into a column to a specific domain or data
type.
o Ensures data accuracy and consistency.
4. User-Defined Integrity:
o Custom rules and constraints defined by the database administrator to enforce
specific business rules.
o These rules can be complex and tailored to specific organizational needs.

QUESTION NUMBER 1(D)

Write a comprehensive report on operators of relational algebra with an

innovative explanation of different join types.

Relational Algebra Operators: A Comprehensive Overview

Relational algebra is a formal query language that provides a theoretical foundation for relational
databases. It consists of a set of operators that manipulate relations (tables) to retrieve specific
information.

Fundamental Operators

1. Selection (σ):
o Extracts rows from a relation based on a given condition.
o Syntax: σ_condition(relation)
o Example:

SQL

SELECT * FROM Customers WHERE City = 'New York';

2. Projection (π):
o Selects specific columns from a relation.
o Syntax: π_attribute_list(relation)
o Example:

SQL

SELECT CustomerName, City FROM Customers;

3. Union (∪):
o Combines two relations with identical schemas, eliminating duplicates.
o Syntax: relation1 ∪ relation2
 o Example:

SQL

SELECT CustomerID, CustomerName FROM USCustomers

UNION
SELECT CustomerID, CustomerName FROM UKCustomers;

4. Intersection (∩):
o Returns rows that exist in both relations.
o Syntax: relation1 ∩ relation2
o Example:

SQL

SELECT CustomerID, CustomerName FROM VIPCustomers

INTERSECT
SELECT CustomerID, CustomerName FROM FrequentShoppers;

5. Set Difference (-):

o Returns rows that exist in the first relation but not in the second.
o Syntax: relation1 - relation2
o Example:

SQL

SELECT CustomerID, CustomerName FROM AllCustomers

EXCEPT
SELECT CustomerID, CustomerName FROM VIPCustomers;

6. Cartesian Product (×):

o Combines each row of one relation with each row of another relation.
o Syntax: relation1 × relation2
o Example:

SQL

SELECT * FROM Customers CROSS JOIN Orders;

Join Operators

Joins combine rows from two or more relations based on a related attribute.

1. Theta Join (⪰θ):

o Most general join operation, allowing arbitrary comparison operators (θ) between
attributes.
o Syntax: relation1 ⪰θ relation2
o Example:
 SQL

SELECT * FROM Orders O, Customers C

WHERE O.CustomerID = C.CustomerID;

2. Equijoin (=):
o A specific type of theta join where the comparison operator is equality (=).
o Syntax: relation1 = relation2
o Example:

SQL

SELECT * FROM Orders O JOIN Customers C ON O.CustomerID =

C.CustomerID;

3. Natural Join (⋈):

o An equijoin that implicitly joins on all common attributes.
o Syntax: relation1 ⋈ relation2
o Example:

SQL

SELECT * FROM Orders NATURAL JOIN Customers;

4. Outer Join:
o Preserves rows from one relation even if there's no matching row in the other.
o Types:
▪ Left Outer Join (⟕): Preserves all rows from the left relation.
▪ Right Outer Join (⟖): Preserves all rows from the right relation.
▪ Full Outer Join (⟗): Preserves all rows from both relations.

Innovative Explanation of Join Types

Imagine two tables: Customers and Orders.

• Equijoin: Like matching socks from two piles based on color.

• Natural Join: Like automatically matching socks based on color and size.
• Left Outer Join: Like keeping all the left socks, even if there's no matching right sock.
• Right Outer Join: Like keeping all the right socks, even if there's no matching left sock.
• Full Outer Join: Like keeping all socks, regardless of whether they have a match.

QUESTION NUMBER 1(E) :

Explain group and analytical functions with the help of appropriate and
catchy examples.
Group and Analytical Functions in Relational Databases

Group and analytical functions are powerful tools in SQL that allow you to aggregate and
analyze data in various ways.

Group Functions

Group functions operate on a set of rows and return a single value. They are commonly used
with the GROUP BY clause to categorize data into groups.

Common Group Functions:

1. COUNT: Counts the number of rows.

SQL

SELECT COUNT(*) FROM Customers; -- Counts all customers

2. SUM: Calculates the sum of a numeric column.

SQL

SELECT SUM(OrderAmount) FROM Orders; -- Total order amount

3. AVG: Calculates the average of a numeric column.

SQL

SELECT AVG(Age) FROM Employees; -- Average age of employees

4. MIN: Finds the minimum value in a column.

SQL

SELECT MIN(Salary) FROM Employees; -- Lowest salary

5. MAX: Finds the maximum value in a column.

SQL

SELECT MAX(OrderDate) FROM Orders; -- Latest order date

Analytical Functions

Analytical functions operate on a set of rows and return a value for each row, based on
calculations across a set of rows. They are often used to compare values within a group or across
groups.
Common Analytical Functions:

1. RANK: Assigns a rank to each row within a partition, starting from 1.

SQL

SELECT EmployeeID, Salary, RANK() OVER (ORDER BY Salary DESC) AS

SalaryRank
FROM Employees;

2. DENSE_RANK: Similar to RANK, but doesn't skip ranks.

3. ROW_NUMBER: Assigns a sequential number to each row within a partition, starting
from 1.
4. LAG: Accesses data from a previous row within a partition.

SQL

SELECT EmployeeID, Salary, LAG(Salary) OVER (ORDER BY EmployeeID) AS

PreviousSalary
FROM Employees;

5. LEAD: Accesses data from a subsequent row within a partition.

6. PARTITION BY: Divides the result set into partitions based on specified columns.
7. ORDER BY: Sorts the rows within each partition.

Example: Analyzing Sales Data

Consider a Sales table with columns ProductID, SalesAmount, and OrderDate.

To analyze sales trends over time, we can use analytical functions:

SQL
SELECT
ProductID,
SalesAmount,
OrderDate,
RANK() OVER (PARTITION BY ProductID ORDER BY SalesAmount DESC) AS
ProductRank,
LAG(SalesAmount) OVER (PARTITION BY ProductID ORDER BY OrderDate) AS
PreviousSales
FROM
Sales;

This query will rank products by their sales amount within each product category and show the
previous sales amount for each product.
 QUESTION NUMBER 2 :

HEALTH CARE MANAGEMENT SYSTEM

Entity Classes:

• Patient
o PatientID (PK)
o Name
o DateOfBirth
o ContactDetails
o InsuranceInformation
• Appointment
o AppointmentID (PK)
o Date
o Time
o Purpose
o HealthcareProfessionalID (FK)
• HealthcareProfessional
o HealthcareProfessionalID (PK)
o Name
o Specialization
o DepartmentID (FK)
• Department
o DepartmentID (PK)
o Name
• MedicalRecord
o MedicalRecordID (PK)
o PatientID (FK)
• MedicalRecordEntry
o EntryID (PK)
o MedicalRecordID (FK)
o Date
o Description
o HealthcareProfessionalID (FK)
• Bill
o BillID (PK)
o Date
o TotalAmount
o PatientID (FK)
• InsuranceClaim
o ClaimID (PK)
o BillID (FK)
 o InsuranceProvider
o ClaimStatus
• Medication
o MedicationID (PK)
o Name
o Dosage
o PrescriptionDate
• LabTest
o TestID (PK)
o TestName
o OrderDate
• TestResult
o ResultID (PK)
o TestID (FK)
o ResultDate
o ResultValue
• EmergencyCase
o CaseID (PK)
o PatientID (FK)
o AdmissionDate
o EmergencyLevel

Relationships and Cardinalities:

1. Patient - Appointment: One-to-Many (A patient can have many appointments, but an

appointment belongs to one patient.)
2. HealthcareProfessional - Appointment: One-to-Many (A healthcare professional can
have many appointments, but an appointment is scheduled by one healthcare
professional.)
3. HealthcareProfessional - Department: Many-to-One (Many healthcare professionals
can belong to one department, but a department can have many healthcare professionals.)
4. Patient - MedicalRecord: One-to-One (A patient has one medical record, and a medical
record belongs to one patient.)
5. MedicalRecord - MedicalRecordEntry: One-to-Many (A medical record can have
many entries, but an entry belongs to one medical record.)
6. MedicalRecordEntry - HealthcareProfessional: Many-to-One (Many entries can be
made by one healthcare professional, but an entry is made by one healthcare
professional.)
7. Patient - Bill: One-to-Many (A patient can have many bills, but a bill belongs to one
patient.)
8. Bill - InsuranceClaim: One-to-Many (A bill can have many insurance claims, but an
insurance claim is associated with one bill.)
9. Patient - Medication: Many-to-Many (A patient can be prescribed many medications,
and a medication can be prescribed to many patients.)
 10. HealthcareProfessional - Medication: Many-to-Many (A healthcare professional can
prescribe many medications, and a medication can be prescribed by many healthcare
professionals.)
11. Patient - LabTest: Many-to-Many (A patient can undergo many lab tests, and a lab test
can be performed on many patients.)
12. HealthcareProfessional - LabTest: Many-to-Many (A healthcare professional can order
many lab tests, and a lab test can be ordered by many healthcare professionals.)
13. LabTest - TestResult: One-to-Many (A lab test can have many test results, but a test
result belongs to one lab test.)
14. Patient - EmergencyCase: One-to-Many (A patient can have many emergency cases,
but an emergency case belongs to one patient.)

Additional Considerations:

• Weak Entity: MedicalRecord could be considered a weak entity as it depends on

Patient to exist.
• Derived Attribute: The TotalAmount in Bill could be derived from the services
rendered and medications prescribed.
QUESTION NUMBER 2 PART B

COFFEE MANAGEMENT SYSTEM

a) Entity Classes and Attributes:

1. Employee

Employee_ID (Primary Key)

Name
Address
Phone_Number
Role
Salary
2. Product

Product_ID (Primary Key)

Name
Description
Price
Category
3. Coffee_Variety

Coffee_Variety_ID (Primary Key)

Product_ID (Foreign Key)
Brew_Time
Intensity
Recommended_Add_ons
4. Customer

Customer_ID (Primary Key)

Name
Phone_Number
Email_Address
Loyalty_Points
5. Invoice

Invoice_ID (Primary Key)

Date
Total_Amount
Payment_Method
Customer_ID (Foreign Key)
6. Supplier

Supplier_ID (Primary Key)

Name
Contact_Information
Type_of_Goods_Supplied
7. Inventory
Item_ID (Primary Key)
Description
Quantity_in_Stock
Reorder_Level
Supplier_ID (Foreign Key)

8. Daily_Special

Special_ID (Primary Key)

Date
Product_ID (Foreign Key)
Special_Price
b) Necessary Relationships:

Employee - Role: An employee can have one role, and a role can be assigned to
many employees.
Product - Supplier: A product can be supplied by one or more suppliers, and a
supplier can supply many products.
Invoice - Product: An invoice can contain many products, and a product can be part
of many invoices.
Customer - Invoice: A customer can generate many invoices, and an invoice is
generated for one customer.
Inventory - Supplier: An inventory item is supplied by one supplier, and a supplier
can supply many inventory items.
Product - Coffee_Variety: A product (coffee) can have many varieties, and a coffee
variety belongs to one product.
Invoice - Daily_Special: An invoice can include one or more daily specials, and a
daily special can be part of many invoices.
c) Connectivity for Each Relationship:

Many-to-One
Many-to-Many
Many-to-Many
One-to-Many
Many-to-One
One-to-Many
Many-to-Many
d) Relationship Names:

Has_Role
Supplied_By
Contains
Generates
Supplied_By
Is_Variety_Of
Includes
QUESTION NUMBER 2 PART C
Entity Classes and Attributes:

1. Event

Event_ID (Primary Key)

Name
Date
Time
Type (Wedding, Corporate Meeting, Concert)
2. Event_Planner

Planner_ID (Primary Key)

Name
Contact_Information
3. Venue

Venue_ID (Primary Key)

Name
Address
Capacity
Booking_Options

4. Supplier

Supplier_ID (Primary Key)

Name
Contact_Information
Services_Offered

5. Attendee

Attendee_ID (Primary Key)

Name
Contact_Information

6. Ticket

Ticket_ID (Primary Key)

Event_ID (Foreign Key)
Attendee_ID (Foreign Key)
Ticket_Type
Price
Purchase_Date
Payment_Status

7. Feedback

Feedback_ID (Primary Key)

Event_ID (Foreign Key)
Attendee_ID (Foreign Key)
Rating
Comment

8. Sponsor

Sponsor_ID (Primary Key)

Name
Contact_Information

9. Marketing_Campaign

Campaign_ID (Primary Key)

Name
Start_Date
End_Date
Marketing_Channels
Relationships and Connectivity:

Event - Event_Planner: Many-to-Many (An event can have multiple planners, and
a planner can work on multiple events.)
Event - Venue: Many-to-Many (An event can be held at multiple venues, and a
venue can host multiple events.)
Event - Supplier: Many-to-Many (An event can involve multiple suppliers, and a
supplier can provide services for multiple events.)
Event - Attendee: Many-to-Many (An attendee can attend multiple events, and an
event can have multiple attendees.)
Event - Ticket: One-to-Many (An event can have many tickets, and a ticket is
associated with one event.)
Event - Feedback: One-to-Many (An event can receive many feedback, and a
feedback is associated with one event.)
Event - Sponsor: Many-to-Many (An event can have multiple sponsors, and a
sponsor can sponsor multiple events.)
Event - Marketing_Campaign: Many-to-Many (A marketing campaign can target
multiple events, and an event can be promoted by multiple campaigns.)
Relationship Names:

Is_Planned_By
Is_Held_At
Involves
Attends
Has_Ticket
Receives_Feedback
Is_Sponsored_By
Is_Promoted_By

QUESTION NUMBER 3 PART 4

Entities:

Author:

Email_ID (Primary Key)

First_Name
Last_Name
Paper:

Paper_ID (Primary Key)

Title
Abstract
File_Name
Contact_Author_Email (Foreign Key referencing Author)

Reviewer:

Reviewer_Email (Primary Key)

First_Name
Last_Name
Phone_Number
Affiliation
Topics_of_Interest

Review:

Review_ID (Primary Key)

Paper_ID (Foreign Key referencing Paper)
Reviewer_Email (Foreign Key referencing Reviewer)
Technical_Merit_Rating
Readability_Rating
Originality_Rating
 Relevance_Rating
Overall_Recommendation
Committee_Comment
Author_Feedback
Relationships:

Author - Paper: Authored_By (A paper is authored by multiple authors)

MANY TO MAY
Reviewer - Paper: Reviews (A reviewer reviews multiple papers) MANY
TO MANY
Paper - Review: Receives_Review (A paper receives multiple
reviews) ONE TO MANY
QUESTION 2 PART 5
Entities:

User:

User_ID (Primary Key)

Username
Email
Password
Subscription_Plan
Join_Date
Country
Playlist:

Playlist_ID (Primary Key)

Name
Creation_Date
User_ID (Foreign Key referencing User)

Song:

Song_ID (Primary Key)

Title
Duration
Release_Date
Album_ID (Foreign Key referencing Album)
Album:

Album_ID (Primary Key)

Name
Release_Date
Artist_ID (Foreign Key referencing Artist)
Artist:

Artist_ID (Primary Key)

Name
Primary_Genre
Debut_Year
Genre:

Genre_ID (Primary Key)

Name

Review:

Review_ID (Primary Key)

Rating
Comment
Review_Date
User_ID (Foreign Key referencing User)
Song_ID (Foreign Key referencing Song)

Listening_History:

History_ID (Primary Key)

User_ID (Foreign Key referencing User)
Song_ID (Foreign Key referencing Song)
Play_Date
Play_Count
Play_Duration

Subscription_Plan:

Plan_ID (Primary Key)

Name
Monthly_Cost
Ads_Enabled
Features

Relationships and Their Names:

User - Playlist: One-to-Many (A user can have many playlists, but a playlist
belongs to one user.) Owns
Playlist - Song: Many-to-Many (A playlist can contain many songs, and a song can
be in many playlists.) Contains
Album - Song: One-to-Many (An album contains many songs, but a song belongs
to one album.) Contains
Artist - Album: One-to-Many (An artist can release many albums, but an album is
released by one artist.) Releases
Song - Genre: Many-to-Many (A song can belong to multiple genres, and a genre
can have many songs.) Belongs_To
User - Review: One-to-Many (A user can write many reviews, but a review is
written by one user.) Writes
Song - Review: One-to-Many (A song can receive many reviews, but a review is
for one song.) Receives
User - Listening_History: One-to-Many (A user can have many listening history
entries, but a listening history entry is for one user.) Has
Song - Listening_History: Many-to-Many (A song can be listened to by many
users, and a user can listen to many songs.) Is_Listened_To
User - Subscription_Plan: One-to-One (A user can have one subscription plan, and
a subscription plan can be assigned to one user.) Subscribes_To
QUESTION NUMBER 2 PART 6

Entities:

1. Vehicle:
o VehicleID (PK)
o VehicleType
o LicensePlate
o OdometerReading
2. Department:
o DepartmentID (PK)
o DepartmentName
3. Faculty:
o FacultyID (PK)
o Name
o DepartmentID (FK)
4. Reservation:
o ReservationID (PK)
o DepartmentID (FK)
o FacultyID (FK)
o VehicleID (FK)
o ExpectedDepartureDate
o Destination
5. TripCompletionForm:
o TripCompletionFormID (PK)
o ReservationID (FK)
o StartOdometerReading
o EndOdometerReading
o MaintenanceComplaints
o FuelPurchased
o CreditCardNumber
6. MaintenanceLog:
o MaintenanceLogID (PK)
o VehicleID (FK)
o Description
o InitialLogDate
o CompletionDate
o MechanicID (FK)
7. MaintenanceDetail:
o MaintenanceDetailID (PK)
o MaintenanceLogID (FK)
o MaintenanceItem
o PartUsed
o MechanicID (FK)
8. Part:
 o PartID (PK)
o PartName
o MinimumQuantity
9. Mechanic:
o MechanicID (PK)
o Name
o Authorization

Identifying Relationships and Cardinalities

1. Department - Faculty: One-to-Many (One department can have many faculty members, but a
faculty member belongs to only one department.)
2. Department - Reservation: One-to-Many (One department can make many reservations, but a
reservation is made by one department.)
3. Faculty - Reservation: One-to-Many (One faculty member can make many reservations, but a
reservation is made by one faculty member.)
4. Vehicle - Reservation: One-to-Many (One vehicle can be reserved for many trips, but a
reservation is for one specific vehicle.)
5. Reservation - TripCompletionForm: One-to-One (One reservation leads to one trip completion
form, and one trip completion form is associated with one reservation.)
6. Vehicle - MaintenanceLog: One-to-Many (One vehicle can have many maintenance logs, but a
maintenance log is for one specific vehicle.)
7. MaintenanceLog - MaintenanceDetail: One-to-Many (One maintenance log can have many
maintenance details, but a maintenance detail is associated with one maintenance log.)
8. Mechanic - MaintenanceLog: Many-to-Many (Many mechanics can work on one maintenance
log, and one mechanic can work on many maintenance logs.)
9. Mechanic - MaintenanceDetail: Many-to-Many (Many mechanics can work on one maintenance
detail, and one mechanic can work on many maintenance details.)
10. Part - MaintenanceDetail: Many-to-Many (Many parts can be used in one maintenance detail,
and one part can be used in many maintenance details.)