Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Wait! You have not been prepared! -- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2


devel / comp.databases.theory / Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

SubjectAuthor
* "Theoreticians” are Clueless about Relational DataDerek Ignatius Asirvadem
`* Re: "Theoreticians” are Clueless aboutNicola
 +* Re: "Theoreticians” are Clueless aboutNicola
 |`* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 | `* Re: "Theoreticians” are Clueless aboutNicola
 |  `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |   `* Re: "Theoreticians” are Clueless aboutNicola
 |    +* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |+- Re: "Theoreticians” are Clueless aboutNicola
 |    |`* Re: "Theoreticians” are Clueless aboutNicola
 |    | +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    | `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |  `* Re: "Theoreticians” are Clueless aboutNicola
 |    |   `* Re: "Theoreticians” are Clueless aboutNicola
 |    |    `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |     +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |     `* Re: "Theoreticians” are Clueless aboutNicola
 |    |      +- Re: "Theoreticians” are Clueless aboutNicola
 |    |      `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |       `* Re: "Theoreticians” are Clueless aboutNicola
 |    |        `* Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-RelDerek Ignatius Asirvadem
 |    |         +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |         `* Re: "Theoreticians” are Clueless aboutNicola
 |    |          `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |           +- Re: "Theoreticians” are Clueless aboutNicola
 |    |           `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |            +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |            +- Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-RelDerek Ignatius Asirvadem
 |    |            `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             +* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             |`* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             | `* Re: "Theoreticians” are Clueless aboutLP
 |    |             |  +* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             |  |`* Re: "Theoreticians” are Clueless aboutLP
 |    |             |  | +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             |  | +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             |  | +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             |  | `- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             |  `- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             +- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |             `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |    |              +- Re: "Theoreticians” are Clueless aboutLP
 |    |              `* Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-RelDerek Ignatius Asirvadem
 |    |               `- Re: "Theoreticians” are Clueless aboutLP
 |    `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
 |     `- Re: "Theoreticians” are Clueless aboutNicola Vitacolonna
 `* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
  +* Re: "Theoreticians” are Clueless aboutNicola
  |`- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
  `* Re: "Theoreticians” are Clueless aboutNicola
   +* Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem
   |`- Re: "Theoreticians” are Clueless aboutNicola
   `- Re: "Theoreticians” are Clueless about RelationalDerek Ignatius Asirvadem

Pages:123
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s4nui4$917$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=46&group=comp.databases.theory#46

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!usenet.goja.nl.eu.org!aioe.org!Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Thu, 8 Apr 2021 22:02:44 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 164
Message-ID: <s4nui4$917$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com>
<s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com>
<s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
NNTP-Posting-Host: Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Thu, 8 Apr 2021 22:02 UTC

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 “hot”,
> not just the words in “hot” 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 “Subtype” in IDEF1X. Use “generalisation”
> and “category” throughout, to be faithful to the IDEF1X terminology.

Ok.

> 2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X.

ISO 31320:2, §3.1.21 (emphasis mine):

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

§9.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 is—except perhaps for terminology,
which I have updated.

> Use “generalisation” and “category”
> 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 don’t agree with your definition (yellow panel in the middle).

Simplified.

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

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

You are quoting the unqualified sentence.

> --- “when the business part[y] is a customer” is contrived.

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

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

> - 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 “Non-Exclusive Subtyping” in IDEF1X.

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

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

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

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

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 “the same meaning as” the
> IDEF1X Incomplete Category symbol.

Graphical rendition of the same first-order predicates.

Nicola

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s4p3c8$1qaa$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=47&group=comp.databases.theory#47

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!KdKqB2LwXfu0rATk1FQaag.user.gioia.aioe.org.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Fri, 9 Apr 2021 08:31:04 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 11
Message-ID: <s4p3c8$1qaa$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com>
<s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com>
<s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
NNTP-Posting-Host: KdKqB2LwXfu0rATk1FQaag.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Fri, 9 Apr 2021 08:31 UTC

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
(§6) with predicates, which I believe is what you will be more
interested in dissecting:

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

Nicola

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=48&group=comp.databases.theory#48

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:141a:: with SMTP id d26mr12827568qkj.363.1617962089136;
Fri, 09 Apr 2021 02:54:49 -0700 (PDT)
X-Received: by 2002:a9d:3437:: with SMTP id v52mr11535046otb.55.1617962088575;
Fri, 09 Apr 2021 02:54:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Fri, 9 Apr 2021 02:54:48 -0700 (PDT)
In-Reply-To: <s4nui4$917$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.38; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.38
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Fri, 09 Apr 2021 09:54:49 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Fri, 9 Apr 2021 09:54 UTC

Nicola

Thanks for yours. Good work.

I think one item of difference, generally, re the 1997 revision of IDEF1X, because (a) it validates the anti-Relational “identity-based”, and (b) it is watered down (eg. allowing “Subtype” for Category; etc), is that I rejected it. So there is a difference between the original IDEF1X and the revision, my position is the original, and yours is the revision. I will try to hold the 1997 mindset for this thread.

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. Thus the comments in my previous post may be too strict.

I have no option. I remain in this class, in this hierarchy:
- strict FOPC
--- Predicates
- strict /RM/
--- Relational Predicates
--- Relational Normal Forms
- strict Data Modelling
- strict IDEF1X
--- original
--- plus IEEE mods (loosely described in the ERwin Methods Guide; strictly defined in my SG docs)
--- as used for forty years
--- revision rejected
- strict SQL.

I will respond to your post first, and then to your revised doc V2.

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

Well it is redundant because in the Relational world, an optional parent [Null FK] is prohibited.
- Min parent = 1
- Max parent = 1
- Max parent > 1 is hysterically stupid
- Min parent < 1 is anti-logic

The IDEF1X relation line excludes cardinality at the parent end.

> But I am not
> morbidly attached to it.

Attachment to a clearer, more concise, and prior definition (you like the Occam’s Razor principle, yes) is never negative, it is natural. Morbid is the pig poop factory, the Torrid Manifesto, that suppress the /RM/ and market 1960’s filth as “Relational”. Suppression of truth is the black death of the soul. So yes, I agree, attachment to that would be morbid. Glad you are not !

> > 2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X.

(Understand that I was referring to the Original IDEF1X, the Standard.)

> ISO 31320:2, §3.1.21 (emphasis mine):
>
> "category entity: An entity whose instances represent a **subtype** or
> subclassification of another entity (generic entity). Syn: subclass;
> **subtype.**."
>
> §9.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**".

That kind of nincompoop definition is exactly why I rejected the Revision. It is written by OO/ORM idiots. They have tried to include {Exclusive|Non-Exclusive}, but being clueless as pig poop, they cannot even do that.

No doubt, this is where you base your notion that “IDEF1X does not define Non-Exclusive properly”. Waaaah. Go and fry the idiots who pooped that anti-standard in oil.

You are working with something that fails the definition of Standard, that I rejected, and informed you, years ago.

> > I suggest remove the page.
>
> Overruled. That example is good as it is—except perhaps for terminology,
> which I have updated.

I accept that on the basis that the revised IDEF1X is loose and floppy, meaning your doc is fine.

I reject it for normal use by Data Modellers, on the basis that the revised IDEF1X is loose and floppy; rejected as a Standard, and thus will lead to unnecessary complications and avoidable discussions.

Now I understand, that what I viewed as /your/ confusion, is sourced from the revised standard, which I rejected decades ago, precisely because it was confused. Sorry, I thought you wanted to add clarity. Now I would say, trying to be faithful to the revised IDEF1X, that is simply not possible. You will have better luck trying to be faithful to the local whore.

If you wish to propagate the confusion, no, I cannot help you or afford to have my work associated with such an endeavour.

If you wish to teach, and therefore clarify the confusion, yes, I will help you. In that case, you have to decide how to handle and resolve the confused terms.

Last, why is the title of that page *NOT* [2 Complete Categorisation], hell, it uses the Complete symbol, and *NOT* the IEEE symbol.
- That it is Exclusive in the IEEE categorisation does not make it equivalent to the IEEE Exclusive categorisation.

> > (Subtype; Exclusive, are IEEE terms.
>
> Well, IEEE does not hold a trademark, I guess. As witnessed above, other
> standards use them, as well.

The point was about faithful use of terminology. Whether a copyright or trademark is held is not relevant to the point. In any case, with loose terms, confusion remains, and nothing is a mistake.

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

Supertype.

The Methods Guide was written by a non-technical person, which was part of the appeal. As evidenced, he had only a partial understanding of the /RM/. Those were the early days when the RecordID subversion (Date; Darwen; Fagin) was not understood and thus allowed. It was the only thing out there for describing IDEF1X, and its use, for decades, so it became the de facto “IDEF1X Methods Guide”.

Supertype is as stupid and inaccurate as other insanity from the Gulag: “superkey”. Typical of non-technical people, and if technical then of saboteurs.

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

Before we care about the Predicates, we have to care about the terms that the Predicates enforce, and that those terms are correct, true: first in English; second in technical English; third without damaging any previously existing term; and fourth, if a new concept, that it is accurate. Such that the Predicates that follow are also straight-forward to implement. The First law of Thought is Identity, correct identity, which relies on context of existence. I am disputing it at that level.

As long as the dispute stands, the Predicates that follow are irrelevant. There is no point in asserting that there is no difference at that level. There most certainly *IS* a difference in the Predicates, but likewise, I will not argue at that level.

> > - 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.
>
> You are quoting the unqualified sentence.

Sure, but that is not the point, that is not the intent, I am not breaking the sentence up and then disputing the fragments. I am going through each clause, saying this or that clause is false or invalid, giving you a specific clause to correct. Which of course implies that the sentence is false. It is your doc, the purpose of which is slowly becoming clear, change it or not, as you wish.

> > --- “when the business part[y] is a customer” is contrived.
>
> That completes the sentence above. But ok, it's contrived.
>
> > - 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.
>
> > - 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.


Click here to read the complete article
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s4pmj7$1vqt$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=49&group=comp.databases.theory#49

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Fri, 9 Apr 2021 13:59:03 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 159
Message-ID: <s4pmj7$1vqt$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com>
<s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com>
<s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
NNTP-Posting-Host: Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Fri, 9 Apr 2021 13:59 UTC

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 “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):

«2.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.»

«2.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.»

«2.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):

«Since 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 “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.

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

> Knock yourself out. Give the Predicates.

> Give the Predicates.

See my document v3, §6.

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

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 §6 of my
document (v3).

Nicola

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=50&group=comp.databases.theory#50

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:15d4:: with SMTP id o20mr17742443qkm.81.1618039675351; Sat, 10 Apr 2021 00:27:55 -0700 (PDT)
X-Received: by 2002:a05:6830:1dfd:: with SMTP id b29mr15203294otj.48.1618039675058; Sat, 10 Apr 2021 00:27:55 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sat, 10 Apr 2021 00:27:54 -0700 (PDT)
In-Reply-To: <s4pmj7$1vqt$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.142; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.142
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com> <s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org> <2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org> <67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org> <fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org> <fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com> <s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com> <s4pmj7$1vqt$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Sat, 10 Apr 2021 07:27:55 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 388
 by: Derek Ignatius Asirv - Sat, 10 Apr 2021 07:27 UTC

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

Thank you.

> Everything wrong, false, fragmented and invented, of course.

No, you are getting frustrated and mixing things up nicely.
- I could not have said all the references were wrong, because you just gave it to me in this post.
- I did say that the single reference that was a superficial critique was a superficial critique.
- I did say the fragmentation is a general problem for all people who are “educated” in the Modernist “science” system, and you are no less affected by it
- I said the inventions are premature, that you have to progress them further.

> So, except from your own documents, what else is not nonsense?

It appears you are experiencing difficulty. From my side, it is a bit upsetting that you jump from one mindset to another. From someone who has done a few hard yards, experienced difficulties, realised the subject matter is a mess, so you sought out the oracle and climbed the mountain. But then you did not accept the oracle and you argued against the single truth. You want the answers, but you want them delivered in your re-framed perspective..

Part of the problem is, I am following your lead in this thread. No complaint, but you have to understand that. The question-and-answer style, interspersed with accusations, is laborious.

As a counter-point consider this. I am known for my Standards, for rock-solid methods that do not change (truth is permanent, it does not change). Of course each of those Standards is written up, included in any project for a customer, which means IP and income. I have a number of docs intended for public consumption, which are the bare bones to get people going (no cost). Obviously, those docs are each a fraction of the customer versions.

I can’t give you the customer version for my IDEF1X document (it is illegal to give away something that I charge others for). You have seen three docs related that are published. All we have been doing in this entire thread is, closing that gap. Now the fastest way is, closing it from my side: you have to be open to education, and I deliver it in one practised sequence. You won’t do that, you want to close it from your side; your perspective: a Q&A process, dealing with only the points you bring up. That leads to more points that you did not know about, and so on. So it is laborious for both parties.

Another way of understanding it is, I am very much top-down, I explain things in the natural hierarchy. You are very much bottom up, and as detailed, schooled in fragmentation, which is the fragments at the bottom, up.

Analogy. Recall my little discourse on Atomicity. It often happens on a project where I am responsible for writing V2 of the customer’s horrendous V1 database, that the developers want to know how come my SQL runs at about 1,000 times faster than theirs. So I am happy to teach them. As you know Codd asks us to think in terms of SETS, and SQL is of course a Set-oriented language. So the main subject is how to deal with Sets. While most of their code is not procedural, it is very superficially Set-oriented (think OO/ORM cretins who are only interested in “poishistance”). The ones who can cross over to full Set-oriented queries obtain say 100 times the speed. The ones who are stuck in their row-to-row method obtain nothing. I have given up trying to teach Chinese: they desperately want it but are so closed, they cannot receive it.

I need you to stop working with fragments, stop relating fragments of one entity to fragments of another entity (because there is no connection between the fragments, only imagined), and start treating each entity as an Atom and connect the entities via their Atomic Relational Keys.

> 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!

I will overlook the rhetoric, and you are free to get past it and make an actual finding of something wrong.

> FIPS 184, ("Definitions" section):

That (and the detail you provided, thanks) caused me to go back to the archives and dig my FIPS 184 doc out. God help me. The exercise brought back the memories, and also the docs that I have, that have not changed in thirty years.

When IDEF1X came out, and my customers wanted it, I engaged with it. It was a mess. I wrote a doc that:
- determined the errors, and excised them
- determined ambiguities, and if possible tightened up the definitions, and if not dismissed them
- of course, where a Standard pre-existed (IEEE) I used that, I did not invent anything
The value is in the straightened-out and totally clarified [IDEF1X SG Qualified] document, not in the messed up FIPS doc.

I have done this business of Relational Data Modelling for over thirty years. I have gotten so used to implementing [SG IDEF1X Qualification], which as you can perhaps imagine, in all those project teams, we discussed and implemented as “IDEF1X”, not as [IDEF1X SG Qualified]. It was only my dealing with your FIPS 184 reference that exposed the fact that I have entirely forgotten about what the original IDEF1X really is, that I worked with thirty years ago.

So a big mistake on my part has been exposed. In this thread, up to this point, all my references to an IDEF1X Standard that is rock-solid and reliable, is sorry, actually references to my corrected and qualified version of IDEF1X.

You are right. The original IDEF1X Standard, FIPS 184, is a mess. You can’t use it.

If and when you recognise that there is a man who has the correct and mature knowledge of (a) Relational Data Modelling, and (b) IDEF1X as an important part of that, which means (c) a method of how to implement IDEF1X without problems, come to me. I can’t give [IDEF1X SG Qualified] to you, but I can give its content, in answer to questions, or [top-down] in a lecture style.

> So, except from your own documents, what else is not nonsense?

I don’t know of anything else that is not nonsense. Everything else that I have seen on this subject matter other than [IDEF1X SG Qualified] is nonsense, yes. The original IDEF1X definition; the 1997 revision; the superficial critique; the ERwin Methods Guide.

And who is to blame for that, who bears the responsibility ? The pig poop eaters that have created a mountain of excreta, marketed as “science”.

Confirming only the Grace of God, yes, whether it has to do with the real /Relational Model/ or IDEF1X, there is just one person whom I know of, who produces a single, clear, unchanging definition.

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

I realise that you have posted a V3 with Predicates overnight: please understand that our posts have crossed paths.

Now that I have gone through my ancient docs, I can declare that my position on the subject matter [previously from memory only] is further confirmed, and that what you seek (a common set of classifications) is impossible. But I don’t think you will accept that from the oracle, you will want to work it out for yourself, and use me just to confirm/deny small items, one at a time. Ok.

Now for your post ...

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

Will get back to you on that.

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

Accepted.

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

Yes.
There is a better version will less muck, but that is no longer available.

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

No, I was arguing from [IDEF1X SG Qualified], which is strict and immediately implementable.

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

(I am now more certain that that is not possible, but I will let nature take its course.)

> > and that uses the new loose and floppy IDEF1X revision terminology.
>
> Not new, not floppy. See below.

No. The new is loose and floppy. *AND* the original is only slightly less loose and floppy.


Click here to read the complete article
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<d91b0f56-e7d2-4a02-8ea0-a9a48db22668n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=51&group=comp.databases.theory#51

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a0c:a956:: with SMTP id z22mr12608151qva.22.1618044710831;
Sat, 10 Apr 2021 01:51:50 -0700 (PDT)
X-Received: by 2002:a9d:6389:: with SMTP id w9mr15415467otk.242.1618044710594;
Sat, 10 Apr 2021 01:51:50 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sat, 10 Apr 2021 01:51:50 -0700 (PDT)
In-Reply-To: <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.142; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.142
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d91b0f56-e7d2-4a02-8ea0-a9a48db22668n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Sat, 10 Apr 2021 08:51:50 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Sat, 10 Apr 2021 08:51 UTC

> 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 §5, 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, “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.

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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s4uclu$rql$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=52&group=comp.databases.theory#52

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!H5Vo4H2BX1tnrvSRrCRRGw.user.gioia.aioe.org.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Sun, 11 Apr 2021 08:40:30 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 28
Message-ID: <s4uclu$rql$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com>
<s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com>
<s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org>
<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
NNTP-Posting-Host: H5Vo4H2BX1tnrvSRrCRRGw.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Sun, 11 Apr 2021 08:40 UTC

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

Nicola

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=53&group=comp.databases.theory#53

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:d87:: with SMTP id s7mr22978183qti.32.1618178936690;
Sun, 11 Apr 2021 15:08:56 -0700 (PDT)
X-Received: by 2002:aca:3d41:: with SMTP id k62mr12109890oia.119.1618178936454;
Sun, 11 Apr 2021 15:08:56 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sun, 11 Apr 2021 15:08:56 -0700 (PDT)
In-Reply-To: <s4uclu$rql$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.133; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.133
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Sun, 11 Apr 2021 22:08:56 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Sun, 11 Apr 2021 22:08 UTC

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 “my” 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 “how to” doc for the DBAs. Eg. in IMS they did have an additional structure for it (I don’t recall the name).

A word on Sets and Proper Subsets. While there is no problem at all in the treatmesnt of Sets in Codd’s /RM/ and Codd’s /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 “RM”, such that people are driven to fiddle and fart around with records or “instances” 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 §4.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. Don’t 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 (§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).

No problem at all to change the example (because the truth is the truth and it will destroy falsity anywhere). Next edition.

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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s50shl$15e6$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=54&group=comp.databases.theory#54

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org.POSTED!not-for-mail
From: nic...@nohost.org (Nicola)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Mon, 12 Apr 2021 07:23:33 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 41
Message-ID: <s50shl$15e6$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com>
<s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com>
<s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org>
<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org>
<ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
NNTP-Posting-Host: Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Nicola - Mon, 12 Apr 2021 07:23 UTC

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

Nicola

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=55&group=comp.databases.theory#55

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:622a:205:: with SMTP id b5mr24788587qtx.186.1618229623619;
Mon, 12 Apr 2021 05:13:43 -0700 (PDT)
X-Received: by 2002:a05:6830:10:: with SMTP id c16mr6579574otp.48.1618229623407;
Mon, 12 Apr 2021 05:13:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 12 Apr 2021 05:13:43 -0700 (PDT)
In-Reply-To: <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.133; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.133
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 12 Apr 2021 12:13:43 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3130
 by: Derek Ignatius Asirv - Mon, 12 Apr 2021 12:13 UTC

> 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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<0a5f8e5f-2cfe-4663-9a5b-92eb48cf61a3n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=56&group=comp.databases.theory#56

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ae9:f719:: with SMTP id s25mr27028672qkg.42.1618231417399;
Mon, 12 Apr 2021 05:43:37 -0700 (PDT)
X-Received: by 2002:a9d:65d9:: with SMTP id z25mr3046814oth.55.1618231417122;
Mon, 12 Apr 2021 05:43:37 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 12 Apr 2021 05:43:36 -0700 (PDT)
In-Reply-To: <c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.133; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.133
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0a5f8e5f-2cfe-4663-9a5b-92eb48cf61a3n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 12 Apr 2021 12:43:37 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Mon, 12 Apr 2021 12:43 UTC

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

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

Cheers
Derek

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<3b8097f8-5818-45dc-98f5-c60b45cfbd5bn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=57&group=comp.databases.theory#57

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:4b67:: with SMTP id g7mr25418961qts.247.1618235015992; Mon, 12 Apr 2021 06:43:35 -0700 (PDT)
X-Received: by 2002:a05:6808:8c9:: with SMTP id k9mr12032585oij.160.1618235015732; Mon, 12 Apr 2021 06:43:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 12 Apr 2021 06:43:35 -0700 (PDT)
In-Reply-To: <0a5f8e5f-2cfe-4663-9a5b-92eb48cf61a3n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.133; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.133
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com> <s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org> <2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org> <67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org> <fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org> <fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com> <s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com> <s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com> <s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com> <c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <0a5f8e5f-2cfe-4663-9a5b-92eb48cf61a3n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3b8097f8-5818-45dc-98f5-c60b45cfbd5bn@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 12 Apr 2021 13:43:35 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 54
 by: Derek Ignatius Asirv - Mon, 12 Apr 2021 13:43 UTC

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

Especially when making a reference to a term in the Standard.

But that exposes something more serious. You can’t be relying on the original “definition” 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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=58&group=comp.databases.theory#58

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:70c1:: with SMTP id g1mr19949105qtp.302.1618244803551;
Mon, 12 Apr 2021 09:26:43 -0700 (PDT)
X-Received: by 2002:a05:6830:3115:: with SMTP id b21mr24180452ots.318.1618244803300;
Mon, 12 Apr 2021 09:26:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 12 Apr 2021 09:26:42 -0700 (PDT)
In-Reply-To: <c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.133; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.133
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 12 Apr 2021 16:26:43 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Derek Ignatius Asirv - Mon, 12 Apr 2021 16:26 UTC

> 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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=59&group=comp.databases.theory#59

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a0c:e88a:: with SMTP id b10mr36157252qvo.21.1618370845680;
Tue, 13 Apr 2021 20:27:25 -0700 (PDT)
X-Received: by 2002:a9d:6b8f:: with SMTP id b15mr9892967otq.242.1618370845376;
Tue, 13 Apr 2021 20:27:25 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 13 Apr 2021 20:27:25 -0700 (PDT)
In-Reply-To: <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=49.181.204.155; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 49.181.204.155
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Wed, 14 Apr 2021 03:27:25 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Wed, 14 Apr 2021 03:27 UTC

Nicola

> 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 attributes 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 onwards), and formed an opinion re what is missing, and how to correct it. Thus this lengthy discussion has been about informing you about reality, dragging you back from that academic position.

No doubt, the filth that passes for “textbooks” these dark days, fail to define Subtyping.

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 who follow the link to my doc will not understand it adequately. Further, it better identifies the context of your doc.

c.
> 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 distinctive enough, but yes, you do need to separate them. Perhaps a little grid, something like my page 11.

The IDEF1X doc was written by an academic. Putrid and unusable definitions..

----
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 body is EITHER male XOR female. Regardless of deformations; mutilations; additions.)

d. Different point. This:
> 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; Logic; Semantics remain unaffected.

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.

(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 definition first.

c. The reference [Subtype doc §3] is clearly quite different.

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 IDEF1X
No. 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 you are going to change anything, you have to change that **CLASSIFICATION**, not just grab a component (**FRAGMENT**) from here and add it there.

f.
> 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 “interpretation” is a gross misrepresentation. As confirmed in:

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

h.
> 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 stable of able horses.


Click here to read the complete article
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<d7d1557a-2eaa-4582-8aca-4afafac158b5n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=60&group=comp.databases.theory#60

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:24cc:: with SMTP id m12mr5554748qkn.496.1618521844527;
Thu, 15 Apr 2021 14:24:04 -0700 (PDT)
X-Received: by 2002:a05:6830:3115:: with SMTP id b21mr945976ots.318.1618521844212;
Thu, 15 Apr 2021 14:24:04 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Thu, 15 Apr 2021 14:24:03 -0700 (PDT)
In-Reply-To: <516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.139; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.139
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d7d1557a-2eaa-4582-8aca-4afafac158b5n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Thu, 15 Apr 2021 21:24:04 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Thu, 15 Apr 2021 21:24 UTC

On Wednesday, 14 April 2021 at 13:27:26 UTC+10, Derek Ignatius Asirvadem wrote:
> Nicola
>
> > 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 attributes 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 onwards), and formed an opinion re what is missing, and how to correct it. Thus this lengthy discussion has been about informing you about reality, dragging you back from that academic position.
>
> No doubt, the filth that passes for “textbooks” these dark days, fail to define Subtyping.
>
> 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 who follow the link to my doc will not understand it adequately. Further, it better identifies the context of your doc.
>
> c.
> > 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 distinctive enough, but yes, you do need to separate them. Perhaps a little grid, something like my page 11.
>
> The IDEF1X doc was written by an academic. Putrid and unusable definitions.
>
> ----
> 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 body is EITHER male XOR female. Regardless of deformations; mutilations; additions.)
>
> d. Different point. This:
> > 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; Logic; Semantics remain unaffected.
>
> 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.
>
> (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 definition first.
>
> c. The reference [Subtype doc §3] is clearly quite different.
>
> 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 IDEF1X
> No. 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 you are going to change anything, you have to change that **CLASSIFICATION**, not just grab a component (**FRAGMENT**) from here and add it there.
>
> f.
> > 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 “interpretation” is a gross misrepresentation. As confirmed in:
>
> > 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 it.
>
> h.
> > 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 stable of able horses.
>
> ----
> 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, it needs a name and definition first.
>
> 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]. If 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 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].
>
> 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 started our interaction.
>
> 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” !!!)
> <<<<
>
> 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 generic cannot [be] a category, a category cannot be a generic.
>
> In case you try to use the word [is], don’t, that is already established, and such a misuse would be insanity.
>
> 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 humans.)
>
> 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.
>
> 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, cannot be mutilated into a “basetype” that optionally hosts non-exclusive “subtypes” that IDEF1X does not have.
>
> 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 a classification; a definition.
>
> Since when should IT people care about “convenience” and “symmetry” ??? Should we care about empathy and sympathy ???
>
> 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 example from the natural universe (trannies and other insane excluded as abnormal), where a basetype is a valid basetype, and has zero subtypes.
>
> 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


Click here to read the complete article
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=61&group=comp.databases.theory#61

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a37:b17:: with SMTP id 23mr6351246qkl.68.1618534784753;
Thu, 15 Apr 2021 17:59:44 -0700 (PDT)
X-Received: by 2002:a05:6830:18e1:: with SMTP id d1mr1547760otf.330.1618534784437;
Thu, 15 Apr 2021 17:59:44 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Thu, 15 Apr 2021 17:59:44 -0700 (PDT)
In-Reply-To: <516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.139; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.139
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s41o47$pc3$1@gioia.aioe.org> <s4260a$73h$1@gioia.aioe.org>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Fri, 16 Apr 2021 00:59:44 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Fri, 16 Apr 2021 00:59 UTC

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 “deficiency” 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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s5bgnq$153a$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=62&group=comp.databases.theory#62

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org.POSTED!not-for-mail
From: lp...@nohost.org (LP)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Fri, 16 Apr 2021 08:09:30 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 31
Message-ID: <s5bgnq$153a$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com>
<s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com>
<s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org>
<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org>
<ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
<2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
<c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
NNTP-Posting-Host: Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: LP - Fri, 16 Apr 2021 08:09 UTC

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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=63&group=comp.databases.theory#63

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a0c:db05:: with SMTP id d5mr11866442qvk.41.1618644298513;
Sat, 17 Apr 2021 00:24:58 -0700 (PDT)
X-Received: by 2002:aca:3d41:: with SMTP id k62mr9207920oia.119.1618644298261;
Sat, 17 Apr 2021 00:24:58 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!50.7.236.10.MISMATCH!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Sat, 17 Apr 2021 00:24:57 -0700 (PDT)
In-Reply-To: <s5bgnq$153a$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.118; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.118
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<2d68ce75-84ef-45aa-8fc4-e91102ac0273n@googlegroups.com> <s4aqsf$qf4$1@gioia.aioe.org>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com> <c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
<s5bgnq$153a$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Sat, 17 Apr 2021 07:24:58 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3317
 by: Derek Ignatius Asirv - Sat, 17 Apr 2021 07:24 UTC

> 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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s5hm1g$1o1j$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=64&group=comp.databases.theory#64

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org.POSTED!not-for-mail
From: lp...@nohost.org (LP)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Sun, 18 Apr 2021 16:16:48 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 19
Message-ID: <s5hm1g$1o1j$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com>
<s4c5lv$11vg$1@gioia.aioe.org>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org>
<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org>
<ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
<2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
<c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
<s5bgnq$153a$1@gioia.aioe.org>
<f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com>
NNTP-Posting-Host: Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: LP - Sun, 18 Apr 2021 16:16 UTC

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

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<e64979fc-e768-4012-a9b5-37e095957d57n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=65&group=comp.databases.theory#65

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a37:9f41:: with SMTP id i62mr11068551qke.36.1618830913729; Mon, 19 Apr 2021 04:15:13 -0700 (PDT)
X-Received: by 2002:aca:4fc8:: with SMTP id d191mr1275758oib.139.1618830913355; Mon, 19 Apr 2021 04:15:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fdcspool3.netnews.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Mon, 19 Apr 2021 04:15:13 -0700 (PDT)
In-Reply-To: <s5hm1g$1o1j$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.134; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.134
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com> <67b442bb-e1ea-4699-beb1-e805455b20a7n@googlegroups.com> <s4c5lv$11vg$1@gioia.aioe.org> <fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org> <fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com> <s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com> <s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com> <s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com> <c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com> <516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com> <c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com> <s5bgnq$153a$1@gioia.aioe.org> <f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com> <s5hm1g$1o1j$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e64979fc-e768-4012-a9b5-37e095957d57n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Mon, 19 Apr 2021 11:15:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 380
 by: Derek Ignatius Asirv - Mon, 19 Apr 2021 11:15 UTC

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

On the one hand, you are welcome, I am happy to assist.

But I am not sure that I did that. That was not declared from the beginning, I answered only what was presented, in the increments that were presented.

You have a new doc, which presents the overall subject under a new heading (new terminology). Thus, AFAIC, this is a continuation of the thread, the next increment of revelation.

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

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

But even that:
- fails to define Specialisation
- fails to define the *SET* of specialisations.
Can you imagine, that if genuine authorities were used, life would be so much simpler for all concerned, developers and modellers alike.

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

Copyright © 1993-2021 Derek Ignatius Asirvadem
<<<<

Yes, the only one that is similar to the classification that applies to data is “generalisation/specialisation hierarchy”. But ...

I reject the terms “generalisation specialisation”; “generalisation hierarchy”; “generalisation/specialisation hierarchy” as pertaining to data, because:
- they are OO/ORM terms, and
- carry heavy OO/ORM connotations (refer link above)
- OO/ORM have nothing to say about Data Modelling (they do and very loudly, but it is a grave mistake)
- the definitions for Subtyping (that does apply to data), is absent.

Data Modelling and Process Modelling (including Objects as a type of Process) are two vastly different sciences. I reject any terminology that suggests OO/ORM can pertain to data, it is the single most destructive assumption, destructive on both the Data Modelling and Object Modelling sides.

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

Whereas Subtype existed before OO/ORM, and indeed before IDEF1X (which is why I say the academic that wrote IDEF1X is as schizophrenic as his colleagues, no more, no less). The worse problem, if there can be such, is his introduction of the new classification (hithertofore unknown and untested) *AS* a standard. (Again, there are more problems in the IDEF1X definition, this covers only the Category classification.)

Thus I suggest terms that do not carry non-data connotations, and preferably, terms that existed before both OO/ORM and IDEF1X. Failing that, use IDEF1X terms exclusively, but with the restated definitions as demanded.

> All the definitions I have used are on page 2. Although not completely
> formal, they are accurate enough for understanding the document.

No problem.

> I have
> added predicates throughout: hopefully, that will prevent further
> misunderstandings.

Since this appears to be re a Data Modelling course, that uses IDEF1X, and from another thread, you have stated that you teach Predicates, 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. For what I think your purpose is, I would show the separate
Predicates.

-------------------------------------------------------------------------------
> 6. Summary and Comparison with IEEE notation
-------------------------------------------------------------------------------

a.
> IDEF1X <all four classes>
> Specialization is an exclusive subtype [of] 1 Generic
> Specialization is 1 Generic
the second is redundant because the first states it (its existential 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>
> Specialization is { an exclusive | a non-exclusive } specialization [of] 1 Generic
> Specialization is dependent on 1 Generic
The first Predicate clearly indicates dependence, thus the second is redundant.

e. Ditto for IEEE <both classes>.

f.
> IDEF1X <all four classes>
The predicate headings:
> Generic
> Specialization
should be:
> <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
-----------------------

It is great that you have this page.

Before I get into the specifics, let me make some general declarations.
- /Reality/ includes both material reality and Facts about reality (which may be abstractions and thus not material, ie. Logic; Predicates).
- the empty set or the null set or null is very, very, necessary for the theory
--- it does not exist in reality (ie. it can be ignored outside the theory classroom)
--- if you challenge this, please provide an example from the natural universe (excludes the contrived fantasies in the asylum)
- the set of one member is a valid set, but it is not a Proper Subset (by definition)
--- the set of one exists in reality
- the set of one is not feasible where commonality is required, because commonality requires at least two members
--- thus the set of one is illegal re Subtypes
--- it is also ridiculous re OO/ORM Objects
--- (I HAVE DETAILED THIS IN PREVIOUS POSTS, NOT REPEATED HERE)

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.


Click here to read the complete article
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s5ks3p$14kt$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=66&group=comp.databases.theory#66

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org.POSTED!not-for-mail
From: lp...@nohost.org (LP)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Mon, 19 Apr 2021 21:18:49 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 380
Message-ID: <s5ks3p$14kt$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com>
<s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org>
<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org>
<ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
<2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
<c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
<s5bgnq$153a$1@gioia.aioe.org>
<f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com>
<s5hm1g$1o1j$1@gioia.aioe.org>
<e64979fc-e768-4012-a9b5-37e095957d57n@googlegroups.com>
NNTP-Posting-Host: Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: LP - Mon, 19 Apr 2021 21:18 UTC

Derek,
I have taken note of your comments, and applied some of your suggestions
to my document (those that made sense to me, more on that below). But
I am not posting another version (yet).

On 2021-04-19, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:
> 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.

Fine.

> This doc is frequently used, it is generally viewed as authoritative:
> __https://people.cs.vt.edu/~kafura/cs2704/generalization.html

Read, but I did not find it particularly insightful or relevant to our
present discussion. As you said, the OO world is a different beast.

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

Ok.

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

You have argued that point of view convincingly enough in your "Nicola
IDEF1X 2" document.

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

Sure.

> 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>
>> Specialization is an exclusive subtype [of] 1 Generic
>> Specialization is 1 Generic
> the second is redundant because the first states it (its existential
> reality, dependence), and does so more precisely.

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.

> c. Ditto for IEEE <both classes>.

Ok.

> d.
>> IDEF1X <all four classes>
>> Specialization is { an exclusive | a non-exclusive } specialization [of] 1 Generic
>> Specialization is dependent on 1 Generic
> The first Predicate clearly indicates dependence, thus the second is redundant.

Answered above.

> e. Ditto for IEEE <both classes>.
>
> f.
>> IDEF1X <all four classes>
> The predicate headings:
>> Generic
>> Specialization
> should be:
>> <Generic>
>> <Specialization>

Ok.

> f.1. Two instances of “subtype” under IDEF1X should be “specialisation”.

Why? 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.

> g. Last but not least, each of the six sets needs a clear and
> unambiguous title.

Noted, yet to be added (some other things need to be resolved first).

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

Ok.

> -----------------------
>> 0 Definitions
> -----------------------

> What you are trying to do is two separate things:
> - validate IDEF1X Incomplete

Yes, it's an attempt.

> - 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 combined
> form of definition.

Ah ok, now I understand what you mean above. I beg to disagree: my
definitions are quite the opposite of "combined"; they are quite
orthogonal.

> 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?

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

I do not follow you. Perhaps, you have a reversed implication in mind.
I have written that, *since* Employee is a (perverted) specialization of
Person, *then* "in particular, employees have the same attributes as
individuals [...] and typically have additional attributes". The latter
is a *consequence* of the former. The converse does not hold, of course.


Click here to read the complete article
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<373b1b3c-9b58-4322-8a55-faae5ea1091fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=67&group=comp.databases.theory#67

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:ac8:6055:: with SMTP id k21mr11051413qtm.196.1618914911757;
Tue, 20 Apr 2021 03:35:11 -0700 (PDT)
X-Received: by 2002:a9d:d35:: with SMTP id 50mr6918979oti.318.1618914911397;
Tue, 20 Apr 2021 03:35:11 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!50.7.236.18.MISMATCH!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Tue, 20 Apr 2021 03:35:11 -0700 (PDT)
In-Reply-To: <s5ks3p$14kt$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.122; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.122
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com> <c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
<s5bgnq$153a$1@gioia.aioe.org> <f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com>
<s5hm1g$1o1j$1@gioia.aioe.org> <e64979fc-e768-4012-a9b5-37e095957d57n@googlegroups.com>
<s5ks3p$14kt$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <373b1b3c-9b58-4322-8a55-faae5ea1091fn@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Tue, 20 Apr 2021 10:35:11 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 42234
 by: Derek Ignatius Asirv - Tue, 20 Apr 2021 10:35 UTC

Nicola

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

Good.

Well, in that case, I have to take the declarations given as Predicates, and in that case the Predicates are plain incorrect; false. In that case, the redundant Predicate is a gross error. Every Predicate is an implementation directive. After the first [correct] Predicate is given [implemented], the second [redundant] Predicate simply cannot be implemented because the first is already implemented. Therefore the second [redundant] Predicate is false; incorrect.

I trust you understand that Predicates are Normalised.

Do not list false Predicates and descriptive text with correct Predicates in a Predicate List.

> > -------------------------------------------------------------------------------
> >> 6. Summary and Comparison with IEEE notation
> > -------------------------------------------------------------------------------
> >
> > a.
> >> IDEF1X <all four classes>
> >> Specialization is an exclusive subtype [of] 1 Generic
> >> Specialization is 1 Generic
> > the second is redundant because the first states it (its existential
> > reality, dependence), and does so more precisely.
>
> 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.

Ok, as per the clarification above, now my comments are certain.
The second is redundant; false; incorrect.

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

(I trust you are not in denial of the fact that there is a Subtype Cluster; a Subtype Set, that that is just your way of pointing something out to me.)

No, it is not contradictory because each declaration applies to a discrete Subtype Set.

Yes, it gets resolved in my Normalised or combined forms with the “and”. Sorry, my Lexicon is not published.

You are right, in the single-Predicate list, {SubtypeList} has to be stated..

Teacher is an exclusive basetype of {SubtypeList}
....
Teacher is a non-exclusive basetype of {SubtypeList}

> > f.1. Two instances of “subtype” under IDEF1X should be “specialisation”.
> Why?

For your purpose, I am assuming that you want to maintain the “generalisation/specialisation hierarchy” terminology, even though I have stated it would be better to maintain the IDEF1X terminology and *add* your proposed classifications. In the Predicate text:
- so first, [subtype] does not belong on the IDEF1X side, the word is [Category]
- second, if you are using the OO/ORM terminology, the word is [Specialisation]

Not:
> Specialisation is an exclusive subtype 1 Generic
> Specialisation is a non-exclusive subtype of 1 Generic
but IDEF1X:
> <Category> is an exclusive category 1 <Generic>
> <Category> is a non-exclusive category of 1 <Generic>
or OO/ORM:
> <Specialisation> is an exclusive specialisation 1 <Generalisation>
> <Specialisation> is a non-exclusive specialisation of 1 <Generalisation>

Throughout your doc, basically, be consistent and use one set of terminology, as applicable. Yes, when you describe IEEE sets, use IEEE terminology. I don’t know what you want to do with IDEF1X original terminology vs your proposal terminology (which seems OO/ORM). I have just tried to assistin obtaining that consistency.

> If anything, it should read "total specialization" then (which is
> the same as "subtype").

I don’t see how that applies.

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

First, not repeating the above.
Why would you want to mix the terminology ?
Why does IDEF1X terminology not stand on their own ? [It does]
Why does your proposal terminology not stand on its own ? [In progress]

Second, it exposes a deeper issue. If your proposal is dependent on the IEEE definitions, then you need to state that openly, at the beginning. Ditto any dependencies on IDEF1X. That will make your porposal straight-forward and clear.

What you have now [V4] is a strong push for your proposal, minimising both IEEE and IDEF1X dependencies, in fact denying it in some cases. Which leads to the back-and-forth, as evidenced.

>>>>
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-maintained bubble of atheism:
- Define atheism without using the concept of God

Silence.

Blank stare.

Immediate change of subject.

So the simple undeniable fact of atheism is, it depends on the existence of God. 95% of atheist polemics are eliminated if you understand this.
<<<<

Thus far, you are trying to define a set without making a clear reference to the set that it is dependent upon, and running into problems. Declare the dependency (and thus an acknowledgement) at the outset, and that class of problems will disappear. (My doc §3 may be an example.)

> > g. Last but not least, each of the six sets needs a clear and
> > unambiguous title.
> Noted, yet to be added (some other things need to be resolved first).

Ok.
In Predicate terms, if it is not named, it does not exist. Yet.

> > -----------------------
> >> 0 Definitions
> > -----------------------
> > What you are trying to do is two separate things:
> > - validate IDEF1X Incomplete
> Yes, it's an attempt.
>
> > - 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.

I have understood, at this late stage in the discussion. The combined form is what you have in V4, in which the two goals are not stated but can be inferred. I am saying, state those two goals as separate, *NOT* in the combined form. That will make the doc and your proposals clear to any reader.

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

I agree with your earlier statement above, I can’t but agree with the content of a published standard. I am saying something else:
- that it is not an “implication”, it is explicit
- you can’t get rid of it or ban it (that would be denial of reality)
- that you would be better off acknowledging it [mutual exclusivity in IDEF1X Categorisation], and then proposing the new set [*NOT* mutually exclusive].


Click here to read the complete article
Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<s5q1s8$13n3$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=68&group=comp.databases.theory#68

 copy link   Newsgroups: comp.databases.theory
Path: i2pn2.org!i2pn.org!aioe.org!Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org.POSTED!not-for-mail
From: lp...@nohost.org (LP)
Newsgroups: comp.databases.theory
Subject: Re: "Theoreticians” are Clueless about
Relational Data Modelling, Teach Anti-Relational Muddling
Date: Wed, 21 Apr 2021 20:27:52 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 47
Message-ID: <s5q1s8$13n3$1@gioia.aioe.org>
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org>
<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org>
<ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
<2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
<c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
<s5bgnq$153a$1@gioia.aioe.org>
<f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com>
<s5hm1g$1o1j$1@gioia.aioe.org>
<e64979fc-e768-4012-a9b5-37e095957d57n@googlegroups.com>
<s5ks3p$14kt$1@gioia.aioe.org>
<373b1b3c-9b58-4322-8a55-faae5ea1091fn@googlegroups.com>
NNTP-Posting-Host: Ca3fXwVFPO74v52zQgh0qQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Darwin)
X-Notice: Filtered by postfilter v. 0.9.2
 by: LP - Wed, 21 Apr 2021 20:27 UTC

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 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?

Regards,
Nicola

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<4ebd2537-e7f4-4b07-b8e9-a96ca180ea19n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=69&group=comp.databases.theory#69

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a05:620a:b85:: with SMTP id k5mr55006qkh.24.1619037592541;
Wed, 21 Apr 2021 13:39:52 -0700 (PDT)
X-Received: by 2002:a05:6830:1d5c:: with SMTP id p28mr18197oth.362.1619037592187;
Wed, 21 Apr 2021 13:39:52 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Wed, 21 Apr 2021 13:39:51 -0700 (PDT)
In-Reply-To: <373b1b3c-9b58-4322-8a55-faae5ea1091fn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.136; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.136
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<fb5de44e-c466-4e35-b6bc-0eb4b28cfb66n@googlegroups.com> <s4fm2h$g36$1@gioia.aioe.org>
<fbcbaf56-1a7b-4c2d-98f0-ba4d1f57c810n@googlegroups.com> <s4kv05$1d9d$1@gioia.aioe.org>
<s4kvqs$1r6c$1@gioia.aioe.org> <cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com>
<s4nui4$917$1@gioia.aioe.org> <b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com>
<s4pmj7$1vqt$1@gioia.aioe.org> <bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com>
<s4uclu$rql$1@gioia.aioe.org> <ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com>
<c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com> <2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com>
<516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com> <c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com>
<s5bgnq$153a$1@gioia.aioe.org> <f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com>
<s5hm1g$1o1j$1@gioia.aioe.org> <e64979fc-e768-4012-a9b5-37e095957d57n@googlegroups.com>
<s5ks3p$14kt$1@gioia.aioe.org> <373b1b3c-9b58-4322-8a55-faae5ea1091fn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4ebd2537-e7f4-4b07-b8e9-a96ca180ea19n@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Wed, 21 Apr 2021 20:39:52 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 9123
 by: Derek Ignatius Asirv - Wed, 21 Apr 2021 20:39 UTC

Nicola

> On Tuesday, 20 April 2021 at 20:35:12 UTC+10, Derek Ignatius Asirvadem wrote:
> >
> > >> 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 a incoherent article.
>
> 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 sense should be clear from previous posts, and from the context, but the mistake needs to be corrected explicitly. That should read:

__ Likewise, here you are trying to validate the set of one, which is not a valid SubtypeSet.

Of course a set of one is a valid set, but it has no Proper Subset, and it is not a valid SubtypeSet:

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

If zero is eliminated, that means the IDEF1X[Incomplete] is eliminated.

That means in your §6, the lower two classifications under IDEF1X are eliminated. Please confirm.

That leaves your venture with two remaining items:
- introduction of Non-Exclusive as an amendment to IDEF1X
--- ignoring the IEEE notation (vastly more accepted, as you said)
--- with a new symbol
- the SubtypeSet of one issue awaits a decision

> > >> We also say that each employee is a person.
> > > No, we do not. That perverts the well-established understanding of
> > > the [is a] relation.
> > 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?
>
> 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 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.
>
> So yet again, it is about the great chasm between a richly defined Relational paradigm, and the pathetically defined OO/ORM world. While a few terms may be similar, on any inspection beyond the cursory, no, the terms have quite different definitions or a definition on the Relational side and a silly description on the OO/ORM side.

Eg. for decades, they have been hammering away with the word /Inheritance/. They perceive the entire world as objects that inherit properties from other objects. So they perceive the Subtype Cluster as an “inheritance hierarchy”, and the Subtypes as as “inheriting” the Basetype. Even though no Object is built along those lines. The absurdity does not faze them.

Eg. The fixation on persistence. No concept of a shared database. Avoiding the Transactions altogether. The hilarious notion of Multiple Versions of the truth [one fact in one place] that have no Concurrency Control whatsoever (the CC in MVCC is false).

> 4. But wait. There’s more. Due to (a) the looseness and laziness on the OO/ORM side, (b) the abject ignorance of the /RM/in the academic world, and (c) the horrendous lack of definition in the academic world, the [“Relational”] academics have picked up this silly and superficial notion [that] “OO/Generalisation equals Subtypes”. You are the first to venture out of that morass.

(Note the added qualification.)

> And due to them arguing over every little thing, and resolving nothing (no Four Laws), even that notion has been perverted. Now they apply it all over the place, if only to prove a point. Misuse and abuse. Eg. you, in your definitions. That is why I did not fault you, I faulted the whole academia that schooled you, particularly the pig poop eaters that write the anti-relational “theory” and market it as “Relational”.

The thing to understand here is, the “Relational” academics have no clue about Subtypes; no proper handle; no definition, so the superficial OO/ORM notion is accepted as the definition for Subtypes, and it is used by them. It is sow’s milk straight from the sow, it fills the void that “Codd failed to give them”, they wet themselves just thinking about it. Thus you will see these academics:
a. talking about Subtypes as if they understand Subtypes, but as defined here, they are clueless, they are actually talking about the OO/ORM notion, which is a small fraction of Subtypes (Eg. you at the beginning of this thread).
b. use it in their 1960’s Record Filing Systems, that they market and promote as “Relational”. The thing to understand here is, whatever monstrosity they put together, is not a clean definition, not as powerful as a real Subtype Cluster. Think about the effect that the lack of genuine Relational Keys has.

Here is an example that covers many of the issues and use/abuse/misuse of terms that I am discussing here, the liberal use of [is a] that means exactly nothing. Look at just the pictures, notice both the similarities and the differences. This poor guy is solving a problem /with academic confidence/ while being ignorant of the problem, and clueless that he is ignorant, a perfect example of the Dunning-Krüger Effect:
__ https://www.softwaregems.com.au/Documents/Article/Application%20Architecture/UTOOS%20Response.pdf

Cheers
Derek

Re: "Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling

<de54a417-1113-4936-9728-cbe2e66f230dn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=70&group=comp.databases.theory#70

 copy link   Newsgroups: comp.databases.theory
X-Received: by 2002:a37:6004:: with SMTP id u4mr502704qkb.369.1619044800070;
Wed, 21 Apr 2021 15:40:00 -0700 (PDT)
X-Received: by 2002:a9d:2787:: with SMTP id c7mr335200otb.105.1619044799755;
Wed, 21 Apr 2021 15:39:59 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Wed, 21 Apr 2021 15:39:59 -0700 (PDT)
In-Reply-To: <s5q1s8$13n3$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=199.229.250.136; posting-account=bFMNewoAAAAHC6b_JPlV7XvI31zIuG5T
NNTP-Posting-Host: 199.229.250.136
References: <72b862c2-2508-44b9-913e-47f0f9f91a5en@googlegroups.com>
<s4kv05$1d9d$1@gioia.aioe.org> <s4kvqs$1r6c$1@gioia.aioe.org>
<cd5637e4-a7b2-42d2-bbfd-6fdaf98aafbfn@googlegroups.com> <s4nui4$917$1@gioia.aioe.org>
<b35019c4-d718-4e26-b7fb-6d578974a964n@googlegroups.com> <s4pmj7$1vqt$1@gioia.aioe.org>
<bde7b688-83f4-4d3a-9cc3-2185f73ce72an@googlegroups.com> <s4uclu$rql$1@gioia.aioe.org>
<ea18ded9-ac5a-492d-ae9d-62b5f26b4a44n@googlegroups.com> <c9a5ca79-d194-4690-93c1-13292f1b4b66n@googlegroups.com>
<2ca7a49a-5427-407f-99f0-57721cdf63a5n@googlegroups.com> <516aae17-30d8-4cb6-a1ba-9423e06ae13fn@googlegroups.com>
<c40daa9e-bf7f-4cb4-85b5-91f2bb259e10n@googlegroups.com> <s5bgnq$153a$1@gioia.aioe.org>
<f2eb524e-f9a2-4707-a578-63cb4b414417n@googlegroups.com> <s5hm1g$1o1j$1@gioia.aioe.org>
<e64979fc-e768-4012-a9b5-37e095957d57n@googlegroups.com> <s5ks3p$14kt$1@gioia.aioe.org>
<373b1b3c-9b58-4322-8a55-faae5ea1091fn@googlegroups.com> <s5q1s8$13n3$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <de54a417-1113-4936-9728-cbe2e66f230dn@googlegroups.com>
Subject: Re:_"Theoreticians”_are_Clueless_about_Relational_
Data_Modelling,_Teach_Anti-Relational_Muddling
From: derek.as...@gmail.com (Derek Ignatius Asirvadem)
Injection-Date: Wed, 21 Apr 2021 22:40:00 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Derek Ignatius Asirv - Wed, 21 Apr 2021 22:39 UTC

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

That admission is to be commended, it is rare among academics.

> > 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?

I can’t answer the question directly, but I can give you some understanding. Please appreciate that during that time, I worked for Cincom, their TOTAL NDBMS codeline, across all DEC machines, first in Level 3 support and then in R&D writing the “next generation”. Those were the days when the arguments between the players were articles in Datamation, etc. Boyce; Date; and Chamberlin were big-noting themselves, Barker and Bachman had competing notation, Codd was trying to stop the tide of adulteration of the /RM/ (which he himself started, unwittingly, by bending over and giving RM/T for the hordes that could not understand the /RM/). Point being, I was covering the market at the very high end, and had little knowledge of the insanity that was academic papers, which were brought to our attention by our internal academics if and only if relevant. We just knew it was happening.

The progress, the whole enterprise, was driven by the DBMS vendors, because they had actual products and they delivered actual methods. Eg. Subtyping.. But it was not called Subtyping, it was called <providers_navigation_method>, and one provider would declare that his was better than the others, etc. TOTAL was beating the crap out of IMS and other HDBMS in the online market, but the latter held its own in the conservative DSS/OLAP market (fast access vs Modified-ISAM hierarchic access). IMS and others had a verb to “SWITCH-PATH”, which was their implementation, TOTAL just needed understanding at the designer level, a single page “How To” that I mentioned.

IEEE had various notations to support the various articles that those guys were publishing/proposing. Some lived to become known (eg. instead of the crows foot, the arrow with one arrowhead at the parent end and two arrowheads at the child end; the Subtype symbol), and others died by the wayside.

The nested boxes was classic Hierarchic Paradigm (JKL has corrected me, that it was not a model because it did not have a formal mathematical definition, but it was a model in the sense of the common use of the word these days, ala “business model”, it is a formula), it was in common use. We knew it was not a Venn diagram, but a file design. Imagine your doc §0 Venn diagrams drawn properly as a data model: the sets would be nested. For §2, PersonMale; PersonFemale; and Gender would each be boxes nested inside the Person box. It defined the navigation path (via notation, specific to the product). There was just one file Person. As things progressed, the child tables were differentiated, basically setting conditions or qualifying the path, and that depended on the facility (if any) that was in the product.

Nested boxes meant the designer was using a HDBMS. The notation (lines; notches; arrows; crows foot; etc, were IEEE is the sense that they were common and understood but there was no IEEE published standard that I can recall.. Think Popular Electronics magazine being applied by IT professionals in that day and age. In those days, the only standards were IEEE and ANSI/FIPS, if it was not strictly IEEE, it was an extension that was commonly understood. There were many notations, and the designer used the one he subscribed to {Bachman; Barker; etc). No one used ERD, it was plain stupid, eg. considering the nested box diagrams.

An Hierarchic file consisted of one parent type-of-record, and many child types-of-record. What we now call sets. But they were 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. That was the navigation path, which had to be programmed. But we knew that each child was a logical set, and the data model showed it as a nested box, the good designer had both logical and physical notation in one model; one diagram [intense], the rest had separate logical and physical models. (In those days, we called them [File Definition] or [File Design], not models.)

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.

(In his /RM/ Codd clearly speaks about these aspects and issues. Not to the academics, but to normal un-perverted minds, he gives The Hierarchic Normal Form.)

The Hierarchic access concept lives on today:
- Genuine RDBMS (not the freeware) where the modeller implements the /RM/, Relational Keys ... obviously not in files but in every Relational table
--- Sybase has the best implementation and the fastest, with their [Clustered Index], copied by MSSQL. The concept was pure Britton-Lee, which morphed into Sybase.
- in Oracle Index Ordered Tables (a monstrous mess) in the one table, which is one FILE (hidden as “tablespace”)
--- identical to HDBMS in terms of physical structure but with “sql” access
The /RM/ is a direct progression of the HM, with the FOPC foundation, and the Independent Access from NDBMS. The academics position it as if it was created on the Jupiters fourth moon, with no past, isolated from the reality that gave it context, that produced it. As usual.

To differentiate ordinary child type-of-record from a Subtype type-of-record, which were both drawn as nested boxes, was a matter of notation, limited by what the HDBMS provided and the flavour preferred by the designer. The concept was in the designer’s head, and [just as we have argued here] some designers had a better understanding. I can’t count the number of times I fixed a problem that was presented as “navigation” agony, simply by defining the child/subtype sets more accurately; more discretely.

At some point, the IEEE Subtype symbol became standard use.

Cheers
Derek

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor