GeoCASE is based on the Entity-Relationship (E-R) model, extended to suit an object oriented approach to representing the real world

GeoCASE – Data Modelling Tool
Introduction:

GeoCASE is based on the Entity-Relationship (E-R) model, extended to suit an object oriented approach to representing the real world. GeoCASE differs from the standard E-R approach in the following ways:

The term "class" or "object class" replaces "entity". A class contains both the data (attributes) and the operation and procedures to be used with the data.

Classes operate on a hierarchical basis and enable attributes to be assigned at the most appropriate level.
Spatial features can be grouped into categories according to dimension.
Dimensions can be 0D (points), 1D (spaghetti and simple line) or 2D (area).
Topological relationships are defined by intersection of boundaries and interiors.
The specification in terms of boundary/interior is more specific than casual terms such as "overlap".
Each class can be designated as being represented by a combination of spatial features.
Relationships include an additional spatial component.
The spatial component defines the intersection of boundaries and interiors of the classes at either end.
Additional spatial relationships such as "common line" (two polygons share a common line) and "line along" (two lines must lie along each other) can be specified.
Integrity checks can be run on the resulting database using the defined spatial restrictions.

Notation:

Derived classes are related to parent classes with an arrow pointing in the direction of the parent class.

Degree and optionality relationships are depicted on the model diagram as follows:

Dimensions:

Spatial classes can be one or more of the following:

0D: points
1D: spaghetti or simple line
2D: area

Where a class is identified as being more than one of the above it is linked to derived classes where the modelling identifies differing attributes or relationships.

Spatial relationships and constraints:

The above class types generally have both a "boundary" and an "interior" as follows:

A point has a boundary which is the point itself but no interior.

The two end points of a line are its boundaries and the line between these points is the interior.
The line around an area is its boundary and the contained area is the interior.

It is possible to define most combinations of boundary and interior as follows:

The boundary of class A can intersect with the boundary of class B.

The interior of class A can intersect with the interior of class B.
The boundary of class A can intersect with the interior of class B.
The interior of class A can intersect with the boundary of class B.

By defining the allowable spatial relationships in this way it is possible to place constraints on these relationships which can be used as integrity checks on the resulting database.

Code lists:

Code lists are used to define the domain (allowable range) of legal values for certain attributes. They also enable a user to select from these lists when entering data.

Structure of model documentation:

Each data model has been presented in the form of an HTML document with the following parts:

Overview

Class diagram
Class details
Relationships
Code lists
Miscellaneous information

Overview:

General details about the data model (project).

Class diagram:

A visual representation of the model depicting classes, relationships and the degree and optionallity of these.

Class details:

Details of each class including a description and notation as to its allowable feature types. (p = point, l = line, a = area). Where attributes have been defined these are also detailed. If an attribute has an associated code list this is detailed later.

Relationships:

Provides details of each relationship including. The details include the degree and optionality, along with the allowable boundary/intersection relationships.

Code lists:

Provides a list of the legal values for a specific attribute.

Miscellaneous information:

Other ancillary information about the model.