Re: Fails Relational, Fails Third Normal Form
Date: Sun, 8 Feb 2015 16:44:33 -0800 (PST)
Message-ID: <7e70f829-7de1-4a6f-aa43-6ee3b8ce6a53_at_googlegroups.com>
Nicola
> On Monday, 9 February 2015 08:47:10 UTC+11, Nicola wrote:
> In article <7e4c6cec-6534-4187-bc75-2fe09ea5cdb1_at_googlegroups.com>,
> Derek Asirvadem <derek.asirvadem_at_gmail.com> wrote:
>
> > 1. Is the strike-out and substitution correct ? Otherwise the facts given
> > are incoherent.
>
> Usually, students take an exam for a course, not for a chapter,
Really ? It is quite different here, we have at least one exam per semester. (Chapter is a contrivance for the example, but I knew that.) No matter.
> so
> "course" intuitively make more sense. Let me see if I can spot some
> contradiction. I will go through the requirements (not in the same
> order) and try to provide an example of sets of values compatible with
> each requirement and the previous ones.
Whoa! I just needed a quick answer to a tiny question, re the contradiction in the requirement. I thought you understood (from your posts and mine) that I was going to try and find the Keys the "hard" way, without FDs. Sorry if I wasn't clear. Thanks for taking the time, but I won't look at the details, certainly not at the non-FDs.
< big snip of long and winding, "computationally expensive" road, thanks anyway >
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
Give me five ...
... I am back.
Let's set the context for this, so as to avoid confusion. Here is the sequence:
> > 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?
Yes.
> > 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) ....
And following that, you have given me the missing requirements ...
So now I am going to try the "hard" way, to determine the Keys without using your non-FDs or his non-FDs.
The first thing is to translate all those text strings re the facts about the data (Köhler's section 5, first two paras only), into Relational. The easiest and most comprehensive way to do that is to erect a model. And then check that with the user (you !), "have I got the facts about the data right ?". At this stage, it is minus the Keys, because there is no point in /formally/ determining the keys if the facts re the data are incorrect.
(No keys were given in the paper, as usual for theoreticians. Being Relational on my side, as a natural result of modelling the stated facts, some keys are /informally/ determined, in order to support the facts. You might say, the obvious Keys, or the demanded Keys. But that is a natural product of the exercise, and it remains informal, until the formal exercise commences.)
After I get the facts verified, I will determine the Keys the "hard" way, without the "computationally expensive" method from the non-relational side, using the formal method on the Relational side.
And check that with you. If I fail, you can give me the computationally expensive method from the non-relational side.
Is that alright with you ?
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.
Cheers
Derek
Received on Mon Feb 09 2015 - 01:44:33 CET