[DB이론] 관계 모델( Relation Model ) - 논리적 설계

1. 관계 모델 ( Relation Model )

관계형 모델은 실제 세계의 데이터를 관계라는 개념을 사용해 표현한 데이터 모델입니다.

데이터 모델이란 "~~라는 개념을 사용해 데이터를 표현해주세요"라고 정의하는 것을 말하며, 관계형 모델은 그중에 하나라고 할 수 있습니다.

몽고DB 같은 KVS( Key-Value Store )도 데이터 모델의 하나라고 볼 수 있습니다.

관계형 모델은 수학의 집합론에 근거한 모델이며, 릴레이션(테이블)의 연산을 술어논리로 표현할 수 있어야 합니다.

SQL과 관계형 모델을 동일시 여기는 경우가 있는데, 이 둘은 다른 개념입니다.

그렇기 때문에 관계형 모델과 SQL에서 사용하는 용어도 다른데, 용어에 대해서는 조금 뒤에 언급하겠습니다.

이 글에서는 ER 모델을 관계형 모델로 변환하는 방법에 대해 다루기 때문에 둘의 차이점을 자세히 다루지 않지만, SQL 테이블과 관계형 모델을 엄연히 다릅니다.

관계 모델은 관계형 데이터베이스에 직접 구현할 수 있도록 DB구조를 정의하는 방법을 제공합니다.

쉽게 테이블을 설계하는 과정이라고 생각하시면 되고, ER 다이어그램을 기반으로 작업하는 것이 순서입니다.

관계 모델은 릴레이션의 관계를 표현하는 것입니다.

아래는 관계 모델의 핵심인 릴레이션에 대한 예시입니다.

• 릴레이션 ( Relation )
• 개체를 표현하기 위한 데이터 구조로써 2차원 테이블로 표현하며, heading(스키마)와 body(본체)로 구성되어 있습니다.
• heading은 속성(attribute)이 n개가 모인 집합이며, 이름과 데이터형으로 구성되어 있습니다.
• body는 속성값의 집합인 튜플(tuple)의 집합입니다.
• SQL의 테이블과 대응됩니다.
• 튜플 ( Tuples )

• 하나의 개체를 의미하고 Relation에서 행으로 표현하며, 이를 릴레이션 상태( Relation State )라고도 합니다.

• 각 튜플은 유일해야 한다는 특징이 있습니다.

• SQL의 row와 대응됩니다.

• 애트리뷰트 ( Attributes )

• 개체의 속성들을 의미하며 Relation에서 열로 표현

• SQL의 column과 대응됩니다.

이를 정리하면, 릴레이션은 튜플의 모임이고, 릴레이션의 관계를 정의한 것이 관계 모델입니다.

관계 모델은 릴레이션 단위로 다양한 연산을 사용해 질의를 수행하는 데이터 모델입니다.

2. 제약 조건

관계 모델이 정의되기 위해서는 몇 가지의 제약 조건이 있습니다.

1) 무결성 제약 조건 ( Integrity constraints )

한 객체에 저장되는 데이터를 제한하는 조건을 말합니다.

• 도메인 제약 조건
• 각 튜플의 애트리뷰트는 도메인에 속하는 값이어야 합니다. 
• 즉, 도메인이 Integer면 Integer 값만 저장될 수 있습니다.
• 엔티티 무결성 제약 조건
• 기본 키 값은 NULL이 될 수 없습니다.
• 참조 무결성 제약 조건
• 어떤 릴레이션 A의 튜플이 다른 릴레이션 B의 튜플을 참조하려면, 참조하려는 그 튜플은 B 릴레이션 내에 존재해야 합니다.
• 외래 키(Foreign key)는 참조 무결성 제약조건을 만족해야 합니다.
• 외래 키 : 다른 릴레이션의 key 애트리뷰트를 참조하는 애트리뷰트

2) 키 제약 조건

서로 다른 튜플은 동일한 키 애트리뷰트를 갖지 않아야 한다는 조건을 말합니다.

3. ER 모델을 관계 모델로 변환

관계 모델은 ER 모델을 기반으로 설계된다고 언급했었는데요,

이제 개념적 설계인 ER 모델을 논리적 설계인 관계 모델로 바꾸는 방법에 대해 알아보겠습니다. ( ER 모델에 대해서는 여기를 참고해주세요. )

1) 일반적인 변환

일반적으로 ER모델과 Relation은 다음과 같이 대응됩니다.

• 하나의 Entity는 한 개의 Relation으로 대응
• Entity가 가지고 있는 Attribute들은 Relation의 Attribute로 대응
• Relation Entity인 Takes 역시 하나의 Relation으로 표현

이것이 ER모델을 Relation으로 변환하는 일반적인 방법입니다.

지금부터 ER모델의 특별한 Attribute에 대해서 ER모델을 Relation모델로 변환할 때의 주의점, 또 두 Entity간의 관계성에 따라 릴레이션의 수를 줄일 수 있는 방법에 대해 알아보도록 하겠습니다.

2) 복합 Attribute

복합 Attribute을 구성하고 있는 독립된 Attribute들을 나눠서 관계 모델의 Attribute로 작성합니다.

ER 모델의 복합 Attribute인 Address를 구성하고 있는 do, si, dong, apratment Attribute들은 관계 모델로 변환할 때 일반적인 단일 Attribute처럼 취급합니다.

즉, 왼쪽 릴레이션 처럼 Address 안에 독립적인 Attribute가 포함된 것이 아니라, 오른쪽 릴레이션처럼 각 Attribute들이 단일 Attribute처럼 취급합니다.

3) 약한 개체 ( Weak Entity )

ER 모델에서 약한 개체는 독립적으로 존재할 수 없고 Owner Entity Type에 종속적입니다.

그런데 관계 모델로 변환할 때는 약한 개체를 독립된 Relation으로서 작성해야 합니다.

bunban Entity는 약한 개체로서 Course에 종속적입니다.

약한 개체인 bunban을 ER모델에서 Relation으로 변활할 때는 하나의 Relation으로 표현합니다.

이 때 주의할 것은 bunban Relation의 Attribute에 Owner Entity Type인 Course Entity의 key가 Attribute로 추가된다는 것입니다.

즉, bunban Relation의 속성에는 course_no가 추가됩니다.

4) 유도된 Attribute

ER 모델의 유도된 Attribute는 Relation모델에서는 생략됩니다.

상품 가격의 총합을 나타내는 total Attribute는 price와 count에 의해 계산되어진 유도된 Attribute입니다.

유도된 Attribute는 ER 모델에서 Relation으로 변환할 때 Attribute로 추가되지 않습니다.

그래서 변환된 Relation에는 total이라는 Attribute가 없습니다.

5) 다중값 Attribute

다중값 Attribute의 각 Attribute 값들은 Relation에서 하나의 튜플이 됩니다.

Student Entity에 friends라는 다중값 Attribute가 있을 때,

왼쪽 릴레이션처럼 다중값 Attribute를 하나의 튜플안에 표현하는 것이 아니라,

오른쪽 릴레이션처럼 friends의 각 값들이 각각 하나의 튜플이 되어 작성되어야 합니다.

참고로 이렇게 중복을 없애는 작업을 정규화라고 합니다.

앞서 일반적인 변환에서 ER 모델의 Relation Type을 관계 모델로 변환을 할 때 별도의 릴레이션을 작성해야 한다고 했었습니다.

그 이유는 두 Entity가 관계를 맺고 있다는 것을 두 Entity의 primary key를 Attribute로 하는 하나의 릴레이션으로 만듦으로써 표현할 수 있기 때문입니다.

그러나 릴레이션이 많아지는 것은 연산이 복잡해진다는 것을 의미하기 때문에 릴레이션의 수를 줄이는 것이 좋습니다.

Relationship으로는 1:1, 1:N, M:N이 있으며 어떤 경우에는 ER모델의 Relation Type이 관계 모델로 변환될 때 생략될 수 있습니다.

물론 다른 방법으로 두 Entity의 관계를 표현합니다.

이제 Relationship의 각 경우에 대해 ER모델을 관계 모델로 변환할 때의 주의사항을 알아보겠습니다.

6) 1:1 관계

어떤 두 Entity의 관계성이 1:1 관계일 때 ER모델의 Relation Type을 관계 모델로 변환을 할 경우,

Relation Type에 해당하는 릴레이션을 따로 만들지 않고, 한 쪽의 Entity에 다른 Entity의 primary key와 Relation Type의 Attribute들을 Attribute로 추가합니다.

예를 들어, Employee Entity Type에 e_no가 101~105인 개체 5개가 있고, Store Entity Type에  s_no가 101~103인 개체 3개가 있다고 해보겠습니다.

두 엔티티를 어느 한 쪽으로 합쳤을 때의 결과를 보면 다음과 같습니다.

Employee 릴레이션에 manage의 startDate 애트리뷰트, Store의 primary key인 s_no을 추가할 경우 왼쪽 릴레이션과 같고,

Store 릴레이션에 manage의 startDate 애트리뷰트, Employee의 primary key인 e_no을 추가할 경우 오른쪽 릴레이션과 같습니다.

두 방식의 차이점은 null이 있느냐 없느냐 입니다.

Employee의 경우 Store와 관계를 맺지 않고 있는 튜플이 많이 있기 때문에, Employee에 합칠 경우 관계를 맺지 않는 개체에 대해서 null 값이 생성됩니다.

반면 Store 쪽으로 합칠 경우에는 null이 생성되지 않죠.

두 방식 중 뭐가 좋느냐, 결론은 null이 적게 생기는 릴레이션 쪽으로 Attribute를 추가하는 것이 좋습니다.

즉, 1:1 관계일 때 ER모델을 관계 모델로 변환하는 방법은

• Relation Type에 해당하는 릴레이션을 생성하지 않는다.
• 원래 Relation Type에 있어야 할 Attribute들을 관계를 맺는 두 릴레이션 중 한쪽으로 합쳐버립니다.
• 합칠 때 null이 적게 생기는 경우를 선택하여 합칩니다.

7) 1:M 관계

1:M 관계에서도 마찬가지로 Relation Type에 해당하는 릴레이션을 생성하지 않고 릴레이션을 합칩니다.

부모(parent)는 많은 자식(children)을 가질 수 있고 자식은 한 부모를 가지므로, 부모와 자식은 1 : M 관계입니다.

이 경우 ER모델을 관계 모델로 변환할 때, Many에 해당하는 릴레이션 쪽으로 Attribute들을 합칩니다.

즉, parent, relate의 Attribute들이 모두 children으로 합쳐집니다.

이렇게 합치는 이유 역시, null이 적게 생기기 때문입니다.

8) N:M 관계

N:M 관계는 앞에서 소개했던 일반적인 경우처럼, 관계를 맺는 두 Entity의 primary key를 가져와서 하나의 릴레이션을 생성합니다.

즉, 기존의 두 엔티티가 릴레이션으로 변환되고, primary key를 가져와 하나의 릴레이션을 생성하여 총 3개의 릴레이션이 생깁니다.

이상으로 관계 모델에 대해서, 그리고 ER모델을 관계 모델로 변환하는 방법에 대해 알아보았습니다.

ER모델을 관계 모델로 변환할 때는 Attribute에 따라, Relationship에 따라 조금 다른 방법이 적용되는데 이 부분을 주의해서 모델을 작성해야 합니다.

올바르지 못한 테이블 설계는 연산의 부하 및 메모리 낭비 등 문제점을 초래하기 때문입니다.