Scribd
Upload
10 views

DBMS Lab Assignment 1- ER Diagram

This document outlines the process of converting an ER model to a relational schema in database design, detailing the treatment of entities, attributes, and relationships. It provides rules for handling various types of attributes and relationships, including multi-valued, 1:1, 1:N, and N:N relationships, along with practical examples and assignments for students. Additionally, it includes specific implementation questions for creating ER diagrams and relational schemas for different scenarios.

Uploaded by

Anuska
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
10 views

DBMS Lab Assignment 1- ER Diagram

This document outlines the process of converting an ER model to a relational schema in database design, detailing the treatment of entities, attributes, and relationships. It provides rules for handling various types of attributes and relationships, including multi-valued, 1:1, 1:N, and N:N relationships, along with practical examples and assignments for students. Additionally, it includes specific implementation questions for creating ER diagrams and relational schemas for different scenarios.

Uploaded by

Anuska
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 6

Department of Computer Science & Information Technology

DBMS Lab Assignment - 1


ER to Relational Model Conversion
The ER Model is intended as a description of real-world entities. Although it is constructed in
such a way as to allow easy translation to the relational schema model, this is not an entirely
trivial process. The ER diagram represents the conceptual level of database design meanwhile
the relational schema is the logical level for the database design. We will be following the
simple rules:

1. Entities and Simple Attributes:

An entity type within ER diagram is turned into a table. You may preferably keep the same
name for the entity or give it a sensible name but avoid DBMS reserved words as well as avoid
the use of special characters. Each attribute turns into a column (attribute) in the table. The
key attribute of the entity is the primary key of the table which is usually underlined. It can be
composite if required but can never be null.

It is highly recommended that every table should start with its primary key attribute
conventionally named as TablenameID.

Taking the following simple ER diagram:

The initial relational schema is expressed in the following format writing the table names with
the attributes list inside a parentheses as shown below for
Persons( personid , name, lastname, email )

Persons and Phones are Tables. name, lastname, are Table Columns (Attributes).

personid is the primary key for the table : Person

1
Department of Computer Science & Information Technology

2. Multi-Valued Attributes

A multi-valued attribute is usually represented with a double-line oval.

If you have a multi-valued attribute, take the attribute and turn it into a new entity or table of
its own. Then make a 1:N relationship between the new entity and the existing one. In simple
words. 1. Create a table for the attribute. 2. Add the primary (id) column of the parent entity
as a foreign key within the new table as shown below:

Persons( personid , name, lastname, email )


Phones ( phoneid , personid, phone )
personid within the table Phones is a foreign key referring to the personid of Persons

3. 1:1 Relationships

To keep it simple and even for better performances at data retrieval, I would personally
recommend using attributes to represent such relationship. For instance, let us consider the
case where the Person has or optionally has one wife. You can place the primary key of the
wife within the table of the Persons which we call in this case Foreign key as shown below.

Persons( personid , name, lastname, email , wifeid )


Wife ( wifeid , name )

Or vice versa to put the personid as a foreign key within the Wife table as shown below:

Persons( personid , name, lastname, email )


Wife ( wifeid , name , personid)
For cases when the Person is not married i.e. has no wifeID, the attribute can set to NULL

2
Department of Computer Science & Information Technology

4. 1:N Relationships

This is the tricky part ! For simplicity, use attributes in the same way as 1:1 relationship but
we have only one choice as opposed to two choices. For instance, the Person can have a House
from zero to many , but a House can have only one Person. To represent such relationship the
personid as the Parent node must be placed within the Child table as a foreign key but not the
other way around as shown next:

It should convert to :

Persons( personid , name, lastname, email )


House ( houseid , num , address, personid)

5. N:N Relationships

We normally use tables to express such type of relationship. This is the same for N − ary
relationship of ER diagrams. For instance, The Person can live or work in many countries.
Also, a country can have many people. To express this relationship within a relational schema
we use a separate table as shown below:

It should convert into :

3
Department of Computer Science & Information Technology

Persons( personid , name, lastname, email )


Countries ( countryid , name, code)
HasRelat ( hasrelatid , personid , countryid)

Relationship with attributes:

It is recommended to use table to represent them to keep the design tidy and clean
regardless of the cardinality of the relationship.

Practice Example

Convert the following ER diagram into database relational schema:

The relational schema for the ER Diagram is given below as:

Company( CompanyID , name , address )


Staff( StaffID , dob , address , WifeID)
Child( ChildID , name , StaffID )
Wife ( WifeID , name )
Phone(PhoneID , phoneNumber , StaffID)
Task ( TaskID , description)
Work(WorkID , CompanyID , StaffID , since )
Perform(PerformID , StaffID , TaskID )

4
Department of Computer Science & Information Technology

Assignment 1 Lab Questions


Theory Questions
1. What are ER Diagrams? What is their significance in DBMS?
2. Explain the conversion process from ER to Relational.

Implementation Question:- Draw an ER diagram for the following problem statements and
then convert them into database relational schema

1) CAR Rental Management


 One customer can rent one car.
 Each car has one manufacturer.
 Each manufacturer can manufacture many types of cars.
 Each car has its own maintenance schedule.
 The revenue is generated based on number of days the car was rented.
 The company has branches in 5 major cities.
 The companies also have 5 employees per branch.
 Initial rental requests are handled by employees.

2) SIU Library Management System.


 SIU library there can be individual institute libraries.
 Library has members.
 Library buys books of many publishers.
 Sellers sell books of many publishers.
 Library contains books
 Books are written by one/many authors.
 Authors’ books are published by publishers.

3) Online Grocery Ordering System


 Customer must orders one or more items. Each customer is identified by
his/her name. The postal address and email address of the customer are also
required for the correct placement of order.
 Items have their name and price to be shown to the customers.
 Shopping carts are created by the orders of the customers.
 Shopping carts contain at least one item.
 An order must have at least one requested item.
 Not all items have customers.
 Distinct companies produce distinct items which are differentiated by the
company’s name.
 Payment must be made via credit cards. The payment process has to be done
after the credit card’s verification.

5
Department of Computer Science & Information Technology

Common Instructions for Implementation Questions:


For Each Question:
- Draw Hand written ER Diagram
- Create tables with valid 4-5 values for each column
- Typed Relational Schema
Theory Questions & answers Can be typed one.

You might also like