From Newsgroup: comp.databases.theory

Hello everyone.
I'm learning databases now by reading a book of Hector Garcia-Molina
"Database Systems The Complete Book" 1st edition.
There're a lot of interesting exercises and on some of them
there're answers here - http://infolab.stanford.edu/~ullman/dscb.html#solutions.
But not for all.

And when I see a question (exersise), I'm not always sure that
my solution to it is fully correct.
+ Some of author's inferences are not obvious for me.
And I'd like to discuss them with someone,
but as I am self-taught in database theory and I don't have an opportunity to discuss questions with anyone in person, I was hoping that someone here would be able to clarify some points that I do not understand.

So here's one of them.
BTW: This paragraph is taken out of context, so you might not understand it. Just in case, I give a link to the book and page: shorturl.at/rxBOS
(page 43).

The authors write:

Now we going to give the conditions under which we prefer to use an attribute instead of an entity set.
Suppose E is an entity set. Here are conditions that E must obey, in order for us to replace E by an attribute or attributes of several other entity sets.
1. All relationships in which E is involved must have arrows entering E.
That is, E must be the "one" in many-one relationships
2. The attributes for E must collectively identify an entity. Typically, there will be only one attribute, in which case this condition is surely met. However, if there are several attributes, then no attribute must depend on the other attributes.
3. No relationship involves E more than once

I don't understand the 2nd point when there are several attributes.
Why no attribute must depend on the others?
These rules are abstracted out of concrete cases, so..
Let's assume we have some relation R with A and B as its attributes: R(A, B)
If B depends on A (B -> A) then for every entity of R the following statement is true: if A have a value "aVal" then B always have a concrete value "bVal".
I.e. there can't be entities where A = "aVal" and B != "bVal".

So why can't we replace E with it's attributes in this case?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On 2021-01-15, -L-#-|-U-+-+ -E-+-|-|-U-|-|-# <evolventa94@gmail.com> wrote:

Hello everyone.
I'm learning databases now by reading a book of Hector Garcia-Molina "Database Systems The Complete Book" 1st edition.
There're a lot of interesting exercises and on some of them
there're answers here - http://infolab.stanford.edu/~ullman/dscb.html#solutions.
But not for all.

And when I see a question (exersise), I'm not always sure that
my solution to it is fully correct.
+ Some of author's inferences are not obvious for me.
And I'd like to discuss them with someone,
but as I am self-taught in database theory and I don't have an opportunity to discuss questions with anyone in person, I was hoping that someone here would be able to clarify some points that I do not understand.

So here's one of them.
BTW: This paragraph is taken out of context, so you might not understand it. Just in case, I give a link to the book and page: shorturl.at/rxBOS
(page 43).

The authors write:

Now we going to give the conditions under which we prefer to use an attribute instead of an entity set.
Suppose E is an entity set. Here are conditions that E must obey, in order for us to replace E by an attribute or attributes of several other entity sets.
1. All relationships in which E is involved must have arrows entering E.
That is, E must be the "one" in many-one relationships
2. The attributes for E must collectively identify an entity. Typically, there will be only one attribute, in which case this condition is surely met. However, if there are several attributes, then no attribute must depend on the other attributes.
3. No relationship involves E more than once

I don't understand the 2nd point when there are several attributes.
Why no attribute must depend on the others?

The example in the book is something like Movie(SomeKey, StudioName) and Studio(StudioName, Address), where SomeKey is the primary key of Movie,
and StudioName is the primary key of Studio. Then, Address depends on StudioName.

If you were to get rid of Studio and incorporate its attributes into
Movie, you would obtain Movie(SomeKey, StudioName, Address), with
SomeKey still as the primary key. But Address still depends on
StudioName, which is not a key, and dependencies from anything that is
not a key are bad. I believe that you can easily verify by yourself that
the latter Movie schema leads to redundancy and inconsistencies.

These rules are abstracted out of concrete cases, so..
Let's assume we have some relation R with A and B as its attributes: R(A, B) If B depends on A (B -> A) then for every entity of R the following statement is true: if A have a value "aVal" then B always have a concrete value "bVal".
I.e. there can't be entities where A = "aVal" and B != "bVal".

So why can't we replace E with it's attributes in this case?

I assume that E has a many-one relationship with R, that, in relational
terms, E is E(... A) with A being a foreign-key referring to R(A,B)
(where A is the primary key of R). Then, this is exactly the
Movie/Studio situation depicted above, with E = Movie and R = Studio.

And, strictly speaking, it's not that you "can't" perform the
replacement; but if you did, then the result would not be not a good
database design.

As a general remark, I am not sure how the rules you mention help
understanding the database design process. It seems to me that they
instill confusion rather than anything else.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Friday, 22 January 2021 at 22:51:03 UTC+11, Nicola wrote:
As a general remark, I am not sure how the rules you mention help understanding the database design process. It seems to me that they
instill confusion rather than anything else.

No kidding.
They (the Date; Darwen; Fagin Gulag) started with denial of reality (The Relational Model, logical only), then they too fragments on the Relational Model, built on top of 1960's Record Filing Systems (physical), and fraudulently marketed that confused filth as "relational". Then they and their followers wrote "textbooks" for that confused filth. The "Alice book", Abiteboul; Hull; Viannu. Elmasri and Navathe. This is just the latest "textbook", by someone who is stuck in that confused filth, trying desperately to design a database using it, clueless that it is confused filth.
Get back to the real Relational Model, boys and girls. The one and only Dr E F Codd. No pretenders. Nothing confused. Everything clear. FIFTY YEARS of confusion eliminated.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Friday, 15 January 2021 at 15:59:36 UTC+11, evolv... wrote:

Just in case, I give a link to the book and page: shorturl.at/rxBOS
(page 43).

The link fails.

Cheers
Derek

--- Synchronet 3.21d-Linux NewsLink 1.2