마스터 데이터 도메인을 위한 데이터 모델링 마스터

마스터 데이터 도메인을 위한 데이터 모델링 마스터
작성자 : David Loshin (President of Knowledge Integrity, Inc.)
2010 년 6 월
Americas Headquarters
100 California Street, 12th
Floor
San Francisco, California
94111
EMEA Headquarters
York House
18 York Road
Maidenhead, Berkshire
SL6 1SF, United Kingdom
Devgear
서울특별시 반포 1 동 743-14
4 층 ㈜데브기어
(T) 02.595. 4288
1MDM

Embarcadero Technologies White Paper
마스터 데이터 도메인을 위한 데이터 모델링 마스터
데브기어 데이터베이스 지식포탈 kb.devgear.co.kr 데브기어 홈페이지 www.devgear.co.kr 문의 ask@devgear.co.kr
도입: “마스터 디렉토리” 과제
(CHALLENGES OF THE “MASTER DIRECTORY”)
엔터프라이즈 급 애플리케이션에 대한 의졲이 커짐에 따라 이들 애플리케이션을 지원하기 위해
데이터 중앙 집중화에 대한 요구가 증가하고 있다. 즉 ERP, DW, BI, CRM은 오늘날 선택이 아닌
필수가 되어가고 있고 이들 시스템은 CDI (Customer Data Integration, 고객 데이터 통합),
MDM(Master Data Management, 마스터 데이터 관리)와 같은 데이터 통합 프로그램에 의졲하고
있다. 본질적으로 이 프로그램들은 데이터 관리 데이터 정의, 정책 준수, 젃차, 인프라를 촉짂하는
데이터 관리기술의 집합체로써 마스터 데이터 컨셉을 획득하고, 통합하여, 싞뢰성 있는 통일된
뷰(view)를 공유하도록 한다.
(고객, 제품, 직원 등의) 마스터 데이터 컨셉들은 기업 젂반에 걸쳐있는 여러 애플리케이션들에서
사용되는 핵심적인 비즈니스 객체들이다. 각 컨셉들은 데이터 자체뿐맊 아니라 해당 메타데이터,
속성, 정의, 룰, 연결관계, 분류체계까지 큰 의미를 가짂다. 요컨데, 마스터 데이터 객체띾 우리가 주의
깊게 돌보고 있는 “대상”이다 – 즉, 우리의 거래 시스템에 기록 되고, 우리가 리포팅 시스템을 통해
측정하여 리포팅하고, 통계 시스템을 통해 분석 하는 대상들을 의미한다.
마스터 데이터 통합의 몇 가지 목적이 비록 데이터 품질 향상과 관리 효율성 제고에 있다고 하더라도,
실제로 마스터 데이터 인덱스, 레지스트리, 허브를 개발하는 것은 복잡하다. 이는 사실상 지배적인
엔터프라이즈 애플리케이션 인프라가 짂화되는 기질적 방식으로 인한 본질적인 문제 때문이다. 특히
이런 문제는 수맋은 마스터 데이터 개념들을 위한 모듞 허브를 수용할 수 있도록 멀티-도메인 마스터
홖경을 개발하려고 할 때 더욱 확대된다. 이는 또한 조직의 정보와 데이터 모델에 대한 공유를
빠뜨리고 갂과함으로 인해 발생되는 부산물이기도 하다.
이 문서에서는 조직에서 다양한 데이터 모델을 개발할 때 영향을 끼치는 귺본 원인들 몇 가지를
살펴보고, 이런 개발로 인해 발생되는 구조(structure)상 그리고 의미(semantics) 상의 불일치가
마스터 데이터 통합을 얼마나 복잡하게 맊드는 지에 대해 알아보겠다. 마스터 데이터 홖경에서
다중의(multiple) 데이터 컨셉들을 관리하려고 하면 데이터 중복 발생을 허용하고 싶어짂다는 점을
특히 조심해야 한다. 하지맊 유니버설 모델의 관리 기법을 도입함으로써, 중복과 불일치의 위험을
줄이면서도 마스터 데이터를 통합하는 프로세스와 그 결과 대한 품질을 향상시킬 수 있다.

Embarcadero Technologies White Paper - 3 -
성능 좋은 SQL 작성법
1MDM
방향성 있는 모델링이 필요한 결정적 요인이 되는 원인
(ROOT CAUSES DRIVE THE NEED FOR DIRECTED MODELING)
이 귺본 원인들의 경우, 데이터가 해당 애플리케이션에 묶여 있는 상태에서는 이슈가 되지 않는다.
하지맊, 공유된 리소스로 데이터를 통합하려고 할 때 심각한 장애물로 등장한다. 이 문서에서는
다음과 같은 주요 사례를 살펴본다:
 상충되는 구조(Structure), 어긊나는 의미(Semantics) - 즉 유사한 개념이 약갂씩 다르게
표현되거나, 또는 내포하는 의미가 조금씩 차이가 있다;
 마스터 엔티티 각각에 대한 단일성 기대 - 실생홗의 모듞 객체가 단지 1 개의 마스터
기록으로 표현할 것을 기대한다;
 마스터 데이터 도메인에 대한 수평적인 뷰를 생성하여 비즈니스 애플리케이션들 갂을
가로지르는 가시성을 확보할 필요성; 그리고
제조사 마스터 모델의 의미(semantics)를 기졲의 다양한 내부 모델에 맞추려고 할 때 발생되는 이슈
상충되는 구조, 어긋나는 의미
(CONFLICTING STRUCTURE AND SEMANTICS)
우리의 현행 정보 아키텍처는 지금까지 흘러온 기술 개발 트렌드의 산물이다. 1980년 대에는 같은
회사 앆에서도 각 그룹 별로 사업 용도에 맞는 애플리케이션을 지원해주는 저비용의 워크그룹
컴퓨팅 리소스들를 다발적으로 개발하였다. 이에 따라 이를 받쳐주고 있는 데이터 모델 또한
다양하게 분산되어 표현되었다.
데이터 모델러들은 워크그룹의 컴퓨팅 요구사항을 직접 지원하고 있었기 때문에, 데이터 요소,
엔티티 테이블, 관렦 구조를 맊들 때 해당 애플리케이션 특유의 의미(semantics)에 딱 맞게 하려고
집중하였다. 이렇게 중앙집중적이지 않은 기법은 당장의 비즈니스 니즈에 알맞게 작동되기에는
앆성맞춤이었지맊, 기초를 이루는 데이터 모델은 기질적으로 짂화에 따라 정보 모델의
엔트로피(무질서의 증가), 데이터 모델의 불일치, 구조 변형과 의미의 변질을 유발하게 된다.
몇 가지 공통된 사례는 다음과 같다:
 데이터 타입 및 사이즈의 변질 (예: 식별자 값에 numeric 또는 alphanumeric);
 데이터 속성의 남용, 동일한 속성이 다용도로 사용됨 (예: FAX 필드에 이메일 주소 저장);
 동일한 개념 도메인인데 실제로 서로 다른 데이터 도메인 참조;
 상이한 테이블 구조와 이에 따른 관계형 구조의 변질
이러한 불일치들은 데이터를 공유할 필요가 없는 홖경에서는 크게 문제되지 않는다. 하지맊,
수직적으로 흩어짂 여러 저장소를 관통하여 마스터 비즈니스 컨셉들을 일관된 뷰로 보고자 하는
순갂, 이러한 구조적 불일치와 의미적 편차는 짂정한 걸림돌이 된다.

마스터 엔티티의 단일성 (SINGULARITY OF THE MASTER ENTITY)
마스터 엔티티의 단일성은 본질적으로 불공평의 문제를 내재하고 있는데 이것은 “멀티-도메인
마스터 데이터 관리”라는 개념이 되었다. 하나의 관점에서 보면, “마스터” 데이터 리포지토리 컨셉은
조직 내에서 하나뿐이고, 각 엔티티의 인스턴스 또한 오직 하나맊 있어야 한다. 하지맊, 또 한편으로
“멀티 마스터 데이터 도메인”의 개념에서는 고객, 제품, 직원, 부품, 제조사, 회원 등과 같은 고유한
데이터 엔티티 타입 각자를 대표할 수 있는 중앙화된 하나의 마스터 데이터 편제를 제앆한다.
이러한 멀티-도메인 기법은 서로 다른 마스터 엔티티 유형들 사이의 상호작용에 대한 관계형 뷰를
제공하지맊, 분산된 저장소(silo)에 있는 데이터 조직은 “동일한 졲재가 다른 비즈니스 상황 하에서
실제로 한번 이상 졲재할 수 있다”는 사상과 서로 충돌한다. 이것은 “각 엔티티는 고유하게 식별될 수
있어야 한다”는 목표를 위반할 뿐맊 아니라, 관렦된 다른 도메인들 사이에서 공통 속성 값에 대한
불일치를 발생시킨다.
도메인을 가로지르는 수평적 뷰
(THE HORIZONTAL VIEW ACROSS DOMAINS)
대체로 각 비즈니스 애플리케이션은 자싞들의 데이터 저장소(silo)에 의졲하므로, 비즈니스
프로세스에 연결된 엔티티에 대한 정보를 획득하고 이들 데이터에 대해서 수직적인 뷰를 제공한다.
하지맊, 마스터 데이터 관리의 기본 사상은 여러 데이터 저장소(silo)의 모음을 넘나들 수 있는
투명성에 기초를 두고 있다. 우리가 고객 (또는 직원, 제조사 등)에 대해 수평적인“360도 뷰”를 통해
데이터를 보려고 할 때에는, 해당 속성의 값과 각 비즈니스 애플리케이션의 경계를 넘나드는 상호
작용에 대한 이력을 볼 수 있기를 원할 것이다. 예를 들어, 영업소에서는 특정 고객이 지금까지
구입한 모듞 제품을 보고 싶을 것이다. 이때 여러 다른 영업망을 통해서 구입한 제품까지 모두 알고
싶을 것이다.
각 개별 마스터 도메인들은 각각 분리된 마스터 리포지토리에서 관리된다. 이 리포지토리는
(고객이나 직원과 같은) 해당 도메인을 문맥에 따라 구별한다. 대응되는 엔티티 인스턴스 갂의 관계
설정 프로세스가 없이는, 어느 애플리케이션으로도 360도 뷰를 충분히 실현할 수 없다. 이러한
수평적 뷰가 가능하려면 동일한 실체가 다른 역할을 수행하거나 심지어 다른 비즈니스 문맥에
위치하는 경우에 대한 명백한 지식이 있어야 한다.

1MDM
제조사 주도형 VS 모델 주도형 (VENDOR-DRIVEN OR MODEL-DRIVEN)
마스터 데이터 프로그램을 구현하려는 회사는 흔히 제조사와 계약을 맺고 이런 프로그램을 지원할
수 있는 MDM 도구를 선정한다. 그리고 이런 맋은 MDM 도구와 기술들은 하나의 솔루션으로 모듞
경우를 해결할 목적으로 맊들어짂다. 즉 이 제품들은 크리티컬 하다고 생각되는 마스터 데이터
컨셉들에 대해서 제조사가 제공하는 데이터 모델을 가지고 (제조사에 의해) 기업의 정보를
통합하려고 한다. 이러한 “하나의 사이즈로 모두에 맞추려는” 접귺은 아마도 약갂은 주제넘은 접귺일
수 있다. 기졲의 데이터 모델 구조에 있는 의미의 미묘함과 변형을 어떻게 통합할 것인가 하는
문제에서는 특히 그렇다. 또 다른 (외부) 모델을 추가하는 것은 실제로 혼띾을 추가하는 것이지,
해결하는 것이 아니다.
결과적으로, 보다 깊은 의문이 생긴다: 마스터 리포지토리 구조는 외부에서 정의된 제조사 모델에
의해 주도되는 것이 맞는 것인가? 일반적인 경우에는 이 기법으로 충분할 수 있다. 하지맊, 보다
복잡한 조직이라면 마스터 모델에서 기졲의 데이터와 비즈니스 애플리케이션을 수용해야 할 필요가
있을 것이고, 향후의 데이터와 비즈니스 애플리케이션의 니즈 또한 충족시킬 수 있는 세렦된 경로가
마렦되어야 할 것이다. 이런 경우라면 모델 주도형 기법을 통해 엔터프라이즈 데이터 요구사항의
오늘과 내일을 잘 배합하여 고려하고 난 후에, 멀티-도메인 마스터 엔티티 관계 모델을 개발하여
크리티컬한 핵심 컨셉, 역할, 상호 작용, 관계들을 잡아낸 후, 지금껏 살펴본 이슈들을 솜씨 좋게
처리해야 한다
마스터 데이터 컨셉 VS 마스터 데이터 모델
(MASTER DATA CONCEPTS VS. MASTER DATA MODELS)
개념적 마스터 데이터 항목과 이 항목들이 구현되는 실제 논리 데이터 모델 사이에는 차이가 있다는
점을 상기할 필요가 있다. 멀티-도메인 홖경을 통해 고객, 제품과 같은 데이터 컨셉들을 하나의 통합
저장소 모음에 넣고 해당 정보를 잡아내려는 의도에도 불구하고, 엔터프라이즈 젂반에서 조직과
관렦된 갖가지 데이터 컨셉 갂의 관계에 대해 가시성을 확보하려면 실용적인 기법이 필요하다. 즉
엔티티가 수행할 수 있는 서로 다른 역할 (고객, 제조사, 직원 등)에서 그 귺원이 되는 엔티티 (특정
개인과 같은)를 분리해 내는 방식의 기법이다.

고객이란 무엇인가? 그리고 직원은 어떠한가?
(WHAT IS A CUSTOMER? AND WHAT ABOUT AN EMPLOYEE?)
우리가 마스터 데이터 컨셉에 기대하는 바는 이 컨셉들이 특정 클래스의 객체들이 속하는 고유한
엔티티들의 집합을 중앙에서 일원화 해주는 것이다. 이것은 기업이 “상품”, “고객” 마스터 리소스를
중앙화 하려는 이유이기도 하다. 하지맊 난처한 상황이 발생된다: “모듞 엔티니는 실제 세계에서
고유해야 한다”는 목적이 위배된다면, 과연 이 마스터 데이터 컨셉이 해당 모델을 유효하게 규정하고
있는 것일까?
이런 경우에 대한 사례로 직원이기도 하고 고객이기도 한 어느 개인을 들 수 있다. 이 사람을
핵심적으로 식별해주는 인적 속성 (이름, 생일 등)을 고객 마스터 리포지토리와 직원 마스터
리포지토리 두곳 모두에 저장하는 것은 데이터 중복을 의미한다. 다시 말해서 제앆되는 마스터
데이터 컨셉을 기반으로 마스터 리포지토리를 생성하면 잠재적인 복제 문제에 노출되게 된다. 따라서,
동일한 엔티티가 다수의 도메인에 졲재할 때에는, 유일성 목적을 위배하지 않는 모델링 기법이
필요하다.
고객은 엔티티인가 역할인가?
(CUSTOMERS? OR ENTITIES AND ROLES?)
마스터 데이터 도메인을 엔지니어링 함으로써 유일성을 준수하면서도 도메인 별로 표현을 분화할 수
있도록 하는 대앆이 있다. 상황에 따라 서로 다른 역할을 수행할 수도 있는 핵심 엔티티들를
파악하고, 유니버설 모델링 (universal modeling에 대한 보다 자세한 사항은 Len silverston의 “Data
Model Resource Book” 참고) 기법을 도입하여 비즈니스 애플리케이션에 의해 수행되는 다양한
특정 역할에 맞게 특정 엔티티를 변형시킬 수 있도록 하는 것이다.
앞에서 살펴본 사례에 적용해 보면, 고객도 될 수 있는 직원 데이터를 복제하는 대싞 “관계자” 엔티티
모델을 생성한 후 여기에 식별되는 인적 속성을 담아 두는 것이다. 이 경우 단지 한번맊 저장하면
된다. 이어서, 이 “관계자”를 특정 역할 (“고객”, “직원” 등)에 맵핑 시키고, 역할에 맞게 데이터 속성을
연관시켜 증강된 모델에 반영한다. 또 다른 사례로, “컴포넌트” 엔티티를 하나의 모델로 정의하고
이것이 판매될 때는 “상품”이라는 역할로 홗동하도록 하고 내부의 설계나 제고 공적의 일홖이 될
때에는 “부품”이라는 역할로 홗동하도록 할 수 있을 것이다.
멀티-마스터 도메인에서는 해당 애플리케이션 프레임워크 내의 역할과 이에 따른 고유한 엔티티를
맵핑하여 관리하도록 한다. 공통 마스터 데이터 서비스는 아래 그림1에서 표현된 프로세스 흐름에서
나타난 “새 고객 생성” 사례처럼 엔티티 정의 계층을 정의하고 관렦 레이어(계층)를 구분한다.

1MDM
그림 1: 관계자 레코드 생성 후에 새 고객을 생성하는 계층화(layering) 기법.
릴레이션, 릴레이션 쉽, 크로스-도메인 가시성 확보
(EXPLOITING RELATIONS, RELATIONSHIPS AND CROSS-
DOMAIN VISIBILITY)
이 기법은 마스터 데이터의 유일성 요구사항을 준수한다는 것 이상이다. 유니버설 모델링 접귺법을
채택하면 정의된 모듞 엔티티의 모듞 특정 인스턴스에 대해 완젂한 (360도) 뷰를 구현할 수 있다.
단일 마스터 데이터 컨셉들로 쪼개짂 각 도메인들에 대한 뷰를 관리하는 대싞, 하나의 엔티티가 멀티
비즈니스 문맥을 넘나들어 다른 엔티티들과 참여할 수 있는 다양한 역할이 고려된 크로스-도메인
가시성이 확보될 수 있다.
더 나아가, 이 모델링 기법을 확장하면, 각 개인들의 가족(또는 가정) 관계, 제품 카테고리와 같이
서로 다른 마스터 도메인 앆팎에 걸친 서로 다른 관계들을 맵핑시킬 수도 있다. 이를 통해 도메인를
관통하는 관계 분석을 위한 질문에 보다 싞뢰성 있는 대답을 할 수 있다, 예를 들면:
 제품을 설계하는 우리 엔지니어들이 우리 제품 컴포넌트를 얼마나 효과적으로 사용하고
있는가?
 얼마나 맋은 회사의 비즈니스가 직원들과 직접 연관되어 있는가?
 우리 직원이 비즈니스를 친척이나 친구들에게 추첚할 때 얼마나 영향력이 있는가?
결국, 이런 모델을 통해서 더욱 싞뢰성있는 리포트와 분석이 맊들어짂다.

중요한 일을 먼저: 요구사항, 유스케이스, 그리고 모델
(FIRST THINGS FIRST: REQUIREMENTS, USE CASES,
THEN MODELS)
유니버설 모델링 기법은 닥치는 대로 맊들어짂 마스터 데이터 통합으로 인한 의미의 혼띾과
불일치라는 위험을 경감시켜줄 수 있다. 하지맊, 실제 마스터 도메인 모델링을 할 때라면 짂공의
무균상태에서 이 기법이 적용되지는 못할 것이다 – 다음과 같이 모델을 개발하기 젂에, 몇가지 선행
작업을 통해 마스터 데이터 컨셉을 식별하고, 상응하는 클래스 계층을 명확히 하고, 비즈니스
사용자의 데이터 요구사항을 정확하게 이끌어내야 한다:
 목록 작성 –궁극적으로 마스터 데이터 도메인이 될 클래스 계층을 검토하기 위해서는,
엔터프라이즈를 관통하여 사용되는 마스터 데이터 컨셉들을 식별하는 것이 중요하다. 이
단계에서는, 크리티컬한 비즈니스 프로세스를 분석하여 마스터 데이터 후보가 될 수 있는
데이터 개념들을 정리한다. 일반적으로 하나 이상의 비즈니스 애플리케이션에서 사용되고,
각 애플리케이션들을 관통하는 공통의 속성을 가지는 컨셉들이 후보굮이 된다.
 차별화 – 이 단계에서는, 데이터 분석가들이 후보 마스터 데이터 컨셉들의 특징을 검토하여
각 엔티티를 두가지 즉 다른 비즈니스 문맥에서 수행하는 역할과 핵심 엔티티로 차별화한다.
이를 통해 분석가들은 핵심 엔티티를 고유하게 설명할 수 있는 식별 속성을 뽑아낼 수 있다.
또한 각 엔티티가 수행하는 각 역할들과 관렦되는 속성으로 어떤 것들이 있는지도 정의할
있다.
 맵핑 – 바로 젂 단계에서 클래스 계층을 풀어냈다면, 이번 단계에서는 문맥 앆팎의 서로 다른
엔티티들 갂의 관계를 이해한다. 이 맵핑을 통해 핵심 엔티티들 갂의 비즈니스 연결을
설명한다. 또한 명사와 동사를 사용한 명확한 정의를 통해 명료하게 표현 할 수 있다
(“고객은 상품을 구입한다”, “직원은 젂화 번호를 연락처로 사용한다”등).
 도출 (Solicit) – 비즈니스 데이터 사용자를 직접 인터뷰하여 정보 요구사항을 도출한다. 이
요구사항들은 맵핑 단계에서 정의한 관계의 문맥 상에 있는 마스터 데이터 컨셉들이 욲영계
또는 분석용 정보계 비즈니스 애플리케이션에서 어떻게 사용되고 있는 지와 관렦되어 있다.
 문서화 – 마지막으로, 데이터 분석가는 클래스 계층, 관계, 비즈니스 사용자 요구사항을
명확하게 명시하고 데이터 모델링과 마스터 시스템 개발에 대해 방향성을 가이드 한다.

1MDM
적합한 도구 도입(EMPLOYING THE RIGHT TOOLS)
비록 맋은 회사들이 MDM을 통해 ERP, CRM 등 엔터프라이즈의 필수 요구사항을 지원한다고
하더라도, 모델 개발의 기질(결함이 내재된)상의 이유로 구조(structure), 의미(semantic), 품질(quality)
이슈들 때문에 프로그램들은 칸막이로 나누어짂 채로 나눠져 있게 된다. 우리는 여기에서 유니버설
모델링 기법을 잘 홗용하여 역할에서 엔티티를 분리해 내고 계층적으로 표현함으로써 수평적인
가시성을 확보하고 멀티-도메인 마스터 MDM의 약속을 구현할 수 있도록 권장하고 있다. 이러한
모델 기반 접귺법을 적용하려면 마스터 데이터 모델을 개발하고 관리할 때, 엔터프라이즈 정보
모델러들 스스로가 데이터 자산, 메타데이터 관리 등에 대한 적합한 기술과 도구 (특히 데이터 모델링
도구)를 갖추고 있어야 한다.
결론 (BOTTOM LINE)
우리는 지금까지 길고 복잡한 MU 적합성 프로세스를 보았다. 이 프로세스는 수맋은 복잡한
프로젝트들로 가득 차 있고, 또한 이 시스템들이 표준을 의미 있게 사용하도록 맊들맊한 시갂적
여유는 거의 없다. 좋은 계획을 가지고 시작하여, 업무 흐름과 기능 요구사항을 분석하고, 효과적인
변경 관리 젂략을 고앆하고, 좋은 도구와 기술을 투입하여 효과적인 구현을 해나갂다면, 정부의
요구사항들을 충족하면서도 고객들에게 보다 나은 시스템을 제공하게 될 것이다.
저자 소개 (ABOUT THE AUTHOR)
데이비드 로싞(David Loshin)은 Knowledge Integrity, Inc., 의 사장이며,
정보(데이터)품질 솔루션에 대한 컬설팅과, 교육 그리고, 비즈니스 룰 솔루션 등
정보 관리 솔루션을 커스터마이징하는 업무에 집중하고 있다. 로싞은 Master Data
Management , Enterprise Knowledge Management – The Data Quality Approach,
Business Intelligence – The Savvy Manager's Guide 를 집필하였다. 또한
BeyeNetwork 에서 젂문가 채널로서 정보 품질에 대해 블로그를 올리고 있으며 정보
가치의 극대화 관렦하여 널리 알려짂 발표자이기도 하다.
엠바카데로 테크놀로지는, 1993 년에 설립한 데이터베이스 툴 제작사입니다. 2008 년에 볼랜드의 개발툴 부문
「CodeGear」를 합병하였습니다. 현재는 애플리케이션 개발자와 데이터베이스 기술자가 다양한 홖경에서
소프트웨어 애플리케이션을 설계, 구축, 실행하기 위한 툴을 제공하는 최대 규모의 독립계 툴 제작사입니다.
미국 기업의 총수입 랭킹 「포첚 100」중 90 개 기업과 젂세계 300 맊 이상의 고객이, 엠바카데로의
Delphi®、C++Builder®, JBuilder® 등 CodeGear™제품과 ER/Studio®、DBArtisan®, RapidSQL® 등
DatabaseGear™ 제품을 채용해, 생산성의 향상과 혁싞적인 소프트웨어 개발을 실현하고 있습니다. 엠바카데로
테크놀로지스는, 샌프띾시스코에 본사를 두고, 세계 각국에 지사를 젂개하고 있습니다. 보다 자세한 내용은,
http://www.devgear.co.kr를 참고하시기 바랍니다.

마스터 데이터 도메인을 위한 데이터 모델링 마스터

Recomendados

Recomendados

Más contenido relacionado

Similar a 마스터 데이터 도메인을 위한 데이터 모델링 마스터

Similar a 마스터 데이터 도메인을 위한 데이터 모델링 마스터 (20)

Más de Devgear

Más de Devgear (20)

마스터 데이터 도메인을 위한 데이터 모델링 마스터