flowchart LR OP["운영 시스템<br/>(Operational Systems)"] --> EX["추출·통합<br/>(Extract/ETL)"] subgraph DWbox["데이터 웨어하우스 (Data Warehouse)"] CD["현재 상세<br/>(Current Detail)"] OD["오래된 상세<br/>(Old Detail)<br/>대용량 매체"] LS["경요약<br/>(Lightly Summarized)"] HS["고요약<br/>(Highly Summarized)"] META["메타데이터<br/>(Metadata)"] CD --> OD CD --> LS LS --> HS META -. 색인 .-> CD META -. 색인 .-> LS META -. 색인 .-> OD end EX --> CD LS --> DM["데이터 마트<br/>(Data Mart)"] DM --> IND["개인 계층<br/>(Individual)"] CD -.-> LSB["살아있는 표본 DB<br/>(Living Sample DB)"] CD -.-> EXP["탐색·데이터 마이닝<br/>(Exploration/Mining)"] DWbox -. 간접 접근 .-> OP DWbox --> ODS["운영 데이터 저장소<br/>(ODS, Class IV)"]
Mermaid
복사
소제목 (챕터 / 소제목명) | 새로 등장한 개념 | 관련 단계 | 내용 정리 | 내 메모 |
1장<br>도입부 | • 데이터 웨어하우스(Data Warehouse)<br>• 의사결정 지원 시스템(DSS, Decision Support System) | (구체적 단계 미등장) | • 정보처리는 1960년대에야 시작된 미성숙한 분야 — 세부에 집착하는 경향이 문제<br>• DW는 전체(whole)에서 세부(particular)로 내려가는 아키텍처 설계가 필요하다는 핵심 주장<br>• 이 챕터의 목적: DW를 이해하려면 정보·DSS의 진화 역사를 먼저 봐야 한다 | • |
1장<br>The Evolution | • 마스터 파일(Master File)<br>• 자기 테이프(Magnetic Tape)<br>• 중복 데이터(Redundant Data)<br>• 운영 시스템(Operational System) | 운영 시스템 | • 1960년대 초: 개별 애플리케이션 + 마스터 파일(자기 테이프)로 데이터 저장 — 순차 접근만 가능, 전체 테이프 중 실제 필요 데이터는 5% 이하<br>• 1965년경: 마스터 파일 폭발적 증가 → 중복 데이터 대량 발생 → 데이터 동기화 복잡성·프로그램 유지보수 어려움·하드웨어 비용 급증<br>• 1980년대: PC·4GL 등장으로 엔드 유저가 데이터를 직접 다루기 시작 → 운영 트랜잭션 처리와 분석 처리를 단일 DB로 동시에 처리할 수 없다는 한계가 드러남<br>• 이 한계가 DW 필요성의 출발점 | • |
1장<br>The Advent of DASD | • 직접 접근 저장 장치(DASD, Direct Access Storage Device)<br>• 데이터베이스 관리 시스템(DBMS, Database Management System)<br>• 온라인 트랜잭션 처리(OLTP, Online Transaction Processing)<br>• 데이터베이스(Database) | 운영 시스템 | • 1970년대: DASD 등장 — 자기 테이프의 순차 접근 한계를 극복, 레코드를 밀리초 단위로 직접 접근 가능<br>• DASD와 함께 DBMS 등장 → 마스터 파일 문제(중복·동기화)의 기술적 해결책<br>• 1970년대 데이터베이스 정의: "모든 처리를 위한 단일 데이터 소스(a single source of data for all processing)" — 당시의 이상이었으나 이후 한계 드러남<br>• 1975년경 OLTP 등장 → 예약 시스템·ATM·제조 제어 등 실시간 처리 가능해짐<br>• 그러나 OLTP(운영 처리)와 분석 처리를 단일 DB가 동시에 감당할 수 없다는 문제는 여전히 남음 | • |
1장<br>Enter the Extract Program | • 추출 프로그램(Extract Program)<br>• 추출 처리(Extract Processing) | 운영 시스템 → 추출 | • OLTP 시스템이 거대해지자 운영 DB에서 데이터를 꺼내 다른 파일/DB로 옮기는 추출 프로그램 등장<br>• 추출 프로그램이 인기를 끈 두 가지 이유: ① 운영 처리 성능에 영향 없이 대량 데이터 분석 가능(성능 분리) ② 데이터를 운영 영역에서 꺼내는 순간 엔드 유저가 데이터 소유권을 가져감(통제권 이전)<br>• 추출 처리가 조직 전반에 급속히 퍼짐 → 다음 소제목 "Spider Web"의 직접적 원인 | • |
1장<br>The Spider Web | • 거미줄 아키텍처(Spider Web)<br>• 자연 발생적 아키텍처(Naturally Evolving Architecture) | 운영 시스템 → 추출 | • 추출 프로그램이 통제 없이 퍼지면서 추출의 추출, 추출의 추출의 추출… 형태로 연쇄 증식 — 대기업은 하루 45,000건 추출도 흔함<br>• 이 통제 불능 상태에 이름이 붙음: 자연 발생적 아키텍처(Naturally Evolving Architecture) — 조직이 아키텍처를 무계획·방임(laissez-faire) 방식으로 다룰 때 나타남<br>• 조직이 크고 오래될수록 문제가 심화됨 → 다음 소제목에서 세 가지 구체적 문제(데이터 신뢰성·생산성·정보 변환 불가)로 이어짐 | • |
1장<br>Problems with the Naturally Evolving Architecture | • 자연 발생적 아키텍처의 문제(Problems with the Naturally Evolving Architecture) | 운영 시스템 → 추출 | • 자연 발생적 아키텍처(The Spider Web)가 만들어내는 3가지 핵심 문제를 소개하는 전환 소제목:<br> ① 데이터 신뢰성 결여(Data Credibility)<br> ② 생산성 문제(Productivity)<br> ③ 데이터에서 정보로의 변환 불가(Inability to transform data into information)<br>• 이후 3개의 소제목에서 각각을 상세히 다룸 | • |
1장<br>Lack of Data Credibility | • 데이터 신뢰성 결여(Lack of Data Credibility)<br>• 시간 기반 부재(No Time Basis)<br>• 알고리즘 차등(Algorithmic Differential)<br>• 추출 계층(Levels of Extraction)<br>• 외부 데이터 문제(External Data Problem) | 운영 시스템 → 추출 | • 문제 상황: 두 부서가 각각 +10%, -15%로 상충되는 보고를 경영진에 제출 → 경영진은 데이터가 아닌 정치·인맥으로 의사결정할 수밖에 없음<br>• 신뢰성 위기가 예측 가능한 5가지 이유:<br> ① 시간 기반 부재: 부서마다 데이터를 추출한 시점이 다름 (일요일 vs 수요일) — 서로 다른 시점의 데이터는 일치할 이유가 없음<br> ② 알고리즘 차등: 부서마다 분석 기준이 다름 (오래된 계좌 vs 큰 계좌) — 기준이 다르면 결과가 달라지는 건 당연<br> ③ 추출 계층: 추출이 8~9단계씩 쌓이면서 앞의 두 문제가 기하급수적으로 증폭됨<br> ④ 외부 데이터 문제: 분석가가 WSJ·Business Week 등 외부 데이터를 가져올 때 출처 정보가 제거되고 조율도 없음<br> ⑤ 공통 소스 부재: 부서 A는 파일 XYZ, 부서 B는 DB ABC를 원천으로 사용 — 애초에 데이터 동기화 자체가 없음 | • |
1장<br>Problems with Productivity | • 생산성 문제(Problems with Productivity)<br>• 레거시 시스템(Legacy Systems) | 운영 시스템 → 추출 | • 자연 발생적 아키텍처의 두 번째 문제: 전사 데이터를 모아 보고서 하나 만들려면 ① 데이터 위치 파악 ② 데이터 취합 ③ 개발 인력 확보, 세 단계 모두 극도로 비효율적<br>• 데이터 위치 파악만도 고통: VSAM·IMS·Adabas·IDMS 등 기술마다 다른 스킬셋 필요, BALANCE·CURRBAL·INVLEVEL처럼 같은 개념이 다른 이름으로 산재 — 이름뿐 아니라 정의·계산 방식까지 일일이 검토해야 함<br>• 실제 추정치(Figure 1.6): 데이터 탐색 9~12개월 + 데이터 취합 15~24개월 + 개발 인력 확보 3~5년 → 첫 번째 보고서에만 3~5년<br>• 더 큰 문제: 1번째 보고서 작업이 2번째·3번째 보고서에 재활용되지 않음 — 매번 처음부터 동일한 비용 반복<br>• 결론: 거미줄 레거시 환경에서는 정보 접근 비용이 극히 높고 시간이 너무 오래 걸림 | • |
1장<br>From Data to Information | • 원시 데이터(Primitive Data)<br>• 파생 데이터(Derived Data)<br>• 통합(Integration)<br>• 시간 지평(Time Horizon) | 운영 시스템 → 추출 → 데이터 웨어하우스 | • 자연 발생적 아키텍처의 세 번째 문제: 데이터에서 정보로의 변환 불가<br>• 예시: "최근 5년간 계좌 활동이 어떻게 달랐나?"라는 질문에 기존 시스템으로 답하려면 — ① 비통합 레거시 앱(예금·대출·신탁 등) 각각 따로 접근해야 함 ② 앱마다 보유 이력 기간이 다름 (DDA 60일, 대출 2년, CD 18개월 등) — DSS 분석에 필요한 이력 데이터 자체가 없음<br>• 운영 시스템은 현재값 처리용으로 설계 → 분석에 필요한 시간 지평(수년 이상)을 애초에 담을 수 없음<br>• 원시 데이터(운영·상세·현재값·갱신 가능) vs 파생 데이터(DSS·요약·이력·갱신 불가)는 본질적으로 달라 단일 DB에 공존 불가 | • |
1장<br>A Change in Approach | • 설계된 환경(Architected Environment)<br>• 기업 정보 팩토리(Corporate Information Factory)<br>• 4계층 아키텍처(4-Level Architecture) | 전 계층 공통 | • 자연 발생적 아키텍처의 한계를 해결하려면 아키텍처 자체의 전환이 필요 → 설계된 환경(Architected Environment) 등장<br>• 4계층으로 구성: ① 운영 계층(상세·현재값·고접근빈도·앱 지향) ② 원자/DW 계층(최세밀·시간변형·통합·주제 지향) ③ 부서/데이터 마트 계층(부서별 파생 데이터) ④ 개인 계층(임시·휴리스틱·PC 기반)<br>• 이 4계층이 **기업 정보 팩토리(Corporate Information Factory)**를 구성함<br>• 자연 발생적 아키텍처가 오히려 데이터 중복을 폭발적으로 만들었던 것과 달리, 설계된 환경에서는 계층 간 중복이 거의 없음 | • |
1장<br>The Architected Environment | • 데이터 마트(Data Mart)<br>• 시간 변형 데이터(Time Variant Data)<br>• 주제 지향성(Subject Orientation) | 운영 시스템 → 추출 → 데이터 웨어하우스 → 데이터 마트 | • J Jones 예시로 4계층 역할 설명: 운영(현재 주소·신용등급) / DW(1986~현재 주소 이력) / 데이터 마트(월별 고객 집계) / 개인(임시 분석)<br>• DW 계층의 핵심 특성: 레코드마다 시간 정보 포함, 레코드 간 시간 겹침 없음, 갱신 아닌 새 레코드 추가로 이력 관리<br>• 데이터 마트는 DW를 원천으로 하며, 부서 운영 요건에 맞게 비정규화·요약·재구성된 데이터를 보유<br>• 통합(Integration): 운영 환경 → DW로 넘어올 때 반드시 통합이 수행되어야 함 — J Jones가 보험 4개(생명·자동차·주택소유·건강)에 흩어진 정보를 단일 레코드로 통합하는 예시<br>• ETL(Extract/Transform/Load) 소프트웨어가 이 통합 과정을 자동화 — 고통스럽지만 한 번만 하면 됨 | • |
1장<br>Data Integration in the Architected Environment | • ETL(Extract/Transform/Load)<br>• DSS 분석가(DSS Analyst)<br>• 발견 마인드셋(Mindset of Discovery) | 운영 시스템 → 추출(ETL) → 데이터 웨어하우스 | • 운영 → DW 이동 시 통합 없이 데이터를 그냥 던져 넣으면(whole cloth) 전사적 관점 지원 불가 → 통합은 필수<br>• DSS 분석가의 특성: 비즈니스 담당자가 우선, 기술자가 차선 — "원하는 걸 보여줘야 진짜 원하는 게 뭔지 알 수 있다" (발견 마인드셋)<br>• 이 마인드셋이 정당하고 전 세계적으로 보편적이며, DW 개발 방식에 근본적 영향을 미침<br>• 고전적 SDLC는 요구사항을 먼저 정의 → DSS 환경에선 요구사항이 마지막에 발견됨 → 완전히 다른 개발 생명주기 필요 | • |
1장<br>The Development Life Cycle | • 시스템 개발 생명주기(SDLC, Systems Development Life Cycle)<br>• 역방향 생명주기(CLDS)<br>• 나선형 개발 방법론(Spiral Development Methodology) | 데이터 웨어하우스 | • 운영 시스템: SDLC(요구사항 → 설계 → 개발) — 폭포수(waterfall) 방식, 요구사항 주도<br>• DW 시스템: CLDS(SDLC의 역순) — 데이터에서 출발 → 통합 → 편향 테스트 → 프로그래밍 → 결과 분석 → 요구사항 이해 순서<br>• CLDS = 나선형 개발 방법론 — DW의 작은 부분을 완성 → 반복적으로 확장<br>• SDLC용 도구(CASE 등)를 DW에 적용하면 낭비와 혼란만 초래 | • |
1장<br>Patterns of Hardware Utilization | • 하드웨어 활용 패턴(Patterns of Hardware Utilization)<br>• 이진 활용 패턴(Binary Utilization Pattern) | 운영 시스템 / 데이터 웨어하우스 | • 운영 환경: 하드웨어 사용률에 예측 가능한 피크·밸리 패턴 존재<br>• DW 환경: 이진 패턴(binary pattern) — 전부 사용 중이거나 전혀 미사용 중이거나, 중간값이 없음<br>• 두 환경의 패턴이 근본적으로 달라 동일 장비에서 동시 운영 불가 — 운영 최적화와 DW 최적화는 동시에 할 수 없음 | • |
1장<br>Setting the Stage for Reengineering | • 리엔지니어링(Reengineering)<br>• 프로덕션 환경(Production Environment) | 운영 시스템 → 데이터 웨어하우스 | • DW 환경으로 전환 시 운영(프로덕션) 환경에 간접적 긍정 효과 발생<br>• ① 대용량 아카이브 데이터를 DW로 이전 → 운영 환경이 더 작고 단순해짐 (수정·재구조화·모니터링·인덱싱 용이)<br>• ② 정보 처리(리포트·화면·추출 등)를 DW로 이전 → "영원한 유지보수"처럼 보이던 변경 부담이 사라짐<br>• 결론: 리엔지니어링 성공의 가장 중요한 첫 단계는 DW 환경으로 전환하는 것 | • |
1장<br>Monitoring the Data Warehouse Environment | • DW 모니터링(Monitoring)<br>• 평균일 프로파일(Average-Day Profile)<br>• 응답 시간(Response Time) | 데이터 웨어하우스 | • DW 구축 후 데이터와 사용 현황 두 가지를 정기적으로 모니터링해야 함<br>• 모니터링으로 파악 가능한 것: 데이터 성장 위치·속도, 접근 데이터, 응답 시간, 사용자, 사용량, 사용 시점 등 — 이를 모르면 계속 스토리지·프로세서만 사야 함<br>• DW 응답 시간은 OLTP와 달리 미션 크리티컬하지 않음 (분·시간·일 단위) — 하지만 응답 시간이 짧을수록 분석가의 반복적 탐색 생산성이 높아지므로 여전히 중요<br>• 모니터링 위치 트레이드오프: 단말(관리 부담 높음, 성능 영향 낮음) vs 서버(관리 쉬움, 전체 성능 영향 있음)<br>• 평균일 프로파일을 만들어 현재 상태와 비교 → 장기 트렌드 추적 가능 | • |
1장<br>Summary | 전 계층 공통 | • 1장 전체 요약: DW는 운영·DW·데이터 마트·개인의 4계층 아키텍처 속에 존재<br>• 운영 데이터 → DW로 흘러들 때 통합이 핵심 (복잡하고 고통스럽지만 필수)<br>• DW → 데이터 마트로 흘러가며, 데이터 마트는 부서 요건에 맞게 재구성됨<br>• 개발 방식: 고전 SDLC가 아닌 나선형 개발 방법론(CLDS) 사용<br>• DW 사용자는 발견 마인드셋 — "원하는 걸 줘야 진짜 원하는 걸 알 수 있다" | • | |
2장<br>도입부 | • 주제 지향성(Subject Orientation)<br>• 통합(Integration)<br>• 비휘발성(Nonvolatility)<br>• 시간 변형성(Time Variancy)<br>• 현재값 데이터(Current-Value Data)<br>• 스냅샷(Snapshot) | 데이터 웨어하우스 | • 2장의 핵심 명제: DW는 "주제 지향적(subject-oriented), 통합적(integrated), 비휘발성(nonvolatile), 시간 변형적(time-variant) 데이터의 집합" — 경영 의사결정 지원용<br>• ① 주제 지향성: 운영 시스템은 애플리케이션 중심(보험사 예: 자동차·건강·생명·재해 앱)이지만 DW는 비즈니스 주제 중심(고객·정책·보험료·클레임) — 회사 유형마다 고유한 주제 집합이 있음<br>• ② 통합: 4가지 특성 중 가장 중요. 운영 환경 여러 원천에서 데이터가 들어올 때 인코딩·명명 규칙·물리 속성·측정 기준을 일관되게 변환·표준화 → DW 내에서는 단일 물리적 기업 이미지(single physical corporate image) 유지<br>• ③ 비휘발성: 운영 환경은 레코드 단위로 삽입·갱신·삭제를 반복하지만 DW는 대량 적재(load) 후 조회(access)만 — 변경 시 기존 레코드 수정이 아닌 새 스냅샷 레코드 추가로 이력 유지<br>• ④ 시간 변형성: DW의 모든 데이터는 특정 시점에 정확한 값을 가짐 — 운영 시스템(현재값, 60~90일 시간 지평)과 달리 DW는 5~10년 시간 지평, 레코드 키에 반드시 시간 요소 포함<br>• 운영 현재값 데이터는 갱신 가능하지만, DW 데이터는 시점별 스냅샷의 연속 — 이력적 활동·사건의 흐름을 보여줌 | • |
2장<br>The Structure of the Data Warehouse | • 현재 상세(Current Detail)<br>• 오래된 상세(Old Detail)<br>• 경요약(Lightly Summarized)<br>• 고요약(Highly Summarized)<br>• 메타데이터(Metadata)<br>• 입도 이동(Shift in Granularity)<br>• 공통 키(Common Key) | 데이터 웨어하우스 | • DW 내부는 4개의 상세 레벨로 구성 (Figure 2.5): ① 고요약(월별 제품 매출 등) ② 경요약/데이터 마트 수준(주별 소제품 매출 등) ③ 현재 상세(1990~1991 판매 상세) ④ 오래된 상세(1984~1989 판매 상세, 주로 대용량 보조 스토리지)<br>• 운영 환경 → DW로 데이터가 흘러들 때 상당한 변환(transformation) 발생. 이후 데이터는 현재 상세 → 오래된 상세로 노화(aging)되고, 현재 상세 → 경요약 → 고요약으로 집계됨<br>• 주제 지향 물리 구조: 주제 영역은 복수의 관련 물리 테이블로 구현 — 예) '고객' 주제: 기간별 기본 고객 정보 테이블 + 고객 활동 요약 테이블 + 고객 활동 상세 테이블 등 5개 이상의 테이블<br>• 동일 주제 내 모든 테이블은 **공통 키(예: customer ID)**로 연결됨 (Figure 2.7)<br>• 접근 빈도 높고 용량 작은 데이터 → 빠르고 비싼 매체(DASD), 접근 빈도 낮고 대용량 → 저렴하고 느린 매체(자기 테이프·광학 디스크·마이크로피시). 동일 주제 내 데이터가 여러 매체에 분산 저장 가능<br>• 광학 디스크(Optical Disk)는 DW에 특히 적합: 저렴·빠름·대용량 + DW 데이터는 한번 쓰면 갱신이 거의 없어 Write-Once 특성과 잘 맞음<br>• 요약 레벨과 상세 레벨이 공존하는 것은 **입도 이동(shift in granularity)**의 일종 — 이후 'Granularity' 소제목에서 상세히 다룸<br>• DW 내 모든 테이블 키에는 시간 요소(time element) 포함 (from date, activity date, month 등) | • |
2장<br>Subject Orientation | • 고수준 기업 데이터 모델(High-Level Corporate Data Model)<br>• 주제 영역(Subject Area) | 데이터 웨어하우스 | • DW는 기업의 고수준 데이터 모델에서 정의된 주요 주제 영역을 중심으로 구성됨 — 대표적 주제: 고객(Customer), 제품(Product), 거래/활동(Transaction/Activity), 정책(Policy), 클레임(Claim), 계좌(Account)<br>• 각 주제 영역은 복수의 관련 물리 테이블로 구현 (10개, 100개 이상도 가능)<br>• 예) '고객' 주제: 1985~1987 기본 고객 정보 테이블 / 1988~1990 기본 고객 정보 테이블 / 1986~1989 고객 활동 요약 테이블 / 1987~1989 고객 활동 상세 / 1990~1991 고객 활동 상세 — 시간 구간별로 테이블이 분리되고 속성 정의도 달라짐<br>• 동일 주제 내 모든 테이블은 **공통 키(customer ID)**로 연결 — 키를 통해 여러 테이블·여러 매체에 흩어진 데이터를 하나의 주제로 묶음<br>• 같은 주제 테이블이라도 DASD(고빈도·소용량)와 자기 테이프(저빈도·대용량)에 혼재 가능 — DBMS가 여러 개이거나 아예 없는 매체에 데이터가 있어도 DW의 일부<br>• 각 테이블 키에는 시간 요소(from date, activity date, month 등)가 반드시 포함됨 | • |
2장<br>Granularity | • 입도(Granularity)<br>• 상세 레벨(Level of Detail)<br>• 웹 로그 클릭스트림(Web Log Clickstream)<br>• Day 1-Day n 현상(Day 1-Day n Phenomenon) | 데이터 웨어하우스 | • 입도(Granularity): DW 설계에서 가장 중요한 단일 설계 사안 — 데이터 단위의 상세함 또는 요약 수준을 의미<br>• 상세할수록 → 낮은 입도(low granularity) / 요약할수록 → 높은 입도(high granularity)<br> - 예) 고객의 월별 통화 건별 상세 기록 = 낮은 입도(40,000바이트/월, 200건) / 월별 통화 요약 1건 = 높은 입도(200바이트/월, 1건)<br>• 입도가 중요한 이유: DW에 저장되는 데이터 볼륨과 처리 가능한 쿼리 유형 두 가지를 동시에 결정 — 둘 사이의 트레이드오프<br>• 실무 경향: 대부분 너무 상세한 수준으로 들어옴 → 개발자가 분리 작업에 큰 리소스 소모. 반대로 웹 로그 클릭스트림처럼 너무 세밀한 경우 편집·필터링·요약 후 적재해야 함<br>• 입도의 이점: ① 동일 데이터를 마케팅(월별 지역별)·영업(주별 담당자별)·재무(분기별 제품별) 등 여러 부서가 각각 다른 방식으로 활용(재사용성) ② 부서 간 분석 불일치 시 단일 원천으로 조정(reconciliation) 용이 ③ 미래의 알 수 없는 요구사항(새 법령, 시장 변화 등)에도 대응 가능<br>• Day 1-Day n 현상: DW는 한 번에 완성되지 않고 주제 영역을 하나씩 채워나가는 점진적·반복적 개발이 표준 — "빅뱅" 방식은 재앙을 초래함<br> - Day 1: 레거시 운영 시스템만 존재 → Day 2~3: 첫 주제 적재·DSS 분석가 유입 → Day 4: DW 상당 부분 채워짐·접근 경쟁 장애물 부상 → Day 5~6: 데이터 마트 개화·엔드 유저 이동 → Day n: 운영+DW+다수 데이터 마트로 아키텍처 완성 | • |
2장<br>The Benefits of Granularity | • 재사용성(Reusability)<br>• 조정(Reconciliation)<br>• 유연성(Flexibility) | 데이터 웨어하우스 | • DW는 하나의 목적으로 구축되었다가 여러 종류의 DSS 처리에 쓰임을 발견하는 경우가 많음 — 인프라는 한 번만 구축하면 재사용 가능<br>• 재사용성: 동일한 세밀 데이터(granular data)를 마케팅·영업·재무 등 여러 부서가 각자 다른 시각으로 사용 가능 (마케팅: 월별 지역별 / 영업: 주별 담당자별 / 재무: 분기별 제품별)<br>• 조정(Reconciliation): 단일 원천이 존재하므로 부서 간 분석 결과 불일치 시 근거 데이터로 돌아가 차이를 설명·해소하기 쉬움 — 1장의 '데이터 신뢰성 결여' 문제의 해결책<br>• 유연성: 분석 방식을 바꾸고 싶을 때 이미 세밀한 데이터 기반이 있으므로 쉽게 대응 가능<br>• 이력 보존: 세밀한 데이터는 기업 전체의 활동·이벤트 이력을 담고 있어 다양한 필요에 맞게 재구성 가능<br>• 가장 큰 이점: 미래의 알 수 없는 요구사항(새 법령, 시장 충격, 규칙 변경 등)에 대응 가능 — DW가 이미 있으면 새 요구사항이 생겼을 때 분석 준비 완료 상태 | • |
2장<br>An Example of Granularity | 데이터 웨어하우스 | • 전화 통화 기록 예시로 입도 트레이드오프를 수치로 비교 (Figure 2.12)<br>• 낮은 입도(높은 상세): 고객 1인당 월 200건 레코드 × 200바이트 = 40,000바이트/월 — 통화 일시·상대방·완료 여부·장거리 여부 등 세부 속성 다수 포함<br>• 높은 입도(낮은 상세): 고객 1인당 월 1건 레코드 × 200바이트/월 — 월별 누적 통화 수·평균 통화 시간·누적 장거리 통화 수 등 요약 속성만 포함<br>• 볼륨 차이: 200:1 (40,000바이트 vs 200바이트) — 입도 선택이 스토리지 규모를 수백 배 좌우함<br>• 낮은 입도는 개별 통화 패턴 분석 등 세밀한 쿼리 가능 / 높은 입도는 저장 효율 높고 월 단위 집계 분석에 최적 — 어느 쪽을 선택할지가 DW 설계의 핵심 의사결정 | • | |
2장<br>Dual Levels of Granularity | • 이중 입도(Dual Levels of Granularity)<br>• 경요약 데이터(Lightly Summarized Data)<br>• 진정한 아카이브 데이터(True Archival Data) | 데이터 웨어하우스 | • 대부분의 조직은 효율(압축)과 세밀한 분석 능력을 동시에 원함 → 해답: DW 상세 영역에 두 개(이상)의 입도 레벨을 두는 이중 입도 설계 — 거의 모든 조직의 기본 설계로 권장<br>• 전화 회사 예시 (Figure 2.15):<br> - 운영 환경: 30일치 통화 상세 이력 (청구 시스템용)<br> - DW ① 경요약(Lightly Summarized): 고객별 월별 집계 (통화 건수·평균 통화 시간·장거리 건수 등) — 225바이트/레코드, 볼륨 대폭 감소<br> - DW ② 진정한 아카이브(True Archival): 운영에서 넘어온 원본 상세 데이터 10년치 — 자기 테이프 등 대용량 매체에 저장<br> - 데이터 마트: 지역구(district)별로 파생 데이터 분배 → 각 지역이 독립적으로 분석<br>• 경요약 데이터: 상세 데이터를 아주 조금만 집계 (예: 시간 단위 요약, 일 단위 요약) — 볼륨이 크게 줄어 DASD에 보관 가능하고 대부분의 DSS 쿼리 대응 가능<br>• 진정한 아카이브 데이터: 볼륨이 방대해 자기 테이프·대용량 매체에 저장. 개별 이벤트 수준의 세밀한 쿼리("Cass Squire가 지난주 보스턴에 전화했나?")에만 필요<br>• 이중 입도의 효과: 대부분의 DSS 처리는 경요약 레벨에서 수행(빠름·저비용), 드문 세밀 쿼리만 아카이브 레벨로 → 두 마리 토끼를 동시에 잡음 | • |
2장<br>Exploration and Data Mining | • 탐색(Exploration)<br>• 데이터 마이닝(Data Mining) | 데이터 웨어하우스 | • DW의 세밀한 데이터는 데이터 마트뿐 아니라 탐색·데이터 마이닝도 지원<br>• 탐색·마이닝이란: 방대한 상세 이력 데이터를 분석해 이전에 알려지지 않은 비즈니스 패턴을 발견하는 활동<br>• DW가 탐색·마이닝에 이상적인 이유: 정제(cleansed)·통합(integrated)·정리(organized)된 이력 데이터가 이미 갖춰져 있음 — 마이너·탐색가가 필요로 하는 정확한 기반<br>• 단, DW만이 유일한 소스는 아님 — 외부 데이터 등과 자유롭게 혼합해 활용 가능 | • |
2장<br>Living Sample Database | • 살아있는 표본 데이터베이스(Living Sample Database)<br>• 판단 표본(Judgment Sample)<br>• 무작위 표본(Random Sample) | 데이터 웨어하우스 | • DW 데이터 볼륨이 너무 커졌을 때의 특수 설계 기법 — DW의 일부 데이터(진정한 아카이브 또는 경요약)를 주기적으로 갱신되는 서브셋으로 유지<br>• "Living": 주기적으로 갱신(refresh)됨 / "Sample": 전체가 아닌 일부<br>• 용도: 통계 분석·트렌드 파악·집계 쿼리 — J Jones가 고객인지 개별 확인하는 용도로는 절대 사용 불가 (표본에 없어도 실제 고객일 수 있음)<br>• 로딩 방식: 100번째 혹은 1000번째 레코드씩 무작위 추출 → DB 크기를 1/100~1/1000로 줄임. 무작위 표본은 편향 없지만 통계적 유의성 문제 / 판단 표본은 기준을 두어 선택하지만 편향(bias) 위험<br>• 최대 장점: 접근 효율 — 24시간 걸리는 전체 DB 스캔이 표본 DB에서는 10분으로 단축 → 휴리스틱 분석의 반복 속도 극적으로 향상<br>• 권장 활용법: 탐색적 반복 분석은 표본 DB에서 수행 → 쿼리가 확정되면 마지막에 한 번만 전체 DB에 실행 | • |
2장<br>Partitioning as a Design Approach | • 파티셔닝(Partitioning)<br>• 물리적 단위(Physical Unit) | 데이터 웨어하우스 | • 파티셔닝은 DW의 두 번째 주요 설계 사안 (첫 번째는 입도) — 데이터를 독립적으로 관리할 수 있는 별도의 물리적 단위로 쪼개는 것<br>• DW에서 파티셔닝의 쟁점은 "할지 말지"가 아니라 "어떻게 할지" — 반드시 해야 함<br>• 황금 법칙: 입도와 파티셔닝이 올바르게 설계되면 DW의 거의 모든 다른 설계 측면이 자연스럽게 따라옴. 반대로 이 둘이 잘못되면 다른 설계가 아무리 잘돼도 소용없음<br>• 파티셔닝이 주는 이점: 데이터 적재(Loading) / 접근(Accessing) / 아카이빙(Archiving) / 삭제(Deleting) / 모니터링(Monitoring) / 저장(Storing) — 6가지 운영 측면 모두에서 유연성 확보<br>• 결론: 파티셔닝을 올바르게 하면 데이터가 성장해도 관리 가능 / 잘못하면 데이터가 늘어날수록 관리 불능 상태로 빠짐 | • |
2장<br>Partitioning of Data | • 애플리케이션 레벨 파티셔닝(Application-Level Partitioning)<br>• DBMS 레벨 파티셔닝(DBMS-Level Partitioning)<br>• 파티셔닝 기준(Partitioning Criteria) | 데이터 웨어하우스 | • 현재 상세 데이터는 반드시 파티셔닝됨 — 데이터를 같은 구조끼리 묶어 둘 이상의 물리적 단위로 분리, 각 레코드는 정확히 하나의 파티션에만 속함<br>• 파티셔닝 기준(개발자가 선택): 날짜(Date) / 사업 부문(Line of Business) / 지역(Geography) / 조직 단위(Organizational Unit) / 위 기준의 조합 — DW에서는 날짜 기준이 사실상 필수<br> - 예) 생명보험사: 2000·2001·2002 건강 클레임 / 1999·2000·2001·2002 생명 클레임 / 2000·2001·2002 재해 클레임 → 연도×보험 종류 조합으로 파티셔닝<br>• DBMS 레벨 vs 애플리케이션 레벨: DW는 애플리케이션 레벨 파티셔닝 권장<br> - DBMS 레벨: 단일 데이터 정의 강제 — 10년치 데이터의 정의 변화를 수용 불가<br> - 애플리케이션 레벨: 연도별로 다른 데이터 정의 가능, 파티션을 다른 처리 복합체(processing complex)로 자유롭게 이동 가능<br>• 파티션 적합성 테스트: "다른 운영을 방해하지 않고 인덱스를 추가할 수 있는가?" → 가능하면 파티션이 충분히 작은 것, 불가능하면 더 세분화 필요 | • |
2장<br>Structuring Data in the Data Warehouse | • 단순 누적 구조(Simple Cumulative)<br>• 롤링 요약 구조(Rolling Summary)<br>• 단순 직접 파일(Simple Direct)<br>• 연속 파일(Continuous)<br>• 복합 키(Compound Key) | 데이터 웨어하우스 | • DW에서 가장 일반적인 4가지 데이터 구조:<br>• ① 단순 누적(Simple Cumulative): 운영 환경의 일별 트랜잭션을 DW로 가져와 고객·계좌 등 주제 단위로 일별 합산 — 상세도 유지, 저장 공간 많이 필요, 처리 복잡<br>• ② 롤링 요약(Rolling Summary): 7일 → 1주 슬롯 → 4~5주 → 1월 슬롯 → 12월 → 1년 슬롯으로 집계 후 하위 슬롯 초기화 — 매우 압축적, 오래된 데이터일수록 상세도 감소<br>• ③ 단순 직접(Simple Direct): 누적 없이 운영 환경에서 특정 시점의 스냅샷을 그대로 복사 — 일별이 아닌 주·월 단위로 수행<br>• ④ 연속(Continuous): 두 개 이상의 단순 직접 파일을 병합 → from-to 날짜 범위로 레코드 변화 이력을 연속적으로 표현 (예: P Anderson Jan~Jan 456 High St / Feb~현재 1455 Tincup Ct)<br>• 복합 키(Compound Key): DW 키는 필연적으로 복합 키 — ① 날짜(연/연월/연월일 등)가 거의 항상 키의 일부 ② 파티셔닝 기준(사업 부문·지역 등)도 키 구성 요소로 포함됨 | • |
2장<br>Data Warehouse: The Standards Manual | • 표준 매뉴얼(Standards Manual)<br>• 기록 시스템(System of Record) | 데이터 웨어하우스 | • DW가 새로운 조직에서는 **공식 내부 문서(표준 매뉴얼류)**가 필요 — "표준 매뉴얼"이라는 이름은 먼지만 쌓이는 연상을 줘 피하는 게 낫지만, 어떤 형태로든 내부 출판물은 가치 있음<br>• 문서에 포함해야 할 항목: DW 정의 / 원천 시스템 설명 / 사용 방법 / 문제 발생 시 연락처 / 담당자 / 마이그레이션 계획 / 운영 데이터와의 관계 / DSS 활용법 / 추가하면 안 되는 데이터 / 메타데이터 가이드 / 기록 시스템(system of record) | • |
2장<br>Auditing and the Data Warehouse | • 감사(Auditing) | 데이터 웨어하우스 | • DW에서 감사(auditing)를 수행하는 것은 기술적으로 가능하지만 권장하지 않음<br>• 이유: ① 원래 DW에 들어오지 않을 데이터를 강제로 포함해야 함 ② 데이터 입력 타이밍이 크게 달라짐 ③ 백업·복구 요건이 대폭 강화됨 ④ 감사 목적상 입도를 최저 레벨로 유지해야 해 DW 설계 자유도 제한<br>• 결론: 감사는 다른 환경에서 하는 것이 훨씬 합리적 | • |
2장<br>Cost Justification | • 투자 대비 수익(ROI, Return on Investment)<br>• 반복적 구축(Incremental Build) | 데이터 웨어하우스 | • DW의 비용 정당화는 사전 ROI 방식이 적용되지 않음 — 구축 전에 실제 편익을 알 수 없기 때문 (발견 마인드셋: 만들어봐야 어디에 쓸지 알 수 있다)<br>• 해결책: 반복적 소규모 구축 — 첫 반복(iteration)은 빠르고 소규모로 완성 → 분석가가 가능성을 탐색하면서 비용 정당화를 시작할 수 있음<br>• 첫 반복의 황금률: "만들 수 있을 만큼 작고, 의미 있을 만큼 크게" — 초기 설계가 50% 정확하면 성공으로 간주<br>• 첫 기능 영역은 보통 재무(Finance)·마케팅(Marketing)·영업(Sales) 중 하나로 시작 | • |
2장<br>Justifying Your Data Warehouse | • 유지보수 비용(Ongoing Maintenance Cost)<br>• ETL 도구(ETL Tool) | 데이터 웨어하우스 | • DW 비용 구조는 일반 시스템과 반대: 일반 시스템은 초기 구축 비용이 크고 유지보수 비용은 작지만, DW는 유지보수 비용이 초기 인프라 비용을 훨씬 초과<br>• 주요 비용 요인: ① 방대한 데이터 볼륨 ② 운영 원천과의 인터페이스 유지 비용 (ETL 도구 사용 시 비용 완화, 수동 구축 시 유지비 폭증) ③ DW는 완성이 없음 — 주제 영역을 계속 추가해야 하는 영속적 필요<br>• DW는 기업이 지금껏 경험한 것을 훨씬 초과하는 데이터 볼륨·상세도·이력을 다룸 | • |
2장<br>Cost of Running Reports | • 정보 비용(Cost of Information)<br>• ERP(Enterprise Resource Planning) | 운영 시스템 → 데이터 웨어하우스 | • DW의 비용 정당화 핵심 논리: 정보 비용을 약 100배 절감 — DW 없으면 정보 1건 접근에 $10,000, DW 있으면 $100<br>• 회사 A(DW 없음) vs 회사 B(DW 있음) 비교: 보고서 1건에 ① 데이터 찾기 ② 접근 ③ 통합 ④ 병합 ⑤ 보고서 작성 5단계 동일하게 필요<br> - A: 비용 $25,000~$100만, 소요 시간 1~12개월 (레거시 미문서화·기술 단절·접근 장벽 때문)<br> - B: 비용 $500~$10,000, 소요 시간 수 시간~반나절<br>• A는 결국 보고서 생성을 포기 → 엔드 유저 좌절·IT 불신 악순환 | • |
2장<br>Cost of Building the Data Warehouse | 운영 시스템 → 데이터 웨어하우스 | • DW 구축 비용은 보고서 1건만 쓴다면 낭비 — 5단계 작업(탐색·접근·통합·병합·보고)은 A와 동일하게 필요하기 때문<br>• 그러나 모든 기업은 복수의 보고서가 필요 (회계·마케팅·영업·경영진이 각각 다른 시각으로 데이터를 봄) → DW 구축 비용은 일회성 투자로 다수의 보고서에 재사용<br>• 결론: DW 구축 비용은 다수 보고서에 분산되어 정당화됨. DW가 없는 A사는 각 보고서마다 고비용을 반복 지불하다 결국 정보 접근을 포기함 | • | |
2장<br>Data Homogeneity / Heterogeneity | • 동질성(Homogeneity)<br>• 이질성(Heterogeneity)<br>• 데이터 발생(Occurrences of Data) | 데이터 웨어하우스 | • DW 데이터는 표면적으로 동질해 보이지만 실제로는 매우 이질적(heterogeneous)<br>• 데이터는 3단계로 세분화됨: ① 주제 영역(Subject Area) — 제품·고객·공급사·거래 등 ② 테이블(Table) — 주제 영역 내 여러 물리 테이블 (예: 제품 주제 안에 주문·BOM·공급사·출하 테이블 등 5개) ③ 데이터 발생(Occurrences) — 테이블 내 1월·2월·3월 출하 건 등 값 단위 구분<br>• 각 테이블의 공통 실(common thread)은 키/외래 키 — 제품 주제의 모든 테이블은 'product' 키로 연결<br>• 이 3단계 조직 구조 덕분에 DW는 아키텍처의 다양한 구성 요소(데이터 마트·탐색·마이닝 등)가 쉽게 접근·이해·활용 가능 | • |
2장<br>Purging Warehouse Data | • 데이터 생명주기(Data Life Cycle)<br>• 퍼징(Purging) | 데이터 웨어하우스 | • 데이터는 DW에 영원히 쌓이기만 하는 것이 아니라 고유한 생명주기를 가짐 — 퍼징은 DW 설계에서 반드시 다뤄야 할 핵심 설계 사안<br>• 퍼징(또는 변환)의 4가지 방식:<br> ① 롤링 요약 파일에 추가 — 상세 데이터 소실(detail lost)<br> ② DASD 등 고성능 매체에서 자기 테이프 등 대용량 매체로 이동<br> ③ 실제 시스템에서 완전 삭제<br> ④ 아키텍처 계층 간 이동 (예: 운영 계층 → DW 계층)<br>• 데이터 생명주기(적재 → 노화 → 요약/이동/삭제)는 DW 설계 프로세스에서 적극적으로 계획해야 함 — 사후에 처리하면 볼륨 관리 실패로 이어짐 | • |
2장<br>Reporting and the Architected Environment | • 운영 보고(Operational Reporting)<br>• DW 보고(Data Warehouse Reporting) | 운영 시스템 / 데이터 웨어하우스 | • DW 구축 후 모든 보고 처리를 DW에서 하려는 유혹이 있지만 운영 보고는 운영 환경에 두는 것이 맞음<br>• 운영 보고: 라인 아이템(개별 건) 중심, 사무직(clerical) 대상 — 예) 은행 창구 직원이 퇴근 전 당일 거래 내역 보고서로 잔액 정산<br>• DW 보고: 요약·계산값 중심, 경영진(managerial) 대상 — 예) 은행 부행장이 신규 ATM 설치 여부를 결정하기 위해 내·외부 다양한 정보를 종합 분석<br>• 라인 아이템 상세 정보는 기본 계산이 끝나면 DW 보고에서는 거의 쓸모가 없음 | • |
2장<br>The Operational Window of Opportunity | • 운영 윈도우(Operational Window)<br>• 아카이브 데이터(Archival Data) | 운영 시스템 / 데이터 웨어하우스 | • 아카이브 데이터: 현재 시점보다 오래된 모든 데이터 — DW는 24시간 이상 된 아카이브 데이터만 보유 (5~10년 범위)<br>• 운영 환경에도 소량의 아카이브 데이터가 존재: 운영 윈도우(Operational Window) — 1주~2년 범위, 접근 빈도 높고 볼륨 작음<br>• 산업별 운영 윈도우 예시: 보험 2~3년 / 은행 신탁 2~5년 / 전화 고객 사용 30~60일 / 소매 은행 계좌 활동 30일 / 항공 좌석 30~90일 / 공공 유틸리티 고객 사용 60~90일<br>• DSS 분석가에게 미치는 영향: 운영 윈도우 내 데이터 → 개별 건 분석에 적합 / 운영 윈도우 밖(DW) 데이터 → 대규모 트렌드 분석에 적합. 두 환경을 용도에 맞게 구분해 활용해야 함 | • |
2장<br>Incorrect Data in the Data Warehouse | • 오프셋 항목(Offsetting Entry)<br>• 계정 리셋(Account Reset) | 데이터 웨어하우스 | • 오류 데이터가 DW에 들어왔을 때 3가지 대응 방법 (예: 7/2에 $5,000 스냅샷 적재 → 8/15에 실제는 $750임을 발견):<br> ① 직접 수정(Update): DW 내 해당 레코드를 $5,000→$750으로 직접 갱신 — 깔끔하지만 7/2~8/16 사이 보고서와 조정 불가, DW에 갱신 기능 필요, 다건 수정 시 복잡<br> ② 오프셋 항목(Offsetting Entry): 8/16에 −$5,000과 +$750 두 항목을 동시에 추가 — 최신 상태를 가장 정확히 반영하지만 복잡한 계산이면 수정 자체가 어려울 수 있음<br> ③ 계정 리셋(Account Reset): 8/16 기준으로 $750을 현재 잔액으로 그냥 기록 — 과거 오류를 추적하지 않음, 과거 이력 정확도 손실<br>• 세 가지 중 절대적으로 옳은 방법은 없음 — 상황에 따라 더 나은 선택이 달라짐 | • |
2장<br>Summary | 전 계층 공통 | • 2장 핵심 요약: DW 설계에서 가장 중요한 두 가지 결정은 **입도(Granularity)**와 파티셔닝(Partitioning)<br>• 입도: 대부분의 조직에 이중 입도(경요약 + 진정한 아카이브)가 최적 — 너무 낮으면 볼륨 과다, 너무 높으면 세밀한 분석 불가. 대안으로 살아있는 표본 DB 활용 가능<br>• 파티셔닝: 애플리케이션 레벨 파티셔닝 권장 — 작은 물리 단위로 분리해 적재·인덱싱·아카이빙·삭제 등 관리 유연성 확보<br>• DW 개발은 반복적(iterative) 방식이 유일한 정답 — 빅뱅 방식 금지. 엔드 유저가 발견 모드로 작동하므로 첫 반복 이후에야 진짜 필요를 파악 가능<br>• DW 내 모든 데이터 단위에는 시간 요소가 결합됨 — 스냅샷·테이블 단위 타임스탬프·일/월/분기 요약·연속 파일 등 다양한 형태<br>• 감사(auditing)는 DW에서 가능하지만 하지 말 것 — 운영 트랜잭션 환경에서 하는 것이 맞음<br>• 퍼징(purging)은 DW 생명주기의 정상적인 일부 — 설계 단계에서 반드시 포함해야 하며, 빠뜨리면 DW가 무한 증가해 붕괴함 | • | |
3장<br>도입부 | • 휴리스틱 개발(Heuristic Development)<br>• 피드백 루프(Feedback Loop) | 운영 시스템 → 데이터 웨어하우스 | • 3장의 핵심 전제: DW 구축에는 두 가지 주요 구성 요소가 있음 — ① 운영 시스템에서의 인터페이스 설계 ② DW 자체 설계<br>• 그러나 "설계(design)"라는 말은 완전히 정확하지 않음 — 사전에 요구사항을 완전히 계획할 수 없기 때문<br>• DW는 휴리스틱 방식으로 구축됨: 일부 데이터 적재 → DSS 분석가가 사용·검토 → 피드백 기반으로 데이터 수정·추가 → 다음 부분 구축 → 반복<br>• 이 피드백 루프는 DW 생애 전체에 걸쳐 계속됨 — 고전적인 요구사항 주도 시스템과 근본적으로 다른 개발 방식<br>• 그렇다고 요구사항 예측 자체가 불필요한 것은 아님 — 현실은 "완전한 사전 계획"과 "완전한 즉흥" 사이 어딘가에 있음 | • |
3장<br>Beginning with Operational Data | • 인코딩 변환(Encoding Transformation)<br>• 측정 단위 변환(Unit of Measure Transformation)<br>• 필드 변환(Field Transformation)<br>• 아카이브 적재(Archival Load)<br>• 증분 적재(Ongoing Changes Load) | 운영 시스템 → 추출(ETL) → 데이터 웨어하우스 | • 운영 데이터를 단순 추출해 DW에 넣는 것만으로는 DW의 잠재력이 거의 실현되지 않음 — 통합(integration)이 핵심<br>• 레거시 시스템들은 서로 독립적으로 만들어졌기 때문에 통합을 전혀 고려하지 않음 → 4가지 비통합 문제 발생:<br> ① 인코딩 불일치: 성별 데이터가 앱마다 m/f, 0/1, x/y, male/female로 제각각 → DW로 들어올 때 일관된 값으로 변환 필요<br> ② 측정 단위 불일치: pipeline 필드가 앱마다 cm, 인치, mcf, 야드로 다름 → 단일 기업 측정 기준으로 변환<br> ③ 필드명 불일치: 동일 개념이 balance, bal, currbal, balcurr 등 다른 이름으로 산재 → 단일 필드명으로 매핑<br> ④ DBMS 이질성: IMS, DB2, VSAM 등 서로 다른 기술에 데이터가 분산 → 단일 기술로 통합<br>• 이 문제들이 수천 개의 레거시 시스템에 문서화도 없이 복합적으로 존재 → ETL 개발자의 악몽<br>• DW로의 3가지 적재 유형: ① 아카이브 데이터(최초 적재 시) ② 현재 운영 데이터 ③ 마지막 갱신 이후 변경분(증분 적재) | • |
3장<br>Data/Process Models and the Architected Environment | • 프로세스 모델(Process Model)<br>• 데이터 모델(Data Model)<br>• 시간 기반 이동(Time-Basis Shift)<br>• 데이터 압축(Data Condensation)<br>• 델타 파일(Delta File)<br>• 타임스탬프(Timestamp) | 운영 시스템 → 추출(ETL) → 데이터 웨어하우스 | • 증분 적재의 5가지 기법 (운영 환경의 변경분만 효율적으로 추출하는 방법):<br> ① 타임스탬프 스캔: 마지막 변경 시각이 찍힌 레코드만 읽음 — 효율적이나 원래부터 타임스탬프가 있어야 함<br> ② 델타 파일: 변경 건만 담은 파일 스캔 — 매우 효율적이나 대부분의 앱이 델타 파일을 만들지 않음<br> ③ 로그/감사 파일: 트랜잭션 부산물로 생성 — 내용은 풍부하나 시스템 내부 형식이라 해석이 어렵고 운영 팀 반발 있음<br> ④ 애플리케이션 코드 수정: 오래되고 취약한 코드라 거의 불가<br> ⑤ 이전/이후 이미지 비교: 두 스냅샷을 순차 비교 — 최후의 수단, 리소스 낭비가 심함<br>• 시간 기반 이동(Time-Basis Shift): 운영 데이터는 현재값(갱신 가능)이지만 DW 데이터는 시점 고정(갱신 불가) — 운영 → DW 이동 시 반드시 시간 요소 부착 필요<br>• 데이터 압축(Condensation): 추출 시점·DW 적재 시점 모두에서 데이터를 압축해야 함 — 하지 않으면 볼륨이 걷잡을 수 없이 증가 (일별 → 주별 → 월별 집계)<br>• 프로세스 모델 vs 데이터 모델: 프로세스 모델(기능 분해·DFD·구조도 등)은 사전 요구사항을 전제하므로 DW에는 적합하지 않음 — 운영 환경과 데이터 마트에만 적용. 데이터 모델은 운영 환경과 DW 환경 모두에 적용됨 | • |
3장<br>The Data Warehouse and Data Models | • 기업 데이터 모델(Corporate Data Model)<br>• 안정성 분석(Stability Analysis)<br>• 관계의 아티팩트(Artifacts of Relationships)<br>• 파생 데이터(Derived Data) | 운영 시스템 → 데이터 웨어하우스 | • 기업 데이터 모델(원시 데이터만 포함)을 기반으로 운영 모델과 DW 모델이 각각 파생됨 (Figure 3.8)<br>• 운영 데이터 모델: 기업 모델 ≒ 동일 + 성능 요소 추가만 — 변화 거의 없음<br>• DW 데이터 모델: 기업 모델에서 4가지 변환 적용:<br> ① 순수 운영 데이터 제거<br> ② 키 구조에 시간 요소 추가<br> ③ 공개적으로 사용·반복 계산되는 파생 데이터 추가<br> ④ 운영 환경의 관계(relationship)를 DW에서 **아티팩트(artifact, 관계의 흔적)**로 전환<br>• 안정성 분석(Stability Analysis): 하나의 대형 테이블을 변경 빈도에 따라 3개로 분리 — ① 거의 안 변하는 데이터(Seldom Changes) ② 가끔 변하는 데이터(Sometimes Changes) ③ 자주 변하는 데이터(Frequently Changes) — DW에서 이력 관리 효율화 | • |
3장<br>The Data Warehouse Data Model | • 고수준 모델(ERD, Entity Relationship Diagram)<br>• 통합 범위(Scope of Integration)<br>• 사용자 뷰 세션(User View Session) | 데이터 웨어하우스 | • DW 데이터 모델링은 3단계로 이루어짐: ① 고수준(ERD) → ② 중간 수준(DIS) → ③ 물리 모델<br>• 고수준(ERD): 엔티티(타원)와 관계(화살표)로 표현 — 화살표 방향·수가 카디널리티를 나타냄, 직접 관계만 표시해 전이 종속성 최소화<br>• 통합 범위(Scope of Integration): 모델링 시작 전 반드시 정의 — 모델러·경영진·사용자가 합의, 5페이지 이내·비즈니스 언어로 작성. 범위 미정의 시 모델링이 끝나지 않음<br>• 기업 ERD: 부서별 사용자 뷰 ERD를 수집·통합해 구성 — DSS 커뮤니티 요구사항은 사용자 뷰 세션(인터뷰)을 통해 파악<br>• 비유: 기업 데이터 모델 = 아담 / 운영 데이터 모델 = 카인 / DW 데이터 모델 = 아벨 — 같은 혈통이지만 각기 다름 | • |
3장<br>The Midlevel Data Model | • 데이터 항목 집합(DIS, Data Item Set)<br>• 기본 그룹(Primary Grouping)<br>• 보조 그룹(Secondary Grouping)<br>• 커넥터(Connector)<br>• 유형 데이터("Type of" Data)<br>• 슈퍼타입/서브타입(Supertype/Subtype) | 데이터 웨어하우스 | • ERD의 각 주요 주제 영역(엔티티)마다 **DIS(Data Item Set)**를 별도로 작성 — 전체를 한꺼번에 만들지 않고 필요한 주제부터 순차 전개<br>• DIS의 4가지 구성 요소 (Figure 3.14):<br> ① 기본 그룹: 주제 영역당 1번만 존재하는 속성들<br> ② 보조 그룹: 주제 영역당 여러 번 존재할 수 있는 속성들 (기본 그룹 아래 방향으로 연결)<br> ③ 커넥터: 주제 영역 간 관계를 나타냄 — ERD의 관계가 DIS 레벨에서는 외래 키 밑줄로 표시<br> ④ "Type of" 데이터: 슈퍼타입(왼쪽)→서브타입(오른쪽) — 예) 은행 활동 DIS: 입금/출금 유형 + ATM/창구 유형이 동시에 존재 → ATM입금·ATM출금·창구입금·창구출금 4종류<br>• 공통 데이터는 왼쪽, 고유 데이터는 오른쪽 배치 — 예) date·time은 모든 거래 공통, cashbox balance는 창구 거래만 해당<br>• 거래 2건(ATM 출금 + 창구 입금)이 5개 테이블에 6개 항목을 생성 (Figure 3.18) | • |
3장<br>The Physical Data Model | • 물리 데이터 모델(Physical Data Model)<br>• 물리적 I/O(Physical I/O) | 데이터 웨어하우스 | • 중간 수준 DIS에 키와 물리 속성을 추가하면 물리 데이터 모델(관계형 테이블 형태) 완성<br>• 물리 설계 전 마지막 필수 단계: 입도·파티셔닝 결정 — 이후 키 구조에 시간 요소 추가<br>• 물리 설계의 핵심 요소는 물리 I/O(입출력) 최소화 — I/O가 성능을 좌우하므로 이를 기준으로 인덱스·분산·배치 등 나머지 물리 설계 결정이 이루어짐 | • |
3장<br>The Data Model and Iterative Development | • 반복적 개발(Iterative Development)<br>• 통합 로드맵(Integration Roadmap) | 데이터 웨어하우스 | • DW는 항상 반복적으로 구축해야 하는 4가지 이유: ① 업계 성공 사례가 일관되게 지지 ② 첫 반복 완성 전에는 엔드 유저가 요구사항을 말할 수 없음 ③ 경영진은 가시적 결과가 나오기 전 전면 투자를 거부 ④ 빠른 가시적 결과가 필요<br>• 데이터 모델의 역할: 각 반복 개발의 통합 로드맵 역할 — 모든 반복 개발이 단일 데이터 모델을 기준으로 진행되므로 두 번째 반복이 첫 번째와 자연스럽게 교차·연결됨<br>• 단일 데이터 모델 아래 반복 개발 → 각 반복이 응집력 있고 조화로운 전체를 이룸<br>• 반대로 통합 데이터 모델 없이 반복 개발 → 중복·분리·비일관적 결과 초래 (불협화음) | • |
3장<br>Normalization/Denormalization | • 정규화(Normalization)<br>• 비정규화(Denormalization)<br>• 데이터 배열(Array of Data)<br>• 선택적 중복(Selective Redundancy)<br>• 데이터 분리(Further Separation of Data) | 데이터 웨어하우스 | • 정규화 결과물은 작은 테이블 다수 → 프로그램이 테이블 간 점프할 때마다 I/O 발생 → 성능 저하<br>• DW 물리 설계의 핵심 비정규화 기법 4가지:<br> ① 테이블 병합(Merging Tables): 자주 함께 쓰이는 테이블을 물리적으로 합침 → I/O 대폭 절감<br> ② 데이터 배열(Array of Data): 시간 순서로 반복되는 데이터를 별개 행 대신 단일 행의 배열로 저장 → 1번의 I/O로 n개 기간 데이터 조회. DW의 시간 기반 특성상 월별 배열이 매우 자연스러움<br> ③ 선택적 중복(Selective Redundancy): 널리 쓰이고 안정적인 속성(예: 부품 description)을 여러 테이블에 의도적으로 중복 배치 → 접근 비용 절감. DW는 갱신이 없으므로 중복으로 인한 갱신 비용 걱정 불필요<br> ④ 데이터 분리(Further Separation): 접근 빈도가 크게 다른 속성을 별도 테이블로 분리 — 예) 계좌 잔액(고빈도)과 계좌 개설일·주소(저빈도)를 분리 → 고빈도 데이터 접근 I/O 최소화 | • |
3장<br>Snapshots in the Data Warehouse | • 스냅샷(Snapshot)<br>• 이산 활동(Discrete Activity)<br>• 1차 데이터(Primary Data)<br>• 2차 데이터(Secondary Data)<br>• 아티팩트(Artifact) | 데이터 웨어하우스 | • 다양한 DW 애플리케이션의 공통 구조: 스냅샷(Snapshot) — DW 내 데이터 레코드의 기본 단위<br>• 스냅샷 트리거 2가지: ① 이산 활동(수표 발행·전화 통화·주문 완료 등 비즈니스 이벤트, 무작위 발생) ② 시간 경과(일·주·월 말 등 예측 가능한 트리거)<br>• 스냅샷의 4가지 구성 요소 (그림 3.34):<br> ① 키(Key): 단일 또는 복합 키 — DW에서는 보통 복합 키. 레코드와 1차 데이터를 식별<br> ② 시간 단위(Unit of Time): 연·월·일·시간·분기 등 — 이벤트 발생 시점 또는 데이터 캡처 시점<br> ③ 1차 데이터(Primary Data): 키에 직접 연관된 비키 데이터 — 예) 판매 키라면 판매 제품·가격·조건·장소·담당자<br> ④ 2차 데이터(Secondary Data, 선택): 스냅샷 생성 시점에 함께 캡처된 부수적 정보 — 예) 판매 시점 재고 수량, 은행 우대 금리. 외래 키일 수도, 아닐 수도 있음<br>• 2차 데이터와 1차 데이터가 동일 스냅샷에 공존 → 아티팩트(artifact): 스냅샷 시점의 관계를 암묵적으로 내포 (해당 시점에만 성립하는 추론적 관계) | • |
3장<br>Meta Data | • 메타데이터(Meta Data)<br>• 추출 이력(History of Extracts) | 데이터 웨어하우스 | • 메타데이터 = 데이터에 관한 데이터 — 정보 처리에서 늘 존재했지만 DW에서 새로운 중요성을 가짐<br>• 메타데이터가 없으면: 사용자가 DW에 무엇이 있는지·없는지 알 방법이 없음 → 탐색에 막대한 시간 낭비, 올바른 데이터를 찾거나 정확히 해석할 보장도 없음<br>• 메타데이터가 있으면: DW 내용의 색인(index) 역할 — 필요한 데이터가 어디 있는지 빠르게 안내하거나, 없다는 것을 즉시 확인<br>• 메타데이터 저장소가 추적하는 항목:<br> - 프로그래머 관점의 데이터 구조<br> - DSS 분석가 관점의 데이터 구조<br> - DW로 유입되는 원천 데이터<br> - 데이터가 DW로 들어올 때의 변환(transformation) 내역<br> - 데이터 모델<br> - 데이터 모델과 DW의 관계<br> - 추출 이력(history of extracts) | • |
3장<br>Managing Reference Tables in a Data Warehouse | • 참조 테이블(Reference Table)<br>• 참조 데이터(Reference Data) | 데이터 웨어하우스 | • 참조 테이블은 DW에서 자주 간과되지만 반드시 포함·관리해야 함<br>• 문제: 참조 테이블이 운영 환경에서 조용히 변경되는 동안, DW의 과거 데이터가 현재 시점의 참조 테이블을 참조하면 부정확한 결과 발생 (예: 1995년 DW 데이터를 1999년 기준 참조 테이블로 조회)<br>• 해결 원칙: 참조 데이터도 DW의 다른 데이터처럼 **시간 변형적(time-variant)**으로 관리해야 함 — 참조 데이터는 데이터 볼륨 절감에도 유용<br>• 두 가지 설계 방식 (양 극단):<br> ① 6개월마다 전체 스냅샷: 단순하지만 논리적으로 불완전 — 3월 15일 추가·5월 10일 삭제된 항목처럼 기간 내 변경 이력을 놓침<br> ② 초기 스냅샷 + 연간 변경 이력 수집: 논리적으로 완전 — 임의 시점의 참조 테이블 상태를 재구성 가능. 단, 매우 복잡하고 구현 부담이 큼<br>• 두 극단 사이에 다양한 변형 설계가 존재 — 어떤 방식이든 참조 테이블은 DW의 정규 관리 대상으로 다뤄야 함 | • |
3장<br>Cyclicity of Data — The Wrinkle of Time | • 데이터 순환성(Cyclicity of Data)<br>• 시간의 주름(Wrinkle of Time) | 운영 시스템 → 데이터 웨어하우스 | • 데이터 순환성: 운영 환경의 변경이 DW에 반영되기까지 걸리는 시간 — 예) Judy Jones가 주소를 바꾸면 ① 운영 환경에 즉시 반영 ② DW에는 기존 레코드 종료일 수정 + 새 레코드 삽입<br>• 시간의 주름 원칙: 운영 환경에 변경이 알려진 시점부터 최소 24시간 후에 DW에 반영 — 서두를 이유 없음<br>• 24시간 지연의 3가지 이유:<br> ① 기술 비용: 연계가 촘촘할수록 기술이 비싸고 복잡해짐 — 24시간: 일반 기술로 구현 가능 / 12시간: 더 큰 비용 / 6시간: 훨씬 더 큰 비용<br> ② 환경 규율: 지연이 충분히 있어야 DW에서 운영 처리를 하거나 운영 환경에서 DW 처리를 하려는 유혹을 막을 수 있음 — 4시간 이하로 줄이면 경계가 흐려짐<br> ③ 데이터 안정화 기회: 데이터가 DW로 이동하기 전 운영 환경에서 조정(correction)할 시간이 생김 — 이미 DW에 들어간 후 수정하면 양쪽 모두 수정해야 하는 이중 작업 발생 | • |
3장<br>Complexity of Transformation and Integration | • 데이터 정제(Data Cleansing)<br>• 키 재구성(Key Restructuring)<br>• 병렬 적재(Parallel Load)<br>• 도메인 점검(Domain Checking) | 운영 시스템 → 추출(ETL) → 데이터 웨어하우스 | • 운영 → DW 데이터 이동이 단순 추출처럼 보이지만 실제로는 극도로 복잡 — 프로그래머가 "내가 할 수 있다!"며 3분 만에 코딩을 시작했다가 낭패를 보는 패턴이 반복됨<br>• ETL 과정의 주요 복잡성 요소:<br> ① 기술 전환: DBMS(IMS→Informix 등)·OS·하드웨어·데이터 구조 모두 변환 필요<br> ② 선택 로직: 추출 대상 레코드 판별을 위해 여러 파일을 조인하는 복잡한 로직 필요, 온라인 윈도우 내 접근이 필요한 경우도 있음<br> ③ 키 재구성: 입력 키에 시간 요소 추가 또는 전체 키 구조 재해시<br> ④ 비키 데이터 재포매팅: 날짜 형식(YYYY/MM/DD → DD/MM/YYYY) 등 포맷 변환<br> ⑤ 데이터 정제: 도메인 점검·레코드 간 교차 검증·인공지능 서브루틴 등 다양한 정제 기법 적용<br> ⑥ 다중 원천 병합: 조건에 따라 다른 파일에서 데이터를 가져와 병합, 키 해소(key resolution)·시퀀스 재정렬 필요<br> ⑦ 요약: 여러 운영 레코드를 단일 프로파일 레코드로 집계 — 입력 레코드 유형별 도착 순서 조율 필요<br> ⑧ 레거시 관계 해독: 프로그램 로직에 묻힌 데이터 관계를 문서 없이 역추적·해독 (가장 고통스러운 작업)<br> ⑨ 기타: 문자 인코딩 변환(EBCDIC  ASCII), 병렬 적재/읽기, 기본값(default) 지정, 데이터 요소 이름 변경 추적, 전송 위치 결정 등<br>• 초창기에는 COBOL·C로 수작업 개발이 불가피했으나, 이러한 복잡성 때문에 ETL 도구가 탄생 | • |
3장<br>Triggering the Data Warehouse Record | • 이벤트/스냅샷 상호작용(EVENT/SNAPSHOT Interaction)<br>• 활동 생성 이벤트(Activity-Generated Event)<br>• 시간 생성 이벤트(Time-Generated Event) | 운영 시스템 → 데이터 웨어하우스 | • DW에 데이터가 채워지는 기본 비즈니스 상호작용: 이벤트/스냅샷 상호작용 — 운영 환경의 이벤트가 스냅샷을 트리거 → DW로 이동<br>• 이벤트 2가지 유형: ① 활동 생성 이벤트(판매·재고 입고·전화 통화·배송 완료 등 비즈니스 활동 — 무작위 발생) ② 시간 생성 이벤트(일 마감·주 마감·월 마감 등 — 규칙적·예측 가능)<br>• 스냅샷의 구성 요소(Components of the Snapshot): 시간 단위(이벤트 발생 시점) + 키 + 1차 비키 데이터 + 선택적 2차 데이터(아티팩트)<br>• 단순 사례(Some Examples): 고객이 이사할 때마다 스냅샷 생성 → 1989~1991·1991~1993·1993~현재 등 고객 이력 연속 추적. 보험료는 6개월마다 납부 시 스냅샷 생성 | • |
3장<br>Profile Records | • 프로파일 레코드(Profile Record)<br>• 집계 레코드(Aggregate Record)<br>• 활동 생성 이벤트(Activity-Generated Event)<br>• 시간 생성 이벤트(Time-Generated Event) | 운영 시스템 → 데이터 웨어하우스 | • 스냅샷이 이벤트에 의해 트리거되는 두 가지 방식: ① 활동 생성 이벤트(판매·재고·전화 통화 등 비즈니스 활동 — 무작위 발생) ② 시간 생성 이벤트(일·주·월 말 등 — 예측 가능·규칙적)<br>• 개별 활동 레코드가 맞지 않는 3가지 상황: 데이터 볼륨이 방대할 때 / 데이터가 자주 변할 때 / 세밀한 이력 상세가 불필요할 때<br>• 프로파일(집계) 레코드: 여러 개의 운영 상세 레코드를 단일 레코드로 묶은 것 — 예) 전화 회사: 월말에 고객의 월간 통화 활동 전체를 1건의 레코드로, 은행: 월간 전체 거래를 1건의 집계 레코드로<br>• 집계 방식: 합산(sum) / 건수(tally) / 최고·최저·평균 / 첫·마지막 발생 / 특정 조건 내 측정 / 특정 시점 기준값 / 최오래된·최최근 데이터 등<br>• 장점: 엔드 유저가 단일 레코드만 보면 되어 분석이 편리 — 데이터 아키텍트가 사전에 데이터를 패키징해 제공 | • |
3장<br>Managing Volume | • 볼륨 관리(Managing Volume)<br>• 대안적 상세 이력(Alternative Detail) | 데이터 웨어하우스 | • 프로파일 레코드의 핵심 효과: 볼륨 2~3 오더 매그니튜드 감소 (100배~1000배 압축) 가능<br>• 단점: 집계 시 상세 정보가 소실됨 — 소실되는 상세가 DSS 분석가에게 중요하지 않은지 확인 필수<br>• 위험 방지 전략 ①: 반복적 구축 — 1차 반복이 작고 빠를수록 누락된 상세를 발견하고 수정하기 쉬움. 첫 반복이 클수록 중요한 상세가 영구히 누락될 위험<br>• 위험 방지 전략 ②: 프로파일 레코드와 함께 대안적 상세 이력을 별도 보관 — 느리고 저렴한 순차 스토리지에 저장, 접근 불편하지만 필요 시 조회 가능. 대부분의 DSS 처리는 프로파일 레코드에서 수행 | • |
3장<br>Creating Multiple Profile Records | 데이터 웨어하우스 → 데이터 마트 | • 동일한 상세 데이터에서 복수의 프로파일 레코드 생성 가능 — 예) 전화 회사: 동일 통화 레코드로 고객 프로파일 / 지역 트래픽 프로파일 / 회선 분석 프로파일 등 동시 생성<br>• 범용 목적이면 DW로, 부서 특화 목적이면 데이터 마트로 투입<br>• 프로파일 레코드 생성은 대개 운영 서버에서 수행 (데이터가 있는 곳, 대용량 처리 가능한 곳). 과정이 복잡해지면 스냅샷 자체의 타당성을 재검토<br>• 프로파일 레코드의 메타데이터에는 집계 프로세스 정보(어떻게 집계했는지)가 핵심 항목으로 추가됨 | • | |
3장<br>Going from the Data Warehouse to the Operational Environment | • 직접 접근(Direct Access)<br>• 역방향 데이터 흐름(Reverse Data Flow) | 데이터 웨어하우스 → 운영 시스템 | • 정상 데이터 흐름: 운영 → DW. 그러나 기술적으로 역방향(DW → 운영)도 가능한 몇 가지 상황 존재<br>• 직접 접근(Direct Access): 운영 환경이 DW에 쿼리를 보내고 결과를 가져옴 — 가능하지만 엄격한 제약 존재:<br> ① 응답 시간이 최대 24시간까지 걸릴 수 있어 온라인 처리에 부적합<br> ② 요청 데이터는 수 바이트 단위의 소량이어야 함 (메가·기가바이트 불가)<br> ③ 두 환경의 기술(DBMS·프로토콜·용량)이 호환되어야 함<br> ④ 데이터 포매팅이 최소화되어야 함 | • |
3장<br>Indirect Access of Data Warehouse Data | • 간접 접근(Indirect Access)<br>• 사전 분석 파일(Preanalyzed File)<br>• 주기적 갱신(Periodic Refreshment) | 데이터 웨어하우스 → 운영 시스템 | • 직접 접근의 제약 때문에 간접 접근이 DW 데이터의 훨씬 효과적인 역방향 활용 방식<br>• 간접 접근 패턴: DW 분석 프로그램이 주기적으로 실행 → 관련 특성·기준 분석 → 소규모 온라인 파일 생성 → 운영 환경에서 빠르게 활용<br>• 분석 프로그램 특성: AI적 특성 보유 / DW 내 모든 데이터에 자유롭게 접근 / 백그라운드 실행(응답 시간 제약 없음) / DW 변경 주기에 맞춰 실행<br>• 온라인 사전 분석 파일 특성: 단위당 소량·전체 합계는 대용량 가능 / 온라인 담당자에게 필요한 것만 포함 / 갱신 아닌 주기적 전체 교체 / 개별 단위 접근에 최적화 | • |
3장<br>An Airline Commission Calculation System | 데이터 웨어하우스 → 운영 시스템 | • 간접 접근 사례 ① — 항공사 커미션 계산: 여행사와 항공사 담당자의 2~3분 대화 중 최적 커미션을 즉시 제시해야 함<br>• 최적 커미션 = 현재 예약 현황 + 과거 탑승 이력 조합 — 온라인 직접 계산 시 응답 시간 초과<br>• 해결책: 오프라인에서 정기적으로 분석 → 소규모 항공편 상태 테이블 생성 → 담당자는 현재 예약과 이 테이블만 조회하면 즉시 응답 | • | |
3장<br>A Retail Personalization System | 데이터 웨어하우스 → 운영 시스템 | • 간접 접근 사례 ② — 소매 개인화 시스템: 고객 전화(5~8분) 중 담당자가 개인화 대화로 구매 유도<br>• DW 분석 프로그램이 이력 분석 → 운영 환경에 고객 이력 파일 준비(마지막 구매일·유형·마케팅 세그먼트 등)<br>• "2월 이후 처음이시네요", "그 스웨터 마음에 드셨나요?" 등 개인화 대화 → 추가 광고 비용 없이 매출 증대 | • | |
3장<br>Credit Scoring | 데이터 웨어하우스 → 운영 시스템 | • 간접 접근 사례 ③ — 신용 점수: 고객 대출 신청 시 창구에서 5~10분 내 승인 여부 결정<br>• 소액·안정적 고객 즉시 승인 / 고액·불안정 고객은 과거 상환 이력·자산·소득 등 광범위한 이력 조사 필요 — 온라인 직접 계산 불가<br>• 분석 프로그램이 정기적으로 사전 승인 고객 파일 생성(고객 ID·승인 한도·특별 승인 한도) → 창구 담당자 즉시 조회, 한도 초과 시에만 대출 담당자 개입 | • | |
3장<br>Indirect Use of Data Warehouse Data | 데이터 웨어하우스 → 운영 시스템 | • 세 사례(항공·소매·신용)에서 드러나는 간접 활용의 공통 패턴: DW를 주기적으로 분석 → 핵심 정보를 담은 소규모 온라인 파일 생성 → 운영 환경에서 빠르고 효율적으로 활용<br>• 분석 프로그램 특성: AI적 특성 / DW 전체 데이터에 자유롭게 접근 / 백그라운드 실행(응답 시간 제약 없음) / DW 변경 주기에 맞춰 실행<br>• 주기적 갱신 특성: 드물게 발생 / 교체(replacement) 모드 / DW 기술 → 운영 환경 기술로 이동<br>• 온라인 사전 분석 파일 특성: 단위당 소량 / 온라인 담당자에게 필요한 것만 / 갱신 아닌 주기적 전체 교체 / 고성능 온라인 환경의 일부 / 개별 단위 접근에 최적화 | • | |
3장<br>Star Joins | • 스타 조인(Star Join)<br>• 팩트 테이블(Fact Table)<br>• 차원 테이블(Dimension Table)<br>• 다차원 접근법(Multidimensional Approach) | 데이터 마트 | • DW 설계의 최적 방식은 정규화(normalized) — 이유: 유연성 / 세밀한 데이터에 적합 / 특정 요구사항에 편향되지 않음 / 데이터 모델과 잘 맞음<br>• 스타 조인·팩트 테이블·차원 테이블 등 다차원 접근법은 데이터 마트 전용 — DW에 적용하면 특정 사용자 집단에 최적화되어 나머지 전체에게는 비최적화<br>• 스타 조인 구조: 대용량 엔티티(예: ORDER)가 팩트 테이블(중심) / 소용량 엔티티(PART·DATE·SUPPLIER·SHIPMENT)가 차원 테이블(주변) — 팩트 테이블에 외래 키 사전 조인, 수치 데이터는 팩트·문자 데이터는 차원으로 분리되는 경향<br>• 데이터 마트 ≠ 데이터 웨어하우스 대체재: 데이터 마트 구조는 부서별로 달라 기업 전체 관점의 재사용·조정(reconciliation)·유연성이 없음 — DW의 세밀한 정규화 데이터만이 이를 제공 | • |
3장<br>Data Marts: A Substitute for a Data Warehouse? | • OLAP<br>• 큐브(Cube) | 데이터 웨어하우스 → 데이터 마트 | • IT 업계 일각의 주장: DW는 비싸고 힘드니 데이터 마트로 대체하자 → 단기적으로는 일리 있지만 장기적으로 데이터 마트는 DW의 대체재가 될 수 없음<br>• 이유: 데이터 마트 구조는 부서 요구사항에 따라 형성 → 재무·영업·마케팅 데이터 마트가 각각 다른 스타 조인 구조를 가짐<br>• 데이터 마트를 DW로 쓰면 해당 부서에만 최적화되고 나머지 조직에는 비최적화·사실상 사용 불가<br>• 데이터 마트 구조의 한계: 재사용 불가 / 유연성 없음 / 부서 간 조정(reconciliation)의 기반 불가 / 미래 미지의 요구사항 대응 불가<br>• 반면 DW의 정규화된 세밀 데이터는 위 4가지를 모두 제공<br>• DW → 데이터 마트 이동 시 정규화 세계에서 다차원(큐브) 세계로 데이터를 선택·접근·재형성하는 비trivial한 과정이 필요 | • |
3장<br>Supporting the ODS | • 운영 데이터 저장소(ODS, Operational Data Store)<br>• 클래스 IV ODS(Class IV ODS)<br>• 프로파일 데이터(Profile Data) | 데이터 웨어하우스 → 운영 시스템 | • ODS 유형: 클래스 I(동기식) / 클래스 II(2~3시간 내) / 클래스 III(야간 동기화) / 클래스 IV(DW에서 비정기적으로 업데이트)<br>• 클래스 IV ODS: DW 데이터를 분석해 프로파일 데이터 형태로 ODS에 적재 — 간접 접근 패턴의 또 다른 형태<br>• 예) 고객 거래 이력 분석 → 고객 프로파일(이름·ID / 거래량 고저 / 수익성 고저 / 활동 빈도 / 선호 정보 등) 생성 → ODS에 적재<br>• DW 데이터(상세 다수)와 클래스 IV ODS 데이터(분석된 프로파일) 간에는 근본적 차이가 있음 | • |
3장<br>Summary | 전 계층 공통 | • 3장 핵심 요약: DW 설계는 데이터 모델에서 시작 — 기업 데이터 모델 → 운영 모델(거의 동일) / DW 모델(시간 요소·파생 데이터·아티팩트 추가)<br>• DW는 반복적 구축, 사전 요구사항 정의 불가, SDLC와 완전히 다른 개발 생명주기<br>• 핵심 설계 과제: 볼륨 관리 — 입도·파티셔닝이 가장 중요한 두 가지, 나머지 물리 설계는 데이터 접근 효율 중심<br>• 운영 → DW 데이터 이동: DBMS·OS·하드웨어·의미론·인코딩 등 복잡한 변환 과정, 시간 이동(time-basis shift) 필수<br>• DW 레코드의 기본 구조: 타임스탬프 + 키 + 직접 데이터 + 2차 데이터<br>• 참조 테이블도 시간 변형적으로 관리 필수 / 24시간 시간의 주름 원칙 준수<br>• 스타 조인은 데이터 마트 전용 설계 기법 — DW에 적용하면 특정 사용자에게 편향된 구조가 됨 | • |