속성과 도메인: 값의 의미와 품질

핵심 요약

속성의 분류와 도메인·NULL·파생 속성의 설계 원칙을 데이터 품질 관점에서 정리한다.

학습 목표

• 기본·설계·파생 속성과 단순·복합 속성을 구분한다.
• 도메인이 데이터 품질에 미치는 영향을 설명한다.

본문

개념 지도

업무 사실→엔터티와 행 단위→속성·도메인→관계·카디널리티→제약

핵심 내용

속성은 엔터티 인스턴스를 설명하는 최소 의미 단위다. 한 속성은 한 업무 의미를 가져야 하고, 같은 종류의 값이 들어오도록 도메인을 정한다. 도메인은 데이터 타입만이 아니라 길이, 허용 범위, 형식, 기본값과 제약조건까지 포함하는 값의 집합이다.

• 기본 속성: 업무에서 본래 수집하는 값(주문일시)
• 설계 속성: 모델 구현을 위해 만든 값(주문번호)
• 파생 속성: 다른 값으로 계산되는 값(주문합계)

파생 속성은 조회를 빠르게 할 수 있지만 원천 값과 불일치할 위험이 있다. 저장할 때는 계산 규칙, 갱신 시점, 책임 주체를 함께 정해야 한다. NULL은 미정·해당 없음처럼 값이 없음을 나타내며 0이나 공백과 다르다.

슈퍼타입·서브타입의 구분자

슈퍼타입은 여러 유형이 공유하는 속성과 관계를 모은 엔터티이고, 서브타입은 그중 특정 유형에만 필요한 속성과 관계를 가진 엔터티다. 구분자(Discriminator)는 슈퍼타입의 각 인스턴스가 어느 서브타입에 속하는지 나타내는 속성이다.

고객을 개인고객과 법인고객으로 구분한다고 하자. 고객번호·고객명은 공통이므로 고객 슈퍼타입에 두고, 생년월일은 개인고객, 법인등록번호는 법인고객 서브타입에서 관리한다. 고객의 customer_type이 구분자이며, 값 IND는 개인고객, CORP는 법인고객을 뜻한다.

101과 102는 고객번호로 구별되는 서로 다른 고객이지만 같은 구분자 값 IND를 갖는다. 고객번호는 인스턴스 식별, 구분자는 유형 식별에 쓰인다. 서브타입을 별도 테이블로 구현하면 개인고객의 고객번호 101은 고객의 고객번호 101과 같은 고객을 가리키며, 일반적으로 서브타입 기본키이자 슈퍼타입을 참조하는 외래키가 된다.

배타성·포괄성과 완전성

• 배타적 서브타입: 한 인스턴스가 같은 분류의 여러 서브타입에 동시에 속하지 않는다. 개인과 법인 중 한 유형만 허용한다면 customer_type에 한 유형의 코드를 기록한다.
• 포괄적 서브타입: 한 인스턴스가 여러 서브타입에 동시에 속할 수 있다. 한 사람이 학생이면서 직원일 수 있는 모델이라면 유형별 표시 속성, 소속 관계 테이블 또는 동시 소속을 표현하는 코드 체계가 필요하다.
• 완전성: 모든 슈퍼타입 인스턴스가 반드시 어떤 서브타입에 속해야 하는지를 정한다. 배타성의 “동시에 몇 유형인가”와 완전성의 “소속이 필수인가”는 별도 규칙이다.

구분자에 IND를 기록하는 것만으로 개인고객 행이 자동 생성되거나 외래키의 NULL이 제거되지는 않는다. 구분자 값의 도메인과 실제 서브타입 소속이 일치하도록 키·참조 무결성 및 업무 검증을 설계한다. 구분자는 슈퍼타입과 서브타입의 관계를 없애는 속성도, 각 서브타입에 서로 다른 기본키를 만드는 속성도 아니다.

NULL 속성을 모델링할 때 구분할 업무 상태

NULL은 단순히 “값이 없다”가 아니라 서로 다른 업무 원인을 가릴 수 있습니다.

서로 다른 상태를 모두 하나의 NULL로 저장하면 “미입력”과 “해당 없음”을 구분할 수 없습니다. 반대로 의미 없는 기본값 0, 'N/A', '99991231'을 넣으면 실제 값과 구분이 어려워지고 집계·정렬·제약이 왜곡됩니다.

CREATE TABLE customer (
    customer_id      NUMBER       PRIMARY KEY,
    customer_type    VARCHAR2(10) NOT NULL,
    corporation_no   VARCHAR2(20),
    CONSTRAINT customer_c1 CHECK (
      (customer_type = 'CORP' AND corporation_no IS NOT NULL)
      OR
      (customer_type <> 'CORP' AND corporation_no IS NULL)
    )
);

시험에서는 필수성(Optionality), 업무상 해당 여부, 도메인, 기본값을 함께 보고 NULL 허용이 업무 의미를 정확히 표현하는지 판단합니다.

속성 분류를 실제 Column으로 연결하기

고객번호        기본·식별 속성
생년월일        기본 속성
나이            파생 속성(기준일에 따라 계산)
주소            복합 속성 후보(우편번호·시도·상세주소)
전화번호 목록   다중값 속성 → 별도 고객전화 엔터티 후보

파생값을 저장하면 조회는 쉬워지지만 원천값이 바뀔 때 동기화가 필요하다. 나이처럼 시간에 따라 변하는 값은 저장보다 생년월일과 기준일에서 계산하는 편이 일관적이다.

도메인이 보장할 것

도메인은 단순 데이터 타입이 아니라 허용 범위·형식·단위·코드 의미를 포함한다.

status_code VARCHAR2(10) NOT NULL
  CHECK (status_code IN ('READY','PAID','CANCEL'))

금액의 통화, 비율의 단위, 날짜의 Time Zone을 속성 이름과 정의에 명시한다. 같은 상태코드 이름을 주문과 고객에서 서로 다른 의미로 사용하면 동음이의어 문제가 생긴다.

원자성은 업무 문맥 기준

주소 전체가 항상 한 번에 출력만 된다면 문자열 하나로 볼 수도 있지만 지역별 검색·우편번호 검증·주소 이력이 필요하면 구성 요소로 분리한다. 원자성은 DBMS 타입의 최소 크기가 아니라 업무에서 더 이상 분해해 사용할 필요가 없는 수준이다.

품질 체크

• 속성마다 한 가지 의미와 출처가 있는가?
• NULL이 미입력·해당 없음·알 수 없음 중 무엇인지 정의했는가?
• 코드·단위·길이·정밀도와 유효기간을 정했는가?
• 파생 속성의 계산식과 기준 시점을 재현할 수 있는가?

시험 포인트

문항 풀이 보강: 속성의 성질·명명·도메인

속성은 엔터티의 인스턴스를 설명하며 한 속성에는 한 가지 업무 의미가 들어가야 한다. 일반적으로 업무에서 관리할 필요가 있고, 주식별자에 함수적으로 종속되며, 같은 의미의 값이 반복 그룹으로 저장되지 않아야 한다.

원금과 이자율로 계산한 이자를 저장하면 파생 속성이다. 조회는 빨라질 수 있지만 원금이나 이자율 변경 시 함께 갱신해야 하므로 계산 기준과 동기화 시점이 필요하다.

도메인은 데이터 타입만 뜻하지 않는다. 허용 범위, 길이, 형식과 제약까지 포함한다.

amount       NUMBER(12,2) CHECK (amount >= 0)
product_name VARCHAR2(20) NOT NULL

속성 이름의 기준

• 업무에서 사용하는 이름을 쓴다.
• 서술식으로 지나치게 길거나 의미가 모호한 약어를 피한다.
• 엔터티 안에서 유일한 이름을 사용한다.
• 동일 의미 속성은 모델 전체에서 가능한 한 같은 이름과 도메인을 사용한다.

문제에 적용하는 순서

“계산하여 저장”, “합계·잔액·나이”는 파생 속성 가능성을 본다. “값의 범위·길이·형식”은 도메인, “원래 업무에서 수집”은 기본 속성, “식별을 위해 인위적으로 부여”는 설계 속성이다.

자주 틀리는 부분

• 속성은 더 이상 의미 있게 분리할 필요가 없는 업무 단위이지, 무조건 물리적으로 가장 작은 문자열은 아니다.
• 복합 속성을 여러 컬럼으로 나누는 판단은 검색·정렬·검증 등 업무 사용 방식을 따른다.
• 파생 속성은 언제나 나쁜 것이 아니지만 무결성 유지 비용을 동반한다.