DataBlade Developers Kit User's Guide
Chapter 2: Designing DataBlade Modules
Home
Contents
Index
Master Index
New Book
Data Model
A
data model
is a high-level definition of a DataBlade module: what objects it will represent and what operations on those objects it will provide. 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 using 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:
Overlaps(Polygon, Polygon)
and
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 may have difficulty remembering which routine computes which value. For example, say 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:
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.
DataBlade Developers Kit User's Guide
, version 3.6
Copyright © 1998, Informix Software, Inc. All rights reserved.
