Моделирование бизнес-процессов / Моделирование бизнес-процессов / ERwin_Insider
.pdf
The Erwin Insider™
& BPwin Insider™
Tips, Tricks and Articles
of Interest to
ERwin & BPwin
Users
Contributions by ERwin & BPwin Users from Around the World
Edited and Complied by Ben Ettlinger
Contributors
Ben Ettlinger |
Data Administrator |
|
New York Power Authority, White Plains, NY |
|
President |
|
New York Enterprise Modeling User Group |
Gary Gramm |
Consultant, DataSmart Business Solutions Inc. |
|
Vancouver, BC Canada |
Karen Lopez |
ListMistress, ERwin Users Discussion Group |
|
InfoAdvisors, Inc. |
|
www.infoadvisors.com |
|
Toronto, Ontario Canada |
Lucie S. Johnson |
Consulting System Engineer |
|
Bank of America, San Francisco |
Doug Stone |
Information Modeler |
|
NUSCO (NU Service Co.) Berlin, CT. |
Table of Contents |
|
CONTRIBUTORS......................................................................................................................................................................... |
2 |
PREFACE........................................................................................................................................................................................ |
6 |
HOW TO ABBREVIATE ATTRIBUTE BUSINESS NAMES TO COLUMN NAMES IN ERWIN MODELS |
|
........................................................................................................................................................................................................... |
10 |
Overview................................................................................................................................................................................. |
11 |
Sample %Lookup Macro Setup .......................................................................................................................................... |
12 |
Special Considerations........................................................................................................................................................ |
14 |
ERWIN KEY BOARD SHORT CUTS .................................................................................................................................. |
16 |
MODEL MART KEY BOARD SHORT CUTS .................................................................................................................. |
17 |
IDEF1X VS UML – A COMPARATIVE ANALYS IS ......................................................................................................... |
19 |
WHY COMPARE? ........................................................................................................................................................................ |
19 |
WHY ERWIN AND PARADIGM PLUS? ...................................................................................................................................... |
19 |
ER DIAGRAM VS CLASS DIAGRAM........................................................................................................................................ |
20 |
ENTITY VS CLASS...................................................................................................................................................................... |
21 |
RELATIONSHIPS VS A SSOCIATIONS........................................................................................................................................ |
21 |
KEYS VS OIDS............................................................................................................................................................................ |
22 |
CARDINALITY VS MULTIPLICITY............................................................................................................................................ |
22 |
IDEF1X Cardinality............................................................................................................................................................. |
23 |
UML Multiplicity .................................................................................................................................................................. |
24 |
Ranges in IDEF1X ................................................................................................................................................................ |
25 |
RELATIONSHIPS VS A SSOCIATIONS........................................................................................................................................ |
25 |
One to One VS Many to Many ............................................................................................................................................ |
26 |
One to One Relationship...................................................................................................................................................... |
26 |
Simple Relationships............................................................................................................................................................ |
27 |
Succinct Relationships......................................................................................................................................................... |
29 |
Many to Many Relationships.............................................................................................................................................. |
30 |
Complex Relationships......................................................................................................................................................... |
31 |
Diamonds vs Nulls ................................................................................................................................................................ |
32 |
Data Types ............................................................................................................................................................................. |
34 |
N ary Relationships.............................................................................................................................................................. |
36 |
Verb Phrases.......................................................................................................................................................................... |
38 |
ATTRIBUTES................................................................................................................................................................................ |
38 |
1st Normal Form VS Attribute Multiplicity....................................................................................................................... |
38 |
CONSTRAINTS............................................................................................................................................................................. |
39 |
Contingent Constraints........................................................................................................................................................ |
39 |
Figure 36 .............................................................................................................................................................................. |
40 |
Or Constraint......................................................................................................................................................................... |
40 |
Categories VS Subtypes...................................................................................................................................................... |
41 |
Inheritance ............................................................................................................................................................................. |
43 |
Multiple and Complex Generalizations............................................................................................................................ |
45 |
For a further discussion on the specifics of this generalization, refer to The UML Reference Manual. .............. |
47 |
Aggregation ........................................................................................................................................................................... |
47 |
Composition........................................................................................................................................................................... |
49 |
Dependency............................................................................................................................................................................ |
50 |
RECURSIVE RELATIONSHIPS..................................................................................................................................................... |
51 |
METHODS.................................................................................................................................................................................... |
52 |
IDEF1X VS IDEF4X VS DMT2............................................................................................................................................ |
52 |
MOVING ATTRIBUTES TO DIFFERENT ENTITIES ON REVERSE ENGINEERING .................................. |
54 |
BPWIN IDEF EXTERNAL AGENTS ................................................................................................................................... |
55 |
MACROS GREATER THAN 130 CHARACTERS .......................................................................................................... |
56 |
HEADERS & FOOTERS .......................................................................................................................................................... |
57 |
USING SUBJECT AREAS FOR LOGICAL & PHYSICAL DISPLAYS ................................................................... |
58 |
© 2000 New York Enterprise Modeling User Group
c/o Ben Ettlinger 10 Overlook Terrace
New York, NY 10033-2268
Preface
Over the last few years Erwin has established it self as the World's leading data modeling tool. Its ease of use and functionality has given data base administrators, data administrators and data modelers a powerful tool to effectively perform their tasks in building and maintaining relational databases of almost every size platform and description.
Along with every tool, comes it's prescribed standard methods of use and methodologies. In a way, licensing software is really no different than owning a car. The auto manufacturer supplies you with a drivers manual, but the real neat and nifty efficiencies and tricks you learn from your mechanic, auto club magazines and networking with other owners of the same vehicle. That is exactly the purpose of this publication. It should serve as an open, and frank exchange of ideas to help us, the data modelers and administrators do our job better.
Although Computer Associates personnel have been invited to participate in this publication, it is presented in the same manner as we run our Enterprise Modeling user groups. These groups are receive organizational support from CA but remain as independent unaffiliated entities. To put in our own IDEF1X jargon, the user groups, and this publication, have a "non identifying" relationship with CA. We've got our own identity.
I would be remiss in not acknowledging Stacy Jensen of Computer Associates, Princeton for her energized and enthusiastic support of our User Groups and their undertakings, including this publication.
In addition, kudos go to NYPA CIO Russell Krauss, and Director of Applications Peter Poggi for their encouragement and ardent support of my, participation in the activities of NYEMUG, penning articles, reviews and papers.
Ben Ettlinger
Data Administrator
New York Power Authority
President, NYEMUG
New York Enterprise Modeling User Group
Mass Import of Definitions
ListMistress, ERwin Users Discussion Group InfoAdvisors, Inc.
www.infoadvisors.com
Toronto, Ontario Canada
A little background, first. While many of the data model objects had definitions, a few entities and attributes did not. Rather than install a copy of ERwin on a business person's machine, train him, and have that model tied up for a few days, we decided to let them write draft definitions separately, then merge them in later.
- Generate a report of Entity Name, Entity Definition, Table Name, Attribute Names, Column Name, Attribute Definitions.
* IMPORTANT *
Include only owned attributes so that each attribute appears once (unless there are manually duplicated attributes, of course.) Also, you may want to ensure that all objects are not marked logical only.
-Export this report to a spreadsheet. I chose Excel, but any DDE capable of saving as an ascii file will work.
-Provide this spreadsheet to the person working on the definitions. Instruct him not to change any of the object names, no matter what problem he sees. Instruct them not to use any quotes, special characters, or apostrophes anywhere. This is difficult to do, I know, but as you know these can make it impossible to do an import.
-Review definitions and reach agreement on any issues. Use Search and replace to remove any quotes, apostrophes, or special characters.
-In the original model, generate and save a script for generating a database. Use only those options necessary to create the tables and columns.
-In the final spreadsheet file, insert a new column that will be used to construct an SQL statement for reverse engineering.
-Use a concatenation function to form part of an SQL statement. This should use the Table Name and Column name.
For instance, In Excel, the function looked something like this (for a UDB table)
CONCATENATE("COMMENT ON COLUMN ", B1, ".", C1, " IS '", D1, "';")
Where B1 is the column for Table Name, C1 is the column for Column Name and D1 is the column for the definition. Copy this formula down the new column in the spreadsheet. Copy this column to a new spreadsheet, converting the formula to hard values when asked.
- Export the new spreadsheet in ASCII format.
- Using the generated from the model script, manually cut and past the definitions for one table where it goes in the script file.
For instance, using the Movies.ER1 file that comes with ERwin, the CUSTOMER table would look like:
CREATE TABLE CUSTOMER ( customer_number INTEGER NOT NULL, customer_first_nam CHAR(15) NOT NULL, customer_last_name CHAR(15) NOT NULL,
customer_address_1 VARCHAR(180) NOT NULL, customer_address_2 VARCHAR(180), customer_city CHAR(18),
customer_state CHAR(2), customer_zip CHAR(10), customer_phone INTEGER, customer_credit_ca INTEGER, customer_credit_ca TIMESTAMP, customer_status_co CHAR(1)
);
COMMENT ON COLUMN CUSTOMER.customer_number IS 'An identifier for a customer assigned at the first time a person rents a video.';
CREATE TABLE EMPLOYEE ( employee_number INTEGER NOT NULL, store_number INTEGER NOT NULL, employee_first_nam INTEGER NOT NULL, employee_last_name CHAR(15) NOT NULL, employee_address_1 VARCHAR(20), employee_address_2 CHAR(20), employee_city VARCHAR(20), employee_state CHAR(2) NOT NULL, employee_zip INTEGER,
employee_phone INTEGER, employee_ssn INTEGER, hire_date TIMESTAMP, salary NUMERIC NOT NULL,
supervisor INTEGER NOT NULL );
... and so on.
-save the modified script file.
-Open *a copy of* the original model in the Main subject area, set the display to physical, then do a complete compare (if you want to compare each definition with the original one as I did) or just use Alter Database if you are going to automatically replace all definitions.
- If all goes well (meaning that you removed all special characters and nobody changed the column names, you will have a new ER1 file with updated definitions.
----
I could have automated this much more, but I only had about 100 definitions to deal with. I would have spent more time if I had more or believed I would be doing this more than one time.
Some Comments:
-Because this technique uses database functions to do the import, it will only work on those objects that are not marked Logical Only.
-If the model is in development, the best time to write definitions is when the objects are being created. As much as we all hate doing the definitions, it's much more painful to do
them afterwards, in batch.
-Good definitions are very important for others to understand the model. Don't assume that just because you have good names that the true meaning will be understood.
-When writing definitions, keep in mind that you are not writing a definition of the word used as the name of the object. You should be writing about the concept being modelled. For instance, there may be a definition of the word -customer- in the dictionary, but that may not be exactly what you mean by the entity your put in the model.
-Don't strictly use those grade 2 definition rules you learned in school. It is silly to read a definition of -Order Datethat goes something like:
"A named division of time that a request for goods was submitted by a being, natural or conceptual, to an organization."
when it will be less confusing and much better understood if you write
"The date that a product order was received at MyCompany, Inc."
Yes, it breaks those rules of using part of the defined term in the definition, but the second definition is much clearer on what the modeller meant when he created that attribute.
How to Abbreviate Attribute Business Names to Column Names In ERwin Models
Lucie S. Johnson
Bank of America, San Francisco
Bay Area Enterprise Modeling User Group
Preface
This document is intended for the use of the Data Management professional who uses Platinum ERwin/ERX to create and manage logical and physical data models.
It is intended as a quick reference on how to setup the proper parameters in ERwin/ERX to enable the tool to automatically convert the Logical Domain business names to the Physical Domain short column names.