Scribd
Upload
4 views12 pages

ER Model Exmpl

The document discusses data modeling concepts, focusing on how to represent entity sets and relationship sets as relation schemas in a database. It explains the use of primary keys, redundancy in schemas, and how to handle composite and multivalued attributes. Additionally, it covers methods for representing specialization and aggregation in database schemas.

Uploaded by

amitsharma.himcs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
4 views12 pages

ER Model Exmpl

The document discusses data modeling concepts, focusing on how to represent entity sets and relationship sets as relation schemas in a database. It explains the use of primary keys, redundancy in schemas, and how to handle composite and multivalued attributes. Additionally, it covers methods for representing specialization and aggregation in database schemas.

Uploaded by

amitsharma.himcs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Data Modeling

Which data to include in the database


Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.db-book.com

1
Reduction to Relation Schemas
n Primary keys allow entity sets and relationship sets to be
expressed uniformly as relation schemas that represent
the contents of the database.
n A database which conforms to an E-R diagram can be
represented by a collection of schemas.
n For each entity set and relationship set there is a unique
schema that is assigned the name of the corresponding
entity set or relationship set.
n Each schema has a number of columns (generally
corresponding to attributes), which have unique names.

2
E-R Diagram for a Banking Enterprise

3
Representing Entity Sets as Schemas
n A strong entity set reduces to a schema with the
same attributes.
example:
branch = (branch_name, branch_city, assets )
n A weak entity set becomes a table that includes a
column for the primary key of the identifying strong
entity set
payment =
( loan_number, payment_number, payment_date,
payment_amount )
4
Representing Relationship Sets as
Schemas
n A many-to-many relationship set is represented as a
schema with attributes for the primary keys of the two
participating entity sets, and any descriptive attributes
of the relationship set.
n Example: schema for relationship set borrower
borrower = (customer_id, loan_number )

5
Redundancy of Schemas
n Many-to-one and one-to-many relationship
Primary key of the entity set on the “many” side serves as
the primary key
Example: cust_banker(customer_id, employee_id, type)

6
Redundancy of Schemas (Cont.)

n One to One
Primary key of either entity set can be choosen
Example: Head_of(dept_name, emp_id)

Head
Department Employee
Of

7
Redundancy of Schemas (Cont.)
n The schema corresponding to a relationship set
linking a weak entity set to its identifying strong
entity set is redundant.
n Example: The payment schema already contains
the attributes that would appear in the
loan_payment schema (i.e., loan_number and
payment_number).

8
Composite and Multivalued Attributes
n Composite attributes are flattened out by creating a separate attribute for each
component attribute
n Example: given entity set customer with composite attribute name with
component attributes first_name and last_name the schema corresponding to
the entity set has two attributes name.first_name and name.last_name
n A multivalued attribute M of an entity E is represented by a separate schema
EM
n Schema EM has attributes corresponding to the primary key of E and an
attribute corresponding to multivalued attribute M
n Example: Multivalued attribute dependent_names of employee is represented
by a schema: employee_dependent_names = ( employee_id, dname)
n Each value of the multivalued attribute maps to a separate tuple of the relation
on schema EM
n For example, an employee entity with primary key 123-45-6789 and
dependents Jack and Jane maps to two tuples:
(123-45-6789 , Jack) and (123-45-6789 , Jane)

9
Representing Specialization via Schemas
Method 1:
Form a schema for the higher-level entity
Form a schema for each lower-level entity set, include primary key of
higher-level entity set and local attributes

schema attributes
person person_id, name, street, city
customer person_id, credit_rating
employee person_id, salary
Drawback: getting information about, an employee requires
accessing two relations, the one corresponding to the low-level
schema and the one corresponding to the high-level schema

10
Representing Specialization as Schemas
(Cont.)
n Method 2:
n Form a schema for each entity set with all local and inherited
attributes

schema attributes
person person_id, name, street, city
customer person_id , name, street, city, credit_rating
employee person_id , name, street, city, salary

n If specialization is total, the schema for the generalized entity set


(person) not required to store information
n Can be defined as a “view” relation containing union of specialization
relations
n But explicit schema may still be needed for foreign key constraints
n Drawback: street and city may be stored redundantly for people
who are both customers and employees

11
Schemas Corresponding to Aggregation
n For example, to represent aggregation manages between relationship
works_on and entity set manager, create a schema

n manages (employee_id, branch_name, title, manager_name)


n Schema works_on is redundant provided we are willing to store null
values for attribute manager_name in relation on schema manages

12

You might also like