No project of this size can be completely without errors and this is no exception. It's sort of like writing a 300,000 word program without the benefit of a compiler to check your spelling and grammar.
If you find other errors, please let me know.
Nguyen Minh Hieu pointed out that in Figure 7-6 the CadetShips table has Ship marked as the primary key. The Cadet field should be the primary key. The table can hold only one record per cadet but might hold many records for a given ship.
|188||Davood reported this:
At page# 188 (Multiple-Object Associations) , the author is telling that the relationship between Director/Movies is one-to-one (lpage188 - last paragraph) ; however, on page189 in the last diagram it show same relationship as one-to-many (page189 - last Diagram).
Here's my reply:
Also, on page 188 the relationships between Actors/Movies and Crew-members/ Movies are described as many-to-many (Figure 9-7); however, on page189 in the first Diagram those relationships are shown as "many-to-ONE" (Figure 9-6).
The book overall is great. Thank you.
Sorry about the confusion. You're right that the text and figures don't quite match up.
One of the hardest parts of designing a database, particularly early on, is deciding what needs to be represented and what doesn't. I remember when writing this section thinking about how you might sometimes care that moves can have multiple directors and sometimes you wouldn't. I think I probably confused my self and then didn't get everything consistent.
I think the best model for this example is the one shown in Figure 9-7. You could also add a relationship table between Director and Movies if you want to deal with multiple directors on the same movie. (That's probably the most confusing mismatch between the figures.)
Then you could go back to the diagram in Figure 9-6 and change the 1.1 relationships to 1.N. (You wouldn't if you wanted a single director.)
I think that fixes it.
|212||Davood also reported:
In Figure 10-2 (page 212), the PHONES Table does not have any fields to include the Phone numbers.
The classes in many of the diagrams don't include all of the details that you might need to use the class in a particular program, but in this case it's a pretty silly omission. Clearly the Phones table needs to have the actual number to dial. Thanks for pointing this out!
I think it lacks a "Phones" field which is also a Candidate key.
I'm not sure the phone number would make a good candidate key, however, because it might not be unique. For example, a player's mother and father might give their shared home phone number as a contact number. ParentId plus PhoneNumber would be unique but it's more likely that you would want to look up numbers by ParentId plus Priority.
|164-165||Mike Roberts says:
In the 5NF try it out example Ben Winsh is specified as being able to do both metalwork and sculpture. However, he is specifically not doing sculpture at the Tribal Confusion show. This distinction is lost in step 2 which fails to characterize this relationship.
The short answer is Mike's right and I can see the source of confusion.
With the addition of either a row in the starting data specifying that Ben Winsh was showing sculpture at Tribal Confusion or the addition of a ShowingAt Table (equal to the starting table but restricted by the contents of the other tables) this problem could be solved.
Also, in the ArtistShows table Tribal Confusion is spelled as Trible Confusion at one point.
I think I was trying to make the database represent the combinations that are possible rather than the ones that are actually used. So it shows that Ben could exhibit Sculpture at Tribal Confusion even if he isn't.
A model that shows the combinations that are actually being used would probably be more useful in a real application but I think that would mess up the non-5NF-ness of the example. (I have trouble coming up with good examples for these more advanced normal forms.)
I Mike's your second suggestion for adding a ShowingAt table would be more useful in the real world but I think the first suggestion of adding a new row showing Ben entering Sculpture at Tribal Confusion fits the example better. (In a way you can infer that row from the other records but that's not supposed to be part of the example either.)
Finally, yes, Tribal Confusion was misspelled. I was suffering from Spelling Confusion not trying to start a Star Trek art show. (And yes I know that's not how you spell "tribble" either.)
If you sign up for one of my VB Helper newsletters, you will be notified when there are updates to this book.