Entity-Relationship (ER) Modelling ER modelling - Identify entities - Identify relationships - Construct ER diagram - Collect attributes for entities & for relationships - Record attributes in the design through schemas - Decide on cardinalities in relationships Extensions to basic ER modelling

Step 1: Identifying entities What entities we need to represent in the database? – Depends on the application. E.g.: People: staff, clients/customers, patients, members, owners, contacts, other individuals,... Objects: stock items, real estate, offices,... Organisations: firms (suppliers or customers), departments, charities, clubs, committees,... Object classes: recordings, films, books, types of stock, biological species, work roles,... Events: concerts, examinations, lecture courses, consultations, sales,...

Step 1: Identifying entities (cont'd) How we get the entities from the customers - main entities ~ nouns in natural language - but not every noun warrants to be an entity * Is there more than one instance of this entity? If not, a constant will do. * If there is more instance, are these fixed? (e.g. the days of the week)? If so, no need to create an entity * Is anyone really interested in the instances? If not, no need for the entity as it will just cutter the database.

Step 2: Identify relationships These appear as verbs in natural language. E.g. Ownership: person owns object Lines of command: person supervises person Participation: person participates in event Part of relationship: item is part of order; person belongs to organisation Location: house is located in region Personal: person is married to person; person is parent of person

Step 2: Identify relationships (cont'd) - There can be more than 2 entities involved in a relationship, although this is somewhat less common. - E.g. a sale involves a seller, a buyer, a property, a lawyer,... - E.g. an exam involves a student, and examiner, a course - Sometimes it's difficult to decide whether to use a relationship or an entity - The good news is, it doesn't really matter, as through the ER modelling we will get the same tables anyway!

Step 3: Draw an ER diagram

Step 4: Collect attributes Entities have many attributes in order to identify the real-world entity. - usually include an artificial id as the primary key - some attributes are complex (e.g. address) or varying (e.g. list of children) – don't worry about this at this stage. Relationships have few attributes because the participating entities have all attributes that describe them. - usual attributes refer to time, e.g. worked at branch since... until... - the keys of participating entities will be included automatically at a later stage

Step 4b: Record attributes in the design A good way to do this is ia schemas. E.g.: Employee(eid, first_name, middle_name, last_name, date_of_birth, home_address, national_insurance_number, first_day_of_employment,... ) Underline attribute(s) that you wish to use as primary key. Note: The point of this whole modelling phase is to find the correct table where the info should be stored. So do NOT include attributes that refer to other entities (e.g. department, manager) as these are best placed in their own table.

Step 5: Cardinalities in relationships That is: The expected number of times a particular instance of that entity will take part in the relationship. We have 4 different cases: (1,1) (0,1) (1,n) (0,n) Add these multiplicities to the ER diagram.

Put it all together The design of the Employees database

Extensions to basic ER Hierarchies - Allows us to split an entity into subtypes – and so we can have different table structure for each subtype! Weak entities - this is like an attribute that is itself a table!

Logical Design Logical design: Translating ER diagrams into SQL “CREATE” statements 1. Translate strong entities. a) determine attributes b) determine attribute types c) determine a primary key d) write out the SQL “CREATE” statement 2. Complete the schema notation 3) Declare constraints

Logical Design (cont'd) 4. Translate Relationships 5. Special cases re translation of relationships 6. Sequence generators (for unique serial numbers) 7. Translate weak entities 8. Translate generalisation hierarchies 9. More database constraints 10. Misc.

1. Translating strong entities b) Attribute types: BOOLEAN CHAR CHAR(n) [string of exactly n characters] TEXT [string of arbitrary length] VARCHAR(n) [string of up to n characters] INT or INTEGER DECIMAL or NUMERIC [string s.t. 002 = 2; but 0.10<>0.1] REAL [beware rounding errors!] DECIMAL(n,m) or NUMERIC(n,m) [exactly m digits after dp] DATE TIME [HH:MM:SS; '<' can do comparisons] SERIAL [we also need to say PRIMARY KEY] and more [specific to PostgreSQL]

1. Translating strong entities (cont'd) b) Attribute types: Q: What if my attribute is a “structure”? – (e.g. Address) A: Q: What if my attribute is a list of variable length? A:

1. Translating strong entities (cont'd) c) Determine a primary key Needs to be a unique identifier! Usually requires to create an artificial attribute Could be an integer or a string (strings don't remove the leading zeros!) d) Write out the SQL “CREATE” statement. For the “staff” table this would look as follows: CREATE TABLE staff (sid SERIAL PRIMARY KEY, title VARCHAR(6), firstname VARCHAR(15), lastname VARCHAR(20), VARCHAR(40), office INT, phone INT);

2. Compete the schema notation - we underline the attributes that form a primary key for the table (could be multiple attributes that together form a primary key) - we add a superscript 'o' for all attributes that are allowed to be NULL (those that don't have the superscript are not allowed to br NULL) staff(sid, title, firstname, lastname, ◦, office ◦, phone ◦ )

3. Declaring constraints Constraints are meant to maintain the integrity of the database. The PRIMARY KEY declaration above is an example of a constraint. Other common constraints: NOT NULL UNIQUE Note. PRIMARY KEY is in fact a combination of both.

3. Declaring constraints (cont'd) From: staff(sid, title, firstname, lastname, ◦, office ◦, phone ◦ ) We get: CREATE TABLE staff (sid SERIAL PRIMARY KEY, title VARCHAR(6) NOT NULL, firstname VARCHAR(15) NOT NULL, lastname VARCHAR(20) NOT NULL, VARCHAR(40) UNIQUE, office INT, phone INT);

Next: Translating relationships... A relationship is translated as a separate table. - we incorporate as attributes the primary keys of the entities involved in the relationship. So they become “foreign keys” in the relationship table.