데이터베이스 속성
IT 위키
더 많은 작업
- Attribute
- 업무에 필요한 엔터티의, 더 이상 분리되지 않는 최소 데이터 단위
데이터 모델링에서 속성(Attribute)은 엔터티가 가지는 성질 하나하나를 말한다. 업무상 관리할 필요가 있고, 의미상 더 쪼갤 수 없는 최소 단위의 데이터다. 논리 모델의 속성은 물리 모델에서 테이블의 칼럼(열)이 된다.
예를 들어 '사원' 엔터티는 사번, 이름, 입사일자, 부서코드 같은 속성을 가진다. '주소'처럼 업무에서 통째로 다루는 값은 하나의 속성으로 볼 수 있지만, 업무가 시·구·상세주소를 따로 조회하고 집계한다면 각각을 별도의 속성으로 나누는 것이 맞다. 무엇이 최소 단위인지는 업무가 정한다.
| 용어 | 의미 | 예(사원 엔터티) | 물리 모델 |
|---|---|---|---|
| 엔터티 | 관리 대상의 집합 | 사원 | 테이블 |
| 인스턴스 | 엔터티에 속한 개별 대상 하나 | 사번 1001인 김철수 사원 | 행 |
| 속성 | 인스턴스가 가지는 성질 | 이름, 입사일자 | 칼럼 |
| 속성값 | 특정 인스턴스의 특정 속성이 가진 값 | '김철수', 2020-03-02 | 칼럼 값 |
- 하나의 엔터티는 두 개 이상의 인스턴스를 가진다.
- 하나의 엔터티는 두 개 이상의 속성을 가진다.
- 한 인스턴스의 한 속성은 하나의 속성값만 가진다. 이것이 데이터베이스 제1정규형이 요구하는 원자값 조건이다. 한 사원이 전화번호를 여러 개 가진다면 '전화번호' 속성에 값을 나열하지 않고, 별도 엔터티(사원전화번호)로 분리한다.
SQLD 출제 범위에서 쓰는 분류로, 속성이 어디에서 왔는지를 기준으로 나눈다.
| 분류 | 설명 | 예 |
|---|---|---|
| 기본 속성 | 업무 분석을 통해 바로 정의한 속성. 가장 많다. | 제품명, 제품가격, 주문수량, 입사일자 |
| 설계 속성 | 업무상 원래 있던 것은 아니지만, 설계하면서 규칙화하거나 식별을 위해 새로 만든 속성 | 상품코드, 학과코드, 주문의 일련번호 |
| 파생 속성 | 다른 속성에서 계산하거나 가공해 얻을 수 있는 속성 | 주문총액(수량×단가의 합), 재고수량, 나이(생년월일로 계산) |
- 코드 성격의 속성이라도 원래 업무에서 쓰던 코드라면 기본 속성으로 본다. 설계 속성은 모델링 과정에서 새로 정한 것이다.
- 파생 속성은 원본 데이터가 바뀔 때마다 같이 고쳐야 한다. 이를 놓치면 원본과 파생값이 서로 맞지 않는 데이터 불일치가 생긴다. 그래서 파생 속성은 조회 성능상 꼭 필요한 경우에만 적게 두고, 갱신 방법(트랜잭션 안에서 함께 갱신, 트리거, 배치 재계산 등)을 정해 둔다.
주문 테이블에 파생 속성 '주문총액'을 두고, 주문상세의 수량만 고친 경우다.
CREATE TABLE 주문 (주문번호 NUMBER PRIMARY KEY, 주문일자 DATE NOT NULL, 주문총액 NUMBER);
CREATE TABLE 주문상세 (주문번호 NUMBER REFERENCES 주문, 순번 NUMBER, 상품명 VARCHAR2(20), 수량 NUMBER, 단가 NUMBER, PRIMARY KEY (주문번호, 순번));
INSERT INTO 주문 VALUES (1, DATE '2026-10-01', 7000);
INSERT INTO 주문상세 VALUES (1, 1, '연필', 2, 1000);
INSERT INTO 주문상세 VALUES (1, 2, '공책', 1, 5000);
-- 연필 수량만 3으로 바꾸고 주문총액은 고치지 않음
UPDATE 주문상세 SET 수량 = 3 WHERE 주문번호 = 1 AND 순번 = 1;
SELECT o.주문번호, o.주문총액, SUM(d.수량 * d.단가) AS 상세합계
FROM 주문 o JOIN 주문상세 d ON d.주문번호 = o.주문번호
GROUP BY o.주문번호, o.주문총액;
| 주문번호 | 주문총액 | 상세합계 |
|---|---|---|
| 1 | 7000 | 8000 |
- 같은 사실을 두 곳에 저장했기 때문에 한쪽만 고치면 값이 어긋난다. 이것이 파생 속성에 일관성 관리가 필요한 이유다.
| 분류 | 설명 | 예(주문상세) |
|---|---|---|
| PK 속성 | 엔터티의 인스턴스를 식별하는 속성(주식별자) | 주문번호, 순번 |
| FK 속성 | 다른 엔터티와의 관계에서 넘겨받은 속성 | 주문번호(주문 엔터티 참조), 상품코드(상품 엔터티 참조) |
| 일반 속성 | PK·FK에 포함되지 않는 나머지 속성 | 수량, 단가 |
- 주문상세의 주문번호처럼 하나의 속성이 PK이면서 FK일 수도 있다. 부모의 PK가 자식의 PK에 포함되는 식별 관계에서 이런 모양이 된다.
| 기준 | 분류 | 설명 | 예 |
|---|---|---|---|
| 분해 가능 여부 | 단일 속성 | 더 나눌 수 없는 속성 | 성별, 회원번호 |
| 복합 속성 | 여러 의미 있는 속성으로 나눌 수 있는 속성 | 주소(시, 구, 동, 상세주소), 성명(성, 이름) | |
| 가질 수 있는 값의 수 | 단일값 속성 | 인스턴스마다 값이 하나 | 주민등록번호, 생년월일 |
| 다중값 속성 | 한 인스턴스가 값을 여러 개 가질 수 있음 | 전화번호, 취미, 자격증 |
- 다중값 속성은 관계형 테이블의 한 칼럼에 그대로 담을 수 없다. 별도 엔터티로 분리하는 것이 데이터베이스 제1정규형의 정규화 방법이다.
- 복합 속성을 나눌지 말지는 업무에서 부분 값을 따로 쓰는지로 판단한다.
도메인(Domain)은 각 속성이 가질 수 있는 값의 범위다. 데이터 타입, 길이, 허용 값의 범위나 목록, NULL 허용 여부 같은 제약을 함께 정의한다. 예를 들어 '학년' 속성의 도메인은 1~4의 정수, '성별' 속성의 도메인은 'M'과 'F'다.
물리 모델에서 도메인은 데이터 타입과 길이, CHECK 제약, NOT NULL 제약으로 구현한다. 속성값이 도메인에 속해야 한다는 규칙이 데이터베이스 도메인 무결성이다.
CREATE TABLE 학생 (
학번 NUMBER(8) PRIMARY KEY,
이름 VARCHAR2(30) NOT NULL,
학년 NUMBER(1) CHECK (학년 BETWEEN 1 AND 4),
성별 CHAR(1) CHECK (성별 IN ('M', 'F'))
);
INSERT INTO 학생 VALUES (20260001, '김철수', 1, 'M'); -- 성공
INSERT INTO 학생 VALUES (20260002, '이영희', 5, 'F'); -- ORA-02290 (학년 CHECK 위반)
INSERT INTO 학생 VALUES (20260003, '박민수', 2, 'X'); -- ORA-02290 (성별 CHECK 위반)
INSERT INTO 학생 VALUES (20260004, '최지우', 2, NULL); -- 성공
SELECT * FROM 학생 ORDER BY 학번;
| 학번 | 이름 | 학년 | 성별 |
|---|---|---|---|
| 20260001 | 김철수 | 1 | M |
| 20260004 | 최지우 | 2 | NULL |
- CHECK 조건의 결과가 UNKNOWN이면 위반으로 보지 않는다. 그래서 성별에 NULL은 들어간다. 값을 반드시 받아야 한다면 NOT NULL을 함께 걸어야 한다. NULL의 동작은 데이터베이스 Null 참고.
- 해당 업무에서 실제로 쓰는 용어로 짓는다.
- 약어는 되도록 쓰지 않는다. 약어를 쓰면 다른 사람이 의미를 알기 어렵다.
- 서술식으로 짓지 않고 명사형으로 짓는다. 예를 들어 '고객이 주문한 날짜' 대신 '주문일자'로 쓴다.
- 수식어나 소유격을 줄이고, 전체 데이터 모델에서 유일한 이름이 되도록 짓는다. 여러 엔터티에 '이름'이 있으면 '고객명', '상품명'처럼 구분한다. 이름이 유일해야 같은 이름이 서로 다른 뜻으로 쓰이는 혼란을 막을 수 있다.
- 속성의 특성 분류(기본·설계·파생)에서 예시가 어디에 속하는지 묻는 문제가 자주 나온다. 원래 업무에 있던 코드는 기본 속성, 새로 만든 코드·일련번호는 설계 속성, 계산 값은 파생 속성이다.
- 파생 속성은 데이터 정합성 관리 부담이 크므로 가급적 적게 정의한다.
- 엔터티 구성 방식 분류(PK·FK·일반 속성)와 특성 분류(기본·설계·파생)를 섞지 말 것.
- 한 인스턴스의 한 속성은 하나의 값만 가진다. 다중값 속성은 별도 엔터티로 분리한다.
- 도메인은 속성이 가질 수 있는 값의 범위이며, 데이터 타입·크기·제약 조건으로 구현한다.
- Chen, P. P. (1976). "The Entity-Relationship Model—Toward a Unified View of Data". ACM Transactions on Database Systems, 1(1), 9–36. doi:10.1145/320434.320440
- Oracle Database SQL Language Reference – constraint
- Oracle Database Concepts – Data Integrity