Моделирование бизнес-процессов / Моделирование бизнес-процессов / ERwin_Insider_2

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 Compiled by Ben Ettlinger

Volume 1 Number 2

September 2000

Editor's Note

Considering our shoestring budget, and limited resources, the publication of the first issue of The Erwin & Bpwin Insider was a great success. The issue enjoyed wide circulation among Erwin users and was sent electronically around the World. The President of the Japan Erwin Users Group, our good friend Satoshi Matsumoto has orchestrated the translation of the entire issue into Japanese, hence making the Insider available to thousands of users in Japan. Exact circulation numbers are difficult to estimate in the world of electronic distribution, as the first issue as been forwarded many times over, via e-mail.

Although this is only the second issue we hope it will be the last….at least the last issue that deals with Erwin 3.5.2 as the current version. As we go to hard copy and electronic print the beta Erwin 4.0 beta program should be in full swing. I sincerely hope that the next issue will present, among other things, an introduction to 4.0 and a whole load of tips and tricks for the new 4.0 features. In order to do it, we really need help from you, the Erwin user. Sharing your expertise in the Insider will benefit all Erwin users, including yourself.

Based on the success of the first issue, and the feedback we received from users and CA, we felt we could widen The Erwin Insiders scope a little bit. In addition to the popular Tips and Tricks, and modeling issues, in this issue you will find two articles that go beyond just a discussion of Erwin 3.5.2. In "Are You Ready for OR" we take a look at the object relational scene, where indications are pointing the market is headed and which direction we think Erwin should go for version 4.

The final article lets off a bit of steam at software vendors for the apparent lack of respect for logical data modeling.

Ben Ettlinger

Editor

Data Administrator

New York Power Authority

President, NYEMUG

New York Enterprise Modeling User Group

ben.ettlinger@nypa.gov

Domains

Seen on the Erwin WebBoard by Whit Owens, CA

One of the things I am seeing a lot of is a misuse of domains. ERwin Domains should be built as 'generic attributes/columns. If your organization uses Class Words then these are very good candidates for domains. Ideally, a domain should support several occurrences of the attribute. Name, Last name, First Name, Address, Area Code, Start Date...are all good possibilities. Depending on your naming standards, creative use of ERwin Macros in the 'name inherited by attribute' line of the domain editor can be very useful, a Macro of <%Lower(%OwnerEntity %AttDomain)> would create a lower case attribute using the entity name plus the domain name. Any property given an attribute or column can be given to a domain and these domains can now be dragged from the Independent Attribute Browser to an entity to create attributes with all the properties given the domain. It now becomes easier to use the standard than to create something from scratch.

Error Messages

Seen on the Erwin WebBoard by Linda Jeney

Invalid object name 'pbcattbl'

This error occurs because of a default setting. "From the Client menu, select Target Client and then Select 'None.' You currently have it set to PowerBuilder (the default, don't ask me why - OK, it's because PB is the first in a set of radio buttons, but that is a really stupid reason) and although this doesn't cause problems when forward engineering, it does cause problems when generating as the export phase of a complete compare."

Mass Import of Definitions

Submitted by Karen Lopez, List Mistress for the Erwin Web Board www.infoadvisors.com

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 script generated from the model, 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.';

- 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 modeler meant when he created that attribute. 1

Mass Changes to Attribute Names

Submitted by Karen Lopez, List Mistress for the Erwin Web Board www.infoadvisors.com

-Export the ERwin model to an ERX file.

-Open the ERX file in Wordpad

-Find the section on Domain Properties

-Cut out and paste this section into its own Wordpad file. Save this as Attributes.txt

-Open Attributes.txt in Excel, which will ask you some questions about format. Choose comma delimited.

-In Excel, Create a new column in this worksheet.

-Populate the column with a function that changes the attribute name for all the rows that have CD_ANM as the property type. Use the SUBSTITUTE function to substitute a space for an underscore. Simply copy the rows that have a different property type.

-Copy that column

-Paste Special it (values) where the name column is

-Save the worksheet as a text file.

-Open the text file in Wordpad

-copy the text

-replace the old section in the _original_ ERX file with the new text.

Entity Names

- Same as above, except you can change all the names in the Entity section.

When you have replaced the two sections, you can import the new ERX file into ERwin

1 Editor's Note : CA Tech Support has advised as follows: "CA Tech has an Excel sheet that contains the instructions and the macro preset to convert the Table/Column Name/Comments in the correct format which can be imported into ERwin.

Note: Since, not all databases support Comments, so that field/option may not be available for all databases. One can change the Target Server to Oracle (which does support Comments) but make sure that while changing the target server when it prompts for data conversion. check "NO"!!! Changing the target server to and from can potentially harm the internal data mapping and can corrupt the diagram." We will attempt to procure that document and include it in our next edition.