O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

ER MODEL

2.960 visualizações

Publicada em

CS 2: Chapter 3

Publicada em: Educação
  • Entre para ver os comentários

ER MODEL

  1. 1. Chapter 3: CONCEPTUAL DESIGN-ER- MODEL (Entity-Relational)
  2. 2. The Entity Relationship Model  Perspective Organisation Information System Relational Model Physical data storage ERM Conceptual Model Logical Model Physical Model
  3. 3. Steps in Database Design  Requirements Analysis  user needs; what must database do?  Conceptual (Database) Design  high level (or semantic) description.  often done with the ER model  Logical (Database) Design  translate ER into DBMS data model (e.g., Relational Model)  Schema Refinement  consistency, normalization  Physical (Database) Design - indexes, disk layout  Security Design - who accesses what, and how
  4. 4. Identify the entities, its attributes and the relationships between entities. Identify entities For the list of activities, identify the subject areas you need to maintain information about. These will become tables. An entity may be an object with a physical existence - a particular person, car, house, or employee – or it may be an object with a conceptual existence - a company, a job, or a university course. For example, to develop a company's database for maintaining information on employees, the application should be able to store and provide data on employee such as when was the employee was hired; is the employee still with the company; if the employee has left the company when did he leave the company; which department does employee work for; who is his/her manager; what is his/her skill level etc. In this example, the entities are company, department, employee, manager. An Attribute is a property that describes an entity. In the above example, Entity : employee Attribute: employee’s name, age, address, salary and job etc
  5. 5. So the concepts we want you to learn today are: The basics of Entity-Relationship modelling Entities Relationships Attributes
  6. 6. 6 Entities  Entity - distinguishable “thing” in the real world – Strong entity - entities have an independent existence – Weak entity - existence dependent on some other entity EntityName Entity space for attributes
  7. 7. Notation for attributes Primary Key marked {PK} Composite attribute Derived Attribute Multi-Valued Attribute (number of values in [ ] brackets) {PPK} Partial Key - part of composite PK - or of a weak entity EntityName keyAttribute {PK} compositeAttribute partOne partTwo / derivedAttribute multiValued [min..max]
  8. 8. Relationships  A relationship is “.. An association among entities (the participants)..”  Relationships link entities with each other
  9. 9. Concept of Entity and Relationship:
  10. 10. The entity set which does not have sufficient attributes to form a primary key is called asWeak entity set. A member of a strong entity set is called dominant entity and member of weak entity set is called as subordinate entity. The primary key of a weak entity set is formed by the primary key of the strong entity set . The relationship between weak entity and strong entity set is called as Identifying Relationship.
  11. 11. For example, payment_number acts as discriminator for payment entity set. It is also called as the Partial key of the entity set. In the above example {loan_number, payment_number} acts as primary key for payment entity set. The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set is existence dependent plus the weak entity sets discriminator. Here double lines indicate total participation of weak entity in strong entity set it means that every payment must be related via loan-payment to some account. The discriminator of a weak entity set is underlined with dashed lines rather than solid line.
  12. 12. Weak Entities • A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. – Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities). – Weak entity sets must have total participation in this identifying relationship set. – Trans_no is a discriminator within a group of transactions in an ATM. since address Trans_no amount ATM Transactions atmID type
  13. 13. 15 Attributes  Entity types have Attributes (or properties) which associate each entity with a value from a domain of values for that attribute  Attributes can be – simple (atomic) e.g. license_no – composite e.g. address (street, town, postcode) – multi-valued e.g. phone number – derived e.g. D.O.B. ; age – Null – Single valued e.g. name  Relationship types can also have attributes!
  14. 14. Types of attributes: Simple attribute: Simple attributes are atomic values, which cannot be divided further. Composite attribute: Composite attributes are made of more than one simple attribute. For example, a student's complete name may have first_name and last__name. Derived attribute: Derived attributes are attributes, which do not exist physical in the database, but there values are derived from other attributes presented in the database. For example,age can be derived from data_of_birth. Single-valued attribute: Single valued attributes contain on single value. For example: Social_Security_Number. Multi-value attribute: Multi-value attribute may contain more than one values. For example, a person can have more than one phone numbers, email_addresses etc.
  15. 15. Keys Key is an attribute or collection of attributes that uniquely identifies an entity among entity set. For example, roll_number of a student makes her/him identifiable among students.
  16. 16. Degree of relationship The number of participating entities in an relationship defines the degree of the relationship. Unary=degree 1 Binary = degree 2 Ternary = degree 3 n-ary = degree n
  17. 17. 19 Relationships: constraints  The degree of a relationship type – binary (connects 2 entity types) – unary/ recursive (connects 1 entity type with itself) – Ternary (connects 3) – complex (connects 3 or more entity types)  Relationship constraints - cardinality – one to one (1:1) – one to many (1:m) – many to many (m:n)  Relationship constraints – participation – full/mandatory – or partial/optional Degree
  18. 18. Binary relationship Entity1 Entity3 TernaryRelationship Entity2 Relationships: Degree Entity1 Entity2 HasLinkWith Supervisor Supervises ESnttaitfyf1 Supervisee Complex relationship – here ternary Recursive (Unary) relationship - example
  19. 19. 21 Relationships example Manages Manager Department responsibility] dateAllocated Each department is managed by ONE manager Each manager Relationship manages departments attributes
  20. 20. Unary Example with Data Staff supervises A member of staff may supervise another staff member, but a staff member may be supervised by one or more staff members STAFF Member Age Supervisor A 43 C B 27 B C 35 D D 33 A
  21. 21. In a one-one relationship an entity of either entity set can be connected to at most one entity of the other set.
  22. 22. 24 Ternary Diagram registers “a client at a branch will be registered by one member of staff” “a member of staff will register a client at one branch” Staff Branch “a member of staff at a branch may register many clients” Client Try to determine participation/cardinality by operating in pairs
  23. 23. the Works_In Relationship Set lot name Employees ssn since Works_In dname did budget Departments
  24. 24. A Ternary Relationship Set: Works_In2
  25. 25. Key Constraints(ternary relationships) dname did budget name lot name ssn Location Employees works_In Departments 12-233 12-354 12-243 D12 • 12-299 Rome London Paris D10 D13 ••• Each employee can work at most in one department at a single location
  26. 26. ER Model….. Relationship:  Association among two or more entities. E.g., Peter works in Pharmacy department.  Relationship sets can also have descriptive attributes (e.g., the since attribute of Works_In). subor-dinate super-visor Reports_To since Works_In dname did budget Departments lot name Employees ssn
  27. 27. Participation Constraints  The participation of the entity set Departments in the relationship set Manages is said to be total if we assume every department have a manager.  Connect Departments and Manages by a thick line.  The participation of the entity set Employees in Manages is partial.
  28. 28. Participation Constraints • Does every department have a manager? – If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). • Every Department MUST have at least an employee • Every employee MUST work at least in one department name dname lot did budget since Employees Departments Manages since ssn Works_In
  29. 29. Mapping Cardinalities: Cardinality defines the number of entities in one entity set which can be associated to the number of entities of other set via relationship set. One-to-one: one entity from entity set A can be associated with at most one entity of entity set B and vice versa. One-to-one relation]
  30. 30. Many-to-one: More than one entities from entity set A can be associated with at most one entity of entity set B but one entity from entity set B can be associated with more than one entity from entity set A. Many-to-one relation]
  31. 31. Many-to-many: one entity from A can be associated with more than one entity from B and vice versa. Many-to-many relation]
  32. 32. •One-to-many: One entity from entity set A can be associated with more than one entities of entity set B but from entity set B one entity can be associated with at most one entity. One-to-many relation]
  33. 33. CASE STUDY: “Yatra company” has branches situated all over Maharashtra. • Each branch is treated as an independent travelling agency • Each such agency arranges tours. • For each tour they have schedule of buses. • Each bus is allocated a team of workers: Driver, cleaner, conductor, helper. • Passenger book the tour by booking a specific schedule and bus. • The agency has many employee working as: Clearks,agents,stenos. • Each of the tour have many Schedules based on time of departure and similarly Many buses for one tour but each schedule can have one bus only.
  34. 34. Entity Primary Key Branch Br_no Tours T_no Buses Bus_no Employees Emp_id Pasengers P_no Scheduledby T_no,Bus_no Allocated Emp_id,Bus_no Bookedby P_no,Bus_no Physical entity relationship
  35. 35. Branch
  36. 36. Relational Model with all entity: • Tours (tno, title, no_of_days, capacity ,departure,date) • Branch(________________) • Buses(_________________) • passenger(________________) • Employee(__________________________) Relationship(AS per E-R-D) • One branch of YATRA COMPANY forms many tours • Many tours scheduled as many buses. • Many passenger booked many buses. • Many buses allocates many employees.
  37. 37. ISA Hierarchies Contract_Emps name ssn Employees lot hourly_wages Hourly_Emps contractid hours_worked ISA If we declare A ISA B, every A entity is also considered to be a B entity. » Reasons for using ISA: To add descriptive attributes specific to a subclass. To identify entities that participate in a relationship.
  38. 38. Aggregation – Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. – Employees are assigned to monitor SPONSORSHIPS. ssn started_on until name Employees Monitors lot since pid pbudget did budget dname Projects Sponsors Departments
  39. 39.  Aggregation vs. ternary relationship:  Monitors and Sponsors are distinct relationships, with descriptive attributes of their own.  Also, can say that each sponsorship is monitored by at most one employee (which we cannot do with a ternary relationship).
  40. 40. 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?
  41. 41. CASE STUDY: • Design Database for banking enterprise, with record information about CUSTOMER ,EMPLOYEES of the bank. • A customer can be a DEPOSITOR OR BORROWER, • A EMPLOYEE of the bank can be CUSTOMER of the bank. • There are two types of account SAVING or CURRENT account. • Questions:(***Hint: Use unary relationship, specialization, generalization) • Identify all entities. • Identify all attributes. • Identify all relations. • Draw E-R-Diagram. • Relational data model.
  42. 42. Primary key Customer_no Account_no Customer_no Primary key Foreign key

×