Re: Hierarchical data models

From: Nilone <reaanb_at_gmail.com>
Date: Sun, 16 Aug 2009 03:09:54 -0700 (PDT)
Message-ID: <41f36481-9383-4e59-b19c-f8aee3eebc57_at_c29g2000yqd.googlegroups.com>


On Aug 15, 6:46 pm, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
> Nilone wrote:
> >I'm looking for any references, discussion or theory about
> >hierarchical models for situations such as residential addresses,
> >geopolitical subdivisions, corporate structures, military ranks, file
> >systems, type systems, etc.
>
> Do you mean something like this?
>
>  ftp://ftp.software.ibm.com/software/data/u2/pubs/whitepapers/nested_r...

No, I don't think so. In that paper, the parent-child relationship is an attribute of the type of the parent or child, meaning that a customer always has orders, an order always consists of parts, etc.

I'm talking about hierarchies where the parent-child relationship is part of the data. For example, from Wikipedia: 'Counties are used in 48 of the 50 states, while Louisiana is divided into parishes and Alaska into boroughs. These are considered "county-equivalents", as are some cities not designated as part of a county.'

Take a look at http://www.bitboost.com/ref/international-address-formats.html. What are the common attributes - how should I model an address?

>
> >I'm specifically interested in models that can recognize partial
> >correlations between subtrees, e.g. most/all countries have cities,
>
> [...]
>
> What does that mean?  Should the data model itself express such
> quantitative correlations, or only the query language?
>
> --
> Reinier

It seems to me that these organizational structures can be modeled as trees where every node is typed and every node can have children, but the parent/child relationship is not an attribute of the type of the parent. The entire tree forms a domain such that valid values of the domain are paths from the root of the tree to any leaf.

If you take the types and values of the nodes through which such a path passes / is constructed, you get something that looks like a tuple, except that the presence of certain attributes depends on the values of other attributes.

I see some resemblance to parsing regular expressions. Received on Sun Aug 16 2009 - 12:09:54 CEST

Original text of this message