DATOR


마스터데이터연결법 데이터모델


데이터 모델의 핵심 데이터인 마스터 데이터들은 혼자만으로도 중요한 정보를 관리하고 있다. 그러나 혼자 일 때 모다 여럿이 뭉쳤을 때 강력한 파워를 발휘하듯이 마스터 데이터도 다른 데이터와 서로 연결을 하면서 의미가 강력해 진다.

본 글에서는 개체집합, 핵심, , 기본, 마스터 데이터 등 여러 용어들을 사용하고 있는데 개인적으로는 그냥 마스터라고 부르는 것이 편하다.  처음 프로그램 세계에 입문하였을 때 마스터-디테일 테이블이라고 부르던 습관 때문인 것 같다.

이번에는 개체집합인 마스터 데이터들끼리 서로 연결하는 모형을 살펴 보도록 하자. 개체와 개체를 연결하는 이유는? 바로 비즈니스 규칙을 정의하기 위함이다.  다른 말로는 프로그램에서 처리할 로직을 데이터로 세팅하기 위함이다.

 

< 목적 >

     - 개체 마스터 데이터간의 데이터 연결을 알아본다.

시나리오 >

     - 엔코 전자에서는 다양한 컴퓨터 부품/반제품/완제품을 생산한다.

     - 제품을 생산하기 위해서 많은 제조장비가 갖추어져 있다. 제조 장비별로 생산 가능한 제품들이 정해져 있다.

     - 제품과 장비의 다양한 셋업 정보들이 존재 하며, 셋업 정보를 어떻게 구성 할 지가 고민이다.

설명 1) 장비와 컴퓨터의 M:M 연결 

1.기본MM 설명.jpg

설명 1) 컴퓨터를 생산하기 위해서는 많은 장비들이 필요하다. 각 장비들은 컴퓨터의 부품, 반제품을 생산하기 위하여 가동된다. 모든 장비들이 하나의 컴퓨터를 생산하기 위해 필요한 것은 아니다. 특정 장비는 특정 컴퓨터 제조공정에만 사용되어 있다. 이러한 규칙들은 미리 세팅되어야 제조공정 자동화가 구현 될 수 있다. 장비 : 컴퓨터의 관계는 M:M으로 구성되어 있다.

 

모델 1) 장비컴퓨터 M:M 관계 엔티티

1.기본MM 모델.jpg

모델 1) 장비와 컴퓨터는 M:M 관계를 지닌다. 관계형 엔티티는 보통 여러 개의 매핑 규칙을 지니고 있다. 때문에 모델에는 서브타입인 관계구분코드 PK로 정의되어 있다.

이것으로 데이터 연결모형이 끝나는 걸까? 대부분의 사이트에서는 이 정도 관계엔티티로 마무리되는 경우가 많을 것이다.

그러나 비즈니스가 복잡하고 대량의 마스터 데이터를 관리하는 곳에서는 연결 데이터를 만드는 것에 시간과 노력이 많이 소비되기 때문에 또 다른 대안을 찾고자 할 수 있다.

설명 2) 대량의 마스터 데이터를 연결하려면 대량의 관계를 관리해야 해

2.대량이라면 설명.jpg

설명 2) 마스터 데이터가 엄청 많다면 관계를 설정하는 것이 어지러운 일일 것이다.  과연 이 많은 데이터의 설정이 올바로 세팅 되었는지 담당자도 자신하지 못 할 수 있다. 에고~  파란 관계선을 보니 현기증이 날려 한다. 좀 적은 데이터로 세팅 할 수는 없을까?  있다.  바로 이전 글에서 계속 이야기 해 오던 그룹핑이 하나의 대안이 될 수 있을 것이다.

 

설명 3) 그룹을 만들어 관계 개수를 줄여 보자

3. 장비그룹 연결 설명.jpg

설명 3) 생산 장비는 기계의 특성과 용도에 따라 논리적인 그룹이 가능 할 것이다.  컴퓨터의 특성과 유사한 장비의 특성을 모아서 그룹 개체를 만들고 이 그룹 개체와 컴퓨터를 연결한다. 그림에서도 수 많은 관계선이 많이 없어지고 단순화 되었다.  관계는 단순해 지겠지만 장비그룹을 만들어 관리해야 하고,  장비그룹장비마스터의 연결 관리도 해야 한다. 추가적인 업무관리가 발생하는 것은 어쩔 수 없을 것이다.  과연 이런 그룹형태의 업무관리가 효율적인지는 업무전문가의 많은 경험, 노련함, 의지가 반드시 있어야 할 것이다.

 

모델 3) 장비그룹으로 컴퓨터와 연결 

3. 장비그룹 연결 모델.jpg

모델 3) “장비그룹엔티티가 추가 되었다.  비즈니스 규칙이 장비에서 장비그룹으로 변경되었다.  모델은 평이한 구조이기 때문에 쉽게 이해 할 수 있을 것이다.  그룹 데이터를 누가 어떻게 관리하느냐가 관건이겠다.

 

설명 4) 컴퓨터도 이라는 형태의 그룹을 만들어 연결해 볼까?

4.컴퓨터 그룹 연결 설명.jpg

설명 4) 와우! 관계 개수가 엄청 단순해 졌다.  마치 복잡하게 얽힌 실타래가 풀린 것 같은 느낌이 들지 않는가?  그림에서는 일부러 과장하여 단순한 관계선으로 표현하였다.  그룹그룹으로 데이터를 연결하는 기법을 사용하였다.  하나를 취하면 하나를 잃는 것이 자연의 섭리.  컴퓨터 군이라는 요상스런 그룹을 또 누군가가 관리해 주어야 한다. 현장에서는 품목코드, 마스터항목, 아이템코드 들이 컴퓨터의 그룹집합이 될 수 있겠다.

모델 4) 그룹끼리의 관계연결

4.컴퓨터 그룹 연결 모델.jpg

모델 4) 데이터 관리가 상세화 됨에 따라 추가적인 엔티티들이 도출되었다.  장비그룹 : 컴퓨터군 = M:M 관계로 구성되었다. ~ 멋져 보인다. 그럴싸한 모델처럼 보인다. 이런 그룹 형태의 모델로 업무를 처리하다 보면 꼭 나타나는 요상한 요건들이 나타난다.  초기 사용시기에는 나타나지 않을 수 있지만, 유지보수하고 세월이 지남에 따라 최초 업무규칙에서 어긋나는 데이터들이 발생한다. “그냥 있는 그대로 쓰세요.  시스템 규칙에서 어긋나지 않게 올바로 사용하세요. 시스템 영향도가 크기 때문에 구현할 수 없어요. 라는 시스템 관리자의 말은 통하지 않는다.  강성 고객의 입맛에 따라 단순한 로직들은 꼬이기 시작한다. 배배 꼬여 ~

 

OO제품은 장비그룹 관계를 따르지 못해요.  컴퓨터군이 아니라 컴퓨터에 직접 연결해 주세요. 이건 예외사항 이라구요”. 그렇다.  모든 시스템에 존재 하는 예외사항!  If then else, case when 구문을 아주 좋아하는 예외 사항 말이다.

 

설명 5) 빨간색 연결은 >> 예외처리 

5. 예외 연결 모델.jpg

모델 5) 빨간색 연결선은 장비컴퓨터와 직접 연결되어 있다. 일부 예외 처리를 할 수 밖에 없는 상황이다.  언제부턴가 IT 프로그래머의 힘이 약해져서 고객의 요구사항을 수용해 주어야만 하는 신세가 되었다. 만들어 달라는 대로 만들면 되지 뭐.  우린 프로그램을 창조하는 IT전문가 이니까.  우리가 구현 못할 기술들이 있으랴.

 

모델 5) 장비와 컴퓨터의 예외 엔티티 추가요

5. 예외 연결 모델_ㅈ.jpg

모델 5) 결국 관계 엔티티가 2개 생겨 버렸다. “장비그룹 별 컴퓨터군 관계장비 별 컴퓨터 예외관계  OO장비에서 사용가능 한 컴퓨터를 찾으려면 1) “그룹관계에서 해당 컴퓨터를 찾는다. 2) “장비컴퓨터예외에서 해당 컴퓨터를 찾는다.  2)번에 데이터가 있으면 이를 따르고 없으면 1)에서 찾은 데이터를 따르게 된다.  양쪽에 데이터가 존재하니 2개의 테이블을 각각 조회하여 매칭시켜 보아야 한다.  이때 2건의 데이터 중 어느 것을 선택할 것인가에 대한 우선순위가 결정되어야 한다.

 

모델5)2개 관계 테이블을 보면 통합하고 싶은 욕망이 마구 일어나지 않는가? 그럼 한번 통합한 모델을 보자.

 

모델 6) 관계 테이블의 통합

6. 관계 테이블통합 모델.jpg

모델 6) 관계 엔티티가 통합 되었다. PK장비식별ID”컴퓨터식별ID”로 되어 있다.  PK가 서로 다른 장비그룹장비을 대신하는 속성이다. 배타적인 PK를 통합한 형태이다.

 

모델5는 관계 분리형태이고 모델6은 관계가 통합된 형태이다. 어느 모델이 유리 할까? 너무 많은 통합을 해 놓으면 시간이 흘러 여러 사람의 손을 거치고 나서, 이상한 정체 불명의 통합 관계 엔티티가 될 가능성이 높다. 심지어 개발자도 이곳에 있는 데이터가 무엇인지 모른다.  프로그램을 봐야만 알 수 있는 지경이 올 수도 있다. 통합과 분리는 상황에 따라 다르기 때문에 현재 운영 중인 사이트에서 가장 잘 관리 할 수 있는 형태를 선정 해야겠다.

 

모델 7) 공통분모로 M:M 연결

7.공통분모 연결모델.jpg

모델 7) 만약 마스터 데이터들간의 공통적인 성격이 있다면 공통속성으로 이루어진 장비제품공통엔티티가 도출 될 수 있다. 이는 장비컴퓨터간 직접적인 연결을 하지 않고 간접적인 M:M 관계로 로직을 구성 할 수 있다. 이에 대한 사례는 현재 잘 기억이 나지는 않지만 가능한 case가 있다. (나중에라도 샘플이 나타나면 글로써 올려야 겠다)

 

지금까지 개체 집합들끼리의 연결에 대한 여러 방식을 살펴보았습니다. 하나의 모델에서 출발하여 꼬리에 꼬리를 물고 여러 case의 모델을 만들게 되었습니다. 

모델 사례를 작성하다 보니 의미 전달하는 것이 쉽지 않다. 최대한 개념 이미지를 설명하고 매칭되는 모델을 그려보지만, 이것은 내 머리 속에서 이해한 내용일 뿐 글을 읽는 다른 분들이 얼마나 쉽게 접근하고 있는지 살짝 걱정이 된다.  데이터 모델이라는 것이 눈으로 한번 읽어서 이해되는 분야가 아니다.  엔티티 하나를 보더라도 이건 뭐지?  왜 이런 거야? 그래서 어떻게 하라는 거야? 스스로에게 질문을 던지고 심도 깊게 빠져 들지 않으면 모델링 지식은 책 속에 만 있을 뿐 내 것이 되지 않는다.

 

매일 매일 조금씩 강해 지자

 

 

* 따뜻한 데이터 세상 만들기 - FROM 핫신 *
Tag :

Leave Comments