1

2

목차

소개 ............................................................................................................................................................................... 3

THE TOP 10 .............................................................................................................................................................. 7

진정한 멀티레벨 서브모델 ............................................................................................................................. 7

진정한 논리/물리 모델 분리 ...................................................................................................................... 12

리버스 엔지니어링 .......................................................................................................................................... 17

메타데이터 확장............................................................................................................................................... 19

표준 명명 ............................................................................................................................................................ 23

비교 및 병합(COMPARE AND MERGE)............................................................................................... 27

매크로(Macros) ................................................................................................................................................ 30

유니버설 맵핑(UNIVERSAL MAPPINGS) ............................................................................................. 32

빅데이터에 대한 네이티브 지원 .............................................................................................................. 34

리파지토리, 게시 & 협업 ............................................................................................................................ 35

추가 고려사항 ........................................................................................................................................................ 38

데이터 리니지(DATA LINEAGE) ............................................................................................................... 38

결론 ............................................................................................................................................................................ 40

3

소개

ERwin에서 ER/Studio로 툴을 변경할지 고민 중인가? 또는 Erwin과 ER/Studio 중 무엇을 사용할

지 고민 중인가? 그렇다면 아마 당신은 아래와 같은 질문을 갖고 있을 것이다:

가장 중요한 주요 기능은 무엇인가?

둘 중 어느 툴이 더 좋으며 이유는 무엇인가?

생산성을 올리기 위해 얼마만큼의 시간이 필요한가?

둘 중 어느 툴이 더 혁신적인 패턴을 보여주고 있나?

둘 중 최고의 장기 투자 제품은 무엇인가?

나 또한 몇 년 전, 이러한 고민을 거쳐 툴을 결정했다. 나의 경험이 당신에게 도움이 됐으면 한다.

나는 우선 당신에게 나의 이야기를 하여 내가 겪었던 상황을 이해시킬 것이다:

나는 30년 넘게 IT 분야에서 일을 했다. 사실상 이 30년이 넘는 시간은 정보 기술의 혁명적인 변

화의 시간으로 모든 비즈니스 측면과 우리의 일상 생활을 발전시킨 시간이었다. 데이터의 중요성

이 증가함과 동시에 데이터의 양도 무수히 늘어났다. 현재로서 정보는 그 어느 때보다 더 메타데

이터 그 자체로서 전략적인 자원이다.

나는 제조회사에서 일을 시작했고 이후 두 개의 다른 컨설팅회사에서 일을 했으며, 그 후 독립적

인 컨설턴트로 20년을 일했다. 나는 데이터 모델링과 아키텍처, 비즈니스 모델링, 비즈니스 변환,

컴퓨터 지원 소프트웨어 엔지니어링, 프로젝트 관리, 엔터프라이즈 아키텍처 및 전략에 초점을 맞

춘 기술 플랫폼과 다양한 산업에 대한 경력을 쌓았다. 나는 나의 컨설팅 관점을 기준으로 이 글

을 썼다. 나는 엠바카데로 제품의 품질과 회사의 혁신에 대한 의지를 보고, 엠바카데로 테크놀로

지라는 회사에 이번 년도 6월에 합류했다.

데이터 모델링은 기업의 애플리케이션의 근본인 데이터베이스를 설계, 구축, 그리고 구현하기 위

한 방법 중 한가지이다. 데이터 모델링 툴이 상업적으로 사용되기 전, 나는 화이트보드와 포스트

잇을 사용하여 데이터 모델링을 시작했고 이후에는 다양한 기술과 툴을 사용해왔다. 그때부터 나

는 모델링 & 아키텍처 도구들을 많이 사용해왔으며, 뿐만 아니라 Silverrun에 데이터와 프로세스

를 입력하기 위해 설계 및 개발용 리버스 엔지니어링 브릿지도 사용해왔다.

나의 고객 중 많은 고객들이 ERwin을 사용했었다. 몇몇의 고객들은 ERwin을 이미 가지고 있었고,

그 외의 경우에는 나의 추천에 따라 ERwin을 구입했었다. 나는 ERwin이 Logicworks에 의해 발표

된 처음 릴리즈 버전부터 1998년에 짧은 기간 Platinum Technologies에 있었을 때, 그리고 그 이

후 1999년 Computer Associates에 의해 인수될 때까지 ERwin에 대한 많은 사용 경험이 있다. 나

는 꽤 오랫동안이나 ERwin을 강하게 지지했었다. 나는 ERwin의 4.x 버전과 7.x 버전을 많이 사용

4

했다(일반적으로 버전을 나타내는 숫자 앞에 "r"을 소문자로 표시한다). 나는 아직도 5와 6버전이

왜 건너뛰어졌는지 이유를 모른다.

언제나 ERwin의 새로운 버전이 언제 출시될 지는 예측할 수 없었다. 언제 나올지 모르는 새로운

버전을 기다리는 동안, 나는 언제나 ERwin이 기존의 데이터베이스에 대한 기본적인 리버스 엔지

니어링뿐만 아니라 여러 다양한 개발 프로젝트의 설계와 DDL 생성을 위한 유용하고 사용 가능한

데이터모델링 툴이기를 바랬다. 그러나 나는 항상 이 툴이 주요 사업에 대한 협업 및 커뮤니케이

션 관점에서 부족하다고 느꼈다.

ERwin r8의 트라이얼 버전을 처음 봤을 때, 나는 퇴행적이라고 느꼈다. 사용자 인터페이스는 완전

히 개편되었지만, 비즈니스 프로세스 모델링과 같은 몇 가지 주요한 내부 기능은 사라졌다. 이 사

건이 내가 다른 툴을 찾게 된 원인이 되었다.

진행하던 업무를 마무리 짓고 넘어간 다음 단계는 복잡한 상황이었다. 고객사는 인수합병이 있었

으며, 각각의 기업은 해당 기업의 시스템과 애플리케이션에 대한 무수한 결과, 데이터베이스 그리

고 point-to-point 인터페이스를 갖고 있었다. 이 것은 풀어야 하는 복잡한 거미줄이 되었다. 기업

은 엔터프라이즈 아키텍처를 수립해야 하는 초기 단계에 있었으나, 기업은 데이터 및 비즈니스

아키텍처가 아닌 주요 기술 아키텍처에 초점이 맞추어져 있었다. 나는 이 일을 빨리 해결해야 했

다.

나는 고객뿐만 아니라 복잡한 데이터 범위에 대해 계획하고 이해하고 커뮤니케이션하기 위해 나

에게도 더 강력하고, 확장이 가능한 포괄적인 데이터 아키텍처 툴이 필요하다는 것을 알고 있었

다. 나는 또한 조직이 데이터를 이해하고 프로세스에 영향을 주는 데이터를 이해하기 위한 비즈

니스 프로세스 모델링을 통합하는 기능이 필요했다. 나의 고객들은 보통 ERwin Process Modeler

(ERwin Data Modeler와는 또 다른 구성 제품)를 구입하지 않았기 때문에, 나는 일반적으로 비즈니

스 프로세스 모델링을 하기 위해 다른 툴들을 사용했다. 또한 Process Modeler는 ERwin r8에 포

함되어 있지 않았으므로, 향후 출시되는 다른 버전에도 통합된 프로세스 모델링은 더 이상 제품

에 포함되지 않을 것이라 판단했다.

컨설턴트로서, 나는 한 번도 도전을 주저한 적이 없다. 그러나 나는 짧은 기간 안에 눈에 보이는

성과를 낼 수 있다는 확신이 필요했다. 사실 철저하게 무언가를 추구하고 준비하고, 어떻게 구조

화를 시키던지 간에 이런 노력과 준비와는 상관없이 중요한 것을 빠트릴 것만 같은 기본적인 두

려움은 언제나 있다.

다른 다양한 툴들을 사용해보지 않은 사람들과 ERwin만 사용했던 사람들이 변화에 대한 두려움

이 더욱 크다는 것을 이해한다. 사람의 본성은 종종 우리에게 익숙하고 친숙한 것을 사용함으로

써 우리를 편안한 상태에 안주하게 만든다. 나는 나의 전문지식을 믿고 의지하는 조직들에게 쉽

게 ERwin을 구입하고 사용하는 것을 납득시켰었다. 그러나, 다른 대체 툴을 찾게 만든 ERwin의

단점들을 우려하고 있다.

5

여러 데이터모델링 툴을 찾아보면서, 나는 모든 일반 엔터프라이즈 아키텍처 툴은 적절한 데이터

아키텍처 기능을 갖고 있지 않다고 판단했다. 데이터베이스 벤더의 OEM 툴은 좋은 기능을 갖고

있었지만, 공급 업체 자체의 플랫폼을 선호하는 경향이 있었으며 엔터프라이즈 데이터 아키텍처

관점에서는 조금 부족했다. 많은 툴들이 비즈니스와 프로세스 모델링 기능을 갖고 있지 않았다.

Embarcadero의 ER/Studio는 ERwin의 비교 툴로 빠르게 등장했다. 나는 툴 비교 시 ERwin을 기준

툴로 여겼다. 나는 ER/Studio를 내가 사용할 툴로 정할지를 결정하기 위해 ERwin과 비교하여

ER/Studio의 기능을 명백하게 알아야 했다.

ER/Studio와 ERwin을 비교하여 선택해야 하는 상황이 이번이 처음은 아니었다. 나는 ER/Studio가

처음 툴 시장에 나타났을 때부터, 나는 ER/Studio를 알고 있었다. 나는 90년 후반에 프로젝트를

위해 ER/Studio를 평가했었고 평가도 좋았다. 그러나 그 시점에 고객의 주요 플랫폼이었던

AS/400을 ERwin이 더 좋은 지원을 제공하고 있다고 판단하여 ERwin을 사용했었다.

툴을 평가할 때의 나의 기준을 간결하게 요약하면-모든 주요 기능들은 내가 사용했던 ERwin 7.3

보다 좋아야 했다. 평가하는 동안, 나는 또한 각각의 주요 기능들을 수행하기 위해 무엇을 했는지

에 초점을 맞췄다. 툴들은 각각의 툴들의 기본 설계에 뿌리를 두고 작업을 수행하기 때문에, 약간

씩 다른 기술 용어와 기술을 사용한다. 언뜻 보기에는 우리가 익숙해져 있는 툴과 다른 방식으로

작동이 되기 때문에 특정 기술을 간단하게 기각시키기 쉬웠다. 그러나 이 것은 우리가 과거에 사

용했던 툴보다 더 우수하거나 동등하지 않은 것을 의미하는 건 아니다. 나는 이코노미 자동차에

서 럭셔리 자동차로 업그래이드 하는 것과 ERwin에서 ER/Studio로 마이그래이션 하는 것을 비교

해보았다. 기본 조작 방법은 동일했고 몇 몇의 컨트롤의 위치는 달랐다. 그러나 전반적으로 품질

과 성능 면에서는 큰 향상이 있었다.

평가를 할 때, 나는 ER/Studio가 ERwin과 다르게 작동하는 것을 찾아냈다. 그러나 대부분은 좋은

이유에서 다르게 작동하였다. 평가하는 동안, 내가 가지고 있던 모든 두려움 또는 걱정은 사라졌

다. 나는 ER/Studio가 매우 직관적이고 사용하기 쉬울 뿐만 아니라 매우 기능이 많고 강력한 툴이

라는 것을 알았다. 나는 바로 ER/Studio를 선택하고 사용할 수 있었다. 그리고 많은 작업에 대해

생산성이 높아졌다. 나는 또한 ERwin에서는 하지 못했던 많은 기능들을 ER/Studio에서는 내 마음

대로 사용할 수 있었다.

명백하게 툴을 변경할 때에는, 많은 고려사항이 있다. 선택에 있어서 고려해야 하는 10가지 주요

기능들을 요약해서 말하겠다. 내가 나열하는 순서는 논리 흐름으로 나열한 것이지 중요한 기능

순서로 나열한 것이 아니다. 각각의 기능의 중요도는 조직에 따라 달라질 것이다.

각각의 기능들에 대한 나의 요약은 다음 사항을 포함한다:

이 기능은 무엇인가?

왜 중요한가?

6

툴들은 이 기능에 대한 접근방식에 어떤 차이가 있는가?

이 기능에 어떤 툴이 적합한가?

명시되지는 않았지만, 비교 기준은 ERwin r7.3과 ER/Studio XE6 Enterprise Team 에디션이다. 해당

버전을 선택한 주요 이유는 다음과 같다:

ERwin r7.3은 수 많은 고객 환경에서 내가 사용했던 툴이므로, 나에게 있어서는 기준이

다.

많은 조직들은 ERwin r7.3에서 다음 버전으로의 업그레이드를 진행하지 않는다. 일부

회사의 경우에는, 최신 버전으로의 어려운 업그레이드가 ERwin r7.3 버전을 계속 사용하

기로 선택한 이유 중 하나일 수 있다.

이제부터 ERwin과 ER/Studio 각각에서 주로 사용되는 기본 설계와 상대적인 접근법을 기준으로

주요 기능을 말하겠다. 지난 몇 년간, 두 툴 모두 버전이 변하고 있지만 각각의 툴은 그들의 기본

설계는 일관성 있게 유지되고 있다.

만약 ER/Studio를 사용해 본 적이 없다면, ER/Studio가 지원하는 기능을 보고 놀랄 것이다. 이 문

서를 읽어보면서 ERwin과 비교해보고 주요 기능들을 배워보기 바란다.

7

THE TOP 10

진정한 멀티레벨 서브모델

서브모델이란 무엇인가?

서브모델은 모델링되거나 설계되어지는 범위에 포함되는 업무영역 또는 주제영역을 나눠놓은 것

이다. 일반적으로 서브모델을 생성하는 기준 중 가장 의미 있고 안정된 기준은 업무 분리를 기준

으로 서브모델을 만드는 것이다. 예를 들어, 회계라는 광범위한 범위를 미수금, 지급 계정, 총계정

원장, 급여 등의 하위레벨 서브모델로 분리할 수 있다.

모든 성공적인 서브모델 구조(분리)의 핵심은 업무와 연관이 있는 용어와 정의를 확실하게 하고

상위 레벨에서 봤을 때 한눈에 이해가 되어야 하는 것이다. 모델링 된 업무의 깊이와 복잡성은

서브모델 계층의 폭과 깊이를 좌우한다.

ER/Studio vs ERwin, 서브모델로의 접근 방식에 어떤 차이가 있나?

이 전에 설명했던 것처럼, 툴들은 같은 컨셉에 대해 사용하는 용어들이 서로 약간씩 다를 수 있

다. ERwin은 주제영역(subject area)이라는 컨셉을 사용하여 같은 통합된 영역 안에서 데이터 모델

을 분리한다. ER/Studio는 모델을 분리하는 것을 서브모델이라는 용어를 사용한다. 단지 서로 사

용하는 용어만 다를 뿐이다.

이 경우, 두 툴의 접근 방식을 예제를 사용하여 대조하는 것이 최고의 방법이다. 아래에 나오는

그림은 주요 공급 체인 사업에 대한 서브모델 구조를 보여준다.

8

여기서 사용된 구조는 여러 서브모델 안에 또 다른 여러 개의 서브모델이 중첩된 진정한 계층 구

조이다. 이 구조는 계층 안에서 주어진 서브모델이 어디에 존재하는지 정확하게 볼 수 있는 구조

이다. 따라서, ER/Studio는 작업에 대해 순서화 되어있고 구조화 되어있는 조직을 허용하는 업무

분해 패러다임을 따른다. 서브모델과 중첩된 서브모델은 데이터모델의 크고 복잡한 뷰를 분해하

기에 효율적이다. 데이터 분해는 필요에 따라 특정 분야에 초점을 맞출 수 있다. 구조로 보면 각

각의 서브모델은 메인 모델 아래에서 메인 모델에 연결되어 있다. 각각의 서브모델은 레이아웃,

컬러, 디스플레이 설정, 표기법 등 독립된 디스플레이를 가질 수 있다. 서브모델 안에서의 모든

오브젝트 변경사항(엔터티, 속성, 관계, 테이블, 컬럼, 외래키, 프로시저, 함수 등)은 자동적으로 연

관된 메인 모델에 반영된다. 변경사항은 계층구조 상 상위 서브모델에도 자동 반영되며, 이 패턴

은 가장 일반적으로 사용되는 패턴이다.

9

그러나, 자동 반영을 원하지 않을 때는, 자동 반영을 안 시킬 수도 있다. 변경사항은 항상 계층

구조의 최상위(메인 모델 뷰)까지 반영되기 때문에, 변경사항에 대한 반영 손실은 없다. 각각의 특

정 엔터티(또는 테이블)에 대해, ERwin Modeler는 서로 다른 서브모델 안에서 어떤 속성들(또는

컬럼), 그리고 관계까지 표기할지를 명시적으로 선택할 수 있다. 이 기능은 궁극적인 유연성을 제

공한다. 그렇기 때문에, 모델을 사용하는 작업자는 관련 없는 상세 내용을 제외한 자기가 보고 싶

은 내용만 볼 수 있다.

서브모델 계층구조를 사용하면, 모델 탐색은 극단적으로 간단해진다. 아래의 ER/Studio 화면 사진

을 보면, 공간이 많이 줄어든 것을 볼 수 있다. 아래의 사진은 모델의 원하는 부분만 보여주면서

얼마나 공간을 축소할 수 있는 지를 보여준다. 이 사진은 논리모델이며 오직 상위 서브모델만 보

여주고 있다. 아래의 사진에서는 볼 수 없지만 물리모델 또한 축소되어있다.

다음 ER/Studio 화면 사진은 서브모델 또는 중첩된 하위 서브모델 안에 존재하는 오브젝트가 유

형별로 나누어져 있는 트리구조로 되어있으며, 하나 또는 그 이상의 서브모델을 확장할 수 있다

는 것을 보여준다.

10

사진에서도 볼 수 있듯이, ER/Studio의 서브모델 기능은 엄청나게 크고 복잡한 모델을 쉽게 정리

하고 관리할 수 있는 기능의 최고수준이다.

아래의 사진은 ERwin 7.3에서 볼 수 있는 정보 유형의 개념적인 목업이다. ER/Studio와는 시각적

으로 상당히 다른 패러다임을 산출해낸다. 아래 사진의 모델은 주제영역(subject area)에 대한 오

브젝트 목록이 보여지고 있으며 해당 목록은 각각의 주제영역 안의 오브젝트의 목록만을 볼 수

있게 확장이 된다.

11

모든 주제영역은 메인 모델(ERwin의 용어로는 메인 주제영역)에 포함되어 있다. 각각의 주제영역

은 레이아웃, 컬러, 디스플레이 설정, 표기법 등 디스플레이 특징을 독립적으로 설정할 수 있다.

주제영역 안의 모든 오브젝트(엔터티, 속성, 관계, 테이블, 컬럼, 외래키, 프로시저, 함수 등) 변경

사항은 메인 주제영역에 반영된다. 그러나 모델 복잡성을 측정하기 위해 필요한 오브젝트 개수는

표시되지 않는다.

여기서 볼 수 있듯이, ERwin은 업무 분해 또는 진정한 계층 구조를 표현하는 기능은 없다. 이 기

능이 없으면 큰 모델에서는 골칫거리가 되며 이 기능이 가장 필요하다. 내가 ERwin을 사용했을

때, 나는 나의 ERwin 주제영역 이름 앞쪽에 숫자를 달아서 주제영역 이름을 정했다. 그렇게 함으

로써 작업을 의미 있는 방식으로, 적어도 순서대로 주제영역을 분해하는 구조를 가졌다. 그러나,

이 방법은 작업의 분해와 상세의 진정한 레벨을 보여주는 서브모델 중첩 방법이 아니다.

어느 툴이 이 기능에 더 적합할까?

이 영역에서는, 전체적인 기능과 전체적인 모델 관리를 봤을 때, ER/Studio가 명백하게 ERwin보다

앞서있다. 기능 차이는 복잡성 관리와 해결에 대한 철학을 기반으로 만들어진 ER/Studio의 기본

설계에 있다.

12

진정한 논리/물리 모델 분리

논리모델 vs 물리모델?

데이터 관리 방법론에서 말하는 데이터 모델이란 연관된 모든 프로세스와는 독립적으로 실 세계

의 오브젝트를 설명하는 데이터와 오브젝트 간의 관계를 표현하기 위한 것이다. 일반적으로 활용

되어 지는 데이터 모델링의 3 단계가 있다. 추상적인 순서로:

개념 모델

논리 모델

물리 모델

일반적으로, 개념 모델은 꽤 추상적이며, 엔터티와 엔터티들 간의 비즈니스 관계만 나타낸다. 개

념 모델은 일반적으로 속성을 다 찾지 않으며 정규화를 하지 않는다.

논리 모델 또한 비즈니스 측면에서 더 상세화된 관점을 나타낸다. 그러나 일반적으로 논리모델은

속성이 완벽하게 추출되어져 있으며 완벽하게 정규화가 되어있다. 논리 모델은 플랫폼에는 완벽

하게 독립적이다.

물리 모델은 특정 물리 DBMS 플랫폼에 데이터베이스로 구현되기 위해 모든 테이블, 컬럼, 제약

사항, 인덱스 등을 포함하고 있다. 물리 모델은 구현 플랫폼에 맞는 물리적 명명과 데이터 타입을

활용한다.

대부분의 방법론 및 엔터프라이즈 아키텍처 프래임워크에서 데이터모델은 일반적으로 아래와 같

은 추가적인 내용에 의해 증가된다:

가치사슬분석, 데이터 모델 오브젝트와 연결되는 것들:

특정 비즈니스 프로세스

애플리케이션

프로젝트

목표

조직

각각의 주요 엔터티에 대한 상태의 변화를 통합시키는 모델링의 라이프 사이클

ER/Studio vs ERwin, 논리 모델과 물리 모델에 대한 접근 방식은 어떻게 다를까?

13

ERwin과 ER/Studio 모두 논리와 물리 모델을 생성한다. 그러나, 생성하는 방식은 서로 실질적으로

는 다르다.

ERwin은 논리와 물리 모델을 분리하여 생성하기 위해 Design Layers라는 개념을 사용한다. 이 개

념은 r4.x에 도입되었으며, 모델 파일에서 지원하는 서로 다른 세 가지 유형이 있다:

논리 모델 파일

물리 모델 파일

결합된 모델 파일(논리와 물리)

결합된 모델 파일은 ERwin 용어로는 클래식 모델 파일이라고도 알려져 있다.

ERwin은 개념 모델과 논리 모델을 구별하지 않는다. 사실상, 제품 설명서의 일부는 논리 모델을

개념적 논리모델이라고 설명한다. 모델이 서로 다른 데이터베이스 플랫폼을 사용하여 배포되어지

는 상황에서는, ERwin은 아래의 모델 3 단계를 만드는데 Design Layers의 복잡성을 이용한다:

개념 논리 모델

일반적인 물리 모델

데이터베이스의 특정 물리 모델

만약 이 Design Layers를 적절하게 사용하지 않으면, Design Layers가 많이 까다로워질 수 있다.

이 것은 ERwin 유저들이 이 Design Layers를 사용하려고 하지 않는 이유 중 하나가 될 수 있다.

대신에, 사용자들은 하나의 파일 안에서 논리와 물리 모델이 결합되어있는 클래식 모델에 의존한

다. r4의 파일 확장자는 .er1이고 r7은 .erwin 파일이다.

Design Layers는 또한 모델을 추출하고 분할하고 연결하는 기능을 제공한다. 이 기능은 동기화를

지원하는 기본으로서 논리와 물리 사이의 오브젝트를 연결하는 기본 기능을 생성시킨다.

Design Layers는 또한 "변환" 기능을 제공한다. Design Layers는 아래와 같은 기본 디자인 변환을

수행할 수 있다:

다대다 관계 해소

계층구조 구현 일반화

컬럼 반정규화

변환 오브젝트는 소스와 타겟 오브젝트에 대한 기록을 유지해서 갖고 있다.

NOTE: 이 상황에서의 변환은 오직 Design Layers 간, 논리모델에서 물리모델로의 메타데이터 변

14

환을 말한다. ETL 프로세스에 대한 데이터 변환 맵핑 또는 이런 프로세스와 관련 있는 데이터 리

니지 변환 맵핑의 개념이랑 혼동하지 않기를 바란다.

r7에서는, ERwin의 변환 기능이 확대되어 ERwin modeler는 통합된(클래식) 모델에서 논리적 관점

에서의 소스 오브젝트와 물리적 관점에서의 타겟 오브젝트를 볼 수 있다.

R8에서의 흥미로운 점은, ERwin은 변환 기능은 유지하고 있지만, 오브젝트 자체 변환 기능은 사

라졌다. 즉, 변환은 이루어질 수 있으나, 소스와 타겟 오브젝트 간의 맵핑 기능은 지원하지 않는

다. Cascading 효과는 변환 오브젝트가 사라지면 해당 변환 오브젝트에 종속되어있는 기능들 또

한 사라진다는 것을 의미한다. 추가적으로, 논리와 물리적인 관점에서 서로 다른 상태를 보여주는

기능 또한 사라졌다. 이러한 이유 때문에 r7.3에서 위 버전으로 업그레이드가 다소 복잡해졌다.

내가 일했던 고객들은 대부분 논리 모델과 물리 모델 간 1:1로 대응되는 ERwin 클래식 모델을 사

용했다. 다르게 얘기하면, ERwin의 논리모델과 물리모델은 서로 밀접하게 연결되어있다. ERwin

modeler에서, 유저는 툴바 안의 콤보박스를 사용하여 논리와 물리 계층 간 전환이 가능하다.

반대로, ER/Studio는 논리와 물리 모델 간 느슨한 결합을 사용한다. 논리와 물리모델 간 '1:다'로

대응되며 이 모델들은 모두 동일한 하나의 ER/Studio Data Architect file(.dm1)파일에 포함된다.

ER/Studio는 또한 개념, 논리, 물리 모델의 진정한 의도를 지원한다. 개념 모델은 ER/Studio

Enterprise Team 에디션에 포함되어있는 Business Architect 툴에서 생성된다. Business Architect는

비즈니스 유저가 쉽게 이해할 수 있는 결과물을 만드는데 매우 적합하다. 또한 이 툴은 필요하다

면, BPMN 컴플라이언스가 적용된 비즈니스 프로세스 모델을 만들 수 있다. 개념 모델 오브젝트는

Model Repository(모델 리파지토리)를 통해 ER/Studio Data Architect로 공유되고 ER/Studio Data

Architect에서 사용되어 진다. 엔터티는 논리모델에서 생성되기 때문에, 논리모델의 엔터티에 기반

이 되는 개념적인 엔터티와 연결될 수 있다. 이 연결 관계는 모든 툴에서 다 사용할 수 있는

"Where used" 기능을 통해 전체적으로 볼 수 있다.

ER/Studio Data Architect에서, 다수의 물리 모델은 메인 논리 모델 또는 모든 논리적인 서브모델

에서 생성될 수 있다. 이 모든 모델들은 아래의 그림에서처럼 하나의 동일한 .dm1 파일에 포함될

수 있다.

원한다면 다차원 모델 또한 같은 파일에서 지원된다.

15

물리 모델 생성은 직관적이고 마법사를 통해 진행된다. 그리고 다대다 관계 해소도 포함한다. 게

다가, 사용자 정의가 된 맵핑은 반정규화된 컬럼 관계 등을 포함한 여러 용도로 사용될 수 있다.

이런 정보는 "where used" 기능을 통해 확인 할 수 있다. ER/Studio는 또한 슈퍼타입/서브타입의

사용을 통해 일반화 계층 구조의 모델링을 지원한다. 만약 물리모델을 생성하기 위해 사용될 논

리적 서브모델이 중첩된 하위 서브모델을 포함하고 있다면, 동일한 물리적 서브모델 또한 생성

가능하다. ER/Studio는 또한 매우 강력한 서브모델 동기화 기능을 갖고 있다.

이 전의 다이어그램에서, 다수의 다른 플랫폼 용 물리 모델이 동일한 논리 모델에서 생성되었다.

지금 보여지는 ER/Studio 화면 사진은, Broker 엔터티에 대한 "where used" 디스플레이다. 이 사진

은 모든 서브모델에서 사용된 일치하는 인스턴스를 보여주고 있다. 다차원 서브모델에서 다차원

으로 사용된 인스턴스까지 보여준다.

16

어느 툴이 이 기능에 더 적합할까?

ER/Studio는 최고의 유연성으로 관련된 개념, 논리, 그리고 물리 모델링을 결합하고 독립적으로도

사용할 수 있게 하는 기능면에서 우수한 기능을 제공한다. ERwin은 비록 복잡한 design layer 기

능이기는 하지만 몇 가지 흥미로운 것을 제공한다. 그러나, r8에서의 변환 오브젝트 기능 제거 등

몇 가지 기능의 후퇴가 일부 기존 고객에게는 업그레이드를 힘들게 한다. 반면에, ER/Studio는 꾸

준히 사용자의 추가 노력 없이 또는 적은 노력으로도 버전(릴리즈)간 쉬운 모델 업그레이드 기능

을 제공한다.

17

리버스 엔지니어링

리버스 엔지니어링이란?

리버스 엔지니어링이란 기존의 데이터베이스로부터 데이터 모델을 읽어와 데이터 모델을 생성하

는 기능이다. 이 것은 네이티브 커넥터 또는 ODBC 데이터 소스를 이용하여 데이터베이스에 연결

하여 사용한다. 일반적으로 마법사는 테이블, 뷰, 인덱스, 디폴트, 규칙, 사용자 정의 데이터타입,

오너, 오브젝트, 뷰, 저장프로시저, 함수, 트리거 그리고 다른 물리적인 구성요소와 같은 특정 데이

터베이스 오브젝트 중 무엇을 리버스 엔지니어링 할 지를 정확히 선택하기 위해 사용된다. ODBC

커넥션을 사용하는 것은 네이티브 커넥션을 이용하는 것보다 더 제한적이다. 일반적으로 ODBC

커넥션을 이용하면 오직 테이블과 뷰만 리버스 엔지니어링 해 올 수 있다. 테이블에서 추출한 정

보는 제약사항, primary key, foreign key, 커맨트를 포함한다. 일반적으로 리버스 엔지니어링 시 선

택한 내용을 파일 또는 템플릿에 저장해서 다음에도 재 사용할 수 있다.

리버스 엔지니어링 기능은 복잡한 데이터의 전체적인 요소를 분석하고 맵핑을 용이하게 하기 위

해 매우 중요한 기능이다. 리버스 엔지니어링 되어진 오브젝트는 모델링 툴에서 수정될 수 있고

동일한 소스 데이터베이스를 수정하는데 사용될 수 있고 또는 대체 데이터베이스의 설계 또는 구

축에 사용될 수 있다.

ER/Studio vs ERwin, 리버스 엔지니어링의 접근 방식에 어떤 차이가 있나?

ERwin과 ER/Studio 모두 훌륭한 리버스 엔지니어링 기능을 갖고 있다. 두 툴 모두 네이티브와

ODBC 커넥션 기능을 제공해주고 있을 뿐만 아니라 마법사 기반의 접근, 리버스 엔지니어링 매개

변수를 저장하여 재사용이 가능한 기능을 제공한다. 아래의 사진은 ER/Studio의 마법사 그림이다.

따라 하기 쉽게 구성되어 있어 사용자는 쉽게 오브젝트 타입과 타입 내의 특정 오브젝트를 선택

할 수 있다.

18

두 툴 모두 import bridge를 사용하여 다른 툴의 다양한 중요한 정보를 가져오거나 리버스 엔지

니어링 할 수 있는 추가적인 기능을 갖고 있다. ERwin에서는 이 기능을 Metadata integration

Wizard라 부르고 ER/Studio에서는 MetaWizard라 부른다.

어느 툴이 이 기능에 더 적합할까?

두 툴의 리버스 엔지니어링 기능은 거의 동일하다. 그러나 ER/Studio의 마법사가 사용하기에 더

직관적이고 쉽다. 두 툴 모두 비슷한 범위의 데이터베이스 플랫폼을 지원한다. 그러나 ER/Studio

가 빅데이터 플랫폼을 네이티브로 지원하는 등 더 종합적으로 제공을 한다. 빅데이터는 이 문서

의 뒷부분에서 다루겠다.

19

메타데이터 확장

메타데이터 확장이란?

데이터 모델 내의 오브젝트를 설명하는 모든 특성이 메타데이터의 한 부분이다. 메타데이터는 이

름, 설명, 커맨트, 데이터타입, 길이, 그리고 무수히 많은 추가적인 속성들을 포함한다. 그러나 조

직은 모델 오브젝트를 더 정의하고 분류하기 위해 종종 추가적으로 메타데이터를 생성하고 정의

하기를 원한다. 이러한 많은 메타데이터의 확장은 데이터 거버넌스를 지원하기 위해 정의되고 생

성된다. 일반적으로 메타데이터는 데이터 관리자, 데이터 품질 파라미터, 마스터 데이터 관리의

분류, 데이터 보존 정책 등을 할당하기 위해 사용된다. 보안에 대한 고려사항이 많아지면서 규정

준수 맵핑 및 개인정보보호 수준의 지정과 같은 메타데이터 확장이 추가됐다.

ER/Studio vs ERwin, 메타데이터 확장의 접근 방식에 어떤 차이가 있나?

ERwin과 ER/Studio Data Architect 모두 메타데이터 확장을 정의하는 기능을 갖고 있다. 그러나,

어느 한 툴에서도 메타데이터 확장이라는 이름을 쓰지 않는다. ERwin은 사용자 정의 속성으로 메

타데이터 확장을 나타내고 ER/Studio는 그것을 attachment라고 부른다. ER/Studio는 또한 데이터

딕셔너리에서 데이터 보안 정보(Data Security Information) 태그를 따로 분리해서 정의해놓았다.

두 툴 모두에서, 메타데이터 확장 타입이 정의되면, 아래의 엔트리를 설정할 수 있다:

인터저(Integer)

텍스트(Text)

날짜(Date)

텍스트 값의 특정 리스트로부터 선택

게다가, ER/Studio는 설명 및 시간 값의 엔트리도 허용한다. ER/Studio의 메타데이터 확장은 또한

일반적으로 기능을 설명하기 위해 외부 파일 경로, 외부 문서의 첨부파일, 스프레드시트, 그리고

다른 파일 유형의 엔트리도 허용한다. 따라서 이름, 첨부파일을 가능하게 해 외부 파일로의 진입

을 허용한다.

ERwin의 경우에는, 사용자 정의 속성 유형의 정의는 오직 한 모델의 오브젝트 유형에 대한 특정

속성에만 적용된다. 다음 그림은 ERwin 7.의 엔티티에 대한 사용자 정의 속성을 설정하는 개념 모

형이다:

20

ERwin에서, 정의된 리스트의 첫 번째 값은 위험 수준을 알려주는 값의 목록에 대한 디폴트 값으

로 추정된다. 리스트의 값은 쉼표를 이용해 구분되기 때문에, 리스트는 반드시 신중하게 구성되어

야 한다. 이 접근방식은 값의 목록을 재정의하는 경우에는, 잠재적으로 에러를 발생시키기 쉽다.

ER/Studio의 attachment 유형은 쉽게 데이터 딕셔너리에서 정의되며 attachment가 적용될 수 있

는 오브젝트 유형의 범위에 쉽게 정의된다. Attachment는 단 한 번만 정의되면 되고 많은 다른

오브젝트 유형에 적용가능 하기 때문에, 이 기능은 매우 강력하다.

값을 수정하는 것은 매우 간단하고 쉽다. 아래의 사진에서 보여지는 것처럼 텍스트 리스트에 선

언되어있는 디폴트 값을 수정하면 된다.

21

간단한 예제를 통해 명확하게 보여주겠다: 우리가 특정 엔터티와 속성의 비즈니스 값을 지정하기

위해 메타데이터 확장을 만들려 한다고 가정하자. 가장 중요한 데이터데이터가 가장 먼저 검토되

어야 한다. 그러기 위해서 데이터의 품질에 대한 우선순위를 지정할 것이다. 데이터 품질 값으로

는 위험, 높음, 중간, 낮음이 올 수 있다. ER/Studio에서는, attachment의 유형을 리스트 유형으로

하여 딱 한 번만 생성하면 된다. 그럼 오브젝트 유형 중 엔터티와 속성에 이 생성한 attachment

를 이용하면 된다. 필요에 따라 엔터티와 속성에 attachment를 바인딩시키고 리스트의 값 중 적

절한 값을 선택하면 된다.

반대로, ERwin에서는 사용자 정의 속성은 반드시 별도로 설정되어야 한다: 사용자 정의 속성 하나

는 엔터티에, 다른 하나는 속성에 사용된다. 사용자 정의 속성 명은 같은 이름을 사용할 수 있지

만 허용된 값의 동일한 목록은 반드시 다른 설정 탭을 사용하여 각각 설정되어야 한다. 엔터티와

속성에는 상관 관계가 없기 때문에, 반드시 분석 목적을 위해 별도로 평가되어야 한다.

다음 그림은 attachment와 Data Security Information 태그를 표시한 ER/Studio의 데이터 딕셔너

리 탭이다. 오른쪽 사진은 모델 다이어그램에서 attachment와 Data Security Information 태그가

표현되어있는 테이블이다.

22

어느 툴이 이 기능에 더 적합할까?

ER/Studio가 이 기능에 있어서는 확실한 승자다. ER/Studio는 데이터 딕셔너리 안에서 메타데이터

확장에 대해 더 간결하고 중앙 집중화된 정의를 제공한다. 오브젝트 유형과 인스턴스에 바인딩

된 메타데이터를 추적 가능하다. 이 섹션에서는 단지 ER/Studio Data Architect 툴 내의 메타데이

터 확장만을 설명한다. ER/Studio Team Server Core를 사용하면 비즈니스 유저는 비즈니스 용어

사전 및 용어가 포함된 메타데이터 확장을 정의하고 다른 비즈니스 유저들과 공유하는 등의 더욱

확장된 기능을 사용할 수 있다.

23

표준 명명

표준 명명이란?

표준 명명은 모델 오브젝트에 명명 규칙을 정의, 적용하고 시행하는 매커니즘이다. 오브젝트, 특

히 엔터티와 속성의 이름은 비즈니스 상황과 현실 세계 오브젝트를 이해하기 위해 매우 중요하다.

표준 명명은 일반적으로 다음과 같은 내용을 포함한다:

명명에 사용하기 위한 공통의 비즈니스 용어의 목록

각 용어의 약어

용어의 순서를 지정하기 위한 템플릿

대소문자 표준(대문자, 소문자, 첫 문자를 대문자로 등)

접두사와 접미사

ER/Studio vs ERwin, 표준 명명의 접근 방식에 어떤 차이가 있나?

두 툴 모두 표준 명명 템플릿을 설정하고 적용하는 기능을 제공한다. 뿐만 아니라 마이크로소프

트의 엑셀 스프레드시트와 같은 외부 소스에서 용어와 약어를 업로드 할 수 있다. 두 툴에서 사

용하는 표준 명명 템플릿은 거의 비슷하다. 아래의 화면 사진은 ER/Studio의 Naming Standards

Template 탭 중 한 화면이다.

표준 명명의 일반적인 사용 예제는 논리 명에 대응하는 물리 명을 만드는 것이다:

24

엔터티 명 → 테이블 명

속성 명 → 컬럼 명

표준 명명을 사용하는 방법은 ERwin과 ER/Studio가 서로 다르다. 논리와 물리 모델 사이의 결합

도의 수준에서 차이가 있다.

ERwin에서는, 명명 지정 규칙은 모델 오브젝트에 대해 매크로 방식으로 적용된다. 기본 명명 방식

은 모델이 생성될 때 발생한다. 하지만 모델 명명 옵션 에디터를 사용하여 변경할 수 있다. 기본

명명 방식은 아래에 나타나있다. 각각의 매크로 이름은 "%"로 시작된다. 그리고 어떤 것은 이름

뒤에 "()"도 온다. 일반적으로 매크로는 문서의 뒷부분에 별도 항목으로 나타난다.

ERwin은 또한 표준에 맞지 않는 아이템을 찾고 표시하는 기능을 갖고 있다. 그렇기 때문에, 표준

에 맞지 않는 용어를 쉽게 찾아내고 수정할 수 있다. 이름을 수정할 수 없게 제재할 수도 있다.

이 기능을 ERwin에서는 "Naming Hardening"이라 부른다.

ER/Studio에서는, 표준 명명은 ER/Studio Data Architect 내의 XML Schema Generation(XML 스키

마 생성), Generation Physical Model(물리모델 생성), Compare and Merge(비교 및 병합), Model

Validation(모델 유효성 검사), Add New Physical Model(물리모델 추가) 등 다른 마법사를 사용할

때도 사용할 수 있다. 또한 아래의 그림처럼 Naming Standards Utility(표준 명명 기능)를 사용하

여 모델과 서브모델 오브젝트에 적용 가능하다:

25

이 기능은 다른 배포 플랫폼에 대해 서로 다른 표준 명명 템플릿을 제공할 수 있다. 이 경우 타

겟 템플릿은 특정 명명 변환 규칙을 갖고 있어야 한다.

ER/Studio의 표준 명명 기능은 매우 직관적이고 사용자 친화적이다. 선택기준이 한번 입력되고 나

면, 기준에 충족되는 오브젝트는 자동으로 선택되며 소스 이름과 번역된 이름 모두 나타난다. 만

약 사용자가 수정하기를 원하지 않는 오브젝트가 있다면, 체크를 풀면 된다. 이름에 잠금을 걸어

이름이 수정되는 것을 막을 수도 있다. 이것을 ER/Studio 용어로는 "Freeze Names"라고 부른다.

표준 명명 템플릿은 또한 오브젝트 에디터 창의 Naming Standards 탭에서 도메인, 속성/컬럼, 그

리고 엔터티/테이블에 적용될 수 있다. Freeze Names 옵션이 선택되어 있으면, 선택된 오브젝트의

이름을 변경하는 것을 방지한다.

표준 명명은 버전 안에 캡슐화 또는 템플릿/파일 안의 표준으로 설정될 수 있으므로 모델에서 재

사용을 촉진한다.

이 전에 언급한 것처럼, 일반적인 표준 명명은 논리에서 물리 명으로 변환될 때 사용된다. 그러나

물리에서 논리 명으로 변환에도 사용 가능하다. 이 기능은 리버스 엔지니어링으로 물리적인 데이

터베이스를 데이터에 맵핑할 때 매우 유용하다. 축약된 물리적 이름(그리고 이름의 부분)은 비즈

니스 용어로 번역되어 논리 오브젝트 명에 적용 가능하다.

어느 툴이 이 기능에 더 적합할까?

다시 한 번 말해서, ER/Studio는 양방향에서(논리에서 물리로나 물리에서 논리로), 표준 명명을 정

26

의하고 적용하기에 사용자 친화적이며 궁극의 유연성을 갖고 있으므로 ER/Studio는 이 기능에 있

어서 우월하다.

27

비교 및 병합(COMPARE AND MERGE)

비교 및 병합이란?

비교 및 병합은 이름에서 나타내는 의미 그대로다; 데이터 모델(또는 서브모델)과 다른 모델 또는

데이터베이스를 비교하는 기능이다. 모델 또는 데이터베이스 각각에 포함되어있는 오브젝트를 서

로 비교한다. 오브젝트 비교 시 오브젝트 간 차이가 발생한다면, 오브젝트의 속성이 소스에서 타

겟으로 병합된다. 비교 및 병합에 대한 리포트도 생성 가능하다. 이 기능은 개발자가 소스코드를

병합하는 프로세스와 매우 유사하다.

ER/Studio vs ERwin, 비교 및 병합의 접근 방식에 어떤 차이가 있나?

비교 및 병합 기능은 ERwin에서는 "complete compare"이다. 이 기능을 이용하기 위해서는, 소스

와 타겟을 선택해야 한다. 소스와 타겟 중 하나는 반드시 모델이어야 하며 다른 하나는 데이터베

이스가 될 수 있다. ERwin은 좌측과 우측을 비교하고 선택하여 complete compare를 완성한다. 여

러 다양한 특성이 비교될 수 있으므로 여러 목록 중에 비교를 원하는 항목으로만 추슬러서 비교

가능하게 하는 것이 중요하다. 그렇지 않으면, 아래에 있는 ERwin의 개념 목업에서 보이는 것처럼,

화면에 너무 많은 정보가 표시되어 작업하기가 힘들다. 이 목업에서, 오브젝트는 하얀색 부분에

나타난다. 아이템 하나를 클릭하면, 그 부분이 파란색으로 강조되며, 목업 하단의 회색 부분에는

오브젝트에 대한 비교 속성이 나타난다.

선택이 완료되면, 좌측(소스)에서 우측(타겟)으로 상태가 적용된다. 오프라인 데이터베이스 타겟에

대한 Alter SQL 스크립트가 생성된다.

ER/Studio는 넓은 범위의 비교 및 병합 기능을 제공한다. Compare and Merge 기능은 소스와 타

겟 모델을 비교한다. ER/Studio에서 사용자가 열어놓고 작업하고 있는 활성 다이어그램(모델)이 항

28

상 소스가 되며, 유효한 타겟을 선택하여 비교하고 원한다면 병합도 가능하다. 또한 오프라인 데

이터베이스를 업데이트하기 위하여 Alter SQL 스크립트를 생성한다.

ER/Studio의 Compare and Merge기능에서 논리모델은 아래의 대상과 비교 및 병합이 가능하다:

동일한 .dm1 파일에 있는 물리모델

또 다른 ER/Studio Data Architect 데이터 모델의 논리모델

또 다른 ER/Studio Data Architect 데이터 모델의 물리모델

ER/Studio의 Compare and Merge 기능에서 물리모델은 아래의 대상과 비교 및 병합이 가능하다:

동일한 데이터 모델의 논리 모델

동일한 데이터 모델의 또 다른 물리 모델(동일한 DBMS 플랫폼과 버전의 물리 모델)

또 다른 ER/Studio Data Architect 데이터 모델의 논리모델

또 다른 ER/Studio Data Architect 데이터 모델의 물리모델(동일한 DBMS 플랫폼과 버

전의 물리모델)

운영 데이터베이스

SQL 파일

두 개의 모델이나 서브모델을 비교 후 결과를 현재 다이어그램의 모델이나 다른 .dm1 파일의 모

델로 업데이트 할 수 있다. 즉, 양방향으로 소스 모델 또는 타겟 모델을 업데이트 할 수 있다. 또

한 몇 개의 변경사항은 타겟으로 그리고 나머지 변경사항은 소스 모델로 변경사항을 병합하여 소

스 및 타겟 모델 둘 다 업데이트 할 수 있다. 아래의 그림처럼 가능하다:

29

ER/Studio의 Compare and Merge 기능에 사용되는 스크린은 매우 직관적이며 효과적이다.

어느 툴이 이 기능에 더 적합할까?

ER/Studio와 ERwin 모두 이 기능은 잘 지원한다. 그러나 ER/Studio는 사용과 유연성에서 ERwin보

다 앞선다. 사용자는 ER/Studio의 기능을 사용하여 실수를 덜 한다.

30

매크로(Macros)

매크로란?

간단히 말해서, 매크로는 모델 오브젝트에 대한 변경사항을 적용하고 업데이트하거나 모델링 툴

에서 자동화를 적용하기 위해 스크립트 언어를 사용하는 기능을 제공한다.

ER/Studio vs ERwin, 매크로의 접근 방식에 어떤 차이가 있나?

ERwin에서는, 매크로는 일반적으로 다음과 같은 영역에서 사용된다:

물리 오브젝트에 대한 명명을 할 때 사용

Pre-script와 post-script(테이블과 모델 수준에서)

저장 프로시저 템플릿

트리거 템플릿

ERwin 매크로 스크립트 구문은 다소 복잡하고 새로운 사용자가 이해하기에는 어려울 수 있다. 매

크로를 사용하여 작업하는 경우, 구문 작성 시 도구 상자를 이용할 수 있지만, 직관적이지는 않다.

ER/Studio의 매크로 기능은 ERwin의 매크로 기능과는 근본적으로 다르다. 매크로 코딩이 SAX

Basic이라는 언어를 기반으로 되어있다. 학습 곡선이 훨씬 빠르며, 특히 Visual Basic 또는 다른 유

사한 언어에 접했던 사람이라면 더욱 접근하기가 쉽다.

ER/Studio Data Architect는 아래의 그림처럼 매크로를 생성하기 위한 완벽한 기능을 갖춘 편집기

를 제공한다:

31

반복적인 작업을 자동화하거나 이미 애플리케이션에 있는 기능을 확장하기 위해 매크로를 생성할

수 있다.

또한 애플리케이션에서 매번 자동적으로 수행될 액션(예를 들어, 엔터티 추가 등)을 실행시키기

위한 이벤트 핸들러를 생성할 수 있다.

매크로는 오브젝트를 업데이트하고, 오브젝트의 정보를 엑셀로 export하고, 엑셀에서 정보를

import하고 디스플레이 속성을 변경하는 등 많은 작업을 할 때 사용할 수 있다. ER/Studio Data

Architect 설치 시 엠바카데로에서 제공하는 다양한 샘플 매크로가 같이 포함되어있다.

어느 툴이 이 기능에 더 적합할까?

이 기능면에서는 사실상 경쟁이 안된다. ER/Studio 매크로가 기능적으로 훨씬 넓은 범위에서 생성

하고, 자동화하고, 사용하기 훨씬 쉽다.

32

유니버설 맵핑(UNIVERSAL MAPPINGS)

유니버설 맵핑이란?

유니버설 맵핑은 같은 모델 파일 또는 별도의 모델 파일의 연관된 오브젝트나 비슷한 오브젝트를

연결하는 기능이다. 일반적인 사용 사례는 다른 모델에 존재하는 동일한 실제 비즈니스 오브젝트

를 연결하는 것이다. 예를 들어, 직원에 대한 개념을 다룬다고 했을 때, 직원 데이터는 조직 전체

에 걸쳐 여러 다른 데이터베이스에 존재할 것이다. 이 데이터베이스들을 리버스 엔지니어링하면,

유니버설 맵핑은 테이블(또는 일치하는 엔터티)을 연결하는데 사용된다. 유니버설 맵핑은 "where

used" 기능에서 오브젝트의 모든 인스턴스를 찾기 위해 추적 기능을 제공한다.

ER/Studio vs ERwin, 유니버설 맵핑의 접근 방식에 어떤 차이가 있나?

두 툴은 유니버설 맵핑에서 크게 다르다. 유니버설 맵핑 기능은 오직 ER/Studio에만 있는 기능이

다.

유니버설 맵핑은 많은 시스템과 중복되는 데이터와 프로세스를 가지고 있는 큰 조직 안에서 엔터

프라이즈-수준의 모델링을 지원하기 위해 구현되어있다. 동일한 .dm1 파일의 모델 간 오브젝트와

서로 다른 .dm1 파일의 모델 간 오브젝트를 맵핑할 수 있으며 또한 Model Repository에 공유되

어 있는 ER/Studio Data Architect 다이어그램과 ER/Studio Business Architect 워크스페이스 간의

맵핑도 가능하다. 이러한 맵핑 정보는 ER/Studio에 남아있어 비교 및 병합 시 이 정보를 이용할

수 있다. 만약 맵핑 정보가 존재한다면, Compare and Merge 기능을 사용 시 자동적으로 적용된

다.

유니버설 맵핑은 아래의 그림처럼 "where used" 창에 있다:

33

유니버설 맵핑은 다음과 같은 여러 방법으로 생성될 수 있다:

● 하나의 디자인 층 내의 맵핑: 이 맵핑은 수평 타입으로 논리에서 논리, 물리에서 물리,

개념에서 개념과 같이 설계 층 내의 재사용을 나타낸다. 설계 층 내의 맵핑 범위는 엔터

티와 엔터티, 테이블과 테이블, 컬럼과 컬럼 등과 같이 동일한 유형의 오브젝트에서만 맵

핑될 수 있도록 제한적이다.

● 다른 디자인 층에서의 맵핑: 이 맵핑은 수직 타입으로 추적성과 "where used"를 통해

개념과 논리, 논리와 물리 등과 같이 서로 다른 디자인 층에 대한 업스트림과 다운스트

림을 보여준다.

공통의 오브젝트가 어디에 있는지 이해하는 것은 개념과 논리모델 간 추적기능을 제공하는 분석

관점에서 매우 중요하다.

유니버설 맵핑은 데이터를 기업 관점에서 보기 용이하다. 일반적으로 주제영역을 식별하는 것으

로 시작하여, 개념 엔터티 식별, 그리고 개념으로부터 논리/물리 모델을 식별한다. 한번 계층구조

가 자리잡아지면, 논리/물리 오브젝트로부터 업스트림을 볼 수 있고 개념모델과 프로세스 모델로

부터 다운스트림을 볼 수 있다.

어느 툴이 이 기능에 더 적합할까?

ERwin은 유니버설 맵핑 기능을 제공하지 않기 때문에, 비교사항이 없다. ER/Studio는 명백하게 엔

터프라이즈 모델링 관점에서 혁신적인 기능을 보여준다.

34

빅데이터에 대한 네이티브 지원

빅데이터에 대한 네이티브 지원이란?

빅데이터에 대한 네이티브 지원이란 nested 오브젝트와 오브젝트 array와 같은 일반적으로 빅데

이터 저장소에 있는 빅데이터 구조를 모델링할 수 있는 능력이다. 이 능력은 기존의 관계형 모델

링을 넘어선 단계이다. 빅데이터 저장소의 포워드 그리고/또는 리버스 엔지니어링의 수준 또한 필

요하다. 이 기능은 기업이 빅데이터 플랫폼을 포용하고 기업의 데이터 전체를 맵핑시키고 모델링

을 하기 위해서 매우 중요하다.

ER/Studio vs ERwin, 빅데이터에 대한 네이티브 지원의 접근 방식에 어떤 차이가

있나?

ERwin과 ER/Studio 모두 MetaWizard를 통해 빅데이터 플랫폼의 구조를 import 할 수 있다. 그러

나, 이 기능은 기본적으로 지원되는 기능은 아니다.

하지만, ER/Studio는 기본적으로 MongoDB와 Haddop Hive 데이터베이스를 그들의 nested 오브젝

트에 대한 표기법 확장을 포함하여 리버스 엔지니어링을 할 수 있다. Hive에 대한 DDL 생성

(CREATE) 또한 지원한다. 아래의 ER/Studio 그림을 보면 임베디드 오브젝트와 오브젝트 array에

대한 표기법을 볼 수 있다:

어느 툴이 이 기능에 더 적합할까?

ERwin은 네이티브 빅데이터 기능을 지원하지 않으므로 비교대상이 못 된다.

35

리파지토리, 게시 & 협업

(REPOSITORY, PUBLISHING & COLLABORATION)

리파지토리, 게시 & 협업이란?

모델링 환경은 아키텍트, 모델러, 비즈니스 분석가 그리고 비즈니스 이해관계자가 같이 작업을 하

는 대규모 팀을 지원할 수 있어야 한다. 그러기 위해서는, 체크-인, 체크-아웃이 빠르고 지속적으

로 발전되는 모델을 검토하는 기능을 가진 강력한 모델 리파지토리는 필수이다. 강력한 모델 리

파지토리는 특정 모델 오브젝트 뿐만 아니라 모든 서브모델에 대해서도 체크-인, 체크-아웃 기능

을 가진다.

리파지토리를 진정으로 사용하려면, 다른 협업자들이 모델 결과물과 메타데이터를 사용하고 피드

백을 줄 수 있도록 일반적으로 웹 포탈을 이용하여 모델 결과물과 메타데이터를 게시해야 한다.

비즈니스 이해관계자들은 반드시 메타데이터 생성에 참여하고 그들이 중요하다고 생각하는 아이

템에 변경사항이 발생할 때 조언을 줄 수 있어야 한다.

ER/Studio vs ERwin, 리파지토리, 게시 & 협업 영역에 어떤 차이가 있나?

Repository(리파지토리)

ERwin과 ER/Studio 모두 모델러의 대규모 팀에게 체크-인, 체크-아웃 기능, 보안과 시스템 기반의

리파지토리에서 예상할 수 있는 기본적인 기능을 제공한다. ERwin은 리파지토리를 Model

Manager Mart라고 부른다. 체크-인과 체크-아웃은 모델/서브모델 수준에서 가능하며 개별 오브젝

트 수준에서는 지원하지 않는다. 기본적으로, 작업이 진행될 때, 모델의 스냅샷이 촬영된다. 데이

터 마트는 굉장히 작은 양의 테이블만 포함한다. 클라이언트에서 만들어진 ERwin 메타-모델은 약

160개의 엔터티로 구성되어있다. 마트는 약 25개의 테이블을 포함하고 있다. 모델이 마트에 저

장될 때, 오브젝트의 특성은 무시되고 이름/값의 쌍으로 m7Object와 m7ObjectProperty라는 핵심

마트 테이블에 저장된다. 큰 모델에 대해서는, 모델을 마트에 저장하거나 마트에서 모델을 열 때,

성능에 영향을 미칠 수 있다.

ER/Studio Model Repository는 다른 오브젝트 유형과 메타데이터 구조를 갖고 있는 많은 테이블

이 있는 관계형 데이터베이스이다. 체크-인과 체크-아웃은 모든 모델, 서브모델, 오브젝트의 집합,

또는 개별 오브젝트에서 수행된다. Model Repository는 또한 Business Architect 툴의 워크스페이

스도 지원하기 때문에, 모델 오브젝트는 툴들 간 공유가 가능하고 참조가 가능하다.

Publishing(게시)

ERwin과 ER/Studio 모두 모델 다이어그램과 메타데이터를 포탈에 게시하는 기능을 갖고 있다.

ERwin r7.3에서 다이어그램에 대한 리포트는 HTML 또는 PDF 포맷으로 생성 가능하다. 생성된

HTML 다이어그램은 볼 수 있으나 모델 오브젝트는 클릭할 수 없어 기본 메타 데이터를 볼 수

36

없다.

ER/Studio는 모든 릴리즈 버전의 모델링 툴 안에 기본적으로 리포트 생성 기능이 있다. 생성 가능

한 리포트 형식은 HTML과 RTF이다. HTML 모델 오브젝트는 클릭이 가능하여 기본 메타데이터를

볼 수 있다. RTF 형식은 Microsoft Word와 같은 툴에서 사용할 수 있으며 리포트를 생성하기 전

에 추가적인 내용을 삽입할 수 있다. 또한 워드 파일은 PDF로 저장 및 출력이 가능하다. HTML

다이어그램은 또한 Business Architect 모델에 대해서도 생성 가능하다.

Collaboartion(협업)

ER/Studio Team Server Core는 무제한으로 웹 사용자가 접속가능하며, 완전히 새로운 차원의 협업

방식을 제공한다. 비즈니스 사용자는 비즈니스 용어사전 & 용어와 정의를 완벽하게 생성하고 검

토할 수 있다. 사용자는 또한 그들만의 리포트를 생성할 수 있고 추가적인 메타데이터도 생성 가

능하다. 업데이트 상황을 알고 최신버전을 유지하기 위해서는, 사용자는 소셜 네트워킹 파라다임

을 사용하여 관심 있는 모델과 오브젝트를 팔로잉할 수 있다.

ER/Studio Enterprise Team 에디션은 모델과 메타데이터 협업을 제공하고 더욱 정확한 데이터를

이용하여 효과적인 결정을 더욱 빠르게 할 수 있게 한다. 주력 제품인 ER/Studio Data Architect는

전체 제품들의 기본이 되는 제품으로 import&export 브릿지, 모델 리파지토리, 데이터소스 레지

스트리 등이 포함된 제품이다.

ER/Studio Enterprise Team 에디션은 데이터 관리 전문가 수준으로 모델 및 메타데이터를 분산된

팀들에게 쉽게 공유, 문서화, 게시할 수 있다. ER/Studio는 필수 데이터와 정의에 대한 커뮤니케이

37

션과 협업을 위한 사용하기 쉬운 기능을 갖고 있어 ER/Studio 사용자는 그들의 데이터를 성공적

으로 관리하기 위해 필요한 데이터를 간단하고 빠르게 찾고, 높은 가치의 결정을 내리기 위해 데

이터를 사용한다.

어느 툴이 이 기능에 더 적합할까?

이 영역에서도 ER/Studio는 ERwin에서 제공하는 기능 이상의 기능을 증명했다. ER/Studio Team

Server Core까지 고려하면 사용 가능한 협업 기능 격차는 더욱 커진다.

38

추가 고려사항

데이터 리니지(DATA LINEAGE)

이 문서의 비교 대상이 되는 툴은 ERwin r7.3이다. 그러나 ERwin의 새로운 버전인 r9.5에 대해 논

의 시 나올 수 있는 주제 중 하나는 포탈에서 볼 수 있는 데이터 리니지다. 두 제품 간 비교는

하지 않을 것이다. 하지만 데이터 리니지라는 용어는 ER/Studio와 ERwin에서 서로 다른 의미를

가지고 서로 다른 상황에서 사용되기 때문에, 설명할 필요는 있다.

ERWIN 데이터 리니지

ERwin r9.5 웹포탈은 영향 분석 영역에서의 새로운 기능이다. Lineage Analyzer라고 부르며 사용자

들이 데이터 오브젝트 간 논리, 일반적인 물리, 그리고 데이터베이스의 특정 물리 모델 사이의 상

호 관계 등 관계를 볼 수 있다. Lineage Analyzer는 "where used" 분석을 포함하여 (예를 들어) 뷰

에서 어떤 테이블이 사용됐는지, 또는 도메인에서 어떤 컬럼/속성이 사용됐는지를 볼 수 있다. 이

데이터 리니지는 모델링 툴 자체가 아닌 포탈에서 볼 수 있다.

ERwin에 메타데이터 리니지에 대한 3가지 종류가 있다:

● 의미(시맨틱) 모델에서 모델로의 리니지: ERwin에서 디자인 계층을 사용하는 '의미 모델

에서 모델로의 리니지'는 포탈에서 모델-to-모델의 의미 관계를 만들기 위한 기본적인 메

타데이터를 생성한다.

● 데이터 웨어하우스 맵핑 리니지: ERwin에서 다차원(dimensional) 모델을 만들 때, ERwin

Data Modeler의 소스-to-타겟 맵핑 기능은 포탈에 표시하기 위한 기본 메타데이터를 생

성한다. 소스-to-타겟 맵핑은 기본적인 연결 관계만 있고 ETL을 위한 데이터 변환은 포함

하지 않는다.

● 데이터베이스 뷰 맵핑: 데이터 리니지의 뷰는 ERwin의 물리모델 안의 테이블에서 뷰를

만들 때 제공된다. 포탈은 그래픽적으로 뷰에서 참조하는 테이블을 표시할 수 있다.

ER/STUDIO 데이터 리니지

ER/Studio에서는, 메타데이터 리니지가 모델링 툴의 "where used"와 dependent-objects 기능을 통

해 바로 지원된다. 메타데이터 리니지는 Team Server에 게시할 수 있는 메타데이터의 한 부분이

다.

ER/Studio에서, 데이터 리니지는 데이터 추출, 변환 그리고 로드 파라미터를 문서화할 수 있는 기

능이며, 때때로 소스와 타겟 맵핑이라고 불린다. 데이터 리니지는 A에서 B 지점으로 데이터가 이

동한 흐름에 대해 문서화할 수 있으며, 그 사이의 모든 중간 단계를 문서화 할 수 있다. 이 데이

터의 이동은 때때로 추출, 변환, 및 로드(ETL)라고도 불린다. ER/Studio에서 생성된 모델은 데이터

가 이동하는 길에 대한 모든 지점을 나타낼 수 있다. Data Architect는 컬럼/속성 수준까지 데이터

의 "소스" 또는 "타겟"을 지정하는 기능이 필요하다. 데이터의 이동을 나타내는 기능은 소스와 타

39

겟 맵핑을 정의하는 메타데이터와 함께 데이터가 어떻게 조작되는지에 대한 규칙이다.

데이터의 이동은 데이터 리니지라는 용어가 일반적으로 사용될 때, 논의되는 기능 중 하나이다.

40

결론

우리는 엔터프라이즈 급의 데이터 모델링 툴에 매우 중요한 10가지 주요 기능들을 보았다. 우리

가 다뤄본 기능은 다음과 같다:

진정한 멀티 레벨 서브모델

진정한 논리/물리 모델 분리

리버스 엔지니어링

메타데이터 확장

표준명명

비교 및 병합

매크로

유니버설 맵핑

빅데이터에 대한 네이티브 지원

리파지토리, 게시&협업

우리는 주로 ERwin과 ER/Studio 각각에서 사용되는 기본 디자인과 상대적인 기능에 대해서 알아

봤다. 두 툴 모두 버전이 업데이트되고 있지만, 각각의 툴은 그들만의 기본 디자인에 대한 일관성

을 남아있다.

나는 이 문서에서 10가지 기능만 언급했지만, 더 많은 기능을 언급할 수 있다. 이 문서에서는

ER/Studio가 ERwin은 제공하지 않는 유니버설 매핑이나 네이티브 빅데이터 지원을 제외하고도 다

른 모든 영역에서 확실한 승자임을 증명한다. 만약 당신의 조직에서 데이터모델링 툴을 ER/Studio

로 바꾸는 것을 고려하고 있다면, 이 문서의 정보가 당신이 가질 수 있는 우려를 줄일 수 있기를

바란다. ER/Studio는 내가 데이터 아키텍처 사례에 사용할 만큼 잘 작동했다. ERwin을 사용하는

많은 조직은 ER/Studio로 툴을 바꿨다. 엠바카데로는 지속되는 제품의 발전을 보여주며 지속적으

로 제품에 투자하고 있는 것을 나타냈다. 이 사실이 ER/Studio를 이용하는 것이 당신과 당신의 회

사를 위한 장기 투자라고 느낄 것이다.

나에게 ER/Studio의 제품 매니저 역할 제의가 들어왔을 때, 나의 선택은 쉬웠다:

나는 ER/Studio를 매우 좋아하며, 이 회사에 합류하겠다!