Abbildung: Entity-Typ Mitarbeiter mit Attributen
| home | ITIL | IT Management | Prozessmanagement | Kontakt |
| ITIL Software | Projektmanagement | Organisation | Dienstleistungen |
b
Die Vorgehensweise bei der Datenmodellierung ist vergleichbar mit dem Verfassen eines Aufsatzes. Man erarbeitet zunächst ein Konzept und überträgt dieses dann in "Reinschrift". So wird bei der Datenmodellierung zunächst der für das Unternehmen relevante Realitätsausschnitt abstrahiert dargestellt und zwar unabhängig von den Anwendungsprogrammen oder Datenbanksystemen. Gegenstand des Konzepts sind die Objekte mit ihren Eigenschaften und die Beziehungen zwischen den Objekten.
Wichtig sind dabei die grundlegenden Beziehungen zwischen den Objekten der Realität und die Stellung bzw. Bedeutung des einzelnen Objektes innerhalb der Gesamtheit aller Objekte. Die Realität wird simplifiziert, idealisiert, formalisiert und dadurch systematisiert. Um die Semantik in leicht verständlicher Weise darzustellen, bedient man sich grafischer Hilfsmittel wie z. B. des Entity-Relation-Modells von CHEN (allg. Bezeichnung: Semantische Modelle). Charakteristisch für solche Modelle ist, dass sie nur dann verändert werden müssen, wenn sich der relevante Realitätsausschnitt ändert.
Dieses allgemeine Modell kann dann im nächsten Schritt in jedes beliebige logische Datenbankmodell umgesetzt werden (hierarchisches, netzwerkförmiges oder relationales Datenbankmodell). I. d. R. wird heute das relationale Datenbankmodell verwendet, da dieses die logische und physische Datenunabhängigkeit gewährleistet.
Im dritten und letzten Schritt geht es darum, das logische Datenbankmodell in das physische / interne Modell umzusetzen. Erst hier wird die physische Organisation der Datenbank wichtig wie z.B. der Speichermedien, Speicherplätze und Zugriffsformen.
Zusammenfassend lässt sich die Vorgehensweise folgendermassen formulieren:
in Betracht.
Konzeptionelles Datenmodell
Wenn wir ein Unternehmen der realen Welt betrachten, so müssen wir, je nachdem, was wir untersuchen wollen, von vielen konkreten Dingen abstrahieren und uns ein geeignetes Modell von diesem Unternehmen machen.
Das konzeptionelle Datenmodell gibt ein datenorientiertes Abbild der Realität wieder (es gibt auch ablauf- und funktionenorientierte Abbilder). In diesen werden die interessierenden Objekte mit ihren Eigenschaften sowie den zwischen ihnen bestehenden Beziehungen erfasst.
Entities (Objekte)
Die einzelnen realen Objekte werden als Entities bezeichnet. Solche Entities können z. B. sein: einzelne Personen, Orte, Gegenstände, Begriffe, Ereignisse oder beliebige andere reale oder abstrakte Dinge, die aus Aufgabensicht von Interesse sind. Ein Beispiel wären solche Entities: "Projektleiter Häberle", "Mitarbeiter Müller", "Projekt Copy1" usw.
Klassen/Entity-Typen (Objekttypen)
Um die Komplexität des realen Unternehmens im Modell zu reduzieren, wird nach strukturellen Ähnlichkeiten gesucht: Aufgrund gewisser Ähnlichkeitskriterien, die den Entities zukommen, werden Klassen von Entities gebildet, wie z. B., um bei dem Teilbereich eines Industrieunternehmens zu bleiben:
Ein "Projektleitertyp" ist in dem unten erstellten ERM nicht enthalten. Hieraus wird ersichtlich, dass es bei der Modellierung in dieser Phase stark auf den Ausschnitt der jeweilig betrachteten Aufgabe ankommt. Verschiedene Sichtweisen sind in dieser Phase möglich und auch gewollt.
oder:
Ein "Angestelltertyp" ist in dem unten erstellten ERM ebenfalls nicht enthalten., man kann sich den "Angestellten" aber als Spezialisierung von Mitarbeitertyp vorstellen.
Um von einzelnen Entity-Typen zu übergeordneten Entity-Typen zu gelangen, sind vor allem zwei Vorgehensweisen wichtig:
Einzelne Entity-Typen werden zu einem (#1) Typ verallgemeinert, bspw. alle einzelnen Mitarbeiter zum Mitarbeitertyp
Bereits zusammengefasste Entity-Typen werden wieder detailliert, um Informationen zu den verschiedenen Typen i.S. der Ziele der Datenorganisation (s.o) besser zur Verfügung stellen zu können. So könnte bspw. der Entity-Typ "Mitarbeiter" in "Projektleitertyp" und "Projektmitarbeitertyp" spezialisiert werden.
Der Grad der Spezialisierung bzw. Generalisierung stellt eine wichtige Modellierungsentscheidung des Analysten dar. Sie richtig zu treffen, erfordert neben Erfahrung sehr weitgehende Kenntnis des Fachproblems sowie der Anwendungsprogramme und des Datenbanksystems selbst. Sie sehen, dass die Vorgehensweise bei der Datenmodellierung keine einfache lineare Abfolge von Aktivitäten ohne Rückkoppelung darstellt.
In bildlichen Darstellungen werden Entity-Typen durch
ein Rechteck dargestellt: "Projekt", "Mitarbeiter" oder "Produkt" sind
beispielsweise solche Entity-Typen.
Attribute (Eigenschaften)
Informationen über Entities bestehen zum einen aus den Ausprägungen (Werte) der Eigenschaften der Entity. Die Ausprägungen machen Entities unterscheidbar und im Sinn der betriebswirtschaftlichen Aufgabe verwendbar. Realweltobjekte haben im Prinzip unendlich viele Eigenschaften. Bei der Datenmodellierung müssen die betriebswirtschaftlich relevanten herausgefunden werden, dies ist in der Praxis oft sehr zeitaufwendig und auch nur inkrementell zu bewältigen. Projekte können bspw. durch ihre Projektnummer, ihren Namen, ihre Beschreibung usw. inhaltlich beschrieben werden.
In der ERM-Darstellung werden die Attribute mit Kreisen an die zugehörigen Entity- oder Beziehungs-Typen angehängt:
Beispiel sind die Attribute "Name", "Adresse", "Gehalt" des Entity-Typs Mitarbeiter oder auch die Attribute "Proj#" und "Beschreibung" des Entity-Typs "Projekt".
Abbildung: Entity-Typ Mitarbeiter mit Attributen
Domäne (Wertebereich)
Jedes Attribut kann Werte aus einem definierten Wertebereich (Domäne) annehmen, etwa für ein konkretes Produkt:
Wir ersehen aus diesen Beispielen bereits eine charakteristische Eigenschaft der Klassenbildung: Jedem Entity-Typ kann man eine Kombination von Attributen, jedem Entity dieses Typs eine entsprechende Kombination von Attributwerten zuordnen. Die Modellbildung muss so geschehen, dass diese Attributkombinationen das zugehörige Entity eindeutig identifizieren und aufgabengerecht beschreiben.
Als Wertebereich denkbar wären z.B. 0000..9999 für PE#, oder 00..99 für PROJ#.
Beziehungen
Zwischen Entities gibt es bestimmte Beziehungen, z. B. zwischen bestimmten Projektleitern und Projekten:
Beziehungstypen (Relationen)
Analog zu den Entities werden gleichartige Beziehungen zu Beziehungstypen zusammengefasst, zum Beispiel zwischen Produkten und Projekten (allgemein):
LEITEN: Projektleiter leiten bestimmte Projekte. In bildlichen Darstellungen stellen wir Beziehungen durch eine Raute dar, mit welcher die beteiligten Entity-Typen mit Strichen verbunden sind.
Abbildung: Beispiel für die Darstellung einer Relation (Beziehung)
Beziehungen können ebenso wie Entity-Typen Attribute besitzen (entsprechende konkrete Beziehungen zwischen Entities besitzen entsprechende Attributwerte), so
ARBEITET FÜR: Mitarbeiter arbeiten in bestimmten Funktionen in einem Projekt mit.
Abbildung: Beispiel für die Darstellung eines Attributs einer Relation
Beziehungstypen zwischen Mengen
Im Rahmen des ERM können 1:1-, 1:n- sowie m:n- Beziehungen (Komplexitäten) zwischen je zwei Entity-Typen dargestellt werden:
Bei einer 1:1-Beziehung wird jedem Element der ersten Menge genau ein Element der zweiten Menge zugeordnet und umgekehrt.
Bei einer 1:n-Beziehung werden jedem Element der ersten Menge n Elemente der zweiten Menge zugeordnet, jedem Element der zweiten Menge aber genau ein Element der ersten Menge, bspw. ist jeder der (vielen, also n) Mitarbeiter immer genau einer (also 1) Abteilung zugeordnet.
Bei einer n:m-Beziehung werden einem Element der ersten Menge mehrere Elemente der zweiten Menge zugeordnet und umgekehrt, bspw. arbeiten mehrere Mitarbeiter an einem Produkt, jeder Mitarbeiter arbeitet an mehreren Produkten.
Die Komplexität des Beziehungstyps wird an die Kanten des ERM eingetragen.
Festlegung der Schlüsselattribute
Ein (#1) Attribut oder eine (#1) Attributkombination dient zur Identifikation jeder Entity. Diese Attribute werden als Schlüsselattribute des Entity-Typs bezeichnet. Im Beispiel sind die Personalnummer PE# und die Projektnummer PROJ# Schlüsselattribute. Beide Attribute sind eigentlich künstlich erzeugt, ihnen entsprechen keine beobachtbaren Eigenschaften von Entities wie der Name, die Adresse, das Geburtsdatum, der Projektname oder ähnliche. Sie werden bewusst erzeugt und ausschliesslich zur Identifikation benötigt. Liegen beobachtbare Merkmale vor, die eine Identifikation erlauben, können diese als Schlüsselattribute verwandt werden. Schlüsselattribute werden zur Kennzeichnung unterstrichen.
Beziehungen werden meist durch das Zusammenfügen der Schlüsselwerte der betreffenden Entity-Typen identifiziert - hier also die LEITEN-Beziehungen durch Angabe der Personal- und Projektnummer. Sie können auch ein eigenes Schlüsselattribut bekommen.
Wozu das Ganze?
Entity- und Beziehungstypen dienen dazu, statische Strukturen im Unternehmen zu beschreiben. Zeitlich veränderlich ist hingegen die Menge der konkret vorhandenen Entities und Beziehungen zwischen diesen Entities.
Das Unternehmen ist in Wahrheit natürlich viel komplexer als im Beispiel. Zum Beispiel müsste man noch die Entity-Typen Lager, Kunde, Bestellung, Auftrag usw. und die damit verbundenen Beziehungen einbeziehen. Aus Gründen der Übersichtlichkeit sind diese Entities und Beziehungen jedoch in dem Beispiel weggelassen, das geht in der Praxis natürlich nicht. Es wird eine unternehmensweite konzeptuelle Datenmodellierung angestrebt, die in einem (#1) Unternehmensdatenmodell ihr Ergebnis findet. Dies ist mit derart vielen praktischen und theoretischen Schwierigkeiten verbunden, dass vielfach schon ein abteilungsweites Datenmodell einen echten Fortschritt mit sich bringt.
Es nützt wenig, allein die Daten einheitlich zu modellieren. Die Prozesse und Funktionen sind genauso wichtig.
Der Aufwand zur Erstellung eines Unternehmensdatenmodells ist enorm gross. Das in dem betriebswirtschaftlich bedeutsamen Produkt R/3 implementierte Datenmodell hat beispielsweise allein mehrere Millionen Euro gekostet. Eine Wirtschaftlichkeitsbetrachtung ist immer vorzunehmen. (Faustregel: "Die ersten 80% kosten soviel Geld und Zeit wie die letzten 20%)
Die Unternehmensdaten sind unterschiedlich zeitstabil. Ein Unternehmensdatenmodell sollte vor allem diejenigen Entity-Typen und Beziehungen abbilden, die sich nicht oder nur sehr selten ändern.
Setzen wir nun die einzelnen Ergebnisse des ersten Schrittes der Datenmodellierung zusammen, erhalten wir ein konzeptionelles Datenmodell. Wir stellen es - da es so üblich, übersichtlich und leicht verständlich ist - in einem ERM dar. ERM bedeutet: Entity-Relationship-Modell, also ein (graphisches) Modell der Objekte und ihrer Beziehungen:
Abbildung: Beispiel für ein Entity-Relationship-Modell (ERM)
Das ERM ist der Input für den nächsten Schritt, die Erstellung des logischen Datenbankmodells. Da später Modellierungsfehler gar nicht mehr erkannt werden oder nur noch mit sehr viel Aufwand korrigiert werden können, sollten Sie der ersten Phase stets die allergrösste Sorgfalt entgegenbringen. Dies gilt analog für alle Aufgaben, die mit der Erstellung von Informationssystemen zu tun haben.
Weiter zu:
| home | ITIL | IT Management | Prozessmanagement | Kontakt |
| ITIL Software | Projektmanagement | Organisation | Dienstleistungen |