Introduction
When it came out in 1970, the Relational Model (Codd, not the
pretenders) made a paradigm shift in all areas of perceiving data (examination; data modelling; storage and retrieval; programming).
Codd had an uphill battle against the established academics because
they could not understand it,
The point of this thread.
On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
One reason is Chen's Entity-Relationship models are likely perceived
as easier to grasp for novices than something like IDEF1X. Whether
that is a correct perception, it can be debated. Another reason is
probably just historical, due to the huge influence of Chen's seminal
paper.
It may have been seminal for the academics, let me assure you, it was
not seminal, or even great, for practitioners of the day. It does not
have a semantic base, whereas the /RM/ and IDEF1X does.
For academics. I can grant, up to 1970, the paper was amazing. After
1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct; superseded.
Ok, to rephrase the question, why was that pre-Relational method being
taught after 1983, and why is it still being taught after the advent
of the /RM/, after the /RM/was proved, and after the first genuine SQL platforms came out (1983), and after IDEF1X came out (1983 to
practitioners, 1989 as a product, 1993 as an international standard) ?
after IDEF1X came out [in...] 1993 as an international standard)
In a general setting, ERD is fine for teaching the basics of
modeling
ERDs can be useful as a gentle introduction to such topics.
ERD can be introduced without any background knowledge in databases
For introductory levels, show them IDEF1X/Entity level.
Some may feel IDEF1X is "low-level" (too many details) compared to
ERDs.
False: display only the level of detail necessary for any given
exercise {Entity|Key|Attribute}.
Or some may have criticisms along the lines of this analysis:
https://www.essentialstrategies.com/publications/modeling/idef1x.htm
God help me. Academics just love to sabotage themselves, and then cry
about the fact that they have been sabotaged.
My main complaint with IDEF1X is the treatment of generalization
hierarchies, in particular the lack of a correct way to model a total
inclusive specialization (A must be one of B1, ..., Bn and it may be
any of B1, ..., Bn); the approach I have seen around (e.g., see
Thomas Bruce's book or ERwin's manual) does not cover such case in
a sound way. And the standard never mentions inclusive
specializations, AFAICT.
The problem there is, you do not understand Transactions
There are several threads in this forum that simply do not progress to closure due to the unwillingness of academics to engage, and to learn
about ACID Transactions.
This document may assist somewhat in explanation, noting that the full
and formal explanation lies in ACID Transactions, which has not
progressed in this forum, and indeed in academia, since 1970.
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf
If there is anything in that doc that is not completely understood,
please ask.
(“If you drew all the relationships without dashed lines, you would
still be able to interpret your model in the same way"). I found it
difficult sometimes to convince them that such a distinction is
important.
Only in the early stages of data modelling. Once the Keys are
exposed, and worked, which is the bulk of the modelling exercise, that distinction is exposed, and difference is plain.
When engaging the modelling exercise fully, meaning, in order, FOPC;
the /RM; and IDEF1X as the rendition, and as you confirm “meaning is king”, you may realise: - the solid lines define ownership (Extension,
of the Matter of the parent) - the dashed lines define classification (imposition of the Form of the parent)
Another criticism about IDEF1X is the lack of many-to-many
relationships (except in "Level 1"/"ER" diagrams), which sometimes
makes it awkward to read a relationship, because it is more natural
to skip the intermediate associative entity.
You have the right idea, but not the precise method.
I was thinking more in terms of "department employees", one of whoseIn your model, each teacher must always be assigned to at leastWhy is that constraint “unrealistic” ? In the real world, it is
one course. With
(a) such an (unrealistic) constraint, *and*
a common; even pedestrian, requirement. We have been implementing
such in Relational databases since 1983.
duties may be teaching (but they may not be teaching all the time).
But sure, you may think in terms of employees who teach (a subset of
all the employees): then they must teach something, of course.
Sorry, that is not what I meant.
Let me rephrase the question. Why do professors commonly labour and
state that a 1::1-to-n relation is difficult, why do they pretend it
is uncommon ?
Here is a quick document that clarifies the issues you questioned,
that I have answered. To be complete, I have added an item re
Rolenames, because it is the third common “issue” that people raise: https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
I don’t know how you don’t strangle your colleagues.
Regarding subtyping, my critique is specifically on the notation given
in ERwin Methods Guide at the crossing of "Complete" with "Inclusive Subtype". Let me denote the specialization symbol with `-O||`, and
a categorization cluster with `P -O|| {C1, ..., Cn}`.
By definition, P -O|| {C1, ..., Cn} means:
"P must be exactly one of C1, ..., Cn".
If an entity P has two ore more clusters, each should be interpreted as above. For instance:
P -O|| {A,B}
P -O|| {C,D}
reads as:
- P must be (exactly) one of A and B; and
- P must be (exactly) one of C and D.
The notation I'm criticizing corresponds to:
P -O|| {A}
P -O|| {B}
which, by the definition above, one should read as:
- P must be A; and
- P must be B.
Instead, the assumed interpretation is:
- P must be A or B; and
- P may be both A and B,
which is inconsistent with the general definition.
Don’t include such things as the hysterical MVCC in that, because “MVCC” is not a real thing, it is a imaginary thing, collectively imagined and collectively assented to, by academia alone. All hail the imbecile Stonebraker and insist that he is a
On Wednesday, 31 March 2021 at 22:58:03 UTC+11, Nicola wrote:
On 2021-03-29, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
Introduction
When it came out in 1970, the Relational Model (Codd, not the
pretenders) made a paradigm shift in all areas of perceiving data (examination; data modelling; storage and retrieval; programming).
Codd had an uphill battle against the established academics because
they could not understand it,
I don't think that's a fair assessment. Who are those "established academics" you mention?
*Some* academics may have had issues with Codd's
proposal, but it was definitely understood, and supported, by many other academics.
And certainly at a greater degree than people in industry.
This is confirmed by those who were there:
https://archive.computerhistory.org/resources/access/text/2015/06/102702111-05-01-acc.pdf
E.g., quote from p. 8:
"So Codd's paper got some traction in the academic community where these mathematical concepts were very familiar. It didn't, at first, get much traction in the commercial database community. They had their
navigational systems. [...]"
Codd had an uphill battle against the established academics because
they could not understand it
Another first-hand historical perspective is provided by:
https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
Quote from the "Prehistory" section:
"[...] Nevertheless, what kicked off this work [on project Gamma-0 and, eventually, System R] was a key paper by Ted Codd - was it published in
1970 in CACM?
- Yes.
- A couple of us from the Systems Department had tried to read it -
couldn't make heads nor tails out of it. [laughter] At least back
then, it seemed like a very badly written paper: some industrial
motivation, and then right into the math. [laughter]"
Those are not academics talking.
Regarding the rest of your historical comments, I do not have anything
to add or object to. Except, perhaps, that the best DBMS in the world apparently survives in legacy mode now.
The point of this thread.
Let's come to the point.
On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
One reason is Chen's Entity-Relationship models are likely perceived
as easier to grasp for novices than something like IDEF1X. Whether
that is a correct perception, it can be debated. Another reason is
probably just historical, due to the huge influence of Chen's seminal
paper.
It may have been seminal for the academics, let me assure you, it was
not seminal, or even great, for practitioners of the day. It does not
have a semantic base, whereas the /RM/ and IDEF1X does.
For academics. I can grant, up to 1970, the paper was amazing. After
1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct; superseded.
Uh? Chen's ER paper is from 1976. That was a period of intense research
on so called "semantic modelling" (also spurred in part by Codd's work). IDEF1X relies heavily upon Chen's shoulders.
For academics. I can grant, [if it were published] up to 1970, the paper was amazing.
[Since it was published] After 1970, it was ageing, badly.
By 1983 [when RDBMS platforms were freely available, several providers, AND IDEF1X was freely available], it was dead; obsolete; defunct; superseded.
IDEF1X relies heavily upon Chen's shoulders.
On Thursday, 1 April 2021 at 02:54:53 UTC+11, Nicola wrote:
On the other hand, it makes it impossible to express the situation
above, i.e., that "P must be A, B, or both" (complete + inclusive).
... each instance
of the parent must always be an instance of one of the children—even
when the cluster has only one child.
I find it somewhat surprising that this aspect has not been clarified
and addressed in the standard, which was last revised in 2019.
Another first-hand historical perspective is provided by:
https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
404 - Not Found.
On Saturday, 3 April 2021 at 06:39:42 UTC+11, Nicola wrote:
https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
404 - Not Found.
My fault (wrong case):
https://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html
On Wednesday, 31 March 2021 at 22:58:03 UTC+11, Nicola wrote:
Another first-hand historical perspective is provided by:
Quote from the "Prehistory" section:
"[...] Nevertheless, what kicked off this work [on project Gamma-0 and, eventually, System R] was a key paper by Ted Codd - was it published in
1970 in CACM?
- Yes.
- A couple of us from the Systems Department had tried to read it -
couldn't make heads nor tails out of it. [laughter] At least back
then, it seemed like a very badly written paper: some industrial
motivation, and then right into the math. [laughter]"
Those are not academics talking.
On the other hand, it makes it impossible to express the situation
above, i.e., that "P must be A, B, or both" (complete + inclusive).
If you give me an example (names, not A B C), I would be happy resolve it.
On Wednesday, 31 March 2021 at 22:58:03 UTC+11, Nicola wrote:
On 2021-03-29, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
Introduction
When it came out in 1970, the Relational Model (Codd, not the
pretenders) made a paradigm shift in all areas of perceiving data
(examination; data modelling; storage and retrieval; programming).
Codd had an uphill battle against the established academics because
they could not understand it,
I don't think that's a fair assessment. Who are those "established
academics" you mention?
The main fight was within IBM, with the likes of Date and Fagin, who pretended to be his supporters but as time has told, they are his
subverters. There were others, more later.
There is absolutely zero articles in academia reinforcing or
progressing the /RM/. That is evidence, for FIFTY YEARS, that
academia does not understand it. All the nameless freaks, save one.
Likewise there is not a single book that honestly promotes the /RM/ or progresses it. All of them that purport to articulate “Relational Database” promote instead 1960’s Record Filing Systems, based on RM/T,
as confirmed in another thread. Even here, you are the only one
looking into genuine Relational Data Modelling. The rest promote anti-Relational pig poop.
*Some* academics may have had issues with Codd's
proposal, but it was definitely understood, and supported, by many other
academics.
Name one (prior to 1980, because that was the statement I made).
After 1981, when Sybase came out, and the IBM product (many names) was established, yes, academia could no longer deny it.
Try naming one paper written any time after 1970.
IDEF1X relies heavily upon Chen's shoulders.
Nonsense. Give one example, one article. Rob Brown already had
a diagrammatic modelling method (as distinct from the various diagrams
that data modellers created) that was widely accepted ... after
consultation with Codd, he produced what became known as IDEF1X.
Ok, fine. But your words contradict that, you can’t say that and also
say “My main complaint with IDEF1X is the treatment of generalization hierarchies”.
So what, if anything, is your remaining complaint re “generalization hierarchies”.
Regarding subtyping, my critique is specifically on the notation given
in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
Subtype".
What “crossing” ???
You can’t use both IDEF1X and IEEE notation in any single model, they cannot be mixed. They are exclusive. You can’t go back-and-forth
either.
Sorry. I don’t understand what you are trying to say.
Here is a quick document that clarifies the issues you questioned,
that I have answered. To be complete, I have added an item re
Rolenames, because it is the third common “issue” that people raise: >> > https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
A question: what is the use case for an association that does not imply
a foreign key (rightmost symbol in your "improved IE")? Why would you
require a parent entity to exist at the time of insertion, but not
later?
It is actually a very common requirement. Refer this Data Model: ____https://www.softwaregems.com.au/Documents/Student_Resolutions_2020/Giannis/RoomMonitor%20DM%20V0_51.pdf
Since we are discussing IDEF1X, you might be interested in this Q&A: ____https://stackoverflow.com/q/4132044/484814
On Sunday, 4 April 2021 at 08:40:19 UTC+10, Nicola wrote:
On 2021-04-02, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
On the other hand, it makes it impossible to express the situation
above, i.e., that "P must be A, B, or both" (complete + inclusive).
If you give me an example (names, not A B C), I would be happy resolve it.
The example from your Subtype.pdf document is fine: a Pastime (P) must
be a PastimeHobby (A) or a PastimeSport (B), or both.
Using standard IDEF1X symbology [excluding IEEE notation], and following the text of the standard
(FIPS 184 or ISO 31320:2, they don't differ on this), you cannot express
the assertion above, only approximate it, AFAICS.
The "or both" is not a Predicate, it is a collection of instances.
It appears this is boiling down to:
- you do not accept the IEEE notation for Relational Data Modelling
- you are in denial that IEEE notation exists
--- in fact it existed before you or I were born
- you do not accept correction of an incomplete Standard
--- even if the correction existed prior
--- or put otherwise, IDEF1X Subtype notation is a regression, and thus invalid
- therefore for you there is only the IDEF1X notation
Yes, the IDEF1X Subtype notation is broken. Yes, that is just one of
the many things that one should be able to (a) model, and (b) model
compliant with the /RM/, that cannot be rendered in IDEF1X/IDEF1X
Subtype Notation.
The same problem exists with IDEF1X Cardinality notation.
In Bruce's book (and in ERwin) you'd use two clusters, each with one
child, but that requires an interpretation that does not find
an equivalent in the standards. At least, to the best of my
understanding.
Your understanding is correct.
That interpretation is false.
Bruce is an idiot (per reasons explained above, for noticing the problem and NOT resolving it).
Do not follow an idiot.
Further, the “two clusters with one child each” is a hideous, gross, Normalisation error.
Thus the model is invalid; incorrect, fix it.
As a counter-point, think about UML. Even though it is heavily
marketed as a “Standard”, it is not a Standard by any means, because
it is (a) grossly incomplete: each modeller adds his own 5 to 10
notations to cover the missing bits because he has designed objects or interaction for which no UML notation exists. When a few hundred do
that private dance and publish their models, those 400 or 500
notations become de facto UML, like it or not. Yes, you and I as
purists would reject all that. But whereas I would model it in
a genuine modelling notation, and thus resolve the issue, you would
stand and argue that UML is broken, that the added notation is
invalid.
Further, the main fault with UML, its self-destroying fault, is [b]
the lack of integration in all areas, The many different diagrams
simply do not come together as an integrated System Definition.
I have updated this doc to reflect the above. In case there remains
anything worth discussing on this issue, I have added a page with the Subtypes, and given the Predicates (which are an excellent method of verifying the model, a feedback loop).
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
Note, I am not asking you how you would *implement* this situation; only
how a data model would look like.
RE the added page, looking at the transactions, I think PersonPastime's subtypes are not exclusive (the diagram has an X that should not be
there).
On Sunday, 4 April 2021 at 08:27:43 UTC+10, Nicola wrote:
On 2021-04-02, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
On Wednesday, 31 March 2021 at 22:58:03 UTC+11, Nicola wrote:
On 2021-03-29, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
Introduction
When it came out in 1970, the Relational Model (Codd, not the
pretenders) made a paradigm shift in all areas of perceiving data
(examination; data modelling; storage and retrieval; programming).
Codd had an uphill battle against the established academics because
they could not understand it,
I don't think that's a fair assessment. Who are those "established
academics" you mention?
The main fight was within IBM, with the likes of Date and Fagin, who pretended to be his supporters but as time has told, they are his subverters. There were others, more later.
There is absolutely zero articles in academia reinforcing or
progressing the /RM/. That is evidence, for FIFTY YEARS, that
academia does not understand it. All the nameless freaks, save one. Likewise there is not a single book that honestly promotes the /RM/ or progresses it. All of them that purport to articulate “Relational Database” promote instead 1960’s Record Filing Systems, based on RM/T, as confirmed in another thread. Even here, you are the only one
looking into genuine Relational Data Modelling. The rest promote anti-Relational pig poop.
*Some* academics may have had issues with Codd's
proposal, but it was definitely understood, and supported, by many other >> academics.
Name one (prior to 1980, because that was the statement I made).
After 1981, when Sybase came out, and the IBM product (many names) was established, yes, academia could no longer deny it.
Try naming one paper written any time after 1970.
Among the papers I know from before 1980 (Codd's papers excluded), I'd
say that it's not hard to find some that are supportive of the RM. Any
that have understood it? Hard to tell... Progressed it? Let's see:
I have a few papers on semantic modeling, which do not qualify; several papers on data dependencies, normal forms and other purely theoretical amenities such as closed/open worlds or the computational complexity of joins, which do not qualify because they are not practical; and a few
papers on physical and systems design (such as the papers on System R), which might qualify, but they are from the IBM Systems Journal or IBM Research Labs.
I would consider Grant's 1977's critique on "Null values in a Relational Data Base" a progress, as it pointed out the inconsistency of Codd's preliminary proposal for the treatment of nulls. But you'd likely say
that Codd's treatment of nulls was a regression, so Grant would at most
move things back to the start.
I'd rather like to know why you think that, after 1981, papers with
the qualities that you cannot ascribe to '70s papers would exist, and
ask you to name one such paper, if you know any.
Anyway, I appreciate your own recount of those times, albeit somewhat critical of the sources I have cited. I do not feel qualified to comment
on that any further, though.
IDEF1X relies heavily upon Chen's shoulders.
Nonsense. Give one example, one article. Rob Brown already had
a diagrammatic modelling method (as distinct from the various diagrams that data modellers created) that was widely accepted ... after consultation with Codd, he produced what became known as IDEF1X.
FIPS 184, Background section: "The theoretical roots for [the initial approach to IDEF information modeling] stemmed from the early work of
Dr. E. F. Codd on relational theory and Dr. P. P. S. Chen on the entity-relationship model."
And two paragraphs later: "Application within industry had led to the development in 1982 of a Logical Database Design Technique (LDDT) by R.
G. Brown of the Database Design Group. The technique was based on the relational model of Dr. E. F. Codd, the entity-relationship model of Dr.
P. P. S. Chen,
and the generalization concepts of J. M. Smith and D. C.
P. Smith."
Ok, fine. But your words contradict that, you can’t say that and also say “My main complaint with IDEF1X is the treatment of generalization hierarchies”.
So what, if anything, is your remaining complaint re “generalization hierarchies”.
My complaint is not about "generalization hierarchies" per se. It is
a specific critique on the specific notation used by IDEF1X. That has nothing to do with understanding transactions, or whatever. It is the
lack of a way (if you follow the standard) or a cumbersome way (if you follow Bruce/ERwin) to represent what in your document is called "Non-Exclusive Subtyping", using the "complete categorization" symbol.
cumbersome
Regarding subtyping, my critique is specifically on the notation given
in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
Subtype".
What “crossing” ???
I did not express myself clearly. I meant the IDEF1X (not IE) notation
at the intersection of the "Complete" column and "Inclusive Subtype"
row.
Sorry. I don’t understand what you are trying to say.
My fault, not the best example of clarity. But the point is, in
a nutshell, that non-exclusive subtyping is not straightforward as it
should be (as it is in IE).
Here is a quick document that clarifies the issues you questioned,
that I have answered. To be complete, I have added an item re
Rolenames, because it is the third common “issue” that people raise:
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
A question: what is the use case for an association that does not imply >> a foreign key (rightmost symbol in your "improved IE")? Why would you
require a parent entity to exist at the time of insertion, but not
later?
It is actually a very common requirement. Refer this Data Model: ____https://www.softwaregems.com.au/Documents/Student_Resolutions_2020/Giannis/RoomMonitor%20DM%20V0_51.pdfI have had time only for a cursory look at the requirements and the
model,
but one thing that I have noticed is that there is no independent
Sensor entity.
That strikes as something unusual. It's ok to associate
a Reading with a Room for auditing, but with an independent Sensor you should also be able to maintain referential integrity even when
a sensor's location is changed as the MAC is immutable. But, again,
I need to re-read your requirements.
On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
Yes, the IDEF1X Subtype notation is broken. Yes, that is just one of
the many things that one should be able to (a) model, and (b) model compliant with the /RM/, that cannot be rendered in IDEF1X/IDEF1X
Subtype Notation.
There are two orthogonal aspects in a generalization hierarchy:
1. are the subtype mutually exclusive or not?
2. is every instance [row] of the parent entity an instance [row] of some child
entity ("subtyping" in your terminology), or not?
So, four combinations.
Following the terminology of your document:
| Exclusive?
Subtyping? | Yes No -----------|----------------------------------------------
Yes | Exclusive Subtyping Non-exclusive subtyping
No | ? Optional attr.[Group], Not Subtype
In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
What is marked with ? corresponds to an "incomplete categorization" in IDEF1X terminology.
Using IE notation, how would you model an
"incomplete categorization"?
There is no example in your document.
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
Note, I am not asking you how you would *implement* this situation; only
how a data model would look like.
The same problem exists with IDEF1X Cardinality notation.
Which problem do you have with IDEF1X cardinalities?
In Bruce's book (and in ERwin) you'd use two clusters, each with one
child, but that requires an interpretation that does not find
an equivalent in the standards. At least, to the best of my
understanding.
Your understanding is correct.
That interpretation is false.
Bruce is an idiot (per reasons explained above, for noticing the problem and NOT resolving it).
Do not follow an idiot.
Further, the “two clusters with one child each” is a hideous, gross, Normalisation error.
Thus the model is invalid; incorrect, fix it.
You could also show us how you would solve the example above in ERwin
(with IE notation). I do not have an ERwin license, so I can't try it myself.
As a counter-point, think about UML. Even though it is heavily
marketed as a “Standard”, it is not a Standard by any means, because it is (a) grossly incomplete: each modeller adds his own 5 to 10
notations to cover the missing bits because he has designed objects or interaction for which no UML notation exists. When a few hundred do
that private dance and publish their models, those 400 or 500
notations become de facto UML, like it or not. Yes, you and I as
purists would reject all that. But whereas I would model it in
a genuine modelling notation, and thus resolve the issue, you would
stand and argue that UML is broken, that the added notation is
invalid.
Well, one thing is asking to fix something that it's just a notational glitch that can be easily fixed; "fixing UML" is something on another
level entirely: I'd not dare ask anything like that.
I have updated this doc to reflect the above. In case there remains anything worth discussing on this issue, I have added a page with the Subtypes, and given the Predicates (which are an excellent method of verifying the model, a feedback loop).
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
Yes, the updated chart looks better. IE notation covers subtyping
correctly. My only remaining question is the one above.
RE the added page, looking at the transactions, I think PersonPastime's subtypes are not exclusive (the diagram has an X that should not be
there).
On Sunday, 4 April 2021 at 08:27:43 UTC+10, Nicola wrote:
My complaint is not about "generalization hierarchies" per se. It is
a specific critique on the specific notation used by IDEF1X.
**That has nothing to do with understanding transactions, or whatever.**
On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
I fail to see the problem, I must be missing something. Sorry.
Page 4
Note, I am not asking you how you would *implement* this situation; only
how a data model would look like.
There is a difference in your mind ?
By the way, I have given you two ways of transacting a 1::1-to-n
relation.
There are two orthogonal aspects in a generalization hierarchy:
I don’t care for the title, it is some academic artefact, of relevance
to academia only. I know that what you mean is the Basetype-Subtype
clusters that we have had in databases, decades before those papers
were written. And again, I am very interested in modelling data the
way it actually exists, not limited to any perception.
Further, I accept wholeheartedly that the correct observation of genus
vs species is an essential part of genuine Analysis, here Data
Analysis.
1. are the subtype mutually exclusive or not?
Ok. One category is. Because they are Exclusive, we [normal people,
not prone to reading academic fantasies, unless forced] call the
category:
____Exclusive
In Logic, that is an XOR Gate [Discriminator] on the Basetype that
identifies the single Subtype. It is Semantic (examples in the
progressing doc).
The remaining category, since it is not Exclusive, and certainly not inclusive, is called:
____Non-Exclusive
The Subtypes are not mutually exclusive. There is no Discriminator. Typically, the Basetype has more than one [but not many or all]
Subtypes. Note that each Basetype-Subtype pair must be perceived as
a logical row.
2. is every instance [row] of the parent entity an instance [row] of
some child entity ("subtyping" in your terminology), or not?
For Exclusive: yes, exactly one Subtype row.
For Non-Exclusive: yes, one or more Subtype rows.
So, four combinations.
Whoa. What four combinations ??? How can you combine Exclusive with Non-Exclusive ???
In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
If you say so. But you are mixing things up: in IDEF1X Notation,
there is no “Non-Exclusive” Subtyping, there is only {Complete|Incomplete}.
What is marked with ? corresponds to an "incomplete categorization"
in IDEF1X terminology.
Ok.
Using IE notation, how would you model an
"incomplete categorization"?
Well, you can’t. Because it does not exist in IE. Because it does
not exist in reality.
Nevertheless, because the IDEF1X notation is inferior, a lower-order
concept, it can be progressed to a superior, higher-order concept.
Just get rid of the notion of “incomplete/complete”.
Anyway, I appreciate your own recount of those times, albeit somewhat
critical of the sources I have cited. I do not feel qualified to comment
on that any further, though.
Hah. You will love the critique I have for the new list of academics,
above.
IDEF1X relies heavily upon Chen's shoulders.
Nonsense. Give one example, one article.
FIPS 184, Background section:
Yes, it is written.
So what, do you believe everything that is written ?
On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
I fail to see the problem, I must be missing something. Sorry.
Page 4
On Monday, 5 April 2021 at 23:28:43 UTC+10, Nicola wrote:
On 2021-04-05, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
Anyway, I appreciate your own recount of those times, albeit somewhat
critical of the sources I have cited. I do not feel qualified to comment >> on that any further, though.
Hah. You will love the critique I have for the new list of academics, above.
Too bad the people you mention, and often insult, are not here to
provide their point of view. You know, the discussion would be much more interesting.
insult
IDEF1X relies heavily upon Chen's shoulders.
Nonsense. Give one example, one article.
FIPS 184, Background section:
Yes, it is written.
So what, do you believe everything that is written ?
When I said “article” I did not mean a report somewhere, I meant a concept, that is recognisable.
a. Name one thing, a method or rule or whatever, from the Chen ERD, that exists in IDEF1X.
b. Name one thing FROM the /RM/ that Chen has in his ERD.
So what, do you believe everything that is written ?
Never. Not by you, either :-)
On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
I fail to see the problem, I must be missing something. Sorry.
Page 4
That captures the requirements correctly, but it introduces an entity (Employee FT_or_C) that does not exist in reality, it is not in the requirements and, in fact, is not inherently necessary. An IDEF1X model would have just three entities => IDEF1X is better than your IE by
Occam's Razor. QED
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
I fail to see the problem, I must be missing something. Sorry.
Page 4
That captures the requirements correctly, but it introduces an entity (Employee FT_or_C) that does not exist in reality,
it is not in the requirements
and, in fact, is not inherently necessary. An IDEF1X model
would have just three entities => IDEF1X is better than your IE by
Occam's Razor. QED
Note that your model, in a larger context, might be a better choice in
some circumstances.
But with your modeling language, it's the only one
you can build for the requirements above.
You may counter this, but know in advance that I will not respond,
because for me this matter is settled.
The last word is yours!
Note, I am not asking you how you would *implement* this situation; only >> how a data model would look like.
There is a difference in your mind ?
The difference between logical and physical.
your modeling language
your IE
On Tuesday, 6 April 2021 at 04:48:54 UTC+10, Nicola wrote:
On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
I fail to see the problem, I must be missing something. Sorry.
Page 4
This is my comparative assessment of IE vs IDEF1X notation, re generalization:
https://jirafeau.net/f.php?h=1mnluFoq
Feel free to add your comments,
Nicola
This is my comparative assessment of IE vs IDEF1X notation, re
generalization:
https://jirafeau.net/f.php?h=1mnluFoq
There is a problem with that. Actually two.
[...]
In future, please feel free to use my docs and to refer to them,
please do not-cut-paste.
The second problem is, you have performed a nice Reverse Straw Man.
Anyway, here is a revised document (with references this time):
On Thursday, 8 April 2021 at 04:51:55 UTC+10, Nicola wrote:
On 2021-04-07, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote: Nicola
There is a problem with that. Actually two.
This is my comparative assessment of IE vs IDEF1X notation, re
generalization:
[...]
In future, please feel free to use my docs and to refer to them,
please do not-cut-paste.
My apologies. That document is not online any more.
The second problem is, you have performed a nice Reverse Straw Man.I think that the misrepresentation is more in the eyes on the beholder.
Anyway, here is a revised document (with references this time):
https://jirafeau.net/f.php?h=2NbPmq6L
What I see is that both notations have deficiencies, which are easily
fixed. Once that is done, they become completely equivalent. IE's only advantage is being vastly more popular.
On Thursday, 8 April 2021 at 05:06:08 UTC+10, Nicola wrote:
On 2021-04-07, Nicola <nic...@nohost.org> wrote:Fixed a typo:
Anyway, here is a revised document (with references this time):
https://jirafeau.net/f.php?h=1WA2Cs0R
On Monday, 5 April 2021 at 23:50:56 UTC+10, Nicola Vitacolonna wrote:
On 2021-04-05, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
There are two orthogonal aspects in a generalization hierarchy:
I don’t care for the title, it is some academic artefact, of relevance to academia only. I know that what you mean is the Basetype-Subtype clusters that we have had in databases, decades before those papers
were written. And again, I am very interested in modelling data the
way it actually exists, not limited to any perception.
Further, I accept wholeheartedly that the correct observation of genus
vs species is an essential part of genuine Analysis, here Data
Analysis.
1. are the subtype mutually exclusive or not?
Ok. One category is. Because they are Exclusive, we [normal people,
not prone to reading academic fantasies, unless forced] call the
category:
____Exclusive
In Logic, that is an XOR Gate [Discriminator] on the Basetype that identifies the single Subtype. It is Semantic (examples in the
progressing doc).
The remaining category, since it is not Exclusive, and certainly not inclusive, is called:
____Non-Exclusive
The Subtypes are not mutually exclusive. There is no Discriminator. Typically, the Basetype has more than one [but not many or all]
Subtypes. Note that each Basetype-Subtype pair must be perceived as
a logical row.
2. is every instance [row] of the parent entity an instance [row] of
some child entity ("subtyping" in your terminology), or not?
For Exclusive: yes, exactly one Subtype row.
For Non-Exclusive: yes, one or more Subtype rows.
No, the distinction I have made is between subtyping/not subtyping.
So, four combinations.
Whoa. What four combinations ??? How can you combine Exclusive with Non-Exclusive ???
I thought that was clear enough, but it mudded the waters instead. It doesn't matter, though, because the matter is settled for me, as per my previous post.
In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
If you say so. But you are mixing things up: in IDEF1X Notation,
there is no “Non-Exclusive” Subtyping, there is only {Complete|Incomplete}.
Exactly. But "non-exclusive subtyping" is not a notation, it is
a concept.
And IDEF1X has not straightforward notation for that.
What is marked with ? corresponds to an "incomplete categorization"
in IDEF1X terminology.
Ok.
Using IE notation, how would you model an
"incomplete categorization"?
Well, you can’t. Because it does not exist in IE. Because it does
not exist in reality.
Look who is in denial of reality.
My Employee[Full-Time,Consultant]
example is just that.
Similarly to the above, "incomplete
categorization" is not a notation, it is a concept.
And your IE has not
straightforward notation for that.
Nevertheless, because the IDEF1X notation is inferior, a lower-order concept, it can be progressed to a superior, higher-order concept.
Just get rid of the notion of “incomplete/complete”.
Without such a notion, you are forced to model "incompleteness" of
a generalization hierarchy with 1:1-0:1 relationships. While you can do that, it may not be the most natural or more economical way of modeling
some situations, witness your Employee[Full-Time,Consultant] solution.
Responding to issues in the doc only.
a. Re links. It seems in each instance, the entire text box is “hot”, not just the words in “hot” colour and underlined.
b. Re Place. In my DM, I am displaying the Entity level symbol for
this entity, on a page that is displaying Attribute level. That means
that Place is fully defined somewhere else (another page) in the DM.
What does the dot-dot-dash line intend to convey ?
d. Cardinality. The expected (universally understood) notation is:
__ Parent::Child
__ 1::0-to-1 -- eg. optional attribute
__ 1::0-or-1 -- equally understood
This is new:
__ 1:1-0:1
1. Other than the minor issues above, I agree, that is the correct
IDEF1X rendition of [Optional Attribute (Not Subtype) ]. But ...
There is no such thing as “Subtype” in IDEF1X. Use “generalisation” and “category” throughout, to be faithful to the IDEF1X terminology.
2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X.
I suggest remove the page.
Use “generalisation” and “category”
throughout, to be faithful to the IDEF1X terminology.
(Subtype; Exclusive, are IEEE terms.
Basetype; Non-Exclusive are my
corrections to incorrect ERwin terms.)
3. I know what it is but I have not used Incomplete Categorisation,
so my comments on this point exclude that of correctness against
[Incomplete Categorisation].
b. I don’t agree with your definition (yellow panel in the middle).
- declarations SUCH AS “business party and a customer must be treated
as a single logical unit” are valid for IEEE Subtypes, I don’t see how they apply to IDEF1X Categories.
- in the example, the declaration “business party and a customer must
be treated as a single logical unit” violates (a) logic, and (b)
IDEF1X Categories.
--- “when the business part[y] is a customer” is contrived.
- the declaration “customer and business party are the same entity” is patently false: the model shows two distinct entities.
- Finally, a Category with a single member is a gross Normalisation
error, it is corrected by making it an Optional Attribute.
c. To be clear, in any case (IDEF1X xor IEEE) Customer is definitely
not BusinessParty.
Go back to the Predicates to check: Business Party
is 0-to-1 Customer. Which of course is an optional attribute, an
optional Fact, of BusinessParty.
4-Non-Exclusive Subtyping
a. There is no such thing as “Non-Exclusive Subtyping” in IDEF1X.
I don’t know what the IDEF1X equivalent of “Non-Exclusive Subtyping” would be, or what you think it would be, thus I can’t help you there.
4-Partial Specialization with Mutually Exclusive Child Entities
a. Categorisation, not Specialisation.
b. Re the “Nicola IDEF1X” link. Goes to my doc that supports the
entire discussion, progressively: I don’t mind, but is that what you
want ? Page 4 specifically, which has changed (as noted in my
previous post) ? To me, that page provides a number of models, the
purpose of which is to foster discussion in this thread, it is not
definitive of anything.
g. The new symbol.
Text box on right. I don’t understand how you can apply “Incomplete specialisation [Categorisation]” which is a valid IDEF1X term, to the
IEEE classifications, let alone to a specific IEEE symbol, which has
a defined meaning totally unrelated to the IDEF1X classifications.
- Further, I do not understand how it is “the same meaning as” the
IDEF1X Incomplete Category symbol.
I have simplified the document a bit. Note that I have also reordered
the sections:
On Friday, 9 April 2021 at 08:02:50 UTC+10, Nicola wrote:
On 2021-04-07, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
d. Cardinality. The expected (universally understood) notation is:That is (min parent):(max parent)-(min child):(max child).
__ Parent::Child
__ 1::0-to-1 -- eg. optional attribute
__ 1::0-or-1 -- equally understood
This is new:
__ 1:1-0:1
I think one item of difference, generally, re the 1997 revision of
IDEF1X, because (a) it validates the anti-Relational “identity-based”,
The second general item is, the purpose of your venture is not
completely clear to me. This has gone back-and-forth a bit, and your
attempt to demonstrate the need for a new symbol seemed like the end
goal
(and thus we were discussing whether the condition for it
exists), and I was arguing from strict IDEF1X. But now it seems like
you trying to cover any and all ways of **classifying** Subtype sets,
and that uses the new loose and floppy IDEF1X revision terminology.
On Friday, 9 April 2021 at 08:02:50 UTC+10, Nicola wrote:
2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X.
- declarations SUCH AS “business party and a customer must be treated
as a single logical unit” are valid for IEEE Subtypes, I don’t see how >> > they apply to IDEF1X Categories.
I do because I see no difference between "complete categorization" and
"exclusive subtyping" in terms of the predicates they represent. If
there are any, please let me know.
Ok.
1. Where, pray tell, in the definition of IDEF1X[Complete
Categorisation] (preferably the original, but ok, the revised if you
must), excluding your interpretation, does it state that the members
are mutually exclusive, as it states in the IEEE[Exclusive Subtype].
2. Where, pray tell, in the definition of IEEE[Exclusive Subtype],
excluding your interpretation, does it state that the set of members
is complete [ie. there will not be a new member added in the future],
as it states in the IDEF1X[Complete Categorisation] definition
(preferably the original, but ok, the revised if you must).
6. My Subtype doc, §4 Optional Attribute[Group], Not Subtype:
“If the Basetype can exist without any of the Subtypes, then it is not
a Basetype::Subtype Relation, it is an ordinary Relation, which is an optional child (1::0-1)”
8. You have not exposed the Predicates, as you should.
Knock yourself out. Give the Predicates.
Give the Predicates.
- the declaration “customer and business party are the same entity” is
patently false: the model shows two distinct entities.
Let me rephrase it: each instance of a Customer entity represents the
same real-world "thing" as its associated instance of the Business Party
entity.
Nonsense.
c. To be clear, in any case (IDEF1X xor IEEE) Customer is definitely
not BusinessParty.
No answer ?
On Friday, 9 April 2021 at 23:59:07 UTC+10, Nicola wrote:
On 2021-04-09, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
Nonsense.
You have
asked me to point out "articles", "standards". I have complied, with
titles, page numbers, paragraphs, verbatim quotes.
Everything wrong, false, fragmented and invented, of course.
So, except from your own documents, what else is not nonsense?
I start to believe that if
I quoted one of your documents as a reply to some of your objections,
you would call that nonsense as well!
FIPS 184, ("Definitions" section):
So, except from your own documents, what else is not nonsense?
the last version I have linked in my previous post (v3) has the
predicates you have asked for.
I think one item of difference, generally, re the 1997 revision of
IDEF1X, because (a) it validates the anti-Relational “identity-based”,
The "identity-based" part can be ignored.
What is relevant is Section 9,
which is essentially a copy of FIPS 184, minus the methodology and the first-order formalization. But I'll do as you prefer and refer to FIPS
184 directly (I assume that FIPS 184 is "the original" you mention).
The second general item is, the purpose of your venture is not
completely clear to me. This has gone back-and-forth a bit, and your attempt to demonstrate the need for a new symbol seemed like the end
goal
Yes.
(and thus we were discussing whether the condition for it
exists), and I was arguing from strict IDEF1X.
But now it seems like
you trying to cover any and all ways of **classifying** Subtype sets,
That's the purpose of adding a new symbol: to be able to express all
kinds of generalization hierarchies.
and that uses the new loose and floppy IDEF1X revision terminology.
Not new, not floppy. See below.
On Friday, 9 April 2021 at 08:02:50 UTC+10, Nicola wrote:
2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X.
FIPS 184, ("Definitions" section):
[...]
So, a category "is also known as" a sub-type.
So, exclusive/non-exclusive is covered quite explicitly. More on that
below.
- declarations SUCH AS “business party and a customer must be treated >> > as a single logical unit” are valid for IEEE Subtypes, I don’t see how
they apply to IDEF1X Categories.
I do because I see no difference between "complete categorization" and
"exclusive subtyping" in terms of the predicates they represent. If
there are any, please let me know.
Ok.
1. Where, pray tell, in the definition of IDEF1X[Complete
Categorisation] (preferably the original, but ok, the revised if you must), excluding your interpretation, does it state that the members
are mutually exclusive, as it states in the IEEE[Exclusive Subtype].
Besides the above, FIPS 184, Annex B also contains a first-order formalization of IDEF1X, which also asserts the exclusivity requirement. Specifically (the labeling starts with "C" although the section is "B"),
p. 116:
«C1.2 The categories within a cluster are mutually exclusive.
For 1 <= i < j <= n, add a rule
(for all *)(not exists(v: e_i): I, exists(v: e_j: I))
to the theory
C1.3 If the categorization is complete, ensure a category instance for
every generic instance by adding the rule
(for all *)(if exists(v: e): I
then exists(v: e_1): I or ... or exists(v: e_n): I)»
2. Where, pray tell, in the definition of IEEE[Exclusive Subtype], excluding your interpretation, does it state that the set of members
is complete [ie. there will not be a new member added in the future],
as it states in the IDEF1X[Complete Categorisation] definition
(preferably the original, but ok, the revised if you must).
Give me a standard reference where I can read "the definition of IEEE[Exclusive Subtype]". Without that, the definition I am assuming is
from your Subtype document,
where you state (p. 2): "For each Basetype,
there is exactly one Subtype", which entails that for every instance of
the basetype, there is an instance of subtype 1 or ... or subtype
n
(essentially, C1.3 above).
6. My Subtype doc, §4 Optional Attribute[Group], Not Subtype:
“If the Basetype can exist without any of the Subtypes, then it is not
a Basetype::Subtype Relation, it is an ordinary Relation, which is an optional child (1::0-1)”
With this premise, your reasoning is correct, I am not arguing against
your inferences. The premise is a reasonable assumption, too. But it's
not an absolute truth.
I could equally state:
If the generic entity can exist without any of its categories, then it
is still a generalization structure.
Hence, a Business Party is
a generalization of a Customer (a Customer *is* a Business Party),
although not all Business Parties are customers.
On Saturday, 10 April 2021 at 17:27:56 UTC+10, Derek Ignatius Asirvadem wrote:
On Friday, 9 April 2021 at 23:59:07 UTC+10, Nicola wrote:
sorry, it is already dismissed.Hence, a Business Party isI have already dismissed that as connecting fragments instead of connecting atoms, and explained in great detail the issue of fragmentation. If you are going to take it up you have to respond to that. Since you are not, since you are just re-stating,
a generalization of a Customer (a Customer *is* a Business Party), although not all Business Parties are customers.
Yes, of course, “a Customer *is* [always] a Business Party”, but that is not a Predicate, and that connects two unconnected things. You are mixing up queries with Predicates.
Cheers
Derek
With a view to making the exchange a bit more top-down, I have added
to this doc. Page 7 gives a chronology of the appearance of
Standards, and my Software Gems docs that are relevant. Hopefully
that will assist you in obtaining an overview, and thus reduce the back-and-forth.
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
On Sunday, 11 April 2021 at 18:40:33 UTC+10, Nicola wrote:
On 2021-04-10, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
With a view to making the exchange a bit more top-down, I have added
to this doc. Page 7 gives a chronology of the appearance of
Standards, and my Software Gems docs that are relevant. Hopefully
that will assist you in obtaining an overview, and thus reduce the back-and-forth.
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdfOk, I have understood your definitions and explanation, and how you
consider subtyping different from "proper subsetting" (for a lack of
a better term).
Nothing to object. After all, this back and forth was
prompted by my critique of IDEF1X's treatment of generalization. You
have made it sharper.
I will just point out that the example you have chosen for §4.7 is
a straw man:
if you look at my document (§1), I have not used an
incomplete categorization for that, because that would be wrong. Use the Business Party/Customer/Supplier instead (if you do not want to assume
that a Business Part might be something different from a Customer or
a Supplier, remove Supplier).
As you said, our posts have crossed paths: feel free to comment on my v3
(I am still interested),
although you have already brought forth the
arguments to dismiss my tentative IEEE addition.
I do have a long response to your V3 doc
I will just point out that the example you have chosen for §4.7 is
a straw man:
That is a silly charge.
Charges have to do with intent, if there is no intent there is no
crime.
No problem at all to change the example (because the truth is the
truth and it will destroy falsity anywhere).
I don’t know if it would help, because you appear to be fairly fixed
on your understanding of {Complete, Incomplete}. And I have thus far
been unable to get you to see it.
On Monday, 12 April 2021 at 08:08:57 UTC+10, Derek Ignatius Asirvadem wrote:
I do have a long response to your V3 doc, it is just not ready yet. Short answer for now, responding to your post only.
On Monday, 12 April 2021 at 22:13:44 UTC+10, Derek Ignatius Asirvadem wrote:
As mentioned, I have taken some of the content from my IDEF1X Qualification doc, transformed it for public use, into the Response doc.
On Monday, 12 April 2021 at 17:23:37 UTC+10, Nicola wrote:
On 2021-04-11, Derek Ignatius Asirvadem wrote:
I do have a long response to your V3 doc
Looking forward to reading it.
I will just point out that the example you have chosen for §4.7 is
a straw man:
That is a silly charge.
You have taken an example which I (as you in the original model) have (correctly) modelled with optional attributes and turned it into an
example using (incorrectly) an incomplete categorization, and then you
have pointed out its obvious flaws.
Charges have to do with intent, if there is no intent there is no
crime.
My "straw man" qualification is directed at the argument, not at the
author.
No problem at all to change the example (because the truth is the
truth and it will destroy falsity anywhere).
Exactly. That's why there is no point in choosing a bad example.
I don’t know if it would help, because you appear to be fairly fixed
on your understanding of {Complete, Incomplete}. And I have thus far
been unable to get you to see it.
As I said, I have fully understood your definitions,
why you favor the
Exclusive/Non-Exclusive distinction over Complete/Incomplete, and
I agree with you on that.
My understanding of "complete" is different
from yours and I have never thought that it prevents the addition of new categories: I have always attributed to it a meaning analogous to your "basetype is always a subtype".
I acknowledge that the term "complete"
is not the best, though. That's why in my first revision of my document
I had also used "total/partial", which is my preferred terminology,
standard or not.
On Monday, 12 April 2021 at 22:43:38 UTC+10, Derek Ignatius Asirvadem wrote:
On Monday, 12 April 2021 at 22:13:44 UTC+10, Derek Ignatius Asirvadem wrote:
I don’t know if it would help, because you appear to be fairly fixed on your understanding of {Complete, Incomplete}. And I have thus far been unable to get you to see it.
As I said, I have fully understood your definitions,I have provided even better definitions.
why you favor the
Exclusive/Non-Exclusive distinction over Complete/Incomplete, and
I agree with you on that.
Ok. So do you now accept that the choice between them is XOR (“orthogonal” in freak-speak) ?
That undermines the premise of your venture.
My understanding of "complete" is different
from yours and I have never thought that it prevents the addition of new categories: I have always attributed to it a meaning analogous to your "basetype is always a subtype".
I understood that. I understood you needed more definition of what a Subtype really is, before IEEE, before the /RM/, before IDEF1X, and I have provided it just now.
The original IDEF1X “definition” of “complete” is quite a different thing. Detailed in the latest edition.
I acknowledge that the term "complete"
is not the best, though. That's why in my first revision of my document
I had also used "total/partial", which is my preferred terminology, standard or not.
Ok. But I hope you realise, it is better to keep use the Standard terms, even though the Standard, or some terms in it, is putrid.
On Monday, 12 April 2021 at 22:13:44 UTC+10, Derek Ignatius Asirvadem wrote:
Second, in order to provide a Normalised answer (ie. avoid duplication; reduce back-and-forth between it and your V3 doc), I have had to update the Response doc:
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
On Tuesday, 13 April 2021 at 02:26:44 UTC+10, Derek Ignatius Asirvadem wrote:
Note: IDEF1X technical terms are in boldface italic: refer to the standard (ISO 31032:2, Sec. 9) for their definition.
For each (instance of the) generic entity, there is exactly one (instance of a) category.think about adding this, to specify the IDEF1X meaning of Complete:
For each (instance of the) generic entity, there is exactly one (instance of a) category.is actually a definition for Exclusive. It is inadequate as a definition for Complete ... you have to add [b] and fiddle.
§3.6.1 para 3:
There are two categorization relationships in this cluster, one between EMPLOYEE and SALARIED-EMPLOYEE and one between EMPLOYEE and HOURLY-EMPLOYEE.
this is problematic in IDEF1XNo. It is not “problematic”, it simply does not exist in IDEF1X.
The intended interpretation ...
The intended interpretation does not ... conform to ISO 31320:2.
If one sticks to the standard, non-exclusive subtyping can only be approximated.
The issue can be easily remedied by adding a specific symbol for this case
A (not equivalent) rendition in IE notation
I have a problem with your language. This is technical subject matter; science, wherein we have certainty and things are stated as true or false. It is not Modernist philosophy, wherein things are stated as tentative. You have gone soft, since we
Incomplete: an instance of the generic entity may exist without being an instance of any of the category entities.
IE notation does not have a concept of “incomplete categorization”Because it is logically ridiculous. It is not a lack or privation. Declaring it as such is a silly error, same as declaring that a virgin does not have a venereal disease as a privation. (It is only a privation to those who are sluts, not to normal
Although not strictly necessary, in the [top] left model I would “collapse” the [two] incomplete categorization symbols into a single (non- standard) symbol (see below, left), as a matter of convenience, conciseness, and symmetry.
Generic entity: An entity whose instances are classified into one or more subtypes or subclassifications (category entities). Syn: superclass; supertype. [ISO 31320:2, §3.1.72]
Category (entity): An entity whose instances represent a subtype or subclassification of another entity (generic entity). Syn: subclass; subtype. [ISO 31320:2, §3.1.21]
Nicolaattributes is fragmented; crippling). Here you obtained your initial understanding of Subtypes from the idiotic IDEF1X doc (original or revised), instead of from reality (practitioners from 1960’s onwards, relational practitioners from the 1980’s
On Tuesday, 13 April 2021 at 02:26:44 UTC+10, Derek Ignatius Asirvadem wrote:
Updated again, just now:
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
I can’t recall ever having to explain Subtypes from scratch. The problem here is, academics are clueless about **The Logical** such as Subtypes and Atomicity, and about how to implement them (the notion that a “relation” is just a selected set of
No doubt, the filth that passes for “textbooks” these dark days, fail to define Subtyping.who follow the link to my doc will not understand it adequately. Further, it better identifies the context of your doc.
Comments re your V3 doc:
____ https://jirafeau.net/f.php?h=18wYFi9U
0. Intro
a. Typo, remove [’s] after my name.
b. For clarity, I suggest you add a note, that [in your words] Derek Asirvadem uses a stricter form of IDEF1X wherein all ambiguities are removed and all methods are given. He rejects the changes that resulted in ISO 31320:2 outright. Otherwise, those
c.distinctive enough, but yes, you do need to separate them. Perhaps a little grid, something like my page 11.
Note: IDEF1X technical terms are in boldface italic: refer to the standard (ISO 31032:2, Sec. 9) for their definition.
I agree that the doc would be better if you separate the IDEF1X and IEEE terminology, and do so clearly. But then do not refer to the standard because that is clear as two mud puddles. You may not need to give full definitions, because the names may be
The IDEF1X doc was written by an academic. Putrid and unusable definitions.body is EITHER male XOR female. Regardless of deformations; mutilations; additions.)
----
1.
----
is fine.
----
2. Complete Categorisation
----
a. (You think this is equivalent to Exclusive. It is not. Detailed in my doc.)
Read the FIPS 184 doc (mine is 145 pages; has diagrams. The other is 175 pages; no diagrams; includes the bit that you said is removed).
As an example of stating things backwards, and thus with far more complexity than necessary (schizophrenic) check out § 3.6.1. paras 4; 5; 6.
In any case, it is clear [after removing their mud] that Incomplete means the set contains Generic rows that do not have Category rows. And thus Complete means the set the does.
Agreed, the IDEF1X classification {Complete|Incomplete} is “mutually exclusive” but that is not the same thing as the component of the IEEE classification {Exclusive|Non-Exclusive}. Detailed in the Nicola IDEF1X 2 doc.
(And then there are the missing or invalid “formalisms”, which confirm/deny the categories.)
b. After this:
For each (instance of the) generic entity, there is exactly one (instance of a) category.think about adding this, to specify the IDEF1X meaning of Complete:
+ There is no generic row without a category row.
Depending on your bent, you could instead say this:
± For each generic row, there is at least one category row.
Now when you get to Incomplete Categorisation, if you do get to a page for it, add this:
+ There are generic rows without a category row.
c. You need Table[Sex]; PK[SexCode] instead of Gender; GenderCode. (Gender is not a table; not a FK in Person, because it is an imagined state; fluid; ever-changing; no limits. Sex is a physical reality, defined at the chromosome level, every cell in a
d. Different point. This:Logic; Semantics remain unaffected.
For each (instance of the) generic entity, there is exactly one (instance of a) category.is actually a definition for Exclusive. It is inadequate as a definition for Complete ... you have to add [b] and fiddle.
It does not work to position IDEF1X[Complete] as IEEE[Exclusive], it is a great misrepresentation.
e. While we are here, let me point out something we have not touched, that befuddles developers, as a caveat. It is important because it deals with semantics; Logic.
§3.6.1 para 3:
There are two categorization relationships in this cluster, one between EMPLOYEE and SALARIED-EMPLOYEE and one between EMPLOYEE and HOURLY-EMPLOYEE.
That is totally, utterly false. The Generic::CategorySET relation is a single, not one per Category, the symbol is the switching-point or pivot-point. If one accepts their idiocy, it breaks Predicates; Logic; Semantics. If one rejects it, Predicates;
At the physical level, in SQL, yes of course, each Generic::Category pair is a PK::FK relation. The set of relations in the cluster is the “web”, upon which the logical (eg. constraints that make it a Category cluster) is defined, and exists.definition first.
(In case this sounds like the physical governs the logical, no, never, the logical always governs the physical. The problem is, academics do not have a grasp of the Logical.)
----
3. Complete Categorization and Non-Exclusive Child Entities
----
Much better notes in general.
a. “both” is a description, not logical, not a Predicate. You are treating it as a Predicate, which will lead to confusion.
b. IDEF1X[Incomplete] is already defined, it needs no further definition.
There is no such thing as “Non-Exclusive” in IDEF1X, you need to define it first, then give the pictures re what it looks like. Yes, sure, you can take the Predicates straight out of the IEEE[Non-Exclusive] definition, but then again, it needs a
c. The reference [Subtype doc §3] is clearly quite different.you are going to change anything, you have to change that **CLASSIFICATION**, not just grab a component (**FRAGMENT**) from here and add it there.
d. the model as shown is illegal. A Generic with a single Category (the Category SET has one member) is a gross Normalisation error. For the given model, if a reference is used it should be [Subtype doc §4].
e.
this is problematic in IDEF1XNo. It is not “problematic”, it simply does not exist in IDEF1X.
Further, you can’t walk up to IDEF1X (as defined) and just add IEEE[Non-Exclusive]. Because IDEF1X has a **CLASSIFICATION** that has its own components, and IEEE has a **CLASSIFICATION** that has quite different components, eg. [Non-Exclusive]. If
f.interpretation” is a gross misrepresentation. As confirmed in:
The intended interpretation ...
Intended by whom ??? IDEF1X has been with us for forty years, even though the definitions are not great, the interpretations is single, arrived at logically. IDEF1X allows no such thing. It propose that after forty years, IDEF1X has a novel “
it.The intended interpretation does not ... conform to ISO 31320:2.
g.
If one sticks to the standard, non-exclusive subtyping can only be approximated.
False. If one sticks to the standard, Non-Exclusive subtyping is prohibited, because the only defined **CLASSIFICATION** (not either of {Complete|Incomplete} demands exclusivity. it is not even defined.
h.
The issue can be easily remedied by adding a specific symbol for this case
Sure. Give the name & definition first, the example second, and the new symbol third. Not that such will have no reference to IDEF1X{Complete|Incomplete}, which is why I say you need a separate page. Do not conflate DEF1X[Complete].
i. General note. Do not use the terms /parent/ and /child/. What we have here at the logical level is siblings, more precisely Generic and Category. Yes, of course, in SQL, which is physical, the only possibility for a relation is parent and child.
----
4. Incomplete Categorization
----
a. [Incomplete] is already defined in IDEF1X, it needs no further definition.
b. IDEF1X[Incomplete] already provides what you are suggesting, read the definitions. The page is redundant.
c. A separate point is, DEF1X[Incomplete] is not a Subtype structure at all, it is illegal as a Subtype definition.
d. What you are trying to show is something else, such as giving props to the crippled concept, by showing that the crippled concept is somehow better than another concept which is not crippled. False.
e. I don’t think you have anything of substance to add under the heading [4. Incomplete Categorisation]. If you insist that you do, you need to define that (without reference to IDEF1X or IEEE), and give it a name.
f. I categorically state that that thing is not a Subtype of any kind, that it is a combination of an illegal component (Generic that does not have a Category) and optionality. There is no legal Predicate for that strange mixture.
g. The example is contrived. It is possibly acceptable as a classroom exercise at the conceptual level only, it breaks down upon entering the logical level, where Predicates are demanded. Which is where OP was stuck, and my application of Logic solved
h.stable of able horses.
A (not equivalent) rendition in IE notation
There is no equivalent in IEEE because it is insane, and IEEE does not allow insanity.
i. Re IEEE new symbol
It definitely does not need the insanity of an optional set of Categories. We are not about to change something that has been established, and remains unchanged (truth does not change) for sixty years. We do not need to add a crippled horse to the
----it needs a name and definition first.
5. Incomplete Categorization and Non-Exclusive Child Entities
----
a. Again “both” is descriptive, not necessary for logic.
Likewise “neither” and “nor”.
When stated as Predicates those words will disappear.
b. IDEF1X[Incomplete] is already defined, it needs no further definition.
There is no such thing as “Non-Exclusive” in IDEF1X, you need to name it and define it first, then give the pictures re what it looks like. Yes, sure, you can take the Predicates straight out of the IEEE[Non-Exclusive] definition, but then again,
c. Further, you can’t walk up to IDEF1X (as defined) and just add IEEE[Non-Exclusive]. Because IDEF1X has a **CLASSIFICATION** that has its own components, and IEEE has a **CLASSIFICATION** that has quite different components, eg. [Non-Exclusive]. Ifyou are going to change anything, you have to change that **CLASSIFICATION**, not just grab a component (**FRAGMENT**) from here and add it there.
d. the model top left as shown is illegal. A Generic with a single Category (the Category SET has one member) is a gross Normalisation error. For the given model, if a reference is used it should be [Subtype doc §4].started our interaction.
Therefore the model at top right is the only correct one.
I have a problem with your language. This is technical subject matter; science, wherein we have certainty and things are stated as true or false. It is not Modernist philosophy, wherein things are stated as tentative. You have gone soft, since we first
Also, due to the silly notion of “relation”, academics have to labour about the distinction between the entity and the “instance”, which is quite unnecessary. (What happened to the hilarious “tuple” !!!)generic cannot [be] a category, a category cannot be a generic.
<<<<
e.
Incomplete: an instance of the generic entity may exist without being an instance of any of the category entities.
Massively incorrect use of the word [be]. At no time does a generic [be] something other than what it is, a generic, and nothing but a generic. At no time does a category [be] something other than what it is, a category, and nothing but a category. A
In case you try to use the word [is], don’t, that is already established, and such a misuse would be insanity.humans.)
I think you are trying to say something like:
Complete: each generic is related to one category.
Incomplete: a generic may exist without a category.
____(Thus the SET of categories is incomplete.)
f.
IE notation does not have a concept of “incomplete categorization”Because it is logically ridiculous. It is not a lack or privation. Declaring it as such is a silly error, same as declaring that a virgin does not have a venereal disease as a privation. (It is only a privation to those who are sluts, not to normal
g. Collecting two errors (top left: Customer, Supplier) and trying to make a new concept out of it fails, and miserably. You need to correct the errors, and then of course, the new concept will disappear. Populism is ochlocracy; socialism; communism,it is anti-science.
h. You have not given the Predicates. If you do, you would see that it [g] fails.cannot be mutilated into a “basetype” that optionally hosts non-exclusive “subtypes” that IDEF1X does not have.
i.
Although not strictly necessary, in the [top] left model I would “collapse” the [two] incomplete categorization symbols into a single (non- standard) symbol (see below, left), as a matter of convenience, conciseness, and symmetry.
That remains a gross Normalisation error, it fails to recognise the concept of Subtype. The two optional entities remains separate optional entities wrt to the parent. The parent is not a Basetype for either Subtype, that hosts two optional entities,
Further [Customer] and [Supplier] cannot be said to have the same classification (that classifies some SET). Again, you are dealing with fragments (members of some set) while denying (or being unconscious of) the fact that the set is an atom, it has aclassification; a definition.
Since when should IT people care about “convenience” and “symmetry” ??? Should we care about empathy and sympathy ???example from the natural universe (trannies and other insane excluded as abnormal), where a basetype is a valid basetype, and has zero subtypes.
Errors are never symmetric.
----
6. Notation and Terminology
----
a.
Generic entity: An entity whose instances are classified into one or more subtypes or subclassifications (category entities). Syn: superclass; supertype. [ISO 31320:2, §3.1.72]
The “one” is false, because zero is permitted ala [Incomplete]
The “or more” is false (both sets of Categories are mutually exclusive). If you are addressing the row rather than the entity, then the word [entity] is totally incorrect.
I wouldn’t mention the synonyms, because they are incorrect.
I would state (remaining at the [entity] level):
± Generic: An entity that is classified into zero, one or more categories. [ISO 31320:2, §3.1.72]
b.
Category (entity): An entity whose instances represent a subtype or subclassification of another entity (generic entity). Syn: subclass; subtype. [ISO 31320:2, §3.1.21]
I would state:
± Category: An entity that is a classification of one generic
[ISO 31320:2, §3.1.21]
c. Predicates
Great. Not perfect but quite adequate for this exercise.
c.1. In general, do not use parent/child, use Generic/Category on the IDEF1X side, Basetype/Subtype on the IEEE side.
c.2. The missing Predicates are (IEEE side only, the IDEF1X side is still not clear):
Each basetype identifies the subtype
____ (because we can have an alternated Key, in which case it does not).
Exclusive basetype:
Basetype is discriminated by ( Discriminator ).
C.3. Minors. I suggest:
Children: instead use (Category, ...) or (Subtype, ...)
Non-Exclusive basetype: “one or more”: instead use “any of”
d. Now that we have the Predicates, and I can confirm precisely what you mean in the IEEE sets, I reject the two new IEEE sets outright, because they defy logic (reason). And of course the new IEEE symbols. If you challenge this, please supply an
You already know the reasons (logic) for this, they are further detailed in the latest edition of my [Nicola IDEF1X 2] doc. You are merging two discrete Facts into one non-fact (scrambled eggs).
Again, it is not for me to disprove your proposal, but for you to prove it, and you have not done so.
If you want to go into it a bit more deeply, a privation is not a thing, it is a lack of a thing. So if the deprived thing really exists, then it exists as a thing, not as a thing deprived based on a Generic. Therefore:
1. the “generic with zero categories” is not a generic but an ordinary entity
2. the categories are optional
--- you cannot have a set of one, or zero (except in hilarious theory, divorced from reality)
--- categories means a SET, at least two
--- the SET of categories is mandatory, not optional
3. the categories needs a generic to be categories of, which is not the ordinary entity
--- (if it were the entity, it fails [1]
e. The grid is good, the column headings are good. You need row headings. Also, move column 2 into position 3, it will make more sense.
f. I reserve my comments re the new IDEF1X sets and therefore the new symbols, because the definitions are progressing, still not complete.
Cheers
Derek
On Monday, 12 April 2021 at 17:23:37 UTC+10, Nicola wrote:
On 2021-04-11, Derek Ignatius Asirvadem wrote:
I do have a long response to your V3 doc
Looking forward to reading it.
On Wednesday, 14 April 2021 at 13:27:26 UTC+10, Derek Ignatius Asirvadem wrote:
[...]
e. The grid is good, the column headings are good. You need row headings. Also, move column 2 into position 3, it will make more sense.
On Thursday, 8 April 2021 at 04:51:55 UTC+10, Nicola wrote:
On 2021-04-07, Derek Ignatius Asirvadem wrote:
What I see is that both notations have deficiencies
Response please.
Since nothing appears to be forthcoming,
I have added a section to chapter 5.
Minor wording changes to the previous content in ch 5 (ie. only ch
5 has changed).
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
After all that explanation, hopefully you can see there is no
deficiency in the IEEE notation.
Otherwise I will take it that my explanation has closed the
issue, that there is no deficiency in the IEEE notation.
On Friday, 16 April 2021 at 18:09:33 UTC+10, LP wrote:
On 2021-04-16, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote: Response please.
Since nothing appears to be forthcoming,
Be patient, I am very busy currently, but I have read your updated
document.
I will reply to your comments in the other post, but they will be only
minor remarks. The matter is settled for me. I agree with you that there
is no need to "fix" IEEE notation, and that IDEF1X's is broken (but the latter was my point to begin with).
On Monday, 19 April 2021 at 02:16:52 UTC+10, LP wrote:
Derek,
rather than replying point by point, I have uploaded a new document:
https://jirafeau.net/f.php?h=3IaydAN-
This should address your comments in your previous posts.
Thanks for helping me clarifying some aspects of generalization
hierarchies.
As I said, for me the matter is settled. I welcome your comments (or by others), but I do not plan to perform any further significant revisions.
For what it is worth, here are the definitions I give GUI developers (employed by the customer, seconded to me for the duration of the project):
Just one eg. In OO/ORM it is a “generalization hierarchy”, whereas in Data Modelling where “hierarchy” already has a specific data-centric meaning, it is not an hierarchy, it is a treatment of sets, what you might call “sibling” sets. There
All the definitions I have used are on page 2. Although not completely formal, they are accurate enough for understanding the document.
I have
added predicates throughout: hopefully, that will prevent further misunderstandings.
For understanding. In my page 3, the Predicates given in text form.
6. Summary and Comparison with IEEE notation-------------------------------------------------------------------------------
IDEF1X <all four classes>the second is redundant because the first states it (its existential reality, dependence), and does so more precisely.
Specialization is an exclusive subtype [of] 1 Generic
Specialization is 1 Generic
IDEF1X <all four classes>
Generic is { an exclusive | a non-exclusive } basetype of {Subtypes}
Generic is <Quantity> of {SpecializationList}
Generic is <Quantity> of {SpecializationList}
IDEF1X <all four classes>The first Predicate clearly indicates dependence, thus the second is redundant.
Specialization is { an exclusive | a non-exclusive } specialization [of] 1 Generic
Specialization is dependent on 1 Generic
IDEF1X <all four classes>The predicate headings:
Genericshould be:
Specialization
<Generic>
<Specialization>
is discriminated by Discr [not shown]
0 Definitions-----------------------
“Categorization” is avoided because it may be taken to imply mutual exclusivity (in IDEF1X, the categories within
I accept that the issue is closed for you, sure, but for me, it is the
same old issue of tightening loose definitions, and ongoing. I hope
you don’t mind, it is not possible for me to give directions that are
not precise, and that takes time and space.
This doc is frequently used, it is generally viewed as authoritative: __https://people.cs.vt.edu/~kafura/cs2704/generalization.html
For what it is worth, here are the definitions I give GUI developers (employed by the customer, seconded to me for the duration of the
project):
Generalisation
the determination and organisation of a set of abstractions that have common properties
Specialisation
each abstraction in a set of generalised abstractions, representing its distinct properties.
Just one eg. In OO/ORM it is a “generalization hierarchy”, whereas in Data Modelling where “hierarchy” already has a specific data-centric meaning, it is not an hierarchy, it is a treatment of sets, what you
might call “sibling” sets. There is nothing hierarchical about it.
I have
added predicates throughout: hopefully, that will prevent further
misunderstandings.
I would say it is important to state that IDEF1X allows mathematical,
logical definition of Relational database elements, in a graphical
form, and since Relational means FOPC Predicated, the graphical model embodies such ... therefore the Predicates given in text form are
duplicates, to assist novices. Or in some case [in your doc] where
a model is not given, to provide clarity.
For understanding. In my page 3, the Predicates given in text form.
For brevity, when two binary Predicates have the same two Variables, rather than stating them separately:
__ <Variable_A> <Predicate_1> <Variable_B>
__ <Variable_A> <Predicate_2> <Variable_B>
they are stated:
__ <Variable_A> <Predicate_1> {and|,} <Predicate_2> <Variable_B>
<<
That may or may not suit your purpose.
-------------------------------------------------------------------------------
6. Summary and Comparison with IEEE notation-------------------------------------------------------------------------------
a.
IDEF1X <all four classes>the second is redundant because the first states it (its existential
Specialization is an exclusive subtype [of] 1 Generic
Specialization is 1 Generic
reality, dependence), and does so more precisely.
b.
IDEF1X <all four classes>
Generic is { an exclusive | a non-exclusive } basetype of {Subtypes}
Generic is <Quantity> of {SpecializationList}
In my lexicon of Relational Predicates, the second is a declaration of
a discrete Fact (the relation) and thus gives the list, the first
should be a declaration about the discrete Fact of Generic (its
existential reality) alone. (For clarity, refer to my §3.1):
- the duplication of the list is an error
- the “of” is ambiguous
Therefore it should be:
__Generic is { an exclusive | a non-exclusive } basetype
Generic is <Quantity> of {SpecializationList}
c. Ditto for IEEE <both classes>.
d.
IDEF1X <all four classes>The first Predicate clearly indicates dependence, thus the second is redundant.
Specialization is { an exclusive | a non-exclusive } specialization [of] 1 Generic
Specialization is dependent on 1 Generic
e. Ditto for IEEE <both classes>.
f.
IDEF1X <all four classes>The predicate headings:
Genericshould be:
Specialization
<Generic>
<Specialization>
f.1. Two instances of “subtype” under IDEF1X should be “specialisation”.
f.2. Four instances of “basetype” under IDEF1X should be “generic”.
g. Last but not least, each of the six sets needs a clear and
unambiguous title.
h.
is discriminated by Discr [not shown]
In IDEF1X it *is* shown, therefore it is shown in IEEE (same as yours
but in the font used for columns).
My Extension shows it: either with the symbol (typically at the Entity level); or in the column, which must be designated [D] (typically at
the Key and Attribute level).
-----------------------
0 Definitions-----------------------
What you are trying to do is two separate things:
- validate IDEF1X Incomplete
- introduce Non-Exclusive
I suggest you make that clear (eg. as per my §5.3 or similar), rather
than attempting to do both together without clarity ... which leads to
some sort of combined form.
----
“Categorization” is avoided because it may be taken to imply mutual
exclusivity (in IDEF1X, the categories within the same cluster are
mutually exclusive by definition).
That is not true. You are explicitly rejecting the IDEF1X definition
and classification of Category, which quite definitely is mutually
exclusive. (There is no problem with you adding a new classification
to allow non-exclusive.)
Specialization: an entity that models a proper subset of the
instances of another entity. For example, Employee is
a specialization of Person, because the set of all employees is
a subset of the set of all individuals (and there are individuals who
are not employees).
Whoa. I do understand that you are trying to arrive at a combined
form of definition.
But: - this sort of redefinition makes it (both the error of
a combined form, and the definition) absurd.
- a redefinition of an existing, well-established term has to be
rejected outright.
The example given is strictly *NOT* a specialisation in the sense that
people would understand, therefore you are perverting that sense, in
order to generalise it, in order to include Incomplete.
The truth is, Employee is a Person because it is Dependent on Person,
not because it is a “specialisation” of Person (It is not).
By the perverted definition, *ANY* Dependent entity is
a specialisation of the parent. Which is hysterical. In Order DM
Advanced:
__ https://www.softwaregems.com.au/Documents/Documentary%20Examples/Order%20DM%20Advanced.pdf
according to your definition, PartyAddress; OrderSale; OrderSaleItem; OrderPurchase; OrderPurchaseItem; PartVendor are each
“specialisations” of Party, which is ridiculous and false.
And again, while it is true in the simple Relational sense that each PartyAddress; OrderSaleItem; OrderPurchaseItem; PartVendor [is a]
Party, it is not true in the “generalisation/specialisation” sense. Suburb is certainly not a Country, but yes, it depends on; belongs to, Country.
proper subsetSince when is the empty set a proper subset ??? The freaky fantasy is
not even a set, let alone a proper subset.
Generic entity: an entity that has at least one specialization. InThe definition is fine, but the example is horrendous, supply a valid example.
the example above, Person is a generic entity.
This may be a good point at which to declare the differentiation:
- Total = at least two specialisations
- Partial = zero; one; or more
- Generic = at least one
- Specialisation = zero; one; or more
All occs of “Specialization cluster”Generalisation cluster.
We also say that each employee is a person.No, we do not. That perverts the well-established understanding of
the [is a] relation.
Note, though, Employee and Person are two distinct entities (different sets).
??? Are not all depicted sets distinct sets; distinct entities.
Footnote [2]Can be removed.
Total, PartialYes, I see where you are going, I have no argument. But they are not commonly understood or “commonly accepted definitions”. The words in English are way too general, they cannot be used as specific in an application.
Partial specialization cluster: a specialization cluster that is not total. >> Partial [generalisation] cluster: a [generalisation] cluster that is not total.In a section for Definition, I would not state that (what it is not). I would state what it is.
Exclusive specialization cluster: a specialization cluster such that,Great for a theoretician. What about saying “one of”, so that implementors can understand it.
at every time, Si \ Sj is the empty set for all i ≠ j.
Exclusive [generalisation] cluster: a [generalisation] cluster such
that, at every time, Si \ Sj is the empty set for all i ≠ j.
A basetype is always a generic entity, but a generic entity is not
necessarily a basetype
Cliché, cabalist nonsense, not fit for a technical document. It means nothing: a specialisation *IS ALWAYS** -<is>- relative to its parent,
and a generic *IS NOT ALWAYS** -<is>- any of its specialisations.
Where you are trying to differentiate Basetype vs Generic, just state
that: Basetype is Total; Generic is {Total|Partial}
Total specialization clusters (i.e., subtyping) always have at least
two specializations (subtypes)
[Whereas] a Total [generalisation] cluster (i.e., Subtype cluster)
]always[ has at least two specialisations (subtypes) ... a Partial generalisation cluster allows zero or one specialisation.
What is your definition of a zero-specialisation ?
Doc updated.
- I have added §1.6 in response to your V4 diagrams, but the argumentation is in this post.
- Date at the bottom of each page informs you if it has been updated.
____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
On Tuesday, 20 April 2021 at 07:18:54 UTC+10, LP wrote:
For understanding. In my page 3, the Predicates given in text form.
For brevity, when two binary Predicates have the same two Variables, rather than stating them separately:
__ <Variable_A> <Predicate_1> <Variable_B>
__ <Variable_A> <Predicate_2> <Variable_B>
they are stated:
__ <Variable_A> <Predicate_1> {and|,} <Predicate_2> <Variable_B>
<<
That may or may not suit your purpose.
That is deliberate, to have one simple predicate per line and facilitate comparisons.
-------------------------------------------------------------------------------
6. Summary and Comparison with IEEE notation-------------------------------------------------------------------------------
a.
IDEF1X <all four classes>the second is redundant because the first states it (its existential reality, dependence), and does so more precisely.
Specialization is an exclusive subtype [of] 1 Generic
Specialization is 1 Generic
Again, that is deliberate, for better comparisons when alternative
models or notations are proposed. For now I have left them untouched,
but I may remove them in the future.
b.
IDEF1X <all four classes>
Generic is { an exclusive | a non-exclusive } basetype of {Subtypes}
Generic is <Quantity> of {SpecializationList}
In my lexicon of Relational Predicates, the second is a declaration of
a discrete Fact (the relation) and thus gives the list, the first
should be a declaration about the discrete Fact of Generic (its existential reality) alone. (For clarity, refer to my §3.1):
- the duplication of the list is an error
- the “of” is ambiguous
Therefore it should be:
__Generic is { an exclusive | a non-exclusive } basetype
Generic is <Quantity> of {SpecializationList}
Ok. Before I change that, I need a clarification.
Let's say a music school employs teachers, and needs to keep track of
male and female teachers. Also, each teacher is a violinist, a pianist,
or both. Would you state both the following then:
Teacher is an exclusive basetype
...
Teacher is a non-exclusive basetype
...
? That sounds contradictory.
f.1. Two instances of “subtype” under IDEF1X should be “specialisation”.Why?
Specialisation is an exclusive subtype 1 Genericbut IDEF1X:
Specialisation is a non-exclusive subtype of 1 Generic
<Category> is an exclusive category 1 <Generic>or OO/ORM:
<Category> is a non-exclusive category of 1 <Generic>
<Specialisation> is an exclusive specialisation 1 <Generalisation> <Specialisation> is a non-exclusive specialisation of 1 <Generalisation>
If anything, it should read "total specialization" then (which is
the same as "subtype").
f.2. Four instances of “basetype” under IDEF1X should be “generic”.
Ditto. It is "basetype" in the same sense as it is "basetype" in
reference to the IEEE symbol.
When I meet a new friend, somewhere in the conversation it becomes obvious that he is an atheist and I am not. Due to their insecurity, he has to make some demeaning declaration about God. So I ask him my single question that destroys the heavily-
g. Last but not least, each of the six sets needs a clear andNoted, yet to be added (some other things need to be resolved first).
unambiguous title.
-----------------------Yes, it's an attempt.
0 Definitions-----------------------
What you are trying to do is two separate things:
- validate IDEF1X Incomplete
- introduce Non-Exclusive
Yes.
I suggest you make that clear (eg. as per my §5.3 or similar), rather than attempting to do both together without clarity ... which leads to some sort of combined form.Not sure what you mean by "combined form". You have understood what I am trying to do.
“Categorization” is avoided because it may be taken to imply mutual >> exclusivity (in IDEF1X, the categories within the same cluster are
mutually exclusive by definition).
That is not true. You are explicitly rejecting the IDEF1X definition
and classification of Category, which quite definitely is mutually exclusive. (There is no problem with you adding a new classification
to allow non-exclusive.)
I stand by my statement above, which is according to the published standards.
Anyway, "category" is banned, because we do not agree on
its meaning.
Specialization: an entity that models a proper subset of the
instances of another entity. For example, Employee is
a specialization of Person, because the set of all employees is
a subset of the set of all individuals (and there are individuals who
are not employees).
Whoa. I do understand that you are trying to arrive at a combinedAh ok, now I understand what you mean above. I beg to disagree: my definitions are quite the opposite of "combined"; they are quite
form of definition.
orthogonal.
Specialization [...]
But: - this sort of redefinition makes it (both the error of
a combined form, and the definition) absurd.
- a redefinition of an existing, well-established term has to be
rejected outright.
The example given is strictly *NOT* a specialisation in the sense that people would understand, therefore you are perverting that sense, in
order to generalise it, in order to include Incomplete.
Is there any other term you would accept for that concept? Or is the
concept itself absurd?
On Tuesday, 20 April 2021 at 20:35:12 UTC+10, Derek Ignatius Asirvadem wrote:a incoherent article.
Total specialization clusters (i.e., subtyping) always have at least
two specializations (subtypes)
[Whereas] a Total [generalisation] cluster (i.e., Subtype cluster) ]always[ has at least two specialisations (subtypes) ... a Partial generalisation cluster allows zero or one specialisation.
At least one.
Yes, I understand that. I am saying, and I have detailed in previous posts, and in my response doc §3.1.1/1, a Subtype Set of 1 is illegal, logically incoherent. Therefore if you allow that, I have no choice but to reject any definition that relies on
Again, I say, you are trying to validate the incoherent IDEF1X{Incomplete] which is impossible because you cannot validate insanity. With “at least one”, you have realised that. Great. All you have to do is declare the difference re IDEF1X defns:Partial is not Incomplete because Incomplete is incoherent, and the correction is coherent. Crack open the Proseco.
Likewise, here you are trying to validate the set of one, which is not a set.
The challenge: define the commonality in the set of one, that can be extracted into the Basetype. And define the remainder that is distinct.
At least one.
either my Subtype doc or my response doc) is the subtyping, which they call Generalisation Hierarchy. Note again, it is not the same thing, it is that which they can understand in Subtypes, due to the similarity in Objects in some parts.I admit then that my understanding of [is a] is lacking. Can you please elaborate on this point? How should the [is a] relation be understood if not as above?We also say that each employee is a person.No, we do not. That perverts the well-established understanding of
the [is a] relation.
1. [...]
2. [...]
3. Third, we can now get into the OO/ORM perception of Relational elements. While they completely destroy most of it due to the disability mentioned above, the one thing they immediately understand in small part (ie. not the definitions I have given in
So yet aga
[...]
Further, the actual Predicates refute the absurd proposition.
[...]
Likewise, logic is the form, your proposal is the matter, it fails logic. [...]
Ok then, it is a major mistake in conceptualisation. Because you are addressing the fragments, not the atoms.
Well, son, IDEF1X Categorisation{Complete|Incomplete} already exists,
and has for forty years, and it is the doc that you are intending to
apply amendments to, the source doc, if you will. So I would stick to
that, which means you don’t have to supply definitions, you can just
refer to the Standard.
Yes, it is broken. So then you have to first define and apply the resolutions.
Then define only your new proposal.
I am saying, ditch the whole thing, go with the historic path that
many implementors have trodden: accept the Standard;
define the resolutions; add to it.
On Thursday, 22 April 2021 at 06:27:56 UTC+10, LP wrote:
On 2021-04-20, Derek Ignatius Asirvadem wrote:
anything derived from it, anything relying on it, is absurd.
[...]
Further, the actual Predicates refute the absurd proposition.
[...]
Likewise, logic is the form, your proposal is the matter, it fails logic. [...]
Ok then, it is a major mistake in conceptualisation. Because you are addressing the fragments, not the atoms.
Well, son, IDEF1X Categorisation{Complete|Incomplete} already exists,
and has for forty years, and it is the doc that you are intending to
apply amendments to, the source doc, if you will. So I would stick to that, which means you don’t have to supply definitions, you can just refer to the Standard.
Yes, it is broken. So then you have to first define and apply the resolutions.
Then define only your new proposal.
Not quoting the rest of your post, it is not necessary. I have
understood that what I was stubbornly trying to do is a hopeless
endeavour. My premises and my expectations were wrong.
I am saying, ditch the whole thing, go with the historic path that
many implementors have trodden: accept the Standard;
I think that is the way to go then.
define the resolutions; add to it.
That would inevitably end up where you are at. I can skip the effort of going through the same road (the effort to get to this realization was already substantial enough), and join you directly at the light at the
end.
Only one minor detail: I have tried to track the origin of the IEEE
symbols for subtyping, but I don't seem to be able to find much
information. AFAIK, Information Engineering originally used nested boxes (derived from Barker's notation?). Who was/is using it apart from you
and ERwin? You keep mentioning a standard, but there are dozens of IEEE standards: any reference?
On Thursday, 22 April 2021 at 06:27:56 UTC+10, LP wrote:
On Thursday, 22 April 2021 at 06:39:53 UTC+10, Derek Ignatius Asirvadem wrote:
On Thursday, 22 April 2021 at 08:40:00 UTC+10, Derek Ignatius Asirvadem wrote:
On Thursday, 22 April 2021 at 06:27:56 UTC+10, LP wrote:
Only one minor detail: I have tried to track the origin of the IEEE
symbols for subtyping, but I don't seem to be able to find much information. AFAIK, Information Engineering originally used **nested boxes**
(derived from Barker's notation?).
[ explanation, skipped ]
The nested boxes was classic Hierarchic Paradigm ...
Nested boxes meant the designer was using a HDBMS ...
An Hierarchic file consisted of one parent type-of-record, and many child types-of-record ... implemented as a continuous series of records, from the parent record through one bunch of child records; then the next bunch; then the next parent; etc ...
Whereas in the NDBMS, each type-of-record was a separate file, and we had two types of file: Master (key access) and Variable (linked-list chain from the Master). Therefore no nested boxes.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 407 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 13:04:15 |
| Calls: | 8,554 |
| Calls today: | 6 |
| Files: | 13,219 |
| Messages: | 5,925,468 |