Communication & High Tech Haejin, Yu CRM을 위한 데이터모델링 Communication & High Tech Haejin, Yu

목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 고객관계(CRM) 데이터모델링 모델 Repository구성 및 모델 유지/관리 모델링 Roles & Responsibilities ©Accenture 2001 All Rights Reserved

논리 데이터 모델링이란? 관리대상이 되는 정보를 추출하고 그 정보들간의 관계를 설정하여 시각화 하는 과정이다 비즈니스사용자와의 약속 사용자의 정보요구에 대한 종합적인 이해를 촉진 업무(요소)를 반영하고 그것들 간의 관계를 데이터 관점에서 설정 사용자의 요구사항을 만족시켜줄 수 있는 데이터 설계도 IT 그룹간의 약속 설계자, 개발자 및 사용자간의 효과적인 의사전달 수단 데이터저장 및 통제를 위한 청사진 정확성, 무결성, 공유성, 융통성이 높은 DB및 파일 구조설계를 위한 기초제공 (단 물리적인 구현과는 독립적) 최고경영자와의 약속 향후 To-Be Solution에 대한 기반제공 및 이해 촉진 전사적인 비즈니스, 정보의 시각적/구조적 표현 ©Accenture 2001 All Rights Reserved

왜 데이터모델링을 하는가? 효율성과 성능 향상(Efficiency & Performance) 유연성(Flexibility) 필요한 정보를 제공해줄 수 있는가? 얼마나 빠른 시간 안에 정보를 제공하는가? 논리적 프로토타이핑을 함으로서 구현이 용이하고 비용을 절감할 수 있는가? 유연성(Flexibility) 새로운 요구사항에 대하여 얼마나 쉽게 시스템에 적용 가능한가? 비즈니스 전략을 적극 지원할 수 있는 아키텍쳐인가? 유지보수(Maintainability) 중복된 데이터가 없는가? 모든 시스템 유지보수는 As-Is Built모델로부터.. 비즈니스 사용자/모델러/DBA/Application개발자등 관련자 모두에게 유용하게 쓰여지도록 관리되는가? ※데이터모델링에 대한 잘못된 편견 데이터모델링은 모델러만 하면 된다. 오직 다이어그램을 생성하는 것이다. 데이터베이스를 위해서만 존재하는 것이다. ©Accenture 2001 All Rights Reserved

데이터 모델링 기법 데이터 모델이란 개체에 대한 설명과 각 개체들간의 관계를 표현하는 기법 데이터 모델이란 개체에 대한 설명과 각 개체들간의 관계를 표현하는 기법 Entity Relationship Model 개념적 데이터 모델(Conceptual Data Model) 1976, Peter Chen이 최초 고안 1988년, ANSI에 의해 IRDS (Information Resource Dictionary Systems – 리파지토리 표준) 의 표준 모델로 선정 Entity (엔티티), Relationship (관계), 그리고 Attribute (속성) 및 Identifier (유일 식별자) 로 모든 데이터 요구사항을 표현 이후 Extended ERM에는 다른 개념들, 즉 Composite Attribute (중복 속성)이나 Generalization hierarchies (일반화 계층관계) 등이 포함 Relational Model EF Codd 에 의해 1970년에 제안된 모형으로 모든 실체와 관계를 표로 표현하는 기법 일반적으로 기업 경영업무에서 표를 많이 쓰므로 기업용 데이터 모델로 많이 활용 관계형 모델을 사용하여 상용화된 DBMS가 가장 많음 Relation (관계 혹은 표)과 이를 구성하는 Attribute (속성) 및 Primary Key, 그리고 Relation 간의 관계를 표현하는 Foreign Key 등이 있다. ©Accenture 2001 All Rights Reserved

데이터 모델링 기법 Object-Oriented Model Object-Relational Model 프로그래밍 언어에서 개념이 발전된 모델로 단순히 데이터의 구조에 대한 모델 뿐만 아니라 행동까지 포함, 설계하는 방법론 Class, Object, Attribute, 그리고 Operation 들로 실체를 설명하고 관계를 설명하기 위해서 Classification, Polymorphism, 그리고 Inheritance 등 복잡한 개념을 사용 프로그래밍 언어를 위한 모델로는 널리 사용되고 있으나 데이터저장을 위한 모델로는 제한적으로 사용 Object-Relational Model 객체지향 모델의 복잡성을 줄이면서도 그 장점을 활용하기 위하여 고안된 모델 ©Accenture 2001 All Rights Reserved

데이터 모델링 단계 Data Modeling / Database Design은 일반적으로 다음의 세가지 단계를 거치게 됩니다. 요구사항 분석 및 추출 데이터 요구사항 분석 및 추출 개념 설계 논리 설계 물리 설계 산출물: 개념 스키마 산출물: 논리 스키마 산출물: 물리 스키마 Conceptual Modeling Logical Modeling Physical Modeling - 프로젝트 목적정의 - 프로젝트 일정수립 - Role&Responsibility 정의 - 프로젝트 준비자료 관리하고자 하는 유용한 정보와 그 관계를 정의하고 형상화 하는 것 =>경영적 측면 데이터 요구사항을 특정 설계기법을 사용하여 정형적이며 읽기 쉬운 모델로 만드는 작업 특정 DBMS Class (관계형, 계층형) 에는 독립적인 모델로 표현됨 기업내에 존재하는 데이터에 대해 업무와는 독립적으로 실체 인식, 이를 문서화하는 과정 =>수학적 측면 어떤 DBMS Class (관계형, 계층형 등) 를 쓸지를 결정하고 이를 위해 개념스키마를 논리스키마로 변환하는 과정 관계형, 객체관계형, 네트워크형, 계층형 등의 데이터 모델들이 사용됨 관계형 모델을 사용할 경우, 정규화 등이 작업이 요구됨 물리 모델에 독립적임. MODEL에 반영된 정보의 요구사항을 관계형 데이터베이스 설계로 바꾸는 작업 => 시스템적 측면 논리 스키마를 이용하여 특정 DBMS 제품에 종속적인 스키마 산출 특정 제품에 적합한 저장 구조나 접근 방법 등이 고려됨. (Index나 Device 정의 등) ©Accenture 2001 All Rights Reserved

데이터 모델링 단계 개념설계(Conceptual Modeling) 주요 수행 업무 주요 관련 설계자 추상적인 기업업무를 특정 설계기법을 이용하여 정형적으로 표현하는 단계 주요 수행 업무 엔티티 정의 및 관련 제약조건 정의 관계 및 관계관련 제약조건 정의(카디날리티 포함) 일반화 계층 정의 (General Hierarchy) 속성 및 속성 관련 제약조건 정의 식별자 정의 주요 관련 설계자 Business Council Data Architect 시스템 개발 및 유지보수 관련자 개념설계를 지원하는 설계기법은 표현성(Expressiveness), 형식성(Formality), 최소성(Minimality)을 지님. ©Accenture 2001 All Rights Reserved

데이터 모델링 단계 아래 그림은 주문관련 업무를 ER 모델로 개념 설계한 결과입니다. Real World Business ORDER CUSTOMER ITEM PRODUCT Is for Initiate Is part of consist of has Is included ID Order date Order type Name Phone # SSN Birthday Quantity Price Description Type ER Model Discount 요구사항 도출 및 분석 Legend * 위 ER Model의 Notation은 다르게 표현될 수 있습니다. Entity Attribute Relationship Identifier 1:M 1:M 1:M ©Accenture 2001 All Rights Reserved

데이터 모델링 단계 논리설계(Logical Modeling) 주요 수행 업무 주요 관련 설계자 개념모델을 기반으로 하여 특정 DBMS Class (e.g, 관계형, 계층형, 네트워크, ISAM)에 적용가능 하도록 설계하는 단계 주요 수행 업무 개념모델 스키마를 관계형 모델로 매핑 정규화 검토 도메인 설정 관계형 모델 제약조건 설정 및 적용 검토 키 제약조건 – 후보키 (Candidate Key), 유일성, 최소성 엔티티 무결성 제약조건 (Entity Integrity Constraint) – PK는 Null값을 가질 수 없음 참조 무결성 제약조건 (Referential Integrity Constraint) 주요 관련 설계자 Data Architect 모델러 DBA ©Accenture 2001 All Rights Reserved

데이터 모델링 단계 아래 그림은 이전의 개념 설계에 근거한 논리 설계를 관계형 모형으로 표현한 예입니다. ER Model ORDER CUSTOMER ITEM PRODUCT Is for Initiate Is part of consist of has Is included ID Order date Order type Name Phone # SSN Birthday Quantity Price Description Type Discount Relational Model ORDER CUSTOMER ORDER_ITEM ITEM ID Order_date (M) Order_type (M) CTR_SSN SSN Name (M) Phone # Birthday Order_ID Item_ID Quantity (M) Discount Description (M) Price (M) PRT_ID PRODUCT Type Relation Model 관련 논리 정의 (Constraints..) Legend * 위 Model의 Notation은 다르게 표현될 수 있습니다. Relation (M): Mandatory Primary Key A B C (D: XX): Default Value XX Attribute Foreign Key ©Accenture 2001 All Rights Reserved

데이터 모델링 단계 물리설계 (Physical Modeling) 주요 수행 업무 주요 관련 설계자 논리설계 산출물 및 특정 데이터베이스 특성에 기반하여 모델의 최적화를 수행하는 단계 주요 수행 업무 Index 및 View 생성 데이터 분산 결정 Physical Size결정 각종 Procedure설정 테이블 스키마 생성 주요 관련 설계자 DBA 시스템 개발/유지보수 관련자 ©Accenture 2001 All Rights Reserved

목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 고객관계(CRM) 데이터모델링 모델 Repository구성 및 모델 유지/관리 모델링 Roles & Responsibilities ©Accenture 2001 All Rights Reserved

E-R 모델링이란? Entity-Relation모델링 장점 단점 비즈니스의 실체(Entity)를 파악하고 관계를 정의하는 기법 데이터의 중복을 최소화 비즈니스 규칙 및 데이터 정합성 유지 장점 전사적인 비즈니스 View를 제공 포괄적인 데이터 검색 및 분석을 가능 단점 비즈니스 사용자가 모델을 이해/분석하기가 곤란 Tool에서 제공하는 Query가 효과적이지 못함 물리적인 질의 성능 저하 Denormalization 필요 ©Accenture 2001 All Rights Reserved

E-R모델의 예 Account Type Account Role Interest Revenue Account Role_ID Period_ID Organization_ID Account_ID Product_ID Volume Account Customer_Account Account_ID Account_Type Customer_ID Account_ID Role_ID Address Address_ID Party_ID Address City State Country Zip Code Household Customer Household_ID Customer_ID Household_ID Customer_Type Parent_ID Address_Geocoding Geocodes Customer_Type Address_ID Geocode Geocode_ID Customer_Type ©Accenture 2001 All Rights Reserved

모델 정규화 기법(Normalization) 1차 정규화 : (No Repeating Groups) 2차정규화 : ( Non-key Attribute depend on the whole primary key) Customer_ID Customer_ID Child Children1 Comment1 …. ChildrenX CommentX Comment Supplier_ID Part_No City_Name Supplier_Name Supplier_ID Supplier_ID Part_No City_Name Supplier_Name Part_color Contact_Name Contact_Phone Part_Price Part_No Contact_Name Contact_Phone Part_Color Part_Price ©Accenture 2001 All Rights Reserved

3차정규화 : (Non-Key Attributes depend only and fully on primary key) Boyce-Codd 정규화(BCNF) 4차 정규화 5차 정규화 Part_No Part_No Supplier_Name Part_color Contact_Name Contact_Phone Part_Price Supplier_Name Contact_Name Part_Color Part_Price Supplier_Name Contact_Name Contact_Phone ©Accenture 2001 All Rights Reserved

다차원모델이란? 다차원모델 장점 단점 사용자의 질의에 중점을 둔 기법 비즈니스 사용자가 측정하기를 원하는 Fact와 그들의 Dimension에 근거한 View Fact의 Key는 Dimension들의 Key를 연결한 것이다. 장점 사용자의 이해가 용이 구축시간 및 비용 절감 Query성능 증가 단점 제한된 어플리케이션 중복데이터발생(Denormalization) Flexibility가 떨어짐 Cross Functional Question Ad-hoc Query, Mining ©Accenture 2001 All Rights Reserved

다차원모델의 예 Dimension Tables: Fact Tables: Dimension Tables: Fact_Shipments Lookup_Product Lookup_Carrier Product key Market key Carrier key Time key Dollar sales Case sales Extended price Extended cost Product key product desc SKU number size packaging flavor Carrier key Carrier name DUNS rating Carrier type address Credit rating Lookup_Market Lookup_Time Market key market desc territory region Time key Day of week Holiday flag fiscal Period Quarter Year ©Accenture 2001 All Rights Reserved

모델확장 Dimension Tables: Fact Tables: Dimension Tables: 주의 : Fact_Shipments Lookup_Product Lookup_Carrier Product key Market key Carrier key Time key Dollar sales Case sales Extended price Extended cost Product key product desc SKU number size packaging flavor Carrier key Carrier name DUNS rating Carrier type address Credit rating 주의 : Warehouse Withdrawal Fact Table과 Shipments Fact Table간 직접적인 관계를 가지지 않으므로, 이들 두개의 “목적 분야”내에서 어떻게 정보를 서로 공유하여 분석할 수 있느냐 하는 것에 제한성을 가질 수 있음 Lookup_Market Warehouse Withdrawls Lookup_Time Market key market desc territory region Product key Market key Time key Dollar sales Case sales Extended price Extended cost Time key Day of week Holiday flag fiscal Period Quarter Year ©Accenture 2001 All Rights Reserved

Virtual Star Schema Interest Revenue Account Type Account Role Account Period Period_ID Period Attributes Account/ Customer/ Household Interest Revenue Organization Period_ID Organization_ID Account_ID Product_ID Scenario_Type Volume Account_ID Account Attributes . . . Customer_ID Customer Attributes Household_ID Household Attributes Organization_ID Organization Attributes Product Product_ID Product Attributes Scenario Scenario_Type Scenario Attributes Interest Revenue Account Type Account Role Period_ID Organization_ID Account_ID Product_ID Volume Account_Type Role_ID Account Customer_Account Account_ID Account_Type Customer_ID Account_ID Role_ID Address Address_ID Party_ID Address City State Country Zip Code Household Customer Household_ID Customer_ID Household_ID Customer_Type Parent_ID Address_Geocoding Geocodes Customer_Type Address_ID Geocode Geocode_ID Customer_Type ©Accenture 2001 All Rights Reserved

Snowflake Schema Perceived as saving disk space Fact_Shipments Lookup_Month Lookup_Day Lookup_Year Product key Store key Carrier key Date key Dollar sales Case sales Extended price Extended cost Year Key Year DESC Month Key Month Desc Year Key Date Key Month Key Year Key Date Desc Lookup_Store Lookup_Region Lookup_Market Market Key Market Desc Region Key Store Key Store Desc Market Key Region Key Region Key Region DESC Computer Scientist - looks beautiful Average user - intimidated Reasoning Perceived as saving disk space ...............but is it the reality????? ©Accenture 2001 All Rights Reserved

목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 고객관계(CRM) 데이터모델링 모델 Repository구성 및 모델 유지/관리 모델링 Roles & Responsibilities ©Accenture 2001 All Rights Reserved

데이터웨어하우스 아키텍쳐와 모델링 Enterprise-Centric Data Mart-Centric 전사적 데이터웨어하우스 관계형 모델링 방법 : 3차 정규화 모델 상세정보(Detail Data) 전사적인 정보의 단일화 주제중심의 데이터 저장 운영계 시스템으로부터 변형/통합되어 저장 데이터 마트 Star schema 모델링, 다차원데이터베이스(MDDB) 전사적 데이터웨어하우스를 보완하는 요약정보, 복제, 증식 데이터 업무 프로세스 중심으로 설계 Data Mart-Centric Star Schema데이터 모델링 주제중심 혹은 부서업무중심으로 설계 전사적인 모델은 고려하지 않음 ©Accenture 2001 All Rights Reserved

Data Warehouse vs. Data Mart Enterprise-Centric Data Mart-Centric OLTP/ Legacy Systems Enterprise Data Warehouse Departmental Data Marts Sales Marketing Sales Finance Marketing Finance Departmental Data Marts ©Accenture 2001 All Rights Reserved

데이터 웨어하우스 모델링 데이터 모델링 중앙저장소와 비즈니스 사용자가 Operation하는 단계의 정보를 일치시키기 위해서는 가장 중요한 요소 전사적인 데이터 웨어하우스는 상세데이터를 정규화된 모델로 설계하여야 한다 비즈니스 사용자가 직접 Access하는 데이터 마트는 이 모델로부터 생성되어야 한다. e.g.: Standard Coding reference tables will be defined centrally and employed within EDW and Data Marts 데이터 마트의 모델은 특정부서나 특정업무를 지원하기위해서 다른 데이터 마트와 공유되지 않을 수도 있다. ©Accenture 2001 All Rights Reserved

목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 고객관계(CRM) 데이터모델링 모델 Repository구성 및 모델 유지/관리 모델링 Roles & Responsibilities ©Accenture 2001 All Rights Reserved

CRM 사용자그룹 사용자그룹 사용자 특성 비고 Customer Contact 고객과의 접점을 항상 유지하는 사용자 그룹 고객관점에서의 상세데이터를 요구 고객의 행동을 파악/이해하여 Event방식의 마케팅전개 고객의 요구에 신속히 대처/고객이 원하는 정보를 정확히 전달 POS,ATM,Call Center Internet E-R모델링(Operational CRM) Application Server 특정시간에 데이터 웨어하우스를 분석하여 의사결정정보 제공 Event-Driven 마케팅을 가능하게 하는 Application 관리인력이 필요없는 시나리오에 의해 고객 분석 및 고객 접촉 E-R모델링 일반현업사용자 특정한 비즈니스 질의에 대해 Solution제공 특정한 기능을 가진 Application요구 (OLAP) 고객,상품,지역,과금,CDR,시간의 다차원분석업무 단순한 Reporting으로 비즈니스의 문제를 발견 일반현업, OLAP전문가 (특히 Relational OLAP) 다차원모델, E-R모델 분석가 그룹 상세데이터 및 대량의 History 데이터에 대한 분석욕구 다양 표현된 정보의 Business의미나 상관관계(Business Rule)를 도출 강력한 Ad-hoc Query 툴을 이용하여 복잡하고 신축적인 정보 요구 전략기획가, 재무분석가, 마케팅 분석가, 연구원, 데이터 마이닝전문가 등 E-R Modeling 최고경영자 사전에 정의된 Summary형태의 다차원 모델을 요구 현재의 시장상황을 요약한 형태의 시계열분석자료 기업내부의 특성 혹은 예외적인 현상을 표현하는 자료 CEO, Sales관리자, 인사/재무담당임원 (다차원 OLAP) - 다차원모델 ©Accenture 2001 All Rights Reserved

Central data translator Back-office applications and data sources CRM Architecture Operational CRM Analytical CRM Central data translator Back-office applications and data sources Customer Contact Channel Front-end Web ERP DW EAI Application Call Center i2 Application SMS Application Transaction database Relationship database FAX Kiosk profile database E-Mail CID database & CCDB Product information database Planning database WAP LDAP Face to face EAI : Enterprise Application Integration ©Accenture 2001 All Rights Reserved

CRM Business Architecture These capabilities need to be tightly integrated in order to achieve a balance between creating value for the customer and for the company Customer Offers Segments Brands Offers Alliances Acquire Retain Develop Business to Business Business to Consumer CUSTOMERS Channels MAIL/e-mail/Fax Pager/PDA/Cell PHONE WEB RETAIL FACE-to-FACE Manage Customer Interactions (Contact Centers, Retail Operations, Field Operations, Web Operations) Personalization Needs Assessment Profiling Questions Search Tools Pre-built Options Offer Configuration Differentiated Service Status Inquiry Change Content/Scripting Management Value/ Pricing/ Behavior Offer Product Modeling Business Rules Payment Constraints Optimization Generate Customer Insight Integrated Customer Data Customer Understanding (Culture, Organization, Competence, Performance Metrics, Customer-Driven Management, Communication, & Simulation) Culture Data Data B to B B to C Integrated Data Models Strategic Profiling Customer Insight Relationship / Sourcing Preprocessing and Analysis Modeling & Engines Campaign Mgm’t • Operational Loyalty Churn Risk • Contacts Acquire Develop • Extract Value & • Orders/Payments Product • Service Events • Transform Segments Mix Channel Prospecting Cross Selling • External Mix • Load Retain • Equifax Revenue Management • D&B Enterprise Integration / Integration Architecture (Alliances, Back-office, Workflow, Interfaces, Middleware & Software Management) ©Accenture 2001 All Rights Reserved

Classification/ segmentation 고객위주의 데이터모델 Hierarchy - 조직/인력의 계층구조 - 고객계층 - 고객과 고객간의 관계 - 공급자, 협력업체,경쟁업체 Relationship attributes - 고객만족도 - 고객관계시작/종료일자 - 고객과의 관계이력 - 판매량 - 담당고객상담원 - 관계유형 거래 Transaction History - 거래유형 및 성향 분석 서비스 상품 - 고객이 현재 소유하거나 이용하고 있는… 채널 - 고개과의 접촉수단 고객 - Name / Id - Status Classification/ segmentation - Business group specific segmentation - 고객 신용도, 충성도등 Scoring점수 고객행동 구매습관 - 상담내용분석,불만처리 - Sell Next 일반정보 주소, 전화번호, eMail주소 - 언어/ 국가/지방 - 지역 - 고객유형 고객요구사항 - Preferences - Interest Common information element Common core information element ©Accenture 2001 All Rights Reserved

Operational vs. Analytical Operational CRM: Analytical CRM: Transaction Environments Function-Oriented 업무 Flow을 반영한 데이터 구조 Transaction위주의 입력,갱신 삭제처리 특정한 정보에 대해서는 신속한 정보요구(1-2초) 모델링 작업 시 엔터티 유형 : 입금, 출금, 신청, 개통, 구매 등 Query Environments Subject-Oriented 비즈니스분석 위주의 데이터 구조 복잡한 질의 및 대용량 처리 다양한 정보요구에 대해 Reasonable한 성능보장 다차원적인 분석 View제공 비즈니스 사용자의 사용이 용이하게 구성 모델링 작업 시 엔터티 유형 : 고객, 상품, Events, Score 등 Transaction Databases Data Refinery ©Accenture 2001 All Rights Reserved

고객중심의 데이터모델 이슈 고객정보 = 중요한 무형자산임을 인식 분산된 고객정보  통합된 형태로 재구성 고객정보 : 거래데이터  고객 Privacy/Preference  외부고객정보 순으로 획득 현재 보유하고 있지 않은 고객정보에 대해서도 모델링  향후 To-Be의 모습을 고려 신규사업창출을 위한 마케팅 데이터 보유 고객 데이터 획득/분석/활용/ 갱신의 반복적인 프로세스모델 고려 End-to-End Solution을 제공할 수 있는 아키텍쳐와 모델 수립 ©Accenture 2001 All Rights Reserved

목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 고객관계(CRM) 데이터모델링 모델 Repository구성 및 모델 유지/관리 모델링 Roles & Responsibilities ©Accenture 2001 All Rights Reserved

Data Architecture Admin 시스템별 DBA / Application DBA 모델링 관련 역할 및 책임 단일화된 전사적인 통합 개념모델을 수립하고 CRM을 위한 모델링 표준 및 방법론을 제시할 수 있는 역할이 필요하다. Business Community Data Architecture Admin Data Steward Council Data Planning Application Developer DBA 사용자 요구사항 분석단계 개별시스템 개념 및 논리 모델 생성 전사통합 논리모델 반영 및 검토 물리모델 생성 어플리케이션 개발 표준화 데이터 사전 활용 및 등록 시스템별 논리모델 전사개념모델 및 데이터목록 시스템별 모델 및 데이터목록 Owner : 전사 DA팀 시스템별 DBA / Application DBA ©Accenture 2001 All Rights Reserved

모델링 설계참여그룹 특성 Business Community Data Architect Modeler DBA 개념적 논리모델 설계 업무에 대한 요구사항 제공, 모델 검증 Data Architect 변화관리 전사적 통합 모델관리 및 표준화 제공 Legacy Data의 Schema제공 Modeler 개념 설계 및 논리 데이터모델 설계 DBA 물리모델설계 Performance & Tuning Data stewardship council Business Data steward Enterprise Standard Data Steward(Data Architect) Legacy System Data Steward ©Accenture 2001 All Rights Reserved

Data Steward Council 주요 수행업무 통합모델 및 데이터의 품질관리 비즈니스 규칙정의, 표준화 통합모델 Repository 및 메타데이터 관리 비즈니스 사용자와의 Communication Channel, 비즈니스 사용자의 대리인 역할 전사적인 사용자 보안등급 및 인증절차 수립 Business Data Steward 업무를 이해하고 있는 Cross Functional Subject Area전문가 Enterprise Standard Data Steward (Data Architect) 전사 통합모델을 관리 표준화방안 및 모델링 방법론 청사진 제시 Legacy System Data Steward 기존 시스템의 데이터를 이해하고 품질을 검증 ©Accenture 2001 All Rights Reserved

목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 목 차 데이터 모델링 소개 E-R모델링 vs. 다차원 모델링 데이터 웨어하우스 모델링 vs. 데이터 마트 모델링 고객관계(CRM) 데이터모델링 모델 Repository구성 및 모델 유지/관리 모델링 Roles & Responsibilities 결론 ©Accenture 2001 All Rights Reserved

Critical Success Factor 적정성 판단기준 데이터를 정의하고 구성하는 방법이 규칙에 맞게끔 일관된 표현 사용자의 이해가 용이하게끔 단순해야 함 데이터 모델은 필요한 데이터가 한곳에 한번만 존재해야 함 데이터의 정확성과 일치성을 유지하는 무결성을 가져야 함 새로운 요구가 수용될 수 있는 확장성을 가져야 함 성공요소 해당 업무에 대한 지식을 가진 현업 사용자와 공동으로 개발 논리 모델링 전단계에 걸쳐 체계적인 방법을 채택 데이터 중심의 분석 방법을 사용 데이터 구조적인 측면과 무결성(업무 규칙) 측면을 고려 정규화 및 다차원모델의 적정한 선택 작업 담당자들 간의 모델링 개념 및 방법론에 대한 지식 공유 ©Accenture 2001 All Rights Reserved

데이터모델링 Best Practices 모델링 Best Practices 개념모델수립은 비즈니스사용자가 설계 최종적인 모델검증도 비즈니스 사용자의 책임/비즈니스 사용자는 모델을 이해할 수 있어야 함 Top-Down 방식과 Bottom-up 방식을 병행하여 사용 처음부터 모델링 Tool을 사용하지 말고 White Board를 이용 전체모델을 컬러로 복사하여 벽에 걸어놓을 것 논리모델 설계 시에는 Performance에 대해 고려하지 말것 엔티티 Access Matrix(CRUD)를 작성/유지 할 것. 방법론에 대한 Blue Printing 및 Standardization을 사전에 정의 작성된 모델은 Repository에 저장되고 Metadata로서 활용되어야 함 모델은 비즈니스사용자, 모델러, 어플케이션 개발자, DBA등 모든 관련사람에 의해 유지/사용되어야 함. ©Accenture 2001 All Rights Reserved