Lists Home |
Date Index |
> But not all data is tables or can easily be fit into one. There's a
> lot of real-world data, including many narrative documents like
> books, newspapers, diaries, letters, articles, magazines, pamphlets,
> brochures, and more that just doesn't fit into a relational model.
> Vector diagrams like UML, CAD, PICT, SVG, EPS, and similar also don't
> fit the relational model.
It's important to understand the difference between the relational model and
implementation choices made by vendors.
The relational model is about sets (relations) and defined mathematical
operations that act on those sets. Sets are unordered.
There is a difference between the conceptual, logical and physical model of
data. One defining characteristic of the relational model is it does not
specify the physical representation of the data -- it's about the logical
model, not the physical model.
Chris Date has supplemented Codd's work with more recent writings about
domains. Simply put: domain = class. He's said the ideas of object-oriented
are "orthogonal to the ideas of the relational model" because "nowhere does
the relational model prescribe what data types you have. It simply has a
mechanism that allows you to define data types."
So perhaps we should be asking more appropriate questions such as:
1. Should we attempt to retrieve information from the perspective of logical
operations or build ad hoc data retrieval solutions that are tied to the
underlying physical data structure?
2. Is there value in applying relational operations and integrity rules when
managing and accessing sets comprised of XML documents or UML models or SVG
For example, do I want to run a query over a database of aircraft schematics
that does a structural analysis of a specific part and retrieves all
diagrams having the same part? If, for example, the FAA recalls a part
from all Boeing 757-Ds, do I want to cascade that update to all aircraft
models having the same part and to all (XML) inventory documents and
manifests with that part?