Data Warehousing?

  • Inmon is also a good source for the OP to learn data warehousing, but I still prefer Kimball. I grew up on IBM mainframes, migrated to UNIX (Berkeley), and finally ended up in the Microsoft camp, so I have given most everyone a good shot at impressing me regarding DW, and, in my humble opinion, Microsoft is on the right track, and certainly not the only good source for DW.

    Was I required by "law" to mention Inmon? No. Was I being dicriminatory? You bet. Is Kimball (or Microsoft) the only answer? Absolutely...not! 8-))

  • Glen (9/11/2008)


    Does it mean that what you are saying should be translated to: "When I am designing a data warehouse, I am not basing my architecture and design of a particular solution on business requirements"?

    Exactly, that's the difference in between designing a Reporting Application and designing a Data Warehouse.

    Data Warehouse by definition is generic; you design your underlying architecture no matter what the Business Requirements are then... after you have your horizontal structure in place you start building Datamarts one at a time -vertically- Customization based on Business Requirements happens only at Datamart level -and you customize just reporting, never the structure. 😉

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
  • PaulB,

    that is interesting approach. So, you are delivering to any customer, irrelevant from his needs, a framework which is based on a predefined “Information Factory"? Wouldn't it lead to a very expensive and inflexible design?

    Can you please clarify your point by suggesting a solution for the initiator of this topic? By definition (and any definition, Inmon or Kimball) that is a classic relational reporting warehouse.

    We can formulate that the need is to create a:

    1. Report/(s) accessed my multiple users simultaneously. Reports should be optimized by running at the fastest extract performance.

    2. Underlying data structures should be populated ongoing with no interruptions. Reports should reflect current DB information. Delay of up to 15 minutes is allowed.

    3. You have one database as a source of information. Suggested solution should minimally impact performance of the original DB.

    Database is OLTP; accessed by multiple users. Size of DB is 300GB and 120 GB (estimated) are involved in data structures for reports.

    4. The amount of summarization and data drilling in report(s) is minimal. However, client needs to be able to access historical information in reporting warehouse. Annual split criteria.

    BTW, the above I am calling a set of business prerequisites leading to business requirements. Without the above I cannot suggest a customer any solution. The above will define certain limitations on variety of methods and tools I can use in information access layer and data access layer.

    If I understood you correctly, you do not need the above for delivering a client your solution? Can you elaborate?

  • Glen (9/12/2008)


    that is interesting approach. So, you are delivering to any customer, irrelevant from his needs, a framework which is based on a predefined “Information Factory"? Wouldn't it lead to a very expensive and inflexible design?

    Nope.

    1- I'm delivering a comprehensive, solid, consistent, flexible horizontal infrastructure for the whole organization where you can vertically plug Datamarts as you need them.

    2- As I said before I take into consideration Business Requirements at the Datamart level.

    3- The original poster was designing a single report, the term Data Warehouse does not apply to what original poster was doing.

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
  • Just two last questions to clarify your position.

    The original poster was designing a single report, the term Data Warehouse does not apply to what original poster was doing.

    1. So, are you suggesting that the number of reports identifying a definition of data warehouse? Number of data sources? Amount of information? Complexity of report? Would you please give your definition of data warehouse ?

    As I said before I take into consideration Business Requirements at the Datamart level

    2. Business requirements that I gave you have very little to do with data mart level (so far). Based on the busines requirements most you can say that it (probably) should be a ROLAP instead of MOLAP. So far, business requirements that I gave are identifying mostly information and data layers. In this case scenario your horizontal predefined structure will have to be customized killing a purpose of original framework? You can't have a "silver bullet" for every case scenario...

    P.S.

    Very interesting article: http://www.gartner.com/it/page.jsp?id=492112

  • try again, you missed the point. 😉

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
  • I agree with Paul8, and again you are a good example of taking an obviously well informed database person, like yourself, and getting them to "see" the difference between "traditional" reporting and DW Business Analytics reporting. The fact is, a DW can be built and NOT KNOW the "reports" the user will want to see...that is truly the beauty and wonder of DW!!!

  • The thing is:

    1. I do not understand what is a "traditional" report system. For me any "traditional reporting system" is a DWH. The goal of almost all DB based applications is not to store the data - it is extracting stored data and presenting it to the end user. It is well known that reporting against OLTP is a bad idea. Thus, for me any "traditional reporting system" is a DWH (with mostly ROLAP design - guilty...) The fact that the originator currently is talking about one report is saying to me only one thing: his managers are poor project managers. If there is one report consisting of over than 100 columns (another poor design), the next 100 of them are coming shortly.

    2.

    ... NOT KNOW the "reports" the user will want to see...that is truly the beauty and wonder of DW!!!

    You consider the traditional design of a "crystal tower" a beauty?

    I do not. I consider that there is no rocket science in BI or DW and I am simply against the idea of delivering a Cadillac to a customer who asked me about tricycle or delivering a tricycle with a cost of a Cadillac.

    Excerpt from the Gartner article I mentioned above:

    "It is hard to believe that IT organizations still build data warehouses with little or no business involvement," said Frank Buytendijk, research vice president at Gartner. "But some IT experts still believe it is important to 'anticipate the needs of the users.' They also suffer from the 'Atlas Syndrome' - trying to carry the weight of the world on its shoulders- solving problems the users 'do not understand.' As valid as this may seem, it results in a negative outcome."

  • Well, Glen, I find you quite irritating. It is impossible to "show" something to someone who 1. isn't interested in "seeing" it, and 2. is afraid and misinformed about what they refuse to look at! You are, in my opinion, an arrogant, egotistical idiot! There is nothing more to say regarding your bloackheadedness!!! You are either open to understanding it or not. You certainly have no business even responding to this OPs question as you have only lived on one, isolated part of the "reporting" world...certainly, that being no where near DW!! You are clueless, man!!! God gave you two ears and one mouth for a reason -- just to be clear...so you can listen to twice as much as you speak about!!!

  • You have lost your argument when you resort to name calling.

    Please act like a professional.

  • I am not name calling, I am stating a fact! He has no clue what he is talking about, but he persists in talking about it. My argument is fine (lost nothing) for the OP and for him too as it is factual. You may believe what you want, but the facts are facts. He needs to suck it up and take what I am saying as a truthful insite into his character and method of learning.

    "Idiot" -- "Etymology: Middle English, from Anglo-French ydiote, from Latin idiota ignorant person, from Greek idiotes one in a private station, layman, ignorant person, from idios one's own, private; akin to Latin suus one's own." - Websters

    If he takes offense, it is his problem, not mine! I am being quite "professional", unless you mean speaking the truth is unprofessional!!

  • msanchez (9/12/2008)


    I agree with Paul8, and again you are a good example of taking an obviously well informed database person, like yourself, and getting them to "see" the difference between "traditional" reporting and DW Business Analytics reporting. The fact is, a DW can be built and NOT KNOW the "reports" the user will want to see...that is truly the beauty and wonder of DW!!!

    You are absolutely correct.

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
  • Thank you, but you might want to be careful siding with me. I seem to have offended some folks; I wouldn't want to get you caught up in it.

  • msanchez (9/12/2008)


    Thank you, but you might want to be careful siding with me. I seem to have offended some folks; I wouldn't want to get you caught up in it.

    😀

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.

Viewing 14 posts - 31 through 43 (of 43 total)

You must be logged in to reply to this topic. Login to reply