LITMIR.BIZ

       The data-modeling process

      You need a good data model to produce a good geodatabase design. Developing a geodatabase design is a six-step process that follows the flow of the agile methods discussed in chapter 1:

      Step 1—Define user requirements. First, you need to know the purpose of the data, the application requirements to be supported. Many users attempt to develop a complete set of requirements as the first step, but that cannot be done. Even for a small project, the agile method instead encourages you to create a good first effort that has the primary objective of identifying the major components. For an enterprise geodatabase that will support a wide variety of existing and yet-to-be-created applications, seeking a complete set of requirements as the first step is an impossible goal. No, your task here is to identify the general requirements.

      Step 2—Develop conceptual data model. Once you have specified the general requirements for the final product, you will need to identify the basic elements of a geodatabase that meets the requirements. Such elements consist of entities and their relationships. An entity may eventually be reflected in a class, but at this point in the process, you cannot establish a one-to-one equivalency between entities and classes.

      Step 3—Develop a logical data model. Once the general structure of the database—the skeleton—is established, the next step is to add some meat to the bones by specifying attributes for the geodatabase. Entities may change at this point, as attributes are assigned and new relationships discovered. The logical model is independent of the planned implementation platform.

      Step 4—Develop a physical data model. Here is where entities become classes and the implementation platform makes a difference. Your RDBMS, network structure, and organizational behaviors will influence the way you translate the logical design into a physical implementation. The added benefits of the geodatabase and ArcGIS will become apparent at this stage. The geodatabase can perform many functions that would normally have to be handled by user-developed software. For many geodatabase projects, the first task will be to split entities into tables and feature classes. You will also need to decide which fields can be supported by domain classes and which relationships need to be instantiated as a relationship class, not just an implicit relationship established by foreign keys you use when you desire. You need to be alert to the difference between layers on a map and components of the geodatabase. The next task is to specify the details of each class and create the domains, rules, and other elements of a geodatabase. The physical data model specifies the data type, default value, domain, and other characteristics of each attribute. The logical data model tells you about the classes and their attributes, although you may not implement the whole model at one time, and tests may motivate changes to get the desired performance.

      Step 5—Test the data model. Next, you can load the physical data model into ArcGIS and generate a prototype database for testing. Many central elements of a transport geodatabase can be implemented in more than one way. Testing the prototype before you put it into production is a good way to evaluate the efficiency of the implementation choices you made. Testing should include typical editing operations and involve a sample dataset equivalent in size to the one you will use. If the design does not pass this test, it may be necessary to go back to step 3 or 4 to make other choices, but it is much better to find out now than after you put it into production use.

      Step 6—Production implementation. Now you can reap the rewards of your work. Load the geodatabase and create the default version. It is time to put everyone else to work.

      These steps are generally sequential but you may move backward whenever necessary to redesign a portion of the geodatabase. You may also choose to prototype parts of the design at points well before step 5 so as to test key components. What works great for one agency may be a bad idea at another because of an organizational difference or the combination of applications to be supported. It is much cheaper to debug a paper design than an implemented geodatabase. Modeling will not eliminate all chance of error, but it certainly improves the odds of success. The balance of this chapter will explore the differences between conceptual, logical, and physical data models at one time, and tests may motivate changes to get the desired performance.