3. 테이블 설계와 릴레이션

테이블 설계

• 직원/부서관리 단일 테이블
• emp_id
• emp_name
• emp_roman
• emp_email
• dept_name
• dept_tel

• 위와 같이 직원과 부서의 내용을 같이 관리하게 되면 dept_name에 중복이 계속해서 일어나게 됨
• copy & paste가 많게 되면 모든 부분을 바꾸었다고 생각해도 미처 바꾸지 못한 부분이 남아있게 되는 경우가 많음. 즉 한 개의 테이블에 전부를 갖는다는 방법 자체가 잘못된 것

• → 직원과 부서를 분리해서 관리
• 일반적으로 기본 키의 값은 한번 정해지면 쉽게 변경되지 않아야 한다(RDBMS에서 기본 키 값이 자주 변경되면 내부 데이터가 심하게 조각을 일으켜 성능을 크게 악화시킬 수 있다)
• 이 때 dept_name으로 관계를 맺으면 dept_name이 바뀔 수 있으므로
• 잘 바뀌지 않는 dept_id를 도입하여 pk로 설정

참조 무결성 제약(Referential Integrity)

• emp 테이블에 dept_id를 입력할 때 그 값이 dept 테이블에 있는지에 대한 여부 자동으로 체크

• dept 테이블의 레코드를 지우려 할 때 해당 dept_id가 emp 테이블에 존재하는 경우 오류 발생

• 만약 규모가 큰 웹사이트라서 emp 테이블을 전용 서버에서 관리하고 dept 테이블은 다른 서버에서 관리하는 등의 경우가 생기게 되면, 참조 무결성 제약을 사용하는 것이 아닌 해당 기능을 애플리케이션에서 구현하여 확인

• 모든 RDBMS가 외래 키 대상 열에 인덱스를 부여하는 것을 필수 조건으로 하고 있음

테이블 설계의 타당성 검증하기(N:N관계 → 1:N 관계 두개 도입 & 매핑테이블 )

• 만약 위와 같은 설계에서 사원이 여러 부서에 속해야 할 때(겸임)는 어떻게 해야할까?
• emp 테이블에 dept_id, dept_id2, dept_id3 이렇게 계속 추가해야 할까…?(Set 형태의 컬럼을 이용할 수도 있지만 이는 검색하기도 불편) ⇒ 1:N 관계를 두 개 도입하여 매핑 테이블을 사용하기!

매핑 테이블의 특징

기본 키 값이 자주 바뀐다

• 전근 등이 발생했을 때 기본 키 값이 변경됨

• 겸임 위치가 변경되는 경우 기존의 열을 지우고 새로운 열을 등록하는 대신 [겸임 시작일], [종료일] 문자열 추가해서 기본키를 변경하지 않는 형태(항상 추가로 기록해 나가는 형태)로 하는 경우도 많음

레코드 수가 많아진다

• 매핑 테이블의 레코드 수는 매핑의 소스가 되는 두 개(혹은 그 이상)의 테이블보다 많다

• 만약 온라인 게임에서 수백만 사용자 끼리의 대전 정보를 (user_id, target_user_id) 등으로 관리하는 경우 쉽게 억 단위의 레코드에 도달하게 됨 ⇒ 한 개 서버에서 관리하기에 데이터 양이 너무 많아서 테이블 분할하여 복수 시스템에서 갖고 있도록 하는 접근방식 사용될 수도 있음

• 수많은 레코드가 되면 사이즈도 수백 GB(또는 몇 TB) 단위로 늘어나기 때문에 제대로 성능을 낼지 장담하기 어려운 과제가 됨.

정규화 이론의 기본