식별자 종류 Part 1.

대리식별자는 주식별자로 선택되지 않은 후보식별자다. 대체식별자라고도 한다.

후보식별자 : 사원주민등록번호, 휴대전화번호, 이메일주소, 고객번호

주식별자를 고객번호로 선정한다면 나머지는 대리식별자(사원주민등록번호, 휴대전화번호, 이메일주소)

 

주식별자로 선정되지 않은 후보식별자가 대리식별자이므로 인조식별자를 주식별자로 사용하면 모든후보식별자가 대리식별자가 된다. 즉 인조식별자가 사용되면 후보식별자와 대리식별자는 같다. 

 

대리식별자 선정과정

후보식별자를 선정한다. 후보식별자가 여러개 존재할 수 있다.

후보식별자 중에 주식별자로 선정할 후보가 있는지를 판단한다.

후보식별자 중에 주식별자가 있다면 나머지는 대리식별자가 된다.

후보식별자 중에 주식별자가 없다면 인조식별자를 채택한다

인조식별자를 채택하면 모든 후보식별자는 대리식별자가 된다.

 

대리식별자 속성값은 릴레이션에서 유일해야 하며, 이를 물리적인 제약으로 관리하기 위해 유니크인덱스를 생성한다. 그래야 엔터티에 데이터가 잘 못 입력되는 것(중복된 값이 입력되는 것)을 원천적으로 방지할수 있다. 만약 인조식별자가 사용됐다면 대리식별자는 인스턴스가 생성되는 기준이 되기 때문에 더욱 유니크인덱스로 관리해야 한다.

 

 

슈퍼식별자

주식별자에 다른 속성을 추가해서 만든 식별자를 의미한다. 따라서 엔터티에서 슈퍼식별자는 많이 존재할 수 있다.

슈퍼식별자를 구성하고 있는 속성중에서 새로운 인스턴스를 생성하는데 영향을 미치지 않는 속성을 제외하면 후보식별자가 된다. 

슈퍼식별자가 자주 사용되는 이유는 조회조건 속성을 모두 인덱스에 포함시켜 커버링인덱스를 생성하기 때문이다. 

주식별자 분석 미흡해서이다.

주식별자는 인스턴스를 생성하는 기준과 인스턴스를 식별하는 역활만 해야 한다. 인덱스의 역활하는 것은 주식별자가 아니다. 슈퍼식별자를 사용하면 엔터티 성격이 불분명해진다.

인스턴스를 발생시키는 기준,즉 업무식별자가 명확해야 엔터티 성격이 분명해진다. 슈퍼식별자를 사용하면 데이터 성격이 모호해지면서 엔터티 성격이 변질될수 있다. 자연히 엔터티 관계도 모호해지며 가독성도 떨어진다.

슈퍼식별자는 어떤상황에서도 사용하지 않는다는 것을 원칙으로 해야 한다.

 

속성분류기준 : 실제 엔터티에 존재하는 속성을 기준으로 분류(물리적인 속성을 구분한것)

기초속성/관계속성/추출속성/시스템속성

 

기초속성 

엔터티 본질을 설명하는 속성이 기초속성이다. 기초속성을 보면 엔터티의 정의를 알수 있다. 엔터티에 반드시 존재해야하는 업무식별자와 후보식별자, 엔터티의 특성을 설명하는 속성등이 이에해당한다.

기초속성은 오너십과 연관이 된다. 오너십 중에 엔터티가 어느 주제영역에 속해야 하는지에 대한 오너십이 모델오너십이며 모델오너십을 정하는 기준이 기초속성이다.

 

관계, 추출, 시스템 속성으로는 해당 엔터티의 성격을 알 수 없기 때문에 당연히 기초속성이 기준이 돼야 한다. 기초속성의 값은 주로 데이터베이스를 사용하는 사용자의 입력이라는 행위에 의해서 생성되고, 기초속성의 값을 생성하는 영역에서 모델오너십을 가져야한다.

기초속성은 개념모델링 단계에서 도출되기도 하고, 주로 논리모델링 초반에 도출된다. 가장먼저 도출되어야 하는 속성이 기초속성이다.

속성이 도출되는 순서 기초→관계 → 추출 → 시스템 속성순이다. 모델링 할때 이 순서대로 속성을 추가하면 된다.

 

관계속성

 

관계도 속성이다. 관계속성은 다른 엔터티와의 관계를 알기 위해 사용하는 외래식별자 속성이다. ERD에서 관계선이 생략 될수있어도 관계속성이 생략되면 안된다. 관계선을 생략하는 것은 바람직하지 않지만 치명적이지는 않다. 하지만 관계속성을 생략하는 것은 치명적이다.

관계속성이 사용된 모델

관계속성은 여러개 있는 엔터티가 대부분이지만 하나도 없는 엔터티도 있다.

관계속성은 두가지로 나눌수있다.

참조되는 엔터티와 존재 종속 관계면 관계속성은 엔터티의 본질을 의미하므로 기초속성이기도 하다

ex) 주문상품 엔터티의 주문번호 속성은 관계속성이면서 기초속성

엔터티 간 관계가 존재종속 관계가 아니고 단지 참조만 하는 관계라면 관계속성은 기초속성이 아니다.

ex)주문엔터티의 담당사원번호 단지 참조만 하는 관계속성.담당사원번호 속성을 삭제해도 주문엔터티는 존재할 수 있다.

 

상위엔터터의 주식별자를 식별자로 상속받을때 그 속성은 기초속성이면서 관계속성이고, 일반속성으로 받을때는 관계속성뿐이다.

관계속성은 참조되는 엔터티의 주식별자 속성이기에 대부분 핵심속성이다. 

 

추출속성

- 추출속성은 이미 존재하는 속성(원본속성)으로 재생할 수 있는 속성이다.

- 원본속성 값을 연산해서 생성 할 수 있는 속성. 원본속성에 종속되어 있는 속성(파생속성)

- 추출속성 사용 목적 : 데이터 조회 시간 단축 목적이 가장 크다. 한번 저장해 놓으면 반복해서 계산하는 일이 줄어들기 때문에 성능향상에 도움이 된다.

 

 

모든 속성은 원본속성 아니면 추출속성으로 나눌 수 있다.

추출속성은 원본속성과 같은 엔터티에 존재할 수도 있고, 다른 엔터티에 있을 수도 있다. 같은 엔터티에 존재한다는 것은  연산하는 대상 인스턴스가 주로 하나라는 것을 의미하고, 서로다른 엔터티에 존재한다는 것은 연산하는 대상 인스턴스가 통하나 이상이라는 것이다.

예시) 추출속성 

- 고객엔터티에 최종주문일자(하위엔터티 주문일자 max값)

- 주문엔터티에 주문총금액 속성 (하위엔터티인 인스턴스를 합한 값) -----> 성능상 문제가 있을때만 사용

- 주문상품 엔터티 주문금액 속성(같은 엔터터에 주문단가*주문수량 값)---> 사용하지 않는 것이 원칙 (같은 엔터티이기에 성능향상과 거의 관계가 없다) 성능고려하여 계산해둘 필요 없다.

 

추출속성 사용시 유의사항

- 정합성 데이터 품질이 떨어질수 있다. 중복속성은 데이터가 같아야 하지만, 추출속성은 계산된 값이기 떄문에 식별하기 어렵다. 성능 문제로 어쩔수 없이 추출속성을 사용한다면 정합성은 맞춰야 한다. 

- 추출속성을 주식별자로 사용하면 안된다. 이런 파생속성은 결정자가 될 수 없다. 원본속성이 변경되지 않는다고 해도 바람직하지 않다.

- 추출속성은 다른값에서 재현할 수 있는 속성인데, 만약 재현할 수 없다면 추출속성이 아니다. 단지 다른속성을 사용해서 계산했다고 추출속성인것은 아니다.

두번째 모델에 상품엔터티의 단가속성은 현재시점의 단가이기 때문에 주문상품 엔터티의 주문수량과 상품엔터티의 단가를 사용해서 주문금액을 재생할 수 없다. 첫번째 모델인 주문상품 엔터티처럼 그 시점의 주문단가 속성이 있어야 주문금액을 재생할 수 있다. 세번째 모델처럼 상품이력엔터티가 있다면 주문상품 엔터티의 주무금액 속성은 재생할 수 있다. 하지만 주문상품엔터터의 주문일자에 해당하는 시점의 단가를 상품이력 엔터터에서 찾아야 하기 때문에 쿼리가 복잡해진다. 만약 주문상품엔터티에 주문단가속성을 추가하면 추출속성인 주문금액은 추출속성이므로 삭제되어야 한다.

 

추출속성은 모델ERD에서 관리해야 한다. case 툴에서 원본속성과 연산규칙을 지정해 관리할 수 있도록 한다. 툴에서 지원이 안되면 속성설명에 원본속성과 연산규칙을 기술해야 한다. 추출속성은 반드시 하나 이상의 속성에 종속되어야 한다.

 

추출속성이지만 중요하게 관리되어야 하는 속성은 잔고, 잔금 속성이다. 이론적으로는 추출속성이지만 원본내역에서 매번 계산해야하기 때문에 추출속성으로 채택해 미리 계산해서 사용한다. 이런속성은 기초속성이기도 해서 개념모델에서 부터 관리되어야 하는 핵심속성이다.

 

시스템속성

시스템 속성은 데이터에 대한 추적감시를 위해 사용하는 속성이다. 해당 데이터를 누가 언제 생성하고, 수정했는지 관리하는 속성이다. 시스템속성은 전체데이터에 존재하며, 엔터티마다 같은목적으로 사용된다. 모든데이터에 4-10정도의 시스템 속성을 존재하기 때문에 일정부분을 차지하는 속성이다. 시스템속성은 가능한 적어야 좋다. 데이터추적을 정말하게 하려고 많은 속성을 사요하면 모델관리가 불편해지며, 성능에도 영향이 미친다. 시스템속성은 데이터 추적할 수 있는 용도로만 사용하는 것이 바람직하다. 시스템속성에 업무적으로 의미를 부여해서 사용하는것은 좋지 않으며, 시스템속성을 삭제하고도 업무에 지장을 주지 않도록 설계하는 것이 좋다.

 

시스템 속성은 전체 엔터티에 공통으로 존재하는 속성이고, 업무용도로 사용하지 않아야 한다.

- 데이터 추적용도로만 사용하며,

- 가능한 개수는 적게,

- 논의는 가능한 빨리,

- ERD에는 가장 나중에 추가하는 것이 좋다.

 

중복속성

중복속성은 말 그대로 이미 존재하는 속성의 값을 중복해서 사용하는 속성이다. 어떤 엔터티가 존재하는 속성값을 복사해서 그대로 가져다 놓고 사용하는 속성을 의미한다. 중복속성은 주로 상위엔터티에서 하위엔터티로 복사해 놓은 속성이다. (주된이유는 조인을 피하기 위해서)

상위엔터티와 조인을 하지 않으려는 이유

- 조인하면 조회성능이 떨이지기 때문(OLTP는 극소IO가 발생하므로 조회성능이 떨어지는 경우가 많지 않다)

-조인이 불편하기 때문(데이터 정합을 생각하면 오히려 조인이 편한방법이다)

중복속성 사용한 모델

 

계좌엔터티에 주민등록번호는 중복속성이다. 고객엔터티와 조인을 하지 않으려고  중복으로 복사해 놓은건데,  만약 주민등록번호가 변경된다면 주민등록번호를 사용한 모든 엔터터의 값을 변경해줘야 한다. 주민번호와 같은 식별번호는 정합성을 반드시 맞춰야 한다. 원칙대로  조인으로 주민등록번호를 사용했다면 고객엔터티의 주민등록번호값만 변경하면 된다.

 

추출속성은 효과적으로 사용할 여지가 있지만, 중복속성을 사용하면 얻는 것에 비해 잃은것이 크다. 중복속성값은 시간이 흐를수록 데이터 정합성에 속성값이 맞는지 확신할 수 없기 때문에 사용하지 않아야 한다.

 

시점데이터가 중복속성이다?

시점데이터란는 그 당시의 값을 알기위해 관리되어지는 데이터이다. 이력으로 관리하지 않고  시점데이터로 관리하는 것이다. 이력데이터로 관리하지 않을때 시점데이터로 관리된다. 

 

과거시점을 관리하는 계좌 엔터티

 

계좌엔터터의 고객명은 계좌개설할때 고객명을 의미할 수 있다. 만약 그 당시의 데이터를 관리한다면 중복속성이라고 볼수 없다. 만약 고객이 이름을 개명했을때 고객엔터티의 고객명은 변경해야 하지만 계좌엔터티의 고객명은 변경하면 안되기 때문이다. 만약 최근값으로 업데이터한다면 보관하려고 하는 그당시의 이름은 사라지게 된다. 이력 데이터를 관리하지 않는 모델에서 계좌 엔터티의 고객명 속성을 삭제해서는 안된다. 중복속성으로 판단해서 삭제하면 이력데이터 역활을 하는 시점데이터는 사라지며, 요건을 만족하지 않게 잘못 설계한 모델이 된다.

 

고객이력 엔터티에 여러개  존재할 수 있는 인스턴스를 대상으로 계좌개설 시점에 해당하는 고객명을 가져와야 하므로 계좌엔터티의 고객명은 추출속성이다. 다른속성값을 그대로 복사해 놓은 중복속성이 아니다. 로직을 사용해서  고객명이 변경된적이 있는지 구하고, 있다면 고객이력데이터에서 계좌개설일자와 고객변경이력데이터를 확인해서 데이터를 구해야 한다.

 

계좌 엔터티의 고객명 속성은 데이터 성격상 추출속성이므로 성능문제가 없다면 삭제해야 하는 것이 맞지만, 계좌 개설 시점의 고객명이 자주 조회도고, 조금이라도 빨리 조회해야 한다면 추출속성을 사용해야 한다.

 

중복속성을 사용할 수 있는 경우(성능과 무관하게)

- 변하지 않는 속성일때

- 관계비가 1:1일때

- 관계가 종속관계일때(참조관계보다) 

참조관계는 상위엔터티는 실체엔터티, 하위엔터티는 트랜잭션데이터 관리하는 행위엔터티이다, 행위엔터티는 많은 하위엔터티를 갖고있으므로 변경이 발생하다면 영향도가 커진다.  종속관계일떄는 인스턴스가 적으므로 중복데이터도 작게 발생한다. 중복데이터의 용량을 줄이는것 , 중복속성의 길이도 가능한 짧은 것이 좋다.

 

종복속성 유의할 점

- 업데이트가 발생하면 사용하지 말자

- 공간을 많이차지하는 부분

- 모델의 가독성이 떨어지는 문제

- 속성의 본직절 의미가 희석되는 문제.

 

단일값속성과 다가속성

단일값 속성 : 한시점에 하나의 값을 가지는 속성. 데이터는 원자값이어야 한다는 원칙을 지친 정상적인 속성

ex) 나이

다가 속성 : 유사한 성격의 값을 복수로 가지고 있는 속성, 한 속성에 유사한 종류의 값이 여러개 존재하는 속성.여러개의 값을 한 속성에 물리적으로 저장하는 것.

ex)전화번호(두개이상 세부속성으로 구성된 속성)

물리적으로 하나의 값을 가지는데 여러종류의 값을 의미할때가 있다. 고객전화번호 속성에 집전화번호나, 사무실전화번호를 저장하여 사용하는데 속성명을 구체적으로 정의하지 않아서 발생하는 것이다. 고객집전화번호, 고객사무실전화번호, 분리해서 상세하게 정의하는 것이 좋다.

의도적으로 다가속성을 사용하는 경우

- 한속성에  상태구분에 따라 다른값이 들어가는 경우(한속성에 가입일자. 탈퇴일자 같이 관리하는 경우 상호배타속성)

- 업무규칙이 변경되지 않는 경우 (개수가 한정되어 있을경우)

- 개념이나 초기 논리 모델에서는 다가속성 사용할때도 있다.(속성이 구체화되기전 고객 취미,부양자 우편번호)

다가속성은 모델링 과정에서 발생할 수 있다. 하지만 최종 물리모델에서 다가속성이 존재하면 잘못된 모델이다. 물리모델에서 여러개속성으로 분리하던지, 별도의 1정규형 엔터티로 분리해야 한다.

 

단순속성과 복합속성

단순속성 : 더이상 분해될 수 없는 원값으로 이뤄져야 한다는 기본원칙이 부합되는 속성. 이때 원자값은 논리적으로 의미가 있어야 한다.

년월일 나누는 것이 의미가 있을까? 시분초 나누는 것은의미가 있을까? 무조건 나눈다고 단순속성이 되는게 아니라  의미가 있어야 단순속성이다

복합속성 : 여러의미를 가지는 속성. 두개이상의 의미있는 단순속성으로 분해할 수 있는 속겅을 말한다. 나눠서 의미가 있느냐/ 나눠서 의미가 없다면 속성은 아니다. 업무에서 사용하느냐? 

ex) 전화번호속성: 국번+번호 , 고객주소 시구동 나누속성도 의미가 있기때문에 복합속성이다. 하지만 업무에서 사용하지 않는다면 의미가 있더라도 나누지 말아야 한다.

실무에서 많이 보는 복합속성 인조식별자다.계좌번호에 지점번호가 포함돼 있다면 복합속성이다.

ex) 계좌번호10자리=지점번호(4자리)+순번(6자리)

다가속성과 복합속성 차이

다가속성은 각 자리가 의미하는 바가 동일 , 자리값으로 관리하는 건 다가속성 , ex) 취미 101,102,103

복합속성은 각 자리가 의미하는 바가 다름. 속성2자리 =결혼여부(1)+ 자녀수(1) 

텍스트 속성도 복합속성이다. 텍스트에 이름 전화번호 주소등 특정 도메인으로 도출될수 있는 내용이 텍스트에 있다면 분리하게 바람직하다. 텍스트로 뭉쳐져 있는 경우 조회용으로 사용하지 않더라도 데이터 도메인에 맞게 관리하는게 좋다.

 

복합속성은 이론적으로 잘못 설계된 속성이어서 여러개의 개별속성으로 나누는 것이 원칙이다. 하지만 업무에 따라서 복합속성이 더 효율적일 때가 있다. 복합속성 전체로 조회한다면 굳이 나누지 않고 하나의 속성으로 관리하는 것이 효율적이다.

복합속성 분리여부는 개별적인 의미로 조회되는지 업무판단에 따라 달라진다. 개별적으로 사용한다는 것으 개별적인 속성으로 업데이트 된다거나 정렬이나 그룹화 될수 있다는 것을 의미한다. 복합속성으로 관리하면 매우불편하고 비효율이 발생할 것이다.

 

필수속성과 선택속성

속성은 값이 반드시 필요한 필수속성과 값이 없어도 되는 선택속성으로 구분할 수 있다. 속성의 널값허용여부를 분석하는 것은 속성에 대한 거의 마지막 단계 결정이다.

필수속성은 Null값을 허용하지 않는 속성. 논리적으로 허용하지 않는 것과 물리적으로 허용하지 않는것으로 구분한다.

논리적으로 Null을 허용하지 않는 것은 고객엔터티에 고객명 속성은 필수 속성이다.

물리적으로 Null을 허용하지 않는 것은 기본값이 지정된 속성을 의미한다. 논리적으로 Null을 허용하지만 여러이유로 Not Null로 설정한 후 기본값을 지정한 속성이다. 사실상 필수속성은 아니다. 필수속성으로 보일뿐이다.

 

필수속성은 엔터티에 데이터가 입력될 때 반드시 필요한 속성이다. 고객엔터티의 고객명, 고객휴대폰번호는 필수속성이다.

선택속성은 널값을 허용하는 속성이다. 고객엔터티의 닉네임, 취미 등 반드시 입력하지 않아도 되는 선택속성이다. 이선택속성중에서 기본값을 사용하기로 한 속성이 물리적으로 필수속성이다.

 

배타속성

여러속성에 저장된 값들이 상호배타적일때 또는 한 속성에 저장된 값이 어떤 기준에 대하여 서로 배타속성이라 한다.

 

고객엔터티에서 주민등록번호와 법인등록번호 속성값은 상호배타적이기 때문에 배타속성이다. 고객유형이 개인이면 주민등록번호에 법인이면 법인등록번호 속성에 값이 존재한다. 개별적으로는 널값이 존재할 수 있지만, 배타속성의 값을 합하면 전체가 되기 때문에 널값이 존재하지 않는다.  만약 하나의 인스턴스에 배타속성에 값이 모두존재하면 데이터 무결성이 깨진상태가 되기 때문에 주의해야 한다.

 

 

배타속성은 하나의 속성에도 존재할 수 있다. 그러나 하나의 속성이 배타속성이라면 배타속성은 일반화시켜야 한다.

아래와 같은 입출고 엔터티처럼 입고와 출고를 같이 관리할때 입출구분코드 속성값에 따라 발생일자 속성은 입고일자나 속성일자를 의미하게 된다. 수량 및 입출지점번호도 맞찬가지이다. 하나의 속성이 배타속성이라면 배타속성명은 일반화시켜야 한다.

입고와 출고처럼 배타성격의 구분이 한정적이라면 늘어날 가능성이 없다면 입출일자같이 명확하게 사용하는게 바람직하다.

배타속성은 배타관계에 의해서 발생한다. 

배타속성은 구분자 역활을 하는 속성과 같이 위치해야 가독성이 좋아진다.