info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"Theoreticians” are Clueless about Relational Data Modelling, Teach Anti-Relational Muddling
246 views
Skip to first unread message
Derek Ignatius Asirvadem
Mar 29, 2021, 3:59:46 AM3/29/21
to
Introduction
When it came out in 1970, the Relational Model (Codd, not the pretenders) made a paradigm shift in all areas of perceiving data (examination; data modelling; storage and retrieval; programming). Codd had an uphill battle against the established academics because they could not understand it, and against a few of the DBMS vendors, because they were interested in protecting their established products. It took about ten years to overcome those obstacles, and then it took off. IBM had an internal product that progressed through the 1970’s, eventually becoming SQL, and the market begged them to release the definition, so that it could be made a Standard, such that other vendors could provide platforms.
For those who are not old enough to remember, we had perfectly good DBMS in those days, and fairly intense design methods, first for data in general and second for the implementation in our particular DBMS. It just was not a model, in the sense that the /RM/ is a genuine model, defined mathematically and based on First Order Predicate Calculus.
I worked for Cincom, one of the “big five” DBMS vendors, in addition to being expert in their Network DBMS, we were well schooled in the competitions capabilities, in order to compete seriously. We did not care much for academic papers because the science was already deteriorating, and the best scientists (including all progressions in the science, except for the /RM/ ) were invented by engineers who worked for the DBMS vendors.
In contrast to the ever-changing freeware/whatmewear/vapourware/nowhere filth (massive suite of programs, aka open sore) that is marketed these days as “SQL” and as a “platform”, those were the days of real SQL (compliant with the standard), and real platforms (server architecture). We already had ACID Transaction from 1960 IBM/CICS/TPC, thus all pre-Relational DBMS were heavily Transaction oriented and ACID compliant. Thus the first few SQL platforms were high-throughput, high-concurrency, ACID Transaction Processing engines.
There were only two: IBM and Sybase (Britton-Lee the Database Machine people, implemented an SQL Database Machine), and there are still only two, plus a bastard son of Sybase MS/SQL for the low end of the market.
The filth, including Orable, is neither SQL, nor ACID-compliant. Hint: with the schizophrenic notion of MVCC, they cannot handle even simple contention, let alone high-throughput, or high-concurrency, or ACID. (If you wish to comment on this point, there is a separate thread open, begging for progress.)
Methods
Re methods, it was a matter of moving from the established pre-Relational methods to the Relational methods, as opposed to inventing methods for the first time. We did not have, and certainly did not dry about not having, Modelling Tools: we drew diagram on paper, using a stencil. We never heard of, nor used, ERD. Apparently it made a big splash in the academic circles.
Note well, the /Relational Model/ is a single paper that defines a single method, like all academic papers, it defines one thing, it cannot be expected to define related things (such as database design or data modelling or how to blow ones nose without getting snot on ones hands). It is telling that the pig-poop eaters (Date; Darwen; Fagin; and all their followers) wring their hands and wail about “Codd did not define this or Codd did not define that ...). Practitioners are fully capable of continuing the data modelling and database design methods while conforming to the new /RM/, without the need to be fed from a baby bottle.
In 1983 Robert Brown extended his modelling method Logical Database Design Technique to cater for the Relational Paradigm. It became used by a few important customers such as DoD, and thus became known to all DBMS vendors (I personally wrote a database for DoD in Cincom’s TOTAL DBMS), and eventually all their customers. It became widely known by 1987, when the first product ERwin came out (first by LogicWorks, and later by Computer Associates). The IDEF people took it over, named it IDEF1X (following IDEF1 for informational modelling and X for Relational), and maintained it. By 1993 it was a NIST Standard.
Several Data Modelling tools followed, such as PowerDesigner and ER/Studio, but they are nowhere near ERwin in terms of true IDEF1X or platform-neutral implementation.
The point of this thread. In the real world (as distinct from the “world” as concocted by “theoreticians” who allege to serve this space), we have:
- the real /Relational Model/ 1970,
- the real Relational Data Modelling method IDEF1X since 1983 (1987 as a product), and
- real SQL platforms since 1981.
The question begs:
- why is that unknown to the “theoreticians” ?
- why do the pig poop eaters NOT teach Relational Data Modelling ?
--- why do they NOT teach IDEF1X ?
- why do they teach instead the defunct; obsolete; anti-Relational ERD ?
These sad people are operating FIFTY YEARS behind the leading edge AFA the /RM/ is concerned, FORTY YEARS behind the leading edge AFA Standards and SQL Platforms are concerned.
Great news. There is one single academic across the entire planet, who has started a journey from the anti-Relational-marketed-as-Relational land that is their studied home, across the great divide, to the Relational world. We touched on the subject in another thread, but it deserves its own thread, so I have brought it here.
> On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
> > On 2021-03-24, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> >
> > In case you missed them. Could you please respond to these questions.
> >
> >> On Thursday, 18 March 2021 at 14:38:13 UTC+11, Derek Ignatius Asirvadem wrote:
> >> > On Tuesday, 16 March 2021 at 23:23:28 UTC+11, Nicola wrote:
> >>
> >> > Note that the "circularity" in that diagram is only apparent (ERD are
> >> > misleading).
> >>
> >> So, why in heavens name, do professors teach ERD ?
>
> I cannot speak for anyone else...
First, let me thank you for your very interesting and considerate response.
> One reason is Chen's Entity-Relationship models are likely perceived as
> easier to grasp for novices than something like IDEF1X. Whether that is
> a correct perception, it can be debated. Another reason is probably just
> historical, due to the huge influence of Chen's seminal paper.
It may have been seminal for the academics, let me assure you, it was not seminal, or even great, for practitioners of the day. It does not have a semantic base, whereas the /RM/ and IDEF1X does.
For academics. I can grant, up to 1970, the paper was amazing. After 1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct; superseded.
Ok, to rephrase the question, why was that pre-Relational method being taught after 1983, and why is it still being taught after the advent of the /RM/, after the /RM/was proved, and after the first genuine SQL platforms came out (1983), and after IDEF1X came out (1983 to practitioners, 1989 as a product, 1993 as an international standard) ?
Novices grasp anything you give them, so the responsible professor gives them the right thing, not cabbage patch dolls for Computer Science.
> In a general setting, ERD is fine for teaching the basics of modeling:
> entities, relationships, generalizations. For someone who has never done
> it, taking a description in a natural language and analyze it to distill
> such concepts and put them in diagrammatic form is not a trivial task
> (well, it's not trivial even for experts!).
> ERDs can be useful as
> a gentle introduction to such topics.
>
> ERD can be introduced without any background knowledge in databases
For introductory levels, show them IDEF1X/Entity level.
> (although that is true about IDEF1X to some extent, when you are
> teaching IDEF1X you are in fact teaching the Relational Model),
Yes !!! Instead of whatever mumbo jumbo that is NOT Relational. That is pretty much the central point. To think about data in terms of the /RM/, not in terms of the physical records that the freaks can contrive in their little crania, because they cannot grasp the /RM/.
> and even
> for purposes that are different from mapping into the Relational Model.
> For instance, one may use ERDs in the context of programming—say, to
> design a game.
Data, the /RM/, is not application dependent. It is data dependent. It is far superior to any other method or non-method or non-thinking.
> When it comes to using ERD vs IDEF1X for designing Relational databases,
> my experience is as follows:
>
> - when teaching ERDs, one also has to explain the rules to translate
> them into the RM:
One can’t. I don’t. I didn’t in the example. It is like translating the thinking that goes into rap “music”, into the thinking that goes into Beethoven’s Fifth. Don’t. Just think classical music. Don’t draw a diagram that has an inferior understanding of data (actually NO understanding of data), and then attempt to translate it into a higher form. No, think in the higher form. and then draw the higher form.
> this is a layer of accidental complexity that IDEF1X
> completely eliminates.
Yes. And it does so by design, not by accident.
> - On other hand, when teaching IDEF1X one has to introduce a richer
> language, so it doesn't take less time to teach than ERD; but I'd say
> that it doesn't take much longer either, as some people might might
> expect.
When you teach a principle (the RM), the whole lesson, even though it is rich, is actually faster, and more deeply understood. When you teach without the principle (ERD, no RM), you struggle to teach because there is no principle, just a collection of low-level axioms. Fragments of meat on the ground that only pigs and rats forage for, but hey, that is what the “theoreticians” promote.
> - Perhaps contrary to someone's opinion, IDEF1X models can be grasped by
> novices: I have successfully taught IDEF1X to people without any
> background in Computer Science and high-school level of acquaintance
> with logic for a few years now.
Absolutely. I have been doing it for forty years. Half the time, I don’t even tell them what it is, I just erect the data model during the discussion. If they ask, I give them my short IDEF1X Intro:
https://www.softwaregems.com.au/Documents/Documentary%20Examples/IDEF1X%20Introduction.pdf
> - ERDs make it difficult or impossible to reason about keys effectively:
> think split keys, for instance. Or common ancestor constraints. This
> is one of my biggest issues with ERDs.
Well, it is completely 100% brain-dead re the concept of Keys. Which is why I say that ERD is anti-Relational. The central concept in the /RM/ is logical Keys, that are composite. It is not possible to teach Relational using a method that cannot describe Relational.
On the other hand, if one wishes to cancel the DATA MODELLING exercise, and to go into the establishment of premature entities (which the entire OO/ORM world slavishly does), sure, ERD works fine: the “modelling” is not modelling abut a single iteration of drawing what Entities one can imagine (that is imagined, not real) for a first evaluation, based on the need (not on the data), and one knows that one will stamp as ID field on every file. In the other thread, OP has given us three perfect examples of precisely that, the total absence of modelling.
ERD cannot be used for (a) Relational modelling of any kind, (b) modelling data of any kind by a mind that is cognisant of the /RM (1970, fully established by 1981, available in SQL platforms 1983).
Since ERD does not handle Relational Keys, the bottom line is, ERD is anti-Relational.
The freak brigade (Date; Darwen; Fagin; and their followers) play the Straw Man that is their god, they use ERD to muddle instead of model, and then on the basis that ERD fails re Keys, they declare that the /RM/ doesn’t handle Keys very well. Lies upon lies upon lies.
> If you are using them to design
> a video game, that might not be a problem, but for mapping them into
> the RM, well, they effectively cripple your design process.
Yes. Again, one cannot use ERD for Data Modelling of any kind, let alone for Data Modelling under the Relational paradigm.
I reject the notion that a database that is required for any category whatsoever is better designed without reference to the /RM/. The notion is ridiculous if you understand FOPC. If you suggest there is, please open a new thread and provide an example.
> - There are some aspects of ERDs that are *far* from intuitive. If you
> have ever tried to explain ERD relationships of degree higher than two
> (and especially how to constrain the cardinalities of the participant
> entities), then IDEF1X seems a lot simpler!
Yes, on both points. Technically, there is no Cardinality at all, any Cardinality that is drawn by the designer, is beyond ERD, and extension. The reason they do that, is precisely because Cardinality is important to the modelling process. As evidenced in the source thread.
Criteria for considering redundant relationships in ERD
https://groups.google.com/g/comp.databases.theory/c/8rUC80JwTaE
> I have recommended my colleagues to switch to IDEF1X without success
> (but without insisting either, to be honest). I guess this is simply
> because habits are hard to change and most textbooks do not use it. New
> generations pick up what they have been taught by previous generations.
That is true, and it is the same as for cannibals that live in mud huts. The Creutzfeldt–Jakob Disease is not going to effect a change in their habits. Exactly the opposite of what is required of a scientist.
> Some may feel IDEF1X is "low-level" (too many details) compared to ERDs.
False: display only the level of detail necessary for any given exercise {Entity|Key|Attribute}.
> Or some may have criticisms along the lines of this analysis:
>
> https://www.essentialstrategies.com/publications/modeling/idef1x.htm
God help me. Academics just love to sabotage themselves, and then cry about the fact that they have been sabotaged.
That is too superficial and ignorant, I don’t understand why a guy like you (with some actual experience of IDEF1X) would resort to it. It has the odour of the academic, isolated from reality, writing about how yesterdays milk is sour, without ever having milked a cow.
It is very sad that that is all that is available to academia, re IDEF1X. Perhaps try searching.
I will not answer such superficial, ignorant nonsense. However, the relevant issues are noted by you, and answered by me, below.
> Another issue may be that IDEF1X is not so popular in the industry
> either, except for some sectors or in some geographical areas. E.g., it
> doesn't seem to be so popular in Europe.
Academics know absolutely nothing about the industry. They tell each other what the “industry” is, and use that to make sure they stay FORTY YEARS behind the industry. Think about the fact that there are many DM tools available, and each of them provide IDEF1X, and the fact that academics will not use them, in order to pretend that both the DM tools, and IDEF1X, does not exist. Pure ignorance of the industry that they purport to serve. Sure, they stick to the freeware, eg. the various anti-SQL, which is not SQL< and complain that “SQL is broken”. Likewise, there is no freeware DM tool, so they say it does not exist, and does not exist in their contrived “industry”. Meanwhile, back in the industry, we have had those tools since 1983, automated since 1989, and we have resolved those problems since 1983, automated since 1989.
> My main complaint with IDEF1X is the treatment of generalization
> hierarchies, in particular the lack of a correct way to model a total
> inclusive specialization (A must be one of B1, ..., Bn and it may be any
> of B1, ..., Bn); the approach I have seen around (e.g., see Thomas
> Bruce's book or ERwin's manual) does not cover such case in a sound way.
> And the standard never mentions inclusive specializations, AFAICT.
The problem there is, you do not understand Transactions (ACID, since 1960 in IBM Mainframes; since 1970 in pre-relational DBMS; since 1981 in RDBMS). It is a major blind spot for academics and theoreticians, that practitioners simply do not have. There are several threads in this forum that simply do not progress to closure due to the unwillingness of academics to engage, and to learn about ACID Transactions. Again, academics are stuck in their vacuum tube of what they themselves have written (filth from Stonebraker; Ellis; Date; Darwen; Fagin; etc), and are in reinforced pathological denial of the actual industry; the actual commercial products that serve the industry, and they remain so for FIFTY YEARS.
Any good NON-"theoretical" data modeling/Codd-relational database design courses/books/papers out there
https://groups.google.com/g/comp.databases.theory/c/T8sRg3I2vJU
[[Relational] Database] Open Architecture Standard
https://groups.google.com/g/comp.databases.theory/c/umEPHEi5FA8
MVCC, Advantages & Disadvantages
https://groups.google.com/g/comp.databases.theory/c/f474bCuvZ_A
Since you are the single academic who is venturing out from their safe space, I welcome such an engagement, please feel free to engage those threads, if and when you have the interest.
Yes, absolutely, out here in the real world, using real SQL RDBMS platforms since 1983, we have been implementing precisely both Exclusive and Non-Exclusive Subtypes perfectly, since 1983. That is:
- for a Non-Exclusive Basetype, we guarantee that there must be at least one Subtype
- for an Exclusive Basetype, we guarantee that there must be one Subtype only
This document may assist somewhat in explanation, noting that the full and formal explanation lies in ACID Transactions, which has not progressed in this forum, and indeed in academia, since 1970.
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf
If there is anything in that doc that is not completely understood, please ask.
> Another thing: people who already know ERDs easily accept the
> distinction between independent and dependent entities (which reminds
> them of the distinction between ERD's strong and weak entities), but
> they may not see what additional information identifying and
> non-identifying relationships bring to the table
They can’t. Because it is not taught, not defined. Teaching the distinction between strong::weak, but not teaching how to implement that, in terms of the child PK, is criminal. Chen’s strong::weak is weak. RM/IDEF1X Independent vs Dependent; Identifying vs Non-Identifying, is strong (has not changed since 1970).
Since it is one concept, not two, in the RM/IDEF1X, you get the one concept with the one implementation method, and it can be perceived several ways, any way you like, at any level-of-detail you like.
> (“If you drew all the
> relationships without dashed lines, you would still be able to interpret
> your model in the same way"). I found it difficult sometimes to convince
> them that such a distinction is important.
Only in the early stages of data modelling. Once the Keys are exposed, and worked, which is the bulk of the modelling exercise, that distinction is exposed, and difference is plain.
When engaging the modelling exercise fully, meaning, in order, FOPC; the /RM; and IDEF1X as the rendition, and as you confirm “meaning is king”, you may realise:
- the solid lines define ownership (Extension, of the Matter of the parent)
- the dashed lines define classification (imposition of the Form of the parent)
Assuming you are familiar with Aristotelian concepts, otherwise please ask.
> Another criticism about IDEF1X is the lack of many-to-many relationships
> (except in "Level 1"/"ER" diagrams), which sometimes makes it
> awkward to read a relationship, because it is more natural to skip the
> intermediate associative entity.
You have the right idea, but not the precise method.
> For instance, one might want to model
> the following:
>
> - a customer BUYS zero or more products;
> - a product IS BOUGHT BY zero or more customers.
>
> In IDEF1X, you'd do it like this:
>
> +-----------+ +-----------+
> | | | |
> | Customer | | Product |
> | | | |
> +-----------+ +-----------+
> | |
> | |
> | +-----------+ |
> | | | |
> +-----O| Purchase |O-----+
> | |
> +-----------+
>
> How would you label the relationships? You might use:
>
> - a customer PERFORMS (?) zero or more purchases;
> - a product IS SOLD AS (?) zero or purchases.
>
> But the most natural reading is as above, with "buys"/"is bought by"—
> which does not mention purchases, though.
Well, in the previous model, Purchase does NOT exist, those verbs are relevant in that context only. It is natural to not-reference what is not-there.
In the model in which Purchase DOES exist, it is not natural to ignore it. The verbs must deal with the entities at the two ends of each relation, not some entity at the end of a chain.
>>>>
I believe you understand that the /RM/ is founded on First Order Predicate Calculus, and thus there is nothing in the universe that cannot be defined in FOPC, and therefore in a RDB. Thus you can’t mess with the Predicates, the are atoms, that you must treat as such. You don’t want to mis-read a Predicate in a single “link”, for focussing too much on what is at the end of a Predicate chain.
Separate point. You can’t take a summary at level 1, and apply it as detail in level 2. You have to either expand the summary at level 1 (full detail, which can then be applied at lower levels), or vacate the notion that a level 2 article can be described by a summary at level 1.
<<<<
At level 2, since Purchase exists,
Each customer BUYS zero or more products
Each product IS BOUGHT BY zero or more customers
is simply false. The truth is:
Each Customer buys 0-to-n Purchases
Each Product is sold as 0-to-n Purchases
Each Purchase is bought by 1 Customer
Each Purchase is a sale of 1 Product
Having said that, it is quite acceptable to READ OFF a Predicate chain, without violating the atomic Predicates:
- Each Customer buys 0-to-n Products via Purchase
- Each Product is sold to 0-to-n Customers via Purchase
In this example, p :
https://www.softwaregems.com.au/Documents/Documentary%20Examples/Order%20DM%20Advanced.pdf
after observing the model, it is quite acceptable to READ OFF:
- Each Party offers 0-to-n Objects via PartVendor
- Each Party uses 1-to-n Addresses via PartyAddress
Note that the above explanation regards the /Relational Model/, and FOPC, its foundation, not IDEF1X, which just happens to be the notation we are using for this data model, and which facilitates modelling data Relationally. It is not a “problem” in IDEF1X.
Put another way, if FOPC Predicates, not necessarily the calculus, but the full articulation of logic definition, is taught first, the pupils obtain a solid grounding in the definition of facts, using formal logic. That is the /semantics/ that we will later expect in a model. After that, teaching the /RM/ is easy. After that, issues in rendering a Relational Data Model in IDEF1X is easy. Issues such as these are minor and easily resolved in the context of the three layers. It is not a “problem” isolated in the third layer, devoid of context.
> IMO, this is a valid criticism. Some additional (an)notation to pick out
> "pure associative entities" (for a lack of a better term) might help.
First understand that the [pure] Associative entity consists of Keys only, no attributes. If it has attributes, it is not an Associative entity.
Then, for Associative entities, the VerbPhrase should apply to the entity at the end of the chain, not the proximate entity. That is an exception.
> >> Why, since we have had IDEF1X for Relational Data Modelling since
> >> 1983 (established and well-known international standard since 1993),
> >> do professors suppress that, and instead “teach”; push; shove;
> >> market; propagate the broken ERD, which is a pre-Relational artefact
> >> ?
> I think I have answered this above, at least by providing my own
> perspective.
Thanks.
As per the entire body of evidence, consistent, since 1970, they are actively suppressing the /RM/, and IDEF1X that goes with it. They are actively promoting pre-1970, pre-DBMS Record Filing Systems fraudulently, as “Relational”, along with the ancient; broken ERD that goes with it, and fraudulently calling it “Relational Data Modelling”.
Why ? Because their goal is the destruction of science, the suppression of truth, by causing confusion, by maintaining non-resolution, by pleading that falsity is “truth”, by denying reality, teh Four Laws of Thought.
> >> > In your model, each teacher must always be assigned to at least one
> >> > course. With
> >> >
> >> > (a) such an (unrealistic) constraint, *and*
> >> Why is that constraint “unrealistic” ? In the real world, it is
> >> a common; even pedestrian, requirement. We have been implementing
> >> such in Relational databases since 1983.
> I was thinking more in terms of "department employees", one of whose
> duties may be teaching (but they may not be teaching all the time). But
> sure, you may think in terms of employees who teach (a subset of all the
> employees): then they must teach something, of course.
Sorry, that is not what I meant.
Let me rephrase the question. Why do professors commonly labour and state that a 1::1-to-n relation is difficult, why do they pretend it is uncommon ? And how is such a relation (you correctly identify it as a Constraint) established in a Relational database (and in the data model erected in IDEF1X).
The core difference between pre-Relational theory; methods; and DBMS platforms vs the Relational Model; Relational Data Modelling; and RDBMS, is Relational Keys. The core of Relational Keys is Identity, the identity of the subject. To teach Data Modelling after say 1983 without teaching the relevance of Keys, without teaching precisely how to identify a subject, is criminal.
Here is a quick document that clarifies the issues you questioned, that I have answered. To be complete, I have added an item re Rolenames, because it is the third common “issue” that people raise:
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
------------
-- Status --
------------
In essence, you have picked up IDEF1X, you have determined it is *THE* Standard for Relational Data Modelling, and you have started to use it. Excellent, the single academic who does. However, you are hindered by reading the nonsense that academics have to say about it (noting that they actively suppress it and instead promote ERD), which is as usual ignorant and incorrect, totally unscientific.
There are no problems or difficulties whatsoever in using IDEF1X in the entire exercise of genuine Relational Data Modelling. I have close to 100 such databases, some with over 500 tables (which is why and how I have developed Extensions). Instead, if you have any questions; any difficulty at all, please ask me. Hopefully you will progress much faster.
I would say, get more experience, and use data models that have some complexity (problems to solve).
(The only problem, if one could say such a thing exists, is that IDEF1X cannot enforce the /RM/, people can still do what ever they want. I have a remedy for that, but that is beyond the scope of this thread.)
----------------
-- Conclusion --
----------------
It is very sad that academics deny the real world; the industry; the science; the methods; the platforms, and instead indulge themselves in an isolated contrived “reality”, fixed in 1969. FIFTY YEARS OUT OF DATE.
We need to appreciate that as per the mountain of consistent evidence, the “theoreticians” teach the anti-Relational, pre-1970, pre-DBMS methods as “Relational”. FOR FIFTY YEARS. Now, categorically, as per the evidence, it is clear that the “theoreticians” do not teach the Standard Relational Data Modelling, but instead teach porcine excreta as “Relational Data Modelling”. FOR FORTY YEARS.
I don’t know how you don’t strangle your colleagues.
Cheers
Derek
When it came out in 1970, the Relational Model (Codd, not the pretenders) made a paradigm shift in all areas of perceiving data (examination; data modelling; storage and retrieval; programming). Codd had an uphill battle against the established academics because they could not understand it, and against a few of the DBMS vendors, because they were interested in protecting their established products. It took about ten years to overcome those obstacles, and then it took off. IBM had an internal product that progressed through the 1970’s, eventually becoming SQL, and the market begged them to release the definition, so that it could be made a Standard, such that other vendors could provide platforms.
For those who are not old enough to remember, we had perfectly good DBMS in those days, and fairly intense design methods, first for data in general and second for the implementation in our particular DBMS. It just was not a model, in the sense that the /RM/ is a genuine model, defined mathematically and based on First Order Predicate Calculus.
I worked for Cincom, one of the “big five” DBMS vendors, in addition to being expert in their Network DBMS, we were well schooled in the competitions capabilities, in order to compete seriously. We did not care much for academic papers because the science was already deteriorating, and the best scientists (including all progressions in the science, except for the /RM/ ) were invented by engineers who worked for the DBMS vendors.
In contrast to the ever-changing freeware/whatmewear/vapourware/nowhere filth (massive suite of programs, aka open sore) that is marketed these days as “SQL” and as a “platform”, those were the days of real SQL (compliant with the standard), and real platforms (server architecture). We already had ACID Transaction from 1960 IBM/CICS/TPC, thus all pre-Relational DBMS were heavily Transaction oriented and ACID compliant. Thus the first few SQL platforms were high-throughput, high-concurrency, ACID Transaction Processing engines.
There were only two: IBM and Sybase (Britton-Lee the Database Machine people, implemented an SQL Database Machine), and there are still only two, plus a bastard son of Sybase MS/SQL for the low end of the market.
The filth, including Orable, is neither SQL, nor ACID-compliant. Hint: with the schizophrenic notion of MVCC, they cannot handle even simple contention, let alone high-throughput, or high-concurrency, or ACID. (If you wish to comment on this point, there is a separate thread open, begging for progress.)
Methods
Re methods, it was a matter of moving from the established pre-Relational methods to the Relational methods, as opposed to inventing methods for the first time. We did not have, and certainly did not dry about not having, Modelling Tools: we drew diagram on paper, using a stencil. We never heard of, nor used, ERD. Apparently it made a big splash in the academic circles.
Note well, the /Relational Model/ is a single paper that defines a single method, like all academic papers, it defines one thing, it cannot be expected to define related things (such as database design or data modelling or how to blow ones nose without getting snot on ones hands). It is telling that the pig-poop eaters (Date; Darwen; Fagin; and all their followers) wring their hands and wail about “Codd did not define this or Codd did not define that ...). Practitioners are fully capable of continuing the data modelling and database design methods while conforming to the new /RM/, without the need to be fed from a baby bottle.
In 1983 Robert Brown extended his modelling method Logical Database Design Technique to cater for the Relational Paradigm. It became used by a few important customers such as DoD, and thus became known to all DBMS vendors (I personally wrote a database for DoD in Cincom’s TOTAL DBMS), and eventually all their customers. It became widely known by 1987, when the first product ERwin came out (first by LogicWorks, and later by Computer Associates). The IDEF people took it over, named it IDEF1X (following IDEF1 for informational modelling and X for Relational), and maintained it. By 1993 it was a NIST Standard.
Several Data Modelling tools followed, such as PowerDesigner and ER/Studio, but they are nowhere near ERwin in terms of true IDEF1X or platform-neutral implementation.
The point of this thread. In the real world (as distinct from the “world” as concocted by “theoreticians” who allege to serve this space), we have:
- the real /Relational Model/ 1970,
- the real Relational Data Modelling method IDEF1X since 1983 (1987 as a product), and
- real SQL platforms since 1981.
The question begs:
- why is that unknown to the “theoreticians” ?
- why do the pig poop eaters NOT teach Relational Data Modelling ?
--- why do they NOT teach IDEF1X ?
- why do they teach instead the defunct; obsolete; anti-Relational ERD ?
These sad people are operating FIFTY YEARS behind the leading edge AFA the /RM/ is concerned, FORTY YEARS behind the leading edge AFA Standards and SQL Platforms are concerned.
Great news. There is one single academic across the entire planet, who has started a journey from the anti-Relational-marketed-as-Relational land that is their studied home, across the great divide, to the Relational world. We touched on the subject in another thread, but it deserves its own thread, so I have brought it here.
> On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
> > On 2021-03-24, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> >
> > In case you missed them. Could you please respond to these questions.
> >
> >> On Thursday, 18 March 2021 at 14:38:13 UTC+11, Derek Ignatius Asirvadem wrote:
> >> > On Tuesday, 16 March 2021 at 23:23:28 UTC+11, Nicola wrote:
> >>
> >> > Note that the "circularity" in that diagram is only apparent (ERD are
> >> > misleading).
> >>
> >> So, why in heavens name, do professors teach ERD ?
>
> I cannot speak for anyone else...
First, let me thank you for your very interesting and considerate response.
> One reason is Chen's Entity-Relationship models are likely perceived as
> easier to grasp for novices than something like IDEF1X. Whether that is
> a correct perception, it can be debated. Another reason is probably just
> historical, due to the huge influence of Chen's seminal paper.
It may have been seminal for the academics, let me assure you, it was not seminal, or even great, for practitioners of the day. It does not have a semantic base, whereas the /RM/ and IDEF1X does.
For academics. I can grant, up to 1970, the paper was amazing. After 1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct; superseded.
Ok, to rephrase the question, why was that pre-Relational method being taught after 1983, and why is it still being taught after the advent of the /RM/, after the /RM/was proved, and after the first genuine SQL platforms came out (1983), and after IDEF1X came out (1983 to practitioners, 1989 as a product, 1993 as an international standard) ?
Novices grasp anything you give them, so the responsible professor gives them the right thing, not cabbage patch dolls for Computer Science.
> In a general setting, ERD is fine for teaching the basics of modeling:
> entities, relationships, generalizations. For someone who has never done
> it, taking a description in a natural language and analyze it to distill
> such concepts and put them in diagrammatic form is not a trivial task
> (well, it's not trivial even for experts!).
> ERDs can be useful as
> a gentle introduction to such topics.
>
> ERD can be introduced without any background knowledge in databases
For introductory levels, show them IDEF1X/Entity level.
> (although that is true about IDEF1X to some extent, when you are
> teaching IDEF1X you are in fact teaching the Relational Model),
Yes !!! Instead of whatever mumbo jumbo that is NOT Relational. That is pretty much the central point. To think about data in terms of the /RM/, not in terms of the physical records that the freaks can contrive in their little crania, because they cannot grasp the /RM/.
> and even
> for purposes that are different from mapping into the Relational Model.
> For instance, one may use ERDs in the context of programming—say, to
> design a game.
Data, the /RM/, is not application dependent. It is data dependent. It is far superior to any other method or non-method or non-thinking.
> When it comes to using ERD vs IDEF1X for designing Relational databases,
> my experience is as follows:
>
> - when teaching ERDs, one also has to explain the rules to translate
> them into the RM:
One can’t. I don’t. I didn’t in the example. It is like translating the thinking that goes into rap “music”, into the thinking that goes into Beethoven’s Fifth. Don’t. Just think classical music. Don’t draw a diagram that has an inferior understanding of data (actually NO understanding of data), and then attempt to translate it into a higher form. No, think in the higher form. and then draw the higher form.
> this is a layer of accidental complexity that IDEF1X
> completely eliminates.
Yes. And it does so by design, not by accident.
> - On other hand, when teaching IDEF1X one has to introduce a richer
> language, so it doesn't take less time to teach than ERD; but I'd say
> that it doesn't take much longer either, as some people might might
> expect.
When you teach a principle (the RM), the whole lesson, even though it is rich, is actually faster, and more deeply understood. When you teach without the principle (ERD, no RM), you struggle to teach because there is no principle, just a collection of low-level axioms. Fragments of meat on the ground that only pigs and rats forage for, but hey, that is what the “theoreticians” promote.
> - Perhaps contrary to someone's opinion, IDEF1X models can be grasped by
> novices: I have successfully taught IDEF1X to people without any
> background in Computer Science and high-school level of acquaintance
> with logic for a few years now.
Absolutely. I have been doing it for forty years. Half the time, I don’t even tell them what it is, I just erect the data model during the discussion. If they ask, I give them my short IDEF1X Intro:
https://www.softwaregems.com.au/Documents/Documentary%20Examples/IDEF1X%20Introduction.pdf
> - ERDs make it difficult or impossible to reason about keys effectively:
> think split keys, for instance. Or common ancestor constraints. This
> is one of my biggest issues with ERDs.
Well, it is completely 100% brain-dead re the concept of Keys. Which is why I say that ERD is anti-Relational. The central concept in the /RM/ is logical Keys, that are composite. It is not possible to teach Relational using a method that cannot describe Relational.
On the other hand, if one wishes to cancel the DATA MODELLING exercise, and to go into the establishment of premature entities (which the entire OO/ORM world slavishly does), sure, ERD works fine: the “modelling” is not modelling abut a single iteration of drawing what Entities one can imagine (that is imagined, not real) for a first evaluation, based on the need (not on the data), and one knows that one will stamp as ID field on every file. In the other thread, OP has given us three perfect examples of precisely that, the total absence of modelling.
ERD cannot be used for (a) Relational modelling of any kind, (b) modelling data of any kind by a mind that is cognisant of the /RM (1970, fully established by 1981, available in SQL platforms 1983).
Since ERD does not handle Relational Keys, the bottom line is, ERD is anti-Relational.
The freak brigade (Date; Darwen; Fagin; and their followers) play the Straw Man that is their god, they use ERD to muddle instead of model, and then on the basis that ERD fails re Keys, they declare that the /RM/ doesn’t handle Keys very well. Lies upon lies upon lies.
> If you are using them to design
> a video game, that might not be a problem, but for mapping them into
> the RM, well, they effectively cripple your design process.
Yes. Again, one cannot use ERD for Data Modelling of any kind, let alone for Data Modelling under the Relational paradigm.
I reject the notion that a database that is required for any category whatsoever is better designed without reference to the /RM/. The notion is ridiculous if you understand FOPC. If you suggest there is, please open a new thread and provide an example.
> - There are some aspects of ERDs that are *far* from intuitive. If you
> have ever tried to explain ERD relationships of degree higher than two
> (and especially how to constrain the cardinalities of the participant
> entities), then IDEF1X seems a lot simpler!
Yes, on both points. Technically, there is no Cardinality at all, any Cardinality that is drawn by the designer, is beyond ERD, and extension. The reason they do that, is precisely because Cardinality is important to the modelling process. As evidenced in the source thread.
Criteria for considering redundant relationships in ERD
https://groups.google.com/g/comp.databases.theory/c/8rUC80JwTaE
> I have recommended my colleagues to switch to IDEF1X without success
> (but without insisting either, to be honest). I guess this is simply
> because habits are hard to change and most textbooks do not use it. New
> generations pick up what they have been taught by previous generations.
That is true, and it is the same as for cannibals that live in mud huts. The Creutzfeldt–Jakob Disease is not going to effect a change in their habits. Exactly the opposite of what is required of a scientist.
> Some may feel IDEF1X is "low-level" (too many details) compared to ERDs.
False: display only the level of detail necessary for any given exercise {Entity|Key|Attribute}.
> Or some may have criticisms along the lines of this analysis:
>
> https://www.essentialstrategies.com/publications/modeling/idef1x.htm
God help me. Academics just love to sabotage themselves, and then cry about the fact that they have been sabotaged.
That is too superficial and ignorant, I don’t understand why a guy like you (with some actual experience of IDEF1X) would resort to it. It has the odour of the academic, isolated from reality, writing about how yesterdays milk is sour, without ever having milked a cow.
It is very sad that that is all that is available to academia, re IDEF1X. Perhaps try searching.
I will not answer such superficial, ignorant nonsense. However, the relevant issues are noted by you, and answered by me, below.
> Another issue may be that IDEF1X is not so popular in the industry
> either, except for some sectors or in some geographical areas. E.g., it
> doesn't seem to be so popular in Europe.
Academics know absolutely nothing about the industry. They tell each other what the “industry” is, and use that to make sure they stay FORTY YEARS behind the industry. Think about the fact that there are many DM tools available, and each of them provide IDEF1X, and the fact that academics will not use them, in order to pretend that both the DM tools, and IDEF1X, does not exist. Pure ignorance of the industry that they purport to serve. Sure, they stick to the freeware, eg. the various anti-SQL, which is not SQL< and complain that “SQL is broken”. Likewise, there is no freeware DM tool, so they say it does not exist, and does not exist in their contrived “industry”. Meanwhile, back in the industry, we have had those tools since 1983, automated since 1989, and we have resolved those problems since 1983, automated since 1989.
> My main complaint with IDEF1X is the treatment of generalization
> hierarchies, in particular the lack of a correct way to model a total
> inclusive specialization (A must be one of B1, ..., Bn and it may be any
> of B1, ..., Bn); the approach I have seen around (e.g., see Thomas
> Bruce's book or ERwin's manual) does not cover such case in a sound way.
> And the standard never mentions inclusive specializations, AFAICT.
The problem there is, you do not understand Transactions (ACID, since 1960 in IBM Mainframes; since 1970 in pre-relational DBMS; since 1981 in RDBMS). It is a major blind spot for academics and theoreticians, that practitioners simply do not have. There are several threads in this forum that simply do not progress to closure due to the unwillingness of academics to engage, and to learn about ACID Transactions. Again, academics are stuck in their vacuum tube of what they themselves have written (filth from Stonebraker; Ellis; Date; Darwen; Fagin; etc), and are in reinforced pathological denial of the actual industry; the actual commercial products that serve the industry, and they remain so for FIFTY YEARS.
Any good NON-"theoretical" data modeling/Codd-relational database design courses/books/papers out there
https://groups.google.com/g/comp.databases.theory/c/T8sRg3I2vJU
[[Relational] Database] Open Architecture Standard
https://groups.google.com/g/comp.databases.theory/c/umEPHEi5FA8
MVCC, Advantages & Disadvantages
https://groups.google.com/g/comp.databases.theory/c/f474bCuvZ_A
Since you are the single academic who is venturing out from their safe space, I welcome such an engagement, please feel free to engage those threads, if and when you have the interest.
Yes, absolutely, out here in the real world, using real SQL RDBMS platforms since 1983, we have been implementing precisely both Exclusive and Non-Exclusive Subtypes perfectly, since 1983. That is:
- for a Non-Exclusive Basetype, we guarantee that there must be at least one Subtype
- for an Exclusive Basetype, we guarantee that there must be one Subtype only
This document may assist somewhat in explanation, noting that the full and formal explanation lies in ACID Transactions, which has not progressed in this forum, and indeed in academia, since 1970.
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf
If there is anything in that doc that is not completely understood, please ask.
> Another thing: people who already know ERDs easily accept the
> distinction between independent and dependent entities (which reminds
> them of the distinction between ERD's strong and weak entities), but
> they may not see what additional information identifying and
> non-identifying relationships bring to the table
They can’t. Because it is not taught, not defined. Teaching the distinction between strong::weak, but not teaching how to implement that, in terms of the child PK, is criminal. Chen’s strong::weak is weak. RM/IDEF1X Independent vs Dependent; Identifying vs Non-Identifying, is strong (has not changed since 1970).
Since it is one concept, not two, in the RM/IDEF1X, you get the one concept with the one implementation method, and it can be perceived several ways, any way you like, at any level-of-detail you like.
> (“If you drew all the
> relationships without dashed lines, you would still be able to interpret
> your model in the same way"). I found it difficult sometimes to convince
> them that such a distinction is important.
Only in the early stages of data modelling. Once the Keys are exposed, and worked, which is the bulk of the modelling exercise, that distinction is exposed, and difference is plain.
When engaging the modelling exercise fully, meaning, in order, FOPC; the /RM; and IDEF1X as the rendition, and as you confirm “meaning is king”, you may realise:
- the solid lines define ownership (Extension, of the Matter of the parent)
- the dashed lines define classification (imposition of the Form of the parent)
Assuming you are familiar with Aristotelian concepts, otherwise please ask.
> Another criticism about IDEF1X is the lack of many-to-many relationships
> (except in "Level 1"/"ER" diagrams), which sometimes makes it
> awkward to read a relationship, because it is more natural to skip the
> intermediate associative entity.
You have the right idea, but not the precise method.
> For instance, one might want to model
> the following:
>
> - a customer BUYS zero or more products;
> - a product IS BOUGHT BY zero or more customers.
>
> In IDEF1X, you'd do it like this:
>
> +-----------+ +-----------+
> | | | |
> | Customer | | Product |
> | | | |
> +-----------+ +-----------+
> | |
> | |
> | +-----------+ |
> | | | |
> +-----O| Purchase |O-----+
> | |
> +-----------+
>
> How would you label the relationships? You might use:
>
> - a customer PERFORMS (?) zero or more purchases;
> - a product IS SOLD AS (?) zero or purchases.
>
> But the most natural reading is as above, with "buys"/"is bought by"—
> which does not mention purchases, though.
Well, in the previous model, Purchase does NOT exist, those verbs are relevant in that context only. It is natural to not-reference what is not-there.
In the model in which Purchase DOES exist, it is not natural to ignore it. The verbs must deal with the entities at the two ends of each relation, not some entity at the end of a chain.
>>>>
I believe you understand that the /RM/ is founded on First Order Predicate Calculus, and thus there is nothing in the universe that cannot be defined in FOPC, and therefore in a RDB. Thus you can’t mess with the Predicates, the are atoms, that you must treat as such. You don’t want to mis-read a Predicate in a single “link”, for focussing too much on what is at the end of a Predicate chain.
Separate point. You can’t take a summary at level 1, and apply it as detail in level 2. You have to either expand the summary at level 1 (full detail, which can then be applied at lower levels), or vacate the notion that a level 2 article can be described by a summary at level 1.
<<<<
At level 2, since Purchase exists,
Each customer BUYS zero or more products
Each product IS BOUGHT BY zero or more customers
is simply false. The truth is:
Each Customer buys 0-to-n Purchases
Each Product is sold as 0-to-n Purchases
Each Purchase is bought by 1 Customer
Each Purchase is a sale of 1 Product
Having said that, it is quite acceptable to READ OFF a Predicate chain, without violating the atomic Predicates:
- Each Customer buys 0-to-n Products via Purchase
- Each Product is sold to 0-to-n Customers via Purchase
In this example, p :
https://www.softwaregems.com.au/Documents/Documentary%20Examples/Order%20DM%20Advanced.pdf
after observing the model, it is quite acceptable to READ OFF:
- Each Party offers 0-to-n Objects via PartVendor
- Each Party uses 1-to-n Addresses via PartyAddress
Note that the above explanation regards the /Relational Model/, and FOPC, its foundation, not IDEF1X, which just happens to be the notation we are using for this data model, and which facilitates modelling data Relationally. It is not a “problem” in IDEF1X.
Put another way, if FOPC Predicates, not necessarily the calculus, but the full articulation of logic definition, is taught first, the pupils obtain a solid grounding in the definition of facts, using formal logic. That is the /semantics/ that we will later expect in a model. After that, teaching the /RM/ is easy. After that, issues in rendering a Relational Data Model in IDEF1X is easy. Issues such as these are minor and easily resolved in the context of the three layers. It is not a “problem” isolated in the third layer, devoid of context.
> IMO, this is a valid criticism. Some additional (an)notation to pick out
> "pure associative entities" (for a lack of a better term) might help.
First understand that the [pure] Associative entity consists of Keys only, no attributes. If it has attributes, it is not an Associative entity.
Then, for Associative entities, the VerbPhrase should apply to the entity at the end of the chain, not the proximate entity. That is an exception.
> >> Why, since we have had IDEF1X for Relational Data Modelling since
> >> 1983 (established and well-known international standard since 1993),
> >> do professors suppress that, and instead “teach”; push; shove;
> >> market; propagate the broken ERD, which is a pre-Relational artefact
> >> ?
> I think I have answered this above, at least by providing my own
> perspective.
Thanks.
As per the entire body of evidence, consistent, since 1970, they are actively suppressing the /RM/, and IDEF1X that goes with it. They are actively promoting pre-1970, pre-DBMS Record Filing Systems fraudulently, as “Relational”, along with the ancient; broken ERD that goes with it, and fraudulently calling it “Relational Data Modelling”.
Why ? Because their goal is the destruction of science, the suppression of truth, by causing confusion, by maintaining non-resolution, by pleading that falsity is “truth”, by denying reality, teh Four Laws of Thought.
> >> > In your model, each teacher must always be assigned to at least one
> >> > course. With
> >> >
> >> > (a) such an (unrealistic) constraint, *and*
> >> Why is that constraint “unrealistic” ? In the real world, it is
> >> a common; even pedestrian, requirement. We have been implementing
> >> such in Relational databases since 1983.
> I was thinking more in terms of "department employees", one of whose
> duties may be teaching (but they may not be teaching all the time). But
> sure, you may think in terms of employees who teach (a subset of all the
> employees): then they must teach something, of course.
Sorry, that is not what I meant.
Let me rephrase the question. Why do professors commonly labour and state that a 1::1-to-n relation is difficult, why do they pretend it is uncommon ? And how is such a relation (you correctly identify it as a Constraint) established in a Relational database (and in the data model erected in IDEF1X).
The core difference between pre-Relational theory; methods; and DBMS platforms vs the Relational Model; Relational Data Modelling; and RDBMS, is Relational Keys. The core of Relational Keys is Identity, the identity of the subject. To teach Data Modelling after say 1983 without teaching the relevance of Keys, without teaching precisely how to identify a subject, is criminal.
Here is a quick document that clarifies the issues you questioned, that I have answered. To be complete, I have added an item re Rolenames, because it is the third common “issue” that people raise:
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
------------
-- Status --
------------
In essence, you have picked up IDEF1X, you have determined it is *THE* Standard for Relational Data Modelling, and you have started to use it. Excellent, the single academic who does. However, you are hindered by reading the nonsense that academics have to say about it (noting that they actively suppress it and instead promote ERD), which is as usual ignorant and incorrect, totally unscientific.
There are no problems or difficulties whatsoever in using IDEF1X in the entire exercise of genuine Relational Data Modelling. I have close to 100 such databases, some with over 500 tables (which is why and how I have developed Extensions). Instead, if you have any questions; any difficulty at all, please ask me. Hopefully you will progress much faster.
I would say, get more experience, and use data models that have some complexity (problems to solve).
(The only problem, if one could say such a thing exists, is that IDEF1X cannot enforce the /RM/, people can still do what ever they want. I have a remedy for that, but that is beyond the scope of this thread.)
----------------
-- Conclusion --
----------------
It is very sad that academics deny the real world; the industry; the science; the methods; the platforms, and instead indulge themselves in an isolated contrived “reality”, fixed in 1969. FIFTY YEARS OUT OF DATE.
We need to appreciate that as per the mountain of consistent evidence, the “theoreticians” teach the anti-Relational, pre-1970, pre-DBMS methods as “Relational”. FOR FIFTY YEARS. Now, categorically, as per the evidence, it is clear that the “theoreticians” do not teach the Standard Relational Data Modelling, but instead teach porcine excreta as “Relational Data Modelling”. FOR FORTY YEARS.
I don’t know how you don’t strangle your colleagues.
Cheers
Derek
Nicola
Mar 31, 2021, 7:58:03 AM3/31/21
to
On 2021-03-29, Derek Ignatius Asirvadem <derek.a...@gmail.com>
wrote:
academics" you mention? *Some* academics may have had issues with Codd's
proposal, but it was definitely understood, and supported, by many other
academics. And certainly at a greater degree than people in industry.
This is confirmed by those who were there:
https://archive.computerhistory.org/resources/access/text/2015/06/102702111-05-01-acc.pdf
E.g., quote from p. 8:
"So Codd's paper got some traction in the academic community where these
mathematical concepts were very familiar. It didn't, at first, get much
traction in the commercial database community. They had their
navigational systems. [...]"
Another first-hand historical perspective is provided by:
https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
Quote from the "Prehistory" section:
"[...] Nevertheless, what kicked off this work [on project Gamma-0 and,
eventually, System R] was a key paper by Ted Codd - was it published in
1970 in CACM?
- Yes.
- A couple of us from the Systems Department had tried to read it -
couldn't make heads nor tails out of it. [laughter] At least back
then, it seemed like a very badly written paper: some industrial
motivation, and then right into the math. [laughter]"
Those are not academics talking.
Regarding the rest of your historical comments, I do not have anything
to add or object to. Except, perhaps, that the best DBMS in the world
apparently survives in legacy mode now.
> The point of this thread.
Let's come to the point.
>> On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
>> One reason is Chen's Entity-Relationship models are likely perceived
>> as easier to grasp for novices than something like IDEF1X. Whether
>> that is a correct perception, it can be debated. Another reason is
>> probably just historical, due to the huge influence of Chen's seminal
>> paper.
>
> It may have been seminal for the academics, let me assure you, it was
> not seminal, or even great, for practitioners of the day. It does not
> have a semantic base, whereas the /RM/ and IDEF1X does.
>
> For academics. I can grant, up to 1970, the paper was amazing. After
> 1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct;
> superseded.
Uh? Chen's ER paper is from 1976. That was a period of intense research
on so called "semantic modelling" (also spurred in part by Codd's work).
IDEF1X relies heavily upon Chen's shoulders. I'd say that the paper has
aged pretty well as we (let me simplify a bit) are still modelling in
terms of entities, relationships and attributes.
IMO, you are conflating the overall contributions of Chen (and others
working on semantic models), which are important, influential and still
relevant, with the specific details of the notation he invented, which
is not ideal for Relational database design.
> Ok, to rephrase the question, why was that pre-Relational method being
> taught after 1983, and why is it still being taught after the advent
> of the /RM/, after the /RM/was proved, and after the first genuine SQL
> platforms came out (1983), and after IDEF1X came out (1983 to
> practitioners, 1989 as a product, 1993 as an international standard) ?
I already told you my point of view.
Come out with a good database book, with a modern, sound, approach to
data modeling based on IDEF1X, and tell your publisher to send a copy
for evaluation to all academic database researchers. There is no
inherent reason why it should not get adopted because it dismisses ERDs
in favor of IDEF1X. Quite the opposite, actually. There is much need for
a really good reference on database design for the XXI century. I can't
recommend anything off the top of my head.
> after IDEF1X came out [in...] 1993 as an international standard)
The FIPS standard has been withdrawn by NIST in 2008. But IDEF1X has
also been an IEEE standard since 1998, and an ISO/IEC/IEEE standard
since 2012.
>> In a general setting, ERD is fine for teaching the basics of
>> modeling
>>
>> Some may feel IDEF1X is "low-level" (too many details) compared to
>> ERDs.
>
> False: display only the level of detail necessary for any given
> exercise {Entity|Key|Attribute}.
I agree. I did not mean to imply that I think otherwise; just that
a cursory look by someone who knows ERDs but not IDEF1X may lead to such
remarks.
>> Or some may have criticisms along the lines of this analysis:
>>
>> https://www.essentialstrategies.com/publications/modeling/idef1x.htm
>
> God help me. Academics just love to sabotage themselves, and then cry
> about the fact that they have been sabotaged.
Just brought it as an instance of what a superficial look at the
notation may lead to. I do not think that it is a good critical analysis
in any way. And not by an academic either.
>> My main complaint with IDEF1X is the treatment of generalization
>> hierarchies, in particular the lack of a correct way to model a total
>> inclusive specialization (A must be one of B1, ..., Bn and it may be
>> any of B1, ..., Bn); the approach I have seen around (e.g., see
>> Thomas Bruce's book or ERwin's manual) does not cover such case in
>> a sound way. And the standard never mentions inclusive
>> specializations, AFAICT.
>
> The problem there is, you do not understand Transactions
Look, as much as it may be disappointing to you: I know. Very well.
I know, in particular, how to deal with specialization hierarchies
transactionally.
> There are several threads in this forum that simply do not progress to
> closure due to the unwillingness of academics to engage, and to learn
> about ACID Transactions.
Yes, I did not feel those discussions were going towards fruitful
directions. But, time permitting, I might eventually return on the MVCC
vs 2PL matter.
> This document may assist somewhat in explanation, noting that the full
> and formal explanation lies in ACID Transactions, which has not
> progressed in this forum, and indeed in academia, since 1970.
>
> https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf
>
> If there is anything in that doc that is not completely understood,
> please ask.
That's perfectly clear.
>> (“If you drew all the relationships without dashed lines, you would
>> still be able to interpret your model in the same way"). I found it
>> difficult sometimes to convince them that such a distinction is
>> important.
>
> Only in the early stages of data modelling. Once the Keys are
> exposed, and worked, which is the bulk of the modelling exercise, that
> distinction is exposed, and difference is plain.
>
> When engaging the modelling exercise fully, meaning, in order, FOPC;
> the /RM; and IDEF1X as the rendition, and as you confirm “meaning is
> king”, you may realise: - the solid lines define ownership (Extension,
> of the Matter of the parent) - the dashed lines define classification
> (imposition of the Form of the parent)
That's clear, too.
>> Another criticism about IDEF1X is the lack of many-to-many
>> relationships (except in "Level 1"/"ER" diagrams), which sometimes
>> makes it awkward to read a relationship, because it is more natural
>> to skip the intermediate associative entity.
>
> You have the right idea, but not the precise method.
I'm good with your explanation, thanks.
>> >> > In your model, each teacher must always be assigned to at least
>> >> > one course. With
>> >> >
>> >> > (a) such an (unrealistic) constraint, *and*
>> >> Why is that constraint “unrealistic” ? In the real world, it is
>> >> a common; even pedestrian, requirement. We have been implementing
>> >> such in Relational databases since 1983.
>> I was thinking more in terms of "department employees", one of whose
>> duties may be teaching (but they may not be teaching all the time).
>> But sure, you may think in terms of employees who teach (a subset of
>> all the employees): then they must teach something, of course.
>
> Sorry, that is not what I meant.
>
> Let me rephrase the question. Why do professors commonly labour and
> state that a 1::1-to-n relation is difficult, why do they pretend it
> is uncommon ?
Ah, ok. Yes, on this point I agree that it depends on people not
thinking transactionally. I did *not* mean that 1::1-to-n constraints
are unrealistic!
> Here is a quick document that clarifies the issues you questioned,
> that I have answered. To be complete, I have added an item re
> Rolenames, because it is the third common “issue” that people raise:
> https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
A question: what is the use case for an association that does not imply
a foreign key (rightmost symbol in your "improved IE")? Why would you
require a parent entity to exist at the time of insertion, but not
later?
Regarding subtyping, my critique is specifically on the notation given
in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
Subtype". Let me denote the specialization symbol with `-O||`, and
a categorization cluster with `P -O|| {C1, ..., Cn}`.
By definition, P -O|| {C1, ..., Cn} means:
"P must be exactly one of C1, ..., Cn".
If an entity P has two ore more clusters, each should be interpreted as
above. For instance:
P -O|| {A,B}
P -O|| {C,D}
reads as:
- P must be (exactly) one of A and B; and
- P must be (exactly) one of C and D.
The notation I'm criticizing corresponds to:
P -O|| {A}
P -O|| {B}
which, by the definition above, one should read as:
- P must be A; and
- P must be B.
Instead, the assumed interpretation is:
- P must be A or B; and
- P may be both A and B,
which is inconsistent with the general definition.
> I don’t know how you don’t strangle your colleagues.
It's for fear of law enforcement :D
Jokes apart, my database colleagues are among the best people in my
department!
Nicola
wrote:
> Introduction
>
> When it came out in 1970, the Relational Model (Codd, not the
> pretenders) made a paradigm shift in all areas of perceiving data
> (examination; data modelling; storage and retrieval; programming).
> Codd had an uphill battle against the established academics because
> they could not understand it,
I don't think that's a fair assessment. Who are those "established
>
> When it came out in 1970, the Relational Model (Codd, not the
> pretenders) made a paradigm shift in all areas of perceiving data
> (examination; data modelling; storage and retrieval; programming).
> Codd had an uphill battle against the established academics because
> they could not understand it,
academics" you mention? *Some* academics may have had issues with Codd's
proposal, but it was definitely understood, and supported, by many other
academics. And certainly at a greater degree than people in industry.
This is confirmed by those who were there:
https://archive.computerhistory.org/resources/access/text/2015/06/102702111-05-01-acc.pdf
E.g., quote from p. 8:
"So Codd's paper got some traction in the academic community where these
mathematical concepts were very familiar. It didn't, at first, get much
traction in the commercial database community. They had their
navigational systems. [...]"
Another first-hand historical perspective is provided by:
https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
Quote from the "Prehistory" section:
"[...] Nevertheless, what kicked off this work [on project Gamma-0 and,
eventually, System R] was a key paper by Ted Codd - was it published in
1970 in CACM?
- Yes.
- A couple of us from the Systems Department had tried to read it -
couldn't make heads nor tails out of it. [laughter] At least back
then, it seemed like a very badly written paper: some industrial
motivation, and then right into the math. [laughter]"
Those are not academics talking.
Regarding the rest of your historical comments, I do not have anything
to add or object to. Except, perhaps, that the best DBMS in the world
apparently survives in legacy mode now.
> The point of this thread.
>> On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
>> One reason is Chen's Entity-Relationship models are likely perceived
>> as easier to grasp for novices than something like IDEF1X. Whether
>> that is a correct perception, it can be debated. Another reason is
>> probably just historical, due to the huge influence of Chen's seminal
>> paper.
>
> It may have been seminal for the academics, let me assure you, it was
> not seminal, or even great, for practitioners of the day. It does not
> have a semantic base, whereas the /RM/ and IDEF1X does.
>
> For academics. I can grant, up to 1970, the paper was amazing. After
> 1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct;
> superseded.
on so called "semantic modelling" (also spurred in part by Codd's work).
IDEF1X relies heavily upon Chen's shoulders. I'd say that the paper has
aged pretty well as we (let me simplify a bit) are still modelling in
terms of entities, relationships and attributes.
IMO, you are conflating the overall contributions of Chen (and others
working on semantic models), which are important, influential and still
relevant, with the specific details of the notation he invented, which
is not ideal for Relational database design.
> Ok, to rephrase the question, why was that pre-Relational method being
> taught after 1983, and why is it still being taught after the advent
> of the /RM/, after the /RM/was proved, and after the first genuine SQL
> platforms came out (1983), and after IDEF1X came out (1983 to
> practitioners, 1989 as a product, 1993 as an international standard) ?
Come out with a good database book, with a modern, sound, approach to
data modeling based on IDEF1X, and tell your publisher to send a copy
for evaluation to all academic database researchers. There is no
inherent reason why it should not get adopted because it dismisses ERDs
in favor of IDEF1X. Quite the opposite, actually. There is much need for
a really good reference on database design for the XXI century. I can't
recommend anything off the top of my head.
> after IDEF1X came out [in...] 1993 as an international standard)
The FIPS standard has been withdrawn by NIST in 2008. But IDEF1X has
also been an IEEE standard since 1998, and an ISO/IEC/IEEE standard
since 2012.
>> In a general setting, ERD is fine for teaching the basics of
>> modeling
>>
>> ERDs can be useful as a gentle introduction to such topics.
>>
>> ERD can be introduced without any background knowledge in databases
>
> For introductory levels, show them IDEF1X/Entity level.
Sure, I do that.
>>
>> ERD can be introduced without any background knowledge in databases
>
> For introductory levels, show them IDEF1X/Entity level.
>> Some may feel IDEF1X is "low-level" (too many details) compared to
>> ERDs.
>
> False: display only the level of detail necessary for any given
> exercise {Entity|Key|Attribute}.
a cursory look by someone who knows ERDs but not IDEF1X may lead to such
remarks.
>> Or some may have criticisms along the lines of this analysis:
>>
>> https://www.essentialstrategies.com/publications/modeling/idef1x.htm
>
> God help me. Academics just love to sabotage themselves, and then cry
> about the fact that they have been sabotaged.
notation may lead to. I do not think that it is a good critical analysis
in any way. And not by an academic either.
>> My main complaint with IDEF1X is the treatment of generalization
>> hierarchies, in particular the lack of a correct way to model a total
>> inclusive specialization (A must be one of B1, ..., Bn and it may be
>> any of B1, ..., Bn); the approach I have seen around (e.g., see
>> Thomas Bruce's book or ERwin's manual) does not cover such case in
>> a sound way. And the standard never mentions inclusive
>> specializations, AFAICT.
>
> The problem there is, you do not understand Transactions
I know, in particular, how to deal with specialization hierarchies
transactionally.
> There are several threads in this forum that simply do not progress to
> closure due to the unwillingness of academics to engage, and to learn
> about ACID Transactions.
directions. But, time permitting, I might eventually return on the MVCC
vs 2PL matter.
> This document may assist somewhat in explanation, noting that the full
> and formal explanation lies in ACID Transactions, which has not
> progressed in this forum, and indeed in academia, since 1970.
>
> https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf
>
> If there is anything in that doc that is not completely understood,
> please ask.
>> (“If you drew all the relationships without dashed lines, you would
>> still be able to interpret your model in the same way"). I found it
>> difficult sometimes to convince them that such a distinction is
>> important.
>
> Only in the early stages of data modelling. Once the Keys are
> exposed, and worked, which is the bulk of the modelling exercise, that
> distinction is exposed, and difference is plain.
>
> When engaging the modelling exercise fully, meaning, in order, FOPC;
> the /RM; and IDEF1X as the rendition, and as you confirm “meaning is
> king”, you may realise: - the solid lines define ownership (Extension,
> of the Matter of the parent) - the dashed lines define classification
> (imposition of the Form of the parent)
>> Another criticism about IDEF1X is the lack of many-to-many
>> relationships (except in "Level 1"/"ER" diagrams), which sometimes
>> makes it awkward to read a relationship, because it is more natural
>> to skip the intermediate associative entity.
>
> You have the right idea, but not the precise method.
>> >> > In your model, each teacher must always be assigned to at least
>> >> > one course. With
>> >> >
>> >> > (a) such an (unrealistic) constraint, *and*
>> >> Why is that constraint “unrealistic” ? In the real world, it is
>> >> a common; even pedestrian, requirement. We have been implementing
>> >> such in Relational databases since 1983.
>> I was thinking more in terms of "department employees", one of whose
>> duties may be teaching (but they may not be teaching all the time).
>> But sure, you may think in terms of employees who teach (a subset of
>> all the employees): then they must teach something, of course.
>
> Sorry, that is not what I meant.
>
> Let me rephrase the question. Why do professors commonly labour and
> state that a 1::1-to-n relation is difficult, why do they pretend it
> is uncommon ?
thinking transactionally. I did *not* mean that 1::1-to-n constraints
are unrealistic!
> Here is a quick document that clarifies the issues you questioned,
> that I have answered. To be complete, I have added an item re
> Rolenames, because it is the third common “issue” that people raise:
> https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
a foreign key (rightmost symbol in your "improved IE")? Why would you
require a parent entity to exist at the time of insertion, but not
later?
Regarding subtyping, my critique is specifically on the notation given
in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
Subtype". Let me denote the specialization symbol with `-O||`, and
a categorization cluster with `P -O|| {C1, ..., Cn}`.
By definition, P -O|| {C1, ..., Cn} means:
"P must be exactly one of C1, ..., Cn".
If an entity P has two ore more clusters, each should be interpreted as
above. For instance:
P -O|| {A,B}
P -O|| {C,D}
reads as:
- P must be (exactly) one of A and B; and
- P must be (exactly) one of C and D.
The notation I'm criticizing corresponds to:
P -O|| {A}
P -O|| {B}
which, by the definition above, one should read as:
- P must be A; and
- P must be B.
Instead, the assumed interpretation is:
- P must be A or B; and
- P may be both A and B,
which is inconsistent with the general definition.
> I don’t know how you don’t strangle your colleagues.
Jokes apart, my database colleagues are among the best people in my
department!
Nicola
Nicola
Mar 31, 2021, 11:54:53 AM3/31/21
to
On 2021-03-31, Nicola <nic...@nohost.org> wrote:
> Regarding subtyping, my critique is specifically on the notation given
> in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
> Subtype". Let me denote the specialization symbol with `-O||`, and
> a categorization cluster with `P -O|| {C1, ..., Cn}`.
> By definition, P -O|| {C1, ..., Cn} means:
>
> "P must be exactly one of C1, ..., Cn".
>
> If an entity P has two ore more clusters, each should be interpreted as
> above. For instance:
>
> P -O|| {A,B}
> P -O|| {C,D}
>
> reads as:
>
> - P must be (exactly) one of A and B; and
> - P must be (exactly) one of C and D.
>
> The notation I'm criticizing corresponds to:
>
> P -O|| {A}
> P -O|| {B}
>
> which, by the definition above, one should read as:
>
> - P must be A; and
> - P must be B.
>
> Instead, the assumed interpretation is:
>
> - P must be A or B; and
> - P may be both A and B,
>
> which is inconsistent with the general definition.
More precisely, it is inconsistent with IDEF1X's ISO (or FIPS) standard.
> Regarding subtyping, my critique is specifically on the notation given
> in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
> Subtype". Let me denote the specialization symbol with `-O||`, and
> a categorization cluster with `P -O|| {C1, ..., Cn}`.
> By definition, P -O|| {C1, ..., Cn} means:
>
> "P must be exactly one of C1, ..., Cn".
>
> If an entity P has two ore more clusters, each should be interpreted as
> above. For instance:
>
> P -O|| {A,B}
> P -O|| {C,D}
>
> reads as:
>
> - P must be (exactly) one of A and B; and
> - P must be (exactly) one of C and D.
>
> The notation I'm criticizing corresponds to:
>
> P -O|| {A}
> P -O|| {B}
>
> which, by the definition above, one should read as:
>
> - P must be A; and
> - P must be B.
>
> Instead, the assumed interpretation is:
>
> - P must be A or B; and
> - P may be both A and B,
>
> which is inconsistent with the general definition.
In a previous post I wrote that ERwin's (i.e., Bruce's) interpretation
is not sound. That is not correct. The interpretation above is well
defined. It is not entirely satisfying, though, because it introduces an
exception in the interpretation of the complete categorization symbol:
the "completeness" (in the sense that each instance of the parent must
be an instance of one of the children) applies to the whole cluster
*set*, as opposed to each single cluster, when clusters have one child.
For instance, the figure from ERwin's Guide has two single-child
clusters:
+-----------+
| P |
+-----------+
| |
+--- ---+
| |
O O
----- -----
----- -----
| |
+---------+ +---------+
| A | | B |
+---------+ +---------+
and the assumed interpretation is that every instance of P must be an
instance A or of B (or both), as opposed to "every instance of P must be
A, and every instance of P must be B". The latter cannot be expressed
under ERwin's interpretation, but it not very important, because if
"every instance of P is always an instance of A" then A can be absorbed
into P.
IDEF1X's standard, on one hand, removes this exception, by stating
explicitly that, in each complete categorization cluster, each instance
of the parent must always be an instance of one of the children—even
when the cluster has only one child.
On the other hand, it makes it impossible to express the situation
above, i.e., that "P must be A, B, or both" (complete + inclusive).
I find it somewhat surprising that this aspect has not been clarified
and addressed in the standard, which was last revised in 2019.
Nicola
Derek Ignatius Asirvadem
Apr 2, 2021, 4:58:19 AM4/2/21
to
Nicola
Thanks for yours.
Before I get into it, let us understand something.
In academia, academics know nothing of the industry, they have a contrived notion of “industry”, namely anyone who uses PissGreNONsql.
Two exceptions. Codd, because he was a genuine academic who went beyond the academics of his time, and he had his head attached to reality (the commercial application). You, because you are trying to understand reality, and that sets you apart from the academics. The main block you have to get over is, the confidence that academics know reality, which is a total fiction.
If Industry means all who use a DBMS, up to ten years ago, basically it excluded freeware, and they used commercial DBMS, PissGreNONsql was unheard of. Where freeware is used, MyNONsql leads the field. It still does, it is 1,000 times better than PooGoo while remaining in the same NONsql category. But academia only know about the “industry” that uses their pet excreta producer.
Eg. in the Financial & Banking sector, Sybase has 95% share, with MSSQL the rest. Oracle cannot even compete. In high-performance markets (F&B being one category), it is Sybase and DB2, with MSSQL after a large gap. Oracle cannot compete. Freeware is unheard of, no one wants to execute at 10,000 times slower speed or rewrite their “sql” for every new version of the freeware. These are for databases that are permanent, not “refactored” every month or quarter, such as the ever-changing filth that OO/ORM crowd excretes, that academia caters for.
So the market that uses freeware is really the start-ups, the dumb dumb dumb dumb dummies, ignorant of what commercial DBMS provide, aware of only that fraction of DBMS capability that academia bleats about. Start-ups that will not exist in ten years. No one cares about them. Except academia. Because they too, use PooGrossNONsql. And they too have no clue about ACID Transactions or Server Architecture or the features in commercial DBMS that their pet freeware does not have, and will never have. Same as the academics.
In the commercial DBMS industry (ie. the DBMS suppliers), no one knows or cares about the academics, because they are, as evidenced, fifty years behind the industry. As evidenced, there is nothing that academics have come up with that has been implemented in commercial DBMS (except Codd, again). In Sybase (small company) I can assure you from decades of first-hand experience as a Partner, we have hundreds of PhD level scientists. It may even be 1,000, as the company has grown after the acquisition by SAP.
>>>>
Don’t include such things as the hysterical MVCC in that, because “MVCC” is not a real thing, it is a imaginary thing, collectively imagined and collectively assented to, by academia alone. All hail the imbecile Stonebraker and insist that he is a deity. As I posted in the “MVCC” thread, yes, due to the heavy marketing by academia, “MVCC” has become a check-box item, without being understood by those who request it. Thus Sybase have ADDED it on top of the [existing since 1960 in IBM; since 1977 in Britton-Lee; since 1981 in Sybase] Ordinary Locking (aka incorrectly called “Two Phased Locking” or “2PL” by the academics).
To be clear, if the boffin insists of imagining something that is not real, no problem, we add a set of resources, and we erect his fantasy for him. Meanwhile, regardless of what the boffin does, regardless of what multiverse he is fornicating with his beloved sow in, if he executes an SQL verb that does something to the database, it is done in the normal [forty years extant] “2PL” so that he contends with the other users (who are probably not slaves of academia and thus have an attachment to reality, the database content), and resolves that contention, and ADDITIONALLY, we erect his fantasy on the ADDITIONAL resources, and provide/deny his attempt against his fantasy that we have erected for him. It is the way a kind and gentle mental health nurse provides care for her mentally ill and locked up patients, locked up because they insist fantasy is “reality”, which is dangerous to the public.
<<<<
The above are all general points. If you wish to challenge any of them, do so as general points.
> On Wednesday, 31 March 2021 at 22:58:03 UTC+11, Nicola wrote:
> > On 2021-03-29, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> > Introduction
> >
> > When it came out in 1970, the Relational Model (Codd, not the
> > pretenders) made a paradigm shift in all areas of perceiving data
> > (examination; data modelling; storage and retrieval; programming).
> > Codd had an uphill battle against the established academics because
> > they could not understand it,
> I don't think that's a fair assessment. Who are those "established
> academics" you mention?
The main fight was within IBM, with the likes of Date and Fagin, who pretended to be his supporters but as time has told, they are his subverters. There were others, more later.
There is absolutely zero articles in academia reinforcing or progressing the /RM/. That is evidence, for FIFTY YEARS, that academia does not understand it. All the nameless freaks, save one. Likewise there is not a single book that honestly promotes the /RM/ or progresses it. All of them that purport to articulate “Relational Database” promote instead 1960’s Record Filing Systems, based on RM/T, as confirmed in another thread. Even here, you are the only one looking into genuine Relational Data Modelling. The rest promote anti-Relational pig poop.
> *Some* academics may have had issues with Codd's
> proposal, but it was definitely understood, and supported, by many other
> academics.
Name one (prior to 1980, because that was the statement I made). After 1981, when Sybase came out, and the IBM product (many names) was established, yes, academia could no longer deny it.
Try naming one paper written any time after 1970.
> And certainly at a greater degree than people in industry.
> This is confirmed by those who were there:
>
> https://archive.computerhistory.org/resources/access/text/2015/06/102702111-05-01-acc.pdf
>
> E.g., quote from p. 8:
>
> "So Codd's paper got some traction in the academic community where these
> mathematical concepts were very familiar. It didn't, at first, get much
> traction in the commercial database community. They had their
> navigational systems. [...]"
That is not “industry”, that is one voice, and a self-serving one, an academic with no clue about the industry.
I, who worked for one of the big five DBMS vendors at the time, and previously a specialist on DEC (PDP; VAX) have already categorised it as false. Let me assure you that at Cincom, we had many scientists, many mathematicians, who had no problem understanding the /RM/. Yes, we saw the /RM/ as changing the entire landscape. We did not try to “relationalise” the product, thus we had no need to add anything to TOTAL, but the other DBMS vendors did. And that is why Codd had to write his famous Twelve Rules, to ensure that vendors were not fraudulently declaring that they were /RM/ compliant.
(The has progressed to the problem we have today, where even though SQL is THE established Standard, all the freeware and oracle do not comply, but fraudulently declare that they do.)
Likewise, let me assure you that DEC had hundreds of scientists, who understood and implemented the /RM/, their RDBMS called Rdb was brilliant. It still runs in legacy systems on VAX emulators, it still beats Orable by 10,000 times. I am not saying that emulators are good, but there is a market for it, patronised by corporations that do not fix what is NOT broken, which is why they still exist.
That (what you quote) is typical of the propaganda that academia produce and swallow. Waht you might get from guys like me (or any scientist working for a commercial DBMS provider)is, the actual reality. Obviously the thousands of scientists who work for IBM; Sybase; MS, do not even bother with fora such as this, because academics are irrelevant to the real world platforms, only I do.
Chamberlain contradicts himself all over the place, but you won’t catch it. He comes across as being a friend of Codd, but actually, if you examine it, he demeans Codd, sometimes quite subtely. Very dishonest. It is sad that academics view the Chamberlain memories as gospel. Identical to Date. Much like the Stonebraker stupidity, that has no commercial existence, but lives and thrives in academia and in freeware.
On p12 para 2:
“System R ... was not a product that was going to be released commercially. It was a feasibility demonstration. It was proof of the concept that Ted Codd's ideas actually made sense and could be implemented in a robust way. And there was a lot of skepticism about that.”
So the simple evidenced fact, from Chamberlains own mouth, his “memories”, confirms what I said, and he includes himself in that category:
>> Codd had an uphill battle against the established academics because
>> they could not understand it
On p8 para 1:
“Ted thought that we should use this concept [relations] to allow users to interact with stored data in a way that was independent of the physical representation of that data. He called this notion //data independence//”
And on p 8 para 3:
“Codd introduced the notion of relations as an abstraction for stored data, and he explained about //data independence// and why that was important”
The term in the /RM/ is Access Path Independence. Data Independence is quite a different thing.
It is amazing to me, that Chamberlain enumerates all those great mathematicians who were employed by his employer, specifically to go beyond their existing product, but still insists that DBMS providers did not have mathematicians, and were only interested in protecting their market share. Only people who are trained to accept contradiction without question can believe such utter hypocrisy. Pig poop rots the brain.
Here is what Chamberlain actually thought that the “industry” was; what the user base was, and his own admission that what he thought was absurd. Proving yet again that academics are clueless about the industry the purport to serve. p 17 para 5:
“What Ray and I thought we were doing was making access to databases available to a new class of people that hadn’t accessed databases before. We thought they were going to be engineers and architects and city planners and economists, and people like that who were not computer people, not programmers. We thought that these people shouldn’t have to turn themselves into computer experts or programmers in order to ask questions. They should ask questions in this English-keyword notation that we called SEQUEL. So with words like SELECT and FROM and WHERE and GROUP BY and ORDER BY and so on, maybe you could teach that kind of notation to people who didn’t have any computer training at all, and weren’t much interested in computers. They were interested in their domain of expertise. They wanted to study economics or something like that, and they needed to retrieve statistical information about economics, and they needed a language to do that, but they didn’t need to be programmers. That’s what SEQUEL was intended to do. I don’t think it was very successful at doing that. If you look back on it from a perspective of 30 years later, I think you don’t find a lot of architects and economists and city planners writing SEQUEL queries. SEQUEL queries are mostly written by experienced programmers who are trained and specialized in doing that, and a lot of them are generated by machines through some kind of interface that’s specialized to some domain.”
I am not suggesting that he, or any other academic at IBM Labs was stupid. Far from it. I am saying that as an academic, as evidenced, he has huge blind spots, eg. “industry”; “users”. And as is typical of academia, he is unaware that he has blind spots, and makes stupid declarations about them.
Overall, notice the difference, Chamberlain and a host of others (academic but impractical), against Codd (academic and practical). Codd was the bad guy because “he wasn’t a team player”. Thank God for that.
It is horrendous that he does not mention DSS queries in his discourse on that subject. In his /RM/, Codd provided both OLTP and DSS.
> Another first-hand historical perspective is provided by:
>
> https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
404 - Not Found.
They probably realised that it was going to be inspected and removed the filth, because it would not withstand scrutiny.
MCJones is the same idiot (nicely propagandised, well prepared) who interviewed Chamberlain, and who dutifully spouted the same propaganda. I don’t need to read it to know that it will be in the same vein.
> Quote from the "Prehistory" section:
>
> "[...] Nevertheless, what kicked off this work [on project Gamma-0 and,
> eventually, System R] was a key paper by Ted Codd - was it published in
> 1970 in CACM?
>
> - Yes.
>
> - A couple of us from the Systems Department had tried to read it -
> couldn't make heads nor tails out of it. [laughter] At least back
> then, it seemed like a very badly written paper: some industrial
> motivation, and then right into the math. [laughter]"
>
> Those are not academics talking.
Agreed. Those are not capable practitioners either.
Again, at IBM; Cincom; Honeywell; DEC; Cullinane; etc, we had [academically qualified] scientists, rather than academics. And we laughed at academics and their isolation from reality even then. Nothing has changed, it is much worse now. Once a thing is in the toilet bowl, the only way forward, is down down down.
> Regarding the rest of your historical comments, I do not have anything
> to add or object to. Except, perhaps, that the best DBMS in the world
> apparently survives in legacy mode now.
Yes. Corps that exist beyond the start-up ten years don’t fix something that is not broken. After 9/11, Wall Street corps scoured the world for 2GB disk drives. (I don’t know if you will appreciate the relevance of that.)
> > The point of this thread.
>
> Let's come to the point.
>
> >> On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
> >> One reason is Chen's Entity-Relationship models are likely perceived
> >> as easier to grasp for novices than something like IDEF1X. Whether
> >> that is a correct perception, it can be debated. Another reason is
> >> probably just historical, due to the huge influence of Chen's seminal
> >> paper.
> >
> > It may have been seminal for the academics, let me assure you, it was
> > not seminal, or even great, for practitioners of the day. It does not
> > have a semantic base, whereas the /RM/ and IDEF1X does.
> >
> > For academics. I can grant, up to 1970, the paper was amazing. After
> > 1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct;
> > superseded.
>
> Uh? Chen's ER paper is from 1976. That was a period of intense research
> on so called "semantic modelling" (also spurred in part by Codd's work).
> IDEF1X relies heavily upon Chen's shoulders.
First let me clarify my statements above.
> > For academics. I can grant, [if it were published] up to 1970, the paper was amazing.
> > [Since it was published] After 1970, it was ageing, badly.
> > By 1983 [when RDBMS platforms were freely available, several providers, AND IDEF1X was freely available], it was dead; obsolete; defunct; superseded.
The fact that Chen published it in 1976, and that academics performed “intense research” is precisely what I was talking about. Hysterical absurdity, because the /RM/ was published and being accepted, because several vendors were coming out with genuine RDBMS Platforms. Anyone with half a brain (eg. the scientists at IBM; Cincom; DEC; and Britton-Lee) laughed at it, because we were implementing the /RM/, and because the /RM? was far superior to the idiotic ERD.
Do you understand, and appreciate:
- we had ISAM prior to 1960’s & 1970’s DBMS
--- that means we understood KEYS
- separate to being based on FOPC, and therefore a mathematical model, the /RM/ is based on (a) the extant HDBMS, and (b) the extant NDBMS, as detailed in this thread ?
--- Hierarchical Model and its Relevance in the Relational Model
--- https://groups.google.com/g/comp.databases.theory/c/5212JwYtip4
--- HDBMS TECHNOLOGY IS HEAVILY KEY-BASED (of course, the storage is pointer-based)
--- The /RM/ takes its notion of KEYS from HDBMS, and the notion of Independent/Dependent from NDBMS
ERD is devoid of KEYS, of any understanding of KEYS, and since it was 1976, is [yet again] anti-Relational.
That the academics salivated over it, and did their mutual circle-jerk with “intense research” is exactly what I am talking about: it is hysterical absurdity, that can only be done in reinforced isolation from reality, from the /RM/; from the actual [R]DBMS platforms available an becoming available.
> IDEF1X relies heavily upon Chen's shoulders.
Nonsense. Give one example, one article. Rob Brown already had a diagrammatic modelling method (as distinct from the various diagrams that data modellers created) that was widely accepted ... after consultation with Codd, he produced what became known as IDEF1X.
> I'd say that the paper has
> aged pretty well as we (let me simplify a bit) are still modelling in
> terms of entities, relationships and attributes.
I said the same thing in different words. As long as “we” means “we academics”, I agree. The idiotic broken method is being taught throughout academia, fraudulently, as “Relational Data Modelling”. In pathological denial of reality (FOPC; the /RM/; IDEF1X; actual Relational Data Modelling)
> IMO, you are conflating the overall contributions of Chen (and others
> working on semantic models), which are important, influential and still
> relevant, with the specific details of the notation he invented, which
> is not ideal for Relational database design.
I couldn’t have been “conflating” what you say I did, because you have introduced two new items that were not on the table at the time at which I made my comments. Yes, I rejected Chen; the ERD.
Now that you have added Semantic Models, a new response from me. Yes, I reject any and all academic endeavours re Data Modelling (Relational or other). Because the notion is hysterically absurd. For a scientist. But not for the academics, who are by definition [given your reports that they are/were working on “semantic models”] ignorant of the science. If you challenge this, please open a separate thread “Semantic Data Model”.
> > Ok, to rephrase the question, why was that pre-Relational method being
> > taught after 1983, and why is it still being taught after the advent
> > of the /RM/, after the /RM/was proved, and after the first genuine SQL
> > platforms came out (1983), and after IDEF1X came out (1983 to
> > practitioners, 1989 as a product, 1993 as an international standard) ?
> I already told you my point of view.
>
> Come out with a good database book, with a modern, sound, approach to
> data modeling based on IDEF1X, and tell your publisher to send a copy
> for evaluation to all academic database researchers. There is no
> inherent reason why it should not get adopted because it dismisses ERDs
> in favor of IDEF1X. Quite the opposite, actually. There is much need for
> a really good reference on database design for the XXI century. I can't
> recommend anything off the top of my head.
Gee, thanks. That was not what I was expecting, 8}.
But you didn’t answer the question. Other than implying that nothing exists in the entire collection of academic multiverses. So my accusation holds: academics do suppress the /RM/ for theory, while promoting the anti-Relational RFS as “Relational” (as proved in several threads), and now, academics do suppress IDEF1X for Data Modelling, while promoting instead the anti-Relational ERD.
Why would the academics promote my book ??? It destroys the academic mindset, it asserts science and reality, it gives Methods that have existed for FORTY YEARS that academics deny, it gives Progressions to the /RM/ and the Methods, both of which the academics deny. No. At best, I will find a few honest academics who will provide a peer review.
But the book is not expected to be received by the pig poop eaters, it is for practitioners who respect a theoretical foundation. But thanks again.
Data Modelling is not “based on IDEF1X” (or ERD for that matter). Data Modelling is a science. Yes, I have a definition, and a Method, rendered in IDEF0. IDEF1X and IDEF0 are merely Standards, not methods. It gives low-level rules, which provide a simple but incomplete form of rules [defined in the /RM/]. Which, is not THE method or A method for modelling data. It pertains to the finished data model (any particular version), rather than the exercise that is required to produce it. For the purpose of having agreed symbols; completeness; etc. Such that two parties can discuss a Data Model that is /rendered in/ a well-known Standard.
Sure, a person CAN perform Data Modelling “based on IDEF1X”, it would be a class above and beyond any data modelling based on ERD, but it would still be inferior to actual data modelling.
You saw what I did with Movie Title, and to a lesser degree what I did with the three ERDs in OP’s request, you should have more than a whiff. The Vehicle-Accident problem was a good one as well. All three sets of problems exposed two things:
- use of ERD made sure the modeller was stuck; stumped; and stupefied
- classic data modelling [with /RM/ in mind] solved the problem in a straight-forward manner
The simple and explicit crime, that I am trying to get across is, academia has failed in its duty to teach the science, the fact that they teach ERD as “Relational Data Modelling” is a serious fraud, it is subversion of the science, and easily identified as such by those who are not ignorant.
> > after IDEF1X came out [in...] 1993 as an international standard)
>
> The FIPS standard has been withdrawn by NIST in 2008. But IDEF1X has
> also been an IEEE standard since 1998, and an ISO/IEC/IEEE standard
> since 2012.
Yes. So the fact that the NIST Standard was withdrawn is irrelevant, by your own report. No one stopped using it. Even the deaf and blind OO/ORM crowd use a bastardised version of it.
> >> In a general setting, ERD is fine for teaching the basics of
> >> modeling
> >>
> >> ERDs can be useful as a gentle introduction to such topics.
> >>
> >> ERD can be introduced without any background knowledge in databases
> >
> > For introductory levels, show them IDEF1X/Entity level.
>
> Sure, I do that.
So then, you do know, IDEF1X with its full /RM/ articulation (Relational Keys; Independent/Dependent; Identifying/Non-Identifying; Subtypes; etc), its full IEEE Cardinality, even at the Entity level, provides far more richness and definition than ERD. So why are you suggesting ERD “is fine for ...” anything, post 1970 ???
> >> Some may feel IDEF1X is "low-level" (too many details) compared to
> >> ERDs.
> >
> > False: display only the level of detail necessary for any given
> > exercise {Entity|Key|Attribute}.
>
> I agree. I did not mean to imply that I think otherwise; just that
> a cursory look by someone who knows ERDs but not IDEF1X may lead to such
> remarks.
Who cares about what people, ignorant of subject X, say about subject X. It is like a pygmy insisting that a wattle-and-dung hut is the best house in the world. Or Date and Darwen insisting that the /RM/ or SQL is incomplete, and that they will produce something that soves all those problems (still failing, after THIRTY YEARS). By definition, it proves they are ignorant of the /RM/ and SQL, that they are talking about their Straw Man, RM/T plus RFS re-framed as the “Relational Model”. I would prefer if you keep that sort of remark out of our communications.
The only remarks that count; that are worthy of discussion, are from people who know IDEF1X, or both IDEF1X and ERD.
> >> Or some may have criticisms along the lines of this analysis:
> >>
> >> https://www.essentialstrategies.com/publications/modeling/idef1x.htm
> >
> > God help me. Academics just love to sabotage themselves, and then cry
> > about the fact that they have been sabotaged.
>
> Just brought it as an instance of what a superficial look at the
> notation may lead to. I do not think that it is a good critical analysis
> in any way. And not by an academic either.
Ditto.
> >> My main complaint with IDEF1X is the treatment of generalization
> >> hierarchies, in particular the lack of a correct way to model a total
> >> inclusive specialization (A must be one of B1, ..., Bn and it may be
> >> any of B1, ..., Bn); the approach I have seen around (e.g., see
> >> Thomas Bruce's book or ERwin's manual) does not cover such case in
> >> a sound way. And the standard never mentions inclusive
> >> specializations, AFAICT.
> >
> > The problem there is, you do not understand Transactions
>
> Look, as much as it may be disappointing to you: I know. Very well.
> I know, in particular, how to deal with specialization hierarchies
> transactionally.
Ok, fine. But your words contradict that, you can’t say that and also say “My main complaint with IDEF1X is the treatment of generalization hierarchies”.
So what, if anything, is your remaining complaint re “generalization hierarchies”.
Re Transactions. Again, there is contradiction. If you understand ACID, you would reject MVCC. If you accept MVCC even as a potential (it has never reached actual), it proves you don’t understand ACID. Sorry, I am not going by what I think, I am going by your words, and what they actually mean.
> > There are several threads in this forum that simply do not progress to
> > closure due to the unwillingness of academics to engage, and to learn
> > about ACID Transactions.
>
> Yes, I did not feel those discussions were going towards fruitful
> directions.
The very least in the category of “fruitful” is closure. Since you (as distinct from other academics) at least accept the notion of the Four Laws of Thought, which I am rigidly attached to, closure should be no problem. (Closure with other academics is not possible, simply because they are not scientifically honest: refer the multitude of threads, wherein the best they can do is ad hominem attacks; deflection; Straw Man; etc.)
> But, time permitting, I might eventually return on the MVCC
> vs 2PL matter.
Very important. Please and thank you.
> > This document may assist somewhat in explanation, noting that the full
> > and formal explanation lies in ACID Transactions, which has not
> > progressed in this forum, and indeed in academia, since 1970.
> >
> > https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf
> >
> > If there is anything in that doc that is not completely understood,
> > please ask.
> That's perfectly clear.
So you understand, Subtypes of any IEEE legal kind, can be implemented in SQL, using Constraints only (and ACID Transactions are a form of Constraint, the collection of which is the Database API).
> > Here is a quick document that clarifies the issues you questioned,
> > that I have answered. To be complete, I have added an item re
> > Rolenames, because it is the third common “issue” that people raise:
> > https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
>
> A question: what is the use case for an association that does not imply
> a foreign key (rightmost symbol in your "improved IE")? Why would you
> require a parent entity to exist at the time of insertion, but not
> later?
It is actually a very common requirement. Refer this Data Model:
____https://www.softwaregems.com.au/Documents/Student_Resolutions_2020/Giannis/RoomMonitor%20DM%20V0_51.pdf
The initial requirement is here, but he contacted me directly, and we progressed the Data Modelling exercise to completion off StackOverflow, in 25 iterations, which cannot be done at SO, which sucks dead bears. Read it only if interested, to get a feel, the detail in the *Q* is completely obsolete:
____https://stackoverflow.com/questions/61048436/modeling-optional-properties-of-an-entity-based-on-a-mutable-discriminator-in-a
The system distributes Room Monitors (Sensors: Temp; Humidity; DoorOpen; etc) to various hotels (Pensions) in Europe. The Monitors are produced; owned; and managed by the single company, but distributed widely to the locations. The Hotel owns the Network and actually receives the Sensor info (not the central corp). Over time, the specific hardware for a single Monitor gets removed from the Hotel and its Network; back to factory; then re-distributed to some other Hotel.
1. Guy needs the Monitor to be assigned properly in the first place (integrity with parent HotelNetwork), and it needs to be known as such for historical or audit purposes. But not maintained, eg. when it is removed. Therefore an FK Constraint will not work. The Constraint is implemented within an ACID Transaction:
____+Monitor CHECKS HotelNetwork[HotelChain, CountryCode, Town, Suburb) EXISTS.
2. Readings for a Room are stored permanently, for audit and legal reasons, which means Subordinate to Room, not Monitor. But of course, when a Reading is added, we need to ensure that it was produced by a particular Sensor, in a particular Monitor, that was located in that Room.
____Constraint ReadingMeasure_SensorIsValid_ck CHECK Sensor_Get_fn( Sensor.PK )
____which checks that the parent SensorSwitch EXISTS
which applies to the INSERT within the ACID Transaction only.
For understanding, I would say, there are three levels of maintaining history (Audit, etc), for designated tables, and it has some Temporal Database requirement.
1 At most, the requirement is to re-construct a row from the past. Separate table, and very tight KEYS plua DATETIME. Tight understanding of Temporal (not the Date and Darwen monstrosity marketed as “temporal”) is required, more for the coding than the data model.
3 At the least, it is what we have here in Room Monitor. Data is valid at INSERT, but not afterwards. It is not that a SELECT will fail, all SELECTS for those tables have to use OUTER JOIN, with ISNULL( “[Expired]” ) for the potentially non-existent parent. No understanding of Temporal is required.
2. In-between is the most common. When queried, the correct historic value must show up (but no need to re-construct). Reasonable understanding of Temporal (not the Date and Darwen monstrosity marketed as “temporal”) is required.
> Regarding subtyping, my critique is specifically on the notation given
> in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
> Subtype".
What “crossing” ???
You can’t use both IDEF1X and IEEE notation in any single model, they cannot be mixed. They are exclusive. You can’t go back-and-forth either.
> Let me denote the specialization symbol with `-O||`, and
> a categorization cluster with `P -O|| {C1, ..., Cn}`.
> By definition, P -O|| {C1, ..., Cn} means:
>
> "P must be exactly one of C1, ..., Cn".
>
> If an entity P has two ore more clusters, each should be interpreted as
> above. For instance:
>
> P -O|| {A,B}
> P -O|| {C,D}
>
> reads as:
>
> - P must be (exactly) one of A and B; and
> - P must be (exactly) one of C and D.
Understood thus far. For two clusters, agreed thus far. In IEEE notation, it is perfectly clear. You might have to use something like “P--€{A,B}” for Exclusive, and “P--C{C,D}” for Non-Exclusive. You have two Exclusive clusters.
Since C is the classifier in your definition, I would prefer:
____P--€{A1,A2..An}
____P--C{X1,X2..Xm}
(“Inclusive” is incorrect, what we have is not the simple opposite of Exclusive. If it is not “Base is exactly one Subtype” which is Exclusive, then “Base is one or more Subtype” is simply Non-Exclusive. Nothing inclusive about that.)
> The notation I'm criticizing corresponds to:
>
> P -O|| {A}
> P -O|| {B}
>
> which, by the definition above, one should read as:
>
> - P must be A; and
> - P must be B.
>
> Instead, the assumed interpretation is:
>
> - P must be A or B; and
> - P may be both A and B,
Sorry. I don’t understand what you are trying to say.
If you mean the IDEF1X notation for Exclusive, no it does not exist, only {Complete|Incomplete} exists in IDEF1X notation. Don’t use the IDEF1X notation for Subtypes, we know it is inferior to the pre-existing IEEE notation, that is why we replaced the former with the latter.
Again, you can’t go back-and-forth: if you have interpreted the ERwin Methods Guide p 69 as allowing that, no, that is false. It is a diagram for comparison only. Use IDEF1X XOR IEEE Notation.
> which is inconsistent with the general definition.
>
> > I don’t know how you don’t strangle your colleagues.
>
> It's for fear of law enforcement :D
I love that !
> Jokes apart, my database colleagues are among the best people in my
> department!
Evidently, Udine is far better than US universities. But ... first school them in the Four Laws of Thought, the foundation of all science and of Justice. That will ensure determination of science vs anti-science. Then tell them to read Codd/RM, only Codd/RM, and nothing but Codd/RM. The RM/T; etc, has to be rejected because it contradicts the Codd/RM. Tell them NOT to read any other academic.
----
Since we are discussing IDEF1X, you might be interested in this Q&A:
____https://stackoverflow.com/q/4132044/484814
Cheers
Derek
Thanks for yours.
Before I get into it, let us understand something.
In academia, academics know nothing of the industry, they have a contrived notion of “industry”, namely anyone who uses PissGreNONsql.
Two exceptions. Codd, because he was a genuine academic who went beyond the academics of his time, and he had his head attached to reality (the commercial application). You, because you are trying to understand reality, and that sets you apart from the academics. The main block you have to get over is, the confidence that academics know reality, which is a total fiction.
If Industry means all who use a DBMS, up to ten years ago, basically it excluded freeware, and they used commercial DBMS, PissGreNONsql was unheard of. Where freeware is used, MyNONsql leads the field. It still does, it is 1,000 times better than PooGoo while remaining in the same NONsql category. But academia only know about the “industry” that uses their pet excreta producer.
Eg. in the Financial & Banking sector, Sybase has 95% share, with MSSQL the rest. Oracle cannot even compete. In high-performance markets (F&B being one category), it is Sybase and DB2, with MSSQL after a large gap. Oracle cannot compete. Freeware is unheard of, no one wants to execute at 10,000 times slower speed or rewrite their “sql” for every new version of the freeware. These are for databases that are permanent, not “refactored” every month or quarter, such as the ever-changing filth that OO/ORM crowd excretes, that academia caters for.
So the market that uses freeware is really the start-ups, the dumb dumb dumb dumb dummies, ignorant of what commercial DBMS provide, aware of only that fraction of DBMS capability that academia bleats about. Start-ups that will not exist in ten years. No one cares about them. Except academia. Because they too, use PooGrossNONsql. And they too have no clue about ACID Transactions or Server Architecture or the features in commercial DBMS that their pet freeware does not have, and will never have. Same as the academics.
In the commercial DBMS industry (ie. the DBMS suppliers), no one knows or cares about the academics, because they are, as evidenced, fifty years behind the industry. As evidenced, there is nothing that academics have come up with that has been implemented in commercial DBMS (except Codd, again). In Sybase (small company) I can assure you from decades of first-hand experience as a Partner, we have hundreds of PhD level scientists. It may even be 1,000, as the company has grown after the acquisition by SAP.
>>>>
Don’t include such things as the hysterical MVCC in that, because “MVCC” is not a real thing, it is a imaginary thing, collectively imagined and collectively assented to, by academia alone. All hail the imbecile Stonebraker and insist that he is a deity. As I posted in the “MVCC” thread, yes, due to the heavy marketing by academia, “MVCC” has become a check-box item, without being understood by those who request it. Thus Sybase have ADDED it on top of the [existing since 1960 in IBM; since 1977 in Britton-Lee; since 1981 in Sybase] Ordinary Locking (aka incorrectly called “Two Phased Locking” or “2PL” by the academics).
To be clear, if the boffin insists of imagining something that is not real, no problem, we add a set of resources, and we erect his fantasy for him. Meanwhile, regardless of what the boffin does, regardless of what multiverse he is fornicating with his beloved sow in, if he executes an SQL verb that does something to the database, it is done in the normal [forty years extant] “2PL” so that he contends with the other users (who are probably not slaves of academia and thus have an attachment to reality, the database content), and resolves that contention, and ADDITIONALLY, we erect his fantasy on the ADDITIONAL resources, and provide/deny his attempt against his fantasy that we have erected for him. It is the way a kind and gentle mental health nurse provides care for her mentally ill and locked up patients, locked up because they insist fantasy is “reality”, which is dangerous to the public.
<<<<
The above are all general points. If you wish to challenge any of them, do so as general points.
> On Wednesday, 31 March 2021 at 22:58:03 UTC+11, Nicola wrote:
> > On 2021-03-29, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> > Introduction
> >
> > When it came out in 1970, the Relational Model (Codd, not the
> > pretenders) made a paradigm shift in all areas of perceiving data
> > (examination; data modelling; storage and retrieval; programming).
> > Codd had an uphill battle against the established academics because
> > they could not understand it,
> I don't think that's a fair assessment. Who are those "established
> academics" you mention?
There is absolutely zero articles in academia reinforcing or progressing the /RM/. That is evidence, for FIFTY YEARS, that academia does not understand it. All the nameless freaks, save one. Likewise there is not a single book that honestly promotes the /RM/ or progresses it. All of them that purport to articulate “Relational Database” promote instead 1960’s Record Filing Systems, based on RM/T, as confirmed in another thread. Even here, you are the only one looking into genuine Relational Data Modelling. The rest promote anti-Relational pig poop.
> *Some* academics may have had issues with Codd's
> proposal, but it was definitely understood, and supported, by many other
> academics.
Try naming one paper written any time after 1970.
> And certainly at a greater degree than people in industry.
> This is confirmed by those who were there:
>
> https://archive.computerhistory.org/resources/access/text/2015/06/102702111-05-01-acc.pdf
>
> E.g., quote from p. 8:
>
> "So Codd's paper got some traction in the academic community where these
> mathematical concepts were very familiar. It didn't, at first, get much
> traction in the commercial database community. They had their
> navigational systems. [...]"
I, who worked for one of the big five DBMS vendors at the time, and previously a specialist on DEC (PDP; VAX) have already categorised it as false. Let me assure you that at Cincom, we had many scientists, many mathematicians, who had no problem understanding the /RM/. Yes, we saw the /RM/ as changing the entire landscape. We did not try to “relationalise” the product, thus we had no need to add anything to TOTAL, but the other DBMS vendors did. And that is why Codd had to write his famous Twelve Rules, to ensure that vendors were not fraudulently declaring that they were /RM/ compliant.
(The has progressed to the problem we have today, where even though SQL is THE established Standard, all the freeware and oracle do not comply, but fraudulently declare that they do.)
Likewise, let me assure you that DEC had hundreds of scientists, who understood and implemented the /RM/, their RDBMS called Rdb was brilliant. It still runs in legacy systems on VAX emulators, it still beats Orable by 10,000 times. I am not saying that emulators are good, but there is a market for it, patronised by corporations that do not fix what is NOT broken, which is why they still exist.
That (what you quote) is typical of the propaganda that academia produce and swallow. Waht you might get from guys like me (or any scientist working for a commercial DBMS provider)is, the actual reality. Obviously the thousands of scientists who work for IBM; Sybase; MS, do not even bother with fora such as this, because academics are irrelevant to the real world platforms, only I do.
Chamberlain contradicts himself all over the place, but you won’t catch it. He comes across as being a friend of Codd, but actually, if you examine it, he demeans Codd, sometimes quite subtely. Very dishonest. It is sad that academics view the Chamberlain memories as gospel. Identical to Date. Much like the Stonebraker stupidity, that has no commercial existence, but lives and thrives in academia and in freeware.
On p12 para 2:
“System R ... was not a product that was going to be released commercially. It was a feasibility demonstration. It was proof of the concept that Ted Codd's ideas actually made sense and could be implemented in a robust way. And there was a lot of skepticism about that.”
So the simple evidenced fact, from Chamberlains own mouth, his “memories”, confirms what I said, and he includes himself in that category:
>> Codd had an uphill battle against the established academics because
>> they could not understand it
“Ted thought that we should use this concept [relations] to allow users to interact with stored data in a way that was independent of the physical representation of that data. He called this notion //data independence//”
And on p 8 para 3:
“Codd introduced the notion of relations as an abstraction for stored data, and he explained about //data independence// and why that was important”
The term in the /RM/ is Access Path Independence. Data Independence is quite a different thing.
It is amazing to me, that Chamberlain enumerates all those great mathematicians who were employed by his employer, specifically to go beyond their existing product, but still insists that DBMS providers did not have mathematicians, and were only interested in protecting their market share. Only people who are trained to accept contradiction without question can believe such utter hypocrisy. Pig poop rots the brain.
Here is what Chamberlain actually thought that the “industry” was; what the user base was, and his own admission that what he thought was absurd. Proving yet again that academics are clueless about the industry the purport to serve. p 17 para 5:
“What Ray and I thought we were doing was making access to databases available to a new class of people that hadn’t accessed databases before. We thought they were going to be engineers and architects and city planners and economists, and people like that who were not computer people, not programmers. We thought that these people shouldn’t have to turn themselves into computer experts or programmers in order to ask questions. They should ask questions in this English-keyword notation that we called SEQUEL. So with words like SELECT and FROM and WHERE and GROUP BY and ORDER BY and so on, maybe you could teach that kind of notation to people who didn’t have any computer training at all, and weren’t much interested in computers. They were interested in their domain of expertise. They wanted to study economics or something like that, and they needed to retrieve statistical information about economics, and they needed a language to do that, but they didn’t need to be programmers. That’s what SEQUEL was intended to do. I don’t think it was very successful at doing that. If you look back on it from a perspective of 30 years later, I think you don’t find a lot of architects and economists and city planners writing SEQUEL queries. SEQUEL queries are mostly written by experienced programmers who are trained and specialized in doing that, and a lot of them are generated by machines through some kind of interface that’s specialized to some domain.”
I am not suggesting that he, or any other academic at IBM Labs was stupid. Far from it. I am saying that as an academic, as evidenced, he has huge blind spots, eg. “industry”; “users”. And as is typical of academia, he is unaware that he has blind spots, and makes stupid declarations about them.
Overall, notice the difference, Chamberlain and a host of others (academic but impractical), against Codd (academic and practical). Codd was the bad guy because “he wasn’t a team player”. Thank God for that.
It is horrendous that he does not mention DSS queries in his discourse on that subject. In his /RM/, Codd provided both OLTP and DSS.
> Another first-hand historical perspective is provided by:
>
> https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
They probably realised that it was going to be inspected and removed the filth, because it would not withstand scrutiny.
MCJones is the same idiot (nicely propagandised, well prepared) who interviewed Chamberlain, and who dutifully spouted the same propaganda. I don’t need to read it to know that it will be in the same vein.
> Quote from the "Prehistory" section:
>
> "[...] Nevertheless, what kicked off this work [on project Gamma-0 and,
> eventually, System R] was a key paper by Ted Codd - was it published in
> 1970 in CACM?
>
> - Yes.
>
> - A couple of us from the Systems Department had tried to read it -
> couldn't make heads nor tails out of it. [laughter] At least back
> then, it seemed like a very badly written paper: some industrial
> motivation, and then right into the math. [laughter]"
>
> Those are not academics talking.
Again, at IBM; Cincom; Honeywell; DEC; Cullinane; etc, we had [academically qualified] scientists, rather than academics. And we laughed at academics and their isolation from reality even then. Nothing has changed, it is much worse now. Once a thing is in the toilet bowl, the only way forward, is down down down.
> Regarding the rest of your historical comments, I do not have anything
> to add or object to. Except, perhaps, that the best DBMS in the world
> apparently survives in legacy mode now.
> > The point of this thread.
>
> Let's come to the point.
>
> >> On Wednesday, 24 March 2021 at 23:27:48 UTC+11, Nicola wrote:
> >> One reason is Chen's Entity-Relationship models are likely perceived
> >> as easier to grasp for novices than something like IDEF1X. Whether
> >> that is a correct perception, it can be debated. Another reason is
> >> probably just historical, due to the huge influence of Chen's seminal
> >> paper.
> >
> > It may have been seminal for the academics, let me assure you, it was
> > not seminal, or even great, for practitioners of the day. It does not
> > have a semantic base, whereas the /RM/ and IDEF1X does.
> >
> > For academics. I can grant, up to 1970, the paper was amazing. After
> > 1970, it was ageing, badly. By 1983, it was dead; obsolete; defunct;
> > superseded.
>
> Uh? Chen's ER paper is from 1976. That was a period of intense research
> on so called "semantic modelling" (also spurred in part by Codd's work).
> IDEF1X relies heavily upon Chen's shoulders.
> > For academics. I can grant, [if it were published] up to 1970, the paper was amazing.
> > [Since it was published] After 1970, it was ageing, badly.
> > By 1983 [when RDBMS platforms were freely available, several providers, AND IDEF1X was freely available], it was dead; obsolete; defunct; superseded.
The fact that Chen published it in 1976, and that academics performed “intense research” is precisely what I was talking about. Hysterical absurdity, because the /RM/ was published and being accepted, because several vendors were coming out with genuine RDBMS Platforms. Anyone with half a brain (eg. the scientists at IBM; Cincom; DEC; and Britton-Lee) laughed at it, because we were implementing the /RM/, and because the /RM? was far superior to the idiotic ERD.
Do you understand, and appreciate:
- we had ISAM prior to 1960’s & 1970’s DBMS
--- that means we understood KEYS
- separate to being based on FOPC, and therefore a mathematical model, the /RM/ is based on (a) the extant HDBMS, and (b) the extant NDBMS, as detailed in this thread ?
--- Hierarchical Model and its Relevance in the Relational Model
--- https://groups.google.com/g/comp.databases.theory/c/5212JwYtip4
--- HDBMS TECHNOLOGY IS HEAVILY KEY-BASED (of course, the storage is pointer-based)
--- The /RM/ takes its notion of KEYS from HDBMS, and the notion of Independent/Dependent from NDBMS
ERD is devoid of KEYS, of any understanding of KEYS, and since it was 1976, is [yet again] anti-Relational.
That the academics salivated over it, and did their mutual circle-jerk with “intense research” is exactly what I am talking about: it is hysterical absurdity, that can only be done in reinforced isolation from reality, from the /RM/; from the actual [R]DBMS platforms available an becoming available.
> IDEF1X relies heavily upon Chen's shoulders.
> I'd say that the paper has
> aged pretty well as we (let me simplify a bit) are still modelling in
> terms of entities, relationships and attributes.
> IMO, you are conflating the overall contributions of Chen (and others
> working on semantic models), which are important, influential and still
> relevant, with the specific details of the notation he invented, which
> is not ideal for Relational database design.
Now that you have added Semantic Models, a new response from me. Yes, I reject any and all academic endeavours re Data Modelling (Relational or other). Because the notion is hysterically absurd. For a scientist. But not for the academics, who are by definition [given your reports that they are/were working on “semantic models”] ignorant of the science. If you challenge this, please open a separate thread “Semantic Data Model”.
> > Ok, to rephrase the question, why was that pre-Relational method being
> > taught after 1983, and why is it still being taught after the advent
> > of the /RM/, after the /RM/was proved, and after the first genuine SQL
> > platforms came out (1983), and after IDEF1X came out (1983 to
> > practitioners, 1989 as a product, 1993 as an international standard) ?
> I already told you my point of view.
>
> Come out with a good database book, with a modern, sound, approach to
> data modeling based on IDEF1X, and tell your publisher to send a copy
> for evaluation to all academic database researchers. There is no
> inherent reason why it should not get adopted because it dismisses ERDs
> in favor of IDEF1X. Quite the opposite, actually. There is much need for
> a really good reference on database design for the XXI century. I can't
> recommend anything off the top of my head.
But you didn’t answer the question. Other than implying that nothing exists in the entire collection of academic multiverses. So my accusation holds: academics do suppress the /RM/ for theory, while promoting the anti-Relational RFS as “Relational” (as proved in several threads), and now, academics do suppress IDEF1X for Data Modelling, while promoting instead the anti-Relational ERD.
Why would the academics promote my book ??? It destroys the academic mindset, it asserts science and reality, it gives Methods that have existed for FORTY YEARS that academics deny, it gives Progressions to the /RM/ and the Methods, both of which the academics deny. No. At best, I will find a few honest academics who will provide a peer review.
But the book is not expected to be received by the pig poop eaters, it is for practitioners who respect a theoretical foundation. But thanks again.
Data Modelling is not “based on IDEF1X” (or ERD for that matter). Data Modelling is a science. Yes, I have a definition, and a Method, rendered in IDEF0. IDEF1X and IDEF0 are merely Standards, not methods. It gives low-level rules, which provide a simple but incomplete form of rules [defined in the /RM/]. Which, is not THE method or A method for modelling data. It pertains to the finished data model (any particular version), rather than the exercise that is required to produce it. For the purpose of having agreed symbols; completeness; etc. Such that two parties can discuss a Data Model that is /rendered in/ a well-known Standard.
Sure, a person CAN perform Data Modelling “based on IDEF1X”, it would be a class above and beyond any data modelling based on ERD, but it would still be inferior to actual data modelling.
You saw what I did with Movie Title, and to a lesser degree what I did with the three ERDs in OP’s request, you should have more than a whiff. The Vehicle-Accident problem was a good one as well. All three sets of problems exposed two things:
- use of ERD made sure the modeller was stuck; stumped; and stupefied
- classic data modelling [with /RM/ in mind] solved the problem in a straight-forward manner
The simple and explicit crime, that I am trying to get across is, academia has failed in its duty to teach the science, the fact that they teach ERD as “Relational Data Modelling” is a serious fraud, it is subversion of the science, and easily identified as such by those who are not ignorant.
> > after IDEF1X came out [in...] 1993 as an international standard)
>
> The FIPS standard has been withdrawn by NIST in 2008. But IDEF1X has
> also been an IEEE standard since 1998, and an ISO/IEC/IEEE standard
> since 2012.
> >> In a general setting, ERD is fine for teaching the basics of
> >> modeling
> >>
> >> ERDs can be useful as a gentle introduction to such topics.
> >>
> >> ERD can be introduced without any background knowledge in databases
> >
> > For introductory levels, show them IDEF1X/Entity level.
>
> Sure, I do that.
> >> Some may feel IDEF1X is "low-level" (too many details) compared to
> >> ERDs.
> >
> > False: display only the level of detail necessary for any given
> > exercise {Entity|Key|Attribute}.
>
> I agree. I did not mean to imply that I think otherwise; just that
> a cursory look by someone who knows ERDs but not IDEF1X may lead to such
> remarks.
The only remarks that count; that are worthy of discussion, are from people who know IDEF1X, or both IDEF1X and ERD.
> >> Or some may have criticisms along the lines of this analysis:
> >>
> >> https://www.essentialstrategies.com/publications/modeling/idef1x.htm
> >
> > God help me. Academics just love to sabotage themselves, and then cry
> > about the fact that they have been sabotaged.
>
> Just brought it as an instance of what a superficial look at the
> notation may lead to. I do not think that it is a good critical analysis
> in any way. And not by an academic either.
> >> My main complaint with IDEF1X is the treatment of generalization
> >> hierarchies, in particular the lack of a correct way to model a total
> >> inclusive specialization (A must be one of B1, ..., Bn and it may be
> >> any of B1, ..., Bn); the approach I have seen around (e.g., see
> >> Thomas Bruce's book or ERwin's manual) does not cover such case in
> >> a sound way. And the standard never mentions inclusive
> >> specializations, AFAICT.
> >
> > The problem there is, you do not understand Transactions
>
> Look, as much as it may be disappointing to you: I know. Very well.
> I know, in particular, how to deal with specialization hierarchies
> transactionally.
So what, if anything, is your remaining complaint re “generalization hierarchies”.
Re Transactions. Again, there is contradiction. If you understand ACID, you would reject MVCC. If you accept MVCC even as a potential (it has never reached actual), it proves you don’t understand ACID. Sorry, I am not going by what I think, I am going by your words, and what they actually mean.
> > There are several threads in this forum that simply do not progress to
> > closure due to the unwillingness of academics to engage, and to learn
> > about ACID Transactions.
>
> Yes, I did not feel those discussions were going towards fruitful
> directions.
> But, time permitting, I might eventually return on the MVCC
> vs 2PL matter.
> > This document may assist somewhat in explanation, noting that the full
> > and formal explanation lies in ACID Transactions, which has not
> > progressed in this forum, and indeed in academia, since 1970.
> >
> > https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf
> >
> > If there is anything in that doc that is not completely understood,
> > please ask.
> That's perfectly clear.
> > Here is a quick document that clarifies the issues you questioned,
> > that I have answered. To be complete, I have added an item re
> > Rolenames, because it is the third common “issue” that people raise:
> > https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
>
> A question: what is the use case for an association that does not imply
> a foreign key (rightmost symbol in your "improved IE")? Why would you
> require a parent entity to exist at the time of insertion, but not
> later?
____https://www.softwaregems.com.au/Documents/Student_Resolutions_2020/Giannis/RoomMonitor%20DM%20V0_51.pdf
The initial requirement is here, but he contacted me directly, and we progressed the Data Modelling exercise to completion off StackOverflow, in 25 iterations, which cannot be done at SO, which sucks dead bears. Read it only if interested, to get a feel, the detail in the *Q* is completely obsolete:
____https://stackoverflow.com/questions/61048436/modeling-optional-properties-of-an-entity-based-on-a-mutable-discriminator-in-a
The system distributes Room Monitors (Sensors: Temp; Humidity; DoorOpen; etc) to various hotels (Pensions) in Europe. The Monitors are produced; owned; and managed by the single company, but distributed widely to the locations. The Hotel owns the Network and actually receives the Sensor info (not the central corp). Over time, the specific hardware for a single Monitor gets removed from the Hotel and its Network; back to factory; then re-distributed to some other Hotel.
1. Guy needs the Monitor to be assigned properly in the first place (integrity with parent HotelNetwork), and it needs to be known as such for historical or audit purposes. But not maintained, eg. when it is removed. Therefore an FK Constraint will not work. The Constraint is implemented within an ACID Transaction:
____+Monitor CHECKS HotelNetwork[HotelChain, CountryCode, Town, Suburb) EXISTS.
2. Readings for a Room are stored permanently, for audit and legal reasons, which means Subordinate to Room, not Monitor. But of course, when a Reading is added, we need to ensure that it was produced by a particular Sensor, in a particular Monitor, that was located in that Room.
____Constraint ReadingMeasure_SensorIsValid_ck CHECK Sensor_Get_fn( Sensor.PK )
____which checks that the parent SensorSwitch EXISTS
which applies to the INSERT within the ACID Transaction only.
For understanding, I would say, there are three levels of maintaining history (Audit, etc), for designated tables, and it has some Temporal Database requirement.
1 At most, the requirement is to re-construct a row from the past. Separate table, and very tight KEYS plua DATETIME. Tight understanding of Temporal (not the Date and Darwen monstrosity marketed as “temporal”) is required, more for the coding than the data model.
3 At the least, it is what we have here in Room Monitor. Data is valid at INSERT, but not afterwards. It is not that a SELECT will fail, all SELECTS for those tables have to use OUTER JOIN, with ISNULL( “[Expired]” ) for the potentially non-existent parent. No understanding of Temporal is required.
2. In-between is the most common. When queried, the correct historic value must show up (but no need to re-construct). Reasonable understanding of Temporal (not the Date and Darwen monstrosity marketed as “temporal”) is required.
> Regarding subtyping, my critique is specifically on the notation given
> in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
> Subtype".
You can’t use both IDEF1X and IEEE notation in any single model, they cannot be mixed. They are exclusive. You can’t go back-and-forth either.
> Let me denote the specialization symbol with `-O||`, and
> a categorization cluster with `P -O|| {C1, ..., Cn}`.
> By definition, P -O|| {C1, ..., Cn} means:
>
> "P must be exactly one of C1, ..., Cn".
>
> If an entity P has two ore more clusters, each should be interpreted as
> above. For instance:
>
> P -O|| {A,B}
> P -O|| {C,D}
>
> reads as:
>
> - P must be (exactly) one of A and B; and
> - P must be (exactly) one of C and D.
Since C is the classifier in your definition, I would prefer:
____P--€{A1,A2..An}
____P--C{X1,X2..Xm}
(“Inclusive” is incorrect, what we have is not the simple opposite of Exclusive. If it is not “Base is exactly one Subtype” which is Exclusive, then “Base is one or more Subtype” is simply Non-Exclusive. Nothing inclusive about that.)
> The notation I'm criticizing corresponds to:
>
> P -O|| {A}
> P -O|| {B}
>
> which, by the definition above, one should read as:
>
> - P must be A; and
> - P must be B.
>
> Instead, the assumed interpretation is:
>
> - P must be A or B; and
> - P may be both A and B,
If you mean the IDEF1X notation for Exclusive, no it does not exist, only {Complete|Incomplete} exists in IDEF1X notation. Don’t use the IDEF1X notation for Subtypes, we know it is inferior to the pre-existing IEEE notation, that is why we replaced the former with the latter.
Again, you can’t go back-and-forth: if you have interpreted the ERwin Methods Guide p 69 as allowing that, no, that is false. It is a diagram for comparison only. Use IDEF1X XOR IEEE Notation.
> which is inconsistent with the general definition.
>
> > I don’t know how you don’t strangle your colleagues.
>
> It's for fear of law enforcement :D
> Jokes apart, my database colleagues are among the best people in my
> department!
----
Since we are discussing IDEF1X, you might be interested in this Q&A:
____https://stackoverflow.com/q/4132044/484814
Cheers
Derek
Derek Ignatius Asirvadem
Apr 2, 2021, 5:36:28 AM4/2/21
to
Nicola
Thanks for yours.
> On Thursday, 1 April 2021 at 02:54:53 UTC+11, Nicola wrote:
Summary answer.
1. We had subtypes prior to RDBMS and IDEF1X. We had diagrams that were primitive compared to IDEF1X, but they worked perfectly well for the DBMS that we did have. We used IEEE notation.
2. So when IDEF1X was published, no one used {Complete|Incomplete}. [Technically, since one could always add a subtype in the future, every cluster might be Incomplete!].
3. The first (and only compliant) product ERwin provided both notations from day one.
4. ERwin Methods Guide was freely available, and even people who did not have ERwin used it as the proper definition for IDEF1X (rather than purchase).
I concur that the IDEF1X Notation for both Subtypes and Relations is inferior.
Therefore, forget about the thing that does not work, that is known to be inferior, that only academics use, and use the thing that does work, that practitioners have used since 1983, the IEEE notation. For both Subtypes and Relations. Every DM that I am aware of used IEEE (except yours, but you are earnestly trying to understand and use the Standard as is, rather than the modified Standard that practitioners use).
----
Nevertheless, I want to make sure that this particular item is resolved, because absolutely everything that occurs in reality can be modelled under FOPC; the /RM/; and IDEF1X. Refer to my Subtype doc for details and specific examples re what I state here.
First, absolutely and always, think of the Basetype+Subtype pair as a single LOGICAL row (I won’t use silly terms such as “tuple”). Rather than as parent-child (which it is in physical, SQL terms).
> On the other hand, it makes it impossible to express the situation
> above, i.e., that "P must be A, B, or both" (complete + inclusive).
If you give me an example (names, not A B C), I would be happy resolve it.
> ... each instance
If it is not optional, then it is as you say “absorbed” into the parent.
> I find it somewhat surprising that this aspect has not been clarified
> and addressed in the standard, which was last revised in 2019.
Yes. That is because the Date & Darwen freaks messed with it, and they pushed the totally obsolete IDEF1X notation over the IEEE notation. Same as you did before our discussion. Academia sucks dead sows. Even the notion of “Identity-Type” as an alternative to Keys, is hysterically backward, but hey, it now “validates” the OO/ORM approach.
Cheers
Derek
Thanks for yours.
> On Thursday, 1 April 2021 at 02:54:53 UTC+11, Nicola wrote:
Summary answer.
1. We had subtypes prior to RDBMS and IDEF1X. We had diagrams that were primitive compared to IDEF1X, but they worked perfectly well for the DBMS that we did have. We used IEEE notation.
2. So when IDEF1X was published, no one used {Complete|Incomplete}. [Technically, since one could always add a subtype in the future, every cluster might be Incomplete!].
3. The first (and only compliant) product ERwin provided both notations from day one.
4. ERwin Methods Guide was freely available, and even people who did not have ERwin used it as the proper definition for IDEF1X (rather than purchase).
I concur that the IDEF1X Notation for both Subtypes and Relations is inferior.
Therefore, forget about the thing that does not work, that is known to be inferior, that only academics use, and use the thing that does work, that practitioners have used since 1983, the IEEE notation. For both Subtypes and Relations. Every DM that I am aware of used IEEE (except yours, but you are earnestly trying to understand and use the Standard as is, rather than the modified Standard that practitioners use).
----
Nevertheless, I want to make sure that this particular item is resolved, because absolutely everything that occurs in reality can be modelled under FOPC; the /RM/; and IDEF1X. Refer to my Subtype doc for details and specific examples re what I state here.
First, absolutely and always, think of the Basetype+Subtype pair as a single LOGICAL row (I won’t use silly terms such as “tuple”). Rather than as parent-child (which it is in physical, SQL terms).
> On the other hand, it makes it impossible to express the situation
> above, i.e., that "P must be A, B, or both" (complete + inclusive).
> ... each instance
> of the parent must always be an instance of one of the children—even
> when the cluster has only one child.
A cluster that has only one child is a Normalisation error. It is not a Basetype-Subtype but an optional column and therefore an optional table.
> when the cluster has only one child.
If it is not optional, then it is as you say “absorbed” into the parent.
> I find it somewhat surprising that this aspect has not been clarified
> and addressed in the standard, which was last revised in 2019.
Cheers
Derek
Nicola
Apr 2, 2021, 3:39:42 PM4/2/21
to
>> Another first-hand historical perspective is provided by:
>>
>> https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
>
> 404 - Not Found.
My fault (wrong case):
>>
>> https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
>
> 404 - Not Found.
https://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html
I'll come back to the rest at a later time.
Nicola
Derek Ignatius Asirvadem
Apr 2, 2021, 5:45:36 PM4/2/21
to
> On Saturday, 3 April 2021 at 06:39:42 UTC+11, Nicola wrote:
>
> >> https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
> >
> > 404 - Not Found.
>
> My fault (wrong case):
>
> https://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html
>
> >> https://www.mcjones.org/system_r/sql_reunion_95/sqlr95.html
> >
> > 404 - Not Found.
>
> My fault (wrong case):
>
> https://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html
> On Wednesday, 31 March 2021 at 22:58:03 UTC+11, Nicola wrote:
>
>
> Another first-hand historical perspective is provided by:
>
>
> Quote from the "Prehistory" section:
>
> "[...] Nevertheless, what kicked off this work [on project Gamma-0 and,
> eventually, System R] was a key paper by Ted Codd - was it published in
> 1970 in CACM?
>
> - Yes.
>
> - A couple of us from the Systems Department had tried to read it -
> couldn't make heads nor tails out of it. [laughter] At least back
> then, it seemed like a very badly written paper: some industrial
> motivation, and then right into the math. [laughter]"
>
> Those are not academics talking.
No, no, no. Those ARE academics talking. Rather famous ones.
>
> "[...] Nevertheless, what kicked off this work [on project Gamma-0 and,
> eventually, System R] was a key paper by Ted Codd - was it published in
> 1970 in CACM?
>
> - Yes.
>
> - A couple of us from the Systems Department had tried to read it -
> couldn't make heads nor tails out of it. [laughter] At least back
> then, it seemed like a very badly written paper: some industrial
> motivation, and then right into the math. [laughter]"
>
> Those are not academics talking.
Those articles reinforce my declarations, not yours ! Each has a great understanding of a very narrow field (of research) and each remained clueless about the other fields, even related fields. And far removed from the “industry” and “users”.
At Cincom, let me assure you, we were very aware of that, which is typical in large corps such as IBM, and sought to avoid that sort of problem by having a small team made up of specialists, in one location. TOTAL for DEC/PDP was written by a team of four. I came to Australia to write the “next generation” TOTAL for DEC/VAX with full ACID, our team was five. We did it in 18 months, it was named ULTRA-DBMS. (Later, Cincom missed the Relational bus, and got side-lined.)
Cheers
Derek
Nicola
Apr 3, 2021, 6:27:43 PM4/3/21
to
say that it's not hard to find some that are supportive of the RM. Any
that have understood it? Hard to tell... Progressed it? Let's see:
I have a few papers on semantic modeling, which do not qualify; several
papers on data dependencies, normal forms and other purely theoretical
amenities such as closed/open worlds or the computational complexity of
joins, which do not qualify because they are not practical; and a few
papers on physical and systems design (such as the papers on System R),
which might qualify, but they are from the IBM Systems Journal or IBM
Research Labs.
I would consider Grant's 1977's critique on "Null values in a Relational
Data Base" a progress, as it pointed out the inconsistency of Codd's
preliminary proposal for the treatment of nulls. But you'd likely say
that Codd's treatment of nulls was a regression, so Grant would at most
move things back to the start.
I'd rather like to know why you think that, after 1981, papers with
the qualities that you cannot ascribe to '70s papers would exist, and
ask you to name one such paper, if you know any.
Anyway, I appreciate your own recount of those times, albeit somewhat
critical of the sources I have cited. I do not feel qualified to comment
on that any further, though.
>> IDEF1X relies heavily upon Chen's shoulders.
>
> Nonsense. Give one example, one article. Rob Brown already had
> a diagrammatic modelling method (as distinct from the various diagrams
> that data modellers created) that was widely accepted ... after
> consultation with Codd, he produced what became known as IDEF1X.
approach to IDEF information modeling] stemmed from the early work of
Dr. E. F. Codd on relational theory and Dr. P. P. S. Chen on the
entity-relationship model."
And two paragraphs later: "Application within industry had led to the
development in 1982 of a Logical Database Design Technique (LDDT) by R.
G. Brown of the Database Design Group. The technique was based on the
relational model of Dr. E. F. Codd, the entity-relationship model of Dr.
P. P. S. Chen, and the generalization concepts of J. M. Smith and D. C.
P. Smith."
> Ok, fine. But your words contradict that, you can’t say that and also
> say “My main complaint with IDEF1X is the treatment of generalization
> hierarchies”.
>
> So what, if anything, is your remaining complaint re “generalization
> hierarchies”.
a specific critique on the specific notation used by IDEF1X. That has
nothing to do with understanding transactions, or whatever. It is the
lack of a way (if you follow the standard) or a cumbersome way (if you
follow Bruce/ERwin) to represent what in your document is called
"Non-Exclusive Subtyping", using the "complete categorization" symbol.
>> Regarding subtyping, my critique is specifically on the notation given
>> in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
>> Subtype".
>
> What “crossing” ???
at the intersection of the "Complete" column and "Inclusive Subtype"
row.
> You can’t use both IDEF1X and IEEE notation in any single model, they
> cannot be mixed. They are exclusive. You can’t go back-and-forth
> either.
> Sorry. I don’t understand what you are trying to say.
a nutshell, that non-exclusive subtyping is not straightforward as it
should be (as it is in IE).
>> > Here is a quick document that clarifies the issues you questioned,
>> > that I have answered. To be complete, I have added an item re
>> > Rolenames, because it is the third common “issue” that people raise:
>> > https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
>>
>> A question: what is the use case for an association that does not imply
>> a foreign key (rightmost symbol in your "improved IE")? Why would you
>> require a parent entity to exist at the time of insertion, but not
>> later?
>
> It is actually a very common requirement. Refer this Data Model:
> ____https://www.softwaregems.com.au/Documents/Student_Resolutions_2020/Giannis/RoomMonitor%20DM%20V0_51.pdf
model, but one thing that I have noticed is that there is no independent
Sensor entity. That strikes as something unusual. It's ok to associate
a Reading with a Room for auditing, but with an independent Sensor you
should also be able to maintain referential integrity even when
a sensor's location is changed as the MAC is immutable. But, again,
I need to re-read your requirements.
> Since we are discussing IDEF1X, you might be interested in this Q&A:
> ____https://stackoverflow.com/q/4132044/484814
Nicola
Nicola
Apr 3, 2021, 6:40:19 PM4/3/21
to
On 2021-04-02, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>> On the other hand, it makes it impossible to express the situation
>> above, i.e., that "P must be A, B, or both" (complete + inclusive).
>
> If you give me an example (names, not A B C), I would be happy resolve it.
The example from your Subtype.pdf document is fine: a PastTime (P) must
>> On the other hand, it makes it impossible to express the situation
>> above, i.e., that "P must be A, B, or both" (complete + inclusive).
>
> If you give me an example (names, not A B C), I would be happy resolve it.
be a PasttimeHobby (A) or a PasttimeSport (B), or both.
Using standard IDEF1X symbology, and following the text of the standard
(FIPS 184 or ISO 31320:2, they don't differ on this), you cannot express
the assertion above, only approximate it, AFAICS.
In Bruce's book (and in ERwin) you'd use two clusters, each with one
child, but that requires an interpretation that does not find
an equivalent in the standards. At least, to the best of my
understanding.
Nicola
Derek Ignatius Asirvadem
Apr 4, 2021, 5:06:00 AM4/4/21
to
Nicola
> On Sunday, 4 April 2021 at 08:40:19 UTC+10, Nicola wrote:
Thanks for yours.
> > On 2021-04-02, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> >> On the other hand, it makes it impossible to express the situation
> >> above, i.e., that "P must be A, B, or both" (complete + inclusive).
> >
> > If you give me an example (names, not A B C), I would be happy resolve it.
>
> The example from your Subtype.pdf document is fine: a Pastime (P) must
> be a PastimeHobby (A) or a PastimeSport (B), or both.
>
> Using standard IDEF1X symbology [excluding IEEE notation], and following the text of the standard
It appears this is boiling down to:
- you do not accept the IEEE notation for Relational Data Modelling
- you are in denial that IEEE notation exists
--- in fact it existed before you or I were born
- you do not accept correction of an incomplete Standard
--- even if the correction existed prior
--- or put otherwise, IDEF1X Subtype notation is a regression, and thus invalid
- therefore for you there is only the IDEF1X notation
Yes, the IDEF1X Subtype notation is broken. Yes, that is just one of the many things that one should be able to (a) model, and (b) model compliant with the /RM/, that cannot be rendered in IDEF1X/IDEF1X Subtype Notation.
The same problem exists with IDEF1X Cardinality notation.
So freaking what.
If you are a hardened academic, that is all there is in the modelling world, and you can’t accept a Data Modelling job of any kind, because the Standard is broken and you can’t model things that exist in nature correctly.
That is why academics cannot work in the industry that they theorise about. They never the leave university mindset.
Enter the practical man. Drum roll and dancing girls.
The Standard is broken ? No worries, I will fix it.
Please be advised, as detailed in my previous post, we had System Diagrams; File Definition Diagrams long before the /RM/, long before IDEF1X, and we used IEEE notation for Subtypes and Cardinality. Such that when IDEF1X came along, any one who was actually practicing (had diagrams and knowledge of IEEE notation) knew immediately that the IDEF1X Subtype & Cardinality notation was broken; that the well-known and pre-existing IEEE notation was NOT broken, and we used it instead. We viewed the IDEF1X Notation as an esoteric joke. As evidenced in the first product, ERwin, from the very first version (otherwise there is no purpose in it giving both notations).
The problem is, academics like you and the guy who wrote that superficial critique, are (a) hanging onto to the original IDE1X Standard definition, (b) refusing to accept that the IEEE notation existed prior, (c) refusing to accept that the IDEF1X notation is broken, and inferior to the IEEE, and (d) thus maintaining an unresolved space [the Non-Excluded Middle], whereas practitioners have a completely resolved space [the Middle, Excluded].
Whereas science was founded on the Four Laws of Thought, and progressed within those tight boundaries for 2,400 years, and thus such unresolved spaces were absolutely forbidden [Law of the Excluded Middle], with the advent of Modern “science”, the Four Laws; Causality; the Hierarchy, are all denied and suppressed, precisely in order to erect fantasy as “reality”. If you play the role of a medieval monk for a few moments, intending to obtain the reward of heaven (eg. no lies; no misrepresentations; no omissions):
- the Middle [d] is not acceptable, it must be Excluded, it would motivate you to obtain resolution
- the denial of reality in [b][c] has to be removed, reality must be admitted, otherwise you would be insane
- you will arrive at the determination that the published Standard is incomplete; unusable as is
- petition ISO to correct the published Standard, to use the pre-existing and not-broken IEEE notation
- use the pre-existing and not-broken IEEE notation until such time as ISO publishes the amendment
Modern academics alone, enjoy the luxury of wringing their hands because a Standard is incomplete, and can only do so in their ivory towers; their protected safe spaces, and in denial of reality. They get to argue; to debate; to discuss, things that are closed; resolved; unarguable to practitioners, and to do so for decades after resolution has been achieved in reality. These two items were closed in the 1980’s in manual diagrams, closed with the first version of ERwin in terms of Data Modelling Tools. But here we are today, forty years after the fact, still arguing about it, as if it has NOT been resolved.
> In Bruce's book (and in ERwin) you'd use two clusters, each with one
> child, but that requires an interpretation that does not find
> an equivalent in the standards. At least, to the best of my
> understanding.
Your understanding is correct.
That interpretation is false.
Bruce is an idiot (per reasons explained above, for noticing the problem and NOT resolving it).
Do not follow an idiot.
Further, the “two clusters with one child each” is a hideous, gross, Normalisation error.
Thus the model is invalid; incorrect, fix it.
The Standard (any Standard) is not a Method. At best, a Standard is a notation, that (a) prevents illegal arrangements by virtue of NOT having a notation for it, and (b) encourages correct definition by having mandatory notation. When a Standard has an error, yet another Standard, usually a higher Standard or a pre-existing one (ie. not your or my private fabrication) is used to correct it or to fill the gap. Issue closed, resolved for practitioners.
As a counter-point, think about UML. Even though it is heavily marketed as a “Standard”, it is not a Standard by any means, because it is (a) grossly incomplete: each modeller adds his own 5 to 10 notations to cover the missing bits because he has designed objects or interaction for which no UML notation exists. When a few hundred do that private dance and publish their models, those 400 or 500 notations become de facto UML, like it or not. Yes, you and I as purists would reject all that. But whereas I would model it in a genuine modelling notation, and thus resolve the issue, you would stand and argue that UML is broken, that the added notation is invalid.
Further, the main fault with UML, its self-destroying fault, is [b] the lack of integration in all areas, The many different diagrams simply do not come together as an integrated System Definition.
The most important missing capability is [c] that which is required for genuine Analysis, and genuine Design: composition/decomposition. Which of course the pre-existing Standards had, and still have. So the practical person uses IDEF1X Corrected for the Data Model; SSADM or IDEF0 for the Process Model; and dismisses UML. Which remains an endless study for the OO/ORM developers obsess about, to draw their precious dingalings in, and to keep replacing. Much like the insane study the toilet bowl. Eg. I could give my Transaction Definitions as UML Methods, which is limited, or as IDEF1X Extensions that include SQL pseudo-code (as in my Subtype doc). They are defined fully in my GUI Definition [interaction] docs.
The converse is, as you are fully aware, OO/ORM developers not-analysing the requirement, then not-designing the process, then obsessing about their Objects that “need persistence”, spending their entire life drawing and re-drawing said Objects, and last but not least, writing records to a ”persistent data store” that gets “refactored” every month or quarter. Viewing both the world, and the requirement through the myopic lens of oo/orm. Maslow’s Golden Hammer syndrome (If all you have in your toolbag is a hammer, every problem looks like a nail).
You have determined that UML is stupid for Data Modelling of any kind, great. You have accepted IDEF1X for Relational Data Modelling, great. You are at the brink of jettisoning ERD, but your blind loyalty to academia prevents you from calling it what it is, and your non-resolution of a simple problem in the IDEF1X Standard prevents you from embracing it.
Thus, I would prevail upon you, given your teaching position, the influence you have on bright eager young minds, to teach only resolutions, not ambiguity or non-resolution. As the industry has done, as they have built thousands of Relational Databases, for forty years.
I have updated this doc to reflect the above. In case there remains anything worth discussing on this issue, I have added a page with the Subtypes, and given the Predicates (which are an excellent method of verifying the model, a feedback loop).
____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
Cheers
Derek
> On Sunday, 4 April 2021 at 08:40:19 UTC+10, Nicola wrote:
Thanks for yours.
> > On 2021-04-02, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> >> On the other hand, it makes it impossible to express the situation
> >> above, i.e., that "P must be A, B, or both" (complete + inclusive).
> >
> > If you give me an example (names, not A B C), I would be happy resolve it.
>
> be a PastimeHobby (A) or a PastimeSport (B), or both.
>
> Using standard IDEF1X symbology [excluding IEEE notation], and following the text of the standard
> (FIPS 184 or ISO 31320:2, they don't differ on this), you cannot express
> the assertion above, only approximate it, AFAICS.
The "or both" is not a Predicate, it is a collection of instances.
> the assertion above, only approximate it, AFAICS.
It appears this is boiling down to:
- you do not accept the IEEE notation for Relational Data Modelling
- you are in denial that IEEE notation exists
--- in fact it existed before you or I were born
- you do not accept correction of an incomplete Standard
--- even if the correction existed prior
--- or put otherwise, IDEF1X Subtype notation is a regression, and thus invalid
- therefore for you there is only the IDEF1X notation
Yes, the IDEF1X Subtype notation is broken. Yes, that is just one of the many things that one should be able to (a) model, and (b) model compliant with the /RM/, that cannot be rendered in IDEF1X/IDEF1X Subtype Notation.
The same problem exists with IDEF1X Cardinality notation.
So freaking what.
If you are a hardened academic, that is all there is in the modelling world, and you can’t accept a Data Modelling job of any kind, because the Standard is broken and you can’t model things that exist in nature correctly.
That is why academics cannot work in the industry that they theorise about. They never the leave university mindset.
Enter the practical man. Drum roll and dancing girls.
The Standard is broken ? No worries, I will fix it.
Please be advised, as detailed in my previous post, we had System Diagrams; File Definition Diagrams long before the /RM/, long before IDEF1X, and we used IEEE notation for Subtypes and Cardinality. Such that when IDEF1X came along, any one who was actually practicing (had diagrams and knowledge of IEEE notation) knew immediately that the IDEF1X Subtype & Cardinality notation was broken; that the well-known and pre-existing IEEE notation was NOT broken, and we used it instead. We viewed the IDEF1X Notation as an esoteric joke. As evidenced in the first product, ERwin, from the very first version (otherwise there is no purpose in it giving both notations).
The problem is, academics like you and the guy who wrote that superficial critique, are (a) hanging onto to the original IDE1X Standard definition, (b) refusing to accept that the IEEE notation existed prior, (c) refusing to accept that the IDEF1X notation is broken, and inferior to the IEEE, and (d) thus maintaining an unresolved space [the Non-Excluded Middle], whereas practitioners have a completely resolved space [the Middle, Excluded].
Whereas science was founded on the Four Laws of Thought, and progressed within those tight boundaries for 2,400 years, and thus such unresolved spaces were absolutely forbidden [Law of the Excluded Middle], with the advent of Modern “science”, the Four Laws; Causality; the Hierarchy, are all denied and suppressed, precisely in order to erect fantasy as “reality”. If you play the role of a medieval monk for a few moments, intending to obtain the reward of heaven (eg. no lies; no misrepresentations; no omissions):
- the Middle [d] is not acceptable, it must be Excluded, it would motivate you to obtain resolution
- the denial of reality in [b][c] has to be removed, reality must be admitted, otherwise you would be insane
- you will arrive at the determination that the published Standard is incomplete; unusable as is
- petition ISO to correct the published Standard, to use the pre-existing and not-broken IEEE notation
- use the pre-existing and not-broken IEEE notation until such time as ISO publishes the amendment
Modern academics alone, enjoy the luxury of wringing their hands because a Standard is incomplete, and can only do so in their ivory towers; their protected safe spaces, and in denial of reality. They get to argue; to debate; to discuss, things that are closed; resolved; unarguable to practitioners, and to do so for decades after resolution has been achieved in reality. These two items were closed in the 1980’s in manual diagrams, closed with the first version of ERwin in terms of Data Modelling Tools. But here we are today, forty years after the fact, still arguing about it, as if it has NOT been resolved.
> In Bruce's book (and in ERwin) you'd use two clusters, each with one
> child, but that requires an interpretation that does not find
> an equivalent in the standards. At least, to the best of my
> understanding.
That interpretation is false.
Bruce is an idiot (per reasons explained above, for noticing the problem and NOT resolving it).
Do not follow an idiot.
Further, the “two clusters with one child each” is a hideous, gross, Normalisation error.
Thus the model is invalid; incorrect, fix it.
The Standard (any Standard) is not a Method. At best, a Standard is a notation, that (a) prevents illegal arrangements by virtue of NOT having a notation for it, and (b) encourages correct definition by having mandatory notation. When a Standard has an error, yet another Standard, usually a higher Standard or a pre-existing one (ie. not your or my private fabrication) is used to correct it or to fill the gap. Issue closed, resolved for practitioners.
As a counter-point, think about UML. Even though it is heavily marketed as a “Standard”, it is not a Standard by any means, because it is (a) grossly incomplete: each modeller adds his own 5 to 10 notations to cover the missing bits because he has designed objects or interaction for which no UML notation exists. When a few hundred do that private dance and publish their models, those 400 or 500 notations become de facto UML, like it or not. Yes, you and I as purists would reject all that. But whereas I would model it in a genuine modelling notation, and thus resolve the issue, you would stand and argue that UML is broken, that the added notation is invalid.
Further, the main fault with UML, its self-destroying fault, is [b] the lack of integration in all areas, The many different diagrams simply do not come together as an integrated System Definition.
The most important missing capability is [c] that which is required for genuine Analysis, and genuine Design: composition/decomposition. Which of course the pre-existing Standards had, and still have. So the practical person uses IDEF1X Corrected for the Data Model; SSADM or IDEF0 for the Process Model; and dismisses UML. Which remains an endless study for the OO/ORM developers obsess about, to draw their precious dingalings in, and to keep replacing. Much like the insane study the toilet bowl. Eg. I could give my Transaction Definitions as UML Methods, which is limited, or as IDEF1X Extensions that include SQL pseudo-code (as in my Subtype doc). They are defined fully in my GUI Definition [interaction] docs.
The converse is, as you are fully aware, OO/ORM developers not-analysing the requirement, then not-designing the process, then obsessing about their Objects that “need persistence”, spending their entire life drawing and re-drawing said Objects, and last but not least, writing records to a ”persistent data store” that gets “refactored” every month or quarter. Viewing both the world, and the requirement through the myopic lens of oo/orm. Maslow’s Golden Hammer syndrome (If all you have in your toolbag is a hammer, every problem looks like a nail).
You have determined that UML is stupid for Data Modelling of any kind, great. You have accepted IDEF1X for Relational Data Modelling, great. You are at the brink of jettisoning ERD, but your blind loyalty to academia prevents you from calling it what it is, and your non-resolution of a simple problem in the IDEF1X Standard prevents you from embracing it.
Thus, I would prevail upon you, given your teaching position, the influence you have on bright eager young minds, to teach only resolutions, not ambiguity or non-resolution. As the industry has done, as they have built thousands of Relational Databases, for forty years.
I have updated this doc to reflect the above. In case there remains anything worth discussing on this issue, I have added a page with the Subtypes, and given the Predicates (which are an excellent method of verifying the model, a feedback loop).
____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
Cheers
Derek
Nicola
Apr 4, 2021, 6:50:43 AM4/4/21
to
On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> The "or both" is not a Predicate, it is a collection of instances.
>
> It appears this is boiling down to:
> - you do not accept the IEEE notation for Relational Data Modelling
> - you are in denial that IEEE notation exists
> --- in fact it existed before you or I were born
> - you do not accept correction of an incomplete Standard
> --- even if the correction existed prior
> --- or put otherwise, IDEF1X Subtype notation is a regression, and thus invalid
> - therefore for you there is only the IDEF1X notation
I am not in denial of anything; I can read your data models without
> The "or both" is not a Predicate, it is a collection of instances.
>
> It appears this is boiling down to:
> - you do not accept the IEEE notation for Relational Data Modelling
> - you are in denial that IEEE notation exists
> --- in fact it existed before you or I were born
> - you do not accept correction of an incomplete Standard
> --- even if the correction existed prior
> --- or put otherwise, IDEF1X Subtype notation is a regression, and thus invalid
> - therefore for you there is only the IDEF1X notation
issues, for instance, and I am not asking you or anyone to use a "more
standard" notation for the sake of it.
That said, yes, I prefer to stick to IDEF1X notation; but I have no
problem diverging from the standard if I need to.
> Yes, the IDEF1X Subtype notation is broken. Yes, that is just one of
> the many things that one should be able to (a) model, and (b) model
> compliant with the /RM/, that cannot be rendered in IDEF1X/IDEF1X
> Subtype Notation.
1. are the subtype mutually exclusive or not?
2. is every instance of the parent entity an instance of some child
entity ("subtyping" in your terminology), or not?
So, four combinations. Following the terminology of your document:
| Exclusive?
Subtyping? | Yes No
-----------|----------------------------------------------
Yes | Exclusive Subtyping Non-exclusive subtyping
No | ? Optional attr.[Group], Not Subtype
In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
What is marked with ? corresponds to an "incomplete categorization" in
IDEF1X terminology. Using IE notation, how would you model an
"incomplete categorization"? There is no example in your document.
Concrete example:
- An Employee may be a Consultant;
- An Employee may be a Full-Time Employee;
- An Employee may be neither a Consultant nor a Full-Time Employee;
- An Employee cannot be both a Consultant and a Full-Time Employee.
Note, I am not asking you how you would *implement* this situation; only
how a data model would look like.
> The same problem exists with IDEF1X Cardinality notation.
>> In Bruce's book (and in ERwin) you'd use two clusters, each with one
>> child, but that requires an interpretation that does not find
>> an equivalent in the standards. At least, to the best of my
>> understanding.
>
> Your understanding is correct.
> That interpretation is false.
> Bruce is an idiot (per reasons explained above, for noticing the problem and NOT resolving it).
> Do not follow an idiot.
> Further, the “two clusters with one child each” is a hideous, gross, Normalisation error.
> Thus the model is invalid; incorrect, fix it.
(with IE notation). I do not have an ERwin license, so I can't try it
myself.
> As a counter-point, think about UML. Even though it is heavily
> marketed as a “Standard”, it is not a Standard by any means, because
> it is (a) grossly incomplete: each modeller adds his own 5 to 10
> notations to cover the missing bits because he has designed objects or
> interaction for which no UML notation exists. When a few hundred do
> that private dance and publish their models, those 400 or 500
> notations become de facto UML, like it or not. Yes, you and I as
> purists would reject all that. But whereas I would model it in
> a genuine modelling notation, and thus resolve the issue, you would
> stand and argue that UML is broken, that the added notation is
> invalid.
glitch that can be easily fixed; "fixing UML" is something on another
level entirely: I'd not dare ask anything like that.
> Further, the main fault with UML, its self-destroying fault, is [b]
> the lack of integration in all areas, The many different diagrams
> simply do not come together as an integrated System Definition.
explanation purposes, I think I have little or nothing to reply to or
disagree with you about UML or ORM (by which I assume you mean
Object-Relational Mapping).
> I have updated this doc to reflect the above. In case there remains
> anything worth discussing on this issue, I have added a page with the
> Subtypes, and given the Predicates (which are an excellent method of
> verifying the model, a feedback loop).
>
> ____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
correctly. My only remaining question is the one above.
RE the added page, looking at the transactions, I think PersonPastime's
subtypes are not exclusive (the diagram has an X that should not be
there).
Happy Easter,
Nicola
Message has been deleted
Derek Ignatius Asirvadem
Apr 4, 2021, 10:32:52 PM4/4/21
to
1. Normal Forms
They are all a complete joke. Half are redundant, the other half are ignorant of the /RM/, and so they “invent” something that is already in the RM (I have written a couple of responses).
That does not count the various changes the Date; Darwen; Fagin gang keep making to the NFs, which are pig poop. None of the idiots have articulated the Normal Forms that are in the /RM/. Maybe if we wait another fifty years.
2. Complexity of Joins
Nothing compared to the papers already written by Sybase Engineers. We have the most intelligent, third generation, Parser and Query Optimiser. You will not believe the level of analysis and reduction of complexity, then determination of access paths based on Statistics. I have read some of those academic papers and cacked myself (I still have difficulty believing that academics are so isolated from the real world, that they read only what their colleagues write, and thus maintain a cocoon).
(In the last 20 years, we have stopped publishing papers, because we do not want to give the freeware crowd the Method, by publishing our Trade Secrets. I have yanked some of my Sybase doco, and there are a few more than I will yank soon. The Sybase Technical Forum has moved out of public view, into a closed SAP-Only stable, so the public don’t get the details even via technical chats.)
3. “Semantic Models”
It appears you do not get it, and this one is going to be hard nut to cut through, because the academic mindset is set and reinforced by many papers. Look, as an academic; as a mathematician; as a logician, why is it that every single diagram you draw is NOT semantic ???
You understand FOPC. FOPC is semantic. That is the foundation of the /RM/. Now whatever you draw, make sure it is a legal FOPC Predicate, independent, or dependent on other Predicates. Chose your notation, or write one yourself.
The problem is, the academics have concocted this notion of “semantic model”, and written 57 papers about it, with lots of self-serving citations, so they think it is “real”. It isn’t, it is a collectively assented fiction. Much like the problem of “universals”, the freaks deny that Universals exist; what causes their existence; what sustains their existence, and then they concoct a slew of possible ways that “universals” could exist, and they spend the rest of their lives debating the possibilities, never resolving anything. It was resolved in 350BC by Aristotle.
Same here. Academics deny the simple fundamental atomic existence of SEMANTICS, that it is in FOPC already, that conjuring up another “semantics” or forty three is a stupid but income-producing shell game that they can play with each other. Further by denying THE semantic root (FOPC), and then fabricating a “semantic” layer somewhere else, whatever semantics their “semantic” layer has is a mere fraction, and due to incorrect architectural deployment, both massive and hard to design and implement. In any case, it will be grossly incomplete, with no sense of integration.
I will give you a parallel example, which we have discussed to some degree (unfortunately not to closure), the Movie Title Thread. The Relational Data Modeller gave you the Relational Data Model for Movie Title, it has all the FOPC Predicates thought out and modelled. What you engaged in over 14 iterations. Strict FOPC and /RM/, therefore any SQL written against it will be straight-forward (no complexity, /Complexity of Joins/ papers may be irrelevant, yet another academic shell game). In fact any report requirement can be serviced via a single SELECT. But the starting position; the academic position was, “it can’t be done in the /RM/, we need an /ontology/ and a /description logics/“. Don’t mention a fat middleware server, and masses of s/w. Don’t mention that when the perception of data changes, all three layers must be changed, and the “database” has to be “refactored”..
When we insist of FOPC; the /RM/; and genuine Relational Modelling, the /hoontology/ and /descwiption non-logics/ are eliminated, they stand as vacuums. There is no need for an /onotology/ [what a filthy label] to tell the world what the structure of the data is, because the story is told in super integrated form, by the Data Model itself, because the DM is Semantic, because it engages FOPC Predicates.
Another parallel example. FOPC -> Relational Model -> SQL. So real SQL is strictly based on FOPC. But the Torrid Manifesto gulag, the Date; Darwen; Fagin religion totally suppress FOPC and the /RM/, and then assert that SQL is broken. Not only that, they will produce a “data sublanguage” that conforms to the “relational model” which is in fact the anti-Relational RM/T. Thirty years and still nothing.
Meanwhile, back at the farm, guys like me who are unsoiled with their pig poop find absolutely nothing wrong with SQL, there is nothing we cannot do in SQL over a genuine Relational Database.
Do you see what I am trying to say ? Academics are clueless about what SEMANTICS is, that it is already in FOPC, they are therefore clueless about FOPC, what it really and truly is, how the /RM/ isfounded on FOPC. But they write volumes of papers about what “semantics” could be.
> I would consider Grant's 1977's critique on "Null values in a Relational
> Data Base" a progress, as it pointed out the inconsistency of Codd's
> preliminary proposal for the treatment of nulls. But you'd likely say
> that Codd's treatment of nulls was a regression, so Grant would at most
> move things back to the start.
Three-valued logic is plain stupid. I have never used it. I have no Nulls in any database, not even from 1983.
It can be understood only in the context that Codd was bending over backwards to get some engagement from the academic community. For ten years. Same as RM/T. A massive regression to pre-1960’s filing systems. Not even 1970’s.
> I'd rather like to know why you think that, after 1981, papers with
> the qualities that you cannot ascribe to '70s papers would exist, and
> ask you to name one such paper, if you know any.
When I bracketed 1970 to 1980, it was about that critical period when Codd had no support, and was running around the country marketing the /RM/, and unfortunately bending over backwards to demonstrate how even Record-ID-based ISAM and HDBMS could benefit from the /RM/, which was RM/T, which was then fraudulently used by the pig poop Gulag to market as “the Relational Model”.
After 1980, when the /RM/ was accepted, and notably first by RDBMS providers, who actually produced RDBMSs, not by academics, the papers were commercial, internal.
Sure, there were total lunatics such as Stonebraker (great salesman, great cult leader, disgusting academic) that tried to implement parts of the /RM/, while being clueless about databases; contention; concurrency; and transactions (all of which were well and truly implemented and implemented correctly, for 30 years at that time). So in perfect academic fashion, he ignored all that reality, that the database is a shared resource that is in constant change, and concocted the schizophrenic [reality-contradicting] notion of the dumb user that has view of a fixed unchanging database to engage with.
It was called MVCC, but the label is false, there is no such thing in reality as “multiple versions” of a single database, that is the first layer of schizophrenia, like everyone going back to their private tiled cells in the asylum, each holding one row from the single ever-changing story in the library. And no problem, they take their time modifying “their” row, and they will submit in in the morning, after ablutions and a good breakfast. It breaks the first principle of a database: a single version of the truth, shared by all who access it. Maybe have a soy latte, and watch the little girls walk by.
The “concurrency control” part of the label is utterly Stonebraker-style false. It does absolutely nothing re concurrency (each user is left to his own devices, which is the pretence that it is a single-user database mounted between his big toes, to do as he pleases), and certainly nothing to control concurrency. Concurrency is denied, and resolution of the fantasised changes is deferred to the COMMIT.
The best that can be said for it, in honest technical terms that academics have no access to, is that it attempts to serialise the multiple [chronological] events that each user schizophrenically thinks he did (which he actually did not do), in denial of the other users’ events (some of which actually did happen), after the fact [of the fantasy that he did], after all the horses have bolted, when he sends COMMIT. And it fails miserably.
The mantra “readers never block writers, and writers never block readers" is exactly that, a mantra. Same as when a fat and ugly old man goes up to the mirror and repeats his mantra “I am a chick magnet”. It is very satisfying, thinking about events, that have never happened in the past, that will definitely positively absolutely happen in the future. Coz he said so. Check the resolute look in the mirror, tis “real”.
The simple fact is, MVCC does not work without locking, it is a gross lie that MVCC is a substitute for locking. PissGross has four LEVELS of locking (with minor levels within each), on top of MVCC, and it still can’t resolve the millions of multiple versions of records that it has to maintain.
____ https://stackoverflow.com/search?q=%5Bpostgresql%5D+lock+problem
Meanwhile, back at the commercial farm, since 1981 [for RDBMS], with Ordinary Locking (aka “2PL”), of the single version of the truth (ala the first Principle of a Database), we don’t have versions of data, let alone multiple versions, let alone deferred resolutions of multiple version.
Note that that description touches the fantasy of MVCC (which has hidden Locking) vs Locking, it does not mention the main limiting issue re concurrency: the Transaction Log, which also has to be serialised, and which is a higher order than the resolution of the multiple false versions of reality. It must be mentioned, there are two orders [not one] of issues that have to be resolved at COMMIT, which the guru of idiocy Stonebraker denies, and defers to the COMMIT.
The second and third layers of schizophrenia are the ways and means they have written, first in academic papers, and then in implementations, about how to not-have contention problems (by denying the existence of other users that cause contention); how to not-have consistency problems (by denying the existence of all other versions of the row except his “own” single row). Don’t worry, we will resolve everything when the drooling idiot COMMITS. Oopsy, it cannot be resolved, Sally’s row is 42 versions out-of-date, and Fred’s row that is blocking it is 36 versions out-of-date. No problem, let’s redefine “transactions”.
So they munchkins at Berkeley produced Ingres. Total failure. But heavily promoted by academia. So they produced PissGrossNONsql. Total failure. But heavily promoted by academia. “Don’t worry, we are clueless now, but at any moment now we won’t be, promise.” Same as the single cell from which all life forms “evolved”, “we will find it any moment now, even though we haven’t found it in 120 years”.
Larry Ellis saw a commercial opportunity, that he could do a better job of implementing the MVCC fiction than the Stonebraker ashram could (“hey, I don’t have to understand contention, I just deny its existence, and I can deny its existence better than Stonebraker”). It has no ACID, because MVCC cannot support ACID, it has contention problems that “2PL” systems simply do not have, but hey, everyone has a right to grab and hold a private row, while they wait for the coffee to get cold. It is institutionalised schizophrenia, a collective assent to a fiction, with masses of s/w and h/w resources demanded to make it “real”.
So the mantra “readers never block writers, and writers never block readers" may be true if we are charitable, but the great fraud is, they never mention that the method produces; tracks; sort-of-resolves, millions of multiple versions of the rows, which systems that utilise Locking do not do. And the second fraud is, the non-locking MVCC cannot resolve the multiple versions except by using Locking (and a disgusting mess of locks it is) on top of MVCC.
Hey, you get what you pay for. Freeware is free, no one can be held responsible.
> Anyway, I appreciate your own recount of those times, albeit somewhat
> critical of the sources I have cited. I do not feel qualified to comment
> on that any further, though.
> >> IDEF1X relies heavily upon Chen's shoulders.
> >
> > Nonsense. Give one example, one article. Rob Brown already had
> > a diagrammatic modelling method (as distinct from the various diagrams
> > that data modellers created) that was widely accepted ... after
> > consultation with Codd, he produced what became known as IDEF1X.
>
> FIPS 184, Background section: "The theoretical roots for [the initial
> approach to IDEF information modeling] stemmed from the early work of
> Dr. E. F. Codd on relational theory and Dr. P. P. S. Chen on the
> entity-relationship model."
So what, do you believe everything that is written ? They have written that homosexuals can have children, and that Chinese is a “language”.
When I said “article” I did not mean a report somewhere, I meant a concept, that is recognisable.
a. Name one thing, a method or rule or whatever, from the Chen ERD, that exists in IDEF1X.
b. Name one thing FROM the /RM/ that Chen has in his ERD.
> And two paragraphs later: "Application within industry had led to the
> development in 1982 of a Logical Database Design Technique (LDDT) by R.
> G. Brown of the Database Design Group. The technique was based on the
> relational model of Dr. E. F. Codd, the entity-relationship model of Dr.
> P. P. S. Chen,
> and the generalization concepts of J. M. Smith and D. C.
> P. Smith."
> > Ok, fine. But your words contradict that, you can’t say that and also
> > say “My main complaint with IDEF1X is the treatment of generalization
> > hierarchies”.
> >
> > So what, if anything, is your remaining complaint re “generalization
> > hierarchies”.
>
> My complaint is not about "generalization hierarchies" per se. It is
> a specific critique on the specific notation used by IDEF1X. That has
> nothing to do with understanding transactions, or whatever. It is the
> lack of a way (if you follow the standard) or a cumbersome way (if you
> follow Bruce/ERwin) to represent what in your document is called
> "Non-Exclusive Subtyping", using the "complete categorization" symbol.
If you take the {Complete|Incomplete} text in the Standard as gospel, and set it up as a rule for perceiving data [that you wish to model and understand], no, that will damage your perception of data badly. IDEF1X is not a DEFINITION of Data Modelling as an exercise, it is a notation. The Data Modelling exercise requires you to be open, to perceive the data as it actually exists in reality, not forced into a {Complete|Incomplete} mindset.
Separately, there is nothing that you cannot define [from the real universe, using legal Predicates], in FOPC; and thus the /RM/, which is why I asked, give me a real example, and I will resolve it for you, it has nothing to do with {Complete|Incomplete} vs {Exclusive|Non-Exclusive}, it has everything to do with accurate Data Modelling, without any fixed mindset.
> cumbersome
How exactly, is it “cumbersome” ? Predicates are Predicates, atomic. If your model does not resolve, due to not-having the right Predicates, and I resolve the model by inserting the missing Predicate, which of course is essential, and therefore minimal, how is that “cumbersome” ? It is only “cumbersome” to the person who holds the invalid perception of the unresolved model with the one less Predicate.
> >> Regarding subtyping, my critique is specifically on the notation given
> >> in ERwin Methods Guide at the crossing of "Complete" with "Inclusive
> >> Subtype".
> >
> > What “crossing” ???
>
> I did not express myself clearly. I meant the IDEF1X (not IE) notation
> at the intersection of the "Complete" column and "Inclusive Subtype"
> row.
> > Sorry. I don’t understand what you are trying to say.
>
> My fault, not the best example of clarity. But the point is, in
> a nutshell, that non-exclusive subtyping is not straightforward as it
> should be (as it is in IE).
Please inform me as to how Non-Exclusive Subypes is not straight-forward.
> >> > Here is a quick document that clarifies the issues you questioned,
> >> > that I have answered. To be complete, I have added an item re
> >> > Rolenames, because it is the third common “issue” that people raise:
> >> > https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
> >>
> >> A question: what is the use case for an association that does not imply
> >> a foreign key (rightmost symbol in your "improved IE")? Why would you
> >> require a parent entity to exist at the time of insertion, but not
> >> later?
> >
> > It is actually a very common requirement. Refer this Data Model:
> > ____https://www.softwaregems.com.au/Documents/Student_Resolutions_2020/Giannis/RoomMonitor%20DM%20V0_51.pdf
> I have had time only for a cursory look at the requirements and the
> model,
> but one thing that I have noticed is that there is no independent
> Sensor entity.
> That strikes as something unusual. It's ok to associate
> a Reading with a Room for auditing, but with an independent Sensor you
> should also be able to maintain referential integrity even when
> a sensor's location is changed as the MAC is immutable. But, again,
> I need to re-read your requirements.
When a Sensor is replaced, there is no other change to the Monitor, or to the location.
When a Monitor is replaced (repair; back to factory; etc), the extant Sensors stay with the Monitor. After repair and refurbishment, the Monitor gets shipped to a new location, the next waiting.
At the end of the day, it is Reading that is permanent, not Monitor; not Sensor.
Sure, it is possible to model/implement a permanent identifier for each little Sensor, that stays with the Room, rather than the Monitor, but I would have two problems with that: first, it is not reality (there is no permanent or unique Sensor identifier), so it would have to be fabricated, and thus not Relational. Second, the model would have to be re-worked raising Sensor above the Monitor that houses it, which is false.
Besides, that DM has been through 51 iteration slots by virtue of the version number, probably 34 actual iterations (whereas Movie Title was 14 iterations, not yet mature). It is pretty mature, and implemented with no problem whatsoever.
Cheers
Derek
Derek Ignatius Asirvadem
Apr 4, 2021, 11:59:09 PM4/4/21
to
> On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
> > On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> > Yes, the IDEF1X Subtype notation is broken. Yes, that is just one of
> > the many things that one should be able to (a) model, and (b) model
> > compliant with the /RM/, that cannot be rendered in IDEF1X/IDEF1X
> > Subtype Notation.
Before I get into the response, as detailed in my previous post, you need to divest yourself of rules or “rules” that you take by implication of the IDEF1X/IDEF1X Subtype definition. And open up to the world of reality, of modelling data as it is, of course in conformation to FOPC and the /RM/ but not conforming to limitations of IDEF1X or anything else (such as physical implementation in limited freeware; etc).
> > On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> > Yes, the IDEF1X Subtype notation is broken. Yes, that is just one of
> > the many things that one should be able to (a) model, and (b) model
> > compliant with the /RM/, that cannot be rendered in IDEF1X/IDEF1X
> > Subtype Notation.
> There are two orthogonal aspects in a generalization hierarchy:
Further, I accept wholeheartedly that the correct observation of genus vs species is an essential part of genuine Analysis, here Data Analysis.
> 1. are the subtype mutually exclusive or not?
____Exclusive
In Logic, that is an XOR Gate [Discriminator] on the Basetype that identifies the single Subtype. It is Semantic (examples in the progressing doc).
The remaining category, since it is not Exclusive, and certainly not inclusive, is called:
____Non-Exclusive
The Subtypes are not mutually exclusive. There is no Discriminator. Typically, the Basetype has more than one [but not many or all] Subtypes. Note that each Basetype-Subtype pair must be perceived as a logical row.
> 2. is every instance [row] of the parent entity an instance [row] of some child
> entity ("subtyping" in your terminology), or not?
For Exclusive: yes, exactly one Subtype row.
For Non-Exclusive: yes, one or more Subtype rows.
> So, four combinations.
Whoa. What four combinations ??? How can you combine Exclusive with Non-Exclusive ??? You will get “everything”, or scrambled eggs without salami. That is an error at the intellection level, the conceptualisation level. It is invalid.
> Following the terminology of your document:
>
> | Exclusive?
> Subtyping? | Yes No
> -----------|----------------------------------------------
> Yes | Exclusive Subtyping Non-exclusive subtyping
> No | ? Optional attr.[Group], Not Subtype
2. I don’t understand it, so much as I would like to respond, I can’t.
> In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
Which I find seriously lacking, since {Exclusive|Non-Exclusive} Subtypes existed before the /RM/ and before IDEF1X. Further, I am not about to be restricted by artificial limitations that are part of some notation, so I dismiss it on a second count.
> What is marked with ? corresponds to an "incomplete categorization" in
> IDEF1X terminology.
> Using IE notation, how would you model an
> "incomplete categorization"?
Well you can’t. Because the two methods of classification cannot be mixed.
Nevertheless, because the IDEF1X notation is inferior, a lower-order concept, it can be progressed to a superior, higher-order concept. Just get rid of the notion of “incomplete/complete”.
> There is no example in your document.
>
> Concrete example:
>
> - An Employee may be a Consultant;
> - An Employee may be a Full-Time Employee;
> - An Employee may be neither a Consultant nor a Full-Time Employee;
> - An Employee cannot be both a Consultant and a Full-Time Employee.
Page 4 added:
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
> Note, I am not asking you how you would *implement* this situation; only
> how a data model would look like.
Why on earth would I implement something other than what I know the data to be, which knowledge I obtain by modelling it ? Why would I waste time modelling data if I did not have an implementation intent or that is not-for-implementation ? It would be a pathetic relic made of cigar smoke. No thanks.
Ok, fine. It is different to you. Why ?
> > The same problem exists with IDEF1X Cardinality notation.
>
> Which problem do you have with IDEF1X cardinalities?
If the notation cannot be implemented, then it is something that only theoreticians can use (without confidence). Thus any data modelling notation must have enough definition to host an implementation. The academic notion that theory should not make reference to practice deems the academic unfit for the theory that is the foundation of practice. Which means, we have had no academic; no theoretician, since 1970 and Dr E F Codd.
> >> In Bruce's book (and in ERwin) you'd use two clusters, each with one
> >> child, but that requires an interpretation that does not find
> >> an equivalent in the standards. At least, to the best of my
> >> understanding.
> >
> > Your understanding is correct.
> > That interpretation is false.
> > Bruce is an idiot (per reasons explained above, for noticing the problem and NOT resolving it).
> > Do not follow an idiot.
> > Further, the “two clusters with one child each” is a hideous, gross, Normalisation error.
> > Thus the model is invalid; incorrect, fix it.
>
> You could also show us how you would solve the example above in ERwin
> (with IE notation). I do not have an ERwin license, so I can't try it
> myself.
> > As a counter-point, think about UML. Even though it is heavily
> > marketed as a “Standard”, it is not a Standard by any means, because
> > it is (a) grossly incomplete: each modeller adds his own 5 to 10
> > notations to cover the missing bits because he has designed objects or
> > interaction for which no UML notation exists. When a few hundred do
> > that private dance and publish their models, those 400 or 500
> > notations become de facto UML, like it or not. Yes, you and I as
> > purists would reject all that. But whereas I would model it in
> > a genuine modelling notation, and thus resolve the issue, you would
> > stand and argue that UML is broken, that the added notation is
> > invalid.
>
> Well, one thing is asking to fix something that it's just a notational
> glitch that can be easily fixed; "fixing UML" is something on another
> level entirely: I'd not dare ask anything like that.
> > I have updated this doc to reflect the above. In case there remains
> > anything worth discussing on this issue, I have added a page with the
> > Subtypes, and given the Predicates (which are an excellent method of
> > verifying the model, a feedback loop).
> >
> > ____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
>
> Yes, the updated chart looks better. IE notation covers subtyping
> correctly. My only remaining question is the one above.
> RE the added page, looking at the transactions, I think PersonPastime's
> subtypes are not exclusive (the diagram has an X that should not be
> there).
By the way, I have given you two ways of transacting a 1::1-to-n relation.
Happy Easter
Derek
Derek Ignatius Asirvadem
Apr 5, 2021, 1:53:22 AM4/5/21
to
> On Sunday, 4 April 2021 at 08:27:43 UTC+10, Nicola wrote:
> My complaint is not about "generalization hierarchies" per se. It is
> a specific critique on the specific notation used by IDEF1X.
> **That has nothing to do with understanding transactions, or whatever.**
> a specific critique on the specific notation used by IDEF1X.
Well it does. It is fair enough that the academics think in terms of fragments, isolated from the context in which it exists.
But that is not the real world, in which things are integrated, atoms are not fragmented. We do not want to entertain something in theory that is not possible in implementation. A database is a single recovery unit. As long as one is using a genuine SQL platform, one has ACID Transactions. The following Predicates for the Basetype::Subtype relation:
__ Basetype is one of {Subtype1|Subtype2|...} -- Exclusive
____ Cardinality 1::1
__ Basetype is any of {Subtype1|Subtype2|...} -- Non-Exclusive
____ Cardinality 1::1-to-n
are implemented by a Constraint (Declaration in SQL). Transactions are declared Constraints (Methods in UML-speak), that provide ACID (if the SQL Platform provides ACID). They form the Database API.
That [SQL platform] gives us confidence that the implied Database Integrity; the Cardinality of 1::1 or 1::1-to-n is possible, and quite ordinary.
Corollary: it is not possible to implement such Database Integrity on freeware and other mickey mouse program suites (they cannot be called “platforms”), that do not have ACID and fraudulently use “SQL” in the label.
Cheers
Derek
Nicola
Apr 5, 2021, 9:28:43 AM4/5/21
to
On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>> On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
>>
>>
>> Concrete example:
>>
>> - An Employee may be a Consultant;
>> - An Employee may be a Full-Time Employee;
>> - An Employee may be neither a Consultant nor a Full-Time Employee;
>> - An Employee cannot be both a Consultant and a Full-Time Employee.
>
>>
>> - An Employee may be a Consultant;
>> - An Employee may be a Full-Time Employee;
>> - An Employee may be neither a Consultant nor a Full-Time Employee;
>> - An Employee cannot be both a Consultant and a Full-Time Employee.
>
> I fail to see the problem, I must be missing something. Sorry.
>
> Page 4
That captures the requirements correctly, but it introduces an entity
>
> Page 4
(Employee FT_or_C) that does not exist in reality, it is not in the
requirements and, in fact, is not inherently necessary. An IDEF1X model
would have just three entities => IDEF1X is better than your IE by
Occam's Razor. QED
Note that your model, in a larger context, might be a better choice in
some circumstances. But with your modeling language, it's the only one
you can build for the requirements above.
You may counter this, but know in advance that I will not respond,
because for me this matter is settled. The last word is yours!
>> Note, I am not asking you how you would *implement* this situation; only
>> how a data model would look like.
>
> There is a difference in your mind ?
The difference between logical and physical.
> By the way, I have given you two ways of transacting a 1::1-to-n
> relation.
Nicola
Nicola Vitacolonna
Apr 5, 2021, 9:50:56 AM4/5/21
to
>> So, four combinations.
>
> Whoa. What four combinations ??? How can you combine Exclusive with
> Non-Exclusive ???
doesn't matter, though, because the matter is settled for me, as per my
previous post.
>> In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
>
> If you say so. But you are mixing things up: in IDEF1X Notation,
> there is no “Non-Exclusive” Subtyping, there is only
> {Complete|Incomplete}.
a concept. And IDEF1X has not straightforward notation for that.
>> What is marked with ? corresponds to an "incomplete categorization"
>> in IDEF1X terminology.
>
> Ok.
>
>> Using IE notation, how would you model an
>> "incomplete categorization"?
>
> Well, you can’t. Because it does not exist in IE. Because it does
> not exist in reality.
example is just that. Similarly to the above, "incomplete
categorization" is not a notation, it is a concept. And your IE has not
straightforward notation for that.
> Nevertheless, because the IDEF1X notation is inferior, a lower-order
> concept, it can be progressed to a superior, higher-order concept.
> Just get rid of the notion of “incomplete/complete”.
a generalization hierarchy with 1:1-0:1 relationships. While you can do
that, it may not be the most natural or more economical way of modeling
some situations, witness your Employee[Full-Time,Consultant] solution.
Nicola
Nicola
Apr 5, 2021, 10:32:29 AM4/5/21
to
On 2021-04-05, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>> Anyway, I appreciate your own recount of those times, albeit somewhat
>> critical of the sources I have cited. I do not feel qualified to comment
>> on that any further, though.
>
> Hah. You will love the critique I have for the new list of academics,
> above.
Too bad the people you mention, and often insult, are not here to
>> Anyway, I appreciate your own recount of those times, albeit somewhat
>> critical of the sources I have cited. I do not feel qualified to comment
>> on that any further, though.
>
> Hah. You will love the critique I have for the new list of academics,
> above.
provide their point of view. You know, the discussion would be much more
interesting.
>> >> IDEF1X relies heavily upon Chen's shoulders.
>> >
>> > Nonsense. Give one example, one article.
>>
>
> Yes, it is written.
>
> So what, do you believe everything that is written ?
Never. Not by you, either :-)
> Yes, it is written.
>
> So what, do you believe everything that is written ?
Nicola
Nicola
Apr 5, 2021, 2:48:54 PM4/5/21
to
On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>> On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
>>
>>
>> Concrete example:
>>
>> - An Employee may be a Consultant;
>> - An Employee may be a Full-Time Employee;
>> - An Employee may be neither a Consultant nor a Full-Time Employee;
>> - An Employee cannot be both a Consultant and a Full-Time Employee.
>
>>
>> - An Employee may be a Consultant;
>> - An Employee may be a Full-Time Employee;
>> - An Employee may be neither a Consultant nor a Full-Time Employee;
>> - An Employee cannot be both a Consultant and a Full-Time Employee.
>
> I fail to see the problem, I must be missing something. Sorry.
>
> Page 4
This is my comparative assessment of IE vs IDEF1X notation, re
>
> Page 4
generalization:
https://jirafeau.net/f.php?h=1mnluFoq
Feel free to add your comments, reuse as you see fit, or put on your
site.
Nicola
Derek Ignatius Asirvadem
Apr 7, 2021, 5:51:17 AM4/7/21
to
> On Monday, 5 April 2021 at 23:28:43 UTC+10, Nicola wrote:
> > On 2021-04-05, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> >> Anyway, I appreciate your own recount of those times, albeit somewhat
> >> critical of the sources I have cited. I do not feel qualified to comment
> >> on that any further, though.
> >
> > Hah. You will love the critique I have for the new list of academics,
> > above.
>
> Too bad the people you mention, and often insult, are not here to
> provide their point of view. You know, the discussion would be much more
> interesting.
Not really. The slaves of the “people I mention”, as well as of the “sources you have cited” post in this forum, so there is no question that their fetid legacy lives on in spirit. They are not here in person, true, but they and their legacy are here, destroying science, and hammering anyone who does not toe the communist party line. It is a protected space for academics.
> > On 2021-04-05, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> >> Anyway, I appreciate your own recount of those times, albeit somewhat
> >> critical of the sources I have cited. I do not feel qualified to comment
> >> on that any further, though.
> >
> > Hah. You will love the critique I have for the new list of academics,
> > above.
>
> Too bad the people you mention, and often insult, are not here to
> provide their point of view. You know, the discussion would be much more
> interesting.
If you notice the interaction in this forum over the last 15 years, I am the only one who rejects the insanity and takes them on, point by laboured point. I too, did not invent the science, I stand on the shoulders of Science (as defined 350BC to 1911, when the destruction commenced) and Codd, I too, am acting in that spirit, a slave of that system.
So what we have here is the the great war between sanity and insanity, being played out by second generation slaves. It used to be interesting when the golum army was active, but over the years, as O destroyed each of them, they have gone quiet, their only remaining weapon ad hominem, which advertises their position of total loser.
The discussion /was/ interesting. But in the sense of resolution, after the battle is over and the issue has been closed by me, there is not the academic Middle to keep debating, I have Excluded it.
It is with some gratitude that I welcome you, as leaving that crowd, and attempting to cross the great divide into reality (we will have to define that now). But as evidenced, it is slow, moving in fits and starts, often not resolving the issue discussed. And although you are trying hard to grow out of the academic mindset of non-reality, when cornered, you fall back into it.
> insult
Sure, the tone might sometimes be insulting, it is very hard to discuss an idiotic concept without calling it an idiotic concept. But I take pains to ensure the charge is clear. If you have noticed any insult that does not have an underlying charge, please let me know.
I do not retract my insults. You are free to protect the mentally ill; the deranged; the drooling idiots; the purposely evil saboteurs, who are established as academics, from normal humans. You have to decide between your loyalty to freaky academia and the truth.
One the one hand academics argue that an argument from authority is poor, but hysterically, hypocritically, they venerate published academics, regardless of how idiotic their papers are. I don’t hold imbeciles in positions of authority. Genuine authorities rule, and teach. None of you guys do the smallest ruling or tiniest teaching of the science, all of you guys make rulings on anti-Relational filth, and teach anti-Relational pig poop as “Relational”. You want nice treatment ? Go to a brothel. From the real world, you will get disrespect, insults.
What about the fact that for FIFTY years you have come up with nothing, while ranting and railing and caterwauling that you’ve producing the cutting edge of Jello. That is an insult to the undamaged intellect. You insult us, we will insult you back.
Respect is something that is earned, not something that is freely given. You want respect, sure, DO SOMETHING RESPECTABLE. Come up with one thing that articulates or progresses the /RM/, come up with one academic that attacks the fifty years worth of anti-Relational filth. Zero. We get only upset that we did not toe the academic line and genuflect to your imbeciles that never did anything, but tell great stories to interviewers.
Now you are the single exception. Please do not ask me to follow your lead and genuflect to imbecility. Come across the chasm and join me in the real world. Do not run back the safety, the reinforced bastion of insanity, at war with Reality.
> >> >> IDEF1X relies heavily upon Chen's shoulders.
> >> >
> >> > Nonsense. Give one example, one article.
> >>
> >> FIPS 184, Background section:
> >
> > Yes, it is written.
> >
> > So what, do you believe everything that is written ?
You, an established academic, capable of examining these things, did not answer this:
> >>
> >> FIPS 184, Background section:
> >
> > Yes, it is written.
> >
> > So what, do you believe everything that is written ?
> > When I said “article” I did not mean a report somewhere, I meant a concept, that is recognisable.
> > a. Name one thing, a method or rule or whatever, from the Chen ERD, that exists in IDEF1X.
> > b. Name one thing FROM the /RM/ that Chen has in his ERD.
What is written is lies.
[b] Therefore there is nothing in ERD that can be identified as Relational, not one skerrick.
c. Therefore given that (i) there is nothing Relational in ERD, (ii) the /RM/ has demands that ERD does not supply, (iii) that IDEF1X does supply, the use of ERD by all academics (except possibly you), is an anti-Relational act. Consistent with the freaks suppressing the /RM/, in order to promote their primitive concepts as the /RM/,
> > So what, do you believe everything that is written ?
>
> Never. Not by you, either :-)
The problem with academics is, they believe what the have written, they don’t wait for testing or peer reviews. “Here, MyLittlePony has rainbow mane, you can’t prove that that is false, therefore it is true. QED.” And then if anyone disagrees, they refuse to engage. “If you don’t believe that MyLittlePony has a rainbow mane, you are anti-semitic or homophobic or worse. I QED-ed you.”
It is a game for small children, devoid of science. But played all the time, by academics, presenting that filth as “science”.
> > On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> >> On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
> >>
> >> Concrete example:
> >>
> >> - An Employee may be a Consultant;
> >> - An Employee may be a Full-Time Employee;
> >> - An Employee may be neither a Consultant nor a Full-Time Employee;
> >> - An Employee cannot be both a Consultant and a Full-Time Employee.
> >
> > I fail to see the problem, I must be missing something. Sorry.
> >
> > Page 4
>
> That captures the requirements correctly, but it introduces an entity
> (Employee FT_or_C) that does not exist in reality, it is not in the
> requirements and, in fact, is not inherently necessary. An IDEF1X model
> would have just three entities => IDEF1X is better than your IE by
> Occam's Razor. QED
God help me. By virtue of the evidence, you had an agenda from the outset, which was not declared. Then you played a stupid game, no doubt Masters Level, that I was not aware of (I thought you were engaged in honest technical discussion), in order to lead me into a “trap”, and once there, you gleefully declare that the “trap” worked.
> (Employee FT_or_C) that does not exist in reality, it is not in the
> requirements and, in fact, is not inherently necessary. An IDEF1X model
> would have just three entities => IDEF1X is better than your IE by
> Occam's Razor. QED
Ok, I grant, in the confines of your mind, you “won”. Ok, your academic programming is heavy and deep, and much as you tried to understand normal logic, you could not, you reverted to the mindless, logic-less, academic mindset. You “win” but you learned nothing.
Let’s try again, in the vain hope that honesty, your conscience motivates you to step outside your Masters level trick question.
> >> Concrete example:
Pffft. Nothing concrete about it. It is a concept level, simple Logic, question. Calling it “concrete” merely sets up the deceit for the “trap”. Called an ass a horse does not transform the ass into a horse, it only deems the person as dishonest at best, or a deranged evil “scientist” at worst.
Concept level question:
> >> - An Employee may be a Consultant;
> >> - An Employee may be a Full-Time Employee;
> >> - An Employee may be neither a Consultant nor a Full-Time Employee;
> >> - An Employee cannot be both a Consultant and a Full-Time Employee.
> >
> > I fail to see the problem, I must be missing something. Sorry.
> >
> > Page 4
> That captures the requirements correctly, but it introduces an entity
> (Employee FT_or_C) that does not exist in reality,
Your notion of “science” is in fact Materialism; Modernism, which artificially excludes science (Logic; the Four Laws; Causality; Hierarchy; Integration) that we have had from 350BC to 1911, such that you **van** pick out fragments of reality and treat them in isolation, divorced from their context and meaning (remember, you are learning about bringing meaning into the picture, very slowly, but you will not admit that which has excised meaning).
Thus the academic [your] sense of reality is perverted. It is (a) in denial of reality, and 9) a concoction, that becomes a collective agreement, widely cited, a “reality”. It is very narrow and self-serving, which is why people who are not crippled by the academic mindset, who model reality, come up with and use pedestrian methods for forty years, that you alone from academia are finding out about today.
Thus I, not being crippled; or ham-strung; or fed with pig poo, that is, relying only on undamaged science, which includes unperverted Logic, submit that Employee FT_or_C is a Logical Fact in Reality. Yes, it is not material at this silly conceptual level, so you being limited to Materialism, will be blind to the facts of reality.
> it is not in the requirements
1. The requirements for examples; class problems; and even Masters level tests, often leave something out (otherwise getting the answer would be a clerical, not technical, task). Check out the three ERDs that OP was labouring over. The solution is to *DETERMINE* the existence of FACTS that the entities in the ERD depend upon but were excluded (due to purposeful set up of a classroom problem, or criminal insanity [anyone giving those problems as solvable via ERD, as a part of Relational Data Modelling is criminally insane] ).
It is rather common in Data Modelling of reality, to determine the existence of such Facts which are not obvious to the novice. But academics evidently are blind to such: they concoct a “reality” and deny that reality exists. Therefore nothing that they produce can be used in reality. Eg. nothing since 1970, since Codd. If you challenge this, name one article.
2. If the example were a real one (exists in reality) as opposed to the classroom problem, then the producer of the test is an academic who is blind to reality, the Facts that exist but have no Matter (Materialism) to “sense” their existence.
3. But here we have a deceit, the typical academic Straw Man kind, the academic presents a silly classroom problem as “concrete”. And forces the End of Story. Precisely because he dare not go further, because going further will destroy his smugness, his glee, his “victory”. And after forcing a premature and anti-scientific termination to the study of the article he alleges to be studying, he prematurely sings out a “QED”. You asked a Q with an E and got a D.
> and, in fact, is not inherently necessary. An IDEF1X model
> would have just three entities => IDEF1X is better than your IE by
> Occam's Razor. QED
> Note that your model, in a larger context, might be a better choice in
> some circumstances.
Why is it that you attempt optimisation at the conceptual stage ? While making sure that the doctrine of **NOT** optimising at the early stages is taught ? Gee, an “extra” entity; an “extra” index; an “extra” INSERT. Hilarious. You do not have four wheels on the car yet, but you insist that wheel number three is “extra”.
Why can you not see, that I have done this a thousand times, in Reality, in real world models that are implemented, and after about the third time of optimising the four-table model into the three-table model (not resolved but let’s not get distracted) and then reverting to the four-table model, I the real world practitioner, have determined that it is better to implement the plain Facts; the plain Logic, that never need changes, rather than the optimised Facts that always need change.
Let’s see what happens if we progress the conceptual model falsely labelled “concrete” in the direction of concrete, just a little bit. Let’s see, what can we come up with is we contemplate the three concepts in Reality, with or without the establishment of the Fact of Employment. I hope you do not mind if I do not labour over each and every increment. I have added to page 4.
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
> But with your modeling language, it's the only one
> you can build for the requirements above.
> You may counter this, but know in advance that I will not respond,
> because for me this matter is settled.
> The last word is yours!
Please, define your problem in technical terms, as a definition (even Incomplete/“Partial” appears to be misunderstood, but I cannot confirm/deny that because you do not have a definition).
As detailed, do not mix mutually exclusive classes, such as IDEF1X **and** IEEE notation for Subtypes.
It appears to me, that you have taken up IDEF1X (hurrah, forty years late but hurrah), over ERD (another hurrah), but you are stuck in that academic mindset of defending academics; of promoting their false authority. Instead of taking up the real world practice of IDEF1X usage, you have taken up the original version (which is forty years out-of-date, and parts have been rejected by practitioners from day one), plus a superficial academic critique that you know to be false but you trumpet it anyway.
The solution might be, to trust a theoretically solid practitioner, instead of taking the academic route (IDEF1X notation for subtypes) which is known to fail by everyone except academics.
> >> Note, I am not asking you how you would *implement* this situation; only
> >> how a data model would look like.
> >
> > There is a difference in your mind ?
>
> The difference between logical and physical.
That difference is contrived. It is absurd. You turn it OFF and ON when convenient, as per the evidence. It is incoherent. Further, academics have no clue what LOGICAL means, but that should be a separate thread.
>
> The difference between logical and physical.
> your modeling language
> your IE
Pardon me. As evidenced in the ERwin Methods Guide, IE was established and known long before IDEF1X and the idiotic ERD came along. It belongs to IEEE, an international Standards body, it does not belong to me. I just use the Standard.
The language (semantics) is FOPC. As articulated by Dr E F Codd in his /RM/. And his RA. And articulated in IDEF1X.
IDEF1X lacks the definition of IEEE subtypes that we had prior. Get over it.
Last, again, please define your thus-far undefined and incoherent problem, so that we can resolve it. Or at least agree that there is a problem. Terminating the engagement is anti-science, anti-transparent. I lose nothing, you lose your credibility.
I will get to the other posts over the next few days.
Cheers
Derek
Derek Ignatius Asirvadem
Apr 7, 2021, 6:31:56 AM4/7/21
to
Nicola
> On Tuesday, 6 April 2021 at 04:48:54 UTC+10, Nicola wrote:
> > On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> >> On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
> >>
> >> Concrete example:
> >>
> >> - An Employee may be a Consultant;
> >> - An Employee may be a Full-Time Employee;
> >> - An Employee may be neither a Consultant nor a Full-Time Employee;
> >> - An Employee cannot be both a Consultant and a Full-Time Employee.
> >
> > I fail to see the problem, I must be missing something. Sorry.
> >
> > Page 4
>
> This is my comparative assessment of IE vs IDEF1X notation, re
> generalization:
>
> https://jirafeau.net/f.php?h=1mnluFoq
There is a problem with that. Actually two. First, let me confirm that my docs are in the public domain, and you are free to use them. But a copyright notice generally means “use as is” and “if used, you must include the copyright notice”. In these days of the internet, that means, most people refer to the doc. Cut-paste is frowned upon, because (a) it can be misused, and (b) the such content is removed from the context.
In future, please feel free to use my docs and to refer to them, please do not-cut-paste.
The second problem is, you have performed a nice Reverse Straw Man. This damages you more than it does me. I have no comment whatsoever re the matter (material) in your doc. I am only addressing the use of my graphics under your headings, your context. I am not saying you are dishonest (a Straw Man is always dishonest), but that in the Modern “science” using the Straw Man is a well established method for “argumentation”, and you are schooled in it; indoctrinated in it, and you are using it unconsciously.
Think about this. In reality, a horse exists. There are pictures of horses. You have a concept, which is an abstraction, not real, it does not exist in reality (I am explaining something, not commenting on your proposition). Let’s call it ABCDEF. So you write it up, and present ABCDEF-1; ABCDEF-2; etc. And under each section, you attach a picture of a different horse.
You might have mulled over thee ABCDEF for years, it might be very “real” to you, but it does not exist. It is a Reverse Straw Man because you have substituted something real for something false (whereas the missionary Straw Man substitutes something false for something real, and then burns it). Because the content that has been substituted belongs to me, it is I who has the task of burning it. Sorry.
You cannot use good graphics under those headings, it is a mis-representation. That is all. Please feel free to re-issue your doc with references [not cut-pastes] to my doc.
This is what respectful correction looks like:
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20Non-Problem%20Proposal%20-%20Response.pdf
> Feel free to add your comments,
If you do not mind, I would rather not. I am very happy to engage with you on all subject matter related to Relational data science, and I would like to maintain that friendliness. I am happy to fulfil your requests, whether answering questions, or providing decent commentary. But your doc, what you are trying to say, is incoherent. Right now there is no problem in the use of IDEF1X, but given your definition thus far, you appear to have created one, and a complex solution to go with the non-problem. I can’t say for sure because the definition is poor.
Further, your intent, the final goal, your agenda, is not declared (but implied).
Therefore I would ask you to excuse me from that request, this one time.
If you care to progress the work to the point of making a coherent proposal, I would be happy to comment. Obviously, prior to that, we can discuss it in this thread, to afford that progress.
Cheers
Derek
> On Tuesday, 6 April 2021 at 04:48:54 UTC+10, Nicola wrote:
> > On 2021-04-04, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> >> On Sunday, 4 April 2021 at 20:50:43 UTC+10, Nicola wrote:
> >>
> >> Concrete example:
> >>
> >> - An Employee may be a Consultant;
> >> - An Employee may be a Full-Time Employee;
> >> - An Employee may be neither a Consultant nor a Full-Time Employee;
> >> - An Employee cannot be both a Consultant and a Full-Time Employee.
> >
> > I fail to see the problem, I must be missing something. Sorry.
> >
> > Page 4
>
> This is my comparative assessment of IE vs IDEF1X notation, re
> generalization:
>
> https://jirafeau.net/f.php?h=1mnluFoq
In future, please feel free to use my docs and to refer to them, please do not-cut-paste.
The second problem is, you have performed a nice Reverse Straw Man. This damages you more than it does me. I have no comment whatsoever re the matter (material) in your doc. I am only addressing the use of my graphics under your headings, your context. I am not saying you are dishonest (a Straw Man is always dishonest), but that in the Modern “science” using the Straw Man is a well established method for “argumentation”, and you are schooled in it; indoctrinated in it, and you are using it unconsciously.
Think about this. In reality, a horse exists. There are pictures of horses. You have a concept, which is an abstraction, not real, it does not exist in reality (I am explaining something, not commenting on your proposition). Let’s call it ABCDEF. So you write it up, and present ABCDEF-1; ABCDEF-2; etc. And under each section, you attach a picture of a different horse.
You might have mulled over thee ABCDEF for years, it might be very “real” to you, but it does not exist. It is a Reverse Straw Man because you have substituted something real for something false (whereas the missionary Straw Man substitutes something false for something real, and then burns it). Because the content that has been substituted belongs to me, it is I who has the task of burning it. Sorry.
You cannot use good graphics under those headings, it is a mis-representation. That is all. Please feel free to re-issue your doc with references [not cut-pastes] to my doc.
This is what respectful correction looks like:
____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20Non-Problem%20Proposal%20-%20Response.pdf
> Feel free to add your comments,
Further, your intent, the final goal, your agenda, is not declared (but implied).
Therefore I would ask you to excuse me from that request, this one time.
If you care to progress the work to the point of making a coherent proposal, I would be happy to comment. Obviously, prior to that, we can discuss it in this thread, to afford that progress.
Cheers
Derek
Nicola
Apr 7, 2021, 2:51:55 PM4/7/21
to
On 2021-04-07, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> Nicola
> The second problem is, you have performed a nice Reverse Straw Man.
I think that the misrepresentation is more in the eyes on the beholder.
Anyway, here is a revised document (with references this time):
https://jirafeau.net/f.php?h=2NbPmq6L
What I see is that both notations have deficiencies, which are easily
fixed. Once that is done, they become completely equivalent. IE's only
advantage is being vastly more popular.
Nicola
> Nicola
>>
>> This is my comparative assessment of IE vs IDEF1X notation, re
>> generalization:
>>
>> https://jirafeau.net/f.php?h=1mnluFoq
>
> There is a problem with that. Actually two.
> [...]
>> This is my comparative assessment of IE vs IDEF1X notation, re
>> generalization:
>>
>> https://jirafeau.net/f.php?h=1mnluFoq
>
> There is a problem with that. Actually two.
> In future, please feel free to use my docs and to refer to them,
> please do not-cut-paste.
My apologies. That document is not online any more.
> please do not-cut-paste.
> The second problem is, you have performed a nice Reverse Straw Man.
Anyway, here is a revised document (with references this time):
https://jirafeau.net/f.php?h=2NbPmq6L
What I see is that both notations have deficiencies, which are easily
fixed. Once that is done, they become completely equivalent. IE's only
advantage is being vastly more popular.
Nicola
Nicola
Apr 7, 2021, 3:06:08 PM4/7/21
to
On 2021-04-07, Nicola <nic...@nohost.org> wrote:
> Anyway, here is a revised document (with references this time):
Fixed a typo:
> Anyway, here is a revised document (with references this time):
https://jirafeau.net/f.php?h=1WA2Cs0R
Nicola
Derek Ignatius Asirvadem
Apr 7, 2021, 6:15:47 PM4/7/21
to
> On Thursday, 8 April 2021 at 04:51:55 UTC+10, Nicola wrote:
> > On 2021-04-07, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> > Nicola
> >>
> >> This is my comparative assessment of IE vs IDEF1X notation, re
> >> generalization:
> >>
> > On 2021-04-07, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> > Nicola
> >>
> >> This is my comparative assessment of IE vs IDEF1X notation, re
> >> generalization:
> >>
> > There is a problem with that. Actually two.
> > [...]
>
> > In future, please feel free to use my docs and to refer to them,
> > please do not-cut-paste.
>
> My apologies. That document is not online any more.
No worries.
> > [...]
>
> > In future, please feel free to use my docs and to refer to them,
> > please do not-cut-paste.
>
> My apologies. That document is not online any more.
> > The second problem is, you have performed a nice Reverse Straw Man.
> I think that the misrepresentation is more in the eyes on the beholder.
> Anyway, here is a revised document (with references this time):
>
> https://jirafeau.net/f.php?h=2NbPmq6L
>
> What I see is that both notations have deficiencies, which are easily
> fixed. Once that is done, they become completely equivalent. IE's only
> advantage is being vastly more popular.
That is a new presentation. Worthy of discussion. Certainly, you may have insights as to why that is so, how you reach that conclusion, but that is unknown to me, you have not discussed it here, so I can neither agree nor disagree.
>
> What I see is that both notations have deficiencies, which are easily
> fixed. Once that is done, they become completely equivalent. IE's only
> advantage is being vastly more popular.
This post does not respond to that, only to the content in the revised the doc.
0. Intro. Ok, now I know the purpose. Comments are relative to that declaration.
a. Re links. It seems in each instance, the entire text box is “hot”, not just the words in “hot” colour and underlined. Is that what you intend ? It also makes the text in the text box out os reach (eg. for copy-paste).
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 ?
c. AK. The order of the attributes has great significance in many areas. In the context of academic data modelling, ok, it has to be given before the Physical. In real life, it is given whenever more than one attribute is defined for the AK. ERwin of course has to demand it, and it does. The mistake is in the ERwin Methods Guide, where the sequence is *not* given and therefore suggests that it is not always required. That is false.
d. Cardinality. The expected (universally understood) notation is:
__ Parent::Child
__ 1::0-to-1 -- eg. optional attribute
__ 1::0-or-1 -- equally understood
This is new:
__ 1:1-0:1
1. Other than the minor issues above, I agree, that is the correct IDEF1X rendition of [Optional Attribute (Not Subtype) ]. But ...
There is no such thing as “Subtype” in IDEF1X. Use “generalisation” and “category” throughout, to be faithful to the IDEF1X terminology.
2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X. I suggest remove the page. Use “generalisation” and “category” throughout, to be faithful to the IDEF1X terminology.
(Subtype; Exclusive, are IEEE terms. Basetype; Non-Exclusive are my corrections to incorrect ERwin terms.)
In a technical doc that recasts IEEE into IDEF1X, I would use only IDEF1X terminology. If you have to make reference to IEEE terms, then label it as such.
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].
a. You are attempting to use “Partial” as a synonym for Incomplete (not the other way around).
- Why introduce yet another label ? For what purpose ? Is Incomplete not definitive enough ?
- “Partial” is not adequately defined (“not every” does not indicate if 1 is the minimum)
b. I don’t agree with your definition (yellow panel in the middle). The points are too many, here are a few:
- “is-a” is an ambiguous term, not related to the /RM/ or IDEF1X. If you use it, it needs to be defined.
--- (The IEEE meaning is strictly {Exclusive|Non-Exclusive} = {is one of|is any of}. Some people make it more strict {is exactly one of|is at least one of} but I declare that that is superfluous, the former is easily understood.)
- declarations SUCH AS “business party and a customer must be treated as a single logical unit” are valid for IEEE Subtypes, I don’t see how they apply to IDEF1X Categories.
- in the example, the declaration “business party and a customer must be treated as a single logical unit” violates (a) logic, and (b) IDEF1X Categories.
--- “when the business part[y] is a customer” is contrived.
- the declaration “customer and business party are the same entity” is patently false: the model shows two distinct entities.
- Finally, a Category with a single member is a gross Normalisation error, it is corrected by making it an Optional Attribute.
--- Thus the DM on the left is false (impossible, if being true to IDEF1X terminology; false as detailed above; gross error in Normalisation terms).
--- The DM or the right is the only correct one
- (This may pivot on your understanding of the minimum membership for an Incomplete Category.)
- re “In IE notation, only the model on the right is available” is technically inaccurate. No, the model on the left is false, it fails logic (semantics). The model on the right is not an IE rendition, it is a logically sound model, that happens to be rendered in IEEE.
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.
d. Overall for the page. My advice would be to define [Incomplete Categorisation] in generic and definitive terms, using IDEF1X terminology only, THEN draw some comparison to IEEE (if you must, vis-a-vis “recast”). Rather than what you are doing, which is assuming the reader has certain understandings and using mixed IDEF1X/IEEE terms. If you do use IEEE terms, then you must define them.
4-Non-Exclusive Subtyping
a. There is no such thing as “Non-Exclusive Subtyping” in IDEF1X. Since you are trying to recast “Non-Exclusive Subtyping” in IDEF1X, use IDEF1X terms, and put the IEEE terms in double quotes.
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.
b. This issue may be better discussed in open comms, rather than as an article of issue on this page in this doc. Eg. I don’t accept with “Clusters [Categories] cannot be interpreted individually, but only as a whole” because I don’t know what you mean. On the face of it, it seems false: I can definitely interpret the members of a [IEEE Subtype] Cluster individually.
c. The phrase “translated into predicates” raises a red flag and really grates (I thought you understand Predicates). (I am not correcting your English.) There is no “translation”. Every DM is a graphic representation of the Predicates, every DM is semantic. So the graph can be stated in Predicates; the Predicates are stated in the graph. Thus “translate” does not apply, it is merely reading THE ONE MODEL in one language (graphic; visual; semantic) or the other (predicates; semantic).
4-Partial Specialization with Mutually Exclusive Child Entities
(No argument with the use of “Exclusive” here)
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.
c. So I would say, define [Incomplete Categorisation] in IDEF1X terms first. And that stands as a reference. THEN define what you are trying to say here, as a progression. I don’t know what that is, so I can’t help you do that articulation.
d. Re the DMs alone, ie. you have looked after [b][c], and the DMs arrive in a reasonable progression. The model below is illegal, because a Category with a single member is a Normalisation error.
e. “Additional entity; additional insert; additional index” is not appropriate considerations at this level of definition. They are performance issues that yes, must be evaluated long before the physical stage, but not at this conceptual stage.
f. Re “to model the situation above using IE notation”, well show the model (in the correct sequence as per [b][c]. It appears you are trying to say that there is a problem with the IEEE notation, so show it.
--- Alternately, explain precisely what “Incomplete Categorisation with Mutually Exclusive Child Entities” means, and I will add it to my Subtype doc, such that your doc remains IDEF1X-faithful, and my doc has a more complete set in IEEE notation, for reference.
g. The new symbol.
Text box on right. I don’t understand how you can apply “Incomplete specialisation [Categorisation]” which is a valid IDEF1X term, to the IEEE classifications, let alone to a specific IEEE symbol, which has a defined meaning totally unrelated to the IDEF1X classifications.
- Further, I do not understand how it is “the same meaning as” the IDEF1X Incomplete Category symbol.
Cheers
Derek
Derek Ignatius Asirvadem
Apr 7, 2021, 8:54:32 PM4/7/21
to
> On Monday, 5 April 2021 at 23:50:56 UTC+10, Nicola Vitacolonna wrote:
> >> So, four combinations.
> >
> > Whoa. What four combinations ??? How can you combine Exclusive with
> > Non-Exclusive ???
>
> I thought that was clear enough, but it mudded the waters instead. It
> doesn't matter, though, because the matter is settled for me, as per my
> previous post.
That response is probably obsolete, please continue the exchange.
How does one COMBINE opposites ??? Naming it “orthogonal” may allow a 2 x 2 grid, but the content would be meaningless. Eg. if you are trying to do something along the lines of the UNCORRECTED ERwin Mthods Guide p69, no, I have corrected it and you have accepted it.
> >> In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
> >
It is first a concept, absolutely.
It is a concept in IEEE, which existed prior to IDEF1X.
It is a concept outside IDEF1X.
The concept has a notation. (In the same way that a concept has a word.)
The IEEE concept has an IEEE notation.
It is both a concept and a notation.
How can that be denied ???
> And IDEF1X has not straightforward notation for that.
The concept is outside IDEF1X.
It is not that it “has not a straightforward notation”, it has no notation whatsoever for the concept that it does not have.
> >> What is marked with ? corresponds to an "incomplete categorization"
> >> in IDEF1X terminology.
> >
> > Ok.
I am taking the IEEE mindset. If you wish to understand that, and you have to, in order to mount an argument against it, try to understand it. Ask questions. Do not merely perceive the IEEE mindset from a fixed IDEF1X concept-and-notation mindset, because that prevents understanding.
So what am I trying to say in this context ? I have already stated, I cannot understand your cross-hatch pseudo-tabulation. I am trying to understand this thing [?]. You said it “corresponds to an "incomplete categorization" in IDEF1X terminology”. It can’t. Because that thing [incomplete categorization] does not exist in IEEE. It is foreign (not merely “orthogonal”). Stop there and agree/disagree.
----
Now for the next point, after the previous point has been addressed. I say that IEEE does not have [incomplete categorization] because it does not exist in reality. That is not a denial of reality (it is, only if you provide an example of such from reality). A mere declaration will not suffice.
So why do I say such thing, how can it be true ? Because the IDEF1X [incomplete categorization] is not defined, the definition given is not technical, not Relational, not a Predicate that can be implemented (recall, the foundation sequence is: FOPC; /RM/; Modelling; SQL). It is merely “not Complete”.
//For understanding, virtually all Categories, except the most rudimentary (such as Male/Female), would be Incomplete, because they will never be completed, they can be extended in the future. Thus {Complete|Incomplete} fall into the category of meaningless. Thus no one uses it. And particularly since the IEEE Subtypes existed prior, we have no reason to take up this meaningless new categorisation.//
Now if you have a better understanding of IDEF1X[incomplete categorization], or a better definition, please provide.
> My Employee[Full-Time,Consultant]
> example is just that.
No. It is a classroom exercise at the conceptual level only, falsely labelled “concrete”. And then elevated to the status of an universal, by you alone. I have already rejected the requirement as being incomplete, and invalid in terms of providing an example of a generic problem. Yes of course it is IDEF1X[Incomplete] because you made it so, it is your example.
//The burden of proof is on the proposer; the prosecution, not on the defence. It is not for me to disprove your proposal, it is for you to prove it, independently.//
> Similarly to the above, "incomplete
> categorization" is not a notation, it is a concept.
No. As explained above, it is an [IDEF1X] concept first, and an [IDEF1X] notation second. Foreign to IEEE concepts and notation.
> And your IE has not
> straightforward notation for that.
Well, IEEE has NO notation for it, because IEEE has NO concept for it. It is foreign. You can’t fit a square peg into a round hole.
Now if you are trying to say that there is something lacking in the IEEE concepts-and-notation, just explain it, without using IDEF1X concepts-and-notation. If you use your Employee{Full-Time|Consultant} example again, recall I have already proved [not my job] that it is not complete enough to consider as a problem; a lack. The notion that it can be shown in some other notation (eg. Swahili or Chinese pictographs) is irrelevant, it does not prove a lack in the IEEE concepts-and-notation.
Analogy. In the real world, we have only Male/Female, anyone who denies their physical reality is insane. It does not matter what they say they are because they are insane. When a man goes to a doctor and asks for a hysterectomy, he gets treated for insanity, not for a hysterectomy.
Now the insane person comes around, and gleefully declares that his/her/its/shits list of concocted “genders” is better because it has more members and it is forever changing and it will never be complete. That even Fakebook has 104 Genders listed. My response is to give it a sedative and a warm bed. Your response is to declare that there is something lacking in the {Male|Female} set.
Another one. The rag-and-bone man comes along and says he has a child with both male and female organs. Ok, no problem. But then he says it violates the {Male|Female} set. No, it does not, his child is a deformed freak, 0.0001% of the population, due to his wife being his niece. The deformed; the abnormal, prove nothing about the normal, the only thing they prove is about the abnormal.
So if you are trying to say that IEEE concepts-and-notation is lacking in some way, say it squarely, in technical and IEEE terms, not in Swahili; Chinese; insane; or IDEF1X terms.
> > Nevertheless, because the IDEF1X notation is inferior, a lower-order
> > concept, it can be progressed to a superior, higher-order concept.
> > Just get rid of the notion of “incomplete/complete”.
>
> Without such a notion, you are forced to model "incompleteness" of
> a generalization hierarchy with 1:1-0:1 relationships. While you can do
> that, it may not be the most natural or more economical way of modeling
> some situations, witness your Employee[Full-Time,Consultant] solution.
I think that is mostly answered. The bits remaining are:
- nothing is “forced”, that is emotional nonsense
- there is no “incompleteness” or incompleteness in IEEE concepts-and-notation
- if you explain how IEEE IEEE concepts-and-notation is lacking, I would be happy to respond
Yes, I agree IDEF1X concepts-and-notation is broken. That is why I have never used it, that is why I have never seen anyone else use it. (Except you, but you are an academic purist, trying to use something that was deemed obsolete and irrelevant forty years ago, and resisting the actual use by practitioners during those forty years.) No, I will not help you improve or fix that broken thing, because it is obsolete and irrelevant.
Whereas I am very interested in any genuine problem with the IEEE concepts-and-notation. I will help you sort it out, and certainly if an amendment is necessary, I will assist in defining such.
(I don’t think it likely, because it has stood for forty years since IDEF1X came out, and no one has raised such. You are new to this, so it is likely a matter of understanding.)
Cheers
Derek
> > On 2021-04-05, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> >> There are two orthogonal aspects in a generalization hierarchy:
> >
> >> There are two orthogonal aspects in a generalization hierarchy:
> >
> > I don’t care for the title, it is some academic artefact, of relevance
> > to academia only. I know that what you mean is the Basetype-Subtype
> > clusters that we have had in databases, decades before those papers
> > were written. And again, I am very interested in modelling data the
> > way it actually exists, not limited to any perception.
> >
> > Further, I accept wholeheartedly that the correct observation of genus
> > vs species is an essential part of genuine Analysis, here Data
> > Analysis.
> >
> > to academia only. I know that what you mean is the Basetype-Subtype
> > clusters that we have had in databases, decades before those papers
> > were written. And again, I am very interested in modelling data the
> > way it actually exists, not limited to any perception.
> >
> > Further, I accept wholeheartedly that the correct observation of genus
> > vs species is an essential part of genuine Analysis, here Data
> > Analysis.
> >
> >> 1. are the subtype mutually exclusive or not?
> >
> >
> > Ok. One category is. Because they are Exclusive, we [normal people,
> > not prone to reading academic fantasies, unless forced] call the
> > category:
> > ____Exclusive
> > In Logic, that is an XOR Gate [Discriminator] on the Basetype that
> > identifies the single Subtype. It is Semantic (examples in the
> > progressing doc).
> >
> > The remaining category, since it is not Exclusive, and certainly not
> > inclusive, is called:
> > ____Non-Exclusive
> > The Subtypes are not mutually exclusive. There is no Discriminator.
> > Typically, the Basetype has more than one [but not many or all]
> > Subtypes. Note that each Basetype-Subtype pair must be perceived as
> > a logical row.
> >
> >> 2. is every instance [row] of the parent entity an instance [row] of
> > not prone to reading academic fantasies, unless forced] call the
> > category:
> > ____Exclusive
> > In Logic, that is an XOR Gate [Discriminator] on the Basetype that
> > identifies the single Subtype. It is Semantic (examples in the
> > progressing doc).
> >
> > The remaining category, since it is not Exclusive, and certainly not
> > inclusive, is called:
> > ____Non-Exclusive
> > The Subtypes are not mutually exclusive. There is no Discriminator.
> > Typically, the Basetype has more than one [but not many or all]
> > Subtypes. Note that each Basetype-Subtype pair must be perceived as
> > a logical row.
> >
> >> some child entity ("subtyping" in your terminology), or not?
> >
> >
> > For Exclusive: yes, exactly one Subtype row.
> > For Non-Exclusive: yes, one or more Subtype rows.
>
> No, the distinction I have made is between subtyping/not subtyping.
I do not see how. Your stated heading is “two orthogonal aspects in a generalization hierarchy”. Where is this “distinction between subtyping/not subtyping” ?
> > For Non-Exclusive: yes, one or more Subtype rows.
>
> No, the distinction I have made is between subtyping/not subtyping.
> >> So, four combinations.
> >
> > Whoa. What four combinations ??? How can you combine Exclusive with
> > Non-Exclusive ???
>
> I thought that was clear enough, but it mudded the waters instead. It
> doesn't matter, though, because the matter is settled for me, as per my
> previous post.
How does one COMBINE opposites ??? Naming it “orthogonal” may allow a 2 x 2 grid, but the content would be meaningless. Eg. if you are trying to do something along the lines of the UNCORRECTED ERwin Mthods Guide p69, no, I have corrected it and you have accepted it.
> >> In IDEF1X notation, "non-exclusive subtyping" is the problematic one.
> >
> > If you say so. But you are mixing things up: in IDEF1X Notation,
> > there is no “Non-Exclusive” Subtyping, there is only
> > {Complete|Incomplete}.
>
> Exactly. But "non-exclusive subtyping" is not a notation, it is
> a concept.
???
> > there is no “Non-Exclusive” Subtyping, there is only
> > {Complete|Incomplete}.
>
> Exactly. But "non-exclusive subtyping" is not a notation, it is
> a concept.
It is first a concept, absolutely.
It is a concept in IEEE, which existed prior to IDEF1X.
It is a concept outside IDEF1X.
The concept has a notation. (In the same way that a concept has a word.)
The IEEE concept has an IEEE notation.
It is both a concept and a notation.
How can that be denied ???
> And IDEF1X has not straightforward notation for that.
The concept is outside IDEF1X.
It is not that it “has not a straightforward notation”, it has no notation whatsoever for the concept that it does not have.
> >> What is marked with ? corresponds to an "incomplete categorization"
> >> in IDEF1X terminology.
> >
> >
> >> Using IE notation, how would you model an
> >> "incomplete categorization"?
> >
> >> Using IE notation, how would you model an
> >> "incomplete categorization"?
> >
> > Well, you can’t. Because it does not exist in IE. Because it does
> > not exist in reality.
>
> Look who is in denial of reality.
Stop trying to trip me up. Try to understand what I am saying, in the context of the exchange. Otherwise we will never get to closure.
> > not exist in reality.
>
> Look who is in denial of reality.
I am taking the IEEE mindset. If you wish to understand that, and you have to, in order to mount an argument against it, try to understand it. Ask questions. Do not merely perceive the IEEE mindset from a fixed IDEF1X concept-and-notation mindset, because that prevents understanding.
So what am I trying to say in this context ? I have already stated, I cannot understand your cross-hatch pseudo-tabulation. I am trying to understand this thing [?]. You said it “corresponds to an "incomplete categorization" in IDEF1X terminology”. It can’t. Because that thing [incomplete categorization] does not exist in IEEE. It is foreign (not merely “orthogonal”). Stop there and agree/disagree.
----
Now for the next point, after the previous point has been addressed. I say that IEEE does not have [incomplete categorization] because it does not exist in reality. That is not a denial of reality (it is, only if you provide an example of such from reality). A mere declaration will not suffice.
So why do I say such thing, how can it be true ? Because the IDEF1X [incomplete categorization] is not defined, the definition given is not technical, not Relational, not a Predicate that can be implemented (recall, the foundation sequence is: FOPC; /RM/; Modelling; SQL). It is merely “not Complete”.
//For understanding, virtually all Categories, except the most rudimentary (such as Male/Female), would be Incomplete, because they will never be completed, they can be extended in the future. Thus {Complete|Incomplete} fall into the category of meaningless. Thus no one uses it. And particularly since the IEEE Subtypes existed prior, we have no reason to take up this meaningless new categorisation.//
Now if you have a better understanding of IDEF1X[incomplete categorization], or a better definition, please provide.
> My Employee[Full-Time,Consultant]
> example is just that.
//The burden of proof is on the proposer; the prosecution, not on the defence. It is not for me to disprove your proposal, it is for you to prove it, independently.//
> Similarly to the above, "incomplete
> categorization" is not a notation, it is a concept.
> And your IE has not
> straightforward notation for that.
Now if you are trying to say that there is something lacking in the IEEE concepts-and-notation, just explain it, without using IDEF1X concepts-and-notation. If you use your Employee{Full-Time|Consultant} example again, recall I have already proved [not my job] that it is not complete enough to consider as a problem; a lack. The notion that it can be shown in some other notation (eg. Swahili or Chinese pictographs) is irrelevant, it does not prove a lack in the IEEE concepts-and-notation.
Analogy. In the real world, we have only Male/Female, anyone who denies their physical reality is insane. It does not matter what they say they are because they are insane. When a man goes to a doctor and asks for a hysterectomy, he gets treated for insanity, not for a hysterectomy.
Now the insane person comes around, and gleefully declares that his/her/its/shits list of concocted “genders” is better because it has more members and it is forever changing and it will never be complete. That even Fakebook has 104 Genders listed. My response is to give it a sedative and a warm bed. Your response is to declare that there is something lacking in the {Male|Female} set.
Another one. The rag-and-bone man comes along and says he has a child with both male and female organs. Ok, no problem. But then he says it violates the {Male|Female} set. No, it does not, his child is a deformed freak, 0.0001% of the population, due to his wife being his niece. The deformed; the abnormal, prove nothing about the normal, the only thing they prove is about the abnormal.
So if you are trying to say that IEEE concepts-and-notation is lacking in some way, say it squarely, in technical and IEEE terms, not in Swahili; Chinese; insane; or IDEF1X terms.
> > Nevertheless, because the IDEF1X notation is inferior, a lower-order
> > concept, it can be progressed to a superior, higher-order concept.
> > Just get rid of the notion of “incomplete/complete”.
>
> Without such a notion, you are forced to model "incompleteness" of
> a generalization hierarchy with 1:1-0:1 relationships. While you can do
> that, it may not be the most natural or more economical way of modeling
> some situations, witness your Employee[Full-Time,Consultant] solution.
- nothing is “forced”, that is emotional nonsense
- there is no “incompleteness” or incompleteness in IEEE concepts-and-notation
- if you explain how IEEE IEEE concepts-and-notation is lacking, I would be happy to respond
Yes, I agree IDEF1X concepts-and-notation is broken. That is why I have never used it, that is why I have never seen anyone else use it. (Except you, but you are an academic purist, trying to use something that was deemed obsolete and irrelevant forty years ago, and resisting the actual use by practitioners during those forty years.) No, I will not help you improve or fix that broken thing, because it is obsolete and irrelevant.
Whereas I am very interested in any genuine problem with the IEEE concepts-and-notation. I will help you sort it out, and certainly if an amendment is necessary, I will assist in defining such.
(I don’t think it likely, because it has stood for forty years since IDEF1X came out, and no one has raised such. You are new to this, so it is likely a matter of understanding.)
Cheers
Derek
Nicola
Apr 8, 2021, 6:02:50 PM4/8/21
to
On 2021-04-07, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> Responding to issues in the doc only.
> 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.
> not just the words in “hot” colour and underlined.
> b. Re Place. In my DM, I am displaying the Entity level symbol for
> this entity, on a page that is displaying Attribute level. That means
> that Place is fully defined somewhere else (another page) in the DM.
> What does the dot-dot-dash line intend to convey ?
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
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.
> 2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X.
"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.
which I have updated.
> Use “generalisation” and “category”
> throughout, to be faithful to the IDEF1X terminology.
> (Subtype; Exclusive, are IEEE terms.
standards use them, as well.
> Basetype; Non-Exclusive are my
> corrections to incorrect ERwin terms.)
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.
"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.
> --- “when the business part[y] is a customer” is contrived.
> - the declaration “customer and business party are the same entity” is
> patently false: the model shows two distinct entities.
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.
> 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.
optional fact of Business Party?
> 4-Non-Exclusive Subtyping
>
> a. There is no such thing as “Non-Exclusive Subtyping” in IDEF1X.
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.
> 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.
>
> 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.
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.
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.
Nicola
Nicola
Apr 9, 2021, 4:31:08 AM4/9/21
to
On 2021-04-08, Nicola <nic...@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
> I have simplified the document a bit. Note that I have also reordered
> the sections:
(§6) with predicates, which I believe is what you will be more
interested in dissecting:
https://jirafeau.net/f.php?h=18wYFi9U
Nicola
Derek Ignatius Asirvadem
Apr 9, 2021, 5:54:49 AM4/9/21
to
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.
Well, if that is the case, we need to step back from this /implementation/ level and have a little discussion at the /conceptual/ level. Under two heads.
Normalisation
-----------------------
In that case, you are contradicting, in chronological order:
1. IEEE
2. Normalisation
3. FOPC
4. /RM/
5. IDEF1X Original
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)”
--- I hope I don’t need to spell out the corollary: an optional child, modelled as anything but an optional child (such as a Basetype::Subtype relation) is a gross error.
--- The category of error is Normalisation. (If you question that please discuss separately)
7. Yourself, because you suggest you are against superfluous or extraneous definition in the data model (note your comments re the 3-table vs 4-table difference).
--- I agree with the need for the Proper Subset, I declare that achieving that is Normalisation [the exercise, not the hilarious NFs], but that does not apply /there/.
--- It does apply /here/.
8. You have not exposed the Predicates, as you should. If you did, you would see that the Predicates prove a gross error.
--- Which is resolved by an act of Normalisation.
--- Such as eliminating the totally superfluous Basetype::Subtype relation between the standing parent and the standing child.
>>>
Fragmentation/Schizophrenia
------------------------------------------------
Think about this. I am not saying it is your fault. I am saying you are a dyed-in-the wool academic, loyally following the academics that destroy this science. Even when you know that their poop stinks, even though you are trying to get past their poop, you do not realise that you are limited; ham-strung, by their poop that you don’t realise you have.
They break the Atom, and then engage the fragments. It is not only hysterically stupid, it is an act of destruction. We break something up when we need to kill it, and eat [consume] its parts. When we want to eat an animal, we kill it and then break it up.
When we want to use something, WE DO NOT DO THAT. We leave it whole, Atomic. If we want to eat a horse, we break it up and consume its parts. If we want to use it to pull a cart, note that the perfectly wonderful four legs and strong back lying on the ground will not pull a cart. No, we need the horse in its whole condition.
So freaky the sow-suckers (Date; Darwen; Fagin; and all their followers; the professors who write textbooks; etc) break up the Atom, and feed you “clever” ways of dealing with the parts, a method fraudulently called “science”, but it is truly anti-science. You are so schooled in breaking up entities in the real world, into non-entities in the freaky model, and then drawing “relations” between the parts [attributes] that you do not realise you are doing it. All the post-Codd NFs suffer this problem. The infamous shell game of elevating 1960’s Record Filing Systems to “Relational” by drawing “relations” between the parts of a Relational Key, while denying the row that is identified by the Relational Key [and nothing but], and adding a RecordID field.
You fail to see that the real world entities are integral entities, not a sum of attributes; you fail to see the Identity; the Atomicity. You are playing with the parts, as if they are relatable to the parts of other entities, while missing the fact that it is the integral entities that are related, not the parts. You have years, possibly decades, of learning; studying; teaching that filth. It is deeply embedded. But it is false; anti-science, dealing with fragments while denying the Atom.
There are no Predicates on the fragments (any that are suggested will be anti-science, at best fantasy, at worst destructive to the actual Predicates).
That is why I am saying, it is not your fault. See if you can understand all that, and consciously choose to return to science, consciously choose to engage the Atoms, not the fragments.
<<<<
In logical terms, referring to your models, your doc [Revised] edition §3, or the [V2] edition §5:
- BusinessParty is not a whole entity because it is a Basetype.
- BusinessParty is an Exclusive Basetype, one of {Individual|Organisation}
--- each Basetype::Subtype pair is a unit of logic, a logical entity, a logical row, two physical rows
--- BusinessParty is now a whole entity BusinessParty{Individual|Organisation}
- BusinessParty{Individual|Organisation} is 0-to-1 Customer
--- as distinct from “BusinessParty{Individual|Organisation} is a Customer” or “BusinessParty = Customer” which are queries, not Predicates, but again depend on Identity
- which means the Alternate model is correct
--- and the Proper or Minimal Subset
--- and therefore the only correct one, because anything added would be superfluous
Now the burden of proof is on the prosecution; the proposer. Since you are proposing the new claims, it is your job to provide proof, it is not my job to disprove the claim (2,400 years of established science and judicial process). Although I have done so incidentally, by the exposition above. Go ahead and prove:
- “business party and a customer must be treated as a single logical unit” when they are clearly not
- “customer and business party are the same entity” when it is patently false: the model shows two distinct entities.
Knock yourself out. Give the Predicates.
> > - the declaration “customer and business party are the same entity” is
> > patently false: the model shows two distinct entities.
>
> Let me rephrase it: each instance of a Customer entity represents the
> same real-world "thing" as its associated instance of the Business Party
> entity.
Nonsense.
1. That is fragmented “thinking”, fantasy, not thinking. The reality (your model, not the real world) is, two separate determined and drawn entities cannot possibly be the same entity, nor does the child “represent” the parent.
2. And it is stated in anti-Relational terms, given that Relational terms exist for that. Yes, there are relations between them, and yes they are Relational relations. STATE THAT. Failure to state those Relational relations is a gross omission; anti-Relational. And it is that omission or suppression that affords the vacuum for the hysterical proposition (that an Optional Attribute is somehow equivalent to an IDEF1X[IncompleteCategorisation], and a false one at that)
- the child is Dependent on the parent
- the child is owned by the parent (assuming valid RKs)
- the child is Identified, in part, by the parent (assuming valid RKs)
- but by no stretch of the imagination, no amount of good drugs, is the parent and the child “the same”, nor does the child “represent” the parent
It appears you are mutilating the ordinary Optional Attribute configuration, to artificially fit a strange and novel interpretation of IDEF1X[IncompleteCategorisation]. Which it does not. Now if that were purposeful, it is criminal and insane. If not, then stand corrected.
You are so narrow-focussed on the result that you wish to obtain, you do not appreciate the generic result that your contrivance imposes, if accepted: you have made all Optional Attribute structures into illegal Incomplete structures.
See, whereas truth is single, errors are (a) multiple, and (b) compound themselves. Since you accept the 1997 anti-standard for IDEF1X over the established Standard, which is an error, even your well-intended corrections or improvements are simply compounded errors.
The really nasty error you made that affected me was, you talked about IDEF1X meaning the Standard and the hysterical anti-standard, interchangeably. Since you treated both as a Standard, I responded as a Standard. I now stand corrected. Half of what you have said about IDEF1X is the Standard, which is valid, which you use as a foundation to propagate the anti-standard in its place.
I repeat, I reject the 1997 revision outright. I therefore have no errors.
I don’t base anything on it. I therefore have no compounded errors.
I restate:
- I will help you with IDEFX1, the Standard.
- I will *NOT* help you propagate and compound errors, such as the idiotic 1997 revision. The name of which I will not repeat, which would afford it a credibility it does not have.
--- from now on, please do not tell me anything about pig poop (out of respect, I don’t tell you about my poop)
--- please do not ask me to fix pig poop.
--- No, I have rejected it outright, I do not allow it in the house. Let alone the cranium.
> > c. To be clear, in any case (IDEF1X xor IEEE) Customer is definitely
> > not BusinessParty.
No answer ?
> > 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?
Fragmentation again.
> A Business Party is 0-to-1 Organization
False. Fantasy. The DM read by someone playing “join the dots”, not by an educated data modeller.
There is no Predicate in your model that states that. (It is your model.)
I will give the Predicates for model on the right. Obviously, nothing can be reasonably understood when suppressing the Identity, so I will give the Key level. (It is equivalent to Person{Male|Female} in the [Nicola IDEF1X 2] doc, wherein it is fully declared.)
>>
THIS SET OF PREDICATES FOR A SINGLE TABLE IS ATOMIC
>>>>
[Each] BusinessParty
is independent -- exists independently
is primarily identified by ( PersonNo ) -- relational breach
is alternately identified by ( <not known> )
is discriminated by 1 Type
is an exclusive Basetype, one of { Individual, Organisation }
<<<<
<<
Now in that Relational context, it is insane [ (a) Fragmented thinking, and (b) denial of actual Predicates] to propose:
- “A Business Party is 0-to-1 Organization”
--- the relation is [is], AND it is constrained by a Basetype constraint
- “Organization is an optional fact of BusinessParty”
--- There is nothing optional about it: when it is, it is, and when it is not, it is not, as per [Type]
--- {Individual|Organisation} is not an “optional fact” about a BusinessParty. No. {Individual|Organisation} is a mandatory fact about a BusinessParty.
--- {Male|Female} is not an “optional fact” about a Person. No. {Male|Female} is a mandatory fact about a Person.
To think that, either {Individual|Organisation} or {Male|Female}, which are declared SETS, are optional when they are declared as mandatory, is insane. To think you can separate the Atomic SETS and abuse their fragmented parts while denying their Atomic nature, is insane.
> > 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.
Ok, but you still have not defined that problem. Please, for your own good, since you are saying that there is a problem, define it.
Alternately, recognise what I am saying, and realise that you cannot take the categorisation that is defined in one context (one Standard), and impose it onto another context (a different piece of crap). So when you try to do such a silly thing, yes, there is a problem, but the problem *IS* with the person trying the silly thing, the problem is NOT with the Standard (either one).
You can’t destroy the hierarchy and pretend that all the fragments [now flat and meaningless] are somehow “equal”. And then mess with these “equal” fragments. No. The declarations are given in an hierarchy. Taking a single item out of the hierarchy in which it exists, and treating it in isolation, is insanity. As heavily promoted and marketed as “science”, by the evil ones. Stick to science.
> > 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.
So, why do you use it ?
Why do you not understand, that for a person with an un-perverted mind (resistant to the pig poop), if it cannot be defined, IT DOES NOT EXIST. Imagination is strictly not reality.
Why do you accept it, and then mount a proposal for a correction ?
> > 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.
Well, you should not refer to a discussion in progress, and you should refer only to complete and unresolved definitions (as you have in the other references, such as to my Subtype doc). Perhaps wait until the discussion is resolved (science; certainty).
> > 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.
No. I repeat, yet again:
>>
Now the burden of proof is on the prosecution; the proposer. Since you are proposing the new claims, it is your job to provide proof, it is not my job to disprove the claim (2,400 years of established science and judicial process).
<<
If you wish to leave the realm of science, and enter into the realm of shared imagination, you need to declare that, and I won’t be participating.
> The classifications are not "totally unrelated".
They are. IEEE concepts-and-notation is not related to IDEF1X concepts-and-notation. IDEF1X concepts-and-notation is not related to IEEE concepts-and-notation.
> They are strictly related,
1. It is your job to define the relation
2. It is your job to define how they are “strictly related”
> and with small changes, they are equivalent,
Define the small changes.
> as I said, in the
> sense that they represent the same first-order predicates.
Give the Predicates.
> > - 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.
Well, that cannot be determined because you have not given the alleged Predicates.
----
I will get to the new V2 doc tomorrow.
Cheers
Derek
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).
- 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.
> > 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**".
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 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.
> > 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".
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.
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.
> > --- “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.
Normalisation
-----------------------
In that case, you are contradicting, in chronological order:
1. IEEE
2. Normalisation
3. FOPC
4. /RM/
5. IDEF1X Original
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)”
--- I hope I don’t need to spell out the corollary: an optional child, modelled as anything but an optional child (such as a Basetype::Subtype relation) is a gross error.
--- The category of error is Normalisation. (If you question that please discuss separately)
7. Yourself, because you suggest you are against superfluous or extraneous definition in the data model (note your comments re the 3-table vs 4-table difference).
--- I agree with the need for the Proper Subset, I declare that achieving that is Normalisation [the exercise, not the hilarious NFs], but that does not apply /there/.
--- It does apply /here/.
8. You have not exposed the Predicates, as you should. If you did, you would see that the Predicates prove a gross error.
--- Which is resolved by an act of Normalisation.
--- Such as eliminating the totally superfluous Basetype::Subtype relation between the standing parent and the standing child.
>>>
Fragmentation/Schizophrenia
------------------------------------------------
Think about this. I am not saying it is your fault. I am saying you are a dyed-in-the wool academic, loyally following the academics that destroy this science. Even when you know that their poop stinks, even though you are trying to get past their poop, you do not realise that you are limited; ham-strung, by their poop that you don’t realise you have.
They break the Atom, and then engage the fragments. It is not only hysterically stupid, it is an act of destruction. We break something up when we need to kill it, and eat [consume] its parts. When we want to eat an animal, we kill it and then break it up.
When we want to use something, WE DO NOT DO THAT. We leave it whole, Atomic. If we want to eat a horse, we break it up and consume its parts. If we want to use it to pull a cart, note that the perfectly wonderful four legs and strong back lying on the ground will not pull a cart. No, we need the horse in its whole condition.
So freaky the sow-suckers (Date; Darwen; Fagin; and all their followers; the professors who write textbooks; etc) break up the Atom, and feed you “clever” ways of dealing with the parts, a method fraudulently called “science”, but it is truly anti-science. You are so schooled in breaking up entities in the real world, into non-entities in the freaky model, and then drawing “relations” between the parts [attributes] that you do not realise you are doing it. All the post-Codd NFs suffer this problem. The infamous shell game of elevating 1960’s Record Filing Systems to “Relational” by drawing “relations” between the parts of a Relational Key, while denying the row that is identified by the Relational Key [and nothing but], and adding a RecordID field.
You fail to see that the real world entities are integral entities, not a sum of attributes; you fail to see the Identity; the Atomicity. You are playing with the parts, as if they are relatable to the parts of other entities, while missing the fact that it is the integral entities that are related, not the parts. You have years, possibly decades, of learning; studying; teaching that filth. It is deeply embedded. But it is false; anti-science, dealing with fragments while denying the Atom.
There are no Predicates on the fragments (any that are suggested will be anti-science, at best fantasy, at worst destructive to the actual Predicates).
That is why I am saying, it is not your fault. See if you can understand all that, and consciously choose to return to science, consciously choose to engage the Atoms, not the fragments.
<<<<
In logical terms, referring to your models, your doc [Revised] edition §3, or the [V2] edition §5:
- BusinessParty is not a whole entity because it is a Basetype.
- BusinessParty is an Exclusive Basetype, one of {Individual|Organisation}
--- each Basetype::Subtype pair is a unit of logic, a logical entity, a logical row, two physical rows
--- BusinessParty is now a whole entity BusinessParty{Individual|Organisation}
- BusinessParty{Individual|Organisation} is 0-to-1 Customer
--- as distinct from “BusinessParty{Individual|Organisation} is a Customer” or “BusinessParty = Customer” which are queries, not Predicates, but again depend on Identity
- which means the Alternate model is correct
--- and the Proper or Minimal Subset
--- and therefore the only correct one, because anything added would be superfluous
Now the burden of proof is on the prosecution; the proposer. Since you are proposing the new claims, it is your job to provide proof, it is not my job to disprove the claim (2,400 years of established science and judicial process). Although I have done so incidentally, by the exposition above. Go ahead and prove:
- “business party and a customer must be treated as a single logical unit” when they are clearly not
- “customer and business party are the same entity” when it is patently false: the model shows two distinct entities.
Knock yourself out. Give the Predicates.
> > - the declaration “customer and business party are the same entity” is
> > patently false: the model shows two distinct entities.
>
> Let me rephrase it: each instance of a Customer entity represents the
> same real-world "thing" as its associated instance of the Business Party
> entity.
1. That is fragmented “thinking”, fantasy, not thinking. The reality (your model, not the real world) is, two separate determined and drawn entities cannot possibly be the same entity, nor does the child “represent” the parent.
2. And it is stated in anti-Relational terms, given that Relational terms exist for that. Yes, there are relations between them, and yes they are Relational relations. STATE THAT. Failure to state those Relational relations is a gross omission; anti-Relational. And it is that omission or suppression that affords the vacuum for the hysterical proposition (that an Optional Attribute is somehow equivalent to an IDEF1X[IncompleteCategorisation], and a false one at that)
- the child is Dependent on the parent
- the child is owned by the parent (assuming valid RKs)
- the child is Identified, in part, by the parent (assuming valid RKs)
- but by no stretch of the imagination, no amount of good drugs, is the parent and the child “the same”, nor does the child “represent” the parent
It appears you are mutilating the ordinary Optional Attribute configuration, to artificially fit a strange and novel interpretation of IDEF1X[IncompleteCategorisation]. Which it does not. Now if that were purposeful, it is criminal and insane. If not, then stand corrected.
You are so narrow-focussed on the result that you wish to obtain, you do not appreciate the generic result that your contrivance imposes, if accepted: you have made all Optional Attribute structures into illegal Incomplete structures.
See, whereas truth is single, errors are (a) multiple, and (b) compound themselves. Since you accept the 1997 anti-standard for IDEF1X over the established Standard, which is an error, even your well-intended corrections or improvements are simply compounded errors.
The really nasty error you made that affected me was, you talked about IDEF1X meaning the Standard and the hysterical anti-standard, interchangeably. Since you treated both as a Standard, I responded as a Standard. I now stand corrected. Half of what you have said about IDEF1X is the Standard, which is valid, which you use as a foundation to propagate the anti-standard in its place.
I repeat, I reject the 1997 revision outright. I therefore have no errors.
I don’t base anything on it. I therefore have no compounded errors.
I restate:
- I will help you with IDEFX1, the Standard.
- I will *NOT* help you propagate and compound errors, such as the idiotic 1997 revision. The name of which I will not repeat, which would afford it a credibility it does not have.
--- from now on, please do not tell me anything about pig poop (out of respect, I don’t tell you about my poop)
--- please do not ask me to fix pig poop.
--- No, I have rejected it outright, I do not allow it in the house. Let alone the cranium.
> > 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?
> A Business Party is 0-to-1 Organization
There is no Predicate in your model that states that. (It is your model.)
I will give the Predicates for model on the right. Obviously, nothing can be reasonably understood when suppressing the Identity, so I will give the Key level. (It is equivalent to Person{Male|Female} in the [Nicola IDEF1X 2] doc, wherein it is fully declared.)
>>
THIS SET OF PREDICATES FOR A SINGLE TABLE IS ATOMIC
>>>>
[Each] BusinessParty
is independent -- exists independently
is primarily identified by ( PersonNo ) -- relational breach
is alternately identified by ( <not known> )
is discriminated by 1 Type
is an exclusive Basetype, one of { Individual, Organisation }
<<<<
<<
Now in that Relational context, it is insane [ (a) Fragmented thinking, and (b) denial of actual Predicates] to propose:
- “A Business Party is 0-to-1 Organization”
--- the relation is [is], AND it is constrained by a Basetype constraint
- “Organization is an optional fact of BusinessParty”
--- There is nothing optional about it: when it is, it is, and when it is not, it is not, as per [Type]
--- {Individual|Organisation} is not an “optional fact” about a BusinessParty. No. {Individual|Organisation} is a mandatory fact about a BusinessParty.
--- {Male|Female} is not an “optional fact” about a Person. No. {Male|Female} is a mandatory fact about a Person.
To think that, either {Individual|Organisation} or {Male|Female}, which are declared SETS, are optional when they are declared as mandatory, is insane. To think you can separate the Atomic SETS and abuse their fragmented parts while denying their Atomic nature, is insane.
> > 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.
Alternately, recognise what I am saying, and realise that you cannot take the categorisation that is defined in one context (one Standard), and impose it onto another context (a different piece of crap). So when you try to do such a silly thing, yes, there is a problem, but the problem *IS* with the person trying the silly thing, the problem is NOT with the Standard (either one).
You can’t destroy the hierarchy and pretend that all the fragments [now flat and meaningless] are somehow “equal”. And then mess with these “equal” fragments. No. The declarations are given in an hierarchy. Taking a single item out of the hierarchy in which it exists, and treating it in isolation, is insanity. As heavily promoted and marketed as “science”, by the evil ones. Stick to science.
> > 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.
Why do you not understand, that for a person with an un-perverted mind (resistant to the pig poop), if it cannot be defined, IT DOES NOT EXIST. Imagination is strictly not reality.
Why do you accept it, and then mount a proposal for a correction ?
> > 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.
> > 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.
>>
Now the burden of proof is on the prosecution; the proposer. Since you are proposing the new claims, it is your job to provide proof, it is not my job to disprove the claim (2,400 years of established science and judicial process).
<<
If you wish to leave the realm of science, and enter into the realm of shared imagination, you need to declare that, and I won’t be participating.
> The classifications are not "totally unrelated".
> They are strictly related,
1. It is your job to define the relation
2. It is your job to define how 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.
> > - 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.
----
I will get to the new V2 doc tomorrow.
Cheers
Derek
Nicola
Apr 9, 2021, 9:59:07 AM4/9/21
to
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.a...@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
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.
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
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.a...@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”,
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
> (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,
kinds of generalization hierarchies.
> and that uses the new loose and floppy IDEF1X revision terminology.
>> On Friday, 9 April 2021 at 08:02:50 UTC+10, Nicola wrote:
>> > 2. There is no such thing as “Exclusive” “Subtyping” in IDEF1X.
«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].
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).
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)”
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.
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 ?
document (v3).
Nicola
Derek Ignatius Asirvadem
Apr 10, 2021, 3:27:56 AM4/10/21
to
> 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.
> > On 2021-04-09, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
>
> You have
> asked me to point out "articles", "standards". I have complied, with
> titles, page numbers, paragraphs, verbatim quotes.
Thank you.
> 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 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?
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!
> FIPS 184, ("Definitions" section):
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?
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.
> > 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).
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.
> 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):
>
Thank you.
> So, a category "is also known as" a sub-type.
> So, exclusive/non-exclusive is covered quite explicitly. More on that
> below.
> >> > - declarations SUCH AS “business party and a customer must be treated
> >> > as a single logical unit” are valid for IEEE Subtypes, I don’t see how
> >> > they apply to IDEF1X Categories.
> >>
> >> I do because I see no difference between "complete categorization" and
> >> "exclusive subtyping" in terms of the predicates they represent. If
> >> there are any, please let me know.
> >
> > Ok.
>
> > 1. Where, pray tell, in the definition of IDEF1X[Complete
> > Categorisation] (preferably the original, but ok, the revised if you
> > must), excluding your interpretation, does it state that the members
> > are mutually exclusive, as it states in the IEEE[Exclusive Subtype].
>
> Besides the above, FIPS 184, Annex B also contains a first-order
> formalization of IDEF1X, which also asserts the exclusivity requirement.
> Specifically (the labeling starts with "C" although the section is "B"),
>
> p. 116:
>
> «C1.2 The categories within a cluster are mutually exclusive.
> For 1 <= i < j <= n, add a rule
>
> (for all *)(not exists(v: e_i): I, exists(v: e_j: I))
>
> to the theory
Eg. ERwin implements what I said, not what the FIPS 184 doc “defines”.
> 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,
You can purchase it from IEEE or ISO at institutional prices.
> 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).
Definitely not.
[C1.3] ensures that for every Basetype, there is one Subtype, that is their notion of “Complete”. Contrast that to their notion of “Incomplete”, which means a Subtype cluster which includes a Basetype that has no Subtype. Hopefully now you will understand the IDEF1X meaning of {Complete|Incomplete}, the two go together, and that it is a royal farce.
A Basetype that has no Subtype [Category with no members] is ridiculous (in logic). It is not a part of a Subtype cluster. To call it a “Category” or “Generic” does not magically transform it into one, it means the label is false.
Second last, there is no valid formalism for IEEE{Exclusive|Non-Exclusive}. Exclusive is “defined” but not “formalised”. Non-Exclusive is not even “defined”.
Last, again, do not use that quote of mine which is valid of RM/IEEE, to try and perceive what the IDEF1X folks meant. No, it does not have that. You can’t impose modern sensibilities onto the past, you can’t impose a higher-order onto a lower-order. You must try and understand what the IDEF1X folks meant, via their “definitions”.
> > 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.
What “generalisation structure” ??? Since when is a single member a “hierarchy” ???
Give us some reasoning, not mere false labelling.
> Hence, a Business Party is
> a generalization of a Customer (a Customer *is* a Business Party),
> although not all Business Parties are customers.
Yes, of course, “a Customer *is* [always] a Business Party”, but that is not a Predicate, and that connects two unconnected things. You are mixing up queries with Predicates.
Where are the Predicates ? Ok, I have to look at the V3 doc.
Last but not least, I repeat, it is great that you are taking up IDEF1X, but please understand this is forty years late. Guys like me worked out how to correct and use IDEF1X thirty; thirty-five years ago. Which is why I had forgotten that, and held onto the “IDEF1X” Identity. Apologies again.
Cheers
Derek
Derek Ignatius Asirvadem
Apr 10, 2021, 4:51:51 AM4/10/21
to
> 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):
> > On Friday, 9 April 2021 at 23:59:07 UTC+10, Nicola wrote:
> > 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.
> Cheers
> Derek
Nicola
Apr 11, 2021, 4:40:33 AM4/11/21
to
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
> 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
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
Derek Ignatius Asirvadem
Apr 11, 2021, 6:08:57 PM4/11/21
to
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
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).
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.
> I will just point out that the example you have chosen for §4.7 is
> a straw man:
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).
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),
> although you have already brought forth the
> arguments to dismiss my tentative IEEE addition.
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
Nicola
Apr 12, 2021, 3:23:37 AM4/12/21
to
On 2021-04-11, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> I do have a long response to your V3 doc
Looking forward to reading it.
> I do have a long response to your V3 doc
>> I will just point out that the example you have chosen for §4.7 is
>> a straw man:
>
> That is a silly charge.
(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.
author.
> No problem at all to change the example (because the truth is the
> truth and it will destroy falsity anywhere).
> I don’t know if it would help, because you appear to be fairly fixed
> on your understanding of {Complete, Incomplete}. And I have thus far
> been unable to get you to see it.
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
Derek Ignatius Asirvadem
Apr 12, 2021, 8:13:44 AM4/12/21
to
> 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
>
> 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
Derek Ignatius Asirvadem
Apr 12, 2021, 8:43:38 AM4/12/21
to
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:
> >> I will just point out that the example you have chosen for §4.7 is
> >> a straw man:
> >
> > That is a silly charge.
>
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.
>
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).
>
> > 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.
>
> 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
> On Monday, 12 April 2021 at 22:13:44 UTC+10, Derek Ignatius Asirvadem wrote:
>
> As mentioned, I have taken some of the content from my IDEF1X Qualification doc, transformed it for public use, into the Response doc.
> On Monday, 12 April 2021 at 17:23:37 UTC+10, Nicola wrote:
> > On 2021-04-11, Derek Ignatius Asirvadem wrote:
>
> > I do have a long response to your V3 doc
>
> Looking forward to reading it.
Sorry. ETA now Wednesday.
>
> > 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.
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.
> (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.
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).
> author.
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.
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".
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.
Cheers
Derek
Derek Ignatius Asirvadem
Apr 12, 2021, 9:43:36 AM4/12/21
to
Nicola
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
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
Derek Ignatius Asirvadem
Apr 12, 2021, 12:26:44 PM4/12/21
to
> 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
>
> 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
Derek Ignatius Asirvadem
Apr 13, 2021, 11:27:26 PM4/13/21
to
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
> 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
Message has been deleted
Derek Ignatius Asirvadem
Apr 15, 2021, 8:59:45 PM4/15/21
to
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:
Cheers
Derek
> On Monday, 12 April 2021 at 17:23:37 UTC+10, Nicola wrote:
> > On 2021-04-11, Derek Ignatius Asirvadem wrote:
>
> > I do have a long response to your V3 doc
>
> Looking forward to reading it.
> On Wednesday, 14 April 2021 at 13:27:26 UTC+10, Derek Ignatius Asirvadem wrote:
>
> [...]
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.
____ 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.
>
> What I see is that both notations have deficiencies
Cheers
Derek
LP
Apr 16, 2021, 4:09:33 AM4/16/21
to
On 2021-04-16, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> Response please.
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
> Response please.
>
> Since nothing appears to be forthcoming,
Be patient, I am very busy currently, but I have read your updated
> Since nothing appears to be forthcoming,
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
> After all that explanation, hopefully you can see there is no
> deficiency in the IEEE notation.
> Otherwise I will take it that my explanation has closed the
> issue, that there is no deficiency in the IEEE notation.
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
Derek Ignatius Asirvadem
Apr 17, 2021, 3:24:59 AM4/17/21
to
> 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.
> > On 2021-04-16, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> > Response please.
> >
> > Since nothing appears to be forthcoming,
>
> Be patient, I am very busy currently, but I have read your updated
> document.
> I will reply to your comments in the other post, but they will be only
> minor remarks. The matter is settled for me. I agree with you that there
> is no need to "fix" IEEE notation, and that IDEF1X's is broken (but the
> latter was my point to begin with).
If you have any suggestions for my doc, let me know.
Cheers
Derek
LP
Apr 18, 2021, 12:16:52 PM4/18/21
to
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
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
Derek Ignatius Asirvadem
Apr 19, 2021, 7:15:14 AM4/19/21
to
> 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.
>
> 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.
> hierarchies.
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.
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.
> I have
> added predicates throughout: hopefully, that will prevent further
> misunderstandings.
>>
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.
The example given is strictly *NOT* a specialisation in the sense that people would understand, therefore you are perverting that sense, in order to generalise it, in order to include Incomplete.
The truth is, Employee is a Person because it is Dependent on Person, not because it is a “specialisation” of Person (It is not).
By the perverted definition, *ANY* Dependent entity is a specialisation of the parent. Which is hysterical. In Order DM Advanced:
__ https://www.softwaregems.com.au/Documents/Documentary%20Examples/Order%20DM%20Advanced.pdf
according to your definition, PartyAddress; OrderSale; OrderSaleItem; OrderPurchase; OrderPurchaseItem; PartVendor are each “specialisations” of Party, which is ridiculous and false.
And again, while it is true in the simple Relational sense that each PartyAddress; OrderSaleItem; OrderPurchaseItem; PartVendor [is a] Party, it is not true in the “generalisation/specialisation” sense. Suburb is certainly not a Country, but yes, it depends on; belongs to, Country.
The terms “generalisation/specialisation” should only be applied to genuine generalisation/specialisations, and *NOT* to possibilities that are consequential to being Relational. You are again (a) losing the Atoms and (b) then dealing with the Fragments, (c) perceiving connections between the fragments, where there is *NO* connection between the Atoms.
> another entity
Really ?
Any other entity ?
Not a specific entity that consists of the ‘root’ or basetype of a set of abstractions that have common properties.
//No, no, don’t mention that, it will prevent the insanity of the null set from being imposed in reality where it not exists.//
> proper subset
Since when is the empty set a proper subset ??? The freaky fantasy is not even a set, let alone a proper subset.
> Generic entity: an entity that has at least one specialization. In the example above, Person is a generic entity.
The definition is fine, but the example is horrendous, supply a valid example.
This may be a good point at which to declare the differentiation:
- Total = at least two specialisations
- Partial = zero; one; or more
- Generic = at least one
- Specialisation = zero; one; or more
(How one establishes non-existence remains to be seen. But don’t you dare try it via redefinition.)
> All occs of “Specialization cluster”
Generalisation cluster.
> We also say that each employee is a person.
No, we do not. That perverts the well-established understanding of the [is a] relation.
Yes, of course, the relation of any child in any generation to the parent or grandparent is [is a], but that is pedestrian, not limited to, or characteristic of, generalisation/specialisation.
> Note, though, Employee and Person are two distinct entities (different sets).
??? Are not all depicted sets distinct sets; distinct entities.
> Footnote [2]
Can be removed. I operate in North America and Europe, I am quite familiar with the terms.
> Total, Partial
Yes, I see where you are going, I have no argument. But they are not commonly understood or “commonly accepted definitions”. The words in English are way too general, they cannot be used as specific in an application.
> Partial specialization cluster: a specialization cluster that is not total.
> Partial [generalisation] cluster: a [generalisation] cluster that is not total.
In a section for Definition, I would not state that (what it is not). I would state what it is.
> Exclusive specialization cluster: a specialization cluster such that, at every time, Si \ Sj is the empty set for all i ≠ j.
> Exclusive [generalisation] cluster: a [generalisation] cluster such that, at every time, Si \ Sj is the empty set for all i ≠ j.
Great for a theoretician. What about saying “one of”, so that implementors can understand it.
> Non-exclusive specialization cluster: a specialization cluster that is not exclusive.
> Non-exclusive [generalisation] cluster: a [generalisation] cluster that is not exclusive.
1. In a section for Definition, I would not state that (what it is not). I would state what it is.
2. Non-Exclusive is not at all understood or defined, neither in IDEF1X nor in your doc. It needs a proper description and definition. “Not exclusive” fails for a second count. Whereas Exclusive is a single occ for a basetype, Non-Exclusive is plural.
3. What about saying “any of”, so that implementors can understand it.
> A basetype is always a generic entity, but a generic entity is not necessarily a basetype
Cliché, cabalist nonsense, not fit for a technical document. It means nothing: a specialisation *IS ALWAYS** -<is>- relative to its parent, and a generic *IS NOT ALWAYS** -<is>- any of its specialisations.
Where you are trying to differentiate Basetype vs Generic, just state that: Basetype is Total; Generic is {Total|Partial}
> Total specialization clusters (i.e., subtyping) always have at least two specializations (subtypes)
[Whereas] a Total [generalisation] cluster (i.e., Subtype cluster) ]always[ has at least two specialisations (subtypes)
... a Partial generalisation cluster allows zero or one specialisation.
What is your definition of a zero-specialisation ?
Doc updated.
- I have added §1.6 in response to your V4 diagrams, but the argumentation is in this post.
- Date at the bottom of each page informs you if it has been updated.
____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
Cheers
Derek
LP
Apr 19, 2021, 5:18:54 PM4/19/21
to
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.a...@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.
> 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.
> And again, while it is true in the simple Relational sense that each
> PartyAddress; OrderSaleItem; OrderPurchaseItem; PartVendor [is a]
> Party, it is not true in the “generalisation/specialisation” sense.
> Suburb is certainly not a Country, but yes, it depends on; belongs to,
> Country.
Granted.
>> proper subset
> Since when is the empty set a proper subset ??? The freaky fantasy is
> not even a set, let alone a proper subset.
"Proper" has a very specific technical meaning in mathematics, and set
theory in particular. It does not mean what you think it means.
Anyway, the definition could in fact be stricter by saying "a proper
non-empty set".
>> Generic entity: an entity that has at least one specialization. In
>> the example above, Person is a generic entity.
> The definition is fine, but the example is horrendous, supply a valid example.
In what sense do you think that the example is "invalid"?
> This may be a good point at which to declare the differentiation:
> - Total = at least two specialisations
That is mentioned. It's also obvious from the definitions (this is also
mentioned).
> - Partial = zero; one; or more
No. A (perverted) *specialization cluster* ("partial" applies to
a cluster) has at least one specialization (reread the definition).
> - Generic = at least one
> - Specialisation = zero; one; or more
You are writing fragments here. "Generic" qualifies "entity"; "Total"
and "partial" qualify a "specialization *cluster*". A "specialization"
in my perverted definition is an entity (ok, perhaps "specialized
entity" would be better). Do not take a noun here and an adjective
there, otherwise we cannot understand each other.
I'm fine if you do not like my choice of terms, and I'm happy to change
them for better ones. But, even if "specialization" is not used with
a conventional meaning, it's the definition that matters, and within the
scope of that document the definition is given. We could change it to
"spizzalization" throughout, and the document would be understood in the
same way (this is a dejà-vu).
>> All occs of “Specialization cluster”
> Generalisation cluster.
I may consider this change.
>> 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?
>> Note, though, Employee and Person are two distinct entities (different sets).
>
> ??? Are not all depicted sets distinct sets; distinct entities.
Sure, just a trivial remark.
>> Footnote [2]
> Can be removed.
Done.
>> Total, Partial
> Yes, I see where you are going, I have no argument. But they are not
> commonly understood or “commonly accepted definitions”. The words in
> English are way too general, they cannot be used as specific in an
> application.
Any better ones?
>> Partial specialization cluster: a specialization cluster that is not total.
>> Partial [generalisation] cluster: a [generalisation] cluster that is not total.
> In a section for Definition, I would not state that (what it is not). I would state what it is.
That was to make the definitions shorter. I may change that.
>> Exclusive specialization cluster: a specialization cluster such that,
>> at every time, Si \ Sj is the empty set for all i ≠ j.
>> Exclusive [generalisation] cluster: a [generalisation] cluster such
>> that, at every time, Si \ Sj is the empty set for all i ≠ j.
> Great for a theoretician. What about saying “one of”, so that
> implementors can understand it.
The audience of my document has no problem understand that. It would
consider "one of" ambiguous.
>> A basetype is always a generic entity, but a generic entity is not
>> necessarily a basetype
>
> Cliché, cabalist nonsense, not fit for a technical document. It means
> nothing: a specialisation *IS ALWAYS** -<is>- relative to its parent,
> and a generic *IS NOT ALWAYS** -<is>- any of its specialisations.
There are too many "is" in this post. I am really confused.
> Where you are trying to differentiate Basetype vs Generic, just state
> that: Basetype is Total; Generic is {Total|Partial}
It's not only that. According to my definition, that is the only
difference.
>> 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.
> What is your definition of a zero-specialisation ?
There is no zero-specialization.
> Doc updated.
> - I have added §1.6 in response to your V4 diagrams, but the argumentation is in this post.
> - Date at the bottom of each page informs you if it has been updated.
>
> ____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
The qualitative figures are not essential for understanding, just an
addition for the visually inclined; together with the definitions, mine
are quite ok. One thing to notice, though, is that I am labelling only
the entities that are actually part of a hypothetical data model, while
you insist in adding the complement to show that the universe is
complete (which is obvious—it's the yellowish part in my Venn diagrams).
You would not have a NotEmployee or NotSecretaryAndNotConsultant entity
in your database, would you?
Nicola
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.a...@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.
> This doc is frequently used, it is generally viewed as authoritative:
> __https://people.cs.vt.edu/~kafura/cs2704/generalization.html
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.
> 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.
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.
> 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.
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.
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}
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>.
> 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”.
the same as "subtype").
> f.2. Four instances of “basetype” under IDEF1X should be “generic”.
reference to the IEEE symbol.
> g. Last but not least, each of the six sets needs a clear and
> unambiguous title.
> h.
>> is discriminated by Discr [not shown]
>
> In IDEF1X it *is* shown, therefore it is shown in IEEE (same as yours
> but in the font used for columns).
>
> My Extension shows it: either with the symbol (typically at the Entity
> level); or in the column, which must be designated [D] (typically at
> the Key and Attribute level).
> -----------------------
>> 0 Definitions
> -----------------------
> What you are trying to do is two separate things:
> - validate IDEF1X Incomplete
> - introduce Non-Exclusive
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.
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.)
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.
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.
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 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.
> And again, while it is true in the simple Relational sense that each
> PartyAddress; OrderSaleItem; OrderPurchaseItem; PartVendor [is a]
> Party, it is not true in the “generalisation/specialisation” sense.
> Suburb is certainly not a Country, but yes, it depends on; belongs to,
> Country.
>> proper subset
> Since when is the empty set a proper subset ??? The freaky fantasy is
> not even a set, let alone a proper subset.
theory in particular. It does not mean what you think it means.
Anyway, the definition could in fact be stricter by saying "a proper
non-empty set".
>> Generic entity: an entity that has at least one specialization. In
>> the example above, Person is a generic entity.
> The definition is fine, but the example is horrendous, supply a valid example.
> This may be a good point at which to declare the differentiation:
> - Total = at least two specialisations
mentioned).
> - Partial = zero; one; or more
a cluster) has at least one specialization (reread the definition).
> - Generic = at least one
> - Specialisation = zero; one; or more
and "partial" qualify a "specialization *cluster*". A "specialization"
in my perverted definition is an entity (ok, perhaps "specialized
entity" would be better). Do not take a noun here and an adjective
there, otherwise we cannot understand each other.
I'm fine if you do not like my choice of terms, and I'm happy to change
them for better ones. But, even if "specialization" is not used with
a conventional meaning, it's the definition that matters, and within the
scope of that document the definition is given. We could change it to
"spizzalization" throughout, and the document would be understood in the
same way (this is a dejà-vu).
>> All occs of “Specialization cluster”
> Generalisation cluster.
>> We also say that each employee is a person.
> No, we do not. That perverts the well-established understanding of
> the [is a] relation.
elaborate on this point? How should the [is a] relation be understood if
not as above?
>> Note, though, Employee and Person are two distinct entities (different sets).
>
> ??? Are not all depicted sets distinct sets; distinct entities.
>> Footnote [2]
> Can be removed.
>> Total, Partial
> Yes, I see where you are going, I have no argument. But they are not
> commonly understood or “commonly accepted definitions”. The words in
> English are way too general, they cannot be used as specific in an
> application.
>> Partial specialization cluster: a specialization cluster that is not total.
>> Partial [generalisation] cluster: a [generalisation] cluster that is not total.
> In a section for Definition, I would not state that (what it is not). I would state what it is.
>> Exclusive specialization cluster: a specialization cluster such that,
>> at every time, Si \ Sj is the empty set for all i ≠ j.
>> Exclusive [generalisation] cluster: a [generalisation] cluster such
>> that, at every time, Si \ Sj is the empty set for all i ≠ j.
> Great for a theoretician. What about saying “one of”, so that
> implementors can understand it.
consider "one of" ambiguous.
>> A basetype is always a generic entity, but a generic entity is not
>> necessarily a basetype
>
> Cliché, cabalist nonsense, not fit for a technical document. It means
> nothing: a specialisation *IS ALWAYS** -<is>- relative to its parent,
> and a generic *IS NOT ALWAYS** -<is>- any of its specialisations.
> Where you are trying to differentiate Basetype vs Generic, just state
> that: Basetype is Total; Generic is {Total|Partial}
difference.
>> Total specialization clusters (i.e., subtyping) always have at least
>> two specializations (subtypes)
>
> [Whereas] a Total [generalisation] cluster (i.e., Subtype cluster)
> ]always[ has at least two specialisations (subtypes) ... a Partial
> generalisation cluster allows zero or one specialisation.
> What is your definition of a zero-specialisation ?
> Doc updated.
> - I have added §1.6 in response to your V4 diagrams, but the argumentation is in this post.
> - Date at the bottom of each page informs you if it has been updated.
>
> ____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
addition for the visually inclined; together with the definitions, mine
are quite ok. One thing to notice, though, is that I am labelling only
the entities that are actually part of a hypothetical data model, while
you insist in adding the complement to show that the universe is
complete (which is obvious—it's the yellowish part in my Venn diagrams).
You would not have a NotEmployee or NotSecretaryAndNotConsultant entity
in your database, would you?
Nicola
Derek Ignatius Asirvadem
Apr 20, 2021, 6:35:12 AM4/20/21
to
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].
Since you rely on IDEF1X[Incomplete] so much, state that too, and then build on it.
You can’t rely on something, and deny it at the same time (refer to my argument re atheism above).
> Anyway, "category" is banned, because we do not agree on
> its meaning.
Answered above.
> >> 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.
(That word is so over-used, so meaningless.)
No.
1. Your definitions are fragments. That only stand in the context of denial of the atoms from which you extracted said fragments.
2. Then you either combine the fragments, and make something new, which lacks integrity,
3. Or make connections between the fragments, where there is no connection between the Atoms to which the said fragments belong.
It is a grand contrivance.
I am saying, do not deny the reality of IDEF1X definitions; do not deny the reality of Atoms. If your definitions depend on anything, declare those things [no definition or redefinition], and the dependency. Then give your definition for the new thing only. The whole of which will then be clear to any reader { strict IEEE | loose IDEF1X | tight IDEF1X }.
> >> Specialization [...]
1. Here, my comments pertained immediately to Specialisation, and your redefinition of it.
- you can’t, it is already well-established
--- you particularly can’t deny the definition of the atom [ Concept{Generalisation::Specialisation} ] and then use fragments of it [Specialisation alone, minus Generalisation]
--- and then a fragment of [Specialisation alone]
--- and then a novel definition under the head [Specialisation] which is in fact a redefinition
- accept it and move on
- use it as it is defined in the Standard, which is the atom [ Concept{Generalisation::Specialisation} ]
2. The IDEF1X Concept Categorisation{Generic::Category}
That in itself is no problem, it is just new words for Subtype{Basetype::Subtype}, the problem is the new classification {Complete|Incomplete}: as I have detailed, [Incomplete] is totally invalid in a database of any kind, invalid by definition in a Relational database. Again, it is not [Incomplete] as a member that can be eliminated ]and [Complete] retained[ because it is the classification that defined [Incomplete] that is in error, so the classification has to be rejected, neither member can be retained.
As determined; condemned; and published by me in 1993. As determined and rejected by several high-end suppliers that I am familiar with.
Eg. I relied on the pre-existing IEEE, to invalidate the then novel IDEF1X definitions. Logic invalidates it as well.
And to be complete, I give the logical alternative: it is an Optional Attribute, not a Subtype classification of any kind.
So yes, the IDEF1X classification {Complete|Incomplete} under its Concept Categorisation{Generic::Category} is absurd.
3. Your reliance on [Incomplete]
Since [2] is absurd, anything derived from it, anything relying on it, is absurd.
Anyone who persists in [2][3], which means they are denying the logical alternative, which means they are denying logic, is straining at the gnat and swallowing the camel, insisting on the fragments while denying the atom.
4. The null set
At the root of it, I won’t call it metaphysical, but meta-conceptual, you are relying on the concept of the empty set. It is a total absurdity. It does not exist in reality.
My challenge, to provoke you to think about the concept you are proposing: give me an example of the empty set from reality. (By all means, it is a very, very necessary abstraction in theory, but it does not exist in reality, it can be dismissed by practitioners). This is a boundary that you, a schooled academic, needs to cross, and I am trying to get you o do so consciously, without making academics wrong for having a null set. (I do make them wrong for venerating it, or for imposing it on reality where it does not and cannot exist.)
Any reliance on the null set (in fact on null) is an absurdity.
> > 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.
1. No, you said [declared]:
__The set of Employee is a subset of the set of Person, therefore Employee is a specialization of Person.
- you have equated [specialisation] to [subset]
- it is absurd, hysterical
2. Now to deal with the perversion, God help me:
It produces nonsense such as:
__Suburb is a specialisation of Town
__Suburb is a specialisation of Country
__PartyAddress is a specialisation of Party
__OrderSale is a specialisation of Party
Further, the actual Predicates refute the absurd proposition.
> >> proper subset
> > Since when is the empty set a proper subset ??? The freaky fantasy is
> > not even a set, let alone a proper subset.
>
> "Proper" has a very specific technical meaning in mathematics, and set
> theory in particular. It does not mean what you think it means.
I don’t care what it means today or tomorrow in mathematics, as it is being corrupted; changed; modified to suit the pervert’s agenda. I DO care about what it means in mathematics+reality, you know, the fraction of theory that has an implementation intent. I am not arguing against the mathematical definition. I am arguing FOR the mathematical+reality definition.
(Mathematics is not science, it is a formal language, an articulation of Logic. Mathematics cannot do or say or prove anything, it is the person, using mathematics, to say or do whatever. All that can truly be faulted in mathematics is incorrect use of the formalism, or deformation. The subject matter is the thing, the article, that one proposes using mathematics, that may be true or false. Thus it quite possible to write a proposal in perfect mat that a pig can fly, and to write another proposal in perfect math that a pig cannot fly. The former proposal fails the laws of physics, and deems the author an idiot, yet a perfectly defined one.)
Likewise, logic is the form, your proposal is the matter, it fails logic.
- If the set has no members, it is not a set (it is a nothing and non-thing, null), it cannot have a Proper Subset
- If the set has one member, it can have no Proper Subset (there is no possible subset).
> Anyway, the definition could in fact be stricter by saying "a proper
> non-empty set".
No. I have given you several reasons why the definition is wrong, but the overriding issue is, you cannot redefine a term that is defined in the Standard.
> >> Generic entity: an entity that has at least one specialization. In
> >> the example above, Person is a generic entity.
>
> > The definition is fine, but the example is horrendous, supply a valid example.
>
> In what sense do you think that the example is "invalid"?
The example itself means nothing. What you say about the example is wrong. And even the form is wrong. Therefore, you need to say correct things (the definition of whatever you are trying to define), and use a good example to demonstrate that definition.
I have already detailed, in the previous post and then further in this post, why [both] what you say in definition, and in demonstration of that definition in this example, is wrong. The example definitely does not show specialisation: not by the normal meaning; and not by the perverted meaning.
> > This may be a good point at which to declare the differentiation:
> > - Total = at least two specialisations
> That is mentioned. It's also obvious from the definitions (this is also
> mentioned).
(I did not say that you did not say it. I said that this would be a good point to bring all the variants of that together, in one place.)
> > - Partial = zero; one; or more
>
> No. A (perverted) *specialization cluster* ("partial" applies to
> a cluster) has at least one specialization (reread the definition).
(I was not arguing the definition here, just that there should be a collection. Further, I did not directly argue the definitions, I was responding o your doc, point by point.)
>>>>
Ok, fine. Let’s argue the definitions.
1. “specialisation cluster”
This is the root for all your subsequent definitions.
I can accept the definition if the following changes are implemented
- the name is corrected to [Generalisation Cluster]
- n ≥ 2
- add:
____G contains only elements that are common to {S1, ... Sn}
____Each Sn contains only that which is distinct to it [or makes it distinct]
I have already explained why a set of one is invalid, that the alternative is Optional Attribute.
If you do not accept these suggestions, then your definitions are broken, from the root down. Which is why I did not respond to the definitions before.
2. Generic Entity
Redundant (refer [1] ), can be removed.
As is, change [one] to [two].
As is, “Person is a generic entity” is (a) extraneous to the definition, and (b) utterly false, as explained.
3. Total
I do not accept the definition: what you have defined [loosely] is the superset (union of all subtypes), which is not at all the same as the Basetype, or the Generic that you have defined. Further detail in my Subtype doc.
“This is called subtyping” is therefore false.
The definition contradicts [1].
I would love to help you, but I can’t. In previous version I thought you were trying to define IDEF1X[Complete], but that needs no definition, you can just refer to it. Now you are using [Total]. And of course your definitions have dependencies (hopefully a tree, a DAG). SO I don’t really know what you need to do.
4. Partial
I do not accept the definition of partial, because it is a negation, not a definition: supply a definition. Would be good if you refer to Generic and Category.
(Some previous definition included the null set, this one doesn’t. Ok.)
<<<<
> > - Generic = at least one
> > - Specialisation = zero; one; or more
> You are writing fragments here. "Generic" qualifies "entity"; "Total"
> and "partial" qualify a "specialization *cluster*". A "specialization"
> in my perverted definition is an entity (ok, perhaps "specialized
> entity" would be better). Do not take a noun here and an adjective
> there, otherwise we cannot understand each other.
For God’s sake, man. I am not competing with you, I am only providing feedback as requested.
I don’t see how you can construe that section (four lines, suggesting the collection {Total|Partial|Generic|Category/Specialisation} and the numerical differences between) as a definition. Yes, they are fragments of /your/ definitions. No, they are not suggested as definitions.
> I'm fine if you do not like my choice of terms, and I'm happy to change
> them for better ones. But, even if "specialization" is not used with
> a conventional meaning, it's the definition that matters, and within the
> scope of that document the definition is given.
I do not accept that, because it fosters redefinition of established terms, which is absolutely wrong.
Redefinition is deeply dishonest. Further, it is the start of massive destruction of the terms. I do not let it start. Sane people don’t.
> We could change it to
> "spizzalization" throughout, and the document would be understood in the
> same way (this is a dejà-vu).
No, it would be understood by newbies who know nothing about established terms, and it would be rejected by old hands who are aware of the established terms, for reasons stated immediately above.
There is a separate point. You are hung up on “specialisation”. That is the fragment. It is the concept of Generalisation, that has Specialisation as a component. You have it the wrong way around. Refer to:
__ https://people.cs.vt.edu/~kafura/cs2704/generalization.html
There is yet another point, that I have consistently tried to address through all the versions. I don’t think I succeeded: You are dealing with fragments, which means denial of the atoms to which the fragments belong. I think you have the first part, but not the second part, not the error of the whole method., not the gravity of the error.
> >> All occs of “Specialization cluster”
> > Generalisation cluster.
> I may consider this change.
(Link above, again.)
I said that at the time because I thought you made a minor mistake in naming. I now realise, you are quite anchored to it, it is not a mistake in naming.
Ok then, it is a major mistake in conceptualisation. Because you are addressing the fragments, not the atoms. For definitions, you need to go top-down, atoms to fragments. You are going bottom up, straining at the definition of fragments, while ignoring or paying little attention to the definition of atoms that contain the fragments.
I am not suggesting it is a great example, but since we have it on the table, look at my §3.1 as an example of top-down definition. Eg. I do not explain subtyping from the Subtype [Specialisation], UP to SubtypeSet, UP to Basetype, UP to SubtypeCluster. Whereas you do, you start with Specialisation [a divorced and isolated thing], and name the whole subject Specialisation, in defiance of established Standards (you insist on accepting mutual exclusivity in the Standard [Good], but deny Categorisation [Horrible] ), and therefore, no surprise, run into difficulties.
> >> 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. First, the notion comes from the OO/ORM crowd, quite new, relative to the /RM/ and RDBs. So it must be understood not as a definition of Subtypes (which pre-existed it), but as a perception of Subtypes from that world. Eg. I do not mention it in any of my docs. Eg. it is defined at my doc §3.1#4. In Relational terms, it is simply [is] not [is a]. And we have the essential understanding of Predicates, which OO/ORM does not, to give a full context.
__ Person is an exclusive basetype, one of {PersonMale|PersonFemale}
...
____ Each Person [is] {PersonMale|PersonFemale}
...
____ Pastime [is] {Chess|Cricket|Football}
The converse [one Predicate, read in reverse direction) is always [is] not [is a], and the quantity is 1. That is the Relational side.
__ PersonMale is an exclusive subtype of 1 Person
...
____ Each PersonMale [is] 1 Person
____ Each PersonFemale [is] 1 Person
...
____ Chess is 1 Pastime
2. It is an element from the OO/ORM Generalisation/Specialisation concept, now viewed as a relation. Refer to the Generalisation link above (search for [is-a] and [is a]). All four types.
- Here we have to mention, OO/ORM types are severely myopic (view the entire universe in terms of OO Objects); refuse to accept data science is a distinctlty different science to process science [for the ones who even understand science]; think the Golden Hammer is a principle, instead of understanding it to be a crippling absence of capability; and don’t want to learn any other way, which in every instance provides irrefutable evidence for the /Dunning-Krüger Effect/.
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 they immediately apply their [is a] relation to it.
On the Relational side, it is only the relation from the Basetype to the Subtype. Applying it to any other relation is dead wrong. End of story.
It is far less than Relational Predicates, but the superficial understanding is acceptable to the OO/ORM perspective, they have one hammer only in their toolkit, and they found a thing that definitely; positively; indubitably, looks like a nail. Smells like a nail. As in:
__ Person [is a] PersonMale
Then we can say
__ XOR Person [is a] PersonFemale
__ Pastime [is a] Chess
The converse [no notion of Predicates, just reading the relation in the reverse direction) works as well, just as badly.
As in
__ PersonMale is a Person
__ Chess is a Pastime
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.
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 academics have picked up this silly and superficial notion of OO/Generalisation equals Subtypes. You are the first to venture out of that morass.
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”.
So it is best to use Relational terms only. In the alternative, use OO/ORM, if you must, but keep it strictly for the Basetype::Subtype relation.
Which is why:
__ Suburb [is] or [is a] definitely not a Country
__ Employee [is] definitely not a Person
but (using [is] generically, rather than using the specific Predicates):
__ Suburb is 1 Town
__ Suburb is 1 County
__ Suburb is 1 State
__ Suburb is 1 Country
__ Employee is 1 Person
> >> Total, Partial
> > Yes, I see where you are going, I have no argument. But they are not
> > commonly understood or “commonly accepted definitions”. The words in
> > English are way too general, they cannot be used as specific in an
> > application.
> Any better ones?
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.
Which AFAICS is the introduction/addition of IEEE[Non-Exclusive]. Since all the rest is incoherent, or dependent on an incoherent IDEF1X definition. Refer to my doc §5.3.
Further, if you understand what I said overall about [0 Definitions], the definitions are contrived to obtain what you want, and your way. I am saying, ditch the whole thing, go with the historic path that many implementors have trodden: accept the Standard; define the resolutions; add to it.
> >> Partial specialization cluster: a specialization cluster that is not total.
> >> Partial [generalisation] cluster: a [generalisation] cluster that is not total.
> > In a section for Definition, I would not state that (what it is not). I would state what it is.
> That was to make the definitions shorter. I may change that.
> >> Exclusive specialization cluster: a specialization cluster such that,
> >> at every time, Si \ Sj is the empty set for all i ≠ j.
> >> Exclusive [generalisation] cluster: a [generalisation] cluster such
> >> that, at every time, Si \ Sj is the empty set for all i ≠ j.
>
> > Great for a theoretician. What about saying “one of”, so that
> > implementors can understand it.
>
> The audience of my document has no problem understand that. It would
> consider "one of" ambiguous.
I don’t see how “one of” is ambiguous. I married one of many possible women, it was final and unambiguous, even the other women agree. Actually, all women who are not corrupted agree. I redeemed a coupon for one free meal, at a restaurant that had ~20 full meals; ~6 half meals; and ~10 non-meals. No discussion or argument. Perhaps I am not “educated” enough.
But I will skip that, it is not as important as other points ...
In my previous post I made another point elsewhere, which I did not repeat about this item. I will now.
1. That is a backwards definition. Why don’t you state it forwards, in terms of what it is. Don’t get me wrong, a set theory based definition is great.
2. Why make a definition relative to the empty set (treasured by academics, does not exist). Yes, I am aware that it is common practice, but it is still crazy. Why say, a dog crossed with a cat produces a result of nothing. Why not say, a species cannot be crossed with any other species.
3. Why not use the word “exclusive”. The IDEF1X definition does.
> >> A basetype is always a generic entity, but a generic entity is not
> >> necessarily a basetype
> >
> > Cliché, cabalist nonsense, not fit for a technical document. It means
> > nothing: a specialisation *IS ALWAYS** -<is>- relative to its parent,
> > and a generic *IS NOT ALWAYS** -<is>- any of its specialisations.
>
> There are too many "is" in this post. I am really confused.
Sorry.
Not worth expanding, because we have addressed it at a higher level in this (not the previous) post.
It remains to say, do not relate basetype to generic or subtype to category unless they are actually related (they are not) ... but if you do, do it properly using a grid, so that both similarities and differences can be understood. Stay away from silly expressions. Especially if your audience finds “one” ambiguous.
> > Where you are trying to differentiate Basetype vs Generic, just state
> > that: Basetype is Total; Generic is {Total|Partial}
>
> It's not only that. According to my definition, that is the only
> difference.
Those two sentences appear to contradict.
Back to the subject, just state the differences, all of them.
> >> 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. And you are denying the defined alternative. Think about it.
The challenge: define the commonality in the set of one, that can be extracted into the Basetype. And define the remainder that is distinct.
> > Doc updated.
> > - I have added §1.6 in response to your V4 diagrams, but the argumentation is in this post.
> > - Date at the bottom of each page informs you if it has been updated.
> >
> > ____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
> The qualitative figures are not essential for understanding, just an
> addition for the visually inclined;
I think that is great. Theoreticians are deeply attached to a text-only set of theories; laws; and definitions. Decades ago, when I sent IDEF1X data models to The Torrid Manifesto, and even Fagin, they were shocked and did not understand it. Semantic, yes, but they had really weird notions of “semantic”.
It is really limiting to stick to text-only in the context of a world has moved into full-blown graphics. Same as sticking to text-only terminals in a world of GUIs.
I don’t accept the new agree notion of Left/Right brain, but I do accept the papers about it from Cognitive science. All humans are visually inclined, in fact it is the single most important and single most biologically supported (think organs; tissue; processing seat; etc) faculty. No surprise, the forces of evil have a huge industry that exploits this fact, precisely because it is so powerful.
So somewhere in the region of 4-10% of brain power, Left Hemisphere, performs serial functions, like a perfect Turing complete computer. The text processor. Ok, fine, don’t teach using anything else.
For the rest of us, eg. Codd; Brown; and others, IN ADDITION, we use the 90-96% brain power, the Right Hemisphere, the visual. It takes all the info in, and produces a single result {Comprehended|NotComprehended} rather instantly. But it can’t provide an explanation: for that you have to switch to the Left Hemisphere, and process Logic; text.
If you understand that, then you will understand that the pictures must be correct, bad pictures or incorrect use of a standard method [eg. Venn] means the picture will not be understood. This is why I have spent so much energy in the early days, improving my diagram styles.
In any case, it is your proposal, your doc. My suggestions are intended as assistance, you can take it or leave it.
> You would not have a NotEmployee or NotSecretaryAndNotConsultant entity
> in your database, would you?
Definitely not. I don’t need to store non-facts. No code either.
I was implying, you would need at least code to support you zero set. But gratefully you have eliminated it.
The issue that I was pointing out, is not in the database, but in the Venn sets. A Legal Venn diagram requires that all sets are shown. I provided those Venn diagrams, so that the sets can be fully understood (with the caveat that Venn diagrams are *not* good for that purpose, but commonly used anyway, and therefore commonly incorrect.
Cheers
Derek
> 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.
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.
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.
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?
- 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").
> > 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.
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).
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.
> >> “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.
- 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].
Since you rely on IDEF1X[Incomplete] so much, state that too, and then build on it.
You can’t rely on something, and deny it at the same time (refer to my argument re atheism above).
> 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.
No.
1. Your definitions are fragments. That only stand in the context of denial of the atoms from which you extracted said fragments.
2. Then you either combine the fragments, and make something new, which lacks integrity,
3. Or make connections between the fragments, where there is no connection between the Atoms to which the said fragments belong.
It is a grand contrivance.
I am saying, do not deny the reality of IDEF1X definitions; do not deny the reality of Atoms. If your definitions depend on anything, declare those things [no definition or redefinition], and the dependency. Then give your definition for the new thing only. The whole of which will then be clear to any reader { strict IEEE | loose IDEF1X | tight IDEF1X }.
> >> Specialization [...]
>
> > But: - this sort of redefinition makes it (both the error of
> > a combined form, and the definition) absurd.
> > - a redefinition of an existing, well-established term has to be
> > rejected outright.
> >
> > The example given is strictly *NOT* a specialisation in the sense that
> > people would understand, therefore you are perverting that sense, in
> > order to generalise it, in order to include Incomplete.
>
> Is there any other term you would accept for that concept? Or is the
> concept itself absurd?
(Which concept ? I will go through the possibilities, in order to avoid a round of back-and-forth. Sorry if it is long.)
> > 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?
1. Here, my comments pertained immediately to Specialisation, and your redefinition of it.
- you can’t, it is already well-established
--- you particularly can’t deny the definition of the atom [ Concept{Generalisation::Specialisation} ] and then use fragments of it [Specialisation alone, minus Generalisation]
--- and then a fragment of [Specialisation alone]
--- and then a novel definition under the head [Specialisation] which is in fact a redefinition
- accept it and move on
- use it as it is defined in the Standard, which is the atom [ Concept{Generalisation::Specialisation} ]
2. The IDEF1X Concept Categorisation{Generic::Category}
That in itself is no problem, it is just new words for Subtype{Basetype::Subtype}, the problem is the new classification {Complete|Incomplete}: as I have detailed, [Incomplete] is totally invalid in a database of any kind, invalid by definition in a Relational database. Again, it is not [Incomplete] as a member that can be eliminated ]and [Complete] retained[ because it is the classification that defined [Incomplete] that is in error, so the classification has to be rejected, neither member can be retained.
As determined; condemned; and published by me in 1993. As determined and rejected by several high-end suppliers that I am familiar with.
Eg. I relied on the pre-existing IEEE, to invalidate the then novel IDEF1X definitions. Logic invalidates it as well.
And to be complete, I give the logical alternative: it is an Optional Attribute, not a Subtype classification of any kind.
So yes, the IDEF1X classification {Complete|Incomplete} under its Concept Categorisation{Generic::Category} is absurd.
3. Your reliance on [Incomplete]
Since [2] is absurd, anything derived from it, anything relying on it, is absurd.
Anyone who persists in [2][3], which means they are denying the logical alternative, which means they are denying logic, is straining at the gnat and swallowing the camel, insisting on the fragments while denying the atom.
4. The null set
At the root of it, I won’t call it metaphysical, but meta-conceptual, you are relying on the concept of the empty set. It is a total absurdity. It does not exist in reality.
My challenge, to provoke you to think about the concept you are proposing: give me an example of the empty set from reality. (By all means, it is a very, very necessary abstraction in theory, but it does not exist in reality, it can be dismissed by practitioners). This is a boundary that you, a schooled academic, needs to cross, and I am trying to get you o do so consciously, without making academics wrong for having a null set. (I do make them wrong for venerating it, or for imposing it on reality where it does not and cannot exist.)
Any reliance on the null set (in fact on null) is an absurdity.
> > 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.
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).
That is a perversion. The actual Predicates declare no such thing. End of story. Perversions are always stated backwards (the hallmark of schizophrenia). This one fails even if stated forwards:
__The set of Employee is a subset of the set of Person, therefore Employee is a specialization of Person.
- you have equated [specialisation] to [subset]
- it is absurd, hysterical
2. Now to deal with the perversion, God help me:
> > By the perverted definition, *ANY* Dependent entity is
> > a specialisation of the parent.
By the perverted definition, any subset is a specialisation of the parent set.
> > a specialisation of the parent.
It produces nonsense such as:
__Suburb is a specialisation of Town
__Suburb is a specialisation of Country
__PartyAddress is a specialisation of Party
__OrderSale is a specialisation of Party
Further, the actual Predicates refute the absurd proposition.
> >> proper subset
> > Since when is the empty set a proper subset ??? The freaky fantasy is
> > not even a set, let alone a proper subset.
>
> "Proper" has a very specific technical meaning in mathematics, and set
> theory in particular. It does not mean what you think it means.
(Mathematics is not science, it is a formal language, an articulation of Logic. Mathematics cannot do or say or prove anything, it is the person, using mathematics, to say or do whatever. All that can truly be faulted in mathematics is incorrect use of the formalism, or deformation. The subject matter is the thing, the article, that one proposes using mathematics, that may be true or false. Thus it quite possible to write a proposal in perfect mat that a pig can fly, and to write another proposal in perfect math that a pig cannot fly. The former proposal fails the laws of physics, and deems the author an idiot, yet a perfectly defined one.)
Likewise, logic is the form, your proposal is the matter, it fails logic.
- If the set has no members, it is not a set (it is a nothing and non-thing, null), it cannot have a Proper Subset
- If the set has one member, it can have no Proper Subset (there is no possible subset).
> Anyway, the definition could in fact be stricter by saying "a proper
> non-empty set".
> >> Generic entity: an entity that has at least one specialization. In
> >> the example above, Person is a generic entity.
>
> > The definition is fine, but the example is horrendous, supply a valid example.
>
> In what sense do you think that the example is "invalid"?
I have already detailed, in the previous post and then further in this post, why [both] what you say in definition, and in demonstration of that definition in this example, is wrong. The example definitely does not show specialisation: not by the normal meaning; and not by the perverted meaning.
> > This may be a good point at which to declare the differentiation:
> > - Total = at least two specialisations
> That is mentioned. It's also obvious from the definitions (this is also
> mentioned).
> > - Partial = zero; one; or more
>
> No. A (perverted) *specialization cluster* ("partial" applies to
> a cluster) has at least one specialization (reread the definition).
>>>>
Ok, fine. Let’s argue the definitions.
1. “specialisation cluster”
This is the root for all your subsequent definitions.
I can accept the definition if the following changes are implemented
- the name is corrected to [Generalisation Cluster]
- n ≥ 2
- add:
____G contains only elements that are common to {S1, ... Sn}
____Each Sn contains only that which is distinct to it [or makes it distinct]
I have already explained why a set of one is invalid, that the alternative is Optional Attribute.
If you do not accept these suggestions, then your definitions are broken, from the root down. Which is why I did not respond to the definitions before.
2. Generic Entity
Redundant (refer [1] ), can be removed.
As is, change [one] to [two].
As is, “Person is a generic entity” is (a) extraneous to the definition, and (b) utterly false, as explained.
3. Total
I do not accept the definition: what you have defined [loosely] is the superset (union of all subtypes), which is not at all the same as the Basetype, or the Generic that you have defined. Further detail in my Subtype doc.
“This is called subtyping” is therefore false.
The definition contradicts [1].
I would love to help you, but I can’t. In previous version I thought you were trying to define IDEF1X[Complete], but that needs no definition, you can just refer to it. Now you are using [Total]. And of course your definitions have dependencies (hopefully a tree, a DAG). SO I don’t really know what you need to do.
4. Partial
I do not accept the definition of partial, because it is a negation, not a definition: supply a definition. Would be good if you refer to Generic and Category.
(Some previous definition included the null set, this one doesn’t. Ok.)
<<<<
> > - Generic = at least one
> > - Specialisation = zero; one; or more
> You are writing fragments here. "Generic" qualifies "entity"; "Total"
> and "partial" qualify a "specialization *cluster*". A "specialization"
> in my perverted definition is an entity (ok, perhaps "specialized
> entity" would be better). Do not take a noun here and an adjective
> there, otherwise we cannot understand each other.
I don’t see how you can construe that section (four lines, suggesting the collection {Total|Partial|Generic|Category/Specialisation} and the numerical differences between) as a definition. Yes, they are fragments of /your/ definitions. No, they are not suggested as definitions.
> I'm fine if you do not like my choice of terms, and I'm happy to change
> them for better ones. But, even if "specialization" is not used with
> a conventional meaning, it's the definition that matters, and within the
> scope of that document the definition is given.
Redefinition is deeply dishonest. Further, it is the start of massive destruction of the terms. I do not let it start. Sane people don’t.
> We could change it to
> "spizzalization" throughout, and the document would be understood in the
> same way (this is a dejà-vu).
There is a separate point. You are hung up on “specialisation”. That is the fragment. It is the concept of Generalisation, that has Specialisation as a component. You have it the wrong way around. Refer to:
__ https://people.cs.vt.edu/~kafura/cs2704/generalization.html
There is yet another point, that I have consistently tried to address through all the versions. I don’t think I succeeded: You are dealing with fragments, which means denial of the atoms to which the fragments belong. I think you have the first part, but not the second part, not the error of the whole method., not the gravity of the error.
> >> All occs of “Specialization cluster”
> > Generalisation cluster.
> I may consider this change.
I said that at the time because I thought you made a minor mistake in naming. I now realise, you are quite anchored to it, it is not a mistake in naming.
Ok then, it is a major mistake in conceptualisation. Because you are addressing the fragments, not the atoms. For definitions, you need to go top-down, atoms to fragments. You are going bottom up, straining at the definition of fragments, while ignoring or paying little attention to the definition of atoms that contain the fragments.
I am not suggesting it is a great example, but since we have it on the table, look at my §3.1 as an example of top-down definition. Eg. I do not explain subtyping from the Subtype [Specialisation], UP to SubtypeSet, UP to Basetype, UP to SubtypeCluster. Whereas you do, you start with Specialisation [a divorced and isolated thing], and name the whole subject Specialisation, in defiance of established Standards (you insist on accepting mutual exclusivity in the Standard [Good], but deny Categorisation [Horrible] ), and therefore, no surprise, run into difficulties.
> >> 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?
__ Person is an exclusive basetype, one of {PersonMale|PersonFemale}
...
____ Each Person [is] {PersonMale|PersonFemale}
...
____ Pastime [is] {Chess|Cricket|Football}
The converse [one Predicate, read in reverse direction) is always [is] not [is a], and the quantity is 1. That is the Relational side.
__ PersonMale is an exclusive subtype of 1 Person
...
____ Each PersonMale [is] 1 Person
____ Each PersonFemale [is] 1 Person
...
____ Chess is 1 Pastime
2. It is an element from the OO/ORM Generalisation/Specialisation concept, now viewed as a relation. Refer to the Generalisation link above (search for [is-a] and [is a]). All four types.
- Here we have to mention, OO/ORM types are severely myopic (view the entire universe in terms of OO Objects); refuse to accept data science is a distinctlty different science to process science [for the ones who even understand science]; think the Golden Hammer is a principle, instead of understanding it to be a crippling absence of capability; and don’t want to learn any other way, which in every instance provides irrefutable evidence for the /Dunning-Krüger Effect/.
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 they immediately apply their [is a] relation to it.
On the Relational side, it is only the relation from the Basetype to the Subtype. Applying it to any other relation is dead wrong. End of story.
It is far less than Relational Predicates, but the superficial understanding is acceptable to the OO/ORM perspective, they have one hammer only in their toolkit, and they found a thing that definitely; positively; indubitably, looks like a nail. Smells like a nail. As in:
__ Person [is a] PersonMale
Then we can say
__ XOR Person [is a] PersonFemale
__ Pastime [is a] Chess
The converse [no notion of Predicates, just reading the relation in the reverse direction) works as well, just as badly.
As in
__ PersonMale is a Person
__ Chess is a Pastime
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.
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 academics have picked up this silly and superficial notion of OO/Generalisation equals Subtypes. You are the first to venture out of that morass.
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”.
So it is best to use Relational terms only. In the alternative, use OO/ORM, if you must, but keep it strictly for the Basetype::Subtype relation.
Which is why:
__ Suburb [is] or [is a] definitely not a Country
__ Employee [is] definitely not a Person
but (using [is] generically, rather than using the specific Predicates):
__ Suburb is 1 Town
__ Suburb is 1 County
__ Suburb is 1 State
__ Suburb is 1 Country
__ Employee is 1 Person
> >> Total, Partial
> > Yes, I see where you are going, I have no argument. But they are not
> > commonly understood or “commonly accepted definitions”. The words in
> > English are way too general, they cannot be used as specific in an
> > application.
> Any better ones?
Yes, it is broken. So then you have to first define and apply the resolutions.
Then define only your new proposal.
Which AFAICS is the introduction/addition of IEEE[Non-Exclusive]. Since all the rest is incoherent, or dependent on an incoherent IDEF1X definition. Refer to my doc §5.3.
Further, if you understand what I said overall about [0 Definitions], the definitions are contrived to obtain what you want, and your way. I am saying, ditch the whole thing, go with the historic path that many implementors have trodden: accept the Standard; define the resolutions; add to it.
> >> Partial specialization cluster: a specialization cluster that is not total.
> >> Partial [generalisation] cluster: a [generalisation] cluster that is not total.
> > In a section for Definition, I would not state that (what it is not). I would state what it is.
> That was to make the definitions shorter. I may change that.
> >> Exclusive specialization cluster: a specialization cluster such that,
> >> at every time, Si \ Sj is the empty set for all i ≠ j.
> >> Exclusive [generalisation] cluster: a [generalisation] cluster such
> >> that, at every time, Si \ Sj is the empty set for all i ≠ j.
>
> > Great for a theoretician. What about saying “one of”, so that
> > implementors can understand it.
>
> The audience of my document has no problem understand that. It would
> consider "one of" ambiguous.
But I will skip that, it is not as important as other points ...
In my previous post I made another point elsewhere, which I did not repeat about this item. I will now.
1. That is a backwards definition. Why don’t you state it forwards, in terms of what it is. Don’t get me wrong, a set theory based definition is great.
2. Why make a definition relative to the empty set (treasured by academics, does not exist). Yes, I am aware that it is common practice, but it is still crazy. Why say, a dog crossed with a cat produces a result of nothing. Why not say, a species cannot be crossed with any other species.
3. Why not use the word “exclusive”. The IDEF1X definition does.
> >> A basetype is always a generic entity, but a generic entity is not
> >> necessarily a basetype
> >
> > Cliché, cabalist nonsense, not fit for a technical document. It means
> > nothing: a specialisation *IS ALWAYS** -<is>- relative to its parent,
> > and a generic *IS NOT ALWAYS** -<is>- any of its specialisations.
>
> There are too many "is" in this post. I am really confused.
Not worth expanding, because we have addressed it at a higher level in this (not the previous) post.
It remains to say, do not relate basetype to generic or subtype to category unless they are actually related (they are not) ... but if you do, do it properly using a grid, so that both similarities and differences can be understood. Stay away from silly expressions. Especially if your audience finds “one” ambiguous.
> > Where you are trying to differentiate Basetype vs Generic, just state
> > that: Basetype is Total; Generic is {Total|Partial}
>
> It's not only that. According to my definition, that is the only
> difference.
Back to the subject, just state the differences, all of them.
> >> 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.
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. And you are denying the defined alternative. Think about it.
The challenge: define the commonality in the set of one, that can be extracted into the Basetype. And define the remainder that is distinct.
> > Doc updated.
> > - I have added §1.6 in response to your V4 diagrams, but the argumentation is in this post.
> > - Date at the bottom of each page informs you if it has been updated.
> >
> > ____https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
> The qualitative figures are not essential for understanding, just an
> addition for the visually inclined;
It is really limiting to stick to text-only in the context of a world has moved into full-blown graphics. Same as sticking to text-only terminals in a world of GUIs.
I don’t accept the new agree notion of Left/Right brain, but I do accept the papers about it from Cognitive science. All humans are visually inclined, in fact it is the single most important and single most biologically supported (think organs; tissue; processing seat; etc) faculty. No surprise, the forces of evil have a huge industry that exploits this fact, precisely because it is so powerful.
So somewhere in the region of 4-10% of brain power, Left Hemisphere, performs serial functions, like a perfect Turing complete computer. The text processor. Ok, fine, don’t teach using anything else.
For the rest of us, eg. Codd; Brown; and others, IN ADDITION, we use the 90-96% brain power, the Right Hemisphere, the visual. It takes all the info in, and produces a single result {Comprehended|NotComprehended} rather instantly. But it can’t provide an explanation: for that you have to switch to the Left Hemisphere, and process Logic; text.
If you understand that, then you will understand that the pictures must be correct, bad pictures or incorrect use of a standard method [eg. Venn] means the picture will not be understood. This is why I have spent so much energy in the early days, improving my diagram styles.
In any case, it is your proposal, your doc. My suggestions are intended as assistance, you can take it or leave it.
> You would not have a NotEmployee or NotSecretaryAndNotConsultant entity
> in your database, would you?
I was implying, you would need at least code to support you zero set. But gratefully you have eliminated it.
The issue that I was pointing out, is not in the database, but in the Venn sets. A Legal Venn diagram requires that all sets are shown. I provided those Venn diagrams, so that the sets can be fully understood (with the caveat that Venn diagrams are *not* good for that purpose, but commonly used anyway, and therefore commonly incorrect.
Cheers
Derek
LP
Apr 21, 2021, 4:27:56 PM4/21/21
to
On 2021-04-20, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>anything derived from it, anything relying on it, is absurd.
> [...]
>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.
>
> 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
> 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.
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;
>define the resolutions; add to it.
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
Derek Ignatius Asirvadem
Apr 21, 2021, 4:39:53 PM4/21/21
to
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. [...]
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
> 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.
__ 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.
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?
>
>
> 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.
>
> 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”.
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
Derek Ignatius Asirvadem
Apr 21, 2021, 6:40:00 PM4/21/21
to
> On Thursday, 22 April 2021 at 06:27:56 UTC+10, LP wrote:
> > 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
> > 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.
> > 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?
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
Derek Ignatius Asirvadem
Apr 22, 2021, 5:27:03 AM4/22/21
to
> On Thursday, 22 April 2021 at 06:27:56 UTC+10, LP wrote:
> On Thursday, 22 April 2021 at 06:39:53 UTC+10, Derek Ignatius Asirvadem wrote:
Posts crossed again, minutes apart !
Cheers
Derek
Derek Ignatius Asirvadem
Apr 28, 2021, 2:28:45 AM4/28/21
to
> On Thursday, 22 April 2021 at 08:40:00 UTC+10, Derek Ignatius Asirvadem wrote:
> > On Thursday, 22 April 2021 at 06:27:56 UTC+10, LP wrote:
> >
> > Only one minor detail: I have tried to track the origin of the IEEE
> > symbols for subtyping, but I don't seem to be able to find much
> > information. AFAIK, Information Engineering originally used **nested boxes**
> > On Thursday, 22 April 2021 at 06:27:56 UTC+10, LP wrote:
> >
> > Only one minor detail: I have tried to track the origin of the IEEE
> > symbols for subtyping, but I don't seem to be able to find much
> > (derived from Barker's notation?).
>
> [ explanation, skipped ]
>
>
> The nested boxes was classic Hierarchic Paradigm ...
>
> Nested boxes meant the designer was using a HDBMS ...
>
> An Hierarchic file consisted of one parent type-of-record, and many child types-of-record ... implemented as a continuous series of records, from the parent record through one bunch of child records; then the next bunch; then the next parent; etc ...
>
> Whereas in the NDBMS, each type-of-record was a separate file, and we had two types of file: Master (key access) and Variable (linked-list chain from the Master). Therefore no nested boxes.
__Nested boxes__ in pre-Relational File Definition diagrams, is not to be confused with:
> Whereas in the NDBMS, each type-of-record was a separate file, and we had two types of file: Master (key access) and Variable (linked-list chain from the Master). Therefore no nested boxes.
__Nested Sets__
An abortion, straight from hell. A Record Filing System within a Record Filing system. Not only does this generate masses of duplication and break Normalisation rules, this fixes the records in the filing system in concrete.
Moving a single node requires the entire affected part of the tree to be re-written. Beloved of the Date, Darwen and Celko types.
The MS HIERARCHYID Datatype does the same thing. Gives you a mass of concrete that has to be jack-hammered and poured again, every time a node changes. Perfect for beginners who think that Lego is an implementation method in SQL containers.
Cheers
Derek
Derek Ignatius Asirvadem
Jun 10, 2021, 10:21:18 AM6/10/21
to
The discussion document. Page 8 has a couple of errors fixed. Added Hunter.
__
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
Cheers
Derek
__
https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/IDEF1X/Nicola%20IDEF1X%202.pdf
Cheers
Derek
0 new messages