Re: Ideas for World Hierarchy Example

From: Bernard Peek <bap_at_shrdlu.com>
Date: Sun, 14 Jan 2007 18:22:33 +0000
Message-ID: <ml1oIsIpTnqFFwps_at_delta.shrdlu.com>


In message <1168756561.300693.166440_at_51g2000cwl.googlegroups.com>, Neo <neo55592_at_hotmail.com> writes
>> Essentially you can locate a point in space using either polar or
>> Cartesian coordinates. The fact that the two systems use different
>> values for the coordinates does not mean that they can't identify the
>> same point.
>
>So far, I have run into the following two formats:
>
>Lat: 1.2345 Long: 4.5678
>Lat: 5^ 6' 8"N Long: 2^ 3' 4"E (^ for degree)
>
>Are these both cartesian?

No. Both are polar coordinates. In 3D polar coordinates you have three values. One is the Latitude, the second is Longitude. The third is the radial distance from the centre of the sphere. When we use polar coordinates on maps we assume, by default, that the point we are locating is on the earth's surface. To get the full set of coordinates you would need to add some altitude measurement, either distance from the centre of the earth or altitude above/below mean sea level.

A Cartesian coordinate would take some predefined reference point and then describe the distance north/south and east/west and possibly up/down as well. It's the traditional XYX coordinate system. It doesn't work too well when mapping the earth on a global scale, which no doubt is why we usually use polar coordinates.

If, on the other hand, you are using a map projection on a flat sheet then Cartesian coordinates make more sense. If you lived in San Jose you might take that as the zero point and measure the distance of the bridge North and West of your home. If you need precise measurements over long distances this system breaks down because the surface of the earth is not actually flat so straight-line distances measured on a map are only approximations.

>
>> The difference between a hierarchical and relational database is not in
>> the data they hold, but in the route used to navigate to the data.
>
>Here is the current path to the latitude of the position of the Golden
>Gate Bridge:
>
>universe > milky way > solar system > earth > continent > north america
>> usa > state > california > city > san francisco > world wonder >
>>golden gate bridge > location > latitude > 37^ 49' 10" N

That's one path to the bridge, there are a lot of others. You could, for instance, divide the world's bridges into categories by construction type, suspension/cantilever etc then group into subcategories by the year in which they were opened. The choice of which set of coordinates you use to build the hierarchy depends on what information you have to start your search with. If you are only interested in suspension bridge engineering then the fact that the Golden Gate is in the USA is irrelevant and wouldn't be part of your search path. That holds true whatever search technique you use.

Something like the Golden Gate bridge has many attributes which could be used to build either a hierarchical (polar) or relational (Cartesian) map that you could use to navigate to select it. Which you would use depends on what you want to achieve and what information you have to start with. Relational methods are without a doubt the best technique for retrieving one datum from a large number of similar data. A great many database transactions rely on identifying just one bank account out of all of the accounts that a bank holds information on. Although you could use hierarchical indexing for those there isn't a great deal of need for it.

If on the other hand you are intending to write a book about the Golden Gate Bridge you would probably want information stored in a hierarchically indexed system. Libraries do that. You would search a subject index for Bridges and probably browse the shelf until you found a book or some books that had the information you wanted. Navigation by successive approximation is something that hierarchical indexing does well. So even if you have your data in a relational table you might well use it to emulate a hierarchical system. "Select * from catalogue where subject ='bridges'" followed by "Select * from catalogue where subject='bridges' and construction='suspension'". Lather, rinse, repeat until your selection brings up a manageable size list.

There are some people who feel that the existence of a hierarchical model is in some way threatening to the relational model. They react quite vehemently when a pretender to the throne appears. I see the same thing when the Linuxista troll Microsoft support newsgroups and Microgroupies troll the Linux newsgroups. It would be really nice if all of those people went away and founded their own newsgroups to argue in. I propose "alt.food.egg.littleendian" and "alt.food.egg.bigendian."

>Currently the world hierarchy example stores the following (and misc
>info about some of them):
>
>Planets (9)
>Continents (8)
>Continental Plates (14)
>Countries (197)
>US States & Nicknames (50)
>Cities (336)
>Capitals (252)
>Airports & Passengers(30)
>GPS Locations (151)
>Major Universities (11)
>Oceans (5)
>Rivers & Lengths (10)
>Mountains & Heights (7)
>Populations (258)
>Basic Elements (92)
>Languages & Speakers (16)
>Attractions (2)
>World Wonders (10)
>
>If any one can suggest other things to put in the hierarchy or better
>arrangement of the hierarchy or how to implement it using other tools,
>I am all ears. See www.dbfordummies.com/example/ex720.asp for
>downloadable db and exe (380Kb).

I think you have the cart before the horse. Fixed categories mimic the fixed table structure of relational databases, and if you are going to go that route then you should probably use a relational database. You won't gain anything from using the hierarchical model.

Instead consider allowing users to create hierarchies on the fly, depending on the data they have and the uses they want to put it to. At that point you need to ask for some help from the people here who have a deep understanding of the relational model, because you will then face a problem that they haven't yet solved either.

Yes folks, we're back to the EAV thread.

I'm not really interested in hearing all of the old arguments about why an EAV system can't work. Anyone who has spent any significant amount of time in this newsgroup can probably recite them by rote. Anyone else can Google for it.

How about turning the collective brainpower of the group on a constructive task: design a workable computer-based EAV system. The librarians built theirs 200 years ago, and it has been largely unchanged since Mr Dewey used Mr Aristotle's classification methods to create it. Can we do better in the 21st century?

-- 
Bernard Peek
back in search of cognoscenti
Received on Sun Jan 14 2007 - 19:22:33 CET

Original text of this message