어두운 지도를 조금씩 밝혀나가는 데에서 즐거움을 느낀다면
- Top-down approach : 전반적인 설계와 기획에서 시작
- 기술이 성숙되어있으며, 해결해야하는 비즈니스 문제가 명확하고 이해하기 쉬운 경우
- 전체 비즈니스 문제에 대한 전반적인 디자인 후 문제를 세분화하며 진행
- Bottom-up approach : 실험과 프로토타입으로 시작
- 비즈니스 모델링과 기술 개발 초기에 큰 도움
- 조직이 중요업무를 수행하기 전, 상당히 적은 비용으로 기술적 혜택을 평가하는 것이 가능
- 작은 단위의 component를 디자인하고 결합하여 검증하는 방식으로 진행
- combined approach (결합 접근법)
- 계획한 상향식 접근의 전략적 특성을 활용하면서 상향식 접근의 빠른 실행과 기회적 응용 유지
- Waterfall (폭포수 방법) : 다음 단계로 넘어가기 전에 각 단계에서 구조적이고 체계적인 분석 실행
- 각 단계의 entry criteria, tast, exit criteria가 분명히 정의되어있고, 각 단계는 분리되어 있음
- 이전 단계의 변화에 따른 비용이 크다 (변화에 적응하기 어렵다)
- Spiral (나선형 방법) : 연속적인 단계 사이에서 점차 증가하는 기능 시스템을 빠르게 생성
- 작은 prototype부터 기획, 개발, 검증을 반복하며 확장해나감
- turn around time이 짧고, 변화에 적응이 쉽고 빠름
- 데이터 마트에 적합한 방법 Top-down (하향식 접근)과 Bottom-up (상향식 접근) / 두 방식의 조합
- 1) 모형에 적합한 비즈니스 프로세스 선택 (ex. 주문, 송장, 선적, 재고, 판매량......)
- 프로세스가 특정 조직에 대한 것이라면 데이터 웨어하우스 모델을 따름
- 프로세스가 특정 부서에 대한 것이라면 데이터 마트 모델을 따름
- 2) fact table에 표시된 비즈니스 프로세스의 grain (원자 단계의 데이터) 선택 (ex. 개별 거래....)
- 3) 각 fact table record에 적용할 차원 선택 (ex. 시간, 판매 항목, 고객, 공급자.....)
- 4) 각 fact table record에 저장될 measure (측정 단위) 선택 (ex. 판매 달러, 판매 개수.....)
- 일반적인 측정 단위는 누적할 수 있는 수량
- Define a high-level corporate data model : 조직 단계의 데이터 모델 정의
- 전체적인 data 정리로 데이터 통합이 용이해짐
- Data Mart / Enterprise Data Warehouse : 부서별 데이터 마트와 기업 전체의 데이터 웨어하우스 구축
- 데이터 마트와 데이터 웨어하우스를 구축하며 데이터 모델을 정제하고 이를 다시 반영
- Distributed Data Mart : 만들어진 데이터 마트들을 통합
- Multi-tier Data Warehouse : 데이터마트와 데이터 웨어하우스를 통합하여 다 계층 데이터 웨어하우스 완성
-> Incremental (Evolutionary) development
- 질의, 기본 통계 분석, 리포팅 업무 지원
- 위의 정보 처리를 위해 교차표(cross table), 표, 차트, 그래프 등을 활용
- 기본 OLAP 작업 지원 (drill-down, roll-up, slice, dice, pivot)
- 데이터 웨어하우스 내의 데이터에 대한 다차원 분석이 장점
- 숨겨진 패턴으로부터 지식 발견
- 연관성 분석, 분석 모델 구축, 분류와 예측 작업 실행
- 데이터 마이닝 결과를 시각화 툴을 이용하여 나타냄
- 다차원 데이터베이스 상의 지식을 발견하기 위해 OLAP과 데이터 마이닝을 결합
- 데이터 웨어하우스는 통합되고 일관성있으며 정제된, 양질의 데이터를 저장
-> OLAP과 데이터 마이닝에 필요한 고품질 데이터의 원천
- 효과적인 데이터 마이닝은 탐색적 데이터 분석이 필요
-> 데이터 큐브와 데이터 마이닝 결과에 대한 drilling, pivoting, dicing 등의 OLAP 기술을 적용
- 데이터 마이닝 함수를 온라인으로 선택하여 다양한 마이닝 기능, 알고리즘, 업무를 통합하거나 변경 가능
- 데이터 큐브는 여러 cuboid의 격자로 구성
- 데이터 큐브에서 집계 연산은 특정 cuboid에 대한 연산
-> cuboid 전체나 일부를 사전에 계산해두면 빠른 응답이 가능하고, 중복 계산을 피할 수 있음
-> 그러나 다차원 큐브의 경우 모든 cuboid에 대해 사전 계산을 저장하는 것은 비현실적
-> 차원의 저주 (curse of dimensionality)
- 차원의 저주 : n차원 데이터 큐브에 몇 개의 cuboid가 존재하는가?
- n개의 차원에서 i (0 < i ≤ n) 차원의 개념 계층이 Li 개 일때 cuboid의 개수 T
-> 데이터 큐브에 대해 생성할 수 있는 모든 cuboid를 실체화하는 것은 불가능
-> 부분 실체화가 합당함
- 데이터 큐브 실체화 (materialization)
- No materialization (실체화하지 않음) : base cuboid 외에는 사전 계산하지 않음
-> 다차원 집계 계산에 상당한 자원이 소모되며 소요시간이 매우 느림
- Full materialization (전체 실체화) : 모든 cuboid를 사전에 계산
-> 모든 cuboid를 저장하기 위해 상당량의 메모리 필요
- Partial materialization (부분 실체화) : 적합한 cuboid를 선별하여 사전에 계산
-> 접근 빈도, 공유, 크기에 따라 실체화할 cuboid를 선택
- "Compute Cube" 연산자 : DMQL(Data Mining Query Language)에서 cube에 대한 정의와 계산 연산 포함
- ex. define cube sales [item, city, year]: sum (sales_in_dollars)
compute cube sales
- SQL류의 언어에서 "CUBE BY" 연산자 도입
- ex. SELECT item, city, year, SUM (amount)
FROM SALES
CUBE BY item, city, year
- 기존 연산자인 "GROUP BY" 사용
- 관계형 DBMS나 확장관계형 DBMS를 사용하여 웨어하우스의 데이터와 OLAP 미들웨어를 저장하고 관리
- DBMS 백엔드의 최적화, 집계 네비게이션 로직과 추가 툴, 서비스에 대한 실행을 지원
- 주로 거대한 규모
- 배열 기반 다차원 스토리지 엔진을 통해 다차원 데이터 뷰를 지원
- 다차원 뷰를 데이터 큐브 배열 구조에 직접 매핑
- 인덱싱을 활용하여 효율적이고 빠르지만 데이터가 sparse할 때는 스토리지의 낭비를 불러옴
-ROLAP과 MOLAP의 기술으리 결합하여 ROLAP의 확장성과 MOLAP의 빠른 계산의 장점을 취함
- 저 레벨에서는 Relational DB를 이용하며 고 레벨에서는 배열을 이용
Data Warehousing and OLAP(3)
13. 데이터 웨어하우스의 설계
1) Top-down (하향식 접근)과 Bottom-up (상향식 접근) / 두 방식의 조합
- Top-down approach : 전반적인 설계와 기획에서 시작
- 기술이 성숙되어있으며, 해결해야하는 비즈니스 문제가 명확하고 이해하기 쉬운 경우
- 전체 비즈니스 문제에 대한 전반적인 디자인 후 문제를 세분화하며 진행
- Bottom-up approach : 실험과 프로토타입으로 시작
- 비즈니스 모델링과 기술 개발 초기에 큰 도움
- 조직이 중요업무를 수행하기 전, 상당히 적은 비용으로 기술적 혜택을 평가하는 것이 가능
- 작은 단위의 component를 디자인하고 결합하여 검증하는 방식으로 진행
- combined approach (결합 접근법)
- 계획한 상향식 접근의 전략적 특성을 활용하면서 상향식 접근의 빠른 실행과 기회적 응용 유지
2) 소프트웨어 엔지니어링 관점 (계획 - 요구사항 연구 - 문제 분석 - 설계 - 데이터 통합/테스팅 - 전개)
- Waterfall (폭포수 방법) : 다음 단계로 넘어가기 전에 각 단계에서 구조적이고 체계적인 분석 실행
- 각 단계의 entry criteria, tast, exit criteria가 분명히 정의되어있고, 각 단계는 분리되어 있음
- 이전 단계의 변화에 따른 비용이 크다 (변화에 적응하기 어렵다)
- Spiral (나선형 방법) : 연속적인 단계 사이에서 점차 증가하는 기능 시스템을 빠르게 생성
- 작은 prototype부터 기획, 개발, 검증을 반복하며 확장해나감
- turn around time이 짧고, 변화에 적응이 쉽고 빠름
- 데이터 마트에 적합한 방법 Top-down (하향식 접근)과 Bottom-up (상향식 접근) / 두 방식의 조합
3) 전형적인 데이터 웨어하우스 설계 절차
- 1) 모형에 적합한 비즈니스 프로세스 선택 (ex. 주문, 송장, 선적, 재고, 판매량......)
- 프로세스가 특정 조직에 대한 것이라면 데이터 웨어하우스 모델을 따름
- 프로세스가 특정 부서에 대한 것이라면 데이터 마트 모델을 따름
- 2) fact table에 표시된 비즈니스 프로세스의 grain (원자 단계의 데이터) 선택 (ex. 개별 거래....)
- 3) 각 fact table record에 적용할 차원 선택 (ex. 시간, 판매 항목, 고객, 공급자.....)
- 4) 각 fact table record에 저장될 measure (측정 단위) 선택 (ex. 판매 달러, 판매 개수.....)
- 일반적인 측정 단위는 누적할 수 있는 수량
4) 일반적으로 권유되는 데이터 웨어하우스 개발 절차
- Define a high-level corporate data model : 조직 단계의 데이터 모델 정의
- 전체적인 data 정리로 데이터 통합이 용이해짐
- Data Mart / Enterprise Data Warehouse : 부서별 데이터 마트와 기업 전체의 데이터 웨어하우스 구축
- 데이터 마트와 데이터 웨어하우스를 구축하며 데이터 모델을 정제하고 이를 다시 반영
- Distributed Data Mart : 만들어진 데이터 마트들을 통합
- Multi-tier Data Warehouse : 데이터마트와 데이터 웨어하우스를 통합하여 다 계층 데이터 웨어하우스 완성
-> Incremental (Evolutionary) development
14. 데이터 웨어하우스 사용
1) 정보 처리
- 질의, 기본 통계 분석, 리포팅 업무 지원
- 위의 정보 처리를 위해 교차표(cross table), 표, 차트, 그래프 등을 활용
2) 분석 처리
- 기본 OLAP 작업 지원 (drill-down, roll-up, slice, dice, pivot)
- 데이터 웨어하우스 내의 데이터에 대한 다차원 분석이 장점
3) 데이터 마이닝
- 숨겨진 패턴으로부터 지식 발견
- 연관성 분석, 분석 모델 구축, 분류와 예측 작업 실행
- 데이터 마이닝 결과를 시각화 툴을 이용하여 나타냄
15. On-line Analytical Mining (OLAM, 온라인 분석 마이닝)
- 다차원 데이터베이스 상의 지식을 발견하기 위해 OLAP과 데이터 마이닝을 결합
- 데이터 웨어하우스는 통합되고 일관성있으며 정제된, 양질의 데이터를 저장
-> OLAP과 데이터 마이닝에 필요한 고품질 데이터의 원천
- 효과적인 데이터 마이닝은 탐색적 데이터 분석이 필요
-> 데이터 큐브와 데이터 마이닝 결과에 대한 drilling, pivoting, dicing 등의 OLAP 기술을 적용
- 데이터 마이닝 함수를 온라인으로 선택하여 다양한 마이닝 기능, 알고리즘, 업무를 통합하거나 변경 가능
16. 효율적인 데이터 큐브 계산
- 데이터 큐브는 여러 cuboid의 격자로 구성
- 데이터 큐브에서 집계 연산은 특정 cuboid에 대한 연산
-> cuboid 전체나 일부를 사전에 계산해두면 빠른 응답이 가능하고, 중복 계산을 피할 수 있음
-> 그러나 다차원 큐브의 경우 모든 cuboid에 대해 사전 계산을 저장하는 것은 비현실적
-> 차원의 저주 (curse of dimensionality)
- 차원의 저주 : n차원 데이터 큐브에 몇 개의 cuboid가 존재하는가?
- n개의 차원에서 i (0 < i ≤ n) 차원의 개념 계층이 Li 개 일때 cuboid의 개수 T
-> 데이터 큐브에 대해 생성할 수 있는 모든 cuboid를 실체화하는 것은 불가능
-> 부분 실체화가 합당함
- 데이터 큐브 실체화 (materialization)
- No materialization (실체화하지 않음) : base cuboid 외에는 사전 계산하지 않음
-> 다차원 집계 계산에 상당한 자원이 소모되며 소요시간이 매우 느림
- Full materialization (전체 실체화) : 모든 cuboid를 사전에 계산
-> 모든 cuboid를 저장하기 위해 상당량의 메모리 필요
- Partial materialization (부분 실체화) : 적합한 cuboid를 선별하여 사전에 계산
-> 접근 빈도, 공유, 크기에 따라 실체화할 cuboid를 선택
- "Compute Cube" 연산자 : DMQL(Data Mining Query Language)에서 cube에 대한 정의와 계산 연산 포함
- ex. define cube sales [item, city, year]: sum (sales_in_dollars)
compute cube sales
- SQL류의 언어에서 "CUBE BY" 연산자 도입
- ex. SELECT item, city, year, SUM (amount)
FROM SALES
CUBE BY item, city, year
- 기존 연산자인 "GROUP BY" 사용
17. OLAP 서버 아키텍쳐
1) Relational OLAP (ROLAP, 관계형 OLAP)
- 관계형 DBMS나 확장관계형 DBMS를 사용하여 웨어하우스의 데이터와 OLAP 미들웨어를 저장하고 관리
- DBMS 백엔드의 최적화, 집계 네비게이션 로직과 추가 툴, 서비스에 대한 실행을 지원
- 주로 거대한 규모
2) Multidimensional OLAP (MOLAP, 다차원 OLAP)
- 배열 기반 다차원 스토리지 엔진을 통해 다차원 데이터 뷰를 지원
- 다차원 뷰를 데이터 큐브 배열 구조에 직접 매핑
- 인덱싱을 활용하여 효율적이고 빠르지만 데이터가 sparse할 때는 스토리지의 낭비를 불러옴
3) Hybrid OLAP (HOLAP, 하이브리드 OLAP)
-ROLAP과 MOLAP의 기술으리 결합하여 ROLAP의 확장성과 MOLAP의 빠른 계산의 장점을 취함
- 저 레벨에서는 Relational DB를 이용하며 고 레벨에서는 배열을 이용
'전공 과목 공부 > 데이터 사이언스' 카테고리의 다른 글