SchemaEditor

Die Hauptaufgabe des Schema-Editor ist eine XML-Repository zu schaffen und zu verwalten. Es wird ein Benutzer des Schema-Editor als ein Datenbank-Administrator oder auch ein Daten-Verwalter vorausgesetzt. Der Benutzer hat Kenntnisse über die Struktur der Daten und ihrer Repräsentation im relationalem Modell. Das Schema-Editor besitzt folgende Funktionalitäten:

  1. Die Data Dictionary einer relationalen Datenbank auslesen und in XML-Repository umzuwandeln.

  2. Hinzufügen von semantische Informationen zum Repository. Dabei werden die Reverse Engineering Techniken (siehe. 3.3) benutzt, die entweder ganz automatisch oder durch Befragung des Benutzers verlaufen. Der Benutzer kann auch die semantische Informationen selber hinzufügen .

  3. Hinzufügen und Editieren der Meta-Informationen der Attributen.

Die Idee der graphischer Oberfläche basiert auf der Darstellung des Schema als einer Baumstruktur, die von dem Benutzer manipuliert werden kann. Diese Baumstruktur hat folgende Knotentypen.

Abbildung 2-1. Anzeige von DB-Schema als ein Baum

  1. Tabelle (Knoten)

  2. Attribut (Blatt)

  3. Assoziationcontainer

  4. Assoziationtarget

  5. Tabellen-Etikette

  6. Attribut-Gruppen (strukturierte Attribute)

Reverse Engineering

Das relationale Modell ist streng wertorientiert. Es kennt keine Verknüpfungstypen. Die Verknüpfungen werden als Fremdschlüssel repräsentiert. Die Tabellen können als Entities, Relationen, Teilobjekte (bei Generalisierung) oder Eigenschaften (z.B Listen der Attributen) verwendet werden. Bei Reverse Engineering wird die semantische Bedeutung, also die Information, wie das relationale Modell zu interpretieren ist, wiedergewonnen. Diese Informationen werden durch die Namensgebung der Attribute wiedergespiegelt. Weder MySql noch Postgresql unterstützen die Definition von Fremdschlüssel was bei der Erstellung der Formulare großes Nachteil ist. Die Reverse-Engineering Algorithmen basieren bei Xdobry nur auf den relationalen Schema, der Dateninhalt wird nicht ausgewertet. Es wurden drei Reverse-Engineering Algorithmen implementiert. Die Fremdschüssel-Findung ist eine Basis für andere Algorithmen (außer des Spezialisierung-Findung).

Fremdschlüssel-Findung

Finde alle Attributen die genau so heißen wie die Primärschlüssel der anderen Tabellen aber nicht die Prim-Attributen sind oder nicht einziges Prim-Attribut sind. Beschränkung: Schüssel der Objekttabellen bestehen aus einzigen Attribut . Keine Rekursive Beziehungen! Aktion: Es wird eine einfache Referenz erstellt. Assoziation-Container erhält den Fremdschlüssel. Assoziation-Target erhält den Primärschlüssel. Es ist eine Basis für die weitere Algorithmen.

Spezialisierung-Findung

Suche die Spezialisierung. Finde alle Tabellen die einen gleichnamigen Primärschlüssel haben. Sie müssen die Vatertabelle selbst ermitteln. Bei Mehrstufiger Vererbung (Enkelobjekte) muss die Aktion mehrfach durchgeführt werden. Beschränkung: Schüssel der Objekttabellen bestehen aus einzigen Attribut.

Finde Assoziation-Tabellen

Dieses Reverse Engineering Technik basiert auf dem Schritt "Finde Fremdschlüssel". Es sollten die Tabellen ermittelt werden, die Relationship modellieren (z.B n:m Beziehung). Algorithmus: Finde alle Tabellen, dessen Primärschlüssel aus mehreren Fremdschlüssel besteht oder mehrere Fremdschlüssel und kein eindeutiges Primärschlüssel haben. Aktion: Die Relationship-Tabellen werden besonders gezeichnet. Die n:m oder n:m:z.. Beziehungen werden erkannt. Beziehungen dürfen eigene Attributte haben.

Aggregation Vorschlagen

Dieses Reverse Engineering Technik basiert auf dem Schritt "Finde Fremdschlüssel". Schlage die Aggregation (Komposition) der Tabellen vor. (eingebettete Tabellen). Das Algorithmus zeigt nur die Vorschläge, die Aggregation-Semantik kann nur von Benutzter bestimmt werden. Vorschläge: 1. Alle Tabellen die nur einen Fremdschlüssel haben. Es können noch weiter Aggregation existieren. Überprüfen sie die 1:n Assoziationen

Definieren von Abstraktionen

Es können drei Arten von Abstraktionen der konzeptionellen Datenbankmodellierung definiert werden: Assoziation, Aggregation uns Spezialisierung. Die Definition erfolgt stufenweise mit Hilfe von Assistenten.

Assoziation

ist am schwierigsten zu definieren. Es entspricht den Relationship des ER-Modells. Es werden folgende Fragen gestellt.

Ist die Assoziation rekursiv? Es gibt Beziehungen (Relationship) zwischen den Objekten des gleichen Typs.
Gibst es eine Tabelle mit Referenzen? Musste die Assoziation mit Hilfen von zusätzlichen Tabellen abgebildet werden, was beim N:M Beziehungen immer der Fall ist, oder wie bei 1:N Beziehungen gibt es nur ein Verweis in einer der Tabelle
Granulität der Beziehung: beim N:M ist es 2 beim N:M:O ist es 3
Rollennamen: Ein Objekt Student bekommt durch die Beziehung zu Objekt Prüfung einen Rolennamen Prüfling; (nicht obligatorisch)
Existenz Abhängigkeit: Werden bis jetzt nicht weiter unterstützt können aber hier definiert werden

Beim n:m Beziehungen muss klar werden: welche Objekte (Tabellen) nehmen an der Beziehung teil, welche Tabelle beinhaltet die Verweise.

Eine Assoziation wird als Container (Sammlung) mit Verweisen auf Objekte aufgefasst. Die Sammlung kann entweder als getrennte Tabelle mit Verweisen oder als ein Verweis in einem Objekt (1:n) modelliert werden. Um eine Assoziation zu modellieren werden zwei neue Knotentypen hinzugefügt: Assozitaioncontainer bei Verweisen und Assoziationtarget bei Objekten. Zu jeder Assoziation gehört ein Assoziationcontainer und mindestens zwei Assoziatontargets. Die Assoziationen (Assoziationcontainer) besitzen einen eindeutigen Namen. Auf diese weise können auch komplexe Assoziation modelliert werden wie: rekursive 1:n und n:m Beziehungen und Beziehungen der höheren Granulität n:m:s:r. Entsprechung in ER-Modell Abbildung 2-8

Aggregation

Hier handelt es sich um etwa die Modellierung von eingebetteten oder geschachtelten Tabellen. Sie werden naher von FormServer als eingebettete Formulare dargestellt. Man muss spezifizieren: die Behälter Tabelle, die Element Tabelle und Referenz, Fremdschlüssel in Elementtabelle, das auf Primärschlüssel in Container-Tabelle zeigt. Entsprechung in ER-Modell Abbildung 2-10

Spezialisierung

Auch als Vererbung oder Generalisierung bekannt. Es gibt immer einen Vater Objekt und ein Kind Objekt, die in zwei Tabellen modelliert werden. Man muss auch den vererbten Primärschlüssel angeben. Entsprechung in ER-Modell Abbildung 2-9.