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:
To conver Data Dictionary of a relational databases to a XML-Repository.
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.
Add and editing the Meta-information of the attributes.
Table
Attribute
Associationcontainer
Assoziationtarget
Tables-Label
Attribute-groups (structured attributes)
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).
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.
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.
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.
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
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.
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 |
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
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
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 .
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 |
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.
The Properies of the elements are splited to three typesThe Properies, which belong to GUI-object such length, width (visual appearance).
Linkage with tables-column. Default value and notnull
Information to placement of the element
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.
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:
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.
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)
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.