Introduction to modeling

Introduction to modeling ER modellingSlides for this part are based on Chapters 8 from Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition (ISBN: 978-0-12-373568-3), published by Morgan Kaufmann Publishers.

Where are we?

Intro • ER models business domains in terms of entities that have attributes and participate in relationships • Very popular data modeling approach for databases • Originally proposed by Peter Chen in 1976 Material on this slide based on Ch 8.1 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Barker notation • Building blocks: entities, relationships, and attributes • Attributes: • “#” indicates that the attribute is, or is a component of, the primary identifier of the entity type • “*” indicates that the attribute is mandatory • “°” indicates the attribute is optional • Relationships are restricted to binaries • A solid half-line denotes a mandatory role, and a dotted half-line indicates an optional role • Crow’s foot notation is used for cardinality; intuitively indicates “many”, by its many “toes”; the absence of a crow’s foot intuitively indicates “one” Material on this slide based on Ch 8.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Barker notation (cont’) • ER diagram (a) and its equivalent to ORM (b) • Verbalization: Each A (must | may) beR(one and only oneB| one or moreB-plural-form) • Each Employee must be an occupier of one and only one Room; Each Room may be occupied by one or more Employees. Material on this slide based on Ch 8.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Equivalent Barker ER and ORM diagrams Material on this slide based on Ch 8.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Composite identification in Barker ER • A bar “|” across one end of a relationship indicates that the relationship is a component of the primary identifier for the entity type at that end. • Composite identification in (a) Barker ER and (b) ORM Material on this slide based on Ch 8.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Other constraints in Barker ER • Exclusion constraints are shown as an “exclusive arc” connected to the roles with a small dot or circle • Mutually exclusive and disjunctively mandatory constraints uses the exclusive arc, but each role is shown as mandatory (solid line) Material on this slide based on Ch 8.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Other constraints in Barker ER • Subtyping is depicted with a version of Euler diagrams. Material on this slide based on Ch 8.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Barker ER notation – summary Material on this slide based on Ch 8.3 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Information Engineering (IE) Notation • Different versions exist, no single standard • Supported by many data modeling tools very popular notation for database design Material on this slide based on Ch 8.3 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Equivalent constraint patterns in IE and ORM Material on this slide based on Ch 8.3 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

IDEF1X notation overview Material on this slide based on Ch 8.4 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

ERmap – Mapping from ORM to ER Material on this slide based on Ch 8.5 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Some examples of ERmap steps Step 1.1 Step 2 Step 1.2 Step 3 Step 1.3 Step 4 Material on this slide based on Ch 8.5 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

Some remarks on ER vs ORM • In general, attribute-free approaches have advantages for conceptual analysis, including simplicity, stability, and ease of validation • Attributes allow compact diagrams that directly represent the implementation data structures (e.g., tables or classes). • Compact yet still high level view of the business domain • But whether some fact ends up in the design as an attribute should not be a conceptual issue • Attribute-free approaches offer greater semantic stability • If one models a feature as an attribute and finds out later that something needs to record about it, it needs to be remodel as an entity type or relationship because attributes can’t have attributes or participate in relationships • ORM models facilitate validation by both verbalization and population • Attributes make it awkward to use sample data populations • ER models are further removed from natural language and may be harder for the domain expert to conceptualize • Ternary vs binary relationships: an n-ary association may always be transformed into binaries, however this may introduce an object type that appears artificial to the domain expert • In general ER notations are less expressive than ORM for capturing constraints or business rules

Resources • Chapter 8 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition (ISBN: 978-0-12-373568-3), published by Morgan Kaufmann Publishers. • Richard Barker, Case*Method: Entity Relationship Modelling (1990), published by Addison-Wesley Professional • Tools: • RISE Editor: http://www.risetobloome.com/ • Calligra Flow: http://www.calligra.org/flow/ • Dia: http://live.gnome.org/Dia/

Next lecture

Questions?

Introduction to modeling