„Object Role Modeling“ – Versionsunterschied
[gesichtete Version] | [gesichtete Version] |
Keine Bearbeitungszusammenfassung |
K typos |
||
Zeile 1: | Zeile 1: | ||
[[Datei:ORM-diagram-tkz-orm.png|mini|406px|Beispiel eines ORM2 |
[[Datei:ORM-diagram-tkz-orm.png|mini|406px|Beispiel eines ORM2-Diagramms]] |
||
'''Object Role Modeling''' ('''ORM''' |
'''''Object Role Modeling''''' ('''ORM,''' {{enS}} für ''Modellierung der Rollen von Objekten'') dient dazu, im Rahmen der [[Datenmodellierung]] einen Ausschnitt der realen Welt (engl. {{lang|en|''universe of discourse''}}'', UoD'') zu beschreiben. Es beschreibt Objekte und ihre Rollen zueinander entweder in einfachen Sätzen, oder in intuitiven Diagrammen. |
||
Es dient zum |
Es dient zum Einen in der konzeptionellen Phase der Anwendungsentwicklung der Verständigung zwischen Anwendern und Entwicklern, wobei ausschließlich das Was, also die Sachlogik, und nicht das Wie, also die Technik, dargestellt wird. Zum Anderen dient das ORM-Modell in der Implementierungsphase als Grundlage für das Design der Datenbank. |
||
== Beispiel == |
== Beispiel == |
||
[[Datei: |
[[Datei:Orm modell beispiel.gif|gerahmt|Einfaches ORM-Beispiel]] |
||
Im Bild rechts wird eine einfache Beziehung dargestellt: Ein ''Angestellter'' arbeitet in einem ''Department''. |
Im Bild rechts wird eine einfache Beziehung dargestellt: Ein ''Angestellter'' arbeitet in einem ''Department''. |
||
Dieses Diagramm stellt die drei grundlegenden Objekttypen vor: |
Dieses Diagramm stellt die drei grundlegenden Objekttypen vor: |
||
* |
* ''Entities'' (Angestellter und Departement) sind die eigentlichen Objekte des UoDs. Entitäten werden als Ellipsen dargestellt. |
||
* Roles (Arbeitsplatz) (auch |
* Roles (Arbeitsplatz) (auch ''fact type'') stellen die Beziehung zwischen Entities (Objekten) dar. Rollen werden als aneinanderhängende Rechtecke dargestellt. |
||
* |
* ''Label'' („Name des Angest.“ und „Name des Dep.“) sind die Typen der Objekte. |
||
Eine '''Instanz''' in diesem Beispiel ist eine Belegung der Tabelle. Zum Beispiel: |
Eine '''Instanz''' in diesem Beispiel ist eine Belegung der Tabelle. Zum Beispiel: „Franz Otto arbeitet im Verkauf.“ Hierbei ist Franz Otto eine Instanz von Angestellter und Verkauf eine Instanz von Department. |
||
"Franz Otto arbeitet im Verkauf". Hierbei ist Franz Otto eine Instanz von Angestellter und Verkauf eine Instanz von Department. |
|||
== Algorithmus == |
== Algorithmus == |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
# Füge einschränkende Werte, Mengenvergleiche und Subtyping ein. |
# Füge einschränkende Werte, Mengenvergleiche und Subtyping ein. |
||
# Füge restliche Bedingungen ein und führe letzten Check durch. |
# Füge restliche Bedingungen ein und führe letzten Check durch. |
||
=== Algorithmus an einem Beispiel === |
=== Algorithmus an einem Beispiel === |
||
Gegeben ist folgende Tabelle. Daraus soll ein ORM- |
Gegeben ist folgende Tabelle. Daraus soll ein ORM-Diagramm erstellt werden. |
||
{| border="1" cellspacing="0" cellpadding ="5" style="border-collapse:collapse;" |
{| border="1" cellspacing="0" cellpadding ="5" style="border-collapse:collapse;" |
||
Zeile 94: | Zeile 95: | ||
==== Umwandlung bekannter Informationen in elementare Fakten ==== |
==== Umwandlung bekannter Informationen in elementare Fakten ==== |
||
In diesem Schritt versucht man, sich über die Typen und ihren Zusammenhang klar zu werden. |
In diesem Schritt versucht man, sich über die Typen und ihren Zusammenhang klar zu werden. |
||
Zuerst versucht man, die gegebenen Informationen in aussagekräftige Sätze umzuwandeln: |
Zuerst versucht man, die gegebenen Informationen in aussagekräftige Sätze umzuwandeln: |
||
* |
* „Datenbanken wird um 15:00 Uhr gehalten.“ |
||
Um nun leichter auf das Diagramm schließen zu können, muss man sich Gedanken machen, was nun ein |
Um nun leichter auf das Diagramm schließen zu können, muss man sich Gedanken machen, was nun ein ''entity type,'' ein Label ''type'' und eine Instanz eines ''entity types'' darstellt. Der obige Satz lässt sich umformulieren in: |
||
* |
* „Die ''Vorlesung'' mit dem ''Vorlesungsnamen'' Datenbanken wird zu der ''Zeit'' vom Typ ''Uhrzeit'' 15:00 Uhr gehalten.“ |
||
Aus diesem Satz kann man ablesen: |
Aus diesem Satz kann man ablesen: |
||
* |
* ‚Vorlesung‘ und ‚Zeit‘ sind ''entity types'' |
||
* |
* ‚Vorlesungsname‘ und ‚Uhrzeit‘ sind ''label types'' und |
||
* |
* ‚Datenbanken‘ und ‚15:00 Uhr‘ sind Instanzen von Vorlesung und Zeit und sind vom Typ Vorlesungsname und Uhrzeit. |
||
Da Zeit sich in dieser Tabelle wirklich nur auf die Vorlesung bezieht, ist dieser Satz richtig und vollständig. |
Da Zeit sich in dieser Tabelle wirklich nur auf die Vorlesung bezieht, ist dieser Satz richtig und vollständig. |
||
Zeile 108: | Zeile 111: | ||
Zwei '''falsche''' Sätze: |
Zwei '''falsche''' Sätze: |
||
* |
* „Student Müller erreichte die Note 2.0.“ → Hier bleibt die Frage, in welcher Vorlesung er sie erreicht hat |
||
* |
* „In der Vorlesung Datenbanken wurde die Note 2.0 vergeben.“ → Hier entsteht die Frage, für welchen Studenten das gilt. |
||
Richtiger Satz: |
Richtiger Satz: |
||
* „Student Müller erreicht Note 2.0 in der Vorlesung Datenbanken.“ |
|||
Das ist nun kein fact type mehr der nur zwei |
Das ist nun kein ''fact type'' mehr, der nur zwei ''entity types'' überspannt. |
||
==== Zeichnen der fact types ==== |
==== Zeichnen der fact types ==== |
||
[[Datei: |
[[Datei:ORM Vorl-Zeit.jpg|gerahmt|ORM-Diagramm zwischen Vorlesung und Zeit]] |
||
Aus dem Satz: |
Aus dem Satz: „Die ''Vorlesung'' mit dem ''Vorlesungsnamen'' Datenbanken wird zu der ''Zeit'' vom Typ ''Uhrzeit'' 15:00 Uhr gehalten.„ kann man nun folgendes Diagramm erstellen. Dabei ist es erlaubt, den ''label type'' in Klammern unter den ''entity type'' zu schreiben. |
||
Da dieser fact type nur zwei |
Da dieser'' fact type'' nur zwei ''entity types'' bindet, ist das ein binärer ''fact type'' |
||
[[Datei: |
[[Datei:ORM Ternary.jpg|gerahmt|ORM-Diagramm ''Ternary Fact Type'']] |
||
Aus dem Satz: "Student Müller erreicht Note 2.0 in der Vorlesung Datenbanken." erstellt man nun ein ORM-Diagramm mit einem ternären fact type, da dieser fact type drei |
Aus dem Satz: "Student Müller erreicht Note 2.0 in der Vorlesung Datenbanken." erstellt man nun ein ORM-Diagramm mit einem ternären ''fact type,'' da dieser ''fact type'' drei ''entity types'' bindet. |
||
== Weblinks == |
== Weblinks == |
||
* [http://msdn.microsoft.com/de-de/library/aa290383.aspx Object Role Modeling: Ein Überblick im [[MSDN]]] (englisch) |
* [http://msdn.microsoft.com/de-de/library/aa290383.aspx ''Object Role Modeling:'' Ein Überblick im [[MSDN]]] (englisch) |
||
* Zeichnung erstellt mit [http://download.microsoft.com/download/visio2000enterprise/ORMtool/3.1/WIN98/EN-US/MSVM31.EXE Microsoft Visio Modeller] (EXE-Datei, 25,26 MB) |
* Zeichnung erstellt mit [http://download.microsoft.com/download/visio2000enterprise/ORMtool/3.1/WIN98/EN-US/MSVM31.EXE ''Microsoft Visio Modeller''] (EXE-Datei, 25,26 MB) |
||
== Referenzen == |
== Referenzen == |
||
* Information Modeling and Relational Databases von Terry Halpin |
* ''Information Modeling and Relational Databases'' von Terry Halpin, ISBN 1-55860-672-6. |
||
[[Kategorie:Datenbankmodellierung]] |
[[Kategorie:Datenbankmodellierung]] |
Version vom 20. September 2013, 13:19 Uhr

Object Role Modeling (ORM, englisch für Modellierung der Rollen von Objekten) dient dazu, im Rahmen der Datenmodellierung einen Ausschnitt der realen Welt (engl. universe of discourse, UoD) zu beschreiben. Es beschreibt Objekte und ihre Rollen zueinander entweder in einfachen Sätzen, oder in intuitiven Diagrammen.
Es dient zum Einen in der konzeptionellen Phase der Anwendungsentwicklung der Verständigung zwischen Anwendern und Entwicklern, wobei ausschließlich das Was, also die Sachlogik, und nicht das Wie, also die Technik, dargestellt wird. Zum Anderen dient das ORM-Modell in der Implementierungsphase als Grundlage für das Design der Datenbank.
Beispiel

Im Bild rechts wird eine einfache Beziehung dargestellt: Ein Angestellter arbeitet in einem Department. Dieses Diagramm stellt die drei grundlegenden Objekttypen vor:
- Entities (Angestellter und Departement) sind die eigentlichen Objekte des UoDs. Entitäten werden als Ellipsen dargestellt.
- Roles (Arbeitsplatz) (auch fact type) stellen die Beziehung zwischen Entities (Objekten) dar. Rollen werden als aneinanderhängende Rechtecke dargestellt.
- Label („Name des Angest.“ und „Name des Dep.“) sind die Typen der Objekte.
Eine Instanz in diesem Beispiel ist eine Belegung der Tabelle. Zum Beispiel: „Franz Otto arbeitet im Verkauf.“ Hierbei ist Franz Otto eine Instanz von Angestellter und Verkauf eine Instanz von Department.
Algorithmus
Um von einer Tabelle mit (signifikanten) Einträgen zu einem ORM-Diagramm zu kommen, kann man folgende sieben Schritte durchlaufen. Es ist ein etwas formeller Weg zu einem ORM-Diagramm, aber meist (besonders für komplizierte Diagramme) ist es hilfreich, sich das schrittweise zu überlegen und nicht zu versuchen, alles auf einmal umzuwandeln.
- Wandle bekannte Informationen in elementare Fakten um und mache einen Qualitätscheck.
- Zeichne die fact type und mache einen Populationscheck.
- Teste, ob Entity-Typen zusammengefasst werden sollten und kennzeichne alle Typen, die aus den Bestehenden berechnet werden können.
- Füge uniqueness constraints hinzu, und teste die Länge der fact type.
- Füge mandatory role constraints hinzu und teste ob etwas logisch ableitbar ist.
- Füge einschränkende Werte, Mengenvergleiche und Subtyping ein.
- Füge restliche Bedingungen ein und führe letzten Check durch.
Algorithmus an einem Beispiel
Gegeben ist folgende Tabelle. Daraus soll ein ORM-Diagramm erstellt werden.
Vorlesung | Zeit | Student | Matrikelnr. | Note | |||||||||
Datenbanken | 15:00 |
|
|
| |||||||||
Robotik | 15:00 |
|
|
|
Umwandlung bekannter Informationen in elementare Fakten
In diesem Schritt versucht man, sich über die Typen und ihren Zusammenhang klar zu werden. Zuerst versucht man, die gegebenen Informationen in aussagekräftige Sätze umzuwandeln:
- „Datenbanken wird um 15:00 Uhr gehalten.“
Um nun leichter auf das Diagramm schließen zu können, muss man sich Gedanken machen, was nun ein entity type, ein Label type und eine Instanz eines entity types darstellt. Der obige Satz lässt sich umformulieren in:
- „Die Vorlesung mit dem Vorlesungsnamen Datenbanken wird zu der Zeit vom Typ Uhrzeit 15:00 Uhr gehalten.“
Aus diesem Satz kann man ablesen:
- ‚Vorlesung‘ und ‚Zeit‘ sind entity types
- ‚Vorlesungsname‘ und ‚Uhrzeit‘ sind label types und
- ‚Datenbanken‘ und ‚15:00 Uhr‘ sind Instanzen von Vorlesung und Zeit und sind vom Typ Vorlesungsname und Uhrzeit.
Da Zeit sich in dieser Tabelle wirklich nur auf die Vorlesung bezieht, ist dieser Satz richtig und vollständig. Etwas komplizierter wird es wenn man sich die Note ansieht.
Zwei falsche Sätze:
- „Student Müller erreichte die Note 2.0.“ → Hier bleibt die Frage, in welcher Vorlesung er sie erreicht hat
- „In der Vorlesung Datenbanken wurde die Note 2.0 vergeben.“ → Hier entsteht die Frage, für welchen Studenten das gilt.
Richtiger Satz:
- „Student Müller erreicht Note 2.0 in der Vorlesung Datenbanken.“
Das ist nun kein fact type mehr, der nur zwei entity types überspannt.
Zeichnen der fact types

Aus dem Satz: „Die Vorlesung mit dem Vorlesungsnamen Datenbanken wird zu der Zeit vom Typ Uhrzeit 15:00 Uhr gehalten.„ kann man nun folgendes Diagramm erstellen. Dabei ist es erlaubt, den label type in Klammern unter den entity type zu schreiben.
Da dieser fact type nur zwei entity types bindet, ist das ein binärer fact type

Aus dem Satz: "Student Müller erreicht Note 2.0 in der Vorlesung Datenbanken." erstellt man nun ein ORM-Diagramm mit einem ternären fact type, da dieser fact type drei entity types bindet.
Weblinks
- Object Role Modeling: Ein Überblick im MSDN (englisch)
- Zeichnung erstellt mit Microsoft Visio Modeller (EXE-Datei, 25,26 MB)
Referenzen
- Information Modeling and Relational Databases von Terry Halpin, ISBN 1-55860-672-6.