On 2021-01-15, Максим Алексеев <evolv...@gmail.com
> 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
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
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.