MESSAGE
| DATE | 2014-11-26 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] Why Data Models Shouldn't Drive Object Models (And Vice Versa)
|
From owner-learn-outgoing-at-mrbrklyn.com Wed Nov 26 02:09:40 2014
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 98BA0161143; Wed, 26 Nov 2014 02:09:40 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 7F1C7161157; Wed, 26 Nov 2014 02:09:40 -0500 (EST)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 72D96161143
for ; Wed, 26 Nov 2014 02:09:39 -0500 (EST)
Received: from [10.0.0.42] (unknown [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTP id E7005137E6;
Wed, 26 Nov 2014 02:09:38 -0500 (EST)
Message-ID: <54757D01.9090904-at-panix.com>
Date: Wed, 26 Nov 2014 02:10:57 -0500
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: ping-Tsai Chung ,
Samir Iabbassen ,
learn-at-nylxs.com, ping-Tsai Chung
Subject: [LIU Comp Sci] Why Data Models Shouldn't Drive Object Models (And Vice Versa)
References: <547578D7.1020604-at-panix.com> <54757AED.8070802-at-panix.com> <54757BE7.5020204-at-panix.com>
In-Reply-To: <54757BE7.5020204-at-panix.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
Why Data Models Shouldn't Drive Object Models (And Vice Versa)
This is a SUPURB article that should be mandatory reading by anyone in a
database class.
http://www.agiledata.org/essays/drivingForces.html
A common problem that I run into again and again is the idea that a data
model should drive the development of your objects. This idea comes in
two flavors: your physical data schema should drive the development of
your objects and that a conceptual/logical data model should be (almost)
completely developed up front before you begin to design your
objects. Both of these views are inappropriate for non-agile projects
and clearly wrong for agile projects. Let's explore this issue in more
depth. Why do people want to base their object models on existing data
schemas? First, there is very likely a desire to reuse the existing
thinking that went behind the current schema. I'm a firm believer in
reusing things, but I prefer to reuse the right things. There is an
impedance mismatch
between the
object and relational paradigms, and this mismatch leads object and data
practitioners to different designs. You also saw in Object Orientation
101 that
object developers apply different design techniques and concepts than
the techniques and concepts described in Data Modeling 101
that data
modelers apply. Second, the database owner seeks to maintain or even
enhance their political standing within your organization by forcing you
to base your application on their existing design. Third, the people
asking you to take this approach may not understand the implications of
this decision, or that there are better ways to proceed. Why is basing
your object model on an existing data schema a bad idea? First, your
legacy database design
likely has some
significant problems.
**** In practice, I look at existing physical data models to get an idea
of what is currently going on, and to get a feel for the technical
constraints that I'll have to work with, but I won't unnaturally
constrain my application with a bad data design.****
Second, even if the existing database design is very good there can be
significant differences in the way that you map objects to relational
databases. Consider Figure 1
which depicts three object schemas, all of which can be correctly mapped
to the data schema on the right. Now pretend you have the data schema as
your starting point. Which of the three object schemas would you
generate from it? Likely the top one, which may in fact be correct for
your situation, but then again maybe one of the other two schemas could
have been better choices. Yes, all of the models in Figure 1
could be improved, but I neede
|
|
