1. Fundamentals/ICY: Databases 2012/13 WEEK 5 John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK

2. Reminder of Week 4

3. 1:1 Connectivity between Tables PERS-IDNAMEPHONEEMPL IDAGE 9568876Chopples 0121-414-3816 E2256137 2544799Blurp 01600-719975 E8570421 1698674Rumpel 07970-852657 E2256188 5099235BigglesE2256129 PHONETYPESTATUS 0121-414-3816 officeOK 01600-719975 homeFAULT 0121-440-5677 homeOK 07970-852657 mobileUNPAID Note: the representation is still asymmetric in that the People table mentions phones but not vice versa – symmetry would create extra redundancy. NB: Biggles has no phone listed, and 0121-440-5677 has no person recorded. Suggests a possible reason for not combining such tables. 1:1: that is, no more than one phone allowed per person, and vice versa. People Phones

4. 1:M Connectivity between Tables PERS-IDNAMEPHONEEMPL IDAGE 9568876Chopples 0121-414-3816 E2256137 2544799Blurp 01600-719975 E8570421 1698674Rumpel 07970-852657 E2256188 1800748Dunston 0121-414-3886 E2256129 EMPL IDEMPL NAMEADDRESSNUM EMPLSSECTOR E48693BTBT House, London, … 1,234,5678Private TCOM E85704Monmouth School Hereford Rd, Monmouth, … 245Private 2E E22561University of Birmingham Edgbaston Park Rd, …. 3023Public HE People Organizations More than one employee allowed per organization, but no more than one employer per person. NOTE direction of use of the foreign key. Why so??

5. New for Week 5

6. M:N Connectivity between Tables uIF we represent M:N connectivity in a similar way to 1:M, then we can expect that l in the People table: some people will have each several employers listed l or in the Organizations table: an organization will have several employees listed l or both. uThis is a problem. Why?

7. M:N Connectivity between Tables, contd. uBecause of this problem, an M:N relationship is usually broken up into two 1:M relationships. uThis means introducing an extra “bridging” or “linking” or “composite” entity type (hence table) to stand between the two original ones.

8. ORGANIZATIONS EMPLOYMENTS each = person-id + organzn-id possibly plus other attributes M:N -- a person may be employed by more than one organization and an organization may employ more than one person PEOPLE does not have an EMPL ID attrib. does not have a PERS ID attrib

9. M:N Connectivity between Tables using a Bridging Entity Type PERS-IDNAMEAGE 9568876Chopples37 2544799Blurp21 1698674Rumpel88 1800748Dunston29 EMPL IDEMPL NAMEADDRESSNUM EMPLSSECTOR E48693BTBT House, London, … 1,234,5678Private TCOM E85704Monmouth School Hereford Rd, Monmouth, … 245Private 2E E22561University of Birmingham Edgbaston Park Rd, …. 4023Public HE People Organizations PERS-IDEMPL IDSTART 9568876E2256115-06-99 9568876E8570423-11-03 1698674E2256123-11-03 1800748E2256107-07-97 EmploymentsEmploymentsEmploymentsEmployments

10. Strong (or Identifying) Relationships uA relationship from entity type A to entity type B, mediated by having A’s primary key (PK) as a foreign key in B, is strong when B’s PK contains A’s PK. (incl. the case of B’s PK just being A’s PK). So, B entities are defined in terms of A entities. uE.g., A = Customers, B = Dependents, where l A’s PK is: CUST_ID l B’s PK is: CUST_ID, FIRST_NAME, CONNECTION. l So a PK value in B could be (1698674, Mary, child), meaning that this entity is the child called Mary of person 1698674 in the Customer table.

11. a Strong Relationship CUST-IDNAMEPHONEEMPL IDAGE 9568876Chopples 0121-414-3816 E2256137 2544799Blurp 01600-719975 E8570421 1698674Rumpel 07970-852657 E2256188 1800748Dunston 0121-414-3886 E2256129 CUST-IDFIRST NAMECONNECTIONLIVES_WITH 2544799Johncivil partnerTRUE 1698674MarychildFALSE 1698674MaryspouseFALSE 1698674DavidchildTRUE Customers (the “A” type) Dependents (the “B” type) Strong relationship going from A to B (we could say: “B is strongly dependent on A”)

12. Weak (or Non-Identifying) Relationships uA relationship is weak when it isn’t strong! So, most relationships are weak. uNote that strength/weakness is directional: the People to Dependents relationship (above) is strong, but the Dependents to People relationship is weak. uExercise: Can a relationship be weak in both directions? uExercise: Can a relationship be strong in both directions?

13. Weak Entity Types R uA weak entity type E is one such that there is a relationship R from some other entity type F to E that satisfies the following two conditions: l R l R is strong. R l E is existence-dependent on F via R. R That is, an E entity e can only exist in the database if some F entity in the database bears relationship R to e. R —1 R This actually just means that R —1 (the R relationship but in the E to F direction) is mandatory.

14. Weak Entity Types, contd. uSo on a previous slide, Dependents is weak, because there is a strong relationship to it from Customers, and Dependents is existence-dependent on Customers via this relationship. l Mary’s existence in the database as a member of Dependents relies on the existence of customer 1698674 in the database. But this doesn’t mean Mary would vanish from the world if customer 1698674 left the database or even if that customer were to vanish from the world. And indeed Mary could herself be an entity in type Customers, and could remain so even if 1698674 left the DB or really vanished from the world.

15. Strong Entity Types uA strong entity type is one that is not weak! …. uSo, in particular, any entity that receives only weak relationships from other entity types is strong. uSo the usual case is for an entity type to be strong. uAnd any entity type that is not existence-dependent on anything is strong.

16. Mental Exercises for You uWhat about the Employments bridging type we introduced? uAlthough it might look at first as though a strong relationship necessarily implies existence dependence, it doesn’t. Why not? uOne entity type can be existence-dependent on another without therefore being weak. Why?

17. Entity Relationship (ER) Model(s) and Diagrams (ERMs and ERDs)

18. The Entity Relationship Model uIntroduced by Chen in 1976 uMost widely used “conceptual model” of DBs. u“The ER model” : general meaning = just the idea of thinking of things as composed of entities, attributes and relationships. uWe also say that applying this approach in a particular case gives rise to an “ER model” of the specific environment of interest. uDiagrams based on the/a model are a widely accepted and adopted graphical approach to database design. / uThe/an ER model has nothing intrinsically to do with diagrams!!! Let alone any specific sort of diagram!!!

19. A Conceptual Model / uER model that provides high-level, manager/user- friendly view of the database uBasis for identification and description of main data objects and relationships, avoiding details

20. Entity Relationship Diagrams (ERDs) uAn ER model of an environment forms the basis of an ER diagram (ERD) or several ERDs. uThere are several markedly different styles of ERD, and for each main style there are several variants. l And the style in the module handouts will differ somewhat from that in the textbooks and these lectures uAn ERD depicts (some of) the ER model’s entity types, attributes and relationships, and (depending on the diagram style) varying amounts of other info such as connectivities, cardinalities, keys, weakness, …

21. Quick Flavour of Two Styles of Diagram

22. The Completed Tiny College ERD

23. Relationships: The Basic Chen ERD-let

24. Relationships: The Basic Crow’s Foot ERD-let

25. Caution uIn previous two diagrams, each relationship was mandatory in both directions. uBut saying “1:1”, “1:M” or “M:N” does not of itself imply mandatoriness in either direction. In particular, don’t be deceived by the “1” here – it’s not a minimum. uWe will see in a minute how to draw optional (non- mandatory) relationships.

26. A Model for Tiny College

27. 1:1 Relationship Between PROFESSOR and DEPARTMENT (mandatory in both directions)

28. 1:M Relationship Between PAINTER and PAINTING (mandatory in both directions)

29. Tables for that 1:M Relationship

30. M:N Relationship between STUDENT and CLASS (both ways mandatory): preliminary ERD (conceptual level)

31. Conversion to Two 1:M Relationships (towards “logical” level)

32. A Bridge (or Composite) Entity Type uIts table is called a linking table (or bridging table) uIts primary key is composed of the primary keys of each of the entity types to be connected uThose keys are also foreign keys in the bridge type uLinking table may contain multiple occurrences of each foreign key value uMay also contain additional attributes that play no role in the bridging as such

33. Direct Impln of M:N Relationship between STUDENT and CLASS

34. Converting the M:N Relationship into Two 1:M Relationships

35. Connectivity and Cardinality in an ERD

36. Relationship Participation uOptional [in a particular direction, X to Y]: l an X entity occurrence does not require a corresponding Y entity occurrence l i.e. the minimum number of Ys per X is 0 uMandatory [in a particular direction, X to Y]: l an X entity occurrence requires a corresponding Y entity occurrence l i.e. the minimum number of Ys per X is 1 or more

37. Drawing Optionality NOTE: the dashing of the line is NOT because of the optionality, but because of weakness

38. The Chen Representation of the Invoicing Problem

39. The Crow’s Foot Representation of the Invoicing Problem

40. The Attributes of the STUDENT Entity

41. Attributes

42. Weak Entity Types in ERDs

43. A Weak Entity in an ERD

44. A Weak (Non-Identifying) Relationship