Re: Relations as Repeating Groups & Namespaces

Responses in-line...

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c9m55r$k99$1_at_news.netins.net...
> Namespaces ...
> Think of a DBMS schema by whatever name as determining a namespace.
>
> A relation within that schema is named uniquely within that namespace.
The
> relation is then a sub-namespace where attributes are named uniquely
within
> that namespace.
>
> Within a SQL-RDBMS I could not think of any other clear namespaces below
> that level. There are undesignated namespaces for values, such as a State
> attribute providing a scope for the City attribute so if the value of City
> is "Grand Rapids" that value does not stand on its own, it requires a
> designation, such as a State of MI, to resolve the meaning of the value.

Congratulations. You have discovered (a) functional dependency. And look! No functions involved, just data. Whaddaya know...

>
> Repeating Groups...
> The root name space (an Oracle schema, for example) has relations as
> entities

No it doesn't. A relation exists in a _logical_ data model, and here you are dealing with a _physical_ data model. They are tables, not relations. Sometimes a relation in a logical model maps to a table in a physical model, but not always. For example they are usually one and the same on the 1 side of a 1:n relationship, but not always so on the N side. The N side table will take on any attributes of the relationship as well. For example:

OWNER - OWNS - REGISTERD_VEHICLE follows the syntax: entity - relationship - entity,

or if you wish,

relation - relationship - relation

In this case, the business rules state that an owner may own one or more vehicles, and for simplicity's sake, a vehicle can be owned by one and only one owner. So the logical model (with some attributes) is:

OWNER
driver_lic_nbr PK
driver_lic_state PK
name
etc

REGISTERED_VEHICLE
vin PK
make
model
etc

OWNS
purchase_date
lien_or_own

Note that in this case, the relationship "OWNS" iteslf has attributes. This is not normally the case, but it is not infrequent.

So, the tables (physical model) map out as follows. This is done by following established, published, proven rules to go to 3NF:

OWNER
driver_lic_nbr PK
driver_lic_state PK
name
etc

REGISTERED_VEHICLE
vin PK
driver_lic_nbr FK
driver_lic_state FK
make
model
purchase_date
lien_or_own

As you can see, two relations and one relationship in the logical model map to only two tables in the physical model to acheive 3NF.

Unfortunately, this invalidates the rest of your posting. If you want to stretch the notion, and convert the physical model back to a logical model, you could say that a schema (your namespace) in Oracle may contain one or more tables. A table belongs to one and only one schema.

 and, therefore, it has repeating groups (which relations are) as
> entities. The secondary namespaces, relations, are now permitted to have
> repeating groups too, but they are not part of the SQL-92 standard and
> infrequently used by anyone using a SQL-DBMS.
>
> Other models go one or more levels deeper than the relational model in
> permitting namespaces below the relational level. Other models are also
> more consistent in permitting elements within the root name space to be
> repeating groups (e.g. relations) as well as elements within
sub-namespaces
> and so on.
>
> So, if you look at the root name space as analogous to a relation, you can
> see that it would be mathematically elegant, at least, to permit the top
> level name space and sub-name spaces to play by the same rules rather than
> being decidedly different as they are in a SQL-DBMS.
>
> Did that make any sense? If not, ask questions as I want to write this up
> in a way that is not dismissed (or would like to know if this point is so
> stupid it should be dismissed, but be gentle ;-)
> Thanks! --dawn
>
>
Received on Thu Jun 03 2004 - 16:40:04 CEST