Kapitel 2 Benutzer Handbuch

Inhaltsverzeichnis
Systemkomponenten
Schema vs. Formularaussehen
Probleme mit Xdobry

Systemkomponenten

Das System besteht aus 3 ausführbaren Programmen SchemaEditor, FormEditor und FormServer. Die Schnittstellen zwischen den einzelnen Programme sind 2 XML-Dokumenten Typen; das Repository (Standard Datei-Erweiterung .xmldbschema und) und Formular-Beschreibung (Standard Datei-Erweiterung .xmlforms und). Die Bearbeitung von beiden XML-Dokumenten wird von entsprechenden Programmen übernommen, kann allerdings auch manuell in einem Editor erfolgen die passenden DTDs (Document Type Description) finden Sie in Verzeichnis dtd.

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 (s. Abb. 7.2). Diese Baumstruktur hat folgende Knotentypen.

Abbildung 2-1

  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-3

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-5

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-4.

FormEditor

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

Zu speziellen Elemente der Formulare gehören die eingebettete Formulare und die Formular Links. Beide sind verschiedene Visualisierung der Formularverknüpfungen. Die Verknüpfungen entstehend entlang der Beziehung Pfaden (Assoziation oder auch Aggregation). Dabei kann man aus einem Formular ein Formular des Objekts erreichen der ein Fremdschlüssel auf das erste Formular hat. Dabei wird bei dem verknüpften Formular der Fremdschlüssel ausgeblendet (Der Wert wird von ersten Formular bestimmt) und die Dateien werden nach dem Fremdschlüssel gefiltert. Es werden durch die Filterung nur die Objekte gezeigt, die mit dem gezeigten Objekt in dem ersten Formular in Verbindung stehen. Bei eingebetteten Formularen ist der verknüpfte Formular ein Teil des Elternformulars. Bei Formular-Links wird eine Schaltfläche eingebaut, die erst zum öffnen des verknüpften Formulars dient. Die Fremdschlüssel werden nicht als normale Attribute behandelt sondern als spezielle graphische Elemente dargestellt. Dabei sind zwei Tatsachen zu berücksichtigen. Zuerst ist das Wertebereich des Fremdschlüssel durch Integritätsbedingungen auf die Menge von Primärschlüsselwerte in der korrespondierenden Tabelle begrenzt. Das kann durch eine Auswahlliste repräsentiert werden. Der Benutzer weiß dann, dass er nur eine bestimmte Anzahl von Möglichkeiten hat, die er ansehen und auswählen kann. Zweitens sind die Werte des Schlüssel oft für den Benutzer aussageleer oder ungeeignet für die Identifizierung des Objektes. Dafür erwartet der Benutzer weitere Attribute (z.B Name und Vorname außer des PersonalIDs). Die Aggregation kann als die eingebetteten Formulare realisiert werden. Die Assoziation wird als Formular-Links umgesetzt. Die Spezialisierung kann auch als eine Verknüpfung von Formularen realisiert werden. Dabei wird ein Formular für ein Elternobjekt (Ober-Typ) und je ein Formular für den Kindobjekt (Unter-Typ) verwendet.

GUI Editor für Formulare

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.

Abbildung 2-2

Die Eigenschaften der Elemente werden auf drei Typen

Widget

Die Eigenschaften, die zu eigentlichen GUI-Objekt gehören wie: Länge, Art.

Data

Verknüpfung mit Tabellen-Spalte. Defaultwert und NotNULL

Packer

Angaben zu Platzierung des Elements

Die Platzierung der Elemente wird nicht absolut (also mit Koordinaten) aber unter Verwendung von s.g Geometry-Manager angegeben. Bis Jetzt wird nur der Pack-Geomentry-Manager der Tk-Widgetset unterstützt. Die Elementen können in s.g. Frames (Rahmen) gestellt werden (auch geschachtelt). Die Reihenfolge der Elemente in einem Frame ist entscheidend. Der Pack-Geomentry-Manager nimmt nacheinander die Elemente und stellt sie in den Rahmen der restliche Platz wird für nächste Elemente verwendet. Folgende Eigenschaften spezifizieren die Platzierung:

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

Wichtig in diesem Zusammenhang ist die Vorgehensweise wie beim Drag and Drop die Platzierung der Elemente vergenommen wird. Das kann Verwirrung stifften aber ich konnte mir nicht besseres ausdenken. Zeigt man auf ein Frame allgemien wird das Element in deas Frame an letzten Stelle mit Standart Oprionen angefügt (-side top -anchor center -fill none -expand 0). Die genauere Paltzierung wird durch das Anzeigen (Drop) auf ein Element, das bereits in der Frame ist ermöglicht. Die Reihenfolge wird relativ zu dem Angezeigten Element ermittelt, die -side Option wird von dem Element übernommen. Andere Optionen können nur im Eigenschaftenfenster verändert werden.

Tip: Die aktuellen Pack Optionen kann man in der Statusleiste nach dem Anzeigen des Widgets mit Mauszeiger auslesen.

Die meisten Standard-Widget werden angezeigt wie sie sind. Die anderen speziellen Widget wie (NestedForm, FormLink, SQLReference) werden bei GUI Editor durch die Vertreter angezeigt. Ihre Grösse entspricht nicht der Wirklichkeit (Vorsicht beim NestedForm). Will man das tatsächlicht Aussehen der Formulare haben, muss man den FormServer benutzten, die DB-Anbindung ist für solche Zwecke nicht nötig.

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:

  1. 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)

  2. 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.

  3. 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.

Once a given slave has been packed, the area of its parcel is subtracted from the cavity, leaving a smaller rectangular cavity for the next slave. If a slave doesn't use all of its parcel, the unused space in the parcel will not be used by subsequent slaves. If the cavity should become too small to meet the needs of a slave then the slave will be given whatever space is left in the cavity. If the cavity shrinks to zero size, then all remaining slaves on the packing list will be unmapped from the screen until the master window becomes large enough to hold them again.

FormServer

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)

Durch die Formular-Links ist auch eine Navigation durch Dateninhalte entlang der Verknüpfungspfaden möglich. Der Benutzer kann ähnlich wie in Hypertext-Dokumenten navigieren und jede Information auf verschiedenen Wegen erreichen. Vor allem ist die Frage, was ist mit dem Objekt überhaupt verknüpft ist, schnell ohne der Kenntnis des Schemas beantwortet.

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.