Enterprise Architect version 15.0

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

blahamichael

blahamichael

Michael Blaha

Modelsoft Consulting Corp (Consultant)

Since 1994 Michael Blaha has been a consultant and trainer in conceiving, architecting, modeling, designing, and tuning databases. He has worked with dozens of organizations throughout the world. Blaha received his doctorate from Washington University in St. Louis and is an alumnus of GE Global Research in Schenectady, NY. You can contact him at blaha@computer.org.
Monday, 29 August 2011 00:00

Data Modeling with the UML

The UML is a popular modeling notation for programmers, but it is little used by database developers. Nevertheless, the UML is highly effective for high-level conceptual data modeling. The UML notation avoids confusing database details, making it easier for business experts to understand data models. The suppression of details promotes deep thinking about data models, such as the use of abstract patterns. This talk explains the UML notation by comparison to IDEF1X.

Wednesday, 07 March 2012 04:16

Data Modeling Antipatterns - Part 2 of 2

An antipattern is a characterization of a common software flaw. An antipattern shows what not to do and how to fix it. As you construct data models, you should be alert for antipatterns and correct them as they occur. These videos show several examples of data model antipatterns and applies antipatterns to the LDAP case study.

The first EAP file is the database schema for the LDAP product. As the video explains there are 11 tables. The tables clearly define primary key field(s) and there is a consistent naming style. For example, by inspection one would suspect that ClassContainers.clsID and ClassContainers.containerClsID both refer to the Classes table. Examination of the data confirms this supposition. (There are a number of records and all the values of the presumed foreign keys are covered by referenced primary key values.)

A brief comment about notation. The legend "[1..1]" refers to attribute multiplicity -- a minimum of one value and a maximum of one value. When attribute multiplicity is omitted, then the default applies (minimum of zero and maximum of one). The legend "{pk}" means that a field is part of a primary key. All tables have a single primary key field, except for ObjectAttributes. The data types are self evident.

The second EAP file is the database schema after reverse engineering. I deduced foreign key on the basis of suggestive names and confirmed them by data analysis. The foreign key referent is mandatory or optional according to the nullability of the source attribute. Association end names indicate that the foreign key name differs from the referent primary key. The source of identity for ObjectAttributes is complex -- it combines ObjectLookup and Attributes and also requires a third value (sequence) that the qualifier indicates. The use of association classes and qualifiers during reverse engineering is common -- unfortunately many developers do not use object identity and they propagate identity from the data sources. A better schema for ObjectAttributes would have a primary key of objectAttributeID. Then the combination of aID, dsID, and sequence could be indicated with an alternate key.

This is part 2 of 2 in a video series.

Wednesday, 07 March 2012 04:04

Data Modeling Antipatterns - Part 1 of 2

An antipattern is a characterization of a common software flaw. An antipattern shows what not to do and how to fix it. As you construct data models, you should be alert for antipatterns and correct them as they occur. These videos show several examples of data model antipatterns and applies antipatterns to the LDAP case study.

This is part 1 of 2 in a video series.  Part 2 contains two Enterprise Architect Project files that supplement the presentation.

 

 

The duration of this video is 10 minutes and 35 seconds and it is the last of a seven part series.

The duration of this video is 12 minutes and 14 seconds and it is part six of a seven part series.

Please Note: The duration of this video is 6 minutes and 23 seconds and it is part four of a seven part series.

The duration of this video is 5 minutes and 35 seconds and it is part five of a seven part series.

Please Note: The duration of this video is 7 minute and 17 seconds and it is part three of a seven part series.

Tuesday, 11 January 2011 16:42

UML Class Modeling -- 2 -- Finding Classes

Please Note: The duration of this video is 5 minutes and 59 seconds and it is the second of a seven part series.

Tuesday, 11 January 2011 16:19

UML Class Modeling -- 1 -- Problem Statement

Please Note: The duration of this video is 1 minute and 34 seconds and it is the first of a seven part series.

Page 1 of 2