Re: Relations as Repeating Groups & Namespaces

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Thu, 3 Jun 2004 10:48:36 -0500
Message-ID: <c9nh8r$i8f$1_at_news.netins.net>


"Alan" <alan_at_erols.com> wrote in message news:2i8ri8Fj9bvoU1_at_uni-berlin.de...
> 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...

You are gonna have to get that def of function out again, Alan. :-)

> >
> > 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.

Nope, I'm only dealing with the logical model, but provided an example implementation in case it was useful.

> They are tables, not relations.

I'm talking about relations.

> Sometimes a relation in a logical model maps to a table in a physical
model,
> but not always.

Absolutely, but stick to the logical model with this.

> 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:

proven? I think 1NF, on which 3NF is based is an axiom -- I can find not mathematical proof for it based on set theory or first-order logic axioms, for example. Can you point to the theorm/proof for this?

> 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.

Don't be distracted by the physical model - I'm sorry I brought up Oracle schema as an implementation of a root namespace -- think of the namespace hierarchy and the fact that it stops being built-in after one step down in the relational model.
<snip>

--dawn Received on Thu Jun 03 2004 - 17:48:36 CEST

Original text of this message