Object Role Modeling
Object Role Modeling (ORM, englisch für Modellierung der Rollen von Objekten) dient dazu, im Rahmen der Datenmodellierung einen Ausschnitt der realen Welt (englisch 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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]- Object Role Modeling: Ein Überblick im MSDN (englisch)
- Zeichnung erstellt mit Microsoft Visio Modeller (EXE; 25,26 MB)
Referenzen
[Bearbeiten | Quelltext bearbeiten]- Information Modeling and Relational Databases von Terry Halpin, ISBN 1-55860-672-6.