Fails Relational, Fails Third Normal Form
Date: Wed, 4 Feb 2015 19:15:48 -0800 (PST)
Message-ID: <6d463360-6a59-4cfc-a5dd-1b280fc5f611_at_googlegroups.com>
> On Wednesday, 4 February 2015 21:35:12 UTC+11, Jan Hidders wrote:
Thank you for breaking the ice.
> Op dinsdag 3 februari 2015 03:11:05 UTC+1 schreef Derek Asirvadem:
I will take each of them separately
> Yes, it is in 5NF.
> >
> > Ok. Here is the latest extension that a developer proposed to me, to be added to the RDb.
> >
> > http://www.softwaregems.com.au/Documents/Article/Normalisation/Relational%20Database%20101%20A.pdf
> >
> > We need a set of tables to rationalise and consolidate all Addresses. The company sells their gear on the internet as well as Australia, the addresses have to be international. This is what the developer says is the cluster of all address type data that will be used as reference, in order for the data quality in the single Address table to be maintained. The CountryCode and StateCode are ISO 3166-1 and 3166-2, and the CountyCode is ANSI/FIPS, or something meaningful outside America (I already have that loaded elsewhere).
> >
> > Answer the questions in sequence, please. No point in going to [2] if you reject it at [1], etc.
> >
> > 1. The developer declares that the proposed extension satisfies 5NF. Is that correct ? If not, please state why, which NF is breaks, any errors that it may have, etc. A few words will suffice. I expect minimal discussion, but don't let me stop you.
>
> Yes, it is in 5NF. But it is not dependency preserving.
Ok. I think there is no disagreement that, if it "satisfies" 5NF, then it means it "satisfies" 4NF, 3NF, 2NF, 1NF. Yes ?
That is what the developer says, so you are confirming his declaration.
I don't know what to say.
First, from my position of
- Normalising data for 39 years, as a science
- following Normalisation after it was defined as NFs (Codd 1970, 1971), within that science, because those early declarations proved science and articulated it
- after seeing the putrid garbage that various blind people proposed, and dismissing them, as an attack on Codd, on science
- which act reinforced the science, the principle, and categorised the blind who populate certain parts of our field as gross incompetents
- I am left with The Three Normal Forms (not counting HNF and RNF, because you guys have not heard about that [which btw suggests that the blind are deaf as well] )
I declare:
____the proposed data model [A] fails 3NF____
and in general:
____the proposed data model [A] is not Normalised____
Further, since he intends this cluster to be implemented in a Relational Database: ____the proposed data model [A] fails Relational____
- Fail -- The model fails for the following reasons (many instances of said reasons). The ordering of the issues is mine, in that if it isn't Relational, it is not worth bothering about the specifics of a Normalisation error. It fails *Relational* mandates on two counts, it is non-relational.
1 Definition for keys, from the RM: "a Key is made up from the data" __ A surrogate (RecordId) is not made up from the data __ There are no keys on the data
2 The RM demands unique rows (data)
__ A surrogate does not provide row (data) uniqueness
This is a classic Record Filing System, anti-relational. It is nowhere near ready for Normalisation, let alone Relational Normalisation.
None of you theoretician identified any of that.
> But it is not dependency preserving.
Very good insight. Trusting that you do not have private definitions for "depency" and "preserving". Give that man a purple cloak and a point hat!
But from where I sit, there you go again with self-contradiction. In the physical universe, where things are a bit more integrated than in the outer reaches of the galaxy, it is easy for me to Normalise, 3NF is part of, inseparable from Normalisation.
- approve unnormalised data as normalised - permit the absence of essential properties - in the data that you say is "normalised"
Take the purple pointy hat back! Ok, keep the robe.
> > 2. The developer is excited because he has read the C J Date and R Fagin paper *Simple Conditions for Guaranteeing Higher Normal Forms in Relational Databases*, he has complied with the requirements, and he is sure of his 5NF declaration. He asserts that all the keys are "simple". He expects quick approval. If not, please state why, any errors that it may have, etc. Again, minimal discussion.
>
> His conclusion is correct, but he is basing it on wrong assumptions. Not all his candidate keys are simple.
But note that that paper is one of those that I consider an attack on science. Date are Fagin are eating pig poop, straight from the backside of a sow. Therefore anyone who relies on it, categorises himself as a monkey, setting you up, to pick your pocket. Gypsies, tramps, thieves. It is simply not possible to "guarantee" 5NF when he has broken 3NF.
Basically this paper elevates Record Filing systems, much like their other papers. ETNF is an assault on science as well as causing blindness.
- Aside --
Let's stop this difference in terminology. You theoreticians cannot be serving an industry if you have different meanings to established definitions, you are serving something else. Now, since 1985, and as a standard since 1993, we do not have "candidate keys" in IDEF1X data models. In some early stage of modelling, when keys are being evaluated (but not decided), sure, they are Candidates. Once the election takes place, and one of those Candidates are chosen as Primary. After that, the candidates are no longer candidates, because the election is over, they are known as Alternate Keys.
You said you could /read/ IDEF1X. Alternate Keys are identified with [AK].
- End Aside --
> > 3. Is this acceptable to you, as a human being, as a scientific logical person, as a set of relational tables ? If not, why not, please name the problems, if any.
>
> To me it is. But this might also have been the case if it was not in 5NF. Normalization theory does not tell you in which normal form you should be, just whether you are or not and what some of the consequences of that might be.
I don't see how you would accept a model that fails your (not science's) 5NF, as normalised, but I won't argue, I will let that one pass.
To me it is completely unacceptable because it fails Normalisation and it does not comply with (fails) the Relational Model.
The real value in this thread is, how the hell you guys, allegedly theoreticians in the field of Relational Databases, pass off something as "normalised", when it isn't; how you pass off something as "relational" when it isn't. It stands as evidence that you guys are grossly ignorant of both Normalisation and the Relational Model.
The bottom line is, you pass off the unnormalised garbage in Record Filing Systems (anti-relation), as "normalised" and "relational". Through gross ignorance of the science that is established in our field. You justify and validate that 95% of the market that implements RFS, thinking it to be "relational". Due to the books that your mentors have written and marketed, which the implementers read as well.
Of course, I am not singling you out, Jan, you are the only one with enough courage to come out and exercise your theories with someone in the field. The others are too scared to leave the security of their isolation from the field that they allege to be serving, and to maintain their private definitions, and their convulsions (convoluted "logic") that justify them.
Ok, back to business. I informed the developer as to what was wrong, what was unacceptable with his model, and sent him off. Gratefully, it took far less time to communicate that to him, than it does to communicate that to you guys. He came back today, with his corrected version.
He still declares 5NF for sure, and Relational to the best of his understanding (which is based on books by the same authors that you read).
http://www.softwaregems.com.au/Documents/Article/Normalisation/Relational%20Database%20101%20B.pdf
My corrections to his /previous/ model [A] are on page 2.
Please answer the questions in any order:
Cheers
Derek
Received on Thu Feb 05 2015 - 04:15:48 CET