From: Mike Smith
Logical Persistence Models Offer Little Value
Although Figure 14 includes a logical persistence model, the
reality is that most experienced object mappers go straight from their OO
models to their physical persistence model. The extra information that logical
persistence models contain such as domain values for attributes (something
significantly more complex in the OO world considering many attributes are
other objects) and candidate keys (a spectacularly bad idea as we saw
previously) can actually be included in your class model if needed. On the
other hand, the one advantage of modeling candidate keys is that they indicate
potential ways that your users will access data--important information for
tuning your database. However, how your users will interact with your system
should be reflected in your use cases so once again I'm not so sure we actually
need to model candidate keys.
--Scott W. Ambler, Mapping Objects To Relational
Databases, p.18
Ouch.
From: Fabian Pascal
Quite familiar with Ambler and his "pearls"—see Agility Derives From, Not
Substitute For Foundation Knowledge. I sent a copy of one of his
articles to Chris Date and asked if he wanted to comment, and he said "No.
Life is too short". Here’s some other informed opinions:
Iterative
Software Development
No
Silver Bullet
From: Mike Smith
The following quote from the IEEE Computer Society's Certified
Software Development Professional - Sample Questions should be of interest.
This document is from the IEEE organization that hopes to be the gatekeeper of
best software engineering practices. For such a group to contrive the following
question and then suggest the answer they have suggested is, at best,
incredible.
"Q25. Suppose you are given the task of designing a tool to
display simple frequency distributions on discrete-valued data elements. Assume
that a frequency distribution would consist simply of the number of occurrences
of each value for a particular data element, perhaps displayed in graphical
form as a simple bar chart. The input to this tool is conceptually a
"worksheet" of rows (records) and columns (data elements). The user
would select data elements one at a time and would receive an individual
frequency distribution bar chart for the selected data element.
Which of the following storage formats for a given
"worksheet" makes computing the frequency distribution in the context
of the above tool most efficient?
1.A fully normalized relational database, potentially
with multiple relations.
2.A separate flat file for each data element.
3.A single flat file with contiguously stored
records.
4.A non-normalized relational database organized as a
star schema."
ANSWER KEY: 2
ROFL!
Their answer requires one to do at least four
badthings:
1)
To believe and recommend intuitive performance appraisals without
necessary context
2)
To recommend solutions that risk data integrity
3)
To recommend brittle solutions
4)
To recommend physically-dependent solutions
Do they even follow the hollowed practice of document reviews
with fellow experts? Eek! Maybe they did!
OK, this question and answer question is so bad, it may be
difficult to even capture the full impact.
From: Fabian Pascal
Don't get too excited—I've seen worse, and by pillars of
industry. It's rather routine.
I cannot find the question 25 via the links you provide--can
you please check and provide the right link? Thanks.
From: Mike Smith
They have changed the sample questions and answers. That's
good. A quick glance at the new questions indicates nothing quite as
interesting as the previous samples.
On further review, it appears they are extremely deficient in
covering database issues in their fifty questions. There is only one question
about databases in the entire test. Neither “relation” nor
"relational" show up at all. However, eight questions of fifty are
directed towards "objects" and "object-oriented" things.
This is mixed in with a wide variety of managerial and software engineering
issues, so eight is a big allotment. They're probably just trying to cover too
much territory, but seem "up-to-date" at the same time.
For their sole database question, the correct answer they
give is the best of the available choices, but the "rationale" for
the answer is fraught with probable misunderstanding. The tested might wonder
why there is a need to bother with a logical model if it does only three of the
four things the physical model does. I don't like the term
"internal/external" schema phrasing, though perhaps those terms of
art are well defined... somewhere. Here is the question and answers with the
same web links, hopefully they won't change again:
“24. The internal schema (physical model) of a database differs
from the external schema (logical model) in that:
[a] it describes the database
[b] it is not expected to change frequently
[c] it describes the physical structure of the database
[d] it is based on some data model
ANSWER KEY: 24. C”
Rationale: a, b, and d apply to both internal and external
schemas.
Revised 4/28/06
Posted 12/20/02
© Fabian Pascal 2000-2006 All Rights Reserved
