RDB 1:M 관계 (2)

회사와 부서 간의 관계를 고려하여 1:M 관계 모델링 연습을 해보자.

테이블 설계 시 숙지 사항

예제에 들어가기에 앞서, 테이블 설계 시 고려하면 좋을 것들을 숙지하고 가자.

테이블 스키마를 설계할 때는 key들을(기본키, 외래키) 먼저 고려하고 key를 중심으로 어떻게 설계해나갈지 계획을 세운다.
초기 설계 시에는 속성들은 간단히 잡아가는 것이 좋다. 처음부터 모든 속성들을 작성하려면 정신 사납다. 테이블 설계의 본질은 key들의(기본키, 외래키) 관계를 잘 설계 해나가는 것이다.
고객으로부터 얻은 데이터들은 key로 사용하지 않는 것이 좋다. 고객으로부터 얻은 데이터들은 부재 또는 변화의 가능성이 존재하기 때문에 PK에 포함시켜 의미를 부여하는 것은 위험할 수 있다.
숫자 타입으로 인조 식별자를 사용하는 경우 자동 증분(AUTO INCREMENT)을 사용하는 것이 편리하고 안전하다. 단, 데이터 발생 규모를 파악하여 데이터 타입을 정하자.

1:M 모델링 예제 (회사 & 부서)

회사와 부서 간의 테이블을 설계하기 전에 1:M 설계 과정을 살펴보자.

일단, 각 테이블의 스키마를 작성하고 PK를 정해보자.

회사 테이블

company_id를 PK로 잡았다. 초기에 속성은 간단하게 company_name만 작성했다.

	열 이름	데이터 형식	NULL 허용	AUTO INCREMENT
PK	company_id	int	x	o
	company_name	varchar(50)	x	x

부서 테이블

department_id를 PK로 잡았다. 마찬가지로 속성을 department_name만 간단하게 잡았다.

	열 이름	데이터 형식	NULL 허용	AUTO INCREMENT
PK	department_id	smallint	x	o
	department_name	varchar(50)	x	x

PK 결정이 끝났다면 그 이후 두 테이블 간의 관계를 보는 것이다.

⭐️ 관계를 볼 때는 각 테이블의 입장에서 관계를 고려해야 한다.

회사 입장에서 부서와의 관계, 부서 입장에서 회사와의 관계를 모두 살펴본 다음 1:1 인지 1:M 인지, M:N 인지 결정하는 것이다. 따라서 양쪽에서 살펴봤을 때 반드시 동일한 관계 양상이 나와야 한다.

회사와 부서의 관계는?

양쪽 입장에서 살펴봤을 때 회사와 부서의 관계는 1(회사):M(부서) 관계이다.

즉, 1(회사)의 PK가 M(부서)의 FK로 나타나야 한다.

	열 이름	데이터 형식	NULL 허용	AUTO INCREMENT
PK, FK	company_id	int	x	x
PK	department_id	smallint	x	x
	department_name	varchar(50)	x	x

이렇게 PK, FK 등을 설정하는 과정이 끝나면 테이블 스키마의 주된 골격을 설계했다고 볼 수 있다.

이 다음 과정이 회사, 부서의 나머지 컬럼(속성)들을 조사 및 분석하여 채워나가는 것이다.

회사 ID와 부서 ID를 묶어서 복합키를 PK로 잡으면 어떤 차이가 있을까?

결론부터 말하자면, 부서 ID(department_id) 생성 체계가 달라진다. 복합키를 PK로 잡는다면, 각 회사마다 부서 ID를 1번으로 시작할 수 있다. 복합키가 아닌 부서 ID만을 PK로 잡는다면, 자동 증분을 이용해서 PK 값이 계속 증가하는 수 밖에 없다. 따라서 회사별로 동일한 부서에 대해서 동일한 부서 ID를 부여하고 싶으면 묶어서 PK를 만들면 된다. 즉, 복합키를 PK(기본키)로 잡는 것은 회사-부서 관계에 있어서 의미부여 효과가 생긴다.

1:M 관계에서 어떤 테이블의 데이터가 먼저 들어가야할까?

항상 반드시 부모가 먼저 삽입되어야 한다.

insert into 회사 values('삼성전자');
insert into 부서 values(1, 1, '총무부');