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

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

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