Chapter 2. User manual

Table of Contents
System components
Schema vs. Form appearances
Problems with Xdobry

System components

Das system consists 3 executable programsSchemaEditor , FormEditor And FormServer . The interfaces between thies separate programs are to 2 XML-documents types; the Repository (standard file-extension .xmldbschema) and form-description (standard file-extension .xmlforms). The treatment of both XML-documents is taken over from corresponding programs, however, can take place also manually in an editor. You can find the fitting DTDs (Document Type Description) in cataloguedtd.

SchemaEditor

The major task of the schema-editor is to create a XML-Repository and to manage it.. A user of the schema-editor is assumed as a databases-administrator. The user has knowledge about the structure of the data and its representation in the relational model. The SchemaEditor possesses the following functional characters:

  1. To conver Data Dictionary of a relational databases to a XML-Repository.

  2. Add semantic information to the Repository. By using the reverse engineering colleges, which can run either completely automatically or by questioning the user. The user can also add the semantic information separatly.

  3. Add and editing the Meta-information of the attributes.

The idea of the GUI is based on the representation of the schema as a tree structure which can be manipulated by the user. This tree structure has the following edges types.

Figure 2-1.

  1. Table

  2. Attribute

  3. Associationcontainer

  4. Assoziationtarget

  5. Tables-Label

  6. Attribute-groups (structured attributes)

Reverse engineering

The relational model is stron value oriented. It knows no assoziation (relationship) types. The assozation are represented as a foreign key. The tables can represent an Entities (Objects), relations-ship, partial objects (by subtypes modeling) or properies (e.g. , lists of the attributes). With reverse engineering the semantic meaning, also the information how the relational model is to be interpreted, are achived. This information is coded only as the names of the attributes. Neither MySql nor Postgresql support the definition of foreign-keys. This is big disadvantage by the production of the forms. The reverse-engineering algorithms are based only on the relational schema, the data content is not evaluated. It were implemented three reverse-engineerings algorithms. The foreign-key-search is a basis for other algorithms (out of the subtype-search).

Foreign key-search

Find all attributes with the same name as the primary keys of the other tables, however, the Prim-attributes are not Prim-attribute or are not a single Prim-attribute. Limitation: object tables consist only single prim-attribute. No Recursive relations! Action: a simple reference is constructed. Association-container gets the foreign key. Association-Target gets the primary key. It is a basis for the other algorithms.

Subtype-search

Search for the subtype. Find all tables having one primary keys of the same name. They(you) must determine the father's table themselves. With Multi-level inheritance (grandson's objects' the action must be executed repeatedly. Limitation: object tables consist only single prim-attribute.

Find association-tables

These reverse engineering technology is based on the step "foreign-key-search". The tables should be determined which model Relationship (e.g., n:m Relationship). Algorithm: Find all tables whose primary key exists(consists) of several foreign keys or several foreign keys and no unambiguous primary key have. Action: the Relationship-tables are particularly drawn. N:m or n:m:z. Relations are recognized. Relations may have own Attributtes.

Suggest Aggregation

These reverse engineering technology is based on the step "foreign-key-search". Suggest the Aggregation (composition) of the tables (Embedded tables). The algorithm shows only the suggestions, the Aggregation-semantics can be determined only by used. Suggestions: 1. All tables only a foreign key have. It can exist still farther Aggregation. If they check 1:n associations

Define abstractions

Three sorts can be defined by abstractions of the conceptual databases modelling: association, Aggregation (composition) specialization (subtypes). The definition takes place gradually with the help of assistants.

Association

Is the most difficult to define. It corresponds to the Relationship of the ER-model. It are placed the following questions.

Is the association recursive? There are relations (Relationship) between the objects of the same type.
Is ther a table with references? If the association with help had to be illustrated by additional tables what is relations always the case with the N:M, or how with 1:N relations there is only a reference in one of the table
Degree of the Relationship: with the N:M it is 2 with the N:M:O it is 3
Rolle-names: (not obligatorily)
Existence dependence: Do not become till present farther supported, however, can be defined here

For the n:m relationship must become clear: which objects (tables) participate in the Relationship and which table contains the references?

An association is understood as container (collection) with references to objects. The collection can be modelled either as a separated table with references or as a reference in an object (1:n). Around an association become to model two new edeg-types added:Assozitaioncontainer With references and Assoziationtarget With objects. An association container and at least two Assoziatontargets belongs to every association (relationship). The associations (association container) possesses an unambiguous name. In this way can also be modelled complex association such as recursive 1:n and n:m relations and relations the higher Granulität n:m:s:r. Correspondence in ER-modelFigure 2-3

Aggregation

Here it is about the possibly modelling of nested tables. They are shown as embedded (nested) forms from FormServer. One must specify: the container-table, which element-table and reference, foreign key in the element table which points at primary key in container-table. Correspondence in ER-modelFigure 2-5

Subtypes (inclusion dependency)

Also known as inheritance or generalization. There is always a father object and a child object which are modelled in two tables (primary key heritance). One must also give the inherited primary key. Correspondence in ER-modelFigure 2-4 .

FormEditor

The purpose of the component is to generate a collection of the forms to a databases and secondly an user's interface for the adaptation of these forms. The product of the form-editor is a description of the forms as a XML-document. Associations (Relationship) and other abstractions are supported in the forms directly. The user of the form-editor (application-developer) must not know the schema of the data. His task is only to adapt the automatically produced forms under the formative face point or to specify the input fields of the form.

A form becomes as a collection of different input fields, their placement, and their correspondence to objects in the databases (rows in a table). The following types of the input fields were realized:

Frames. Frames for the placement of the elements
Simple text fields (one-line)
Input fields for whole numbers with control arrows
Listsbox
Radiobuttons
Checkbox fields (Yes / No switches)
Text fields consisting of several lines
Multicolumn Listboxes for the representation of the foreign key (references)
FormLinks
Object for the nesting forms

The embedded forms and the formlinks belong to special elements of the forms. Both are a different visualization of the relationship. The FormLinks appearing along coresponding paths (association or also Aggregation). Besides, one can reach from a form a form of the object which has a foreign key on the first form. Besides, the foreign key is faded out with the tied up form (the value is determined by the first form) and the files are filtered after the foreign key. It are shown by the filtering only the objects which are in touch with the shown object in the first form. With embedded forms the tied up form is a part of the parent's form. With form-links a command button is inserted, only to open of the tied up form serves. The foreign keys are not treated as normal attributes but are represented as special diagrammatic elements. First the domain of the foreign key is limited by integrity conditions on the amount of primary key values in the corresponding table. This can be represented by a listbox. Then the user knows that he has only a certain number of possibilities at which he can look and select. Secondly the values of the key are often statement-empty for the user or unsuitably for the identification of the object. For it the user expects other attributes (e.g. name and first name besides of the PersonalIDs). The Aggregation can be realized as the embedded forms. The association is realized as form-links. The specialization can also be realized as a linkage by forms. Besides, a form is applied for a parent's object (high type) and one form for the children's object (under type).

GUI-Editor for forms

An GUI-Editor is opened by the double click on a form in main window. With it the appearance of the form and the linkages to table-columns in the dtatbase can be specified.

Figure 2-2.

The Properies of the elements are splited to three types

Widget

The Properies, which belong to GUI-object such length, width (visual appearance).

Data

Linkage with tables-column. Default value and notnull

Packer

Information to placement of the element

The placement of the elements is not indicated definitely (with coordinates), however, under use by Geometry-manager. Only the Pack-Geomentry-Manager is supported yes (the Tk-Widgetset) The elements are places in Frames (also nested). The order of the elements in a Frame is crucial. The stack-Geomentry-Manager takes one after another the elements and places them(her) in the frame the remaining place it is applied for the next elements. The following qualities specify the placement:

Side - in which page(side) of the frames the object should be added
Anchor - anchor to which pageside
Fill
Expand - the object should be adapted by change of the window size

Tip: One can see the current pack options in the status bar, after pointing the Widgets with mouse's pointer.

Most standards-Widget are displayed like they are (WYSIWYG). The other special Widget like (NestedForm, form link, SQLReference) are indicated with editor GUI by the representatives. Their size does not correspond to the reality (caution with the NestedForm). If one wants to have the tatsächlicht appearance of the forms, one mustFormServer Used, the DB-connection is not necessary for such purposes.

More in addition man-pages in Tk-Dokumantationman pack Here a cut

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

It is a program with which the real end user of the databases has to do. This program can evaluate the form descriptions which come from form-editor, display the forms and connect to database. This program must give a receipt for the manipulations on the forms correctly in in the instructions SQL to the databases. Following functions are supported:

  • Data View

  • Data modifying (update)

  • Data create

  • filter or search Data

  • (new future) data navigating (Browsing)

By the form-links a navigation is also possible by data contents along the linkage paths (relationship-path). The user can navigate like in hypertext-documents and reach every information. The user must not know the schema to work whith FormServer.

The forms themselves support directly higher abstraction concepts like association, Aggregation and specialization. The knowledge about the consepts of the relational modelling like foreign key and primary key must not exist by user.