속성 이야기

속성 정의

속성이란?
데이터를 저장하는 가장 작은, 독립된 저장 단위
-> 속성의 쓰임새를 알려면 속성의 종류을 알아야한다. 이를 통해 속성이 무엇인지 상세하게 알 수 있다.

속성의 분류법

• 식별자(Key) 속성 & 비식별자(Non-Key) 속성

• 원본 & 추출속성

• 기초 속성 & 관계 속성 & 추출속성 & 시스템 속성

속성 정의 방법
분류를 통해 속성의 성격을 파악했다면 이후에,,,,

• 속성명 정의
• 속성 설명
• 속성 표준화
• 도메인
• 데이터 타입 선정
• 널 사용법
• 속성 검증

속성별 특징

속성 분류법1 : 식별자 & 비식별자 속성

식별자 속성(결정자 속성)

개념 : 엔터티에 존재하는 인스턴스의 유일성을 보장해 주는 속성이나 속성 집합.

• 엔터티의 인스턴스마다 서로 다른 값을 가지는 속성이 식별자 속성

• 하나의 속성이 식별자의 역할을 하지 못할 경우 여러 속성이 모여 식별자가 되는데 이를 복합식별자 라고 한다.

• 엔터티의 본질이나 태생에 관련된 속성

비식별자 속성(종속자 속성, 일반 속성)

인스턴스마다 같은 값을 가질 수 있다. = 중복 가능

• 엔터티의 특성을 묘사하는 역할

• 엔터티에서 한 두개인 식별자 속성을 제외한 모든 속성은 비식별자 속성이다.

후보식별자
주 식별자가 될 가능성이 있는 식별자, 모든 식별자는 주 식별자가 될 수 있는 후보로, 사실상 식별자와 동일.
하나 엔터티에 여러 개 존재 가능
주 식별자와 차이 : NULL값 허용 가능. 물리적으로 인스턴스 유일성 보장해주기 위해 유니크 인덱스 생성해야한다.


주 식별자
엔터티에 하나만 존재하는 대표 식별자, 정규화의 기준이 되는 속성, 엔터티의 성격을 대변할 수 있는 기초속성
논리적으로 인스턴스를 식별하는 기준으로 반드시 존재해야한다.
해당 엔터티만 위해 사용되는 것 아니므로 하위 엔터티도 고려해야한다


PK : 보통 주 식별자로 테이블에 지정한 물리적인 제약
자신의 엔터티 내에서 인스턴스 식별하는 역할을 하고, 다른 엔터티와 관계를 식별하는 FK 역할을 한다.
인스턴스 조회 or 다른 엔터티와 조인할 때 사용

주식별자에 대해

주 식별자 선정 절차
업무식별자가 주 식별자가 될 가능성이 크기 때문에 업무식별자를 먼저 도출한다.
후보식별자도 주 식별자가 될 수 있기에 여러 후보식별자를 도출한다.
후보식별자 적합하지 않으면 인조 채택 -> 업무나 후보 식별자가 복합식별자일 수 있지만 인조식별자는 단일 속성으로 이루어짐

주 식별자가 바뀌는 현상

• 엔터티 정의가 불명확할 때

• 데이터 분석이 미흡할 때

• 이력 데이터를 고려하지 않았을 때 : 원천 데이터 설계할 때 이력데이터 고려해서 주 식별자가 변경되는 요인을 막을 수 있다.

  • 업무가 변경될 때는 어쩔 수 없음으로 업무 확장 감지되면 유연하게 설계한다 = 인조식별자를 채택(주 식별자 바뀌었을 때 영향 최소화하기 위해)

주 식별자를 단순하게 설계해야하는 이유

1. 상위 엔터티의 주 식별자 속성이 많으면 하위 엔터티의 주 식별자도 같이 많아진다.

2. 상위 엔터티의 주 식별자가 복잡하면 관계선이 복잡해진다.

3. 조인구문도 복잡해진다.

4. 하위 엔터티에서 발생하는 배타 관계를 관리하기도 수월해진다.

주 식별자 선택 원칙과 기준

1. 주 식별자 속성의 값이 변경되지 않도록 선정

2. 일반 속성에 종속되지 않도록 선정

3. 인조 식별자에는 의미를 부여하지 않도록 선정

4. 주 식별자 속성에 널값이 존재하지 않도록 선정

5. 최소한의 속성이 포함되도록 선정

6. 업무적으로 활용도가 높은 속성으로 선정

7. 업무 식별자와 인조 식별자가 혼합되지 않도록 선정

8. 슈퍼 식별자(주 식별자+속성으로 만든 식별자)가 되지 않도록 선정

9. 최소 길이가 되도록 선정

10. 주 식별자 속성 값은 가능한 고정 길이가 되도록 선정

11. 주 식별자 속성은 전사에서 한 번만 사용되도록 선정

12. 암호화 대상 속성이 포함되지 않도록 선정

13. 업무를 대표할 수 있는 속성으로 선정

식별자 종류

인조식별자
인조 식별자는 임의로 생성한 식별자를 의미한다.
후보 식별자 중에서 주 식별자로 사용할 마땅한 후보가 없을 때, 순번 성격의 속성을 추가해서 식별자로 사용한다.

인조 식별자가 사용되기까지의 순서
1. 후보(업무) 식별자 도출
2. 도출된 후보(업무) 식별자 중에 주 식별자로 적당한 후보가 있는지 검토
3. 적당한 후보가 없다면 인조 식별자 사용

인조식별자 채택 시기
하위 엔터티가 많은 주요 엔터티는 가능한 빨리 인조 식별자를 선택하는 것이 좋다.
후보 식별자를 검토할 때, 인조 식별자를 도입해야 하는지를 동시에 검토하는 것이 좋다.

인조 식별자를 사용해야 좋을 때

• 주 식별자가 복잡하면서 하위 엔터티가 다수 존재할 때
• 업무를 직관적으로 만들어 주는 번호를 사용할 때
• 적당한 후보 식별자가 없을 때
• 모델을 유연하게 설계해야 할 때

부분 인조식별자
업무 식별자와 인조 식별자의 혼합

• 장점 : 업무에 자주 사용하는 기준이 주 식별자에 포함된다.

Ex1) 한 고객이 하루에 같은 상품을 두 번 이상 주문할 수 없을 때 

-> 고객 번호 속성은 업무 식별자에 해당하고, 주문순번 속성은 고객별로 순차적으로 증가하는 순번을 의미하므로 인조 식별자에 해당

Ex2) 교차 엔터티에 이력속성까지 포함돼 업무 식별자가 복잡하고, 대부분의 업무가 학생번호 속성을 사용한다면, 학생번호와 + (수강순번)부분 인조 식별자를 사용할 수 있다.

업무 식별자와 인조 식별자를 혼합해서 사용하면 바람직하지 않는 이유

1. 요건을 알기 어려워 가독성이 떨어짐 : 업무식별자 알기 어려워 인스턴스 생성하는 기준 알 수 없게 된다. 유니크 인덱스 생성해서 물리적으로라도 기준을 제약할 수 있도록 해야한다.
2. 엔터티 성격이 모호해짐 : 발생순번 같은 일반적인 속성 사용하면 많은 엔터티에서 주 식별자가 동일해짐 -> 가독성이 떨어짐 -> 모델 관리가 복잡해짐

-> 업무 확정적 : 업무 식별자 사용/ 업무 요건 다양 : 인조식별자 사용으로 유연성 확보

대리식별자
만약 후보 식별자 중에서 회사코드, 거래처코드, 배송지순번 속성을 주 식별자로 선정했다면 우편번호, 주소 속성은 대리 식별자가 된다.
만약, 인조 식별자를 주 식별자로 사용하면 모든 후보 식별자가 대리 식별자가 된다.

대리 식별자를 선정하는 과정

• 후보 식별자를 선정한다. 후보 식별자가 여러 개 있다.

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

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

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

• 인조 식별자를 채택하면 후보 식별자는 전체가 대리 식별자가 된다.

ak 표기 못하면 속성 설명에 대리 식별자에 대해 간략하게 기술하는 것이 좋다. 인조 식별자를 주 식별자로 사용했을 경우 업무 식별자는 도출해야하니까 대리식별자를 별도로 관리해야한다.

슈퍼식별자

주 식별자에 다른 속성을 추가해서 만든 식별자를 의미한다.

• 최초 속성으로 이루어진 슈퍼식별자가 후보식별자이다.

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

• 주 식별자는 인스턴스를 생성하는 기준과 인스턴스를 식별하는 역할만을 해야 한다. 슈퍼 식별자를 사용하면 데이터 성격이 점점 모호해지면서 엔터티의 성격이 변질될 수 있다. 슈퍼 식별자는 어떤 상황에서도 사용하지 않는 것을 원칙으로 해야 한다.

속성의 분류법 2 : 기초, 관계, 추출, 시스템 속성

기초 속성
엔터티의 본질을 설명하는 속성으로 엔터티의 정의를 알 수 있다. (업무, 후보, 엔터티 특성 설명하는 속성)

기초 속성 특징

• 기초 속성의 값은 주로 데이터베이스를 사용하는 사용자의 입력이라는 행위에 의해서 생성된다

• 기초 속성은 주로 논리 모델링 초반에 도출된다

• 추출, 중복 속성을 제외하면 가장 많은 속성이 기초 속성이다

• 기초 속성을 전부 삭제하면 나머지 속성만으로는 그 엔터티가 무슨 데이터를 관리하는지 알 수 없다.

관계 속성
타 엔터티와의 관계를 알기 위해 사용하는 외래 식별자 속성

관계 속성 특징
참조되는 엔터티의 주 식별자 속성이라 대부분 핵심속성이다. 기초속성보단 덜 중요
ERD에서 관계선이 생략될 수는 있어도 관계 속성이 생략되면 안된다.

추출 속성
이미 존재하는 속성으로 재생(재현)할 수 있는 속성

목적
데이터 조회 시간을 단축하기 위함이다.

원칙
같은 엔터티에 존재하는 원본속성을 연산한 값은 별도로 저장하지 않는 것이 원칙이다. -> 같은 인스턴스 값을 곱하거나 더하는 것은 성능향상과 거의 관계가 없다. 성능 문제 아니라면 추출속성 사용하지 않는다.

단점
정합성이 저하, 계산된 값이기에 중복 식별 거의 불가능 -> 정합성을 실시간으로 맞춰야한다.-> DB에서 제공하는 각종 제약을 사용해 강제적으로 맞춘다.

특징

• 추출 속성은 기존에 존재하는 원본 속성의 값을 연산해서 생성할 수 있는 속성이다.

• 추출 속성은 원본 속성에 종속돼 있다.(=파생 종속)

• 추출 속성은 주 식별자로 사용하면 안 된다.

• 단, 잔고, 잔금 같은 경우엔 중요하게 사용되는 추출속성이고 기초속성이기도 해서 개념모델에 표현될 수 있는 핵심적인 속성이다.

시스템 속성

데이터에 대한 추적, 감시를 위해 사용하는 속성이다.

시스템 속성 특징

• 해당 인스턴스를 누가 생성하고 언제 생성했는지 누가 언제 수정했는지 관리하는 속성

• 시스템 속성의 개수는 가능한 적어야 좋다.

• 시스템 속성은 모든 엔터티에 공통으로 존재하는 속성이다. 다만, 성능 최적화해야 하는 엔터티에서는 삭제할 수도 있다.

• DB에 테이블로 생성하기 바로 직전에 시스템 속성을 추가하는 것이 가장 바람직하다.(시스템 속성 선정은 가능한 빨리) -> 논리모델링 단계에서 전체 엔터티에 추가했는데, 시스템 속성 바뀌면 전체 엔터티에서 바꿔줘야하기 때문에

• 시스템 속성은 엔터티의 제일 하단에 위치한다.

속성 정의방법

속성명 표준화 및 목적

일정한 기준에 따라 같은 의미의 속성에 대해서는 속성 명을 동일하게 사용함으로써 데이터 오류를 줄인다
-> 데이터 품질이 높아지고 관련자의 커뮤니케이션을 돕는다.

• 단어사전으로 단어 정의하고 표준화지침 따라서 속성을 표준화한다.
• 구체적으로 표현, 지나치게 일반적인 용어X -> 도메인 값을 명시 Ex) 일자 -> 가입일자, 삭제일자
• 단어(명사)로 구성
• 영문약어 : 복합단어 사용않기
• 이음동의어&동음이의어 사용 자제
• 전체 모델에서 유일하게 존재(이상적인 목표)
• 속성명 앞에 단순히 엔터티 명 붙여 사용X
• 관계속성명 : 상위 엔터티의 주 식별자 속성명 차용
  Ex) 주문자-> 주문고객번호

속성 설명

• 단순.명료하게 기술해야 한다.

• 해당 엔터티에서의 속성 쓰임새를 기술한다.

• 지나치게 일반적인 용어나 본인만이 이해할 수 있는 특수 용어, 잘모르는 - 축약어는 사용하지 않는다.

• 중복 속성이라면 원본 속성이 무엇인지를 기술해야 한다.

• 추출 속성이라면 대상 데이터와 추출 로직을 기술해야 한다.

• 코드 속성일 때는 코드 인스턴스를 기술하는 것이 좋다.

• 명사형으로 끝나는 형식이 명료하다.

도메인이란?

속성이 가질 수 있는 값의 집합(범위)

목적 : 같은 성격의 속성인데, 데이터 타입이나 길이, 컬럼명의 형식이 달라질 수 있기 때문에 이를 일치시킴으로써 속성을 일관되게 사용하여 데이터 무결성을 높인다.

논리 도메인 : 대표 속성, 데이터성격이 고정적인 속성에만 논리 도메인 적용하는 것이 바람직하다. 중복, 추출 속성은 원본속성과 동일한 의미를 나타내므로 논리 도메인을 사용한다.

물리 도메인 : 데이터 타입 및 길이, 도메인 개수 한정X

Ex) 처음 ‘고객명’을 등록 Varchar(30) -> 물리도메인 / ‘CRM고객명’을 등록 했는데, ‘고객명’속성으로 지정 -> 이때 지정되는 ‘고객명’이 논리도메인
단, 모델의 유연성을 더 고려한다면 물리도메인을 사용할 수 있다.

데이터 타입 선정

데이터 타입 선정 원칙과 절차
개념모델링 단계부터 속성을 정의할 때 데이터 타입을 결정한다.
원칙 : 속성에 저장될 데이터의 성격에 맞는 타입을 결정해야한다.

• 데이터 성격은 숫자지만 특정 숫자가 정해져있으면 코드로 관리하는 것이 바람직하다.
• 도메인을 얼마나 세분화해서 관리하느냐에 따라 최대길이를 결정한다.

NULL에 대해

속성 값을 알 수 없을 때 사용하는 데이터 값
(널의 의미는 '모른다'의 의미지 '해당없음'의 의미가 아니다.)

• 속성을 정밀하게 모델링하기 위해서는 '모르는 것'과 '해당 사항이 없는 것'을 구분할 필요가 있다

• 주문상태코드가 ＇1＇인 경우만 주문취소사유가 존재, ＇해당없음(0)＇과 ＇모름(9)＇를 분리해서 관리

• 널이 존재하는 속성이 많을 때는 원천 엔터티에서 분리해서 별도의 엔터티에서 관리하는 것도 고려

널 특징과 사용법
널 값을 가지는 속성은 가능한 없는 것이 좋다.

NULL 허용

장점

• 현행 데이터 그대로 마이그레이션 가능.
• NULL 값이 인덱스에 포함 안됨.
• 운영 중 추가 속성이 발생해도 기본 값에 대한 처리 방안은 고려하지 않아도 됨.

단점

• 속성의 상세 업무 요건 파악으로 모델링 시간이 증가.
• 속성의 Null 처리 프로그래밍 혼선 발생.
• 연산, 집계 요건이 있을 때 원치 않는 결과 나올 가능성 존재.

Not NULL

장점

• 일관된 모델을 유지할 수 있으며 모델링 시간이 단축됨.
• Null 값이 없으므로 Null처리 프로그래밍이 수월.
• 기본값 사용으로 인덱스 효용성 증대.

단점

• 업무 요건에 최적화되지 않은 일관된 모델.
• 현행 데이터가 Null 허용이면, Default 값 사용으로 이행 시간 증대.
• 운영 중 추가 속성이 발생할 때 기본값을 고려해야 하며, 이로 인해 결국, 운영 부하 및 부담 발생.

속성 검증

속성 존재 여부 검증방법
모델에 표현이 안된 속성이 있는지, 불필요한 속성이 있는지를 검증
1) 어플리케이션 화면에서 사용한 항목과 모델 속성과의 매트릭스를 작성하여 비교
화면에는 존재, 속성은 없는 경우
속성은 존재, 화면은 없는 경우
속성 없음, 화면에도 없는 경우

2) ASIS속성과 TOBE속성과의 매트릭스 작성 비교

식별자 검증방법

• 엔터티명과 엔터티 정의, 주 식별자를 엑셀로 뽑아서 서로 어울리는지 검토
• 주 식별자에 논리적인 널값(기본값) 사용은 바람직하지 않음
• 주 식별자 속성은 값이 변경되지 않아야 하고, 추출속성이 사용되면 안됨
• 체계가 존재하는 식별자 지양, 단순해야 함
• 부분인조식별자가 사용된 엔티티는 재검토
• 슈퍼식별자 사용금지
• 복합 주 식별자 사용시 식별자의 순서의 효율성 겁토
• 주 식별자가 동일한 엔터티가 존재하지 않는지 검토

일반속성 검증

• 속성이 단어의 조합으로 구성되어 있는지 확인
• 논리도메인에 사용돼야 할 속성이 물리도메인에 사용되지 않았는지 검토

모델구조 검증

• 속성명 끝에 숫자가 포함된 속성지양(속성명을 구체적으로 정하던, 정규화를 통해 엔터티 분리 고려)

• 반복속성 검토(반복속성 불변일때는 비정규화 고려하나, 기본적으로 정규화 검토)

• 복합속성 다가속성 ->최대한 사용배제

• 중복속성, 추출속성 -> 원본 속성 기술, 최대한 사용배제

• 코드속성은 코드 인스턴스(코드 값, 코드명) 존재 확인

• 서브타입 모델은 슈퍼/서브타입의 속성이 제위치에 있는지 확인

• 주 식별자에 변경일자, 종료일자 속성이 포함되어 있으면 이력엔티티가 맞는지 확인

• 이음동의어, 동음이의어 검토