Erm

Front 1

1.2 2 Redenen voor het gebruk van datamodelleren

Back 1

1. Datastructuren zijn minder variabel dan functies

2. Databases spelen een centrale rol in de architectuur van bedrijfsinformatiesystemen

Front 2

1.4 4 Voordelen van databases

Back 2

1. Ze promoten data-integratie
2. Meerdere applicaties kunnen toegang hebben tot dezelfde database
3. Redundante dataopslag is hiermee verleden tijd
4. Hergebruik wordt gestimuleerd

Front 3

1.7 Op welke statische aspecten van het univerum legt datamodelleren de focus?

Back 3

1. 'dingen', 'objecten' of 'entiteiten'

2. Hun structuren

3. Hun interrelaties

Front 4

1.7 Wat was de reden dat ERM werd opgezet?

Back 4

In de 1970's werd data georganiseerd met bestand-gebaseerde databases. Hiervan bestonden allemaal verschillende soort systemen. Het doel van ERM was om al deze data te kunnen integreren.

Front 5

1.8 Chen's idea

Back 5

Modelleertaal voor conceptuele datamodellen, dat abstraheert van concrete technologieën.

Front 6

1.8 Elementaire concepten van Chen (1976)

Back 6

o Entity, Entity Type (entiteit, entiteitstype)

o Relationship, Role, Relationship Type (relatie, rol, relatietype)

o Attribute, Value, Value Set (attribuut, attribuutwaarde, bereik)

Front 7

2.1 Concept: Entiteit

Back 7

Een entiteit is een ding t distinct kan worden geïdentificeerd.

Notatie: Rechthoek

Front 8

2.1 Concept: Entiteitstype

Back 8

Set van gelijke entiteiten

Front 9

2.2 Concept: Relatie

Back 9

Een associatie tussen meerdere entiteiten.

Notatie: Diamant

Front 10

2.2 Concept: Relatietype

Back 10

Een set van gelijkende relaties.

Front 11

2.3 Cardinaliteit

Back 11

Beschrijft de maximale hoeveelheid entiteiten waar een entiteit mee verbonden kan zijn.

Notatie: cijfertjes

1 = één

N/M = verscheidene

Front 12

2.3 Cardinaliteiten: min,max

Back 12

• Min = minimum aantal entiteiten waar een entiteit mee verbonden moet zijn

• Max = maximum aantal entiteiten waar een entiteit mee verbonden kan zijn

Front 13

2.4 | 6 syntactische regels voor relaties en entiteiten

Back 13

1. A relationship type is connected to at least one, at most two entity types and by two edges.

2. Relationship types must not be connected to relationship types.

3. Entity types that participate in a relationship have to be enriched with cardinalities.

4. An entity type can have any amount of attributes

5. Every attribute has to be specified by a domain. (attribute type)

6. Relationship types do not have any attributes.

Front 14

2.5 Attribuut

Back 14

Een attribuut kent een waarde van een domein toe aan iedere entiteit van een entiteitstype.

Domain: Bereik/lijst van alle mogelijke waarden.

Value: Waarde/ concrete initialisatie van een attribuut voor een specifieke entiteit.

Front 15

2.5 | 4 soorten attributen

Back 15

• Key attribute: identifies an entity (unique)

• Multivalued attribute: can have multiple values at the same time

• Composite attribute: consists of several other attributes

• Derived attribute: Value is derived (e.g., calculated) from other attributes of the same or other attributes

Front 16

2.5 | 5 veelgebruikte domeinen

Back 16

o String

o Integer

o Decimal

o Boolean

o Date

Front 17

3.1 | Specialisatie

Back 17

Het definiëren van een subset onder een superset

Front 18

3.1 | Generalisatie

Back 18

Het definiëren van een superset op basis van meerdere sets of subtypes.

Front 19

3.1 | Supertype

Back 19

Gegeneraliseerd entiteitstype.

Front 20

3.1 | Subtype

Back 20

Gespecialiseerd entiteitstype.

Front 21

3.2 | Set-georiënteerde interpretatie

Back 21

Een entiteit in een subset is ook een element van het corresponderende superset. Hierdoor beschrijft de g/s dus de relatie van de entiteitsset.

Notatie: subset symbool

Front 22

3.4 | 3 regels waar je aan moet voldoen voor een generalisatie

Back 22

o common (essential!) structure of entity types

o same attributes and associated relationship types

o in the application domain the entity types are used in a similar way

Front 23

3.4 | 3 regels waar je aan moet voldoen voor een specialisatie

Back 23

o a set of entities has a partially different structure

o a set of entities has specific (additional) relationships

o in the application domain a set of entities is used in a different way

Front 24

3.6 | Completeness constraint

Back 24

- beschrijft of een einteit tot een subset behoort

- 'total' of 'partial'

Front 25

3.6| Disjoint constraint

Back 25

- Beschrijft of een entiteit tot medere subsets kan behoren

- 'overlapping' of 'disjoint'

Front 26

3.9 | Disjoint-Disjoint constraint

Back 26

Front 27

3.10 | Disjoint-Overlapping constraint

Back 27

Front 28

3.11 | Traditional G/S notation

Back 28

Front 29

3.12 | 4 notaties van constraints

Back 29

Front 30

3.13 | Wat laten constraints ons niet zien?

Back 30

Constraints geven geen informatie over de compleetheid van een model.

Front 31

3.13 | “A total specialisation contains all subtypes”. Goed of fout?

Back 31

Fout, want je weet nooit of het model compleet is.

Front 32

3.16 | S/G in ERM versus S/G in programmeren

Back 32

• Generalisation/Specialisation in ERM:
o An entity of a subtype is also an entity of the super type (at the same time!).
o Moreover: An entity can be part of many subsets, i.e., can be an entity of several super types.
• Generalisation/Specialisation in (most) programming languages (also called: inheritance, “overerving”):
o An object is instance of exactly one class.
o An object of a subclass, thus, cannot be an object of its superclass – although both objects would refer to the same “thing” in the real world.

Front 33

5 | Assessment: Voordelen van ERM

Back 33

- Maakt abstractie van concrete database technologie mogelijk

- stimuleert een intuitieve visualisatie van datastructuren

- high diffusion (?)

Front 34

5 | Asessment: Nadelen van ERM

Back 34

- gelimiteerde set van domeinen om attributen mee te specificeren

- Geen leesrichting voor relatietypes

- traditionele notatie vermindert leesbaarheid

- geen 'common' interpretatie van g/s