Table of Contents

DA

4.1.4 엔터티 정의 항목

엔터티 이름만으로도 해당 엔터티가 어떤 집합인지 최대한 표현하고, 나머지 미진한 부분은 엔터티 정의에서 구체적으로 기술되어야 합니다. 엔터티 편집창에 대한 설명입니다.

4.1.13 엔터티 삭제

4.2 관계

데이터 모델 구성 3요소 중 하나로 엔터티 간의 업무적 연관성을 관계성(Relationship), 기수성(Cardinality), 선택성(Optionality)으로 표현하며 데이터의 참조 무결성을 보장하기 위해 매우 중요한 업무 규칙입니다.

4.2.4 관계 정의 항목

4.3 속성

데이터 모델 구성 3요소 중 하나로 특정한 엔터티의 본질을 이루는 고유한 특성이나 성질이며 엔터티 내에서 관리하고자 하는 정보 항목들을 의미합니다. 그리고 속성도 일종의 집합이고 관계도 일종의 속성이기도 합니다.

4.3.1 속성 Notation

속성 편집창에서 속성명 입력 후 정의 항목들을 체크박스로 선택 시 모델에 아래와 같은 기호가 표시됩니다.

4.3.3 속성 정의 항목

참고
한 엔터티에는 동일한 속성명의 중복 입력이 되지 않습니다.

5. 상세 논리 모델

5.1 상세화

5.1.1 정규화

데이터 모델 정규화란 이상 현상을 야기하는 속성 간의 종속 관계를 제거하기 위해 엔터티를 작은 여러 엔터티로 손실 없이 분해하는 과정을 의미합니다. 이러한 정규화 절차를 통해 상세 논리 데이터 모델링 할 때 속성의 일부가 다른 엔터티로 독립되는 순간 독립된 엔터티에 대한 식별자 선택 및 정규활르 지원합니다.

5.1.4 속성 구조화

속성의 구조화(계층)는 속성의 표현과 그 속성에 대한 Detail 표현을 가능하게 합니다. 구조화는 점선(Inclusive)과 실선(Exclusive)으로 표현되며, 그 표현 자체가 구조화 타입을 나타냅니다.

5.2 서브 타입

서브타입 표현 시 다 차원/다 계층으로 표현이 가능합니다. 즉 하나의 서브타입을 계층적 구성 및 입체적으로 표현하여 비즈니스 규칙을 정밀하게 표현할 수 있습니다.

5.2.1 서브타입 정의

5.2.2 서브타입 통합

과거 계층 구조 서브타입이 제공되기 전에 작성한 것들을 하나의 계층으로 통합할 수 있는 기능입니다. 별도로 정의되어 있던 서브타입을 하나로 통합합니다.

6. 물리 모델

6.1 물리 모델 변환

완성한 논리 모델을 기반으로 물리 모델을 진행합니다. 이러한 변환 과정은 따로 필요한 것은 아니며 마우스 오른쪽 메뉴를 선택함으로써 물리 모델로 변환이 가능합니다. 이 때, 물리 모델 변환 시 물리 모델링에서 필요한 메뉴가 활성화되며 하나의 논리적 집합(엔터티 혹은 서브타입)은 다양한 물리 모델을 생성할 수 있습니다.

서브타입의 테이블 전환 방법
- 하나의 테이블로 통합(Roll up)
- 서브타입 단위 테이블 생성(Roll Down)
- 슈퍼/서브타입 각각 테이블 생성

6.1.3 슈퍼/서브타입 각각 테이블 생성

물리 모델 전환 시 하나의 논리적 집합(엔터티 혹은 서브타입)이 슈퍼/서브타입 단위 테이블로 생성되는 방법입니다.

주의
반드시 하나의 테이블로 통합되어 생성되는 물리 모데롤 변환 후(즉, 물리 모델을 생성 후) 변환시킬 논리 모델의 Object인 엔터티를 선택해야 분할 아이콘이 활성화되면 절차에 따라 진행이 가능합니다.

6.5 물리 모델 상세화

6.5.1 테이블 정의 항목

물리 모델에서 논리 모델의 엔터티가 테이블로 변환됩니다. 즉, 기본적으로 논리 모델의 정보를 물리 모델로 가져옵니다.

6.5.4 데이터 무결성

무결성 설계 목적은 데이터의 정확성, 유효성, 일관성, 신뢰성을 위해 무효 갱신으로부터 데이터를 보호하기 위함입니다. 즉, 데이터가 테이블에 입력, 삭제, 수정될 때 자식 또는 부모 테이블의 처리에 대한 규칙을 정의하는 기능으로 물리적 스키마의 생성은 삭제 규칙에 한해 선택하는 경우만 스키마를 지원합니다. RI Rule를 Setting 하지 않으면 Default 로 설정 해 놓은 Rule이 적용됩니다.

입력 규칙 목록

항목 설명
Dependent 대응되는 부모 엔터티에 레코드가 있는 경우에만 자식 엔터티에 입력을 허용
Automatic 자식 엔터티 레코드의 입력을 항상 허용, 대응되는 부모 건이 없는 경우 이를 자동 생성
Default 자식 엔터티 레코드의 입력을 항상 허용, 대응되는 부모 건이 없는 경우 참조키(FK)를 지정된 기본 값으로 처리
Customized 특정한 검증 조건이 만족되는 경우에만 자식 엔터티 레코드의 입력을 허용
No Effect 자식 엔터티 레코드의 입력을 조건 없이 허용

삭제/수정 규칙 목록

항목 설명
Restrict 대응되는 자식 엔터티의 레코드가 없는 경우에만 부모 엔터티 레코드 삭제를 허용
Cascade 부모 엔터티 레코드의 삭제를 항상 허용하고, 대응되는 자식 엔터티의 레코드를 자동 삭제
Nullify 부모 엔터티 레코드의 삭제를 항상 허용, 대응되는 부모 엔터티의 레코드가 존재하면, 그것의 참조키(FK)를 NULL로 수정
Default 부모 엔터티 레코드의 삭제를 항상 허용, 대응되는 자식 엔터티의 레코드가 존재하면, 그것의 참조키(FK)를 지정된 기본 값으로 수정
Customized 특정한 검증 조건이 만족되는 경우에만 부모 엔터티 레코드의 삭제를 허용
No Effect 부모 엔터티 레코드의 삭제를 조건 없이 허용

6.5.7 시스템 컬럼

각 모델당 공통적으로 테이블에 쓰이는 시스템 컬럼들을 추가하는 기능을 지원합니다. 추가된 시스템 컬럼들은 자동으로 논리 영역에 가상 엔터티로 생성이 됩니다.

7. Reverse 및 Forward

7.1 Reverse

현재 운영중인 데이터베이스의 스키마가 존재하지 않거나 기존에 가지고 있던 다이어그램의 버전이 너무 오래되어 의미가 없을 경우 운영중인 데이터베이스의 스키마 정보를 DA#에서 그대로 가지고 와서 기존 모델에 대한 분석을 통하여 TO-BE 에 활용할 수 있습니다.

참고
파티션을 도입하게 된 배경과 파티션의 기본적인 역할은 무엇인가?
대용량의 Table을 Partition이라는 보다 작은 단위로 나눔으로써 데이터 액세스 작업의 성능향상을 유도하고 데이터 관리를 보다 수월하게 하고자 하는 개념입니다. 물론 무조건 파티션만 한다고 파티션이 가지고 있는 이점을 모두 취할 수 있는 것은 아닙니다. 잘못된 인덱스가 오히려 처리 속도에 나쁜 영향을 미치듯이 파티션 키를 어떻게 구성하느냐에 따라 많은 비효율을 초래할 수도 있기 때문에 파티션 키의 선정은 다음과 같은 기준에 따라 전략적인 관점의 세심한 판단이 요구됩니다. 

첫째, 성능 향상을 위하여 어떤 부분을 고려해야 하는가?
데이터를 처리하는 방법은 크게 인덱스를 경유하는 Random Access 방법과 인덱스를 경유하지 않고 전체 데이터를 scan하는 두 가지 방법이 있습니다. 데이터의 분포도가 좋아서 인덱스를 사용할 수 있는 상황이라면 문제될 것이 없지만 분포도가 나빠서 인덱스를 사용할 수 없다면 인덱스를 사용하지 않고도 필요한 부분만 액세스를 할 수 있도록 Partitioning 이 이루어져야 합니다. 또한 결합 파티션 키인 경우에는 구성 대상 컬럼의 선정 및 컬럼들간의 결합순서도 고려하여야 합니다. 즉, 액세스 유형에 따라 Partitioning이 이루어질 수 있도록 파티션 키를 선정해야 합니다.

둘째, 데이터 관리의 용이성을 위하여 어떤 부분을 고려 해야 하는가?
이력을 관리하는 데이터는 데이터 관리 전략 및 업무규칙에 따라 그 수명이 다하게 되면, 별도의 저장장치에 기록되고 데이터베이스에서 삭제되게 됩니다. 이력 데이터는 활용가치에 따라 생성주기와 소멸주기가 결정되게 되고 그 주기에 따라 데이터베이스를 정리해야만 합니다. 만약 사용자가 사용하지 않는 데이터를 삭제해야 되는데 그 데이터가 여러 파티션에 분산되어 있다면, 그 데이터를 추출하여 삭제하는데 많은 노력과 시간이 필요할 것입니다. 하지만 파티션이 데이터의 생성주기 또는 소멸주기와 일치한다면 파티션을 대상으로 작업이 이루어져 관리가 용이하게 됩니다. 즉, 이력 데이터의 경우에는 생성주기 또는 소멸주기가 파티션과 일치하여야 합니다. 

7.3.2 인덱스 스키마

참고
인덱스와 클러스터 정의?
인덱스와 클러스터는 데이터 검색에 대한 처리 속도를 향상시키기 위한 물리적 객체입니다. 일반적으로 인덱스는 해당 인덱스 컬럼의 value 의 분포도에 따라서 고밀도 인덱스(dense index)와 저밀도 인덱스(sparse index)으로 구분됩니다. 대표적인 고밀도 인덱스는 B-Tree 인덱스로서 여기서 언급하는 인덱스를 의미하며 저밀도 인덱스는 클러스터 인덱스를 의미합니다. B-Tree 인덱스와 클러스터는 다음과 같은 개념 및 활용의 차이가 있습니다.

B-Tree 인덱스의 특징?
인덱스는 별도의 저장 공간을 가지며 인덱스 컬럼의 값(value)과 해당 테이블의 논리적 주소(rowid)로 구성 됩니다. 인덱스와 실제 데이터가 저장된 테이블이 분리되어 있으므로 인덱스를 경유한 데이터 검색 시에는 랜덤 액세스가 발생하며 다량 데이터 검색시의 빈번한 랜덤 액세스는 성능 부하의 주요원인이 됩니다. 데이터의 밀집도(clustering factor)는 인덱스의 랜덤 액세스에 지대한 영향을 미치며 밀집도가 양호한 경우에는 그렇지 않은 경우에 비해서 랜덤 액세스의 부담이 감소합니다. 그리하여 주로 소량 범위의 데이터를 검색할 때 또는 검색 조건에 해당하는 전체 데이터의 일부분만 검색하여 운반단위만 채우면 추출하는 부분 범위 처리시에 사용합니다.

클러스터의 특징?
클러스터는 검색 속도 개선을 위해 데이터의 밀집도가 양호하도록 동일 값(value)을 클러스터 키에 의해 동일 공간에 저장하는 물리적 저장개념입니다. 동일 공간에 데이터를 저장하기 위하여 정의한 테이블의 컬럼을 클러스터 키라고 하며 클러스터 인덱스는 클러스터 키에 대해서 생성됩니다. 입력되는 데이터는 클러스터 키에 의해 해당 클러스터의 위치에 저장되므로 데이터의 검색/저장 등 모든 데이터 처리 작업은 클러스터 인덱스를 경우하게 됩니다. 클러스터에 저장되는 테이블은 1개 이상이 가능하며 2개 이상의 테이블이 저장될 경우에는 해당 테이블간의 연결고리 컬럼이 클러스터 키가 됩니다. 클러스터 키는 저장공간에 별도로 저장되지 않으므로 전체적인 저장공간이 절약됩니다. 클러스터는 인덱스와는 달리 랜덤 액세스의 부가가 없으므로 주로 다량 데이터 검색 시에 사용 됩니다. 

8. 개체 유형 활용

8.1 엔터티 유형

실전에서 활용 가능한 유형별 엔터티입니다.

bpcny9

8.1.2 복제본 엔터티

관계선 단순활르 위해 사용되는 엔터티 유형으로 관계에 의해 데이터 모델이 매우 복잡한 경우 모델의 가독성을 높이기 위해 주로 사용됩니다. 이는 동일 편집창 즉 동일 주제영역 내에서만 생성이 가능합니다.

8.1.3 대체 엔터티

대체 엔터티의 원본이 될 엔터티와 대체 엔터티로 선언할 엔터티간에 관계를 정의합니다 .이때 정의한 관계는 아무런 관계 정보를 정의하지 않습니다. 두 엔터티간의 관계는 관계로서의 의미는 없고 대체 엔터티로 선언하기 위한 사전 행위에 불과합니다. 또한 대체 엔터티는 원본엔터티가 가지고 있는 관계를 전혀 상속 받거나 상속 시켜줄 수 없으므로, 대체 엔터티 별로 필요한 관계를 모두 정의해야 합니다.

8.2 관계 유형

실전에서 활용 가능한 유형별 관계입니다.

0mdp3N

8.3 속성 유형

실전에서 활용 가능한 유형별 속성입니다.

UEUdcx

11. 표준화 적용

11.1 표준대상 선택

표준화 적용 시 표준 정보를 적용할 대상을 선택합니다. 주제영역, 엔터티, 속성, 컬럼 단위로 표준 대상을 설정하여 표준 동기화를 할 때 활용됩니다. 표준 대상의 종류는 상속/대상/비대상 3가지 종류로 구분됩니다.

11.2 분류체계 선택

표준 사전을 구축 시 정책, 표준, 지침 및 절차에 따라 표준 분류 체계를 한 개 이상 설정하여 데이터 표준화를 구축할 수 있습니다.