Sunteți pe pagina 1din 2

Top-down or bottom-up?

In database design, software design or even general problem solving, there


are 2 approaches: top down or Bottom up approach. Bottom up approach is
one approach wherein the problem is assessed from the lower level or
context level first and then each component or part in the context is further
detailed or more components and analyzed. This process is continues till no
further decomposition can take place. For instance, in normalization of the
database, we start with one un-normalized or bottom level table or say a few
entities and then proceed to normalize those entities or tables. We create
more tables so that the database comes to first normal form, then second,
third and so on. Usually database designers stop at 3rd normal form or Boyce
code Normal form after which we get lot of entities, a lot more in detail, than
the ones with which we started.
In some design, we need to start with Top Down approach. Especially in some
Rapid application design models or extreme programming concepts, where
we need to give the prototype early to the customer, we start with few basic
tables at the root levels. Then we go and complete the advanced prototypes,
more detailed and complete database as we keep receiving the client
feedback. Finally we arrive at the holistic database and application. This is a
pretty Top down approach as we start at the Top level first as we submit the
first proto type. Thus, we saw that we have basically 2 ways, whichever we
choose and come to the final solution. (Date, 1981).
Similarly, in the software design we adopt a top-down approach or bottom-up
approach. Again we have a choice. This also happens in real life situations.
For instance, considering a real scenario, in travel we usually have more than
one way to arrive at a destination. Similarly, in critical problem solving, there
are often multiple solutions. In database management, there is typically
more than one way to design table structures. We already discussed the
normalization process which finally yields the consolidated ERD, which is
then committed to actual logical design. We enter such design based on
these approaches to the actual database systems like Oracle. The process of
starting with world objects and modeling using entity-relationship diagrams
is also referred to as a top-down process. Starting with one large table and
functional dependencies using normalization is referred to as bottom-up
development, as we highlighted.
Thus, as it was pointed, top down method starts from the macro level like
first prototype or world objects, and then we progressively improve the
model by bringing in more details till we reach at the root levels, after which
we cannot add any more details. Bottom up approach is where we started
with un-normalized table and then we completed the normalization and
arrived at the database as required. So both have different approaches and
both have advantages and disadvantages. Advantage of top level method is

that we start as close to the system as possible and then we try to get more
details and we are close to perfection. Bottom up approach sometimes
results in better and acceptable designs as we begin with the actual
understanding and requirements as specified. We first start with what we
actually want to see as end results and then we traverse up so that we
design a consolidate system, as we do it in normalization. (Davis, 1997).
I suggest that we can use both as there are advantages specific to the
scenario. When we want the prototype to develop soon we just cant adopt a
bottom up approach as we need to develop something fairly quickly. Like we
need to just add a few tables in the database and show to the customer and
perhaps worry about the normalization later. So I suggest that we adopt
either of the methods as the situation demands, so long as we are able to
meet the object. (Lassesen and Ken, 1995).

References:
Davis, J. (1997). Universal Servers: Part 1 and Part 2, DBMS Available from
http://www.dbmsmag.com/9706dl3.html [Accessed February 3, 2016]
Techtarget. (nd): What, when, and where. Available from
http://searchoracle.techtarget.com/feature/PL/SQL-What-when-and-where
[Accessed February 3, 2016]
Lassesen and Ken (1995). Mapping the Data Access Object DAO3.0. Available
from
www.eu.microsoft.com/oledev/olemap/mapdao30.htm [Accessed February
3, 2016]
Date, C.J. (1981). An Introduction to Data Base Systems. 3rd ed. Reading,
MA: Addison-Wesley. Available from https://docs.google.com/folderview?
id=0B2Q8Nd2L-6PjZDI0NDk1ODktNGY4ZC00YTBlLWFmZjQtMzg1YzNiOWFlYjlj
[Accessed February 3, 2016]]

S-ar putea să vă placă și