Entity Relationship Diagrams 4 main concepts: Entity Property Relationship Subtype i.e. How to decide how many tables and their attributes. How to achieve reasonable performance for the most common queries

Entity Relationship Diagrams A distinguishable object or thing The world is made up of entities, both concrete and abstract. e.g. supplier, part, shipment, purchase order, employee, student, module, result In a description, entities are often referred to as nouns (but not all nouns become entities)

Entities Can be classified into Entity types, with entities being instances of that type e.g. employee as an entity type, and individual employees as instances of that type Advantage is that some properties can be associated with an entity type, and thus apply to all instances of that type

Entities Can be further subdivided into: Weak entities These are entities whose existence is dependent upon another entity e.g. an employee’s qualifications need the corresponding employee entity to be of value Regular entities (aka strong entities or entities) These are entities that are of interest in their own right

Properties Property Some piece of information that describes an entity e.g. supplier number, shipment quantity,person height, module type, degree classification In a description these might be nouns or adjectives

Properties There are various kinds of property: Simple or composite e.g. employee name (composite) first name or surname or title (simple) Key (or unique within a context) e.g. an NI Number defines a specific employee

Properties Single or multi-valued Base or derived e.g. Alumni qualification(s): A UWE student may have earned more than one qualification and we may be interested in only the most recent, or in all of them Base or derived Property is derived rather than an actual value, e.g. total price for an invoice is the sum of the prices of invoice items plus VAT

Relationships Relationships interconnect two or more entities e.g shipment (supplier and part) recording (composition, orchestra and conductor) They can be nouns or verbs in descriptions The entities involved in a relationship are called participants, and the number of participants is called the degree of the relationship

Relationships If R is a relationship involving E as a participant, then if every instance of E participates in at least one instance of R, then the participation of E in R is said to be total otherwise it is partial e.g. If every employee must belong to a department then the participation of employee with a relationship department-employs (connecting employee with department) is total If it is possible for a department to have no employees, then the participation of department with department- employs is partial

Relationships Assuming all relationships are binary they can be classified as: One-to-one e.g. birth mother and firstborn child One-to-many or many-to-one e.g. department and employee Many-to-many e.g. employee and project

Entity subtypes and supertypes Any entity is of at least one entity type but an entity can be of several types simultaneously e.g. car is a subtype of entity type vehicle, and conversely, vehicle is a supertype of entity type car. Thus properties of car can be inherited from vehicle

E/R diagrams (optional/mandatory relationships)

E/R diagrams (recursive relationships)

E/R diagrams (“hidden entities”)

E/R diagrams (entity subtypes and supertypes)

Mapping E/R models to Relations Entities Entities map into relations with their properties as attributes Key properties are candidate keys Relationships Relationships (especially m:m) map into relations These are likely to have the primary keys of the participating entities as foreign keys for the relation. The designer needs to specify an appropriate set of Update and Delete rules for each foreign key

Mapping E/R models to Relations Relationships (cont) Primary key could be the composite of the primary keys of the participating entities, e.g. {S#,P#} for SP. or could introduce a new key property, e.g. shipment number SP# One-to-one relationships are comparatively rare and often result in a merging together of relations

Mapping E/R models to Relations Properties Single-valued properties become attributes Multi-valued properties are removed so as to conform to First Normal Form and so need their own relation

Mapping E/R models to Relations (handling supertypes and subtypes)

create table EMPLOYEE ( EMP_ID. NUMBER(12). not null, DEPT_ID create table EMPLOYEE ( EMP_ID NUMBER(12) not null, DEPT_ID NUMBER(8) not null, EMP_SSN CHAR(9) not null, EMP_FIRST_NAME VARCHAR2(20) not null, EMP_LAST_NAME VARCHAR2(30) not null, EMP_BIRTH_DATE DATE not null, EMP_GENDER CHAR(1) not null, EMP_HIRE_DATE DATE not null, EMP_STREET VARCHAR2(80), EMP_CITY VARCHAR2(40), EMP_STATE CHAR(2), EMP_ZIP CHAR(5), constraint PK_EMPLOYEE primary key (EMP_ID), constraint AK_EMP_UID2_EMPLOYEE unique (EMP_SSN), constraint AK_EMP_UID3_EMPLOYEE unique (EMP_FIRST_NAME, EMP_LAST_NAME, EMP_BIRTH_DATE, EMP_GENDER), constraint FK_EMPLOYEE_RELATIONS_DEPARTME foreign key (DEPT_ID) references DEPARTMENT (DEPT_ID) )

create table EXEMPT_EMPLOYEE ( EMP_ID. NUMBER(12) create table EXEMPT_EMPLOYEE ( EMP_ID NUMBER(12) not null, EMP_MONTHLY_SALARY NUMBER(8,2) not null, EMP_VACATION_WEEKS SMALLINT not null, constraint PK_EXEMPT_EMPLOYEE primary key (EMP_ID), constraint FK_EXEMPT_E_INHERITAN_EMPLOYEE foreign key (EMP_ID) references EMPLOYEE (EMP_ID) ) create table NON_EXEMPT_EMPLOYEE ( EMP_ID NUMBER(12) not null, UNION_ID NUMBER(8) not null, EMP_HOURLY_RATE NUMBER(5,2) not null, EMP_OVERTIME_RATE NUMBER(5,2) not null, constraint PK_NON_EXEMPT_EMPLOYEE primary key (EMP_ID), constraint FK_NON_EXEM_RELATIONS_UNION foreign key (UNION_ID) references "UNION" (UNION_ID), constraint FK_NON_EXEM_INHERITAN_EMPLOYEE foreign key (EMP_ID) references EMPLOYEE (EMP_ID)