Nicola's Data Model [A] of Non-relational DNF Data
Date: Tue, 10 Feb 2015 15:09:28 -0800 (PST)
Message-ID: <f8d499f1-7152-457c-baf7-034c335de656_at_googlegroups.com>
Nicola
> On Wednesday, 11 February 2015 09:39:50 UTC+11, Derek Asirvadem wrote:
>
> > On Tuesday, 10 February 2015 02:38:51 UTC+11, Nicola wrote:
>
> > Good Lord, I shouldn't have changed sex!
>
> Until then, posts like that one, which demonstrate both your eagerness to learn, and your argumentative sub-human impediments to learning, will go un-answered, your learning will not progress.
But the Grace of God gives me Charity, so I will give you a reminder of what you have lost.
> On Tuesday, 10 February 2015 02:34:50 UTC+11, Nicola wrote:
> In article <694b8c03-9c5e-4dc1-a4f5-c2b14fece057_at_googlegroups.com>,
> Derek Asirvadem <derek.asirvadem_at_gmail.com> wrote:
What, no acknowledgement "Hey Derek, you did a good job of finding the Keys the "hard" way, without employing our obsessive-compulsive non-FDs, and the long and winding road that takes forty times as long" ?
What, no acknowledgement that Relationalising the data eliminates the theoretical paper; that the paper is NOT Relational, all such allegations are false; that there is no problem as proposed if the data was Relational ?
Ok, we ignore the purpose of the exercise, the unexpected finding, we won't even mention any of the big issues, or the data model, we zero in to the tiny ones.
> > > > - No redundancies;
> > >
> > > In StudentExamination, the fact that, say, Room 101 will host the
> > > Networks exam on 3/10, 1pm, is repeated for each student taking that
> > > exam. This is a form of redundancy.
> >
> > 1. Are you sure you know what Redundancy means, whose "definition" are you
> > using ?
> > (If you are using Date' or Darwen', I know that they are wrong, because they
> > don't know what a Relational Database is, and they think migrated keys are
> > "redundancies". Other pig poop eaters may well think that same.)
>
> No, foreign keys have nothing to do with it. Someone (Tegiri, I think?)
> has said it already in some other thread: the accepted definition of
> redundancy is Shannon's. The relationship between that notion and
> relational databases has been investigated thoroughly.
Imbecile.
The data model is an implementation, which is limited to that which is available for implementations. It is not a futuristic picture of what a database could be, in the future, when the theoreticians have implemented their theory into tools. You are applying something that is valid in one context, to a context in which it does not apply, it cannot apply, at least for another forty five years.
Why don't you apply the theory of flower arrangement to the data model ?
> > 1.a That there are no "forms" of redundancy. Either you have it, or you
> > don't ?
>
> True. Then, read: "This is redundancy".
Now that you have corrected your words, yes, I can read them.
It remains an unproven, unevidenced, claim. From a person who has proved that they have half an understanding of databases, and an incorrect understanding that hinders himself, unable to get past the obstacle, because he insists that when he is wrong, he is right. Unteachable. If you want to learn, you have to be open to the notion that what you think is wrong, is right. Hence ask a question.
> > 6. And why exactly is ( Course, DateTime, Room ) included in the "forms of
> > redundancy" list, and ( Student ) excluded ?
>
> Note that if you show me *only* this:
>
> StudentExamination
> Student Course DateTime Room
> --------------------------------
> Nicola Networks 3/10,1pm 101
> Ada ? 3/10,1pm 101
>
> given the requirements, I can infer the only possible value for ?. This
> is not possible for Student.
Imbecile.
This is not a Sudoku puzzle to be solved. Such inferences (which are valid elsewhere) are invalid here. This is a database, and you are looking at occurrences of data. You cannot even distinguish the difference between Keys and non-key data.
Whatever inferences you draw from the above, are not actually from the same table, they are Atomic facts in another table CourseExamination.
In an RDB, facts are Atomic. Atomic means, it cannot be broken up. The fact that a CourseExamination will occur is established by treating ( DateTime, Room, Course ) as an Atom. The combination of any TWO of those elements is not a fact (that concerns the requirement), they are sub-atomic elements, they are irrelevant.
Thus, when that Atomic fact CourseExamination is carried, migrated, to StudentExamination, for the purpose ensuring that all \student examinations\ occur within the limits of the \course examinations\ that have been scheduled, that Atomic fact is carried, whole, not in bits and pieces.
> > 6.a Note that Student is "repeated" (by your wording) for every Course they
> > take.
>
> You can't make the same kind of inference in that case.
Aw shucks, the Sudoku rule doesn't work.
Good, it doesn't work in [6] as well.
If your argument for [6], breaks when you apply it to [6.a], it breaks when you apply it to [6]. The inference is the same. The inference is invalid in both cases.
There, the right side of your mouth proved that the left side of your mouth is false. You did it all on your own. Give the girl, I mean boy, a yellow star.
> > 7. And what exactly, would you do, to fix this "form of redundancy" that you
> > claim ?
>
> I wouldn't fix it. Your model is good enough. My point was just that it
> is not true that it has "no redundancy".
Imbecile.
It is not false either.
Just because an imbecile can't see that "no redundancy" is true, doesn't make it "not true". In the world of applied science, we need a fact, some evidence to support your insipid claim, otherwise the claim is unevidenced bleating, telling us about the level of your capability, it does not tell us anything (one way or the other) about the data model.
Just look at Erwin. Sniping from under a manhole cover. He can't provide any evidence, for any of his one-line remarks, and he disappears back into the depths of his putrid filth. His remarks cannot be proved false, because he gave no evidence that can be used to prove it true. You are doing the same thing (I am not saying that you live in the sewers like Erwin has been doing, for decades). You are making imbecilic, un-scientific comments, without evidence. Sniping. So put up the evidence, or shut up.
This neither-true-nor-false statement is an ancient trick that is used to demean something, without addressing it squarely. It is a form of attack that is used by the mentally crippled, God's Cursed Ones, who cannot attack something openly and honestly, as scientists do. Pig poop eaters.
Choose your friends carefully.
> Anyway, I'll show an alternative design, which I hope you will accept as
> relational, normalized, etc... Note that I am not claiming that it is
> better than (or equivalent to) yours in any sense nor that it is the
> only possible alternative. Sorry for using just textual form:
>
> Session(DateTime, Course)
> Key: {DateTime, Course}
> FK: {DateTime} refers to Time
> FK: {Course} refers to Course
>
> ExamLocation(DateTime, Room, Course)
> Key: {DateTime, Room}
> FK: {DateTime, Course} refers to Session
> FK: {Room} refers to Room
>
> ExamAppointment(Student, Course, DateTime)
> Keys: {Course, Student}, {Student, DateTime}
> FK: {Course, Student} refers to StudentEnrolment
> FK: {DateTime, Course} refers to Session
>
> StudentExamination(Student, DateTime, Room)
> Key: {Student, DateTime}
> FK: {DateTime, Room} refers to ExamLocation
> FK: {Student, DateTime} refers to ExamAppointment
>
> ExaminationChapter(Student, Course, Chapter)
> Key: {Student, Course, Chapter}
> FK: {Student, Course} refers to StudentEnrolment
>
> This is a sample instance (I omit instances of Course, Student, etc...
> for simplicity):
A more honest remark might be, that you refer to those tables in my model, which you are using as reference. They are not "omitted". But then, you live in an universe that is fragmented.
> Session
> DateTime Course
> ---------------
> 10/6 Networks
> 7/7 Networks
> 10/6 Security
> 1/7 Security
>
> ExamLocation
> DateTime Room Course
> --------------------
> 10/6 101 Networks
> 10/6 102 Networks
> 7/7 101 Networks
>
> ExamAppointment
> Student Course DateTime
> -----------------------
> Nicola Networks 10/6
> Nicola Security 1/7
>
> StudentExamination
> Student DateTime Room
> ----------------------
> Nicola 10/6 102
>
> ExaminationChapter
> Student Course Chapter
> ----------------------
> Nicola Analysis 1
> Nicola Analysis 2
That (data content, not the table descriptions) is unnecessary. You guys have no idea that you are obsessed with data content, that that takes your focus off the real work: understanding the data; classifying it by type, meaning; determining facts; determining dependencies of said facts; determining Keys; etc; etc. Instead you play with puzzles concerning data content, using non-FDs.
> Two remarks only:
>
> 1. I have deliberately associated ExaminationChapter to StudentEnrolment
> to make the choice of chapters independent of the exams (imagining that
> students are told which chapters they have to study during the course).
> This is totally arbitrary of course: you could make {Student,Course} a
> foreign key referring to ExamAppointment, for example. Or do something
> else.
>
> 2. StudentExamination is needed because in general an exam may take
> place in more than one room, and we want to know where each student must
> go on the day of the exam.
- Most of that is your mental masturbation, and I must say, you are using a good lubricant.
The requirement is the requirement. If you build sand castles and imagine twenty virgins waiting inside, behind your eyelids, over and above the requirement, we don't need to hear about them. Just get the requirement, and get it right. After that, feel free to extend it.
There is evidence here, and earlier when you gave me incorrect info, that you cannot correctly discern the requirement from Köhler's two paras. There is no point in going on about could-be's and might-be's and bumble bees.
You might want to ask a question:
Gee, Derek, how did you manage to discern all that, all the rules that you have implemented in the data model, from those two lousy paras ?
2. Now this is hilarious. You have several redundancies in that, real redundancies, not unproven claims, but you don't see it. Side-splitting. I have to go to the toilet.
> Note that I am not claiming that it is
> better than (or equivalent to) yours in any sense
Ok, you are right. It has no purpose. But you post it anyway. SO there must be some hidden purpose.
> which I hope you will accept as
> relational, normalized,
Aha, the hidden purpose is revealed.
So what you are really saying is "Derek, please help me. Is this a correct progression, a valid start, in order get to the complete model ?"
Since you are asking, since God's Grace is without limit, I will give you the service you indirectly request.
Requested Service
Acknowledgement
> What, no acknowledgement "Hey Derek, you did a good job of finding the Keys the "hard" way, without employing our obsessive-compulsive non-FDs, and the long and winding road that takes forty times as long" ?
The very act of attempting a data model, stands as:
- an acknowledgement of that fact, and
- since you are attempting some form of my exercise, that it is of value to you.
> What, no acknowledgement that Relationalising the data eliminates the theoretical paper; that the paper is NOT Relational, all such allegations are false; that there is no problem as proposed if the data was Relational ?
The very act of attempting a data model, Relationalising Köhler's data heap, stands as: - an acknowledgement of each of those facts, and - since you are attempting some form of my exercise, that it is of value to you.
Congratulations, your understanding of the Relational Model exceeds Köhler !
Scope
Your proposed text strings are half-right, half requirement-exceeded. This is limited to the half that is right, it excludes the requirement-exceeded half, which remain invalid.
I give summaries, and explicit direction, but I can't be bothered to enumerate the errors. An enumeration is not necessary for you to progress, to learn.
Re Requirement
- it fails to meet the requirement
- it fails to make the obvious constraints ___ let alone all the constraints in the requirement _____ (let alone all the constraints that I implemented, which is beyond the requirement).
Normalisation/Modelling
- It is naïve (especially when you consider that you are looking at a complete data model).
> So what you are really saying is "Derek, please help me. Is this a correct progression, a valid start, in order get to the complete model ?"
- Yes it is. It is an early stage, not yet intermediate level, of the modelling process. You are have established some facts, correctly, and those facts are: ___ a. NOT yet validated, verified, tested (hence less-than-intermediate) ___ b. NOT Normalised (ditto)
- if and when you progress [a], and complete the modelling process, those facts will progress to being Atomic, verified, xor eliminated
- if and when you progress [a], and complete the modelling process, those verified Atomic facts will progress to being Normalised
- ie. you are used to working with binary relations, you have not graduated to ternary relations
- when that magical moment takes place, one ternary relation will replace two binary relations (normalisation), one higher-level Atomic fact states two or three other facts, loss-less-ly, and thus the two or three other facts can be Normalised OUT of the model. ___ Note I said ternary relation, that means three keys, not three columns (three keys may well be ten columns). In the case of my StudentExamination, two keys (one three columns and the other two columns), sit in four columns
- you do not yet understand, that in an RDB, each column does way more than one task ___ eg. my StudentExamination.Course does four separate and discrete tasks
- it is weird (normal for a stunted dwarf, weird for a human) that you can infer some logic, and make *invalid* inferences in the right place, or *valid* inferences in the wrong place, but you cannot use those same powers of logic and inference and identify valid inferences in the right place. Truly amazing.
- you have great gaping holes in your proposition, in the sense that you have lost integrity (or you are clueless about what integrity can be had in a Relational Database) that I have in the data model.
- Ie. a number to FK relationships are missing
- Ie. the ability to read (let alone implement) compound keys, and their meaning is only partial, incomplete ___ eg. your StudentExamination does not ensure that the Course is valid (that it is the Course for which the StudentAppointment is booked, or that it is a Course that the Student is actually taking) ___ eg. your ExamLocation and Session can be normalised into a single Atomic fact, loss-less-ly (note my comments re ternary facts, above) ___ eg. your StudentExamination and ExaminationAppointment can be normalised into a single Atomic fact, loss-less-ly
- again, the mistakes and missing bits are too many to enumerate.
- There are four gross errors re Normalisation which I can't be bothered to enumerate. If you had any of the tools that we have been using since 1985, you would have a visual model (engages the right brain, 96% of the power), and those errors are plainly visible. But you are still, in 2015, using text strings (engaging 4% of the power) that we stopped using in 1985, so those errors will be much more difficult to detect, to 'see'.
But for God's Graces, which are boundless. Have a look at this: http://www.softwaregems.com.au/Documents/Article/Normalisation/DNF%20Nicola%20A.pdf
Summary
It (your suggested tables) is incomplete, normalised in the sense of up-to-this-point, with issues noted, but unnormalised overall because there are many resolved and duplicated facts. It is incomplete. As you can see (if you want you can infer backwards from my tables), the normalised model has far fewer tables; no duplication; no redundancies.
In terms of a level of Normalisation, or progress of the model, if Köhler's is zero, and my finished model is a ten, yours is a four. Well past the beginner stage, well past the RFS mentality of your colleagues, but not quite intermediate yet. Some RFS mentality remains, and you are bogged down with irrelevant non-FDs.
Relational
- On the face of it, it is Relational, but because it is incomplete (detailed baove), the declaration cannot be made. Eg. entry-level is broken, there are masses of duplication.
- It breaks the RM for second-level items, but I can't be bothered to enumerate them, fix the entry-level first.
- It is not Relational along the same lines as for Normalisation above (not counting [a][b] of course): that part that is, is, and the part that is incomplete, is not.
Cause
Well to someone who teaches this, the cause is obvious. Separate to the fact that you have little understanding of Relational Keys and their Integrity (which you are trying to learn, big tick); separate to the causes I have already commented about here and elsewhere, the pig poop eating teachers, and their poisonous books. You are focussing on the non-FDS, it is an obsession with you guys.
Now Köhler did the same thing, and I wiped his problem out. So you really should know that that means all the logic he used to construct his case is false. But you use it anyway, and you take his non-FDS, knowing them to be devoid of value (after my floor-wiping), knowing them to be erroneous, and you use them. To model the data. 42 what-ifs. You will spend your life contorting the model with what-if non-FDs, twenty to thirty models. But it is fun, an obsession.
Forget all that nonsense, all that mental masturbation, forget your obsession, and focus on understanding the data. Yes, you do need progressions, but with this amount of data, just three or four. Don't worry about the fact that I did it in one step, that I can 'see' the data more clearly.
You can also learn from examining my model, and comparing it with yours: the entrie Köhler problem is solved with Relational Keys, only Keys, and nothing but Keys, so help me Codd. He does not mention keys (except in the Terminology section), he, like you guys do not understand the RM and that Relational Keys are central. For you, although you are starting to see the light, you are trying to use the minimal set of columns in each Key, eg. a two-column key that does one thing, where I use a four-column Key that does ten things.
End Requested Service
> > > > no Update Anomalies
> > >
> > > Yes, that may well be the case, with the proper inter-relational
> > > constraints in place.
> >
> > I am saying that that is the case with the constraints that are in the model.
>
> I was not denying that.
Imbecile.
So the claim is false. You are not denying my declaration, but you are saying, without any proof, that there could be snow in the Seychelles at this time of year.
> Just I hadn't checked carefully enough as to be
> sure.
If you want to be treated as a credible person, you have to do your homework, first, before making unfounded claims, second, and be able to back up your claims when called for, third.
Otherwise, you prove, by your actions, that you are not credible. The devil's children work backwards. Scientists work forwards.
> Indeed, that seems the case.
Well, then, shut up. If you were a gentleman, you would retract you imbecilic claim.
"Ok, Derek, you are right, there are no redundancies" is too much to expect from a dishonest person, a snake, they have to say "Until such time as I can prove a redundancy exists, I can't say for sure that there isn't one". They miss the fact that they have just proved themselves to be a non-scientist, a nonsense-ist. Gobbledegook, like a turkey. Sub-human.
Put up or shut up.
I won't hold my breath.
> > > For example, the redundancy mentioned above does
> > > not cause update anomalies by virtue of a referential integrity
> > > constraint.
> >
> > Gibberish.
> >
> > Name the constraint you are talking about.
>
> I mean, you cannot update this:
Oh God, another question posed as a declaration.
StudentExamination
> Student Course DateTime Room
> --------------------------------
> Nicola Networks 3/10,1pm 101
> Ada Networks 3/10,1pm 101
>
> to this:
>
> Student Course DateTime Room
> --------------------------------
> Nicola Networks 3/10,1pm 101
> Ada Security 3/10,1pm 101
>
> which would create an inconsistency, because of the foreign key on
> {Course, DateTime, Room}.
Imbecile.
You can't "create" an inconsistency, precisely because of the very foreign key constraint that you refer to. You are two things in one sentence, each of which contradicts the other.
That imbecility, that "creation", that "inconsistency", is prevented, by the constraint.
So, the constraint is good, and the redundancy/update anomaly does not exist.
> If you remove the foreign key, no constraint
> is violated.
Imbecile.
That is akin to saying, as idiotic as, if you remove the condom, then no prophylactic will be violated if the woman falls pregnant. The express purpose of the condom is to prevent the pregnancy, to play hide-the-sausage with no consequences.
If you remove that foreign key, you would introduce SEVERAL inconsistencies (in an RDB, each Thing performs more than one Task). It is there for a purpose, it is not an accident. If you remove it, you ALLOW StudentExaminations for ( DateTime, Room, Course ) that are NOT in CourseExamination, which is a separate Atomic fact, which cannot be split up.
Part I Higher Order Answer
- There is no fact CourseExamination( Security 3/10,1pm 101 ).
- In fact, it contradicts a known fact CourseExamination( Networks 3/10,1pm 101 ).
- And we prevent more than one examination happening in the same room at the same time (as per requirements; via CourseExamination.AK, as per Notes).
Therefore your proposed change is invalid, it is prevented. By constraints alone.
> I mean, you cannot update this:
Yes, by design, imbecile, not by accident.
Now if your brain operated at human capacity, you would understand that, == AND == that that is all that needs to be understood, == AND == you will go away and ponder the great things that RDBs can do, that the RFS cannot do.
Such as, here is an example of the higher level of Integrity that RDBs have, that RFSs do not have. Such as, here is an example of how DKNF is achieved (not the deranged Fagin definition, which I have exceeded, but the Codd intent).
But there is a fair amount of evidence that your teachers have ravaged your brain, so you cannot operate at human levels, you need the explanation that sub-humans need ...
Part II Lower Order Answer
Second, you are treating StudentExamination.Course as non-key data. You are limited to 'seeing' the RDB through the myopic lens of RFS. Take your time, everyone who has been liberated from their cage, needs time to learn how to run. But it is stupid to refuse to run, or learn how to run, once you have been liberated.
In the RFS, in each record, you have one non-key record ID, and all the fields, are non-key data, that you can change. (And yes, there you can make your "inferences", there they are not idiotic).
In the RDB, which is made up of Keys, you have many columns which contain Keys or parts of a Key, as well as migrated keys, and all the Keys are Atomic. Plus columns of non-key data, in each table.
Sure, you can walk up to the RDB and change non-key data, some attribute in some row. But you can't walk up to the RDB and change Keys. Why ? Because the *structure* of any DB is based on the relationships, and in an RDB those are the Keys (in an RFS those are non-key IDs). Because each Key is a fact, that other tables depend upon, or are dependent upon (in the case of StudentExamination). Thus you can't change the Keys that are migrated to child tables, because you are in fact trying to change a fact, that is established higher up in the hierarchy, you are not trying to "change data", you are trying to change Keys, at a level lower than the Atomic fact that the Key represents.
If you understood that, then you would realise, the change you are attempting is invalid in the location that you are attempting. If you want to change the fact of Ada's StudentExamination, you can't change it there. Because it is not an isolated fact with no relationships. It is a fact,
a. based on an assumed parent fact, that there is a CourseExamination in ( Security | 3/10,1pm | 101 ), which had better exist first, which can't because it is prevented
== AND ==
b. based on an assumed parent fact, that there is a StudentEnrolment ( Ada | Security ), which had better exist first
c. So it is naïve, the kind of thing we have to explain to office juniors, to attempt to change either of those higher-level facts[a][b], in StudentExamination which is a lower-level that depends on the higher level.
d. The method is:
___ Delete the fact in StudentExamination ( Ada | Networks ). Notice, only the PK is required, but you are actually addressing the fact of ( Ada | Networks | 3/10,1pm | 101). ___ Add the fact in CourseExamination ( Networks | DateTime_X | Room_Y ), which cannot be ( 3/10,1pm | 101 ) because that slot is already taken by ( Networks ) _____ which may well cause changes further upstream, such as adding a Room ( Room_Y ) or DateTime ( DateTime_X ) ___ Add the fact in StudentEnrolment ( Ada | Security ), because it does not exist yet _____ which may well cause changes further upstream, Add Student ( Ada ) ___ Now add the fact StudentExamination( Ada | Security | DateTime_X | Room_Y ) _____ which due to the previous steps, would now be valid, whereas StudentExamination( Ada | Security | 3/10,1pm | 101 ), is, was, and remains, invalid.
Imbecile.
End I & II
For the next time, keep your idiotic claims to yourself, and choose one of the two available options, explicitly:
Two choices are open to you:
- Remain in your current sex, and ask a question.
- Ask for the courtesy, the service of education, to be extended to you.
Cheers
Derek
Received on Wed Feb 11 2015 - 00:09:28 CET