none
transformation vs business logic

    Question

  • can anyone please tell me the difference between a transformation and business logic in the context of a Data Warehouse? do these terms mean the same thing?

    thanks for the help.

    • Moved by Olaf HelperMVP Monday, December 30, 2013 9:54 AM Moved from "SQL Database Engine" to a more related forum
    Monday, December 30, 2013 12:32 AM

Answers

  • These things tend to have fuzzy boundaries.

    'When I use a word,' noted data warehouse expert Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'

    Still, a data warehouse typically has data which has been transformed by denormalization, aggregation, and other techniques, and these are more for technical database reasons than for business logic as such.  While OLTP databases tend to be pretty close the third normal form, and business logic may occur in the context of stored procedures or as various forms of additional semantic normalization and flattening.

    HTH,

    Josh

    Monday, December 30, 2013 1:06 AM
  • thanks Josh, i was thinkning that even in stored procedures, we perfrom some sort of transformations(joins, filtering etc). i've been doing researh and couldn't find an example of a business logic which isn't called "transformation"

    Well sure, and that's another sort of fuzziness.  A relational database exists exactly so you can do various kinds of algebraic manipulations as needed, it's not just to persist data without also including those manipulations.  And even the simplest select is a manipulation of a kind.  But "transformation"?  If the select returns the columns as stored, I think that's not transformed.  Even a join to multiply or divide the result set and return a combined row I think would be allowed under relational algebra and not considered a "transformation".

    But as soon as you combine fields in any way, I guess you've cross the border into transformation.

    When you look closely, there's very little about relational technology that's all as cut and dried as some might think!

    Josh

    Monday, December 30, 2013 5:22 AM

All replies

  • These things tend to have fuzzy boundaries.

    'When I use a word,' noted data warehouse expert Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'

    Still, a data warehouse typically has data which has been transformed by denormalization, aggregation, and other techniques, and these are more for technical database reasons than for business logic as such.  While OLTP databases tend to be pretty close the third normal form, and business logic may occur in the context of stored procedures or as various forms of additional semantic normalization and flattening.

    HTH,

    Josh

    Monday, December 30, 2013 1:06 AM
  • thanks Josh, i was thinkning that even in stored procedures, we perfrom some sort of transformations(joins, filtering etc). i've been doing researh and couldn't find an example of a business logic which isn't called "transformation"

    Monday, December 30, 2013 1:13 AM
  • thanks Josh, i was thinkning that even in stored procedures, we perfrom some sort of transformations(joins, filtering etc). i've been doing researh and couldn't find an example of a business logic which isn't called "transformation"

    Well sure, and that's another sort of fuzziness.  A relational database exists exactly so you can do various kinds of algebraic manipulations as needed, it's not just to persist data without also including those manipulations.  And even the simplest select is a manipulation of a kind.  But "transformation"?  If the select returns the columns as stored, I think that's not transformed.  Even a join to multiply or divide the result set and return a combined row I think would be allowed under relational algebra and not considered a "transformation".

    But as soon as you combine fields in any way, I guess you've cross the border into transformation.

    When you look closely, there's very little about relational technology that's all as cut and dried as some might think!

    Josh

    Monday, December 30, 2013 5:22 AM