Sections 4 through 8 are the sections of the Cadastral Data Content Standard educational course which present detailed technical concepts about data models, crosswalks, translations, and maintenance of the Standard.
Section 4 describes the entity relationship diagram and the definitions and relationships used in the Cadastral Data Content Standard, clarifying the data modeling conventions used in the Standard's logical model. Please note that data modeling is a precise and detailed discipline, often requiring a good bit of effort to gain a working knowledge. If you are new to data modeling, keep in mind that the information presented here in Section 4 may require some extra time and patience to understand.
The logical model describes the definitions or semantics of the cadastral information referred to in the Standard. An entity relationship diagram is a shorthand method for showing the associations among various objects in the model, and the relationships between the objects.
The entity relationship diagram illustrates the model's objects, such as the entities, attributes, and the associations (see *Note below).
A logical data model is not an implementation model. Implementation requires modifying the logical data model to best fit operating software. This process, called denormalization, is the process of combining entities into tables in a database that optimize the database operation.
See the diagram conventions discussion for more information about the E-R diagram used in the Cadastral Data Content Standard.
(* Note: The term "association"
is used throughout the Cadastral Data Content Standard to refer to descriptions
of how data entities are related to each other. Some people may be more
accustomed to using the term "relationship", and may wish to substitute
that term for "association" while investigating the sections which describe
the data model.)
Logical models depict the true relationships of attributes as they are grouped into entities, relating attributes to attributes and entities to entities. Logical models are not concerned with implementation, storage mechanisms, and redundancy of data. Logical models are usually normalized. Normalized means that every attribute is independent, that is, not dependent on any other attribute.
Physical models are concerned with the implementation of logical models, and are designed to account for data storage, indexes, how to retrieve data, and how keys are concatenated. Physical models strive to optimize logical models according to how data are going to be used, such as for reports, data entry, and analysis. Physical models take into account the software that will be used, as well as whether the database will be relational, hierarchical or network.
Entities do not have to be the same between the
logical model and the physical model. That is, in order to accomodate efficient
use of data, a physical model may have a greater or fewer number of entities
than a logical model. The physical model assigns lengths to attribute fields.
A physical model is usually de-normalized, that is, attributes may be assigned
values and dependencies with other attributes to support using the data.
For example, an attribute can be derived for one or more other attributes.
The attribute is used daily for reporting purposes so the derived attribute
is stored in the data base to avoid daily recalculation.
For example, the cadastral standard provides a unique nation-wide identification of principal meridians. The names of the principal meridians have been standardized and are listed in the Standard document. In a physical format for a county or state that uses one of the principal meridians, it does not make sense to repeat that value for every record in the county or state. In this case the physical format does not include the principal meridian as defined in the Standard in the database. The value for the principal meridian can be generated and added upon data transfer or exchange.
In another example, an organization may decide they want their physical database to combine bearings and distances and their units of measure in the same file as the record boundary. This might be done to accommodate a computational package, to increase the ease of review of values, or to enhance search performance. The Cadastral Data Content Standard does not provide for this kind of physical database design and use.
The physical structure of cadastral databases will be
dealt with by the Cadastral Data Transfer Profile, which is currently in
development, and is described in Section 6.
Bruce, T.A., Designing Quality Databases with IDEF1X Information Models, Dorset House, 1992.
Chen, P.P.S., "The Entity-Relationship Model -- toward a unified view of data". ACM Transactions on Database Systems 1, 1, March 1976.
Jackson, Michael A., System Development. Prentice Hall International, Englewood Cliffs, New Jersey, 1983.
Federal Information Processing Standards Publication 184, the Standard for Integration Definition for Information Modeling, U.S. Department of Commerce, Technology Administration, National Institute of Standards and Technology, December 1993.
One of the best short summaries of Bachman and Chen data modeling methods which we have found is in McDonnell Douglas' ProKit WORKBENCH Application Manual, Chapter 8, Data Modeler. This is a proprietary software documentation manual, so as far as we know it is not a book available for purchase. Contact McDonnell Douglas (1-800-225-7760) if you are interested. (Note: In April 2002 it was pointed out to us that this document is no longer easily available from McDonnel Douglas, and thus may be difficult to find.)
Surprisingly, there is virtually no widely accessible published information on the Charles Bachman method of data modeling. A search on the subject of Bachman data modeling brought up the following articles:
This ends Course Sectin 4. Use the links below to return to the top of this page, or to go on to Section 5, or any of the other Modules.
Links to the Course Sections and Modules: [Quick
1: Purpose and Benefits of the Cadastral Data Content Standard] [Section
2: How the Standard Was Developed] [Section
3: Other Standards and Related Activities] [Section
4: Data Modeling Techniques, Rules and Diagram Conventions] [Section
5: Crosswalks, Translations, and Examples] [Section
6: Understanding Compliance with the Standard] [Section
7: Maintenance of the Standard] [Section
8: User and Technical Support] [County
Recorder Module] [GIS
Specialist Module] [Surveyor
Learning the Cadastral Data Content Standard
Presented by the United States Department of the Interior Bureau of Land Management, and
the Federal Geographic Data Committee Cadastral Subcommittee