데이터 설계 분석: 상향식(bottom-up) 설계 분석과 표준화

데이터 설계 분석

상향식(bottom-up) 설계 분석과 표준화

작성자 : Jason Tiret (ER/Studio 제품 매니저)

2004 년 8 월

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 동 746-14

3 층 ㈜데브기어

(T) 02.595. 4288

데이터

설계

분석

Embarcadero Technologies


데브기어 기술자료 tech.devgear.co.kr 데브기어 홈페이지 www.devgear.co.kr 문의 [email protected]

도입

이 문서는 설계 문제를 실제 데이터베이스에서부터 거꾸로 찾아서 해결하는 방안을 제시합니다. 이어서

유지보수나 데이터베이스 추가 설계 시 표준화를 적용할 수 있는 안전한 협업 환경을 어떻게 구성할 것인가에

대해 설명합니다.

당면 문제 개요

데이터베이스 시스템을 구축하거나 유지보수 할 때 대부분 많은 어려움과 부딪치게 됩니다. 데이터베이스 구축

시 표준화를 준수하도록 하는 것은 매우 중요합니다. 왜냐하면 데이터베이스 구조라는 것은 항상 진화해 가고,

개발 시간은 줄어가고, 팀의 규모는 커져가기 때문입니다.

정해진 표준과 가이드가 없으면, 데이터베이스에 잠재된 이슈, 즉 데이터 불일치, 데이터 통합 문제, 심지어

데이터 손실과 같은 문제가 발생됩니다. 데이터베이스가 잘 커나갈 수 있도록 돌보는 책임은 개발팀에서부터

유지보수 팀까지 다양한 그룹의 사람들과 관련되어 있습니다.

개발자들은 변경 요구사항이 발생할 때마다 기존 데이터베이스에 새로운 테이블을 만들어 넣고 있습니다. 또한

같은 내용을 작업하면서도 어느 개발자는 “name”이라는 컬럼에 VARCHAR(30) 을 사용하고, 다른 개발자는

VARCHAR(50)을 사용한다면 어떻게 될까요?

설계 상의 불일치 문제가 발생하는 이유는 이와 같이 개발자들이 데이터 요소에 대한 용어집이나 정해진

표준으로 정의된 비즈니스 룰을 염두하고 있지 않기 때문입니다.

그 결과 오히려 복잡한 데이터 통합 작업, 정확하지 않은 리포트로 인한 비용 등이 발생하게 됩니다.

해결 방안 개요

모델링 도구를 활용하면 데이터 설계 표준화와 데이터 무결성 분석에 있어서 큰 도움을 받을 수 있습니다. 이

글에서는 위와 같은 문제를 해결하기 위해 엠바카데로의 모델링 솔루션인 ER/Studio 를 사용하도록 합니다.

ER/Studio 는 데이터 딕셔너리 시스템과 협업 서버 리포지토리가 잘 구성되어 있기 때문입니다. 데이터베이스를

분석하려면 우선 데이터베이스를 눈으로 볼 수 있어야 합니다. 이 글에서는 Oracle 스키마를 리버스 엔지니어링

하는 것에서부터 시작합니다. ER/Studio 를 이용하여 시스템 카탈로그의 메타데이터를 추출하여 논리 모델과

물리 모델을 만들고, 데이터 무결성을 해칠 수 있는 잠재된 문제를 스키마에서 해부합니다. 이어서 발견된

문제를 모델링 환경에서 즉시 정정하고 향후에 동일한 문제가 발생되지 않도록 장치를 마련합니다.

분석을 위한 로드맵

우리는 ER/Studio 의 다이어그램을 이용하여 로드맵을 구성합니다. ER/Studio 를 활용하면 데이터베이스로부터

데이터 딕셔너리를 뽑아낼 수 있고, 이 딕셔너리의 도메인들을 논리모델과 물리모델의 각 요소에 묶을 수

있습니다. 일단 데이터 모델을 구성하여 청사진을 마련하고 나면 데이터베이스 표준화를 적용하도록 하겠습니다.

기존 데이터베이스 리버스 엔지니어링 하기

1. ER/Studio 를 연다.

2. File > New > Reverse Engineer

3. 첫 페이지에서 “native connection,” 를 선택하고 Oracle 서비스와 로그인 정보 입력

4. 두 번째 페이지에서, 가져오고자 하는 스키마와 객체를 선택 (지금은 테이블만 선택한다. 다양한 DBMS

고유의 객체를 모두 선택할 수도 있지만 생략)

Embarcadero Technologies - 3 -



데이터

설계

분석

5. 세 번째 페이지에는, 선택된 스키마의 객체들이 표시된다. 이때 테스트 등 필요 없는 객체들은 제외

(테이블 수와 평균 컬럼 사이즈는 지금 생략)

6. 네 번째 페이지에서, 디폴트 옵션에 “Infer Domains” 옵션을 추가로 선택

중요: 위 옵션은 컬럼명과 데이터타입의 묶음이 고유한 모든 컬럼을 도메인으로 추출합니다. 만약 이름과

데이터 타입 모두가 동일한 컬럼이 두 개가 발견되면 ER/Studio 는 하나의 도메인을 만들고, 이 도메인을 두 개의

컬럼에 각각 맵핑 합니다. 이렇게 하지 않으면 동일한 컬럼이 각각 자기만의 독립 도메인에 맵핑 되므로 설계

분석에 도움이 되지 않기 때문입니다.

7. 다섯 번째 페이지에서, Finish 클릭.

이제 준비가 되었나요?

이제 Oracle 데이터베이스에 대한 “로드맵” 또는 “청사진”이 준비되었습니다.

논리 모델과 물리 모델이 구축되었고 각 모델에는 각기 독립적인 객체로서 메타데이터가 포함됩니다.

예를 들어 논리 모델에서 변경을 주어도 물리 모델이 강제로 변경되지 않습니다. 하지만 변경 내용은

비교/병합 시스템을 통해 필요 시 원하는 방향으로 동기화 할 수 있습니다.

논리 모델로부터 새로운 물리 모델을 하나 더 추가 할 수도 있습니다. 예를 들어 다른 DBMS 용도의

물리 모델이 필요하거나, 실제와는 조금 다른 테스트 서버용 물리 모델이 필요한 경우 등에 사용될 수

있을 것입니다.

각각의 컬럼과 연결되어 있는 도메인 목록이 논리 모델과 물리 모델에 구축되었습니다. 이것은

데이터베이스 분석이나 표준화의 시작점이 될 것입니다.

데이터베이스 설계의 일관성 분석

이제 모델이 완성되었고, 도메인이 추출되었으므로 분석을 시작합니다. 먼저 데이터베이스 테이블 안의 여러

데이터 요소를 살펴보는 것에서부터 시작하겠습니다. 이미 도메인으로 정리되어 있습니다. 만들어진 도메인은

데이터베이스에 들어있는 컬럼과 같은 데이터 요소에 대한 “목록”이 되어 있을 것입니다. 이 추출된 목록에는

데이터 요소의 속성이 상이한 경우도 표시될 것입니다. 같은 이름의 도메인이 발생되면 플래그가 표시됩니다.

왜냐하면 ER/Studio 에서는 컬럼명이 같더라도 테이터 타입, 룰, 제약조건 등 속성이 다른 경우, 새로운

도메인으로 추가하기 때문입니다. 목록을 살펴보겠습니다.




1. Data Dictionary 탭으로 이동 (모델 탐색기 하단의 두 번째 탭)

2. Domains 노드로 이동하여 확장

아래와 같이 추출된 목록이 표시됩니다.

위 목록 중 DESCRIPTION 도메인이 2 개 있는 것을 주목하세요. 해당 도메인을 더블-클릭하여 domain editor 를

열고 잘 보면, 하나는 VARCHAR(255), 다른 하나는 VARCHAR(500)으로 되어 있는 것을 알 수 있을 것입니다. 즉

서로 다른 기준이 적용된 것입니다. 이런 차이는 의도적일 수도 있고 아닐 수도 있습니다. 만약 의도적인

것이라면, 명명 규칙을 향상시킬 필요가 있습니다. 즉 짧은 설명에 대해서는 DESCRIPTION 을 긴 설명은

NOTES 라는 용어를 사용하도록 하는 것입니다. 하지만 이것이 의도적인 것이 아니라면 설계 상에서 이 실수를

떼어 내어야 합니다. 그래야 컬럼 통합 시 데이터 손실을 방지할 수 있습니다.

보다 심층적인 분석을 위해, 해당 도메인을 오른쪽 클릭한 후 “View Domain Bindings.” 를 클릭하면, 다음과

같은 두 가지 사항이 알 수 있습니다:

1. 이 도메인이 어디에 적용되어 있는가! – 보다 구체적으로는, 어느 속성과 컬럼에 묶여

있는지를 알 수 있습니다. 즉 공통의 데이터 요소가 실제로 데이터베이스의 상의 어떤

속성이나 컬럼 등과 연관되어 있는지 관계를 분석할 수 있습니다.

2. 속성이나 컬럼을 실제 변경하기 전에 Impact analysis(영향 분석)을 수행할 수 있습니다.

도메인에 변경을 가하면 연결된 속성이나 컬럼에 변경 사항이 모두 적용됩니다. 비즈니스

요구사항에 의해 변경이 발생되는 경우에는 컬럼을 각각 변경하는 것보다는 domain editor 에서

일괄 변경을 하는 것이 보다 효과적입니다.

DESCRIPTION 에서 다음과 같이 표시되었다고 하면:

DESCRIPTION 도메인이 논리 모델과 물리 모델에서 어떻게

사용되고 있는 지를 보여주고 있습니다. 위 내용은 domain

editor 의 “Binding Information” 탭에서도 볼 수 있습니다. 이

탭에서는 다른 컬럼이나 속성에 추가로 바인딩 할 수도 있습니다.




데이터

설계

분석

잠재된 문제를 바로잡기

데이터 타입의 충돌이 실제로 문제가 되었다고 가정하면, 이 문제를 바로 해결해야 할 것입니다. 이미 도메인이

적용되었으므로 매우 간단하게 처리할 수 있습니다. 여기에서는 DESCRIPTION_2 도메인이 보다 사이즈가 크기

때문에 (500) 이것을 표준으로 삼겠습니다. 우리는 이제 DESCRIPTION 도메인에 묶인 컬럼과 속성들이

DESCRIPTION_2 도메인에 묶이도록 바꾸어 주기만 하면 됩니다. 더불어 도메인 목록을 잘 살펴서 혹시라도

DESCRIPTION 의 성격을 가진 데이터들이 추가로 있는지 확인해 봅니다.

앞서서 “Binding Information”을 통해 이미 이 두 도메인 모두가 사용되고 있음을 알고 있으므로, ER/Studio 의

자동화 매크로에 포함되어 있는 Switch Domain Bindings 매크로를 사용하여 문제를 바로 해결하겠습니다.

1. 모델 탐색기 하단의 Macro 탭 클릭.

2. Switch Domain Bindings 매크로를

오른쪽 클릭하고 Run.

3. 팝업이 나타나면, source 로

DESCRIPTION 을, target 으로

DESCRIPTION_2 선택.

4. Switch 버튼을 클릭하여 바인딩 된 도메인을 바꿉니다. 만약 DESCRIPTION_2 로 바인딩을 바꾸고자

하는 도메인이 더 있다면 source 에서 선택할 수 있습니다. RELEASE_COMMENTS 와 같은 도메인도

여기에 묶으면 좋을 것 같아 보입니다. 이와 같이 3,4 단계를 반복하여 DESCRIPTION_2 로 통합합니다.

5. DESCRIPTION_2 도메인에서 “View Domain Bindings” 를 다시

보면 정리된 것이 보입니다. 이렇게 하여 올바른 길로 한발 더 다가

섭니다.

6. DESCRIPTION 과 RELEASE_COMMENTS 도메인은 이제 더 이상

사용되지 않으므로 제거해도 안전합니다.

지금까지 도메인 목록을 리펙토링하고, “설명” 정보 데이터에 대해 단일한 표준을 적용하였습니다. 이제 개발자,

DBA, 데이터 아키텍트가 이 도메인을 사용하여 새롭게 컬럼을 추가하게 되면 표준 속성들이 그대로 적용됩니다.

따라서 조직 전반적으로 동일한 표준이 적용될 것입니다.




함께 작업할 수 있는 환경으로 업그레이드

지금까지는 특정 Oracle 스키마 하나를 분석하고 표준화 하였습니다. 하지만, 아직은 동료들이 분석을 하거나

논리 모델과 물리 모델을 변경할 때, 또는 메타 데이터에 대한 보고서를 작성할 때 위 표준 사항을 함께 활용할

수 있는 환경은 구축되지 않았습니다. 또한 아직 전사적인 비즈니스 룰, 표준 데이터 요소를 적용하지 않았으며,

사내의 애플리케이션에 일관되게 사용될 수 있는 메타 데이터를 구성하지는 않았습니다. 이제 개발팀과 표준화

수준을 팀 차원 또는 회사 차원으로 넓혀 보겠습니다. ER/Studio 리포지토리와 협업서버 (ER/Studio

엔터프라이즈 에디션에 포함되어 있음)를 활용하면, 안전한 방식으로 “실시간” 팀 작업을 할 수 있습니다.

리포지토리는 Oracle, DB2, SQL Server, Sybase 에 설치됩니다.

협업 환경 구축하기

우선 리버스 엔지니어링 한 모델을 협업으로 작업할 수 있도록 ER/Studio 리포지토리에 넣습니다. 해당

다이어그램의 모든 정보가 리포지토리 데이터베이스에 저장되기 때문에 ER/Studio 사용자는 부여된 권한에

맞게 공유된 모델을 사용할 수 있습니다.

리포지토리에 추가하기 대화 상자는 다음과 같습니다:

객체 공유, 재사용, 영향도 분석

리포지토리에 추가할 때, 만약 이미 리포지토리에 엔터프라이즈 데이터

딕셔너리가 있다면 원하는 딕셔너리를 연결할 수 있습니다. 엔터프라이즈

데이터 딕셔너리는 전사적으로 정의된 도메인과 룰, 첨부 태그, 디폴트,

사용자정의 타입 등의 객체에 대한 공유 딕셔너리 입니다. 위 그림에서는

EMBT 딕셔너리에 연결하였습니다. 따라서 공유된 다이어그램에는 해당

표준과 딕셔너리에 물리게 됩니다. 이제 해당 딕셔너리의 모든 요소를 들을

사용하여 모델을 관리할 수 있습니다.




데이터

설계

분석

지금부터는 속성과 컬럼 중에서 도메인을 가지고 있지 않거나, 여전히 로컬 데이터 딕셔너리를 사용하고 있는

것들을 찾아서 EMBT 딕셔너리에 연결되도록 합니다. EMBT 딕셔너리는 전사적으로 활용되는 딕셔너리이므로

보다 일관적이고 효과적으로 관리될 수 있습니다. 영향 분석 방식은 동일하지만, 적용 범위는 해당 리포지토리의

모든 다이어그램으로 확장됩니다. 예를 들어, EMBT 딕셔너리에 있는 Identifier 도메인을 기준으로 다이어그램의

모든 ID 속성과 컬럼을 관리하고자 한다면, 각 모델에 들어 있는 모든 ID 컬럼은 Identifier 라는 하나의

도메인으로 묶어서 관리할 수 있습니다. (참고: 엔터프라이즈 도메인의 Binding Information 탭이나 매크로를

활용하여 작업할 수 있습니다). 그 결과 이제는 Identifier 도메인이 활용되는 곳을 리포지토리 내의 모든

다이어그램에서 쉽게 추적할 수 있게 됩니다.

표준화 준수 장치 마련

이제는 엔터프라이즈 딕셔너리에서 관리해야 할 것과 로컬 딕셔너리를 그냥 사용해도 될 것을 가려내는 작업을

할 때입니다. 리버스 엔지니어링을 통해 추출한 도메인 리스트에는 해당 Oracle 데이터베이스 스키마에서만

사용하기 위해 만든 애플리케이션 의존적인 도메인들도 있을 것입니다. 하지만 다른 것들은 EMBT 딕셔너리의

도메인에 묶게되면 표준화 수준이 한 단계 올라가게 됩니다. EMBT 딕셔너리를 살펴보았더니 “Long

String”이라는 도메인이 있습니다. 해당 속성을 자세히 보니 DESCRIPTION_2 도메인에 묶인 속성과 컬럼을

관리하기에 안성맞춤입니다.

이런 것들은 단일한 글로벌 도메인 하나로 관리하는 것이 바람직합니다. 그렇게 되면 전사적으로 데이터베이스

구조를 변경해야 하거나, 추가할 때 명료하게 구현할 수 있고 개발 과정 전반에 걸쳐 모든 애플리케이션에

표준이 적용될 수 있습니다. 이제까지는 “설명”정보 데이터가 로컬의 DESCRIPTION 도메인에 물려 있었지만,

Switch Domain Bindings 를 활용하여 다시 옮기도록 합니다. 이번에는 도메인 뿐만 아니라 source dictionary 와

target dictionary 도 선택하여야 합니다




작업을 마치고 나면, DESCRIPTION_2 가 실수로 사용되지 않도록 로컬 딕셔너리에서 제거합니다.

결론

ER/Studio 와 협업 서버, 리포지토리를 활용하여 Oracle 데이터베이스의 잠재된 무결성 문제를 때어 냈습니다.

도메인을 추출하고 현재의 데이터베이스에서 같은 의미의 컬럼들의 데이터 타입이 충돌되고 있는 것을

찾아냈습니다. 문제가 왜 발생하게 되었는지는 알 수 없었지만, 이것이 데이터 무결성과 관련된 다양한 문제를

일으킬 수 있다고 인식하고, 하나의 표준을 정하여 통합함으로써 문제를 해결하였습니다. 이 때 만들어진 표준은

모델을 리포지토리에 통합하는 과정에서 전사 표준 딕셔너리의 표준에 맞게 다시 수정하였습니다. 그 결과

전사적으로 동일한 문제가 발생되지 않도록 관리될 수 있게 되었습니다. 데이터 무결성 문제는 여러가지 요인에

의해 언제든지 발생될 수 있습니다. 하지만, 분산된 팀에 대해서도 전사 표준을 작성하고 준수할 수 있는 환경을

구축하면 사전에 방지할 수 있습니다.

엠바카데로 테크놀로지는, 1993년에 설립한 데이터베이스 툴 제작사입니다. 2008년에 볼랜드의 개발툴 부문 「CodeGear」를

합병하였습니다. 현재는 애플리케이션 개발자와 데이터베이스 기술자가 다양한 환경에서 소프트웨어 애플리케이션을 설계, 구

축, 실행하기 위한 툴을 제공하는 최대 규모의 독립계 툴 제작사입니다. 미국 기업의 총수입 랭킹 「포춘 100」중 90개 기업과

전세계 300만 이상의 고객이, 엠바카데로의 RAD Studio®, Delphi®、C++Builder® 등 개발툴 제품과 ER/Studio®、

DBArtisan®, RapidSQL®, DB PowerStudio® 등 데이터 모델링 및 DB관리 제품을 채용해, 생산성의 향상과 혁신적인 소프트웨

어 개발을 실현하고 있습니다. 엠바카데로 테크놀로지스는, 샌프란시스코에 본사를 두고, 세계 각국에 지사를 전개하고 있습니

다. 보다 자세한 내용은, http://www.devgear.co.kr를 참고하시기 바랍니다.

http://www.devgear.co.kr/

데이터 설계 분석: 상향식(bottom-up) 설계 분석과 표준화

Technology