[DAsP] 4. 데이터 모델링 요약,정리

1. 데이터 모델링의 기본 원칙

• 커뮤니케이션 원칙
  : 요구 사항은 모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성되어야 함
• 모델링 상세화 원칙
  : 데이터의 상세화 정도를 제시하고, 조직이 사용하는 정보 구조의 ’최소 공통 분모‘를 제시해야 함
• 논리적 표현 원칙
  : 모델은 물리적 제약조건 없이 비즈니스를 그대로 반영해야 함. 즉, 논리적 데이터 모델은 특정 아키텍처, 기술 또는 제품 등에 독립적이어야 함

 

 

2. 데이터 모델링 정의

• 개념 데이터 모델링
  : 현실 세계의 다양한 업무에서 발생하는 정보를 데이터베이스에 저장/활용하기 위하여 추상화를 통하여 개념 세계에서 정보의 구조와 업무 규칙을 ERD로 표현해 나가는 과정
  : 엔터티의 정의를 명확히 하는 것은 바람직하지만 연관 하위 엔터티를 정의하는 것은 수평적 사고를 방해할 위험요소가 있으므로 바람직하지 못함
• 논리 데이터 모델링
  : 개념 데이터 모델을 특정 데이터베이스(계층형, 망형, 관계형)로 구현할 것을 결정하고, 그 구조로 표현하는 것
  • 논리 데이터 모델링 절차
    • 주제영역 정의 → 엔터티 정의 → 관계 정의 → 속성 정의 → 식별자 확정 → 정규화 → 이력관리
    • 주제영역 정의 : 주제영역은 조직이 사용하는 데이터의 최상위 집합 : 데이터를 하향식(Top Down)으로분석하기 위한 개념으로 유용 : 계층적으로 표현할 수 있음 : 주제영역을 분해하면 하위 수준의 주제영역이나 엔터티가 나타남 : 주제영역 내부에 존재하게 될 개체들이 높은 결합성을 갖도록 설계

 

 

3. 엔터티-관계 데이터 모델(개체-관계 데이터 모델)

• 피터 첸이 최초로 제안한 모델로 이 모델이 지니고 있는 단순성 때문에 현재 개념/논리 모델링에서 가장 일반적으로 사용됨
• 현실세계에 존재하는 구체적인 개체 또는 객체들의 “공통된 특징”을 파악하여 인식의 대상으로 삼는 것
• 복잡한 현실의 것에서 핵심적인 개념, 또는 기능 등을 간추려 내는 활동
• 현실 업무를 기호, 설계서로 표현하기 위해 미리 정한 규칙을 통해 정의하는 과정
• 추상화
• 타입과 인스턴스
• 엔터티-관계 데이터 모델 3구성요소 : 엔터티, 관계, 속성
• 모델의 단순성때문에 현재 광범위하게 사용됨
• 확장된 개체-관계 모델은 서브타입을 포함함
• 서로 다른 뷰들을 하나로 통합할 수 있는 단일화된 설계안을 만들 수 있음

 

 

4. 논리 데이터 모델링에서 사용하는 추상화 유형

• 유형화 : 현실세계에 존재하는 같은 성질을 갖는 멤버들을 타입 또는 유형(Class)이라는 하나의 개념으로 정의하는데 사용
• 집단화 : 값을 유형화하면 속성이라는 타입이 됨. 집단화는 속성이라는 타입들의 세트로 구성되는 새로운 타입(엔터티 타입)을 정의하는 개념
• 일반화 : 여러 엔터티 타입 간의 공통적인 특성을 파악하는 과정. 즉, 일반화는 둘 또는 그 이상의 엔터티 타입 요소 간에 서브세트(부분집합)을 정의하는 개념

 

 

5. 논리 데이터 모델링 추가 사항

• 현실세계를 추상화하기 때문에 ‘논리적‘이라는 용어를 사용함
• 테이블 구조가 아니라 대상 데이터의 논리적 형태를 표현하기 위한 것이기 때문에 한글화가 필수적
• 한글화하지 않더라도 이해 증진을 위해 구성원들이 이해할 수 있는 자연어로 최대한 표현되어야 함
• 초기에 엔터티 사이가 다대다, 순환, 배타적 관계 등의 관계로 연결된 엔터티가 많이 보임
• 업무영역이 바뀌어도 잘 설계된 논리적 모델은 설계 변경이 거의 발생하지 않음
• 논리 데이터 모델은 하나의 엔터티가 반드시 물리적으로 하나의 테이블이나 세그먼트가 되지 않을 수 있음

 

 

6. 엔터티 일반화

• 현실세계의 사물, 사건을 단순화하여 표현하는 추상화 기법 중 하나로 엔터티의 부분집합을 정의하는 것
• 슈퍼타입, 서브타입 엔터티를 이용하여 데이터 구조 명료화
• 엔터티 내의 특정 속성에 의해 구분될 수 있는 부분집합이 정의될 수 있을 때 이를 서브타입이라 함
• 서브타입을 갖는 엔터티 = 슈퍼타입
  
  

• 배타적 서브타입
  : 서브타입 간에 상호 배타적이므로 슈퍼타입의 인스턴스는 반드시 하나의 서브타입과 1:1 관계가 존재해야 함
  : 서브타입의 합 = 슈퍼타입
  : 배타 관계에 있는 관계는 보통 동일
  : 배타 관계는 논리적 관점. DB 저장 구조로 구현될 때 애플리케이션 성능이나 업무 유연성 확보 등을 고려하여 배타관계에 있는 엔터티들을 하나로 통합하여 물리 데이터 모델로 정의할 수 있음
  : 모두 선택적이던지 모두 필수적이어야 함
• 포괄적 서브타입 : 겹치는 부분이 있는 서브타입으로 슈퍼타입의 인스턴스 하나에 두 개 이상의 서브타입과 관계가 존재할 수 있음

 

 

7. 일반화 vs 상세화

 

 

8. 데이터의 특성

• 조작과 기술에 비해 독립적
• 프로세스에 비해 안정적. 즉, 변화가 적음
• 여러 프로세스 또는 기능에서 사용

 

 

9. 데이터 무결성

• 엔터티 무결성 규칙(실체 무결성, 개체 무결성) : 주 키는 Null값을 포함하지 않는다
• 참조 무결성 규칙 : 관계 엔터티의 모든 외래 키 값은 관련 있는 관계 엔터티의 모든 주 키값이 존재해야 함
• 도메인(속성) 무결성 규칙 : 엔터티 내의 모든 열에 관한 무결성 규칙으로 데이터 타입, 길이, 허용 값, 기본값, 유일성, 널 여부 등에 관한 제한
• 연쇄 작용 또는 업무 규칙 : 입력,삭제,수정 또는 조회 등의 작업이 동일 엔터티 혹은 다른 엔터티의 속성에 영향을 미치는 업무 규칙 정의

. 

10.  엔터티 무결성

• 엔터티 내 특정 건의 유일성을 보장할 것
• 최소한의 속성 집합일 것

 

 

11. 참조 무결성

• 데이터가 하나 또는 두 개의 관계있는 엔터티에 입력, 수정, 삭제될 때 데이터가 어떻게 반응해야 하는가에 대한 업무규칙
• 엔터티의 모든 FK값은 관계있는 엔터티에 모든 PK값으로 존재해야 함하
• 입력규칙 : 자식 엔터티의 행이 입력될 때
  • Dependent : 참조되는(부모) 테이블에 PK값이 존재할 때만 참조하는(자식)테이블에 입력을 허용
  • Automatic : 부모 테이블에 PK값이 없는 경우 부모 테이블에 PK를생성한 후 자식테이블에 입력
  • Default : 부모 테이블에 PK값이없는 경우 자식 테이블에 지정된 기본값으로 입력
  • Customized : 특정한 조건을 만족할 때만 입력을 허용
  • Null(Nullify) : 부모 테이블에 PK값이없는 경우 자식 테이블의 FK를 null값으로 처리
  • No effect : 조건 없이 입력을 허용
• 삭제규칙 : 부모 엔터티의 행을 삭제할 때 (또는 PK를 수정할 때)
  • Restrict : 자식 테이블에 부모 테이블의 PK값이 없는 경우에만 부모테이블에서 해당 PK의 행의 삭제.수정 허용 (자식 테이블의 행을 먼저 삭제해야 함)
  • Cascade : 부모 테이블의 행을 삭제하면 해당 레코드의 PK를 FK로 상속받아 참조하는(자식) 테이블의 행까지 연쇄적 삭제/수정
  • Default : 부모 테이블의 수정을 항상 허용하고 자식 테이블의 외래키를 지정된 기본 값으로 변경
  • Customized : 특정한 조건을 만족할 때만 수정.삭제 허용
  • Null : 부모 테이블의 수정을 항상 허용하고 자식 테이블의 외래키를 Null값으로 수정
  • No effect : 조건 없이 삭제.수정 허용

 

 

12. 도메인 무결성

• 같은 도메인의 값들끼리만 비교 가능
• 속성이 취할 수 있는 값의 제한

 

 

13. 관계형 모델 이론

• 업무에서 사용하는 데이터의 구조, 조작, 무결성에 대한 매우 간단한 이론
• 데이터를 테이블(릴레이션)로 표현하는 방식
• 데이터는 열과 행으로 구성된 테이블에 저장되며, 테이블 간의 관계를 정의하여 데이터 간의 연결성을 표현함
• 릴레이션 = 테이블
• 애트리뷰트 = 열
• 튜플 = 행
• 차수 = 애트리뷰트의 개수
• 카디널리티 = 튜플의 개수
• 관계형 모델에서 데이터의 가장 작은 논리적 단위는 애트리뷰트임.
• 하나의 애트리뷰트(속성)가 갖는 같은 타입(유형)의 모든 원자 값들의 집합을 그 속성의 “도메인”이라 함

 

 

14. 객체 지향 모델

• 조직이나 시스템은 객체(Object)라는 것에 관련되어 있고 객체에 대한 정보를 저장(고객, 직원, 교실 등)
• 객체는 대개 객체를 기술하는 데이터와 그 기술 데이터를 운영하는 메소드(Method)로구성됨
• 속성 유형과 메소드를 공유하는 객체가 그룹화 되어 객체 클래스(또는 클래스)가 됨
• 객체 인스턴스는 객체 클래스의 어커런스. (직원이 객체 클래스이면 ‘홍길동’은 직원클래스의 객체 인스턴스)
• 객체는 연관(Association) 또는 상속(Inheritance)를 통해 다를 객체들에 연결
• 상속, 다형성, 캡슐화 등 객체 지향 프로그래밍의 개념을 활용하여 데이터 모델 구성

 

 

15. 객체지향 모델링 - 논리데이터 모델링 대응

• 객체 = 엔터티
• 속성 = 속성
• 연결 = 관계(Relationships)
• 캡슐화 = 대응개념 없음
• 객체 클래스 = 엔터티 유형
• 객체 인스턴스 = 엔터티 인스턴스
• 메시지 = 대응 개념 없음

 

 

16. 관계형 모델의 릴레이션(테이블)이 갖는 6가지 특성

• 각 열은 하나의 값을 가짐
  : 애트리뷰트의 원자성. 즉, 한 릴레이션에 나타난 애트리뷰트 값은 논리적으로 더 이상 분해할 수 없는 값
  : 애트리뷰트 값으로 반복 그룹, 즉 값의 집합이 허용되지 않음. 이러한 반복 그룹을 애트리뷰트 값으로 허용하지 않는 릴레이션을 1차 정규형(1NF)릴레이션이라 함
  : ’취미‘라는 애트리뷰트에 수영,영화 등의 여러 값이 들어간다면 취미가 수영인 사람을 찾을 때 select 성명 From 고객취미 where 취미=수영 과 같은 쿼리로 찾을 수 없음
• 각 열의 값은 동일한 종류이다.
  : 속성은 같은 성격을 갖는 속성 값을 추상화하여 개념화한 것으로 같은 도메인 하에서 속성을 정의함.
  : 즉 같은 성격을 갖는 속성 값을 추상화하여 개념화 한 것으로 같은 도메인 하에서 속성을 정의하였기 때문. → 도메인 무결성
• 각 행은 유일하다.
  : 튜플의 유일성. 이 튜플의 유일성은 릴레이션을 조작하기 위해 튜플에 접근하고 식별하는 방법의 기본이 됨. → 엔터티 무결성
• 열의 순서는 의미가 없다.
  : 애트리뷰트의 무순서성. 릴레이션 정의 시 몇개의 애트리뷰트로 구성됨을 정의한 것이지 애트리뷰트의 물리적인 위치나 상대적 위치, 즉 나열 순서까지 정의한 것은 아님
• 행의 순서는 의미가 없다.
  : 튜플의 무순서성. 튜플들의 순서를 다르게 한다 하더라도 릴레이션이 본질적으로 달라지는 것이 아님.
• 각 열은 유일한 이름을 갖는다.
  : 열의 순서는 중요하지 않기 때문에, 열은 그 위치에 의해서가 아니라 열의 이름에 의해서 그 값을 찾을 수 있음

 

 

17. 관계형 모델 이론‘과 ‘비관계형 모델 이론’의 차이점

• 관계형은 데이터 중심의 분석 기법 vs 비관계형은 일반적으로 프로세스 중심의 분석 기법
• 관계형은 데이터의 구조와 조작 및 무결성 정의 vs 비관계형은 데이터의 구조와 조작 정의
• 관계형은 데이터를 집합적으로 처리를 요구 vs 비관계형은 데이터의 레코드 처리(한 건씩 처리)를 요구

 

 

18. 관계연산자와 처리연산자

• 관계연산자
  • Select (or Restrict) : 열에 의거한 행의 부분집합
  • Project : 열의 부분집합
  • Product : 두 관계 테이블간 행의 조합을 묶음
  • Join : 열의 기준에 의거하여 각 행을 수평적으로 묶음
  • Union : 중복을 없이 하여 각 행을 수직적으로 묶음
  • Intersection : 관계 테이블간의 공통된 행
  • Difference : 하나의 관계 테이블에만 있는 행
  • Division : 단른 관계 테이블의 모든 행에 대응하는 열을 제외한 열
• 처리연산자
  • Insert
  • Update
  • Delete

 

 

19. 속성

• 속성
  : 더 이상 분리되지 않는 단위 값
  : 실체를 서술하며 양을 계수화하고 자격을 부여/분류하며 구체적으로 기입하는 정보 항목
• 속성 유형
  • 기본 속성 : 속성 값이 해당 인스턴스에 월내 존재하며, 다른 속성 값으로 부터 유도될 수 없는 속성
  • 유도 속성 : 속성 값이 항상 다른 속성의 값으로부터 유도되거나 계산되는 속성
  • 설계 속성 : 업무 제약사항을 반영하거나 시스템 운영을 단순화하기 위하여 생성하는 속성
• 속성 검증
  • 원자 단위 검증 : 원자 값 단위까지 분할
  • 유일값 검증 : 하나의 값만을 가지는지 검증
  • 추출값 검증 : 유도 속성인지 검증

 

 

20. 엔터티 분류

• 일반적인 엔터티 분류
  • 유형 엔터티 : 물리적으로 존재하는 대상(고객, 상품 등)
  • 활동 엔터티 : 어떤 사건에 관한 정보 (주문, 계약, 장비 고장 등)
  • 개념 엔터티 : 관리할 정보가 있는 무형의 개념(계정과목, 성적 등)
• 모델 관점 엔터티 분류
  • 독립 엔터티 : 인스턴스를 식별하는데 있어서 어떤 다른 인스턴스에 의존적이지 않는 엔터티( 고객, 제품, 사원 등)
  • 종속 엔터티 : 인스턴스를 식별하는 데 있어서 하나 또는 하나 이상의 다른 인스턴스에 의존하는 엔터티(사원가족, 주문상품 등)
    • 특성 엔터티 : 하나의 인스턴스에 여러번 발생하는 속성의 그룹으로 다른 인스턴스에 의하여 직접적으로 인식되지는 않는 엔터티(사원경력 등)
    • 연관 엔터티 : 두 개 이상의 연관된 다른 엔터티로부터 식별자를 상속 받는 엔터티(다대다 관계 해소 시 생성됨)
    • 서브타입 엔터티 : 다른 부분집합과 구별되는 공통 속성이나 관계를 공유하는 엔터티의 부분집합
• 발생 시점 엔터티 분류
  • 키 엔터티 : 자신의 부모를 가지지 않는 엔터티 (사원, 부서, 고객 등)
  • 메인 엔터티 : 키 엔터티를 제외한 다른 모든 엔터티는 부모 엔터티를 가지고 있어야만 태어날 수 있음. 이러한 엔터티는 업무의 크기에 따라 엔터티 간 계층의 깊이가 달라짐. 여기서 키 엔터티를 제외한 엔터티 중에서 업무의 중심에 해당하는 엔터티를 메인 엔터티라 함 (주문, 보험계약, 구매의뢰, 사고 등)
  • 액션 엔터티 : 키, 메인 엔터티를 제외한 것은 모두 액션 엔터티(상태 이력, 차량수리내역 등)
• 엔터티 후보 선정 시 유의 사항
  • 중요 엔터티라도 너무 깊게 분석 X
  • 단어 하나하나에 집중해 전체 집합을 고려하여 집합을 개념적으로 정의
  • 프로세스에 연연하지않고 엔터티 후보 선정
  • 이음동의어, 동음이의어 등과 같이 동의어처럼 보이는 집합도 집합을 명확하게 구분하여 파악해야 함

 

 

21. 엔터티 검증

• 조직의 업무를 수행하는데 필요한 의미 있는 정보를 나타내는지
• 특정 사례가 아닌 유사한 사물들을 대표하는 집합체
• 인스턴스가 포함할 내부 연관성 있는 속성에 의해 결정된 단일 개념을 대표해야 함
• 엔터티 내 인스턴스의 출현을 구별할 수 있는 능력을 제공해야 함(인스턴스 식별)
• 정규화 규칙을 만족해야 함

 

 

22. 배타적 관계(Arc 관계)의 특징

1. • 관계는 보통 동일하다
   • 배타적관계는 항상 필수(Mandatory)이거나 선택(Optional)이어야 한다
   • 배타적 관계는 반드시 하나의 인스턴스에만 속해야 한다
   • 어떤 엔터티는 다수의 배타적 관계를 가질 수 있다. 하지만 지정된 관계는 단 하나의 배타적 관계에만 사용되어야 한다,

 

 

23. 엔터티 표기법

• 정보공학(IE)엔터티 표기법
  • 독립 엔터티, 종속엔터티(특성, 연관, 서브타입 엔터티) 존재
  • 독립엔터티 : 각진 사각형으로 표시
  • 종속 엔터티 : 모서리가 둥근 사각형으로 표시
• CASE*Method 엔터티 표기법
  • 모든 엔터티를 모서리가 둥근 사각형으로만 표현
  • 독립인지 종속인지를 확인하기 위해서는 부모의 유일 식별자가 자식 유일 식별자의 일부가 되는지를 보는 것과 관계선에 수직으로 그어져 있는 UID Bar를 확인

 

 

24. 속성 표기법

• 정보공학(IE) 표기법 : PK를 사각형의 줄이 그어진 윗부분에 표시
• CASE*Method 표기법 : 유일 식별자 속성 앞에 ‘#’ 표시

 

 

25. 관계 표기법

• 관계 기수성(Cardinality, Degree) 표기법
  

  

• 관계 선택성 표기법
  • CASE*Method 표기법에서는 필수를 실선으로, 정보공학(IE) 표기법에서는 필수는 동그라미 생략과 선택은 관계 선에 동그라미를 표시
    

    

• 관계 식별성 표기법
  • CASE*Method 표기법에서 수직인 바(UID Bar)사용하고, 정보공학(IE) 표기법에서는 실선을 사용하여 표현
    
    

 

 

26. 식별자

• 모든 인스턴슬는 유일성이 보장되어야 함. 유일성을 보장하기 위해 필요한 것이 식별자.
• 식별자 종류
  • 본질식별자 : 업무에서 사용하는 속성을 이용하여 유일성을 보장
    • 인조식별자도 때로는 본질식별자가 될 수 있음
    • 기준 정보 엔터티의 본질 식별자 : 부모 엔터티 없이도 혼자서 정의될 수 있는 기준 정보 엔터티의 본질 식별자 : 주민등록번호 등.
    • 거래 처리 엔터티의 본질 식별자 : 하나의 인스턴스를 유일하게 발생시키는 일련의 속성이 어느 부모로부터 상속되었는지를 찾고자 하는 것.
  • 인조식별자 : 업무에서 사용하는 속성이 아닌 인위적으로 만든 유일성을 보장하는 속성
    • 인조식별자 지정 기준
      • 최대한 범용적인 값 사용
      • 유일한 값을 만들기 위한 인조 식별자 사용
      • 하나의 인조 식별자 속성으로 대체할 수 없는 형태를 주의
      • 편의성.단순성 확보를 위한 인조 식별자 사용 가능
      • 의미의 체계화를 위한 인조 식별자 사용 가능
      • 내부적으로만 사용하는 인조 식별자
  • 보조식별자 : 엔터티 내에서 하나의 인스턴스를 유일하게 식별할 수 있는 속성이지만 대표성을 갖지 못하는 속성
  • 참고. 신용카드의 카드번호는 실질식별자(인조식별자). 고객번호, 카드상품코드, 카드발급일시 등이 본질식별자임

 

 

27. 관계

• 집합 간에 다양한 관계가 존재할 수 있지만, 이 관계들 중에서 직접 관계만을 표현하는 것이 논리 데이터 모델
• 다대다 관계는 개념단계에서는 풀지 않지만, 논리 단계에서 두개의 1:M 관계 엔터티로 생성
• 관계의 내용에 따라 관계의 형태가 바뀔 수 있음
• 관계를 맺는 두 엔터티의 의미상 식별자가 결정되지 않았다면 관계 생성의 의미 없음
• 관계도 집합임
• 특수 관계
  • 자기 참조 관계
  • 다대다 관계
    • 다대다 관계를 해소하는 시점
      : 자신만의 속성을 가져야 할 때
      : 자식을 가져야 할 때
      : 자신만의 속성을 갖지 않거나 자식을 갖지 않는 경우는 논리 모델 상세화 단계에서.

 

 

28. 다중 관계 처리

• 다중 관계란 두 엔터티 사이에 하나 이상의 관계를 가지고 있는 상태. (통합, 분할과 엄연히 다른 개념)
• 병렬식 관계
  • 두 엔터티 사이에 존재하는 관계들을 별도의 관계로 간주함으로써 여러 개의 관계 선분이 나란히 병렬로 관계가 맺어지게 되는 경우
  • 테이블이 될 때 여러 개의 칼럼으로 나열됨
  • 하나의 로우에서 관리되므로 새로운 테이블을 추가할 필요 없음
  • 인덱스 수가 증가되고 SQL이 복잡해짐
  • 새로운 관계의 추가, 관계 형태 변경 등에 매우 취약한 형태
  • 관계 내용별로 상세 정보 관리 불가능
• 직렬식 관계
  • 두 엔터티 사이에 존재하는 몇 개의 관계를 모아 상위 개념으로 통합함으로써 하나의 관계로 관리하는 방법
  • 관계들을 관리하는 새로운 엔터티가 추가되어야 함
  • 관계들이 로우 형태로 나타남
  • 인덱스 수가 감소하고 SQL이 단순해짐
  • 새로운 관계의 추가, 관계 형태의 변경 등에 유연한 형태
  • 관계 내용별로 상세 정보 관리 가능(자식 엔터티 생성)
  • 속성이 추가되더라도 모델에 변화 없음

 

 

29. 특수 형태 관계

• 순환 관계
  • 하나의 엔터티가 다른 엔터티가 아닌 자기 자신과 관계를 맺는 관계
  • 하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함해야 함
  • 각 계층에 있는 속성은 동일하게 취급하는 것이 좋음
  • 필수(직선)관계로 취급 불가(무한 Loop 발생). 반드시 선택 관계
  • 조직의 변경(추가/삭제)에 쉽게 대응 가능
  • 최상위는 의미적으로 NULL이지만 물리적 요소(수행 성능 등)를 고려해 특정 값을 갖는 것이 바람직함
  • M:M 순환관계를 처리하기 위해서는 별도의 엔터티 추가해야 함
• BOM(Bill of Materials) 관계
  • 네트워크 구조(전철노선이나 하이퍼링크를 갖는 웹 도큐먼트같은)라 함
  • 제조업에서 부품의 수요량 파악 등의 모델에 유용하게 이용
  • M:M 순환구조임
  • 상세 모델링 과정에서 새로운 관계 엔터티를 추가하여 두 개의 1:M관계로 구성된 모델로 구체화됨
• Arc(배타적) 관계
  • 아크 내 관계는 보통 동일
  • 아크 내 관계는 항상 필수이거나 항상 선택
  • 반드시 하나의 엔터티에만 속해야 함(하나의 아크가 여러 엔터티 가질수 없음)
  • 어떤 엔터티는 다수의 아크를 가질 수 있지만 지정된 관계는 단 하나의 아크에만 사용되어야 함

 

 

30. 엔터티 통합과 분할

• 엔터티의 통합은 향후 유연성이 크게 향상(but 독립성 저하)
• 통합을 통해 배타적 관계의 가능성을 줄임
• 하위 엔터티를 위해서 최대한 통합을 유도하는 것이 바람직함
• 경우에 따라 하나의 집합이 완전히 포함되는 통합이 발생할 수 있음
• 새로운 유형의 집합이 추가되더라도 새로운 엔터티나 기존에는 관계의 변화가 일어나지 않으면서 서브타입만 증가하는 형태가 바람직

 

 

31. 정규화

• 엔터티에 데이터 입력, 수정, 삭제 연산을 수행할 때 발생하는 이상 현상을 제거하여 논리 데이터 모델링의 목적인 정확성, 일관성, 단순성, 비중복성, 안정성을 만족시키는 최적의 데이터 구조를 만들어가는 과정
• 장점
  • 중복 값 감소
  • 널 값 감소
  • 복잡한 코드로 데이터 모델 보완 필요 x
  • 새로운 요구 사항의 발견 과정을 도움
  • 업무 규칙의 정밀한 포착 보증
  • 데이터 구조의 안정성 최대화
• 정규화 과정
  • 제 1 정규형(1NF)
    • 모든 속성은 반드시 하나의 값을 가져야 함
    • 각 속성의 모든 값은 동일한 형식이어야 함
    • 각 속성들은 유일한 이름을 가져야 함
    • 행들은 서로 간에 식별 가능해야 함
  • 제 2 정규형(2NF)
    • 식별자가 아닌 모든 속성은 식별자 전체 속성에 완전 종속되어야 함 : 부분적 함수 종속 제거
    • PK가 아닌 모든 컬럼이 PK에 종속이어야 제2정규형(2NF) 만족
    • Ex. 주문상품 테이블에 PK(주문번호, 상품코드)이고 일반 속성에 상품명이 있을 때 상품명이 상품코드에 종속적 → 제2정규형 위반
  • 제 3 정규형(3NF)
    • 제2정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안됨 : 이행적 함수 종속 제거
  • BCNF
    • 제3정규형을 만족하고 다른 속성의 값을 결정하는 결정자가 되는 속성을 테이블을 분해하여 해당 속성이 후보키가 될 수 있도록 함
    • 즉 모든 결정자가 후보키가 되도록 테이블을 분해하는 것
  • 제 4정규형(4NF)
    • BCNF를 만족하고 다치종속이 없어야 함
    • 다치 종속이란 A→B일 때 A값에 여러 개의 B값이 존재하는 것
    • 최소 3개의 컬럼이 존재하고 A와 B사이에 다치 종속성이 있을 때 B와 C가 독립적
    • Ex. 학생번호, 자격증, 언어라는 컬럼이 있을 때 101번 학생의 자격증과 언어는 관계가 없는 독립적 관계지만 학생번호라는 컬럼에 다치종속됨 학생번호,자격증 / 학생번호,언어 두개의 테이블로 분리되어야 함
  • 제 5정규형(5NF)
    • 제4정규형을 만족하고 중복을 제거하기 위해 분해할 수 있을 만큼 전부 분해하는 것
    • 조인 종속 제거
    • 조인 종속은 하나의 릴레이션을 여러 개의 릴레이션으로 무손실 분해했다가 다시 결합할 수 있는 경우를 말함
    • Ex. 4정규형에서 학생번호,자격증 / 학생번호,언어 두 개의 테이블로 분할했지만 합치만 다시 동일함 이를 학생번호,자격증 / 학생번호,언어 / 자격증,언어 세개의 테이블로 분할하는 것

 

 

32. 이력 관리

• 이력 관리 대상 선정
  • 사용자 조사 : 이력관리를 할 필요가 있는지에 대한 조사
  • 이력 데이터 종류
    • 발생 이력 데이터 : 어떤 데이터가 발생할 때마다 남기는 이력 정보 : 이벤트가 발생할 때마다 생성하거나 이력이 발생하지 않더라도 날마다 데이터를 생성하는 방법이 있음
    • 변경 이력 데이터 : 데이터가 변경될 때마다 변경 전과 후의 차이를 확인해야 한다면 변경 이력 관리
    • 진행 이력 데이터 : 업무의 진행에 따라 이 데이터를 이력 정보로 남겨야 하는 경우 생성 : 대부분 각 단계가 누구에 의해 처리되고, 현재 단계는 무엇인지에 관한 정보 (Ex.주문)
  • 이력 관리 형태
    • 시점 이력 : 데이터의 변경이 발생한 시각만을 관리 : 특정 시점의 데이터를 추출하고자 할 때 불필요한 작업을 수행하게 됨 (Ex. 환율 변경)
    • 선분 이력 : 데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리
  • 선분 이력 관리 유형
    • 인스턴스 레벨 이력 관리
      • 하나의 인스턴스의 어떤 변경이라도 발생하면 전체 인스턴스를 새롭게 생성
      • 한 번의 액세스로 스냅샷 참조 가능
      • 로그성 데이터를 저장할 목적인 경우 적당한 방법
      • 다른 이력 관리 유형에 비해 저장이 쉬움
      • 하나 이상의 컬럼에 변경 발생 시 이벤트가 모호해짐
      • 이벤트가 자식정보를 가지면 매우 치명적(해당 이벤트를 찾기 어려워짐)
      • 다른 유형의 이력관리에 비해 공간낭비 초래 가능
      • 어떤 데이터가 변경되었는지 찾기 위해서는 과거 데이터를 Merge해서 비교해야함
      • 특정 순간의 스냅샷만 보는게 아니면 처리가 복잡함
      • 변화가 빈번하게 발생하는 상황이라면 고려해볼 수 있는 유형
    • 속성 레벨 이력 관리
      • 이력을 관리할 대상 속성에서 변화가 생길 때만 이력 관리
      • 변경 이벤트가 매우 명확함(어떤 데이터가 변경되었는지 분명함)
      • 다른 엔터티와 통합 이력 관리 가능
      • 변경된 것만 처리하기 때문에 독립적 처리 가능
      • 변화 발생 가능성은 매우 낮으며 이력 관리 대상 속성은 매우 많은 경우 사용하는 것이 유리함
      • 특정 속성에 변화가 집중되는 경우 유리함
      • 다른 유형에 비해 향후 사용될 데이터 액세스 쿼리에서 조건 검색이 어려움
      • 변화가 너무 많은 경우 적용이 곤란함
    • 주제 레벨 이력 관리
      • 내용이 유사하거나 연동될 확률이 높은 것별로 Row 레벨 이력 관리
      • 로우 레벨과 속성 레벨의 장점을 모두 수용하는 형태
      • 확장성을 확보할 수 있는 용도로 사용 가능
      • 변경 부분만 처리 가능(독립적 처리 가능)
      • 다른 엔터티와 통합 이력관리 가능
      • 속성 레벨의 단점 해소
      • 전체 참조 시 로우 레벨에 비해 Merge가 발생하는 문제점 존재
      • 부문에 따라 변경 정도 차이가 심한 경우 유리함
  • 선분 이력에서 종료점 처리 시 주의사항
    • 종료점이 미정이므로 Null - 인덱스를 사용하지 못하므로 수행 속도 저하
    • 수렴하므로 최대치 부여 (일자라면 9999/12/31) - 가능한 테이블 생성 시 기본값 부여, 수행 속도에 유리함
  • 이력을 관리하는 모델로 변환 시에 나타나는 상황
    • 관계의 형태를 변화시킴. 즉, 속성이나 관계의 Cardinality를 증가시킴
    • 하나의 엔터티에 일반 속성 이력을 관리하면 1:M 관계의 하위 엔터티를 생성하게 됨
    • M:M관계인 상태에서 해당 관계에 대한 이력 관리 시 기존의 관계 엔터티에 추가적인 식별자 속성을 발생시킴
    • 1:M 관계에 대한 이력을 관리하면 M:M 관계로 변하게 되어 새로운 관계 엔터티 생성해야 함

 

 

33. 물리 데이터 모델링

• 물리 데이터 모델 : 논리적 모델을 특정 데이터베이스로 설계함으로써 생성된 데이터를 저장할 수 있는 물리적인 스키마
• 하나의 논리적 집합(엔터티 or 서브타입)은 하나 이상의 테이블이 될 수 있으며, 경우에 따라서 속성의 일부만으로 생성될 수 있음
• 논리 데이터 모델을 사용하고자 하는 각 DBMS의 특성을 고려하여 데이터베이스 저장 구조(물리 데이터 모델)로 변환하는 것
• 물리 데이터 모델링 vs 데이터베이스 디자인
  • 물리 데이터 모델링 : 데이터의 구조에 관련된 것들을 물리적인 모습까지 설계하는 것
  • 데이터베이스 디자인 : 이러한 물리적인 모델(설계도면)을 DBMS 관점의 객체로 생성하는 최적의 설계(디자인)를 하는 것 Ex. 객체별 저장 공간의 효율적 사용 계획, 객체 파티셔닝 설계, 인덱스 설계 등
• 하나의 논리 데이터 모델을 가지고 서로 다른 형태의 물리 데이터 모델을 설계하는 경우
  • 분산 데이터 구축 시
    : 분산 데이터베이스 구축 시 노드별로 자신이 원하는 형태의 물리 모델을 생성하고자 할 때
  • 물리 데이터 모델 비교
    : 나름대로의 특징을 가지고 있는 여러 물리적 모델을 생성하여 비교.검토
  • 물리적 환경의 변화
    : 논리 모델에는 변화가 발생하지 않지만, 물리적인 환경에는 변경이 발생했을 경우 기존의 물리모델을 새로운 목표 모델로 개선하고자 할 때
  • 물리적 모델의 형상 관리
    : 물리 모델이 세월의 흐름에 따라 조금씩 변해갈 경우 그 이력을 관리할 목적으로 여러 개의 버전을 보유하고자 할 때
• 물리 데이터 모델 설계에 영향을 미치는 요소
  • 시스템 구축 관련 명명 규칙
  • 하드웨어 자원 (CPU, 메모리,디스크, I/O컨트롤러, 네트워크 등)
  • 운영체제 및 DBMS 버전
  • DBMS 파라미터 정보
  • 데이터베이스 운영과 관련된 관리 요소(사용자 관리 기법, 백업/복구 기법, 보안 관리 정책)

 

 

34. 논리 데이터 모델 → 물리 데이터 모델 변환

 

 

 

35. 엔터티 - 테이블 변환

• 서브타입 변환
  • 슈퍼타입 기준 테이블 변환
    • 서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만듦
    • 주로 서브타입에 적은 양의 속성이나 관계를가진 경우 적용
    • 하나의 테이블로 통합이 유리한 경우
      • 데이터 액세스가 좀 더 간편
      • 뷰를 활용하여 각 서브타입만을 액세스하거나 수정 가능
      • 수행 속도가 좋아지는 경우가 많음
      • 서브타입 구분 없는 임의 집합 가공 용이
      • 다수의 서브타입을 통합한 경우 Join감소 효과가 큼
      • 복잡한 처리를 하나의 SQL로 통합하기 용이
    • 하나의 테이블로 통합이 불리한 경우
      • 특정 서브타입의 Not Null 제한 불가
      • 테이블 컬럼 수 증가
      • 테이블 블럭 수 증가
      • 처리 시마다 서브타입의 구분이 필요해지는 경우가 많음
      • 인덱스 크기가 증가
  • 서브타입 기준 테이블 변환
    • 슈퍼타입 속성들을 각 서브타입에 추가하여 각각의 서브타입마다 하나의 테이블로 만듦
    • 분할된 테이블에는 해당 서브타입의 데이터만 포함되어야 함
    • 주로 서브타입에 많은 양의 속성이나 관계를 가진 경우 적용
    • 유리한 경우
      • 각 서브타입 속성들의 선택 사양이 명확한 경우 유리함
      • 처리 시마다 서브타입 유형 구분이 불필요
      • 전체 테이블 스캔 시 유리함
      • 단위 테이블의 크기 감소
    • 불리한 경우
      • 서브타입 구분 없이 데이터 처리하는 경우 Union 발생
      • 처리 속도 감소하는 경우 많음
      • 트랜잭션 처리 시 여러 테이블을 처리하는 경우 증가
      • 복잡한 처리의 SQL통합이 어려워짐
      • 부분 범위 처리가 불가능해질 수 있음
      • 여러 테이블을 합친 뷰는 조회만 가능
      • UID 유지 관리가 어려움
  • 개별타입 기준 테이블 변환
    • 슈퍼타입과 서브타입을 각각 테이블로 변환한 경우
    • 슈퍼타입과 서브타입 테이블 간에는 1:1 관계가 생성됨(한 쪽을 모두 합치면 전체와 같게 된다는 면에서 개념적으로 아크 관계와 유사)
    • 다음의 여러 경우를 만족할 때 사용
      • 전체 데이터 처리가 빈번하게 발생할 경우
      • 서브타입의 처리는 주로 독립적으로 발생할 경우에 적용
      • 테이블을 통합했을 때 컬럼의 수가 너무 많아지는 경우
      • 서브타입의 컬럼 수가 많은 경우
      • 트랜잭션이 주로 공통부분(슈퍼타입)에서 발생
      • 슈퍼타입의 처리 범위가 넓고 빈번하여 단일 테이블 클러스터링 해야 할 때

 

 

36. 속성 - 컬럼 변환

• 일반 속성 변환
  • 컬럼의 명칭은 속성과 일치할 필요는 없으나 혼동을 피하기 위해 가급적 표준화된 약어 사용 → SQL 해독 시간 감소
  • SQL의 예약어 사용을 피함
  • 컬럼명은 가급적 짧은 것이 좋음(개발자의 생산성에 긍정적)
  • 필수 입력 속성은 Nulls/Unique란에 NN표시
  • 실제 테이블에 대한 설계 검증 목적으로 가능하다면 표본 데이터 입력
• Primary UID → 기본키변환
  • 실제 DDL에서는 기본키 제약조건의 형태로 객체 생성
  • 테이블에 PK표시 → Nulls/Unique란에 NN,U로표시 → 여러개 컬럼으로 UID 구성 시 각각의 컬럼에 NN,U1표시 → 또 다른 Unique Key있다면 U2로 표시
• Primary UID(관계의 UID Bar) → 기본키 변환
  • 논리모델의 Pirmary UID에 속하는 속성 중에는 해당 엔터티 자체에서 생성된 것도 존재하지만 다른 엔터티로부터의 관계에 의해 생성되는 UID도 존재함 → 기본적인 속성 UID 변환과는 약간 다름
  • 테이블에 외래키 컬럼 포함 → PK의일부분으로 표시(Nulls/Unique란에 NN,U1표시, 키 형태란에 PK/FK표시) → 여러 컬럼으로 구성된 경우 PK,FK1을 각각 표시
• Secondary(Alternate) UID → Unique Key 변환
  • Secondary UID 들은 해당 집합과 상태 집합과의 선택적인 관계를 가질 수 있도록 함

 

 

37. 관계 변환

• 1:M 관계 변환
  • 1 쪽의 엔터티의 PK를 M쪽 엔터티의 FK로 변환
  • 1 쪽이 Mandatory(필수) 관계일 때 변환 시 주의 사항
    • 자식 쪽의 Row가 반드시 하나 이상은 되어야만 부모 쪽 Row를 생성 가능
    • 자식 쪽 Row를 삭제할 경우 전체를 다 삭제할 수는 없고, 반드시 하나 이상의 자식 Row를 남겨두어야 함. 또는 자식, 부모 Row를 동시 삭제
      

      

• 1:1 관계 변환
  • 1:1 관계를 물리모델로 변환하는 과정은 관계의 선택성(Optionality)에 따라 다른 방법으로 적용됨
  • 양쪽 다 Optional인 경우에는 더 빈번하게 사용되는 테이블이 외래키를 가지는 것이 유리함
  • Mandatory 반대쪽에 있는 테이블의 PK를 Mandatory쪽 테이블의 외래키로 변환
  • 변환 시 주의사항
    • 1:1 관계에 의해 생긴 모든 외래키 부분은 Unique Key 필수
    • 한쪽이 Optional이고 반대쪽이 Mandatory라면 Mandatory쪽 테이블에 외래키 생성
      

      

• 1:M 순환 관계 변환
  • 대부분 데이터의 계층 구조를 표현하기 위해 이러한 관계 사용
  • 해당 테이블 내에 외래키 컬럼 추가. 외래키는 같은 테이블 내의 다른 로우의 PK 컬럼을 참조함
  • 외래키 컬럼명은 가능한 관계 명칭을 반영하고, 이 때 외래키는 결코 Not Null(NN)이될 수 없음
    

    

• 배타적 관계 변환
  • 외래키 분리 방법
    • 각각의 관계를 관계 컬럼으로 생성하는 방법
    • 이 방법을 사용하면 실제 FK 제약조건 생성 가능
    • 하지만 각각의 키 컬럼들이 Optional이어야 함
    • 추가적인 체크 제약조건 생성 필요
      

      

  • 외래키 결합 방법
    • 각각의 관계를 하나의 관계 컬럼으로 생성하는 방법
    • 이 방법을 사용하면 실제 FK 제약조건을 생성할 수 없음
    • 또한 각각의 관계를 선택적으로 구분하기 위한 추가 컬럼 필요
    • 구분하기 위한 추가컬럼(TYPE) 예시
      

      

      
      
      

 

38. 데이터 표준 적용

• 논리에서 테이블, 컬럼으로 변환하는 과정에서 명칭에 대한 데이터 표준을 따라야 함
• 데이터베이스 : 주제영역(통합 모델링 단계)이나 업무영역(애플리케이션 모델링 단계)에 대응되는 객체
• 스토리지 그룹 : DASD(Direct Access Storage Device), 즉 물리적 디스크를 묶어 하나의 그룹으로 정의해 놓은 것으로 테이블스페이스, 인덱스 스페이스 생성 시 스토리지 그룹명 지정하여 물리적 영역 할당
• 테이블스페이스 : 테이블이 생성되는 물리적 영역, 하나의 테이블 스페이스에 하나 또는 그 이상의 테이블 지정
• 테이블 : 엔터티
• 컬럼 : 속성
• 인덱스
• : 테이블에서 특정 조건의 데이터를 효율적으록 검색하기 위한 색인 데이터.(PK, FK 등)
• 뷰 : 테이블에 대한 재정의로서 물리적으로 테이블의 특정 컬럼, 특정 로우를 뷰로 정의하여 특정 사용자만 접근이 가능하도록 할 수 있음

 

 

39. 반정규화

• 정규화로 데이터의 중복을 최소화하고 데이터의 일관성과 정확성.안정성을 보장하는 데이터 구조 완성
• 시스템의 성능 향상, 개발 과정의 편의성, 운영의 단순화를 위해 반정규화 수행
• 성능과 관리효율을 증대시킬 수 있지만, 데이터의 일관성 및 정합성을 해칠 위험을 내포하고 있음
• 이를 유지하는데 비용이 발생하여 지나치면 오히려 성능에도 악영향을 미칠 수 있음

 

 

40. 반정규화 종류

• 테이블 분할 (= 파티셔닝_데이터 저장 방식의 파티셔닝과는 구분되는 개념)
  • 수평 분할
    • 레코드를 기준으로 테이블 분할
    • 하나의 테이블에 데이터가 너무 많이 있고, 레코드 중에서 특정한 범위만을 주로 액세스 하는 경우 사용
    • 분할된 각 테이블은 서로 다른 디스크에 위치시켜 물리적 디스크의 효용성을 극대화
    • 이러한 수평 분할은 DBMS차원에서 제공됨
    • 범위 분할, 해쉬 분할, 목록 분할, 복합 분할 등의 기법이 사용됨
  • 수직 분할
    • 하나의 테이블이 가지는 컬럼의 개수가 많은 경우 사용
    • 조회 위주의 컬럼과 갱신 위주의 컬럼으로 나뉘는 경우 : 레코드에 Locking수행하기 때문
    • 특별히 자주 조회되는 컬럼이 있는 경우 : 물리적 I/O양을 줄임
    • 특정 컬럼의 크기가 아주 큰 경우
    • 특정 컬럼에 보안을 적용해야 하는 경우
• 중복 테이블 생성
  • 많은 양의 정보를 자주 Group By, Sum 등과 같은 집계함수를 이용하여 실시간으로 통계 정보들을 계산할 수 있음
  • 이러한 계산 유형은 매우 많은 양의 데이터가 대상이 되고, 하나의 테이블이 아닌 여러 개의 테이블에서 필요한 데이터를 추출하는 경우가 대부분.
  • 이를 위해 특정 통계 테이블을 두거나 중복 테이블 추가 가능
  • 중복 테이블 생성 판단 근거
    • 정규화에 충실하면 종속성, 활용성은 향상되지만 수행속도가 증가가 발쌩하는 경우
    • 많은 범위를 자주 처리해야 하는 경우
    • 특정 범위의 데이터만 자주 처리되는 경우
    • 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우
    • 요약 자료만 주로 요구되는 경우
    • 추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정
    • 인덱스의 조정이나 부분 범위 처리로 유도하거나 클러스터링을 이용하여 해결할 수 있는지를 철저히 검토한 후 결정
  • 중복 테이블 유형
    • 집계(통계) 테이블 추가
    • 진행 테이블 추가