XML, data modeling, and database design are all ways to structure data. Each has its place. Unfortunately, our industry is somewhat confused as to what those places are. This article attempts to
sort that out.
“Accurate and germane
XML, data modeling, and database design are all ways to structure data. Each has its place. Unfortunately, our industry is somewhat confused as to what those places are. This article attempts to
sort that out.
“Accurate and germane sharing of information across jurisdictions is a critical issue for justice and public safety. Although there has been significant progress in the field of
information technology, the lack of standards for exchanging justice data has not only been a major obstacle to, but also the principal reason for, the high costs involved with justice
So says the introduction to an XML model published by the Justice Department to promote data sharing. In response to this the Justice Department has developed the “Global Justice XML Data
Model” as a “collaborative effort among local, state, tribal, and federal visionaries.”2
The problem is that, while XML is a perfectly good vehicle for describing data to be transmitted from one place to another, it is not so good for describing the semantics – the nature of
– the underlying data. It cannot replace data modeling and sound database design.
This article will present this issue from two different perspectives:
- The meaning and significance of different kinds of data models, and
- The difference between storing data and transmitting data.
DIFFERENT KINDS OF DATA MODELS
Three Ways to Look at Data
In 1975, the American National Standards Institute (ANSI) published its “3-schema approach” to viewing data.3 As they the Institute saw it, there were at least three different
perspectives on data. (Actually, in various drafts, they saw many more perspectives than that, but these have survived.)
Everyone in an organization looks at its data slightly differently. Each person holds in mind a “schema” or structure that is the representation of his/her surroundings from a
particular point of view. Each of these schemas describing the world as one person sees it is called by ANSI an external schema. While, ideally, these are similar for the
many people working in a company, as often as not they are in fact very different. Misunderstandings about what something means are at the heart of many systems (and management) problems in
Because of their diversity, it is not practical to draw a picture of each person’s view of their data, but it is appropriate when surveying these points of view to assemble an ontology or
glossary of the language used throughout the organization. Where terms have different meanings or there are different terms for the same thing, these differences should be made explicit.
All of these participants in an organization are, after all, fundamentally looking at the same business, even if their perspectives are different. The objective of a good systems analyst is to
integrate the set of external schemas to produce a single conceptual schema which represents the fundamental structure of the organization’s data.
The data model that portrays a conceptual schema consists of boxes representing the things of significance to it, along with lines describing how they are related to each other. (This is often
referred to as an “entity/relationship” or “E/R” model.)
These conceptual schemas can be rendered at various levels of abstraction.
- An enterprise abstract conceptual data model is in terms of things that apply to the organization as a whole. This presents a general structure for addressing people
and organizations, geography, physical assets, activities, and corporate objectives.
- A purpose-oriented concrete conceptual data model is in terms of a language that is relatively close to a particular area or function of the organization, such as
contracting, human relations, or manufacturing. It represents assertions that are true for anyone working in that area, given the policies and procedures of the overall organization, but these are
usually about things that are specific to that part of it. The project concrete model is then made up of: 1) sub-types of the enterprise entity classes, 2) “views” (analogous to SQL
views) of sets of entity classes and relationships, and 3) new entity classes.
ANSI originally described the internal schema as the way data are represented in a physical storage medium. This included the use of random-access storage, tracks and cylinders, and so forth. With
the advent of database management systems, however, this was broken into two schemas:
- A logical schema described data in terms of a particular data management technology. In the early days, this might have been a hierarchical database management system
(DBMS), or a networked one. In more recent times, this describes the tables and columns of a relational DBMS, the classes of an object-oriented program, or XML tags.
- Database technology has advanced to the point that a true physical schema describing the physical architecture of a database is more important than ever. A set of
tables and columns in a logical database may be implemented in many pieces scattered all over the world.
No