P. 1
ER diagram

ER diagram

|Views: 30|Likes:
Published by Tushar Jaiswal

More info:

Published by: Tushar Jaiswal on Mar 12, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

11/15/2013

pdf

text

original

The Entity-Relationship Model

CSCD34- Data Management Systems. A. Vaisman

1

Overview of Database Design
 

Requirements Analysis: Understand what data will be
stored in the database, and the operations it will be subject to.

Conceptual Design: (ER Model is used at this stage.)
 What are the entities and relationships in the enterprise?  What information about these entities and relationships should we store in the database?  What are the integrity constraints or business rules that hold?  A database `schema’ in the ER Model can be represented pictorially (ER diagrams).  Can map an ER diagram into a relational schema.

Logical Design: Convert the conceptual database design into
2

the data model underlying the DBMS chosen for the CSCD34- Data Management Systems. A. Vaisman application.

 Application and Security Design: Consider aspects of the application beyond data. Methodologies like UML often used for addressing the complete software development cycle.Overview of Database Design (cont.Data Management Systems. build indices). Physical Database Design and Tuning: Consider typical workloads and further refinement of the database design (v.g.)   Schema Refinement: (Normalization) Check relational schema for redundancies and anomalies. Vaisman 3 . A. CSCD34.

. 4 CSCD34.    All entities in an entity set have the same set of attributes.  Entity Set: A collection of entities of the same kind. An entity is described using a set of attributes.ER Model Basics  ssn name lot Employees Entity: Real-world object distinguishable from other objects. all employees.g.Data Management Systems. A. Vaisman . E. Each attribute has a domain. Each entity set has a key(a set of attributes uniquely identifying an entity).

g. A. Relationship Set: Collection of similar relationships..  Relationship sets can also have descriptive attributes (e..) since ssn lot Employees dname did budget name ssn lot supervisor Employees   Works_In Departments subordinate Reports_To CSCD34.Data Management Systems. Peter works in Pharmacy department. E.name ER Model Basics (Contd. Vaisman Relationship: Association among two or more entities. . en  En  Same entity set could participate in different relationship sets. or in different “roles” in same set. the since attribute of Works_In).. 5 . A relationship is uniquely identified by participating entities without reference to descriptive attributes.. each relationship in R involves entities e1  E1... En..  An n-ary relationship set R relates n entity sets E1 .g.

Cardinality)  since dname lot did budget  Constraints are IMPORTANT because they must be ENFORCED when IMPLEMENTING the database CSCD34. a dept can have many employees. according to the key constraint on Manages. A. In contrast.Data Management Systems.Key Constraints (a. Vaisman 6 Consider Works_In (in previous slide): An employee can work in many departments.k. name ssn Employees Manages Departments 1-to-1 1-to Many Many-to-1 Many-to-Many . each dept has at most one manager.a.

A.Data Management Systems.Key Constraints (ternary relationships) name name Location dname did budget Each employee can work at most in one department at a single location ssn lot Employees works_In Departments 12-233 12-354 12-243 12-299 D10 • • • • D12 D13 Rome London Paris CSCD34. Vaisman 7 .

• Every Department MUST have at least an employee • Every employee MUST work at least in one department • There may exist employees managing no department name ssn lot since dname did Manages budget Departments Employees Works_In since CSCD34.Participation Constraints  Does every department have a manager?  If so. A. Vaisman 8 . partial). this is a participation constraint: the participation of Departments in Manages is said to be total (vs.Data Management Systems.

Data Management Systems.    Owner entity set and weak entity set must participate in a one-tomany relationship set (one owner. transac# is a discriminator within a group of transactions in an ATM.Weak Entities  A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. Vaisman 9 . A. address atmID since transac# amount type ATM Transactions CSCD34. Weak entity sets must have total participation in this identifying relationship set. many weak entities).

hourly_wages hours_worked ISA contractid we declare A ISA B. If so. » Reasons for using ISA: To add descriptive attributes specific to a subclass. Covering constraints: Does every Employees’ entity also have to be an Hourly_Emps or a Contract_Emps entity?. To identify entities that participate in a relationship. specify => Hourly_Emps OVERLAPS Contract_Emps. Hourly_Emps Contract_Emps   Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? if so. or other PLs. Vaisman . every A entity is also considered to be a B entity. attributes are inherited. A.Data Management Systems. write Hourly_Emps AND Contract_Emps COVER Employees.name ISA (`is a’) Hierarchies As If ssn lot Employees in C++. 10 CSCD34.

Sponsors  Aggregation vs.  Also.  Monitors until started_on pid Projects pbudget since did dname budget Departments  CSCD34. . can say that each sponsorship is monitored by at most one employee (which A.name ssn lot Employees Aggregation  Used when we have to model a relationship involving (entity sets and) a relationship set. Employees are assigned to monitor SPONSORSHIPS. with descriptive attributes of their own.Data Management Systems. Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. ternary relationship:  Monitors and Sponsors are distinct relationships. Vaisman 11 we cannot do with a ternary relationship).

But some constraints cannot be captured in ER diagrams.Conceptual Design Using the ER Model  Design choices:    Should a concept be modeled as an entity or an attribute? Should a concept be modeled as an entity or a relationship? Identifying relationships: Binary or ternary? Aggregation? A lot of data semantics can (and should) be captured. A.Data Management Systems. 12  Constraints in the ER Model:   CSCD34. Vaisman .

. address must be an entity (since attributes cannot be setvalued). we want to retrieve employees in a given city. street. e. CSCD34. etc.g.) is important.Data Management Systems. • If the structure (city.Entity vs. Attribute Should address be an attribute of Employees or an entity (connected to Employees by a relationship)?  Depends upon the use we want to make of address information. Vaisman 13 . and the semantics of the data:  • If we have several addresses per employee. address must be modeled as an entity (since attribute values are atomic). A.

Similar to the problem of wanting to record several addresses for an employee: We want to record several values of the descriptive attributes for each instance of this relationship. Vaisman 14 . Accomplished by introducing new entity set. ssn Employees name ssn Employees lot Works_In4 did dname budget Departments from Duration to CSCD34.Data Management Systems. A. Attribute (Contd.Entity vs. Duration.) name  from lot to dname did Works_In4 budget Departments  Works_In4 does not allow an employee to work in a department for two or more periods (a relationship is identified by participating entities).

Data Management Systems. Relationship   First ER diagram OK if a manager gets a separate discretionary budget for each dept. Vaisman .Entity vs. What if a manager gets a discretionary budget that covers all managed depts?  since name ssn Employees name lot dbudget did dname budget Departments Manages2 ssn Employees lot since did Manages2 dname budget Departments  Redundancy: dbudget stored for each dept managed by manager. ISA Managers dbudget This fixes the problem! 15 CSCD34. Misleading: Suggests dbudget associated with department-mgr combination. A.

Bad design Dependents Beneficiary Better design policyid Policies cost 16 CSCD34. Ternary Relationships name ssn lot Employees Covers Policies policyid name ssn Employees Purchaser lot cost pname age pname age Dependents  Suppose:  A policy cannot be owned by more than one employee.  Dependent is a weak entity set. A.Binary vs. Vaisman .Data Management Systems. identified by policiId.  Every policy must be owned by some employee.

Ternary Relationships (Contd. Vaisman . A.) Previous example illustrated a case when two binary relationships were better than one ternary relationship. Departments and Suppliers. 17 CSCD34. all these do not imply that D has agreed to buy P from S (because D could buy P from another supplier).Data Management Systems. and has descriptive attribute qty.  An example in the other direction: a ternary relation Contracts relates entity sets Parts. and D “deals-with” S. D “needs” P.Binary vs. No combination of binary relationships is an adequate substitute:   Although S “can-supply” P.

ISA hierarchies. A.  Some additional constructs: weak entities.Summary of Conceptual Design   Conceptual design follows requirements analysis.Data Management Systems. and aggregation. and attributes (of entities and relationships). Vaisman 18 . close to the way people think about their applications.  Yields a high-level description of data to be stored Constructs are expressive.  CSCD34.  Note: There are many variations on ER model. ER model popular for conceptual design  Basic constructs: entities. relationships.

and overlap/covering constraints for ISA hierarchies. Constraints play an important role in determining the best database design for an enterprise.   Some constraints (notably. CSCD34. Vaisman 19 . functional dependencies) cannot be expressed in the ER model.Data Management Systems.Summary of ER (Contd. A. participation constraints. Some foreign key constraints are also implicit in the definition of a relationship set.)  Several kinds of integrity constraints can be expressed in the ER model: key constraints.

whether or not to use ISA hierarchies. binary or nary relationship. attribute.)  ER design is subjective. Common choices include:  Entity vs.  Ensuring good database design: resulting relational schema should be analyzed and refined further. 20 CSCD34. A. entity vs.Summary of ER (Contd.Data Management Systems. relationship. and whether or not to use aggregation. especially for a large enterprise. Vaisman . There are often many ways to model a given scenario! Analyzing alternatives can be tricky. FD information and normalization techniques are especially useful.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->