February 20, 2019 Extended Entity-Relationship (EER) Model ▪ Over the years the ER model has been extended with additional concepts to increase its expressiveness ▪ specialisation and generalisation (ISA relationship) ▪ ISA constraints ▪ aggregation
February 20, 2019 Specialisation and Generalisation ▪ An entity set can be further subgrouped or specialised into distinctive entity sets ▪ an entity subset may for example have additional attributes ▪ top-down approach ▪ Parts of multiple entity sets may be generalised in a higher level entity set ▪ bottom-up approach ▪ Specialisations as well as generalisations are represented by the same ISA relationship construct ▪ represented by a triangle in the EER model ▪ A ISA B implies that every A entity is also a B entity ▪ generalisation can be seen as the inversion of specialisation ISA
February 20, 2019 ISA Relationship Persons id name Students ISA Teachers PhD Students Professors ISA research topic teaching hours studentID #projects LivesAt Locations address 0..* 0..1 ISA
February 20, 2019 ISA Relationship ... ▪ The attributes of a higher level entity set (superclass) are inherited by the lower level entity set (subclass) via the ISA relationship ▪ e.g. students inherit the id attribute from persons ▪ A subclass also inherits any relationship participation from its superclass ▪ e.g. students, teachers etc. can participate in the LivesAt relationship ISA
February 20, 2019 ISA Constraints ▪ To model an application domain more precisely, specific constraints can be defined over an ISA relationship ▪ Membership constraints ▪ a condition-defined membership constraint assigns an entity to a specific subclass based on one or more attribute values ▪ a user-defined membership constraint can be used to manually assign entities to a specific subclass (manual classification) ▪ Disjointness constraints ▪ an overlapping constraint over subclasses specifies that an entity may belong to multiple subclasses - e.g. a person may be a teacher as well as a student - by default, subclasses participate in an overlapping constraint ISA
February 20, 2019 ISA Constraints ... ▪ Disjointness constraints ... ▪ a disjoint constraint specifies that an entity can only belong to exactly one subclass - e.g. a teacher can be either a PhD student or a professor (but not both) - expressed by writing the word disjoint next to the triangle ▪ Completeness constraints ▪ a partial specialisation (generalisation) constraint specifies that some superclass entities may not belong to any subclass - default completeness constraint ▪ a total specialisation (generalisation) constraint defines that each superclass entity must belong to a subclass - e.g. each teacher must belong to the PhD Students or Professors subclass (or to both of them) - represented by a double line connection to the triangle (like total participation) ISA
February 20, 2019 ISA Constraints ... disjointness and completeness constraints are independent of each other ISA Persons id name Students ISA Teachers PhD Students Professors ISA research topic teaching hours studentID #projects LivesAt Locations address birthdate Adults ISA birthdate < 23.02.1996 disjoint 0..* 0..1
February 20, 2019 Aggregation ▪ A limitation of the ER model is that relationships cannot be modelled over other relationship sets ▪ What if we would like to introduce a manager for some (employee, company, duration) combinations? WorksFor Companies Employees id name name address Durations from to 0..* 0..* 1..1
February 20, 2019 Aggregation ... ▪ We cannot just create a 4-ary relationship WorksFor ▪ not all combinations have a manager ▪ Introduce a new 4-ary Manages relationship ▪ problem: we introduce some redundancy! - (employee, company, duration) are replicated in (manager, employee, company, duration) WorksFor Companies Employees id name name address Durations from to Manages Managers 1..1 0..* 0..* 0..* 0..* 0..* 0..*
February 20, 2019 Aggregation ... ▪ An aggregation treats the relationship as a higher level entity ▪ can be used in another relationship WorksFor Companies Employees id name name address Durations from to Manages Managers 1..1 0..* 0..* 1..* 0..*
February 20, 2019 ER Design Issues ▪ When do we model something as an attribute and when as an entity set? ▪ there is no general answer and the choice depends on the specific application domain to be modelled ▪ When do we model something as a relationship set and when as an entity set? ▪ a relationship set often corresponds to an action between entities ▪ In general we should try to avoid higher level n-ary relationship sets ▪ 3-ary relationship sets should be the maximum and even these should be used carefully
February 20, 2019 Attribute or Entity? ▪ Should the address in the example be modelled as an attribute or as a separate entity? ▪ depends on the intended use of the address ▪ if we need an address for different entities (e.g. not just for employees) it is better to model the address as separate entity LocatedAt Offices Employees id name birthday phone age #offices address street city 0..1 0..*
February 20, 2019 Attribute or Entity? ▪ Should the duration be modelled as a from and to attribute or as a separate entity? ▪ Depends again on the use ▪ if we foresee that the same duration period is used by other entity sets, it should be modelled as a separate entity WorksFor Companies Employees id name name address Durations from to 0..* 0..* 1..1
February 20, 2019 N-ary or Binary Relationships? ▪ Basically any n-ary relationship can be replaced by a number of binary relationship sets ▪ "real" 3-ary relationships should not be replaced - e.g. WorksFor presented earlier ▪ the Parents relationship is a example of a non-real 3-ary relationship - have to use null values if there is either no father or mother - better to model it as two separate binary relationships Parents Persons child father mother Persons HasFather HasMother child child father mother 0..* 0..* 0..1 0..1 0..1 0..* 0..*
February 20, 2019 ER Design Principles ▪ Make sure that you pay attention to all the entities, their relationships and any other constraints mentioned in the description (requirements) of a specific application domain ▪ e.g. show cardinality constraints for all relationships ▪ Avoid redundancy! ▪ The resulting conceptual model should be as simple as possible, but not simpler ▪ introduce only necessary entities and relationships ▪ Some constraints (e.g. functional dependencies) cannot be expressed in the ER model ▪ also write down any assumptions
February 20, 2019 ER Design Principles ... ▪ In two weeks we will see how the conceptual ER model can be mapped to a logical database schema (e.g. relational database schema) ▪ The resulting relational schema can be further analysed by using functional dependencies and normalisation
February 20, 2019 Classification and Typing ▪ Aristotle (384 BC-322 BC) introduced a biological classification (ontology) ▪ artificial classification system ▪ organisms with the two subclasses plants and animals ▪ animals further subclassified into animals with blood and animals without blood ▪ animals also classified into walking animals, flying animals and swimming animals (habitat) ▪ Characteristics (problems) of Aristotle's classification ▪ based on behaviour and not on similarities (non-evolutionary) ▪ animals can belong to multiple classes - e.g. a duck belongs to the walking animals as well as swimming animals class Aristotle
February 20, 2019 Classification and Typing ... ▪ Bertrand Russell defined the type of a given predicate P as the entity set spanned by P ▪ intentional notion of type ▪ The notion of type for classi- fying entities based on a set of conditions was questioned by Wittgenstein ▪ there exists no precise definition (type) for some general concepts - e.g. no definition for the general concept of a game ▪ We can have a definitional (e.g. intentional) or prototypical definition of a type Bertrand Russell Ludwig Wittgenstein
February 20, 2019 OM Model ▪ Data model that integrates concepts from the entity-relationship and object-oriented data models ▪ based on objects, collections and associations (binary collections) - supports associations over associations ▪ different types of collections - sets, bags, rankings and sequences ▪ Separates typing and classification (role modelling) ▪ Operational part (algebra) over objects and collections ▪ A family of object database platforms have been realised based on the OM model (e.g. OMS Java) Moira C. Norrie
February 20, 2019 The Unified Modelling Language (UML) ▪ UML is a standard developed by the Object Manage- ment Group (OMG) ▪ used to specify the components of a software system ▪ based on earlier work including the object-modelling technique (OMT) by Rumbaugh et al., the Booch method by Booch and object- oriented software engineering (OOSE) by Jacobson ▪ UML supports different types of diagrams ▪ class diagrams, use case diagrams, package diagrams,... Ivar Jacobson Grady Booch James Rumbaugh
February 20, 2019 UML Class Diagrams ▪ A UML class diagram is similar to an ER model ▪ A UML class is "like" an ER entity set ▪ contains attributes as well as methods Employees id name birthday phone age address employee id name birthday phone address age() ER entity set UML class
February 20, 2019 UML Class Diagrams ... ▪ UML relationship class with attributes can be used like an ER aggregation in other UML relationships ▪ e.g. locatedAt in the example ▪ Note that the position of the cardinality constraints are switched in UML ER relationships UML relationships LocatedAt Offices Employees employee office employee office office employee locatedAt LocatedAt Offices Employees employee office years 0..* 0..1 0..* 0..1 employee office office employee locatedAt years
February 20, 2019 UML Class Diagrams ... Teachers PhD Students Professors ISA disjoint teacher phdStudent professor Teachers PhD Students Professors ISA teacher phdStudent professor overlapping disjoint ER specialisation UML specialisation
February 20, 2019 Modelling Exercises ▪ Model the RSL link model in ER ▪ Define an ER model for the following application ▪ You are going to develop a database for the Chamber of Com- merce and Industry of Brussels (CVO) to manage information about language courses in Dutch, Spanish, French and Italian. The database should store information about the teachers and students as well as the individual language courses. A semester lasts for 13 weeks. Regular courses are scheduled for two sessions (each 3 hours) per week; advanced courses for three sessions (each 4 hours) per week. Each course has a difficulty level (module) of 1, 2 or 3 and costs a certain amount of money. A teacher may not give more than 4 courses and not teach in more than 2 languages. Each student has to do a final exam and will get a grade for the exam.
February 20, 2019 Homework ▪ Study the following chapter of the Database System Concepts book ▪ chapter 7 - sections 7.8-7.10 - Extended ER Model (EER) - Unified Modelling Language (UML)
February 20, 2019 References ▪ A. Silberschatz, H. Korth and S. Sudarshan, Database System Concepts (Sixth Edition), McGraw-Hill, 2010 ▪ M.C. Norrie, An Extended Entity-Relationship Approach to Data Management in Object-Oriented Systems, Proceedings of ER 1993, 12th International Conference on Conceptual Modeling, Arlington, USA, December 1993 ▪ B. Signer and M.C. Norrie, As We May Link: A General Metamodel for Hypermedia Systems, Proceedings of ER 2007, 26th International Conference on Conceptual Modeling, Auckland, New Zealand, November 2007 ▪ https://beatsigner.com/publications/signer_ER2007.pdf