Full text of DOI:10.1109/6294.839366

There’s a difference between an
ideal logical design and a prag-
matic implementation design.
Tim Ma rt yn
Im p le m e n t a t io n
De s ig n fo r Da t a b a s e s :
Th e ‘Fo r g o t t e n ’ St e p
ost methodologies for database
analysis and design specify con-
ceptual,logical,and physical design
as the three major design steps (see
advanced database architectures, such as distrib-
uted and parallel databases and data warehouses.
M
REFLECTIONS ON
MACHINE EFFICIENCY
Figure 1). However, although this three-step
approach is popular, there is no consensus on
when to use implementation design techniques,
such as table partitioning and denormalization.
Consequently,these techniques are treated as sub-
steps in one of the three main design steps.
This inconsistent treatment may be why many
designers frequently rely on their intuition in
applying implementation design techniques.
Clearly, this ad hoc practice shouldn’t continue.
Ad hoc anything is not a good idea when design-
ing a complex system.
To resolve this problem, I propose that we
extend the three-step methodology to include a
fourth major step, implementation design (see
Figure 2). In this methodology, implementation
design is the process of modifying an “ideal” logi-
cal data model (relational or object-oriented) to
produce a more machine-efficient, “pragmatic”
model—the implementation model. The imple-
mentation model, in turn,
To introduce the concepts and issues involved in
creating an implementation model, I offer a sim-
ple example.Figure 3 illustrates a three-step design
process for a trivial application. The conceptual
model describes just one type of entity,STUDENT.
The corresponding logical data model contains just
the STUDENT table. The physical design shows
the STUDENT table stored in one file.There is a
straightforward progression from conceptual
model to logical model to physical design.
Now let’s muddy the waters. Assume that the
STUDENT table contains the columns in Figure
4a. Also, assume that this table is very large.
Finally,assume that two queries constitute 90 per-
cent of the action against this table.
SELECT SNO, SNAME, ADDR
FROM
STUDENT
SELECT SNAME, PHONE, MAJOR
FROM STUDENT
serves as input to the physical
design step.
In sid e
This four-step method will
encourage practitioners to
resist the ad hoc approach
and simplify the other design
steps. It will also help in
addressing the additional
complexity associated with
Under these circumstances, we decide to verti-
cally partition the STUDENT table into two sep-
arate tables, STUDENT1 and STUDENT2, as
Figure 4b shows.The modified logical data model
(implementation model) directly corresponds to
the two base tables that the database administra-
tor will create.
Why Implementation
Design Is Problematic
Resources
42 IT Pro March ❘ April 2000
1520-9202/00/$10.00 © 2000 IEEE

Fig u re 1. Cla ssic t h re e -st e p m e t h o d o lo g y fo r d a t a b a se d e sig n .
In the first two steps, the models produced are inde- a particular DBMS.The big drawback to this method is
pendent of a particular database management system that there is no consistent place for implementation
(DBMS). However, in the third step, because machine design techniques like table partitioning and denor-
efficiency is the goal, the design becomes dependent on malization.
Goal: Form a conceptual model. This model, which is essentially a business model, represents a
1. Conceptual design
high-level nontechnical description of the application domain. It is thus independent of technology
and performance considerations.
Activities: Analyze the application domain from a business (versus technical) viewpoint. Discover
relevant entity (object) types, relationships, and attributes and represent them in an
entity-relationship (or object) model.
Goal: Generate a logical data model. For a relational system, this means specifying a set of tables,
including columns, and primary and foreign keys.
2. Logical design
Activities: Transform the conceptual model to a logical data model for a relational DBMS (RDBMS) by
performing transformations, such as making each entity a table. The resulting relational data model
is the ideal logical data model because it directly represents the conceptual model’s semantics. This
transformation is a cookbook process that is easy to automate using a CASE tool.
Goal: Make a logical data model machine efficient.
3. Physical design
Activities: Specify the internal storage structures and access methods that will be used to implement
the logical data model. Consider issues like index selection and physical data clustering.
Given this more efficient implementation
model, we must modify queries Q1 and Q2 to
reference STUDENT1:
Fig u re 2. Pro p o se d
fo u r-st e p m e t h o d -
o lo g y fo r d a t a b a se
d e sig n .
1. Conceptual design
SELECT SNO, SNAME, ADDR
FROM
STUDENT1
Like the three-step method,
the process begins with con-
ceptual design and moves to
logical design. However, the
logical model in logical de-
sign remains ideal. The ideal
model becomes the input
to implementation design,
whose goal is to produce a
pragmatic version of the
ideal model, the implemen-
tation model.The implemen-
tation model then becomes
the input to physical design.
This process keeps all per-
formance enhancements out
of logical design and simpli-
fies physical design.
SELECT SNAME, PHONE, MAJOR
FROM STUDENT1
2. Logical design
(Ideal relational model)
This modification enhances performance
because the STUDENT1 table is smaller than
the original STUDENT table. If a STUDENT1
row is five times smaller than a row in the orig-
inal STUDENT table (because the ESSAY col-
umn is very long),then STUDENT1 is only one
fifth the size of STUDENT. Hence, queries Q1′
and Q2′ should execute five times faster than
the original queries.This fivefold speedup would
occur 90 percent of the time.
3. Implementation design
(Pragmatic relational model)
4. Physical design
Lo g ica l o r p h ysica l d e sig n ?
Considering the preceding example,would you
say that vertical partitioning is a physical or log-
ical design technique? The best answer is proba-
bly“neither.” It is not a physical design technique
March ❘ April 2000 IT Pro 43

D A T A B A S E S
because it modifies the logical data model. But neither is it
a logical design technique because we modified the design
to enhance performance.This kind of ambiguity is one rea-
son methods and designers vacillate in where they apply
implementation design techniques. Making implementa-
tion design a separate step will resolve this ambiguity.
of many classic database design techniques.Others include
horizontal and mixed (horizontal and vertical) table par-
titioning, denormalization, data replication, materialized
views, and design restructuring (such as representing a
one-to-many relationship as a distinct table). All these
techniques have two common features:
Co st -b e n e fi t t ra d e -o ffs
• The designer modifies a logical design to help some pre-
sumably important database operations execute faster.
(This is the good news.) However, the same modifica-
tion may also cause some presumably less important
database operations to execute slower. (This is the bad
news.)
Implementation design techniques are used primarily
to enhance performance, but the cost of these enhance-
ments can be high. Vertical table partitioning is just one
• A design modification might increase the design’s com-
plexity, possibly forcing users to write complex SQL
commands. (More bad news.)
Fig u re 3. Th e t h re e -st e p d e sig n
m e t h o d a p p lie d t o a t rivia l
e xa m p le .
This type of good-news/bad-news trade-off is old news
to experienced database designers. In the example, the
major benefit of partitioning the STUDENT table is the
significant speed-up for queries Q1 and Q2. However,
there is rarely such a thing as a free lunch.In this case,per-
formance costs increase for any query that needs to access
columns from both tables. For example, the following
query could incur a significant join cost:
This example has only one entity, STUDENT.
Conceptual model
STUDENT
Logical data model
STUDENT Table
SELECT
FROM
S1.SNAME, S2.HOBBY
STUDENT1 S1,
STUDENT2 S2
WHERE
S1.SNO = S2.SNO
Also,INSERT and DELETE operations become more
expensive because these operations must be applied to
both STUDENT1 and STUDENT2. Furthermore, some
UPDATE operations would be applied to both tables.
However, if queries Q1 and Q2 constitute 90 percent of
the action, we can conclude that performance trade-offs
justify the partitioning.
Physical design
Data file
STUDENT records
Fig u re 4. Ve rt ica l t a b le p a rt it io n in g .
Vertical partitioning modifies the logical data model (a) ble implementation design techniques) may enhance
to produce the implementation model (b) for the exam- performance but it can also make the design more com-
ple in Figure 3. Table partitioning (one of many possi- plex.
STUDENT
SNO
SNAME
ADDR
ADDR
PHONE MAJOR MOTHER FATHER HOBBY
ESSAY
(a)
STUDENT1
STUDENT2
SNO
SNAME
PHONE MAJOR
SNO
MOTHER FATHER HOBBY
ESSAY
(b)
44 IT Pro March ❘ April 2000

Wh y Im p le m e n t a t io n De sig n Is Pro b le m a t ic
You would like your logical design modifications to is no longer needed. All implementation design tech-
be transparent to your users. This objective presents niques will be part of the physical design.
a problem for practitioners because
The Current Age of Confusion: Current
RDBMSs provide complete transparency
for some but not all implementation design
techniques. They provide triggers, some
view update capabilities, and smarter opti-
mizers that offer an improved level of do-
it-yourself transparency.
facilities that support transparency vary
according to the R D BMS and imple-
mentation design technique being used.
In other words, the designer confronts a
moving target. Consider the past and
future of transparency support.
Ancient History: In the early 1980s, most
Fortunately, history shows that we can
RDBMSs provided very limited transparency. They did expect enhanced physical design facilities as
not support triggers, and view update capabilities were RDBMSs continue to evolve. Take Oracle. There was
very basic. Users had to deal with complex logical designs. no support for horizontal partitioning before Version
Fortunately, most early applications were small, relative 7.3, which provided partial transparency for query
to today’s.
operations; Version 8 now offers complete trans-
parency. Therefore, facilities to support logical design
transparency will continue to improve as RDBMSs
evolve. We might hope that the Golden Age arrives
soon, but the availability of advanced database archi-
tectures means you will probably be using a four-step
method for some time.
The Golden Age: Some day your RDBMS will pro-
vide complete physical and logical data independence.
The user will always see the ideal logical data model.
All performance enhancement techniques will be com-
pletely transparent, so the implementation design step
Partitioning the STUDENT table makes the design more
complex, and this complexity also has a cost that we must
consider. Users who write SQL statements would have to
able to transform Q1 into Q1′, and Q2 into Q2′. If the
RDBMS can support such transformations, we can make
logical design modifications transparent to users.(The for-
mal term for this idea is “logical data independence.”)
• be aware of the partitioning and know which columns Clearly, designers must consider the transparency issue
are in which tables,
during implementation design.
• occasionally execute more complex and costly join
queries like Q3, and
Su p p o rt in g t ra n sp a re n cy
• execute multiple INSERT and DELETE statements
within a single transaction to maintain database
integrity associated with the one-to-one correspondence
between the rows in STUDENT1 and STUDENT2.
Supporting transparency is very important for two rea-
sons. First, as previously indicated, the modification of a
logical design usually increases its complexity. And
increasing the complexity of a logical design also increas-
es the opportunity for user errors. Therefore, supporting
transparency should reduce user errors.
Another important reason to support transparency is
schema evolution. For example,assume that after you par-
tition the STUDENT table, you subsequently decide to
move the ADDR column from STUDENT1 to STU-
DENT2. You would have to notify your users about this
design change. Thereafter, some users would have to
rewrite and retest every query like Q1′ that references
ADDR. If your shop has a “go into production” bureau-
cracy (auditing,operations scheduling),this simple design
change could cost a lot of time and money.
This example illustrates that a modest design change
can significantly increase design complexity. However, if
we can (somehow) make the logical design modification
transparent, we can then realize the performance benefit
without making the user suffer the cost associated with
additional complexity. In the example, we would like the
user to be able to execute the following query against the
original STUDENT table:
SELECT SNAME, HOBBY FROM STUDENT
Ideally, the RDBMS would automatically convert this
simple query into the more complex Q3.It should also be
Supporting transparency can be very simple, quite dif-
ficult, or impossible, depending on the specific DBMS and
March ❘ April 2000 IT Pro 45

D A T A B A S E S
the design modification being con-
sidered. Commercial database sys-
tems provide facilities that directly
support transparency for some,but
not all, implementation design
techniques. For example, most of
these systems support horizontal
partitioning, but they do not
directly support vertical partition-
ing. Hence, the application of ver-
tical partitioning will not be
transparent to all users;some users
will see an implementation model
that differs from the ideal logical
data model.
Fig u re 5.
Ideal logical model
St e p s w it h in
im p le m e n t a -
t io n d e sig n .
Step 3.1 Implementation
analysis
(DBMS-independent)
Collect “how big, how many,
how often” statistics for the
current design
The goal is to gener-
ate an efficient imple-
mentation model that
also supports an ac-
ceptable level of trans-
parency (logical data
independence). The
conceptual and logi-
cal design steps (see
Figure 2) have gener-
ated an ideal logical
data model that serves
as the initial im-
plementation model.
During the implemen-
tation design step,
designers iterate the
substeps to improve
the model according
to their performance
and transparency re-
quirements.
Represent the statistics within
some organized format
Identify potentially problematic
hot spots
For each hot spot, iterate steps 3.2 and 3.3
until you have analyzed and considered design
modifications. Then document the final
implementation model, including statistical
information, and proceed to physical design.
An RDBMS provides complete
transparency support for a specific
design technique if three conditions
hold:
Step 3.2 Consider potential
design modification
(DBMS-independent)
• The technique can be defined and
implemented with a declarative
data definition language (DDL).
• Users can execute INSERT,
UPDATE, or DELETE state-
ments against a logical table
without experiencing a loss in
data integrity.
Propose a design modification
to resolve a problematic
“hot spot”
Perform a cost-benefit analysis
of the proposed modification
Reject proposed
design modification;
return to Step 3.2
Does
the proposed
modification
No
significantly enhance
performance?
• The optimizer is smart enough to
capitalize on the design tech-
nique.
Yes
Fall through
to Step 3.3
According to these criteria,com-
mercial systems do not support
complete transparency for vertical
partitioning, but they do support
transparency for horizontal parti-
tioning. Thus, you should consider
horizontal partitioning during
physical design and vertical parti-
tioning during implementation
design.A design technique’s trans-
parency establishes a critical dis-
tinction between implementation
and physical design. Unfortunately,
this distinction varies according to
both the technique and the
RDBMS under consideration.
If, for a given design technique,
your RDBMS does not support
complete transparency,you may be
able to achieve an acceptable level
of partial transparency by creating
views or triggers. This do-it-your-
self approach can usually provide
Step 3.3 Commit/reject
design modification
(DBMS-dependent)
Commit to the
design modification;
revise implementation
design and statistical
information;
Can
your RDBMS
directly provide
complete
return to Step 3.2
Yes
Yes
Yes
transparency?
No
Fall through
Reject the
design modification;
return to Step 3.2
Does
your
application require
complete
transparency?
No
Commit to the
Fall through
design modification;
revise implementation
design and statistical
information;
Is a
partial
“do-it-yourself”
transparency sufficient
for your
return to Step 3.2
application?
Reject the
design modification;
return to Step 3.2
(Can views and/or
triggers provide an
acceptable level
of transparency?)
No
46 IT Pro March ❘ April 2000

transparency for queries, but it will often fail to provide
transparency for some update operations.
design.The required skills are similar to those of the phys-
ical designer, but because steps 3.1 and 3.2 are independ-
ent, designers don’t need to possess a deep knowledge of
the specific production-level DBMS, which physical data-
base designers must have.
USING A FOUR-STEP PROCESS
As with conventional three-step design methods, the
conceptual and logical design steps in the four-step
method generate an ideal logical
These product-process-people considerations justify the
positioning of implementation
data model.The difference is in the
design as a major independent step
within a database design method-
ology.
If t wo s et s of des ign
a ct ivit ies cha nge
last two steps,implementation and
physical design, which address
machine performance.
s ignifica nt ly in t er ms
of pr oduct , pr oces s ,
or people, it is
Figure 5 outlines the substeps
within the implementation design
step by presenting a variation of
TobyTeorey and James Fry’s LRA
schema refinement methodology
within the context of an RDBMS.
This methodology is not dog-
matic; designers can easily tailor it
for a specific application environ-
De sig n a d va n t a g e s
Decoupling implementation de-
sign from the logical and physical
design has significant advantages
for all design steps except concep-
tual design. In implementation
design, practitioners are forced to
complete important activities before
they initiate physical design:
common s ens e t o
decouple t hem.
ment. For example, step 3.3, unlike steps 3.1 and 3.2, is
DBMS-dependent. It presumes that you know your pro-
duction RDBMS. An alternative approach would be to
move step 3.3 into physical design, making all activities in
implementation design independent of the RDBMS.This
alternative approach also lets you postpone selecting your
production RDBMS until the beginning of physical design.
• Collect and represent data and access characteristics in
some organized format.
• Identify hot spots in the design.
• Consider some computational model to evaluate design
trade-offs.
• Consider the transparency issue before committing to a
design modification.
Im p o rt a n t d iffe re n ce s
Some people may argue that database designers should
just retain the current practice of using implementation
design techniques as a substep of logical or physical design.
But how do you define a major design step? I believe that
if two sets of design activities change significantly in the
product they yield, the process they follow, or the people
who may perform them, it is common sense to decouple
them. Implementation design has significant differences
in all three areas, relative to logical and physical design.
Logical design benefits from removing implementation
design considerations because it
• stays “ideal;” directly representing the semantics of the
conceptual data model;
• need not consider process;
• is strictly logical and thus DBMS-independent;
• remains a simple “cookbook” procedure that a CASE
tool can execute; and
• can then be done by someone who understands con-
ceptual and logical data models but does not deeply
understand database performance issues.
In the product... A pragmatic implementation model
might look very different from the ideal logical data
model. It also differs from a physical design specification
because it is visible to users and does not reference inter-
nal DBMS-specific facilities like indexes.
Within physical design,the designer can focus on the best
way to use the internal access methods provided by the
specific DBMS.This has the following implications:
In the process... Implementation design techniques are
very different from and much more challenging than the
cookbook design transformations applied during logical
design.The techniques also differ from a physical design
because they do not consider internal, DBMS-specific
facilities.
• The implementation model is practically frozen.Making
all logical design modifications before physical design
reduces the possibility that the physical designer will ask
for a change to the logical design. Also, applications
developers can start to develop programs in parallel with
physical design, and programmers need not worry that
logical design changes will require program changes.
• Statistical information about access patterns gathered
during implementation analysis is available to the phys-
In the people... The implementation designer must
understand performance issues for relational databases—
knowledge that is not required for conceptual or logical
March ❘ April 2000 IT Pro 47

D A T A B A S E S
ical designer.This information will be very use-
ful for physical design decisions such as index
selection and data clustering.
Re so u rce s
• If desired, you can postpone selecting a pro-
duction-level DBMS until just after implemen-
tation analysis (step 3.1). After this step, you
can provide potential vendors with a specifica-
tion that completely describes your logical data
model and related performance requirements.
• A technical specialist with limited knowledge
of the application domain can do the physical
design.
Bo o ks
Design of Database Structures, Toby Teorey and James Fry,
Prentice Hall, Upper Saddle River, N.J., 1982.An excellent oldie
but goody that predates most commercial RDBMSs. The
authors use “implementation design” to describe the design
phase between conceptual and physical database design.Within
this phase, they present a logical record access (LRA) design
method that explicitly decouples schema formulation and
schema refinement. The LRA method triggered my thoughts
on the advantages of further decoupling schema refinement by
“promoting” it to a major independent design step.
An Introduction to Database Systems, C.J. Date, 7th ed.,
Addison Wesley Longman, Reading, Mass., 2000. Date artic-
ulates the importance of both physical and logical data inde-
pendence.
Object-Oriented Modeling and Design for Database
Applications, Michael Blaha and William Premerlani,
Prentice Hall, Upper Saddle River, N.J., 1998. The authors
identify 20 primitive transformations to convert a high-level
object model to a detailed object model. Especially interest-
ing is their presentation of a partial mathematical theory to
formalize these transformations. Later, during relational
design, they also consider alternative mappings from a detailed
object model to tables. Their approach appears to be consis-
tent with the idea of decoupling schema refinement from phys-
ical design.
ADVANCED ARCHITECTURES
Thus far,I have presumed that the database will
be implemented on a conventional centralized
DBMS executing on a single-CPU server. Imple-
mentation design can incorporate design activi-
ties for advanced database architectures.Systems
that use advanced database architectures should
still define conceptual and logical data models.
During implementation design, you would then
explicitly consider logical design modifications
specific to the type of advanced database archi-
tecture.
Dist rib u t e d d a t a b a se syst e m s
A distributed database is a collection of
autonomous database systems that share data via
a communications network.Database design in a
distributed environment considers data parti-
tioning (fragmentation), data replication, and
allocation of data to different sites. Distributed
design techniques are based on a “how big, how
many,how often” analysis except that “how often
a program is executed” becomes “how often a
program is executed at a particular site.” In other
words,data analysis in a distributed environment
builds on the implementation analysis described
in Figure 5.
Principles of Distributed Database Systems, Tamer Ozsu
and Patrick Valduriez, 2nd ed., Prentice Hall, Upper Saddle
River, N.J., 1999. Major text on distributed database technol-
ogy and design methodology.
Art icle s
Surajit Chaudhuri and Umeshwar Dayal, “An Overview of
Data Warehousing and OLAP Technology,” ACM SIGMOD
Record, Mar. 1997, pp. 65-74.
The ideal distributed database should appear to
the user as a single centralized database. (This is
C.J. Date’s Rule Zero for distributed databases.)
This means that a distributed database should pre-
serve the ideal logical data model. It should hide
any design complexity that stems from three
sources: some tables are partitioned into frag-
ments, some tables/fragments are replicated, and
tables/fragments or their replicas are allocated to
and can migrate among different sites.
Unfortunately, the ideal distributed database
does not exist.Vendors have provided distributed
systems that support replication transparency.
However,these systems do not provide complete
support for fragmentation or allocation trans-
David DeWitt and Jim Gray, “Parallel Database Systems:
The Future of High Performance Database Systems,” Comm.
ACM, June 1992, pp. 85-98.
Le Gruenwald, and Margaret Eich, “Selecting a Database
Partitioning Technique,” J. Database Management, Vol. 4,
No. 3, 1993, pp. 27-39.
Shamkant Navathe,“Evolution of Data Modeling for Data-
bases,” Comm. ACM, Sept. 1992, pp. 112-123.
Tamer Ozsu and Patrick Valduriez, “Distributed and
Parallel Database Systems:Technology and Current State-of-
the-Art,” ACM Computing Surveys, Mar. 1997, pp. 1-4.
Nick Roussopoulos, “Materialized Views and Data Ware-
houses,” ACM SIGMOD Record, Mar. 1998, pp. 21-26.
48 IT Pro March ❘ April 2000

parency. You can provide do-it-yourself allocation trans- ally visible to the user. In fact, some warehouse users may
parency by creating synonyms,views,or stored procedures, never access the underlying tables that contain the source
but it is very difficult to support fragmentation trans- data.
parency. The reality is that some
users of a distributed database will
see a distributed implementation
model that is derived from a global
logical model. For these reasons, I
contend that the implementation
design step provides an appropri-
ate framework for considering dis-
tributed design techniques.
he practical advantages of
implementation design tech-
The four -s t ep met hod
pr ovides a founda t ion
for a ddr es s ing t he
incr ea s ed complexit y
int r oduced by r ecent
a dva nces in pa r a llel
da t a ba s es a nd da t a
wa r ehous e s ys t ems .
T
niques are obvious.They have
been applied over the past four
decades in the context of file sys-
tems and centralized database sys-
tems. Given the relative simplicity
of these older systems, many prac-
titioners have successfully used
these techniques on an ad hoc
basis.However,as systems become
more complex, the ad hoc ap-
proach will become problematic.
Recent advances in distributed
and parallel database and data
Pa ra lle l d a t a b a se syst e m s
Parallel DBMSs are popular for
applications that access very large
tables.A parallel DBMS sits on top
of a multiprocessor hardware sys-
tem and attempts to improve
response time via intraquery parallelism. It may also try warehouse systems have greatly enhanced the functional-
to improve throughput via interquery parallelism.
A parallel DBMS has many features in common with a
distributed DBMS. Within a distributed database, each
ity of database technology. They have also dramatically
increased the complexity of database design. By making
implementation design a separate step, the four-step
DBMS operates in parallel with other remote DBMSs. method provides a foundation for addressing this addi-
Within a parallel DBMS,a network-in-a-box connects mul- tional complexity (which will surely transcend the intu-
tiple processors. Parallel design techniques are also simi- itive powers of most mortal designers).
lar to distributed design techniques.Tables are partitioned
Of course,there is much work to be done to flesh out the
(fragmented) and allocated to different disk devices (ver- four-step method. At a practical level, the most obvious
sus sites).Furthermore,a parallel DBMS application may task is to develop a comprehensive CASE tool to expedite
entail some data redundancy, especially if it uses RAID
technology.
Horizontal table partitioning across multiple disks is the
the implementation design step.The challenge is to build
a tool that supports the major implementation design tech-
niques.A first step would be to specify a generic input data
primary design technique, although you could use others. structure—a “super” CRUD (create-retrieve-update-
Effective partitioning is necessary to realize parallel pro- delete) matrix.Such a data structure could serve as a stan-
cessing.Various partitioning strategies have been proposed
(range partitioning and hashing, for example) to support
this objective.
dard input to the various computational models associated
with different implementation design techniques.This kind
of data structure would be feasible because all the associ-
A parallel DBMS makes horizontal partitioning trans- ated computational models are fundamentally based on
parent to users. Hence, you should define horizontal par- implementation analysis (“how big,how many,how often”
titioning within the physical design step.However,because
implementation analysis is the foundation of an effective
statistics) for a given logical design.
Meanwhile, although CASE tool support lies in the
partitioning strategy, you could also make partitioning future, there are still plenty of reasons to consider using a
decisions within the implementation design step.
four-step design process.This is a significant but not radi-
cal enhancement to current practice.The classic three-step
methodology has been very effective,but I believe we can
improve it by promoting implementation design to a fourth
major step.The potential benefits make it well worth con-
sidering. ■
Da t a w a re h o u se s
A data warehouse is a special application that usually
supports very large tables. Because it often uses a parallel
DBMS, many of the same observations apply. A typical
data warehouse has two characteristics relevant to imple-
mentation design.First,it stores materialized views (tables
with derived data). Second, most applications are read-
only, which means that denormalized tables and redun-
dant data are common. Implementation analysis is
necessary to effectively design the materialized views and
denormalized tables. Furthermore, these tables are usu-
Tim Martyn is a faculty member in the Computer and
Information Sciences Department at Rensselaer at Hart-
ford. Contact him at martyn@rh.edu.
March ❘ April 2000 IT Pro 49