1. 데이터 모델링의 이해
<모델링의 특징>
- 단지 시스템 구현만을 위해 수행하는 것이 아니며, 시스템 구현을 포함한 업무분석 및 업무형상화를 하는 목적도 있다.
- 현실세계를 일정한 형식에 맞추어 표현하는 추상화의 의미를 가질 수 있다.
- 복잡한 현실을 제한된 언어나 표기법을 통해 이해하기 쉽게 하는 단순화의 의미를 가지고 있다.
- 애매모호함을 배제하고 누구나 이해할 수 있도록 정확하게 현상을 기술하는 정확화의 의미를 가진다.
<데이터 모델링 목적>
- 정보시스템을 구축하기 위한 데이터 관점의 업무분석기법
- 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
- 데이터베이스를 구축하기 위한 분석, 설계의 과정
- 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것
<데이터 모델링 유의점>
- 중복성 : 데이터베이스가 여러 장소에 같은 정보를 저장해서는 안된다.
- 비유연성 : 데이터, 프로세스의 작은 변화가 애플리케이션, 데이터베이스에 중대한 변화를 일으킬 가능성을 줄인다.
- 비일관성 : 데이터와 데이터 간의 상호 연관관계에 대해 명확히 정의하여 일관성 유지할 수 있다.
<개념적 데이터 모델링>
- 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행
- 전사적 데이터 모델링
- EA수립시 많이 이용
- DB 종류와 관계 없다.
- 주요 산출물로는 개체관계 다이어그램(E-R 모델)이 있다.
<논리적 데이터 모델링>
- 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현
- 재사용성이 높다.
- 업무의 모습을 모델링 표기법으로 형상화하여 사람이 이해하기 쉽게 표현
- 목표 DBMS에 맞는 스키마 설계, 트랜잭션 인터페이스 설계(테이블도 설계)
- 정규화를 수행
- 주요 산출물로는 관계 데이터 모델, 계층 데이터 모델, 네트워크 데이터 모델(CODASYL DBTG), 객체지향 데이터 모델, 객체관계 데이터 모델이 있다.
- 논리적 데이터베이스 구조로 매핑, 스키마의 평가 및 정제
<물리적 데이터 모델링>
- 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계
- DBMS의 특성 및 성능을 고려하여 물리적인 스키마 생성, 데이터베이스 저장공간 변환
- 테이블, 인덱스, 뷰, 파티션 등 객체 생성
- 반정규화를 수행
- 트랜잭션에 대한 인터페이스는 논리적 단계에서 정의하지만, 실제 트랜잭션 모델링은 물리적 단계에서 수행
- 레코드 집중의 분석 및 설계, 저장 레코드 양식 설계, 접근 경로 설계
- 응답시간, 저장공간 효율화, 트랜잭션 처리를 고려하여 설계
<데이터베이스 스키마 3단계 구조>
- 외부 스키마(External Schema)
- 개념 스키마(Conceptual Schema) : 통합관점의 스키마구조를 표현, 데이터 모델링은 개념 스키마를 만들어가는 과정
- 내부 스키마(Internal Schema)
<발생시점에 따른 엔터티(Entity) 분류> -> 엔터티 = 테이블
- 기본/키 엔터티 : 업무에 원래 존재하는 정보. 독립적으로 생성 가능, 타 엔터티의 부모역할
- 중심 엔터티 : 기본엔터티로부터 발생. 업무에서 중심적인 역할 수행
- 행위 엔터티 : 두 개 이상의 부모엔터티로부터 발생. 자주 내용 바뀌거나 테이터량 증가
<엔터티 특징>
- 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
- 유일한 식별자에 의해 식별 가능해야 한다.
- 영속적으로 존재하는 인스턴스의 집합이어야 한다('한 개'가 아니라 '두 개 이상').
- 업무 프로세스에 의해 이용되어야 한다.
- 반드시 속성이 있어야 한다(두 개 이상).
- 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다(공통코드, 통계성 엔터티 제외).
<ERD 작성 순서>
- 피터첸에 의해 E-R Model(Entity-Relationship Model)표기법이 만들어졌다.
- 엔터티를 그린다.
- 엔터티를 적절하게 배치한다(가장 중요한 엔터티를 왼쪽 상단에 배치).
- 엔터티간 관계를 설정한다(존재와 행위를 구분하지 않는다).
- 관계명을 기술한다.
- 관계의 참여도를 기술한다.
- 관계의 필수여부를 기술한다.
<엔터티 명명 기준>
- 가능하면 현업업무에서 사용하는 용어를 사용한다.
- 가능하면 약어를 사용하지 않는다.
- 단수명사를 사용한다.
- 모든 엔터티를 통틀어서 유일하게 이름이 부여되어야 한다.
- 엔터티 생성 의미대로 이름을 부여한다.
<속성>
- 업무에서 필요로 하는 인스턴스에서 관리하고자 하는, 의미상 더이상 분리되지 않는 최소의 데이터 단위
- 엔터티에 대한 자세하고 구체적인 정보를 나타낸다.
- 하나의 엔터티는 두 개 이상의 속성을 갖는다.
- 하나의 속성은 하나의 속성값을 갖는다.
- 속성도 집합이다.
- 각 속성은 가질 수 있는 값의 범위가 있는데, 이를 속성의 도메인(Domain)이라 한다. 속성에 대한 데이터타입, 크기, 제약사항을 지정한 것이다.
<속성 분류>
- 기본속성 : 업무로부터 추출된 일반적인 속성. 데이터 요구 분석 명세서에 포함된다.
- 설계속성 : 원래 존재하지 않지만 필요에 따라 설계자가 추가한 속성. 데이터 요구 분석 명세서에 포함되지 않는다. 대부분 식별자 역할을 하기 위해 추가된 속성이다.
- 파생속성(유도속성) : 기본속성으로부터 계산 등의 가공처리를 통해서 생성된 속성. 중복의 의미가 있으므로 일반적으로 개념적 모델링에서 식별하지 않는다.
<속성 명칭 부여>
- 해당업무에서 사용하는 이름을 부여한다.
- 서술식 속성명은 사용하지 않는다.
- 약어사용은 가급적 제한한다.
- 전체 데이터모델에서 유일성 확보하는 것이 좋다.
<관계>
- 존재적 관계와 행위에 의한 관계로 나눌 수 있다.
- 표기법은 관계명, 관계차수, 선택성(선택사양)의 3가지 개념으로 표현한다.
- ERD에서는 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다.
- 1:1, 1:N과 같이 관계의 기수성을 나타내는 개념은 관계차수
- 필수관계, 선택관계를 나타내는 개념은 선택사양
<관계 읽기(엔터티 사이 관계 도출)>
- 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
- 두 개의 엔터티 사이에 정보의 조합이 발생하는가?
- 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
- 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?(명사가 아니라 동사)
<식별자의 종류>
- 대표성 여부에 따라 주식별자와 보조식별자로 구분(참조관계 연결 여부)
- 스스로 생성 여부에 따라 내부식별자와 외부식별자로 구분
- 속성의 수에 따라 단일식별자와 복합식별자로 구분
- 대체 여부에 따라 본질식별자와 인조식별자로 구분
<주식별자 고려사항>
- 유일성 : 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되어야 한다.
- 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
- 불변성 : 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
- 존재성 : 주식별자가 지정되면 반드시 값이 들어와야 한다(Null 안됨).
- 명칭, 내역 등과 같이 이름으로 기술되는 것은 주식별자로 부적절하다. 동명이인 있을 수 있기 때문
<식별자 관계 / 비식별자 관계>
| 항목 | 식별자 관계 | 비식별자 관계 |
| 목적 | 강한 연결관계 표현 | 약한 연결관계 표현 |
| 자식 주식별자 영향 | 자식 주식별자 구성에 포함됨 | 자식 일반 속성에 포함됨 |
| 표기법 | 실선 표현 | 점선 표현 |
| 연결 고려사항 | - 반드시 부모 엔터티 종속 - 자식 주식별자 구성에 부모 주식별자 포함 필요 - 상속받은 주식별자 속성을 타 엔터티에 이전 필요 - 식별자, 비식별자 관계 선택은 단순히 SQL 문장의 복잡성을 낮추는 목적으로 고려되는 것은 바람직하지 않음 |
- 자식 주식별자 구성을 독립적으로 구성 - 자식 주식별자 구성에 부모 주식별자 부분 필요 - 상속받은 주식별자 속성을 타 엔터티에 차단 필요 - 부모 쪽의 관계참여가 선택관계 - 부모 엔터티의 주식별자를 자식 엔터티에서 받아 손자 엔터티까지 흘려보내기 위해서는 비식별자 관계 고려 |
<비식별자 관계 설정>
- 부모 없는 자식이 생성될 수 있는 경우
- 부모가 있었지만, 자식만 남겨두고 먼저 소멸될 수 있는 경우
- 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현될 경우
- 자식 엔터티타입에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우
- 자식과 관련있는 엔터티타입으로의 주식별자 상속을 차단하기 위하여
2. 데이터 모델과 성능
<성능 데이터모델링>
- 데이터베이스 성능향상을 목적으로 설계단계의 데이터모델링 때부터 성능과 관련된 사항이 데이터모델링에 반영될 수 있도록 하는 것
- 데이터의 증가가 빠를수록 성능저하에 따른 성능개선비용은 증가한다.
- 데이터모델은 성능을 튜닝하면서 변경이 될 수 있는 특징이 있다.
- 분석/설계단계에서 성능을 고려한 데이터모델링을 수행할 경우, 성능저하에 따른 Rework비용을 최소화할 수 있는 기회를 가지게 된다.
<성능 데이터모델링 수행절차>
- 데이터모델링을 할 때, 정규화를 정확하게 수행한다.
- 데이터베이스 용량산정을 수행한다.
- 데이터베이스에 발생하는 트랜잭션의 유형을 파악한다.
- 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.
- 이력모델, PK/FK, 슈퍼타입/서브타입 조정 등을 수행한다.
- 성능관점에서 데이터모델을 검증한다.
<성능 데이터모델링 고려사항>
- 정규화가 항상 조회성능을 저하시키지는 않는다. 기본적으로 중복된 데이터 제거함으로서 향상 가능
- 물리적인 데이터모델링할 때, PK/FK 컬럼 순서조정, FK인덱스 생성 등은 성능향상을 위한 중요한 요소
- 이력데이터는 시간에 따라 반복적으로 발생, 대량데이터일 가능성 높아 특별히 성능 고려하여 컬럼 등을 추가하도록 설계해야 한다.
<정규화(Normalization)>
- 관계형 데이터베이스의 설계에서 중복을 최소화하게 데이터 구조화하는 프로세스
- 목적 : 테이블 불일치 위험 최소화, 이상현상 최소화함으로써 데이터 구조 안정성 최대화, 효과적인 검색 알고리즘 생성
- 처리조건에 따라 조회성능이 향상될 수도, 저하될 수도 있다.
- 정규화된 정도를 정규형(Normal Form)으로 표현
- 1차 정규형 : 릴레이션(테이블)에 속한 모든 속성의 도메인이 원자값(최소단위)으로만 구성되면 1차 정규형(1:M관계)
- 2차 정규형 : 1차 정규형+기본키가 아닌 모든 속성이 기본키에 완전함수 종속되면 2차 정규형(1:M관계)
- 3차 정규형 : 2차 정규형+기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속(삼단논법)되지 않으면 3차 정규형
- 보이스-코드 정규형 : 모든 결정자가 후보 KEY인 경우(후보키가 아닌 함수 종속 제거)
<반정규화>
- 정규화된 엔터티, 속성, 관계에 대해 시스템의 성능향상, 개발과 운영의 단순화를 위해 중복, 통합, 분리 등을 수행
- 데이터를 조회할 때 디스크 I/O량이 많아서 성능저하, 경로 멀어서 조인으로 인한 성능저하, 컬럼 계산하여 읽을 때 성능저하 예상되는 경우 반정규화 수행
- 집계 테이블 외에 다양한 유형에 대해 반정규화 테이블 적용이 필요할 수 있다.
- 이전 또는 이후 위치의 레코드에 대한 탐색은 window function으로 접근 가능하다.
- 하나의 결과셋을 추출하기 위해 다량 데이터 탐색하는 처리가 반복적으로 빈번하게 발생한다면 반정규화 고려(반정규화 정보에 대한 재현의 적시성으로 판단)
- 지나치게 많은 조인이 걸려 데이터 조회가 기술적으로 어려울 경우 -> 뷰 테이블 활용
- 다량 데이터 검색의 경우, 인덱스가 아닌 파티션 및 데이터 클러스터링 등의 다양한 물리저장기법을 활용하여 성능개선 유도가능
- 논리적으로 하나의 테이블을 물리적으로 여러개의 테이블로 분리 -> 파티셔닝(Partitioning)
<반정규화 절차>
- 반정규화 대상조사 : 범위처리빈도수, 대량의 범위처리, 통계성 프로세스, 테이블 조인 개수
- 다른 방법유도 검토 : 뷰 테이블, 클러스터링 적용, 인덱스 조정, 파티셔닝 기법, 응용 애플리케이션
- 반정규화 적용 : 테이블 반정규화, 속성 반정규화, 관계 반정규화
<반정규화 기법>
- 테이블 반정규화 : 1:1관계 테이블병합, 1:M관계 테이블병합, 슈퍼/서브타입 테이블병합, 수직분할, 수평분할, 중복테이블 추가, 통계테이블 추가, 이력테이블 추가, 부분테이블 추가(하나의 테이블의 전체컬럼 중 자주 이용하는 집중화된 컬럼을 별도로 모으기)
- 컬럼 반정규화 : 중복컬럼 추가(조인감소를 위해 여러 테이블에 동일한 컬럼을 추가), 파생컬럼 추가(조회성능 향상을 위해 미리 계산된 컬럼 추가), 이력테이블 컬럼 추가(최신값 처리하는 이력 특성 고려), PK에 의한 컬럼 추가, 응용시스템 오작동 위한 컬럼 추가
- 관계 반정규화 : 중복관계 생성
<슈퍼/서브타입 데이터모델 변환기술>
- 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
- 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성
- 전체를 하나로 묶어 트랜잭션 발생할 때는 하나의 테이블로 구성
- 트랜잭션은 항상 전체를 통합하여 분석처리하는데, 테이블 하나로 통합되어 있으면 조인감소로 성능 우수하다.
- 트랜잭션은 항상 전체를 대상으로 일괄처리하는데, 테이블 서브타입별로 개별 유지하는 것으로 변환하면 Union연산에 의해 성능저하될 수 있다.
- 트랜잭션은 항상 서브타입 개별로 처리하는데, 테이블 하나로 통합하여 변환하면 불필요하게 많은 데이터 있어 성능저하될 수 있다.
- 트랜잭션은 항상 슈퍼+서브타입을 함께 처리하는데, 개별로 유지하면 조인에 의한 성능저하될 수 있다.
<PK 순서결정기준(인덱스 정렬구조)>
- 상수값으로 EQUAL 조건으로 조회되는 컬럼이 가장 앞으로 나오기
- 그 다음 범위조회하는 유형의 컬럼이 나오기
<관계, FK>
- 엔터티 간에 논리적 관계가 있을 경우, FK 생성여부와 관계없이 조인성능향상위해 인덱스 생성하는 것이 유리
<분산 데이터베이스>
- 데이터가 여러 지역에 분산되어 있지만, 하나의 데이터베이스처럼 사용하기 원하는 경우
- 장점 : 지역 자치성, 점증적 시스템 용량 확장, 신뢰성, 가용성, 효용성, 융통성, 빠른 응답속도, 통신비용 절감, 지역 사용자의 요구수용 증대
- 단점 : 소프트웨어 개발비용, 오류의 잠재성, 처리비용, 설계 및 관리의 복잡성과 비용, 불규칙한 응답속도, 통제의 어려움, 데이터 무결성
- 공통코드, 기준정보 등 마스터 데이터는 분산데이터베이스에 복제분산 적용가능
- 거의 실시간 업무적인 특성을 가지고 있을때 적용가능
- 백업사이트 구성할때, 간단하게 분산기능 적용가능
- Global Single Instance(GSI)는 통합 데이터베이스 구조를 의미, 분산데이터베이스와 배치되는 개념
