Sonstiges > Entwicklung > ORM-Ansatz

Datenbanken - Entwicklung mit dem Object Role Modell

Der ORM-Ansatz ist im Gegensatz zum traditionellen ERM sehr schematisiert und vereinheitlicht. Daher sind die Diagramme ohne weitere Informationen lesbar, was den Austausch von Informationen stark vereinfacht. Object Role Modeling hat seinen Namen aufgrund seiner Weltsicht erhalten, welche den zu modellierenden Weltausschnitt als eine Menge von Objekten (Werten oder Einheiten) sieht, welche Rolle in Beziehungen spielen. Dabei werden die relevanten Daten als elementare Fakten (elementary facts) definiert. Diese wiederum zeichnen sich dadurch aus, dass sie nicht in kleinere Fakten aufgeteilt werden können, ohne Informationen zu verlieren.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Sonstiges > Entwicklung > ORM-Ansatz Freitext

Eine Einheit (Objekt) wird als Ellipse dargestellt. Prädikate und Rollen werden als Rechtecke mit einer Unterteilung pro Rolle dargestellt, wobei diese Rollen mit ihren Einheiten verbunden sind. Die Rolle wird dabei mit einem Satz / Stichwort beschrieben, welche in beide Richtungen (Aktiv, Passiv) lesbar ist und daher das Verständnis des Diagramms deutlich verbessert. Diese Grundkonstruktion kann dann durch obligatorische Übernahme von Rollen und durch Hierarchiebeziehungen verfeinert werden.

Zu Beginn eines Projekts zur DB-Entwicklung steht immer eine ausführliche Untersuchung über die Anforderungen, welche Transaktionen und Prozesse, die mit der Datenbank erfolgen sollen, nötig machen. Dabei gilt es, von möglichst vielen Endbenutzern, welche in Gruppe geschichtet werden sollten, individuell Anforderungsprofile zu sammeln und diese in der Umsetzungs- und Konzeptionsphase zu berücksichtigen.
In einer zweiten Phase wird dann das eigentliche Modell erstellt. Dabei kann zum einen das zukünftige Datenbanksystem unberücksichtigt bleiben, damit anhand der Modell-Komplexität ein geeignetes System ausgewählt werden kann. Zum anderen bietet diese Phase allerdings auch die Möglichkeit, das System, in dem das konzeptuelle Modell später eingesetzt werden soll, von vorneherein zu bestimmen. Im ersten Fall hat man die Möglichkeit, ein optimales System für die Transaktions- und Benutzerzahlen sowie für die Komplexität des Modells auszuwählen, während man beim zweiten Möglichkeiten - aber auch Einschränkungen -, welches ein gegebenes System bietet, gleichfalls zu berücksichtigen. Insbesondere proprietäre Erweiterungen wie spezielle Programmiertechniken in Form von prozeduralen SQL-Erweiterungen können hier sehr gut in ein erweitertes DB-Design einbezogen werden.
In einer dritten Phase wird dann anhand des Modells mit der Hilfe von Testdaten und den zuvor ermittelten Anwendungsfällen ein virtueller oder realer Testbetrieb durchgeführt.
Anschließende Phasen in der Form von neuen Projekten können dann die konkrete Umsetzung der gefundenen Modellstruktur und der Programmierung der DB-eigenen Prozeduren sein. Für Datenbanken mit besonders intensivem Austausch von dichten Daten wie z.B. Textdateien oder organisationsübergreifendem Datenaustausch können bereits in der Analyse- und Entwicklungsphase die Integration von XML-Technologien eingeflochten werden. Dies erspart dann später evtl. Anpassungen an das Design. Den XML-Einsatz unterstützen auch hier schon Überlegungen zum eingesetzten System sowie der umgebenden System-Landschaft und verwendeten Programmiersprache.

• DB-Installation und -Konfiguration
• XML-Einsatz und automatischer Datenaustausch
• Software-Entwicklung und DB-proprietäre Programmierung mit PL/SQL und Transact SQL