1. 반정규화를 통한 성능향상 전략

가.반정규화의 정의

• 반정규화는 정규화된 엔티티,속성,관계를 시스템의 성능향상 및 개발과 운영의 단순화를 위해 중복,통합,분리 등을 수행하는 데이터 모델링 기법이다.
• 디스크 I/O량이 많아서 조회시 성능이 저하되거나, 테이블끼리의 경로가 너무 멀어 조인으로 인한 성능저하가 예상되거나, 컬럼을 계산하여 읽을 때 성능이 저하될 것이 예상되는 경우 반정규화를 수행하게 된다.
• 업무적으로 조회에 대한 처리성능이 중요하다고 판단될때 부분적으로 반정규화를 고려하게 된다.
• 설계단계에서 반정규화를 적용하게 되며, 반정규화 미수행시에는 다음과 같은 현상이 발생된다.
  • 성능이 저하된 데이터베이스가 생성될 수 있다.
  • 구축단계나 시험단계에서 반정규화를 적용할 때 수정에 따른 노력비용이 많이 든다.

나.반정규화의 적용방법

• 반정규화에 대한 필요성이 결정되면 컬럼의 반정규화 뿐만 아니라, 테이블의 반정규화, 관계의 반정규화를 종합적으로 고려하여 적용해야 한다.
• 반정규화는 막연하게 중복을 유도하는 것만을 수행하기 보다는 성능을 향상시킬 수 있는 다른방법을 고려하고 그 이후에 반정규화를 적용하도록 해야 한다.

• 반정규화의 대상을 조사한다.
  • 자주 사용되는 테이블에 액세스하는 프로세스의 수가 가장 많고, 항상 일정한 범위만을 조회하는 경우에 반정규화를 검토한다.
  • 테이블에 대량데이터가 있고 대량의 범위를 자주 처리하는 경우, 성능을 보장할 수 없는 경우에 반정규화를 검토한다.
  • 통계성 프로세스에 의해 통계정보를 필요로 할 때, 별도의 통계테이블(반정규화)를 생성한다.
  • 테이블에 지나치게 조인을 많이 하게 되어, 데이터를 조회하는 것이 기술적으로 어려울 경우 반정규화를 검토한다.

• 반정규화의 대상에 대해 다른 방법으로 처리할 수 있는지 검토한다.
  • 테이블에 많은 조인하여 데이터를 조회하는 것이 기술적으로 어려운 경우 VIew를 검토한다. 조회성능을 향상 시키지는 않지만, SQL작성의 미숙함으로 인하여 생기는 성능저하를 예방할 수 있다.
  • 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우 클러스터링을 적용하거나, 인덱스 조정을 통해 성능을 향상 시킬수 있다.
  • 대량의 데이터는 PK의 성격에 따라 파티셔닝 기법을 적용하여 성능저하를 방지할 수 있다.
  • 어플리케이션에서 로직을 구현하는 방법을 변경하므로써 성능을 향상 시킬수 있다.

• 반정규화를 적용한다.
  • 반정규화 대상으로는 테이블, 속성, 관계에 대해 적용할 수 있으며, 중복을 통한 방법만이 반정규화가 아니고, 테이블,속성,관계를 추가/분할/제거할 수도 있다.

2. 반정규화의 기법

가.테이블 반정규화

나.컬럼 반정규화

다.관계 반정규화

테이블, 컬럼의 반정규화는 데이터 무결성에 영향을 미치나, 관계의 반정규화는 데이터 무결성을 깨뜨리지 않고도 성능을 향상시킬 수 있는 반정규화의 기법이다.

3. 정규화가 잘 정의된 데이터 모델에서 성능이 저하될 수 있는 경우

전화번호,메일주소,위치정보가 이력형태로 관리되는 데이터모델

• 공급자정보를 가져올 때, 최근의 전화번호/메일/위치정보를 가져오기 위해서는 복잡한 조인을 거쳐야 함.
• 공급자 테이블에 최근 변경된 전화번호,메일주소,위치컬럼을 반정규화하면 간단하게 정보를 조회할 수 있음

4. 정규화가 잘 정의된 데이터 모델에서 성능이 저하된 경우

분산환경에서 타서버의 테이블에서 정보를 가져올때

• 서버B에서 데이터를 조회할 때, 항상 부서명을 가져오기 위해서 서버A를 거쳐야 하므로 성능저하가 발생한다.
• 부서명을 서버B의 연계테이블에 반정규화함으로 써 성능을 개선 시킬 수 있다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743790&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

1. 성능 데이터 모델링의 정의

성능 데이터 모델링 데이터베이스 성능향상을 목적으로 설계단계의 데이터 모델링 때 부터 정규화, 반정규화, 테이블통합, 테이블분할, 조인구조, PK, FK등 여러가지 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것이다.

2. 성능 데이터 모델링 수행시점

성능 데이터 모델링은 언제하면 좋은가?

• 사전에 할 수록 비용이 들지 않는다.
• 분석/설계단계에서 성능을 고려한 데이터 모델링을 수행하면, 나중에 성능저하때문에 발생하는 재업무(Rework)비용을 최소화할 수 있다.

비즈니스 처리에 핵심적인 트랜잭션이 있다면, 프로젝트 초기에 운영환경에 대비한 테스트환경을 구축하고 트랜잭션을 발생시켜 실제 성능테스트를 해보아야 한다.
데이터 모델의 구조도 변경하면서, 가장 적절한 구조인지를 검토하여 디자인하는 전략이 요구된다.

3. 성능 데이터 모델링 고려사항

일반적으로 성능 데이터 모델은 다음과 같은 프로세스로 진행하는 것이 데이터 모델링 단계에서 성능을 충분히 고려할 수 있는 방안이 된다.

1) 데이터 모델링을 할 때 정규화를 정확하게 수행한다.
2) 데이터베이스 용량산정을 수행한다.
3) 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.
4) 용량과 트랜잭션 유형에 따라 반정규화를 수행한다.
5) 이력모델의 조정, PK/FK조정, 슈퍼타입/서브타입 조정 등을 수행한다.
6) 성능관점에서 데이터 모델을 검증한다.

=> 데이터모델을 검토할 때는 일반적인 데이터 모델규칙만 검증하지 말고, 충분하게 성능이 고려되었는지도 체크리스트에 포함하여 검증하도록 한다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743520&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제5절 식별자

1. 식별자의 개념

• Entity 내에서 Instance 들을 구분할 수 있는 구분자

2. 식별자의 특징

3. 식별자 분류 및 표기법

가. 식별자 분류

나. 식별자 표기법

4. 주식별자 도출 기준

• 해당 업무에서 자주 이용되는 속성을 주식별자로 지정하도록 함
  
• 명칭, 내역 등과 같이 이름으로 기술되는 것은 피함
  
• 속성의 수가 많아지지 않도록 함
  
  

5. 식별자관계와 비식별자관계에 따른 식별자

가. 식별자관계와 비식별자관계의 결정

• 부모 자식간의 관계에 의해 외부식별자가 생성된다.
• 이때 부모로부터 받은 외부식별자를
  자신의 주식별자로 이용할 것인지? --> 식별자관계 
  부모와 연결이 되는 속성으로만 이용할 것인지? --> 비식별자관계
  결정해야 한다.

나. 식별자관계

다. 비식별자관계

라. 식별자관계로만 설정할 경우 문제점

마. 비식별자관계로만 설정할 경우 문제점

바. 식별자관계와 비식별자관계 모델링

1) 비식별관계 선택 프로세스

2) 식별자와 비식별자관계 비교

3) 식별자와 비식별자를 적용한 데이터 모델

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743477&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제4절 관계(Relationship)

1. 관계의 개념

가. 관계의 정의

• 인스턴스 사이의 논리적 연관성으로서 존재 또는 행위로서 서로에게 연관성이 부여된 상태

나. 관계의 페어링(Relationship Paring)

• Relationship 은 Entity 안의 Instance 가 개별적으로 관계를 가지는 것(Paring)이고 이것의 집합을 관계로 표현한다는 것이다.
  따라서 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 Entity 사이에 2개 이상의 관계가 형성 될 수 있다.

2. 관계의 분류

3. 관계의 표기법

가. 관계명(Membership) : 관계의 이름

나. 관계차수(Degree / Cardinality) : 1:1, 1:M, M:N

다. 관계선택사양(Optionality) : 필수관계, 선택관계

4. 관계의 정의 및 읽는 방법

가. 관계 체크사항

• 두개의 Entity 사이에 관심있는 연관규칙이 존재하는가?
• 두개의 Entity 사이에 정보조합이 발생되는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

나. 관계 읽기

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743462&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제3절 속성(Attribute)

1. 속성(Attribute)의 개념

• 속성(Attribute) 의 사전적 의미
  • 사물의 성질, 특징, 또는 본질적인 성질, 그것이 없다면 실체를 생각할 수 없는 것
  • 본질적 송석이란 어떤 사물 또는 개념에 없어서는 안될 징표의 전부이다.
  • 징표는 사물이나 개념이 어떤것인지를 나타내고 그것을 다른 것과 구별하는 성질
• 데이터 모델링 관점에서 속성(Attribute) 의 정의
  • 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더이상 분리되지 않는 최소의 데이터 단위
  • 엄무상 관리하기 위한 최소의 의미 단위
  • 속성은 엔터티를 성명하고
  • 속성은 인스턴스의 구성요소
• 예시
  • 생년월일은 그 자체로 의미가 있으므로 속성이라 할 수 있다.
    생년, 생월, 생일 로 분리가 가능하지만 이는 하나의 속성을 관리목적으로 분리한 것일 뿐 각각을 속성이라 할수는 없다.
  • 이름과 주소는 각각 의미있는 속성이지만 '이름주소'로 묶는다면?
    하나의 속성이 두가지 의미를 가지므로 기본 속성이라 할 수 없다.
    차라리 '이름주소'가 아닌 '인적사항'정도로 관리한다면 속성으로 볼수도 있다.

2. 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

가. 엔터티, 인스턴스, 속성, 속성값의 관계

나. 속성의 표기법

3. 속성의 특징

• Entity 와 마찬가지로 해당 업무에서 필요하고 관리하고자 하는 정보
• 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
• 하나의 속성은 하나의 값만 가진다.
  하나의 속성에 여러개의 값이 있는 경우, 별도의 Entity 를 이용하여 분리한다.

4. 속성의 분류

가. 속성의 특성에 따른 분류

• 1) 기본속성 : 업무로부터 추출한 모든 속성
• 2) 설계속성 : 코드성 데이터, Entity 식별용 일련번호
• 3) 파생속성 : 다른 속성에 영향을 받아 발생하는 속성, 계산된 값, 합계, 재고, 잔액
  • 파생속성은 그속성이 가지고 있는 계산방법에 대해 반드시 어떤 엔터티에 어떤 속성에 의 해 영향을 받는지 정의가 되어야 한다.
  • 타 속성에 의해 지속적으로 영향을 받아 자신의 값이 변하는 성질을 가지고 있는 속성
  • 파생속성은 꼭 필요한 경우에만 정의하여 업무로직이 속성내부로 스며들지 못하도록 주의해야 한다.
  • 파생속성을 정의한 경우라면 그 값의 정합성을 유지할 수 있도록 해야 한다.
  • 통계관련 엔터티, 배치작업 수행 관련

나. 엔터티 구성방식에 따른 분류

5. 도메인(Domain)

• 속성이 가질 수 있는 값의 범위

6. 속성의 명명(Naming)

• 용어사전 : 속성 이름을 정확하게 부여하고, 용어의 혼란을 없애기 위함
• 도메인정의 : 각 속성이 가지는 값의 범위를 명확하게 하기 위해
• 속성명 부여 원칙
  • 1. 해당 업무에서 사용하는 이름을 부여한다.
  • 2. 서술식 속성명은 사용하지 않는다.
  • 3 약어사용은 가급적 제한한다.
  • 4. 전체 데이터 모델에서 유일성 확보하는 것이 좋다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743420&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제2절 엔터티(Entity)

1. Entity 의 개념

• Entity : 실체, 객체

• 옛날 할부지들이 정의한 Entity
  • 변별할수 있는 사물 - Peter Chen (1976) -
  • 데이터베이스 내에서 변별 가능한 객체 - C.J Date (1986) -
  • 정보를 저장할 수 있는 어떤 것 - James Martin (1989) -
  • 정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등 - Thomas Bruce (1992) -

• 위 정의들의 공통점
  • 엔터티는 사람, 장소, 물건, 사건, 개념등의 명사에 해당한다.
  • 엔터티는 엄무상 관리가 필요한 관심사에 해당한다.
  • 엔터티는 저장이 되기 위한 어떤 것이다.

2. Entity 와 Instance 에 대한 내용과 표기법

• Entity(객체), Instance(사례, 경우)
• Entity 는 Instance 의 집합

3. Entity 의 특징

가. 업무에서 필요로 하는 정보

• 반드시 해당 업무에서 필요하고, 관리하고자 하는 정보이어야 한다.

  병원시스템	Entity	인사시스템
  O	환자	X
  X	토익점수	O

나. 식별이 가능해야 함

• 유일한 식별자에 의해 식별이 가능해야 한다.

다. Instance 의 집합

• 영속적으로 존재하는 Instance 의 집합
• 2개 이상의 Instance 의 집합
• 1개의 Instance 로 이루어진 _집합_은 Entity 가 아니다.

라. 업무 프로세스에 의해 이용

• 업무 프로세스가 반드시 그 Entity 를 이용해야 한다.

마. 속성을 포함

• Entity 에는 반드시 속성(Attributes)이 포함되어야 한다.
• 식별자만 존재하고 일반 속성이 전혀 없는 객체는 Entity 가 될 수 없다.
  단, 관계 Entity 의 경우엔 주 식별자 속성만으로도 Entity 로 인정

바. 관계의 존재

• Entity 는 다른 Entity 와 최소 한개 이상의 관계가 존재하여야 한다.
• 데이터모델링에서 관계를 생략하여 표현하는 경우
  • 1) 통계를 위한 데이터 : 통계만을 위한 Read Only Table
  • 2) 코드성 Entity
    • 너무 많은 Entity 들과의 관계로 데이터 모델이 복잡해짐
    • 일반적으로 코드 테이블에 FK 를 설정하지 않는 경우가 대부분이다.
  • 3) 시스템 처리시 내부적으로 필요한 Entity : 로그 테이블

4. Entity 의 분류

가. 유무(有無)형에 따른 분류

나. 발생시점(發生時點)에 따른 분류

다. Entity 분류 방법의 예

5. Entity 의 명명

• 가능하면 현업업무에서 사용하는 용어를 사용
• 가능하면 약어를 사용하지 않는다.
• 가능하면 단수명사를 사용한다.
• 모든 Entity 에서 유일하게 이름이 부여되어야 한다.
• Entity 생성의미대로 이름을 부여한다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743402&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제1절 데이터 모델의 이해

1. 모델링의 이해

가. 모델링의 정의

• 모델링에 대한 다양한 정의
  • Webster 사전
    • 가설적 일정 양식에 맞춘 표현
    • 어떤 것에 대한 예비표현으로, 그로부터 최종대상이 구축되도록 하는 계획으로서 기여하는 것
  • 복잡한 '현실세계'를 단순화시켜 표현하는 것
  • 모델이란 사물 또는 사건에 관한 양상(Aspect)이나 관점(Perspective)을 연관된 사람이나 그룹을 위하여 명확하게 하는 것이다.
  • 모델이란 현실 세계의 추상화된 반영이다.

나. 모델링의 특징

• 모델링의 재정의 : 현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법
• 정보시스템 구축에서의 모델링 활용
  • 계획/분석/설계 단계 : 업무를 분석하고 설계하는데 이용
  • 구축/운영 단계 : 변경과 관리의 목적으로 이용

다. 모델링의 세 가지 관점

2. 데이터 모델의 기본개념의 이해

가. 데이터 모델링의 정의

• 모델링에 대한 다양한 정의
  • 정보시스템을 구축하기 위해, 해당 업무에 어떤 데이터가 존재하는지 또는 업무가 필요로 하는 정보는 무엇인지를 분석하는 방법
  • 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 본재하는 업무 규칙(Business Rule)에 대하여 참(True) 또는 거짓(False)을 판별할 수 있는 사실(사실명제)을 데이터에 접근하는 방법(How), 사람(Who), 전산화는 별개(독립적인)의 관점에서 이를 명확하게 표현하는 추상화 기법

• 실무적 관점(정보시스템 구축)에서의 데이터 모델링을 하는 주요 이유
  • 정보시스템 구축 대상이 되는 업무 내용을 정확하게 분석하는 것
  • 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것
  • 단지 데이터베이스 구축만이 목적이 아니라 데이터 모델링 자체로서 업무를 설명하고 분석하는 부분에도 중요한 의미를 가지고 있음.

• 데이터 모델링이란
  • 정보시스템을 구축하기 위한 데이터 관점의 업무분석 기법
  • 현실세계의 데이터(Whet)에 대해 약속된 표기법에 의해 표현하는 과정
  • 데이터베이스를 구축하기 위한 분석/설계의 과정

나. 데이터 모델이 제공하는 기능

• 업무를 분석하는 관점에서 데이터 모델이 제공하는 기능
  • 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.
  • 시스템의 구조와 행동을 명세화 할 수 있게 한다.
  • 시스템을 구축하는 구조화된 틀을 제공한다.
  • 시스템을 구축하는 과정에서 결정한 것을 문서화한다.
  • 다양한 영역에 집중하기 위해 다른 영역의 세부사항은 숨기는 다양한 관점을 제공한다.
  • 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공한다.

3. 데이터 모델링의 중요성 및 유의점

가. 파급효과(Leverage)

• 시스템 구축이 완성되가는 시점에서의 데이터 모델 변경은 엄청난 파급효과를 발생시킨다.
• 데이터 구조변경에 따른 표준영향분석, 응용영향분석등 많은 영향 분석이 일어난다.
• 변경해야할 데이터 형태에 따른 영향도는 차이가 있겠지만, 
  구조 변경으로 인한 일련의 변경작업은 전체 시스템 구축 프로젝트에서 큰 위험요소이다.
• 따라서, 데이터 설계는 그만큼 중요하다.

나. 복잡한 정보 요구사항의 간결한 표현(Conciseness)

• 데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구이다.

다. 데이터 품질(Data Quality)

• 데이터는 중요한 자산이며, 기간이 오래될수록 활용가치는 더 커진다.
• 그러나, 데이터의 정확성이 떨어진다면? 데이터의 활용가치는 떨어지게 된다.
• 따라서 데이터 모델링을 할때는 다음을 유의하여 데이터 품질을 높여야 한다.
  • 중복(Duplication) : 동일 자료의 중복
  • 비유연성(Inflexibility) : 잘못된 데이터 모델은 사소한 업무변화에 대응하지 못하고 유지보수에 어려움이 따른다.
  • 비일관성(Inconsistency) : 데이터의 모순, 데이터간 상호 연관관계에 대한 정확한 정의로 이러한 위험을 예방

4. 데이터 모델링의 3단계 진행

가. 개념적 데이터 모델링(Conceptual Data Modeling)

나. 논리적 데이터 모델링(Logical Data Modeling)

다. 물리적 데이터 모델링(Physical Data Modeling)

5. 프로젝트 생명주기(Life Cycle)에서 데이터 모델링

6. 데이터 모델링에서 데이터독립성의 이해

가. 데이터독립성의 필요성

• 데이터 독립성 필요
  • 유지보수 비용 증가
  • 데이터 중복성 증가
  • 데이터 복잡도 증가
  • 요구사항 대응 저하

나. 데이터베이스 3단계 구조

다. 데이터독립성 요소

라. 두 영역의 데이터독립성

마. 사상(Mapping)

7. 데이터 모델링의 중요한 세 가지 개념

가. 데이터 모델링의 세 가지 요소

• 업무가 관여하는 어떤 것(Things)
• 어떤 것이 가지는 성격(Attributes)
• 업무가 관여하는 어떤것 간의 관계(Relationships)

나. 단수와 집합(복수)의 명령

8. 데이터 모델링의 이해관계자

가. 이해관계자의 데이터 모델링 중요성 인식

나. 데이터 모델링의 이해관계자

9. 데이터 모델링의 표기법인 ERD의 이해

가. 데이터 모델 표기법

나. ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법

1) ERD 작업순서

• 1. 엔터티를 그린다.
• 2. 엔터티를 적절하게 배치한다.
• 3. 엔터티간 관계를 설정한다.
• 4. 관계명을 기술한다.
• 5. 관계의 참여도를 기술한다.
• 6. 관계의 필수여부를 기술한다.

2) 엔터티 배치

• 좌에서 우로, 위에서 아래로
• 가장 중요한 고객과 주문을 좌측 상단에 배치
• 주문에 따른 출고 및 재고 를 주문의 아래에 차례로 배치
• 업무 흐름의 중심이 되는 엔터티(주문, 출고, 주문목록, 출고목록)를 중앙에 배치
• 중심 엔터티와 관계있는 엔터티(창고, 고객, 사원, 재고)를 주위에 배치

3) ERD 관계의 연결

• 서로 관련있는 엔터티간의 관계를 설정
• 초기에는 모두 PK 로 속성이 상속되는 식별자 관계를 설정
• 중복관계, Cycle 관계 등을 유의

4) ERD 관계명의 표시

• 관계이름은 현재형을 사용
• 지나치게 포괄적인 용어(예, 이다, 가진다 등)은 사용하지 않도록
• 실무에서는 생략해도 무방 - 관계명이 없어도 ERD의 흐름을 알 수 있다.

5) ERD 관계 관계차수와 선택성 표시

관계	선택성	IE 표기법	Barker 표기법
1 : 1	필수
1 : 1	선택
1 : n	필수
1 : n	선택

10. 좋은 데이터 모델의 요소

가. 완전성(Completeness)

• 업무에서 필요로 하는 모든 데이터가 모델에 정의되어 있어야 한다.

나. 중복배제(Non-Redundancy)

• 하나의 데이터베이스에 동일한 사실은 반드시 한번만 기록되어야 한다.
• 중복시 문제점
  • 저장공간의 낭비
  • 일관성 유지를 위한 추가 비용 발생

다. 업무규칙(Business Rules)

• 업무규칙(Business Rules)을 데이터 모델링에 표현하고, 모든 사용자가 공유한다.
• 모든 사용자(개발자, 관리자)가 해당 규칙에 대해 동일하게 판단하고 데이터를 조작할 수 있게 된다.
• 업무규칙이 명확하게 표현되지 않았다면
  • 각각의 사용자가 같은 업무를 다르게 판단 할 수 있다.

라. 데이터 재사용(Data Reusability)

• 통합성
  • 과거 시스템은 각각의 업무 영역별 데이터 별도 관리
  • 전사적 관점에서 공통데이터를 도출하고 이를 전 영역에서 사용하기 적절한 형태로 설계하여야 한다.
  • 이러한 통합 데이터 모델이어야 데이터 재사용성을 향상시킬 수 있다.

• 독립성
  • 과거 시스템은 데이터 모델이 별도로 없이 어플리케이션의 부속품 정도로 여겨졌다.
  • 이경우 데이터는 각각의 업무 프로세스에 종속적일수밖에 없고
  • 중복데이터 발생, 일관성 저하, 재사용성이 떨어지게 된다.
  • 따라서 데이터가 어플리케이션에 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다.

• 확장성, 유연성
  • 정보시스템은 비즈니스 변화에 대해 최적의 적응을 요구한다.
  • 비즈니스 변화에 유연하게 대처하고 확장이 용이한 데이터 설계가 필요하다
  • 확장성, 유연성이 떨어질 경우 작은 업무 변경에도 시스템 기반이 흔들리게 된다.

• 합리적 균형이 있으면서도 단순하게 분류하는 것
  • 예를 들면, 동일한 계약 업무를 수행하기 위한 테이블이 A보험사는 10개, B보험사는 100개라면?
  • A사의 데이터 모델은 단순하지만 새로운 업무환경 변화에 대해서 확장성을 가지고 있다.
  • B사는 업무환경 변화(신규상품출현 등)에 적응하지 못하고 데이터 모델의 한계로 테이블 갯수를 늘려왔다.
  • 간결한 모델의 전제조건은 통합.

마. 의사소통(Communication)

• 데이터 모델은 대상 업무를 데이터 관점에서 분석하고 설계하여 나오는 최종 산출물이다.
• 분석과정에서 도출되는 수많은 업무 규칙들은 최대한 자세하게 표현되어야 한다.
• 모든 관련자들이 데이터 모델을 통해 의사소통을 할 수 있도록 자세하게 기술해야 한다.

바. 통합성(Integration)

• "라. 데이터 재사용" 부분 참조.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743267&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

◎ 연재기사 ◎ 

▷ 물탱크 구조로 알아본 오라클의 블록 옵션 ‘PCTFREE와 PCTUSED’ 
▷ 이산가족 찾기 생방송을 통해 배우는 DB 원리 
▷ 개발자에게 맞는 DB 공부방법 찾기: 물리적 분류와 논리적 분류 그리고 인덱스 
▷ 데이터베이스 인덱스의 오해와 진실 
▷ 쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (상)
▷ 쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (하)
▷ 누구도 알려주지 않았던 ‘오라클 인덱스 생성도’의 비밀
▷ 누구도 알려주지 않았던 ‘오라클 쿼리 작성의 비법’
▷ 퀴리 최적화 및 튜닝을 위한 오라클 공정쿼리 작성법
▷ 만능 쿼리와 한 방 쿼리
▷ 오라클 옵티마이저 ‘CBO와 RBO’ 이해하기
▷ 재미있는 DB 이야기 ‘60갑자와 쿼리’
▷ 그림으로 배우는 ‘오라클 조인의 방식’ 이야기
▷ 반드시 알아야 하는 오라클 힌트절 7가지
▷ 오라클 플랜을 보는 법
▷ 개발자들의 영원한 숙제 ‘NULL 이야기’ 
▷ 알면 유용한 오라클 기능 ‘GATHER_PLAN_STATISTICS’
▷ 알면 유용한 오라클 기능들 
▷ 오라클 DICTIONARY를 활용한 DB툴 프로그램 ‘FreeSQL’ 
▷ 이제는 말할 수 있다: 주식 자동매매 프로그램(상) 
▷ 이제는 말할 수 있다: 주식 자동매매 프로그램(하) 
▷ 개발자들이 자주 접하는 오라클 에러 메세지 
▷ 재미있는 DB 이야기 ‘사라진 날짜를 찾아라’
▷ 오라클 랜덤 함수와 사용자 정의 함수
▷ 그림으로 배우는 ‘공정쿼리와 인덱스 생성도’
▷ 이병국의 개발자를 위한 DB 이야기: 디폴트 세팅의 함정과 오라클 파라미터
▷ 재미있는 DB 이야기 ‘놀라운 마방진의 세계’
▷ 오라클 운반 최소 단위 BLOCK
▷ 이병국의 개발자를 위한 DB 이야기: 이세돌과 알파고의 세기의 대결
▷ 이병국의 개발자를 위한 DB 이야기(30회) : DB 엔지니어의 가볍게 읽는 세상 이야기
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(31회) : 개발자를 위한 DB 튜닝 실전(1편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(32회) : 개발자를 위한 튜닝 실전(2편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(33회) : 개발자를 위한 튜닝 실전(3편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(34회) : 개발자를 위한 DB 튜닝 실전(4편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(35회) : 개발자를 위한 튜닝 실전(5편)
▷ 이병국의 개발자를 위한 DB 이야기: 페이징 처리에 대한 이해 (36회)
▷ 보기 좋은 떡이 먹기도 좋다 - 좋은 쿼리 좋은 성능
▷ 테이블의 수직분할과 수평분할에 대한 이해