Question no 2

Creating Relations for the ER Diagram

Understanding the ER Diagram:

The given ER diagram represents a generalization/specialization hierarchy. An employee can be

specialized into two subtypes: assistant and professor. Both subtypes have additional attributes: office
for assistant and rank for professor.

Proposed Relations:

Based on the ER diagram, we can define the following relations:

1. Employee:

o Attributes: empID, name

o Primary Key: empID

2. Assistant:

o Attributes: empID, office

o Primary Key: empID

o Foreign Key: empID (references Employee)

3. Professor:

o Attributes: empID, rank

o Primary Key: empID

o Foreign Key: empID (references Employee)

Explanation:

• The Employee relation stores the common attributes for all employees.

• The Assistant and Professor relations store the specific attributes for each subtype.

• The empID attribute is used to establish the relationship between the subtypes and the
supertype. It acts as both the primary key in the subtype relations and a foreign key referencing
the Employee relation.

Advantages and Disadvantages of Different Methods for Creating Relations in

Generalization/Specialization

There are four common methods to represent generalization/specialization in relational databases:

1. Single Table:

o Advantages: Simple to implement, efficient for queries involving all subtypes.

 o Disadvantages: Wastage of space for unused attributes, potential performance issues for
queries involving specific subtypes.

2. Separate Tables:

o Advantages: Efficient for queries involving specific subtypes, avoids null values.

o Disadvantages: More complex to implement, requires joins for queries involving all
subtypes.

3. Subtype Table with Discriminator Column:

o Advantages: Combines the benefits of single and separate tables.

o Disadvantages: Requires additional column to indicate subtype, potential performance

issues for queries involving specific subtypes.

4. Inheritance View:

o Advantages: Provides a logical view of the hierarchy without physical changes to the
data.

o Disadvantages: May not be supported by all database systems, can introduce

complexities in querying and updates.

Choosing the Best Method:

The choice of method depends on factors such as:

• Query patterns: If most queries involve specific subtypes, separate tables or subtype table with
discriminator column might be better.

• Update frequency: If updates to subtypes are frequent, separate tables can reduce the impact
on other subtypes.

• Database system capabilities: Inheritance views may not be supported by all systems.

In the given example, the separate tables approach seems suitable as it avoids null values and is efficient
for queries involving specific subtypes. However, the choice might differ based on specific application
requirements and database system capabilities.
Question No 3

Analyzing the ER Diagram

Key Entities:

• Customer: Identified by customerID, with attributes name, street, and city.

• Loan: Identified by loanNumber, with attributes amount.

• Payment: Identified by pNumber, with attributes pDate and pAmount.

• Account: Identified by accountNumber, with attributes balance and startDate.

• SavingsAccount: Inherits from Account, with attribute interestRate.

• CheckingAccount: Inherits from Account, with attribute overdraftLimit.

Relationships:

• Customer borrows Loan: One-to-many relationship. A customer can borrow multiple loans, but
a loan can only be borrowed by one customer.

• Customer owns Account: One-to-many relationship. A customer can own multiple accounts, but
an account can only be owned by one customer.

• Loan pays Payment: One-to-many relationship. A loan can have multiple payments, but a
payment can only be associated with one loan.

• Account ISA SavingsAccount: One-to-one relationship. An account can either be a savings

account or a checking account, but not both.

Proposed Relations

Based on the analysis, we can define the following relations:

1. Customer:

o Attributes: customerID, name, street, city

o Primary Key: customerID

2. Loan:

o Attributes: loanNumber, amount

o Primary Key: loanNumber

o Foreign Key: customerID (references Customer)

3. Payment:

o Attributes: pNumber, pDate, pAmount

o Primary Key: pNumber

 o Foreign Key: loanNumber (references Loan)

4. Account:

o Attributes: accountNumber, balance, startDate

o Primary Key: accountNumber

o Foreign Key: customerID (references Customer)

5. SavingsAccount:

o Attributes: accountNumber, interestRate

o Primary Key: accountNumber

o Foreign Key: accountNumber (references Account)

6. CheckingAccount:

o Attributes: accountNumber, overdraftLimit

o Primary Key: accountNumber

o Foreign Key: accountNumber (references Account)

Explanation:

• The Customer, Loan, and Payment relations are straightforward, representing the core entities
and their attributes.

• The Account relation stores common attributes for both savings and checking accounts.

• The SavingsAccount and CheckingAccount relations inherit from the Account relation and add
their specific attributes.

• Foreign keys are used to establish relationships between entities.

Note:

• The assumption is made that a payment is associated with only one loan. If a payment can be
associated with multiple loans, the Payment relation would need to have a foreign key to the
Loan relation as a composite primary key.

• Attribute domains are ignored as per the prompt.

• The assumption is made that only a few null values are expected, so extra relations to handle
null values are not created.