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

Neo wrote:
> > Person(id, cars) Car(id, manufacturers)
>
> Ok, so initially given john has no cars, tom has two cars, and bob has
> one, the MV solutions looked similar to:
>
> Person Car
> john
> bob nissan, porsche
> tom aston_martin
>
> and with the new data requirements of 0-to-many mfgs, it became:
>
> Person Car
> john
> bob ->nissan, ->porsche
> tom ->aston_martin
>
> Car Mfg
> nissan
> porsche
> aston_martin gm, honda
>
> What is used to link the cars in the two files? Their name or some type
> of ID?

I would use codes for both cars and mfg. Of course, if this were a "car system" there would be other things to model, such as model numbers and the like, but I'm just working with the few requirements listed. Put both the codes for cars and for mfgs in the same validation table (see my current blog entry www.tincat-group.com/mewsings) or in separate "code files" (lookup tables).

> Does splitting the data from one file to two affect existing
> queries, ie find all persons who have nissan and porshe?

No, we simply added more data. Unlike if we had person and car in a view (with multiple lines per person) and then added mfg (thereby adding more lines), no queries are harmed in the addition of this data.

> I assume a
> human splits the data from the single file to two files,

If I am understanding, you started with 1 mfg that was in the car file and then went to multiples? Or did you do an ugly design up front by putting both the car and the mfg in the relation with the person, with car->mfg? Either way the queries are still fine. In the case that you removed the mfg from the person relation to another one, then queries all work, but your update "services" need to update a different "record" than they used to do.

> or is it
> handled automatically by db itself?

The db has one main integrity constraint that it handles (parent-child, when child is nested under parent) and very little else. Think 1970's.

> Because dbd is highly systematic, it doesn't require a schema change by
> user or splitting of data to different tables/files by user and
> pre-existing queries are largely unaffected. For example the following
> query to find persons with nissan and porsche stays the same before and
> after the new data requirements:
>
> (& (get * has nissan)
> (get * has porsche))

The reason queries can almost always stay the same in MV is because queries are related to vocabulary, which can be extended as needed. If we start with an attribute that is a list of cars and switch to the-form-formerly-known-as-1NF so we have one row per person-car combination, and another table Person, then we redefine "cars" as a virtual attribute associated with Person that "retrieves" all cars as a list (much like the SQL Server UDF that is an array, as I understand it). So, you don't need to ask a different question (that is, employ different vocabulary), but you might need to change the definition of your terms if you change the logical data model. --dawn Received on Wed Jan 17 2007 - 00:35:48 CET