태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

서브타입을 설계할 때는 특정 시점을 기준으로 설계하기 때문에 변경이력 데이터를 포함시키지 않고 현재 시점의 데이터로 판단한다.

 

서브타입이 배타 서브타입인지 중복 서브타입인지는 특정 시점을 기준으로 판단한다. 특정 시점에 어느 하나의 서브타입에만 속하는지(배타 서브타입) 여러 서브타입에 속할 수 있는지(중복 서브타입)에 따라 서브타입의 유형이 정해진다.

 

따라서 과거 데이터인 변경이력 데이터는 제외하고 현재 시점을 기준으로 판단해서 서브타입 유형을 설계한다.

 

데이터 성격이나 업무 요건은 서브타입 간에 중복 데이터가 없어야 하는데 변경이력 데이터로 인해 중복된 것처럼 보이는 경우가 있기 때문에 주의해야 한다.

 

사원은 정규직이거나 임시직이어야 한다는 업무 요건이 있다면, 아래 모델처럼 배타 서브타입으로 설계해야 한다.

 

[그림 사원-배타서브타입]

 

하지만 [그림 사원릴레이션] 릴레이션과 같이 사원유형코드 속성 값이 변했을 때도 같은 릴레이션에서 관리하면, 즉 변경이력 데이터를 같이 관리하면 서브타입 모델에 왜곡이 생길 수 있다.

 

[사원]

#사원번호

사원명

주민등록번호

입사일자

사원유형코드

12345

홍길동

1234567890123

2021-07-07

정규직

67890

이길동

6789012345678

2023-01-02

정규직

23456

홍길동

1234567890123

2028-03-05

임시직

[그림 사원릴레이션]

 

사원 엔터티의 릴레이션이 위와 같을 때, 데이터만으로 판단하면 홍길동은 정규직과 임시직 인스턴스가 동시에 존재하기 때문에 배타 서브타입이 아니다.

 

하지만 첫 번째 인스턴스는 변경이력 성격의 데이터다. 과거에 정규직으로 근무했던 기록으로 현재 시점에서는 죽어 있는 데이터다. ‘홍길동에 대해 현재 시점에 유효한 데이터는 세 번째 인스턴스뿐이다.

 

이력 데이터인 첫 번째 인스턴스가 없다면, 업무 요건을 그대로 반영한 배타 서브타입이 된다. 즉 데이터를 제대로 해석하면 배타 서브타입이 된다.

 

[그림 사원릴레이션] 릴레이션은 변경이력 데이터 때문에 어떤 서브타입인지 혼란스러울 수 있는 릴레이션이다. 업무 요건에 따라서 홍길동이 동시에 정규직이면서 임시직인 상태는 없기 때문에 배타 서브타입이 되도록 설계해야 한다. 그렇게 하려면 아래 릴레이션처럼 변경이력 데이터는 별도의 릴레이션에서 관리하는 것이 명확하다.

 

[사원]

#사원번호

사원명

주민등록번호

입사일자

사원유형코드

67890

이길동

6789012345678

2023-01-02

정규직

12345

홍길동

1234567890123

2028-03-05

임시직

[사원이력]

#사원번호

#변경일자

사원명

주민등록번호

입사일자

사원유형코드

12345

2028-03-05

홍길동

1234567890123

2021-07-07

정규직

[그림 사원릴레이션2]

 

사원 릴레이션의 서브타입은 배타 서브타입이다.

 

위와 같이 변경이력 데이터를 분리해서 설계하지 못하는 상황이라도, 서브타입이 배타 서브타입인지를 설계하는 기준은 특정 시점이기 때문에 현재 시점에서 업무적으로 중복된 데이터가 없어야 한다면 [그림 사원-배타서브타입] 모델과 같이 배타 서브타입으로 표현한다.

 

배타 서브타입인지 중복 서브타입인지를 판단하는 기준은 특정 시점이며, 변경이력 데이터 때문에 중복 서브타입처럼 보일 수 있다는 것을 주의해서 설계에 반영해야 한다.



 

'데이터 Story > 모델링 매뉴얼' 카테고리의 다른 글

실체 엔터티의 변경이력 엔터티 설계  (0) 2017.03.22
관계 엔터티 설계  (2) 2017.03.09
배타 서브타입 설계  (0) 2017.02.16
실체 엔터티 설계  (0) 2016.12.29
종속 엔터티의 엔터티 명  (0) 2016.12.08
기준 엔터티의 엔터티 명  (0) 2016.12.01
블로그 이미지

블루퍼필

댓글을 달아 주세요

보이거나 만질 수 있는 실제의 물체(物體)를 나타내는 데이터는 실체 엔터티로 설계한다.

 

엔터티를 정의할 때 엔터티에서 관리하는 데이터가 실제로 존재하는 물체인지, 만질 수 있는 물건인지를 가장 먼저 따져서 실체를 나타낸다면 실체 엔터티로 설계한다. 실체 엔터티는 엔터티 명에 실체접미어를 붙인다.

 

[그림1] 서적실체 엔터티는 만질 수 있는 실체인 책을 관리하는 엔터티다.


[그림1]

 

서적실체 엔터티는 실체 엔터티이기 때문에 엔터티 명에 실체접미어를 붙인다.

 

책을 한 권씩 개별적으로 다룬다면 서적실체 엔터티가 필요하다. 바코드 정보가 있어 해당 책을 관리할 수 있다.

 

하지만 서적실체 엔터티에는 책에 대한 이름이나 저자 등과 같은 기본 정보가 없다. 이런 정보는 책을 상징하는 정보로서 실체 정보는 아니다. [그림1] 서적실체 엔터티의 도서번호 속성이 책에 대한 개념 정보를 나타내는 관계 속성이다.

 

책에 대한 개념을 관리하는 도서 엔터티는 아래와 같다.

[그림2]

 

도서 엔터티는 책에 대한 개념을 의미하며, 낱권의 책을 의미하지 않는다. 따라서 실체 엔터티가 아니다. 따라서 엔터티 명에 실체접미어를 붙이면 안 된다.

 

책에 대한 개념과 실체를 관리하는 모델은 아래와 같다.


[그림3]


업무에 따라 도서에 대한 개념을 나타내는 도서 엔터티만 필요할 수 있으며, 낱권의 책인 실체를 관리하는 서적실체 엔터티까지 필요할 수 있다.

 

실체 엔터티는 보이고 만질 수 있는 것(Tangible)을 관리하는 엔터티다. 물체를 관리하는 엔터티가 실체 엔터티다. 노트북, 자동차, 창고, 카드 등이 만질 수 있는 물체다.

 

실체 엔터티는 엔터티의 성격이 명확한데다 중요하게 사용될 수 있기 때문에 설계를 명확하게 해야 한다. 행위의 주체와 대상이 될 수 있는 실체 엔터티가 불분명하면 하위 엔터티와의 관계도 명확하지 않게 된다.


'데이터 Story > 모델링 매뉴얼' 카테고리의 다른 글

관계 엔터티 설계  (2) 2017.03.09
배타 서브타입 설계  (0) 2017.02.16
실체 엔터티 설계  (0) 2016.12.29
종속 엔터티의 엔터티 명  (0) 2016.12.08
기준 엔터티의 엔터티 명  (0) 2016.12.01
역할 엔터티의 엔터티 명  (0) 2016.11.18
블로그 이미지

블루퍼필

댓글을 달아 주세요

엔터티에 속한 속성이 많을 때, 성능이나 관리 측면에서 좋지 않은 영향을 미친다면 일부 속성을 별도의 엔터티로 분리할 수 있다.

 

이때 속성 성격에 따른 분리가 아닌 사용 빈도에 따른 분리일 경우, 즉 유사한 성격의 속성으로 분리할 수 없고 자주 사용되는 않는 속성, 덜 중요한 속성으로 분리할 때는 엔터티 명을 상위 엔터티 명+상세(Suffix)’ 형식으로 정한다.

 

이런 속성으로 구성된 엔터티는 특별한 데이터 성격이 없기 때문에 엔터티 명을 정하기가 어렵다. 이때는 상위 엔터티 명에 상세라는 접미어를 붙어서 정한다.

 

[그림1] 고객 엔터티에 속성이 많아 일부 속성을 별도의 엔터티로 분리해야 한다고 가정한다.


[그림1]

 

엔터티를 속성 기준으로 수직 분리할 때는 유사한 성격의 속성을 분리하는 것이 바람직하지만 속성의 성격으로 분리하기 어려울 때는 [그림2] 고객상세 엔터티처럼 덜 자주 사용돼서 중요하지 않은 속성을 분리해서 설계한다.


[그림2]

 

결혼이나 직장, 학력과 같이 덜 사용되는 속성으로 구성됐기 때문에 엔터티의 성격이 있는 것은 아니어서 엔터티 명을 정하기 애매하며, 고객 엔터티가 이미 존재하기 때문에 구분하기 위해 상위 엔터티인 고객에 접미어 상세를 붙인다.

 

이렇게 분리하면 고객 엔터티에는 자주 사용되는 속성이 존재하며, 고객상세 엔터티에는 자주 사용되지 않는 속성이 존재한다.

 

엔터티 명을 정하는 기준은 데이터의 성격이다. 데이터의 본질적 성격을 나타내야 한다. 하지만 자주 사용하지 않는 것은 데이터의 성격을 나타내는 것이 아니기 때문에 이런 속성으로 구성된 엔터티는 엔터티 명을 정하는 기준이 없는 것이다. 따라서 데이터 성격이 나타나지 않는 경우에는 엔터티 명을 정하기가 곤란해진다. 그래서 부득이하게 상세라는 접미어를 정해 이런 경우에 사용한다.

 

또한 고객 엔터티와 같은 주요 엔터티는 자주 사용되는 속성만으로 구성하는 것이 바람직하다. 가끔 사용되는 속성이나 널(Null) 값이 대부분인 속성은 원 엔터티에서 제외시키는 게 효과적이다.

 

물론 중요한 속성만을 사용하는 것이 아니고 전체 속성 위주로 사용한다면 굳이 엔터티를 분리할 이유는 없다. 적절한 이유 없이 엔터티가 많은 것은 바람직하지 않다.

 

주의할 것은 고객상세 엔터티에 자주 사용되지 않는다는 이유로 고객의 본질을 나타내는 기초 속성을 옮기면 안 된다는 것이다.

 

또한 분리한 속성이 특정 성격을 나타낸다면 해당 데이터 성격에 맞게 엔터티 명을 정해야 한다. 특정 성격의 데이터인데도 불구하고 데이터 성격을 표현하지 않고 ‘~상세접미어를 붙이면 안 된다.

 

[그림2] 고객상세 엔터티처럼 엔터티 명을 특정하게 정할 수 없을 때만 어쩔 수 없이 상세접미어를 붙여 고객 정보라는 정도만을 알 수 있도록 한다.



'데이터 Story > 모델링 매뉴얼' 카테고리의 다른 글

배타 서브타입 설계  (0) 2017.02.16
실체 엔터티 설계  (0) 2016.12.29
종속 엔터티의 엔터티 명  (0) 2016.12.08
기준 엔터티의 엔터티 명  (0) 2016.12.01
역할 엔터티의 엔터티 명  (0) 2016.11.18
소속 엔터티의 엔터티 명  (0) 2016.11.05
블로그 이미지

블루퍼필

댓글을 달아 주세요

기준 엔터티는 기준 데이터임을 명확하게 구분하기 위해서 엔터티 명에 기준이라는 단어를 접미어(Suffix)로 붙인다. 그리고 접미어 앞에는 데이터 성격을 나타내는 명사형의 단어를 사용하며, 필요 시 명사형 단어 앞에 수식어를 사용한다.

 

[그림1] 환율기준 엔터티는 기준 정보로서 환율 데이터를 관리하는 엔터티다.


[그림1]

 

기준 데이터로 관리하려는 대상이 환율이기 때문에 환율은 데이터의 성격을 나타내는 명사형의 단어다. 데이터 성격은 기본 속성을 보면 알 수 있다. 기본 속성이 환율을 의미하기 때문에 데이터 성격을 나타내는 명사형의 단어는 환율이다. 그리고 명사형의 단어 앞에 수식어가 필요 없기 때문에 접미어인 ‘~기준을 사용해 환율기준이라고 붙인다.

 

[그림2] 고객수수료율기준 엔터티는 고객에 대한 수수료율을 관리하는 엔터티다.


[그림2]

 

데이터 성격을 나타내는 용어인 수수료율에 접미어인 기준을 붙여서 엔터티 명을 정한다. 수수료 중에서 고객의 수수료를 관리하기 때문에 고객을 수식어로 사용해 고객수수료율기준으로 엔터티 명을 정한다.

 

[그림3] 국가세율기준 엔터티는 국가에서 정한 기준 세율을 관리하는 엔터티다.


[그림3]

 

세율을 나타내는 수식어인 국가와 기준 데이터의 성격을 의미하는 세율’, 그리고 접미어 기준을 붙여서 국가세율기준으로 엔터티 명을 정한다.


기준 엔터티는 업무를 할 때 참조하는 데이터를 의미한다. 실체나 행위 데이터의 기준이 되는 데이터로 참조(Reference) 엔터티라고도 하는 기준 엔터티는 실체 엔터티와 비슷한 면이 많다. 실체 엔터티가 보이는 것을 관리하면 기준 엔터티는 개념적인 것을 관리한다. 엔터티 개수가 많지 않으며, 데이터 건수도 많지 않다. 기준이 되는 데이터이기 때문에 품질과 직결된다. 따라서 구별해서 지속적으로 인지할 수 있도록 엔터티 명에 기준접미어를 붙인다.



'데이터 Story > 모델링 매뉴얼' 카테고리의 다른 글

실체 엔터티 설계  (0) 2016.12.29
종속 엔터티의 엔터티 명  (0) 2016.12.08
기준 엔터티의 엔터티 명  (0) 2016.12.01
역할 엔터티의 엔터티 명  (0) 2016.11.18
소속 엔터티의 엔터티 명  (0) 2016.11.05
실체 엔터티의 엔터티 명  (0) 2016.10.13
블로그 이미지

블루퍼필

댓글을 달아 주세요

실체의 본질적인 성격이나 특성을 관리하는 엔터티가 아닌, 실체가 하는 역할을 관리하는 엔터티의 이름은 대상 실체 엔터티 명+역할 의미+담당 실체 엔터티 명형식으로 정한다.


즉 양쪽 실체 엔터티 명(실체라는 접미어를 제외한 명)과 실체가 하는 역할을 의미하는 단어를 사용해서 엔터티 명을 정한다. 이 엔터티는 실체 자체를 의미하지 않으므로 엔터티 명에 접미어 실체를 붙이지 않는다.

 

[그림1] 계좌관리사원 엔터티는 계좌를 관리하는 역할을 하는 사원을 관리하는 엔터티다.

[그림1]

 

계좌를 관리하는 사원이든, 사원에게 관리되는 계좌이든 실체 자체를 의미하지 않고, 실체의 역할을 의미한다. 역할을 담당한 실체는 사원이기 때문에 ‘~사원처럼 엔터티 명을 정하며 관리라는 역할의 대상은 계좌. 따라서 엔터티 명은 계좌관리사원이 된다. 계좌관리사원 엔터티는 실체 자체를 나타내지 않기 때문에 ‘~실체라는 접미어를 붙이지 않는다.

 

대상 실체 엔터티 명+역할 의미+담당 실체 엔터티 명형식으로 엔터티 명을 정할 때 역할을 의미하는 단어 앞에는 역할에 대한 대상 실체를 나타내는 엔터티 명을 사용하고, 뒤에는 역할을 담당한 실체를 나타내는 엔터티 명을 사용한다.

 

[그림2] 프로젝트수행사원 엔터티는 프로젝트를 수행한 사원을 관리하는 엔터티다.

[그림2]

 

대상 실체 엔터티 명+역할 의미+담당 실체 엔터티 명형식으로 엔터티 명을 정할 때, 역할을 의미하는 용어는 수행이며, 프로젝트를 수행한 것이기 때문에 수행에 대한 대상인 프로젝트수행앞에 사용하며, ‘수행이란 역할을 담당한 것은 사원이기 때문에 사원을 뒤에 사용해서 프로젝트수행사원으로 정한다.

 

엔터티에서 관리하는 데이터가 실체 자체가 아니라 실체가 하는 역할을 의미한다면 실체 엔터티로 정의하지 않는다. 실체 자체를 관리하는 엔터티와 실체를 의미하지만 실체 자체를 관리하는 것이 아닌 실체와 연관된 데이터를 관리하는 엔터티는 구별해야 한다. 후자를 실체 자체로 정의하지 않아야 한다. 자연히 후자일 때는 엔터티 명에 접미어인 ‘~실체를 붙이지 않는다.



 

블로그 이미지

블루퍼필

댓글을 달아 주세요

실체 자체를 관리하는 엔터티가 아닌, 실체의 소속 데이터를 관리하는 엔터티의 이름은 대상 실체 엔터티 명+소속 실체 엔터티 명형식으로 정한다. 엔터티 명 앞에는 어디에 소속됐는지를 의미하는 대상 엔터티를 사용하고, 뒤에는 소속된 엔터티를 사용해서 정한다.

 

위와 같이 소속을 나타내는 데이터는 실체 엔터티가 아니기 때문에 실체접미어는 붙이지 않는다.

 

[그림 도서관직원] 도서관직원 엔터티는 도서관에 소속된 직원을 관리하는 엔터티다.

 

[그림 도서관직원]

 

도서관직원 엔터티에서 관리하려고 하는 데이터는 직원 데이터인데, 도서관에 소속된 직원이다. 따라서 소속된 실체는 직원이고 어디에 소속됐는지를 의미하는 대상은 도서관이므로 엔터티 명은 도서관직원으로 정한다.

 

[그림 예산부서사원] 예산부서사원 엔터티는 예산 부서에 속한 사원을 관리하는 엔터티다.

 

[그림 예산부서사원]

 

예산부서사원 엔터티는 사원을 의미하지만 사원 자체 데이터를 관리하는 엔터티는 아니다. 사원 데이터는 별도로 존재해야 하며, 사원이 어디에 소속됐는지를 나타낸다.

 

이렇게 실체의 소속 개념을 관리하는 엔터티는 실체 엔터티가 아니라 관계 엔터티나 내역 엔터티에 가깝다. 엔터티 명 역시 그에 맞게 정해야 한다. 사원을 관리한다고 예산부서사원실체 등으로 정하면 안 된다. 예산을 관리하는 부서에 소속된 사원을 의미하는 엔터티 명으로 예산부서사원, 예산부서소속사원, 예산부서관계사원 등이 적절하다.

 

실체의 역할을 관리하는 엔터티와 마찬가지로 실체의 소속을 관리하는 엔터티 명 또한 실체 엔터티로 정하지 않아야 한다. 소속 데이터를 실체 엔터티로 정하면 모델이 전반적으로 혼란스러워진다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

실체 엔터티는 실체 엔터티임을 명확하게 구분하기 위해서 엔터티 명에 실체라는 단어를 접미어(Suffix)로 붙인다. 그리고 접미어 앞에는 엔터티 성격을 나타내는 명사형의 단어를 사용한다.

 

[그림 실체엔터티명] 장비실체 엔터티는 장비를 관리하는 엔터티다.

  

[그림 실체엔터티명]

 

장비실체 엔터티는 장비라는 만질 수 있는(Tangible) 실제의 물체(物體)를 관리하는 엔터티로 실체 엔터티다. 명사형인 장비와 접미어인 실체를 붙여 장비실체로 엔터티 명을 정한다.

 

명사형과 동사형의 단어를 구분하는 방법은 ‘~했음을 붙여 자연스러우면 명사형이 아니라 동사형이다. ‘장비라는 단어는 명사형이기 때문에 ‘~했음을 붙이면 의미가 통하지 않는다. ‘~했음을 붙여 의미가 통하는 동사형의 단어는 행위 엔터티에 사용한다.

 

엔터티 명에는 엔터티의 종류를 나타내는 접미어를 사용하지 않는 것이 바람직하지만, 실체 엔터티는 대개 핵심 엔터티이기 때문에 지속적으로 관리하기 위해 엔터티 명을 분명하게 구분하는 것이 의미가 있다. 추후에 실체 엔터티만을 뽑아서 검증할 수도 있고, 모델링 중에도 지속적으로 인지할 수 있어 엔터티를 잘못 설계하는 오류를 최소화할 수 있다.

 

또한 엔터티 정의를 명확하게 하는 효과도 있다. 실체 엔터티 명에 ‘~실체라는 접미어를 붙이면, 엔터티 명에 엔터티의 성격이 포함돼 있어 엔터티 정의가 더욱 명확해진다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

 

엔터티의 주 식별자는 다른 엔터티의 외래 식별자(Foreign Identifier)가 되며, 외래 식별자 값에는 주 식별자에 존재하는 값을 사용해야 한다. 따라서 만약 주 식별자 속성 값이 바뀌면 그 값을 사용한 하위 엔터티의 외래 식별자 속성 값도 바꿔야 한다. 그래야 참조 무결성이 지켜진다.

 

하지만 외래 식별자 속성 값을 바꿔주는 것은 쉽지 않다. 대상 엔터티가 한없이 늘어날 수 있으며, 해당 엔터티의 인스턴스도 정확히 지정해야 하기 때문에 쉽지 않은 작업이다. 잘못된 설계로 인해 불가피하게 외래 식별자 속성 값을 바꿔주는 작업을 하는 경우는 있지만, 그렇게 하도록 설계하는 것은 그 자체로 잘못된 설계다.

 

주 식별자 속성 값이 바뀌지 않도록 주 식별자를 선정하는 것은 주 식별자 선정의 중요한 원칙이다. 또한 원칙적으로 주 식별자로 사용되는 업무 식별자는 값이 수정되지 않는다. 업무 식별자의 값은 인스턴스를 발생시키는 기준이 되는데, 그 기준 값이 변경되는 것은 일종의 모순이기 때문이다.

 

[그림1] 고객 엔터티의 주 식별자가 주민등록번호 속성이지만, 암호화 문제가 없다고 하더라도 주민등록번호는 변경될 수 있기 때문에 주 식별자로 적절치 않다.

 

[그림1]

 

만약 ‘홍길동’의 주민등록번호가 ‘123456-7890123’에서 ‘123456-7890128’으로 바뀌면 ‘123456-7890123’ 주민등록번호를 사용한 주문 엔터티나 고객주문집계 엔터티의 외래 식별자 속성 값도 수정해야 ‘홍길동’ 고객이 주문했던 내역도 찾을 수 있고 주문 집계도 구할 수 있다.

 

타 엔터티에 존재하는 값을 어쩔 수 없이 바꾸는 일이 없도록 [그림2] 고객 엔터티와 같이 값이 변하지 않을 속성을 주 식별자로 사용해야 한다.

 

[그림2]

 

위와 같은 이유로 비록 업무 식별자 성격일지라도 이메일 주소나 휴대전화번호를 엔터티의 주 식별자로 사용하는 것도 바람직하지 않다.

 

소속 부서도 주 식별자에 자주 포함되는 속성인데, 소속 부서와 같은 소유의 개념이 있다면 소유가 바뀔 때 주 식별자 값도 바뀌게 된다. 바뀔 수 있는 소속 부서는 주 식별자가 아닌 일반 속성으로 관리해야 한다.

 

명이나 내용 같은 텍스트도 값이 변할 수 있기 때문에 주 식별자로는 적절치 않다. 횟수/수량/금액/여부 등도 변할 수 있는 값으로서 주 식별자로 적절하지 않다.


 

블로그 이미지

블루퍼필

댓글을 달아 주세요

사원 엔터티의 업무 식별자는 주민등록번호 속성만이 되도록 설계한다. 그래서 퇴사한 후 재입사하더라고 같은 식별자를 사용하기 때문에 다른 사원이 되지 않도록 한다.

 

만약 퇴사한 사원이 재입사했을 때 다른 사원으로 인식한다면, 즉 사원번호가 달라진다면 사원 엔터티의 업무 식별자는 주민등록번호+입사일자가 된다. [그림1] 릴레이션이 이를 나타낸다.

 

[사원]

#사원번호

사원명

주민등록번호

입사일자

퇴사일자

12345

홍길동

1234567890123

2032-01-01

2042-12-31

23456

김길동

2345678901234

2025-01-30

{null}

34567

이길동

6789012345678

2027-10-15

{null}

45678

홍길동

1234567890123

2045-05-01

{null}

 

[그림1]

 

업무 식별자가 주민등록번호+입사일자이기 때문에 2032년에 입사했다가 2042년에 퇴직한 홍길동 2045년에 다시 입사하면 홍길동의 사원번호는 두 개가 된다. 이는 홍길동을 두 개의 인스턴스로 관리하는 것이며, 다른 사원을 의미하는 것이기도 하다.

 

‘45678’ 사원번호는 현재 사용하고 있는 사원번호이고, ‘12345’ 사원번호는 과거에 사용했던 사원번호를 나타내는데, [그림1] 릴레이션처럼 관리할 때의 문제는 같은 사람의 사원번호가 두 개라는 점이다. 사원번호는 시스템에서 광범위하게 사용되는데, ‘홍길동의 사원번호가 두 개라면 데이터를 통합 관리하는 데 문제가 된다. 우선 집계할 때 어떤 식으로든 복잡해진다.

 

또한 사원 엔터티에 대한 정의와도 연관된다. 사원에 대한 일반적인 정의라면 한 사람에 대한 사원번호가 한 개만 존재하는 것이 바람직하다.

 

[그림2] 릴레이션과 같이 한 번 부여된 홍길동의 사원번호는 재입사 여부와 무관하게 지속적으로 사용해야 한다. 입사일자, 퇴사일자 등 변경 사항은 사원이력 엔터티에서 별도로 관리한다.

 

[사원]

#사원번호

사원명

주민등록번호

입사일자

퇴사일자

12345

홍길동

1234567890123

2045-05-01

{null}

23456

김길동

2345678901234

2025-01-30

{null}

34567

이길동

6789012345678

2027-10-15

{null}

 

[사원이력]

#사원번호

#변경일자

사원명

주민등록번호

입사일자

퇴사일자

12345

2045-05-01

홍길동

1234567890123

2032-01-01

2042-12-31

 

[그림2]

 

[그림2] 릴레이션은 사원 개별로 하나의 사원번호만 존재한다는 것을 나타내므로 업무 식별자는 주민등록번호 속성 하나다.

 



 

블로그 이미지

블루퍼필

댓글을 달아 주세요

업무가 변경될 가능성이 있을 때는 이를 대비해서 모델을 유연하게 만드는 인조 식별자를 주 식별자로 설계한다.

 

[그림1] 계좌 엔터티의 주 식별자인 세 개 속성을 붙여서 계좌번호로 사용한다.

 

[그림1]

 

현재 업무에 의해서 계좌번호는 10자리 번호이며, 이를 3-2-5 체계로 구성해서 주 식별자를 세 개의 속성으로 설계했지만 향후에 계좌번호 체계가 3-8 등으로 바뀔 수 있으며, 상품번호 자체가 3자리로 변경될 수 있다면 [그림1] 계좌 엔터티로는 대처하기 어렵다.

 

위와 같이 업무가 바뀜으로써 주 식별자까지 변경되는 상황을 방지하기 위한 방법 중 하나가 [그림2] 계좌 엔터티처럼 인조 식별자를 사용하는 것이다.


 

[그림2]

 

[그림2] 계좌 엔터티와 같이 인조 식별자를 사용하면, 체계가 3-2-5에서 3-8 정도로 변경돼도 자릿수만 늘리면 되므로 모델 변경이나 프로그램 변경을 최소화할 수 있다. 상품번호가 3자리로 늘어나면 3-3-4로 할 수 있는 등 [그림1] 계좌 엔터티보다 변화에 대처하기 수월하다.

 

업무가 변경될 가능성이 있을 때는 인조 식별자를 사용하는 것이 모델을 확장하기 좋은 유연한 모델을 만드는 방법이다.

 

만약 업무 식별자를 주 식별자로 사용한 상태에서 주 식별자를 변경해야 할 정도로 업무가 바뀌었을 때 해당 엔터티의 하위 엔터티가 있다면 주 식별자를 변경하기 사실상 어렵다. 이때 인조 식별자를 사용한 상태라면 주 식별자는 변경하지 않고, 업무 식별자에 생성한 유니크 인덱스만 변경하면 된다. 업무가 바뀌더라도 주 식별자가 바뀌지 않는다면 감당할 수 있는 정도다.

 

인조 식별자를 사용하는 주요 이유는 두 가지다. 업무(후보) 식별자가 복잡하면서 하위 엔터티가 많을 때 인조 식별자를 사용해서 모델을 단순하게 만드는 게 주요 이유다.

 

또 다른 이유는 모델을 의도적으로 유연하게 만들기 위해서다. 하나의 속성으로 구성된 인조 식별자는 주로 무의미하게 증가하는 번호를 사용하기 때문에 업무 식별자와 직접 연관이 없다. 따라서 자유롭게 사용할 수 있어 모델이 유연해진다.



 

블로그 이미지

블루퍼필

댓글을 달아 주세요