Re: OO and relation "impedance mismatch"
Date: Thu, 7 Oct 2004 10:22:26 -0400
Message-ID: <DsWdnaVHBo-pzPjcRVn-pQ_at_comcast.com>
> 3. Enforce the arbitrary convention that a foreign key definitionto be based on the same domain. Keep track of the relationship between columns and domains in the metadata (and also in the DD if you have one.) "corresponding columns" includes foreign keys and primary keys, but it isn't limited to them.
> causes columns to be placed into the child table that correspond
> in name and type/precision/scale to the primary key of the
> parent. (consequently requires system to check for duplicate
> column names, but that should be prevented anyway).
There's another way. Allow named user defined domains. Define each named domain once in terms of type/precision/scale. Cause corresponding columns
consider this:
create domain employee_nbr number (6);
create domain department_nbr number (4);
create domain currency_amount (number 8, 2);
create table departments
( department_id department_nbr
, department_name char (40)
, manager_id employee_nbr
, budgeted expense currency_amount
, actual_expense currency amount
);
Here "manager_id is a foreign key, and is based on a named domain.
"department_id" is primary key (even though I didn't say so), and is based
on a named domain.
"budgeted_expense" and "actual_expense" are non key values, but they are
still based on a named domain
so that they are forced into the same type/precision/scale as each other.
"department_name" could have been based on a named domain, but what's the
point?
The primary value of named domains is to establish a link, at the elementary data level between database definitions and data dictionary entries. I haven't illustrated this, because it's DBMS specific, but it can be done. Received on Thu Oct 07 2004 - 16:22:26 CEST