Data model

A data model is a high-level definition of a DataBlade® module: what objects it represents and what operations on those objects it provides.

Here are some issues to keep in mind when you design a data model:
  • Consider the data model independently from the applications that use it and the user interfaces required by those applications.
  • Concentrate on designing a service, rather than an application.
  • Build a data model that is reusable by multiple client applications, rather than creating one tailored to a particular client application.
For example, consider the fictitious SimpleMap DataBlade module, which stores, manipulates, and displays maps. The data model for this DataBlade module might specify:
  • Spatial data types, such as polygons to represent counties and cities and line segments to represent roads and rivers
  • Operations performed on the spatial data types, such as search and comparison routines that determine whether a particular city lies within a particular county or whether two roads intersect

This data model allows you to make requests such as, Find all the polygons in the map that fall inside the currently visible region, where the currently visible region is a given polygon. The query scans the database and returns only the polygons that meet the request criteria.

However, the display logic for the data types does not belong in this data model; the rendering of polygons is a user-interface issue. After the desired polygons have been retrieved from the database, the client application displays them.

The data model for a DataBlade module must be simple to understand, and the DataBlade module must provide a rich set of services with a minimal set of routines. This fundamental software design concept applies to DataBlade modules in particular, because DataBlade modules are intended for use by other developers.

For example, in the SimpleMap DataBlade module, assume that users want to find overlapping regions on a map. The DataBlade module can provide a number of different interfaces to support the query. Two examples are as follows:
Overlaps(Polygon, Polygon)
Contains(Polygon, Polygon)

The Overlaps() routine returns TRUE if any parts of the two polygons overlap, while the Contains() routine returns TRUE if the first polygon completely contains the second. These two routines are simple to understand and easy to remember.

However, if the semantics of two routines are too similar, users might have difficulty remembering which routine computes which value. For example, assume the SimpleMap DataBlade module also provides the following Intersects() routine: 
Intersects(Polygon, Polygon)
This routine returns TRUE if the boundaries of the two polygons intersect. Intersects(a, b) is equivalent to the following statement: 
Overlaps(a, b) and not (Contains(a, b) or Contains(b, a))

Intersects() and Overlaps() are confusing when both are supplied. Because Overlaps() and Contains() together can compute intersections, it is probably best to leave Intersects() undefined.

When you design a data model, separate the routines used by a single application from the more general service routines. For example, perhaps you want to provide a routine that takes a polygon as an argument and returns another polygon with a border exactly one pixel outside the original. To display the new polygon, the two polygons are used together to create the appearance of a polygon with a thick border.

Such a routine is probably useful only for a particular application that displays thick-bordered polygons; it is not useful to other applications that operate on spatial data. Thus, it is a poor candidate for inclusion in a DataBlade module.

In summary, these are the issues to consider when you design the data model for a DataBlade module:
  • Separate the user interface from the abstract operations on data.
  • Think about data types and routines that operate on them.
  • Keep the design simple.
  • If you are building a production DataBlade module, do not add server routines intended to support a single application.