02. 속성, 관계, 식별자

SQLD STUDY NOTE · PART 1 · 02

속성, 관계, 식별자

엔터티에 살을 붙이는 속성, 엔터티끼리 잇는 관계, 인스턴스를 구별하는 식별자를 정리한다.

속성, 더는 쪼개지지 않는 최소 단위

속성이란 업무에서 필요로 하는, 인스턴스로 관리하고자 하는 의미상 더는 분리되지 않는 최소의 데이터 단위다. 엔터티가 무엇인지를 정의한다면, 속성은 그 무엇이 구체적으로 어떤 성질을 갖는지를 정의한다.

생년월일을 예로 들면 이해가 쉽다. 생년월일은 그 자체로 하나의 속성이다. 이걸 생년·생월·생일로 쪼개도 여전히 하나의 속성을 관리 편의상 나눈 것일 뿐이다. 반대로 서로 관련 없는 이름과 주소를 '이름주소'라는 속성 하나로 묶으면 문제가 생긴다. 한 속성이 두 가지 의미를 동시에 가지게 되어 기본속성으로 성립하지 않는다. 이런 경우는 속성이 아니라 '내역(Description)'으로 다뤄야 한다.

업무 필요성업무에서 실제로 관리해야 하는 정보여야 한다.

함수적 종속주식별자에 종속되는 값이어야 한다.

단일 값하나의 속성은 한 개의 값만 가진다. 다중값이면 별도 엔터티로 분리한다.

엔터티·인스턴스·속성·속성값의 관계를 정리하면 이렇다. 한 개의 엔터티는 두 개 이상의 인스턴스를 가진다. 한 개의 엔터티는 두 개 이상의 속성을 가진다. 한 개의 속성은 한 개의 속성값을 가진다. 사원 엔터티에 홍길동이라는 인스턴스가 있고, 이름·주소·전화번호·직책이라는 속성에 각각 '홍길동', '서울시 강남구', '123-4567', '대리'라는 값이 채워지는 방식이다.

속성의 세 갈래

분류	정의
기본속성	업무로부터 바로 추출한 속성. 엔터티에서 가장 큰 비중을 차지한다
설계속성	업무상 존재하지 않지만 설계 과정에서 새로 도출한 속성 (코드, 일련번호 등)
파생속성	다른 속성의 영향을 받아 계산되어 나오는 속성

파생속성은 원본 속성이 바뀌면 값이 어긋날 위험을 늘 안고 있다. 되도록 적게 두는 편이 데이터 정합성 관리에 유리하다.

이름 붙이기. 현업 용어를 그대로 쓰고, 서술식보다 명사형을 쓰며, 공용화되지 않은 약어는 피한다. 속성명을 되도록 유일하게 부여해두면 나중에 반정규화로 이름이 충돌하는 상황을 피할 수 있다.

RELATIONSHIP

관계, 인스턴스끼리 맺는 연관

관계란 엔터티의 인스턴스 사이에 존재의 형태로나 행위로 부여된 논리적 연관성이다. 여기서 반드시 짚어야 할 개념이 관계 패어링(Relationship Pairing)이다. 관계는 엔터티가 아니라 그 안의 개별 인스턴스가 맺는 연결, 즉 패어링의 집합이다. 그래서 같은 두 엔터티 사이에도 인스턴스별로 성격이 다른 관계가 두 개 이상 형성될 수 있다.

관계는 성립 방식에 따라 존재 관계와 행위 관계로 나뉜다. 사원이 어떤 부서에 '소속되어 있는' 것은 행위 없이도 성립하는 존재 관계다. 고객이 '주문한다'는 행위로 주문 데이터가 생겨나는 것은 행위 관계다. 관계의 표현은 이항·삼항·n항으로 나눌 수 있지만, 실무에서 삼항 이상은 거의 등장하지 않는다.

관계를 검증하는 질문법

관계를 정의한 뒤, 그 문장의 뒷부분을 의문문으로 바꾸면 검증 질문이 된다. "한 주문에 대해서 하나의 제품만을 주문합니까?"처럼 물으며 업무 담당자와 대화하면 관계를 자연스럽게 다듬어갈 수 있다. 이 방법은 관계 설정뿐 아니라 업무 흐름을 함께 확인하는 데도 쓸모가 있다.

IDENTIFIER

식별자, 인스턴스를 가리키는 이름

엔터티는 인스턴스들의 집합이므로, 그 안에서 각 인스턴스를 구별할 논리적인 이름이 필요하다. 이것이 식별자다. 여기서 흔히 헷갈리는 지점이 있다. 식별자와 키(Key)는 쓰임이 다르다. 식별자는 업무적으로 구분되는 정보로서 논리 데이터 모델링 단계에서 쓰고, 키는 테이블에 접근하는 매개체로서 물리 데이터 모델링 단계에서 쓴다.

주식별자가 갖춰야 할 조건

• 엔터티 내 모든 인스턴스가 이 식별자만으로 유일하게 구분되어야 한다.
• 식별자를 구성하는 속성 수는 유일성을 만족하는 최소한이어야 한다.
• 값이 자주 바뀌지 않아야 한다.
• 주식별자로 지정되면 반드시 값이 있어야 한다. NULL은 허용되지 않는다.

분류 기준	종류
대표성 여부	주식별자 / 보조식별자
스스로 생성 여부	내부식별자 / 외부식별자
속성 수	단일식별자 / 복합식별자
대체 여부	본질식별자 / 인조식별자

주식별자를 고르는 세 가지 기준

1. 업무에서 자주 쓰이는 속성을 고른다. 직원 엔터티에서 주민등록번호와 사원번호가 모두 유일하게 식별 가능하더라도, 실무에서 자주 쓰는 사원번호를 주식별자로 삼고 주민등록번호는 보조식별자로 둔다.
2. 명칭이나 내역처럼 이름으로 기술되는 값은 피한다. 부서이름 같은 긴 문자열은 조회 조건에 매번 정확히 써넣기 번거롭다. 이럴 땐 별도의 일련번호나 코드를 새로 만드는 편이 낫다.
3. 복합식별자를 쓸 때는 속성 수를 최소로 유지한다.