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

3.Move this text block to the upper left hand corner of the diagram.

4.Add this text block to every subject area in which you want this information to appear. You need do this only once and when you create a new subject area.

Because you placed this in the upper left hand corner of the main diagram, it will appear there in each new subject area.

When you need to update that information you can update it in one place and the change will appear everywhere. I use this technique for version numbers and copyright notices.

Physical Role Names

Submitted by: Ann Peoples, Wachovia, Inc

Given the following situation: A table was created in the Physical view as "physicalonly". The table had many relationships to other tables, including multiple relationships to one table. (The table was a reference table containing many types of codes.) The primary key column (i.e., REF_ID) was migrated as a foreign key to other tables, keeping its same name and folding into one column on the table with multiple relationships. The foreign key columns needed to be renamed. However, on the physical side, there is no facility for assigning role names.

Solution: Remove "physical only" status from table and assign role names in the logical view. When the names are as desired, change the table status back to "physical only".

Resolving a Quirk in Relationship Names

Submitted by: Ann Peoples, Wachovia, Inc

Given the following situation: Domain (or Code) tables existed in the logical model as "logical-only". Foreign keys to these tables were renamed in the physical model to names such as STAT_REF_ID, DT_TYP_REF_ID, etc. A reference table was added as "physical-only". Initially, relationships between the reference table and other tables were not drawn. It was decided to draw the relationships in the physical view. The foreign keys in the logical

view were marked as "logical only" to avoid duplication. The process described in the above problem was followed, but the physical names were not allowed because ERwin thought they already existed. However, the names did not appear on reports and could not be viewed anywhere within ERwin.

Solution: Delete the affected relationships in the logical view and add them back.

Oracle 8i Connections / SQL*Net

Seen on the Erwin WebBoard

Problem: With Oracle 8.1.5 client software, installed the Erwin Server | Oracle Connection command was executed and Oracle Connection dialog is opened. The user/pw/connect string the Connect button was clicked...and NOTHING happened.

Resolution: Oracle 8i doesn't install SQL*Net at all, and Net8 which is required by 8i to connect, is not recognized by ERwin as an alternative. You must install and configure SQL*Net to connect from Erwin to Oracle 8i.

Editor's Note: CA Tech Support has advised that this issue has been resolved in Service Pack 3.

DB2 Index Defaults

Submitted by: Theo van Westrienen, Martinair Holland, theo.van.westrienen@nl.martinair.com

Problem: Is there anyway to set the defaults for a DB2 index?

Resolution: Default for physical DB2 properties can only be set in DB2 it self, not in ERwin.

Index type can be set within DB2: if you leave it blank in ERwin, DB2 will apply the default at generation time.

The USING block has standard defaults within DB2: Primary and secondary quantity will be 12 and 12 (in DB2 v5 for OS/390) when left blank in ERwin; there are more default values for the other keywords, you can find these in the DB2 reference manuals.

I also use the Index Name Macro in the Target Server Settings, but I do not understand what you mean with "UDP for a table". The Table Name Macro is not an UDP, you can find the UDPs for a table on a separate tab in the Table Editor.

The tablespace name can be entered in the Table Editor on the tab Physical Props. You can also enter the Database name here. To get there: right click a table (in the physical view), choose Table Editor, and choose Physical Properties.

I think UDPs don't make sense here, because it seems to me to be more work using UDPs (probably in combination with macro's) then the actual Physical Props editor.

In the Volumetric Editor is also a possibility to assign tablespace/database names to tables. In the storage corner (below, right) you can click on the button with the dots to enter the Physical Object editor. I do not use this option, because I tend to miss changes that I enter this way.

I have used ERwin for hundreds of tablespace DDL generations this way already over the past 18 months without any problems.

When you do not fill out the index type, using block you can get the values that DB2 applied by doing a Complete Compare (or an Update Model) with the proper options set. For tablespace and databases you can use the DBsync option in the Phys. Object editor.

User Defined Data Types in SQL SERVER

A question from the Erwin WebBoard

Q) When forward engineering to some data base platforms (e.g. SQL Server or Sybase) there are two options that work together: under schema, a check box called sp-addtype and under column, a check box called user data type. When these are checked, ERwin generates a bunch of stored procedures that 'catalog' all the user defined data types in the IAB to the SQL server database, then refers to columns associated to these data types as the data type name in the sql generated to be forward engineered to the database, instead of the actual physical characteristics (e.g. varchar(20) ). Why someone would want to do this?

A) When using Sybase with the spatial data option it is necessary to have spatial related data columns defined as point, polygon, line, etc in the ddl. The Sybase spatial server uses these "user-datatypes" as clues to create additional columns or tables to hold the appropriate spatial information.

Magnificent Macros

Migrate Umlauts from a Logical Model to a Physical Model

Contributed by:

Norbert Felderer, Data Administrator

Sparkassen Datendienst Gesellschaft m.b.H.

Vienna, Austria

If you want to use German umlauts in the logical model, you can generate them to the physical model with the following macros;

Entities -> Tables

This macro capitalizes the entity name, replaces German umlauts and cuts the logical name to 18 characters (max. for our database)

Place: Server.TargetServer.TableNameMacro

%Substr(%Substitute(%Substitute(%Substitute(%Upper(%EntityName()),Ä,AE),Ö,OE

),Ü,UE),1,18)

Attributes -> Columns

This macro capitalizes the attribute name, replaces German umlauts and cuts the logical name to 18 characters (max. for our database)

Place: Independent ColumnBrowser.DomainDictionaryEditor.NameInheritedByColumn in the <default> domain.

%Substr(%Substitute(%Substitute(%Substitute(%Upper(%EntityName()),Ä,AE),Ö,OE

),Ü,UE),1,18)

Please note: Other special characters like "ß" can be generated as well but we don't use them in our shop in the logical model.

Depending on your browser or language settings the umlauts might not come out right in the macros above but I hope you still get the general idea.

Macro for Domains

See the section on Domains in Tips and Tricks.

Modeling Issues

International Addresses

Adapted from the Data Modeling WebBoard by Eric Nielsen Consulting Information Architect

Most commonly addresses are logically modeled with attributes, in an ADDRESS entity or directly in, say, EMPLOYEE entity. These attributes are most frequently, State, City, Street, Address etc. However there are many locations in other countries where addresses cannot be expressed in that common format.

Here is a suggestion for a flexible model that can support international postal addressing (and other types of addresses), try starting from the following base

model...then work it to fit your unique needs.

Notation: Information Engineering.

Three entity types:

(1)ADDRESS (PK is Address Id as a minimum, but could be the compound of something like Customer Id plus Address Type (bill-to, ship-to, etc.), or something else.)

(2)ADDRESS LINE ( PK could be compound of PK of ADDRESS plus Sequence Number...attributes include Text and the foreign key of PK from ADDRESS LINE TYPE)

(3)ADDRESS LINE TYPE (PK of Address Line Type Id...entity type probably contains a Description attribute, maybe others)

Two relationships:

(1)Containing: a one-to-many from ADDRESS to ADDRESS LINE, mandatory on the ADDRESS end and optional on the ADDRESS LINE end.

(2)Defines: a one-to-many from ADDRESS LINE TYPE to ADDRESS LINE, optional on the ADDRESS LINE end and mandatory on the ADDRESS LINE TYPE end.

The domain of values for ADDRESS LINE TYPE could be: street, PO Box, City, State, Province, Region, Country, Attention, Department, Floor, Mailstop, etc.

This base model allows one to have as many address lines as needed per address, with those lines sequenced by the Sequence Number attribute.

One natural extension to this base model is defining country/postal authority-specific rules about which ADDRESS LINE TYPES appear in which sequence for each COUNTRY (COUNTRY being an additional entity type)...with the right model these can be captured as data values rather than using data structure.

How you tie in ADDRESS TYPES (bill-to, ship-to, email, IP, intra-company mailstop, etc) depends on how you manage addresses.

is object relational. If the platform is strictly relational, the methods or operations reside in the business logic level. UML is the generally accepted language for object development. At which ever of the above layers object development is being performed, one can employ the appropriate UML diagram. (UML is comprised of a set of diagrams e.g. use case diagram, activity diagram etc.) The diagram most appropriate for the database layer is the class diagram, UML's equivalent to the Entity relationship diagram.

What does this all mean for the Erwin user? What if you are designing an object oriented database? Do you use UML design it or do you use ERwin? …can you even use Erwin in the object relational environment?

Not every application may necessarily need the features introduced in OR. Most traditional financial applications may not require the new constructs. They do help a great deal in certain newer applications such as Geographical Information Systems (GIS) databases and applications that use multi-media.

The realization of object relational paradigm with connectivity to Oracle 8i, DB2 7.0, Sybase 12.0 and SQLServer 7.0, is unfortunately not going to be addressed in version 4.0. Indications are, however, that the version 4.5 release will address these database platforms and a whole plethora of new database versions. There is in fact, some optimism that it will appear shortly after the 4.0 release.

The bottom line is that 4.5 will have to address the new constructs, but how? How do you represent collections in the form of nested tables and variable arrays, operations or methods, distinct or user defined data types, row types, etc?

Neither the SQL3 standard3 under development by the ISO and ANSI, nor the IDEF1X standard, which does not appear to have been changed since 1993, deal with visual representations of the object relational constructs.

If IDEF1X in its current form cannot be used to properly model for an ORDBMS, then why not just forget about it and use the UML class diagram? You could. Be forewarned, however, UML is not simple to learn. UML is not the be all and end all for everything. Many experts question The UML validity for data modeling. "Dave Hay, an experienced modeler, author of Data Model PatternsConventions of Thought (Dorset House) and ardent fan of the Oracle ER notation, argues that "there is no such thing as 'objectoriented analysis'" [5], only object-oriented design, and that "UML is … not suitable for analyzing business requirements in cooperation with business people….I agree with Dave Hay that UML class diagrams are less than ideal for data modeling…. 4

Terry Halpin, originator of Object Role Modeling (ORM) and Technical Lead in Database Design for the Visio Division of the Microsoft Corporation states that "Entity Relationship modeling (ER) views the application domain in terms of entities that have attributes and participate in relationships…..This view of the world is quite intuitive, and in spite of the recent rise of UML for modeling object-oriented applications, ER is still the most popular data modeling approach for database applications.5

So why not advance an ER modeling language to model in the OR environment?

Ironically OR-Compass which was the old Logic Works' tool for modeling object relational databases was poised to be the product that was to meld the "O" and the "R". Version 1.01, which ended up being the only release, introduced three notation extensions to IDEF1X, the view, which has since been added to Erwin, table methods and type tables. OR-Compass which afforded only a physical model, eventually was supposed to incorporate all the new constructs. There was even talk at the time of eventually merging it with Erwin.

3See Oracle 8 Object Oriented Design by David Anstey, (Chapter 8) Coriolis, 1997 for a discussion on development of this standard.

4Entity Relationship Modeling from an ORM Perspective, Dr. Terry Halpin, 12/99, The Journal of Conceptual

Modeling

5ibid

All methods used by the entity/table will appear in this lower section. Immediately to the right of the method name, in parenthesis, or following a colon, will be a list of attributes/columns used by the method. There should also be an

Figure 3 - Entity with Operation Area

option to turn on or off the ability to view the attributes/columns in the operational section, similar to the options the other display options currently available (data type, null etc.). and the ability to hide the operational section altogether.

The ability to attach an operation to a table actually currently exists in Erwin 3.5.2. An operation can be considered a table level stored procedure, which can be created and associated with a table in the Erwin 3.5.2 table editor.

Figure 4 - Erwin Stored Procedure Editor