📌 [정보처리기사] 논리 데이터 모델의 물리 데이터 (모델 변환/모델 품질 검토)

자격증/정보처리기사 📌 [정보처리기사] 논리 데이터 모델의 물리 데이터 (모델 변환/모델 품질 검토)

Dexter_- 2024. 2. 16. 14:33

728x90

물리 데이터베이스 설계

🎯 물리 데이터 모델 변환

테이블(Table)

테이블은 컬럼(Column, 열)과 로우(Row, 행)로 구성되며, 컬럼에는 지정된 유형에 따라 데이터가 저장된다.
테이블의 구성 요소

로우(Row)	튜플, 인스턴스, 어커런스라고도 한다.
컬럼(Column)	각 속성 항목에 대한 값을 저장한다.
기본키 (Primary key)	- 기본키는 후보키 중에서 선택한 주키(Main key)이다. - 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성이다.
외래키 (Foreign key)	- 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합을 의미한다. - 한 릴레이션에 속한 속성 A와 참조 릴레이션의 기본키인 B가 동일한 도메인 상에서 정의되었을 때의 속성 A를 외래키라고 한다.

	COLUMN
ROW	사원번호	이름	직급	연봉	부서번호
	S001	김채원	과장	50,000,000	B02
	S002	카즈하	차장	62,000,000	B01
	S003	허윤진	이사	90,000,000	B03
	기본키				외래키

엔티티(Entity)를 테이블로 변환

📌 논리 데이터 모델에서 정의된 엔티티를 물리 데이터 모델의 테이블로 변환하는 것이다.

엔티티를 테이블로 변환한 후 테이블 목록 정의서를 작성한다.
- 테이블 목록 정의서 : 전체 테이블을 목록으로 요약 관리하는 문서로, 테이블 목록이라고도 한다.
- 예) 테이블 목록 정의서

테이블 ID	테이블명	타입	분류	테이블 스페이스	파티션 여부	발생 주기	총 건수	수정일
user_item	제품	STANDARD						2023/12/02
sell_list	판매 목록	STANDARD						2023/12/09
user_name	사용자	STANDARD						2023/12/01

변환 규칙

논리적 설계(데이터 모델링)	물리적 설계
엔티티(Entity)	테이블(Table)
속성(Attribute)	컬럼(Column)
주 식별자(Primary Identifier	기본키(Primary Key)
외부 식별자(Foreign Identifier)	외래키(Foreign Key)
관계(Relationship)	관계(Relationship)

🔔 예) 엔티티를 테이블로 변환

변환 시 고려사항
- 일반적으로 테이블과 엔티티 명칭은 동일하게 하는 것을 권고한다.
- 엔티티는 주로 한글명을 사용하지만 테이블은 소스 코드의 가독성을 위해 영문명을 사용한다.
- 메타 데이터 관리 시스템에 표준화된 용어가 있을 때는 메타에 등록된 단어를 사용하여 명명한다.

💡 메타 데이터 관리 시스템 : 메타 데이터 관리 스시템은 메타 데이터를 수집하거나 여러 사람이 메타 데이터를 편리하게 사용할 수 있도록 제공하는 시스템이다.
💡 메타 데이터(metadata or metainformation)는 데이터(data)에 대한 데이터이다. 이렇게 흔히들 간단히 정의하지만, 캐런 코일(Karen Coyle)에 의하면 '어떤 목적을 가지고 만들어진 데이터(constructed data with a purpose)'라고도 정의한다. 즉, 다른 데이터를 정의하고 기술하는 데이터(data that defines and describes other data)이다. 가령 도서관에서 사용하는 서지 기술용으로 만든 것이 그 대표적인 예이다. 지금은 온톨로지의 등장과 함께 기계가 읽고 이해할 수 있는(Machine Actionable)형태의 메타 데이터가 많이 사용되고 있다. 설명 메타데이터, 구조화 메타 데이터로 구분된다.

슈퍼타입/서브타입을 테이블로 변환

📌 슈퍼타입/서브타입은 논리 데이터 모델에서 이용되는 형태이므로 물리 데이터 모델을 설계할 때는 슈퍼타입/서브타입을 테이블로 변환해야 한다.

슈퍼타입/서브타입 모델을 테이블로 변환하는 방법에는 슈퍼타입 기준 테이블 변환, 서브타입 기준 테이블 변환, 개별타입 기준 테이블 변환이 있다.
슈퍼타입 기준 테이블 변환
- 슈퍼타입 기준의 테이블 변환은 서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만드는 것이다.
  - 서브타입에 속성이나 관계가 적을 경우에 적용하는 방법으로, 하나로 통합된 테이블에는 서브타입의 모든 속성이 포함되어야 한다.
  - 예) 슈퍼타입 기준 테이블 변환

💡 서브타입의 <방문접수> 개체에 있는 '지점코드', '담당부서'와 <인터넷접수> 개체에 있는 'ID', '수수료 납부방법'이 슈퍼타입인 <접수> 개체에 통합되어 <접수> 테이블로 변환 된다.

장, 단점

장점	- 데이터의 액세스가 상대적으로 용이하다. - 뷰를 이용하여 각각의 서브타입만을 액세스하거나 수정할 수 있다. - 서브타입 구분이 없는 임의 집합에 대한 처리가 용이하다. - 여러 테이블을 조인하지 않아도 되므로 수행 속도가 빨라진다. - SQL 문장 구성이 단순해진다.
단점	- 테이블의 컬럼이 증가하므로 디스크 저장 공간이 증가한다. - 처리마다 서브타입에 대한 구분(TYPE)이 필요한 경우가 많이 발생한다. - 인덱스 크기의 증가로 인덱스의 효율이 떨어진다.

서브타입 기준 테이블 변환
- 서브타입 기준의 테이블 변환은 슈퍼타입 속성들을 각각의 서브타입에 추가하여 서브타입들을 개별적인 테이블로 만드는 것이다.
- 서브타입에 속성이나 관계가 많이 포함된 경우 적용한다.

장점	- 각 서브타입 속성들의 선택 사양이 명확한 경우에 유리하다. - 처리할 때마다 서브타입 유형을 구분할 필요가 없다. - 여러 개의 테이블로 통합하므로 테이블당 크기가 감소하여 전체 테이블 스캔 시 유리하다.
단점	- 수행 속도가 감소할 수 있다. - 복잡한 처리를 하는 SQL의 통합이 어렵다. - 부분 범위에 대한 처리가 곤란해진다. - 여러 테이블을 통합한 뷰는 조회만 가능하다. - UID(Unique Identifier, 식별자)의 유지 관리가 어렵다.

🔔 예) 서브타입 기준 테이블 변환

슈퍼타입인 <접수> 개체에 있는 '신청자 이름', '접수', '수수료'가 서브타입인 <방문접수> 대체와 <인터넷 접수> 개체에 각각 추가되어 <방문접수>와 <인터넷접수> 테이블로 변환된다.

개별타입 기준 테이블 변환
- 개별타입 기준의 테이블 변환은 슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환하는 것이다.
  - 슈퍼타입과 서브타입 테이블들 사이에는 각각 1:1 관계가 형성된다.
  - 개별타입 기준 테이블 변환을 적용하는 경우
    - 전체 데이터에 대한 처리가 빈번한 경우
    - 서브타입의 처리가 대부분 독립적으로 발생하는 경우
    - 통합하는 테이블의 컬럼 수가 많은 경우
    - 서브타입의 컬럼 수가 많은 경우
    - 트랜잭션이 주로 슈퍼타입에서 발생하는 경우
    - 슈퍼타입의 처리 범위가 넓고 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우
장, 단점

장점	- 저장 공간이 상대적으로 작다. - 슈퍼타입 또는 서브타입 각각의 테이블에 속한 정보만 조회하는 경우 문장 작성이 용이하다.
단점	슈퍼타입 또는 서브타입의 정보를 처리하면 항상 조인이 발생하여 성능이 저하된다.

🔔 예) 개별타입 기준 테이블 변환

슈퍼타입의 <접수> 개체와 서브타입의 <방문접수>, <인터넷접수> 개체가 각각 <접수>, <방문접수>, <인터넷 접수> 테이블로 변환된다.

속성을 컬럼으로 변환

📌 논리 데이터 모델에서 정의한 속성을 물리 데이터 모델의 컬럼으로 변환한다.

일반 속성 변환
- 속성과 칼럼은 명칭이 반드시 일치할 필요는 없으나, 개발자와 사용자 간 의사소통을 위하여 가능한한 표준화된 약어를 사용하여 일치시키는 것이 좋다.
- 컬럼명은 SQL의 예약어(Reserved Word) 사용을 피한다.
- 컬럼명은 SQL의 가독성을 높이기 위해 가능한 한 짧게 지정한다.
- 복합 단어를 컬럼명으로 사용할 때는 미리 정의된 표준을 따른다.
- 테이블의 컬럼을 정의한 후에는 한 로우(Row)에 해당하는 샘플 데이터를 작성하여 컬럼의 정합성을 검증한다.
- 예) 일반 속성 변환

<사원> 엔티티의 '부서번호', '이름', '주소', '전화번호', '이메일' 속성이 <사원> 테이블의 각각의 컬럼으로 변환되었으며, 예시를 위한 데이터가 들어있다.

Primary UID를 기본키로 변환
- 논리 데이터 모델에서의 Primary UID는 물리 데이터 모델의 기본키로 만든다.
Primary UID(관계의 UID Bar)를 기본키로 변환
- 다른 엔티티와의 관계로 인해 생성된 Primary UID는 물리 데이터 모델의 기본키로 만든다.
Secondary(Alternate) UID를 유니크 키로 변환
- 논리 모델링에서 정의된 Secondary UID 및 Alternate Key는 물리 모델에서 유니크 키로 만든다.

💡 Primary UID
UID(Unique Identifier)는 식별자, Primary UID는 주 식별자를 의미한다.
UID Bar란 엔티티에 포함된 고유한 속성의 식별자(UID)가 아니라 다른 엔티티와의 관계로 인해 생성된 식별자(UID)를 의미한다.
유니크 키는 해당 속성에 입력된 값이 유일하다는 것을 보장하기 위한 제약 조건인 유니크(Unique)속성이 설정된 키이다.

관계를 외래키로 변환

📌 논리 데이터 모델에서 정의된 관계는 기본키와 이를 참조하는 외래키로 변환한다.

다음은 개체 A, B로 이루어진 E-R 모델을 관계 테이블로 변환하는 방법이다.
- 1:1 관계 : 개체 A의 기본키를 개체 B의 외래키로 추가하거나 개체 B의 기본키를 개체 A의 외래키로 추가하여 표현한다.
- 1:M 관계 : 개체 A의 기본키를 개체 B의 외래키로 추가하여 표현하거나 별도의 테이블로 표현한다.
- N:M 관계 : 릴레이션 A와 B의 기본키를 모두 포함한 별도의 릴레이션으로 표현한다. 이때 생성된 별도의 릴레이션을 교차 릴레이션(Intersection Relation) 또는 교차 엔티티(Intersection Entity)라고 한다.
- 1:M 순환 관계 : 개체 A에 개체 A의 기본키를 참조하는 외래키 컬럼을 추가하여 표현한다. 데이터의 계층 구조를 표현하기 위해 주로 사용된다.

🔔 예) 1:1 관계 변환

<교수> 테이블의 기본키인 '교수번호' 필드를 <과목> 테이블의 외래키로 추가한다.

🔔 예) 1:M 관계 변환

<교수> 테이블의 기본키인 '교수번호' 필드를 <학생> 테이블의 외래키로 추가한다.

🔔 예) N:M 관계 변환

N:M의 관계는 관계를 별도의 테이블로 구성해서 표시해야 한다. <학생> 테이블의 기본키인 '학번'필드와 <과목> 테이블의 기본키인 '과목번호' 필드를 이용하여 <등록> 테이블을 만든다.

🔔 예) 1:M 순환 관계 변환

<메뉴> 테이블의 기본키인 '메뉴 ID' 필드를 참조하는 외래키 '상위메뉴ID' 필드를 추가한다.

관리 목적의 테이블/컬럼 추가

📌 논리 데이터 모델에는 존재하지 않는 테이블이나 컬럼을 데이터베이스의 관리 혹은 데이터베이스를 이용하는 프로그래밍의 수행 속도를 향상시키기 위해 물리 데이터 모델에 추가할 수 있다.

🔔 예) 시스템 등록 일자, 시스템 번호 등

데이터 타입 선택

📌 논리 데이터 모델에서 정의된 논리적인 데이터 타입을 물리적인 DBMS의 물리적 특성과 성능을 고려하여 최적의 데이터 타입과 데이터의 최대 길이를 선택한다.

주요 타입에는 문자 타입(Character Type), 숫자 타입(Numeric Type), 날짜 타입(Date Type)이 있다.
Oracle에서 자주 사용되는 데이터 유형

CHAR	고정길이 문자열 Data 최대 2,000Byte 까지 저장 가능
VARCHAR2	가변길이 문자열 Data 최대 4,000Byte 까지 저장 가능
NUMBER	38자릿수의 숫자 저장 가능
DATE	날짜 저장

물리 데이터 모델 품질 검토

📌 물리 데이터 모델의 품질 검토는 물리 데이터 모델을 설계하고 데이터베이스 객체를 생성한 후 개발 단계로 넘어가기 전에 모델러와 이해관계자들이 모여 수행한다.

물리 데이터 모델은 시스템 성능에 직접적인 영향을 미치므로 향후 발생할 문제에 대해 면밀히 검토해야 한다.
물리 데이터 모델 품질 검토의 목적은 데이터베이스의 성능 향상과 오류 예방이다.
물리 데이터 모델을 검토하려면 모든 이해관계자가 동의하는 검토 기준이 필요하다.

물리 데이터 모델 품질 기준

📌 대표적인 물리 데이터 모델의 품질 기준으로는 정확성, 완전성, 준거성, 최신성, 일관성, 활용성이 있다.

정확성	데이터 모델이 요구사항이나 업무 규칙, 표기법에 따라 정확하게 표현되었음을 의미한다.
완전성	데이터 모델이 데이터 모델의 구성 요소를 누락 없이 정의하고 요구사항이나 업무 영역을 누락 없이 반영하였음을 의미한다.
준거성	데이터 모델이 데이터 표준, 표준화 규칙, 법적 요건 등을 정확하게 준수하였음을 의미한다.
최신성	데이터 모델이 최근의 이슈나 현행 시스템을 반영하고 있음을 의미한다.
일관성	데이터 모델이 표현상의 일관성을 유지하고 있음을 의미한다.
활용성	작성된 모델과 설명을 사용자가 충분히 이해할 수 있고, 업무 변화에 따른 데이터 구조의 변경이 최소화 될 수 있도록 설계되었음을 의미한다.

물리 데이터 모델의 품질 기준은 조직 혹은 업무 상황에 따라 가감하거나 변형하여 사용한다.

물리 데이터 모델 품질 검토 항목

📌 물리 데이터 모델의 품질 검토 항목은 물리 데이터 모델의 특성을 반영한 품질 기준을 작성한 후 이를 기반으로 작성한다.

물리 데이터 모델에 정의된 테이블, 컬럼, 무결성 제약 조건 등 물리 데이터 모델의 주요 구성 요소와 반정규화, 인덱스, 스토이지 등 물리 데이터 모델의 전반적인 것을 검토 항목으로 작성한다.
체크리스트는 물리 데이터 모델의 품질 검토를 용이하게 수행할 수 있도록 한다.

🔔 예) 데이터 품질 체크리스트

대상	검토 항목	검토 내용	평가	비고
테이블	명명	명명 규칙을 준수하였는가?
		의미전달이 명확한 명칭을 사용하였는가?
		테이블 한글명은 엔티티 명칭과 일치하는가?
	설명	데이터 집합 구성상의 특징이 설명되었는가?
	정의	테이블 형태는 성능을 고려하여 결정되었는가?
	정의	테이블 생성 관련 파라미터들은 적절하고 충분하게 정의되었는가?
	권한	테이블 생성/변경/삭제 시 메타 데이터 권한을 정의하였는가?
	권한	테이블에 대한 접근 권한을 정의하였는가?

물리 데이터 모델의 품질 검토 순서

데이터 품질 정책 및 기준을 확인한다.
물리 데이터 품질의 특성에 따라 품질 기준을 작성한다.
데이터 품질 기준에 따라 체크리스트를 작성한다.
논리 데이터 모델과 물리 데이터 모델을 비교한다.
각 모델링 단계의 모델러와 이해관계자가 품질 검토를 수행한다.
모델러와 이해관계자가 작성한 체크리스트 내용을 종합하여 물리 데이터베이스 모델의 품질 검토 보고서를 작성한다.