속성

속성은 엔터티가 가지는 세부 특성으로 인스턴스를 설명합니다. 속성값은 특정 인스턴스에 실제로 저장된 값이며, 속성은 하나의 엔터티에 귀속됩니다.

속성은 원칙적으로 업무에서 의미 있는 최소 단위로 정의합니다. 여러 값을 한 칸에 문자열로 합치면 검색·검증·집계가 어려워질 수 있어 별도 속성이나 하위 엔터티로 분리할지 검토합니다.

논리 모델의 속성은 물리 모델에서 보통 테이블의 컬럼에 대응합니다. 스터디룸 예약 서비스로 보면, 스터디룸은 엔터티이고 룸번호·룸이름·시간당 요금은 속성입니다. R01이라는 스터디룸 한 건이 인스턴스이며, 그 인스턴스의 룸이름에 들어 있는 창의실이 속성값입니다.

표에서 행 하나는 스터디룸 한 건, 열 하나는 엔터티가 관리하는 정보의 종류이고, 행과 열이 만나는 12000 같은 값이 속성값입니다.

속성은 무엇을 기준으로 보느냐에 따라 여러 방식으로 분류합니다. 기본·설계·파생은 값이 생긴 출처, 주식별자·외부식별자·일반은 엔터티 구성에서 맡은 역할에 따른 구분입니다.

단일값과 다중값, 필수와 선택 여부도 설계에 영향을 줍니다. 다중값을 반복 컬럼이나 구분자 문자열로 저장하는 대신 별도 엔터티와 관계로 표현하면 무결성과 확장성이 좋아집니다.

시험 함정은 이자율입니다. 이자율은 상품 조건으로 주어지는 값이라 기본 속성이고, 그것으로 계산한 결과인 이자만 파생 속성입니다. 파생 속성은 원본 값이 바뀌면 정합성을 다시 맞춰야 하므로 꼭 필요할 때만 둡니다.

복합 속성은 한 정보 항목을 여러 부분으로 나눌 수 있다는 뜻(위치 → 건물명·층수·호실)이고, 복합 식별자는 여러 속성을 묶어 하나의 식별자로 쓴다는 뜻이라 서로 다릅니다. 또 모든 기본키가 설계 속성은 아닙니다. 업무에 이미 있는 고유번호를 기본키로 고를 수도 있습니다.

속성은 관계에서 맡는 역할에 따라 PK 속성, FK 속성, 일반 속성으로 볼 수 있습니다. PK는 인스턴스를 식별하는 열(또는 열의 조합), FK는 다른 테이블의 키를 참조하는 열(또는 열의 조합)이고, 룸이름·시간당 요금처럼 식별·참조 역할이 없는 항목은 일반 속성입니다.

속성 이름은 업무 담당자와 개발자가 같은 뜻으로 이해할 수 있어야 합니다. 현업에서 쓰는 명사형 용어를 쓰고, 서술식으로 길게 풀어 쓰지 않으며, 뜻을 알기 어려운 약어는 피합니다. 예약시작시각처럼 무엇을 가리키는지 드러나는 이름이 시간처럼 막연한 이름보다 낫습니다.

논리 모델에서는 알아보기 쉬운 업무 용어를 우선하고, 물리 모델에서는 조직의 명명 표준에 따라 ROOM_ID, HOURLY_RATE 같은 영문 컬럼명으로 바꿀 수 있습니다. 시험 기준 원칙은 속성명을 전체 데이터 모델에서 유일하게 짓는 것입니다. 같은 뜻을 여러 이름으로 쓰거나 다른 뜻에 같은 이름을 쓰면 혼란이 생깁니다.

도메인은 속성이 가질 수 있는 값의 범위와 형식, 제약을 정의합니다. 예를 들어 주문상태는 허용 상태 코드 집합, 주문일자는 날짜 형식과 유효 범위를 가질 수 있습니다.

속성명·정의·데이터 타입·길이·허용값·기본값·NULL 가능 여부를 일관되게 관리하면 데이터 표준과 입력 검증을 함께 개선할 수 있습니다.

예를 들어 이용시간이 정수 1~8만 가능하다면 7은 허용되지만 12는 도메인에 맞지 않습니다. 논리 모델에서 정한 도메인은 물리 모델에서 VARCHAR2, NUMBER 같은 자료형과 NOT NULL, CHECK 같은 제약조건으로 구체화합니다.

주의할 점은 CHECK만 선언하면 Oracle에서 NULL이 허용될 수 있다는 것입니다. 값이 반드시 있어야 한다면 NOT NULL을 따로 지정합니다.

도메인을 정하면 잘못된 값의 입력을 초기에 줄일 수 있지만, 자료형·범위만으로 모든 업무 규칙을 검증할 수는 없습니다. 예약 시간 중복 같은 규칙은 추가 제약이나 애플리케이션 로직으로 검토합니다.

스터디룸 하나에 빔프로젝터와 화이트보드가 모두 있다고 합시다. 한 컬럼에 PROJECTOR, WHITEBOARD를 넣으면 비품 하나를 찾거나 바꿀 때 문자열을 쪼개야 합니다. 비품이 늘 때마다 비품1, 비품2 컬럼을 추가하는 방식도 확장하기 어렵습니다.

개념 모델에서는 이런 특징을 다중값 속성으로 인식할 수 있지만, 관계형 테이블의 제1정규형(1NF)을 고려하면 비품을 한 행씩 관리하는 ROOM_AMENITY 같은 별도 테이블을 두는 편이 적절합니다. 개별 비품으로 검색·관리해야 하는 업무라면 여러 값을 담은 문자열은 원자적이지 않습니다.

이렇게 나누면 PROJECTOR가 있는 스터디룸만 찾거나 특정 룸의 비품 하나만 지우기가 쉬워집니다. 다중값을 여러 행으로 옮기는 원리는 정규화 단원의 1NF 원자성과 이어집니다.