3. 2장 데이터베이스 설계 (database design) (3) - Conceptual Database Design

ER 모델을 이용해 개념적 설계를 할 때 고려하면 좋을 부분에 대해 설명한다.

 

Entity vs Attribute

특정 정보를 속성으로 정의할지, 엔티티로 정의할 지 결정할 필요가 있다.

 

예를 들어,, 직원의 주소를 생각해보자.

직원의 주소에는 시, 군, 구, 동, 번지, 상세주소 등등으로 나눌 수 있다.

    당장 나만해도 "서울특별시 서초구 어쩌구동 이러쿵아파트 3단지 302동 101호" 와 같은 형태로 이루어져있다.

1. 그냥 attribute로 정의하기

    "직원" entity의 속성으로 주소 라는 속성이 추가된다.

    이 경우 그냥 string으로 저장할 수 있다...

2. entity로 정의하기

    주소를 조각조각 내서 저장하고 싶다면, "주소" entity를 정의해서 넣어주는게 좋을 수 있다!

    => 예를들어.. 여러개의 주소를 저장할 수 있는경우 (배민의 경우 집, 학교, 직장 등등,, 여러 주소를 저장한다)

          아니면 시, 군, 구, 동, 번지, 상세주소를 따로따로 저장하고 싶은경우

    이렇게 되면, "직원"과 "주소" entity는 "Has_Address"라는 관계로 연결될 수 있다!

 

또 다른 예로,, 직원의 기간별 근무정보를 저장하는 경우를 생각해보자.

직원이 특정 부서에서 일하는 기간은, Work 관계의 속성으로 저장할 수 있었다 (이전에 작성한 글 참고)

-> 근데,,, 직원이 휴직 복직 휴직 복직을 왔다갔다 해서 기간 정보가 여러번 저장 될 필요가 있다면 어떨까?

    예를들어,, 직원A가 2018~2020 사이에 일했고, 육아휴직으로 2년 쉬고 복직해 2022~2024 기간동안 일했다고 하면

                      기존의 Work 관계로는 표현할 방법이 없다! (기간을 한번만 저장할 수 있으니까)

=> 기간을 Duration이라는 별도의 entity로 정의해, 여러 기간을 저장할 수 있도록 해주자!

 

 

Entity vs Relationship

어떤 정보를 엔티티로 표현할지, 관계로 표현할지 정한다.

-> 엔티티로 표현하는경우, 정보를 더 세밀하게 다룰 수 있지만, 설계가 복잡해질 수 있다.

 

manage 관계를 생각해보자... (직원과 부서 사이의 관계)

-> 특정 직원(관리자)이 어떤 부서를 관리하기 위한 예산을 할당해준다고 생각하면,,,

=> manage 관계에 "예산" 속성을 넣을 수 있다.

근데,, 만약 관리자가 모든 부서에 "동일한" 예산을 할당하면 어떻게 될까?

    A라는 관리자가 있는 모든 manage 관계의 "예산" column은 같은값이 되고,

    B라는 관리자가 있는 모든 manage 관계의 "예산" column도 같은값이 된다.

    즉 불필요한 데이터 중복이 생기게된다.

=> 이런경우 manager라는 별도의 엔티티를 만들어 관리하는것이 더 효율적일 수 있다.

 

Binary vs Ternary Relationships

이진관계와 삼항관계 중 어떤 것을 사용할지도 잘 생각해야 한다!

삼항관계를 쪼개서 이항으로 표현해주는것이 더 좋을때가 있다.

 

회사의 보험정책을 생각해보자,,, 아래와 같은 조건이 추가됐다고 생각했을 때

- 하나의 보험정책에는, 하나의 직원만 할당됨 (두 명 이상이 공동으로 소유할 수 없음)

- 모든 보험 정책은 반드시 어떤 직원이 소유해야함

- 부양가족은 weak entity set임 (이전 블로그글 참고)

=> 이 3개의 관계를 3항관계로 표현해줄 수 있다

첫번째 조건을 만족하기 위해, 복지정책에 key constrain을 걸어준다!

근데 이러면,,, 복지정책이 "한명의 부양가족만 커버할 수 있다"는 의미까지 포함해버린다!

=> 이렇게 되면 2항으로 변경해줄 필요가 있다!

이러면, 문제가 해결된다!

 

반대로, 이진보다 삼항관계를 쓰는게 더 좋을때도 있다.

부품 (Parts), 공급자(Suppliers), 부서(Departments) 라는 엔티티셋 사이의 계약(Contracts)이라는 관계를 생각해보자.

    계약 : 특정 부서에 특정 부품을 공급자에게서 받겠다는 관계, 수량 (qty)라는 속성이 관계에 필요하다.

이걸 이진관계로 생각하면 어떨까?

부서는 특정 부품을 "원한다" & 공급자는 특정 부품을 "제공한다" & 부서가 공급자에게 "요청한다"

   -> 이렇게 세개의 관계로 쪼개볼 수 있다.

   하지만 문제는...

    - 부서가 부품을 원한다고 해도, 공급자로부터 부품을 반드시 구매한다는건 아니다 (연결이 안됨)

    - 계약 관계의 수량을 표현할 방법이 없음

=> 그래서 이런경우는 삼항관계가 더 좋다!

 

Aggregation vs Ternary Relationships

집합으로 표현할지, 삼항관계로 표현할지도 잘 선택해야 한다.

설명은... 앞 블로그글 맨 마지막 내용 참고,,

 

아무튼 삼항관계보다 집합으로 표현해주는게 더 간단하게 표현이 가능하다는 말이다.

(어떤 관계 전체를 하나의 엔티티마냥 취급할 수 있어서)

 

ERD

위에서 ER modeling은 동그라미, 마름모 등등으로 표현했었다.

이걸 좀 더 테이블 형태로..? 그린게 ERD이다!

아무튼 담고있는 내용은 똑같다.

이런 느낌..!