Re: Order details table reference live data

From: vldm10 <vldm10_at_yahoo.com>
Date: 19 Oct 2006 14:26:00 -0700
Message-ID: <1161293160.631504.216370_at_i42g2000cwa.googlegroups.com>


> Hence, the identifer used in recording propositions about that item
> should /not/ just be a {product_id} as it is in your current design,
> but rather a compound identifier such as {product_id, timestamp} that
> is able to distinguish it (and so can also serve as a foreign key in
> the orders table).
>
> For a better discussion than I can offer, I would recommend having a
> look at:
> "Temporal Data & the Relational Model" (Morgan Kaufmann Series in Data
> Management Systems).

I haven't been here, now I am back and here is my reply. 1)The solutions from 'Temporary data and The Relation model' (TDRM) have very complex key.
For arbitrary entity F (A1, Datefrom1, Dateto1,...,An, DatefromN, DatetoN) where Ai are the attributes
of F, the key K for F can be: (A1, Datefrom1, ...,An, DatefromN). If we need a relationship between F
and another entity, the relationship key, becomes very complex.

2) Sixth Normal Form is not a universal. In the book the authors write that some relvars of degree
three or more cannot be decomposed. In my model it is universally possible to decompose a relvar
into binary relvars, where one column is a simple key. These binary relvars are not a result of a decomposition procedure. They are the construction and
design of a database.
The starting relvar and the corresponding binary relvars have the same key, what is not in 6NF.
This can be important if the key of the starting relvar participate in a relationship key.
See for "Simple Form" on my website under dbdesign10/4.1

3) There is no definition what are the attributes, but they are applied directly in RM in this book.
I don't think that Datefrom1, Dateto1,..., DatetoN are the attributes of an entity.

4) The solutions in this book are not flexible. They can't support for example
the operator (i.e. user_password from my solution in this thread). The operator (i.e. user_password) in (TDRM) is the attribute of the entity,
but it is obvious that the operator in mentioned example is related to the
attribute price (not to entity product). Same for D1, D2, D3, D4 in my example
from this thread. In fact my solution supports much more. (See knowledge columns in dbdesign10/2.2)

5) In (TDRM) and 6NF the key is a composite. Let me briefly analyze the

kind of key from (TDRM) which you suggest; (product_id, timestamp). Here product_id is the surrogate key. As far as I know, there is no definition
of the surrogate key. I also use this key. There is "explanation" which Codd gave, that it is a surrogate. And it is the surrogate for the entity. Timestamp is the attribute of the entity(?)
So the key: (product_id, timestamp) is combination of the surrogate key

i.e. the surrogate for the entity and entity's attribute. In my solution from
this thread the key is precisely defined in dbdesign10/1.2 What is an attribute I defined in dbdesign10/ 5.2 and what isn't the attribute
I defined in dbdesign/5.1.
However I think that this book is very good book. The authors of the book tried to solve the problems which are not solved and which are fundamental in the database theory.

Vladimir Odrljin Received on Thu Oct 19 2006 - 23:26:00 CEST

Original text of this message