> On Thursday, 10 June 2021 at 02:43:14 UTC+10, Nicola wrote:
> Among the rest, the model declares:
>
> Person is 0-to-1 Employee
>
> The textual predicates do not state it explicitly, but the model also
> declares the converse relationship:
>
> Employee is 1 Person
>>>> To be Clear
Yes, of course.
First we have First Order Predicate Calculus.
We know that we can define anything in the universe, in FOPC terms.
The /Relational Model/ is founded on FOPC.
Therefore we know that we can define anything in the universe, in the RM in Relational terms, which is FOPC terms.
SQL is the current rendition of the Data Sublanguage defined in the /RM/, it fulfills the stated goals. (Non-compliant program suites that fraudulently use the label “sql” do not.)
IDEF1X merely renders FOPC[ RM[ Predicates ] ] diagrammatically.
Absolutely every Predicate [that is used] is rendered diagrammatically.
__Ok, you need my IDEF1X Extension for Additional Constraints; etc
Absolutely every Predicate [that is used] can be determined directly from the diagram.
Just as an FK declaration is declared only in the child, but very obviously and laughably “two-way” or more hilariously “bidirectional”, it can be read from the parent (reference) to the child (referent). If I tell you that Sally is Fred’s daughter, you know from that single Fact that Fred is Sally’s father.
Thus any Binary Predicate can be read “two ways”, and only the *Verb*, not the full text, is required on the relation line, because each of the binaries is diagrammatically connected. Usually only the parent->child *Verb* is shown, and the converse is simple enough to determine [by reversal of the elements] by the reader.
My Doc
I have not given all Predicates in text form, only the ones that I thought may be relevant, that may be argued.
*All the Predicates are in the diagram*.
<<<<
> Besides:
>
> Employee is an exclusive basetype, one of {FullTime, Consultant}
>
> Your predicates do not state is explicitly, but the verbal phrase for
> exclusive subtyping is "is". So, the model also declares:
>
> EmployeeFullTime is 1 Employee
> EmployeeConsultant is 1 Employee
>
> "Each Basetype and Subtype pair should be perceived as a single logical
> unit" (same doc., p. 5).
Yes, of course. Keep in mind, that is for the purpose of understanding what, in heavens name, is a Subtype.
>>>>
Now before we get into the next set of Qs. Stop and take a breath. Consider this. As an academic, you are heavily (and I mean heavily) programmed into thinking in terms of Fragments (as opposed to Atoms); single level (as opposed to multiple); simple idiotic truths (as opposed to a chain of truth); dis-integrated elements (as opposed to integration); ugliness (as opposed to beauty). That is the normal, you people have had fifty years of it, every single textbook.
By the Grace of God, you, a single academic has left the morass of pig poop, and a whole new world of the Real Relational Model/, and how it is really implemented, has opened up. But please understand, you are approaching it in small steps (transmission in increments), you do not have the privilege of a paid lecture or course from me (full consolidated transmission of the subject matter).
The issue you are experiencing here is, you have approached the beauty, which is the integration, of truth, here FOPC[ RM[ Predicate ] ], but due to your programmed manner of thinking, you are limited to seeing only the Fragments, and not the whole. So take a breath, rub your eyes, renounce the schizophrenic filth taught by (Date; Darwen; Fagin; Abitebul; Hull; Viannu; Navarthe; etc; and all “professors” who use their textbooks.
Language is everything.
Please, erase all your pre-conceived notions of what FOPC and the /RM/ is, and just read and think, as a child does when reading a new book.
You are used to having filth like Lady Gaga shoved down your throat as “beauty”. Vomit all that out, and get ready to meet Sophia Loren; Grace Kelly; Gina Lollobrigida.
<<<
> So, it's fair to say, e.g., that an
> EmployeeFullTime has a JobTitle and an EmployeeDate, and I can sensibly
> query for the job titles of all full time employees. JobTitle and
> EmployeeDate are descriptors of EmployeeFullTime.
Yes.
Not “fair to say”, but the Predicates declare it (given that you understood the above].
> But Person and Employee should not be perceived as a single logical
> unit: as per your discussion in §3, that would be incoherent.
Why ? How is it it incoherent ?
(The Basetype::Subtype relation must not be conflated with the Fact::OptionalAttribute, each has to be understood separately. And yet, of course, there are common elements. Which is why I labour to differentiate them, even in my simplest docs.)
Certainly not a *single* logical *unit*, as per when trying to understand Subtypes.
But in the ordinary logical sense of two sets connected by a Foreign Key.
A - Entity Level
Person is independent. A Person is optionally an Employee.
B - Attribute Level
Person is an Atom. The row contains its mandatory attributes. The optional row contains its optional attributes. Which in this case, renders it a new Fact: Employee. Person::Employee is a Molecule.
> So, does
> an Employee have a NameLast or a BirthDate?
Absolutely.
Where else, in heavens name, would an Employee get his NameLast or a BirthDate from.
> If so, what in the model
> does entitle me to state that?
The Predicates.
Again, a Binary Predicate can be read “two ways”. I will read it from the child to the parent.
1.
First, for clarity, this:
____Employee is identified by, and dependent on, 1 Person
combines two Binary Predicates that have the same parent and child, plus it Existential Predicate, the explicit Predicates are:
__1_Employee is identified by 1 Person
__E_Employee is dependent (whereas Person is independent)
__2_Employee is dependent on 1 Person
And yes, the Predicates can all be determined directly from the model.
2.
This is an error:
__Person is described by ( SexCode, Title )
It should be:
__Person is described by ( NameLast, NameFirst, Initial, BirthDate, BirthCountryCode, BirthPlace, Sex, Title )
But the error is harmless here.
3.
Now please stop and contemplate Codd’s 3NF, there is only Full Functional Dependency (the fragmentation of it by the pig poop eaters is condemned).
__Every domain (attribute) is functionally dependent on the Key; the whole Key; and nothing but the Key.
Key=Fact
Fact=Key
We can *count* on the fact that, from the child, any attribute in a parent hierarchy is 1::1.
4.
The answer. Since:
__Employee is 1 Person
____Person is described by ( NameLast, NameFirst, Initial, BirthDate, BirthCountryCode, BirthPlace, Sex, Title )
Therefore:
__Employee is described by Person( NameLast, NameFirst, Initial, BirthDate, BirthCountryCode, BirthPlace, Sex, Title )
__EmployeeFullTime is 1 Employee
____Employee is 1 Person
Therefore:
__EmployeeFullTime is described by Person( NameLast, NameFirst, Initial, BirthDate, BirthCountryCode, BirthPlace, Sex, Title )
Do *NOT* perceive Employee or EmployeeFullTime as a Fragment, isolated from its context.
Do perceive any entity in its full context only:
__Employee as Person-Employee;
__EmployeeFullTime as Person-Employee-EmployeeFullTime
Again, not as a single logical unit, but as ordinary logic, a chain of existential dependency.
5.
Consider the example Order Advanced DM
__
https://www.softwaregems.com.au/Documents/Documentary%20Examples/Order%20DM%20Advanced.pdf
the Country..Street hierarchy.
Why is Country.Fullname *NOT* 1::1 for each Suburb row ?
When does a Town row *EVER* have [exist in] an other-than-one Country; or State; etc ?
> For comparison, suppose that there is also a Hunting License entity, and
> a relationship between Person and Hunting License:
>
> Person has 0-to-1 Hunting License
Ok, let’s say:
- the PK is the same as Person (must needs be)
- the attributes are ( CountryCode, StateCode, HuntingLicenceNo, ExpiryDate, IsRevoked )
> Certainly, I would not say that a Hunting License has a NameLast or
> a BirthDate or that NameLast and BirthDate are descriptors of Hunting
> License.
Why not ?
(I am assuming you are not being silly about the wording, but chasing meaning; declarative meaning.)
A Hunting licence is not a piece of paper gambolling around in the Tyrolian Alps (Fragment).
__If it were a Fragment, sure, you should not say that
__But a HuntingLicence is not a Fragment
A Hunting licence is a /Power to Act/, that is given to a Person (not animal, not thing), it does not exist independently, it exists only in the context of Person.
Predicates, as modelled:
__HuntingLicence is dependent
__HuntingLicence is dependent on 1 Person
__HuntingLicence is identified by 1 Person
__HuntingLicence is 1 Person
Strictly, the entity is not HuntingLicence but Person-HuntingLicence.
Which is the real world, HuntingLicence is not a piece of paper (the Physical), but an option of Person (the Logical, the Real). (Or /a/ progression of Person in the fullness of definition of Person).
Why would a Person who is a Hunter (or Fisher or other) *NOT* have the attributes that a generic Person has ???
Why would a County that has a CountySportsField *NOT* have the State-attributes that all Counties in the State have ?
Since:
__HuntingLicence is 1 Person
____Person is described by ( NameLast, NameFirst, Initial, BirthDate, BirthCountryCode, BirthPlace, Sex, Title )
Therefore:
__HuntingLicence is described by Person( NameLast, NameFirst, Initial, BirthDate, BirthCountryCode, BirthPlace, Sex, Title )
----
Behold, the beauty of the chain of Predicates.
Impossible under the anti-Relational freak show promoted by the pig poop eaters, characterised by RecordIDs presented as “keys”, marketed as “relational”.
----
Trivially, a SELECT command is merely a test, of a chain of Predicates. One can add attributes obtained anywhere in the chain, and then it becomes a projection.
With *Relational Keys*, one obtains Access Path Independence. That means the chain does *NOT* have to be navigated link-by-link, as demanded with RecordID files.
> We can *count* on the fact that, from the child, any attribute in a parent hierarchy is 1::1.
T-SQL
SELECT Name, -- Country.Name
StateCode,
Town
FROM Town T
JOIN Country C ON
T.CountryCode = C.CountryCode
WHERE Town LIKE ( “Napoli%”, “Naples%” “Neapolit%” )
Cheers
Derek