른 책들 또는 저자들을 추천
Eyes
새로 나온 책들을 email로 추천
Amazon.com Deliver
고객이 선택한 속성과 일치하는 책들을 email로 추천
Book Matcher
고객의 직접적인 feedback(rating)에 따라 새로운 책 추천
CDNOW
Album Adviser
고객이 선택한 앨범에 대하여 10개의 관련 앨범 추천
My CDNOW
고객의 앨범 및 아티스트에 대한 선호도 + 고객의 구매 자료로부터 새로운 앨범의 추천
Reel.com
Movie Matches
선택한 영화와 유사한 장르, 주제, 분위기의 영화 추천
Movie Map
고객이 입력한 속성값에 가장 근접한 영화를 추천
BSD
BSD(Business System Design)은 간단하게 말해서 DB 구축시의 모델링 방법론, 튜닝 방법론 등 말 그대로 시스템을 디자인하는 여러가지 내용들을 지칭하는 것이다.
시스템 디자인의 설명에 들어가기에 앞서, 데이터웨어 하우스의 구조 및 내부 활동을 살펴보고 시스템 디자인이 어떻게 사용될 지에 관해 미리 살펴보자.
DW 구조
DW는 원시데이터 계층, 데이터웨어하우스 계층, 클라이언트 계층으로 구성되며 데이터 추출, 데이터 저장, 데이터 조회의 활동으로 구성된다.
특히 데이터웨어하우스 계층은 대용량 정보 저장의 RDB와 목적지향의 MDB(Multi Dimensional Database)로 분류되고 이 취합 정보들을 클라이언트에게 보여준다.
구성요소
- 원시 데이터 계층
기존 메인 프레임 어플리케이션, 클라이언트 어플리케이션, 외부 데이터 소스를 포함한 수 많은 소스들로 구성되며 데이터는 이들 소스로부터 추출되어 변환 및 표준화 과정을 거쳐 데이터웨어하우스로 적재 된다.
- 데이터 웨어하우스 계층
데이터웨어하우스 계층은 의사결정을 지원하기 위해 주제 중심적, 통합적, 시계열적 데이터의 집합으로써 사용자의 요구에 따라서 대량의 데이터가 축적된 인프라를 만들어 놓고 실제 활용은 최종 사용자에게 맡기는 계층이다.
- 클라이언트 계층
사용자들이 정보를 엑세스하고 분석할 수 있는 수단으로 데이터웨어하우스에 대한 별도의 지식이 없이도 통합된 데이터의 결과치를 볼 수 있도록 한 계층이다.
데이터웨어하우스 내부 주요 활동
- 데이터 추출 및 적재
운영 DB, 파일형태의 데이터, 외부 자료 등으로부터 데이터를 추출하여 운영데이터 저장소로 적재하는 작업으로 메타 데이터의 정보를 참조하는 작업이 포함된다.
- 데이터웨어하우스 모델링
데이터 모델링은 분석과 설계의 두 단계를 거친다.
분석 단계에서는 업무 규칙 및 요구사항을 도출하여 적용하고 설계단계에서는 실제 구현작업을 한다. 두 단계를 거치며 생성되는 산출물은 개념적, 논리적, 물리적 모델이다.
데이터는 업무 중심이 아니라 분석을 요구하는 중요 주제별로 정리된다.
여러 다양한 소스로부터 데이터들을 통합한다.
데이터 모델링의 최우선 고려 사항은 빠른 검색 속도이다.
( 중복 데이터가 많이 발생하여 비정규화된 모델이 생성된다. )
공식 및 계산 적용을 위한 파생데이터 항목이 많이 생성된다.
시간을 키의 일부로 갖는다.
데이터웨어하우스 조회
데이터웨어하우스는 중앙 집중화된 데이터 저장고(repository)이다.
이곳에는 임시저장소(ODS : Operational Data Store)와 여러 측면의 분석을 필요로 하는 데이터가 다차원적 모델링으로 구성되어 있는 사실 테이블(Fact Table), 차원 테이블(Dimension Table), 요약 테이블(Summary Table), 메타 데이터(Meta Data)가 들어 있다.
이러한 자료를 여러 차원의 분석을 전문적으로 해줄 수 있는 OLAP도구를 사용하거나 일반 4GL로 작성한 프로그램 또는 SQL 문장으로 액세스 한다.
위의 사항 중 [데이터웨어하우스 모델링] 부분이 바로 BSD(Business System Design) 단계의 시작이라고 할 수 있겠다.
관계형모델
- 거래명세표 상의 데이터의 특성(속성유형별) 분류
업무 분석시에, 관련되는 자료만 가지고 데이터의 특성에 따른 즉 '데이터 중심 분석'에 의해 데이터베이스에 저장되는 자료의 기본 단위가 되는 실체(설계단계에서는 테이블로 전환)를 정의할 필요가 있다.
영업이나 구매 등의 업무에서 사용되는 거래명세표라는 자료를 가지고 생각을 해 볼 때,거래명세표를 구성하는 데이터(속성 : Attribute)들은 자연에 실제로 존재하는 기초 속성과, 원래 존재하지 않지만 필요에 따라 설계자가 만든 데이터인 설계 속성, 다른 데이터로부터 계산 등의 가공 처리를 통해 만들어진 데이터인 추출 속성으로 나누어진다.
데이터를 이렇게 분류하는 이유는 관계형 데이터베이스는 원칙적으로 기초 속성과 설계 속성만을 데이터베이스에 저장하고 추출 속성은 저장하지 않아도 되기 때문이며,또한 기초 속성은 대개가 실체(Entity)의 대상이 되며 설계 속성은 실체의 주식별자(Primary Key)가 되는 수가 많습니다.
따라서 양식이나 장부 등을 분석할 때는 그들을 구성하는 데이터의 특성을 분류하는 것이 매우 중요하게 됩니다.
- 거래명세표 상의 데이터의 특성(실체자격기준) 분류
거래명세표에서 실체를 정의시 우선적으로 분석되는 데이터가 실체의 자격에 적합한지를 선택할 필요가 있다. 실체의 자격으로는
첫째, 유일한 식별자가 되는 속성이 존재하는가이다. 실무적으로는 실체의 이름 뒤에 'XX번호, XX코드'를 넣어서 어색하지 않으면 첫째의 조건을 만족하는 것으로 가정한다.
둘째, 유일한 식별자(Unique Key) 외에 5~6개 이상의 속성들이 있어야 이 조건을 만족한다는 것이다.
마지막으로, 사용자가 해당실체를 데이터베이스에 저장하여 입력, 수정, 삭제, 조회 등의 관리를 할 필요성이 있는가 하는 문제이다.
실무적으로는 실체는 그것의 인스턴스(Instance)가 다량으로 존재해야만 비교적 가능하기 때문이다.
하지만, 업무 상황과 사용자 또는 개발자의 판단에 따라 첫째 둘째의 조건을 만족하더라도 실체로 인정되지 않는 경우도 또한 많이 발생하는 것이 현실이다.