Results 1 to 5 of 5

Thread: BI Dev as a Job

  1. #1
    Join Date
    Jul 2010
    Posts
    20

    Unanswered: BI Dev as a Job

    Hi all,

    Can I ask a non techy question.

    This is my second position as a BI Dev. The last one was for a laid back company.

    Reports and cubes were built over a matter of weeks and months.

    It was ok but I felt it did not stretch me.

    Company I work for now is the exact opposite.

    They use the reporting system for operational matters. So for example they use the Datawarehouse
    to control production and manufacturing. This seems wrong to me but could be the norm for all I know.

    Complicated Reports and cubes have to be built in a matter of days.

    My question is, is this normal in the BI world ?

    Whilst I am learning a lot more than my last position, which was with hindsight to easy, I find myself getting quite stressed.

    I feel like I am back in a support type role rather than a dev role.

    Mods, please feel free to move this if it is in the wrong place.

    Thanks all.

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by LuckyJim1001 View Post
    They use the reporting system for operational matters. So for example they use the Datawarehouse
    to control production and manufacturing.
    Not normal for BI/Datawarehouses.
    Quote Originally Posted by LuckyJim1001 View Post
    Complicated Reports and cubes have to be built in a matter of days.
    Normal for BI/Datawarehouses.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    I work in a variety of environments, some very laid back, some frentic from the git-go and ramp up fast from there.

    I see data in three distinctly different stages. OLTP data which is supports the day-to-day needs of the company. The true DataWarehouse itself, which is a pure province of SMEs (Subject Matter Experts) and DataWarehouse Professionals that should evolve very slowly. OLAP data or DataMarts, which includes cubes and other such things that are used by Analysts to discover new information that was hidden within the data.

    THe OLTP system tracks information like purchase orders, inventories, sales, etc. This is the dynamic data store that "runs the company", the data that people with "feet on the ground" providing goods, services, or both to customers work with every day. The schema for this data changes as the company changes, and that can be quite frequently in some cases.

    The DataWarehouse is the "single source of truth" for reporting, and is often the one place where you can see all of the important data and it is all meaningful and comparable. The DataWarehouse schema should only change when there are gross changes in the company or in its business model. The DataWarehouse adds data to existing entities (tables), and adds members (columns) or entities (tables), but rarely if ever changes or deletes data that is "in scope" for the DataWarehouse.

    DataMarts come and go as need arises. Their schema can change frequently based on those needs. Some DataMarts last forever, these become well defined over time and become part of operations instead of analytics. Other DataMarts are created for a limited or single purpose and might only be used once and then discarded.

    I'd have to know a whole lot more about the business in order to give you a meaningful opinion, but I agree with blindman... Running a business off of dynamic datamarts is unusual (but not completely unheard of). Changing DataMarts for Analyst requests is common. One of my long standing clients creates new DataMarts every day, and many of them are "single use then discard" datamarts.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  4. #4
    Join Date
    Jul 2010
    Posts
    20
    Thanks all. Food for thought.

    I am just going to have to get faster at working :-)

  5. #5
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    As a matter of disclosure, Pat and I subscribe to Bill Inmon's original "single source of truth" concept of the datawarehouse. Unfortunately, what is more popular these days (and what you most likely have in your office) is Ralph Kimball's cookie-cutter approach to datawarehousing that reduced everything to fact tables and star schemas, and in which the "datawarehouse" is defined as the collection of individual and (necessarily disparate) "datamarts". This concept does NOT follow the "single source of truth" ideal.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •