TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: "Top down" vs. "bottom up" From:"Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM> Date:Tue, 5 Apr 1994 10:11:36 -0500
This letter replies to:
Can someone enlighten me (and probably a few others too):
what is "top down" design and what is "bottom up" design?
I've often run across the terms in tech writing and
other design contexts, but when I ask for definitions, the
replies don't seem consistent. (Is this like "another think/
thing coming?")
Ken d'Albenas
Calgary, Alberta
(-::
***************************
I don't know what context you're seeing this in, but in data modeling (the
process though which databases should be designed), "top down" refers to
figuring out what entities the system needs to function (For example: Customer,
Order, Item, Invoice), then working out what relationships the entities should
have (one-to-one, one-to-many, many-to-many) and finally deciding what
attributes each entity should have (for example: Customer Name, Delivery
Address, Item, Price, etc.). This approach has a kind of wonderful conceptual
purity, but sometimes produces a model that can't deal with reality.
"Bottom up" design starts with the known data (Invoices, Customer lists, Order
Forms, etc.) and applies a process called "normalization" that breaks it down
into chunks (entities) appropriate for planning a relational database. The
normalization process also reveals what relationships the entities should have
and what the attributes of each entity should be. This approach assumes that
the data you have to start with is a pretty good model of what you're trying to
do, which isn't always true.
Basically, "top down" design proceeds from the abstract (the entity-relationship
diagram) to get to the concrete (data), while "bottom up" design proceeds from
the concrete (data) to get to the abstract (the entity-relationship diagram).
"Top down" is often used in designing new systems, while "bottom up" is often
used when trying to figure out what the heck somebody else did in an existing
system. In reality, most data modeling sessions are iterative, bouncing back
and forth between "top down" and "bottom up" modes as the need arises.
There's a lot more to it than that, of course, but that's a reasonable rough
sketch.
