1. 전체를 볼 수 있다면 진리에 가까워지고 있는 것이다.

왜 이책이 필요한가?
- 템플릿 또는 일반 데이터 모델을 사용하고 다양한 기업에 맞게 수정한 다수의 경험을 기반으로 우리는 다음의 결론을 내렸다.
- 보통 50% 이상의 데이터 모델이 대다수 조직에 적용할 수 있는 공통 구조로 이루어져 있으며,
- 다른 25%의 모델은 산업에 특화돼 있고, 평균적으로 약 25%의 모델이 해당 조직에 특화돼 있다는 사실이다.
- 이것은 대부분의 데이터 모델링 노력이 다른 조직에서 이미 여러 번 설계된 모델 구조를 재현하는 것이라는 의미다.
- 많은 책들이 모델을 어떻게 설계해야 하는 지를 설명하지만 예제 모델은 매우 적다.
- 이 책은 모델링을 잘 시작할 수 있도록 적합한 모델을 제공한다.
- 이는 모델러가 최소한의 노력으로 더 효과적이고 통합된 데이터베이스 디자인을 개발하도록 도울 것이다.

이 책을 읽으면 도움이 될 사람은 누구인가?
- 이 책은 다양한 종류의 시스템을 개발하는 많은 전문가, 즉 데이터 관리자, 데이터 모델러, 데이터 분석가, 데이터베이스 설계자, 데이터 웨어하우스 관리자, 데이터 웨어하우스 설계자, 데이터 담당자, 그리고 데이터 구조를 분석하거나 통합하는 사람들 모두에게 도움이된다.
- 시스템 전문가는 생산성을 높이고 모델 품질을 체크하기 위해 이 책에 있는 데이터베이스 구조를 사용할 수 있다.

참조 데이터 모델의 필요성
- 데이터 모델링의 개념은 1976년에 피터 첸의 논문인 "실체-관계 모델링"에서 새롭게 발견한 방법으로 처음 등장했다. 그 후로 데이터 모델링은 데이터베이스를 설계하는 데 사용하는 표준 방법이 됐다.
- 조직의 데이터를 올바르게 모델링 함으로써 데이터베이스 설계자는 부정확한 정보와 비효율적인 시스템의 주 원인인 중복 데이터를 제거할 수 있다.
- 최근에 데이터 모델링은 널리 알려져 있고 효과적인 데이터베이스를 설계하는 데 적합한 방법으로 받아들여진다.
- 기업에 표준 템플릿을 제공하여 백지 상태에서 급하게 설계하지 않고 템플릿을 사용해서 정제하고 수정하면서 설계할 수 있도록 하는 활동이 반드시 필요하다.
- 비록 많은 표본 모델이 존재하긴 하지만 데이터 모델링을 한 단계 더 나아가게 할 필요성이 있으며, 그 단계는 공통 데이터 모델 예제가 있는 라이브러리에 편하게 접근해서 사용하도록 하는 것이다. 서로 많은 다른 조직과 산업은 이 데이터 모델 라이브러리를 사용할 수 있어야 한다. 이런 참조 데이터 모델은 시스템 개발 과정에서 사용되는 막대한 시간과 비용을 절감할 수 있도록 해준다.

시스템 개발의 전체론적 접근법
- 효과적인 시스템을 구축하기 위한 가장 훌륭한 도전 중 하나는 통합이다.
- 시스템은 필요할 때마다 개별적으로 구축되곤 한다.
  - 시스템이 개별적으로 구축될 때는 정보 저장소가 각 시스템에 생성된다.
  - 이 중 많은 시스템은 조직, 사람, 장소, 상품과 같은 공통 정보를 사용할 것이다.
  - 이는 시스템이 개별적으로 정보원천을 구축해서 각자 사용한다는 것을 의미한다.
  - 큰 조직에서 고객, 사원, 조직, 상품, 위치 정보가 십여 개의 분리된 시스템에 저장돼 있는 것을 보는 일은 어렵지 않다.
  - 그러면, 어떤 정보가 최신 정보며 가장 정확한 정보인지 어떻게 알 수 있겠는가?
- 통합되지 않은 데이터 구조 시스템 운영의 또 다른 문제점은 기업이 통합된 정보를 조회할 때 일관된 정보를 볼 수 없다는 것이다.
  - 개인과 조직, 상품과 재고에 대한 완전한 정보를 조회할 수 있다는 것은 대단한 장점이다.
  - 어떤 조직이라도 타 부서가 무엇을 하는지 알 수 있고, 조직의 대고객 부서, 판매 부서, 구매 부서, 회계 부서가 사람, 조직, 상품에 대한 정보를 어디에 통합했는지 알 수 있도록 구축된 시스템을 상상해 보라.
  - 통합 시스템은 서비스와 판매는 물론, 기업의 생산성에 커다란 차이를 가져다 줄 것이다.
- 시스템 개발의 또 다른 접근 방법은 개별 시스템을 서로 연결해서 사실상 하나의 연결 시스템에서 볼 수 있도록 하는 것이다.
  - 시스템에 효과적으로 작동할 수 있도록 전사적 프레임워크를 구축하는 것은 대단히 유용하다.
  - 이 프레임워크에는 기업의 가장 가치 있는 자산 중 하나인 정보를 관리. 지원할 수 있는 전사 데이터 모델을 포함해야 한다.
  - 각 시스템이나 응용 프로그램은 사람, 조직, 상품, 위치에 대한 유사한 정보를 사용하기 때문에 공유 정보 아키텍처는 매우 유용하다.
- IS(정보 시스템) 산업은 통합된 디자인이 필요하고, 많은 기업 데이터 모델링과 기업 데이터 웨어하우스 모델링의 필요성을 인지하고 있다.
  - 불행하게도 IS 산업이 기업 데이터 모델을 구축하고 운영한 실적은 매우 부족하다.
  - 기업들은 데이터 모델을 구축하기 위해서는 매우 많은 시간과 자원이 소요된다는 것을 깨닫고 있다.
- 좋은 품질의 정확한 정보를 제공하기 위해서는 통합된 데이터 구조를 구축하는 것이 답이다.
  - 이렇게 할 수 있는 유일하고 효과적인 방법은 기업 내에 있는 데이터와 그 데이터 간 관계가 어떻게 어울리는지를 이해하고 데이터를 전체적인 통합 관점에서 보는 것이다.
  - 효과적인 시스템을 구축하기 위해서 데이터의 본질을 이해하는 것은 필수다.
  - IS 산업은 시간이 오래 걸린다는 이유로 기업 데이터 모델링이나 CASE 도구가 잘못된 방법이라고 말해선 안된다.
  - 더 효과적으로 일할 수 있는 길을 찾아야 한다.
  - 공통적이며 재사용이 가능한 데이터 구조를 구축함으로써 IS 산업은 빠른 결과를 낼 수 있고 트랜잭션 처리와 데이터 웨어하우스 환경 모두에서 통합된 구조로 나아갈 수 있다.

이 책에 사용된 표기법과 표준
- 이 책에 사용된 모델에서 볼 수 있는 명명 표준과 작도법을 설명한다.
- 엔터티, 서브타입, 속성, 관계, 외래 키, 물리 모델, 사례 테이블에 대해서 자세하게 알아본다.

엔터티
- 엔터티는 기업이 정보를 저장하려고 하는 어떤 중요한 곳이다.
  - 예를 들어, ORDER(주문) 엔터니는 상품을 구매하는 관계자 간의 행위 정보를 저장하는 엔터티를 나타낸다.
  - 개념과 업무 규칙을 묘사하기 위해서 엔터티의 이름이 문장에 사용될 때는 일반 텍스트처럼 쓴다.
  - 예를 들어, '많은 기업은 판매 주문 정보를 저장하기 위해서 판매 주문 양식과 같은 방법을 보유하고 있다.' 와 같다.
- 엔터티에 대한 명명법은 운영되는 정보를 반영한 가능한 의미 있는 단수 명사를 사용하는 것이다.
  - 추가로, 만약 ORDER(주문) 엔터티와 같이 실제로 발생한 특정 인스턴스를 나타내는 게 아니라 ORDER TYPE(주문유형) 엔터티와 같이 정보의 분류를 나타낸다면 접미어 "TYPE"를 엔터티 명에 추가한다.
- 이 책에서는 id(아이디)와 description(설명)만이 있는 엔터티라도 ERD에 TYPE 엔터티로 포함시킨다.
  - 이런 엔터티들은 완전한 모델을 위해서 추가되고, 허용 값이 어디에 저장돼 있는 지를 보여주기 위해서 포함된다.
  - 예를 들어, 기업이 배송 추적에 관심이 없다면 데이터 모델에 이 정보는 포함되지 않아야 한다.
  - 왜나하면, 그것은 기업이 관리할 정도로 중요한 정보가 아니기 때문이다.
  - 엔터티는 둥근 박스로 표현된다. 그림 1.1.은 ORDER(주문) 엔터티를 보여준다.

슈퍼타입과 서브타입
- 간혹 서브 엔터티로 언급되기도 하는 서브타입은 일반적인 엔터티와 마찬가지로 속성이나 관계를 가지고 있는 엔터티의 종류이다.
  - 예를 들어, LEGAL ORGANIZATION(법인조직)과 INFORMALORGANIZATION(비공식조직)은 ORGANIZATION(조직)의 서브타입이다.
- 서브타입의 공통 속성과 공통 관계는 슈퍼타입인 바깥 엔터티에 나타난다.
  - 슈퍼타입의 속성과 관계는 서브타입으로 상속된다.
  - 그림 1.2는 슈퍼타입인 ORGANIZATION(조직)과 서브타입인 LEGAL ORGANIZATION(법인조직), INFORMALORGANIZATION(비공식조직)을 보여준다.
  - 서브타입은 ERD에서 엔터티 안에 표현된다.
  - Name(이름) 속성은 슈퍼타입인 ORGANIZATION(조직)에 적용됐고, Federal Tax ID(연방세ID) 속성은 서브타입인 LEGAL ORGANIZATION(법인조직)에만 적용됐다는 것을 주목하라.
  - 이 속성은해당 서브타입에 적용되기 때문에 LEGAL ORGANIZATION(법인조직) 서브타입에만 보인다.
  - LEGAL ORGANIZATION(법인조직)과 INFORMALORGANIZATION(비공식조직) 서브타입은 슈퍼타입의 속성을 상속하기 때문에 모두 name(이름) 속성을 가진다.

슈퍼타입의 단계는 여러 개가 될 수 있다.
- 그림 1.2에서 Corporation(기업)과 Goverment Agency(정부기관)는 Organization(조직) 서브타입에 속해 있는 Legal Organization(법인조직)의 서브타입이라는 것을 나타낸다.
- 어떤 서브타입이 부모 슈퍼타입의 속성과 관계를 상속하는지를 묘사하기 위해 상자 안에 상자를 그려서 단계를 나타낼 수 있다.
- 한 엔터티 내에 있는 서브타입 분류는 완전한 집합이어야 한다.
  - 즉, 서브타입의 합은 슈퍼타입이어야 한다.
  - 그리고, 동시에 상호 배타적이어야 한다.
  - 많은 경우에 데이터 모델에 Other(기타) 서브타입을 포함시킨다.
  - 이는 기업이 정의해서 사용할 엔터티에 다른 유형의 서브타입이 생길 것을 대비하기 위해서이다.
    - 예를 들어, Informal Organization(비공식조직)은 Team이나 Family, 또는 Other Informal Organization(기타 비공식조직) 일 수 있다.
- 서브타입이 발생 가능한 유형의 완전한 집합을 나타내는 반면에 데이터 모델에 포함되지 않는 더 상세화된 서브타입이 있을 수 있는데, 이는 TYPE(유형) 엔터티에 포함시킬 수 있다.
- 이 경우 서브타입은 모델에서 두 가지 형태로 나타난다. 즉 서브타입 자체로 나타나고, 엔터티에 허용된 타입의 영역을 보여주는 TYPE(유형) 엔터티로 나타난다.

상호 배타적이지 않은 서브타입 집합
- 간혹, 서브타입은 서로 배타적이지 않다.
  - 다시말해서, 슈퍼타입이 다른 방식으로 분류될 수 있고, 하나 이상의 서브타입 집합이 같은 슈퍼타입에 적용될 수 있다.
  - Requirement(요구사항) 슈퍼타입이 다른 방식의 서브타입으로 설계된 그림 1.3을 보라.
  - Requirement(요구사항)는 고객에게서 나온 Customer Requirement(고객요구사항)일 수 있고 기업 내부의 요구사항인 Internal Requirement(사내요구사항)일 수도 있다.
  - 동시에, Requirement(요구사항)는 특정 상품에 대한 요구사항인 Product Requirement(상품요구사항)일 수 있고,
  - 수행된 업무에 대한 요구사항인 Work Requirement(업무요구사항)일 수 있다.
- 따라서, 두 개 이상의 서브타입이 Requirement(요구사항)에 인스턴스를 생성할 수 있다.
  - 예를 들어, Customer Requirement(고객요구사항)와 Product Requirement(상품요구사항)에 인스턴스를 생성할 수 있다.
  - 그림 1.3은 서브타입에 이름이 없는 상자를 사용해서 상호 배타적이지 않은 서브타입임을 나타낸다.
  - 이런 상자는 슈퍼타입에 대해 하나 이상의 서브타입 집합이 있을 때 사용한다.

속성
- 속성은 주문에 대한 주문일과 같은 특정 정보를 담는다.
- 이 책에서 속성을 나타낼 때는 order date(주문일자)와 같이 소문자 굵은 글씨로 표시한다.
- 엔터티의 주 키로 알려진 식별자도 속성의 일부다.
  - ERD에서 주 키 속성의 속성 명 앞에는 "#" 표시를 하여 식별한다.
  - 필수 속성은 속성 명 앞에 "*" 표시를 해서 구분한다.
  - 선택 속성은 속성 명 앞에 "ㅇ" 표시를 한다.
- 그림 1.4 ORDER(주문) 엔터티
  - 주 키 속성은 order ID(주문ID) 속성이며,
  - 필수 속성은 order date (주문일자) 속성,
  - 선택 속성은 entry date (입력일자) 속성이다.

관계
- 관계는 두 개의 엔터티가 서로 어떻게 연관돼 있는지를 나타낸다.
- 관계가 설명에 사용될 때는 일반 소문자를 사용한다.
- 어떤 경우에 특별히 강조하고 싶은 때는 굵은 소문자를 사용한다.
  - 예를 들어, 'manufactured by'는 이 책의 내용에서 관계를 의미할 수 있다.
- 관계존재성
  - 관계존재성은 '선택'이거나 '필수'이다.
  - 엔터티 옆에 점선으로 된 관계선은 그 엔터티로부터의 관계가 선택이라는 것을 의미한다.
  - 실선으로 된 관계는 그 엔터티의 모든 인스턴스에 관계가 존재해야 하는 필수관계를 의미한다.
  - 그림 1.5의 관계는
    - Shipment(배송) 엔터티의 모든 인스턴스는 반드시 하나의 Postal Address(우편주소)를 가져야 하는 관계를 나타낸다.
    - 이는 배송 데이터를 생성하기 위해서는 배송에 대한 우편주소가 반드시 필요하다는 것을 의미한다.
    - 이 관계를 반대 방향에서 읽을 때는 선택이 된다.
    - 즉, 어떤 Postal Address(우편주소)는 배송과 연결되지 않을 수 있다.
    - 이는 배송에 사용되지 않은 우편 주소가 존재할 수 있다는 것이다.

관계
- 관계비
  - 관계는 1:1, 1:M, M:N 관계가 있다.
  - 이를 일반적으로 관계비라고 한다.
  - 까마귀 발처럼 세 개의 선으로 갈라진 새발 표시가 보이면 한 인스턴스가 다른 엔터티의 하나 이상의 인스턴스를 가리킨다는 것을 나타낸다.
  - 그림 1.6은
    - 새발 표시가 Order Item(주문품목) 엔터티 쪽에 있기 때문에 '각 Order(주문)가 하나 이상의 Order Item(주문품목)으로 구성됐다.'는 것을 나타낸다.
    - 반대방향의 관계는 '각 Order Item(주문품목)은 하나 이상의 Order(주문) 에만 포함돼야 한다.'는 것을 나타낸다.
    - 1:1 관계는 새발 표시가 없으며, M:N 관계는 관계 양쪽에 새발 표시가 있다.
    - 가끔, 1:M 관계는 부모-자식 관계로 언급된다.
  - 간혹 '언젠가는'이라는 단어가 1:M 관계를 확인하기 위해 관계 문장에 추가된다.
    - 예를 들어, Order(주문)는 단지 하나의 Order Status(주문상태)만 가질지 모른다.
    - 그러나, 만약 상태 이력이 필요하면 Order(주문)는 언젠가는 하나 이상의 상태를 가질지 모른다.
  - 이 책에 사용된 데이터 모델 중에서, 1:1 관계는 소수다.
  - 이는 주로 1:1 관계가 정규화되면 단일 엔터티로 합져질 수 있기 때문이다.
  - M:N 관계는 매번 교차 엔터티로 해소되기 때문에 ERD에 M:N 관계가 나타나지 않는다.

관계
- 외래 키 관계
  - 외래 키는 엔터티 내에 있는 다른 엔터티의 주 키로 정의된다.
    - 예를 들어, 그림 1.6 Order(주문) 에서 내려온 order ID(주문ID) 속성이 Order Item(주문품목) 엔터티의 일부가 된다.
    - 따라서, order ID(주문ID) 속성은 외래 키다.
  - 1:M 관게는 관계비가 '1인 엔터티의 주 키가 관계비가 'M'인 엔터티로 내려온다.
  - 어떤 데이터 모델러는 이 외래 키를 엔터티의 속성으로 보여준다.
  - 이 책에서는 이런 표현이 중복이기 때문에 엔터티의 외래 키를 속성으로 보여주지 않는다.
  - 관계 자체는 외래키를 의미한다.
    - 그림 1.6 모델에서
    - order ID(주문ID) 속성은 Order Item(주문품목) 엔터티의 속성으로 보여지지 않는다.
    - 1:M 관계는 외래키가 있다는 것을 의미하기 때문이다.
- 외래 키 상속
  - 이 책에서 사용한, 상속한 외래 키가 자식 엔터티의 주 키 일부임을 나타내는 관계선의 작도법은 관계선에 '~' 표시를 하는 것이다.
  - 그림 1.6 관계에서 보이는 '~' 표시는 order ID(주문ID) 속성이 Order Item(주문품목) 엔터티의 주 식별자에 포함돼 있다는 것을 나타낸다.
  - 이 표기법에서는 '~'가 표시된 관계 쪽 엔터티의 주 키 뿐만 아니라 상위 엔터티의 주 키 속성이 합쳐져서 엔터티의 주 키가 됨을 나타낸다.
  - 따라서, Order Item(주문품목) 엔터티의 주 키는 order item seq ID(주문품목순번) 속성에 order (주문) 엔터티의 주 키인 order ID(주문ID) 속성을 더한 속성이다.
  - 이 표기법은 엔터티의 주 키를 문서화하기 위해 기호를 허용하는 것이며, 이는 다른 엔터티의 주 키에 외래 키 속성이 반복됨으로써 공간을 차지하는 것을 방지한다.
  - 또한, '#' 기호가 있는 속성 뿐만 아니라 주 키에 포함되는 관계를 명시해서 주 키의 의미를 나타낸다.

다대다 관계를 다루는 교차 엔터티
- 교차 엔터티는 연관 엔터티 또는 상호 참조 엔터티로도 알려져 있다.
- 교차 엔터티는 두 엔터티가 서로 참조하면서 M:N 관계를 해소하는 데 사용된다.
- 그리고, 종종 관계를 더 설명하는 별도 속성이 존재한다.
- 그림 1.7의
  - Party(관계자) 엔터티와 Contact Mechanism(연락매체) 엔터티는 서로 참조하는 M:N 관계임을 보여준다.
  - 관계자에게 연락할 수단은 많기 때문에 Party(관계자) 엔터티가 Postal Address(우편주소), Telecommunications Number(전화번호), Electronic Address(전자주소)와 같은 하나 이상의 Contact Mechanism(연락매체)과 연관된다.
  - 반면에 하나의 contact Mechanism(연락매체)은 하나 이상의 Party(관계자)에 의해서 사용될 수 있다.
    - 예를 들어, 많은 사람의 회사 주소나 사무실 전화번호가 같을 수 있다. 이런 M:N 관계는 Party Contact Mechanism(관계자연락매체) 엔터티 같은 교차 엔터티로 풀린다.
    - 양쪽 엔터티의 키는 교차 엔터티로 상속된다.
    - 따라서, 교차 엔터티가 양쪽 엔터티의 키를 상속한 것으로 나타내기 위해 교차 엔터티 관계에 '~' 기호가 항상 사용된다.
    - 예제에서 party id(관계자ID) 속성과 contact mechanism id(연락매체ID) 속성은 from date(시작일자) 속성과 함께 Party Contact Mechanism(관계자연락매체) 엔터티의 주 키의 일부다.
  - 모든 모델에서 관계의 양쪽에는 관계를 묘사하는 두 개의 관계 명이 존재한다. 관계 명은 아래와 같이 조합되어 완전한 문장으로 읽힐 수 있어야 한다.
  - '각 엔터티는 {하나/하나 또는 그 이상} 엔터티와 엔터티 관계 명{여야 한다/일 수 있다}'라는 문장으로 적절히 채워쳐야 한다.
  - ERD의 가독성을 높이는 일관된 방법으로써 관계비를 나타내는 새발 표시는 일반적으로 위측이나 좌측을 향하도록 한다.
  - 이렇게 하면 데이터 모델의 가독성이 더 좋아진다.

관계
- 배타 관계
  - 배타 관계는 한 엔터티가 두 개 이상의 다른 엔터티와 관계를 가진다는 것을 식별하기 위해서 사용하는데, 하나의 인스턴스에는 하나의 관계만이 존재할 수 있다.
  - 배타 관계는 두 개 이상의 관계선을 통과하는 휘어진 선으로 표현한다.
  - 그림 1.8은 배타 관계에 대한 예제다.
    - 배타 관계는 다음과 같이 읽힌다.
    - '각 Inventory Item(재고품)은 하나의 Facility(시설)이나 Container(컨테이너)에 위치해야 하고 둘 다에 위치하면 안된다.'
    - 이것은 재고품은 두 종류의 저장소 중에서 하나에만 저장돼야 한다는 것을 의미한다.
    - 재고품은 창고와 같은 시설에 위치할 수 있고 시설 내에 위치한 통과 같은 컨테이너에 저장될 수 있다.

관계
- 재귀 관계
  - 재귀 관계는 한 엔터티가 자신과 어떻게 연관되는 지를 나타내는 관계다.
    - 예를 들어, 재귀 관계는 한 엔터티가 자기 자신에 지정한 관계를 통해서나 M:N 관계를 통해서 설계될 수 있다.
    - 이것은 재귀 관계가 M:N 재귀 관계나 1:M 재귀 관계인지에 달려있다.
    - 한 엔터티에 여러개의 재귀 관계가 존재하는 것은 가능하다.
  - 그림 1.9 예제는
    - 재공정이 있을 수 있기 때문에, Work Effort(작업공정) 엔터티에 1:M 재귀 관계를 나타낸다.
    - 모델은 또한 작업 공정이 다른 공정에 속해있거나 여러 개의 하위 공정으로 분해될 수 있어서 교차 엔터티인 Work Effort Association(작업공정연계) 엔터티로 해소된 M:N 재귀 관계를 보여준다.