데이터 모델링14 - 정의된 집합으로 모델링 하기

명확하게 정의된 집합으로 모델링을 시작하자

그림 8-4 IT 교육 센터의 다양한 교육 프로그램

한 IT교육 센터에서 [그림 8-4]와 같은 다양한 교육 과정을 관리하기 웹페이지의 데이터를 관리하기 위한 모델링을 시작했다고 가정해 보자.

 

가장 먼저 흰종이에 박스 하나를 그리고 그 위에 '교육 과정'이라는 이름을 붙인 엔티티를 하나만들었다. 엔티티를 의미하는 박스를 만들고 엔티티명을 적는 것은 박스 안의 세계와 바깥에세계를 완전히 단절시키는 행위다. 즉, 교육 과정이라는 집합에 들어갈 개체와 들어가서는 안되는 개체를 완전히 분리하겠다는 의미다. 앞서 언급한 것처럼 관계형 데이터 모델의 핵심은 엔티티는 엔티티와 관련된 속성만을 집약해서 가지고, 다른 엔티티의 정보가 필요할 경우는 관계를 통해서 연결해 사용하는 것이다.

 

그림 8-6 교육 과정 상세 페이지

 

교육 과정 관리를 위한 웹페이지 모델링 이야기로 돌와와 교육과정 엔티티에 대해 그 정체성과 정의를 깊이 생각해보자 교육 과정은 교육 과정 안내 페이지의 어느 영역에 해당하는가? [DB]-[데이터베이스 기술]-[과정로드 맵] -[핵심]의 속한 과정인  'RDB를 기초로 한 데이터 모델링' 이라는 개체 수준인가, 아니면 해당 과정을 클릭 했을 때 조회되는 상세 페이지[그림 8-6]의 주제 수준인가?

 

다시 말해 이 질문은 '교육 과정'이라는 것이 순수 '교육 과목'을 의미(추상적의미)하는지 아니면 '특정 기간네 개설되는 강좌'를 의미하는지 확인하는 것이다. 교육과정 엔티티가 두가지중 어떤 것을 의미하느냐에 따라 집합의 개념이 완전히 달라진다. 교육 과정이 순수한 교육과목으로서의 추상화된 의미라면 'RDB를 기초로 한 데이터 모델링'이라는 개체는 교육 과정 집합에 단 하나 존재하게 되지만, '특정 기간에 개설되는 강좌'라면 개설된 수 만큼의 개체가 존재하게 된다.

 

그런데 순수 교육 과목이라는 개념도 생각보다 간단하지 않다. 예를 들어 이 교육센터에는 다음과 같은 업무 규칙이 있다고 하자

• 주중에 공휴일이 있는 주에는 5일 과정이 4일 과정으로 개걸되기도 한다.
• 동일한 과목이지만 과정 이름과 강의 일수만 다른 과정이 존재할 수 있다. 예를 들어 'RDB기초로 한 데이터 모델링' 과목이 5일짜리 동명의 과정으로 개설될 수도 있고, '업무에 바로 쓰는 RDB 데이터 모델링 Essential'이라는 3일 과정으로 개설될 수도 있다.

이 업무 규칙의 핵심은 과목의 변형된 형태와 그것의 원형이 존재한다는 것이다. 이를 반영한 데이터 모델의 위 그림과 같다.

 

그림 8-7 과목의 원형과 변형된 형태를 관리하는 구조

<교육과목> 엔티티는 순수 과목 집합(추상화된 개념)이라고 보면된다. 즉, 교육 센터 홈페이지의 교육 과정 안내와 같은 뷰에서 보이지 않지만, 교육 과목의 원형을 관리하는 집합이다. 'RDB를 기초로 한 데이터 모델링'이라는 책이 있고, 이 책의 내용을 강사 A는 3일, 강사 B는 5일 동안 강의한다고 할 때, 바로 책(<교육과목>의 정보단위) 수준의 관리 집합이라고 보면 이해하기 쉬울 것이다. 이러한 맥락에서 <교육과목>엔티티의 속성에는 교육 일수는 포함되지 않으며 <교육과목>의 본질에 해당하는 메타정보인 <과목수준코드>(초급, 중급,고급 등)와 <과목분류코드>(DB,OS등의 기술분류 체계)등이 포함된다. 

 

또한 <교육과정>역시 변형이 존재할수 있다. <교육과정> 엔티티는 'RDB를 기초로 한 데이터 모델링'이라는 과목이 과목명 그대로 개설된 경우와 '업무에 바로 쓰는 RDB 데이터 모델링 Essential'이라는 과정으로 변형된 경우를 개별 개체로 분리하여 관리하는 집합이다.  이때   <교육과목>을 가르치는 방식에대한 차이가 교육과정 개체 생성의 정보단위가 된다.따라서 <교육일수>같은 속성은 이 수준에서 관리되는 것이 적당하다. 

 

끝으로 <개설교육과정> 엔티티는 'RDB를 기초로 한 데이터 모델링'과정이 12월에 1일과 15일 2차례 걸쳐 개설된다고 할 때의 2개의 개별 개설 과정 개체를 관리하는 집합이다.

 

이처럼 모호한 것들을 객관적인 시각에서 명확히 하여 관리할 수 있도록 하는 것이 엔티티 정의의 시작이다. 엔티티를 명확히 정의한다는 의미는 집합의 성격에 부합하는 엔티티명을 지어준다는 뜻도 있지만, 그 집합의 개체들이 어떤 기준(정보단위)으로 발생되고 관리 되는지 명시적으로 규정하는것, 속성들이 어떤 수준(ex.책)이나 존재(엔티티 ex.교육과목)에 고유한 특성인지 파악하는 것이라고 할 수있다.

 

그림 8-8 사원-프로젝트 할당 모델 예

더불어 위의 예와 같이 개체의 발생 규칙과 주 식별자가 일치하는지 검증하는 것도 엔티티의 정의에서 중요한 과정이다. [그림 8-8]의 <프로젝트할당> 엔티티의 주 식별자는 부모인 <사원>과 <프로젝트>엔티티로부터 내려받은  <사원번호>와 <프로젝트ID>로 구성되어 있다. 통상 사원 한명이  여러 프로젝트를 수행할 수 있고 한 프로젝트에 여러 사원이 참여할 수 있다. 즉, <프로젝트할당> 엔티티는 이러한 M:N의 관계를 해소한 관계 엔티티인 셈이다.

 

그런데 프로젝트에 단위테스트와 통합테스트 같은 특정 단계에 잠깐 할당되는 테스트 전문 인력도 있을 수 있다. 그에 반해 위 구조에서는 한사원은 하나의프로젝트에 단 한 번만 관계할 수 있다. 개체의 발생 규칙에 해당하는 주 식별자가<프로젝트ID> + <사원번호>로 구성되어 있기 때문이다. 따라서 사원X가 A라는 프로젝트의 여러번 할당(여러가지 역할로 참여할 수 있다.)될 수 있으려면 주 식별자에는 할당(발령)일자와 같은 시간이 추가로 개입되어야 한다. 이는 앞선 게시물 [데이터 모델링2- 데이터 이해하기]의 소재목 상품 주문 데이터 이해하기 에서 다루었던 고객의 상품 주문과 유사한 패턴이다.

 

엔티티를 정의할 때는 엔티티의 성격뿐 아니라 개체의 증가 기준도 명확히 해야 하는데, 주 식별자가 바로 이러한 개체 발생 규칙을 설명한다.(*인조 식별자로 처리되는 경우는 논외로한다.) 즉, '주 식별자 정의 = 엔티티 정의'라고 할 수 있으며 '주 식별자는 엔티티와 한 몸이다'라고 할 수 있다.

 

💡tip) 인조식별자

업무의 필요에 의해 만들어지지 않았지만 본질 식별자가 복잡한 구성을 갖고 있어 인위적으로 만든 식별자 이거나 혹은 후보 식별자 중 PK로 선정할만 한 것이 없을 때 사용한다.

장점
- 모델이나 SQL이 간단해진다.

단점
- 인스턴스 생성 기준을 인조 식별자만으로 판단하기 어렵다.
- 모델만 보고 업무를 이해하기 어렵게되어 특히 행위 엔티티에서 가독성이 저하된다.

복합키의 변경이 빈번할 경우 혹은 복합키가 4개 이상일 경우 인조 식별자를 사용하는 것이 나을 수 있다.

 

그림 8-9 주소를 회원에 종속된 정보로 관리하는 경우와 별개로 관리하는 경우

마지막으로 주소와 관련된 사례를 하나 더 살펴보자 [그림 8-9]의 <주소>엔티티를 어떻게 정의했느냐에 따라 <고객>과 <주소>의 관계가 달라진다. <주소>는 고객이 이사할 때마다 하나의 개체가 발생하는 고객에 종속(dependent)된 정보로서의 주소를 관리하는 집합이다. 반면에 <ADRESS>는 전국에서 유일한 개체로서의 주소를 관리하는 자립(independent)엔티티이다. <주소>에서 김진희가 살았던  '서울시 강남구 서초동 11'과 김준호가 살았던 주소를 완전히 다른 개체로 관리하지만, <ADDRESS>에서는 하나의 개체로 관리되는 것을 확인 할 수 있다.

 

[출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저]