XML, NoSQL, 빅데이터, 클라우드로 옮겨가는 시장 상황 속, 데이터모델링 여전히 중요한가

XML, NoSQL, 빅데이터, 클라우드로 옮겨가는 시장 상황 속 데이터 모델링, 여전히 중요한가
작성자 : Joe Maguire, Peter O’Kelly
2014년
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 문의 ask@embarcadero.kr
소개
지난 몇 년 간, 여러 데이터베이스 시장의 변화로 많은 사람들은 데이터 모델링1의 유용성에 대한 의문을 갖기 시작했다. 특히, XML 정보관리의 출현으로, 전통적인 관계형 데이터베이스 관리시스템(RDBMS)의 능력과 벤더 관계에 대한 불만이 커져가고 있다. 또한 증가하고 있는 클라우드 플랫폼의 영향력으로 많은 조직은 그들의 데이터 모델링 작업이 반드시 필요한 작업인지를 다시 고민하고 있다.
NoSQL과 빅데이터 시스템을 포함한 다른 데이터베이스 시장의 변화 또한 많은 사람들에게 데이터 모델링의 가치를 재평가하도록 하였다. 이 보고서의 마지막 부분에서는 오늘날 우리가 알고 있는 NoSQL과 빅데이터의 역할에 대한 가능성이 대체로 오해였다고 생각하는 이유를 설명할 것이다. 그러나 이러한 느슨하게 정의된 도메인들을 위한 시장의 열정이 전통적인 데이터모델링에 도전해왔다는 것에는 의심할 여지가 없다.
전반적으로, 우리는 데이터 모델링이 과거 어느 때보다 중요하다고 믿고 있으며, 데이터베이스 시장 변화를 완벽하게 활용하고자 하는 조직은 그들의 데이터 모델링에 대한 집중을 더욱 증대해야만 한다. 이제 이 보고서를 통해 우리의 관점과 그에 대한 이유를 설명한다.
정보 관리 프레임워크
지난 몇 년간 정보 관리 혁신이 큰 관심을 받았다. 마치 새로운 기회를 최대한 이용하고자 하는 조직이 인터넷 중심의 컴퓨팅과 클라우드 플랫폼으로 개발을 전환함으로써 가능성을 만들었던 것과 같은 것이다. 우리는 다음 세션에서 시장 역학의 가장 괄목할 만한 부분을 살펴 볼 것이다. 그 다음으로 얼마나 다양한 시장 역학이 서로 관련되어 있는지 이해하는데 사용할 수 있는 프레임워크를 소개할 것이다. 이 프레임워크는 현재의 시장 역학을 이해하기에 중추적인 역할을 담당하며 이들은 데이터 모델링 역할에 전체적인 영향을 준다.
관계와 자원: 이분법인가, 연속체인가?
첫 번째 프레임워크의 관점은 정보 요소와 리소스/관계 두 타입으로 구분된다. 리소스는 이야기의 흐름을 전하는데(예: 스토리를 공유하기 위한) 최적화된 디지털 아티팩트이다. 그리고 이는 일반적으로 설명, 계층, 시퀀스 측면으로 구성된다. 일반적으로 사용되는 리소스 타입으로는 책, 잡지, 문서(예, PDF와 Word 파일들) 그리고 웹페이지와 XBRL(eXtensible Business Reporting Language)과 같은 하이퍼텍스트 문서가 있다. 비동기식 스토리 공유를 의미하는 것으로, 리소스는 인간의 이해를 위해 최적화 되어 있다.
이와는 대조적으로, 관계는 실재로 존재하는 것과 이들 사이의 연관 관계에 대한 응용프로그램의 독립적인 설명이다. 사례는 보편적인 데이터베이스 도메인에 포함되어 있는데 고객, 세일즈, 인력 관리 모델과 같은 것들이다. 관계는 응용프로그램과 툴(예: 쿼리/리포팅툴)에 사용되기 위하여 설계되었다. 그리고 이러한 툴이 없어도 이야기를 전달하거나 주어진 도메인에 대한 인간의 이해력 향상에는 영향을 미치지 않는다.
그림 1 자원/관계 연속체 도식
1 1데이터 모델링, 이 문서의 목적을 위하여 전통적인 모델링에 국한하지 않는다; 이것은 엔터프라이즈 컨텐츠 관리와 웹 컨텐츠 관리와 같은 도메인에도 적용될 수도 있다. 이것은 데이터 모델링과 다양한 컨텐츠 모델링 모두를 포괄하는 “정보 모델링”과 같은 폭넓은 도메인을 참조하는 것이 더 정확하다.

Embarcadero Technologies - 3 -
그림 1: 자원/관계 연속체
그림 1의 모델은 정확하거나 철저한 의미의 모델은 아니다. 이것은 리소스와 관계 카테고리 사이의 차이점을 설명하는데 도움을 준다.
리소스와 관계는 상호보완 관계다. 예를 들어, 인터넷 기반 주문 프로세스 시스템은 관계에 중점을 둔 데이터베이스와 구매 주문 내역서를 캡쳐하는 XML 문서와 같은 리소스 모두에 포함된 것처럼 보인다. 그리고 인증을 목적으로 사용되는 디지털 서명과 같은 다른 종류의 문서도 포함한다.
관심사의 분리: 개념, 논리, 물리
프레임워크의 두 번째 차원은 모델링 추상화의 세 가지 상호 보완적 레벨을 표현한다. :
• 개념: 기술 중립적이고 도메인 이해관계자 간 상황에 대한 합의를 확립하기 위하여 우선적으로 사용된다. 정보 작업자는 관념의 개념적 모델 수준에서 이상적으로 작업을 한다.
• 논리: 개념 모델을 기술적으로 해석한다. 두 개의 가장 광범위하게 사용되는 논리 모델은 하이퍼텍스트(예: 웹페이지, 그러나 종종 훨씬 더 정교한 XBRL 리포트처럼)와 관계를 포함한다. 응용시스템 개발자는 이상적으로 관념의 논리적 수준에서 이상적으로 작업을 한다.
• 물리: 인덱싱과 연합(federation)과 같은 구현 레벨을 포함한다. 물리 모델링 문제는 이상적으로 시스템 아키텍트와 관리자에게 한정이 된다; 정보 작업자와 응용 개발자는 물리 모델 상세를 부담할 수는 없다.
대부분의 조직은 현재 논리와 물리 모델의 조합으로 작업을 한다. 그림 2 두 개의 개념모델 일부 샘플을 포함한다. 하나는 EverNote이고 나머지 하나는 MS OneNote이며 이들은 유명한 개인 정보 관리 툴이다.

그림 2: 개념모델 다이어그램 예제
이 다이어그램은 심지어 모델링 기술의 트레이닝이 없어도 관찰하기 쉽다. 그림 2의 예제를 보면, OneNote는 EverNote보다 더 정교한 모델을 갖고 있다. OneNote는 하위페이지/절 수준의 태깅을 지원한다. 반면에 EverNote 태깅은 노트/페이지 수준이다.
개념모델 규칙은 논리 모델링 툴 사용 경험이 있는 사람들에게만 익숙한 것처럼 보일 수 있지만, 외래키 관계, 데이터 타입, 널 제약사항과 같은 세부 사항을 포함하고 있지는 않다. 개념 모델은 업무 의사결정자 간 상황에 맞는 합의를 수립하는데 도움을 줄 수 있도록 최적화 되어있다. 그래서 그들은 엔터티, 속성, 관계, 식별자에 집중하게 되었고 논리 모델 설정 또는 낮은 레벨의 세부 사항 포함을 가정하지 않는다. 그것들은 업무 도메인에 집중하는 사람을 방해하거나 혼란을 줄 수도 있다.
그림 3 통합 프레임워크의 차원 캡쳐 Resources Relations Conceptual Resources and links Entities, attributes, relationships, and identifiers Logical Model : Hypertext language: XQuery Model: extended relational Language: SQL Physical Indexing(e.g., scalar data types, XML, full-text), locking and isolation levels, federation, replication, in-memory databases, columnar storage, table spaces, caching, and more
그림 3: 통합 프레임워크

프레임워크는 다음 절에서 우리가 NoSQL, 빅데이터와 같은 데이터베이스 시장 역학을 리뷰 할 때 다시 언급하게 될 것이다.
응용 프로그램, 데이터, 응용 프로그램/데이터 독립
세 번째와 마지막 프레임워크 차원은 응용프로그램과 데이터 사이의 차이점을 고려하는 것이 중요하다. 물론 데이터 관리는 정보에만 국한된 것이 아니다; 정보를 유용하게 만드는 응용프로그램 또는 분석 툴이 없는 정보는 단순한 기록 저장이다. 비록 정보 관리 범위가 응용프로그램 요구사항에 의해 가이드 되었지만 응용프로그램/데이터 독립성은 주요 목적이고 데이터베이스가 다중의 응용프로그램 도메인에 유용할지 확인할 수 있게 한다.
몇몇 데이터베이스 시나리오에서, 응용프로그램 개발자 환경은 정보 모델링에 불균형적인 영향을 줄 수가 있다. 예를 들어, 프로그래머의 생산성에 우선적으로 초점을 맞추고 있는 조직들은 프로그래밍 언어 프레임워크(일반적으로 객체기반 패러다임)와 저장소 문제(일반적으로 XML과 SQL) 사이의 “임피던스 불일치”이라 불리는 것들을 최소화 하고자 할 것이다. 극단적인 경우에 있어서, 이러한 접근은 이전의 DBMS 시기로 돌아가는 것으로 효율적으로 나타낼 수 있다. 프로그램 파일(program-have-file)을 정신적으로 반영하는 것은 정보관리를 굉장히 복잡하게 만들 수 있다. 데이터베이스 전문가에게는 역설적이지만, 이러한 접근은 일상적인 정보 관리 패턴이며 그것은 데이터 모델링 관점에서 재검토할 때 반드시 고려되어야만 하고, 그것은 우리가 데이터베이스 마켓 역학을 재검토하는 것처럼 우리가 다시 찾아가게 될 토픽이다.
요약: 정보 관리 프레임워크의 가치
리소스와 관계를 상호 보완적으로 집중시킨 프레임워크로 작업하고 개념, 논리, 물리 모델을 구별함으로써, 현재 데이터베이스 시장 변화가 서로 상대에게 어떻게 맞춰지는지를 탐색 가능하게 한다. 조직들은 아래와 같은 프레임워크 리스크를 가지고 일을 하지 않도록 해야 한다:
• 언제 무엇을 사용할지에 대한 불확실성, 데이터베이스 시스템과 모델링 툴 측면에서, 도메인을 위한 최적의 툴 대신 오히려 응용프로그램 개발자가 기술적으로 사용하고 그들이 가장 친숙하고 익숙하게 사용하는 툴이 종종 결정된다.
• 실제 정보 모델에 기반한 충돌 문제는 상황 합의의 부족으로 인한 대화 부족 및 오해에 의해서 빈번하게 발생한다.
• 아래의 내용들에 대한 불충분한 집중:
 응용프로그램/데이터 독립성, 이전 DBMS 시대의 프로그램 파일(program-have-files) 접근으로 돌아갈 가능성 초래
 개념, 논리, 물리 모델 독립성, 정보 작업자와 응용프로그램 개발자가 낮은 수준의 구현 고려사항으로 역효과적인 부담이 되는 결과 초래
• 현재 데이터베이스 시장 역학의 핵심인 관계형 DBMS와 XML DBMS 사이의 지속 가능성 및 상호 보완에 대한 적합 가능성의 낮은 평가
데이터베이스 시장 변화
이번 섹션은 현재 데이터베이스 시장 역학에 대한 높은 수준의 리뷰를 포함하고 있다.
RDBMS 재검토
지난 10년간 상용 RDBMS의 주요 벤더들에 대한 도전이 있었다. 그들은 RDBMS가 업무에 일반적으로 광범위하게 확산되는 IT 인프라 환경 속에서, 때로는 RDBMS 벤더사의 정책(예: 대중적이지 않은 가격과 라이선스 정책)부터 고객 서비스의 역효과적인 부분까지 여러 측면에서 문제가 발생했다. 많은 응용프로그램

개발자들이 데이터베이스 관리자(DBA)가 지나치게 보수적이거나 제어 지향적이라는 생각을 가지고 있어 DBA 직업 또한 어려움이 있었다.
또한 몇 가지 도전이 있었는데, 다음과 같은 RDBMS 기능에 대한 오랫동안 지속된 추정들이 그것이다:
• “웹 스케일” 컴퓨팅(예, 페이스북, 구글, 트위터, 기타 세계적인 서비스)에 대한 RDBMS의 적합성
• 빠르게 변경되는 응용프로그램 도메인 요구되는 유연성 또는 “민첩성”
• 응용프로그램/데이터 “임피던스 불일치”, 프로그래밍 프레임워크/SQL 바운더리에는 오랜 불만이 있으며, 프로그램 프레임워크와 XML 바운더리에 대한 불만 또한 증가 추세이다.
이러한 역학관계는, 오픈 소스 DBMS와 특별한 목적의 DBMS(예: 다른 DBMS 유형은 “웹스케일” 분석 및 정보 스트림 처리를 위해 홍보되었다) 출현과 함께, 그것이 “전통적인 DB 접근 방식의 마지막”이라는 주장 중 일부를 주도했다.
여전히 정보관리 혁신에 대한 충분한 여지가 있는 반면, 우리는 상용 RDBMS 제품과 오픈소스가 매우 강력하고 유연하며, 대용량 메모리 서버와 SSD(Solid State Disk) 스토리지의 주류로 채택된 바와 같이 그것들이 지속적으로 빠르게 발전될 것이라고 믿고 있다.
하지만, RDBMS를 사용하고 지지한다고 하더라도 현재 전례 없는 문제(기술적 및 정책적으로)에 직면하고 있으며, 이러한 문제는 아키텍트와 개발자가 RDBMS가 효과적으로 해결할 수 있는 것에 초점을 두기보다는 RDBMS가 어떻게 사용되는지에 관련을 짓는 부정적인 생각 때문에 아키텍트와 개발자를 힘들게 한다.
그림 4는 RDBMS가 이전 문서에서 소개한 프레임워크에서 어디에 적합한지에 대한 우리의 시각의 상위레벨 묘사이다. Resources Relations Conceptual Resources and links Entities, attributes, relationships, and identifiers Logical Model : Hypertext language: XQuery Model: extended relational Language: SQL Physical Indexing(e.g., scalar data types, XML, full-text), locking and isolation levels, federation, replication, in-memory databases, columnar storage, table spaces, caching, and more
그림 4: 통합 프레임워크의 RDBMS
XML 정보관리를 위한 XDBMS
XML 정보 관리를 위한 DBMS의 사용은 또 다른 중요한 데이터베이스 시장 변화이다. XML 정보 관리는 XML스키마, XPath, XSLT, XQuery, SQL/XML과 같은 관련 산업 표준을 구축하게 하는 등 몇 가지 주목할 만한 기회를 선사한다.
XML에 초점을 둔 정보관리 시스템은 XML 하이퍼텍스트 문서(리소스)와 XML 데이터(관계) 모두를 담당하는데 사용될 수 있다. 리소스를 위한, XML 시스템은 주로 초기 컨텐트/문서 관리 시스템의 대체에 유용하다. XML

데이터를 위한, 이 시스템은 주로 XML이 응용프로그램 간의 구조화된 데이터 교환을 직렬화하는 시나리오에 유용하다.
상당한 혼란이 XML 리소스와 관계 문제의 차이에 대한 불충분한 평가에서 발생할 수 있다. 모든 XML 정보 관리 도메인을 같은 방식으로 다루는 것은 마치 1980년대 후반의 불운의 “객체 데이터베이스” 제품과 관련된 “모든 것은 객체다”라는 접근법처럼 도움이 되지 않는다. 특히 지나치게 일반화된 유형이 정보관리에 미치는 영향을 충분히 고려하지 않는 프로그래머 환경에 주도될 때 그렇게 된다.
오늘날 XDBMS(XML DBMS)에 접근하는 두 가지 일반적인 접근법이 있다:
• 선도적인 상업용 RDBMS에 XML 모델 관리가 추가 된 하이브리드, 멀티모델 DBMS들. 이것은 상업용 RDBMS 벤더들의 주도하에 추구되는 방법이며 IBM, Microsoft, Oracle (실제로, 그들의 최신 버전을 RDBMS와 같은 범주에 넣는 것은 잘못된 명칭이다. 세 개의 벤더들 모두 이제 멀티 모델 관리 시스템을 제공하지만 RDBMS 협회는 쉽게 바꾸길 원치 않는다) 등이 있다. 벤더들은 SQL/XML 그리고 XQuery 지원을 포함한 그들의 XML 기능 연구와 개발에 매우 주목할 만한 투자를 하고 있다.
• 특화된 XML DBMS, 예를 들자면 오픈 소스 이니셔티브와 마크 로직 서버 상용 제품이다. 모던 XML DBMS는 상용 서버 하드웨어의 대용량 확장성을 위하여 구조화되었다.
그림 5: 하이브리드 DBMS (출처: IBM)
그림에서 제안된 바와 같이, 하이브리드 접근은 리소스에 집중된 개발자들이 관계적인 정보와 XML 정보 모두를 이용하여 작업을 할 때 XQuery 사용을 가능하게 한다. 그리고 관계에 집중된 개발자들은 같은 정보로 일하기 위한 XML 확장기능으로 SQL을 사용할 수 있다.
그림 6 통합 프레임워크에서 XDBMS가 적합한 부분 표시(하이브리드 X/RDBMS는 그림 4와 6에서 강조된 결합된 영역을 제공한다). Resources Relations Conceptual Resources and links Entities, attributes, relationships, and identifiers Logical Model : Hypertext language: XQuery Model: extended relational Language: SQL Physical Indexing(e.g., scalar data types, XML, full-text), locking and isolation levels, federation, replication, in-memory databases, columnar storage, table spaces, caching, and more
그림 6: 통합 프레임워크의 XDBMS

NoSQL
NoSQL은 “NoSQL”의 의미가 무엇이냐라는 것에 대한 명확한 의견 일치가 없기 때문에, 이는 데이터베이스 시장의 흥미로운 현상이다. 산업 이니셔티브처럼, NoSQL은 그것이 무엇인지 보다는 SQL 기반이 아닌 것을 정의하는 것에 의해 시작되었다. 그럼에도 불구하고, NoSQL 옹호자들은 RDBMS 업무에서의 일반적인 경험의 좌절 덕택에 수용적인 청중을 찾을 수가 있다.
NoSQL이 빠르게 발전되고 있다는 것이 중요하다. 그것은 처음에는 “단지 SQL은 거부한다!”라는 제안의 움직임처럼 받아들여졌다. 그러나, 지난 몇 년 이후, RDBMS에 대해 경쟁적인 자세 보다는 보완을 더 강조하여 “SQL만이 유일한 것은 아니다”라고 조용히 그리고 소급하여 재정의되었다.
그림 7은 NoSQL에 대한 위키에서 가져온 NoSQL 시스템 유형 분류체계이다.
그림 7: 위키피디아 NoSQL 분류
반면에 아티클에서 식별된 시스템의 여덟 가지 유형에 대한 리뷰는 이 문서의 범위를 넘어섰다. 그림 8은 이 문서에서 논의된 이전 토픽에 다양한 유형을 맵핑하는 방법에 대한 우리의 관점을 나타낸다.

그림 8: NoSQL 개념 맵핑
그림 8과 같이, NoSQL 필수요소(meme)는 아래의 내용들을 하나로 합친다:
• 문서 저장 필요 조건: XDBMS 접근법에 의해 최적으로 제공 (더 많은 혼란을 주어, XDBMS는 NoSQL 시스템의 서브 클래스로 간주된다).
• 물리 모델 우려 사항: DBA와 시스템 아키텍트가 집중해야 하는 요소 (그리고 RDBMS와 XDBMS의 경쟁 보다는 어느 것이 더 상호 보완적인지 고려한다)
• 객체 데이터베이스: 수십 년간 응용 프로그램 개발자들의 선호를 받고 있지만, 최소화된 “임피던스 불일치”라는 인식과 고유 정보 관리 타협이 불충분하다는 점으로 수십 년간 영향력을 갖기 위해 고군분투 해오고 있다.
• 시맨틱 모델: 이 문서의 범위는 아니지만 일반적으로 이것 또한 RDBMS와 XDBMS의 경쟁을 대체하여 더 상호보완 할 수 있다.
빅 데이터
“빅 데이터”는 부정확하게 정의된 또 다른 시장 변화이다. 많은 사람들은 빅 데이터가 NoSQL의 서브클래스가 될 것이라고 생각하고 있다. 빅 데이터는 일반적으로 응용프로그램 도메인과 관련이 있다:
• 정보 스트림 처리 시나리오: 예, 핸드폰 사용량, 센서 네트워크, 웹사이트 로그 분석 등
• 대규모-스케일 데이터 분석: 예, 구글은 비주얼 검색과 음성 인식 기술을 개선시키기 위하여 적용하였다.
하둡(Hadoop) 또한 빅 데이터와 많은 관련이 있다. 맵리듀스(MapReduce)와 구글 파일 시스템 등 구글 계획을 기반으로 만들어진 하둡은 분산 프로세싱용 아파치(Apache) 아키텍처로 주로 상업용 하드웨어의 네트워크 사용과 관련이 있다.
많은 선두 벤더들은 데이터 웨어하우징과 비즈니스 인텔리전스에 집중했고 고객에게 더 많은 가치를 제공하는 수단으로 하둡을 수용하게 되었다. 그러나, 2010년 11월 포레스터 리서치(Forrester Research)는 “DB 기술 혁신의 경계를 유지하라(Stay Alert to Database Technology Innovation)”라는 제목의 리포트에서 “BI 유스케이스의 90%가 대부분 50TB 미만의 사이즈이며 이를 위하여 관계형 DBMS면 충분하다”라고 언급했다.
그림 9 이 문서의 앞부분에 제시된 프레임워크에 빅 데이터와 관련된 견해를 나타낸다.

Resources Relations Conceptual Resources and links Entities, attributes, relationships, and identifiers Logical Model : Hypertext language: XQuery Model: extended relational Language: SQL Physical Indexing(e.g., scalar data types, XML, full-text), locking and isolation levels, federation, replication, in-memory databases, columnar storage, table spaces, caching, and more
그림 9: 통합 프레임워크의 빅 데이터
다시 말해서, 우리는 빅 데이터(NoSQL 유형의 나머지 분류체계 대부분도 포함)를 RDBMS와 XDBMS의 경쟁으로 접근하기 보다는 서로 더 상호 보완하고 물리 모델 문제에 주로 초점을 두는 것을 고려하고 있다.
클라우드
이 문서에서 다루는 데이터베이스 변화의 범위 중 마지막은 클라우드 데이터베이스 플랫폼의 출현이다. 클라우드 데이터베이스는 RDBMS, XDBMS, 그리고 파일 시스템에 기반을 둔 많은 대안으로 넓고 다양하게 구성되어 있으며, 선도적인 클라우드 데이터베이스는 다음과 같은 옵션을 포함한다:
• Amazon SimpleDB and RDS
• Google BigTable and MegaStore
• Microsoft SQL Azure
PaaS(Platform-as-a-service)는 일반적으로 여러 데이터베이스 서비스 옵션을 제공한다.
클라우드 데이터베이스 서비스는 중요한 데이터베이스 아키텍쳐 혁신과 전통적인 RDBMS의 향후 버전까지 적용될 수 있는 혁신을 제공하고 있다. 그러나 결론적으로 우리는 클라우드 데이터베이스를 별개의 데이터베이스 모델의 대안이라기 보다는 배포 옵션으로 여긴다. 클라우드 컴퓨팅은 장비 중심의 기능에 사용되는 자금을 운영비로 전환시킬 수 있으므로 클라우드는 또한 금융 회계 중심 결정 방안 중 하나이다.
데이터베이스 시장 변화: 정리
관계형 데이터모델링 고려사항을 리뷰 전에 정리하자면, 우리는 다음의 내용을 믿는다:
• 다음 사이에는 실질적이고, 지속적인, 시너지 관계가 있다:
 RDBMS
 XDBMS
 하둡(Hadoop)
 정보 관리 플랫폼으로서의 클라우드
• 상대적으로 말해, NoSQL과 빅 데이터 시장 밈(memes)은 잘못 정의되고 일시적이고 과대 포장되어 있다.

정보 모델링의 역할 재탐색
현재 데이터베이스 시장 변화는 다음과 같은 응답을 받을 자격이 있다: 새로운 현실은 새로운 행동을 유도해야 한다. 그러나, 유효성이 입증 된 오래된 행동은 아무렇게나 폐기 할 수 없다. 정보 모델링의 오랜 장점의 대부분은 유효성이 유지될 것이다.
오래된, 바뀌지 않은 현실
비록 정보관리 시장에 최근 및 향후의 변화가 흥미롭고 중요하긴 하지만 정보 모델링에 대한 대부분의 기본적인 현실은 변경되지 않는다. 어떤 경우에는 이러한 기본적인 현실을 존중하는 것이 그 어느 때보다 중요하다.
관심 사항의 분리
관심 사항의 분리는 설계의 노력과 그로 인해 얻어진 인공 산물을 구분 짓기 위한 노력이다. 관심 사항의 분리는 개념, 논리, 물리 모델링을 구분 짓는다; 세 가지 모델링은 각각의 다른 목표를 가지고 있으며 관련된 사람 또한 다르며, 다른 기술을 요구한다. 그러므로 설계자들과 요구사항 분석자들은 모델링의 이 세 가지 형식을 반드시 구분 지어야 한다.
마찬가지로, 관심사항의 분리는 프로세스와 데이터를 구분지어야 한다.
프로세스와 데이터 구분
모델러와 요구사항 분석가가 프로세스 요구사항으로부터 데이터 요구사항을 구분하는 것은 매우 중요한 정보이다. 프로세스 요구사항과 데이터 요구사항을 제대로 구분 짓지 못한다면 다음과 같은 광범위한 부정적인 결과에 도달할 것이다: 응용프로그램/데이터의 독립성 저하, 데이터모델과 그 기본이 되는 데이터베이스의 조기 노후화, 그리고 낮은 정확도의 데이터모델로 인한 저급의 정보 품질
정보 관리의 새로운 현실은 새로운 잘못된 인식을 초래했기 때문에 이 프로세스와 데이터 구분이라는 가장 좋은 방법은 새롭게 주목 받을 가치가 있다. 특히, 일부 설계자는 데이터 모델링을 메시지 모델의 설계(예를 들어 SOA 시스템을 위해)로 교체했다. 메시지 모델은 무엇보다도 가장 먼저 처리되는 아티팩트이다; 이것은 데이터 흐름 다이어그램의 일부분의 표현이다(결국 프로세스 모델이다). 메시지 모델 설계는 중요하지만 데이터 모델링의 대체가 될 수 없으며 똑 같은 잇점을 제공하지 못한다.
맥락적 합의
맥락적 합의는 모델러에게 개념 데이터 모델링의 중요한 가치를 인식시키기 위해 중요하다. 개념 데이터 모델링은 다음과 같은 정보의 의미에 대한 맥락적 합의를 설계하는 프로세스이다: 어떤 카테고리가 존재하는지, 카테고리에 어떠한 특성을 적용시킬 지, 어떻게 카테고리 간 상호 연관을 시킬지, 각각의 카테고리는 어떻게 다른 카테고리들과 구분 지을지, 그리고 어떤 비즈니스 용어를 해당 카테고리, 특성, 그리고 관계에 사용할지
정보 관리라는 새로운 현실에 대한 잘못된 인식은 개념적 데이터 모델링을 손상(또는 경솔하게 모든 것을 제거)시킬 수 있기 때문에 이 맥락적 합의라는 가장 좋은 방법은 새롭게 주목 받을 가치가 있다. 기술의 대부분은 NoSQL 필요조건(meme) 하에서 근본적으로 물리 데이터 모델링의 특성을 변경하였다. 그러나 물리 데이터 모델링의 특성의 변경은 반드시 개념적 데이터 모델링에 동일하게 반영시킬 필요는 없다. 개념적 합의는 “갖기에 좋은(nice to have)”가 아니다, 이 것은 다음과 같은 내용이 중요하다:
• 개념적 합의는 응용프로그램/데이터의 독립성에 핵심이다—데이터를 공유하는 다른 응용프로그램을 사용하는 개발자와 사용자는 반드시 공유하는 데이터의 의미에 동의해야 한다.
• 개념적 합의는 비즈니스 룰의 표현에 대한 기초를 제공한다—개념 데이터 모델에서 정의된 명사들은 처리 방식과 정책 요건을 공식화 할 비즈니스 룰의 오퍼랜드(피연산자;operand)로 제공된다.

사용자에게 알려진 메타모델
모델러, IT 전략가, 소프트웨어 아키텍트는 반드시 사용자가 다양한 개념적 메타-모델을 잘 알고 있다고 인식해야 한다. 사용자는 심지어 하나의 메타 모델을 또 다른 메타 모델로 전환할 수 있어야 한다; 네 가지의 메타 모델을 포함한 전형적인 식당의 메뉴로 예를 들어보겠다:
• 서술 데이터(Narrative data) – 예, 삼 대째 하고 있는 식당에 대한 기이한 역사
• 구조화된 데이터(Structured data) – 예, 식당에서 제공하는 음식 메뉴에 대한 이름, 번호, 설명, 가격 및 제공되는 시간
• 이미지 데이터(Image data) – 예, 몇 년 전의 식당 사진
• 지리 공간적 데이터(Geospatial data) – 예, 식당에 위치를 보여주는 지도
시스템 설계자는 편리한 메타 모델이더라도 만약 사용자의 생각을 혼동시킨다면 그 편리한 메타 모델을 선택할 권한이 없다.
정보 관리라는 새로운 현실은 전통적으로 분리되어 있는 콘텐츠와 데이터의 인공적인 벽을 무너트리기 때문에 사용자에게 알려진 메타모델이라는 방법은 새롭게 주목 받을 가치가 있다. 전통적인 인공의 벽이 무너지면, 데이터와 콘텐츠는 주로 큰 기업의 이익을 위해 뒤섞일 것이다. 그러나 이런 혼합은 사용자에게 알려진 개념 메타모델과 개발자가 선택한 구현 메타모델과의 연관 관계에 대해 신중하게 생각하는 개발자와 아키텍트들에게는 이득일 수 있다. 반대로, 사용자의 필요성이 아닌 쉬운 구현 방법을 기준으로 선택한 메타 모델의 개발자는 질 낮은 데이터 품질을 얻고 사용자의 혼란을 만든다.
사용자에 의해 선호된 메타데이터는 요구사항을 분석하는 동안 명확해지는 것을 알아두자. 즉, 만약 개념 데이터 모델링 표기법을 특정 메타 모델을 전제로 선정했다면, 개념 데이터 모델링은 작동될 수 없다.
주목할 만한 새로운 현실
데이터 모델링에 대한 기본은 변하지 않더라도, 데이터베이스 시장의 새로운 현실에는 일부 효과를 줄 것이다.
클라우드 컴퓨팅을 위한 데이터 모델링
클라우드 응용프로그램은 물리 데이터 모델링의 필요성을 감소시킬지도 모른다. 기업이 DB 설계 및 운영에 대한 부담을 외부의 클라우드로 이전한다면 기업은 더 이상 테이블스페이스, 인덱스 등에 대한 물리적 설계 결정을 내릴 필요가 없다.
그렇다고 해도 이것은 기업의 개념 모델링 책임을 덜어주지는 않는다. “클라우드 데이터베이스 사용”기술은 컨텍스트 합의에 대한 필요성을 미연에 방지하지는 않는다. 실제로, 클라우드는 개념 모델링을 고려하는 조직에는 사치이며 적절한 개념 모델링 수행에 시간을 들이거나 기존의 데이터베이스를 향상시키는 것이 더 필요할 수 있다.
개념과 논리 모델링의 차이점
정보관리의 새로운 현실은 개념 및 논리 모델링의 차이를 모호하게 할 것이다.
좋든 나쁘든 몇몇 기업들은 그들의 데이터 요구사항을 측정하고 수집하기 위해서 논리 모델링 기술을 사용해왔다. 이 기술은 완벽하지는 않지만 데이터 요구 사항을 논리 메타모델에 맞게 제공할 수 있다. 가장 일반적으로 사용되는 논리 메타모델은 다음과 같은 확장된 관계 모델과 연관이 있다: 엔티티-관계 모델링, 바커 표기법(Barker Notation), IDEF1X 등. 당연히 개념 데이터 모델링은 가장 일반적으로 자원보다는 관계에 적용된다.

정보관리에 있어서 새로운 현실은 아키텍트와 시스템 설계자가 관계에 최적화된 논리 표기법을 선택할 수 있게 한다: 예를 들어, HTML, XML 스키마 등. 비 계층 현상(Non-hierarchical phenomena)을 위해서 이러한 표기법은 낮은 정확도의 데이터모델 및 불완전한 사용자 요구사항을 얻게 된다.
요구사항 분석을 위한 적절한 단계는 개념 모델링 기술과 관계와 리소스 모두에 대한 요구사항을 표현할 수 있는 표기법 간의 관계를 다시 정립하는 것이다.
역설: 데이터 모델링에 대한 과소 투자
시장 역학의 변화는 IT 전략가를 단지 데이터 모델링의 과거와 새로운 현실에 대한 고민이 아닌 더 나아가서의 고려까지 하게한다; 과거(그리고 새로운 것)에 대한 망상은 유용하다. 역사적으로, 데이터 모델링 망상에 대한 부족한 투자는 부족한 결과를 초래해왔다.
문명의 역사에서, 나쁜 아이디어는 좋은 아이디어보다 수가 많다. 데이터 모델링에서도 다르지 않다; 그러므로 모든 시도들은 그 시도들에 대한 철저한 망상을 할 것이다. 그러나, 일부 망상은 특히 주목해야 한다:
• 데이터 모델링의 가치가 빈번하게 과소 평가되는 것
질 낮거나 불충분한 데이터모델링의 결과는 모델링 한 모델러에게도 즉각적으로 드러나지 않으므로 다른 사람들에게도 널리 인식되지 않는다. 질 낮거나 불충분한 모델링의 결과는 규제 기관에 의해 보고되는 데이터 품질 문제 등에 의해 나중에 분명해진다.
• 데이터 아티팩트가 아닌 코드/프로세스 아티팩트에 중점을 두고 모델링이 된 데이터 모델링은 큰 혼돈을 불러일으킨다.
IT 전략가들과 아키텍트들은 데이터 모델링에 충분한 관심을 가져야 한다. 코드 품질 측정처럼 데이터 품질 측정도 중요하다.
데이터 모델링의 광범위한 사용을 억제하는 다음과 같은 잘못된 망상들이 있다:
• 실제로는 아니지만, 자신들이 데이터 모델링을 하고 있다고 믿는 잘못된 몇몇 활동
• 예를 들어, 메시지 모델에 맞는 XML 스키마를 설계하는 작업. 이것은 프로세스 모델링이지 데이터 모델링이 아니다.
• XML 기반의 정보 관리를 위해 데이터 모델링은 불필요하다고 믿는 몇몇의 IT 전략가의 잘못된 믿음
데이터가 관계형 데이터베이스에서 표현되든 XML 파일에서 표현되는 맥락적 합의는 언제나 중요하다.
요약 및 권장사항
정보 관리에 관여할 수 있는 흥미로운 시간이다. 새로운 시장의 현실은 수십 년 동안 IT를 괴롭힌 특정 문제에 대한 해결책을 제공한다. 그럼에도 불구하고, IT 전문가들은 자신들의 시도했고 입증 받은 최고의 방법들을 계속 활용할 수 있다.
소프트웨어 기능, 하드웨어 기능, 그리고 변화하는 가격/성능 비율에 놀라운 개선이 전통적인 RDBMS에 의해 해결되었던 문제의 규모와 범위를 더 확대할 것이다. 이러한 개선은 제한된 형태의 디스크 기술과 대규모 메모리 범용 서버를 포함한다.
배포 옵션으로, 클라우드 형식의 데이터베이스로 움직이는 부분의 일부를 제거하여 정보 아키텍쳐를 단순화 할 수 있으며, 내부 IT 조직의 운영 부담을 줄일 수 있다. 클라우드로 개념 모델링(비록 기술을 확대해야 하지만)을 수행하는 모델러를 줄일 수 있다.

단순화를 위한 또 다른 기회: XML 기반의 데이터 관리(XDBMS 또는 하이브리드, 멀티 모델 DBMS)와 움직이는 부분(웹 콘텐츠 관리, 기업 콘텐츠 관리, 파일 관리)을 대체할 수 있는 관계와 리소스의 관리 조정에 대한 새로운 접근. 또한, SQL과 XQuery의 결합으로 응용프로그램의 스택을 간소화, 선억적 개발 최대화, 로우 레벨의 스크립팅 및 프로그래밍 최소화가 가능하다.
구글 맵리듀스(MapReduce) 패러다임의 구현과 근사(특히, 하둡)는 범용 하드웨어의 네트워크에서 분산 처리를 위한 실행가능하고 유용한 프레임워크를 제공할 것이다.
필수요소 “NoSQL” 시장은 사라지고 다음과 같은 것으로 대체될 수 있다: a) NoSQL 요지를 포함하기 위한 개별적인 기능과 기술의 배포와 b) 더 나은 정보, 전통적인 RDBMS 기술에 대한 지식은 현대 정보 관리의 기초 주력 유지
권장: 전략적 합의를 수립하라
새로운 시장 상황에 대응하여, 기업들은 전략적 비전과 장기간 플랜을 세워야 한다. 비전은 데이터 거버넌스와 정보 품질, 정보 라이프사이클 관리, 보안 및 리스크 관리나 다른 비즈니스 사업에도 영향을 미치게 되므로 IT에만 국한되어서는 안 되며 기업 전체적인 부분을 다루어야 한다.
플랜은 기술의 효율적인 사용 및 선택에 대한 목표를 수립해야 한다. 이러한 목표는 XDBMS 또는 하이브리드 다중 모델 DBMS의 현명한 사용으로 웹 컨텐츠 관리, 기업 컨텐츠 관리, 파일 관리 도구들을 단번에 대체할 수 있는 것과 같이, 일부 기술에 대한 해체를 어떻게 효율적으로 할 것인가에 대한 내용 또한 포함하고 있어야 한다.
또한 더 이상 새로운 시장 현실에 적용되지 않는 내용들을 수정하고, 모범 사례를 다시 한 번 분명하게 설명해야 한다. 뿐만 아니라 모범 사례는 프로그래머, 모델러, 정보 아키텍쳐 및 기타 IT 실무자들이 인정할 수 있도록 IT 보상 구조를 명확하게 하고 개선해야 한다.
권장: 데이터 모델링을 재조명하라
모범 사례는 반드시 데이터 모델링이 포함되어 있어야 하며, 모델링 관련 사례는 언어, 문화, 분류, 기술의 첫 번째 원칙에서 시작됨을 다시 한 번 강조해야 한다. 모델링 모범 사례는 요구사항의 분리를 반드시 이행해야 한다. IT 보상 시스템은 모델링을 장려하고 요구할 필요가 있으며, IT 메트릭스는 정보 품질뿐만 아니라 코드 품질까지도 보상을 확장해야 한다.
권장: 관계와 리소스간의 상호작용을 감사하라
새로운 시장 변화는 컨텐츠 관리에서 데이터 관리를 분리하는 인위적인 벽을 해체할 것이다. 관계와 리소스 합류의 결과는 새로운 효율성을 제공할 뿐만 아니라 오류에 대한 새로운 기회를 소개할 것이다. 이와 같은 오류들을 방지하기 위해 IT 전략가와 실무자들은 리소스와 관계 사이의 상호작용에 대한 전문 지식을 갖추어야 한다. 이러한 전문지식은 기본에 바탕을 둔 메타 모델들에 대한 철저한 검토에서 시작된다:
• 확장된 관계형 모델 (선호하는 DBMS 벤더사에 의해 구현된 단순한 모델이 아닌)
• 하이퍼텍스트 정보 모델 (HTML이나 XML이 아닌)
권장: XQuery를 배우고 활용하라
많은 경우에 있어서, 관계를 관리하기 위한 SW 공학 모범사례는 관리 자원에 동일하게 잘 적용된다. 일례로, 선언적 프로그래밍은 절차적 코드에 바람직할 것이다. XQuery는 XML 데이터에 대응하여 선언적 쿼리를 기술하기 위한 선택적 언어아니다. 정보관리의 새로운 현실에 투자를 하기 원하는 IT 실무자는 XQuery를 배워야만 한다.

추가 정보
주요 데이터베이스 시장 변화와 데이터 모델링, 정보 관리, 협업에 대한 결과에 대한 보다 자세한 정보는 다음 링크를 통해 얻을 수 있다: www.okellyassociates.com
엠바카데로 테크놀로지는, 1993년에 설립한 데이터베이스 툴 제작사입니다. 2008년에 볼랜드의 개발툴 부문 「CodeGear」를 합병하였습니다. 현재는 애플리케이션 개발자와 데이터베이스 기술자가 다양한 환경에서 소프트웨어 애플리케이션을 설계, 구축, 실행하기 위한 툴을 제공하는 최대 규모의 독립계 툴 제작사입니다. 미국 기업의 총수입 랭킹 「포춘 100」중 90개 기업과 전세계 300만 이상의 고객이, 엠바카데로의 RAD Studio®, Delphi®、C++Builder® 등 개발툴 제품과 ER/Studio®、 DBArtisan®, RapidSQL®, DB PowerStudio® 등 데이터 모델링 및 DB관리 제품을 채용해, 생산성의 향상과 혁신적인 소프트웨어 개발을 실현하고 있습니다. 엠바카데로 테크놀로지스는, 샌프란시스코에 본사를 두고, 세계 각국에 지사를 전개하고 있습니다. 보다 자세한 내용은, http://www.devgear.co.kr를 참고하시기 바랍니다.

XML, NoSQL, 빅데이터, 클라우드로 옮겨가는 시장 상황 속, 데이터모델링 여전히 중요한가

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (19)

Similar to XML, NoSQL, 빅데이터, 클라우드로 옮겨가는 시장 상황 속, 데이터모델링 여전히 중요한가

Similar to XML, NoSQL, 빅데이터, 클라우드로 옮겨가는 시장 상황 속, 데이터모델링 여전히 중요한가 (20)

More from Devgear

More from Devgear (20)

XML, NoSQL, 빅데이터, 클라우드로 옮겨가는 시장 상황 속, 데이터모델링 여전히 중요한가