계속해서 회의실 엔터티를 개선해보도록 하겠습니다.
원래 계획은 회의실의 소모품 불출 행위에 대한 엔터티를 추가할 계획이었으나, 디비안(DBian)의 무동님께서, 기존의 모델에 수정이 필요한 부분을 말씀 주셔서 그 부분을 먼저 해결해보려고 합니다. 무동님의 의견은 아래 링크를 확인해주세요.
이 글을 쓰는 목적 자체가 데이터 모델링 자체를 많은 분들이 접하게 하고, 다양한 모델러 분들의 의견을 들어 보는 것입니다. 감사하게도 현직 모델러 전문가들의 사부님이라 할 수 있는 무동님께서 의견을 주셔서 매우 좋았습니다.
설명에 앞서 간단하게 제2정규형과 제3정규형을 퀵하게 살펴보겠습니다. 데이터베이스 모델링에 있어 가장 중요한 기법 중 하나가 바로 정규화(Normalization)입니다.
정규화는 데이터의 중복을 최소화하고 데이터 무결성을 유지하기 위해 데이터베이스 구조를 체계적으로 설계하는 과정이라고… GPT가 정리해줬습니다. 정규화 과정을 통해 데이터의 일관성을 보장하고, 저장 공간을 효율적으로 사용하며, 데이터 조작 시 발생할 수 있는 이상 현상을 방지합니다… 라고 역시 GPT가 정리해줬습니다.
정규화 과정에서 데이터 구조는 여러 단계의 정규형(Normal Form)을 만족하도록 개선이 됩니다. 제2정규형과 제3정규형을 간단히 정의해보면 다음과 같습니다.
•
제2정규형(2NF)
◦
제1정규형(1NF)을 만족해야 합니다. 즉, 모든 속성의 값이 원자적이어야 합니다.
◦
부분 함수 종속성이 없어야 합니다. 키가 아닌 속성이 기본 키의 일부에만 의존하는 경우를 제거해야 합니다.
•
제3정규형(3NF)
◦
제2정규형(2NF)를 만족해야 합니다.
◦
기본 키가 아닌 일반 속성이 다른 일반 속성에 종속되서는 안됩니다.
▪
이행적 종속을 제거해야 합니다.
정말 간단히 개념만 설명했습니다. 정규화는 시간을 들여 꾸준히 공부하고 실습할 필요가 있습니다.
앞에서 설계했던, 회의실의 회의실별장비는 정규화가 잘 되었는가에 대해 고민해 볼 필요가 있습니다. 각자 공부했던 모델링 이론을 이용해 평가해보시기 바랍니다. 비난이 아닌 서로에게 나이스한 평가를 부탁드립니다. :)
원래 설계했던 회의실별장비의 속성들은 다음과 같습니다.
•
회의실ID(PK)
•
장비순번(PK): ???
•
장비ID(FK)
•
배치시작일자
•
배치종료일자
•
수량
•
장비시리얼번호(UK)
•
장비모델명
•
장비배치상태
여기서 ‘장비순번’이란 용어에 문제가 있습니다. 제가 사용한 기준은 ‘회의실에 장비를 배치한 순서 번호’의 의미입니다. 장비 테이블의 장비 데이터가 회의실에 배치 되는 순간 순번을 증가 시키면서 배치하는 번호의 의미입니다. 이와 같이 설계한 이유는 한 회의실에 같은 장비 여러 개가 배치될 수 있다는 점을 고려했기 때문입니다. 사실, ‘장비’ 테이블부터 좀더 디테일하게 설계되지 않았기 때문에, 위에서 무동님이 말씀주신것 처럼 이와 같이 모호한 설계가 만들어진 부분이 있습니다.
어쨋든, 이 구조에서 설계 내용을 좀 더 다듬어 보겠습니다. 장비순번을 ‘회의실장비배치순번’이란 의미로 변경하고 그에 따른 실제 데이터를 샘플로 그려보면 다음과 같습니다.
•
장비ID E01은 장비자산유형이 자산입니다.
◦
자산은 시리얼번호와 모델명을 관리하는 자산입니다.
◦
시리얼번호와 모델명이 입력되는 시점은 장비가 회의실에 배치되는 시점입니다.
•
장비ID E02는 장비자산유형이 소모품입니다.
◦
시리얼번호와 모델명을 관리할 필요가 없는 소모품입니다.
‘회의실별장비’ 엔터티의 기존 속성인 ‘장비순번’을 ‘회의실장비배치순번’이란 조금 더 명확한 개념으로 변경했을 때, 위 구조에서 제2정규형을 위배하는 속성이 보이지는 않습니다. (제가 발견 못하고 넘어갔을 수도 있으니, 있다면 댓글 부탁드립니다.) 또한 실제 샘플 데이터를 같이 살펴봄으로써 엔터티의 각 속성이 의미하는 바를 좀 더 잘 이해할 수 있게 되었습니다. 이를 통해 모델링 관련해서 다음과 같은 주의할 사항을 도출해볼 수 있습니다.
•
용어 선정에 매우 신중할 필요가 있습니다.
•
모델과 함께 실제 샘플 데이터를 표시한다면, 모델 이해에 큰 도움이 됩니다.
이번에는 제3정규형이 위배되는 항목을 찾아보죠. ‘장비시리얼번호’와 ‘장비모델명’ 이 두 속성은 제3정규형에 위배가 됩니다. 이 두 속성은 기본 키인 회의실ID와 회의실장비배치순번이 아닌 FK인 장비ID에 종속되는 속성이기 때문입니다. 이 부분이 해석이나 업무 시나리오에 따라서는 조금 다를 수도 있습니다. 예를 들어, “장비의 시리얼번호와 모델명은 무조건 회의실에 장비가 배치되는 순간에 입력합니다.”와 같은 절대적인 규칙이 존재한다면, 위의 모델이 제3정규형에 어긋난다고 말하기는 애매할 수도 있습니다.
하지만, 데이터 모델러로 잔뼈가 굵었다면, 이러한 업무 정의에 대해 다음과 같은 생각을 해볼 필요가 있습니다.
•
장비는 실제 생산 시점에, 시리얼 번호와 모델명이 부여되어 있습니다.
•
A 회의실에서 장비(자산)가 배치 되었다가 B 회의실로 옮기는 부분에 대해서는 어떻게 처리할 것인지에 대한 의문도 제기할만합니다.
•
장비가 폐기되는 순간은 또 어떻게 해야 할까요?
•
장비를 배치했다가 회의실에서 잠깐 뺀 경우에는 어떻게 할 것인가요?
위와 같이 꼬리에 꼬리를 무는 질문을 스스로 해보면, 현재 데이터 모델이 프로그램 UI 상으로 돌아가는 데는 문제가 없어 보이지만, 데이터가 계속 흐르면서 운영하다 보면 문제들이 생길 수 있지 않을까라는 생각이 들게 됩니다. 실제 업무 담당자, 개발자와 함께 이러한 부분을 논의하고 필요하다면 설계를 변경하는 것을 제안해볼 필요가 있습니다.
생각을 거듭해 장비와 회의실별 장비에 대한 데이터베이스 모델을 조금 더 발전시켜보면 다음과 같습니다.
•
우선, 장비자산유형을 다음과 같은 구분으로 변경합니다.
◦
자산관리장비: 자산으로 등록해 모델명과 시리얼번호를 관리하는 고가의 장비입니다.
◦
자산비관리장비: 의자와 같이 회의실에 배치를 하지만 모델명이나 시리얼번호의 관리가 필요없는 장비입니다.
◦
소모품: 마커펜, 화이트보드지우개와 같은 주기적으로 불출하고 소모되는 소모품입니다.
위 내용을 포함해 모델을 다시 만들어 보면 다음과 같습니다.
위 모델은 완벽할까요? 아닙니다. 여전히 문제가 있을만한 모델입니다. UI 구성에 따라 개발 난이도가 증가할 수 있으며, 향후 데이터를 분석하거나 활용할때 쉽지 않은 모델일 수 있습니다.
지금 중요한 것은 여러분들의 상상력과 생각을 담아 자신의 모델을 만들어 보는 것입니다. 잘하든, 못하든 상관 없이 많이 그려보고 많이 생각해보기 바랍니다.