0% found this document useful (0 votes)
21 views34 pages

DB Lecture 05

The document discusses concepts related to data dictionaries and relational schema diagrams, emphasizing their importance in database design. It includes exercises for creating Entity-Relationship Diagrams (ERDs) and explains the relationships and cardinalities between various entities in scenarios such as citizenship and student-class assignments. Additionally, it highlights the benefits of relational databases in minimizing data duplication and anomalies during updates and deletions.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views34 pages

DB Lecture 05

The document discusses concepts related to data dictionaries and relational schema diagrams, emphasizing their importance in database design. It includes exercises for creating Entity-Relationship Diagrams (ERDs) and explains the relationships and cardinalities between various entities in scenarios such as citizenship and student-class assignments. Additionally, it highlights the benefits of relational databases in minimizing data duplication and anomalies during updates and deletions.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 34

National University of

Modern Languages – NUML


(Department of Software Engineering/IT)

Engr. Sehrish Ferdous


Official E-Mail: [email protected]

Lecture - 5
 Data Dictionary

2
Data Dictionary

A data dictionary is a collection of descriptions of the data


objects or items in a data model for the benefit of
programmers and others who need to refer to them.

3
4
Continued…

5
Continued…

6
7
 Relational Schema
Diagram

8
Relational Schema Diagram

A relational schema diagram is the skeleton structure that represents


the conceptual view (transformed ERD) of the entire database.
It defines how the data is organized and how the relations among
them are associated.
It expresses about the constraints/checks that are to be applied on
the data.

9
Continued…

10
ERD Reading

11
Continued…

12
Continued…

13
Exercise
Draw the ERD (Information Engineering Standard) for the following scenarios:
i. CITY to COUNTRY (real time scenario) Cardinality and Degree of Relationship.
ii. Player plays for a at most one Cricket team, In a Cricket team at least eleven
players must play.
iii. Each patient has one or more patient histories; each instance of patient history
belongs to one patient only.
iv. An employee may be recorded as having many jobs; a particular job may be
recorded as having been held by many employees.
v. A person must be a citizen of at most one Country. A country must have one or
more than one person as citizens.

14
(Solution)
Solution of Scenario 5: -
A person must be a citizen of at
most one Country. A country must have one or more than
one person as its citizens.
Entities:-
There are two number of Entities (COUNTRY
and PERSON) which are participating in this given scenario
Degree of Relationship:-
There are two Entities participating in this relationship
so it is in Binary Relationship
Cardinality of Relationship:-
Both Entities are in Mandatory (COUNTRY) to (PERSON)
Mandatory cardinalities

Type of Relationship:-
Type of relationship is One (COUNTRY) to Many
(PERSON) 15
16
1) Is the scenario on last slide is in Relational Database or in Flat File System?

It is in Relational Database because two tables relates with each other with
Primary Key and Foreign Key.

Primary Key (countryId in COUNTRY table)


Foreign Key (countryId in PERSON table)

Because, Scenario is in One (COUNTRY) to Many (PERSON) type of


relationship.

17
2) Is the designed scenario on last slide is 100% correctly designed to
achieve the core objective of Relational Database System?

Yes, It is 100% correctly designed because there is no repetition of


Countries Instances (records) in COUNTRY table; When related to PERSON
table as many citizens in one country must exists. There are many citizens
of Pakistan so we don’t need to repeat Pakistan as many times the record
of PERSON is stored. We can refer it from COUNTRY table via Primary Key
to Foreign Key in PERSON table.

18
3) If In Relational Database; Than, How it is minimizing
Duplication of Data?

Duplication of Instances is removed because there is no


repetition of Countries Instances in COUNTRY table. Country
instance must be called via Foreign Key in PERSON table and
there are many number of instances of persons in PERSON
table as citizens of Pakistan, these instances can be related to
a single instance of Country Pakistan in COUNTRY table.

19
4) Is it minimizing Update and Delete
Anomaly/Irregularity?

Yes, We have removed Update and Delete Anomaly. When


Country instance is updated or deleted in COUNTRY table
than it will automatically show updated or deleted record
against countryId in PERSON table where ever It is referred
by Foreign Key. So, we don’t have to update or delete
millions of records in PERSON table against countries.

20
Case Study-1

In a school, Each STUDENT must be allocated to exactly one


CLASS and a CLASS must be formed by at least twenty or
more than twenty number of STUDENTs. There are Many
Mandatory posts for STUDENT’s exists in every CLASS and
there are Many Mandatory STUDENT’s assigned to different
posts like Class Representative (CR), Girls Representative
(GR), Boys Representative (BR) in every CLASS.

21
Entities
Step 1: Identifying Entities: -

◦ STUDENT

◦ CLASS

22
Step 2: Writing Scenario with Type and Cardinality of
Relationship as per Business Rules: -

23
Reasoning for Type of Relationships: -

24
Step 3: ERD Designing in Information Engineering Style: -

25
Entities
Step 4: Transforming ERD into Relations (If
Required): -
Transformed/Mapped Entities into Relations: -

STUDENT

CLASS

POST (Associative/Junction Entity)

26
Reasoning behind finding Type of Relationships with a Junction Table: -

27
POST Entity/Table is known as Associative or Junction Entity/Table
because it relates two number of Table’s as shown in previous diagram.
Associative/Junction Entity/Table can store some information that is
linked to both tables as per relationship existence as in previous
diagram classPost detail is stored in POST entity like who is CR, BR or GR
of which class and these details cannot be stored in STUDENT and in
CLASS Entity/Table. Only STUDENT details are stored in STUDENT table
and CLASS details are stored in CLASS table.
All the instances/records in Associative Entity/Table must be unique.
Primary key of Associative Entity/Table can be a Cumbersome Key
(Group of Primary Keys) in Associative/Junction Entity/Table that
uniquely identifies a record in a relation/table. In previous diagram,
className, stdRegNo and postTitle can make a Cumbersome key in
associative table/entity.

28
Step 5: Transforming ERD into Relations: -
Case Study-2

Odeon Cinema and other international cinemas have decided to


install a centralized database. This database should keep information
regarding cinemas including its name, address and phone number.
Each cinema must have one or more theaters and each theater has a
specific showing time. During these showing times a particular movie
is shown to the general public

30
Entities

CINEMA

THEATER

SHOW

MOVIE

31
Relationships

A CINEMA must contain one or more THEATERs. A THEATER must


belong to only and only one CINEMA.

A THEATER has one or more SHOW times. A particular SHOW time


for a movie must belongs to only and only one THEATER.

A MOVIE may have many SHOW times and a particular SHOW time
must belongs to one MOVIE only.

32
Assignment # 02
Draw ER Diagram of Online Shopping Management System having following
Entities:
Entities and Attributes
Website/Application Entity: Attributes are domain name and app name.
Customer Entity: Attributes are username, password, email address, mobile number,
country name, district, address, C_id.
Products Entity: Attributes are product ID, P_name, P_category, P_price,
P_availability.
Admin Entity: Attributes are username, password, A_id.
Shopping Cart Entity: Attributes are product id, product name, total price, billing
products.
Registration Entity: Attributes are user id, username, password, forgot password,
signup.
THANKYOU

34

You might also like