데이터 인사이트

데이터 전문가 칼럼
데이터 전문가가 전하는 데이터 노하우

노찬형의 제로에서 시작하는 데이터 모델링 시즌II (6회) : 릴레이션십 응용으로 프로그램의 유연성 확보

작성자
관리자
작성일
2020-08-28 18:20
조회
1401

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


릴레이션십 응용으로 프로그램의 유연성 확보

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

주경야독하는 이들을 위해

우연한 일이 계기가 돼 필자는 DB와 데이터 모델링을 글로 정리할 수밖에 없는 상황에 맞닥뜨렸다. 필자는 2012년부터 2013년까지 한 대학에서 DB 강의를 했다. 강의를 요청받았을 때, 어떻게 해야 할지 난감했다. 필자가 맡은 반은 낮에는 일하고 저녁에 공부하는 학생들로 구성돼 있었다. 일반 대학생들처럼 많은 시간을 공부에 쓸 수 없는 학생들에 DB를 알려줘야 했다. 어떻게 하면 그들에게 작으나마 도움이 될까 하고 고민하던중 시중 교재 대신, 필자가 직접 강의 자료를 만들어 보면 좋겠다는 생각을 하기에 이르렀다.

물론 시중의 책이 부족해서 그런 것은 아니다. 필자가 자료를 직접 만들어 쓰면, 일반 책으로 했을 때보다 더 쉽게 소개할 수 있을 것 같아서 그랬다. 누가 보더라도 이해하기 쉽게 전달하겠다는 목표로 강의 자료를 만들기 시작했다. 2년 넘게 강의 자료를 준비하다 보니, DB의 기초와 데이터 모델링의 기초에 대한 내용을 어느 정도 만들어 낼 수 있었다.

학생들이 강의자료를 요청하면 줬다. 하지만 설명이 없는 프레젠테이션 문서라서 아쉬웠다. 설명이 추가되면 학생들이 예습/복습을 할 때도 훨씬 좋을 텐데…. 배웠거나 배울 학생들을 위해 프레젠테이션 문서를 글로 정리하기 시작했다. 말보다 글로 정리하는 게 더 어렵다는 걸 실감하는 순간의 연속이었다.

‘하늘 아래 새로운 건 없다’는 말처럼 필자의 강의 자료 역시 인식하든 못하든 수많은 자료와 가르침을 받았던 결과물들이다. 물론 보고 들었던 이론을 개발 현장에서 적용?확인하는 과정을 거친, 경험의 산물이다. 앞으로 몇 회에 걸쳐 ‘제로에서 시작하는 데이터 모델링’ 연재를 하겠다고 용기를 내보았다. 독자 여러분과 함께 쓴다는 생각으로 수많은 의견이나 접근 방법을 댓글 또는 이메일로 받을 수 있었으면 좋겠다.
지난 연재에서 M:M 논리모델을 물리모델에 적용하기 위해 1:M 모델로 바꾸는 방법을 알아보았다. 이번 연재에서는 릴레이션십 응용에 대해 알아본다.

?

?

? 자기참조관계

자기참조관계(self referencing)는 순환(recursive) 관계라고도 한다. 자기참조관계는 하나의 엔티티타입 내에서 엔티티와 엔티티가 관계를 맺고 있는 형태다. 즉 하나의 엔터티가 자기 자신과 관계를 맺는 것이다. 부서, 부품, 메뉴 등과 같이 계층 구조 형태를 표현할 때 유용한 관계 형식이기도 하다.


[그림 1] 학부모와 학생
학부모와 학생의 예로써 자기참조관계를 알아보자. 학생의 학부모는 1건만 있다고 가정해 보면, [그림 1]과 같이 모델링할 수 있다. 이 모델은 당장은 문제가 없다. 하지만 학생이 자라서 학부모가 됐을 상황을 수용할 수 없는 모델이다. 이 문제는 어떻게 해결할 수 있을까?


[그림 2] 학부모, 학생, 학생_1
[그림 2]와 같이 학생 밑에 새로운 엔터티를 추가하면 된다. 하지만 이 모델 또한 학생_1이 커서 학부모가 되면 그 상황을 수용할 수 없다. 또 다시 하위에 엔터티를 추가해야 할까?

좋은 모델이란 엔터티의 변경 없이 또는 최소 변경으로 변화에 대응할 수 있어야 하는데 위와 같이 엔터티와 관계를 계속 추가하는 것은 좋은 모델이라고 할 수 없다. 이럴 때 적용할 만한 방법이 자기참조관계 활용이다. 자기참조관계를 활용하면 학부모와 학생은 다음 [그림 3]과 같은 모델이 된다.


[그림 3] 자기참조관계
학부모와 학생은 모두 사람이므로 학부모 엔터티와 학생 엔터티를 통합한다. 이어서 자기참조관계선을 추가해 학생의 학부모가 누구인지만 관리하면 된다. 자기참조관계는 앞서 제시했듯이 트리구조, 조직, 분류 등의 데이터를 관리할 때나 자기참조를 위해 사용할 수 있다. 이때 주의할 점은 필수적인 관계로 만들면 최상위 부모 개체가 만들어 질 수 없기 때문에 널(null)값을 허용한 관계선을 설정해야 한다. 그리고 SQL 구현 시에는 connect by 절을 사용한다.

?

?

? 제품의 부품 항목(BOM) 모델은 어떻게 해야 할까?

BOM(Bill Of Material)은 특정 제품이 어떤 부품으로 구성되는지를 표나 그림으로 표현한 것이다. 여기서 제품과 부품은 같을 수도 있고, 부품의 조합이 제품일 수도 있다. 즉 BOM은 제품과 부품 간 관계(relationship)를 정의하는 것이다.

대부분의 제품은 모두 여러 부품의 조합결과라고 볼 수 있다. 예를 들어 노트북, 청소기, 키보드, 마우스, TV, 시계 등은 모두 여러 부품을 조립해 만든다. 전자제품보다 더 친숙한 요리와 식재료를 갖고 좀 더 자세히 알아보자.


[그림 4] 요리와 식재료 모델
하나의 요리는 여러 식재료를 필요로 하고, 한 식재료는 여러 가지 요리에 사용될 수 있다. 따라서 M:M 관계가 되었고, 이 관계를 릴레이션(교차) 엔터티로 풀어냈다.

식재료 중 일부는 또 다른 식재료와 조합해 하나의 요리가 된다고 하자. 만두처럼 식재료 중 일부는 요리이고, 요리 중 일부는 다시 떡만두국 같은 다른 요리의 식재료가 될 수 있다. 이는 식재료와 요리는 근본적으로 같다는 말이므로 요리 엔터티와 식재료 엔터티의 통합을 생각해볼 수 있다. 요리 엔터티와 식재료 엔터티를 통합하면 [그림 4]와 같이 모델링할 수 있다.


[그림 5] BOM 모델
BOM 모델은 ‘부품_통합’ 엔터티에 전체 데이터, 즉 요리와 식재료 데이터를 한꺼번에 관리하면서 요리에 들어가는 식재료가 무엇인지를 ‘조립재료’ 엔터티에서 관리하는 형태다.


[그림 6] 요리 BOM 모델
엔터티명이나 속성명이 적합하지 않지만, 요리와 식재료를 BOM 모델로 표현하면 [그림 6]과 같다. [그림 7]은 요리 모델의 데이터를 표현한 것이다.


[그림 7] 요리 BOM 모델의 데이터
?

BOM 모델은 하위에 아무리 많은 부품이 있더라도 모델 변경 없이 수용할 수 있다. 자기참조관계는 하나의 부모만 지원하지만, BOM은 여러 개의 부모를 가질 수 있어서 주로 제조?생산 부문에서 사용된다. 하지만 SQL 난이도가 그만큼 올라간다(connect by).

? 일반화와 특수화

엔터티의 일반화와 특수화에 대해 알아보자. 일반화를 하면 유연성이 올라가고 특수화를 하면 비즈니스 룰을 정확하게 표현하고 강제할 수 있다고 했다. 일반화와 특수화 중 어느 것이 좋은지는 비즈니스 요건에 따라서 정의돼야 한다.

하지만 현재의 특수성을 고려할 것인지 향후 확장성을 고려할 것인지는 모델러의 역량에 따라서 결정되기도 한다. 필자는 주로 확정성과 유연성을 위해 일반화를 하는 편이다. 어떤 것이 더 좋고 나쁘다를 논하기보다는 어떤 것이 더 유리한지에 집중할 필요가 있다.

1) 다중릴레이션십

IT 프로젝트를 관리하는 모델을 갖고 이야기해보자. 원래는 문제를 내고 직접해보고 서로가 한 것을 보면서 부족한 부분을 채우는 방법이 좋으나 지면상 그것은 불가능하니 계속 이야기를 진행하겠다. 그렇더라도 가능하면 이쯤에서 잠시 멈추고 IT 프로젝트를 관리하는 모델을 직접 한번 해보길 바란다. IT 프로젝트를 관리하는 모델의 조건은 다음과 같다.

① 우리가 관리하는 프로젝트에는 PM, 사업관리, 모델러, 품질관리, DBA가 배정된다.
② 필요한 인력은 정직원?외부직원?인턴사원 중에서 배정할 수 있다.

위 조건을 살펴보면, 엔터티로 나올 수 있는 것이 일단 프로젝트, 사원 정도가 될 것 같다. 사원에는 정직원·외부직원·인턴사원이 서브타입으로 구분될 수 있을 것이다. 이를 토대로 모델링을 해보면 [그림 8]과 같이 된다.


[그림 8] 프로젝트 관리 모델 1
[그림 8]에서 보는 바와 같이 두 개의 엔터티 간의 관계는 하나 이상일 수 있다. 프로젝트 계획에 따라서 필요한 인력은 각각 릴레이션을 가질 수 있으며, 관계의 방향이 서로 다른 릴레이션십이 공존할 수도 있다.

위 모델은 비즈니스 요건을 만족하기 때문에 별다른 문제는 없어 보인다. 그런데 필요한 인력의 종류가 늘어나면 릴레이션을 추가해 줘야 한다. 릴레이션을 추가한다는 것은 단순히 렐레이션만 설정하는 끝날 일이 아니다. 프로젝트 엔터티에 속성이 추가되는 것이며 이는 곧 물리적으로 테이블 변경이 필요한 일이다. 결국 이와 관련된 프로그램도 변경돼야 한다. 매번 늘어날 때마다 이런 식으로 관리하는 것은 물론 문제가 있다. 이런 모델이 바로 좋지 않은 모델이다.

이런 경우는 다음과 같이 여러 개의 릴레이션을 하나로 통합해 엔터티화하면 논리모델이나 물리 테이블의 변경없이 확장성을 확보할 수 있다.


[그림 9] 프로젝트 관리 모델 2
[그림 9] 모델의 1:M 릴레이션십은 통합할 수 있고, 양방향(M:M)의 릴레이션십이 되기 때문에 릴레이션(교차) 엔터티를 도출한 모델이다. 이 모델은 프로젝트에 배치되는 사원의 역할이 늘어나도 모델변경 없이 ‘사원역할’만 추가하면 된다. 또한 식별자를 조정해 이력으로 관리하거나 역할별 참여 수를 제한할 수도 있다.

2) 릴레이션십의 일반화

렐레이션십의 통합과 일반화는 엔터티와 마찬가지로 통합을 통해 일반화가 가능하며, 일반화가 될수록 더 유연하다. 경우에 따라서 구현이 어려운 경우도 존재한다. 릴레이션십이 확장될 가능성이 없다면 불리할 수 있으므로 잘 판단해야 한다. 즉 프로젝트에 투입되는 인력의 역할의 종류가 고정이라면 [그림 8]과 같은 모델이라도 문제가 없다. 하지만 조금이라고 확장될 가능성이 있다면 [그림 9]가 더 나은 나은 모델이라고 할 수 있다.

이로써 릴레이션에 대한 소개를 마치고 다음 회부터는 속성에 대해 소개한다. (다음 회에 계속)

?

?

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

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