[
Lists Home |
Date Index |
Thread Index
]
hi roger
this is how unibase has managed relational database stuff for over 20 years:
the dictionary structure is (apologies for the diagram) a set of tables
each defined as:
<table def> ::=
<table name>
{<table help>}
<attribute def>
...
>
<key def>
...
>
{<association def>}
...
>
{<classification def>}
...
>
<table name> ::=
<simple name>|<alias name>
<simple name> ::=
<local filename>
<alias name> ::=
<text>,<simple name>|<simple name>,<file name>
<attribute def> ::=
<name>,<width>>{*<dimension>}{<domain>{<domain info>}}
<help>
<key def> ::=
{<attribute>{,<key def>}}
<association def> ::=
{<assoc type>}<table>{<key def>}
<assoc type> ::=
+|-|=|*
<classification def> ::=
<expression>
so basically (going back to the permathread) you fully normalise all
structures. define ways to find data in a table. and define
relationships between tables based on this info. after decades of
experience i can tell you it works very fast (much faster than
traditional sql stuff) and allows high level representations of the data
model. i've left unexplained some of the subtleties, but there are
semantic requirements for locating the correct rows that don't show up
in your simpler examples.
this works well over very large data sets comprising thousands of tables
and can be parsed in real time. in fact remote data relationships can be
discovered in real time too. i'm experimenting with an xml vocabulary to
replace the non-xml one used at the moment. and i am struggling with
some of the detail - i don't know yet if it's my problem or xml's.
also note that one issue xml sort of knows about but doesn't do well is
the need to view a piece of data in different ways. eg sometimes it's
useful to consider a number as a sequence of digits, sometimes it's
useful to think of the digits individually. a patr number might be one
string or a structured string (easier case) etc. you'll want to address
that at some stage too :)
another interesting point is that a lot of our syntax is visually 2
dimensional - is that unique? certainly makes reading and maintenance
much easier.
everything you want, just not xml. but the technology works and works well.
what goes around, comes around.....
rick
Roger L. Costello wrote:
>Hi Folks,
>
>Yesterday I received an approach from Naz Irizarry. His approach
>has some similarities with Peter's approach.
>
>Before describing Naz's approach let me make some observations
>about this simple XML object:
>
><Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
></Person>
>
>OBSERVATIONS
>
>1. The above XML represents information about a Person "object" with
> Name, HairColor and SSN "properties".
>
>2. The Name, HairColor, and SSN properties are "physics". That is,
> they are basic, immutable aspects of an object.
>
>3. These properties could be used by many objects. For example,
> they could be used to describe an "Employee":
>
><Employee id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
></Employee>
>
>or they could be used to describe a "Student":
>
><Student id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
></Student>
>
>and many, many other ways.
>
>Thus, many different types of objects may have the same properties.
>
>4. The properties may be aggregated with other type-specific
> properties. For example, the Employee type may have a specific
> property called EmployeeID:
>
><Employee id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
> <EmployeeID>10981</EmployeeID>
></Employee>
>
>5. The type of an object may be inferred simply from the aggregation
> of properties. For example, if I told you:
>
> "The object has 4 tires and a steering capability."
>
> You might infer that the object is an automobile. If I told you:
>
> "The object has 4 tires, a steering capability and wings."
>
> You might infer that the object is an aircraft.
>
>6. In the real world relationships between objects change. For example,
> when I drove to work this object:
>
><Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
></Person>
>
>established a relationship to this object:
>
><Auto id="RLC-Avalon">
> <Model>Avalon</Model>
> <Make>Toyota</Make>
> <Year>2004</Year>
></Auto>
>
>Namely, the relationship established was:
>
> "The RLC Person is driving the RLC-Avalon Auto."
>
>Once I got to work that relationship ceased to exist.
>
>Thus, it is useful to provide for dynamic relationships.
>
>7. Consider again the Person object:
>
><Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
></Person>
>
> This XML defines a "static" relationship between the Person "type"
> and the Name, HairColor, and SSN "properties". That is, by nesting
> <Name>, <HairColor>, and <SSN> within <Person> I am "hardcoding"
> a dependency between the <Name>, <HairColor>, <SSN> properties and
> the <Person> type.
>
>8. Consider the coupling of a Person object and an Auto object:
>
><Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
></Person>
><Auto id="RLC-Avalon">
> <Model>Avalon</Model>
> <Make>Toyota</Make>
> <Year>2004</Year>
> <DrivenBy href="#RLC"/>
></Auto>
>
> Note how the Auto object references the Person object
> using <DrivenBy href="#RLC"/>
>
> This defines a "static" relationship between the
> Person object and the Auto object. I am "hardcoding" a
> dependency between these two objects.
>
>9. I will stipulate that in large systems "agility" of data
> is important:
> - At "run-time" it is useful to be able to
> aggregate properties and denote them to
> be of a particular type.
> - At run-time it is useful to be able to
> extend the properties of an object.
> - At run-time it is useful to be able to
> add relationships from one object to
> another object, and to be able to
> remove relationships.
>
>With the above observations in mind, I am now ready to
>present Naz's approach.
>
>THE NAZ IRIZARRY APPROACH
>
>The key feature of Naz's approach is the Bag. Think of a Bag as an
>"object". An object has "properties". An object has a "type". And an
>object has "relationships" to other objects. Thus, a Bag has three parts:
>
>1. A collection of data (these are the properties of the object).
>2. An indication of the type (the type of the object).
>3. Relationship information.
>
>For example, here's how to express information about Roger L. Costello
>and his relationship to The MITRE Corp.
>
><bag id="RLC">
> <is-a instanceOf="Person"/>
> <has property="Name">Roger L. Costello</has>
> <has property="HairColor">Red</has>
> <has property="SSN">310-60-1234</has>
> <refersTo xlink:role="employed-by"
> xlink:href="#MITRE"/>
></bag>
>
>The way to read this is,
>
> "This is information about an object which has three properties - Name,
> Age, and SSN. The type of the object is 'Person'. It is related to
> another object (MITRE) by the relationship, 'employed-by'."
>
>With the Bag approach properties are dynamically composed. The
>same properties can be associated with a different type. Further, the
>properties can be associated with multiple types.
>
>Here the Name, HairColor, SSN properties are associated with an
>"Employee" type and a "Person" type:
>
><bag id="RLC">
> <is-a instanceOf="Employee"/>
> <is-a instanceOf="Person"/>
> <has property="Name">Roger L. Costello</has>
> <has property="HairColor">Red</has>
> <has property="SSN">310-60-1234</has>
> <refersTo xlink:role="employed-by"
> xlink:href="#MITRE"/>
></bag>
>
>So properties are things that can be aggregated, typed, and related to
>other objects ... dynamically. In a large, dynamic system this agility
>is crucial (I assert). This is called "opportunistic composition and
>relationships".
>
>In my last message I issued a challenge: how can simple vocabularies be used
>to construct an Invoice for the purchase of a Book. Here's how to implement
>the Invoice using Naz's approach:
>
><bag id="RLC">
> <is-a instanceOf="PostalAddress"/>
> <has property="Addressee">Roger L. Costello</has>
> <has property="Street">38 Boylston St.</has>
> <has property="City">Boston</has>
> <has property="State">MA</has>
> <has property="Zipcode">01320</has>
> <refersTo xlink:role="purchased"
> xlink:href="#Bach"/>
></bag>
>
><bag id="Bach">
> <is-a instanceOf="Book"/>
> <has property="Title">Illusions</has>
> <has property="Author">Richard Bach</has>
> <has property="Date">1977</has>
> <has property="ISBN">0-440-34319-4</has>
> <has property="Publisher">Dell Publishing Co.</has>
> <refersTo xlink:role="purchased-by"
> xlink:href="#RLC"/>
></bag>
>
><bag>
> <is-a instanceOf="Invoice"/>
> <refersTo xlink:role="contains"
> xlink:href="#RLC"/>
> <refersTo xlink:role="contains"
> xlink:href="#RLC"/>
></bag>
>
>The advantages of the Bag approach are:
>
>1. Opportunistic composition and relationships.
>2. Highly scalable.
>3. Well-suited in cross-domains.
>4. Well-suited in evolving systems.
>5. A flexible, dynamic Web of data is created.
>
>The disadvantages of the Bag approach are:
>
>1. It requires more skill to build applications because
> properties and relationships are not fixed. We are
> all comfortable with writing applications that can
> process this:
>
> <Person>
> <Name>Roger L. Costello</Bag>
> <Age>39</Age>
> <SSN>310-60-1234</SSN>
> </Person>
>
> But it is much more challenging to write an application
> that can process a {Name, Age, SSN} collection which in
> one part of the system represents a Person, in another
> part of the system represents an Employee, etc.
> Further, the relationships between this object and other
> objects may dynamically change (see observation #6 above).
>
>2. A flexible query and navigation language is required. The
> language must allow navigation based upon dynamically
> established relationships. For example,
>
> "[From the Person object] Navigate to the "driving" object."
>
> See Observation #6 above. Unfortunately, XPath provides a
> fixed (static) set of navigation capabilities - child, ancestor,
> preceding-sibling, etc. [I assert] These are inadequate in a
> large, dynamic system.
>
>Comments? /Roger
>
>
>
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
