ТОП просматриваемых книг сайта:
Designing Geodatabases for Transportation. J. Allison Butler
Читать онлайн.Название Designing Geodatabases for Transportation
Год выпуска 0
isbn 9781589482913
Автор произведения J. Allison Butler
Жанр Базы данных
Издательство Ingram
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.
Physical data models
The most complete version of your geodatabase design is the physical data model, which includes many of the bells and whistles a geodatabase can supply. Classes are more precisely specified, as are their attributes. As with the transition from conceptual model to logical model, changes in the design may occur as you construct or test the physical data model.
The core of any physical geodatabase model will be object and feature classes. Relationships may be implied by foreign keys or explicitly included as relationship classes. An implicit relationship is called a join relationship and represents association. Explicit relationships may include attributes or merely enforce cardinality rules.
Domain classes may be added to control data entry by limiting the available choices to a defined set. An enumeration of representative values included in a logical data model must be converted to a fully defined list of values for the physical data model if it is to be reflected in a domain class.
The geodatabase has rich capabilities that ease the transitional leap from a conceptual to a physical data model. In the past, you would have been required to break down entities in the conceptual model into component parts when you made the transition. The implementation environments for which the physical data model is designed required you to provide the behaviors and data structures necessary to express the full range of characteristics and actions embodied in each entity. For example, with a relational database implementation, you have to create lookup tables for domain control and manage association relationships with software you write. In contrast, the underlying geodatabase data model allows you to implement such behaviors by simply declaring the domain of valid values and stating the rules you want to enforce, all without writing any code at all. At the end of the day, the geodatabase classes you define in the physical data model for a geodatabase implementation look very much like the entities in the original conceptual data model.
Figure 2.13 Physical data model The physical data model exists to embrace the implementation environment and mold it to the form required by the logical data model. This example is for an ArcSDE geodatabase that includes road centerlines in a polyline feature class, plus states and the routes they contain in two tables. An attributed relationship class handles the many-to-many relationship between State and Route: a state can contain many routes and given route can traverse many states. Four coded-value domains have been included to manage data inputs.
The next chapter describes the geodatabase and how it works. It also presents some basic techniques of geodatabase design.
All the data models included in this book were created using Microsoft Visio, which is also supported by ArcGIS for loading database designs into ArcCatalog so as to create classes automatically. Instructions for how to do this are contained in the online ESRI Support Center.
There are many tools you can use to create data models. If you have a copy of Visio, you will notice that it contains many templates for software and database design following a wide variety of published “standards.” Use the ones that work for you.
Notes
1 A computer scientist will tell you that these structures are called relations, not tables, and they consist of tuples (rows) and vectors (columns). These terms were chosen to avoid the impression that the data is physically stored as rows and columns in a separate piece of the database. In most RDBMS implementations, all the records in all the tables are stored in one big file. From a database design perspective, it is much better to work with tables containing rows and columns than the more ephemeral concepts of tuples and vectors contained in a table space.
2 Date, C.J. 1995. An introduction to database systems. Reading, MA: Addison-Wesley Publishing Co.
3 See, e.g., Zeiler, Michael. 1999. Modeling our world: The ESRI guide to geodatabase design, pages 81 and 98-99. Redlands, CA: ESRI Press.
Geodatabases