Suggestions for using powerdesigner

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 of comment statements of data tables.
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 into a powerdesigner model and the comment statement of the data table is updated, the carriage return symbol can be avoided, which works 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.
actual method used:
convert the Erwin model to the powerdesigner model, save it as the erx type in Erwin, and then import the model in powerdesigner ), save the file as a PDM type (XML format), delete the view, domains, business rule, reference, and other information in the model, and leave only the information of the relevant data table, then, modify the extension of the model file to XML, and use xmlspy to generate the DTD file of this file, java is used to compile a Program Based on sax to parse the XML file and extract the comment statements of each data table and field, then, update the comment statement of the data table and field in the database.

1.9.erwin upgrade to powerdesigner
1.9.1 domain upgrade
when erwin3.52 is upgraded to powerdesigner9.5, the association between domain information and data tables is lost, you need to manually re-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 must set the reference relationship (Extended dependencies) of the data table to the domain ).
Upgrade of 1.9.2 business rule
Upgrade from erwin3.52 to powerdesigner9.5. The expression (SCRIPT) of business rule needs to be modified, modify @ column in all
business rule expressions to % column %
the specific implementation method can be directly modified in powerdesigner9.5; or save the model as XML (the file class is. you can use tools such as ultraedit or xmlspy to modify the settings. Of course, note that
only the content in can be modified. Otherwise, the content should not be modified.
like the domain, when upgrading from erwin3.52 to powerdesigner9.5, the association between business information and data tables is also lost. If the business rule is not too many, we recommend that you manually modify the model file.

1.9.3.sequence upgrade
. Sequence upgrade is recommended by programming and maintenance in the domain mode.
1.9.4. physical graph upgrade
from erwin3.52 to powerdesigner9.5, physical graphs can also be imported into powerdesigner9.5. However, the upgrade 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. If any of my peers encountered similar problems
.
2. Change management of data structures in powerdesigner
currently, some data structures in the demolition project are out of control. The following suggestions are provided on the basis of the concept of the powerdesigner package.
2. 1. data structure is maintained by business module
all 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 Structure is managed by category based on its lifecycle.
Create the following packages under the packages of each business module:
2.2.1 temporary Test Data Structure:
it is the data structure used for testing the current business module, can be deleted at any time
2.2.2 Data Structure in 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 was previously used normally by the business and is no longer in use, but data migration has not yet been performed
the data in the expired data table does not have a completely voided data structure. If you want to invalidate these data structures,
you must first perform data migration and other related processing.
2.2.6 void Data Structure:
the data migration has been completed for business data tables that are no longer used by the database, but the data tables have not been deleted,
related documents are not updated.