1. Database Design E-R

6. Occurrences versus Entities 56 28 Jack Ackov Jill Hill Entity Occurrences Entity Instances Objects Let’s consider these two instances. Here we have both Jack and Jill, aged 56 and 23 respectively. By themselves they exist as people in their environment. In this case we consider them to be two customers. If we wish to model them and all of the possible customers that we have we need to create an Entity Class for all possibilities.

7. Occurrences versus Entities 56 28 Jack Ackov Jill Hill CUSTOMER Customer# CustName Customer# CustName 56 28 Jack Ackov Jill Hill CUSTOMER( Customer#, CustName ) Entity Occurrences Entity Instances Objects These are the Tuples of the table below Entity Classes Entity Types Entity Sets This will convert to the schema below with Customer# being the Primary Key

8. 56 28 Jack Ackov Jill Hill Bike Cup of Tea Pussy Cat 23 156 234 1 50 25 3 12 4 1 Here we have Jack and Jill placing orders for particular items of stock. They appear to order different amounts of each. For instance Jack orders 3 bikes. Each item being ordered also has a Stock#, Price and Description. These are individual instances of the process so we need to be able to represent any possibility of this in our model. See how we do this on the next page.

9. 56 28 Jack Ackov Jill Hill CUSTOMER Customer# CustName ITEM Stock# ORDERS Desc Price Quantity Bike Cup of Tea Pussy Cat 23 156 234 1 50 25 3 12 4 1

10. Occurrences to Entities to Schemas Customer# CustName 56 28 Jack Ackov Jill Hill CUSTOMER( Customer#, CustName ) Customer# 56 56 28 28 ORDERS( Customer#, Stock#, Quantity ) Stock# Desc 23 156 234 Bike Cup of Tea Pussy Cat ITEM( Stock#, Price, Desc ) Price 50 1 25 Stock# 23 156 156 234 Quantity 3 12 4 1

15. Narrative & Forms 1 Search for strong entities and attributes Entities Attributes 3 Search for relationships Relationships 2 Identify strong entities Strong entities 4 & 5 Determine constraints and attach attributes Entity-Relationship Diagram 6 Expand attributed relationships and/or multivalued attributes Weak Entities 7 Identify weak entities Identified weak entities 6’ Represent attributed relationships and/or multivalued attributes as Functional Dependencies Functional Dependency Diagrams The Method

17. A worked example finding strong Entities A customer is identified by a customer#. A customer has a name and an address. A customer may order quantities of many items. An item may be ordered by many customers. An item is identified by a stock#. An item has a description and a price. A stock item may have many colours. Any item ordered by a customer on the same day is part of the same order Here we have a scenario. Try to firstly identify all of the strong entities followed and all of the attributes. Can you also identify a weak entity? Are there any attributes that you have missed?

18. Worked Example Continued Let us take and place it around the nouns. These lead us to what we will consider to be the strong entities. If we then place the around items that we think would be the attributes, we can see if if any of the identified Entities are strong. You will notice that the item has a description, price, colour and stock # and a customer has a customer number, name, and address. These a Existence Independent Entities, and hence they must be strong. A customer is identified by a customer#. A customer has a name and an address. A customer may order quantities of many items. An item may be ordered by many customers. An item is identified by a stock#. An item has a description and a price. A stock item may have many colours. Any item ordered by a customer on the same day is part of the same order

19. Worked Example Continued We have our Entities and the attributes displayed before us. Customer and Item are strong entities as they are Existence Independent. What about Order? Order cannot be identified completely by any of its own attributes. It is dependent on the attributes of the other 2 entities to be identified. An order is made up of a customer ordering an item. We need the customer# and the item# to identify the order Conceptual Schema CUSTOMER ITEM Description Address Price Quantity Customer# Stock# Customer Name Date ORDER Colour

25. Relationships and the Worked Example . Conceptual Schema We can now deal with the order. The order is a relationship between the Customer and the Item. It is for a set Quantity on a given Date. ITEM CUSTOMER Customer# Price Address CustName Stock# Desc Colour Date Qty ORDERS

27. These are Steps 4,5 & 6 from the Original Diagram Relationships Strong entities 4 & 5 Determine constraints and attach attributes Entity-Relationship Diagram 6 Expand attributed relationships, domain sharing & multivalued attributes Weak Entities 7 Identify weak entities Identified weak entities Unattched Attributes Unidentified weak entities

30. Step4. The Resulting ER with the Cardinality Constraints in Place CUSTOMER ITEM ORDERS Many CUSTOMERs can ORDER an ITEM. Many ITEMs can be ORDERed by a CUSTOMER. CITY LIVES IN Many CUSTOMERs can LIVE IN a CITY. A CUSTOMER can LIVE IN only one CITY. {Colour} An ITEM can have many Colours.

32. Step4.Determine constraints: Participation. CUSTOMER CITY LIVES IN This is also the case for the Customer living in the City. Does the customer have to live in the City? In this case Yes, as we class all areas as being within a City. Hence we place the “|” symbol beside the cardinality constraint next to the Entity City. The next one is difficult. Does a City have to have a Customer living in it. You might think No here, but are you prepared to record all of the cities in the world just to make sure? Common sense tells us that we have to make this mandatory so we only keep a record of the cities where our Customers live.

33. Step4. The Resulting ER with the Participation Constraints in Place CUSTOMER ITEM ORDERS An ITEM might be ordered by a CUSTOMER. A CUSTOMER might order a ITEM. CITY LIVES IN A CITY must have a CUSTOMER LIVing IN it. A CUSTOMER must LIVE IN a CITY.

34. Step4. Determine constraints: Validation by Population. CUSTOMER ITEM ORDERS CITY LIVES IN Cust# Stock# CityName {Colour} An important method of evaluating the proposed model is to populate with instances that demonstrate that the constraints that you have identified will work.

35. Step4. Tables Created to Validate CUSTOMER ITEM ORDERS CITY LIVES IN Cust# Stock# 12 23 12 13 77 77 88 99 CityName Cust# Ayr Ayr Tully 12 23 13 Cust# Stock# CityName {Colour} Colour Stock# Pink Blue 77 77

36. Step5. Attach remaining attributes to entities and relationships. In the previous lectures we looked at a worked problem with a Customer ordering an Item. Here we were able to identify Entities from the narration. Next we also listed the attributes which helped us identify the Strong Entities. We noticed that there were some Attributes, Qty and Date, left that could not be attached to any of the strong entities. They, in fact, belong to the Relationship that was associated with the two Entities. ITEM CUSTOMER Customer# Price Address CustName Stock# Desc Colour Date Qty ORDERS

37. Step5. Attach remaining attributes to entities and relationships. The quantity attribute cannot be attached to the Customer, as the Customer will order different quantities of various items at any time. It cannot also be attached to the Item. It must therefore be attached to the relationship between them, being the order. This is also the situation for the Date that the order was placed.

38. Step5. Attach remaining attributes to entities and relationships. Conceptual Schema ITEM CUSTOMER Customer# Price Address CustName Stock# Desc {Colour} Date Qty ORDERS

39. Step6.Expand multi - valued attributes, domain sharing attributes and binary relationship attributes. Once we have identified the Strong Entities, Relationships and attached all Attributes to either the Strong Entities or Relationships, we are required to expand the diagram as much as possible to permit us to complete the process. This requires us to move in 2 directions. We must first look at all of the binary relationships to see what the cardinality constraints are between them. If they are “many-to-many” they must be carefully considered and expanded where appropriate. We then must look at what we call Multi-valued Attributes and Domain Sharing Attributes. The process is shown on the following diagram.

40. Step6 Entity-Relationship Diagram Expand relationships with attributes Dependent Entities Many-to-many Relationships with Attributes Multi-valued Attributes Domain Sharing Attributes Expand Multi - valued and domain sharing attributes Characteristic Entities Associative Entities

41. Step6 In the worked example we have a Many-to-Many relationship with 2 attributes . When we have a Many-to-Many relationship with attached attributes we are required to create an Associative Entity that bridges the 2 Entities. Conceptual Schema ITEM CUSTOMER Customer# Price Address CustName Stock# Desc {Colour} Date Qty ORDERS

42. ITEM CUSTOMER Customer# Price Address CustName Stock# Desc Date Qty ORDER MAKES FOR Associative Entity Step6 Between Customer and Item we create the Weak (Associative) Entity called Order. We have to redo the constraints. A customer can place many orders or none. An order can come from only one customer, and must be from a customer. An order is for many items and must be for at least one item, and an item can be on many orders but does not have to appear on an order. These have all been placed in the diagram shown below in their correct position.

43. ITEM CUSTOMER Customer# Price Address CustName Stock# Desc Colour Date Qty ORDER COLOUR MAKES FOR HAS Associative Entity Characteristic Entity Step6 We have also noticed that an item can come in many colours. This is a multi-valued attribute. We can show this in our extended diagram by having a relationship between the Item and the Colour, where colour is the only attribute of the entity. In this case we are also saying that the colour of the item is optional (IE natural if requested) and that the only colours to be recorded are those that are used.

44. Step6. Expand domain sharing attributes. Managers supervise Workers. All employees are residents of a City. Employees who live in different cities from their managers get a special allowance. MANAGER WORKER SUPERVISES City City Allowance MANAGER SUPERVISES CityName Allowance CITY OF OF WORKER Characteristic Entity

46. Step7. Identify weak entities. Conceptual Schema ITEM CUSTOMER Customer# Price Address CustName Stock# Desc Colour Date Qty ORDER COLOUR MAKES FOR HAS An ORDER is uniquely identified by the CUSTOMER and the Date.

47. Step7. Identify weak entities. Here we still have the relationship between Order and Item that is many to many with attributes. We must expand this. Conceptual Schema ITEM CUSTOMER Customer# Price Address CustName Stock# Desc Colour Date Qty ORDER COLOUR MAKES FOR HAS

48. Step8. Iterate until no further expansion is possible. An intersection entity is one that is identified by only by its relationships. We introduce the weak entity orderline that for one item. It is fully dependent on the attributes of Order and Item to be identified Conceptual Schema ITEM CUSTOMER Customer# Price Address CustName Stock# Desc Colour Date Qty ORDER COLOUR MADE BY FOR HAS ORDERLINE HAS An ORDERLINE is identified by an ITEM on an ORDER.

52. Course Specifications Form

53. Course Offering Form

54. Course Attendance Form