데이터 인사이트

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

노찬형의 제로에서 시작하는 데이터 모델링 시즌II (2회) : 데이터 모델링에서 릴레이션십과 상속의 원리

작성자
관리자
작성일
2020-08-28 18:15
조회
50

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


데이터 모델링에서 릴레이션십과 상속의 원리

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

주경야독하는 이들을 위해

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

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

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

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

 

• 릴레이션십과 상속의 원리

릴레이션십을 거론할 때 △부모자식간 관계 △상위하위 관계 △식별/비식별관계 등으로 소개하는 것을 볼 수 있다.

식별일 때는 부모자식간 관계이고, 비식별일 때는 상위하위 관계라고 소개하기도 한다. 필자는 부모자식간 관계보다는 상위하위 관계를 다시 식별/비식별로 구분하는 것이 적절하다고 본다. 하지만 이 글에서는 상위=부모, 하위=자식이라고 가정하고 좀 더 자세히 알아보겠다.

1) (상위)자식(하위) 관계

릴레이션십은 직접 관계인 2개의 엔터티 사이에서 설정하기 때문에 두 엔터티 중에 하나는 부모(상위) 엔터티가 되고 나머지 하나는 자식(하위) 엔터티가 된다. 1:M 관계에서 1쪽이 부모(상위) 엔터티가 되고, M쪽이 자식(하위) 엔터티가 된다. 1:1이나 M:M 관계에서도 어느 한 쪽이 부모(상위) 엔터티가 되고 나머지가 자식(하위) 엔터티가 된다.

2) 렐레이션십 구현

릴레이션십은 부모(상위)로부터 자식(하위)으로 관계선을 연결해 표현한다. 릴레이션십이 형성되지만 자식(하위) 엔터티는 부모(상위) 엔터티에 영향을 미치지 않는다. 하지만 자식(하위) 엔터티는 부모(상위) 엔터티의 식별자를 속성으로 갖게 된다. 자식(하위) 엔터티에 생성된 속성은 Foreign Key가 되며, 이는 참조무결성(reference integrity)을 지원하는 역할을 한다.


[그림 1] 릴레이션십의 예
[그림 1]은 회사와 부서 관계다. 회사 엔터티와 부서 엔터티, 부서 엔터티와 사원 엔터티 릴레이션의 차이는 식별관계냐 비식별관계냐이다.

- 회사 엔터티와 부서 엔터티 관계

회사가 부모(상위), 부서가 자식(하위) 엔터티다. 부서는 회사 엔터티의 식별자인 회사 ID를 상속받아 부서 엔터티의 일반 속성으로 구현됐다. 이와 같이 자식(하위) 엔터티가 부모(상위) 엔터티의 키를 자신의 일반 속성으로 상속받는 것을 비식별관계라고 한다.

- 부서 엔터티와 사원 엔터티 관계

부서가 부모(상위), 사원이 자식(하위) 엔터티다. 사원은 부서 엔터티의 식별자인 부서 ID를 상속받아 사원 엔터티의 식별자 속성으로 구현됐다 이와 같이 자식(하위) 엔터티가 부모(상위) 엔터티의 키를 자신의 식별자 속성으로 상속받는 것을 식별관계라고 한다.

3) 릴레이션십으로 상속이 이루어진다

[그림 2]에는 ‘계좌’와 ‘계좌입출금내역’이라는 2개의 엔터티가 있다. 두 개의 엔터티 가운데 어느 것이 부모(상위)이고, 어느 것이 자식(하위)인지 결정하는 방법을 알아보자.

필자는 어떤 것이 먼저냐, 먼저 생성되는지 또는 되어야 하는지를 따져본다. 자식보다 부모가 먼저 있어야 하듯이, 계좌입출금내역이 있으려면 계좌가 먼저 있어야 하기 때문에 계좌가 부모(상위) 엔터티가 되고, 계좌입출금내역이 자식(하위) 엔터티가 된다.


[그림 2] 릴레이션십에 의한 상속
 

부모(상위) 엔터티와 자식(하위) 엔터티가 정해지면 계좌에서 계좌입출금내역 쪽으로 관계선을 그어주면 릴레이션십이 설정된다. 부모(상위) 엔터티의 식별자인 계좌번호가 자식(하위) 엔터티인 계좌입출금내역의 속성으로 생성된다.

이렇게 되면 자식은 부모(상위) 개체 이름(식별자)을 갖고 있으므로 부모(상위)를 유일하게 식별할 수 있어, 부모(상위)의 모든 속성을 사용할 수 있게 된다. 이것이 엔터티가 식별자를 가져야하는 이유이자 엔터티와 릴레이션십(E-R)의 기본 원리다.

이로써 릴레이션을 설정하는 방법에 대해 알아보았다. 이번에는 식별과 비식별에 대해 알아보자. 이 부분은 설명하기는 쉽지만, 실제 논리 모델링에서 완벽하게 지켜지지는 않는 것 같다. 그 이유는 식별관계인데도 여러 가지 이유에 따라 비식별관계로 변할 때도 있기 때문이다. 그렇더라도 원론에 입각해 식별인지 비식별인지를 구별하고, 릴레이션십을 설정할 수 있어야 한다.

식별/비식별관계 여부는 상속된 속성의 위치에 따라 결정된다. 부모(상위) 식별자 전체가 자식(하위) 식별자에 포함되면 식별관계, 부모(상위)의 식별자 전체가 자식(하위)의 일반속성이 되면 비식별관계가 된다.

 

• 식별/비식별관계

1) 식별관계

상위(부모) 식별자 전체가 하위(자식)의 식별자에 포함되면 식별관계이며, 이를 부모-자식간 관계라고 한다.


[그림 3] 릴레이션십에 의한 상속 및 식별관계
식별관계로 릴레이션 선을 설정하면 위와 같이  모양의 선이 그어진다. 부모 ‘계좌’ 엔터티의 식별자인 계좌번호가 자식 ‘계좌입출금내역’ 엔터티의 식별자로 포함ㆍ생성된다(DA#의 Barker 표기법에서 #은 식별자를 나타낸다).

식별관계의 특징은 부모 엔터티는 자식의 탄생에 직접적인 역할을 해 자식은 부모 없이 생성할 수 없다는 점이다. 따라서 식별관계는 릴레이션십 중 부모-자식 사이가 강하고, 중요한 관계로서 일반적으로 데이터 모델의 골격 역할을 한다.

2) 비식별관계

비식별관계는 부모(상위) 엔터티의 식별자가 자식(하위) 엔터티의 일반속성에 포함되는 것을 말한다.


[그림 4] 릴레이션십에 의한 상속/비식별관계
비식별관계로 릴레이션을 설정하면 [그림 4]와 같이  모양의 선이 그어진다. ‘직업’ 엔터티의 식별자 직업코드가 ‘고객’ 엔터티의 일반속성으로 포함된다.

위 모델의 ‘직업’ 엔터티와 ‘고객’ 엔터티를 보면 서로 관계를 갖고 있고, 비식별관계로 설정돼 있음을 알 수 있다. 비식별관계는 그림과 같이 직업 엔터티의 식별자 ‘직업코드’가 고객 엔터티의 일반속성으로 생성된다. 이 관계를 비식별관계라고 하며, ‘직업’ 엔터티는 ‘고객’ 엔터티 생성에 직접 관여하지 않는다. 즉 직업이 없어도 고객은 존재할 수 있다는 말이다.


[그림 5] 비식별관계 예와 Join
[그림 5]에서 보는 바와 같이 ‘직업’ 엔터티와 ‘고객’ 엔터티는 비식별관계로 릴레이션이 설정돼 있다. 서로 관계를 갖고 있고, 고객 엔터티는 직업 엔터티로부터 식별자를 상속받았기 때문에 SQL에서 Join할 수 있으며, 고객 개체가 가진 직업코드에 해당하는 직업은 반드시 1개여야 한다.

여기서 유의해야 할 점이 하나 있다. ‘고객’ 엔터티의 (직업 엔터티로부터) 상속받은 직업코드 식별자가 널(null)이냐 널이 아니냐는 다른 이야기이다. 즉 비식별 릴레이션십이 설정됐다고 해서 상속받은 식별자가 꼭 있어야 하는 것은 아니다. 없을 수도 있다. 직업이 없는 고객이 존재할 수 있으므로, 그런 고객은 ‘고객’ 엔터티의 직업 코드가 널(null)일 수도 있다.

[그림 5] 릴레이션에서는 널(null)이 없다고 돼 있다(고객 엔터티의 직업코드 속성 앞 * 표시가 있으면 널(null)이 없음(not null)을 의미한다). 이는 현실 세계에서는 고객의 직업이 없을 수도 있지만, 비즈니스적으로나 데이터적으로는 고객의 직업은 꼭 존재해야 한다는 의미라고 볼 수 있다.

위에서 소개한 식별과 비식별의 표기법을 정리해 보면 다음과 같다.


[그림 6] 식별/비식별관계 표기법
식별관계인 경우 자식 엔터티의 관계선에 바(I)가 표시되지만, 비식별관계인 경우에는 바(I)가 없다. 모델링 툴인 DA#, ER-WIN으로 실습해 보면 금방 알 수 있으니 꼭 해보기를 바란다.

관계(relation)에서 참조 무결성(referential integrity), 종속과 참조 관계, 식별과 비식별관계, 카디널리티(cardinality), 관계 디그리(relationship degree), 관계명, 순환 관계, 추출 관계(derived relationship) 등에 대한 것을 알아야 좋은 모델을 할 수 있다.

이에 대해 자세히 소개하면 좋겠지만, 데이터 모델 초급자를 위한 범위를 넘어서고 데이터 모델링 시작하는 분들에게 오히려 혼란을 야기할 수 있다고 보고 이 글에서는 언급하지 않는다. (다음 회에 계속)

 

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

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