1

Name: Zanib Fatima

Roll.No:309-22
Assignment no 3
Chapter no 12
Question no 1:
Four Basic Components of the ER Model:
Entities:
An entity represents a real-world object, person, place, or concept that has an
independent existence and is distinguishable from other objects.
For example, "Student," "Employee," and "Course" can be considered entities.
Entities are typically represented as rectangles in ER diagrams.

Attributes:
Attributes are the properties or characteristics that describe an entity.
For example, an "Employee" entity might have attributes like "Employee ID," "Name,"
"Address," and "Date_of_Joining."
Attributes can be of different types, such as simple, composite, derived, or multi-valued.

Relationships:
Relationships describe how entities are associated with each other.
For example, a "Student" entity may be related to a "Course" entity through an "Enrolled
in" relationship.
In ER diagrams, relationships are typically represented as diamonds, with lines
connecting them to the involved entities.

Keys:
Keys uniquely identify an entity within a database.

Primary keys
Primary keys are attributes that uniquely identify a single instance of an entity (e.g.,
"Student ID" for a "Student" entity).
 2

Foreign keys
Foreign keys are attributes in one entity that reference the primary key of another entity
to establish relationships between them.

Question no 2:
Types of Relationships with Examples
1. Unary Relationship (Recursive Relationship):
A unary relationship occurs when an entity is related to itself. In this case, the same
entity participates in the relationship.

Example:
Employee supervises Employee: In a company, an "Employee" entity can have a
relationship with another "Employee" entity, where one employee supervises another.

2. Binary Relationship:
A binary relationship involves two entities and is the most common type of relationship
in an ER model. Example:
Student enrolls in Course: Here, "Student" and "Course" are two different entities, and
the relationship "enrolls in" connects them.

3. Ternary Relationship:
A ternary relationship involves three entities. It represents a relationship that connects
three different entities simultaneously.

Example:
Doctor prescribes Medicine to Patient: In this scenario, the entities "Doctor," "Medicine,"
and "Patient" are involved in the relationship, and all three participate together in the
"prescribes" relationship.

Quaternary Relationship:
A quaternary relationship involves four entities. It is less common but still used in
complex ER models to represent relationships among four entities simultaneously.

Example:
Project requires Employee with Skill in Location: This relationship connects the entities
"Project," "Employee," "Skill," and "Location," indicating that a specific project requires
an employee who possesses a certain skill and is located in a particular place.
 3

Question no 3:
1. Entities
Notation: Entities are represented by rectangles.
Description: The name of the entity is written inside the rectangle. For example, an
entity "Student" would appear as a rectangle labeled "Student." Strong Entity: Has a

unique attribute or primary key.

Weak Entity: Represented by a rectangle with a double border, indicating that its
existence depends on a strong entity.

2. Attributes

Notation: Attributes are represented by ellipses (ovals) connected to their respective

entities.

Types of Attributes:

Simple Attribute: A simple attribute is composed of a single component with an

independent existence.

Composite Attribute: A composite attribute is composed of multiple components

each with an independent existence.

Single Valued Attribute: A single-valued attribute holds a single value for each
occurrence of an entity type.
Multi-Valued Attribute: A multi-valued attribute holds multiple values for each
occurrence of an entity type.
Derived Attribute: A derived attribute represents a value that is derivable from the
value of a related attribute or set of attributes, not necessarily in the same entity.

Question no 4:
The multiplicity constraint, also known as cardinality constraint, in an Entity-
Relationship (ER) model specifies the number of instances of one entity that can or
must be associated with each instance of another entity in a relationship. It defines the
 4

minimum and maximum number of times an entity can participate in a relationship, and
it is crucial for understanding the nature of the interaction between entities.

Types of Multiplicity Constraints:

One-to-One (1:1) Relationship:
Each instance of Entity A can be associated with at most one instance of Entity B, and
vice versa.
Example: A "Person" has one "Passport," and each "Passport" is associated with one

"Person."

One-to-Many (1: M) Relationship:

Each instance of Entity A can be associated with multiple instances of Entity B, but each
instance of Entity B is associated with only one instance of Entity A.

Example: A "Department" has many "Employees," but each "Employee" belongs to one
"Department."

Many-to-One (N: 1) Relationship:

This is the reverse of the one-to-many relationship, where multiple instances of Entity A
can be associated with a single instance of Entity B.

Example: Multiple "Students" can be supervised by one "Teacher."

Many-to-Many (M: M) Relationship:

Multiple instances of Entity A can be associated with multiple instances of Entity B.

Example: "Students" can enroll in multiple "Courses," and each "Course" can have
multiple "Students" enrolled.

Minimum and Maximum Constraints:

Multiplicity constraints also define the minimum (optional or mandatory) and maximum
(upper limit) number of times an entity can participate in a relationship.

Minimum Constraint: Indicates the minimum number of relationships an entity must

participate in (e.g., 0 means optional, 1 means mandatory).
 5

Maximum Constraint: Indicates the maximum number of relationships an entity can

participate in
(e.g., 1, N, M).

For example: a multiplicity of (0, N) for an "Employee" in a "Works on" relationship with
"Project" indicates that an employee may work on zero or more projects.

Question no 5:
Integrity constraints are rules or conditions that ensure the accuracy, validity, and
consistency of data within a database. They help maintain the integrity of the database
by restricting the types of data that can be entered or the relationships that can be
formed. Integrity constraints enforce certain conditions on data, making sure it adheres
to specified rules throughout the database's lifecycle.

Types of Integrity Constraints:

Domain Constraints:
These ensure that data values fall within a specified range or set of permissible values .

For example: an age attribute might have a constraint that only allows values between
0 and 120.

Entity Integrity Constraints:

Ensure that every entity instance can be uniquely identified.
The Primary Key constraint is a common form of entity integrity, requiring that no two
rows have the same primary key value and that primary key values are not null.

Referential Integrity Constraints:

Ensure that relationships between tables are consistent.
For example, a Foreign Key in one table must match a Primary Key in another table, or
it can be null if the relationship is optional.

Multiplicity Constraints (Cardinality Constraints):

Define the number of instances of one entity that can be associated with instances of
another entity in a relationship.
Multiplicity helps to model real-world associations between entities, ensuring data
consistency by specifying how many times an entity can participate in a relationship.
 6

One-to-One (1:1) Multiplicity:

Ensures that for each instance of an entity, there is at most one corresponding instance
of another entity.
Enforces data integrity by preventing scenarios where an entity is linked to multiple
instances when it shouldn't be.

One-to-Many (1: M) Multiplicity:

Specifies that an entity instance on the "one" side can relate to multiple instances on the
"many" side, but each instance on the "many" side relates to only one instance on the
"one" side.
Ensures data consistency by modeling relationships such as "each employee works in
one department," while allowing "a department to have many employees."

Many-to-Many (M: M) Multiplicity:

Allows multiple instances of one entity to be associated with multiple instances of
another.
Data integrity can be managed by creating an associative entity (junction table) to keep
track of the many-to-many associations.

Optional and Mandatory Participation (0 or 1):

Indicates whether the participation of an entity in a relationship is required (mandatory)
or optional.
For example: a "0" minimum means that the entity's participation is optional, while a "1"
minimum indicates mandatory participation, thereby ensuring that certain relationships
are maintained as needed.

Question no 6:
Multiplicity in an Entity-Relationship (ER) model represents both cardinality and
participation constraints for a relationship type, specifying how entities interact within a
relationship and whether their participation is mandatory or optional. It is crucial for
modeling real-world relationships accurately in a database system.

How Multiplicity Represents Cardinality and Participation Constraints:

Cardinality Constraints:
 7

Cardinality defines the number of instances of one entity that can be associated with a
given instance of another entity in a relationship.
The maximum value in the multiplicity notation (such as 1, N, or M) represents the
cardinality constraint.

One-to-One (1:1): Each instance of Entity A is related to at most one instance of Entity
B, and vice versa.

One-to-Many (1: M): Each instance of Entity A can relate to multiple instances of
Entity B, but each instance of Entity B relates to only one instance of Entity A.

Many-to-Many (M: M): Instances of Entity A can relate to multiple instances of

Entity B, and instances of Entity B can also relate to multiple instances of Entity A.
Cardinality ensures that the correct number of entity instances can be associated in the
relationship.

Multiplicity: (1, 1)
Example: A "Person" must have exactly one "Social Security Number" (SSN), and each
SSN is associated with exactly one "Person." This enforces a one-to-one relationship
with mandatory participation for both entities.

One-to-Many (1) Relationship with Optional Participation:

Multiplicity: (0, N)

Example: A "Manager" can manage zero or more "Employees" (optional

participation), but each "Employee" is managed by exactly one "Manager" (mandatory
participation on the employee side).

Many-to-Many (M) Relationship with Optional Participation:

Multiplicity: (0, N) on both sides
Example: "Students" can enroll in multiple "Courses" (0 to N), and "Courses" can have
multiple "Students" enrolled (0 to N). Here, participation for both entities is optional.

Question no 7:
 8

A relationship type with attributes occurs when the association between entities has
properties of its own that need to be captured. In such cases, the attributes are directly
associated with the relationship rather than the individual entities.

Example of a Relationship Type with Attributes:

Scenario: Consider a university database where Students enroll in Courses.

• Entities:
o Student: Attributes include Student ID, Name, and Major.
o Course: Attributes include Course-ID, Course_Name, and Credits. 
:
o Enrolls in: Represents the association between Student and Course.
• Attributes of the Relationship:
o The Enrolls_in relationship can have attributes such as:
 Enrollment_Date: The date on which the student enrolled in the
course.
 Grade: The grade the student received for the course.

ER Diagram Representation:
In the ER diagram:

• The Student entity is represented as a rectangle labeled "Student."

• The Course entity is represented as a rectangle labeled "Course."
• The Enrolls_in relationship is represented as a diamond labeled "Enrolls_in,"
with lines connecting it to both "Student" and "Course."
• The relationship attributes, Enrollment_Date and Grade, are represented as
ovals connected to the "Enrolls_in" diamond.

Explanation:
• Here, Enrollment Date and Grade are specific to the association between the
student and the course, not the individual entities. Therefore, they are attributes
of the Enrolls in relationship.
• This modeling approach allows capturing additional details about the enrollment
process, making the database design more accurate and comprehensive.

Question no 8:
Entity-Relationship (ER) Model:
 9

• Definition: The ER model is a conceptual framework used for designing and

describing the structure of a database. It defines the rules, components, and
relationships needed to represent data in a structured form.
• Components: The ER model consists of:
o Entities: Objects that represent real-world concepts (e.g., "Student,"
"Course"). o Attributes: Characteristics or properties of entities (e.g.,
"Student ID," "Course Name").
o Relationships: Associations between entities (e.g., "enrolls in"). o Keys
and Integrity Constraints: Rules that ensure data integrity, such as
primary keys and foreign keys.
• Purpose: The primary goal of the ER model is to provide a high-level
conceptual representation of data, making it easier to understand the structure
and relationships within a system before the actual database is created.

Entity-Relationship (ER) Diagram:

• Definition: The ER diagram is a visual representation of the ER model. It is a
graphical depiction that illustrates the entities, attributes, and relationships
defined in the ER model.
• Components Representation:
o Entities: Represented as rectangles. o Attributes: Represented as
ellipses (ovals) connected to the corresponding entities.
o Relationships: Represented as diamonds with lines connecting them to
the entities involved.
o Cardinality and Participation Constraints: Often represented near the
connecting lines to indicate the number of instances and participation
requirements.
• Purpose: The ER diagram serves as a visual tool to help designers and
stakeholders understand the database's structure, relationships, and constraints
more intuitively. It acts as a blueprint for database development.

Key Differences:
Aspect ER Model ER Diagram
Conceptual framework for
Graphical representation of the ER
Definition designing
model
databases
Describes the structure and rules Provides a visual depiction of the
Purpose of the database database design
Consists of entities, attributes, Uses rectangles, ovals, and diamonds to
Components represent entities, attributes, and
relationships, and constraints relationships
Used for conceptual database Used for visualizing and communicating
Usage design database structure
 10

In summary, the ER model defines the conceptual structure and rules of a database,
while the ER diagram is the graphical illustration of that model, helping to visualize and
understand the database's design.

Question no 9:
Fan traps and chasm traps are potential issues that can occur in an Entity-
Relationship (ER) model when designing a database. They arise due to improper
representation of relationships, leading to ambiguities in understanding the associations
between entities.

1. Fan Trap
• Definition: A fan trap occurs when a model represents
a relationship in such a way that it becomes unclear
which instances of one entity are associated with which
instances of another entity. It happens when a single
entity is involved in two or more one-to-many
relationships that converge at a common entity, making
it difficult to identify the correct path for data association.
• Example:
o Suppose we have three entities: Department, Manager, and Employee.
o There are two relationships:
1. Department has Manager (One-to-Many): Each department has
one manager.
2. Department employs Employee (One-to-Many): Each department
can employ multiple employees.
o The fan trap occurs because the relationships do not explicitly connect the
Manager to the Employee through the Department. We cannot directly
determine which employees a specific manager supervises. 
Resolution:
o To resolve a fan trap, we need to add a new relationship or restructure the
existing relationships to correctly represent the intended association.
o In the example, we can introduce a direct relationship between Manager
and Employee (e.g., Manager supervises Employee) to make the
connections explicit.
2. Chasm Trap
• Definition: A chasm trap occurs when a model
allows for possible gaps in the relationships
between entities, leading to missing associations.
It arises when an expected relationship path
between entities is not properly represented,
 11

resulting in certain instances not being reachable

or connected.
• Example:
o Consider three entities: Branch, Department, and Employee.
o There are two relationships:
1. Branch contains Department (One-to-Many): Each branch can
contain multiple departments.
2. Department employs Employee (One-to-Many): Each department
can employ multiple employees.
o The chasm trap occurs if there is no department associated with a
particular branch, making it impossible to determine which employees
belong to that branch.  Resolution:
o To resolve a chasm trap, we need to ensure that the relationships
explicitly capture the intended associations. o In this case, we could add
a direct relationship between Branch and Employee (e.g., Branch has
Employee) to ensure all employees are associated with a branch, even if
there are no departments present.

Summary of Resolution Approaches:

• Fan Trap: o Restructure the relationships to
correctly represent the associations.
o Add new relationships where necessary to avoid ambiguity.
• Chasm Trap:
o Add direct relationships to ensure all expected associations are explicitly
captured.
o Make sure that participation constraints reflect the real-world requirements
to avoid missing connections.

Question no 10:
Let's create the Entity-Relationship (ER) models step by step for each description and
then combine them into a single ER model.

(a) Each company operates four departments, and each department belongs to
one company.
• Entities:
o Company o Department  Relationships: o
Company operates Department  Cardinality:
o One Company operates multiple Departments (1) o

Each Department belongs to exactly one Company (N:1) ER

Model for (a):
 12

Lua
Copy code
+----------+ operates +-----------+
| Company |----------------------| Department|
+----------+ (1: N) +-----------+

(b) Each department in part (a) employs one or more employees, and each
employee works for one department.
• Entities: o Department o
Employee  Relationships: o
Department employs Employee 
Cardinality:
o Each Department employs one or more Employees (1)

o Each Employee works for exactly one Department (N:1) ER

Model for (b):
Lua
Copy code
+-----------+ employs +----------+
| Department|---------------------| Employee |
+-----------+ (1: N) +----------+

(c) Each of the employees in part (b) may or may not have one or more
dependents, and each dependent belongs to one employee.
• Entities:
o Employee o Dependent  Relationships: o
Employee has Dependent  Cardinality:
o Each Employee may have zero or more Dependents (0)

o Each Dependent belongs to exactly one Employee (N:1) ER

Model for (c):
Lua
Copy code
+----------+ has +----------+
| Employee |----------------------| Dependent|
+----------+ (0: N) +----------+

(d) Each employee in part (c) may or may not have an employment history.
• Entities:
o Employee o Employment_History 
Relationships: o Employee has Employment_History 
Cardinality:
 13

Each Employee may have zero or more records in

o
Employment_History (0

ER Model for (d):

Lua
Copy code
+----------+ has +---------------------+
| Employee |----------------------| Employment_History |
+----------+ (0: N) +---------------------+ (e)

Combined ER Model for (a), (b), (c), and (d):

Here’s how the combined ER model looks:

Lua
Copy code
+----------+ operates +-----------+ employs +-------
---+ has +----------+
| Company |----------------------| Department|----------------------|
Employee |---------------------| Dependent|
+----------+ (1: N) +-----------+ (1: N) +-----
-----+ (0: N) +----------+
|
| has
|--------
----------+
|
|
| (0:N)
|
+--------
----------+
Em
ployment_History
Explanation of the Combined ER Model:
1. Company operates Department (1): Each company operates multiple
departments, but each department belongs to one company.
2. Department employs Employee (1): Each department employs multiple
employees, but each employee works for one department.
3. Employee has Dependent (0): An employee may have zero or more
dependents, and each dependent belongs to one employee.
4. Employee has Employment History (0): An employee may have zero or more
records in their employment history.

Question no 11:
 14

To develop a database system for the university that keeps track of student registration
and accommodation records, let's identify the main entity types, relationship types, and
draw an ER diagram based on your requirements.

(a) Main Entity Types

1. Student o Attributes: Student-ID (Primary Key), Name, IQ,
Enrollment_Date, etc.
2. Course o Attributes: Course-ID (Primary Key), Course_Name,
Credits, etc.
3. Faculty
o Attributes: Faculty-ID (Primary Key), Faculty-Name, etc.
4. Hostel o Attributes: Hostel-ID (Primary Key), Hostel-Name,
Location, etc.
5. Room
o Attributes: Room-ID (Primary Key), Room-Number, Type, etc.
6. Furniture o Attributes: Furniture-ID (Primary Key), Type,
Quantity, etc.

(b) Main Relationship Types and Multiplicity

1. Student enrolls in Course
o Relationship:
Enrolls o Multiplicity:
 Each Student can enroll in multiple Courses (0).
 Each Course can have multiple Students enrolled (0).
2. Course belongs to
Faculty o Relationship:
Offers o Multiplicity:
 Each Course is offered by one Faculty
(N:1).  Each Faculty can offer multiple
Courses (1).
3. Student stays in Hostel
o Relationship:
Resides o
Multiplicity:
 Each Student can reside in one Hostel (1:1).
 Each Hostel can accommodate multiple Students (0).
4. Hostel has Room o
Relationship: Contains o
Multiplicity:
 Each Hostel contains multiple Rooms (1).
 Each Room belongs to exactly one Hostel (N:1).
 15

5. Room has Furniture o

Relationship: Contains o
Multiplicity:
 Each Room can have multiple Furniture items (0).
 Each Furniture item can be associated with multiple Rooms (0).

Assumptions
• A Student can reside in only one Hostel at a time.
• Each Room has its own distinct set of Furniture.
• There are no limits on how many Courses a Student can enroll in.
• The University owns all the hostels, but the faculties are not responsible for
student accommodation.

(c) ER Diagram Representation

Now, let's draw the ER diagram based on the identified entities and relationships.
sql Copy
code
+-----------+ enrolls +----------+
| Student |---------------------| Course |
|-----------| (0:N) |----------|
| Student-ID| | Course-ID |
| Name | | Course-Name|
| IQ | | Credits | |
Enrollment_Date| +----------+
+-----------+
|
| resides
|----------------
| (1:1)
|
+-----------+
| Hostel |
|-----------|
| Hostel-ID |
| Hostel-Name|
| Location |
+-----------+
|
| contains
|----------------
| (1:N)
|
+-----------+
| Room |
|-----------|
| Room-ID |
| Room-Number|
| Type |
 16

+-----------+
|
| contains
|----------------
| (0:N)
|
+-----------+
| Furniture |
|------------|
| Furniture-ID|
| Type |
| Quantity |
+-----------+

+-----------+
| Faculty |
|-----------|
| Faculty-ID|
| Faculty-Name |
+-----------+
|
| offers
|----------------
| (1:N)
|
+----------+

Explanation of the ER Diagram:

• The Student entity is connected to the Course entity through the Enrolls
relationship, indicating that students can enroll in multiple courses.
• The Course entity is connected to the Faculty entity through the Offers
relationship, showing which faculty offers which courses.
• The Student entity is connected to the Hostel entity through the Resides
relationship, indicating where students live.
• The Hostel entity contains multiple Rooms, represented by the Contains
relationship.
• Each Room can contain multiple pieces of Furniture, showing what is present in
each room.

Question no 12:
To design a database for the DVD rental company based on the provided case study, let's break
down the requirements step by step.

(a) Identify the Main Entity Types

1. Branch o Represents the different branches of
the DVD rental company.
 17

2. Staff o Represents the staff members, including

the manager.
3. DVD
o Represents the DVDs available for rent.
4. Member
o Represents the customers who register to rent DVDs.
5. Rental o Represents the rental transaction for
DVDs.

(b) Identify Main Relationship Types

1. Branch has Staff o Each branch has
multiple staff members.
2. Branch has DVD Stock o Each branch has
a stock of DVDs.
3. Member registers at Branch o Each
member registers at one branch.
4. Member rents DVD o A member can
rent multiple DVDs, and each DVD can be
rented by multiple members over time.

ER Diagram Representation (without multiplicity)

Here's the basic ER diagram structure representing the entity types and relationships:
sql Copy
code
+----------+ has +----------+
| Branch |---------------| Staff |
+----------+ +----------+
| Branch-No| | Staff-No |
| Address | | Name |
| Telephone | | Position |
+----------+ | Salary |
+----------+

+----------+
| DVD |
+----------+
| Catalog-No|
| DVD-No |
| Title |
| Category |
| Daily-Rental|
| Cost |
| Status |
| Main-Actors|
| Director |
+----------+
 18

+----------+
| Member |
+----------+
| Member-No |
| First-Name|
| Last-Name |
| Address |
| Register-Date|
+----------+

+----------+
| Rental | +----------+
| Rental-No |
| Member-No |
| DVD-No |
| Rental-Date|
| Return-Date|
| Title |
| Daily-Rental|
+----------+

(c) Determine the Multiplicity Constraints

1. Branch has Staff o Multiplicity: One Branch has many Staff (1), and each Staff
belongs to one Branch (N:1).
2. Branch has DVD Stock o Multiplicity: One Branch has many DVDs (1), and each
DVD can be available in multiple Branches (N) due to multiple copies.
3. Member registers at Branch o Multiplicity: Each Member registers at one
Branch (N:1), but one Branch can have many Members (1).
4. Member rents DVD o Multiplicity: A Member can rent many DVDs (0), and
each DVD can be rented by many Members (0).

ER Diagram Representation with Multiplicity

Here’s the ER diagram with multiplicity indicated:

sql Copy
code
+----------+ has +----------+
| Branch |1-------------N| Staff |
+----------+ +----------+
| Branch-No| | Staff-No |
| Address | | Name |
| Telephone | | Position |
+----------+ | Salary |
+----------+
|
|
 19

1..N|
|
|
+----------+
| DVD |
+----------+
| Catalog-No|
| DVD-No |
| Title |
| Category |
| Daily-Rental|
| Cost |
| Status |
| Main-Actors|
| Director |
+----------+

+----------+
| Member |
+----------+
| Member-No |
| First-Name|
| Last-Name |
| Address |
| Register-Date|
+----------+
|
|1
|
|
| rents
|0..N
|
+----------+
| Rental |
+----------+
| Rental-No |
| Member-No |
| DVD-No |
| Rental-Date|
| Return-Date|
| Title |
| Daily-Rental|
+----------+

(d) Identify Attributes and Associate Them

Now let's identify the attributes associated with each entity and relationship type in the ER
diagram:

 Branch:
o Attributes:
 20

 Branch-No (Primary Key)

 Address (Street, City, State, Zip Code)
 Telephone  Staff:
o Attributes:
 Staff-No (Primary Key)
 Name
 Position  Salary  DVD: o Attributes:
 Catalog-No (Primary Key)
 DVD-No (Primary Key, Unique Copy Identifier)
 Title
 Category (e.g., Action, Drama, etc.)
 Daily-Rental
 Cost
 Status(e.g., Available, Rented)
 Main-Actors  Director  Member: o Attributes:
 Member-No (Primary Key)
 First-Name
 Last-Name  Address  Register-Date  Rental:
o Attributes:
 Rental-No (Primary Key)  Member-No (Foreign Key)
 DVD-No (Foreign Key)
 Rental-Date
 Return-Date
 Title (Redundant, could be derived from DVD)
 Daily-Rental (Redundant, could be derived from DVD)

(e) Determine Candidate and Primary Key Attributes

• Branch:
o Primary Key: Branch-No
 Staff:
o Primary Key: Staff-No
• DVD:
o Primary Key: Catalog-No,

DVD-No(Composite Key) 
Member:
o Primary Key: Member-No
 Rental:
o Primary Key: Rental-No
 21

(f) Combined ER Diagram

Now, we will combine all elements into a single ER diagram:
sql
Copy code
+----------+ has +----------+
| Branch |1-------------N| Staff |
+----------+ +----------+
| Branch-No| | Staff-No |
| Address | | Name |
| Telephone | | Position |
+----------+ | Salary |
+----------+
|
|
1..N|
|
|
+----------+
| DVD |
+----------+
| Catalog-No|
| DVD-No |
| Title |
| Category |
| Daily-Rental|
| Cost |
| Status |
| Main-Actors|
| Director |
+----------+
|
|0..N
|
|
+----------+
| Member |
+----------+
| Member-No |
| First-Name|
| Last-Name |
| Address |
| Register-Date|
+----------+
|
|1 |
|
| rents
|0..N
|
+----------+
| Rental |
+----------+
 22

| Rental-No |
| Member-No |
| DVD-No |
| Rental-Date|
| Return-Date|
| Title |
| Daily-Rental|

+----------+ Assumptions:
1. Each branch can have multiple staff members, but each staff member works for
only one branch.
2. Each DVD can have multiple copies (DVD-No) in different branches.
3. A member can rent multiple DVDs at a time, but only up to ten.
4. The Rental entity contains both a foreign key reference to the Member and the
DVD, allowing for the tracking of rentals and returns.

Question no 13:

To create an ER model for the parking lot system described in your request, we will
break down the requirements step by step, identify the main entity types, their
attributes, and the relationships among them.

(a) Identify the Main Entity Types

1. Parking Lot o Represents the parking lots available within
the organization.
2. Parking Space o Represents individual spaces within each
parking lot.
3. Staff Member o Represents the employees of the organization
who may request parking spaces.

(b) Identify the Attributes for Each Entity Type

1. Parking Lot o
Attributes:
 Parking-Lot-ID (Primary Key)
 Name (Unique Name of the Lot)
 Location
 Capacity  Number-of-Floors 2. Parking Space o Attributes:
 Space-Number (Primary Key, unique within a parking lot)  Parking-Lot-

ID (Foreign Key referencing Parking Lot)

 Status (e.g., Available, Reserved)
 23

3. Staff Member o
Attributes:
 Staff-Number (Primary Key, unique for each staff member)
 Name
 Telephone-Extension
 Vehicle-License-Number

(c) Identify the Relationship Types

1. Parking Lot has Parking Spaces o Each parking lot contains
multiple parking spaces. o Relationship: Contains
o Multiplicity: One Parking Lot has many Parking Spaces (1), and each Parking
Space belongs to one Parking Lot (N:1).
2. Staff Member requests Parking Space o Each staff member
can request the use of a single parking space. o
Relationship: Requests
o Multiplicity: One Staff Member can request one Parking Space (1:1), and each
Parking Space can be requested by one Staff Member (1:1).

(d) Assumptions
1. Each parking space is uniquely identified within its respective parking lot.
2. A staff member can request the sole use of one parking space at a time.
3. The status of a parking space can be either available or reserved for a staff
member.
4. Each parking lot can have multiple parking spaces.

(e) ER Diagram Representation

Now, let's represent the data requirements as a single ER diagram.
sql
Copy code
+-----------------+
| Parking Lot |
+-----------------+
| Parking-Lot-ID | 1 contains N |
| Name |------------------|
| Location | |
| Capacity | |
| Number-of-Floors| |
+-----------------+ |
|
| 1 requests 1
|-------------------|
| | v
| +-------------------+ |
 24

| Parking Space | |
+-------------------+ |
| Space-Number | |
| Parking-Lot-ID | |
| Status | |
+-------------------+ |
|
|
+---------------------+
| Staff Member |
+---------------------+
| Staff-Number |
| Name |
| Telephone-Extension |
| Vehicle-License-Number |

+---------------------+ Explanation of the ER Diagram:

• Parking Lot is the main entity that contains multiple Parking Spaces. Each
parking lot
is uniquely identified by Parking-Lot-ID.
• Parking Space is associated with a single Parking Lot and uniquely identified
by Space-Number.
• Staff Member can request the use of one Parking Space at a time, creating a
one-to-one relationship between Staff Member and Parking Space.

Question no 14:
To create an ER model representing the data used by a library based on the provided
specifications, we will identify the main entity types, their attributes, and the relationships
among them. Here’s how we can break it down: Identify the Main Entity Types

1. Book
o Represents the collection of books in the library.
2. Copy
o Represents individual copies of each book available for loan.
3. Borrower o Represents
individuals who borrow books
from the library.
4. Loan
o Represents the transaction of borrowing books.

Identify the Attributes for Each Entity Type

1. Book o Attributes:
 ISBN (Primary Key)
 25

 Title
 Edition
 Year-of-Publication 2. Copy o Attributes:
 Copy-Number (Primary Key, unique for each book copy)
 ISBN (Foreign Key referencing Book)
 Status (e.g., Available, Loaned)
 Loan-Period (Duration of loan period)
3. Borrower o
Attributes:
 Borrower-Number (Primary Key, unique for each borrower)
 Name  Address 4. Loan o Attributes:
 Loan-Number (Primary Key, unique for each loan)
 Copy-Number (Foreign Key referencing Copy)
 Borrower-Number (Foreign Key referencing Borrower)
 Loan-Date  Return-Date

Identify the Relationship Types

1. Book has Copies o each book can have multiple copies. o
Relationship: Contains
o Multiplicity: One Book has many Copies (1), and each Copy belongs to one
Book (N: 1).
2. Borrower loans Copies o a borrower can loan multiple
copies, and each copy can be loaned by one borrower at a
time. o Relationship: Loans
o Multiplicity: One Borrower can loan many Copies (1), and each Copy can be
loaned to one Borrower at a time (1:1).
3. Loan Transaction o each loan transaction involves a
borrower and a copy. o Relationship: Records o
Each loan transaction has a unique loan number.
ER Diagram Representation

Here’s the ER diagram for the library system:

sql Copy
code
+------------+ contains +------------+
| Book |1-----------------------N| Copy |
+------------+ +------------+
| ISBN | | Copy-Number |
| Title | | ISBN |
| Edition | | Status |
| Year | | Loan-Period |
+------------+ +------------+
|
 26

|1
|
|
N|
|
+---------------------+
| Loan |
+---------------------+
| Loan-Number |
| Copy-Number |
| Borrower-Number |
| Loan-Date |
| Return-Date |
+---------------------+
|
|1
|
|
N|
|
+---------------------+
| Borrower |
+---------------------+
| Borrower-Number |
| Name |
| Address |
+---------------------+

Explanation of the ER Diagram:

• Book entity represents the collection of books in the library, uniquely identified by
ISBN.
• Copy entity represents individual copies of each book, uniquely identified by Copy
Number and linked to the Book entity through ISBN.
• Borrower entity represents individuals borrowing books, uniquely identified by
Borrower-Number.
• Loan entity records the transactions of borrowing, linking Copy and Borrower
with attributes like Loan-Date and Return-Date, and is uniquely identified by
Loan-Number.