Suggestions for using powerdesigner (full version ZZ)

Suggestions for using powerdesigner (Full Version)

1. Suggestions for using powerdesigner
1.1 Use of business rules)
For business logic that may appear in multiple data tables, it is recommended to encapsulate it into business rule, which facilitates re-use of business logic and maintenance of business logic.
To facilitate maintenance of business logic, you can consider combining business rule and domains. Apply the business rule to domains, and then the domains to the fields of the data table.
For example, in a demolition project, the demolition business section, the management parameter business section, the Housing Business Section, and the data table in the demolition Contract Section contain the floor field. Therefore, a business rule is created first, then define a domain so that the corresponding data table fields can use this domain.
1. 2. Use of the Custom Data Type (domains)
Oralce provides some built-in data types, but you can also define custom data types based on business needs.
Wrap business logic in custom data types.
As for the housing floor above, we can define an independent data type (domain) for maintenance, and then in the relevant data table
Use this custom data type on the field.
Generally, you can define your own data types in Oracle, and then add standard check or business rules.
For example, in a demolition project, the area Category field appears in many data tables and can be maintained as a separate data type, define an "area category" domains (including: 0 --- area of the Department room, 1 --- area of use, 2 --- area of the unit, 3 --- area of the total construction, 4 --- area of the shared area ). In addition, because of the Association function provided by powerdesigner, when the business logic changes, you can quickly find out which objects are affected.
1.3 Use of serial number (sequence)
In the powersigner model, a bunch of sequence are defined. Next, we need to associate them with the relevant fields of the data table, especially those used for multiple data table fields.
A data table allows only one field to use sequence. Before using sequence for a data table field, add the sequence to extended dependencies of the data table.
If a data table has two or more fields that use sequence, a prompt is displayed during model check.
Generally, the rules can only be applied to the primary key fields of the data table.
It is recommended that the primary key field be composed of a data table + "ID" or "number.
For example, for the "housing consolidation area" data table, its primary key field = Housing consolidation area number, and the corresponding sequence is
SEQ _ housing consolidation area. This sequence may also be used for other data tables. You also need to set the reference relationship before using it.
(Set the reference relationship on extended dependencies of the data table)
1.4 Use of Oracle package
Some procedure can be set in the Oracle package, but what are the database objects referenced in the Oracle package? We recommend that you manually maintain this information. In particular, we recommend that you maintain the data tables, views, and Oracle packag used by the Oracle package.
Use of 1.5 packages
The package of powerdesigner is equivalent to a folder. You can use it as a container to maintain business logic. We recommend that you create a powerdesigner package based on the business module. If the module needs to be subdivided, you can create a powerdesigner sub-package.
We recommend that you save the model object shortcut in the container. We recommend that you do not place the original information in the container. This information may not be maintained when the powerdesigner model is merged or reverse engineering is put into the container.
In the powerdesigner package, physicaldi.pdf is recommended. We recommend that you organize the objects in physicaldi.pdf according to a topic or business perspective like the subject area of Erwin, so that each physicaldi.pdf has clear functions.

. Use of views
A view is created on a data table or view (or a stored procedure may be referenced ). Generally, reference information of the data source of the view should be maintained in the view model.
In our current project, the database model does not maintain the view. Therefore, you need to create the powerdesigner
Model.
In the powerdesigner9.5 environment, I cannot obtain the View Script through reverse engineering.
If you set the parameters, you still cannot obtain the script.
You can use the following two methods to obtain the View Script.
Method 1: Use the reverse engineering of powerdesigner8.0 to obtain the View Script.
The graph model is merged to maintain the view.
Method 2: Use Erwin reverse engineering to obtain the Erwin model of the view, and save the model as an erx file.
Import the file in powerdesigner9.5 and then merge the model.
Powerdesigner's view model has poor processing capabilities and cannot maintain the view dependency (that is, establishing the view dependency on the data source), which is obviously inferior to Erwin.

1. 7. Use of synonyms (Synonym)
A synonym is equivalent to an alias for a database object, providing the independence of location and data. When cross-database users access objects, you can consider creating synonyms and assigning permissions to simplify access to database objects.

. Use of data tables
Update the comment statement of the data table.
Business Background:
In our project, the Comment statement of the data table in the Erwin model is not synchronized to the Oracle database. Now we need to modify the comment statement of the data table in the database.
Possible implementation methods:
Method 1: Erwin directly goes to the project, but the update fails because the comment statement contains the carriage return symbol.
Method 2: If the Erwin model is converted to the powerdesigner model and the comment statement of the data table is updated, the carriage return symbol can be avoided and can work normally, however, because the logic models in the Erwin model are inconsistent with those in the physical model and even the order in which they appear are inconsistent, the powerdesigner model is incorrect, and the generated script for modifying the database is incorrect.
The actual method is as follows:
Convert the Erwin model to the powerdesigner model and save it as the erx type in Erwin. then import the model in powerdesigner. Save the file as the PDM type (in XML format) and delete the view in the model, domains, business rule, reference and other information, only the information of the relevant data table itself is left, then the suffix of the model file is modified to XML, and xmlspy is used to generate the DTD file of this file, then, a sax-based program was written in Java to parse the XML file, extract the comment statements of each data table and field, and then update the comment statements of the data table and field in the database, in this way, you can.

1.9.questions about upgrading Erwin to powerdesigner
1.9.1 domain upgrade
When upgrading from erwin3.52 to powerdesigner9.5, the relationship between the domain information and the data table will be lost. You need to manually add the relationship between the two. Of course, you can program to modify the model file of powerdesigner and add the associations between the two. Generally, the powerdesigner model file is large. As long as there are dozens of data tables, it must be 1 MB in the model file. We recommend that you add information using the sax method.
Note: When adding the domain used by the data table field, you need to set the reference relationship (Extended dependencies) of the data table to the domain ).
1.9.2 upgrade of business rule
From erwin3.52 to powerdesigner9.5, the Business Rule expression (SCRIPT) needs to be modified
Change @ column in the expression of business rule to % column %
The specific implementation method can be directly modified in powerdesigner9.5; or the model can be saved in XML format (the file class is. you can use tools such as ultraedit or xmlspy to modify the settings. Of course note
You can only modify the content in <C: businessrules> </C: businessrules>. Otherwise, the content cannot be modified.
Like domain, when upgrading from erwin3.52 to powerdesigner9.5, the association between business information and data tables will also be lost. If the business rule is not too many, we recommend that you manually modify the model file.

1.9.3.sequence upgrade
The. Sequence upgrade is recommended to implement programming and maintenance in the domain mode.
1.9.4. Physical graph upgrade
From erwin3.52 to powerdesigner9.5, the physical graph can also be added to powerdesigner9.5. However, the update function of powerdesigner9.5 has some problems: the data table information in the generated physical graph has some problems: fields in the data table in the physical graph are not completely displayed, and the type of fields in the data table cannot be fully displayed in many cases. I use Java to parse the upgraded model file in the way of sax, and then regenerate the location information of the data table in the physical graph (two coordinates of the data table: coordinates in the upper left corner and coordinates in the lower right corner ); in addition, you can generate your own powerdesigner9.5 package based on business needs and create a physical graph to add data tables to the physical graph.

1.9.5. Other Instructions
From erwin3.52 to powerdesigner9.5, I wrote some Java programs to solve related problems.
You can talk about it.
2. Change management of data structures in powerdesigner
At present, the data structure in the demolition project is out of control. The following suggestions are provided on the basis of the concept of the powerdesigner package.
2. 1. Maintain the data structure according to the business module
All the data structures in the model are in one file, and each business module in the top-level folder maintains a shortcut to the data structure.
2. Data structures are managed by category based on their lifecycles.
Create the following package under the packages of each business module:
2.2.1 temporary Test Data Structure:
Is the data structure used for testing the current business module and can be deleted at any time.
2.2.2 data structure in the discussion:
The data structure is under discussion and has not been determined yet.
2.2.3 Data structure to be updated:
The data structure has been determined, but has not been updated to the database.
2.2.4 formal data structure:
Data Structure normally used by businesses in the database
2.2.5 void data structure:
The database has been used normally by the business before and is no longer in use yet.
Data Migration in the obsolete data table does not have a completely voided data structure. If you want to invalidate the data structure,
Data migration and other related processing are required.
2.2.6 void data structure:
Business data tables that are no longer used by the database have been migrated, but the data tables have not been deleted,
Related documents are not updated.