State of Normalisation /Theory/ Proved

Dear people

Ok, for context we Have:

• 1 --------
  > On Monday, 9 February 2015 10:59:35 UTC+11, James K. Lowden wrote:
  

In which James appeared to address the inability of the theoreticians in Normalising the given 38 attributes and 9 suggested tables (two of which are complete, so it is real 38 and 7), inability to produce anything of any kind.

And my reply:

• 2 --------

> On Tue, 10 Feb 2015 23:06:25 -0800 (PST) Derek Asirvadem <derek.a..._at_gmail.com> wrote:

In which I answered James' points, and provided more detail re the 38 attributes. The floor has been open since then. I have received no further questions. It appears you need no further information.

• 3 -------- Further, taking up Nicola's challenge, I Normalised a previously unknown set of data that was alleged to be "Hard", one that justified a theoretical paper, and solved the entire problem, using Codd's 3NF/FDs. In so doing, I proved that: *** "Hard" Key Determination Method is Easy. DNF Paper is Done. *** and *** Relationalisation Eliminates Theory ***

> On Monday, 9 February 2015 17:54:40 UTC+11, Derek Asirvadem wrote:

• 4 -------- Finally, I provided full and complete info (as per points raised by James), and set the context for the next iteration. You were free to use either the normal Key Determination method using Codd's 3NF/FD, or your theoretical non-FD-fragments plus the 17 NF fragments (that in total come up to a fraction of Codd's 3Nf/FD).

Quoted here in full:

> On Wednesday, 11 February 2015 18:08:19 UTC+11, Derek Asirvadem wrote:
> Dear people
>
> > On Saturday, 7 February 2015 20:10:43 UTC+11, Derek Asirvadem wrote:
> >
> > So it appears that:
> > - all of you accept the declaration that the data model is "5NF"
> > - a few of you are uncomfortable with it, but not uncomfortable enough to reject it.
> > ___ And that discomfort is around the smell of the keys, but nothing specific has been stated
> > ___ If nothing is stated, that means you accept it as such
> > - nothing has been stated re the 3rd claim, that it is Relational. That means you accept it as such.
> >
> > I will give it a few more days, perhaps to ponder the keys.
>
> The days are up.
>
> The Address [B] proposition is rejected. I will cut-paste the text that I gave the developer. The main directive was to determine the keys:
>
> >>>>
> The issues are the same as the last time. This is a Record Filing System. 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
> ___* Yes, you did add Keys, but they are invalid, therefore still no Keys
>
> 2 The RM demands unique rows (data)
> ___* A surrogate does not provide row (data) uniqueness, only Keys supply row uniqueness
>
> Re Normalisation, (if we consider that outside the Relational Model):
>
> 3 It breaks Third Normal Form, because in each case, there is no Key for the data to be Functionally Dependent upon (it is dependent, yes, but on a pork sausage, outside the data, not on a Key).
>
> This RFS is nowhere near ready for Normalisation, let alone Relational Normalisation:
> <<<<
>
> Previous bullet points in annotation in Address [A] have been numbered [a] to [d].
>
> >>>>
> e Keys. You did not action my points from your first attempt. I will have to number them for you. Items [c][d] relate to Keys and Identifiers. Read my IDEF1X Intro again.
>
> ___* What is the Identifier for a State ? You have StateCode, which is the 2-char ISO code. Really ? You can walk up to the database, ask for a CountyCode, and you will get one row ? Really ? There are thousands of States. Hint: we have the [N]orthern [T]erritory, Canada has the [N]orthwest [T]erritories.
>
> ___* What is the Identifier for a County ? When the user walks up to the database, with one County is mind, what does he have in mind, how does he Identify "Lee County" ?
>
> ___* County(CountyCode) is unique ? America has 50 States, they have a minimum of 1 County, they start with 001. The moment you attempt to insert the first County for the second State, it will blow you away.
>
> ___* Street(StreetName, StreetTypeCode) is unique ?
> ___ One street of one name+type in the whole Street table ?
> ___ Did you mean Street(SuburdId, StreetName, StreetTypeCode) is unique ?
>
> ___* Do you want two countries named Brazil ? I showed you how to prevent that three years ago, you have forgotten. America has 13 Counties named "Lee County".
>
> ___This applies to all seven tables, every one of them has a gross error on the Key. Talk through each point with Ken. If you come back with Keys that are less than 95% complete, if you fail to follow my directions again, I will burn your books.
> <<<<
>
> =========================================================================
> None of you theoreticians identified any of that
> The non-rejection, with or without specifics, is an acceptance
> =========================================================================
>
> The exercise now, is to determine the correct Keys. Let's see if you can produce them, before the developer can. Use the Address [B] proposal, because there is no change.
> http://www.softwaregems.com.au/Documents/Article/Normalisation/Relational%20Database%20101%20B.pdf
>
> If you want more detail re what I told the developer, visit this. The pages are in RC order. He has not returned with a proposal [C], so the first page is blank (it will be populated when he does):
> http://www.softwaregems.com.au/Documents/Article/Normalisation/Relational%20Database%20101%20C.pdf
>
> Now it has been established, for decades, that humans can determine Keys, directly, by working with the data directly, and by using FDs to validate the Keys (the FD Definition is in the 3NF Definition).
> - That has recently been confirmed yet again, in this thread, when I Relationalised Köhler's DNF data and eliminated his problem, his proposal.
> - It is further confirmed by Nicola, implicitly, because he is following those directions. the developer will be using that method.
>
> In two iterations you have not been able to do that.
>
> However, it has now been exposed (in this thread) that your teachers have taught you to determine keys via non-FDs; to make puzzles; which is great for RFSs, but not for RDBs; to avoid the direct method that is relevant to RDBs. Further, as evidenced in this thread, you people are obsessed with it. Therefore, I invite you to determine the Keys *using whatever method you like*. This is a great opportunity to demonstrate, to confirm, the non-FD method.
>
> ----
>
> Key points from another post, that are worth keeping in mind:
>
> > On Saturday, 7 February 2015 19:09:53 UTC+11, Derek Asirvadem wrote:
> > > On Friday, 6 February 2015 04:07:52 UTC+11, Jan Hidders wrote:
> >
> > d. Keep in mind that the users and developers mean "Alaska" when they use "AL", they do not want to, and should not have to, use "US-AL". Ie. a StateCode is an Atomic item, it would be preposterous if we had to mess with SUBSTR(StateCode, 3, 2).
> >
> > e. Likewise for the CountyCode. It is not CHAR(7) ie. containing CountryCode and StateCode. It is CHAR(3) containing CountyCode, only CountyCode, and nothing but CountyCode, so help me Codd. FIPS is US only, numeric; most countries use a string.
>
> > So what we have to deal with here is, we implementers use the original [3NF & FD] definition and reject the data model as failing 3NF; you use the 42 fragments and accept the same data model as "satisfying 5NF". It is pointless to argue about definitions, especially the established ones; better to examine the difference, and to determine why you people are so crippled.
>
> ----
>
> Please keep my response of today to James in mind. Please ask me as "customer" and "user" any and all questions. I don't know what you do not know, unless you ask. I thought the data in that cluster was pretty much known to most IT people.
>
> Here is more detail, to cover some of the issues that have been touched, what I think James may be getting at.
>
> - All columns must be Atomic (1NF).
>
> - CountryCode is CHAR(2) ISO-3166-1
>
> - StateCode is CHAR(2) ISO-3166-2
>
> - CountyCode is CHAR(3) FIPS numeric for America; char for the rest of the world
>
> - The above three are generally well-known. Eg. the sales people know their ambit by heart (not the numerics!). We do not mess with clarity. All dialogues (windows, frames, whatever) that are used by users have three separate fields for the above (which may be set next to each other when relevant)
>
> - All Name columns are CHAR(32)
>
> - All FullName columns are CHAR(64)
>
> - All ID columns are 32- or 64-bit Integers, depending on the max rows possible.
> ___ He is on notice that he can't have them as he has planned because it is an RFS, that he must use the minimum possible surrogates. But I am not pushing it in this iteration, the Keys are thig for this one.
>
> > It has a type
>
> The type is generally not necessary in an exercise at this level, but having had that pointed out as a limit to assumptions, etc, I have given it.
>
> > domain,
>
> Yes. That is for you to determine, to work out.
>
> > and some relationship (perhaps functional dependency) on other
> > columns.
>
> Yes. That is for you to determine, to work out. Which is infinitely more possible, and much easier, if you determine the Keys first.
>
> > Any statement about keys *must* be based on stated FDs.
>
> Fine, but it does not apply to this task.
>
> And feel free to ignore my statement above, and go that route. The result we want is, desperately now, to have the Keys determined. If you think your way is better, go for it.

I have received no submissions. Twenty two days since the task was initially tabled, fifteen days since the current iteration commenced (with great detail and specific directions as above), and still no submissions.

This is proof that you guys cannot Normalise anything. Not by the normal Method. Not by your high-falutin theoretical method. Not by asking questions and getting them answered.

I was hoping that we could get to say, a set of semi-normalised tables, and we could inspect important issues, such as the difference between Relational databases and Record Filing Systems; why precisely, the former has more Integrity, power, and speed. But no. We didn't even get past square one.

• Thus you have no right, no position, whatsoever, to tell people who can Normalise data, how to Normalise data.
• Thus you have no right, no position, whatsoever, to lift your nose, to feel superior in any way, to people who can Normalise, how to Normalise.
• Regarding the very subject that you allege to be theoreticians in, you are not merely inferior, you are grossly incompetent, and completely impotent.

  ---

If there is anything in the above that any of you can counter, with specific details, and evidence, I would like to hear it. Caterwauling, squealing, and diminishing comments should be kept to yourselves.

Cheers
Derek Received on Tue Feb 24 2015 - 03:59:44 CET