Re: What is Pick anyway?

From: "x" <x_at_not-exists.org>

>
> "B Faux" wrote

[snip]
>
>> So now we can model the example in
>> a MV database with the multiple phone numbers, but I'll further
>> complicate
>> it by calling it 'contact data' allowing for pagers, email addresses,
>> etc.
>> In this case, we would benefit by creating two designated attributes in
> the
>> data record we'll call 'Contact_Type' and 'Contact_Data'. We will
>> further
>> establish these two fields as 'related' fields or 'controlling-dependent'
>> related attributes.
>
> How can one define two fields as "related" ?
>

The 'controlling/dependent' relationships are handled in the dictionary record. In this example, the dictionary will contain two records to control the 'Contact_Type' and 'Contact_Data' fields. You would then assign a 'controlling' value to the '_Type' dictionary item specifying the '_Data' attribute (field) as that which is being controlled and a 'dependent' value to the '_Data' dictionary item specifying the '_Type' attribute that controls it, (methods of doing this vary among MV implementations, but all have it in some way.) This will keep the relationships straight, so that if you try to enter a 'Contact_Data' element (value), you will need to also specify the 'Contact_Type' for that data or the write will not be successful, at minimum you will get run-time errors on data extraction or reports.

>> So extending the example above, the actual data as stored in the database
>> looks something like this (please forgive formatting - these should
> align):
>>
>> Field (attribute) - Description
>> 0 - ID
>> 1 - FIRSTNAME
>> 2 - LASTNAME
>> 3 - POSTALCODE
>> 4 - CONTACT_TYPE
>> 5 - CONTACT_DATA
>
>> Notice no reserved space for 'CITY' or 'STATE' because these values are
>> contained in a different file, the 'POSTAL file. We might benefit from
>> creating a control file called 'CONTACT', but the data likely to be held
>> there could also be in the dictionary item itself, if there are only a
>> few
>> types allowed. So we'll use the following: 'HP' for 'Home Phone', 'BP'
> for
>> 'Business Phone', 'MP' for 'Mobile Phone' and 'EM' for 'Email.'
>
> With this design is it possible to store a contact data as being of
> multiple
> types ?
> For example a list of contact addresses being of both e-mail and home
> types:
> Home Business
> Phone HP BP
> E-mail HEM BEM
> In other words: In a type field is it possible to store a variable number
> of
> values ?
> Is it possible to define three fields as "related" (T1,T2)-->V where
> (T1,T2) define the type for value(s) V?
> What makes type fields different from other fields ?
> How many kinds of fields are there ?
> What make them different ?
>
> The following "design" is possible ?
>
>> Field (attribute) - Description
>> 0 - ID
>> 1 - FIRSTNAME
>> 2 - LASTNAME
>> 3 - POSTALCODE
>> 4 - CONTACT(TYPE, DATA)
>
> If yes, what make it different from first design (ignoring physical
> file/disk layout).
>
>

Caution - space based formatting may have screwed up my example in your post.

It should be showing a total of five (5) data elements (attributes, fields), with Contact_Type and Contact_Data listed in separate fields.

To answer your question... Yes, it is possible to extend this indefinitely. The original example only specified three (3) fields (or attributes) in the data record; FIRSTNAME, LASTNAME, and POSTALCODE. These being quite logically assigned to attributes 1, 2, and 3 respectively. Furthermore, each data element has only a single value.

In my extended example I have added two additional fields for CONTACT_TYPE and CONTACT_DATA. These have been assigned to attributes 4 and 5 in the data record. But in contrast to the original example, these attributes are "Multi-Valued" to allow for UNLIMITED individual data values.

You could add another attribute (field) to house an additional related data element. But I would recommend an extended file method, like that used in the City and State extraction of the original example from DonR. This technique would allow you to store repeated data values that pertain to the same Contact_Type in one place, the actual file data only needs the correct Contact_Type value to translate from the 'CONTACTTYPES' file, for example. Now there is only one record to maintain for each supported Contact_Type, not every PEOPLE record in the system.

If you combine the values of different types, as the modified example above seems to imply, you would lose the ability to extend the values within the structure of the DBMS. The built-in capabilities to create and maintain indexes, or to search and retrieve specific data elements would be lost, which is a very high price to pay. You could design it to contain combinations within sub-value structures, but you would be unnecessarily complicating things. There is nothing to be gained from this and much would be lost.

Also beware, human beings (even mutants like us) are conditioned to prefer to see things represented a certain way, like having the Contact_Type followed by the corresponding Contact_Data, which in turn is followed by the next Contact_Type and it's Contact_Data, etc. But the Data Base Management System (DBMS) wants to see it turned on it's side (so to speak.) Resulting in a simple delimited list of 'Type's in one attribute, with the corresponding 'Data' in another (they do not need to be sequential.)

This is primarily because the dictionary references will be keyed to the attribute number, it is difficult (if not impossible) to tell the dictionary that the odd numbered values in an attribute are for 'Type' while the even numbered values are for 'Data'. As I mentioned earlier, there is no advantage to doing this, except to make it easier for ordinary earth people to read it in raw form, and who cares about them anyway?

BFaux- Received on Mon Jan 16 2006 - 22:55:04 CET