Michael Blaha

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.

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.

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.

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

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