SQLD 노랭이 1과목 개념 정리 (데이터 모델링의 이해)

데이터모델링

- 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법

- 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정 (추상화의 의미)

- 복잡한 현실을 제한된 언어나 표기법을 통해 이해하기 쉽게 하는 단순화의 의미

- 애매모호함을 배제하고 누구나 이해 가능하도록 정확하게 현상을 기술하는 정확화의 의미를 가짐

- 데이터베이스를 구축하기 위한 분석/설계 과정

 

 

데이터모델링이 필요한 이유

- 업무정보를 구성하는 기초가 되는 정보들에 대해 일정한 표기법에 의해 표현

- 분석된 모델을 가지고 데이터베이스를 생성하여 개발 및 데이터 관리에 사용하기 위함

- 데이터모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미를 가짐 

- 데이터베이스를 구축하기 위한 용도를 위해 데이터모델링을 수행하고 업무에 대한 설명은 별도의 표기법 이용

• 일정한 표기법에 의해 표현
• 구축하기 위한 용도로만 쓰이는 것이 아니라, 데이터모델링 자체로서 업무를 설명하고 분석하는 중요한 의미를 가짐 

 

 

데이터모델링 유의점

- 중복 (Duplication)

- 비일관성 (Inconsistency)

- 비유연성 (Inflexibility)

• 데이터모델을 어떻게 설계했느냐에 따라 사소한 업무 변화에도 데이터모델이 수시로 변경됨으로써
  유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터 사용 프로세스와 분리함으로써
  데이터모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는
  가능성을 줄인다.

 

 

스키마 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것

데이터베이스 스키마 구조

- 개념스키마

• 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현
• 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것
• DB에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마

- 내부스키마

• 데이터베이스의 물리적 저장구조를 정의
• 물리적인 저장장치 입장에서 DB가 저장되는 방법을 기술한 것
• 시스템 프로그래머나 시스템 설계자가 보는 관점의 스키마

- 외부스키마 (서브스키마 - 사용자 뷰)

• 사용자나 응용프로그래머가 개인의 입장에서 필요한 데이터베이스의 논리적 구조를 정의
• 실세계에 존재하는 데이터들을 어떤 형식, 구조, 배치 화면을 통해 사용자에게 보여줄 것인가
• 하나의 데이터베이스에는 여러 개의 외부스키마 존재 가능
  (하나의 외부스키마를 여러 개의 응용프로그램이나 사용자가 공용 가능)

 

 

엔터티 사이에서 관계를 도출할 때 유의할 점

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

 

 

성능을 고려한 데이터 모델링의 순서

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

 

 

논리데이터모델의 슈퍼타입과 서브타입 데이터모델을 물리적인 테이블 형식으로 변환할 때 

• 트랜잭션은 항상 전체를 대상으로 일괄 처리하는데 테이블은 서브타입 별로 개별 유지하는 것으로 변환하면
  UNION 연산에 의해 성능이 저하될 수 있다.
• 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합하여 변환하면 불필요하게 많은 양의 데이터가
  집적되어 있어 성능이 저하될 우려가 있다.
• 트랜잭션은 항상 슈퍼+서브 타입을 함께 처리하는데 개별로 유지하면 조인에 의해 성능이 저하될 수 있다.
• 트랜잭션은 항상 전체를 통합하여 분석 처리하는데 슈퍼+서브타입이 하나의 테이블로 통합되어 있으면
  하나의 테이블에 집적된 데이터만 읽어 처리할 수 있기 때문에 다른 형식에 비해 더 성능이 우수하다. (JOIN 감소)

 

비식별자를 선택하는 기준

• 관계의 강약을 분석하여 상호간에 연관성이 약할 경우
• 자식테이블에서 독립적인 Primary Key의 구조를 가지기 원할 때
• 모든 관계가 식별자 관계로 연결되면 SQL Where절에서 비교하는 항목이 증가되어 조인에 참여하는 테이블에 따라
  SQL문장이 길어져 SQL문의 복잡성이 증가되는 것을 방지하기 위해 (가장 마지막으로 고려할만한 비중)
• 부모엔터티에 참조값이 없어도 자식엔터티의 인스턴스가 생성될 수 있는 경우
• 여러 개의 엔터티를 하나로 통합하면서 각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합되는 경우
• 자식쪽 엔터티의 주식별자를 부모엔터티와는 별도로 생성하는 것이 더 유리하다고 판단하는 경우

 

 

데이터모델에 대한 반정규화 시 판단 요소

• 반정규화 정보에 대한 재현의 적시성으로 판단한다.
  ex) 빌링의 잔액(balance)은 다수 테이블에 대한 다량의 조인이 불가피하므로
        데이터 제공의 적시성 확보를 위한 필수 반정규화 대상 정보
• 다량 데이터 탐색의 경우 인덱스가 아닌 파티션 및 데이터 클러스트링 등의 다양한 물리 저장 기법을 활용해
  성능 개선을 유도 가능
  (다만, 하나의 결과셋을 추출하기 위해 다량의 데이터를 탐색하는 처리가 반복적으로 빈번하게 발생하면 반정규화를 고려하는 것이 좋음)
• 이전 또는 이후 위치의 레코드에 대한 탐색은 window function으로 접근 가능하다.
• 집계 테이블 이외에도 다양한 유형(다수 테이블의 키 연결 테이블 등)에 대해 반정규화 테이블 적용이 필요할 수 있음

 

하나의 테이블의 전체 컬럼 중 자주 이용하는 집중화된 컬럼들이 있을 때 디스크 I/O를 줄이기 위해 해당 컬럼들을 
별도로 모아놓는 반정규화기법                                                                              [ 테이블 추가 - 부분테이블 추가 ]