[데이터베이스] 6. 개념적 데이터베이스 설계

ERD를 사용하여 개념적 데이터베이스 설계를 시작해보자.

요구사항을 기반으로 개념적 데이터베이스를 설계하다보면 다양한 선택지를 놓고 고민하게 된다.

 

어떤 개념을 엔티티로 모델링할지, 속성으로 모델링할지 고민할 수 있고,

엔티티와 관계 중 어떤 형태로 모델링할지 고민할 수도 있고,

관계들을 구분하는데 있어서 이진 관계, 삼진 관계, 집단화 중 어떤 것을 사용할 지 고민할 수도 있다.

 

또한 ER 모델을 설계할 때는 데이터에 담긴 여러가지 의미(비즈니스 로직 등)를 함께 나타내도록 설계해야 하므로 다양한 제약조건을 걸게 되는데, 내가 어떤 형태로 ERD를 그리냐에 따라 비즈니스 로직에 맞는 제약조건을 걸 수 없게 되기도 한다.

 

이제 다양한 예시 상황을 보면서 어떤 개념적 데이터베이스 설계를 취할지 고민해보자.

 

 

Entity  vs. Attributes

만약 어떤 직원의 주소를 저장해야 한다고 해보자.

이때 이 직원의 주소를 그냥 하나의 address 속성으로서 문자열로 저장할 수도 있고,

주소를 구조화해서 도, 시, 구, 읍면동과 같은 세부 필드를 갖는 엔티티로 주소를 저장한 뒤 직원과 별도의 관계를 맺도록 설정할 수도 있다.

 

만약 후자로 설계한다면 우리가 특정 주소에 살고 있는 모든 직원 정보를 얻고 싶을 때 특정 도/시/군/읍면동 필드를 조건으로 걸어서 원하는 주소 단위에 있는 모든 직원을 편하게 조회할 수 있다.

 

하지만 전자로 설계한다면 직접 문자열을 파싱해야 할 뿐만 아니라, 각각의 직원이 누구는 '서울특별시' 누구는 '서울시' 누구는 '서울' 과 같이 통일되지 않은 형식으로 데이터를 저장할 수 있으므로 데이터를 식별하는데 높은 비용이 들게 된다.

 

또는 한 명의 직원이 여러 개의 주소를 갖는 경우에도 속성 대신 엔티티로 분리해야 할 이유가 생긴다.

따라서 이 선택지는 내가 설계하려는 서비스의 비즈니스 모델과 요구사항에 맞게 선택하면 된다.

 

 

 

또는 위와 같은 형태의 설계를 살펴보자.

 

지금 이 그림은 직원이 한 부서에서 일하는 관계를 나타낸다.

이때 Works_In4 관계는 이 직원이 언제부터 언제까지 일했는지 일한 기간도 속성으로 갖고 있다.

 

지금은 이 관계 집합에서 하나의 관계를 식별할 때 (ssn, did) 셋으로 식별하고 있다.

그런데 만약 어떤 직원이 2021년부터 2022년까지 근무했다가, 2023년에 돌아와서 2024년까지 근무했다고 해보자.

그러면 이 Works_In4 릴레이션에는 (ssn, did , 2021, 2022), (ssn, did, 2023, 2024) 라는 데이터가 들어있을 것이다.

현재 works_in4 릴레이션은 pk 로 (ssn, did) 쌍을 사용하고 있으므로, 위와 같이 저장하면 유일한 레코드를 식별할 수 없다.

 

그러면 결국 기존 데이터를 덮어쓰는 식으로 밖에 저장할 수 없는데, 이렇게 저장하면 '근무 내역' 으로서 저장하려고 하는 기존의 의도가 훼손될 수 있다.

 

 

따라서 위와 같이 (from, to) 라는 어트리뷰트를 Duration 이라는 별도 엔티티로 빼내고, 두 값의 조합을 PK로 하도록 저장하면 문제를 해결할 수 있다.

(그런데 그냥 Works_In4 안에서 4개 어트리뷰트를 PK로 저장할 수도 있지 않을까? 어차피 Duration 과의 관계를 Works_In 에 저장하려면 (from, to) 가 필요한데..)

 

 

 

Entity  vs  Relationship

 

위 그림과 같은 ERD를 살펴보자.

지금 부서 자체에 예산(budget)이 있고, 직원 중 1명이 어느 시점부터 부서를 dbudget을 가지고 관리하고 있다.

이때 이 dbudget 은 관리자(employee)가 부서를 관리함에 있어서 쓸 수 있는 예산을 의미한다.

 

 

이 그림은 매니저가 여러개의 부서를 관리할 수 있을 때 매니저라는 직원 한명이 총 쓸 수 있는 예산으로 dbudget을 갖고 있음을 알 수 있다.

이때 매니저 엔티티를 서브클래스로 분리한 이유는 모든 직원이 매니저일 수 없기 때문에, dbudget 필드를 공통적으로 가지지 않게끔 분리한 것이다.

 

 

이 두 ERD는 어떤 요구사항인지에 따라 다르다.

이해를 위해 나는 아래와 같이 그리는 것이 조금 더 좋다고 생각한다.

 

 

 

한 명의 매니저가 여러 부서를 관리할 때,

위 다이어그램은 자신이 관리하는 각 부서마다 별도의 관리 예산을 갖고 있는 상태를 나타낸다.

아래 다이어그램은 매니저에게 총 관리비가 할당되고, 매니저는 이 관리비를 자신이 관리하는 여러부서에 자유롭게 나눠서 사용할 수 있다.

 

만약 매니저에게 총 관리비가 할당되고, 자유롭게 자신이 관리하는 부서에 나누어 사용하는 경우, 

아래처럼 그리면 dbudget을 중복적으로 저장하지 않아도 괜찮고,

마치 dbudget이 기존 첫 번째처럼 이 예산이 이 부서를 관리하는데 모두 쓰이는 것 같은 오해를 불러일으키지 않으므로

두번째 다이어그램처럼 그리는 것이 옳다.

 

 

이진 관계  vs   삼진 관계

직원이 있고, 직원은 다양한 보험에 가입할 수 있다. 이때 각각의 보험은 직원의 부양가족들에게 혜택을 주는 보험이다.

예를 들면 화재 보험에는 부모님 두 분에 대해 보장하도록 가입하고, 학자금 보험은 자신의 아들에 대해 보장하다록 가입하는 것과 같다.

각 부양가족들은 모두 약개체라고 할 때 ERD를 그려보자.

 

 

먼저 이렇게 삼진관계를 통해 나타낸 그림은 좋은 디자인이 아니다.

만약 각각의 Policy 객체는 Empoyee 와의 관계에 1번만 참여한다고 해보자.

 

즉, Empolyee : Policy = 1 : N 관계라고 해보자.

그러면 위 그림과 같은 삼진관계에서는 Policy에 화살표를 그을 수가 없다.

왜냐하면 화살표를 긋는 순간, (employee, dependents, policy) 관계에 대해서 policy 가 한번만 참여한다는 뜻이 되므로,

한명의 직원이 하나의 보험 상품을 가입했는데, 이 보험 상품이 여러 명의 부양가족에 대해 보장한다는 것을 나타낼 수 없게 된다.

(교수님 말씀으로는 화살표가 employees 에 걸리는지, dependents 에 걸리는 지 알 수 없다고도 표현하셨다.)

 

 

또 다른 문제로는 dependents 는 약개체이므로 다른 엔티티에 의해 식별이 되어야 한다.

그런데 지금 이 그림과 같은 상황에서는 dependents 가 (employees, policies) 쌍에 의해 식별이 되는데,

문제 상황에서 dependents 는 자신을 보장하는 policy 보험에 의해 식별이 되어야 한다면 이를 나타낼 수도 없다.

 

 

 

따라서 이렇게 2개의 이진 관계로 분리해서 나타내면 문제를 해결할 수 있다.

Policy - Employees 에 대한 키 제약조건도 표시할 수 있고, 약개체도 올바르게 나타낼 수 있게 된다.

 

위와같이 삼진관계로 표현을 하고자 하는 경우에는 세 엔티티에 제약조건이 없고 서로 자유롭게 관계를 맺을 수 있을 때 나타내면 된다.

(삼진관계가 무조건 나쁜 것은 아니다!)

 

---

 

한번 삼진관계로 표현하는 것이 더 좋기도한 예시를 살펴보자.

만약 어떤 기계를 만드는 회사가 있다고 해보자.

회사의 각 부서는 자신이 담당한 부분을 만들기 위해 필요한 부품 파츠가 있다.

이 파츠는 부품을 생산하는 공장과 계약을 맺어서 가져온다고 해보자.

 

이때 특정 부서에서 필요로 하는 특정 파츠의 공급 계약 수량을 저장하고자 할 때 어떻게 저장할 수 있을까?

예를 들면 화성탐사로봇의 바퀴 파츠가 10개 필요해서 특정 바퀴 생산업체와 10개 수량으로 계약을 맺은 것이다.

이 계약에 대한 정보를 만약 이진 관계로 나타내서 저장하려면 아래와 같이 저장하고자 할 것이다.

 

 

이렇게 공급사, 부품, 부서 사이에 이진관계를 3개 구성하고, 각 관계에 qty를 두는 경우에는 당연하지만 '계약 수량' 이라는 의미가 분산되게 된다.

 

먼저 공급사와 부품 사이에는 생산 수량의 의미가 되어버리고

부서와 부품 사이에는 필요 수량의 의미가 되어버린다.

마지막으로 부서와 공급사 사이에는 거래 수량이 되어버리는데, 이 거래 수량이 우리가 의도한 계약 수량이라고 하기에는 이 공급사로부터 몇가지 종류의 부품을 받는지 모르기 때문에 사실상 거래하는 전체 부품의 수량의 의미가 되어버린다.

 

 

 

 

따라서 이렇게 계약을 중심으로 둔 삼진관계를 구성하면 의도에 맞게 문제를 풀 수 있다.

 

 

삼진 관계 vs 집단화

 

삼진관계와 집단화는 제약조건을 걸 때 그 제약 조건이 한쪽에 걸려야 하는지, 양쪽 모두에 걸려야 하는지를 주의하면서 설계하면 된다.

위 그림에서는 프로젝트를 어떤 부서가 후원할 때, 그 부서의 직원이 프로젝트를 감독하는 상황에서 만약 한명의 직원이 감독할 수 있는 프로젝트가 최대 1개라는 키 제약조건을 추가하는 상황을 나타낸 것이다.

 

지금과 같은 상황에서는 직원에게 걸린 키 제약조건이 Project 에 걸리는 것인지, Departments에 걸리는 것인지 모호하기 때문에 aggregation 으로 표현하는 것이 더 좋다.

(만약 직원은 여러 부서에 속할 수 있는데, 최대 하나의 프로젝트만 감독을 할 수 있다면 키 제약조건이 양쪽에 동시에 걸리면서 두 요구사항을 모두 만족할 수 없게 된다.)