Database Reference
In-Depth Information
plication should ideally cover the steps we go through during these three levels of design
anyway. For example, if we jump straight into building a MongoDB database, we would
still need to ask at least some of the questions about definitions and business rules; it's
just that we would do it all at once instead of in separate phases. Also, if we don't follow
these modeling steps proactively, we will be asking the questions during support, where
fixing things can be much more expensive in terms of time, money, and reputation. Believe
me, I know—many of my consulting assignments involve fixing situations due to skipping
levels of design (e.g., jumping right to the physical). I can't tell you how many times during
my assignments I have heard a manager use the phrase “technical debt” to summarize the
high cost to maintain and poor performance of applications built without conceptual and
logical data models. For example, take the MongoDB document we created in the previous
chapter:
{
titleName : “Extreme Scoping”,
subtitleName : “An Agile Approach to Enterprise Data Warehousing and Business Intelligence”,
pageCount : 300
}
This is a very simple document with just three fields: the topic's title name, subtitle name,
and page count. However, even with just these three fields, there are conceptual, logical,
and physical questions that need to be answered.
During conceptual data modeling, we would address questions such as these:
•
What is the right name for the concept of “book”? Should we call it a “book” or a
“title” or a “copy” or an “intellectual unit”?
•
What is a clear, correct, and complete definition for the concept of “book”? Once
we get this definition agreed upon and documented, nobody else will need to go
through this painful definition process again.
•
Is the scope only book, or can it include other important concepts such as author,
publisher, and customer? That is, what is the scope of the application?
•
Can a book exist without an author?
•
Can a book be written by more than one author?
During logical data modeling, we would address questions such as these:
•
Is the topic's title name required? Is subtitle name required? Is page count re-
quired?
•
Can a book have more than one subtitle?
•
How do you identify a book?
•
Is an eBook considered a book?
