노찬형의 제로에서 시작하는 데이터 모델링 시즌II (3회)

엔터티 계층과 릴레이션십 구성

필자: 노찬형 빅터플랫폼 CIO. 대학에서 소프트웨어공학을 전공했으며 개발자로 사회 생활을 시작했다. 사회 생활 10년을 넘기고 시작했던 DB 공부가 프로그래머로서 자신을 분명하게 되돌아볼 수 있는 기회를 주었다. 사회 초년생 또는 대학생에게 도움이 되는 데이터 모델링 글을 쓰고 싶은 게 그의 작은 바람이다. pemaker@gmail.com

?

주경야독하는 이들을 위해 우연한 일이 계기가 돼 필자는 DB와 데이터 모델링을 글로 정리할 수밖에 없는 상황에 맞닥뜨렸다. 필자는 2012년부터 2013년까지 한 대학에서 DB 강의를 했다. 강의를 요청받았을 때, 어떻게 해야 할지 난감했다. 필자가 맡은 반은 낮에는 일하고 저녁에 공부하는 학생들로 구성돼 있었다. 일반 대학생들처럼 많은 시간을 공부에 쓸 수 없는 학생들에 DB를 알려줘야 했다. 어떻게 하면 그들에게 작으나마 도움이 될까 하고 고민하던중 시중 교재 대신, 필자가 직접 강의 자료를 만들어 보면 좋겠다는 생각을 하기에 이르렀다. 물론 시중의 책이 부족해서 그런 것은 아니다. 필자가 자료를 직접 만들어 쓰면, 일반 책으로 했을 때보다 더 쉽게 소개할 수 있을 것 같아서 그랬다. 누가 보더라도 이해하기 쉽게 전달하겠다는 목표로 강의 자료를 만들기 시작했다. 2년 넘게 강의 자료를 준비하다 보니, DB의 기초와 데이터 모델링의 기초에 대한 내용을 어느 정도 만들어 낼 수 있었다. 학생들이 강의자료를 요청하면 줬다. 하지만 설명이 없는 프레젠테이션 문서라서 아쉬웠다. 설명이 추가되면 학생들이 예습/복습을 할 때도 훨씬 좋을 텐데…. 배웠거나 배울 학생들을 위해 프레젠테이션 문서를 글로 정리하기 시작했다. 말보다 글로 정리하는 게 더 어렵다는 걸 실감하는 순간의 연속이었다. ‘하늘 아래 새로운 건 없다’는 말처럼 필자의 강의 자료 역시 인식하든 못하든 수많은 자료와 가르침을 받았던 결과물들이다. 물론 보고 들었던 이론을 개발 현장에서 적용?확인하는 과정을 거친, 경험의 산물이다. 앞으로 몇 회에 걸쳐 ‘제로에서 시작하는 데이터 모델링’ 연재를 하겠다고 용기를 내보았다. 독자 여러분과 함께 쓴다는 생각으로 수많은 의견이나 접근 방법을 댓글 또는 이메일로 받을 수 있었으면 좋겠다.

?

지난 1~2회에 이어 이번 회에도 릴레이션십에 대해 알아본다.

?

? 엔터티 계층

1) 엔터티 계층

엔터티를 도출하고 릴레이션을 설정하면 상속을 통해 전체적으로 자연스럽게 계층화가 이뤄진다. 부모로부터 자식으로 상속되고 그 자식으로부터 자식에게 상속돼 현실 세계의 가족 구조와 비슷하게 된다.

다음의 예를 같이 보자.


[그림 1] 계층이 없는 모델[그림 1] 모델을 보면 모든 엔터티가 ‘회원’ 엔터티와 직접 관계를 맺고 있다. 즉 최상위 엔터티가 모든 엔터티와 직접 관계인데 이는 엔터티 직접 관계도출에 실패했다고 볼 수 있다. [그림 1] 계층이 없는 모델을 독자 나름대로 좋은 모델로 바꿔 보는 연습도 필요하지 싶다.

다음 [그림 2]는 비교적 잘 도출한 모델이다. 그림이 작아서 자세한 내용을 볼 수 없겠지만, 모델의 전체적인 모습을 보고 그 모양을 느껴보기 바란다.


[그림 2] 계층이 있는 모델엔터티 간 상속 관계를 통해 계층이 발생하는 것은 지극히 정상적이다. 실제로 상위 엔터티와 직접 연결되는 엔터티는 그리 많지 않다. 따라서 [그림 1]과 같이 모든 엔터티가 최상위 엔터티와 직접 관계를 맺고 있는 모델이 나온다면, 모델이 잘 설계됐는지 다시 고민해 볼 필요가 있다.

2) 관계와 SQL

엔터티 간 관계를 통해 자연스럽게 엔터티의 계층화가 이뤄지면, 차상위의 엔터티 정보 찾기가 어렵다고 생각하는 경우가 있다. 그런데 아버지 엔터티가 할아버지 엔터티의 식별자를 물려주었다면, 할아버지의 정보를 직접 찾을 수 있으므로 SQL이 복합하지 않을 수 있다. 즉 관계는 반드시 지나가야 하는 경로(path)가 아니다.


[그림 3] 엔터티의 계층과 SQL Join[그림 3]은 ‘시험-시험접수내역-시험접수별선택과목’으로 식별관계로 설정돼 있다. ‘시험접수별선택과목’ 엔터티는 시험과 시험접수내역의 식별자를 자신의 속성으로 다 갖고 있다.

관계는 시험-시험접수내역-시험접수별선택과목 순이지만, SQL을 작성할 때는 시험과 시험접수별선택과목을 직접 조인해 사용할 수 있다. 과목코드 ‘10’인 고객목록을 조회하는 SQL은 다음과 같이 간단하게 작성할 수 있다.

?

? 릴레이션십의 구성

릴레이션십은 name, cardinality, optionality(selectivity)라는 3가지 요소를 이용해 표현된다.

1) Name

릴레이션십이 설정되면 해당 릴레이션십의 이름, 즉 관계명을 기술하는 것이 좋다. 해당 릴레이션을 단순히 관계선만 보고 추정 가능한 때도 있지만, 그렇지 않은 경우도 있다. 따라서 본인을 위해서나 추후 모델을 관리하고 참조해야 하는 담당자를 위해서도 기술하는 것이 좋다.

기억력을 자만해서는 안된다. 다들 알겠지만 순간의 기억이 장기 기억으로 가기 위해서는 많은 노력과 반복이 필요하다. 그러므로 자신의 머리와 기억력을 믿지 말고 가능하면 기록을 습관화해야 한다.

관계에 명칭을 정의하는 것은 엔터티와 마찬가지로 해당 릴레이션이 어떤 집합인지를 보여준다.


[그림 4] 관계 명칭[그림 4] 모델의 ‘부서’와 ‘사원’ 관계에 대해 알아보자. 사원 엔터티는 부서 엔터티로부터 비식별관계로 설정됐다. 그렇다면 사원에 포함된 부서는 어떤 부서일까? 사원이 소속된 소속부서일까? 사원을 관리하는 관리부서일까? 아니면 사원이 희망하는 근무부서일까? 릴레이션만 보고는 알 수가 없다. 관계명이 없으면 일반적으로 사람들은 소속부서일 것이라고 추정하는 오류를 범하게 된다. 이런 오류를 줄이고 명확히 하기 위해 관계명이 필요하다.

관계명은 바라보는 관점에 따라 달라진다. 예를 들어 부부에서 남자는 여자의 남편이 되고, 반대일 경우는 아내가 되듯>


[그림 5] 관계명 관점부모 또는 상위가 하위를 바라볼 때는 Include, 자식 또는 하위가 바라볼 때는 belong to 관점으로 정의하나, 실제 업무에서는 중간 입장의 관계 명칭을 사용하는 것이 일반적이다.


[그림 6] 관계 명칭관계 명칭을 써야 하는 또 하나의 이유는 엔터티 사이에 렐레이션이 하나 이상일 수 있기 때문이다. 데이터 모델링에 대해 배우기 시작하는 사람들이 엔터티 사이의 관계는 하나라고 생각하는 경우가 있다. [그림 6]에서 보는 바와 같이 부서 엔터티와 사원 엔터티 사이에는 3개의 릴레이션(관계선)이 존재한다. 그것도 무려 양방향으로 말이다. 이렇게 여러 개의 릴레이션이 있을 때 관계 명칭이 없으면, 그 릴레이션이 어떤 의미인지를 알 수 없으므로 관계 명칭은 가능하면 꼭 써줘야 한다.

관계명칭을 써야 하는 경우는 롤(Role) 이름이 필요할 때, 순환 관계일 때, 추출 관계일 때, 양방향 관계일 때, 다대다 관계일 때다. 반면에 부모(상위) 엔터티에 일대다(1:M)로 종속되는 관계는 관계명을 굳이 쓰지 않아도 되나, 처음에는 쓰는 것을 습관화하면 좋다.

다음 회에는 릴레이션십 구성에 대해 살펴보겠다. (다음 회에 계속)

?

출처 : 한국데이터산업진흥원

제공 : 데이터 전문가 지식포털 데이터온에어(dataonair.or.kr)