#5.관계형 데이터베이스

1. 관계형 데이터베이스 

1970년 IBM의 연구원인 에드거 코드(Edgar F. Codd) 박사는 관계형 모델(Relational Data Model)이라는

새로운 데이터 모델을 제안 했다.

관계형 데이터 베이스의 가장 큰 장점은 업무 변화에 따른 적응 능력이 탁월 하다는 것이며, 이는 생산성이

높다는 것을 의미한다.

 

관계형 데이터베이스는 의미는

최소한의 의미를 갖는 테이블로 구성되고, 그 테이블에 있는 필드들을 서로 연결된 것이다.

여기서 최소한의 의미를 갖는 테이블로 구성된다라는 말은 논리적인 최소의 단위로 테이블이 정의되어야

한다는 것이다.

 

우리가 데이터베이스를 설계할 때 가장 명심해야 할 중요한 내용으로서, 궁극적으로 테이블에 포함되는

컬럼(많아야 10개 내외)의 숫자가 많지 않아야 한다는 것을 의미한다.

관계형 데이터베이스에서 관계는 부모테이블의 기본키(PK)가 자식 테이블에 포린키(FK)로 전이됨으로써

연결되는 것이다.

 

 

2. 부모 테이블과 자식 테이블

개념적 데이터 모델링 단계에서는 관계를 정의할 때 업무적인 연관성이라고 정의 했는데

이러한 관계는 일반적으로 두 테이블 사이에서 이루어지게 되는데,

관계를 맺고 있는 두 테이블 중에 반드시 하나는 부모 테이블이 되고, 나머지 하나는 자식 테이블이 된다.

이때 부모와 자식을 구분하는 기준은 업무를 중심으로 누가 주체로서 역할을 하느냐 이다.

부모 테이블과 자식 테이블 예제

위 그림에서 부서와 사원 테이블 사이에는 소속이라는 관계가 정의되어 있다.

소속되는 쪽이 객체이고, 소속시키는 쪽이 주체가 될것이며 당연히 부서에 사원이 소속되는 것이므로

부서가 부모 테이블이 되고, 사원이 자식 테이블이 된다.

 

단, 동일한 테이블 간의 사이라도 관계가 다르게 정의 되어짐에 따라 부모와 자식의 역할이 반대로 표현되는

경우도 있을 수 있다.

[사원 - 관리 -부서] 처럼 동일한 테이블 간에도 관계의 정의에 따라서 부모와 자식과의 관계가 바뀔 수도

있는 것이다.

주체 관계로 구분이 모호한 경우에는 "어느 테이블의 데이터가 먼저 정의되어야 하는가?" 라는 것을 기준으로 

부모 테이블과 자식 테이블을 구분하면 보다 쉽게 부모 테이블과 자식 테이블을 정의할 수 있을 것이다.

 

우선 업무적인 상황에 따른 관계를 정확하게 파악해야만 하며, 그 관계에 따라서 부모와 자식과의 관계를 정확하게

정의해 주어야 한다.

만일 부모와 자식의 관계가 잘못 정의되면 , 그 이후에 발생하는 모든 프로세스도 역시 잘못되게 마련인 것이다.

 

 

3. 기본키(Primary Key)와 포린키(Foreign Key)

개념적 데이터 모델링 단계에서 식별자를 정의할 때

후보 식별자 중에서 해당 실체를 대표할 수 있으면서 업무적으로 활용도가 높고, 길이가 짧은 속성을 주 식별자로

정의 한다고 했다.

 

개념적 데이터 모델링 단계에서 정의된

주 식별자는 관계형 데이터베이스에서 기본키(Primary Key)로 정의되며 관계를 형성하고 있는 두 테이블 중에

부모 테이블의 기본키(Primary Key)는 자식 테이블에 포린키(Foreign Key)로 전이된다.

이때 이 전이 된다 라는 말은 

부모 테이블의 기본키가 자식 테이블에 형식과 구조가 복제된다는 것을 말하며, 이렇게 기본키가 자식 테이블에

포린키로 전이됨으로써 관계형 데이터베이스 에서 관계가 정의되는 것이다.

 

 

4. 관계의 표현방식

I/E 표기법

관계의 표현방식

위 관계의 표현방식 중 Exactly 관계를 사용하는 경우는 

제조업체의 경우 어떤 제품에 대한 부품 구성 내역이 정형화되어 있기 때문에 사용하는 경우가 있다.

 

개념적 데이터 모델링 단계에서 정의했던 관계에 대한 표현 방식은

실체-관계 모델에 의한 표현 방식으로 마름모 기호를 통해 정의되었지만,

논리적 데이터 모델링 단계에서의 관계에 대한 표현 방식은

위와 같은 형식으로 정의 될 수 있으며 정보 공학(Information Engineering)적인 표기 방식 이라고 한다.

그 외 방식으로는 Idef1x 표기방식이라는 미국의 국방성에서 프로젝트 표준안으로 제안된 모델이 있다.

 

 

5. 식별관계와 비 식별관계

부모 테이블의 기본키는 자식 테이블의 포린키로 전이된다고 했는데 전이 유형에는 2가지가 있다.

식별관계(Identifying Relationship)와 비 식별관계(Non Identifying Relationship) 이다.

이 식별관계, 비 식별관계에 대한 정의는 궁극적으로 개발자의 의지에 달려있다.

동일한 상황이라 하더라도 개발자는 식별관계를 선택할 수도 있고, 비 식별관계를 선택할 수도 있다. 

 

①식별관계 

부모 테이블의 기본키가 자식 테이블의 기본키, 혹은 기본키 그룹의 구성원으로 전이되는 것이다.

이런 형태의 식별관계는 기본적으로 두 테이블간의 차수가 일대일인 경우와 다대다 관계를 해소하기 위해

정의한 교차 실체에서 그 예를 쉽게 찾아볼수 있다.

식별관계 예제1

②비 식별관계

부모 테이블의 기본키가 자식 테이블에 일반 속성그룹으로 전이되는 것을 말한다.

비 식별관계 예제1

그렇다면 부모 자식 관계에서 "동아리 등록" 테이블 내의 학번 컬럼과 동아리 코드 컬럼이 전이 되었을때

기본키 그룹으로 묶어서 사용하지 않고 왜 새로운 기본키인 등록 번호를 만들어서 일반 속성으로 사용할까?

식별-비식별 관계 예제1

위 그림은 "동아리 등록" 이라는 테이블이 자식 테이블인 "활동 내역" 이라는 테이블을 갖게 되는 경우이다.

 

관계형 데이터베이스에서는 부모 테이블과 자식 테이블이 관계를 맺게 되면 부모 테이블의 기본키들이 

자식 테이블의 기본키(식별관계)나 일반 속성(비 식별관계)으로 전이 되어야 한다.

 

그렇다 보니 식별관계 형태로 부모 자식 형태로 테이블이 관계가 형성되어, 이런 형태로 몇단계를 이어지다 보면

부모 테이블의 기본키들이 계속 자식 테이블로 전이 되고,

그 자식과 관계 있는 또 다른 테이블이 존재하면 또 기본키들이 전부 다 전이되면서 계속적으로 기본키가 늘어나는

비효율성 이란 문제에 부딪히게 된다.

궁극적으로 포린키 컬럼이 여러 개이므로 자식 테이블에 Row의 길이도 커질 뿐만 아니라 조인(Join)을 하기 위해서도

포린키 컬럼의 숫자만큼 조인의 조건을 정의해 주어야만 하기 때문에 당연히 관련된 프로세스가 비효율적으로 동작

할 수 밖에 없다.

 

그러므로 위와 같이

[학생 테이블]과 [동아리 등록 테이블], 그리고 [동아리 테이블]과 [동아리 등록 테이블]의 관계를

비 식별관계로 정의하고, [동아리 등록 테이블]의 기본키를 설계 속성 형태의 등록번호(PK)로 정의하면

[활동내역 테이블]에 포린키 컬럼도 등록번호(FK) 하나만 전이되게 됨으로써 활동내역 테이블의 Row의 길이도

줄어들 뿐만 아니라 조인(Join)을 할 때에 조인(Join)의 조건도 한번 만 정의하면 되므로 훨씬 더 효율적인 프로세스를

기대할 수 있는 것이다.

 

 

6. 데이터 무결성

말 그대로 잘못된 데이터가 입력되지 못하도록 정의하는 것을 말하며, 이러한 데이터 무결성의 종류에는

참조 무결성(Table 대상), 실체 무결성(Row 대상), 도메인 무결성(Column 대상) 등이 있다.

 

①참조 무결성

관계를 맺고 있는 두 테이블 사이에 서로 불일치한 데이터가 발생하지 못하도록 강제하기 위한 제약조건으로서, 

부모 테이블에 존재하지 않는 데이터가 자식 테이블에 입력될 수 없도록 강제하기 위한 제약 조건인 것이다.

즉, 자식 테이블에 데이터가 입력될 때는 항상 부모 테이블의 기본키 컬럼을 참조해서 부모 테이블의 기본키 컬럼에

데이터가 존재하면 입력을 허용하게 되고, 그렇지 않으면 입력을 허용하지 않게 된다.

 

이러한 상황은 자식 테이블에서 데이터를 수정할 때도 역시 부모 테이블의 기본키 컬럼을 참조해서

부모 테이블의 기본키 컬럼에 존재하는 데이터로만 수정될 수 있도록 강제하며, 

부모 테이블의 데이터를 수정하거나 삭제할 때에도 역시 이 데이터를 참조하고 있는 데이터가 자식 테이블에 존재

한다면 이를 수정하거나 삭제하지 못하게 강제한다.

제약조건	부모 테이블	자식 테이블
입 력	제약 없음	부모 테이블에 데이터가 존재하는지 검증
수 정	수정 하려는 데이터를 자식 테이블에서 참조 하고 있는지를 검증	부모 테이블에 존재하는 다른 데이터로 변경 가능
삭 제	삭제 하려는 데이터를 자식 테이블에서 참조 하고 있는지를 검증	제약 없음

참조 무결성의 여러 옵션 중에 CASCADE란 옵션이 있다.

이 옵션은 부모 테이블의 기본키 컬럼에 있는 데이터를 수정하거나 삭제할 경우, 이를 참조하고 있는 자식 테이블의

데이터도 함께 수정하거나 삭제하도록 정의하는 옵션이다.

그러나 CASCADE 옵션은 일반적인 관계에서 보편적으로 적용되는 경우는 아니다.

 

②실체 무결성(Row: 행)

한 테이블 내에서 각각의 로우(Row)는 상호 구분이 가능해야 하며 모든 테이블에는 반드시 각각의 로우를 구분할 수

있는 기본키가 반드시 존재해야만 한다.

기본키는 테이블을 정의할 때 옵션이 아니라 필수이다.

 

③도메인 무결성(컬럼)

한 컬럼에 입력될 수 있는 데이터의 유형, 형식, 경우의 수 등을 정의해서 잘못된 형식의 데이터가 입력되지 못하도록

하는것을 말한다.