Zum Inhalt springen

„Object Role Modeling“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
[gesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
Keine Bearbeitungszusammenfassung
K typos
Zeile 1: Zeile 1:
[[Datei:ORM-diagram-tkz-orm.png|mini|406px|Beispiel eines ORM2 Diagramms]]
[[Datei:ORM-diagram-tkz-orm.png|mini|406px|Beispiel eines ORM2-Diagramms]]


'''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.
'''''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 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.
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:Orm_modell_beispiel.gif|gerahmt|Einfaches ORM-Beispiel]]
[[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 UoD's. Entitäten werden als Ellipsen dargestellt.
* ''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.
* 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.
* ''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 ==
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.


Um von einer Tabelle mit (signifikanten) Einträgen zu einem ORM-Diagramm zu kommen, kann man folgende sieben Schritte durchlaufen.
# Wandle bekannte Informationen in elementare Fakten um und mache Qualitäts Check.
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.
# Zeichne die fact type und mache einen Populations Check.

# Teste, ob Entity Typen zusammengefasst werden sollten und kennzeichne alle Typen, die aus den Bestehenden berechnet werden können.
# Wandle bekannte Informationen in elementare Fakten um und mache einen Qualitätscheck.
# Füge uniqueness constraints hinzu, und teste die Länge der fact type.
# Zeichne die ''fact type'' und mache einen Populationscheck.
# Füge mandatory role constraints hinzu und teste ob etwas logisch ableitbar ist.
# 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 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- Diagramm erstellt werden.
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."
* „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:
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."
* „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
* ‚Vorlesung‘ und ‚Zeit‘ sind ''entity types''
* 'Vorlesungsname' und 'Uhrzeit' sind Label types und
* ‚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.
* ‚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
* „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.
* „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."
* „Student Müller erreicht Note 2.0 in der Vorlesung Datenbanken.


Das ist nun kein fact type mehr der nur zwei Entity types überspannt.
Das ist nun kein ''fact type'' mehr, der nur zwei ''entity types'' überspannt.


==== Zeichnen der fact types ====
==== Zeichnen der fact types ====
[[Datei:ORM_Vorl-Zeit.jpg|gerahmt|ORM-Diagramm zwischen Vorlesung und Zeit]]
[[Datei:ORM Vorl-Zeit.jpg|gerahmt|ORM-Diagramm zwischen Vorlesung und Zeit]]


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.
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
Da dieser'' fact type'' nur zwei ''entity types'' bindet, ist das ein binärer ''fact type''


[[Datei:ORM_Ternary.jpg|gerahmt|ORM-Diagramm Ternary Fact Type]]
[[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 Entity types bindet.
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 (ISBN 1-55860-672-6)
* ''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

Beispiel eines ORM2-Diagramms

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

Einfaches ORM-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.

  1. Wandle bekannte Informationen in elementare Fakten um und mache einen Qualitätscheck.
  2. Zeichne die fact type und mache einen Populationscheck.
  3. Teste, ob Entity-Typen zusammengefasst werden sollten und kennzeichne alle Typen, die aus den Bestehenden berechnet werden können.
  4. Füge uniqueness constraints hinzu, und teste die Länge der fact type.
  5. Füge mandatory role constraints hinzu und teste ob etwas logisch ableitbar ist.
  6. Füge einschränkende Werte, Mengenvergleiche und Subtyping ein.
  7. 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
Maier
Müller
Schultze
25538402
25587304
25587305
1.3
2.0
2.3
Robotik 15:00
Schmitt
Schmidt
Müller
25534567
25584555
25587304
1.7
2.7
1.0

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

ORM-Diagramm zwischen Vorlesung und Zeit

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

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 entity types bindet.

Referenzen