Re: Ideas for World Hierarchy Example

From: dawn <dawnwolthuis_at_gmail.com>
Date: 11 Jan 2007 19:28:42 -0800
Message-ID: <1168572522.547597.225550_at_v45g2000cwv.googlegroups.com>

Neo wrote:
> > > Marshall: Almost none of the data is encoded in a way a machine can do any useful semantic processing on it.
>
> > Dawn: when you click on words in a wiki, similar to "clicking" on a foreign key value within a database (an actual instance of a database), you navigate to another node (called a "document", think "record") that is set up as a tree (specified in xhtml, for example) with more foreign key values found by which you can find more documents (records). A wiki is a web. It can be modeled as a digraph with trees on the nodes. This is pretty much the model for many databases that are not RDBMS's by design (e.g. UniData, UniVerse, OpenQM, Revelation, jBASE, D3, Cache', UniVision)
>
> Would it be fair to say that RMDBs offer a higher degree of
> systematicness but less flexibility?

With the implementations of each model (intended model, no implementation is perfect), it would be fair to say that there are more constraints built into the dbms in the case of the RDBMS and more flexiibility with the di-graph. It isn't clear to me that is a function of the data model, however, as it could be more the mindset of those using the model. One implication of the way one is likely to implement an RDBMS compared to a "wiki data model" is that these seem more likely to have variable lengths throughout (as delimiters are used to implement hierarchy, just not delimiters with metadata like XML uses).

> And that di-graph based db (ie
> UniData, etc) offer a higher degree of flexibility but less
> systematicness? And each is a better fit for different types of
> applications?

This is a question I've considered several times because the marketing point for these not-really-RDBMS products has been that there are some apps that call for their use and that you choose the tool that is right for the application. However, I cannot think of any database implemented in an RDBMS that could have an equally good or better implementation in a di-graph other than an RDBMS that is open to multiple companies (that do not have a common parent company) to build apps directly on top of it. So, sure, it is fine to say that you want to choose the tool for the job, but that doesn't tend to be the way a DBMS is selected. It is more of the hammer that sees everything around it as a nail.

> > > T_City (id, name)
> > > T_Country (id, city, capital,
> > > official_cap, admin_cap, leg_cap, jud_cap, defacto_cap)
> > > How do I get rid of all those NULLs?
> >
> > ... don't worry about the nulls with this model
>
> Ok, I can let the NULLs slide, but what was worrying me more is data
> redundancy and not systematically storing some relationships.

You will notice I snipped your model since that is not the way I would model this. I forget all your requirements, but off the top of my head, I would suggest that if every city is in exactly one country (is that the case) your City relation (node, document, file, table), should include the country code

T_City (city_id, city_name, country_id)
T_Country (country_id, country_name)
T_Capital(city_id, capital_types)

and a code file, either specifically for capital types or preferably (in this model) a big one as indicated in my current blog entry on OTLT

If a single city can be in multiple countries, then turn the country_id into a multivalue and add country_id to the T_Capital relation. Otherwise the only nested structure is capital_types (and we named it with the plural so you could guess that it is a multivalued attribute)

> For
> example, captial is redundant. And the relationship between modifiers
> (ie official, admin, ... ) and captial is not stored in a
> tuple/attribute/value manner. I know I need to break T_Country into
> more tables but I can' t figure out into which ones exactly.

Does the above model work? Capital types would have possible values of OFFICIAL, ADMIN, DEFACTO, etc with a code file for the descriptions of these codes.

--dawn Received on Fri Jan 12 2007 - 04:28:42 CET