데이터웨어하우스 데이터 모델링 (Data Warehouse Data Modeling)

목 차(1) 제 1 장 데이터웨어하우스 데이터모델링 개요 제 2 장 데이터 정의 DW 데이터의 특성 DW 모델링 개요 목 차(1) 제 1 장 데이터웨어하우스 데이터모델링 개요 DW 데이터의 특성 DW 모델링 개요 제 2 장 데이터 정의 원 데이터와 목적 데이터 갭(Gap) 분석 및 해결 데이터 변형

목 차(2) 제 3 장 데이터웨어하우징 모델링 Dimensional Business Model Star Model 목 차(2) 제 3 장 데이터웨어하우징 모델링 Dimensional Business Model Star Model Star Model의 구축 Fact Table Fact Table 의 속성 Dimension Tables Snowflake Model Multiple Fact Tables Multi Star Schema 외부참조 테이블 (Outboard Table) DW내에서의 시간의 활용

목 차(3) 제 4 장 고급 데이터웨어하우스 모델링 제 5 장 데이터의 집합화 Dimension 속성의 변경 목 차(3) 제 4 장 고급 데이터웨어하우스 모델링 Dimension 속성의 변경 History의 관리 One Dimension Compare To Several Dimensions 계층구조 데이터의 모델링 차원내의 복수 계층 제 5 장 데이터의 집합화 요약 Table과 집합화 집합화 (Aggregation) Snowflake model과 요약 fact table 하나의 대규모 단일 fact table DW내에서 요약 Table의 관리 요약 Table 사용시의 주의할 사항 Granularity

제1장 데이터웨어하우스 데이터모델링 개요 DW 데이터의 특성 DW 모델링 개요 DW는 데이터의 통합체 DW 데이터는 주제중심 정보요구를 모델로 DW 모델 주제영역 논리적 데이터모델링 데이터웨어하우스는 두 가지 목적으로 탄생하였다. 즉, 분석과 의사결정의 지원 그리고 각종 Source로부터 얻은 데이터의 통합이 그 목적이다.

DW는 데이터의 통합체(Consolidation) Internal Data Operational Data Store External Data Data Warehouse 내부데이터(Internal Data) : 매출,고객,수주 데이터와 같이 기존의 운영계 시스템에서 발생하는 기업의 내부데이터 외부데이터(External Data) : 경쟁사정보, 각종 경제지표, 인구정보, 기온, 날씨 등 의사결정을 위하여 필요하다고 인식되는 외부데이터 Manual Data : 정보시스템에서 관리하지 않고 수작업에 의해 생성되는 정보지만 의사결정을 위해 참조할 필요가 있는 정보라고 인식되는 경우 해당 데이터도 데이터웨어하우스의 대상데이터가 될 수 있다. Manual Data Data Marts

DW 데이터는 주제중심(Subject Oriented) 적용업무에 의해서가 아닌 업무적 주제에 의한 분류 및 저장 여신 수신 고객실적 정보 공통 외환 수출입 하나의 주제를 중심으로 해당 주제에 관하여 기업전반에 걸쳐 필요한 각종 데이터를 모아 하나의 집합(Single Set)으로 구성하여 저장 하나의 주제를 중심으로 관련된 각종 정보를 한 곳에서 얻을 수 있다. 주제의 선정은 사용자의 업무적 정보요구(Business Requirements)로 한다. 데이터웨어하우스의 업무적 주제에 의한 분류 적용업무에 의한 분류

DW 데이터는 ... 데이터통합 Time Variant 비휘발성 데이터의 일관성 (Data Consistency) 데이터의 중복 (Data Redundancy) Time Variant Key Time Element 비휘발성 데이터의 통합 Source Data 의 상세한 분석을 통해 전사적 관점에서 의미 있는 정보로. 즉, 다른 Format, 동음이의어, 오류데이터의 해결, 측정단위, Naming Conventions, 코딩구조 등의 통일이 필요. (Extraction,Transformation,Transportation) 특히 데이터의 일관성유지 및 오류의 해결(Data Cleansing)은 DW 에 Loading 하기 전에. 많은 시간과 비용이 필요 데이터중복은 최소화 할 것(단지, 운영계 시스템에서 선택해서 물리적으로 옮기기만 하는 형태의 중복) Time Variant 데이터웨어하우스 데이터는 본질적으로 Historical 하다. ( 과거의 추이, 경향을 토대로 미래를 예측하기 위함) 해당 데이터가 어느 시점의 데이터인가와 관련하여 시기를 나타내는 정보를 Key 에 포함시켜야 함 ( 연도, 분기, 반기, 주, 일 … ) 비휘발성 ( Non-Volatile ) 데이터웨어하우스데이터는 수정, 삭제는 없다. Initial Loading, Regularly Refreshing ( Refresh Cycle)

정보요구를 모델로 정보요구 수집 업무 프로세스가 아닌 데이터를 보는 관점(View)에 주력 JAD (Joint Application Development) Interviews Current Reports IT Report Backlog 대상업무와 관련된 업계의 출판물 경영진, 관리자와의 Meetings 업무 프로세스가 아닌 데이터를 보는 관점(View)에 주력 Current Reports 업무처리에 필요한 각종 Report 와 분석Report IT Report Backlog 사용자가 전산에 요구했으나 개발되지 않았거나 지원하지 못한 내용 “어떻게 주문을 받지?” 가 아닌 “누가 어떤 지역에서 어느 시기에 수익을 얼마나 ?” 현재(today) 의 관점보다는 미래(future)의 관점에서 ...

DW 모델 Operational Data Store Subject Area Logical Data Model Star Schema Physical Data Model Subject Area Logical Data Model 주제를 중심으로 시작하라 ( 주제는 Long-Term View/안정적인 업무를 근간으로 선정하라) 주제영역은 데이터웨어하우스의 범위, 엔티티(entity)와 속성, 업무규칙, 데이터의 도메인(domain),관계(cardinality,optionality), 참조무결성규칙(Referential Integrity Rules)을 정의하는 단위로 인식 Snowflake Schema Physical Data Model

주제영역 논리적 데이터모델링 Subject Area 정의 엔티티(Entity) 정의 속성(Attribute) 정의 관계(Relationship) 정의 업무규칙(Business Rule) 검증 Critical Business Measure 정의 추출데이터 추가 시간요소 추가 주제영역 논리적데이터 모델링 엔티티 정의 (주제를 중심으로) 속성정의 (Descriptive attributes, Identifier(즉, Key 항목), Level 을 의미하는 속성 포함 Critical Business Measures 정의 중요한 수치정보 업무를 평가할 수 있는 사실 고객의 실적 마케팅정보 업무의 성과를 나타내는 수치정보 추출 데이터 ( 계산 등으로 얻을 수 있는 데이터) 시간요소 포함 사실테이블의 날짜,시간,기간 시점정보를 인식하기위한 날짜 등

제2장 데이터 정의 원 데이터와 목적 데이터 갭(Gap) 분석 및 해결 데이터 변형

원 데이터와 목적 데이터 원 데이터 (Source Data) 목적 데이터 (Target Data) 다른 database, file, segment들에 있는 data나 외부에서 제공되는 data 운영 시스템에서 추출된다 목적 데이터 (Target Data) Data Warehouse database의 data가 되는 data 원 시스템(Source System) 분석 ER-Diagram Database Catalogs Metadata 역공학(Reverse Engineering) 을 활용하라 80:20 Rule을 염두에 두라 Data는 원시 시스템, Database, 혹은 파일에서 추출된다. 회사에서 기존에 존재하던 data는 Data Warehouse를 위한 가장 우선적인 자원이다. ER-Diagram 이나 Program Source Code 안에 포함된 개발자의 주석 그리고 Data Dictionary 와 같은 대상 시스템의 분석을 위해 필요한 산출물이 없는 경우 Reverse Engineering의 활용을 고려하라. OLTP 를 위한 시스템의 개발과는 달리 Data Warehouse의 구축은 특히 Data 에 관한 구체적인 지식이 요구되므로 데이터를 찾고, 데이터의 품질을 높이고 데이터를 정련하는데 많은 시간이 소요된다. 전 개발기간의 60% 이상을 해당작업에 할애하라. 데이터웨어하우스 데이터의 80% 정도가 전형적으로 하나 혹은 두개의 대상시스템(Source System)으로부터 온다.

갭(Gap) 분석 및 해결 갭(Gap) 분석 갭(Gap) 의 해결 Data content Data format Data relationship Granularity 갭(Gap) 의 해결 Ignore Adjust Compromise Postpone 갭(Gap) 분석 Source system 과 DW 의 주제영역모델을 비교 분석하여 차이를 해결한다. Data Content - 데이터의 내용에 관한 검증과 평가가 필요.(Source system 에 없는 것처럼 보이는 정보에 관해서도 다른 정보로부터 추출될 수 있는지 까지도 확인할 것) Data Format - 데이터의 크기나 구조가 다르다면 Source system 에 맞추기 위해서 DW 의 구조를 바꾸거나 DW에서 효율적으로 관리할 수 있는 대안을 찾는다. Relationship - 관계는 다소 일치하지 않을 수 있으나 지나치게 다르다면 정확히 정의하고 해결하라. Granularity - 대부분의 경우 Source system과 DW는 Granularity가 다를 수 있다. Source system의 데이터로부터 데이터의 무결성을 손상시키지 않으면서 DW에서 원하는 수준으로 생성할 수 있는지 검증하라. 갭(Gap)의 해결 차이가 별로 중요하지 않거나 ETT 과정을 통해 제거될 데이터일 경우 차이를 무시할 수 있다. ETT (Extraction, Transformation, Transportation) 기준을 선정하고 해당 기준에 맞춘다. 또 다른 Source를 이용해 절충안을 찾는다. 운영계 시스템이 교정될 때까지 미룬다.

데이터 변형 원시 시스템에서 추출된 데이터는 DW로 구성되기 전에 통합되고 변형된다. 제품 번호 = 17A554322 17 A 지역 Code 영업구역 Data Warehouse에서 중요하나 종종 회피 되는 특징이다. 한 회사에서 제품번호가 9자리, 11자리 혹은 자동으로 제품의 종류가 첨가된다. 제품번호에 지역 code, 영업 구역, 제품 code, 제품 크기 code가 모두 나타날 때, data 변형이 행해지지 않았다면, 어떻게 지역내의 특정 담당 구역 내에서의 영업을 비교할 것인가? 데이터 변형 운영 시스템에서 추출된 data의 특성을 변형 다른 data type을 통합하고, code를 변경 남자, 여자, 1, 2등으로 표현된 것을 M, F등으로 변경 data를 계산하거나 요약하고 본질적으로 다른 갱신 cycle을 재 조정한다. 대부분의 변형 도구들은 data 변형을 code로 남긴다. 데이터 변형 도구 이형의 database, file, segment 등에서 data를 추출 source data를 target data에 대응 시킨다. DDL(data definition language)의 생성 Data를 변형하거나 조작하는 code를 생성 Target database로 data를 적재한다. 제품 Code 제품 Size Code Key들로 구축된 항목

제3장 데이터웨어하우징 모델링 Dimensional Business Model Star Model Star Model의 구축 제3장 데이터웨어하우징 모델링 Dimensional Business Model Star Model Star Model의 구축 Fact Table Fact Table 의 속성 Dimension Tables Snowflake Model Multiple Fact Tables Multi Star Schema 외부참조 테이블 (Outboard Table) DW내에서의 시간의 활용 Data modeling이란 실질적인 물리적 data structure로 변환될 수 있기 위한 business 개념을 도형화된 형태로 변환하는 현실적인 절차이다.

Dimensional Business Model Product Geography Facts Sales Inventory Costs Dist. Channel Time Dimension 사용자는 매일 매일의 business가 어떻게 수행되는 지에 대한 business model을 갖는다. 최종 사용자는 그들의 관심대상의 계량치(metric)와 정보를 바라보는 차원(dimension), 차원내에서의 계층, 그리고 어떻게 그러한 계량치들이 서로 상관되는가에 대한 좋은 의견을 가지고 있다. Data Warehouse는 이러한 최종 사용자 business model을 반드시 반영해야 한다. 이러한 수집된 정보들을 간단하게 조직화하는 방법은 business 실체와 항목들을 사실(fact)과 차원(dimension) table로 분리하는 것이다. 논리적 데이터 모델 Entity Relationship Diagram 개발과 같은 전통적인 논리적인 data modeling도 가끔은 Data Warehouse 개발에 적용되기도 한다. 성공적인 Data Warehouse는 충분하고 완전한 논리적 data model 개발을 필요로 하지 않는다. 많은 경우에 Dimensional Business Model의 개발만으로 Data Warehouse 개발로 운영하기에 충분하다. High level Dimensional Business Model

Star Model 분석 처리를 지원 장점 단점 Fact table Dimension table 간단한 모델 사용자 중심 테이블 조인을 감소하여 성능 향상 단점 융통성이 적다 중복된 데이터를 갖는다 다수의 요약 테이블을 필요로 한다 Fact 테이블간의 조인이 어렵다 분석 처리를 지원하기 위한 특별한 형태의 database 설계 Fact와 Dimension table은 미리 정의되고 사용자가 정의한 join 경로를 이용하여 SQL 질의된다 의사 지원 database의 목적은 star schema라고 하는 database 설계에 의하여 성취된다. Star schema 설계는 상대적으로 적은 수의 table들과 잘 정의된 join 경로를 갖는 간단한 구조. 이러한 설계는 transaction processing database를 위한 정규화된 구조와는 상반된다. Star schema는 빠른 질의 응답 시간을 제공하고 간단한 schema는 분석가와 최종 사용자, 또한 database 구조와 친숙하지 않은 사람들에게도 쉽게 이해된다. Star Schema를 사용할 때의 이점들 Data modeling과 물리적 database 설계를 들어가기 전에 star schema를 사용할 것인지 전통적인 관계형 database 설계를 사용할 것인지 결정 하는 것이 중요 Star schema 설계가 Data Warehouse Database 설계의 표준이 될 수 있는 이유 빠른 응답 시간을 제공하는 database의 생성 Data Warehouse가 성장함에 따라 개발주기를 통하여 쉽게 변경될 수 있고 추가될 수 있다. 최종 사용자가 구상하고 사용하고자 하는 대로 database 설계를 병렬로 할 수 있다 개발자와 최종 사용자를 위한 metadata의 이해와 확장을 간단히 한다. Front end data access tool의 선택의 폭을 넓힌다.

Star Model의 구축 주제 영역 사실 (Facts) 세분화 (Granularity) 차원 (Dimensions) 차원의 속성들 (Dimensional attributes) 속성의 특징 정적인가 동적인가 스타 모델을 구축하기 위해서는 다음과 같은 요소들에 대하여 먼저 조사되어야 한다 모델화되어지는 주제 영역은 무엇인가? 주제 영역을 위한 주요한 업무 측정치들은 무엇인가? 분석은 어느 정도까지 수행되어지나? Fact들은 어떠한 종류의 정보를 표현하는가? Dimension은 어떤 종류의 속성들을 갖는가? 속성들은 변화하는가?

Fact Table Major table이라고도 한다. Business에 관한 수량적이거나 사실적인 data를 갖는다. 숫자로 나타내는 측정치가 정보로 질의된다. 많은 수의 column들과 수백만의 행을 갖는다. Product Time Key Product Key Customer Key Channel Key Sales Facts (Units, Price) Customer Fact table은 복수개의 key를 갖는 관계형 데이터베이스의 테이블로 DW Model에서는 공통적으로 나타난다. 서로 상관없는 여러 개의 Dimension table간의 다-대-다 관계의 중심부에 자리 잡으므로 고도로 정규화 되어 있어야 한다 스타 모델의 중심적인 테이블로 DW내의 모든 수치값을 갖는다 DW 데이터베이스에서 종종 가장 큰 테이블이다 Dimension table은 fact table과 primary key와 foregin key로 공유된다 Fact table의 모든 fact 속성들은 새로 생성되어져야 한다 여기에 반해, primary key와 foregin key는 변형절차에서 만들어지므로 새로 생성되어질 필요는 없다. Channel Time

Fact Table Attributes Fact는 업무의 양적 특성을 보이는 속성이다 Fact Data Fact table의 속성들은 외부 dimension key들이나 판매나 단위와 같은 수치적 특성들을 구분한다 Fact Data Additive Non-additive Semi-additive Sales Fact Time_Key Product_Key Store_Key Promotion_Key Quantity_sold* Revenue* Cost* Customer_count Store Time Fact라는 것은 업무의 성능을 양적화한것으로 업무의 성능을 측정하는 값으로 주로 참조되며 판매단위나 총판매량등이다. 이러한 측정값들은 두개 이상의 dimension에 의하여 얻어질 수 있다. 이 측정값들은 운영 시스템으로부터 직접 취해지거나 fact table의 원시 데이터나 다른 데이터들로부터 유도될수도 있다. Fact Data Additive : Dimension의 조합에 의해서 값들이 추가된다 Non-additive : 수치적인 측정값들은 추가될 수 없다. 비율, 총 이윤, 평균등의 계산되어진 fact들은 구성요소들의 값이 취합되면 재계산되어져야 한다 Semi-additive : 어떤 값들은 단순히 차원을따라 추가될수도 있다. Warehouse내에서 fact들을 분류하는것은 설계단계에서 중요한 의미를 갖는다 추가되어지는 정도가 다름에따라 다른 종류의 fact table을 생성하기를 원할수도 있다. Non-additive나 semi-additive fact들을 갱신하는데 필요한 자원들은 batch window에 영향을 주거나 설계에 영향을 줄수도 있다 적절한 사용을위해 필요한 모든 fact들을 재계산하는데 필요한 규칙을 정의해야 한다. Additive Semi-Additive Product Promotion

Dimension Table Minor table이라고도 한다. Large Dimension Tables Business의 차원을 반영하는 서술적인 data를 갖는다. Fact table내의 각각의 row에 대하여 서술적인 정보를 갖는다 일반적으로 fact table에 비하여 그 양이 적다 시간 차원 테이블을 갖는다 Large Dimension Tables 모든 dimension table이 항상 작은 것은 아니다 고객에 관한 정보를 갖는 dimension table이라면 매우 커질 수 있다 이러한 복잡한 분석을 지원하기 위하여 보다 정교한 인덱스와 조인 기술을 필요로 한다 Dimension table은 관계형 데이터베이스상에서 단일 key를 가지고 Fact table과 Join되는 테이블이다. Dimension table의 속성들은 다음과 같은 특징을 갖는다 문자로 이루어지고 거의 변경되지 않는다 분석적인 질의에 제한을 가하는 원천 자료이고 질의 도구에서 리스트 항목의 값을 제공한다 Fact table의 각각의 행에 대하여 서술적인 정보를 제공한다 대규모 Dimension table 은행이나 금융 서비스, 전화국등은 수백만의 고객을 갖는 매우 큰 Dimension table이다. 복잡한 분석과정에서 이러한 Dimension을 다루는 것은 매우 주의깊은 모델링뿐만 아니라 정교한 Index와 Join 기술을 필요로 한다 Dimension의 수 Fact table의 행의 수는 Dimension이 증가함에 따라 매우 큰 규모로 증가한다 비록, Dimension의 수를 제한하는 어떤 기술적인 방법이 없을지라도, 유지보수와 성능의 관점에서 12개를 초과하지 않는것이 좋다.

Snowflake Model Star model의 변형 잇점 단점 fact table 구조는 그대로 유지하면서 모든 차원 정보를 3차 정규형으로 저장 잇점 보다 적은 저장 공간을 필요로 한다 대부분의 많은 개발툴이 지원한다 데이터 중복을 최소로 한다 단점 보다 복잡해지므로 사용자의 이해도를 좀 더 필요로 한다 Time Period Category Products Sales (units, price) Time Snow flake model은 평면적인 dimension table이 트리구조로 재 분할되거나 정규화되는 것으로, 잠재적으로 계층에 있어 많은 복합화된(nested) 수준을 갖는다 여기서 2차적인 Dimension table을 outrigger table이라고도 한다 잇점 보다 적은 공간을 필요로 한다. 그러나 Star를 정규화 하는 과정에서 공간의 절약의 정도는 보장되지 않는다. 성능과 유연성, 유지보수 기능을 개선할 수 있다. 다양한 접근 도구를 지원한다 데이터의 중복을 최소화 한다 Warehouse에 대한 데이터 drill-down이나 history 관리등의 데이터 보고서와 유지 보수 관리를 다루는데 가장 적합한 형태이다. 단점 좀더 복잡하기 때문에 warehouse database를 이해하는데 좀 더 어려울 수 있다. 그러나 데이터베이스가 좀 더 복잡해졌다고 하여도 OLTP 설계자들은 그것을 오히려 자연스럽게 받아들일 수 있다. Dimension 계층으로부터 fact를 이끌어내는데 필요한 과외의 Join은 성능에 영향을 줄 수 있다. Customer Channel Segment

Multiple Fact Table (1) Snowstorm model이나 Snowflake model이라고도 한다 Fact table들이 dimension table을 통하여 연결된다 서로 다른 시간 Dimension을 적용할 수 있다 Period_ID Product_ID Market_ID Units Dollars Discount% Prod_Desc Brand Size Market_Desc District Region Period_Desc Quarter Year Fact table들이 dimension table들을 통하여 연결될 수 있다. 이러한 종류의 모델은 복수 주제 영역의 구현한다. 잇점 계속증가되는 구현을 지원한다 각 data mart 주제 영역은 후에 하나의 warehouse로 통합될 수 있다. 단점 공통의 Dimension들이 서로 다르게 정의될 수 있다. 서로 상관되지 않는 fact들을 갖든지 혹은 적재 시간의 주기가 다르면(예를 들어, 내부적인 적재 data는 주단위로 가능하고, 통합된 data는 4주마다 제공되어 진다면) 여러 개의 Fact table을 갖는 star schema가 된다. 또는 성능 향상을 위하여 복수개의 fact table이 존재할 수도 있다. 즉, 다수의 fact table은 여러 수준의 집합화 data를 다루는데 사용되는데 특별히 집합화의 양이 클 때 사용된다. 복수 fact table은 집합화를 판매를 매일, 매주, 매년 등의 다른 table로 관리할 때 만들 수 있다.

Multiple Fact Table (2) DW Model의 모든 table들이 fact나 dimension으로 나뉘어지는 것은 아니다 business의 임의의 차원간의 다-대-다 관계를 해소하기 위하여 추가된다 Factless fact table Associative Dimension Period_ID Product_ID Market_ID Units Dollars Discount% Prod_Desc Brand Size Market_Desc District Region Period_Desc Quarter Year Group_ID Group_Desc 한 product가 하나 이상의 group에 속하고, 각 group은 여러 개의 product를 갖는다면 새로운 fact table의 추가로 다-대-다 관계를 해소한다. Dimension은 서로간에 독립적이어야 한다 associative dimension은 따라서 다른 형태의 fact table이다. Sales database에서 product가 하나 이상의 group에 속하고, 각 group은 여러 개의 product를 갖는다면 product와 group간에 다-대-다 관계가 생긴다. 이러한 다-대-다 관계를 해소하기 위하여 새로운 fact table이 추가된다. Factless fact table 일련의 키값들 외에는 다른것을 가지지 않는다. 종종 여러 개의 dimension에 의한 특별한 조건들의 출현을 세는데 이용된다. 사건에 관련된 수치 fact들이 없기 때문에 fact table에 fact가 없기도 하다 Fact table은 단순히 dimension들간의 사건에 관한 다-대-다 관계를 표현한다. Associative Dimensions 모든 테이블들에 대하여 fact나 dimension의 이름을 붙일 수 있는 것은 아니다. 종종 dimension간의 교차관계를 표현하기 위한 테이블을 두기도한다. 이러한 성격의 테이블은 fact나 dimension으로 구획을 나눌 수 없다.

2개의 2차 dimension table을 갖는 Multi star schema foreign key의 연결만으로 fact table의 각 행을 유일하게 구분할 수 없을 경우에 유도된다 Class_ID Class_Desc Store_ID Store_Name Region Manager Units Price Amount SKU_ID Date Receipt_Nbr Receipt_Line_Item Dept_ID Item Dept_Desc 2개의 2차 dimension table을 갖는 Multi star schema 단순 star schema에서는 fact table의 primary key는 foreign key의 연결로 만들어 진다. 그러나 가끔은 foreign key의 연결만으로 fact table의 각 행을 유일하게 구분할 수 없을 경우도 있다. 이러할 때 복합 star schema가 요구된다. Multi Star Schema : Fact table은 dimension table을 참조하는 foreign key의 집합과 하나 이상의 column으로 구성하여 행을 유일하게 구분할 수 있는 하나의 primary key를 갖는다. Primary key는 foreign key와 multi star schema내의 임의의 다른 key column과의 어떠한 조합에 의해서도 구성될 수 있다. Multi star schema에서는 fact table내의 연결된 foreign key가 같은 값을 갖는 record가 여러 개 있을 수 있기에 더 이상 하나의 record를 유일하게 구분할 수 없는 것이다.

외부참조 테이블 (Outboard Table) 임의의 Dimension table은 다른 Dimension table에 의하여 참조될 수 있다 참조되는 dimension table을 outboard, outrigger 혹은 2차 dimension table이라고도 한다 Period_ID Product_ID Market_ID Units Dollars Discount% Prod_Desc Brand Size Market_Desc District_ID Region_ID Period_Desc Quarter Year District_Desc Region_Desc Dimension table은 다른 dimension table에 있는 primary key를 참조하는 foreign key를 가질 수 있다. 참조되는 dimension table을 outboard, outrigger, 혹은 2차 dimension table이라고도 한다.

DW내에서의 시간의 활용 DW에 있어 시간의 표현은 필수요소 시간은 어디에 저장되어야 하는가? 일반적으로 DW내에서의 시간 dimension table은 시간적인 요소로 fact table에 저장된다 Multiple Time Hierachies Calendar 접근 시간에 대한 측정치는 간단하게 시작될 수 있으나 곧 매우 복잡한 개념으로 발전하게 된다 집합화에 있어 시간을 정의하기는 무척 어렵다. 어떤 나라는 일주일을 월요일부터 시작하고 다른곳은 일요일부터 시작하기도 한다 주간 단위는 52주라 하여도 몇일이 남기때문에 명확하게 년도의 개념으로 roll-up하기 어렵다. 한 분기라 하여도 13주로 구성될수도 있다. 달력의 날과 회계연도와는 다를수 있다. 조직과 장소에따라 휴일은 같지 않다. DW에서 시간의 표현을 필수이다. 시간의 여러 단위를 다양하게 만족시킬 수 있는 복수계층을 설정할 수 있어야 한다 만일, 외부 데이터를 이용한다 할지라도 전체적으로 통합되어지게 계층을 두거나 변환하는 테이블을 생성해야 할것이다. 외부 데이터의 시간의 granularity를 내부의 DW의 시간 dimension으로 맞추는 것은 매우 어려운 일이다. 시간을 어디에 저장해 둘것인가? 거의 모든 DW에서는 시간 dimension을 둔다. 데이터 분석을 위한 시간 단위의 다양성을 사용해야 한다 Fact table에서 시간 key는 질의가 일, 월, 년도의 분석으로 한정된다면 그것만으로도 충분하다.

제4장 고급 데이터웨어하우스 모델링 Dimension 속성의 변경 History의 관리 제4장 고급 데이터웨어하우스 모델링 Dimension 속성의 변경 History의 관리 One Dimension Compare To Several Dimensions 계층구조 데이터의 모델링 차원내의 복수 계층 단순한 스타 모델을 넘어서는 다양한 모델에 대해서 살펴보기로 한다 단순 스타 모델이 대부분의 기업의 모델로 추천되는 것은 아니다. 그 보다는 오히려 Snowflake나 좀 더 복잡한 다른 개념들이 구현되어지기도 한다

Dimension 속성의 변경 DW는 history를 저장한다 사용자의 요구사항이 저장되어져야 할것을 결정 변화는 추적가능해야 한다 사용할 수 있는 몇가지 방법들 history를 전부 다시쓴다 record를 추가함으로 history의 유지 history table을 이용한 history 유지 부분적 history의 유지보수 Single Married Separated Divorced DW는 업무의 시간적 추이를 저장한다 Warehouse의 설계의 과정에서 history는 어떻게 저장되어져야 하는지 결정되어야 한다 업무의 사용자들은 warehouse내의 시간의 정의를 주도하여, 데이터의 사용성과 신뢰성이 실질적인 구현을 정의한다 데이터베이스 설계의 절차에서 데이터가 시간에 따라 변하는 것을 어떻게 관리할 것인가? DW의 적재나 재반영(refresh)은 이미 저장되어있는 dimension 속성의 변화를 관리하는 시스템운영 루틴을 반드시 포함해야 한다.

History의 관리 History 다시 쓰기 Record를 추가함으로 history의 유지 구현이 쉽다 이전의 history를 잃는다 Record를 추가함으로 history의 유지 차원이 증가하여 history 보존 시간적 제약은 필요하지 않다 일반화할 수 있는 Key를 필요로 한다 History table을 이용한 history 유지 History table이 추가되어 Dimension이 확장된다 History table내에서의 key를 무엇으로 할것인가 부분적 history의 유지보수 Data의 불안정에 대비하여야 한다 Single Married Separated History 다시 쓰기 History를 관리하기 위한 가장 간단한 방법 이전의 history를 잃는다 최종으로 변경한 날짜를 따로 관리할 수도 있다 비교적 치명적이지 않은 데이터에 대해서는 이 방법이 가장 적당할 것이다. Record를 추가함으로 history의 유지 단순히 차원의 크기를 history를 포함하도록 늘리는 것이다 변화가 있을때마다 fact table에 record를 추가함으로써 모든 history를 관리할 수 있다. 일반화된 Key란 history가 추가됨으로써 잃을 수있는 Primary key의 성질을 보호하기 위하여 부가적으로 추가되는 일련의 번호 같은 것이다. History table을 이용한 history 유지 분리된 테이블로 history를 관리하기 위해서는 warehouse 모델은 다른 접근방법을 사용해야 한다. 즉, dimension은 history table을 포함하도록 확장되어져야 한다 또한 history table내의 유일성을 어떻게 보장할 것인지도 같이 고려해야 한다 가장 일반적인 경우는 참조하는 테이블의 primary key와 변화한 날짜를 같이 기록한다 일반화된 key를 고려할 수도 있으나 실제적인 데이터 값을 key로 가져야 한다 Dimension table의 현재 상태를 유지해야 한다 부분적 history의 유지보수 지속적인 변화에 대비하여 이전의 상태를 위한 부가적인 속성일 필요하다 현재의 상태나 변화된 날짜를 기록하기 위하여 날짜 컬럼이 필요할 것이다 어떻게 변화된 데이터를 감지할 수 있는지에 대한 처리절차가 필요할 것이다 모든 규칙이 적용되었다 하여도 데이터가 어느 시점(초기생성시점 등)에는 불완전할 수 있음을 주의해야 한다 Divorced

One Dimension Compare To Several Dimensions 단일 차원 보다 적은 조합에 의한 보다 작은 Fact table을 만든다 dimension data의 분석과 유지를 어렵게 한다 복수 차원 다수의 조합에 의하여 fact table의 크기를 증가 시킨다 분석의 융통성을 증대 data 정의의 변화에 있어 보다 쉬운 방법을 제공 전반적인 유지보수를 쉽게 한다 단일 Dimension 조합해야 하는 테이블이 적은 관계로 결과적으로는 보다 적은 fact table을 만든다 Dimension 데이터를 유지하고 분석하는 것이 결과적으로는 어려워진다 여러 개의 Dimension 조합이 많이 생기므로 결과적으로 fact table의 크기가 커진다. 분석에 있어 유연성이 있다. 데이터 정의의 변화에 대응하는데 보다 쉬운 방법을 제공한다 전반적인 유지보수가 쉽다 나이 성별 급여 Dimension 1,000 rows 나이 성별 학교 급여 Dimension 5,000,000 rows 학교 Dimension 5,000 rows

계층구조 데이터의 모델링 계층 구조 데이터는 다음과 같이 표현된다 여러 개의 모델이 사용 가능하다 단일 계층 (차원; dimension) 복수 계층 (dimensions) 계층적 data는 dimension table에 저장된다 Dimension은 하나 이상의 계층을 가질 수 있다 여러 개의 모델이 사용 가능하다 Flat Recursive Combined 3NF Drill 활동을 지원하기 위하여 dimension table내에 계층을 둘 수 있다. Flat model은 horizontal model이라고도 한다 최종 계층은 비정규화된 차원내의 primary key로 제공된다 상위계층은 그 column을 포함하게 된다 Drill-up이나 drill-down이 단일 join으로 수행된다 Recursive model은 vertical model이라고도 한다 이 모델에서는 dimension key는 전체 계층구조의 모든 가능한 값들을 포함한다 Recursive model에서는 데이터의 중복이 계층내의 수준을 이동하여 부가적인 테이블로 대치될 수 있어 복수의 join을 하는 곳에서는 적당하지 않다 재귀적 관계(recursive relationship)는 warehouse 환경에서는 드물지 않고 운영환경에서 BOM등을 갖는 테이블내의 계층을 제공하는데 종종 사용된다. 스타 모델의 정규화 계층적 데이터는 스타 모델을 정규화하는 과정에서 부가적인 테이블을 생성하는 과정에서 발생할 수 있다. 정규화에 대한 비용은 질의 처리과정에서 부가적인 join이 생길수 있고 결과적인 모델이 snowflake이다.

Dimension table내의 복수 계층 차원내의 복수 계층 테이블 항목의 사용 항목 계층의 생성 Drilling down 좀 더 자세히 Rolling Up 요약하여 모든 고객 Sales Region State Sales Zone Country Sales District 테이블 항목의 사용 Dimension table에서 추가적인 attribute들은 전체 group 내에서 차별화 된 부분 집합들을 찾을 수 있게 한다. 항목 계층의 생성 Data는 다르게 보여도 서로 관련이 되어 있으므로 최종 사용자 상세의 수준에 따라 data를 분석하게 해야 한다. 모든 계층의 Dimension에 의해서 표현되는 fact들이 있다면, 그러한 모델을 표현해 내게 되면 결과적으로 스타 모델이 되게 된다 Drilling down data를 다른 dimension에서 높은 수준으로 좀 더 자세히 보는 것 Rolling Up (Drilling Up) Data의 상세 수준을 요약화 단계로 하여 좀 더 높은 관점에서 보는 것 Drilling은 세 가지 방법으로 일어난다 단일 계층을 통하여 단일 계층에서 비계층적인 속성으로 단일 계층에서 또 다른 계층으로 고객 Dimension table내의 복수 계층

제5장 데이터의 집합화와 요약 요약 Table과 집합화 집합화 (Aggregation) 제5장 데이터의 집합화와 요약 요약 Table과 집합화 집합화 (Aggregation) Snowflake model과 요약 fact table 하나의 대규모 단일 fact table DW내에서 요약 Table의 관리 요약 Table 사용시의 주의할 사항 Granularity DW에서 왜 요약 table이 사용되는가를 알도록 한다 요약 테이블의 잇점은 무엇인가 요약의 수준과 차원을 결정한다 요약 테이블을 다루기 위해 필요한 기술적인 사항들을 구분한다

요약 Table과 집합화(Aggregation) 요약된 데이터란? 미리 정의된 fact data를 누적 직접적이고 쉽게 접근할 수 있도록 data를 집합화 왜 요약된 데이터를 갖는가? 질의 응답시간을 개선하기 위하여 자원의 활용도를 최적화 하기 위하여 분석 처리를 강화하기 위하여 집합화된 data(Aggregated data) DW내의 SUM, MAX, MIN, COUNT등으로 미리 계산되고 요약된 data 일반적으로 요약된 fact table에 저장 DW에서 요약 테이블은 무척 중요하다. 보다 나은 응답시간을 제공할 수 있으므로 사용자에게 보다 나은 서비스를 지원한다 저장공간이나 CPU의 활용도면에서 성능을 개선하고 최적화한다 Drill-down이나 drill-up을 통하여 분석의 능력을 강화한다 요약 데이터를 만들고자 할때는 집합화된 데이터를 저장하는 공간과 동적으로 집합화된 데이터를 재계산하는 등의 trade-off 역시 고려해야 한다. 사실(FACT) 테이블이 시간에 기초하고 있는 것과 같이, 집계(AGGREGATION) 테이블은 시간에 기초하고 있기도 하지만 다음 예제와 같이 시간의 범위가 정해져 있다. SELECT SUM(cost*qty), store_id FROM SALE_FACT WHERE DATE > ‘31-DEC-96’ AND DATE < ‘01-JAN-97’ GROUP BY store_id 데이터 웨어하우스의 사실(FACT) 테이블은 불특정 일자에 따라 정렬되지만 집계 테이블은 특정한 날짜에 의해서 정렬된다.

Geography와 product dimension에 대한 미리 저장된 집합화 Table 집합화 (Aggregation) Geography Market Region Store 집합화란 미리 정의된 항목에 따라 fact data를 누적하는 것이다. Database 설계 구문 내에 data를 변형 처리할 때와 이미 계산된 data를 Data Warehouse로 적재하는 동안의 집합화 생성에 대한 결정을 해야 한다. 미리 저장되어지는 집합화를 위한 주요 추진 인자들은, 최종 사용자 질의 성능의 개선 CPU cycle의 수를 감소 같은 집합체가 300명의 사용자에게 매일 요구된다면 운영체제에게는 좋지 않은 영향을 주므로 이러한 경우에 미리 저장된 집합체가 보증 된다. 무엇을 Data Warehouse에 미리 저장할 것인가를 결정하기 위해서는 최종 사용자의 접근의 빈번함 뿐만 아니라 집합화를 했을 때의 총 행의 수의 감소 역시 고려해야 한다. 선택된 수준에서의 요약된 data는 sparse 집합화 구조를 갖게 된다. 즉, item과 store 수준의 상세성과 item과 market의 집합화를 갖는다면 item과 region의 집합체는 갖지 않는다. 적절한 집합화의 수준을 선정하면 질의 성능과 Data Warehouse내의 disk 저장공간을 최적화 할 수 있다. Data Warehouse로 data를 적재할 때 중요한 마지막 개념은 물리적 table 분할과 같은 전통적인 database 기술을 사용해야 한다. 이것은 수백 GB의 data를 사용할 때 특히 중요하다. Item Class Dept Product Geography와 product dimension에 대한 미리 저장된 집합화 Table

Snowflake model과 요약 fact tables Dimension table을 공유 가능하게 한다 보다 진보된 의사결정 tool들의 사용을 쉽게한다 유연성 정규화를 요구한다 성능이 저하될 수 있다 대규모 dimension Date Key Region ID Product Total Units TotalSales Region ID ... Region Summary Table Total by region, by product, by day Denormalized Store Dimension Table State ID ... Date Key State ID Product Total Units TotalSales State Summary Table Total by state, by product, by day Snowflake형 요약 테이블 모델은 복수개의 fact table을 갖는 대표적인 설계 형태이다. Store dimension을 비정규화 하여 State와 Region table을 생성한다 이러한 테이블들은 기본적인 fact table을 공유할 뿐만 아니라 요약 fact table도 공유한다 요약 fact table - State summary, Region summary Store Key ... Store Key Product Total Units TotalSales Basic Fact Table

하나의 대규모 단일 fact table 세부 fact data와 요약된 data를 같은 table에 차원에서 level을 관리하기 위하여 일반화된 key가 필요하다 요약된 정보를 얻기위한 질의 절차가 간단하다 종종 OLAP을 위하여 사용된다 유지보수, 운영관리가 어렵다 Row Headers Summary Rowns 하나의 큰 fact table은 embedded facts라고도 한다. 하나의 큰 fact table은 요약 정보와 세부 데이터를 같은 테이블에서 다룰 수 있게 한다. 여기서의 key들을 관리하기 위한 선택사항은 다음과 같다. 하나의 조합된 key(Composite Key)를 사용한다 Dimension table의 수준을 가리킬 수 있는 일반화된 key(Generalized Key)를 사용한다 Composite key 여러 개의 컬럼들이 단순히 모여서 키 역할을 하도록 하는 것이다. 각 계층이 더해지거나 삭제되면 fact table의 물리적인 변경이 일어나야 한다 또한 어떤 경우에는 NULL 값을 다루어야 하므로 문제를 일으킬 염려가 크다. Generalized Key 계층의 수준을 나타내는 Dimension table의 각각의 행을 나타내는 수준 지시자를 추가하는 것을 말한다 컬럼의 추가의 Dimension table의 크기가 증가되므로 결과적으로 fact table의 크기 역시 큰 비중으로 증가된다. Basic Grain Rowns Fact Table

DW내에서 요약 Table의 관리 Yearly summary data Quarterly summary data Monthly Last 12 months Daily detail DW에서 요약 테이블을 관리하는 전략을 위해서는 또 다른 설계 사항이 고려되어져야 한다 데이터의 사용에 있어 가장 중요한 인자는 어떤 요약이 만들어져야 할지를 결정하는 것이나 앞에서도 언급되었던 시간의 적용이나 history등으로 결정을 내리기는 무척 어렵다. 요약이 warehouse내에서 지속적으로 모든 경우에 적용되는 경우는 없다. 사용자는 최근의 데이터를 이전의 데이터에 비하여 굉장히 세부적인 수준으로 보고자 한다면 최근 12개월 동안은 매일 매일의 데이터를 관리하고 그에 따라 월별로 요약된 데이터도 가지고 있어야 한다. 이 경우 이전의 데이터는 월별, 분기별, 년도별로 요약되기도 한다. 1994/1995 1994 1997 1998

요약 Table 사용시의 주의할 사항 생성시의 제한 사항 사용시의 주의할 사항 모든 가능한 사항에 대한 고려는 엄청난 양의 자원을 필요로 한다 사용시의 주의할 사항 요구사항을 명확히 구분한다 향상될 수 있는 성능을 측정해 낸다 요약 table의 가치를 결정하여 더하거나 삭제한다 지속적인 재반영(refresh)은 시간의 소모가 클 수 있다 원활한 운영에 부적합한 Tool을 사용하지는 않는가 제한된 확장성 모든 가능한 경우를 대비한 요약화는 가장 좋은 성능을 낼 것이다. 그러나, 성능과 유지 보수관점에서의 비용은 본질적인 관점에서 제고해야 한다. 모든 요구되는 조합을 위한 요약의 생성에는, 저장공간 Metadata 관리 처리 능력을 위한 유지보수를 위하여 엄청난 자원을 요구한다. 요약은 또한 DW의 데이터가 재반영 될 때마다 재계산되어져야 한다. Batch load window는 가공되지 않은 데이터와의 일치성을 유지하기 위하여 요약 테이블을 재계산 할 때 필요로 하는 자원을 제한하는 역할을 하기도 한다.

Granularity Grin Low level of granularity High level of granularity DW내의 세밀화의 수준 Granularity의 수준은 database의 크기와 database가 지원할 수 있는 분석의 형태에 직접 영향을 준다 Low level of granularity high level of detail 한달 동안 고객이 사용한 각각의 통화에 대한 세부 정보 High level of granularity low level of detail 한달에 임의의 고객이 통화한 횟수 Data Warehouse내의 세밀화의 수준으로 Data Warehouse 개발 내에서 가장 중요한 설계 issue중의 하나 Granulity의 수준은 database의 크기와 database가 지원할 수 있는 분석의 형태에 직접 영향 Highly granular data 아주 세밀한 정보를 제공하므로 data의 양이 크다. 한 달에 발생하는 어떤 이의 당좌 예금 구좌 내에서의 모든 거래 사항의 list. "6월 5일 내 구좌에 있는 차변은 얼마인가?" Less granular data 세밀화의 정도가 약한 data로 좀더 요약되어서 data의 양이 상대적으로 적다. " 지난 3년간 나의 구좌에서 월간 혹은 년간 대차대조표는 어떻게 되는가?"