"Hard" Key Determination Method is Easy. DNF Paper is Done..
Date: Sun, 8 Feb 2015 22:54:38 -0800 (PST)
Message-ID: <bef08005-8a74-4b97-8fce-652022af0e0c_at_googlegroups.com>
Guys and Dolls
> On Monday, 9 February 2015 11:44:36 UTC+11, Derek Asirvadem wrote:
>
> In his paper, I found that this:
> > > Every student can get examined about multiple chapters
> contradicted with this:
> > > a student gets examined for a course only once
>
> Which, thanks to your additional info, I now understand to be:
> - one exam per course per student
> - multiple courses per student, therefore multiple exams
> - therefore multiple chapters.
>
> The poor guy expresses himself backwards ! Ok, so it wasn't a contradiction, it was missing requirements. "multiple chapters" implies:
> - multiple courses
> - one exam per course
> - one chapter per exam
> Could you please look at this page and quickly see if I have gotten the facts (Köhler's section 5, first two paras only) right is the case.
> http://www.softwaregems.com.au/Documents/Article/Normalisation/DNF%20Data%20Model%20A.pdf
>
> I don't want you to spend any significant amount of time typing, etc. If you find issues, please throw it back at me, with a few words.
While I was waiting, I looked at Köhler's paper a little bit further, squeezing my eyes shut tight every time I saw a non-FD. I found what appears to be an instance of the UR on page 6. That seems to show that the above correction was incorrect, the version three correction is: The poor guy expresses himself backwards ! Ok, so it wasn't a contradiction, it was missing requirements. "multiple chapters" implies:
- multiple courses - one exam per course - multiple chapters per exam, in one sitting
So I changed the model to suit the revised revised requirement. Thirty seconds.
That is one (just one) of the great values of using Keys: they are reliable, and when the model changes, because the Keys are solid, the changes are easy as. Stated another way, reliable Keys are the pegs that you can hang something on, with confidence, it doesn't break off or disappear like an ID field in a Record Filing System. As you know, I am finding a lot of things that should be hanged, so I need as many good keys as I can get.
Went back to waiting for the phone to ring.
So I thought, well, that is the third iteration, the facts are progressing in terms of reliability, I might as well check the Keys (that had been informally derived through the simple act of placing the data, as described by the facts, two paras) are good, and the predicates hold.
I read them forwards, backwards, and sideways.
The Keys are good
There is no work, no change to make, to /formally/ determine the Keys. The simple act of placing the data in a Relational context exposed the keys, naturally, and now those Keys hold. Yes, yes, I use real FDs to verify the Keys. Minutes, not days.
So I proceeded to check the predicates. I read them backwards, sideways, and forwards, in honour of Köhler.
The Predicates hold
> > Do you have an example of such ?
>
> Do you mean, an example in which finding the keys directly is harder
> that finding FDs first and deriving the keys from them? Well, it depends
> on how clever you are at "seeing" keys, which in turn depends on how
> much experience you have. For instance (from H. Koehler):
Example in DNF Paper.
Done.
"Hard" Key Determination is Easy.
And the "easy" method is ... well, we are still waiting.
So I rushed to type up a status post, with the good news, that I had accomplished the "hard" task of determining Keys directly from the data, without using the long and winding, computation-heavy, non-key, non-FD method. On data that I had never seen before. It is not that I was against learning the easy method, it is that one thing I learned during my decades of endurance horse riding, never ever use new gear on an official race, always use the tried-and-tested, worn-in gear. Splitting the sking where the sun doesn't shine, due to a seam in a new garment, when you are sixty kilometres from the car is not something you forget easily.
No doubt you are doing the same.
But I thought, I might as well identify the next step, from the paper, and put that in the same post. You good people will never guess what I found out !!!
The problem that Köhler declares, the premise of the paper, DISAPPEARED. There is no problem for me to test the proposed solution ON.
- Normalisation is complete: there is simply no decomposition; reduction to be had (or, stated otherwise, the one critical table cannot be decomposed loss-less-ly. - No redundancies; no Update Anomalies - All Köhler's reports can be produced via simple natural joins - storage (if it ever was a concern) is up no concern, because the predicate cannot be decomposed further - no multiple decompositions to choose from - I thought I should check carefully, so I found his (what seems to be) universal relation and I worked backwards. All good. I added the sample data in the form that it would be, if he had used the Relational Model.
The simple act, of placing the data in the Relational context, translating his text into a Relational model, according to his facts (identifying facts; independent facts; dependent facts, and drawing a picture with dependency lines and squiggles) eliminated the problem that Köhler proposed to solve. The problem simply does not exist in the Relational context.
Relationalisation Eliminates Theory
Now, that is not to say, the paper is useless or that it has no value. Not at all. Outside the Relational context, such as in Record Filing systems, with no keys on the data, that you people are so glued to, of course is has value.
I suppose all my databases are suddenly "satisfying DNF". Through no fault or actiona of my own. I can't keep upw ith the changes. Real 3NF = BCNF+4NF+5NF+ETNF+NRNF+DKNF+DNF ...
And I am not suggesting that he erected a Straw Man argument either. He seems genuine, other than the fact that the propoaal is null in the space he declares it to be a problem, solved, he has done what I perceive (as an unqualified, informal reviewer) to be a good job. It is just that he says this problem exists in Relational databases, and this proposal is going to solve it. He just has no clue what "Relational" means, that the problem simply does not exist in the "Relational" that he keeps talking about. If he changes all occs of "Relational" to "Record Filing System", he will be fine.
He has no idea that Keys are important, let alone how to use keys Relationally. He is playing the same pre-1970's, "non-FD can determine a key" tune you people play. Using that method, the meaning of each column, and the meaning of the constructed key is LOST. Thus the facts too, have no meaning.
A = 1
B = 1
Therefore A = B
Therefore anywhere you use A, you can substitute it with B
The meaning in life cannot be expressed in 1's and 2's, in a's and b's. When you abstract it out to that level, you have totally lost its meaning. And you make massive mistakes.
Horse = 1
Dolphin = 1
Therefore Dolphin = Horse
Horse = gallop
Dolphin = dive
Therefore Horse = dive
Dolphin = galllop
Hysterical.
That is how you end up accepting a model as "5NF", one I have rejected as breaking 3NF.
Accepting a non-relational model as "relational" is due to a different reason, ignorance of what "Relational" means, the set of integrated rules.
One page summary and revised data model: http://www.softwaregems.com.au/Documents/Article/Normalisation/DNF%20Data%20Model%20B.pdf
Back to work.
Cheers
Derek
Received on Mon Feb 09 2015 - 07:54:38 CET