[Data Base] 2. E/R 관계성 모델에 대하여..

지난번에 이어서 이번에는 엔티티-관계성 데이터 모델에 대해서 보도록 하겠습니다.

먼저, 데이터 모델을 조금 살펴보면 제가 알법한 모델은 객체 지향 모델 같은 형태가

있습니다.

데이터 모델(Data Model)
- 데이터와 데이터들간의 관계를 기술하는 개념적 도구
- 데이터베이스의 논리적 구조를 명시.

데이터 베이스 모델링과 구현 과정을 살펴봅시다.

착상 -> E/R 모델링 -> 관계형 스키마 -> 관계 DBMS

위와 같은 과정을 거치게 됩니다. 그리고 2번째 단계에 있는 E/R 모델링에 관하여

2장에서 다루게 됩니다.

E/R 모델링을 하고나면 E/R 다이어그램이 나와야하고 E/R 다이어그램이 나오면

관계형 모델로 변환해야 하는데, 그 과정에서 관계형 스키마가 된다.

3번쨰 단계의 관계형 스키마는 3장에서 다루게 된다.

본격적으로 E/R, 즉, 엔티티-관계성에서 대해서 살펴보자.

엔티티-관계성(Entity-Relationship: E/R) 다이어그램
- 데이터베이스 모델링을 그래프로 표현

엔티티-관계성 다이어그램의 세 가지 구성요소

-엔티티 집합(Entity Set) : 클래스, 엔티티는 객체에 해당
*엔티티는 객체와 같다 엔티티의 집합은 클래스와 같다.
-애트리뷰트 : 엔티티의 특성을 기술하는 값.
-관계성 : 둘 이상의 엔티티 집합들간의 연결

엔티티-관계성 다이어그램을 보면 다음과 같이 시각화 할 수 있다.

다음 엔티티-관계성 다이어그램을 보면 영화 데이터베이스를 다이어그램 형식으로 표현한 것이다.

다이어그램을 표시할 때 사각형을 엔티티 셋으로 나타내고, 다이아몬드 모양을 관계성을

나타내며, 동그라미 모양을 애트리뷰트로 나타낸 것을 볼 수 있다.

다이어그램을 살펴보면 엔티티 셋은 이름을 대부분 복수형으로 가지게된다.

엔티티 '집합' 이니까, 그것이 맞을 것이다.

애트리뷰트들을 보면 엔티티 하나당 가지는 특성 값들을 나타내는 것을 볼 수 있다.

Movies 엔티티 셋과 Stars 엔티티 셋이 Stars-in(출연 관계) 관계성을 가진 것을 볼 수 있다.

그리고 Movies 엔티티 셋과 Studios 엔티티 셋이 Owns 관계성을 가진 것도 볼 수 있다.

그리고 살펴봐야할 부분이 데어터의 내용이 같다면 문자열 상의 내용이 같다면

같은 이름의 다른 것들을 표현할 수 없다.

엔티티 상의 내용이 다르면 전혀 다른 엔티티이나, 이후에는 데이터의 내용이 다르면 전혀

다른 데이터라는 것을 공부할 것이다.

이제는 관계성의 다중 연관성을 봐야 하는데, 다음과 같은 다중 연관성을 알아야 한다.

양 쪽 사이에 배우와 영화라는 엔티티 셋이 존재한다고 한다면 배우가 많은 영화에 출연했

을 수도 있고 영화에 많은 배우가 출연했을 수도 있다. 이런 관계를 다 대 다 관계라고 한다.

many to many 관계라고 한다.

그리고 영화라는 엔티티 셋과 제작사라는 엔티티 셋이 있다고 한다면 한 배급사에서 영화

를 많이 만들어 냈지만, 반대로 한 영화에서 많은 배급사가 나오지는 않는다. 즉, 영화 하나

당 배급사는 한 개 일 수 밖에 없다. 이런 관계를 다 대 일 관계라고 한다.

many to 1 관계라고 한다.

그리고 배급사 엔티티 셋과 대표자 엔티티 셋이 있다고 가정하자.

한 배급사에는 한 대표밖에 존재할 수 없다. 이렇게 1 대 1 대응되는 관계를

1 대 1 관계성이라고 한다.

다음 그림을 보면 관계성을 어떻게 표기하는지 확인할 수 있다.

이 다음으로 다중방향 관계성에 대해서 나오는데, 이 부분을 확인할 필요가 있다.

다중방향(multiway) 관계성
-세 개 이상의 엔티티 집합들이 참여하는 관계성
-다중방향 관계성은 그리 흔치는 않다.
-E/R 모델에서 다중방향 관계성은 충분한 의미 전달이 힘들다.
>> Contracts 관계성은 (star, movie) 그리고 (movie, Studio)의 연관 관계만을 보여주며, (star, studio)의 관계는 의미가 없다.

여기서 유의해야할 것은 3개가 엮여있다고 해서 many : 1 이라고 해도 Studios에 Movies와

Stars 둘 다 연결되있다고 생각하면 안되고 둘 중 하나인 엔티티 셋과 M : 1 관계를 가진다.

3자 관계성에선 Stars와 Movies의 한 쌍의 관계에선 그 관계가 유니크 해야한다.

즉, Stars와 movies의 한 쌍의 관계에서는 하나의 Studios가 나와야한다.

Movie -> A  Stars -> 1, 2 Studios -> F, X, K 라고 할 때

Movie가 A 일 때 Star가 1이고 Studio가 F 이다.
Movie가 A 이고 Star가 2이고 Studio가 X 라고 할 때
Movie가 A 이고 Star가 1일 때 Studio는 K 이다. 이것은 안된다는 것이다.

그 관계가 유니크 해야하기 때문에 Movie가 A이고 Star가 1 일 때 Studio가 F라면

무조건 그 관계에선 Studio가 F여야만 한다는 것이다.

관계성에서의 역할을 살펴보자.

관계성에서 한 영화가 있는 그 영화가 속편으로 2, 3 등이 나왔다고 하자. 이 영화들을 어떻게 구별할 것인가?

관계성에서 속편의 영화들을 구별하기 위하여, 한 선에는 역할 Original 이 표기되어있고

다른 하나에는 역할 Sequel이 표기되어있다.

이로 인해, Original 영화는 Movies에서 하나만 취급할 수 있고 Sequel 영화는 많이 취급할 수 있다.

즉, Sequel-of 관계성에서 Sequel 역할의 역할은 속편작끼리는 다 대 다 관계를 만들 수 있

으나 그 안에 속편작과 원작이 있으니 속편작과 원작의 관계성은 다 대 1 관계를 가져야 한다.

그 역할을 Original 역할이 하게 된다.

위의 다이어그램을 봐도 실질적인 관계성은 3가지 밖에 되지 않습니다.

어떤 스타와 계약을 맺고 있는 한 스튜디오는 그 스타가(다른 스튜디오에서 제작되는) 특정

영화에 출연할 수 있도록 다른 스튜디오와 계약할 수도 있다.

(studio1, studio2, star, movie) 가 관계성이 될 수 있다.

Contract의 관계성을 사각형(앤티티 셋)으로 바꿀 경우 그 사이에 다이아몬드(관계성)을 넣

어서 새로운 관계로 정의해줘야 한다.

경우에 따라 애트리뷰트는 관계성와 연관되어 지기도 한다.

다중 방향 관계성은 여러 개의 이진 다대일 관계성들로 변환 될 수 있다.

기존의 관계성을 앤티티 셋으로 바뀔경우, 연결(Connecting) 엔티티 집합을 만든다.

연결 엔티티 셋으로 바꿔줄 경우 그 엔티티 셋에 연결되는 관계 정보만 있다.

커넥팅 엔티티 셋은 애트리뷰트가 없고 연결 정보만 가지게 된다.

다음으로는 설계 원칙에 대해서 살펴보겠다.

충실성(faithfulness)
-설계는 다루고자 하는 실제 상황을 충실하게 나타내야한다.

* M : N 관계가 되야 한다.
통장과 계좌주가 다 대 다 관계가 될 수 있다.


중복(redundancy) 회피
- 하나가 사실을 나타내기 위해 하나의 정보만을 유지하는 것이 좋다.

빠르게 찾기 위해서 가까운 엔티티 셋에 다른 엔티티 셋의 정보를 넣어두면 빠르게 찾을 수

있기는 하나, 1 대 다 관계의 경우  M쪽의 경우에 1쪽의 정보가 M쪽에 다 생겨버리니까,

공간 낭비가 생길 수 있다. 그리고 업데이트라도 한다면 1쪽의 엔티티셋은 하나의 애트리뷰

트만 업데이트 하면 되지만 M쪽의 엔티티 셋은 모든 애트리뷰트를 업데이트 해야한다.

그리고 업데이트 해야할 항목이 많아서 실수(사람이 하다가 code 오류라도 내면..)라도 내면

불일치 가능성 떄문에 해선 안된다.

중복 회피으 경우 공간 낭비 뿐 아니라 그 불일치 하나로 인해서 데이터 베이스 전체에 문

제가 생길 수 있기 때문에 사전에 방지해야한다..

단순화(Simplicity)
-필요 이상의 요소는 설계에 넣지 않는다.
최대한 단순하게 DB를 설계 해야한다. 필요 이상의 요소는 추가하지 않는다.

올바른 요소의 선택
- 실세계의 개념을 나타내기 위한 애트리뷰트와 엔티티 집합 사이의 선택.
ex) 스튜디오 엔티티 집합 대신, 스튜디오의 이름과 주소를 영화 앤티티 집합의 애트리 뷰트로 만들자.

주소 항목이 중복이 된다. 공간의 낭비가 생긴다.

Data inconsistency 문제가 생겨난다. 스튜디오가 이사를 가게 되면 일일히 주소의 애트리

뷰트의 많은 내용을 전부 업데이트 해야한다.

*어떤 스튜디오가 소유하는 영화가 하나도 없다면, 그 스튜디오의 주소는 저장할 수 없다.(Information loss)

-> 이름뿐만 아니라 좀 더 많은 정보를 필요로 한다면 엔티티 집합이나 클래스를 사용하는 것이 바람직하다. 그러나, 단지 이름만 필요하다면 애트리뷰트로 만드는 것도 좋은 방법이다.

설계시에 앤티티 셋을 설정 때에 Many to 1 관계를 가지는 엔티티 셋을 절대 합쳐서는 안된다. 합쳐버릴 경우에는 정보의 손실 위험이 생긴다.

연결 엔티티 집합의 효용성.
효용성을 위해서 엔티티 셋의 가변성이 필요하다. 같은 엔티티 셋에도 상당하게 부류가 나뉠수도 있으니까, 그것들을 효용할 수 있게끔 한다.

ex) 영화, 스타 그리고 하나 이상의 스튜디오로 구성된 Contract 관계성 집합이 있을 때, 영화 제작사, 음향 담당 영화사 등 스타 계약사, 특수 효과 제작사 등의 제작사가 엄청 많을 경우 어떻게 해야할까?

Connecting 엔티티 셋을 이용해서 해결할 수 있다.

Contract의 연결 엔티티 셋을 이용해서 고유값을 가지고 Stars와 movies에 접근이 가능하고 그것으로 스튜디오들로 접근이 가능하다.

이번 글은 여기까지이다. 이 뒤에 모델링의 제약에 관해 더 글을 남길 것이다.

다음 글에 더 이어서 글을 남기도록 하겠다.

여기서 작성된 모든 정리 내용들은 '데이터베이스 시스템 개론'이라는 아주 유명한 책의

내용을 토대로 정리된 내용들임을 미리 알려드립니다.

데이터베이스 시스템 개론 책을 보면서 공부하는 것도 추천드립니다.

데이터베이스 시스템 개론에 더 자세한 내용이 더 구체적으로 설명되어 있습니다.