데이터 아키텍처 - 데이터 모델링 [3]

 

#‘고객’ 엔터티의 식별자를 결정하기 위한 기준

1) 각 인스턴스들을 유일하게 식별할 수 있어야 한다.

2) 나머지 속성들을 직접 식별할 수 있어야 한다.

3) 후보 식별자로 속성 집합을 선택하는 경우에는 개념적으로 유일해야 한다.

4) 여러개의 속성들을 묶어서 식별자로 생성할 수 있다.

 

#데이터 모델링에서 이력 관리의 대상

1) 부서와 사원의 관계

2) 상품 단가에 대한 관리

3) 금융 상품의 이자율 관리

 

#인조 식별자 지정에 대한 설명

1) 최대한 범용적인 값을 사용한다.

2) 유일한 값을 만들기 위해 인조 식별자를 사용한다.

3) 편의성:단순성 확보를 위해 인조 식별자를 사용할 수 있다.

 

#식별자 확정 시에 고려사항

1) 상위 엔터티로부터 하위 엔터티로 결정해가는 것이 좋다.

2) 메인 엔터티는 하위 엔터티들에 대한 영향이 크기 때문에 식별자 속성의 개수를 적게 하는 것이 좋다.

 

# 3차 정규형 : 1차,2차 정규형을 만족하고, 비식별자 속성 간에 종속이 없어야 한다.

 

#정규화 작업을 수행함으로써 얻을 수 있는 장점

1) 중복값 및 Null 값이 줄어든다.

2) 데이터 구조의 안정성이 향상 된다.

3) 복잡한 코드로 데이터 모델을 보완할 필요가 없어진다.

 

#선분(기간)이력관리에 대한 설명

1) 선분(기간)이 중첩되지 않도록 해야 한다.

2) 시작일자와 종료일자로 관리할 때 종료일자에 “99991231”을 초기값으로 설정하는 것은 성능상의 이유다.

3) 데이터의 유효기간을 관리하는 형태로 특정 시점의 데이터를 조회할 때 유리하다.

 

#다대다(M:M) 관계에 대한 설명

1) 논리 데이터 모델링 과정에서 흔히 나타난다.

2) 실세계의 업무 중 대부분은 다대다(M:M) 관계라고 할 수 있다.

 

#참조 무결성 규칙에 대한 설명

1) 관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주 식별자 값이 존재해야 한다.

2) 데이터베이스 설계 관점이 아닌 사용자의 업무 규칙에 따라 적절한 규칙을 선택한다.

3) 입력 규칙은 자식 실체에 인스턴스를 입력할 때, 참조 무결성 규칙으로 Dependent, Automatic, Nullify, Default 등이 해당된다.

4) 삭제 규칙은 부모 실체의 인스턴스를 삭제할 때 사용되어지는 참조 무결성 규칙으로 Restrict, Cascade, Nullify, Default 등이 해당 된다.

 

#이력 관리 형태에 대한 설명

1) 이력 관리 형태는 시점이력 관리와 선분이력관리로 구분할 수 있다.

2) 시점이력관리는 변경 시점의 스냅샷을 관리하는 형태로 특정 시점의 데이터를 추출할 때 불필요한 작업을 수행하게 되는 단점을 갖고 있다.

3) 선분이력 관리는 데이터의 유효기간을 관리하는 형태로 특정 시점의 데이터를 추출할 때 유리하다.

 

#관계 연산자에 대한 내용

1) Select : 열을 기준으로 한 행의 Subset

2) Join : 열을 기준으로한 각 행을 수평적으로 묶음

3) Union : 중복배제를 기준으로 각 행을 수직적으로 묶음

 

#‘물리 데이터 모델’에 대한 정의

1) 논리 데이터 모델을 특정 데이터베이스로 설계함으로써 생성된 데이터를 저장할 수 있는 물리적인 스키마를 말한다.

2) 하나의 논리 데이터 모델은 여러 개의 물리 데이터 모델로 설계되어 질 수 있다.

3) 논리 데이터 모델의 일부 속성만으로 물리 데이터 모델에서 테이블로 설계하는 경우도 발생할 수 있다.

 

#선분이력의 특징

1) 향후 활용 관점에서 보면 과거 임의 시점의 이력 데이터를 Access하기 위해서는

Select ---

from 변경이력

where 이력주체id = '원하는 이력주체‘

and '원하는 시점‘ between 시작일자컬럼 and 종료일자컬럼;

2) 개체의 상태가 지속된 유효기간을 관리하는 방식이다.

3) 시점별로 환율의 변화를 관리해야 한다면 선분이력으로 관리하는 것이 바람직하다.

 

#하나의 논리 데이터 모델을 가지고 여러 개의 물리 데이터 모델을 생성하는 이유

1) 하나의 논리 데이터 모델을 가지고 분산 데이터베이스 구축 시에 동일한 물리 데이터 모델을 여러 개 생성한다.

2) 조금씩 상이한 물리 데이터 모델을 생성하여 여러 형태의 물리 데이터 모델을 비교하고자

할 때 생성한다.

3) 논리 데이터 모델은 변화하지 않았지만 물리적 환경의 변화 발생 시에 여러 개의 물리 데이터 모델을 생성한다.

 

#일반적인 데이터 모델에서 이력을 관리하는 모델로 변환 시에 나타나는 상황에 대한 설명

1) 이력 관리는 관계의 형태를 변화시킨다. 즉, 속성이나 관계의 Cardinality를 증가시키게 된다.

2) 하나의 엔터티에 일반 속성 이력을 관리하면 일대다(1:M) 관계의 하위 엔터티를 생성하게 된다.

3) 다대다(M:M) 관계인 상태에서 해당 관계에 대한 이력을 관리하면 기존의 관계 엔터티에 추가적인 식별자 속성을 발생시키게 된다.

 

#물리 데이터 모델 설계에 영향을 미치는 요소

1) CPU, MEMORY, DISK 등 하드웨어 자원의 상황

2) 운영체제 및 DBMS 버전

3) DBMS 파라미터 정보

 

#논리 데이터 모델의 관계변환에 대한 설명

1) 일대다(1:M) 관계는 논리 데이터 모델에서 가장 흔한 관계의 형태이고, 물리 데이터 모델에서는 M쪽 관계의 형태에 따라서 해당 칼럼의 선택사항이 결정 된다.

2) 일대일(1:1) 관계에 의해서 생긴 모든 외래키는 Unique Constraints를 정의할 수 있다.

3) 선분이력을 관리하는 상위 엔터티와 관계에서는 상위 엔터티의 식별자 전체를 하위 엔터티에서 상속받지 않아도 데이터적인 연결을 수행할 수 있으므로 식별자 상속을 시키지 않을 수도 있다.

4) 일대일(1:1) 관계에서는 양쪽 집합의 선택사양에 따라서 외래키의 생성 위치가 달라질 수 있다. 즉, Mandatory 관계를 가진 쪽 집합에서 외래키를 생성하는 것이 유리하다.

 

#논리 데이터 모델을 물리 데이터 모델로 변환

1) Entity -> Table

2) Attribute -> Column

3) Primary UID -> Primary Key

 

#논리 데이터 모델의 서브타입 엔터티를 물리적인 테이블로 변환하는 방법에 대한 설명

1) 서브타입을 하나의 테이블로 통합하는 경우에는 주로 서브타입이 적은 양의 속성이나 관계를 가진 경우에 적용한다.

2) 서브타입을 하나의 테이블로 통합하면 데이터 액세스가 보다 간편해지고, 복잡한 처리를 하나의 SQL로 통합하기가 용이해져서 수행속도가 향상될 수 있다.

3) 서브타입을 여러 개의 테이블로 분할하는 경우에는 주로 서브타입이 많은 양의 속성이나 관계를 가진 경우에 적용한다.

 

#논리 데이터 모델에서 관계를 물리 데이터 모델의 객체로 변환하는 방법에 대한 설명

1) 일대다(1:M) 관계는 논리 데이터 모델에 존재하는 가장 흔한 관계의 형태이고, M쪽 관계의 형태에 따라 관계 칼럼의 선택사양을 결정한다

2) 일대일(1:1) 관계에 의해서 생긴 모든 외래키 부분은 Unique Key가 필수적이다.

3) 일대다(1:M) 순환관계는 데이터의 계층구조를 표현하기 위한 수단으로 사용되며 특성상 1쪽, M쪽 양방향 모두 Optional이다.

 

#논리 데이터 모델에서 베타적 관계를 물리 데이터 모델로 변환하는 방법은 크게 외래키 분리 방법과 외래키 결합 방법으로 나눌 수 있다. 두 방법에 대한 설명

1) 외래키 분리 방법에서 가장 큰 단점은 새로운 관계를 추가 할 때 구조가 변경되어야 한다는 것이다.

2) 외래키 분리 방법에서는 논리 데이터 모델의 배타적 관계를 비즈니스 규칙으로 구현하기 위해서 별도의 제약조건을 생성할 필요가 있다.

3) 외래키 결합 방법은 배타적 관계에 참여하는 관계들을 구분하기 위해서 추가적인 칼럼이 필요하다.

 

#논리 데이터 모델의 특정엔터티를 물리 데이터 모델에서 분할할 때에 대한 설명

1) 하나의 테이블의 데이터가 너무 많고, 레코드들 중에서 특정 범위만 주로 엑세스 하는 경우가 많다면 수평분할이 적절하다.

2) 수평분할 시에 분할된 각 테이블들을 서로 다른 디스크에 위치시키면 물리적인 디스크 효용성을 극대화할 수 있다.

3) 테이블의 칼럼 수가 너무 많고, 조회 위주의 칼럼과 갱신 위주의 칼럼이 구별될 수 있으면

수직분할이 유리하다.

 

#파일 시스템과 데이터베이스 시스템의 가장 큰 차이점 - 데이터(정보) 공유