Database Designsemester Slide 1 Database Design Lecture 7 Entity-relationship modeling Text , 7.1

Database Designsemester Slide 2 Overview  Entity-Relationship (ER) model is a popular high-level conceptual data model.  Based on a perception of a real world that consists of a collection of basic objects, called entities, and of the relationships among these objects.  The ER model can be directly translated into relational tables.

Database Designsemester Slide 3 Entities  A database can be modeled as: –a collection of entities, –relationship among entities.  An entity is an object that exists and is distinguishable from other objects. Example: person, company, event, plant  Entities have attributes Example: people have names and addresses  An entity set (aka entity type, entity class) is a set of entities of the same type that share the same properties. Example: set of all persons, companies, students. Entity instance: a specific element in the entity set.

Database Designsemester Slide 4 Attributes  An entity is represented by a set of attributes, that is, descriptive properties possessed by all members of an entity set. Example: customer = (customer-id, customer-name, customer- street, customer-city) Attribute Domain – the set of permitted values for each attribute  Attribute types: –Simple and composite attributes.  Eg composite attribute: address consists of street and city. –Single-valued and multi-valued attributes  E.g. multivalued attribute: phone-numbers –Derived attributes  Can be computed from other attributes  E.g. age, given date of birth

Database Designsemester Slide 5 Keys of Entity  Superkey –subset of attributes which uniquely identify an entity (many possibilities, eg, all attributes in relation, …...)  Candidate Key –minimal superkey - unable to remove any attributes and still provide unique identification of the entity –EMPLOYEE (empno, ……, taxfileno) –one is select as Primary Key (eg. empno) –remaining candidate key/s known as Alternate Keys (taxfileno) –PK’s may be  simple PK (single attribute)  CUSTOMER (custno, ….)  composite PK (multiple attributes)  ORDERLINE (orderno, prodno, quantity,…)

Database Designsemester Slide 6 Drawing Entities and Attributes  Chen's Notation rectangles represent entities oval represent attributes derived attributes use dotted line multi-valued attributes use double line primary key attribute indicated with underline student stu_idname dob age phone Rectangles represent entity sets. address streetcity

Database Designsemester Slide 7 Relationship  Relationship –association between two (or more) entities Examples Students Register for Subjects School Has Staff Driver Commits Traffic Offence Customer Orders Product Supplier Supplies Parts To Projects  Relationship type (aka relationship set) –Set of similar associations among entity sets.

Database Designsemester Slide 8 Types of Relationships  Degree of relationship –UNARY – between entities from one entity set, recursive –BINARY – between entities from two entity sets –N-ARY – among entities from more than two entity sets  Relationship may have attributes –eg, customer orders a product  quantity is attribute of orders relationship –A requirement of our text on attributes of relationship: A relationship must be uniquely identifiable by the participating entities without using the descriptive attributes of the relationship.

Database Designsemester Slide 9 Drawing Relationships  relationships represented by diamond customer product orders quantity

Database Designsemester Slide 10 Example Relationships

Database Designsemester Slide 11 Constraints on Relationships  Cardinality –Given an entity instance e of some entity type, how many entity instances of the related entity type can have the relationship with e. –Example:  Each student enrolls in 1 to 4 subjects,  Each subject may be enrolled by 0 to 300 students. Student Subject EnrolIn (1,4)(0,300)

Database Designsemester Slide 12 Cardinality Ratio  Relationships can be classified as –one-to-one (1:1)  One entity of type A corresponds to at most one entity of type B, and vice versa –one-to-many (1:M)  One entity of type A corresponds to more than one entities in B, but one entity of type B may only correspond to at most one entity of type A. –Many-to-one: opposite to one-to-many –many-to-many (M:N)  One entity of type A corresponds to more than one entities of type B, and vice versa

Database Designsemester Slide 13 Participation  Participation of entity instances in relationship can be –Optional (partial)  eg, an employee may not have a spouse  not every staff manages a department –Mandatory (total)  eg, every spouse must be that of an employee  Every department is managed by some staff.  Mandatory participation is represented by double line

Database Designsemester Slide 14 Examples employee spouse 11 has (0,M)(1,1) (1:M)(0:N) ORDERCUSTOMERplace SUBJECTSTUDENTenrol 1N MN

Database Designsemester Slide 15 Weak Entity  Existence depends on the existence of other entities  primary key partially or totally derived from owner entity  The relationship between the weak entity and its owner entity is called weak relationship. –Eg: Employee Has Dependent  Dependent can be regarded as a weak entity—only when the attributes of Dependent can not uniquely identify a dependent. Eg, Dependent has the attributes d_name and d_birthdate only, but two employees may have dependents with the same name and date of birth. However employee_no and d_name uniquely identify each dependent.  Employee is the owner entity  Has is the weak relationship

Database Designsemester Slide 16 Representing Weak Entities and Relationships  Weak entity is indicated by a double line rectangle, and weak relationship is represented by a double line diamond.  Participation of weak entity in weak relationship is always mandatory.  A weak entity type may have more than one owner entity types. EmployeeDependent Has 1 M

Database Designsemester Slide 17 Modelling with E-R Diagram  list the major entity sets in the system  represent the entity sets graphically by a rectangle  search for relationships between the entities and represent them graphically by a diamond  add attributes, underline PK attribute/s  model relationship cardinality and participation  Do not include Foreign Keys (FK's) on ER Diagram –FK used to depict relationship BUT relationship is already present in ER due to relationship - thus never show FK on ER

Database Designsemester Slide 18 Example COMPANY Database  Requirements for the Company database –The company is organized into DEPARTMENTs. Each department has a name, number, and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations –Each department controls a number of PROJECTs. Each project has a name, number, and is located at a single location.

Database Designsemester Slide 19 Example COMPANY Database (continued) –We store each EMPLOYEE's social security number, address, salary, sex, and birth date. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. –Each employee may have a number of DEPENDENTs. For each dependent, we keep their name, sex, birth date, and relationship to the employee.

Database Designsemester Slide 20

Database Designsemester Slide 21