IBM InfoSphere Data Architect
The IBM manufacturer's tools are one of the most fully developed to maintain the life cycle of developing an information system, and databases are no exception. As part of the process of developing an information system, a tool for modeling and interacting with the DBMS - IBM InfoSphere Data Architect - is implemented for databases in the IBM product line. Having passed a long way of becoming, this product has become one of the most powerful tools for working with databases, providing:
• building a logical model of the database;
• building a physical model of the database iod a large number of databases known on the market;
• Integration with the DBMS to manage data processing;
• transformation of the model into a physical database;
• Code generation in SQL database structure for transfer to DBMS.
However, unlike ERWin, IBM InfoSphere Data Architect does not provide a mechanism for constructing reports on database models, but it is due to the ego development policy of the toolkit in IBM, which considers the use of the product only for solving the necessary functional tasks. Therefore, the documentation tools, taking into account their use for various tools of information system development, are allocated to separate tools and are add-ins to the means of building information systems. Thus, if there is a need to build standardized reports on database models, then you need to use a separate software solution.
The IBM InfoSphere Data Architect tool, like many other IBM products, is implemented on the basis of the Eclipse software platform and the Java language, which allows them to be integrated into a single development space, providing a fast transition from one tool to another, and import/export mechanisms provide detailed possibilities for transforming models for use in environments other than the development environment, implementing an integrated approach to the process of developing an information system. Along with this, IBM tools allow you to develop models only for certain stages of the life cycle of developing an information system, for example, for modeling and building a database, which will be discussed in this section.
At the beginning of working with the tool, the developer needs to define the workspace on the hard disk of the computer (Figure 3.37), where all the information about the development projects will be saved, for which the tool creates a repository. The location of the repository can be any and is not limited to the location determined when the tool is installed by default. Using the Browse ... button (view), the developer can choose any place on his available hard disks, including portable magnetic media, taking into account that the repository is constantly updated with new information and the place where the workspace of models will be located must have a write permission, as well as the ability to delete and overwrite files.
Fig. 337. Defining a workspace for modeling
As a result of the selection of the workspace, a number of utility files will be created in the corresponding place of the disk, which will contain information about the developer projects being implemented (Figure 3.38).
Fig. 3.38. Location of the repository in the operating system file structure
No projects have been created in the presented example, so there are no additional files in the repository, but as the projects are created and developed, the file structure will be supplemented with additional files containing individual components of the created models and projects.
As with many IBM products, the "First Steps" area is implemented for Data Architect. developer, offering access to a variety of reference and training tools for working with the relevant tool, including product information, information about the modeling process, various web resources with practical materials for developing a database model and links to professional forums, examples and training materials on separate mechanisms of the tool.
When you enter the tool, the developer opens a workspace that gives you access to specific mechanisms for working with the database project (Figure 3.39), represented by the following areas:
• Data Project Explorer is an area where the developer can switch between the elements of the database model and create the necessary model elements;
• Data Source Explorer - the area used to organize connections to physical databases for physical modeling and implementation of program logic;
• Outline (area) - an area that illustrates the structure of database model objects for a quick transition between them;
• Properties - the location area of the components that describe the properties of the model object being edited.
In the central part of the workspace, an area is displayed where model description areas and work areas are displayed for graphically displaying diagrams of generated models. It is with this area that the developer, as a rule, interacts using dialog boxes or a tool palette.
The first step of the developer is to create a simulation project, within which many necessary models and diagrams will be presented. Usually, no more than one database model is implemented in one project, but if the information system is divided into several databases, several models related to the allocated databases can be implemented in the project. As a rule, databases do not interact with each other, which makes it necessary to build several models in one project. Create the project of the logical model of the database (Figure 3.40), using the menu item "File/New/Data Design Project"; (File/New/Data Model Project) begins with the definition of the project name and its physical and logical location.
Fig. 339. General view of the developer workspace
The physical location of the default database model is determined in the workspace specified for the project, but the developer can determine another way of placing the project and then the project repository will be placed elsewhere, and a reference to the project location will be indicated in the tool repository. Also, the developer can determine the logical location of the project in already created other projects by defining a working set of model tools, which will lead to the addition of the project to another project. This is done so that you can use identical elements of database models in different projects without their redesigning.
Fig. 3.40. Definition of project parameters
As a result, a project tree will be created (see Figure 3.41), which provides the developer with the ability to build various components, among which are:
- Data Diagrams - includes a set of diagrams implemented for all database models;
Data Models - includes a set of models implemented in the project, which also includes a variety of diagrams and objects related to the model being created;
SQL Scripts (SQL programs) - Includes many software modules in the SQL language required for implementation in the database.
Fig. 3.41. Initial Project Tree
Using the project tree to access the elements of the database model allows the developer to quickly switch between models, diagrams and their components, opening the corresponding areas of description, modeling, and fixing properties. When working with the model level, the developer is given the opportunity to describe the model with basic characteristics. If the chart is activated, it is possible to visualize the database model using graphical elements. The selection of individual model components (entities, links, keys, etc.) takes the developer to the properties area to fix the characteristic features of the corresponding element.