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.

Topics in Section 4:

• Overview of the Model
• Logical Models vs Physical Models
• The Content Standard versus a 'Physical' Standard
• Links and References to Information on Data Modeling

Overview of the Cadastral Data Content Standard Model

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 vs Physical Models

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.

The Content Standard versus a 'Physical' Standard

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.

Links and References to Information on Data Modeling

• Applied Information Science
• There is a commercial data modeling product from agpw, inc., known as Data Master. Though we have not reviewed it and cannot endorse the product, you may find it to be worth investigating.

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:

• Bachman Information Systems Data Base Management No. 6, The Entity Relationship Approach to Logical Data Base Design. Q.E.D. Monograph Series (Wellesley: Q.E.D. Information Science, Inc. 1977).
• C.W. Bachman "Data Structure Diagrams" Journal of ACM SIGBDP Vol 1 No 2 (March 1969) pages 4-10.
• McFadden & Hoffer _Database Management_, 3e, Benjamin Cummings, 1991, ISBN 0-8053-6040-9 or Date _An Introduction to Database Systems_, Volume 1, 5e, Addison Wesley, 1990, ISBN 0-201-51381-1
• Charles W. Bachman: The Role Data Model Approach to Data Structures. 1-18, published in S. M. Deen, P. Hammersley: Proceedings International Conference on Data Bases, University of Aberdeen, July 1980. Heyden & Son, 1980, ISBN 0-85501-495-4.

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 Reference] [Introduction] [Section 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 Module] [Glossary]