데이터베이스 모델링 1-2 정형 vs 비정형(EAV)
정형과 비정형 기초적인 문제임에도 대부분의 개발자들이 의외로 인지하지 못하는 부분이다.
고급언어(화면) 개발자들 중에는 교조적인 경우가 많다.
단순히 DA 가 본인들과 대비해 돈만 많이 받아먹는 하마로 폄훼하는 경우가 많다.(의외로 노골적으로 표현하는 개발자들이 아주 많다)
워딩이 조금은 다를 수 있지만 의미는 동일하게 "내가 해도 그 정도는 하는데 시간이 없는거야" 로 귀결되고 모델링만이 아니라 튜닝도 마찬가지다.
허나 정말 그들이 뭘 알고 하는 말일까?
물론 허접한 DA가 있을 수도 있다.
내가 말하는 것은 정상적인 DA에게 조차도 그런 인식이 존재하는데 경력과 무관하게 고급언어 개발 3년차가 넘어가면 다수가 이런 사고방식에 젖어드는 것 같다.
하지만 그들의 비판에는 늘 이론이 부족하다.
아스팔트위 태극기와 성조기 이스라엘기를 흔드는 사람들과 뭐가 다른지 모르겠다.
책 한권읽은 놈이 가장 무섭다는 격언은 여기서도 통이다 !!
개발언어에서 새로운 매서드, 속성등이 새롭게 지원하면 생성배경이나 사상은 전혀 게의치 않는다.
그냥 맹신적으로 종속되어 사용할 뿐이다.
세상속의 대부분의 Rule을 바라볼때는 배경과 사상을 함께 인지하는 사유의 연습이 필요하다.
이러한 사유를 포함한다 해도 길지 않은 시간에 고급언어는 일반인도 하루이틀이면 개발이 가능한 손쉬운 위저드 형태로 제공될 것이다.
초해문자 상태의 지속은 고급 언어의 개발 수준 격하를 가속화 시킬 것이다.
본론으로 들어가서
정형과 비정형 에 대해서는 들어는 봤을것이고
개념 정립이 된 사람도 있고 반대인 경우도 있을 것이다.
정형 모델링의 대전제 조건은 기본적으로는 스키마의 불변이다.
아래와 같은 물감 판매 테이블이 있다고 치자
create table t1(
colchar1 varchar(4) not null -- 판매처코드
, colchar2 varchar(1) not null -- 유성/수성 구분
, val1 int not nul -- red 개수
, val2 int not nul -- green 개수
, val3 int not nul -- blue 개수
)
이 테이블의 특징은 정형/비정형 모델링이 혼재 되어 있다는 것이다.
colchar2 의 경우 현재 유성/수성 물감으로 구분할 수 있는 구분자이다.
혹 나중에 다른 형태의 물감 형태가 출시된다해도 수용이 가능하다.
다만 이것을 수정_red, 유성_red 로 컬럼을 다 분할할 경우(아래와 같이)
create table t1(
colchar1 varchar(4) not null -- 판매처코드
, valO1 int not nul -- red 유성개수
, valW1 int not nul -- red 수성개수
, valO2 int not nul -- green 유성 개수
, valW2 int not nul -- green 수성 개수
, valO3 int not nul -- blue 유성 개수
, valW3 int not nul -- blue 수성 개수
)
색상이나 구분이 늘어날 경우 수용이 불가능하다.
EAV(Entity-Attribute-Value Model) 로 완전히 변경한다면 아래와 같이 간소화된다.
물론 row count가 늘어날 수 있으나
이런 경우 모든 판매처에에서 모든 생상을 판매하는 것이 아니라면 EAV방식이 더욱더 효율적이다.
create table t1(
colchar1 varchar(4) not null -- 판매처코드
, colchar2 varchar(1) not null -- 유성/수성 구분
, colchar3 varchar(8) -- 색상구분
, val int not nul -- 개수
)
EAV 모델의 경우 탄력적으로 운영이 가능하며
쿼리가 조금 복잡해 질 수 있으나 고객의 요구사항에 따른 조회 조건에 따라 오히려 간소화될 수 있다.
부득이한 경우 컬럼을 추가/수정할 수 있으나 잦은 변경은 초기 모델링이 잘못되었음을 자인하는 격이다.
혹 내가 진행하지 않았다 하더라도 무심코 진행하는 컬럼추가는 지양해야한다.
전임자를 욕하기전에 스스로 또이또이를 인정하는 격이다.
EAV와 반대로 정형 모델링의 경우는 언급한 바와 같이 탄력적이지 않은 것이라 판단되는 경우에 유용하다.
아무래도 직관적이고 조회시 쿼리가 심플해지는 면이 있다.
그럼에도 불구하고 빠른 기업 환경 변화에 적용하기에 무리가 있고
하나의 row에 데이터가 모두 채워지지 않는 경우 데이터의 누적 특징상 사이즈가 비대해지게 마련이다.
오라클에서는 block이라 불리우고 SQL server에서는 page라 불리우는 테이블 하위 단위에 따라 다르겠으나
잘못된 모델링으로 의미없는 공간 낭비는 줄이는게 좋다.
개인적으로 정형(pivot형) 모델링의 최대단점으로는 고도화를 비롯한 고객 요구사항 추가나 변경에 대응이 힘들게 되는데
테이블이 대용량인 라이브에서 적용하기가 무척 난감하게 된다.
그럼에도 불구 혹 기 생성된 테이블이 정형 모델링인 경우 Key 값을 감안하여 개별 테이블로 생성하는 것도 유용하다.
아래 테이블을 보자
create table t1(
colchar1 varchar(4) not null -- 판매처코드
, colchar2 varchar(1) not null -- 유성/수성 구분
, colchar3 varchar(8) -- 색상구분
, coldt varchar(8) -- 판매일자
, val int not nul -- 개수
, constraint pk_t1 PRIMARY KEY CLUSTERED( colchar1, colchar2, colchar3, coldt)
)
조금 억지스러운 예제이겠으나 논리만 이해하고 너그러이 보도록 하자.
이 테이블은 이미 1억 row가 넘어간 상태로 가정한다.
이전까지는 고정 가격이었으나 2025년부터는 업체별로 색상별로 비규칙적 가격 변동제를 계획하고 있다.
어떻게 해야할까?
판가와 일자는 당연히 not null 조건이다.
page 구성에 따라 다르겠으나 아무 생각없이 컬럼 2개 추가하면 어찔될지 테이블의 사이즈 측면에서 상상해 보라.
굳이 설명안해도 감이 잡힐 것이다.
뭐 우리회사 서버는 용량이 아주 넉넉해서 괜찮아.
이제 서버를 직접 관리하는 시대가 저물어간다.
AWS, AZURE, GCP등등.. 이제는 쓴만큼 아주 세부적으로 비용이 청구된다.
이런 추가 요구사항이 나올때마다 이렇게 추가할 것인가?
나라면 테이블 하나를 만든다.
양쪽 테이블의( colchar1 , colchar2 , colchar3) 를 기준으로 기본 조인을 하고
단가 확정일자와 판매일자를 부등연산자와 MIN 혹은 MAX 함수로 찾을 수 있다.
단가 변경은 아주 자주 발생하지 않으므로 아래 tUP 테이블은 row count의 누적량이 작을 것이다.
(외래키는 편의상 생략한다.)
create table tUP(
colchar1 varchar(4) not null -- 판매처코드
, colchar2 varchar(1) not null -- 유성/수성 구분
, colchar3 varchar(8) -- 색상구분
, coldt varchar(8) -- 단가 확정일자
, val1 int -- 단가
, constraint pk_ tUP PRIMARY KEY CLUSTERED( colchar1, colchar2, colchar3, coldt)
)
결론적으로 변화가 거의 발생하지 않을 것으로 예상되고 모든 컬럼에 값이 채워지는 테이블의 경우 정형 모델이 우세할 수도 있겠으나 근래 트랜드상 다양하게 진화하는 데이터 마이닝 여건상 특별한 경우가 아니라면 지양하는게 좋다.
DBMS 모델링에 정답은 없다.
허나 기본기를 바탕으로 고객의 요구사항과 트랜드를 읽어내는 사유는 반드시 대전제로 충족되어야 한다.
상황마다 다르겠으나 사용자도 좀 되고 전체적으로 복잡한 구조라면 DA 혹은 전문 모델러에게 의뢰하길 추천한다.
20년차 고급 개발자도 형편없는 경우을 너무 많이 보아왔다.
이제 사고의 주류는 수렴적(Convergent)이기 보다 확산적(Divergent)이다.
초중등 교육과정이 많이 얼룩진 경향이 강하지만 그냥 굴복하기엔 충분히 혼자 극복이 가능한 시대이다.
개별적인 열정을 바탕으로한 확산적 사고만이 AI 시대에 대응할 유일한 대안이 아닐까 싶다.
이 글은 이비니어스( www.evinious.co.kr )의 소유이며 불펌은 허락하지 않습니다.