Rules of transition between levels of representation of data...

Rules for transition between data model representation levels

Earlier, in Ch. 1, the levels of representation of data models that determine the use of appropriate terminology and technologies for presenting and describing the data to be represented in the implementation of the database were considered. Thus, at the analytical and conceptual levels, when the analysis of the subject area and the description of business processes are considered, information data structures are presented in the form of business elements and data warehouses. At the logical level, the developers represent the logical and infologic models of the database, oriented to the representation of the database and the informational structure of the subject area, respectively. At the datological and physical levels, the database implementation model is represented. At the internal and external levels - the actual execution of the database on a magnetic medium. Between these levels, in order to ensure the integrity of the design, the transition processes are applied (Figure 4.73), many of which are implemented in the respective tools.

Fig. 4.73. Model transformation process


Go to the logical database model

Formed at the analytical and conceptual levels, business elements that describe the information structures of objects, information about which it is necessary to process and store in the database, when organizing the logical level of the database representation, it is expedient to transfer it to the created empty logical database model for subsequent normalization.

Considering the process of transformation of information structures to a logical level, it is easy to see that the tools used differ substantially in the organization and presentation of data structures. This imposes certain restrictions on the possibilities of direct integration of products, and in the case of products from different manufacturers, the issues of integration (collaboration) of products often become unsolvable. Therefore, for the transition between levels, a method is applied, which de-facto became the standard for the transfer of structured data. This method consists in using the XML format, on the basis of which files containing the necessary information are represented.

As a result, understanding the complexities of direct product integration, the developers of tools, for compatibility purposes, provide the ability to export and import models presented in the appropriate formats. If the tools for modeling business processes and database models are tools of one manufacturer and only interaction between them is provided, an integration mechanism for transferring data structures is organized between products.

For example, the BPWin Process Modeler CA tool enables the developer to generate complete data structures, including their attributive composition, directly in the tool, when building data flow models (DFDs). Direct integration with the ERWin Data Modeler allows you to create, without performing entity generation procedures, in the database model. The developer only needs to ensure the establishment of links between entities and their normalization. The problem with this approach is the need to work with already generated complete data structures, which often causes difficulties in the correctness of the application of normalization rules, because during the modeling of business processes and data flows, developers describe documents or object structures, information about which should be stored in the database, not having the opportunity to build a model of a database with links and determine the correctness and completeness of the selected structures.

Given such complexities, the most correct method is that data structures will be created which, although presented at the level of business modeling by attributes, nevertheless, the database models are transformed by independent types of entities, which makes it possible to implement the documentary approach procedure to database modeling, using the rules of technical and logical normalization. This method implies that any business element is described by structural elements with undefined attributes or without attributes.

Previously, using the IBM WebSphere Business Modeler tool, the business process of selling an item in an e-store was described, where on the flows between business functions and auxiliary functions, some business elements were defined in the form of certain data structures, assuming their further conversion to the essence of the logical model of the database. Given this feature, the developer in the description of business processes builds the structure of business elements in such a way as to be able to apply the rules of normalization. If you apply a documented approach to database modeling, the developer at the level of the business process description will describe the attributive composition of each business element as detailed as possible

and its structural components (nested business elements). When the developer plans to use the object approach, the attribute composition of the business elements is not based on the reflection of the characteristic attributes of each business element or object, but on the indication of the structural objects that characterize each business element, which leads to the creation of entity-objects, the attribute composition of which is determined at the level of logical database modeling.

The procedure for transforming business elements into a logical database model involves several steps:

• implementation of the export of the business process model for application in the database modeling tools with the rules for the representation of attributive elements in the created entities;

• implementation of importing the unloaded model of data structures into the database modeling tool;

• Determine the attributive composition of the generated entities, establish relationships between them, and conduct the normalization of entities and relationships until a complete database model is obtained.

The transformation of business elements into the structure of the database model begins with the choice of the unloading method (Figure 4.74). For this, the developer, based on IBM WebSphere Business Modeler, selects the item "Export ..." in the context menu of the business process project. and the uploaded data consumer. "InfoSphere Data Architect ... If the data structures are uploaded for further use in the IBM InfoSphere Data Architect tool, the appropriate download format selection option is selected. In the case of using third-party tools, you can use the "Delimited text (.csv, .txt)" download format, which generates a generic representation for use in various software tools, including Microsoft Excel.

Fig. 4.74. Selecting the consumer of the uploaded data structures


The next step is to specify the punk on a magnetic medium (hard disk), where you need to save the uploaded data (Figure 4.75). If you select the InfoSphere Data Architect option, the export procedure will create XML schemas for the L document with the extension .xsd.

Fig. 4.75. Selecting the save destination


As a result of the export, a file of the appropriate format will be created to use the database modeling tool (Figure 4.76). Depending on the selected data format, the required extension will be used. The further procedure of transformation, according to the sequence, is to open and reproduce the uploaded data in the database modeling tool.

Fig. 4.76. Business elements export result


By going to the IBM InfoSphere Data Architect tool in the created data modeling project and using the "Import ... context menu of the project, start the recovery procedure from the unloaded database model file. Because the information was unloaded from a tool not intended for data modeling, the entity representation will be implemented based on the attributes specified in the business elements. In the first dialog of importing data structures, the developer needs to select the type of the Model Model Wizard (Figure 4.77).

After defining the wizard view, the tool asks for information about the data file and the location of the import result. Among these characteristics it is suggested to indicate:

• Model format-specifies the data source type for importing the model, where, when using the exported model from another specialized data structures modeling tool, the ego tool is indicated, or if the desired tool is not available and the format of the uploaded file corresponds to one of the options offered for selection;

• Model - specifies the file where the uploaded data structure information is stored;

• Target project - specifies the project in the workspace of the tool in which you want to create a data model using the file specified above;

• Model type-Indicates the version of the database model being created (logical or physical), but by default, the tool suggests using the Auto detect of the model being created;

• File name - specifies the name of the model file that will acquire the extension corresponding to the type of the model.

Fig. 4.77. Selecting the Modeling Wizard


Taking into account the specified properties, the tool will create the necessary database model file, where information about data structures will be taken from the specified exported (uploaded) file.

The following set of properties indicates additional characteristics of importing the database model (Figure 4.78), defining each attribute as an independent entity (entity) in the database model with which it is necessary to normalize.

In doing so, the developer is offered not only to specify additional transformation properties, but also to determine whether to check the database model being created and, if a physical model of the database is created, select the database management system for which the database model will be created (Figure 4.79) . In this case, they will use the special conditions for presenting the database model, taking into account the peculiarities of its implementation in the DBMS.

Fig. 4.78. Setting the main import parameters


Fig. 4.79. Setting additional import options



However, if all structural data elements are defined in the business process modeling tool, taking into account the object approach, and normalization should be carried out at the level of objects associated with objects, the transformation process of the model can be implemented using another technology using a physical database schema file that can be loaded into the database modeling project.

The principle of "loading" file is identical to the import variant of the model, which assumes the selection of the item "Import ... context menu of the project, but as the type of wizard choose the option "File System"; (File system), and then, taking the export file from the business modeling environment and the file retrieval project, create an XML data schema with all attributive and essential elements, as they were presented in the modeling of business processes (Figure 4.80).

Fig. 4.80. Example of an XML schema imported into the modeling environment


A further transition to the database model is based on defining the rules for transforming the XML schema into a database model (see Figure 4.81), which requires creating a transformation rule via the "New/Transformation Configuration" item; (New/Configuration of transformation) of the context menu of the project section "Data Models". (Data Models).

To ensure the transformation, the developer needs to specify the transformation type "XML Schema to Logical Data Model"; and a design assignment for implementing the model. In order for the tool to know about the source of information on the information structure of objects and documents, it is necessary to specify the XSD file loaded into the project, rather than the project itself (figure 4.82).

As part of the last specification of the transformation parameters from the developer, you need to determine the actions relative to the key attributes (Figure 4.83):

• Generate surrogate key-property specifies the need to generate a primary key for structural elements, in order to subsequently form the concatenated primary keys on related entities.


• Merge entities as attributes, where appropriate - the property defines the ability to represent the created entities as attributes of other entities in the case where the business element is defined by the attribute of another business element.

• Overwrite files without warning - the property makes it necessary to ask the developer to overwrite the database model file if it already exists.

• Prefix foreign key attribute name with inverse verb phrase - Use the prefix of the foreign key with a semantic phrase - the property indicates the need to display the semantic content on the generated foreign key in the model.

Fig. 4.81. Selecting the basic transformation settings


Fig. 4.82. Specifying the schema source and the model recipient


As a result of these steps, a configuration will be created for the transformation of the export of data structures in the form of an XML schema (Figure 4.84), which can be run for execution and obtain a database model corresponding to the characteristics specified in the file.

Fig. 4.83. Defining parameters for the created attributes


Fig. 4.84. Created transformation configuration


In order for the transformation to be started, you must use the Run (Run) in the open configuration window (Figure 4.85). Running the customized transformation algorithm will result in the appearance of a database model with a set of entities and connections between them.

Fig. 4.85. The result of transforming an XML-schema into a logical database model


As a result of the transformation of the XML-schema exported from the business process model, entities are obtained according to the names of the business elements (Figure 4.86). It is important to note that the use of national alphabets when naming attributes and business elements leads to the fact that in the database model, the existing spaces between words are deleted and the names become merged (without spaces). When using

Fig. 4.86. Database model after transformation


The Latin script does not have a problem with spaces. However, even with the use of national alphabets, you can avoid this problem by defining the transformation rules by creating a special Glossary Model that contains the macro rules used for model transformation and link normalization.

With the seemingly useful possibility of transforming the model, there are a number of significant drawbacks to using this technology: the primary keys of the surrogate property are created in each entity, regardless of the existence as primary keys of attributes formed on the basis of identifying links;

- the links between entities are defined by the one-to-one (1: 1) type and the power on both sides of the links "0,1", which requires a subsequent revision of all existing links;

the semantic phrases describing the essence of the connections between entities are determined by nouns that characterize the relation of the child entity to the parent, which is incorrect in essence the wording that must be represented by the verbal form;

- if business elements that are not related to other business elements remain in the process of modeling business processes, they will also be represented by separate entities in the model;

- the dimensions of attributes by data types, where you need to specify the number of characters (usually character and text attributes), is specified in the maximum dimension.

Such lacks of transformation require the developer to further analyze the database model, review the established relationships between entities, determine the need for concatenated primary keys and surrogate primary keys, and normalize the resulting database model.

thematic pictures

Also We Can Offer!

Other services that we offer

If you don’t see the necessary subject, paper type, or topic in our list of available services and examples, don’t worry! We have a number of other academic disciplines to suit the needs of anyone who visits this website looking for help.

How to ...

We made your life easier with putting together a big number of articles and guidelines on how to plan and write different types of assignments (Essay, Research Paper, Dissertation etc)