1. ER Diagrams ● Many different notations are available ● From wikipedia:wikipedia: Entity-relationship modelwikipedia: Entity-relationship model ● How do we decide which to use – Decided by organization – house style – Or constrained by software tools – Or choose the model that best supports communication

2. Examples: facts to model ● A student has one and only one computer ● Each person may own many cars but may own none ● Each car has at most one owner; each car must have an owner. ● Each student may take many modules but may take none; each module may be taken by many students, but may be taken by none.

3. Relationship Participation ● Mandatory (Total) participation – “Every employee has a car” – “Every car has an employee” ● Optional (Partial) participation – “An employee may have a car” – “A car may be assigned to an employee” – “A title may be stocked by a bookshop” – “A bookshop may stock a title”

4. Minimum and Maximum Cardinality ● Maximum cardinalities 1:1, 1:N, N:M; ● Mandatory participation means a minimum cardinality of 1 ● Optional participation means a minimum cardinality of 0 ● Specify the minimum and maximum cardinalities for each relationship

5. Always four numbers ● A relationship needs four numbers – 2 max and 2 min cardinalities ● Each entity has a maximum and a minimum participation constraint ● Clients often fail to tell us one or more – seems obvious? - not to developer – “Each car is allocated to one employee” ● Must all cars be allocated?

6. UML ● Unified Modelling Language – More recent development – Well backed – Result of much experience over many years ● Can model for many different target systems – We use it throughout our courses – Which can be an advantage – but take care; the target system matters!

7. UML Class ● Class – The most common UML classifier – Can describe a kind of object in any kind of system; can describe an entity class – Represented as a rectangle with compartments ● Class in a class diagram – Rectangle with compartments: name, attributes, operations – We won't be using operations for ER modelling

8. UML Associations ● Association is a connection between classes ● Represents a semantic connection between objects ● We will use it to represent relationships between entity classes ● And don't leave out the multiplicity constraints!

9. Multiplicity Constraints ● Multiplicity tells how many objects are linked; it is used to show minimum and maximum cardinalities ● Expressed as 0..1, 0..*, 1..1, 1..* etc. ● Short versions: 1 for 1..1, * for 0..* ● Default is 1, standing for 1..1 ● Short versions and defaults lead to misunderstandings and are discouraged.

10. A 1:1 example ● “each student ‘has’ at most 1 computer, and at least 1 computer” ● ”for each computer there is at most one student, and there may be no student” ● read diagram as “a student has 1 and only 1 computer” – to remember which end is which

11. A 1:M example ● “each person may own many cars, but may own none” ● “each car has at most one owner and every car must have an owner” UML uses * for many

12. An N:M example ● “each student may take many modules but may take none” ● “each module may be taken by many students but may be taken by none”

13. The wordings ● Practice using these readings to translate ER diagrams into the client’s language ● Each can be “said” either way round – max and min cardinalities can be re-phrased ● We are trying to find and be certain about four numbers

14. The numbers ● UML supports – one or two values – values are numbers or * – two values are separated by.. ● e.g. 0..* 0..1 1..1 1..* ● We tend to use just 0, 1 and * ● The relational model does not support other cardinalities well ● You may want to emphasise the importance of non-standard cardinalities Match 0..*2..2 SoccerTeam 2..20..* plays Player 11..*1..1 in 11..*1..1

15. Comments on ER Modelling ● Entities, relationships, cardinalities ● All must be sought, specified, refined ● Similar to object modelling, – but we know we are going in a different direction with the implementation

16. Additional ER concepts ● Weak entities ● Subtypes

17. Weak Entities ● You may identify an entity whose instances cannot exist without a corresponding instance of another entity ● NextOfKin in an employees DB – when employee leaves, we delete the record ● Many notations round the corners on the entity box

18. UML Notation ● We must know one Next of Kin for each member of staff – Composition aggregation – Special case of UML association ● When the member of staff leaves, we want to “forget about” the associated next of kin 1.1 isKnownBy isKnownTo has NextOfKinEmployee

19. Subtypes ● Specialisation/generalisation ● Natural part of our thinking now ● Can be represented fairly well in the relational model ● Newer RDBMS concepts support them directly ● Good part of modelling – worth doing even if implementation were hard

20. “Cardinality” in subtyping ● Can think of – maximum subtyping of an instance ● (can it be subtyped more than once?) – minimum subtyping ● (must it be subtyped at least once?) – Use 0, 1, N etc. ● Really is “participation” ● Mandatory/Optional – must every instance be a member of a subclass? – c.f. abstract class ● Disjoint or not disjoint – must an instance be a member of only one subclass – can it be a member of >1

21. Two contrasting subtype scenarios Employee ClericalTechnicalManagerial Based on Kroenke Client NTUserUnixUserMainframeUser {incomplete, overlappingt} {complete,disjoint}

22. UML facilities ● Attributes can be added, with types etc. – may be able to label the PK (primary key) ● Later stage in the design – tools let you manage the attributes ● (other attribute notations are unwieldy) ● hiding and revealing are useful ● The object constraint language (OCL) expresses constraints in a way that enables tool support ● OCL is a specification language in its own right

23. UML facilities ● Operations in a class have no meaning – (for current generation RDBMS) – But this is changing ● Design can be structured (packages etc.) ● Can relate to documentation (hyperlinks?) ● “Notes” can say almost anything :-)

24. Tours and Operators ● A 'Whole Picture' example ● Tours and Operators (pdf) Tours and Operators (pdf)

25. “Reverse Engineered” ER

26. Constraints and Rules ● The E-R diagram should model, not dictate, the enterprise (business) rules, BUT ● Each binary relationship suggests four cardinality constraints – semantic information ● If not present in the rules, – rules are incomplete – open to ambiguous interpretation – consult, add, document !