Re: References & Restatement

From: Derek Asirvadem <derek.asirvadem_at_gmail.com>
Date: Tue, 3 Feb 2015 06:42:11 -0800 (PST)
Message-ID: <1809c4e6-a616-4f39-859c-b9a1dfe9824d_at_googlegroups.com>


James
Jan

> On Tuesday, 3 February 2015 20:22:27 UTC+11, Derek Asirvadem wrote:

Further Clarity

> Restatement
>
> Given the content of previous discussions, a short restatement of my position re the HM and its relevance to the RM is in order. I am saying the HM lives in the RM:
> - as a concept
> - a previously well-known model, method, of organising data
> - that is explicitly referenced, and used by Codd in the RM, throughout the paper
> - if one implements data according to the _Relational Normal Form_ given, for which explicit steps are given, this leads to Relational Keys, which are compound keys ("non-simple")
> - such keys, in the context of the series of tables in which each and all of those components ("simple" as well as all subsets of the "non-simple") are used, will form an hierarchy
> - the set of such table form an hierarchy
> - such keys may well be called Hierarchical Keys
>
> The corollary is:
> - where one fails to implement Relational Keys as they naturally occur in the data, the value, speed, and Relational power (independent join power) that exists in the Hierarchy (whence they came) is lost

Given the content of previous discussions, a short restatement of my position re the HM and its relevance to the RM is in order. I am saying the HM lives in the RM:

- as a concept
- a previously well-known model, method, of organising data
- that is explicitly referenced, and used by Codd in the RM, throughout the paper
- if one implements data according to the _Relational Normal Form_ given, for which explicit steps are given, this leads to Relational Keys, which are compound keys ("non-simple")
--- such keys, in the context of the series of tables in which each and all of those components ("simple" as well as all subsets of the "non-simple") are used, will form an hierarchy of keys
- the set of such tables form an hierarchy of tables
- such keys may well be called Hierarchical Keys (they are well-known as Relational Keys, I am not suggesting that we change it)

The corollary is:
- where one fails to implement Relational Keys, such as they occur naturally in the data, such as they existed in the hierarchical Model (whence they came), such as they would have existed in the Relational Model (had they been implemented), the value, speed, and Relational power (independent join power) is lost.

Cheers
Derek Received on Tue Feb 03 2015 - 15:42:11 CET

Original text of this message