In my experience Top Down is where you start with Reports that need to be filled. These in turn dictate the design of your cube, data mart and underlying relational schema. Bottom up is starting with a list of capabilities that are needed which you then can build your Relational schema off of then cube and reports.
In my experience top down is faster initially because you can quickly meet the needs of the orginization, but typically forces a design that may not be as flexible making expanding the capabilities of the solution more difficult.
It is an easy trap to get caught up in. My experience leads me to believe you get forced in a top down method when people do not understand the technology or methodology and are unwilling or unable to learn.
I find myself quickly going from a bottom up to Top down environment yet again.
not so much a methodology as what you include. If you build from the report aspect you are likely to only fit the needs of those reports. If you start with here is the the business need we are trying to build for you will probably end up with a more robust design, that includes the immediate needs but also some people have not yet considered.
For me I would say it is more correct to say that. Cubes are A top level entity the star schema supports the cube so I see the star schema as the bottom.
is it not possible to apply top down and bottom up methods to the design of cubes ? and at the same time apply top down and bottom up methods to the design of star schemas.
My point is that I am trying to write a document which describes the difference between top down and bottom up techniques, and am unsure weather to label cubes as top down and stars as bottom up..
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.