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:
Die Data Dictionary einer relationalen Datenbank auslesen und in XML-Repository umzuwandeln.
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 .
Hinzufügen und Editieren der Meta-Informationen der Attributen.
Tabelle (Knoten)
Attribut (Blatt)
Assoziationcontainer
Assoziationtarget
Tabellen-Etikette
Attribut-Gruppen (strukturierte Attribute)
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).
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.
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.
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.
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
Es können drei Arten von Abstraktionen der konzeptionellen Datenbankmodellierung definiert werden: Assoziation, Aggregation uns Spezialisierung. Die Definition erfolgt stufenweise mit Hilfe von Assistenten.
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 |
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-3
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-5
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-4.
Der Zweck der Komponente ist es zuerst eine Sammlung der Formulare zu einer Datenbank zu generieren und zweitens eine Benutzerschnittstelle für die Anpassung der Formulare zu liefern. Das Produkt des Formular-Editor eine Beschreibung der Formulare als ein XML-Dokument. Dabei wird es im Gegenteil zu vorhanden ähnlichen Systemen nicht einzeln zu jedem Tabellen ein Formular generiert, vielmehr wird eine ganze Sammlung der Formularen in einem Schritt generiert. Dabei werden die Assoziationen im Datenbank in der Formularen direkt unterstützt. Der Benutzer des Formular-Editor (Applikation-Entwickler) muss das Schema der Daten nicht kennen. Seine Aufgabe ist es höchstens die automatisch erzeugte Formulare unter dem gestalterischen Gesichtpunkten anzupassen oder die Eingabefelder des Formulars noch weiter zu spezifizieren.
Ein Formular wird als eine Sammlung von verschiedenen Eingabefelder, ihrer Platzierung, und ihrer Entsprechung zu Objekten in der Datenbank verstanden. Folgende Typen der Eingabefelder wurden realisiert:
Frames. Rahmen für die Platzierung der Elemente |
einfache Textfelder (einzeilig) |
Eingabefelder für Ganzzahlen mit Steuerungspfeilen |
Listenfelder |
Radiobuttons |
Checkbox Felder (Ja/Nein Schalter) |
mehrzeilige Textfelder |
Mehrspaltige Auswahllisten für die Darstellung der Fremdschlüssel (Referenzen) |
Formular Links |
Objekt für die Einbettung von Formularen |
Durch das Doppelklick auf ein Formular in Hauptfenster wird ein GUI Editor für Formulare geöffnet. Damit kann das Aussehen des Formulars und die Verknüpfungen der einzelnen Elemente zum Datenbank spezifiziert werden.
Die Eigenschaften der Elemente werden auf drei TypenDie Eigenschaften, die zu eigentlichen GUI-Objekt gehören wie: Länge, Art.
Verknüpfung mit Tabellen-Spalte. Defaultwert und NotNULL
Angaben zu Platzierung des Elements
side - An welcher Seite der Rahmen soll der Objekt hinzugefügt werden |
anchor - Anker zu welcher Seite |
fill - Soll der Objekt in eine Richtung zu den verbleibenden Platz ausgefühlt werden |
expand - Soll bei Änderung der Fenstergröße der Objekt angepasst werden |
Tip: Die aktuellen Pack Optionen kann man in der Statusleiste nach dem Anzeigen des Widgets mit Mauszeiger auslesen.
Mehr dazu Lesen Sie in Tk-Dokumantation man pack Hier ein Aufschnitt
For each master the packer maintains an ordered list of slaves called the packing list. The -in, -after, and -before configuration options are used to specify the master for each slave and the slave's position in the packing list. If none of these options is given for a slave then the slave is added to the end of the packing list for its parent. The packer arranges the slaves for a master by scanning the packing list in order. At the time it processes each slave, a rectangular area within the master is still unallocated. This area is called the cavity; for the first slave it is the entire area of the master. For each slave the packer carries out the following steps:
The packer allocates a rectangular parcel for the slave along the side of the cavity given by the slave's -side option. If the side is top or bottom then the width of the parcel is the width of the cavity and its height is the requested height of the slave plus the -ipady and -pady options. For the left or right side the height of the parcel is the height of the cavity and the width is the requested width of the slave plus the -ipadx and -padx options. The parcel may be enlarged further because of the -expand option (see ``EXPANSION'' below)
The packer chooses the dimensions of the slave. The width will normally be the slave's requested width plus twice its -ipadx option and the height will normally be the slave's requested height plus twice its -ipady option. However, if the -fill option is x or both then the width of the slave is expanded to fill the width of the parcel, minus twice the -padx option. If the -fill option is y or both then the height of the slave is expanded to fill the width of the parcel, minus twice the -pady option.
The packer positions the slave over its parcel. If the slave is smaller than the parcel then the -anchor option determines where in the parcel the slave will be placed. If -padx or -pady is non-zero, then the given amount of external padding will always be left between the slave and the edges of the parcel.
Es ist ein Programm, mit dem der eigentlicher Endbenutzer der Datenbank zu tun hat. Dieses Programm kann die Formularbeschreibungen, die von Formular-Editor stammen, richtig auswerten und die Formulare darstellen. Dieses Programm muss die Manipulationen auf den Formularen richtig in in die SQL Anweisungen umsetzten und an die Datenbank quittieren. Dabei werden folgende Funktionen unterstützt:
Daten Anzeigen (View)
Daten Modifizieren (Update)
Daten Anlegen (Create)
Daten Filtern oder Durchsuchen
durch Daten Navigieren (Browsing or Navigate)
Die Formulare selbst unterstützen direkt höhere Abstraktionskonzepte wie Assoziation, Aggregation und Spezialisierung. Die Kenntnisse über die Konzepte der relationalen Modellierung wie Fremdschlüssel und Primärschlüssel müssen nicht vorhanden sein. Der Benutzer kann die verständliche und allgemeinere Konzepte wie Aggregation und Assoziation wahrnehmen, ohne auf die besondere Techniken der relationalen Modell eingehen zu müssen.