tag:blogger.com,1999:blog-6411920579549337139.post9084854010812899039..comments2023-12-31T05:26:17.608-08:00Comments on DATABASE DEBUNKINGS: This WeekFabian Pascalhttp://www.blogger.com/profile/01346669716885494092noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-6411920579549337139.post-63322706611913398212017-08-25T10:04:52.152-07:002017-08-25T10:04:52.152-07:00"Tables should mirror logical objects but any..."Tables should mirror logical objects but any object may encompass multiple tables" Any man can have one wife but any wife may relate to multiple men. Technically speaking, there is nothing wrong with that. Unfortunately, we're not in a technical business :-) And to those interpreting this word "mirror" in a very rigid one-to-one sense, the blatant contradiction should be obvious.<br /><br />What's wrong :<br /><br />"Use a relational data model for storage." (1) The kind of model that illustrates the structure of the world that is of interest to a business problem owner, is best called an information model, not a data model. (2) And of course relational illustrations of a business problem are not used "for storage", but for documenting the "logical nature/structure of the problem (and/or its solution). (3) And of course most likely the author confused fully formal logical models (which relational information models ought to be) with conceptual models (which are always informal to some degree) such as ER diagrams, but there is not enough material in the quote to evidence this suspicion.<br /><br />"Design the database tables using relational rules including 3rd normal form" Nothing wrong with that of course, though is best for the author to be aware of what 3d normal form actually really means, precisely. And I suspect that is far from certain.<br /><br />"Tables should mirror logical objects but any object may encompass multiple tables" Even if you consider a set of "tables" and a set of "objects [or classes thereof]" as distinct design artefacts, any designer should realize that there is still only one business problem, and that both the set of tables and the set of object classes should never be more than distinct incarnations of the very same single semantics : those of the business problem. It may be the case that the author is insufficiently aware of that, and its consequences for the degrees of freedom he has when doing his design work around the problem.Erwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.com