Re: Nulls, integrity, the closed world assumption and events

Neo wrote:
> Ok, so the MV solution for persons with cars with mfgs look more like
> this (please correct any glaring errors):
>
> Validation Table
> ?cat code? name?
> Car NSN Nissan
> Car POR Porsche
> Car ASM Aston Martin
> Mfg GM General Motors
> Mfg HND Honda
>
> Person Table
> person car
> john
> bob NSN, POR
> tom ASM
>
> CarMfg Table
> Car Mfg
> ASM GM, HND
>
> Queries to find cars mfgd by Honda:
> Add MfgCode and Mfg as virtual fields to the vocabulary of "Cars" (?
> CarMfg Table ?)
> LIST Cars WITH MfgCode = "HND"
> or
> LIST Cars WITH Mfg = "Honda"
>
> Query to find what has things that are manufactured by something whose
> name is honda:
> Add Mfg in Person vocabulary.
> LIST Person WITH Mfg = "Honda"
>
> Query to find people who only have cars from Honda:
> LIST Person WITH EVERY Mfg = "Honda"
>
> -----------
> Questions:
> 1) It seems all entities are moving to the validation table. Why aren't
> people in the validation table also?

Goodness know. Only abbreviations and their descriptions are there, aka "code files." (See my current blog for perhaps a better explanation)

> 2) Would a better name for the Person Table be PersonCar Table?

In this case, if the business is in the auto industry in any way, then I would think of these cars as entities and the table would be a person-car table. Because it is a strong entity, if I needed an embedded table (cars & mfg, even if virtual data) rather than a simple list, I would likely make a PersonCar table, but if this is a typical business outside of the auto industry, then we can think of the cars a person has as more simple demographic data (and likely don't care about the mfg).

Straight answer is Yes, most likely given the requirements you list (both cars and their mfg)

> 3) Adding virtual fields are in essense table joins?

In reality they are definitions to vocabulary items. Think language instead of mathematics for a minute. This model is based extensively on vocabulary. But we would define the Mfg by specifying the link (join-ish, but not processed with a set-mindset) from whatever vocabulary (schema) we are asking a question about to wherever the data is that we want to know. So, when a system is turned over to the user, they are given an extensive vocabulary, including both "base table" (stored data) and derived data. In one of my articles I indicate that to the user this is like looking into Mary Poppin's bag and pulling out everything they want. When they look at a Person, they can see everything they want to know about a Person. When they look at a Car, similarly. The work is in extendnig the vocabulary and catching whatever users might want to find in Mary Poppin's bottomless bag.

> Can you show the
> ones to implement the above queries?

Maybe another of the Pickies will help me out here, but the essence is a function that takes in the car code and uses that to retrieve the mfg code from the CarMfg table. So, it needs to know which attribute to use in the source table, the name of the target table, and which attribute to retrieve.

--dawn Received on Thu Jan 18 2007 - 00:33:56 CET