ENTITY- RELATIONSHIP MODELLING 1 All rights reserved by

Concept of Entity and Relationship: from the retrospect All rights reserved by 2

What is it about? ER model is used to show the Conceptual schema of an organisation. Independent of specific data model or DBMS The model is later transformed into a Logical model (e.g. relational) on which the physical database is built The most widely used form of Semantic modelling: attempt to capitalise on knowledge of meaning of data to inform the model So we need a vocabulary 3 All rights reserved by

Steps in Database Design Requirements Analysis user needs; what must database do? Conceptual (Database) Design high level (or semantic) description from users’ daily view. 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 All rights reserved by 4

Conceptual Design 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. All rights reserved by 5

ER Model Basics Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes. Entity Set: A collection of similar entities. E.g., all employees. All entities in an entity set have the same attributes. Each entity set has a key (underlined). Each attribute has a domain. All rights reserved by 6

ER Model Basics (Cont.) Relationship: Association among two or more entities. Represented by a diamond. relationships can have their own attributes. A relationship must be uniquely identified by the participating entities, without reference to its own attributes. Relationship Set: Collection of similar relationships. An n-ary relationship set R relates n entity sets E 1... E n ; each relationship in R involves entities e 1  E 1,..., e n  E n All rights reserved by 7

Keys A key is a minimal set of attributes whose values uniquely identify an entity in some entity set. For each entity set, we choose a key. Candidate key An entity set can have more than one key. Primary key We designate one of the candidate keys as the primary key. All rights reserved by 8

Representation of an Entity Set Entity set Represented by a rectangle. Attribute: Represented by an oval. Key: Each attribute in the primary key is underlined. Employees ssn name lot All rights reserved by 9

10

An Instance of the Works_In Relationship Set All rights reserved by 11

The Entity Relationship Model Perspective 12 OrganisationInformation System Relational Model Physical data storage ERM Conceptual ModelLogical ModelPhysical Model This was lecture 1! All rights reserved by

ER Model Basics (Cont.) Same entity set can participate in different relationship sets, or in different “roles” in the same relationship set. subor- dinate super- visor Reports_To since Works_In dname budget did Departments lot name Employees ssn All rights reserved by 13

Key Constraints An employee can work in many departments; a dept can have many employees. 1-to-1 M-to-N since Manages dname budgetdid Departments since Works_In lot name ssn Employees In contrast, each dept has at most one manager, according to the key constraint on Manages. 1-to-N All rights reserved by 14

An Instance of the Manages Relationship Set violates the key constraint on MANAGES: A dept has at most one manager. MANAGES is a kind of WORKS_IN All rights reserved by 15

Skills and concepts So the concepts we want you to learn today are: The basics of Entity-Relationship modelling E ntities R elationships A ttributes 16 All rights reserved by

Entities Entity - distinguishable “thing” in the real world Strong (or regular) entity - entities have an independent existence (e.g. staff) Weak entity - existence dependent on some other entity (e.g. next of kin) 17 space for attributes Entity type name (singular, no spaces, capital letter at start of each word) All rights reserved by

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. Surname; date of birth compositee.g. address (street, town, postcode) multi-valuede.g. phone number complexnested multi-valued and composite base or derivede.g. D.O.B. ; age key Relationship types can also have attributes! (see later) 18 All rights reserved by

Notation for attributes 19 Primary Key marked {PK} Multi-Valued Attribute (number of values in [ ] brackets) Derived Attribute Composite attribute Partial Key - part of composite PK - or of a weak entity {PPK} All rights reserved by

Relationships A relationship is “.. An association among entities (the participants)..” Relationships link entities with each other 20 Name: verb, capital start letter, arrow indicates direction in which verb makes sense All rights reserved by

Relationships: constraints The degree of a relationship type binary (connects 2 entity types) unary/ recursive (connects 1 entity type with itself) complex (connects 3 or more entity types) Ternary (connects 3) 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 21 Degree Multiplicity All rights reserved by

Relationships: Degree 22 Binary relationship Complex relationship – here ternary Recursive (Unary) relationship - example All rights reserved by

Relationships: Multiplicity 23 label lines to show cardinality and participation 0..1“zero or one” 0..*“zero or more” 1..1“one” 1..4“between 1 and 4” 1..*“one or more” optional mandatory * Entity1 has a 1:m relationship with Entity2; participation for Entity2 is mandatory, for Entity1 optional. All rights reserved by

Relationships example 24 ManagerDepartment Manages responsibility [1..*] dateAllocated Each department is managed by ONE manager Each manager manages UP TO 3 departments (but need not manage any department) Relationshi p attributes All rights reserved by

Over to You now! See if you can draw an E-R diagram for this scenario – you are already familiar with this! “A student registers for up to 8 modules and each module has many students on it. Record the student ID, their full name and address and also each module ID and title. We also want to hold the grade attained by each student for each module” Remember to show in your model: All primary keys, Entities Relationships Attributes 25 All rights reserved by

Unary Example with Data 26 Staff supervises 0..* 0..1  A member of staff may supervise another staff member, but a staff member may be supervised by one or more staff members STAFF MemberAgeSupervisor Grey43Black Black27 Brown35Black White33Brown All rights reserved by

Ternary Diagrams are Tricky! 27 Scenario modified from Connolly & Begg page 350 registers * Try to determine participation/cardinality by operating in pairs “a client at a branch will be registered by one member of staff” “a member of staff will register a client at one branch” “a member of staff at a branch may register many clients” StaffBranch Client All rights reserved by

Weak Entities A weak entity can be identified uniquely only by relationship with of another (owner) entity. Owner entity set and weak entity set must participate in a 1-N relationship set (1 owner, N weak entities). Weak entity set must have total participation in this identifying relationship set. lot name age pname Dependents Employees ssn Policy cost Weak entities have only a “partial key” (dashed underline) All rights reserved by 28

Class Hierarchies: Organizing Entities into Hierarchies Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed / disallowed) Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity?(Yes / no) All rights reserved by 29

Aggregation As defined so far, a relationship set is an association between entity sets. Aggregation allows us to model a relationship set between entities and relationships. i.e., treat a relationship set as an entity set for purposes of participation in (other) relationships. All rights reserved by 30

An Example of Aggregation Monitors is a relationship between entity Employees and relationship Sponsors. A project is sponsored by at least 1 department. A department may assign employees to monitor a sponsorship. All rights reserved by 31

Aggregation vs. Ternary Relationship Some attributes are not easily expressed without aggregation, such as “until”. Here, the Monitors relationship is not clearly expressed. All rights reserved by 32

Conceptual Design Using the ER Model ER modeling can get tricky! Design choices: Entity or attribute? Entity or relationship? Relationships: Binary or ternary? Aggregation? ER Model goals and limitations: Lots of semantics can (and should) be captured. Some constraints cannot be captured in ER. We’ll refine things in our logical (relational) design All rights reserved by 33

Entity vs. Attribute “Address”: attribute of Employees? Entity of its own? It depends! Semantics and usage. Several addresses per employee? must be an entity atomic attribute types (no set-valued attributes!) Care about structure? (city, street, etc.) must be an entity! atomic attribute types (no tuple-valued attributes!) All rights reserved by 34

Entity vs. Relationship Separate discretionary budget (dbudget) for each dept. What if manager’s dbudget is a SUM that covers all managed depts Could repeat value Better design: Associate dbudget with the appointment of the employee as manager of a group of depts. Manages2 name dname budget did Employees Departments ssn lot dbudget since Employees since name dname budget did Departments ssn lot Mgr_Appts is_manager dbudget apptnum managed_by All rights reserved by 35

Key Points ERM Entities (strong, weak) Attributes (simple, composite, etc) Relationships Degree Cardinality participation Model with the UML notation at conceptual level 36 All rights reserved by

37 All rights reserved by