실무 데이터 관리를 할 때 항상 뭔가.. 데이터가 일관적이지 않은 것 같은 것 같다 (ex. 이걸 key로 하면 숫자가 안맞는데..? 무슨 기준으로 이것을 나눠놓은 걸까..?) 는 의문을 종종 품었던 것 같다. 그리고 루틴하게 관리만 하는 실무자 입장에서는 이런 생각들이 필요 없을 수 있기 때문에 괜한 고민을 하는 게 아닌가 생각했었다. 하지만, 이 문제들은 전부 학문적으로 정리가 되어 있는 것들이었다.
데이터베이스 설계의 가장 첫번째 단계인 개념적 모델링 단계 내용이다.
1. key words
- 데이터 모델링과 ER모델
데이터 모델링의 과정: 요구사항 수집 및 분석 -> 설계 -> 데이터베이스 구현
ER모델은 설계 첫단계에서 사용되며, 일단 구축하고 나면 DBMS에 독립적으로 운영됨.
ER모델은 컴퓨터공학적 지식이 없어도 설계 가능.
- 개체 Entity 와 속성 Attribute
개체는 '어떤 것' 에 해당. ex. 사원
속성은 '어떤 것의 성격'에 해당. ex. 사원의 이름, 사원의 사회보장번호, 사원의 생년월일..
속성 값은 해당 속성에 해당하는 '값'. ex. 속성 '사원의 이름'에 해당하는 속성 값은 Jason Kim, Paul Lee...
속성의 타입은 Simple, Composite, Multi-Valueed, (Complex), Derived, Null 존재
- 개체 타입 Entity type과 키 key
- 관계 Relationship 와 관계 타입 Relationship Type
- 카디널리티 Cardinality 비율 제약조건 (1:1, 1:N, M:N)
- 참여 제약조건 Participation Constraint (Total, Particial)
*관계타입의 속성, 약한 개체타입, 삼진관계타입은 생략하고, 해석으로 넘어가도록 해보겠다.
2. ER모델 해석하기
EMPLOYEE ENTITY
- EMPLOYEE 개체는 SSn, Bdate ... Sex등의 속성을 가지며, Ssn을 키값으로 구분할 수 있고, Name 속성은 다시 하위의 Fnae, Minit, Lname 속성으로 나눌 수 있다.
- EMPLOYEE 개체는 SUPERVISION 이라는 관계를 1:1로 주고받을 수 있다. 예를 들면, 1번 사원 김OO, 2번 사원 이OO사이의 관계는 김OO부장 - 이OO대리로서 대리가 부장에게 보고하는 형식의 관계이다. (보통 이런 경우 따로 Report 컬럼을 두어; Derived Attribute type 해당 사원의 보고 라인을 바로 볼 수 있게 한다. 아래에서 Reculsive Relationship 관련 디테일한 설명을 추가한다.).
- 또한 이 때의 SUPERVISION 관계에서 Supervisor 1명에 여러명의 Supervisee가 존재 가능하다. (이 때의 케이스를 디테일하게 말하면 Supervisor-Supervisee 관계가 아예 없는 EMPLOYEE일 수도, 누군가의 Supervisor이기만 할수도, 누군가의 Supervisee이기만 할수도, 누군가의 Supervisor이면서 Supervisee일 수도 있다.)
EMPLOYEE ENTITY와 DEPARTMENT ENTITY의 관계
- EMPLOYEE는 DEPARTMENT 에 일 하는 관계, DEPARTMENT를 관리하는 관계 두 가지로 구성된다. (즉 사원이 쭉 나열되어있는 엑셀 시트 하나, 부서 관련 정보가 쭉 나열되어있는 엑셀 시트 하나가 있다면 어떤 사원은 부서 내 단순 팀원, 어떤 사원은 피플 매니저일 수 있다.)
- 모든 EMPLOYEE는 어떤 DEPARTMENT에 반드시 소속되어 일하는데 한 사람이 두 부서에 동시에 소속될 수는 없다.
- 부서를 관리하는 EMPLOYEE (manager)이 항상 존재한다. 하지만 모든 EMPLOYEE가 부서를 관리하는 것은 아니다.
- 피플매니저와 DEPARTMENT사이의 관계에서 Start_date이라는 속성이 파생된다.
DEPARTMENT ENTITY
- 한 DEPARTMENT에 여러 Location이 있을 수 있으며 Name 과 Number은 각각 DEPARTMENT의 key로서 사용할 수 있다. (ex, 영업 부서(부서코드: 123) - 근무지: 서울, 천안)
DEPARTMENT ENTITY와 PROJECT ENTITY의 관계
- DEPARTMENT와 PROJECT는 부서에서 프로젝트를 컨트롤하는 형태로 관계가 맺어진다.
- 프로젝트는 반드시 컨트롤해주는 담당부서가 있다. 하지만, 모든 부서가 프로젝트를 컨트롤하고 있는 것은 아니다.
- 한 부서에서 여러 개의 프로젝트를 컨트롤 할 수는 있지만, 한 프로젝트에 여러 부서가 할당되지는 않는다.
PROJECT ENTITY
- Location, Name, Number 속성으로 구성되어 있으며 Name, Number은 key값으로 쓸 수 있다.
PROJECT ENTITY와 EMPLOYEE ENTITY의 관계
- EMPLOYEE가 어떤 PROJECT에 할당되어 일하는 형태의 관계가 있다. 이 때 일하는 시간이라는 속성이 파생된다.
- 모든 EMPLOYEE는 하나 이상의 프로젝트를 맡는다. 직원이 한 명도 할당되지 않는 프로젝트도 있다.
- 하나의 프로젝트에 여러 명이 할당될 수도 있고, 한 직원이 여러 프로젝트에 동시에 할당될 수도 있다.
EMPLOYEE와 DEPENDANT(부양가족)의 관계
- 부양가족이라는 데이터는 EMPLOYEE에 종속된다.
- 부양 가족이 없는 사원도 존재한다.
- 한 사원에 여러 명의 부양가족이 존재할 수 있다.
- 부양가족 데이터 내에서 다시 Name이 있는데, 한 부양가족 리스트 내에서는 Name이 중복되지 않으므로 key값으로 설정 가능하다.
3. Reculsive Relationship Type
인사자료로 조직도를 뽑는 간단한 함수를 만든 적이 있다. 이 때 나도 모르게 내가 사용했던 개념이 recursive relationship인 것 같다. 이 개념이 재미있는 이유는 이것을 통해서 해당 직원의 조직 내 layer을 예상해볼 수 있다는 것이다. 예를 들면, 말단사원 - 대리 - 부장 - 이사 - 사장 의 보고라인을 갖고 있다면, 더이상 recursive가 순환하지 못할 때까지 상사를 찾는 과정을 반복했을 때 말단사원의 조직 내 layer (위에 쌓여있는 보고 라인) 은 4로 보고 아래쪽에 놓는다. 이사급들은 사장에게만 보고하므로 1로 끝난다. 사장은 0이다.
자료 출처: HaRim Jung, Ph.D.