ER Diagrams Many different notations are available From wikipedia: wikipedia: 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
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.
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
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
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?
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!
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
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!
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.
A 1:1 example Student 0..1 has 1..1 Computer 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
A 1:M example Person 1..1 owns 0..* Car 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
An N:M example Student 0..* takes 0..* Module each student may take many modules but may take none each module may be taken by many students but may be taken by none
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 rephrased We are trying to find and be certain about four numbers
UML supports one or two values values are numbers or * two values are separated by.. e.g. 0..* 0..1 1..1 1..* Match plays The numbers SoccerTeam 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 nonstandard cardinalities in Player 0..* 2..2 1..1 11..*
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
Additional ER concepts Weak entities Subtypes
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
UML Notation NextOfKin 1.1 isknownto has 1.1 isknownby Employee 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
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
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
Two contrasting subtype scenarios Client Employee {incomplete, overlappingt} {complete,disjoint} NTUser UnixUser MainframeUser Clerical Managerial Technical Based on Kroenke
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
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 :-)
Tours and Operators A 'Whole Picture' example Tours and Operators (pdf)
Reverse Engineered ER ToursAndOperators.Tour -TourID:int -OperatorCode:String -Transport:String -StartPlace:String -PlaceVisited:String -Duration:Object -GoldFare:long -SilverFare:long -StandardFare:long -ChildDiscount:float -Supplement:long 0..* runs 1..1 ToursAndOperators.Operator -Code:String -CompanyName:String -Telephone:String -Fax:String -CharterRates:boolean
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!