From Newsgroup: comp.databases.theory

On Monday, 30 December 2019 20:42:53 UTC+11, Nicola wrote:

On 2019-12-29, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

Fig 3.3 is missing.

All figures are missing, apparently. Maybe, this is a better document:

https://www.fiafnet.org/images/tinyUpload/E-Resources/Commission-And-PIP-Resources/CDC-resources/20160920%20Fiaf%20Manual-WEB.pdf

It's inspired by FRBR, but it is specific for movies. It has some
diagrams.

Yes, that is the best doc.
The material to focus on would be p17 to p81, ch1 to ch3. But there are problems.
a. If that were written by a high-end user, as a formal or informal User Requirement doc, I would give them a 10 out of 10. Great start, thanks, now it is over to me. Wherein I would model the data (erect a formal data model, several iterations, in communication with the user, etc) and write a Technical Requirement doc to accompany the data model if necessary. At that stage the DM would be what you guys call "logical", and much more, because the real Logical is unknown to you.
b. But it is not. It is a Technical doc that is supposed to be written by a Technical person (film industry technical as opposed to IT technical), for use as a "standard", for an implementation. We have previously agreed that it is a set of considerations and an intent.
c. It is seriously deficient. I would give it 2 out of 10 as a User Technical doc, 0 out of 10 as a Standard. From a technical perspective (attempting a Relational data model [which is the best way to understand the data]; trying to make sense of what they are requiring), it is incoherent.
Let's say that my Key for Movie Title at this stage (some iteration of the DM that is not yet complete), based on the doc, is as follows. (I know it is not correct yet, that is not the point being argued here):
Work.PK ( CountryCode, Year, Creator, Title )
Now take one eg. p22 -o 1.1.1 Boundaries between Works
1. The examples given (to differentiate Works) that are mere changes to one or more component of the Key = Good Thing, confirms the Key. The other examples suck dead bears.
//Change in footage and/or changes in continuity (primary editing)// & the examples given
2. Um. Footage exists only in a Manifestation, it cannot exist in a Work (intellectual concept, not yet real)
//different language versions shot at the same time, released simultaneously//
3. Different Languages is not a Work, because a human can conceive of something in just one language (those who conceive of things in multiple languages can be safely assigned to an asylum). The Language would be the Language of the Country or of the Creator.
Nevertheless, I am willing to accept that multiple languages is an INTENT of the Work.
4. Shooting is a Manifestation (realisation), not a Work.
5. Release is a Manifestation (realisation), or even an Item, not a Work.
Et cetera. I have given just one example of incoherence, there are many such issues.
The same set of problems (incoherence) exists at each of the four Levels.
----
In the normal, real world case, following [a][b][c], I would give the customer a presentation of such errors, the result of which is:
d. either that he would retain responsibility and flick it back to his technical people to produce a Technical doc,
e. or he would commission me to produce a Technical doc that is resolved; free of errors; coherent. Which I would do side-by-side with a DM, in communication with the key users.
Obviously that is not going to happen here. Keeping in mind the central question in this thread, and not shirking the work required, I suggest the following.
- I play both roles, User and Data Modeller
- I make decisions about what each of Work; Variant; Manifestation; Item, actually is (a real world implementation). This will not be arbitrary decisions, but sensible ones
- which will be reflects in the DM, as well as in the conversation in this thread
- however that leaves a rather large gap for argument, and a devil's advocate argument that would be a veritable chasm, a Grand Canyon. Which would detract from the purpose of this thread, and allow you to avoid accepting a hard answer
--- In that case, you have to accept that that is not permitted
- the alternative is [d], you retract the doc, and come back when you have a coherent one, that is sensible enough (not perfect) to model from, to make reasonable decisions re what the Relational
{ Work | Variant | Manifestation | Item }.PK
should be.
Over to you.
Correct me if I am wrong, but the real intent, the real value of this thread, is going to be the discussion that occurs AFTER I give a Relation Key that Identifies a movie. Ie. a good Relational Key vs a surrogate, wrt the charges you have made at the top of this thread.
If, on the other hand, your question is really "how does one determine a Relational Key for a real world implementation, from this incoherent document", then let's confirm that that is the case, and let's have that discussion. It depends on your initial or progressed intent: have a discussion re:
q1. RFS/surrogate vs RDB/Relational Key
-- wherein a model with zero integrity, that does everything for everyone, has already been rejected
or
q2. What is a good Relational Key for this problem
Which is why it is over to you.
----
Re progress, I am more than half complete in either case.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 9 January 2020 10:38:15 UTC+11, Derek Ignatius Asirvadem wrote:

On Tuesday, 7 January 2020 04:24:02 UTC+11, Nicola wrote:

On 2020-01-06, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

First and foremost, the question is always the same: how do you identify
a movie (i.e., q2)?

First submission. Obviously I have done far more work than this, this is just what I am willing to show the "senior user", in order to foster discussion.
Ambiguities and contradictions and circular workflow paths resolved, as detailed in the previous post.
(
I don't have separate "conceptual model"; "logical model"; physical model" (neither does /ERwin/), they are just points of progression in a project. So even though I have a progressed "logical model", I am submitting only the "conceptual model".
)
As such, we are not yet discussing Keys, but we are certainly evaluating, contemplating:
How is each fact Identified in the real world ?
How do we Identify each fact ?
With some regard to the downstream effect.

Labelling, naming, a thing is very very very important. The name carries meaning. From the progress thus far, /Work/ is an idiotic label. I am tending towards /Concept/.

Did I say /very/ ?
Obviously, if I use their terms, then I must mean what they mean. Eg. Item. Where the facts I have determined are different to their confused mess, I can't use their terms. Logical & meaningful names used.

//different language versions shot at the same time, released
simultaneously//

3. Different Languages is not a Work, because a human can conceive of something in just one language (those who conceive of things in
multiple languages can be safely assigned to an asylum). The Language would be the Language of the Country or of the Creator. Nevertheless,
I am willing to accept that multiple languages is an INTENT of the
Work.

Each different language is a different Realisation, /shot/ means physicalisation in a particular medium. May be a Variant.
If and when the Concept becomes established, that fact can be registered.

4. Shooting is a Manifestation (realisation), not a Work.

Realisation

5. Release is a Manifestation (realisation), or even an Item, not a Work.

Realisation, possibly worked back from an Item.

So no devil's advocate arguments. Only real world arguments. And per the detail above, any un-resoved or contradictory article (eg. Anna Christie) will be resolved, and THAT it is unresolved in the magical mystical mysterious world of idiots will NOT be a basis for barracking for them. If you do, by that very act, you place yourself in the same category, and I cannot help you.

I do not wish to limit what you say. But at least for part of evaluating this submission, please play the role of a real world archivist/librarian/cataloguer.
http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_1.pdf
---------------------------------------
User Progression (Early Workflow)
---------------------------------------
Register Collection
Register Items, which are Undetermined
Physical properties ... leading to logical properties
As and when the Realisation is determined ("abstraction" is identified), register Realisation
As and when the Concept is determined ("abstraction" is identified), register Concept
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 9 January 2020 23:17:06 UTC+11, Nicola wrote:

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

[...]

I have more comments on that, but I have run out of time.

I will wait for the rest before responding.
Well if you're going into all those aspects, then I will give you what I have. I previously gave you just the introduction to the basic structure, because it IS different to FRBR; FIAF; etc, and i I thought that THAT would be the focus of the initial discussion.
http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_2.pdf
Non-Identifying relations are not shown (clutter at this stage, next stage is choosing Keys, relevant after that).
I am showing the following as separate SubjectAreas:
Agent ... Person ... Corp ... Collective
Country ... Address
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 9 January 2020 23:17:06 UTC+11, Nicola wrote:

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

http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_1.pdf

---------------------------------------
User Progression (Early Workflow)
---------------------------------------

Register Collection
Register Items, which are Undetermined
Physical properties ... leading to logical properties
As and when the Realisation is determined ("abstraction" is identified), register Realisation
As and when the Concept is determined ("abstraction" is identified), register Concept

That's fine: archivists usually start from the physical media, sometimes without even knowing what it contains. So, working "bottom up"
definitely makes sense.

I know, I am following your paper. Add one table Workflow subordinate to EstateItem, and you have it.

The distinction between determined and
undetermined items is also sensible, from such perspective. The bottom
part of you diagram looks good to me so far.

Variant is a many-many association: that's ok. It's interesting that you
are taking the stance that it is an association between Realisations

First, there seems to be a bit of confusion, part of which I caused, so let me correct that.

Labelling, naming, a thing is very very very important. The name carries meaning. From the progress thus far, /Work/ is an idiotic label. I am tending towards /Concept/.

Did I say /very/ ?
Obviously, if I use their terms, then I must mean what they mean. Eg. Item. Where the facts I have determined are different to their confused mess, I can't use their terms. Logical & meaningful names used.

My Item is the same as theirs, so I have named it the same.
I cringe when I look at Variant now, because I do use that name, but it is not the same at all. To them it is a THING (full set of attributes). To us it is a relation between two Realisations, a simple Fact about two Realisations.

rather than Concepts, so moving it down at the concrete level rather
than keeping it at the intellectual level, contrary to what FIAF, FRBR,
etc. do.

(I would not use the word "contrary" or "contradictory". I have no problem at all appearing to "contradict" insanity, but that is not the point: insanity IS self-contradictory, and contradicts reality, so anything that is closely related to reality will, by definition, "contradict" insanity.)

This is debatable:

Yes. The debate is welcomed (that is the back-and-forth, that predicate the iterations in the modelling exercise). But as per the Four Laws, we must have resolution of each point, not non-resolution.

probably, yes, you first recognize Variants
between Realisations,

(At this stage E-R, we are evaluating the tables and relations, with the Identifying relations only, the Keys [although not specified] being the main consideration. They signify ownership, belonging, Matter. The whole signifies the Form under which the Matter exists. Which is why I need to consider all the ables and relations before we decide the Key for Realisation.)
To be clear:
- I recognise Realisation A, add all the attributes
- then recognise Realisation B, add all the attributes
--- at that point I don't have a Concept
- then recognise that Realisation B (only because I added it second) is a Variant of Realisation A, so I register that fact

but later you may want to promote them as
different (abstract) Expressions of the same Concept.

(I don't have a table for that.)
No. Later when I determine the Concept for Realisation A, I add the Concept A, all its attributes, and then add ConceptRealisation A::A.
I don't need to /register ConceptRealisation for Realisation B/ because they are already related at the concrete level. I don't need a ConceptVariant table.
(If I married your sister, I am related to you because of your relation to your sister, I don't have to add a relation /Derek is related to Nicola/.)
Also, I need just one Variant row A::B, not two (B::A). Because they are two sides of the one coin, not two coins. ("Deferred constraint" types usually argue at this point because they register two rows, and then agonise over the quandary.)
The alternative (Variant under Concept instead of under Realisation) would be limiting, because the Concept of A and B has to be recognised, and Concept A registered first. I am taking it that we work from the concrete up, to the intellectual. The Philosopher says, we recognise the Matter first, via the senses (physical attributes of a thing) before we can conceptualise the Form, the intellectual, non-material "soul" that drives the thing, that gives it the power to act.
Second, yes, it is my "stance", but the point is, I am recording facts about the real world, according to the Four Laws; Science; etc. They are in rainbow unicorn land, with innumerable ambiguities and contradictions. Therefore the two are not readily comparable. And "stance" is not applicable, it is not a personal thing, I am supposed to be a clear-eyed observer of reality, and a designer.
What we need to confirm is, is it true in the real world, that a thing has to exist (Realisation) before it can be determined to be a variation of another thing that exists (Realisation). The Spanish/English versions of Dracula. The examples of Blade Runner.
At that point, the Concept may not exist. Usually doesn't.
Or is it true that the whole tree for a single Realisation A is built, and therefore the Concept A exists, before Realisation B comes along and we need to register it. That is the implied workflow in FRBR/FIAF/IFSA/etc. That is false in your real world requirement for non-feature movie archival.
----

Note that FRBR
uses the term Expression rather than Variant (as you say, naming is very important).

And FIAF uses Variant.
----
Run out of time. More, later.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
Quick answer on a couple of points only. I will get to the detail tomorrow.

On Friday, 10 January 2020 19:38:29 UTC+11, Nicola wrote:

You must distinguish between a particular edition of a movie (e.g., the
Final cut's version of Blade Runner distributed by, say, Warner Bros in
2007 on DVD featuring also extra material such as interviews with the
actor and backstage footage), and the single items of that edition (my
copy of the DVD and your copy of the DVD). The former is a Manifestation
in FIAF's terminology and the latter is an Item. Such distinction is important.

Each Realisation may have many editions through time and on different
media. And, in general, the single physical items of a particular
edition (my copy of the DVD and your copy of the DVD) may have different characteristics for some reason, which I may want to record (e.g., the
state of conservation of the physical disc, the fact that my copy has
a torn cover while your copy is still intact in its envelope, etc.).

Edition.
Better than Product.
We we retain the definition of Edition, that it is the output of the project/production cycle, as distinct from the Item, which is the output of the merchandising cycle (if no merchandising, as in non-feature films, then just one Item).

Item is no longer the FRBR/FIAF Item. For a better name for Item,
would you prefer Product, or Article ?

With the distinction above, Item would retain its meaning. So, perhaps: Edition and Item.

We would be comparable to FRBR/FIAF/IFSA only loosely, in that we have given it due consideration. I would not say that we "retain its meaning" on any issue. We have tight definitions (unambiguous; no circular references; implementatio-ready; etc), they do not.

Concept -> Realisation -> Edition -> Item
| |
Variant

Nice

On Saturday, 11 January 2020 03:26:35 UTC+11, Nicola wrote:

If /Independent/ has the RM/IDEF1X meaning, no. Only Concept
& Realisation are Independent.

I mean independent in the IDEF1X sense. In your model (Movie Title Progression V0_2) Item is independent, (Item Determined is not).

Sorry. My mistake. (My head was already in V0_3)

All this reasoning makes sense to me. I wait for your answer re the Product/Edition thing.

Edition is perfect.

If we converge on that, I think we can finally
start talking about the keys.

"Finally" is not a problem. Three iterations at this level (concepts; entities; relations) before Keys is nothing. We are defining the logical structure of the database, yes ? Concepts (first) are Identified by Keys (second), the sequence cannot be reversed, yes ?
Please confirm
- the ER diagram I sent you is /semantic/
- you can //read// all the semantics from the diagram
The next one will be a bit more intense.
----
Concept. In V0.2 a Realisation can be registered without having determined its Concept. My understanding has progressed. Is that realistic ? When would a Realisation NOT have a determined Concept ? Even including the non-feature film registry.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

On Saturday, 11 January 2020 03:37:11 UTC+11, Nicola wrote:

I've taken all your comments into account, the next iteration is ready. I don't have the words in response. Tomorrow. Since we are flipping night-day, instead of losing a cycle, here it is.
- I have changed Concept to Story
- since we are ready for Keys, I have included the elements for it.

http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_3.pdf

Style:
- Data hierarchies, Identifying Relations, ie. the solid lines, are shown vertically.
- Non-Identifyin relations are attached to the side, so as not to interfere

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

From Newsgroup: comp.databases.theory

On Sunday, 12 January 2020 17:21:53 UTC+11, Derek Ignatius Asirvadem wrote:

Now for the next iteration, I will include keys, one step more than E-R. Since you know that ERD is totally inadequate for that level, what do you use; what do you teach ? If you donrCOt have one, I will provide IDEF1X/Table-Key level.
The purpose of V0.3 was to introduce these concepts, without giving the relations, so that we can have this discussion.

As I was progressing the model, it became plain to me that I have raised many new issues in the previous post, and they cannot be reasonably contemplated without a data model. I understand that academics suppress graphic models and insist on text (DDL), but that is not reasonable at this "conceptual" stage, or the next "logical" stage ... and from the progress in this thread thus far, it appears you accept a graphic model.
Here is the next iteration, remaining in the conceptual stage, probably the last before one that defines the Keys.
http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_4.pdf
The grey tables are Reference or Lookup tables. In this increment, I have introduced most of them, drawing some, but not all, of their Non-Identifying relations. The short form (small squares) are:
- [C]lassifier
- [D]iscriminator
- other [R]eference
We are up to 45 tables plus 20 Reference. No screaming so far. We must be progressing well.
When you respond, which will be against either V0.3 or V0.4 please indicate which.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
We are getting into a nice rhythm, especially re the day-night difference and ability to turn around a response during each other's overnight. I will improve my posts as follows.
a. following yours, which are responses, I will give responses that are required to close any issues, only, and exclude any discussion that causes a next iteration
b. give the discussion from your response, which serves as an intro, and the next iteration, in a separate post.
-------------------------------------
This post is one such [a], re V0.4
-------------------------------------

On Tuesday, 14 January 2020 21:51:51 UTC+11, Nicola wrote:

On 2020-01-12, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

On Friday, 10 January 2020 19:38:29 UTC+11, Nicola wrote:

Thus when you
counter with rCLFIAF does thisrCY, I would ask that instead you consider what the real world requirement is.

Sure. When I say "FIAF does this" or "the standard says that", I am not
using an "appeal to authority" argument: I am just pointing out how
people with deep knowledge of the domain have addressed some issues,
perhaps unsatisfactorily (for various reasons). I believe in the
authority of the argument, not vice versa.

Understood.
I don't have a problem with authority. It is a post-modern tactic to demean the authority (in order to elevate the "everyone is equal and my thoughts are as good as the authority" nonsense) just because it is the authority. Eg. real Standards; Codd; etc, are genuine authorities. UML; Date; Darwen; Fagin; et al; the Alice book; are not authorities ... the proof is, their work cannot be relied upon. That is separate to the gigantic fraud.
The diminution of an argument with a charge of "appealing to authority" or that it is "weak" has no logic in it. It is an attack with no substance, by someone obsessed with rebellion authority. Try driving through a red light at peak hour. Real authorities are, well, real. We do not have to buy it, or pander to their destructive needs.
The FRBR/FIAF people may well have deep knowledge, but they do not follow the Four Laws of Thought; Science; etc. Their standard is ambiguous; confused. It cannot be relied upon, it cannot be readily used for an implementation, the same old considerations have to be repeated, with the addition that a resolution is achieved. Just look at the work that we (you and I) have to do, to get beyond what they have given us, to a resolution. I would say, a full 75% of what we are doing, is not data modelling per se but resolving the ambiguities and confusion that those docs have left us with, using data modelling (Codd, Relational, logical) as the tool or method to do that.
Actually, I love authority. God. Truth. Science. And so on down the hierarchy.

Ok. After reflecting on how Titles and Stories should be related and comparing your v0.3 and v0.4 models, I think that you should reintroduce
an independent Title entity in v0.4. These are the essential facts to be modelled, IMO:

1. A Title identifies (is the "main"/"reduced" title of) of 0-N Stories.
2. A Story has one identifying/main/reduced title.
3. A Title may be an Alternate Title;
4. A Story has zero or more Alternate Titles.

AFACS, in v0.4 you are modelling only 4 (Story Title).

No. In V0.4, the Predicates touching Story are as follows. (The model itself does not give Keys but I have given five of them at the top right):
Language
Each Language is independent
Each Language is engendered by 1 Country
Each Language is primarily identified by ( Language )
Each Language identifies, and is expressed in, 1-to-n Stories
Agent
Each Agent is independent
Each Agent is hosted by 1 Country
...
Each Agent creates 0-to-n Stories
...
Story
Each Story is dependent on 1 Agent
Each Story is created by 1 Agent
Each Story is identified by 1 Agent
Each Story is dependent on 1 Language
Each Story is an expression of 1 Language
Each Story is identified by 1 Language
Each Story is primarily identified by ( Language, TitleReduced, Creator, Year )
Each Story is known as 1-to-n StoryTitles
...
Taking each in turn:

0. reintroduce an independent Title entity

The predicate for that is false. A Title does not exist independently. It exists only because a Story [with that Title] exists.

1. A Title identifies (is the "main"/"reduced" title of) of 0-N Stories.

A ( Language, TitleReduced, Creator, Year ) identifies 1 Story

2. A Story has one identifying/main/reduced title.

Each Story is primarily identified by ( Language, TitleReduced, Creator, Year ) Each Story is known as 1-to-n StoryTitles
One StoryTitle is the TitleReduced in long form

3. A Title may be an Alternate Title;

The /rest/ in StoryTitle are Alternate Titles

4. A Story has zero or more Alternate Titles.

Yes. The 1 in the /1-to-n/ is the main Title un-reduced.

Discussion
-------------

Realisation.PK[ Language, Creator, Year, Title, Differentiator ]

Concept[ English, GB, 1897, Bram Stoker ]
Realisation[ English, US, 1931, Tod Browning, English cast ]
Realisation[ Spanish, US, 1931, Tod Browning, Spanish cast ]
...
Realisation[ English, US, 1958, Jimmy Sangster, "" ] = Christopher Lee

I think you forgot to mention the title there, otherwise it seems ok.

Yes, sorry.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

On Wednesday, 15 January 2020 20:59:15 UTC+11, Derek Ignatius Asirvadem wrote:

[...]

Language again. Title is dependent on Language. So wherever Title is stored, the Atom must be [ Language, Title ]. Which is why I had Language not Country in the PK. Response please.

Before responding, I would ask that you obtain familiarity with SQL language and CharacterSet implementation, both server-side (storage) and client-side (representation). The concept of Locales.
(
I don't know how the NONsql suites do it, and I really don't want to know. I trust you will agree, since we are working with the RM, not the pig poop marketed as "relational", we should concern ourselves with the data sub-language that is defined in the RM: SQL, and not anything else. As always, the high-end suppliers implemented language and charset support decades before the SQL Standard defined it.
)
Note also, my design for Keyword. I allow Keywords to be specified for:
a. { Concept | Realisation }, and
b. { Concept | Realisation }.Title, and
c. I ensure they are not repeated for a given { Concept | Realisation }.
Since Title is Language dependent, any Keyword that is related to a Title will thusly be Language dependent. Default Locale, etc.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Sunday, 19 January 2020 03:14:49 UTC+11, Nicola wrote:\

Nicola

I was preparing a detailed response but I ran out of time. Problem is, Tues is a very busy day for me. I will get back to this on Wed

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

From Newsgroup: comp.databases.theory

On Saturday, 18 January 2020 21:54:21 UTC+11, Nicola wrote:

2. A Story has one identifying/main/reduced title.

Each Story is primarily identified by ( Language, TitleReduced, Creator, Year )
Each Story is known as 1-to-n StoryTitles
One StoryTitle is the TitleReduced in long form

By TitleReduced, do you mean with less attributes (e.g., without
the specification of the title's language?).

No.
Wherever Title is stored, it must be stored with TitleLanguage.

By TitleReduced

I have previously given a quick description of what that is, which I thought was understood ...
OrderAdvanced ...
Keyword ...
PartDescription ...

The same structure will be used for:
- Title
- minus prepositions; conjunctions; etc.
Fully search-able at the SQL level

Also, the language of
a Story and the language of a title are distinct, so perhaps we could
call the latter TitleLanguage for clarity.

Yes.

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

From Newsgroup: comp.databases.theory

===================
This post introduces V0.6
===================

http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_6.pdf

The Keys are defined along with some notes at top right.

On Friday, 24 January 2020 15:08:19 UTC+11, Derek Ignatius Asirvadem wrote:

All issues discussed in that post have been modelled.

So wherever Title is stored, the Atom must be [ Language, Title ], preferable to [ CharSet, Title ].

That is expanded to cover any attribute:
Wherever an attribute that is not in the default Language is stored, it is stored as [ Language, <attribute> ]

[ I said somewhere, that the un-reduced version of Concept.TitleReduced will be in ConceptTitles. ]

That is an error. According to 3NF/FD, it will be an attribute in Concept.Title.

----

In the same way that Edition is a manifestation of 1 RealisationTitle (not Realisation), and therefore a single Language, in this model, I expect to clarify whether Realisation is rendition of 1 ConceptTitle (not Concept), and therefore a single Language.


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

From Newsgroup: comp.databases.theory

On Saturday, 25 January 2020 21:00:03 UTC+11, Nicola wrote:

On 2020-01-24, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

On Sunday, 19 January 2020 03:14:49 UTC+11, Nicola wrote:

On 2020-01-15, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

------------------------------------------------
This post is one such [b], introducing V0.5
------------------------------------------------

A remark: my intended definition of "Concept" in this context is
strictly as "Moving Image Concept", i.e., it would exclude other forms
of intellectual creations. So, if a movie is derived from a novel, that
should be expressed as an association between a (Moving Image) Concept
instance and an instance of another entity, not existing in the current
model.

I don't understand. How can one associate [or reference] a thing with another thing that does not exist ?

You won't reference it, of course. In the example above, you would stop
at Concept [ English, Tod Browning, 1931, Dracula ], without ever
recording the fact that it is derived from Bram Stoker's Dracula. If
you'd want to record such additional fact, you would extend your model.

No. You would:
+ Concept [ English, Bram Stoker, 1879, Dracula ] All relevant attributes Concept [ English, Tod Browning, 1931, Dracula ] Parent = [ English, Bram Stoker, 1879, Dracula ]

But I see what you mean, and I agree: there's no need to multiply
entities without necessity. Both pieces of information are Concepts and
both must be recorded as such. Correctly managing the Concepts
hierarchy, as you explain below, is not difficult.

Yes. I don't promise an "artificial intelligence" system, I promise a Logical one. To the extent that any constraint that is declared by the user, is Logical.

There is a distinction automating that curator's automate-able tasks, and providing curator services.

Ok. At the E-R level I believe that you have nailed things down. I think
that at this point we might start moving to a key-based model, where it
will be clearer whether further normalisation is needed.

Yes.

So wherever Title is stored, the Atom must be [ Language, Title ], preferable to [ CharSet, Title ].

Then, you can probably assume UTF-8 or UTF-16 and dispose of CharSet. In either case, now that I better understand your model, I accept that.

I don't know if you would agree. My perspective (real world, about 40 years):
- what we have been doing in Logical level modelling
--- you probably call it "conceptual level"

I am with Codd when he says that the distinction between "conceptual
level" and "logical level" is fuzzy. Nowadays, I take the two terms as synonyms.

There cannot be a conceptual that is not Logical (ok, there can be, but it will not be the knid that you and I care about). Therefore the only Conceptual that I accept is /within/ the domain of Logical. And FOPC in the first order of that Logical.

Therefore Conceptual is the left side of
If the domain of Logical were perceived as a spectrum:
- Conceptual would be the left side,
- Physical would be the right side
- with a number of specific stages in-between

But even that does not describe it properly. First, I am totally with Codd. Not just hanging on his every word (not saying you are), but:
- what he actually meant when he said something, and
- how that fits into the grand scheme of creating something (true). http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Creative%20Act.png
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Saturday, 25 January 2020 22:15:33 UTC+11, Nicola wrote:

On 2020-01-25, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

===================
This post introduces V0.6
===================

http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_6.pdf

A few thoughts:

(I like where you are going with this ...)

- Does Concept need to be identified by Country? Couldn't that just be
[TitleReduced, Creator, Year]? Each Realisation of a Concept, but not
the Concept itself, is "produced by" a (principal) country. The
Concept itself is a creation of its Creator at some point in time.
How about:

Concept [TitleReduced, Creator, Year] -> Title
Realisation [TitleReduced, Creator, Year, Differentiator] -> Country

?

Ok.
Person[ ... ] raA BirthCountry
We could say
Concept [TitleReduced, Creator, Year] raA Country.
Baba Yaga comes from a distinct Country
We could say
Concept [TitleReduced, Creator, Year] raA Language.
Baba Yaga comes from a distinct Culture, which is defined by Language which is better than defining it by Country
And then,
Realisation [TitleReduced, Creator, Year, Differentiator] raA Concept.Country (parental attribute)
OR, as you say:
Realisation [TitleReduced, Creator, Year, Differentiator] raA Country (local attribute).
If that is not perfectly clear, examine this. In: http://www.softwaregems.com.au/Documents/Documentary%20Examples/Order%20DM%20Advanced.pdf
for Street:
Street[ ... ] raA County.Name
Just as
Table[ Key ] raA Attribute
If 3NF/"Full" FD is understood AND a Relational Key is used:
Table[ Key ] raA Parent.Attribute

- Besides, I would remove Title from Concept, because that information
belongs to ConceptTitle. A ConceptTitle can additionally provide all
the required information about each title.

Disagree. This is correct:
Concept [TitleReduced, Creator, Year] raA 1 Title (local attribute)
And
Concept [TitleReduced, Creator, Year] raA 0-to-n ConceptTitles (subordinate table)
Not 1-to-n as I have explained elsewhere.

- Most of the non-identifying relations you have marked with L do not
need to be explicitly modelled, because, I think, they are implied by
the various referential integrity constraints.

Yes, for some. No, not for others. Therefore it must be explicit (a model should never be ambiguous).

What does "SG" stand for in "SG Relational Notation"?

Software Gems/Derek Asirvadem
First, my intellect and the fact that it is protected from the insanity of corrupted "science", is a Grace from God. Second, I am just a disciple of Codd, having implemented his /RM/ faithfully for about 40 years, without reading the pig poop. Therefore, even though I have many inventions re the RM, I state that they are progressions of Codd's work, and not isolated inventions,
To fully understand what I am doing with that Notation,one must consider the FOPC Predicates (the set that is required for an implementation of the RM) in text form. (Some examples have been given previously.) And since we use Relational Keys, everything is stated in terms of English words. That. Have. Meaning.
Customers love the natural use of English, anything that gets them out of the mind-numbing r, s, t with subscripts and superscripts and Greek letters.
There is more to the Notation, that is just the definition, to get started.

In the same way that Edition is a manifestation of 1 RealisationTitle
(not Realisation), and therefore a single Language, in this model,

Ok.

I expect to clarify whether Realisation is rendition of 1 ConceptTitle
(not Concept), and therefore a single Language.

I'd lean towards answering affirmatively, if we regard a movie dubbed in
a different language as a different Realisation.

That logic still holds, but /in that instance/ it has been trumped by declaring a Dub as an Edition, not a Realisation.
Ok, so we have:
Concept[ TitleReduced, Creator, Year ] raA 1 Title (local attribute)
Concept[ TitleReduced, Creator, Year ] raA 0-to-n ConceptTitles (subordinate table)
ConceptTitle[ TitleReduced, Creator, Year, Language_CT, TitleReduced_CT ] raA Language_CT[ Title ]
Realisation[ TitleReduced, Creator, Year [, Differentiator ], Language_CT, TitleReduced_CT ]
Time for another one of those progression-of-Codd inventions that is fully-integrated-with-science-and-logic. That PK is getting silly, because both TitleReduced and TitleReduced_CT have a Language. Title is duplicated, only one is required. Resolving all that, this becomes the Primary Key:
Realisation[ Language_CT, TitleReduced_CT, Creator, Year [, Differentiator ] ]
This is Alternated Key Normal Form. It is dependent on (the row must be be in) Codd's 3NF/"Full" Functional Dependency ... which I declare as Key Dependency Normal Form. It is not the Date; Darwen; Fagin; et al "3NF", it is more than their "BCNF", "4NF", "5NF", all of which contradict the /RM/, and a bit more articulated than, while remaining strictly within, Codd's.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Saturday, 25 January 2020 22:56:05 UTC+11, Derek Ignatius Asirvadem wrote:

I am with Codd when he says that the distinction between "conceptual
level" and "logical level" is fuzzy. Nowadays, I take the two terms as synonyms.

There cannot be a conceptual that is not Logical (ok, there can be, but it will not be the knid that you and I care about). Therefore the only Conceptual that I accept is /within/ the domain of Logical. And FOPC in the first order of that Logical.

Therefore Conceptual is the left side of
If the domain of Logical were perceived as a spectrum:
- Conceptual would be the left side,
- Physical would be the right side
- with a number of specific stages in-between

But even that does not describe it properly. First, I am totally with Codd. Not just hanging on his every word (not saying you are), but:
- what he actually meant when he said something, and
- how that fits into the grand scheme of creating something (true). http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Creative%20Act.png

(The post got cut off)

At the asylum end of the academic spectrum we have Date; Darwen; Fagin; et al, and their followers.
- Half their life activity is "argument"; sophistry, about fragments of the atoms in the /RM/ that undamaged human beings do not have ... because we have not split Codd's atom into fragments.
- The other half is bleating about what Codd did not do, labouring that the /RM/ is "incomplete" because it does not give rules for database design.

The evidence is, these people have not been to uni, they have not written a single academic paper. If they had, they would know that a paper defines the new article, it is not required to define the larger article, the context that the paper addresses.

Database design and Normalisation existed long before Codd, the /RM/ is not required to define it.

So when Codd states a directive, I take it that he is not rebelling against Logic; the Four Laws; Science; etc, but that his directives are to be taken within that.

All of which are unknown at the TTM Gulag. Which is why they fault Codd for not having taught them how to blow their nose; how to suck their thumbs; .

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

From Newsgroup: comp.databases.theory

On Sunday, 26 January 2020 05:42:42 UTC+11, Nicola wrote:

On 2020-01-25, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

Just as
Table[ Key ] raA Attribute
If 3NF/"Full" FD is understood AND a Relational Key is used:
Table[ Key ] raA Parent.Attribute

Sure, FDs are not necessarily intra-relational.

No.
If 3NF/"Full" FD is understood AND a Relational Key is used:
Parent[ ParentKey ] raA Parent.Attribute
Child[ ParentKey, Differentiator ] raA Child.Attribute
Child[ [ ParentKey ] ] raA Parent.Attribute

- Besides, I would remove Title from Concept, because that information
belongs to ConceptTitle. A ConceptTitle can additionally provide all
the required information about each title.

Disagree. This is correct:
Concept [TitleReduced, Creator, Year] raA 1 Title (local attribute)
And
Concept [TitleReduced, Creator, Year] raA 0-to-n ConceptTitles (subordinate table)
Not 1-to-n as I have explained elsewhere.

Well, let it be then.

Done.

Ok, so we have:
Concept[ TitleReduced, Creator, Year ] raA 1 Title (local attribute)
Concept[ TitleReduced, Creator, Year ] raA 0-to-n ConceptTitles (subordinate table)
ConceptTitle[ TitleReduced, Creator, Year, Language_CT, TitleReduced_CT ] raA Language_CT[ Title ]

Where [TitleReduced_CT, Language_CT, Creator, Year] is also a key. Nice!

Yes. In my courses, having previously taught the /Principle/ that
Each truth is integrated with every other truth
this section of the course is titled /Fun with Relational Keys/.

Time for another one of those progression-of-Codd inventions that is fully-integrated-with-science-and-logic. That PK is getting silly,
because both TitleReduced and TitleReduced_CT have a Language. Title
is duplicated, only one is required. Resolving all that, this becomes
the Primary Key:
Realisation[ Language_CT, TitleReduced_CT, Creator, Year [, Differentiator ] ]

Fine, by migrating an AK (this is one aspect where the IDEF1X standard
should relax its rules, IMO).

Yes and no. It is Codd's directive, in his /RM/. IDEF1X is simply implementing the directive. Therefore I would not change that.
What we have here is a finer grain, a progression, /after/ having implemented that rule. Which is why I have a separate NF defined for it.

That's nice, because each Realisation is naturally identified by its own title, even if they realise the same Concept.

All truth is integrated.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

===================
This post introduces V0.7
===================

http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20Progression%20V0_7.pdf

The Keys are defined along with some notes at top right. That is getting a bit tedious, but it is required for understanding because I have not produced the IDEF1x/Key levl model yet.

On Monday, 27 January 2020 13:41:00 UTC+11, Derek Ignatius Asirvadem wrote:

All issues determined in that post have been modelled.

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

From Newsgroup: comp.databases.theory

On Monday, 27 January 2020 20:03:16 UTC+11, Nicola wrote:

On 2020-01-27, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

This post introduces V0.7

That looks good to me.

Sorry about the delay. Fires. Floods. Sickness.
But by the Grace of God, we don't eat rats; bats; or marmots, and we don't have a plague of locusts.
===================
This post introduces V0.8
===================
Having agreed that V0.7 Table-Relational level is good, there is no /substantial/ difference between V0.7 and V0.8. As you may appreciate, in erecting the Table-Attribute level, minor errors or omissions in the Table-Relation level were exposed, and so there is a new version.
Table-Relational http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TR%20V0_8.pdf
Table-Attribute (many FKs are in the Attributes, not the Keys) http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_8.pdf
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Saturday, 15 February 2020 15:38:57 UTC+11, Derek Ignatius Asirvadem wrote:

===================
This post introduces V0.8
===================

Having agreed that V0.7 Table-Relational level is good, there is no /substantial/ difference between V0.7 and V0.8. As you may appreciate, in erecting the Table-Attribute level, minor errors or omissions in the Table-Relation level were exposed, and so there is a new version.

Not sure if it is possible, but I will ask anyway. I don't have a capable person to check my work right now, and I won't until 06 Mar. There is only so much that self-checking exposes. Could you please;
1. check this at the clerical, not modelling, level. Ie. typos; missed migrations; etc. If any errors I will fix them up.
2. IFF [1] is correct, proceed with ordinary discussion, which is modelling. No point in [2] if there are silly errors.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Saturday, 15 February 2020 15:47:34 UTC+11, Derek Ignatius Asirvadem wrote:

Not sure if it is possible, but I will ask anyway. I don't have a capable person to check my work right now, and I won't until 06 Mar. There is only so much that self-checking exposes. Could you please;
1. check this at the clerical, not modelling, level. Ie. typos; missed migrations; etc. If any errors I will fix them up.
2. IFF [1] is correct, proceed with ordinary discussion, which is modelling. No point in [2] if there are silly errors.

Found and fixed such [1] clerical errors, not change to the substance or intent. It does not warrant a new version number. Note the Date 17 Feb 2020.

==================
This post corrects V0.8
==================

Cheers
Derek

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
===================
This post introduces V0.9
===================
I have:
1. Language
Fixed up Language throughout, particularly where it counts (excludes tables which are loosely defined, which you will probably use UTF-8 and not worry about a declared Language).
2. Keyword
Added clarity, so as to exclude rubbish words from actual Keywords. This is going to be one of the most used search vectors, so I have given it the full definition. (All Hierarchs in a Relational database are "Dimensions" in the "Dimension-Fact" paradigm ...) but this one is rather special, one I developed decades ago, and used in many databases with great success. Here we have:
- Keywords from the Title (in whatever Language the Title is)
- additional Keywords to recall the movie
- without duplication
- prevention of silly words being used as Keywords
Nice little structure for implementing EXCLUDE, which may be of interest to you.
3. Squeezed
Since you do not have access to an A2 printer, I have set it all out in A3 (each SubjectArea), but that does squeeze things a bit. Sorry.
(In Australia, we just go to the local print shop or stationers, where they can print A2; A1; A0, on media that is cheap paper; expensive paper; vinyl; etc, to suit the budget. Colour A2 cost $5 for cheap; $12 for expensive; $20 and up for vinyl; etc.))
Which means a new Version 0.9:
Table-Relation http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TR%20V0_9.pdf
Table-Attribute
(many FKs are in the Attributes, not the Keys) http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_9.pdf
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 20 February 2020 07:20:34 UTC+11, Nicola wrote:

On 2020-02-17, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

I need a few days before coming back to this at full throttle. Life
sometimes gets in the way.

By all means. We need full throttle on both sides for this one. (When I am sick, usually I can still concentrate, at least for short durations. But not that last time, which I felt quite bad about, I couldn't even implement an FK without screwing up.)
When you do come back, please evaluate just the last model, eg. V0_10, those in-between can be safely skipped.

1. check this at the clerical, not modelling, level. Ie. typos; missed migrations; etc. If any errors I will fix them up.
2. IFF [1] is correct, proceed with ordinary discussion, which is modelling. No point in [2] if there are silly errors.

I think I have caught all of [1]. You can proceed directly into argumentation of the logical.

At a quick glance: Agent is an interesting case, because apparently it *requires* the use of a surrogate (AgentNo)...

Yes, of course.
If you think I have declared surrogates are banned, period, that is false. I have declared that surrogates are banned AS A STARTING POIINT in the exercise of modelling a database that is intended to comply with the /Relational Model/.
There are only two scientifically valid reasons for a surrogate (as opposed to the anti-scientific, schizophrenic "reasons" of the Date; Darwen; Fagin; et al Gulag). In both cases, because it is a surrogate, it still constitutes a Relational Breach, specifically
a. a breach of the Independent Access Path Rule. It cuts of access from the tables below the breach, to their genuine ancestors (above the breach).
b. and of course the Relational Key Normal Form.
The surrogate breaks the natural Hierarchy, and creates a new Hierarch (in my IDEF1X models, I show this visually, because I render all Hierarchies visually, vertically). Please feel free to discuss in detail.

I render all Hierarchies visually, vertically

I have an even more superior method, but I can't show that in a public forum, sorry.
1. The PK has become too wide to be used (migrated) throughout the hierarchy, and so a surrogate is /substituted/ for the PK. This is exemplified in Address and Person. I think you understand that usage.
2. The table is a Basetype, and the Subtypes have quite different PKs, such that a common PK cannot be established. Thus the common PK in the Basetype is manufactured, it is a surrogate. Please feel free to discuss this usage in detail.
In any case, if a surrogate is chosen, it must be be late in the modelling exercise, so as not to interfere with the process: the exposure; determination; and deployment of discrete FOPC Facts. Which you have seen a bit of in this exercise, this thread.
-- The corollary is the more relevant point, due to the pig poop promoted and marketed by the Anti-Relational pig poop purveyors. Starting the exercise by stamping a surrogate on every file (they are not tables) cripples the modelling exercise, the exposure; determination; and deployment of discrete Facts.
--------------------------------------
-- This post introduces V0.10 --
--------------------------------------
1. Corrections
- Creator should be CreatorNo
2. Minor but important changes
- RealisationCast renamed RealisationPersonRole
- PK changed, allowing elimination of AK
- the relation
/Each PersonRole plays 0-n RealisationCasts/
changed to
/Each PersonRole fills 0-n RealisationPersonRoles/
3. RealisationPlayer added
/Each RealisationCharacter is played by 0-1 RealisationPlayer/
/Each RealisationPersonRole plays 0-1 RealisationPlayer/
4. I have changed Realisation to Project.
I wanted to propose it; have some discussion; obtain acceptance/rejection; etc ... but with a view to reducing the back-and-forth, given the minor delays on both sides, I have simply implemented it in this version. If you do not like it, I can change it back to Realisation.
/ConceptTitle[ ... ] manifests as Project/
/ProjectTitle [ ... ] is merchandised as Edition/
I considered Materialisation, and rejected it.
5. Table names improved (minor).
Table-Relation http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TR%20V0_10.pdf
Table-Attribute http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_10.pdf
Question
-----------
Re working protocol. To reduce my work in erection of the PDFs. As you can imagine, I cannot work (model) at the A3/SubjectArea level, which involves duplication of tables, I have to work at the level of the model on a single page. Otherwise I can make quite preventable mistakes. (Separately, there is no substitute for the visual facility of the model on a single page, even if hundreds of tables.)
For each version, the last thing I do is erect a PDF in A3 (which I understand you need, at least for printing purposes). This is an exercise of getting the SubjectArea with the full context (I won't exclude the context, it renders the SubjectArea invalid) onto an A3 page. Which includes some squeezing, as well as ugliness. No complaint.
So the question is this. While we are going back and forth with the modelling, can I give you just the whole model on one page ? Right now it is A1.
And whenever you need any Version in A3/SubjectArea, please ask. (I don't know what your requirements are ... print always; print only to read on the train; or whatever). Please do not be shy.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 20 February 2020 21:51:59 UTC+11, Derek Ignatius Asirvadem wrote:

There are only two scientifically valid reasons for a surrogate ...
In both cases, because it is a surrogate, it still constitutes a Relational Breach, specifically
a. a breach of the Independent Access Path Rule. It cuts of access from the tables below the breach, to their genuine ancestors (above the breach).
b. and of course the Relational Key Normal Form.

The surrogate breaks the natural Hierarchy, and creates a new Hierarch (in my IDEF1X models, I show this visually, because I render all Hierarchies visually, vertically). Please feel free to discuss in detail.

That fact, that it is a Relational Breach, is further confirmed because one cannot use FOPC, the first order in the Logical realm, and therefore cannot use the second order, the /Relational Model/.
More precisely, FOPC *can* be applied (because FOPC can be applied to absolutely anything), *and* the FOPC Predicates that are distilled from an RFS model or surrogated table are FALSE (wrt to Reality).
Take an unrelated eg. In the Relational data model, Country cluster:
__Each Country is independent
__Each Country consists of 0-n States
____Each State is dependent on, and identified by, and a constituent of, 1 Country
____Each State is made up of 0-n Counties
______Each County is dependent on, and identified by, and a possession of, 1 State
______Each County has 0-n Towns
each of which is true wrt Reality.
That is a partial set, I have not included the other Predicates, eg:
__Each <row> is identified by <RelationalKey>.
__etc
In the equivalent RFS record model:
__Each Country is independent
__Each Country consists of 0-n States
____Each State is independent <= FALSE
____Each [independent] State is made up of 0-n Counties <= FALSE
______Each County is independent <= FALSE
______Each [independent] County has 0-n Towns <= FALSE
each of which is FALSE wrt Reality, but implemented anyway for some /physical/ purpose.
And:
__Each <record> is identified by <physical_record_no> <= FALSE
__etc
Which is just one of the several reasons the pig poop Gulag avoid mentioning FOPC or Predicates (and if they do, it is a degenerate, misleading form).
A second reason they can't is worth mentioning here. the RFS (even though the RM/T which supposedly supports it contains the word /model/, iy is not a model in the mathematical sense, and therefore FOPC or FOPC Predicates simply cannot be used. Which is why, when the freaks do suggest a Predicate, it is of the degenerate kind (eg. /Person is Called/).
The freaks actually teach this degenerate stuff as "education". This is Hugh Darwen's "compuetr science/database" course at "university of warwick", for decades. He does a great job of perverting Predicates, avoiding the proper introduction of FOPC. He also perverts /Intension/. If you are in a hurry look at the result only -o 10:
https://www.dcs.warwick.ac.uk/~hugh/CS252/CS252-HACD-Notes4.pdf
(Every lecture is chock-full of pig poop, serious perversions ... I am directing your attention to a single item: perversion of the concept of Predicate.)
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

https://www.zerohedge.com/geopolitical/coronavirus-deaths-outside-china-spike-who-team-visits-wuhan

God bless you and your family
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Tuesday, 25 February 2020 16:03:10 UTC+11, Derek Ignatius Asirvadem wrote:

On Tuesday, 25 February 2020 02:44:32 UTC+11, Nicola wrote:

- Others:
- KeywordPermitted is 1:1-N with both ConceptKeyword and
ProjectKeyword: I think that should be 1:0:N (a simple reason is
that a Concept may have no associated Projects).

Yes and no. I realise that academics; "academics"; and certainly all the "theoreticians" (there are no theoreticians serving this space) contemplate each FK (indeed every element in the data model) as a single element, isolated from its context, divorced from all other elements. But that is wrong:
- the database is an integrated unit (no element is isolated; every element exists in a context)
- the FK relates to the parent, and to the child
- where there are two FKs, there are two parents with a common child
- so the two relations, and their cardinality, must be viewed as involving three parties (not two times two parties)

The cardinality declared in V0.10 states, a Keyword will not be added unless it has a child in { ConceptKeyword | ProjectKeyword }. Ie. we do not walk up to the database and add Keywords first, then add Titles. No, the user function is, we add Titles, and as a result, if the words do not exist in Keyword, we add the Keyword as part of the Transaction. (Keyword first, in the Transaction sequence.)

The academics; "academics"; and certainly all the "theoreticians", are totally ignorant of ACID Transactions, which is a huge problem. We had ACID Transactions in every *DBMS long before the /RM/, and SQL, the data sublanguage defined in the /RM/ has ACID Transactions. So while it could be said that the /RM/ does not define Transactions, that is irrelevant, because it does not have to define anything other than the /Relational Model/ (eg. it does not define Basetype-Subtypes either, which we also had before). The relevant point is, all DBMS platforms, Relational or otherwise, have ACID Transactions, as a necessary demand for any implementation, and we had better teach it.

(Non-platforms do not have Transactions and various other implementation requirements, let's not discuss them. They just simply should not be used for any academic or teaching purpose.)

For clarity, teaching purpose, etc. Transactions are best understood from the user perspective (action; function), rather than the database perspective, and then add the understanding of the database requirement. When I (a) discuss or (b) name Transactions, I purposely:
- do NOT use insert/update/delete
- DO use add/modify/drop
So the Transaction discussed is ConceptTitle_Add_tr (because it is independent of Concept_Add_tr, ConceptTitle can be added independent of Concept). It does (in order):
- remove the KeywordsExcluded from Title = TitleReduced
- check that the remaining words are in KeywordsPermitted
- foreach that does not exist in KeywordsPermitted:
--- INSERT Keyword
--- INSERT KeywordPermitted
- then foreach word in TitleReduced
--- INSERT ConceptKeyword
--- INSERT ConceptKeywordTitle
- INSERT ConceptTitle
The order is usually the logical tree, reversed. The database is [C]onsistent at all times, [C]onsistency is not broken for the duration of the Transaction, as some non-platforms prescribe (that is Anti-ACID). We do not need "deferred constraint checking".

For
instance, should an Australian cataloguer insert the title of a new
Concept "Godzilla" as
(a) "Gojira" (in Japanese, I assume),

Hepburn actually, Japanese language in the Roman (be proud!) alphabet.

Ie. phonetic. The Japanese pronunciation of "pe|pe+pa-" sounds like "Gojira". The English word is Godzilla, because it is an amalgam of sea monster (they have deities but no unifying God) plus gorilla.

(b) "pe|pe+pa-"
(which *should* be the Japanese script for Godzilla, at least according
to Google Translate)

It is. Japanese in the Japanese charset (technically East Asians do not have an alphabet, they have only symbols for words).

The East Asians are all primitive as F. No alphabet. No CONCEPT of words that are made up of root words plus prefixes and suffixes to denote tense; particles; etc. Just words as concepts, meaning dependent on context (the string of concepts) and words each have a symbol. Therefore they do not have any literature or poetry (the concept is absent). "Simplified" Chinese:
- symbol for TREE is uL? (notice the stick figure tree)
- symbol for garden is 2 x TREES = o|! (there are 2 x stick figure trees in that, plus house)
- symbol for forest is 3 x TREES = uu< (notice 3 x stick figure trees)
If I want to tell a Chinese to piss off, I have to say the symbol for /bad egg/.
The Japanese, Vietnamese, and Koreans are a bit ahead of the Chinese, because they have a Roman alphabet for phonetic use. The Vietnamese are the best in this pathetic category, because the Jesuits gave them a massive alphabet (Roman plus diacritical marks) for their clicks and sucks.
In any case, their entire total dictionary is only 40,000 words/concepts/symbols. The minimum a person needs to function is 2,000 symbols, for business 4,000. A person is considered /learned/ if they know 6,000 symbols.
That is why learning those stupid "languages" is a simple matter of memory. That is also why East Asian adults can never learn English or Italian, etc: the notion of root words plus suffixes is way too much for them.
Due to this deep intellectual issue, and other deep issues, they have a huge inferiority complex.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Tuesday, 25 February 2020 20:20:36 UTC+11, Nicola wrote:

On 2020-02-25, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

Second, when the **full** PK
Concept[ Creator, Year, TitleReduced ]
is **not** used to Identify the child
ConceptTitle[ Creator, Year, LanguageCode, TitleReduced ]
the relation is Non-Identifying. Of course, the FK is migrated as normal:
/Concept[ Creator, Year, TitleReduced ] is known as ConceptTitle[ Creator, Year, TitleReduced_C ]/

That naming of the attributes has got me confused. Now, I've got it.
Ditto for Project/ProjectTitle.

Sorry. Expanded as TitleReduced_Concept, etc in the next iteration.

- Others:
- KeywordPermitted is 1:1-N with both ConceptKeyword and
ProjectKeyword: I think that should be 1:0:N (a simple reason is
that a Concept may have no associated Projects).

The cardinality declared in V0.10 states, a Keyword will not be added unless it has a child in { ConceptKeyword | ProjectKeyword }.>

...unless it has a child in ConceptKeyword **&** ProjectKeyword }. To
express "one or the other or both (but at least one)", you should make
the associations 0rCoN and add a footnote to explain that at least one association must hold for each keyword. The way I understand your model
is that you cannot add a Keyword unless it is used as both
a ConceptKeyword and as a ProjectKeyword.

Discussion. I am trying to get you to appreciate higher meanings in cardinality when the DM is taken as a whole, not each relation in isolation. What you are saying is perfectly reasonable in the latter perspective, but not in the former.
(Consider, no need to answer each /why/.)
Why ?
Why, when taking the whole model into account, here the Concept cluster, does that mean that ? Why **and**, not **or** ?
Why, in your statement, does the Concept relations not prevail ?
(Transactions have a bearing on this, they are properly considered in the former realm, ignored in the latter.) I repeat, in Transaction code, the order of INSERTS is usually the reverse of the subject tree. In terms of higher meaning, that means there is no Keyword that is NOT IN either ConceptKeyword{ Direct | Title } **or** ProjectKeyword{ Direct | Title }. (It does NOT mean that for every Keyword, there must be a ConceptKeyword **and** a ProjectKeyword.)
Why, when adding a ConceptTitle via execution of ConceptTitle_add_tr, does the DM not suffice ? Why does the unrelated ProjectTitle requirements (and then its Keyword requirements) have to be considered ?
There is no Keyword_Add_tr. Keywords & KeywordsPermitted will added as and when Concepts; ConceptTitles; Projects; ProjectTitles, are added.
In a nutshell, why does the Keyword tree have priority over the Concept (or Project) tree ?
(The above is for discussion.)

To
express "one or the other or both (but at least one)", you should make
the associations 0rCoN and add a footnote to explain that at least one association must hold for each keyword.

Separate point. Generic answer. No. The correct way is to add a pair of Non-Exclusive Subtypes for KeywordPermitted { Concept | Project }.

One issue with the term "Project" is that a full database model would
likely include "cataloguing projects", so the term is at risk of being
overloaded. But for this thread I believe it's fine.

(I would much rather model a real world database than a purely
academic one for this thread. The former has a veracity that the
latter does not have, and the former covers the latter plus more, not less.)

How about just... Movie (or Moving Image)?

Done.

Second, according to IMDb, the movie "Gojira ni-sen mireniamu" is
translated into English as "Godzilla 2000" and also as "Godzilla 2000:
Millennium". In my understanding, those would be two titles with the
same LanguageCode. So, shouldn't the key of ConceptTitle include
TitleReduced_C rather than LanguageCode?

That is a discussion point, that leads to a decision, as opposed to
a mistake. The current intention is, we have just one ConceptTitle
(and ProjectTitle) in any one Language. So if we need multiple titles
per Language ... I would say, the determinant is ...

TitleType, and move that into the PK, rather than TitleReduced_C (the title itself).
ConceptTitle[ ?, ?, en, Original, Godzilla 2000 ]
ConceptTitle[ ?, ?, en, Alternate, Godzilla 2000: Millennium ]

Do you need LanguageCode in the key, though? I'd say that both
LanguageCode and TitleType are determined by the title.
I'd say that ...
LanguageCode ... are determined by the title.

1. From our previous discussions, LanguageCode has to go with a Title where the Title may not be in the cataloguer's language.
2. How can LanguageCode be determined by theTitle ?
For uneventful presentation (any GUI, any platform ... Localisation), I thought it is the reverse.

I'd say that ...
TitleType are determined by the title.

Please explain. Context is of course, our previous discussion: that there are more than one ConceptTitles in a particular Language for a given Concept:

So, shouldn't the key of ConceptTitle include
TitleReduced_C rather than LanguageCode?

I am addressing that problem, but nominating TitleType as the determinant, which is also the determinant of the TitleReduced in the PK.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
======================
This post introduces V0.11
======================
1. Hierarchy & Layout
---------------------------
We discussed Layout, OrgChart (all DMs thus far) vs Hierarchic. This one is Hierarchic Layout. It does take a bit of getting used to, but once gotten, it is preferred. Why ? Because it emphasises the nature of the Hierarchy, ie. all data hierarchies in the model, which are the hierarchies in the real world that we are modelling.
I intended to provide a write-up on hierarchies; their destruction and suppression in the mental enslavement system (otherwise known as "education"). Because the destruction and suppression is so effective, people do not perceive the hierarchies that exist in the universe, and even when I give them a purely Relational database, with all the hierarchies intact (and a nice data model in OrgChart Layout), they still do not appreciate the data hierarchies. Your comments again prove that effectiveness, and which I planned to respond to. But I have run out of time today.
Please humour me. I am trying to elevate your understanding of data hierarchies. When you first open the doc, view the data model such that it fills the window (your large screen). This would be the lowest magnification so that the whole fits in the window. This is the view of the database from 10,000 metres. Study this view for at least 15 mins before proceeding.
If you do not appreciate the database at this level, you will not be able to fully appreciate it at any other level. The solid lines (barely differentiated from the dashed lines at this distance) denote the Logical Structure of the database, and therefore the physical structure.
http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/DM%20at%2010000%20Metres.png
Please spend some time with the new Layout, and compare, before making a decision as to which is best for you. I will produce the next iteration in whatever layout you choose.
2. Changes
---------------
All discussed changes and corrections have been implemented.
3. CreatorName Replaces CreatorNo -----------------------------------------------
We discussed the method of choosing a surrogate in order to form a Common Key for a disparate ("heterogenous"( set of Subtypes. Here is an advanced method. Whereas CorporationName (the short one as distinct from the FullName which is the official and long one) and CollectiveName are single column, and can easily be used as Keys, Person is not because PersonName is LastName plus FirstName plus MiddleName. In the previous method a surrogate PersonNo; CorporationNo; CollectiveNo was used.
The advanced method uses
LastName + ", " + FirstName + " " + MiddleName
to form PersonName. We now have a Common Key. Yes, it is de-normalised (which always results in duplicated columns). Yes, it breaks 1NF, but it is a computed or derived column. Acceptable only in a mature DM that has no errors. That is for convenience: the Agent Key migrated throughout is now a much more useful one.
Concept[ [Shaw, George Bernard], 1913, Pygmalion ]
Concept[ Lerner & Loewe, 1956, My Fair Lady ] -- Variant
Movie[ Lerner & Loewe, 1964, en, My Fair Lady, ] -- Collective
MoviePersonRole[ Lerner & Loewe, 1964, en, My Fair Lady, , [Harrison, Rex], Lead Actor ]
It is advanced because it has no surrogate, the Keys are indeed "made up from the data", and therefore the additional SELECT demanded by a surrogate is eliminated. One of the many progressions that can only be found if the /RM/ has been implemented faithfully, and experience of playing with Keys is gained.
Compare with AddressNo.
4. Colour
------------
I have used a colour scheme to differentiate Concept (belongs to Agent); Movie; Edition; Instance.
For (eg) ConceptKeyword*, I have used the Concept colour, which emphasises its belong to Concept, instead of slate blue, which would emphasise its belonging to Keyword.
5. Constraint
-----------------
First, we have arrived at that point in the modelling exercise wherein all the tables are constrained by Domain (one meaning of Domain, of the 83 occurrences in the /RM/) and Key. Therefore we have achieved "DKNF", which even its author and RM saboteur Ronald Fagin states as impossible to achieve (he wrote the maffemythical definitions for the anti-Relational "NFs", so he was thinking of such abominations, RFS fraudulently marketed as "relational"). As you have seen, achieving "DKNF" is a no-brainer. Every single database I have written since 1993 is "DKNF".
Second, there are of course more Constraints to be declared for each table. I have started declaring them. Feel free to declare whatever you see fit.
The additional symbols I have used are Extensions to IDEF1X, I do not think they need explanation. However, it does make the DM a bit busy. I do have an Extension that eliminates that issue, which you may be interested in, after we settle down with this one.
When the Constraints are actually complete, we could say we have achieved Fully Constrained Normal Form, "DKNF" + C + C ...
6. Data Model
------------------ http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_11.pdf

On Tuesday, 25 February 2020 02:44:32 UTC+11, Nicola wrote:

I am coming back to discussing the model.

I was expecting more discussion.
Also, when you check the data model, could you please confirm that you are checking the Predicates (all expressed in the data model in symbols, not in text form).
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 27 February 2020 17:59:55 UTC+11, Derek Ignatius Asirvadem wrote:

5. Constraint
-----------------

[...]

Second, there are of course more Constraints to be declared for each table. I have started declaring them. Feel free to declare whatever you see fit.

[...]

When the Constraints are actually complete, we could say we have achieved Fully Constrained Normal Form, "DKNF" + C + C ...

Also, when you check the data model, could you please confirm that you are checking the Predicates (all expressed in the data model in symbols, not in text form).

An earlier post ...
[mess, improvable] ...
[contradictory data] ...
[recorded & lost] ...
["linked data models"] ...
"ontology", which will put every piece of data within a well defined
hierarchy.
and a "description logics"

The larger goal is, a fully defined Relational database, based on FOPC and the /RM/, which is therefore stable and fully integrated [all senses], plus a full set of Open Architecture Transactions (which is the Database API), and serves all needs, instead of:
- Record Filing System with zero integrity, refactored frequently
- plus a middleware layer that attempts to do what Transactions do, badly
- plus an "ontology", which has to change for every refactor
- plus a "description logics"
Thus for Constraints, I would like you to ensure that all of them are declared, such that we can work through any and all difficulties, such that all functions in the RFS+MW+O+DL are covered, and the imbecile OO/ORM method can be seen for what it is.
In case I have not stated it before, the Predicates are a powerful feedback loop for checking the veracity of the graphical data model. Ie. validation. If there is any difficulty at all in /reading/ them from the DM, please ask, and I will furnish a text version.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 27 February 2020 19:31:35 UTC+11, Nicola wrote:

On 2020-02-25, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

The relevant predicates corresponding to your model (v.10) are:

1. Each KeywordPermitted recalls one or more ConceptKeywords;
2. Each KeywordPermitted recalls one or more ProjectKeywords.

At the end of a transaction inserting (in order) into:

- Concept
- ConceptTitle
- Keyword
- KeywordPermitted
- ConceptKeyword

would result in predicate (2) to be violated. Such a transaction should
be considered correct, though. Hence, the constraint imposed by the
model is too strict.

You are correct, the V0.10 DM is incorrect.

That is easily fixed as you suggest below.

To
express "one or the other or both (but at least one)", you should make
the associations 0rCoN and add a footnote to explain that at least one
association must hold for each keyword.

Separate point. Generic answer. No. The correct way is to add
a pair of Non-Exclusive Subtypes for KeywordPermitted { Concept
| Project }.

Right. I stand corrected.

There is nothing, absolutely nothing, that cannot be defined in FOPC. The tendency of OO/ORM types is to put everything in the middle tier, and nothing in the RFS. Switching to putting everything in the database does require conscious effort.

I'd say that ...
TitleType are determined by the title.

Please explain. Context is of course, our previous discussion: that
there are more than one ConceptTitles in a particular Language for
a given Concept:

The title type is a discriminator for titles (a title is "original" xor "alternate" xor "preferred" ...).

Ok. At this stage it is not a Discriminator, it is a Classifier. As a Reference table, the referencing row can only reference a single row in the referenced table, so sure, it has a "discriminating" effect, same as a classifying effect. But we can't use the term Discriminator because it means a specific thing: the determinant for an Exclusive Subtype cluster.
So, TitleType is a Classifier, of which only one can be referenced by any one ConceptTitle or MovieTitle. TitleType determines the Title, much the same as LanguageCode does.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
Associative tables for Concept & Movie /Is varied as/ and /is derived as/. Really means multiple parents instead of single. I can see how a thing (Concept or Movie or any thing) can be derived from multiple things. But I cannot see how a thing can be a variant of more than one thing.
It might have to do with the Identifier, which is as required per the Law of Identity ... as opposed to simply /what columns identify the fact ?/. Which I might have a better grasp of. Lineage + Instance (Differentiator) is indeed the best form of Identity.
A single parent provides a single lineage, obtained by a recursive Function, possible because it is a scalar, but multiple parents cannot because it is a two-dimensional result set. There is no real sense of lineage, Like a foster kid.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Thursday, 27 February 2020 23:10:38 UTC+11, Nicola wrote:

On 2020-02-27, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

... continued.

Second, there are of course more Constraints to be declared for each
table. I have started declaring them. Feel free to declare whatever
you see fit.

Could you clarify with an example why TitleType must be in the key of ConceptTitle and ProjectTitle?

Whoa. In another post, you stated:
----

On Thursday, 27 February 2020 19:31:35 UTC+11, Nicola wrote:

On 2020-02-25, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

I'd say that ...
LanguageCode ... are determined by the title.

1. From our previous discussions, LanguageCode has to go with a Title
where the Title may not be in the cataloguer's language.

2. How can LanguageCode be determined by theTitle ?
For uneventful presentation (any GUI, any platform ... Localisation),
I thought it is the reverse.

Upon reflection, yes, I am wrong. To properly track titles in multiple languages, LanguageCode must be part of the key.

----

I believe that my question "How to identify a movie?" is now answered.

Great.
78 posts of interaction to achieve that. 73 tables thus far. I know you said the database is large, but for me, I would say around 100 tables is the average size of a database for a particular application (as opposed to an enterprise), and that it is small. And the interaction (given the lack of face-to-face meetings and workshops) is small. Very successful modelling exercise, due to precision in comms.
200 tables is medium. 500 tables is large, and normal for an enterprise level database or a financial system. I once wrote a Version 2 financial system that was 300 tables, from a 550 table Version 1.
I would like to continue until:
1. You have a database that is complete enough for La Camera Ottica.
2. You confirm that the Relational database which is ...
FOPC + RM + Relational Modelling + Transactions <-- stable
is far superior, not comparable to ...
RFS + "ontology" + "descipshun logicks" + middleware <-- ever-changing, unstable

One thing I'd still change in the model, though: I'd turn the
associations "Is Varied As" and "Is Derived As" into (associative)
entities. The reason is that one would want to add more information
related to such associations (e.g., data about sources that justify
a particular relationship between movies).

As detailed in the earlier post, I can see the validity in a Concept or Movie being derived from more than one Concept or Movie, and therefore it is not a lineage. But I cannot see how a Variant has more than one parent, and how it is not a [single-parent] lineage.

The additional symbols I have used are Extensions to IDEF1X, I do not
think they need explanation. However, it does make the DM a bit busy.
I do have an Extension that eliminates that issue, which you may be interested in, after we settle down with this one.

When the Constraints are actually complete, we could say we have
achieved Fully Constrained Normal Form, "DKNF" + C + C ...

Forget about DKNF and call it FCNF then!

Thank you. Ok.

I was expecting more discussion.

I hope I am catching up. During the next days I'll review your
constraints and validate the model against the examples from the FIAF
manual.

In your own time. I can see that Piedmont and Tirol are exploding. The weaponised Chinese virus sure is effective.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

====================
This post introduces V0.12
====================

All resolved items implemented.

67 Tables after 12 iterations. That is starting from scratch (determining entities), probably 8 iterations in the usual situation. Good work.

More constraints for you to shake a stick at.

http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_12.pdf

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

From Newsgroup: comp.databases.theory

Nicola
=====================
This post introduces V0.13
=====================
Another walk-through.
1. Just caught one mistake. Although the columns in ConceptTitle were correct, the relation /Language expresses ConceptTitle/ was missing. That probably caused your confusion about the table. Even when pointed out, and examined again, I corrected the shortened column names, but I missed the missing relation. Sorry.
2. A number of tiny mistakes corrected, spelling or transposition only. Too small to detail.

67 Tables after 12 iterations. That is starting from scratch (determining entities), probably 8 iterations in the usual situation. Good work.

More constraints for you to shake a stick at.

For me, delivering databases that are fully self-defining per FOPC and /RM/, the number of additional Constraints (beyond "DKNF" or beyond those implicit in the CREATE TABLE commands taken together), ie. CHECK commands, is:
1.5 to 2.0 times the number of tables.
I count these at the table rather than column level because most are at the table level, some are intra-table. That means 100 to 134. So far we have 29.
http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_13.pdf
Trust you and your family are safe.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Tuesday, 3 March 2020 00:48:12 UTC+11, Derek Ignatius Asirvadem wrote:

3. One reference table added: MediumType. The values need some work. It may progress to MediumType vs FormatType.

67 Tables after 12 iterations.

Correction: 63. I don't count reference tables.

Cheers
Derek

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola
I trust you and yours are safe.

On Tuesday, 3 March 2020 00:48:12 UTC+11, Derek Ignatius Asirvadem wrote:

=====================
This post introduces V0.13
=====================

1. Just caught one mistake.

Two

Although the columns in ConceptTitle were correct, the relation /Language expresses ConceptTitle/ was missing. That probably caused your confusion about the table. Even when pointed out, and examined again, I corrected the shortened column names, but I missed the missing relation. Sorry.

- /ConceptTitle manifest as 0-n Movie/ -- is Identifying
- /MovieTitle is merchandised as 0-n Editions/ -- is Identifying
- The Key in the Edition cluster has been corrected.
EditionType needs address.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Wednesday, 4 March 2020 16:40:39 UTC+11, Derek Ignatius Asirvadem wrote:

- /ConceptTitle manifest as 0-n Movie/ -- is Identifying

Retracted. Non-Identifying.

- /MovieTitle is merchandised as 0-n Editions/ -- is Identifying

Retracted. Non-Identifying.

Sorry.

Cheers
Derek

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

(Oops, I just spotted an error. Movie is Independent, but shown as Dependent. Calls for another iteration. I will wait until some of these questions get resolved.)

With a view to getting the DM complete enough to be useful for this exercise (not "production ready"), I would like to resolve all un-resolved items. I have identified several such items in previous posts, these await your discussion. Here is another.
Consider:
- In the FIAF manual, where the definitions are loose and floppy, and anything can be any or all of { Work | Variant | Manifestation | Item }, they have Identifiers (our StandardType) on all four elements of their four-level hierarchy.
- In our DM, where definitions are tight, I had implemented StandardType (FIAF Identifiers) on the three levels of the hierarchy.
But our Concept is purely cerebral, not a realisation/manifestation, which is our Project/Movie. So the question is, can there be a FIAF Identifier/StandardType for a Concept ? I suspect it is for material things only, for Movie & Edition, not for [our definition of] cerebral things. But I am not sure, our Concept may well be a material thing to them.
- I have gone through the FIAF Manual again, and could not resolve this point. Over to you.
- (Btw, that little exercise re-inforced our notion that our treatment of Variant & Derivative is superior to theirs.)
Another reason the DM is not complete is, I have not removed the Nulls. Which absolutely have to be removed before I let a DM be considered complete. It is one of those second-to-last steps.
As discusse, more Constraints, please. Especially difficult ones.
I can appreciate that you are busy, with the conditions in Northern Italy making life very difficult. If you have any time to respond to this thread, this subject is the one I would like you to prioritise.
As I am walking through the DM, I am still finding little errors. I was hoping that your walk-through, and reading off the Predicates as you go, would have caught some of those.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

I opened a new thread for MVCC.

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

From Newsgroup: comp.databases.theory

On Wednesday, 18 March 2020 02:54:48 UTC+11, Derek Ignatius Asirvadem wrote:

Further to that post. Changes and clarifications.

On Tuesday, 17 March 2020 05:24:07 UTC+11, Nicola wrote:

On 2020-03-15, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

I am considering some (perhaps too naive) changes.

The biggest difference is
that I am putting Movie (now Moving Image) under Concept rather than ConceptTitle.

[...]

- Then the Musical and Movie (more famous)
ConceptVariant[ Lerner & Loewe, 1956, en, Original, My Fair Lady ]
-- because you have only movies, books; plays; musicals; etc, which are necessary only for the addition of a Movie, have to be stored as a ConceptVariant
Movie[ Lerner & Loewe, 1964, en, My Fair Lady, ] -- no Differentiator
TitleType[ Original ], CountryCode_Produced[ us ], LanguageCode_Produced[ de ]

Of course that should be:
TitleType[ Original ], CountryCode_Produced[ us ], LanguageCode_Produced[ en ]
Further, that is just an example. If the variations were substantial, we could have used ConceptDerivative instead.

Relation ConceptTitle..MovieTitle

Three items.

A couple of minor items re IDEF1X requirements. If we used a modelling tool, it would do all this for us.
FK
There is no "FK" or (FK)" notation. Each FK column is bold only.
AK
The PK notation already shows the actual sequence of columns. The AK notation has show the the actual sequence of columns, it cannot be assumed to be in the order of appearance. Eg:
AK1.1
AK1.3
AK1.2.
If there is just one AK, I drop the "1.".

(1) Formerly called TitleReduced.

Definitely better. Keeping with my Naming Convention: Title_Concept. The underscore means something, a qualifier. See other uses.

Upon implementing it, actually, no. It is already carefully thought out. There are two aspects, I will take them in turn.
1. The full Title is in the row. TitleReduced states clearly what it is, as differentiated from Title. There is no difference, whether you take /Reduced/ off, and add /Full/.
TitleReduced & Title
vs
Title & FullTitle
2. The addition of /Concept/ to Title looked good to begin with. In the Naming Convention I use, the rule for columns that form a Key, is that it must be explicit (in another discussion, ID was corrected to CountryID).
But we get into difficulty when we consider implementing that is ConceptTitle (with both Titles for each of those rows, and Concept.ConceptTitle. Therefore I pared it back to Title. The same applies to Movie.Title.
I await your comments.

(3) Acyclic.

Yes. Enforced. By the Constraint.

Movie_VariantLineageIsValid_ck
CHECK -- PK NOT IN dbo.Movie_VariantLineage_fn( PK )
The method was discussed in the previous thread. The Function produces the Lineage, for any purpose. Here it is used to ensure that the INSERTED row is not in the Lineage, thus preventing a circular reference.

PDFs
Please feel free to annotate my PDFs with notes and comments such as this. That may be quicker than creating a new diagram. My PDFs are not protected, Preview (and any Adobe viewer) has an AddNote facility. Toolbox.

I don't know if this point was a consideration for you, I will cover it just in case. Each country has a slightly different understanding of copyright (East Asia has no understanding at all). Americans have the most stringent, but it is not correct. If a document is published in the public domain, it is public, available to all, and therefore can be copied. If it has a Copyright notification, it means it can be copied, but only with the Copyright notice intact.
Feel free to annotate any PDF I send you. Except the final version of the DM because that is the finished one.

Another reason the DM is not complete is, I have not removed the
Nulls. Which absolutely have to be removed before I let a DM be considered complete. It is one of those second-to-last steps.

Have your marked optional attributes in some way? I have assumed that
all attributes are mandatory.

Well data modelling is a progressive exercise. At the beginning we don't worry about things like that, somewhere in the middle, we start to worry, and long before the end we get them all perfect. So no, thus far (up to V0.13) I have not worried. Now we are entering the territory where I want the DM to be really useful, so yes, I will make that clear.

(In another thread we discussed hierarchies in a different sense: what has to be done at the physical level; why "deferred constraint checking" is hilariously absurd; etc. Eg. if handled improperly [or when the DM is not yet complete] the head of every hierarchy is a NULL. When handled properly that column is an optional table, and the NULL is eliminated. Again, INSERT/UPDATE/DELETE is true, and "deferred constraint checking" is not required.)

ConceptVariant and MovieVariant will be such tables, new in the next iteration.

The removal of NULL by adding a table for the optional column (the Fact that the row is a Variant, and thus that the parent row is or is not), was discussed in the previous thread. That eliminates the need for treating the head of an hierarchy asa "special case" (code or allow zero or "deferred constraint checking").

As I am walking through the DM, I am still finding little errors.
I was hoping that your walk-through, and reading off the Predicates as you go, would have caught some of those.

The problem is of course that my situation is abnormal. Normally I use a modelling tool, ERwin, and then erect OmniGraffle diagrams only when pretty ones are required. But I have a new Mac, and Windows & Erwin are not installed yet. So it is OG from start to finish. Pretty, but the risk of typos.

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

From Newsgroup: comp.databases.theory

On Tuesday, 17 March 2020 05:24:07 UTC+11, Nicola wrote:

On 2020-03-15, Derek Ignatius Asirvadem <derek.asirvadem@gmail.com> wrote:

That said, what are you proposing? That (Concept|Movie)Titles should incorporate CountryCode? I would go a different route (see below).

I am considering some (perhaps too naive) changes. Please take a look at this:

https://send.firefox.com/download/b2c409b72171dddf/#x_7fCElwXgWmgV2-MVWETg

In my previous two posts, I addressed what I thought you were trying to do, and thus my comments were within that scope. On further study of your DM, it appears that you are trying to do much more, trying to communicate much more, than I first thought. But that means I have to take the definitions as given, that there are no mistakes. (The AK notation issue is too small to consider as a mistake that warrants a discussion here.)
In that case, rather than argue the small points, I have to ask, in your DM, have you communicated the changes that you want, without mistakes ? Assuming the answer is yes ...
Concept
is ok (discussed, awaiting your response)
ConceptTitle
I do not understand what or why you have changed the Key columns. Don't think of ConceptTitle as a list of Titles for a Concept, think of it as a 1::0-n Fact about a Concept, regarding its Titles. And then, how we are going to constrain those Facts. Speaking from V0.13:
-- AK --
As is typical, when the PK is different from the parent PK plus a differentiator, the AK (a) preserves the relation from Concept PK, plus (b) the differentiator. Which in this case is TitleType & Language Code, meaning the ConceptTitle is allowed a max of 1 LanguageCode in each TitleType. It prevents silly and duplicate ConceptTitles, it forces the curator to identify what the Concept is known as in each Language. Once.
-- PK --
Is what the ConceptTitle really is, keeping in mind what we want re the migration to child tables. Which in this case is NOT the Concept PK (because it contains a TitleReduced) and we want a different TitleReduced. Which may be in a different LanguageCode. And again max 1 in each TitleType.
So, given that explanation, I do not understand what you are trying to do by: a. removing TitleType from the PK ... that would allow more than 1 TitleType per LanguageCode
Movie, MovieTitle
Most items discussed in the previous post.
New item. Separate to whether it is a child of Concept or of ConceptTitle. Given the Key has Differentiator, why do we additionally need ProductionDate in the Key. As per previous discussions, ProductionDate pertains to the Project; the Movie production, so there should be just one. Not to be confused with EditionDate which is the date of each Edition, of which there is one per Edition, many per MovieTitle.
Again, apologies, I should have understood your intent better, and included all this in the previous post.
Side-by-side comparison, in case it helps http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Concept-Project-Edition%20Response.pdf
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

Nicola

=======================
This post introduces V0.14
=======================

All items that have been discussed and resolved. Start with the view from 10,000 metres.

Table Relation http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TR%20V0_14.pdf

Table Attribute http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_14.pdf

Consolidated PDF in A3 http://www.softwaregems.com.au/Documents/Article/Database/Movie%20Title/Movie%20Title%20TA%20V0_14%20A3.pdf

- Only because you never ask. Probably too premature because the db is not quite stable yet.
- All collapsed items are clickable
- The understanding of Data Hierarchies is crucial to (a) the understanding,g and (b) the use of the database. Page 2 is the first instalment of that (I give custs more detail of course)
- Split into SubjectAreas, which are the main hierarchies

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

From Newsgroup: comp.databases.theory

On Wednesday, 18 March 2020 23:30:08 UTC+11, Derek Ignatius Asirvadem wrote:

=======================
This post introduces V0.14
=======================

Updated just now

Cheers
Derek

--- Synchronet 3.21d-Linux NewsLink 1.2