Ch. 16 Design and Business Intelligence

Presentation on theme: "Ch. 16 Design and Business Intelligence"— Presentation transcript:

1 Ch. 16 Design and Business Intelligence
병렬소프트웨어설계연구실 오찬영

2 Design and Business Intelligence
Good dimensional design 뿐만 아니라 information에 대한 접 근성도 중요 이러한 접근은 다양한 tool을 통해 이루어짐 These tools are referred to as business intelligence tools End user에게 제공하는 각각의 정보를 report라고 부름 The tools do not require the person developing a report to write query

3 Business Intelligence Tools
Numerous formats chart, table, dashboard widget, … Variety of channels computer, mobile devices, telephones, … Varied access paradigms on-demand, scheduled, exceptional alert

4 Schema-driven SQL Generates
The most basic example identify the table that will be used specify columns that is used to lay out a report the tool generates SQL based on what developer has added to the canvas

5 Semantic Layers A business view of information on top of the technical view report 가능한 것들 = user가 tool을 보는 view Business view가 실제 physical structure와 연결 되어 있는 것이 semantic layer 이를 통해 user는 실제 database의 구조를 몰라도 tool을 사용할 수 있 음

6 Semantic Layers Semantic layer is defined by a developer
Query generator는 semantic layer의 정보를 바탕으로 data를 fetch

7 The Limitations of SQL Generators
SQL generators generates SQL that always follows some standard formats, or templates (not intelligent) 생성 가능한 query는 질의문에 담긴 product에 대한 함수이며, 정확도 는 configuration에 영향을 받는다. 이러한 제약은 생성 가능한 query의 종류를 결정함 Two major limitations Inability to generate a desired query Ability to generate a undesired query

8 Inability to generate a desired query
No tool is capable of generating appropriate query for every situation 하지만 schema design에 의해 해결 될 수 있는 문제일 수 있음 e.g., drill-across를 지원하기 위해서는 merged fact table 추가 기본적으로 특정 tool을 위해 schema를 변경하는 것은 권장되 지 않지만, 상황에 따라 융통성을 발휘하는 것도 필요 derived schema 같은 경우는 schema의 변경 없이 추가만으로 도 구현 가능하기도 함

9 Ability to generate a undesired query
Bank account balance는 시간에 따라 변화하는 값으로, query 를 생성할 때 날짜 등으로 aggregate 되기도 함 tool을 처음 사용하는 경우 정보를 잘못 이해할 수도 있음 마찬가지로, derived schema가 해결책이 될 수 있다 sliced fact table을 이용하여 현재 기간의 balance에만 접근 가능하게 하되, 숙련자는 original data에 접근 가능하게 하는 등의 방법 이런 방법은 multiple semantic layer를 요구함 (one for novices, one for experts)

10 Guidelines for the semantic layer
Features to avoid Renaming attributes Creating virtual attributes Relying on subqueries Features to use Compute nonadditive facts Isolate dimension roles Simplify presentation

11 Features to avoid Dimensional design should be rich and understandable
Renaming attributes business view에서의 naming이 보다 명확할 수 있지만, dimensional design 수준에서의 naming 또한 명확하게 작성해야 함 Semantic layer에서의 naming을 보조 수단(user-friendly translation)으 로 삼지 말 것

12 Features to avoid Creating virtual attributes Relying on subqueries
Semantic layer를 saving space 목적으로 사용하지 말 것 Dimensional design 단계에서 유용한 element의 조합 및 translation을 포함해야 한다 (redundant 할지라도) 예를 들어, full name을 저장하는 대신 last name과 first name을 query 단계에서 concatenation 시키는 경우 복잡한 query에 포함 되면 computing performance에 심각한 영향을 끼칠 수 있음 Relying on subqueries 자주 사용되는 subquery (e.g., categorization based on previous behaviors) 는 design 단계에서 behavioral dimension으로 구성

13 Features to use Compute nonadditive facts Isolate dimension roles
e.g., margin rate = sum(margin_dollars) / sum(order_dollars) fully additive component를 이용한 nonadditive fact는 query time에 계산하는 것이 좋음 Isolate dimension roles 하나의 dimension table이 여러 역할로 사용되는 경우 (여러 reference 가 존재하는 경우) 각각의 역할 별로 구분해서 semantic layer를 구성 하는 것이 좋다  aliasing

14 Features to use Simplify presentation
folder 등으로 attribute를 구분해서 end user가 이해하기 쉽도록 구성

15 Working with SQL-Generating BI Tools
BI tool의 capability를 아는 것이 중요함 addition of derived schema or view에 대한 결정 guarding과 analytic flexibility 사이의 balancing

16 Multiple stars – Drilling across
combining information from more than one fact table: Aggregate facts from each stars, grouping result set by the same dimension Merge the result sets Some configuration is usually required so that the tool will invoke the mechanism (i.e., multi-pass query) automatically Tool이 drill across를 수행할 수 없는 경우에는 merged fact table을 추가해주어야 한다

17 Multiple stars – Queries with no facts
it is called cross-browse 여러 개의 dimension을 결합할 방법이 여러 개가 있을 수 있음 단순히 data의 list만 전달하는 것으로는 부족 e.g., 날짜와 품목을 정해주었을 때, SQL generator는 사용자가 shipment_fact 혹은 order_fact 어느 fact에 대한 질의를 수행했는지 알 수 없음 각 star에 대한 semantic layer를 별도로 구성하여 해결 혹은, shared dimension에 대한 aliasing을 생성 e.g., ordered_product_name, shipped_product_name

18 Multiple stars – More than one way to compare processes
order와 shipment를 비교하는 방법 각 날짜 별 비교 (각 날짜에 발생한 activity) order date를 기준으로 비교 (order의 status) user가 canvas에 date, quantitiy_ordered, quantity_shipped를 올려놓은 경우 수행하고자 하는 질의가 무엇인지 확정 불가 두 merged fact table을 이용하거나, semantic layer를 분리

19 Multiple stars – Conformed dimensions
BI tool은 conformed attribute를 알지 못함 drill across를 자동으로 수행할 수 없음 Snow-flake schema로 구현  schema design에 영향을 줌 merged fact table 구성

20 Semi-additivity – Using semi-additive facts
Periodic snapshot에 대한 fact table은 semi-additive fact를 포 함한다. account balance는 semi-additive 은행, 계좌 등에 대해서는 additive, 시간에 대해서는 non-additive Constrain the query for a specific instance of the non- additive dimension 특정 날짜의 은행 잔고의 합 Group the query results by instances of the non-additive dim. 은행 잔고의 합을 날짜 순 정렬

21 Semi-additivity sliced fact table을 이용하여 user의 접근을 방지하여 회피할 수 있음
expert 에게는 다른 semantic layer를 제공하여 접근 가능하도록 함 tool이 자체적으로 방지하는 경우, average 를 계산하는 등 실제 sum 연산이 필요한 경우에도 제한될 수 있음 별도의 특별한 연산(averaging)을 위한 기능을 제공

22 Browse queries – Mini-dim
when there is a shortcut between main & mini dim., there can be multiple way to relate dimensions

23 Browse queries – Mini-dim
Role에 따른 aliasing 으로 해결

24 Bridge tables Bridge tables allow a single fact to refer to more than one instance of a dimension (many-to-many, Ch. 9 and 10) Sum of order_dollars for each sales person != a grand total 판매에 참여한 사람이 여럿인 경우 It is known as a impact table

25 Bridge tables Primary sales person을 지정  각 order는 한 명의 sales person을 갖도록 for novice user

26 Hierarchy bridge tables
Two configurations, one used for looking down the hierarchy, the other for looking up

27 Cube-centric Business Intelligence
BI tools support interaction with multidimensional databases, rather than a semantic layers. Multiple semantic layers may seem confusing, whereas multiple cubes are natural Different cubes will be provided for different purposes order  order cube, shipment  shipment cube comparing order and shipment  order & shipment cube

28 Cube-centric Business Intelligence
Cube의 pre-computed value를 이용해 OLAP의 “online” 성을 강화 할 수 있음 반면, # attributes가 커지면 performance 감소 less scalable

29 Multiple cubes Drilling into multiple cubes is less of a concern
Just merge the cubes into a new one How to deal with factless query is also far less of a concern cube가 선택되면 scope of analysis가 결정됨 두 process (e.g., order and shipment)를 비교하는 관점이 여럿 존 재하는 경우 각각의 경우에 대해 merged table을 준비 Safety vs. flexibility safe & limited cubes for novice, flexible & dangerous cubes for expert

30 Multiple cubes A new concern Cube-based approaches are less scalable
There should be many ‘targeted’ cubes It can be resulted in over-proliferation of cubes Designer should carefully select the appropriate mix of cubes avoid one-cube-per-report

31 Auto-generation of cubes
SQL generation과 마찬가지로 Cube generation에도 주의가 필요 Easy to generate summarizing the base data without transforming its dimensional structure such as aggregating, slicing Difficult to generate A merged cube must be constructed according to standard drill-across process Manual control의 필요성을 염두 해 두어야 함

32 Hierarchy of attributes
Some tools use attribute hierarchy to control the drilling process. Competing hierarchy (e.g., calendar year vs. fiscal year) will require separate cubes