From Newsgroup: comp.databases.theory

On 2021-03-31, Nicola <nicola@nohost.org> wrote:

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.

More precisely, it is inconsistent with IDEF1X's ISO (or FIPS) standard.

In a previous post I wrote that ERwin's (i.e., Bruce's) interpretation
is not sound. That is not correct. The interpretation above is well
defined. It is not entirely satisfying, though, because it introduces an exception in the interpretation of the complete categorization symbol:
the "completeness" (in the sense that each instance of the parent must
be an instance of one of the children) applies to the whole cluster
*set*, as opposed to each single cluster, when clusters have one child.
For instance, the figure from ERwin's Guide has two single-child
clusters:

+-----------+
| P |
+-----------+
| |
+--- ---+
| |
O O
----- -----
----- -----
| |
+---------+ +---------+
| A | | B |
+---------+ +---------+

and the assumed interpretation is that every instance of P must be an
instance A or of B (or both), as opposed to "every instance of P must be
A, and every instance of P must be B". The latter cannot be expressed
under ERwin's interpretation, but it not very important, because if
"every instance of P is always an instance of A" then A can be absorbed
into P.

IDEF1X's standard, on one hand, removes this exception, by stating
explicitly that, in each complete categorization cluster, each instance
of the parent must always be an instance of one of the childrenrCoeven
when the cluster has only one child.

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).

I find it somewhat surprising that this aspect has not been clarified
and addressed in the standard, which was last revised in 2019.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
Thanks for yours.

On Thursday, 1 April 2021 at 02:54:53 UTC+11, Nicola wrote:

Summary answer.
1. We had subtypes prior to RDBMS and IDEF1X. We had diagrams that were primitive compared to IDEF1X, but they worked perfectly well for the DBMS that we did have. We used IEEE notation.
2. So when IDEF1X was published, no one used {Complete|Incomplete}. [Technically, since one could always add a subtype in the future, every cluster might be Incomplete!].
3. The first (and only compliant) product ERwin provided both notations from day one.
4. ERwin Methods Guide was freely available, and even people who did not have ERwin used it as the proper definition for IDEF1X (rather than purchase).
I concur that the IDEF1X Notation for both Subtypes and Relations is inferior. Therefore, forget about the thing that does not work, that is known to be inferior, that only academics use, and use the thing that does work, that practitioners have used since 1983, the IEEE notation. For both Subtypes and Relations. Every DM that I am aware of used IEEE (except yours, but you are earnestly trying to understand and use the Standard as is, rather than the modified Standard that practitioners use).
----
Nevertheless, I want to make sure that this particular item is resolved, because absolutely everything that occurs in reality can be modelled under FOPC; the /RM/; and IDEF1X. Refer to my Subtype doc for details and specific examples re what I state here.
First, absolutely and always, think of the Basetype+Subtype pair as a single LOGICAL row (I wonrCOt use silly terms such as rCLtuplerCY). Rather than as parent-child (which it is in physical, SQL terms).

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.

... each instance
of the parent must always be an instance of one of the childrenrCoeven
when the cluster has only one child.

A cluster that has only one child is a Normalisation error. It is not a Basetype-Subtype but an optional column and therefore an optional table.
If it is not optional, then it is as you say rCLabsorbedrCY into the parent.

I find it somewhat surprising that this aspect has not been clarified
and addressed in the standard, which was last revised in 2019.

Yes. That is because the Date & Darwen freaks messed with it, and they pushed the totally obsolete IDEF1X notation over the IEEE notation. Same as you did before our discussion. Academia sucks dead sows. Even the notion of rCLIdentity-TyperCY as an alternative to Keys, is hysterically backward, but hey, it now rCLvalidatesrCY the OO/ORM approach.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Another first-hand historical perspective is provided by:

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

I'll come back to the rest at a later time.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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.

No, no, no. Those ARE academics talking. Rather famous ones.
Those articles reinforce my declarations, not yours ! Each has a great understanding of a very narrow field (of research) and each remained clueless about the other fields, even related fields. And far removed from the rCLindustryrCY and rCLusersrCY.
At Cincom, let me assure you, we were very aware of that, which is typical in large corps such as IBM, and sought to avoid that sort of problem by having a small team made up of specialists, in one location. TOTAL for DEC/PDP was written by a team of four. I came to Australia to write the rCLnext generationrCY TOTAL for DEC/VAX with full ACID, our team was five. We did it in 18 months, it was named ULTRA-DBMS. (Later, Cincom missed the Relational bus, and got side-lined.)
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-02, Derek Ignatius Asirvadem <derek.asirvadem@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 rCLRelational DatabaserCY promote instead 1960rCOs 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 canrCOt say that and also
say rCLMy main complaint with IDEF1X is the treatment of generalization hierarchiesrCY.

So what, if anything, is your remaining complaint re rCLgeneralization hierarchiesrCY.

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.

Regarding subtyping, my critique is specifically on the notation given
in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
Subtype".

What rCLcrossingrCY ???

I did not express myself clearly. I meant the IDEF1X (not IE) notation
at the intersection of the "Complete" column and "Inclusive Subtype"
row.

You canrCOt use both IDEF1X and IEEE notation in any single model, they cannot be mixed. They are exclusive. You canrCOt go back-and-forth
either.

Sure, sorry if what I wrote seemed to imply that.

Sorry. I donrCOt 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 rCLissuerCY 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

I 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.

Since we are discussing IDEF1X, you might be interested in this Q&A: ____https://stackoverflow.com/q/4132044/484814

Interesting reading, thanks.

Nicola

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-02, Derek Ignatius Asirvadem <derek.asirvadem@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 PastTime (P) must
be a PasttimeHobby (A) or a PasttimeSport (B), or both.

Using standard IDEF1X symbology, 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.

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.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-04, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

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

I am not in denial of anything; I can read your data models without
issues, for instance, and I am not asking you or anyone to use a "more standard" notation for the sake of it.

That said, yes, I prefer to stick to IDEF1X notation; but I have no
problem diverging from the standard if I need to.

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 of the parent entity an instance 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 rCLtwo clusters with one child eachrCY 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 rCLStandardrCY, 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.

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.

While I sympathize with your position and I accept the UML analogy for explanation purposes, I think I have little or nothing to reply to or
disagree with you about UML or ORM (by which I assume you mean Object-Relational Mapping).

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).

Happy Easter,
Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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 ?

Why on earth would I implement something other than what I know the data to be, which knowledge I obtain by modelling it ? Why would I waste time modelling data if I did not have an implementation intent ?

Ok, fine. It is different to you. Why ?

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).

Thanks.
Fixed.

By the way, I have given you two ways of transacting a 1::1-to-n relation.

Happy Easter
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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.**

Well it does. It is fair enough that the academics think in terms of fragments, isolated from the context in which it exists.
But that is not the real world, in which things are integrated, atoms are not fragmented. We do not want to entertain something in theory that is not possible in implementation. A database is a single recovery unit. As long as one is using a genuine SQL platform, one has ACID Transactions. The following Predicates for the Basetype::Subtype relation:
__ Basetype is one of {Subtype1|Subtype2|...} -- Exclusive
____ Cardinality 1::1
__ Basetype is any of {Subtype1|Subtype2|...} -- Non-Exclusive
____ Cardinality 1::1-to-n
are implemented by a Constraint (Declaration in SQL). Transactions are declared Constraints (Methods in UML-speak), that provide ACID (if the SQL Platform provides ACID). They form the Database API.
That [SQL platform] gives us confidence that the implied Database Integrity; the Cardinality of 1::1 or 1::1-to-n is possible, and quite ordinary.
Corollary: it is not possible to implement such Database Integrity on freeware and other mickey mouse program suites (they cannot be called rCLplatformsrCY), that do not have ACID and fraudulently use rCLSQLrCY in the label.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-04, Derek Ignatius Asirvadem <derek.asirvadem@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

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.

By the way, I have given you two ways of transacting a 1::1-to-n
relation.

Noticed that. They look good to me.

Nicola

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-05, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

There are two orthogonal aspects in a generalization hierarchy:

I donrCOt 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 rCLNon-ExclusiverCY 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 canrCOt. 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 rCLincomplete/completerCY.

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.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-05, Derek Ignatius Asirvadem <derek.asirvadem@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.

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 ?

Never. Not by you, either :-)

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-04, Derek Ignatius Asirvadem <derek.asirvadem@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, reuse as you see fit, or put on your
site.

Nicola

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

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

There is a problem with that. Actually two. First, let me confirm that my docs are in the public domain, and you are free to use them. But a copyright notice generally means rCLuse as isrCY and rCLif used, you must include the copyright noticerCY. In these days of the internet, that means, most people refer to the doc. Cut-paste is frowned upon, because (a) it can be misused, and (b) the such content is removed from the context.
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. This damages you more than it does me. I have no comment whatsoever re the matter (material) in your doc. I am only addressing the use of my graphics under your headings, your context. I am not saying you are dishonest (a Straw Man is always dishonest), but that in the Modern rCLsciencerCY using the Straw Man is a well established method for rCLargumentationrCY, and you are schooled in it; indoctrinated in it, and you are using it unconsciously.
Think about this. In reality, a horse exists. There are pictures of horses. You have a concept, which is an abstraction, not real, it does not exist in reality (I am explaining something, not commenting on your proposition). LetrCOs call it ABCDEF. So you write it up, and present ABCDEF-1; ABCDEF-2; etc. And under each section, you attach a picture of a different horse.
You might have mulled over thee ABCDEF for years, it might be very rCLrealrCY to you, but it does not exist. It is a Reverse Straw Man because you have substituted something real for something false (whereas the missionary Straw Man substitutes something false for something real, and then burns it). Because the content that has been substituted belongs to me, it is I who has the task of burning it. Sorry.
You cannot use good graphics under those headings, it is a mis-representation. That is all. Please feel free to re-issue your doc with references [not cut-pastes] to my doc.
This is what respectful correction looks like:
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20Non-Problem%20Proposal%20-%20Response.pdf

Feel free to add your comments,

If you do not mind, I would rather not. I am very happy to engage with you on all subject matter related to Relational data science, and I would like to maintain that friendliness. I am happy to fulfil your requests, whether answering questions, or providing decent commentary. But your doc, what you are trying to say, is incoherent. Right now there is no problem in the use of IDEF1X, but given your definition thus far, you appear to have created one, and a complex solution to go with the non-problem. I canrCOt say for sure because the definition is poor.
Further, your intent, the final goal, your agenda, is not declared (but implied).
Therefore I would ask you to excuse me from that request, this one time.
If you care to progress the work to the point of making a coherent proposal, I would be happy to comment. Obviously, prior to that, we can discuss it in this thread, to afford that progress.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-07, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

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.

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.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-07, Nicola <nicola@nohost.org> wrote:

Anyway, here is a revised document (with references this time):

Fixed a typo:

https://jirafeau.net/f.php?h=1WA2Cs0R

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-07, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

Responding to issues in the doc only.

a. Re links. It seems in each instance, the entire text box is rCLhotrCY, not just the words in rCLhotrCY colour and underlined.

Bug. Fixed.

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 ?

Exactly the same. It's one of the very few additions to ISO 31320:2
compared to FIPS 184.

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

That is (min parent):(max parent)-(min child):(max child). But I am not morbidly attached to it. Changed.

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 rCLSubtyperCY in IDEF1X. Use rCLgeneralisationrCY and rCLcategoryrCY throughout, to be faithful to the IDEF1X terminology.

Ok.

2. There is no such thing as rCLExclusiverCY rCLSubtypingrCY in IDEF1X.

ISO 31320:2, -o3.1.21 (emphasis mine):

"category entity: An entity whose instances represent a **subtype** or subclassification of another entity (generic entity). Syn: subclass; **subtype.**."

-o9.6.1.2 (again, emphasis mine):

"Since an instance of the generic entity may not be an instance of more
than one of the category entities in the cluster, the category entities
are **mutually exclusive**".

I suggest remove the page.

Overruled. That example is good as it isrCoexcept perhaps for terminology, which I have updated.

Use rCLgeneralisationrCY and rCLcategoryrCY
throughout, to be faithful to the IDEF1X terminology.

Sustained.

(Subtype; Exclusive, are IEEE terms.

Well, IEEE does not hold a trademark, I guess. As witnessed above, other standards use them, as well.

Basetype; Non-Exclusive are my
corrections to incorrect ERwin terms.)

I agree that "Non-Exclusive" is more accurate than "Inclusive". I do not
recall what term ERwin uses instead of "Basetype".

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 donrCOt agree with your definition (yellow panel in the middle).

Simplified.

- declarations SUCH AS rCLbusiness party and a customer must be treated
as a single logical unitrCY are valid for IEEE Subtypes, I donrCOt 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.

- in the example, the declaration rCLbusiness party and a customer must
be treated as a single logical unitrCY violates (a) logic, and (b)
IDEF1X Categories.

You are quoting the unqualified sentence.

--- rCLwhen the business part[y] is a customerrCY is contrived.

That completes the sentence above. But ok, it's contrived.

- the declaration rCLcustomer and business party are the same entityrCY 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.

- Finally, a Category with a single member is a gross Normalisation
error, it is corrected by making it an Optional Attribute.

Why is that? To me it looks perfectly fine.

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.

A Business Party is 0-to-1 Organization. Why does that not make it an
optional fact of Business Party?

4-Non-Exclusive Subtyping

a. There is no such thing as rCLNon-Exclusive SubtypingrCY in IDEF1X.

This is the issue I originally pointed out in IDEF1X treatment of generalization.

I donrCOt know what the IDEF1X equivalent of rCLNon-Exclusive SubtypingrCY would be, or what you think it would be, thus I canrCOt help you there.

Exactly, that's not clear. That's where I find IDEF1X notation lacking.

4-Partial Specialization with Mutually Exclusive Child Entities

a. Categorisation, not Specialisation.

b. Re the rCLNicola IDEF1XrCY link. Goes to my doc that supports the
entire discussion, progressively: I donrCOt 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.

Yes, I am referring to the latest revision of your document.

I have simplified the document a bit. Note that I have also reordered
the sections:

https://jirafeau.net/f.php?h=180L-e4H

g. The new symbol.
Text box on right. I donrCOt understand how you can apply rCLIncomplete specialisation [Categorisation]rCY 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.

The classifications are not "totally unrelated". They are strictly
related, and with small changes, they are equivalent, as I said, in the
sense that they represent the same first-order predicates. If you are
not convinced, show me a counterexample.

- Further, I do not understand how it is rCLthe same meaning asrCY the
IDEF1X Incomplete Category symbol.

Graphical rendition of the same first-order predicates.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-08, Nicola <nicola@nohost.org> wrote:

I have simplified the document a bit. Note that I have also reordered
the sections:

Here is v3, which is identical to v2, except that I have added a page
(-o6) with predicates, which I believe is what you will be more
interested in dissecting:

https://jirafeau.net/f.php?h=18wYFi9U

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Derek,

the last version I have linked in my previous post (v3) has the
predicates you have asked for.


On 2021-04-09, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

I think one item of difference, generally, re the 1997 revision of
IDEF1X, because (a) it validates the anti-Relational rCLidentity-basedrCY,

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 rCLExclusiverCY rCLSubtypingrCY in IDEF1X.

FIPS 184, ("Definitions" section):

-22.22 Entity, Category: An entity whose instances represent a sub-type or sub-classification of another entity (generic entity). Also known as
sub-type or sub-class.-+

-22.24 Entity, Generic: An entity whose instances are classified into one
or more sub-types or sub- classifications (category entity). Also known
as super-type or super-class.-+

-22.48 Relationship, Categorization (Category): A relationship in which instances of both entities represent the same real or abstract thing.
One entity (generic entity) represents the complete set of things the
other (category entity) represents a sub-type or sub-classification of
those things [...] Each instance of the category entity is
simultaneously an instance of the generic entity.-+

So, a category "is also known as" a sub-type.

p. 19 (emphasis mine):

-2Since an instance of the generic entity cannot be associated with an
instance of more than one of the category entities in the cluster, the
category entities **are mutually exclusive**. [...] an entity can be the generic entity in more than one category cluster, and the category
entities in one cluster **are not mutually exclusive** with those in
others [the male/female example follows, btw]-+

So, exclusive/non-exclusive is covered quite explicitly. More on that
below.

- declarations SUCH AS rCLbusiness party and a customer must be treated
as a single logical unitrCY are valid for IEEE Subtypes, I donrCOt 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:

-2C1.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, -o4 Optional Attribute[Group], Not Subtype:
rCLIf 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)rCY

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.

8. You have not exposed the Predicates, as you should.

Knock yourself out. Give the Predicates.

Give the Predicates.

See my document v3, -o6.

- the declaration rCLcustomer and business party are the same entityrCY 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.

So, except from your own documents, what else is not 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. 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!

c. To be clear, in any case (IDEF1X xor IEEE) Customer is definitely
not BusinessParty.

No answer ?

You are right. I'll defer further comments after you have seen -o6 of my document (v3).

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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:

Just clarifying, these comments pertain to V2 or V3 -o5, your IDEF1X notation model at top left, where Customer is a Category (of one member, which is a separate error):

Hence, a Business Party is
a generalization of a Customer (a Customer *is* a Business Party), although not all Business Parties are customers.

I 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, sorry, it is already dismissed.

Yes, of course, rCLa Customer *is* [always] a Business PartyrCY, but that is not a Predicate, and that connects two unconnected things. You are mixing up queries with Predicates.

Whereas in the model at bottom right, IEEE notation, is legal. There you can say *Customer is a BusinessParty*, and it is [the converse of] a Predicate.

Cheers
Derek

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-10, Derek Ignatius Asirvadem <derek.asirvadem@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.pdf

Ok, 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 -o4.7 is
a straw man: if you look at my document (-o1), 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.

Nicola

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
I do have a long response to your V3 doc, it is just not ready yet. Short answer for now, responding to youe post only.

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.pdf

Ok, I have understood your definitions and explanation, and how you
consider subtyping different from "proper subsetting" (for a lack of
a better term).

Well, it is the misunderstanding of terms (or having two different understandings for the one term) that has caused the slow progress, thus I am happy to sharpen them, and agree/disagree.
It is not rCLmyrCY consideration. It is what we had under the title of **Subtype**, before IDEF1X, which was served by IEEE prior to IDEF1X. As implemented by thousands in that day and age, in their {HDBMS, NDBMS, ISAM}, with and without DBMS-specific methods. Eg. in TOTAL (NDBMS) there was no addition because the [Master::Variable] structure allowed for it, I just wrote a one-page rCLhow torCY doc for the DBAs. Eg. in IMS they did have an additional structure for it (I donrCOt recall the name).
A word on Sets and Proper Subsets. While there is no problem at all in the treatmesnt of Sets in CoddrCOs /RM/ and CoddrCOs /RA/, and that can be articulated better, and that leads to a superior understanding of the data ... the detractors and pig poop eaters have buried those mathematical notions of Sets, through their promotion of a false rCLRMrCY, such that people are driven to fiddle and fart around with records or rCLinstancesrCY while ignorant of Sets. I point this out because you are coming out of the latter, but you are not yet in the former. I have not given you a discourse on Sets per the /RM/.

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.

Ok.

I will just point out that the example you have chosen for -o4.7 is
a straw man:

That is a silly charge.
There was a progression, and the choice of that example was yours from the outset. Granted in comes from my Subtype doc, which has been there for decades, in two forms (it is a teaching tool), and you referred to that example. Further, you have used the example, in two renditions, also as a teaching tool.
Charges have to do with intent, if there is no intent there is no crime. I am not trying to prove you right/wrong. DonrCOt take it personally. It is not a competition. I am trying to prove some declaration that you made (or that IDEF1X made) right/wrong, *AND* I supply the correct method which at the least, stands as counter-point for understanding.
For a long time, your goal was not clear, and we were arguing at the lower levels without understanding the [higher-level] intent.
There is also a small error (harmless to the argument) in that $4.7, which may be what you are zeroing in, or not. It will be corrected in the next edition.

if you look at my document (-o1), 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).

No problem at all to change the example (because the truth is the truth and it will destroy falsity anywhere). Next edition.
I donrCOt 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 you said, our posts have crossed paths: feel free to comment on my v3
(I am still interested),

It is coming.

although you have already brought forth the
arguments to dismiss my tentative IEEE addition.

Yes. Only the IEEE addition. Because it is formed on the basis of misunderstanding. So the discussion continues.
Not on the tentative IDEF1X addition. That cannot be evaluated properly because it is an open sore. So the discussion continues to close that. In case it is not clear, I closed the wound thirty odd years ago, with IEEE being maintained within IDEF1X with sharp definitions (as ERwin does [with horrible definitions]), but now you seek to return to the original, determine the issues, and provide a new classification. If and when that discussion clarifies the issues, then I can accept/reject your IDEF1X addition.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-11, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> 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 -o4.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 donrCOt 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.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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.

First, I am a bit busy, please forgive the delay.

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. The intent is to foster a deeper understanding:
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf

As mentioned, I have taken some of the content from my IDEF1X Qualification doc, transformed it for public use, into the Response doc.

I have run out of time tonight, and I did not complete the Response to your V3 doc. And Tuesday is very busy for me, I will get back to this on Wednesday. Thus I am giving you what I have completed right now.

I don't *need* an updated V3 from you, I am happy closing V3 as it stands, but you may wish to produce a V4.

Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

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.

A fair amount has changed. Even the pages in the previous version have small changes. The last-updated-date at the bottom of each page will inform as to whether it needs to be re-read.

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.

Sorry. ETA now Wednesday.

I will just point out that the example you have chosen for -o4.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.

No. I accept that from your perspective, ie. what you are attempting to portray, it is not the right example. But I was not attacking your proposal in that way, I was demonstrating a different thing, a more simple failure.
The latest edition of my Response doc makes that more clear.

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.

Understood. But intent can only be in the Author, who gives the argument. I am saying, the charge is only because you do not understand my intent (in that example), and you relate it to your intent (which it is not), and therefore assume a nefarious intent on my part (ie. to attack your V3$5 example).
The Straw Man issue is closed AFAIC.

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.

Please see if the examples in the latest edition suffice.

I donrCOt 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 (rCLorthogonalrCY 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 rCLdefinitionrCY of rCLcompleterCY 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.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

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 donrCOt 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 (rCLorthogonalrCY 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 rCLdefinitionrCY of rCLcompleterCY 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.

Especially when making a reference to a term in the Standard.
But that exposes something more serious. You canrCOt be relying on the original rCLdefinitionrCY of IFEX1X[Incomplete], and at the same time, deny IFEX1X{Incomplete,Complete} that hosts it. That is why we have the Four Laws of Thought, it determines and excludes insanity.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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

Page 10 updated just now.

Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

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.

Delivered:

On Wednesday, 14 April 2021 at 13:27:26 UTC+10, Derek Ignatius Asirvadem wrote:

[...]

Response please.
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.

Since nothing appears to be forthcoming, and you have been horrible at providing closure in the past, 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

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

After all that explanation, hopefully you can see there is no deficiency in the IEEE notation. Not since 1960 for IEEE, not since 1983 for IDEF1X using IEEE notation, not since 1993 for IDEF1X via ERwin. If you still see any rCLdeficiencyrCY in the IEEE notation, please identify. Otherwise I will take it that my explanation has closed the issue, that there is no deficiency in the IEEE notation.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-16, Derek Ignatius Asirvadem <derek.asirvadem@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 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

Got that.

After all that explanation, hopefully you can see there is no
deficiency in the IEEE notation.

Yes, the "deficiencies" exist only in IDEF1X notation.

Otherwise I will take it that my explanation has closed the
issue, that there is no deficiency in the IEEE notation.

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).

Nicola

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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.

Ok. Take your time. Since you have conceded, there is no rush now.

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).

Ok. I apologise again, for not making the distinction between IDEF1X as published (by an academic, and which is quite unuseable) vs IDEF1X as used (by practitioners, after resolving all issues). I beg your understanding, that thirty years of use of the latter had caused me to forget the former.
If you have any suggestions for my doc, let me know.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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.

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.

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.

Thanks for helping me clarifying some aspects of generalization
hierarchies.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-04-20, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> 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 donrCOt 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?

Regards,
Nicola

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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:

Posts crossed again, minutes apart !

Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

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.

__Nested boxes__ in pre-Relational File Definition diagrams, is not to be confused with:
__Nested Sets__

An abortion, straight from hell. A Record Filing System within a Record Filing system. Not only does this generate masses of duplication and break Normalisation rules, this fixes the records in the filing system in concrete.

Moving a single node requires the entire affected part of the tree to be re-written. Beloved of the Date, Darwen and Celko types.

The MS HIERARCHYID Datatype does the same thing. Gives you a mass of concrete that has to be jack-hammered and poured again, every time a node changes. Perfect for beginners who think that Lego is an implementation method in SQL containers.

Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

The discussion document. Page 8 has a couple of errors fixed. Added Hunter. __ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf

Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2