notation shows a finished product. What you are creating is a work in progress. You need to add notes that explain what the model says and callouts to describe specific entities and relationships. Business rules and definitions are not generally part of published conceptual models, but you will need them. The only important consideration is that the team members developing the model understand the model. Do not try to adhere to a particular external documentation standard for everything. This is not the time to try to teach everyone about the details of data modeling. There is no extra credit for pretty pictures. Use what works best for you. This book shows you the part that probably should be fairly uniform across teams and will be consistently used in this book.
Logical data models
Logical data models presented in this book use a simplified version of the iconic notation typical of Unified Modeling Language (UML) steady-state diagrams. These diagrams present classes and their relationships. You have already seen the UML relationship notation. You also know a class is the encapsulation of software and the data it needs. We only want to model data. ArcGIS and the geodatabase take care of the software part.
Figure 2.10 Object classes This is the normal form of UML steady-state data models. Visibility defines the degree to which class attributes and methods are accessible by other classes. This standard symbology is modified to create the graphical standards for logical data models. The two primary changes were omitting methods, which the ArcObjects we might include in the database design already provide, and assuming that all attributes (properties) are open for anyone to see (public). All attributes added to geodatabase tables and feature classes are also public.
Our data model graphical standards represent a compromise between graphical consistency with UML and other ArcGIS documentation standards. UML is actually used by computer programmers to design their software. The notation is adapted here for use as a data modeling language.
Although it is common to do so, it is really a bit of a stretch and mismatch to use UML steady-state diagrams as a data model. UML is really for application design. Since the data and software that work on the data are tightly bound through encapsulation, steady-state diagrams do show the data, but with a limited view.
Normally, a class symbol is a rectangular box subdivided into three parts. The upper part of the class box holds the name of the class. The center part of the box holds the various class properties (data). The bottom part holds class methods (software). However, the bottom part is not required since ArcObjects classes already include the operations needed to implement a geodatabase. So, logical data models for geodatabase designs use a rectangular, two-part box that omits the bottom methods section. All class properties that you add will be public, so the visibility indicator is not required. Class properties can be referred to as attributes, fields, or columns, and such terms as class, table, and feature can be used to refer to the entities in logical data models.
OK, here is the truth: the other sidebar is lying. You do not actually add properties, in the UML sense of the word, to any ArcObjects class when you create a geodatabase. What you are really doing is using properties and methods that are already in the class. The ArcGIS user interface allows you to access those properties and methods by using wizards and other tools to customize classes so they serve your purposes, but you are not really changing those classes. UML steady-state diagrams are for creating software. You are not creating software; you are designing a geodatabase that is constructed of classes provided by ESRI and, perhaps, one or more of its business partners.
Think of it like using spreadsheet software. When you get started, all you see is a bunch of little boxes into which you can type numbers, text, and formulas. Anything that happens with the contents of a box is already in the spreadsheet software. You are not creating the spreadsheet software. It is the same with the geodatabase you are designing. The geodatabase is already in ArcGIS. You are just telling it which of its capabilities to use and what the inputs and outputs should be.
So, UML is really a poor way to create data models, but it is the one we have. If we were starting from scratch to create a new language, we could definitely think of something better than English, but then we would not have anyone to talk to. It’s the same way with using UML to create data models. It is a language many people already understand.
In all cases, the name of a class that can be created will be shown in normal type, while the name of a class that is abstract in nature (a stereotype that cannot be created but serves as a template for defining a creatable class) will be shown in italics. Attribute names will be stated using a concatenated mnemonic name in a Roman sans serif font with an initial uppercase letter and intermediate capitals to assist in understanding, for example, FirstName.
Besides the entities, a logical data model includes relationships. Relationships are shown as a line with end symbology. For example, the UML diagram in figure 2.10 shows an inheritance relationship, which means that the Employee class is based on the Person class. By convention, UML only shows the new properties and methods added in the Employee class, with all the Person class properties and methods included by the inheritance relationship. Person is thus the parent stereotype or supertype of the Employee class.
Figure 2.11 Stereotypes Inheritance is normally shown through an explicit relationship, but it can also be indicated by placing the name of the superclass in the class name space within double carets. This convention is normally used when the superclass and its inheritance relationship are not shown.
Sometimes the supertype class is not shown. By UML convention, the name of the superclass from which the class inherits its base attributes in the class name space can be included in the entity name space. Some classes may include subtypes listed below the normal class specification. All subtypes have the same attributes.
Figure 2.12 Logical data model A logical data model fleshes out the entities of the conceptual model by adding attributes and resolving many-to-many relationships. Since an ArcGIS geodatabase consists only of predefined classes with mandatory and user-defined attributes, methods will not be included. The result is an abbreviated form of the traditional UML notation and the usual reference to the class properties as attributes. Each ArcGIS class will determine the manner in which attributes are converted to properties.
Relationship notation continues unchanged from that of conceptual data models, but there are differences. One change you should notice is that there are no many-to-many relationships in a logical data model. They have to be resolved during the transition from conceptual to logical form. Otherwise, a logical data model will look much like a conceptual data model with attributes added. A logical data model may also include an enumeration of values that help express the domain of one or more attributes. An enumeration is an example list of values for a domain. The complete domain does not have to be specified until you create the physical data model. The enumeration may become a domain class in the physical data model.
