데이터베이스

[정보처리기술사][데이터베이스] [DB] DB확장을 하는 두가지 방법- 스케일 아웃(scale out)과 스케일 업 (scale up)

졸리운_곰 — Sun, 07 Mar 2021 01:10:11 +0900

[정보처리기술사][데이터베이스] [DB] DB확장을 하는 두가지 방법- 스케일 아웃(scale out)과 스케일 업 (scale up)

[DB] DB확장을 하는 두가지 방법- 스케일 아웃(scale out)과 스케일 업 (scale up)

서버를 운영하다보면 이용자의 증가, 서비스의 확장 등의 이유로 더 많은 용량과 성능이 더 필요하게 된다.

이때, 수평적으로 부하를 분산하는 스케일 아웃(scale out) 방식으로 확장을 할 지 아니면

해당 서버의 용량 자체를 올리는 스케일 업 (scale up) 방식으로 확장을 할지 선택해야 한다.

그렇다면 두 가지 방식이 각각 어떤 차이가 있을까?

출처-한국데이터산업진흥원

???? 스케일 아웃
‘스케일 아웃’이란 접속된 서버를 여러 대 추가하여 처리 능력을 향상하는 방법이다. 수평 스케일로 불리기도 한다. 예를 들어, 하나의 처리 능력을 가진 서버에 동일한 서버 6대를 더 추가하여, 총 7의 처리 능력을 만드는 것이다.

서버가 여러 대가 되기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 ‘로드밸런싱’이 필수적으로 동반되어야 한다. 그리고 스케일 아웃의 경우, 서버 한 대가 장애로 다운되더라도 다른 서버로 서비스 제공이 가능하다는 장점이 있다.

각각의 처리는 비교적 단순하지만 다수의 처리를 동시 병행적으로 실시하지 않으면 안 되는 경우 적합한데 갱신 데이터의 정합성(데이터가 서로 모순 없이 일관되게 일치해야 하는 경우) 유지에 대한 요건이 별로 어렵지 않은 경우에 적절하다. 즉 높은 병렬성을 실현하기 쉬운 경우이다. 모든 서버가 동일한 데이터를 가지고 있어야 하므로, 데이터 변화가 적은 ‘웹 서버’에 적합한 방식이며, 웹 서버 펌, 데이터가 읽기 전용인 검색엔진 데이터 분석 처리 VOD(주문형 비디오) 일부의 과학기술 계산, 메일 서버나 게시판 등의 어플리케이션 등에 적용할 수 있다.

???? 스케일 업
‘스케일 업’은 서버에 CPU나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 방법을 의미한다. 예를 들어, 하나의 처리 능력을 가진 서버 한 대를 7의 처리 능력을 가진 서버로 그 자체의 처리능력을 향상시키는 것이다. 수직 스케일로 불리기도 한다.

CPU나 RAM을 추가하기 부품을 장착할 수 있는 여유 슬롯이 있어야 하며, 그렇지 않은 경우 서버 자체를 고성능으로 교체하는 것이 필요하다.스케일 업의 경우, 서버 한 대로 모든 부하가 집중되므로 장애 시 영향을 크게 받을 수 있는 위험성이 있다.

그리고 한 대의 서버에서 모든 데이터를 처리하므로 데이터 갱신이 빈번하게 일어나는 ‘데이터베이스 서버’에 적합한 방식이다. 빈번히 갱신으로 여러 대의 서버에서는 정합성(데이터가 서로 모순 없이 일관되게 일치해야 하는 경우) 유지가 어렵기 때문이다.

지금까지 데이터베이스 확장이 대부분 스케일아웃의 형태였다면, 고성능 스토리지의 출현과 지속적인 가격 하락으로 인해 이제 스케일아웃과 스케일업을 동시에 고려할 수 있는 하드웨어 환경이 됐다. DB의 확장 및 통합에 정답은 없으며 각각의 장단점이 뚜렷하기 때문에 제공하고자 하는 서비스의 특성과 사용량을 고려하여 최적의 방식을 선택할 수 있게 되었다.

참고

한국데이터산업진흥원

https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=13&dbnum=185192&mode=detail&type=techreport

출처: https://devuna.tistory.com/73 [튜나 개발일기????]

DB와 미들웨어 간 인터페이스에 대한 변화와 전망(2회)

가을의 곰 — Fri, 18 Jan 2013 13:36:44 +0900

DB와 미들웨어 간 인터페이스에 대한 변화와 전망(2회)

No SQL 발전에 따른 미들웨어와 DB 간 인터페이스

필자는 지난 첫 번째 연재에서 미들웨어와 데이터베이스 간 인터페이스가 미들웨어의 변화에 따라 어떠한 방향으로 발전되고 있는지를 알아보았다. 관계모델 기반의 데이터 구조에서 객체모델로 조금씩 변화하고 있는 모습들을 소개하였다. 2회에서는 NoSQL을 중심으로 데이터베이스의 변화를 주도하고 있는 빅데이터가 가지는 인터페이스 특징과 발전방향을 통해 궁극적으로 애플리케이션과 데이터가 어떻게 결합될 수 있을지를 조심스럽게 전망해 보고자 한다.

빅데이터의 등장

요즘 데이터베이스 분야에서 변화를 이끌고 있는 주제는 단연 빅데이터라고 할 수 있다. 대부분의 데이터에 대한 관리는 오랫동안 발전되면서 안정적인 성능을 발휘해 주고 있는 RDBMS 제품들에 의존하고 있으며, 지금까지도 만족스럽게 활용하고 있다. 문제는 최근 들어 모바일, 소셜 네트워크 등 사람들이 인터넷에 의존하는 방식이 다양해지고, 데이터의 형태도 멀티미디어화 되면서 사람들의 활동을 통해 발생하는 디지털 콘텐트의 양이 급증하고 있다는 것이다.

데이터는 사람이 아닌 기기들을 통해 우리가 알지 못하는 사이에도 지속적으로 발생된다. 감시 카메라의 영상정보, 서버의 로그정보, RFID를 통한 물류정보 및 센서, GPS를 통해 수집되는 정보 등 다양한 기기들을 통해 꾸준하게 발생되는 데이터가 넘쳐나고 있으며, 이러한 데이터를 그냥 방치할 것이 아니라 분석함으로써 좀 더 유용한 정보로 활용하는 것이 바람직하다는 생각을 바탕으로 빅데이터 솔루션들이 발전하고 있다.

데이터를 단순히 저장 및 보관하고자 한다면 별 문제가 없겠지만, 이렇게 방대한 양의 데이터를 기반으로 정보를 분석하고자 한다면 기존의 아키텍처로는 여러 가지 문제가 발생하게 될 것이다. 먼저, 저장공간 확보를 위한 하드웨어 비용이 문제가 될 것이고 값비싼 스토리지 증설에 어려움을 느낄 것이며, 혹시 이를 해결하였다고 하더라도 대량의 데이터를 처리하기 위한 적절한 아키텍처의 적용 없이는 필요한 수준의 성능을 유지하기 어려울 것이다.

하나의 시스템을 구성하고 서비스를 시작하는 단계에서는 일반적으로 이미 많은 검증을 통해 정착된 기술로서 RDBMS를 활용하게 된다. 이에 따라 RDBMS가 기초하고 있는 소위 ‘Codd’s 12 rules’를 모범적으로 지키게 될 것이다. 하지만 사용자가 늘어나면 읽기 성능을 높이기 위해 캐시(Cache)를 적극적으로 활용하게 될 것이고, 캐싱(Caching)된 내용과 저장된 내용의 일치 여부는 그다지 중요하지 않게 여겨질 수 있다.

빈번하게 조인(Join)이 많이 사용되는 경우, 정규화(Nomalization)를 통해 중복 데이터를 최소화하는 구조를 포기함으로써 최대한 단순한 질의(Query)만을 유지하는 방식으로 성능을 확보하는 것이 바람직할 수 있다. 그리고 인덱스(Index)를 많이 사용하는 경우, 쓰기 성능에 많은 영향을 끼치게 되므로 인덱스도 상당부분 포기해야 할지 모른다. 한마디로 우리가 당연하게 여기고 있는 RDBMS의 기본법칙들이 깨지게 되는 것이다.

이러한 상황을 극복하기 위해 필요한 솔루션으로 등장한 것이 NoSQL 데이터베이스라고 이해하면 좋을 것이다. RDBMS와 NoSQL의 차이를 정리해 보면 아래의 표와 같다.

NoSQL 데이터베이스들도 나름의 해결방식을 통해 발전하고 있는데 대표적인 형태가 Column, Document 혹은 Key-Value 기반의 데이터 구조를 취하고 있는 것들이다. 하나의 Index를 통해 이미 정렬된 데이터 구조를 취하고 있으며, 스키마 구조를 갖고 있지 않기 때문에 구현하고자 하는 애플리케이션의 로직에 따라 데이터의 구조와 사용방법이 영향을 받게 되어 있어 설계 시 주의가 필요하다.

여기에 Graph 이론에 기반한 Graph 데이터베이스도 좀더 객체기반의 데이터 구조에 부합되고 소셜 네트워크와 같이 관계를 통해 파악되는 데이터 구조를 형상화하고 활용하는 데 유리한 점이 많아 주목 받고 있다. <그림 2>은 ‘Big Data right now’(2012.10.27)에서 발표 자료로 인용된 데이터베이스의 분류를 도식으로 표현한 것이다.

인터페이스의 변화

RDBMS 제품들을 통해 많이 활용되고 있는 SQL(Structured Query Language)은 1974년 RDBMS의 개념이 자리잡으면서 처음 등장하여 1986년에 ANSI(American National Standards Institute) 표준으로, 그리고 그 이듬해인 1987년에 ISO(International Organization of Standards) 표준으로 자리잡았다. 지속적인 규격의 보완을 거쳐 현재 ‘SQL:2011’을 가장 최신 표준으로 유지하고 있다.

SQL은 RDBMS의 발전과 그 길을 함께 해온 만큼 데이터의 조회-생성-변경-삭제뿐만 아니라 스키마의 생성과 변경 및 권한설정 등 RDBMS의 전반적인 기능들을 모두 SQL을 통해 이용할 수 있도록 적용되어 있다. 이러한 SQL의 역할로 인하여 그 동안 무수히 개발되어온 RDBMS 기반의 분석, 검색, 추출 및 동기화를 위한 솔루션들과 ERP, CRM 등 패키지 애플리케이션들은 모두 SQL 인터페이스를 통해 비즈니스 로직과 데이터를 결합시켜 사용되어 왔다.

처음 NoSQL이 빅데이터의 해결책으로 소개되던 때에는 그 적용분야가 주로 인터넷 포털 서비스 업체의 검색엔진이나 소셜 네트워크 등 인터넷 서비스에 국한되어 있어 서비스 개발과 함께 적용이 되면 수정사항이 적어 API 방식을 활용하는 데 문제가 없었다. 하지만 빅데이터 솔루션의 적용범위가 확대되면서 매번 API를 수정해야 하는 번거로움을 줄이고 SQL 기반으로 개발된 솔루션들과 쉽게 통합할 수 있는 방법들을 고민하게 되었다.

이러한 고민 속에서 탄생한 것들이 Pig, Hive, Big Query 등이다. Pig는 야후에 의해, Hive는 페이스북에서 개발되었다. 모두 Hadoop의 HFS(Hadoop File System) 상에서 MapReduce 기반의 데이터 처리를 API를 통하지 않고 스크립트 언어 기반으로 처리하고 그 결과를 얻을 수 있도록 지원한다. 구글에서 Dremel이라는 질의 처리엔진을 기반으로 REST(REpresentational State Transfer) 인터페이스를 통해 질의하고 JSON(Javascript Object Notation) 형식으로 결과를 확인할 수 있는 서비스를 제공하는데 이를 Big Query라고 한다.

이들 모두 SQL과 같은 편의를 제공하기 위해 제시되고 사용되고 있지만, NoSQL 기반의 데이터 처리는 기본적으로 MapReduce를 통해 배치방식으로 처리되기 때문에 데이터 분석에는 어느 정도 만족스럽다. 하지만 실시간 데이터 처리에는 미흡한 부분이 존재한다. 최근 이를 보완하려는 움직임이 보인다. 필자는 이러한 움직임의 해결책을 XTP(Extreme Transaction Processing)가 제시하고 있다고 본다.

XTP(Extreme Transaction Processing)

XTP는 다른 이름으로는 IMDG(In-Memory Data Grid)라고도 불린다. 애플리케이션과 데이터베이스 간에 발생하는 트랜잭션을 x86 기반의 범용 서버들을 이용하여 메모리 기반의 저장소를 구성하고 트랜잭션 정보를 저장한다. 메모리 입출력의 빠른 성능으로 인해 빠른 응답속도와 백엔드 데이터베이스의 부하 경감 효과를 얻을 수 있어 트랜잭션 처리성능을 극대화한다. 물론 이렇게 저장된 트랜잭션은 백엔드 데이터베이스에 시간을 두고 반영되어 데이터의 영속성을 보장한다.

메모리 기반으로 객체정보를 분산 저장하고 이를 검색-참조하여 병렬처리를 유도함으로써 MapReduce 처리방식과 동일하게 처리함으로써 성능을 확보하고, 데이터의 복제를 통해 안정성과 고가용성을 지원하는 저장소 기술이다. 저렴한 서버를 통해 손쉬운 대규모 확장성을 지원하기 때문에 저렴한 비용으로 기존 시스템 아키텍처의 변경 없이 안정적으로 성능저하 문제를 해소할 수 있는 점이 가장 큰 매력이라고 할 수 있다.

단순히 트랜잭션에 대한 분산 캐시 플랫폼(Distributed Caching Platform)으로 생각될 수도 있지만, 발전 가능성에 대한 숨은 잠재력을 아키텍처에서 엿볼 수 있다. IMDG는 다양한 분산 애플리케이션들로 하여금 메모리 기반의 데이터 객체를 관계모델이 아닌 객체모델 그대로 공유하여 활용할 수 있는 방법을 제시한다. 이러한 객체들은 하나의 Key 속성을 통해 일관성있게 참조될 수 있으며, 다른 속성들을 조건으로 함께 활용하여 필요한 정보를 추출할 수 있도록 한다.

객체정보의 변화를 분산환경에서 서로 인지할 수 있도록 이벤트 모델을 운영할 뿐만 아니라 질의를 통해 애플리케이션에서 객체의 생성-참조-변경-삭제(CRUD)를 처리할 수 있도록 API를 지원한다. 저장소도 백엔드 RDBMS, 파일 및 XML 등 영속성 있는 형태로 유지할 수 있어 시스템의 유지보수성을 높였으며, 설정에 따라 동기식으로 디스크에 쓰는 방식의 Write-Through와 비동기식으로 지연 반영하는 Write-Behind로 각각 운영할 수 있다.

많은 IMDG 제품들은 DBMS에서 트리거에 해당하는 에이전트와 저장 프로시저에 해당하는 분산함수들을 객체정보와 공존할 수 있도록 하고 있다. 이렇게 함으로써 대용량 정보를 처리하는 데 있어서 데이터의 이동을 최소화해 처리를 수행함으로써 적정 성능을 유지할 수 있다고 설명한다. 여기서 주목할 점이 바로 비즈니스 로직과 데이터가 공존하는 객체모델을 클라우드 아키텍처 상에서 실현하는 것이 가능할 것이라는 기대감이다.

아직은 기술개발의 초기에 해당하고 앞으로의 성장 가능성에 비추어 보면 성숙도가 낮은 상태이므로, 폭넓게 적용되기까지는 상당한 기간 검증과 표준화를 거칠 것으로 생각된다. 하지만 이러한 개념을 클라우드 아키텍처 상에서 실현한다면 현재 표준 구성으로 자리잡고 있는 3계층(Tier) 아키텍처에 이어 새로운 컴퓨팅 패러다임으로 화려하게 등장할 가능성이 높은 기술로 생각된다.

클라우드로의 통합

하드웨어의 발전과 부품생산의 효율화로 CPU, 메모리 및 디스크의 가격은 계속 떨어져 왔고 성능은 날로 향상되어 왔다. 하드웨어 아키텍처도 메인프레임(IBM, 후지쯔, 히타치)과 유닉스(HP, IBM, 후지쯔, 오라클)를 거쳐 x86 기반의 범용서버(HP, IBM, 후지쯔, 오라클, 델, 시스코)로 오면서 좀 더 늘어난 벤더들의 경쟁으로 인하여 서버 가격을 더욱 끌어내릴 수 있었다. 여기에 IT를 서비스 형태로 제공할 수 있게 되어 IT의 혜택을 누구나 싼값에 누릴 수 있게 됐다.

32비트 OS의 경우 메모리를 4GB(=232)까지만 참조할 수 있지만 64비티의 경우 16엑사바이트 (=264)까지 참조가 가능하다. 메모리의 집적도도 올라가면서 대량의 메모리가 장착된 서버 사용이 가능하다. 이러한 변화는 인메모리 기반 소프트웨어 솔루션의 성장을 유도하고 있으며, 기존의 디스크 기반 제품들에 이어 점차 각광받게 될 것으로 예상된다.

하지만 이러한 기대에도 불구하고 애플리케이션들의 클라우드로의 이행은 그렇게 순조롭지만은 않은 듯 하다. 성능 및 안정성에 대한 낮은 신뢰도, 데이터에 대한 보안정책 미비 등 다양한 이유들이 존재할 것이다. 하지만 우리가 여기서 이야기하고 있는 애플리케이션 플랫폼 관점에서 바라보면, 이는 CEAP(Cloud enabled application platform)을 제공하는 업체들 간에 표준화가 뒤따르지 않으면서 특정 벤더 종속을 우려한 때문이라고 볼 수 있다.

모든 벤더들이 CEAP에 대한 대안들을 제시하고 있지만, 기존의 아키텍처를 그대로 유지하는 방식으로 제공되기 때문에 높은 확장성, 성능 및 가용성을 갖춘 거대한 규모의 클라우드 애플리케이션 플랫폼과는 거리가 있기 때문에 새로운 아키텍처의 시도와 기술의 표준화가 뒤따라야 할 것이다. 새로운 아키텍처의 시도로 앞에서 소개한 XTP(Appistry, GigaSpaces, maatG and Paremus)가 주목을 받고 있다. 이를 기반으로 발전되는 모습을 기대해 볼만 하다.

결국 우리가 이야기해 온 미들웨어와 데이터베이스 간의 인터페이스는 클라우드 컴퓨팅 기술을 통해 통합될 가능성이 점쳐지고 있다. 물론 실제로 실현되기까지는 시간이 많이 걸릴것이고 그 때까지는 수많은 기술의 홍수 속에서 여러 아키텍트분들은 최적의 솔루션을 찾기 위해 고군분투하게 될 것이라는 것을 짐작할 수 있다.

이제 클라우드 애플리케이션 플랫폼에서 갖춰야할 기술들은 무엇이 있을지 나열해 보는 것으로 글을 마무리하고자 한다. 고도로 분산 저장된 데이터를 적정 성능을 발휘하면서 처리하기 위해서는 병렬처리가 기본이 되어야 할 것이다. 그리고 병렬처리를 통한 성능개선 효과를 극대화하기 위해서는 데이터의 분산이 적절히 잘 분포될 뿐만 아니라 다른 노드로 복제되어 있어야 가능하다.

데이터의 복제는 장애 극복을 통한 고가용성과 동일한 데이터에 대한 경합상황을 회피함으로써 성능에 미치는 영향을 최소화할 수 있도록 해 준다. 자주 접근되는 정보에 대해서는 최대한 메모리에 상주할 수 있도록 해야 하며, 특정 객체정보가 변경되면 분산된 정보도 함께 변경되어 정보의 일관성을 유지할 수 있도록 이벤트 기반 통신이 지원되어야 한다.

- 병렬처리 (Parallelization)
- 데이터 분산저장(Partitioning)
- 데이터 복제(Replication)
- 메모리 기반(In-Memory)
- 이벤트 기반 통신(Event-driven Communication)

필자는 첫 회 연재를 통해 객체모델은 메모리, 관계모델은 디스크라는 하드웨어를 기반으로 최적화되면서 발전되어 온 모델이라고 설명한 바 있다. 메모리를 활용한 기술이 대거 등장하고 클라우드 애플리케이션 플랫폼 기술이 정착되면 결국 객체모델 하나로 애플리케이션을 설계하고 관리할 수 있는 상황이 올 수도 있지 않을까 조심스럽게 예상해 본다.

출처 : 한국데이터베이스진흥원

제공 : DB포탈사이트 DBguide.net

미들웨어 발전 방향에 비춰본 DB 인터페이스의 변화

가을의 곰 — Fri, 18 Jan 2013 13:28:58 +0900

미들웨어 발전 방향에 비춰본 DB 인터페이스의 변화

DB와 미들웨어 간 인터페이스에 대한 변화와 전망(1회)

미들웨어 발전 방향에 비춰본 DB 인터페이스의 변화

데이터베이스와 미들웨어는 이제 시스템을 구성하는 데 있어서 당연히 필요한 구성요소로서 정착됐다. 하지만 이들을 엮기 위한 인터페이스를 어떻게 구성할 것인가는 여전히 시스템 아키텍트들의 고민거리가 아닐 수 없다. 그리고 미들웨어와 데이터베이스는 각각의 발전방향을 갖고 지금도 진화를 거듭하고 있으니 이는 영원한 우리들의 숙제가 아닌가 싶다. 필자는 2회에 걸쳐 여러 미들웨어와 데이터베이스의 발전 추세에 비춰 변화하는 인터페이스를 살펴보고 향후 전망을 알아보고자 한다.

데이터베이스와 미들웨어의 차이

IT 업무 시스템의 구현에 있어 ①클라이언트 ②미들웨어 기반의 애플리케이션 서버 ③데이터베이스로 이뤄진 3계층(Tier) 구조가 아키텍처의 개방성 및 효율성과 함께 확장을 비롯한 유지 보수의 편의성이 입증되면서 표준 구성으로 받아들여지고 있다.

하지만 미들웨어와 데이터베이스의 이질감은 어디에서 비롯된 것일까? 필자는 그 이유를 근본적인 하드웨어의 차이에서 찾을 수 있다고 본다. 미들웨어는 메모리에 인스턴스 형태로 존재하고, 클라이언트 혹은 데이터베이스로부터 제공돼 메모리로 옮겨진 정보를 CPU를 이용해 연산을 수행한다. 그 결과를 데이터베이스에 저장하게 되며, 데이터베이스는 이를 영속적인 저장 장치인 디스크에 기록하게 된다.

메모리에서는 주소 값을 참조해 자유로운 입출력이 가능한 반면, 휘발성으로 영속적인 정보관리가 되지 않는다. 하지만 디스크는 비휘발성으로 정보의 반영구적인 보관이 가능하고, 장치의 특성 상 파티션을 통해 분할된 블록 단위로의 입출력에 최적화된 구조를 취하고 있다. 이렇게 하드웨어적인 특성 차이로 인해 주어진 제약 조건 하에서 각각 발전돼 오면서 정보를 다루는 방식에서도 차이를 갖게 됐다.

신속한 Random Access에 유리한 메모리는 참조 형식의 객체모델(Object Model)을 가상머신 기반에서 실현하는 것을 가능하게 하는 반면, Sequential Access를 위주로 디스크에서 블록 단위로 데이터를 검색해 필요한 테이블의 레코드 정보에 대한 연산을 처리하는 방식은 관계모델(Relational Model)에 적합하다. 물론 디스크에서의 Sequential Access에 따른 비효율성은 인덱스(Index)를 채용함으로써 보완됐다.

일찍이 기업용 애플리케이션에서는 모델 엔티티 사이의 관계에 데이터베이스 테이블과 외래 키를 사용했다. 애플리케이션은 단순히 데이터베이스를 기반으로 하는 모델에 대한 뷰와 쿼리 실행을 위한 방법으로만 여겼던 적이 있다. 이는 3계층 아키텍처가 자리잡기 이전 많이 활용되던 클라이언트-데이터베이스로 구성된 2계층 아키텍처를 떠올려 본다면 이해가 쉬울 것이다

최근 애플리케이션 설계의 경향은 데이터베이스의 관계모델 기반의 모델링에서 애플리케이션의 객체모델 기반의 모델링으로 옮겨가고 있다. 이제 데이터베이스는 단순하게 객체 구조에 정의된 영속성 정보를 저장하는 메커니즘으로 인식되고 있다. 이러한 변화를 주도하는 요소들은 다음과 같은 장점들에 기인한다.

- 객체를 중심으로 영속성정보와 객체가 수행하는 행위의 통합
- 느슨한 결합을 갖는 애플리케이션 컴포넌트들의 용이한 운용으로 유연성 향상
- 관계모델을 통해 표현되지 못하는 객체모델 기반의 풍부한 연관관계 표현
- 특정 데이터베이스 플랫폼에 대한 고도의 독립성

관계모델에 비해 객체모델이 좀 더 현실 세계의 실체들을 애플리케이션에 반영하는 데 유리하기 때문에 객체모델을 강조하는 경향은 앞으로도 지속될 것으로 예상된다. 그렇다면 이렇게 이질적인 모델들이 3계층 아키텍처를 기반으로 통합되기 위해서는 무엇이 필요할까?

이러한 변화의 중심에 ORM(Object-Relational Mapping)이 있으며, 이를 통해 애플리케이션의 객체모델이 일관된 방법으로 데이터베이스의 영속성 정보와 결합할 수 있는 다양한 방법들로 발전되고 있다. Hibernate, iBATIS, Apache OJB, JDO(Java Data Objects), TopLink, JPA(Java Persistence API) 등이 그들이며, 이러한 도구들은 객체모델을 관계형 데이터베이스 스키마로 만들어 준다.

ORM(Object-Relational Mapping)의 등장

데이터베이스를 이용하기 위해서는 제공되는 라이브러리(JDBC, ODBC, CLI 등)를 이용해 시스템에 접속하고 SQL(Structured Query Language)을 통해 필요한 정보를 제공받는 방식을 이용해야 한다. 이러한 이용방식은 관계모델로 정의된 데이터베이스 스키마에 종속된 형태로 이뤄진다. 물론 이러한 방식이 가장 효율적이기 때문이다.

하지만 프로그래밍 언어와 미들웨어의 발전에 힘입어 단순히 애플리케이션을 객체모델로 정의하고, SQL을 통해 실 데이터를 테이블의 레코드 단위로 조회？생성？변경？삭제하는 수준을 넘어서 정의된 객체정보를 번거로운 데이터 접근 로직과 예외처리 및 SQL문 작성 등을 거치지 않고 직접 데이터와 연계하고 싶은 개발자들의 열망이 ORM을 탄생시키게 됐다.

자바 언어 기반의 EJB(Enterprise Java Bean)를 통해 ORM을 적용하고자 시도하였으나 컨테이너에 종속적인 비대한 구조로 인해 사용이 복잡하고 유연성이 부족해 점차 개발자들로부터 외면당하게 됐다. 이에 Spring 프레임워크는 EJB의 단점을 극복하는 방안을 제시하면서 대안으로 등장해 ORM이 다시 새롭게 도약하는 발판이 됐다. 이로써 객체모델을 중심으로 데이터베이스를 통합하는 방식의 애플리케이션 개발은 다시 탄력을 받게 된다.

현재 Spring 프레임워크는 TopLink, Hibernate, JDO(Java Data Objects), iBATIS SQL Maps, Apache OJB(ObjectRelational Bridge)를 비롯한 다양한 종류의 ORM 툴 및 persistence 프레임워크를 지원한다. 이들 ORM 솔루션들은 데이터베이스에서 객체를 조회하는 방법, 그리고 객체를 데이터베이스의 테이블과 칼럼 형태로 저장하는 방법에 대해 SQL문을 효과적으로 캡슐화하고 객체의 속성 및 메소드와 연계할 수 있도록 해 준다.

하지만 근본적으로 애플리케이션과 데이터베이스가 완전히 통합된 것이 아니므로 이를 이용해 실제 애플리케이션을 개발하는 경우에는 고려해야 할 사항들이 있다.

ORM 활용 시 고려사항

이렇게 객체모델과 관계모델이 갖는 근본적인 차이 때문에 객체를 테이블에 매핑하는 것은 단순하지 않으며 몇 가지 고려해야 할 사항들이 있다.

- 오브젝트 간의 관계는 테이블 간의 조인으로 매핑될 수 있는데 적절한 최적화가 없다면 매우 높은 성능 부하가 수반될 수 있다.
- 관계모델에는 상속 및 계층의 개념이 존재하지 않는다.
- SQL을 이용하는 경우 SQL문과 객체간의 관계는 모호해질 수 있다.

ORM을 적용한다고 해서 SQL 및 데이터베이스의 락킹(Locking) 모델을 무시해도 된다고 생각하면 곤란하다. ORM은 이질적인 두 가지 모델을 연결하는 가교 역할? 주는 도구로 이해할 필요가 있다. 하지만 구현 환경에 대한 차이를 무시해도 되는 수준의 통합을 아직은 지원해 주고 있지 못하다는 점을 명심해야 한다.

따라서 ORM이 적절하지 않은 경우가 있다는 것을 이해하고 ORM을 선택하기 전에 충분히 그 적용성에 대해 검토할 필요가 있다. 필요한 경우 SQL을 사용하는 것을 회피하지 않는 자세가 필요하다. 일반적으로 ORM의 사용에 적합하지 않는 애플리케이션 요건들을 정리해 보면 다음과 같다.

- 많은 수의 레코드를 높은 빈도로 한꺼번에 저장 및 변경하는 애플리케이션
- OLAP(On-Line Analysis Processing) 애플리케이션
- 데이터의 조회 및 변경을 위해 수작업으로 작성된 SQL 및 저장 프로시저를 주로 이용하는 데이터베이스 환경
- 그 외 순수 SQL 기반 접근 방법을 적용하는 것이 적절한 애플리케이션

데이터베이스의 활용 비중이 높은 애플리케이션 환경이 주를 이루고 있는 것을 확인할 수 있으며, 이러한 경우 JDBC 기반의 접근 방법이 최선의 선택이 될 수 있다. 3번째의 경우, SQL에 대한 효과적인 관리 프레임워크를 제공하고 있는 iBATIS를 고려할 만하다. 그 외 Hibernate와 TopLink와 같이 수준 높은 ORM 제품은 기존 스키마 및 저장 프로시저와 효과적인 연동이 가능하므로 사용을 고려해 볼 필요가 있다.

4번째의 경우에는 비즈니스 로직의 대부분이 데이터베이스에 이미 구현돼 있거나, 데이터베이스 무결성 제약(integrity constraint)이 적용된 경우에 해당하며 이러한 애플리케이션에서는 객체 또는 ORM의 활용 여지가 매우 적어, 데이터베이스 테이블을 도메인 객체로 모델링함으로써 기대할 수 있는 효과가 거의 없다.

하지만 ORM을 사용하는 경우 JDBC와 같은 Low-level 인터페이스를 직접 이용하는 데 비해 예외 처리와 같은 번거로운 작업이 필요하지 않기 때문에 코드량을 20~30% 정도까지 절감하는 것이 가능하므로 최적의 선택을 위해 고려해야 할 것이다.

새로운 프로그래밍 언어들의 등장

C/C++와 자바는 성능과 안정성에서 인정을 받으면서 기업용 애플리케이션을 위한 언어로 자리매김했다. TP-Monitor와 WAS(Web Application Server)라는 미들웨어로 발전해 3계층 아키텍처를 수립하는 데 기여했다. 특히 자바의 경우에는 기업, 인터넷 및 모바일 환경을 아우르는 폭넓은 기능들을 표준 규격으로 발전시켜 오고 있으며, 현재 전성시대를 구가하고 있다.

그 외에도 많은 프로그래밍 언어들이 공개 라이선스 기반으로 개발돼 주로 인터넷 환경에서 다양한 서비스를 제공하는 데 활용되면서 상업적인 성공을 위해 경쟁하고 있다. 기업의 업무 환경이 인터넷과 더더욱 밀접하게 연계되면서 자연스럽게 이러한 언어들이 기업 애플리케이션으로 도입되지 않을까 싶다. 이를 위해서는 적정 수준의 성능 확보와 폭넓은 기능 제공이 관건일 것이다.

필자는 개인적으로 Perl 언어를 좋아한다. 이는 직관적이고 함축적인 문법이 타이핑하기 싫어하는 필자의 성향과 맞아 떨어진 것이기도 하지만, 평소 컨설팅 업무를 수행하면서 데이터베이스에서 데이터를 추출하고 의미있는 정보로 가공하기 위한 목적으로 활용하는 데 아주 요긴하게 이용했던 기억들 때문이다. 이는 Perl이 ‘Practical Extraction and Report Language’의 약자임을 상기한다면 당연한 결과다.

Perl은 1987년 자바에 앞서 발표돼 서버 기반의 동적인 웹 페이지를 표시하도록 웹 서버의 CGI(Common Gateway Interface)를 지원하는 최초의 언어였다. 동일한 로직을 다양한 방식으로 구현할 수 있다는 언어의 표현 능력이 장점이기도 하지만, 여러 사람들이 함께 협력 작업을 하기에는 가독성이 떨어져서 개발 생산성을 높이는 데 어려움이 있다는 단점과 객체지향 프로그래밍 개념이 나중에 적용되면서 문법이 매끄럽지 못해 아쉬운 점으로 지적된다.

그럼에도 불구하고 이어서 발표된 파이썬(Python, 1991)과 루비(Ruby, 1995)에 지대한 영향을 끼치게 된다. 데이터의 형식을 미리 지정하지 않아도 실행 과정에서 자동으로 지정되는 Dynamic Typing이나, CPAN(Comprehensive Perl Archive Network)을 통해 쉽게 필요한 라이브러리를 검색하고 온라인으로 바로 제공받을 수 있는 배포 시스템의 지원 등이 대표적인 것들이다.

파이썬은 Perl이 갖는 문법의 다양성과 함축성이, 협력 작업이 수반되는 규모가 큰 프로그램을 개발하는 데 어려움으로 작용하는 점을 보완하면서, 객체지향(OOP), AOP(Aspect-Oriented Programming), 절차적(Structural) 프로그래밍 방식 등을 다양하게 구사할 수 있도록 배려한 것이 특징이다.

루비는 Perl의 장점들과 함께 스몰토크(Smalltalk)의 객체지향 프로그래밍 언어적인 특징을 접목하면서 파이썬보다 더 깔끔한 문법을 구사한다는 평가를 받고 있다. 하지만 후발주자로서 언어 활용의 확산을 촉진하고자 Perl에서 운용하는 CPAN을 본받아 RubyGems라는 패키지 관리 시스템을 운용하고 있으며, 이를 통해 gem이라는 이름으로 패키징된 다양한 라이브러리들을 온라인으로 배포하는 편의를 제공한다.

웹 애플리케이션 프레임워크들의 특징

새로운 프로그래밍 언어들은 각 언어의 특징에 맞는 프레임워크로 기능이 확대되면서 발전하고 있으며 이는 다시 미들웨어로서의 도약을 위한 발판 역할을 할 것이라 예상된다. 각 언어별로 대표적인 웹 애플리케이션 프레임워크(Web Application Framework)에는 다음과 같은 것들이 있으며, 이들이 취하고 있는 아키텍처 상의 특징을 통해 앞으로 새롭게 등장할 미들웨어의 미래상을 미루어 볼 수 있을 것이다.

이들 프레임워크들은 웹 프로그램과 객체모델이 접목돼 완성된 MVC(Model-View-Controller) 패턴을 취하고 있다. 데이터 처리를 담당하는 Model 부분에 기본적으로 ORM이 채용돼 객체의 생성과 함께 데이터베이스에 스키마를 생성하고 영속성 정보를 저장하고 활용할 수 있는 방법들이 기본적으로 제공된다.

따라서 이러한 프레임워크 기반으로 애플리케이션을 개발하는 경우 객체모델 중심으로 설계와 구현이 진행되며, 데이터 모델에 대한 설계 없이 간단한 설정만으로 객체의 영속성 정보를 운용할 수 있는 편의가 제공된다.

발전방향

어떤 언어를 기반으로 하는 미들웨어가 미래의 애플리케이션 서버 특히 기업에서 자바의 위상을 뒤따를지는 아직 알 수 없다. 하지만 프로그래밍 언어가 발전하면서, 그리고 해당 언어를 지원하는 프레임워크가 자리를 잡으면서 시스템 특성에 따른 제약에서 벗어나 좀더 현실에 가까운 컴퓨팅 모델을 지향함에 따라 객체모델에 좀 더 무게가 실릴 것으로 보인다.

이에 따라 관계모델 기반의 데이터베이스는 단순히 영속성 있는 정보를 보관하는 저장소로 그 역할이 축소될 것으로 예상된다. 하지만 완전히 모델 간 통합이 이뤄진 것이 아닌 만큼 당분간 ORM은 애플리케이션 프레임워크를 이루는 중요한 부분으로 그 역할을 지속하게 될 것이다.

필자가 이러한 이야기를 한다고 해서 데이터베이스에 종사하? 일련의 변화는 장기간 하드웨어와 소프트웨어의 발전이 수반돼야 이뤄질 수 있을 것이며, 지금도 메인프레임을 활용하는 곳이 많은 것을 감안한다면 변화는 공존할 것이 틀림없다. 다만 변화가 지향하는 바를 인식하고 인터페이스를 통해 미들웨어와 데이터베이스를 함께 살펴본다면, 좀더 시스템을 깊게 이해할 수 있을 것이라 생각되며 이를 통해 좋은 결과물을 만들어 낼 수 있지 않을까 기대해 본다.

첫 회에서는 미들웨어의 변화를 통해 데이터베이스와의 인터페이스가 어떻게 발전돼 왔는지를 짚어 보았다. 다음 회에서는 데이터베이스의 변화를 통해 미들웨어와 데이터베이스 간 인터페이스가 SQL에서 No SQL로 변화하는 과정을 짚어보고 이에 대한 발전 전망을 알아보고자 한다.

출처 : 한국데이터베이스진흥원

제공 : DB포탈사이트 DBguide.net

MongoDB 탐구

가을의 곰을... — Sat, 07 Jul 2012 01:25:45 +0900

MongoDB 탐구

이 데이터베이스 관리 시스템이 매우 인기 있는 이유를 확인한다.

Joe Lennon, 모바일관련 개발자, Core International

요약： 이 기사에서는 프로덕션 환경에서 데이터베이스를 확장할 수 있는 기능을 제공하는, C++로 작성된 오픈 소스 문서 지향 데이터베이스 관리 시스템인 MongoDB에 관해 배웁니다. 기존의 관계형 데이터 베이스 시스템(RDBMS)과 비교하여 문서 지향 데이터베이스가 갖고 있는 이점을 확인합니다. MongoDB를 설치하고 데이터베이스 콜렉션과 문서 작성을 시작합니다. RDBMS 데이터베이스 관리자와 개발자에게 익숙한 방식으로 키/값 저장소에 효율성을 제공하는 MongoDB의 동적 쿼리 기능을 시험합니다.

이 기사에 태그： 데이터베이스_및_데이터_관리, 애플리케이션_개발

여기에 태그 달기!

기사 게재일： 2011 년 9 월 20 일
난이도： 중급
원문： 보기
PDF： A4 and Letter (193KB | 24 pages)Get Adobe® Reader®
페이지뷰： 5528 회
의견： 0 (보기 | 의견 추가 - 로그인)

평균 평가 등급 (14 투표수)
아티클 순위

MongoDB란?

최근에는 기존의 관계형 모델과는 다른 데이터베이스 관리 시스템에 대한 관심이 증가하고 있다. 이 중심에는 NoSQL이라는 개념이 있는데, 이는 데이터베이스 상호 작용에 SQL을 사용하지 않는 데이터베이스 소프트웨어를 총괄하는 용어이다. 주목할 만한 NoSQL 프로젝트 중 하나는 JSON 형태의 문서 콜렉션으로 데이터를 저장하는 오프 소스 문서 지향 데이터베이스인 MongoDB이다. MongoDB가 다른 NoSQL 데이터베이스와 다른 점은 쿼리가 매우 쉽게 변환되기 때문에 관계형 데이터베이스를 MongoDB로 쉽게 변환할 수 있는 강력한 문서 지향 쿼리 언어에 있다.

MongoDB는 C++로 작성되어 있다. MongoDB는 JSON의 2진 버전인 BSON을 사용하여, 키/값 쌍으로 데이터를 유지하는 JSON 형태의 문서에 데이터를 저장한다. MongoDB가 다른 문서 데이터베이스와 구별되는 한 가지 기능은 SQL문을 MongoDB 쿼리 함수 호출로 매우 간단하게 변환하는 기능이다. 이 기능을 이용하면 조직에서 현재 사용 중인 관계형 데이터베이스를 쉽게 마이그레이션할 수 있다. 또한, 주요 운영 체제와 프로그래밍 언어에서 사용 가능한 2진 파일과 드라이버를 사용하면 매우 간단하게 설치하여 사용할 수 있다.

MongoDB는 GNU AGPL(Affero General Public License) 버전 3.0에 따라 라이센스가 부여된 데이터베이스를 사용하는 오픈 소스 프로젝트이다. 이 라이센스는 카피레프트 제한이 소프트웨어를 사용하는 데는 적용되지 않고 배포에만 적용되는 허점을 보완한 GNU GPL의 수정 버전이다. 물론, 일반적으로 클라이언트 디바이스에 설치되지 않고 클라우드에 저장되는 소프트웨어는 이점이 중요하다. 사실상 소프트웨어가 배포되지 않기 때문에 일반 GPL을 사용하는 경우에는 라이센스 조항을 회피할 수 있다는 사실을 인식할 수 있다.

AGPL은 데이터베이스 애플리케이션 자체에만 적용되며 MongoDB의 다른 요소에는 적용되지 않는다. 개발자들이 다양한 프로그래밍 언어로 MongoDB에 연결하는 데 필요한 공식 드라이버는 Apache License Version 2.0에 따라 배포된다. MongoDB 문서는 CCL(Creative Commons license)에 따라 사용 가능하다.

문서 지향 데이터베이스

문서 지향 데이터베이스는 기존의 관계형 데이터베이스와는 매우 다르다. 문서 지향 데이터베이스는 테이블과 같은 경직된 구조에 데이터를 저장하지 않고 느슨하게 정의된 문서에 데이터를 저장한다. 관계형 데이터베이스 시스템(RDBMS) 테이블에서는 열을 새로 추가하려면 테이블 자체의 정의를 변경해야 한다. 따라서 비록 널 값을 갖게 될지라도 열이 기존의 모든 레코드에 추가된다. 이는 RDBMS의 엄격한 스키마 기반 설계로 인한 것이다. 그러나 문서를 사용하는 경우에는 기타 모든 문서를 변경하지 않고도 개별 문서에 속성을 새로 추가할 수 있다. 이는 문서 지향 데이터베이스가 일반적으로 스키마를 사용하지 않도록 설계되기 때문이다.

또 다른 기본적인 차이점은 문서 지향 데이터베이스는 문서 간의 엄격한 관계를 제공하지 않는다는 점이다. 이러한 점은 문서 지향 데이터베이스가 스키마 없는 설계를 유지하는 데 도움이 된다. 이점은 관계에 의존하여 데이터 스토리지를 표준화하는 관계형 데이터베이스와는 매우 다른 점이다. 문서 데이터베이스에서는 "관련" 데이터를 별도의 스토리지 영역에 저장하는 대신에 문서 자체에 삽입한다. 각 참조는 추가 쿼리를 필요로 하기 때문에 이렇게 하는 것이 관련 데이터가 저장된 또 다른 문서에 참조를 저장하는 것보다 더 빠르다.

이러한 기능은 데이터가 상위 문서 안에서 독립적으로 존재하는 것이 적합한 많은 애플리케이션에서 매우 잘 동작한다. 이에 해당하는 예(MongoDB 문서에도 있음)로는 블로그 포스트와 주석이 있다. 주석은 단일 포스트에만 적용되므로 주석을 블로그 포스트와 분리해서 생각하는 것은 타당하지 않다. MongoDB에서는 블로그 포스트 문서에 해당 포스트의 주석을 저장하는 comments 속성이 있다. 관계형 데이터베이스에서는 ID가 기본 키인 주석 테이블과 포스트 테이블 그리고 주석이 속하는 포스트를 정의하는 중간 맵핑 테이블 post_comments가 존재하게 된다. 이로 인해 매우 간단해야 할 것들이 불필요하게 매우 복잡해진다.

그러나 관련 데이터를 별도로 저장해야 하는 경우에는 MongoDB에서 별도의 콜렉션을 사용하여 쉽게 이러한 작업을 수행할 수 있다. 또 다른 좋은 예는 MongoDB 문서에 고객 주문 정보를 저장하는 것이다. 일반적으로 고객 주문 정보는 고객 정보, 주문 자체, 주문 품목 및 제품 정보로 구성된다. MongoDB를 사용하면 고객, 제품 및 주문 정보를 개별 콜렉션에 저장하게 되지만, 품목 데이터는 관련된 주문 문서 안에 삽입된다. 그러면, 관계형 데이터베이스에서 사용한 것과 같은 외부 키 형태의 ID를 사용하여 제품과 고객 콜렉션을 참조한다. 이러한 하이브리드 방식은 단순하기 때문에 MongoDB는 SQL로 작업하는 데 익숙한 개발자들에게 좋은 선택이 된다. 그렇긴 하지만, 다른 콜렉션에서 데이터를 참조하는 대신에 문서 내부에 데이터를 삽입하면 성능을 대폭 개선할 수 있으므로 각각의 개별 유스 케이스를 대상으로 취해야 하는 접근 방식을 신중하게 결정해야 한다.

기능 개요

MongoDB는 단지 기본적인 키/값 저장소가 아니다. MongoDB의 다른 기능 중 일부를 간략하게 살펴보도록 하자.

공식 2진 파일은 Windows®, Mac OS X, Linux® 및 Solaris에서 사용 가능하며 소스 배포판을 이용하여 직접 빌드할 수도 있다.
공식 드라이버는 C, C#, C++, Haskell, Java™, JavaScript, Perl, PHP, Python, Ruby 및 Scala에서 사용 가능하며, 다른 언어에서는 광범위한 커뮤니티 지원 드라이버를 사용할 수 있다.
모든 문서 속성에서 기준을 사용하여 데이터를 찾을 수 있게 하는 임시(Ad-hoc) Javascript 쿼리. 이러한 쿼리는 SQL 쿼리의 기능을 반영한 것으로 SQL 개발자는 이 쿼리를 이용하여 MongoDB 쿼리를 매우 간단하게 작성할 수 있다.
쿼리에서 정규 표현식 지원
MongoDB의 쿼리 결과는 limit(), skip(), sort(), count(), distinct() 및 group()을 포함하여 필터링과 수집 및 정렬에 필요한 다양한 함수를 제공하는 커서에 저장된다.
고급 수집용 map/reduce 구현
GridFS를 사용하는 대용량 파일 스토리지
RDBMS 형태의 속성 인덱싱 지원, 여기에서는 선택된 문서 속성에서 직접 인덱스를 작성할 수 있다.
힌트, 설명 계획 및 프로파일링을 사용하는 쿼리 최적화 기능
MySQL과 비슷한 마스터/슬레이브 복제
표준화된 데이터를 필요로 하는 참조 쿼리를 허용하는 콜렉션 기반 오브젝트 스토리지
자동 샤딩(Auto-sharding)을 이용한 수평적 확장
경쟁이 없는 고성능의 동시성을 구현하는 데 필요한 제자리 쓰기(In-place update) 기능
설치하지 않고도 MongoDB를 사용해 볼 수 있는 온라인 쉘
발행되었거나 현재 작성 중인 여러 권의 책과 상세한 문서

위로

MongoDB 설치

다행히도 MongoDB는 다양한 플랫폼에서 매우 간단하게 설치할 수 있다. 2진 배포판은 Windows, Mac OS X, Linux 및 Solaris에서 사용 가능하며 다른 시스템에서는 다양한 패키지 관리자가 쉬운 설치 및 설정 옵션을 제공한다. 자신이 있으면 직접 소스 코드를 컴파일해도 된다. 이 섹션에서는 Windows와 Mac OS X에서 MongoDB를 설치하고 프로세스를 Windows에서 서비스로 설정하거나 OS X에서 디먼으로 설정하는 방법을 배운다.

Windows에서 설치

Windows에서 MongoDB를 설치하는 과정은 매우 간단하다. 선호하는 웹 브라우저로 http://www.mongodb.org/downloads를 탐색하여 안정된 최신 프로덕션 릴리스(Windows용)를 다운로드한다. 64비트 버전을 권장하지만 이 버전은 Windows 운영 체제 64비트 버전을 사용 중인 경우에만 사용할 수 있다. 사용 중인 운영 체제의 버전이 불확실한 경우에는 32비트 버전을 사용한다.

zip 파일을 C:\drive에 추출하면 이름이 mongodb-win32-i386-1.6.4인 폴더가 새로 생긴다. 작업을 편하게 하려면 이 폴더의 이름을 mongo로 바꾼다. 다음에는 데이터 디렉토리를 작성해야 한다. Windows 탐색기에서 C:\drive의 루트로 이동하여 data라는 폴더를 새로 작성한다. 이 폴더 안에 db라는 폴더를 새로 작성한다.

그러면 MongoDB 서버를 시작할 수 있다. Windows 탐색기를 사용하여 C:\mongo\bin을 탐색하고 mongod.exe를 두 번 클릭한다. 열린 명령 프롬프트 창을 닫으면 MongoDB 서버가 중지된다. 따라서, MongoDB 서버를 Windows 제어인 서비스로 설정하는 것이 더 편리하다. 이제 이 작업을 수행하도록 하자.

Start>Run>을 선택하고 cmd를 입력한 후, OK를 클릭하여 명령행 프롬프트 창을 열고 목록 1에 있는 명령을 실행한다.

목록 1. MongoDB 서버를 서비스로 설정

> cd \mongo\bin
> mongod --install --logpath c:\mongo\logs --logappend 
--bind_ip 127.0.0.1 --directoryperdb

목록 2에 있는 결과물이 표시된다.

목록 2. 성공적으로 작성된 서비스

all output going to c:\mongo\logs
Creating service MongoDB.
Service creation successful.
Service can be started from the command line via 'net start "MongoDB"'.

MongoDB를 서비스로 설치했으므로 다음 명령을 사용하여 MongoDB를 시작할 수 있다. > net start "MongoDB".

목록 3에 있는 결과물이 표시된다.

목록 3. 성공적으로 시작된 MongoDB

The Mongo DB service is starting.
The Mongo DB service was started successfully.

이제 MongoDB 쉘 클라이언트를 실행할 수 있다. 명령 프롬프트 창이 열리면 위치가 c:\mongo\bin 폴더인지 확인한 다음, >mongo 명령을 입력한다.

또는 Windows 탐색기에서 C:\mongo\bin으로 이동하여 mongo.exe를 두 번 클릭한다. 어떤 방법으로 쉘을 시작하든지 목록 4에 있는 것과 같은 프롬프트가 표시된다.

목록 4. 쉘 시작

MongoDB shell version: 1.8.1
connecting to: test
>

Mac OS X 시스템에서 MongoDB를 설정하는 경우가 아니면 이 섹션의 다음 부분을 건너뛰어 "시작하기"로 이동할 수 있다. 여기서는 쉘 클라이언트를 사용하여 MongoDB 서버와 상호 작용하는 방법을 배운다.

Mac OS X에서 설치

Mac OS X 64비트 버전을 사용 중이라고 가정하여 다음 단계에서는 MongoDB 64비트 OS X 2진 파일을 다운로드하여 추출한 후, 구성하여 시작하는 방법을 자세히 다룬다. 또한, MongoDB를 디먼으로 실행하는 방법을 살펴본다.

먼저, 터미널을 실행한다(Applications>Utilities>Terminal). 터미널 창에서 목록 5에 있는 명령을 실행한다.

목록 5. Mac OS X에서 MongoDB 설정

$ cd ~
$ curl http://fastdl.mongodb.org/osx/mongodb-osx-x86_64-1.6.4.tgz > mongo.tgz
$ tar xzf mongo.tgz
$ mv mongodb-osx-x86_64-1.8.1/ mongo
$ mkdir -p /data/db

이제 MongoDB가 설정되었으므로 사용할 차례이다. 진도를 나가기 전에 해당 경로에 MongoDB를 추가하는 것이 좋다. $ nano ~/.bash_profile 명령을 실행한다.

이 파일이 아직 존재하지 않을 수도 있다. 어떤 경우이든 다음 행(export PATH={$PATH}:~/mongo/bin)을 추가한다.

ctrl + O을 눌러서 파일을 저장한 후, 프롬프트에서 Enter를 누른다. 그런 다음, ctrl + X를 눌러서 nano를 종료한다. 이제, $ source ~/.bash_profile 명령을 사용하여 bash 프로파일을 다시 로드한다.

그러면 MongoDB를 시작할 준비가 된다. MongoDB를 시작하려면 $ mongod 명령을 실행한다.

이렇게 하면 MongoDB 데이터베이스 서버가 포그라운드 프로세스로 시작된다. MongoDB를 백그라운드에서 디먼 프로세스로 시작하고 싶은 경우에는 그 대신 $ sudo mongod --fork --logpath /var/log/mongodb.log --logappend 명령을 실행한다.

비밀번호를 입력하라는 메시지가 표시되면 이 프롬프트에서 Mac OS X 관리자 비밀번호를 입력한다.

MongoDB를 시작하는 방법에 관계없이 서버가 실행된다. MongoDB를 포그라운드에서 시작한 경우, 클라이언트를 시작하려면 별도의 Terminal 탭이나 창이 필요하다. 클라이언트를 시작하려면 $ mongo 명령을 사용한다.

목록 6에 있는 것과 같은 프롬프트가 표시된다.

목록 6. 클라이언트 시작

MongoDB shell version: 1.8.1
connecting to: test
>

다음 섹션에서는 MongoDB 쉘을 사용하여 데이터베이스, 콜렉션 및 문서 등을 작성하는 방법을 배운다.

위로

MongoDB 시작하기

MongoDB 배포판에 포함되어 있는 것은 데이터베이스를 완전히 제어할 수 있는 쉘 애플리케이션이다. 이 쉘을 사용하는 경우에는 서버측 Javascript 함수를 사용하여 데이터베이스, 콜렉션, 문서 및 인덱스를 작성하고 관리할 수 있다. 이 쉘을 사용하면 MongoDB를 신속하고 쉽게 실행할 수 있다. 이 섹션에서는 쉘을 시작하는 방법을 배우고 예제를 통해 기본적인 데이터 저장 및 검색을 수행할 수 있는 몇 가지 기본적인 명령을 살펴본다.

MongoDB 쉘

MongoDB 쉘 애플리케이션은 bin 폴더에 MongoDB 배포판과 함께 포함되어 있다. Windows에서는 이 쉘이 애플리케이션(mongo.exe)으로 존재한다. Windows 탐색기에서 이 프로그램을 두 번 클릭하면 쉘이 시작된다. 위에 있는 지시사항을 따라 MongoDB 디렉토리를 해당 경로에 추가했다고 가정하면 UNIX® 기반 운영 체제(Mac OS X 포함)에서는 터미널 창에서 mongo 명령을 실행하여 MongoDB 쉘을 시작할 수 있다.

먼저 쉘을 실행하면 목록 7에 있는 메시지가 표시된다.

목록 7. 쉘을 실행 한 후 표시되는 메시지

MongoDB shell version: 1.8.1
connecting to: test
>

이제 로컬 MongoDB 서버(특히 "test" 데이터베이스)에 연결된다. 다음 섹션에서는 데이터베이스, 문서 및 콜렉션을 작성하는 방법을 배운다. 어떤 단계에서든 도움이 필요하면 Mongo 쉘 프롬프트에서 간단히 "help" 명령을 실행한다. 그림 1에는 help 명령을 실행했을 때 표시되는 일반적인 결과물이 표시되어 있다.

그림 1. Mongo 쉘에서 help 명령을 실행했을 때의 결과물

MongoDB 함수의 소스 코드를 알고 싶으면 쉘에서 해당 함수의 이름을 입력하기만 하면 해당하는 Javascript 소스가 표시된다. 예를 들면, connect를 입력하고 리턴 키를 누르면 MongoDB 데이터베이스에 연결하는 데 사용된 소스 코드가 표시된다.

데이터베이스 콜렉션 및 문서 작성

기본적으로 Mongo 쉘은 "test" 데이터베이스에 연결된다. 다른 데이터베이스로 전환하려면 "use dbname" 명령을 사용한다. 데이터베이스가 존재하지 않는 경우에는 데이터를 데이터베이스에 추가하는 즉시 MongoDB에서 데이터베이스가 작성된다. >use mymongo 명령을 사용하여 "mymongo" 데이터베이스로 전환한다.

쉘에서 switched to db mymongo 메시지가 리턴된다.

이 시점에서는 데이터베이스에 데이터가 없으므로 사실상 아직은 데이터베이스가 존재하지 않는다. MongoDB에서는 데이터가 콜렉션에 저장되므로 필요한 경우에는 문서를 분리할 수 있다. 문서를 작성하여 다음과 같이 새 콜렉션("colors")에 저장해 본다. > db.colors.save({name:"red",value:"FF0000"});.

다음과 같이 데이터베이스를 쿼리하여 문서가 저장되었는지 확인한다. > db.colors.find();.

다음과 같은 응답이 표시된다(_id 속성은 고유한 식별자로 결과마다 다를 수 있음). { "_id" : ObjectId("4cfa43ff528bad4e29beec57"), "name" : "red", "value" : "FF0000" }.

MongoDB에서는 문서가 BSON(2진 JSON)으로 저장된다. Mongo 쉘을 사용하는 경우에는 JSON 형태의 구문을 사용하여 데이터를 삽입할 수 있으며 여기에서는 각 문서가 키/값 쌍으로 구성된 하나의 오브젝트이다. 이 예제에서는 값이 각각 red와 FF0000(표준 빨간색의 16진 표현)인 name 및 value 속성이 있는 문서를 작성했다.

알고 있을지 모르지만, colors 콜렉션을 사전 정의할 필요는 없었으며 이러한 작업은 save 함수를 사용하여 항목을 삽입할 때 자동으로 수행된다.

이 예제에서는 매우 간단한 문서를 작성했다. 그러나 사용된 JSON 형태의 구문은 더 복잡한 문서를 작성하는 데 사용될 수 있다. 구매 주문이나 송장을 표현하는 다음 JSON 문서를 생각해 보자(목록 8 참조).

목록 8. 간단한 문서 작성

{
    order_id: 109384,
    order_date: new Date("12/04/2010"),
    customer: {
        name: "Joe Bloggs",
        company: "XYZ Inc.",
        phone: "(555) 123-4567"
    },
    payment: {
        type: "Cash",
        amount: 4075.99,
        paid_in_full: true
    },
    items: [
        {
            sku: "ABC1200",
            description: "A sample product",
            quantity: 1,
            price_per_unit: 75.99,
        }, {
            sku: "XYZ3400",
            description: "An expensive product",
            quantity: 2,
            price_per_unit: 2000
        }
    ],
    cashier_id: 340582242
}

아는 바와 같이 이러한 문서에는 문자열, 정수, 부동수, 날짜, 오브젝트, 배열 등과 같은 다양한 데이터 유형을 저장할 수 있다. 목록 8에서는 주문 품목을 주문 문서에 직접 삽입하며, 이렇게 하면 나중에 문서를 쿼리할 때 이 정보를 더 빠르게 검색할 수 있다.

MongoDB 쉘은 Javascript를 사용하므로 데이터베이스와 상호 작용할 때 일반 Javascript 구문을 작성할 수 있다. 목록 9에서는 문자의 문자열 표현과 문자와 연관된 ASCII 코드가 각각 포함된 문자 문서 콜렉션을 작성한다.

목록 9. 문자 문서 콜렉션 작성

> var chars = "abcdefghijklmnopqrstuvwxyz"
> for(var i =0; i

이 루프에서는 각 알파벳 소문자에 해당하는 문서가 26개 작성되며 각 문서에는 문자 자체와 문자의 ASCII 코드가 포함되어 있다. 다음 섹션에서는 다양한 방식으로 이 데이터를 검색하는 방법을 살펴본다.

데이터 검색하기

마지막 섹션에서는 MongoDB 데이터베이스에 데이터를 삽입하는 방법을 배울 뿐만 아니라 가장 기본적인 데이터 검색 함수인 find를 사용하는 방법을 배운다. 먼저, 이전 섹션의 마지막 부분에서 작성한 알파벳 콜렉션을 대상으로 다음과 같이 find 명령을 사용하자. db.alphabet.find();.

이렇게 하면 목록 10과 같은 응답이 생성된다.

목록 10. 생성된 응답

> db.alphabet.find()
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8c"), "char" : "a", "code" : 97 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8d"), "char" : "b", "code" : 98 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8e"), "char" : "c", "code" : 99 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8f"), "char" : "d", "code" : 100 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec90"), "char" : "e", "code" : 101 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec91"), "char" : "f", "code" : 102 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec92"), "char" : "g", "code" : 103 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec93"), "char" : "h", "code" : 104 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec94"), "char" : "i", "code" : 105 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec95"), "char" : "j", "code" : 106 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec96"), "char" : "k", "code" : 107 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec97"), "char" : "l", "code" : 108 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec98"), "char" : "m", "code" : 109 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec99"), "char" : "n", "code" : 110 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9a"), "char" : "o", "code" : 111 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9b"), "char" : "p", "code" : 112 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9c"), "char" : "q", "code" : 113 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9d"), "char" : "r", "code" : 114 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9e"), "char" : "s", "code" : 115 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec9f"), "char" : "t", "code" : 116 }
has more
>

기본적으로 find() 함수는 콜렉션에 있는 모든 문서를 검색하지만, 처음 20개의 문서만 표시한다. it 명령을 입력하면 나머지 문서 6개가 검색된다(목록 11 참조).

목록 11. 나머지 문서 6개 검색

> it
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca0"), "char" : "u", "code" : 117 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca1"), "char" : "v", "code" : 118 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca2"), "char" : "w", "code" : 119 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca3"), "char" : "x", "code" : 120 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca4"), "char" : "y", "code" : 121 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca5"), "char" : "z", "code" : 122 }
>

사실상 find() 함수는 쿼리 결과 세트에 커서를 리턴하며, 이 경우에는 모든 문서를 검색한다. 이것을 변수에 지정하지 않거나 더 이상의 함수가 수행되지 않으면 기본적으로 샘플 결과 세트가 화면에 표시된다. >db.alphabet.find().forEach(printjson); 명령을 사용하여 모든 결과 세트를 표시할 수도 있다.

이렇게 하면 서브세트가 표시되는 대신 모든 레코드가 결과 세트로 표시된다. 다음 섹션에서는 커서와 쿼리를 사용하여 데이터를 필터링하는 방법을 자세히 본다.

위로

데이터 쿼리

MongoDB의 가장 큰 강점 중 하나는 비록 테이블 대신 BSON 문서를 필터링하고 리턴하기는 해도 기존의 관계형 데이터베이스와 거의 같은 방식으로 작동하는 임시 쿼리를 강력하게 지원한다는 점이다. 이러한 방식이 SQL 개발자들이 이해하는 데 어려울 수도 있는 다른 문서 저장소와 MongoDB의 차이점이다. MongoDB를 사용하면 비교적 복잡한 SQL 쿼리를 Javascript 함수 호출로 쉽게 변환할 수 있다. 이번 섹션에서는 MongoDB에서 데이터를 쿼리할 때 사용되는 다양한 함수와 DB2, MySQL 또는 Oracle의 like에서와 같이 인덱스를 설정하여 쿼리를 최적화하는 방법을 배운다.

기본 쿼리

이전 섹션에서는 find 함수를 사용하여 모든 문서를 검색하는 방법을 배웠다. find 함수는 리턴된 결과를 필터링할 수 있는 일련의 인수를 받는다. 예를 들면, >db.alphabet.find({char: "o"}); 명령을 사용하여, 앞서 작성한 알파벳 콜렉션에서 "char" 속성값이 "q"인 모든 레코드를 찾을 수 있다.

이 명령은 { "_id" : ObjectId("4cfa4adf528bad4e29beec9a"), "char" : "o", "code" : 111 } 응답을 리턴한다.

코드가 100 이하인 모든 문자를 리턴하려면 다음 명령을 사용한다. >db.alphabet.find({code:{$lte:100}});.

예상하는 바와 같이 이 명령은 목록 12와 같은 결과를 리턴한다.

목록 12. 결과

{ "_id" : ObjectId("4cfa4adf528bad4e29beec8c"), "char" : "a", "code" : 97 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8d"), "char" : "b", "code" : 98 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8e"), "char" : "c", "code" : 99 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8f"), "char" : "d", "code" : 100 }

MongoDB는 다음과 같은 다양한 조건부 연산자를 지원한다.

$lt(미만)
$lte(이하)
$gt(초과)
$gte(이상)
$all(배열에 있는 모든 값과 일치)
$exists(필드의 존재 여부 확인)
$mod(모듈)
$ne(같지 않음)
$in(배열에 있는 하나 이상의 값과 일치)
$nin(배열에 있는 0 값과 일치)
$or(쿼리 중 하나와 일치)
$nor(쿼리 중 어느 것과도 일치하지 않음)
$size(정의된 요소 수가 있는 배열과 일치)
$type(지정된 BSON 데이터 유형의 값과 일치)
$not(같지 않음)

이러한 모든 연산자를 자세히 확인하려면 MongoDB 문서를 참조한다(링크는 참고자료 참조).

find 함수의 두 번째 인수를 사용하여 쿼리에서 리턴되는 필드를 제한할 수 있다. 예를 들면, 다음 쿼리는 코드 값이 102 ~ 105 범위 안에 있는 모든 문서의 char 속성만을 리턴한다. > db.alphabet.find({code:{$in:[102,103,104,105]}}, {char: 1});.

이 쿼리의 결과는 목록 13과 같다.

목록 13. 결과

{ "_id" : ObjectId("4cfa4adf528bad4e29beec91"), "char" : "f" }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec92"), "char" : "g" }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec93"), "char" : "h" }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec94"), "char" : "i" }

다음 섹션에서는 인덱스를 작성하여 쿼리 속도를 높이는 방법을 배운다.

인덱싱

MongoDB 인덱스는 관계형 데이터베이스 인덱스와 매우 비슷하다. 모든 속성에 인덱스를 삽입할 수 있다. 이외에도 인덱스화된 필드는 모든 데이터 유형(오브젝트 또는 배열 포함)이 될 수 있다. RDBMS 인덱스와 마찬가지로 다중 속성과 고유 인덱스를 사용하여 복합 인덱스를 작성할 수 있으며 이렇게 하면 값이 중복되지 않도록 할 수 있다.

기본 인덱스를 작성하려면 ensureIndex 함수를 사용한다. 이제 알파벳 콜렉션의 code와 char 속성을 대상으로 인덱스를 작성하자(목록 14 참조).

목록 14. 인덱스 작성

> db.alphabet.ensureIndex({code: 1});
> db.alphabet.ensureIndex({char: 1});

dropIndex와 dropIndexes 함수를 사용하여 인덱스를 삭제할 수 있다. 자세한 내용은 MongoDB 문서를 참조한다.

정렬

결과 세트를 정렬하려면 해당 커서에 sort 함수를 적용한다. 알파벳 콜렉션은 이미 code와 char 속성으로 오름차순으로 정렬되어 있으므로 서브세트를 다시 code 속성으로 오름차순으로 정렬하자. > db.alphabet.find({code: {$gte: 118}}).sort({code: 0});.

이 쿼리는 목록 15와 같은 결과를 리턴한다.

목록 15. 결과

{ "_id" : ObjectId("4cfa4adf528bad4e29beeca5"), "char" : "z", "code" : 122 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca4"), "char" : "y", "code" : 121 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca3"), "char" : "x", "code" : 120 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca2"), "char" : "w", "code" : 119 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beeca1"), "char" : "v", "code" : 118 }

이전 명령에서 sort 함수에 {code: 1} 인수를 제공하면 결과가 오름차순으로 정렬된다. 쿼리의 성능을 강화하려면 사용할 데이터를 정렬할 모든 속성에 인덱스를 추가해야 한다.

위로

SKIP과 LIMIT를 사용하여 결과를 페이지로 나누기

데이터 결과 세트를 처리할 때는 아마도 결과를 페이지로 나누어서 웹 페이지에 표시하기 위해 한 번에 하나의 서브세트만 검색하고자 할 경우도 있다. MySQL에서는 LIMIT 키워드를 사용하여 이러한 작업을 수행한다. MongoDB에서는 skip과 limit 함수를 사용하여 이 기능을 쉽게 복제할 수 있다. 알파벳 콜렉션에서 처음 5개 문서를 리턴하려면 다음 조작을 수행한다. > db.alphabet.find().limit(5);.

이 조작은 목록 16과 같은 결과를 리턴한다.

목록 16. 결과

{ "_id" : ObjectId("4cfa4adf528bad4e29beec8c"), "char" : "a", "code" : 97 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8d"), "char" : "b", "code" : 98 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8e"), "char" : "c", "code" : 99 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec8f"), "char" : "d", "code" : 100 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec90"), "char" : "e", "code" : 101 }

다음 페이지를 얻으려면 다음 명령을 사용한다. > db.alphabet.find().skip(5).limit(5);.

목록 17에서 알 수 있는 바와 같이 이 명령은 다음 5개 레코드를 페치한다.

목록 17. 다음 5개 레코드 페치

{ "_id" : ObjectId("4cfa4adf528bad4e29beec91"), "char" : "f", "code" : 102 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec92"), "char" : "g", "code" : 103 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec93"), "char" : "h", "code" : 104 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec94"), "char" : "i", "code" : 105 }
{ "_id" : ObjectId("4cfa4adf528bad4e29beec95"), "char" : "j", "code" : 106 }

위로

group 함수와 수집

MongoDB의 쿼리 엔진을 이용하면 해당 데이터에 수집 및 그룹 함수를 매우 간단하게 적용할 수 있다. 이러한 기능은 다른 데이터베이스의 해당 SQL 기능과 비슷하다. 이론의 여지가 있지만, 가장 널리 사용되는 함수는 count() 함수이다. > db.alphabet.find().count();.

이 명령은 26을 리턴한다. 필터링된 쿼리를 다음과 같이 쉽게 계수할 수 있다. > db.alphabet.find({code: {$gte: 105}}).count();.

위에 있는 명령문은 18을 리턴한다.

또 다른 유용한 수집 함수는 distinct이다. 이 함수는 고유한 속성값 세트를 리턴하기 위해 사용된다. 알파벳 콜렉션은 모든 데이터가 고유하기 때문에 예제로서 적합하지 않다. 그러므로 이 기사의 앞 부분에서 작성한 colors 콜렉션에 레코드 두 개를 추가한다(목록 18 참조).

목록 18. color 콜렉션에 레코드 추가

> db.colors.save({name:"white",value:"FFFFFF"});
> db.colors.save({name:"red",value:"FF0000"});  
> db.colors.find();

colors 콜렉션을 삭제하지 않았다고 가정하면 목록 19와 같은 응답이 표시된다.

목록 19. 응답

{ "_id" : ObjectId("4cfa43ff528bad4e29beec57"), "name" : "red", "value" : "FF0000" }
{ "_id" : ObjectId("4cfa5830528bad4e29beeca8"), "name" : "white", "value" : "FFFFFF" }
{ "_id" : ObjectId("4cfa5839528bad4e29beeca9"), "name" : "red", "value" : "FF0000" }

아는 바와 같이 이 콜렉션에는 분명히 빨간색 문서가 두 개 있다. 이제, distinct 함수를 사용하여 이 콜렉션에서 고유한 name 속성값을 가져온다. > db.colors.distinct("name");.

이 명령은 [ "red", "white" ]를 리턴한다.

다른 쿼리 함수를 수행하므로 커서나 결과 세트에 대해서는 distinct 함수를 수행하지 않고 콜렉션을 대상으로 직접 distinct 함수를 수행한다. 또한, 이 함수가 문서 세트를 리턴하지 않고 값으로 구성된 배열을 리턴한다는 점을 알게 된다.

MongoDB는 SQL의 GROUP BY 표현식으로 하는 것과 같은 조치를 수행하는 데 필요한 group 함수를 제공한다. group 함수는 복잡하므로 여기에서는 간단한 예제만 살펴보도록 한다. 예를 들면, 이름 값으로 그룹화된 문서의 수를 계수한다고 가정한다. SQL에서는 이 표현식을 다음과 같이 정의할 수 있다. SELECT name, COUNT(*) FROM colors GROUP BY name;.

MongoDB에서 이 쿼리를 수행하려면 목록 20에 있는 명령을 사용해야 한다.

목록 20. group 함수 사용

> db.colors.group(
... {key: {name: true},
... cond: {},
... initial: {count: 0},                                  
... reduce: function(doc, out) { out.count++; }
... });

이 코드는 목록 21과 같은 결과를 생성한다.

목록 21. 결과

[
    {
        "name" : "red",
        "count" : 2
    },
    {
        "name" : "white",
        "count" : 1
    }
]

고급 수집 기능을 수행해야 하거나 대용량 데이터 세트를 사용해야 하는 경우, MongoDB에는 이러한 기능을 수행할 수 있는 map/reduce 구현이 포함되어 있다. 위에서 언급한 group 함수는 공유된 MongoDB 설정에서는 작동하지 않으므로 샤딩을 사용할 경우에는 group 함수 대신 map/reduce를 사용해야 한다.

기존 데이터 업데이트

MongoDB 쉘에서는 문서를 업데이트하기가 매우 쉽다. 앞서 작성한 colors 콜렉션에는 red에 해당하는 레코드가 두 개 있었다. 이 레코드 중 하나를 취하여 값 속성이 000000(검정색의 16진 값)인 black으로 변경한다고 가정한다. 먼저, findOne 함수를 사용하여 값이 red인 단일 항목을 검색하고 필요에 따라 그 특성을 변경하고 해당 문서를 다시 데이터베이스에 저장할 수 있다.

이름이 red인 단일 문서를 가져와서 다음과 같이 blackDoc 변수에 저장한다. > var blackDoc = db.colors.findOne({name: "red"});.

다음에는 점 표기법을 사용하여 문서의 특성을 변경한다(목록 22 참조).

목록 22. 문서의 특성 변경

> blackDoc.name = "black";
> blackDoc.value = "000000";

문서를 저장하기 전에 다음과 같이 문서가 올바른지 확인한다. (문서에는 _id 속성이 있어야 한다. 그렇지 않으면 문서가 red 레코드를 덮어서 저장되지 않고 새 레코드로 삽입된다.) > printjson(blackDoc);

목록 23과 같은 결과가 리턴되면 준비가 된 것이다.

목록 23. 결과

{
    "_id" : ObjectId("4cfa43ff528bad4e29beec57"),
    "name" : "black",
    "value" : "000000"
}

마지막으로 save 함수를 사용하여 문서를 다시 데이터베이스의 colors 콜렉션에 저장한다. > db.colors.save(blackDoc);.

이제 find 함수를 사용하여 콜렉션이 올바른지 확인할 수 있다. > db.colors.find();.

그러면 목록 24와 같은 결과가 리턴된다. 레코드가 4개이면 잘못된 것이다.

목록 24. 결과

{ "_id" : ObjectId("4cfa43ff528bad4e29beec57"), "name" : "black", "value" : "000000" }
{ "_id" : ObjectId("4cfa5830528bad4e29beeca8"), "name" : "white", "value" : "FFFFFF" }
{ "_id" : ObjectId("4cfa5839528bad4e29beeca9"), "name" : "red", "value" : "FF0000" }

Mongo 쉘 외부에서는 애플리케이션에서 update 함수를 사용하여 기존 데이터를 변경한다. update 함수에 대한 자세한 정보는 MongoDB 문서를 참조한다.

데이터 삭제

MongoDB에서 데이터를 삭제하려면 remove 함수를 사용한다. 이는 MongoDB 쉘 프로그램에도 적용되며, 일부 드라이버가 delete 함수를 구현할 수도 있고 그렇지 않을 수도 있다. 필요한 경우에는 특정 구현에 대한 문서를 확인한다.

remove 함수는 find 함수와 비슷하게 작동한다. colors 콜렉션에서 이름이 white인 문서와 일치하는 문서를 제거하려면 다음 명령을 사용한다. > db.colors.remove({name:"white"});.

그런 다음, 다음과 같이 이 문서가 제거되었는지 확인한다. > db.colors.find();.

모든 것이 제대로 되면 문서 두 개만 표시된다(목록 25 참조).

목록 25. 데이터 삭제

{ "_id" : ObjectId("4cfa43ff528bad4e29beec57"), "name" : "black", "value" : "000000" }
{ "_id" : ObjectId("4cfa5839528bad4e29beeca9"), "name" : "red", "value" : "FF0000" }

콜렉션에서 모든 문서를 제거하려면 다음과 같이 명령에서 필터를 생략한다. > db.colors.remove();.

이제는 다음과 같이 find 함수를 사용하려고 해도 응답이 표시되지 않으며 이는 결과 세트가 없다는 것을 의미한다. > db.colors.find();.

변수에 문서를 저장한 경우에는 이 문서를 remove 함수에 전달하여 문서를 삭제할 수 있지만, 이렇게 하는 것은 효과적인 방법이 아니다. 그 대신 이 문서의 _id 속성을 찾아서 remove 함수에 전달하는 것이 더 나은 방법이다.

콜렉션을 삭제하려면 다음 명령을 사용한다. > db.colors.drop();.

이 명령은 true를 리턴한다.

이제 show collections 명령을 사용하여 실제로 콜렉션이 삭제되었는지 확인한다. 그러면 목록 26과 같은 결과가 표시된다.

목록 26. show collections 명령 사용

alphabet
system.indexes

마지막으로 전체 데이터베이스를 제거할 경우에는 다음 명령을 수행한다. > db.dropDatabase();.

이 명령은 현재 선택된 데이터베이스를 삭제한다. 다음과 같은 결과가 표시된다. { "dropped" : "mymongo", "ok" : 1 }.

show dbs 명령을 사용하여 사용 가능한 데이터베이스 목록을 확인한다. mymongo는 이 목록에 표시되지 않는다.

위로

도구와 기타 기능

MongoDB에는 데이터베이스를 관리하는 데 필요한 일련의 유용한 유틸리티가 포함되어 있다. 또한, MongoDB에는 보고나 백업을 위해 데이터를 가져오거나 내보낼 수 있는 다양한 수단이 있다. 이번 섹션에서는 파일을 JSON 형식으로 가져오거나 내보내는 방법과 복구를 하는 데 더욱 효과적인 핫 백업 파일을 작성하는 방법을 알아본다. 또한, map/reduce 함수를 복잡한 데이터 수집에 필요한 Mongo의 일반 쿼리 함수의 대체 수단으로 사용하는 방법을 배운다.

데이터 가져오기 및 내보내기

MongoDB의 bin 디렉토리에는 다양한 형식으로 데이터를 가져오고 내보낼 수 있는 일련의 유틸리티가 있다. mongoimport 유틸리티를 이용하면 각 행에 JSON, CSV 또는 TSV 형식의 문서가 포함되어 있는 파일을 제공하고 이러한 각 문서를 MongoDB 데이터베이스에 삽입할 수 있다. MongoDB에서는 BSON 형식을 사용하므로 JSON 문서를 가져올 경우, 일반 JSON으로는 사용 불가능한, BSON의 추가 데이터 형식을 이용하려면 수정자 정보를 일부 제공해야 한다.

mongoexport 유틸리티를 이용하면 JSON이나 CSV 형식으로 표현된, MongoDB 데이터베이스의 모든 문서가 있는 파일 결과물을 생성할 수 있다. 이 유틸리티는 애플리케이션에서 JSON이나 CSV 데이터를 입력으로 받아서 보고서를 생성하는 데 유용하다. CSV 파일을 생성하려면 결과 파일에 표시되는 순서에 해당 필드를 제공해야 한다.

데이터베이스 백업 및 복원

mongoimport 및 mongoexport 유틸리티는 MongoDB에서 데이터를 가져와서 다른 애플리케이션에서 사용하거나 JSON 또는 CSV 데이터를 사용 가능하게 할 수 있는 다른 애플리케이션에서 데이터를 가져오는 데 유용하다. 그러나 이러한 유틸리티는 MongoDB 데이터베이스를 주기적으로 백업하거나 복원하는 데는 사용되지 않는다. MongoDB에서는 JSON이나 CSV 대신 BSON을 사용하기 때문에 이러한 형식으로 데이터를 가져올 경우에는 데이터 유형을 유지하기가 어렵다.

적당한 백업 및 복원 기능을 제공하기 위해 MongoDB는 두 가지 유틸리티(mongodump 및 mongorestore)를 제공한다. mongodump는 데이터베이스의 2진 백업 파일을 생성하며 mongorestore는 이 파일을 읽어서 이 파일을 사용하는 데이터베이스를 복원하고 필요에 따라 자동으로 인덱스를 작성한다(백업 디렉토리에서 system.indexes.bson 파일을 제거하지 않는 한).

위로

관리 유틸리티

또한, MongoDB는 웹 기반 진단 인터페이스를 제공하며, MongoDB가 기본값으로 구성된 경우에는 이 인터페이스를 http://localhost:28017/ URL에서 이용할 수 있다. 이 화면은 그림 2에 있는 스크린샷과 같다.

그림 2. MongoDB의 진단 인터페이스

기타 관리 정보를 얻으려면 MongoDB 쉘에서 다음 명령을 실행한다.

db.serverStatus();
db.stats();

MongoDB 서버가 파손되는 경우에는 데이터베이스를 복구하여 손상이 없는지 확인하고 데이터 압축을 일부 수행한다. OS 명령행에서 mongod --repair를 실행하거나 MongoDB 쉘에서 db.repairDatabase(); 명령을 사용하여 복구를 실행할 수 있다. 후자는 데이터베이스 레벨에 따라 실행되므로 해당 서버에서 각 데이터베이스를 대상으로 이 명령을 실행해야 한다.

또한, 유효성 검증 함수를 사용하여 콜렉션 데이터의 유효성을 검증할 수 있다. contacts라는 콜렉션이 있는 경우에는 db.contacts.validate(); 명령을 사용하여 콜렉션의 유효성을 검증할 수 있다.

이외에도 MongoDB에는 DBA에게 도움이 되는 기능이 많이 있다. 이외에도 다양한 써드파티 관리 도구와 인터페이스를 사용할 수 있다. 자세한 정보는 MongoDB 문서를 참조한다.

map/reduce

뷰 엔진은 기본적으로 map/reduce 함수를 사용하여 데이터를 필터링하고 수집하므로 이전에 CouchDB 데이터베이스를 사용한 적이 있으면 map/reduce 함수에 익숙할 것이다. 그러나 MongoDB에서는 이렇게 하지 않으며 간단한 쿼리와 필터링 및 수집 기능은 map/reduce 함수에 의존하지 않는다. 그러나 MongoDB는 대용량 데이터 세트를 수집하는 데 사용할 수 있는 map/reduce 구현을 제공한다.

map/reduce는 그 자체로도 하나의 기사가 될 수 있다. 그러므로 MongoDB의 map/reduce 구현에 대한 자세한 정보는 MongoDB 문서를 참조한다(링크는 참고자료 참조).

위로

MongoDB 확장

키/값 저장소와 문서 지향 데이터베이스가 최근에 널리 사용되는 기본적인 이유는 확장성이 우수하고 메모리를 적게 사용한다는 데 있다. 이러한 점을 활용하기 위해 MongoDB는 이번 섹션에서 배우게 될 샤딩과 복제 개념에 의존한다. 이외에도 GridFS를 사용하여 대용량 파일을 MongoDB에 저장하는 방법을 배운다. 마지막에는 쿼리를 프로파일링하여 데이터베이스의 성능을 최적화하는 방법을 배운다.

샤딩

데이터베이스 인프라의 핵심 부분은 확장성에 있다. MongoDB 구현은 자동 샤딩 메커니즘을 사용하여 수평으로 확장되며, 이 메커니즘을 이용하면 자동 로드 밸런싱, 단일 장애 지점 불허 및 자동 장애 복구 기능과 더불어 MongoDB 구성을 수천 개의 노드로 확장할 수 있다. MongoDB 클러스터에 시스템을 새로 추가하는 것도 매우 간단하다.

MongoDB의 자동 샤딩 기능의 장점은 애플리케이션 코드를 거의 변경하지 않고도 단일 서버에서 샤딩된 클러스터로 이동하기가 매우 간단하다. 자동 샤딩이 작동하는 과정과 자동 샤딩을 구현하는 방법과 관련된 자세한 문서는 MongoDB 문서를 참조한다.

복제

MongoDB는 장애 복구와 중복을 구현하기 위해 MySQL과 마찬가지로 마스터-슬레이브 구성의 복제 기능을 제공하며, 이 기능은 노드 간의 일관성을 높은 수준으로 보장한다. 또는 MongoDB에서는 복제 세트를 사용하여 언제든지 노드를 기본 노드로 정의할 수 있으며 장애가 발생했을 때는 또 다른 노드를 기본 노드로 대체할 수 있다.

복제를 기본으로 하여 확장을 하는 CouchDB와 달리, MongoDB에서는 슬레이브 노드를 중복 복제본으로 사용하여 고가용성을 보장하기 위해 주로 복제를 사용한다.

MongoDB 복제에 대한 자세한 정보는 MongoDB 문서를 참조한다(링크는 참고자료 참조).

GridFS를 사용하는 대용량 파일 스토리지

MongoDB 데이터베이스는 BSON 문서로 데이터를 저장한다. 그러나 BSON 문서의 최대 크기는 4MB이기 때문에 BSON 문서로 대용량 파일이나 오브젝트를 저장하는 것은 적합하지 않다. MongoDB에서는 GridFS 스펙을 사용하여 파일을 작은 청크로 나누고 다수의 문서에 분배하여 대용량 파일을 저장한다.

표준 MongoDB 배포판에는 GridFS 파일을 로컬 파일 시스템에 추가하거나 로컬 파일 시스템에서 GridFS 파일을 검색하는 데 필요한 명령행 유틸리티가 들어 있다. 이외에도 모든 공식 MongoDB API 드라이버에는 GridFS에 대한 지원이 포함되어 있다. 자세한 내용은 MongoDB 문서를 참조한다(참고자료 참조).

위로

결론

이 기사에서는 MongoDB 데이터베이스 관리 시스템을 배웠으며 MongoDB가 DBMS 시장의 인기 있는 NoSQL 섹션에서 가장 빠르게 성장하는 옵션 중 하나인 이유를 알아 보았다. 또한, 기존의 RDBMS에 비해 문서 지향 데이터베이스를 선택하는 이유와 MongoDB에서 제공하는 여러 가지 우수한 기능을 배웠다. 더불어 MongoDB를 설치하는 방법과 MongoDB를 사용하여 데이터를 저장하고 검색하는 방법을 배웠을 뿐만 아니라 MongoDB에서 제공하는 다양한 도구와 확장성 옵션을 알아 보았다.

참고자료

교육

공식 MongoDB 사이트를 방문하자.
Wikipedia의 MongoDB 목록을 읽어보자.
공식 MongoDB 문서에 액세스할 수 있다.
MongoDB map/reduce 함수를 자세히 배우자.
MongoDB Cookbook에는 MongoDB를 사용하는 일반적인 방법이 자세히 설명되어 있다.
Twitter의 MongoDB 페이지를 팔로우하자.
developerWorks에 있는 "An introduction to MongoDB" 데모를 보자.
developerWorks의 지식 경로를 통해 NoSQL을 사용하는 방법과 대용량 데이터를 분석하는 방법을 배우자.
한 회사에서 MySQL을 MongoDB로 전환한 방법을 확인하려면 Notes from a production MongoDB deployment를 읽어 본다.
Collective Idea가 어떻게 전환했는지 배우려면 Reflections on MongoDB을 읽어보자.
Wordnik이 어떻게 전환했는지 배우려면 12 Months with MongoDB 블로그를 읽어보자.
Eltot Horowitz(MongoDB를 후원하는 회사인 10gen의 CTO)의 MongoDB 관련 팟캐스트를 들어보자.
10gen에서는 확장 가능한 고성능 문서 지향 오픈 소스 데이터베이스인 MongoDB를 개발하고 지원한다.
Java development 2.0: MongoDB: A NoSQL datastore with (all the right) RDBMS moves(Andrew Glover, developerWorks, 2010년 9월): MongoDB의 사용자 정의 API, 대화식 쉘, RDBMS 스타일 동적 쿼리 및 빠르고 쉬운 MapReduce 계산에 관해 자세히 배우자.
Exploring CouchDB(Joe Lennon, developerWorks, 2009년 3월): Apache의 오픈 소스 CouchDB는 스키마 없는 문서 지향 데이터베이스 모델로 부르는 것으로 데이터를 저장하는 새로운 방법을 제공한다. CouchDB는 관계형 모델의 고도로 구조화된 데이터 스토리지 대신, 반구조화된 문서로부터 구조화된 수집 및 보고 결과를 생성하는 데 필요한 Javascript 기반 뷰 모델을 사용하여 반구조화된 형식으로 데이터를 저장한다.
관심 이벤트: IBM 오픈 소스 개발자에게 유익한 컨퍼런스, 기술 박람회, 웹 캐스트 및 기타 행사를 확인하고 참여하자.
developerWorks 오픈 소스 영역: 오픈 소스 기술을 사용하여 개발하고 이러한 기술을 IBM 제품과 함께 사용하는 데 도움이 되는 광범위한 사용법 정보, 도구 및 프로젝트 업데이트를 찾아보자.

제품 및 기술

MongoDB를 다운로드하자.
IBM 시험판 소프트웨어: 다운로드하거나 DVD로 이용할 수 있는 IBM 시험판 소프트웨어를 사용하여 차기 오픈 소스 개발 프로젝트를 강화하자.

토론

developerWorks 커뮤니티: 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다. developerWorks 커뮤니티에서 Real world open source 그룹을 빌드하는 데 도움을 주자.

필자소개

Joe Lennon은 소프트웨어 개발자로 24살이며 아일랜드 코크에 살고 있다. Joe Lennon은 Beginning CouchDB의 저자이며, 이 책은 Apress에서 출간될 예정이다. 그는 여러 개의 기술 관련 기사와 튜토리얼을 IBM developerWorks에 기고했다. 한가로운 때에는 축구를 하거나 가젯을 조작하며 Xbox 360 게이머 점수를 높이기 위해 노력한다. 그의 웹 사이트 주소는 www.joelennon.ie이다.

닫기 [x]

잘못된 도움말 신고

재고되고 있는 데이터 정규화, Part 2: 21세기의 비즈니스 기록

가을의 곰을... — Sat, 07 Jul 2012 00:29:02 +0900

◎ 연재기사 ◎

▷ 재고되고 있는 데이터 정규화, Part 1: 비즈니스 기록의 역사
▶ 재고되고 있는 데이터 정규화, Part 2: 21세기의 비즈니스 기록

재고되고 있는 데이터 정규화, Part 2: 21세기의 비즈니스 기록

컴퓨터 시스템에서 유지되는 기록의 조사

소개

두 파트로 구성된 이 시리즈의 첫 번째 파트에서는 21세기 이전의 기록 보존 체계와 관계형 데이터베이스 및 웹의 효과를 살펴보았다. 컴퓨팅 시스템이 도입되기 전에는 비즈니스 기록을 원래의 비정규화된 형식으로 그대로 저장했다. 이러한 사례로는 석판, 엄대 및 종이 양식이 있다. 컴퓨팅 시스템이 도입되면서 비즈니스 기록을 공간을 절약하고 데이터베이스에서 이상 항목을 업데이트하지 않아도 되는 다양한 표현으로 변환하기 위해 데이터 정규화가 고안되었다. 그러나 정규화된 표현은 원래의 데이터와는 매우 다르고 이해하기도 어렵다.

두 파트로 구성된 이 시리즈의 두 번째 파트에서는 데이터 형식의 경향과 21세기의 비즈니스 기록을 살펴본다. 여기에서는 먼저, 사례 연구를 통해 정규화하지 않고 디지털화한 비즈니스 기록의 이점, 즉 우수한 성능과 낮은 애플리케이션 개발 및 유지보수 비용을 강조한다. 또한, JSON 및 RDF와 같은 기타 새로운 데이터 표현을 살펴보고 관련된 사용 시나리오에 대해 이러한 표현의 장단점을 집중적으로 설명한다.

관계형 및 XML 데이터 표현: 비교

오늘날에는 많은 시스템과 애플리케이션이 비즈니스 기록을 XML 문서로 작성하고 표현한다. 예를 들면, 각각의 주문, 금융 거래, 세금 반환, 보험 청구 등은 주로 별도의 XML 문서로 되어 있다. 그 이유는 XML이 확장 가능하고 유연하며 자기 기술적이고 구조화된 정보와 비구조화된 정보 및 반구조화된 정보에 적합하기 때문이다. XML의 이러한 특성 때문에 훨씬 더 복잡한 기록을 표현하고, 필요에 따라 데이터 표현을 확장하고, 애플리케이션(A2A)이나 조직(B2B) 간에 비즈니스 기록을 교환하기가 용이하다. 이로 인해 XML은 웹 서비스와 SOA(Service-Oriented Architecture)에 적합한 데이터 형식이 되었다. 이러한 경향에 대응하여 주요 데이터베이스 벤더는 그들의 제품에[1] [3] [5] XML 기능을 추가했으며 여러 가지 XML 전용 데이터베이스가 출현했다[6]. 이러한 제품에서는 관계형 데이터와 동일한 여러 가지 특성(예: ACID 트랜잭션, 복구 가능성, 확장 가능성, 고가용성)을 사용하여 XML을 저장 및 인덱스화하고, 쿼리 및 업데이트할 수 있다. 이러한 데이터베이스 기술의 발전 덕택에 비즈니스 기록을 원래의 형식, 즉 XML로 저장하고 관리할 수 있게 되었다. 이 섹션에서는 (역)정규화와 중복 및 성능 관점에서 XML과 관계형 데이터베이스를 비교한다.

예제

XML은 계층 구조적 데이터 형식이기 때문에 일대다 관계를 불연속 오브젝트 세트로 정규화하지 않고도 하나의 문서로 이러한 관계를 얼마든지 표현할 수 있다. 고객을 설명하는 비즈니스 기록을 생각해 보면, 각 고객에게는 주소, 휴대전화 번호, 이메일 주소, 중간 이름 및 투자 계정이 여러 개 있을 수 있다. 게다가, 각 고객의 계정에는 여러 가지 포지션(보유)이 있을 수 있고, 각 주소에는 "거리" 항목이 여러 개 있을 수 있다. 그림 1에 표시되어 있듯이 정규화된 관계형 스키마에서는 이러한 각각의 일대다 관계를 유지하려면 추가로 테이블이 필요하다. 결국, 하나의 비즈니스 기록을 저장하려면 여러 개의 테이블에 다수의 SQL INSERT 문이 있어야 하며 이 예제에서는 12개의 테이블에 최대 12개의 INSERT 문이 필요하다.

마찬가지로 애플리케이션이 하나의 고객 레코드를 검색할 때는 12개의 테이블 모두를 대상으로 SELECT 문을 실행해야 한다. 이 프로세스를 수행하려면 데이터베이스에 대한 별도의 API 호출이 12개 이상 필요하기 때문에 이 프로세스는 비효율적이다. 이렇게 호출될 때마다 네트워크 트래픽이 발생하며 데이터베이스 테이블과, 테이블 및 인덱스로 향하는 실제 I/O에 액세스하게 된다. 12개의 테이블 모두를 결합하는 하나의 쿼리가 일반적으로 훨씬 더 나쁘다. 예를 들어, 표 1 - 3에 표시되어 있듯이 고객에게 총 7개의 포지션이 있는 3개의 계정이 있는 경우에는 표 4에 표시되어 있듯이 이러한 세 개의 테이블 간의 결합에서 7개의 열이 리턴된다. 이 결과 세트에서는 고객 테이블에서 선택된 값이 일곱 번 반복되었으며 모든 계정의 값이 계정의 각 포지션에 대해 반복되었다. 이러한 중복으로 인해 결과 세트의 크기가 증가되고 클라이언트 서버 간의 통신이 지연되어 성능이 악화된다. 더 많은 테이블이 결합에 추가되면 결과 세트는 빠르게 증가하고 이로 인해 문제점이 확대된다.

표 1 - 3에는 고객, 계정 및 포지션 데이터의 정규화된 관계형 스키마가 표시되어 있다.

또한, 표 4에서는 데이터베이스 스키마를 역정규화하는 과정에서 데이터 중복이 발생한다는 것을 알 수 있다. 목록 1에는 동일한 논리적 비즈니스 기록을 XML로 표현한 코드가 표시되어 있다. 정규화된 관계형 스키마는 고객 정보를 다수의 테이블에 분산하는 반면에 XML의 트리 구조는 동일한 일대다 관계를 하나의 문서로 표현한다. 동시에 "Account"와 같은 각 하위 노드에서는 "Customer"와 같은 상위 노드가 반복되지 않기 때문에 XML 문서에는 중복된 부분이 없게 된다. 따라서 XML은 중복을 일으키지 않고도 비정규화된 하나의 문서로 비즈니스 기록을 표현할 수 있다. 결국, 하나의 SQL문으로 비즈니스 기록을 삽입하거나 검색할 수 있게 되어 데이터베이스 API 호출 수, 애플리케이션 복잡도, CPU 비용 및 네트워크 트래픽을 줄일 수 있게 된다. 다음 섹션에서 살펴보겠지만, 이러한 장점은 다수의 상업용 데이터베이스 시스템에서 관찰되고 평가되었다.

OLTP 시스템에서의 XML과 관계형 구조의 성능 비교

비즈니스 기록을 정규화된 관계형 열 대신 비정규화된 하나의 XML 문서로 삽입하고 검색함으로써 얻을 수 있는 이점은 데이터베이스 전문가 사이에서 주목을 끌었다. 전세계에 있는 주요 물류 사업자는 이러한 가치 제안을 테스트했다. 그들의 OLTP 시스템 중 하나는 특정 비즈니스 기록을 12개의 테이블로 구성된 정규화된 관계형 스키마로 표현한다. 비즈니스 기록 하나를 검색하려면 애플리케이션은 15개의 SQL문을 실행해야 한다. 대부분의 비즈니스 기록은 15개의 열로 표현되지만, 일부는 수백 개의 열로 구성된다. 그들은 비교를 위해 25만 개의 비즈니스 기록을 선택하여 하나의 비즈니스 기록을 하나의 XML 문서로 변환했다. 대부분 문서는 크기가 1 - 2KB였지만 일부 문서의 크기는 최대 500KB였다.

테스트 시나리오에서는 32GB 메모리의 8 코어 AMD Opteron 서버에서 Linux RHEL 4.6과 DB2 9.5 수정팩 4를 사용했다. 최대 7개의 클라이언트 시스템을 사용하여 데이터베이스에 액세스하는 동시 사용자 수가 증가하는 과정을 시뮬레이션했다. 각 클라이언트는 IBM xSeries 345(2 코어) 시스템이었다. 12개의 관계형 테이블 각각에는 적절한 인덱스가 있었다. 비교를 위해 XML 문서를 하나의 테이블과, 레코드 ID 속성에 하나의 XML 인덱스가 있는 하나의 XML 열에 저장했다. 관계형 테스트에서는 시뮬레이션된 각각의 동시 사용자가 무작위로 레코드 ID를 선택했으며, 각 ID로 15개의 SQL 쿼리로 된 트랜잭션을 실행하여 해?? 고려되지 않았다. XML 테스트에서 각 동시 사용자는 레코드 ID를 무작위로 선택하여 XMLEXISTS 조건부에서 XPath 표현식으로 하나의 SQL/XML 쿼리를 실행하여 XML 문서를 검색했다.

그 결과는 그림 2에 표시되어 있다. 평균적으로 XML 솔루션은 정규화된 관계형 스키마보다 처리 속도가 55% 더 빨랐다. 관계형 테스트에서는 84명의 사용자가 초당 약 3800개의 트랜잭션을 동시에 수행하자 테스트에 사용된 시스템의 CPU 용량이 고갈되었다. XML 솔루션을 사용한 경우에는 동일한 시스템이 최대 150명의 동시 사용자와 초당 약 6000개의 트랜잭션을 지원했다. 동시에 XML 솔루션은 관계형 솔루션보다 클라이언트 시스템의 CPU 사용량이 매우 낮았다.

물류 회사의 경우에는 성능이 높아지고 CPU 사용량이 낮아진다는 점 외에도 비정규화된 XML 솔루션의 이점이 많이 있다. 예를 들면, 각 XML 문서는 클라이언트 애플리케이션이 바로 사용할 수 있게 되지만, 검색된 관계형 열을 사용하려면 비즈니스 기록을 구성해야 하기 때문에 그림 2에는 표시되어 있지 않지만 추가 작업이 필요하다. 또한, XML 솔루션에는 더 단순한 데이터베이스 스키마가 있어서 시간이 경과하여 기록 형식이 발전되었을 때 유지보수하기가 더 수월하다. 비즈니스 기록이 데이터베이스와 애플리케이션(XML)에서 동일하게 표현되기 때문에 애플리케이션 개발이 단순해진다. 이러한 이점은 XML 기반 유형 처리, 이벤트 로깅 및 주문 처리에서도[??4] 보고되었다.

XML에 액세스하는 것이 동일한 비즈니스 기록을 표현하는 정규화된 관계형 테이블에 동일하게 액세스하는 것보다 CPU를 적게 사용한다. 비즈니스 기록 자체를 XML로 전송하는 대신 관계형 결합으로 비즈니스 기록을 재구성하면 데이터베이스와 클라이언트 간에 더 많은 데이터가 전송된다. 게다가, XML은 실제 비즈니스 기록과 동일하지는 않다고 해도 더 유사하기 때문에 이해하기가 더 수월하다. 별도의 논리적 데이터 모델은 더 이상 필요하지 않다. 실제 비즈니스 기록과 컴퓨터 안에 저장된 기록 간의 맵핑이 필요하지 않다.

정규화를 통해 데이터를 트리플로 변환하는 과정은 강력한 통합을 이끌어 낼 수 있는 RDF 저장소를 형성하는, 시맨틱 웹의 핵심 부분이다. 정보를 가장 작은 요소인 트리플로 분할하면, 주부와 오브젝트를 노드로하고 술부를 연결부로 하는 그래프로 데이터를 표현할 수 있다. 추론 소프트웨어(추론자)는 그래프를 분석하고 규칙을 적용하여 새로운 문장을 추론할 수 있다. 예를 들면, 부서에는 직원이 있고 인적자원이 부서이면 인적자원에는 직원이 있다고 추론할 수 있다.

관계형 테이블의 기본 키와 외부 키가 그러하듯이 연결된 데이터 링크는 일반적으로 최신 정보만 연결한다. 예를 들면, 관계형 키를 링크하거나 탐색하여 생성되는 주문의 감사는 현재의 고객 주소를 선택하지, 주문을 한 시점에서의 고객 주소를 선택하지는 않는다. 비즈니스 시스템에서는 감사와 준수상의 이유로 주문 수령이나 계좌 입출금내역서 발생과 같은 중요한 이벤트가 발생하는 시점에서 관련된 비즈니스 정보의 스냅샷을 작성해야 한다. 스냅샷의 목적은 나중에 탐색하기 위한 것이 아니라 감사나 쿼리가 이루어질 때 비즈니스 기록을 재생성하기 위한 것이다. 때로는 비즈니스 기록이 작성된 이후로 변조되지 않았다는 증거로 스냅샷에 서명을 한다.

극도로 정규화된 형식인 RDF는 버전화를 처리하고 히스토리와 감사를 관리하기 어렵다는 점에서 정규화된 관계형 데이터와 유사하다. RDF는 고정된 스키마에 구속되지 않는다는 점에서 정규화된 관계형 데이터와 다르다. 자원에 특성이 새로 추가되면 특성을 쉽게 표현하기 위해 추가적 문장(트리플)을 추가한다. 그러나 트리플이 기존의 관계형 스키마보다 쿼리하기가 더 어려울 수 있다.

연결된 데이터와 시맨틱 웹의 메커니즘은 강력하여 겉으로는 관련이 없는 시스템을 통합할 수 있다. 호텔과 항공권 예약, 주문 처리 또는 보험 연장을 소셜 네트워킹 정보와 통합하는 것을 예로 들 수 있다. 시맨틱 어노테이션(트리플)으로 XML 형식의 비즈니스 기록을 증대하면 기존의 비즈니스 기록을 연결된 데이터 및 시맨틱 웹 구성과 융합할 수 있다. 실제로 Best Buy(미국 소매상점)에서는 검색 엔진 및 분류기와 같은 프로그램을 통해 처리할 수 있는 RDF(RDF 어노테이션)를 사용하여 제품을 기술하는 XHTML 페이지를 어노테이션한다[??9].

관계형 데이터베이스 스키마를 변경하지 않으면서 관계형 데이터를 증대할 수 있는 메커니즘이 없기 때문에, 어노테이션을 적용하기가 수월한 XML 비즈니스 기록과 비교해 볼 때 관계형 데이터베이스는 시맨틱 어노테이션과 융합하기가 더 어렵다.

JSON

JSON(JavaScript Object Notation)은 Javascript 프로그래밍 언어의 서브세트를 기반으로 하며 정보를 Javascript 클라이언트에 표시하기 위해 널리 사용된다[?10]. 실제로 많은 REST 및 웹 API가 XML과 JSON 변종을 모두 제공한다. JSON은 Javascript로 사용자 인터페이스를 빌드하는 데 적합한 경량 데이터 교환 형식이다. JSON은 사람이 읽고 쓰기가 수월하며 Javascript로 구문 분석하고 생성하기도 쉽다. 표 8에는 데이터 샘플이 있을 뿐만 아니라 JSON과 XML 표기법도 비교되어 있다.

JSON은 쿼리 결과를 즉시 형식화하여 Javascript 클라이언트에 맞게 처리를 단순화하는 데 매우 적합하다. 따라서 JSON은 웹 애플리케이션에 매우 적합하다. 그러나 JSON에는 네임스페이스가 없기 때문에 제한조건이 사용 가능한 경우에도 이 제한조건을 손쉽게 공유하거나 확장 또는 혼합할 수 없다. 스키마 또는 변환 언어와 같은 JSON 스펙에 대한 지원은 존재하지 않거나 XML 스펙에 못미친다. 데이터 정규화 면에서 JSON에 XML과 같은 이점이 일부 있다고 하더라도 표 9에 표시되어 있듯이 JSON은 XML만큼 성숙되지 않았다.

요약

초기에 매우 상업적인 프로젝트에서 시작된 프로세스인 데이터 정규화로 인해 비즈니스 기록을 거의 언제나 원래의 형식인 XML로 저장하지 못한다. 게다가 XML 비즈니스 기록에 대한 작업은 비효율적이라고 여겨지기도 한다. 이 기사에 있는 성능 비교 결과를 살펴보면 이러한 생각이 꼭 타당한 것은 아니라는 점을 알 수 있다. 사실상, 정규화된 테이블에서 비즈니스 기록을 검색하고 재구성하는 데 들어가는 비용이 비정규화된 XML 문서를 원래대로 저장하고 검색하는 데 필요한 비용보다 더 높은 경우가 많다. 그래서 XML을 비즈니스 기록을 표현하기 위해 사용하는 경우에는 XML을 해당 저장 형식으로 고려해야 한다. 오브젝트 지향 데이터 액세스는 정규화된 관계형 테이블보다는 XML에서 더 잘 수행되며 높은 XML 트랜잭션 비율을 허용한다[2]. 또한, XML을 이용하면 관계형 테이블과 XML 간의 맵핑을 설계하고 유지보수할 필요가 없기 때문에 신속하게 애플리케이션 프로토타입을 작성하여 애플리케이션을 개발하고 발전시켜나갈 수 있다.

또한, Google Big Table 및 HBase와 같은 새로운 스토리지 시스템은 정규화를 하지 않는다. 이러한 시스템에서는 강력한 역정규화를 따르고 데이터를 액세스하는 방식에 따라 데이터를 저장일치하는 수준에서 가장 잘 저장된다는 사실은 XML 데이터?이터, 시맨틱 웹 및 JSON은 최근에 생겨난 데이터 표현이지만 아직은 비즈니스 시스템에서 시스템 간 데이터 교환을 위해 널리 사용되고 있지는 않다. 정규화를 통해 데이터를 트리플로 변환하는 과정은 추론을 통해 새로운 사실을 이끌어낼 수 있는 RDF 저장소를 형성하는, 시맨틱 웹의 핵심 부분이다. XML로 표현된 비즈니스 기록을 RDFa와 같은 시맨틱 어노테이션으로 증대하면 기존의 비즈니스 기록을 연결된 데이터 및 시맨틱 웹과 융합할 수 있다.

이러한 발전에도 불구하고 정규화는 여전히 사용되고 있다. 정규화는 여전히 유용하며, 예를 들어 높은 업데이트 율을 지원하는 기존의 관계형 트랜잭션 처리 시스템에서는 원래의 비즈니스 기록을 거의 재구성하지 않아도 될 뿐만 아니리 기존 업데이트 대신 새 레코드 버전을 삽입하지도 않는다(표 10 참조).

관계형 데이터베이스 시스템, 데이터 정규화 및 XML로 표현된 비즈니스 기록은 그 당시에는 모두 타당한 이유가 있었기 때문에 대단한 성공을 거둘 수 있었다. 21세기에는 일반적으로 비즈니스 기록을 "그대로" 저장하고 조작한다. 실제 세계와의 유사성을 비교하자면, 사람은 장롱안에 있는 의복 및 주차장 안에 있는 자동차와 같은 실물을 취득하여 조작하고 저장한다. 이러한 것들은 주요한 액세스 유형에 매우 적합한 형태로 저장된다. 다시 말해서 자동차와 의복은 먼저 여러 개의 조각으로 분해되지 않고 그대로 저장된다(그림 3 참조).

결론

두 파트로 구성된 이 시리즈에서는 비즈니스 기록을 변경하지 않고 저장하고 데이터 관리 솔루션을 신속하게 전달하지 못하게 하는 주요 장벽을 데이터 정규화로 간주했다. 효과적인 XML 데이터베이스는 즉시 사용 가능하지만[7], 시스템 설계의 초기 단계에서 정규화가 통합되어 원래의 비즈니스 기록을 추적할 수 있는 모든 데이터가 제거되기 때문에 XML 데이터베이스의 효율성이 간과되는 경우가 많다. 데이터 정규화는 조심스럽게 재고되어야 한다.

출처 : 한국IBM

제공 : DB포탈사이트 DBguide.net

재고되고 있는 데이터 정규화, Part 1: 비즈니스 기록의 역사

가을의 곰을... — Sat, 07 Jul 2012 00:27:24 +0900

◎ 연재기사 ◎

▶ 재고되고 있는 데이터 정규화, Part 1: 비즈니스 기록의 역사
▷ 재고되고 있는 데이터 정규화, Part 2: 21세기의 비즈니스 기록

재고되고 있는 데이터 정규화, Part 1: 비즈니스 기록의 역사

컴퓨터 시스템에서 유지되는 기록의 조사

소개

이 기사에서는 상업용 시스템의 데이터 정규화의 역할이[30] 변화하는 과정을 설명한다. 1970년대 이후, 데이터 정규화가 정의되었을 때 컴퓨터 기술과 시스템 및 애플리케이션은 상당히 진화했다. 특히 1970년대에는 데이터 구조가 안정적이었으며 디스크 공간은 매우 제한되어 있었고 비즈니스 정보는 종이에 기록되어 있었다. 종이를 컴퓨터가 읽을 수 있는 형식(예: 천공 카드)으로 변환하려면 사람들과 입/출력(I/O) 디바이스가 필요했다. 은행과 같은 기관에서 소유한 대형 컴퓨터는 메모리 용량이 512KB였으며 가격은 거의 $2,000,000였다. 대형 기관에는 모든 컴퓨터 시스템과 데이터를 저장하기 위해 10MB의 디스크 공간이 있었다. 1970년대에는 인터넷 인프라가 막 구축되기 시작했으며 월드 와이드 웹은 10년이 지난 후에나 개발되었다.

디스크 공간이 극히 제한되어 있었기 때문에 최신 정보만 저장해서 애플리케이션에서 사용할 수 있게 하였다. 정규화는 이름, 주소 또는 주문 정보와 같은 각 데이터 조각을 디스크에서 정확히 한 번만 표시하여 데이터 이상 항목을 피하고 공간을 보존할 수 있게 한다. 일반적으로 데이터 정규화는 컴퓨터 시스템에만 존재하며 데이터의 원래 비즈니스 표현과 일치하지는 않는다. 21세기에는 비즈니스 데이터가 거의 언제나 웹 서비스 요청의 주문 메시지와 같은 디지털 형식으로 작성되었다. 따라서 정규화는 디지털로 표현된 기존의 비즈니스 기록을 쪼개서 데이터베이스에 저장한 다음, 나중에 다시 재구성하여 이러한 비즈니스 기록을 표시하고 사용한다.

관계형 모델의 기반이 되는 가정이 변화되었다. 오늘날에는 대부분이 시스템과 정보 구조가 더 이상 단순하거나 고정되어 있지 않고 복잡하며 빠른 속도로 변한다. 오늘날의 세계에서는 프로세스로서의 정규화가 애자일 시스템의 전달과 시스템의 애자일 전달 모두에 억제제로 역할을 한다.

이 기사에서는 상업용 컴퓨터가 도입되기 전후의 역사를 살펴보면서 기록 유지에 대해 소개할 것이다. 주목할 만한 점은 역사적으로는 비즈니스 기록을 "그대로" 저장하였으며 컴퓨터가 도입되면서 기록을 여러 개의 조각으로 분리(정규화)하기 시작했다. 이 기사에서는 1970년대에 데이터 정규화를 개발하게 된 동기를 살펴본다. 그다음에는 어느 정도의 데이터 비정규화가 일반적으로 적용되는 타협점이 된다는 점을 설명한다. 끝으로 이 기사에서는 비즈니스 기록이 디지털 형식으로 작성될 수 있게 하는, 비즈니스 기록에 대한 웹의 영향을 살펴본다. 결과적으로 처음에는 비즈니스 기록을 컴퓨터에서 원래 구조로 저장하고 처리하는 것이 가능했다.

히스토리를 통해 기록 유지

이 섹션에서는 컴퓨터가 도입되기 이전의 기록 유지의 특성을 설명하는데, 이는 컴퓨터가 도입되면서 생긴 중요한 변화를 이해하는 데 도움이 된다. 이러한 변화는 나중에 설명한다.

오래 전인 BC 3천년 경에 고대 수메리아[?1]에서 진흙판 형태의 수집된 영수증이 발견되었으며 이러한 영수증은 교환된 후, 기록 유지를 위해 저장되었다. BC 18세기[?2] 경에는 바빌로니아의 대부 기록이 발견되었다. BC 1792년에 바빌론에서 발견된 함무라비 법전에는[3] 진흙판으로 된 기록의 처리 및 유지를 통제하는 문구가 포함되어 있다. 예를 들면, 다음과 같다.

- 빚을 지고 있는데, 폭풍우로 인해 곡식이 피해를 입거나, 수확에 실패하거나 물이 부족하여 곡물이 성장하지 않으면, 그 해에는 채권자에게 곡물을 주지 않아도 되므로 빚진 사람은 계약서(진흙판)를 수정하고 그 해의 이자는 지불하지 않는다.

- 타인의 토지나 집을 샀는데 이 토지나 집이 토지세의 적용을 받는 경우 해당 판매 계약서(진흙판)는 파기되고(무효로 선언됨) 매수자는 돈을 잃게 된다. 토지와 집은 원래의 소유자에게 되돌아간다.

역사적으로 보면 거래 정보를 기록하기 위해 엄대와[?4][?5] 같은 다양한 메커니즘을 도입하였으며 이러한 것들은 종이보다 더 저렴했으며 더 신속하게 이용할 수 있었다. 중세 유럽에서는 막대기에 새김눈을 표기한 후, 세로로 쪼갰다. 반으로 자른 두 개의 막대기에는 동일한 새김눈이 있으며 각 거래 당사자는 증거로서 표시된 막대기의 절반을 받았다. 그런 후에는 이 막대기를 보관하여 유지했다. 쪼개진 엄대는 1826년까지 영국 정부에서 세금을 관리하기 위해 계속해서 사용했다. 더욱 현대적인 기록 방법이[?5] 도입되면서 1834년에는 엄대 상점을 소각하라는 명령이 내려졌다.

20세기 말까지는 비즈니스 거래, 판매 계산서, 계약서 및 기타 중요한 문서를 기록하기 위해 종이와 초창기의 파피루스 및 피지[?6]를 널리 사용했다. 기록물에는 서명을 하였으며 때로는 왁스로 밀봉을 하고 관련된 상인의 표식을 부착했다. 복식 부기와 같은 방법은 15세기에 도입되었다. 서류 작업이 증가했기 때문에 서기가 상인을 지원했다. 20세기에 들어와 컴퓨터가 상업용으로 전환되면서 기업에서는 시스템에 컴퓨터를 도입하기 시작했으며 이렇게 하기 위해서는 실제 종이 기록을 컴퓨터가 인식할 수 있는 표현으로[??7] 전환해야 했다.

컴퓨터가 도입되기 전에는 거래 당사자 간에 교환되는 정보의 정확한 사본을 캡처하여 유지하는 것이 기본적인 기록 보관 원칙이었다. 기록물에는 서명을 하거나 몇 가지 방법으로 표시를 하고 "그대로" 저장하여 나중에 다시 사용할 수 있게 했다. 역사적으로 보면 비즈니스 기록과 계약서의 저장 및 처리를 통제하는 규정이 존재했다.

컴퓨터 시스템의 기록 관리

이 섹션에서는 20세기의 두 번째 파트에서 데이터베이스가 도입된 환경과 이러한 시스템의 기본 목적을 설명한다.

1950년대와 1960년대에 상업 비즈니스를 지원하기 위해 디지털 컴퓨터 시스템을 도입하면서 처음으로 기록이 종이 천공 카드에[8] 저장되었으며 이러한 천공 카드는 입출력을 위해 자주 사용되었다. 오퍼레이터가 비즈니스 거래가 표현된 종이 기록물의 내용을 카드에 입력했기 때문에 컴퓨터가 정보를 읽고 사용할 수 있었다(그림 1). 천공된 카드를 사용하던 시기에 컴퓨터에 데이터를 입력한 방법과 일치하지는 않지만, 컴퓨터 시스템 안에서 저장되고 처리 되는 데이터는 종이에 있는 실제 비즈니스 거래와 더 이상 일치하지 않았다.

대용량 데이터를 컴퓨터 시스템에 입출력하기 위해 계속해서 천공 카드를 사용했지만 1980년대에는 자기 테이프를[9] 사용했으며 곧 디스크 스토리지가[?10] 1960년대의 대형 시스템에서 사용되던 천공 카드를 대체했다. 디스크 스토리지 시대가 도래하면서(그림 2), 디스크의 개별 부분을 프로그래밍 방식으로 주소를 지정할 수 있게 되었기 때문에 데이터를 직접적으로 신속하게 액세스할 수 있는 기능이 가능해졌다. 디스크가 존재하기 이전에는 대부분의 처리가 일괄처리로[?11] 수행되었으며 이런 경우에는 데이터가 테이프에 있는 파일이나 천공 카드에 저장된 순서대로 처리되었다. 디스크를 사용하게 되면서 데이터를 무작위로 액세스할 수 있게 되었다.

1960년대에는 많은 데이터베이스 시스템[?12]과 직접 액세스 파일 시스템이[13] 개발되어 여러 사용자가 동시에 액세스하고 업데이트할 수 있는 디스크에 저장된 데이터를 관리하고 새롭게 사용 가능해진 디스크 스토리를 이용할 수 있게 되었다. 가장 일반적으로 사용된 데이터베이스 구조 중 두 가지는 네트워크 모델(CODASYL)[14]과 계층 구조 모델(IMS)이다[?15]. 데이터베이스에 데이터를 저장하고 애플리케이션을 구현하기 이전에 담당 직원이(데이터 분석가 또는 데이터베이스 관리자)이 데이터 설계를 수행하여 그 시대에는 여전히 종이에 기록되어 있었던 비즈니스 데이터를 계층 구조나 네트워크로 재구성했다. 분석가는 두 가지 데이터 설계 모델, 즉 비즈니스 기록을 프로그래머가 액세스하고 조작할 수 있는 계층 구조에 맵핑하는 논리적 설계와 계층 구조와 네트워크를 디스크에 맵핑하는 물리적 모델을 생성했다. 프로그램은 논리적 모델을 학습했으며 그 시대에 널리 사용된 프로그래밍 언어를 위해 데이터베이스 시스템과 함께 제공된 탐색 가능한 프로그래밍 인터페이스를 통해 데이터베이스에 액세스할 수 있었다(예: 상위 요소 안에서 다음 하위 요소 가져오기).

1970년대에는 대단히 성공한 관계형 모델이[30] 도입되었으며 이 모델은 21세기에도 계속해서 비즈니스 시스템에서 사용되었다. 이 모델에서는 비즈니스 데이터를 테이블에 저장한다. 관계형 모델에서는 탐색 가능한 액세스가 필요 없지만, 여전히 데이터를 분석하여 프로그래머가 선언적 언어인 SQL로 비즈니스 데이터를 액세스하는 테이블로 재구성해야 한다. 1970년대와 1980년대에는 비즈니스 데이터를 여전히 종이에 기록했기 때문에 주로 스캐너를 사용하거나 오퍼레이터가 양식을 다시 입력하여 비즈니스 데이터를 변환해야 했다. 일반적으로 비즈니스 데이터를 재구성하는 과정은 데이터 정규화 원칙을[?16][?17] 따르며 데이터 중복과 이상 항목을 최소화하기 위해 21세기에도 계속해서 데이터 정규화를 학습하고 사용한다.

관계형 데이터베이스 개념이 정리되고 있던 시대에 널리 사용된 디스크 스토리지 디바이스는 200MB를 유지하는 3330 모델 11이었으며 이 모델의 구입 가격은 $74,000 - $87,000(1970년대 달러) 정도였다[?19]. 1980년대 관계형 데이터베이스가 널리 사용되기 시작했을 때 매우 인기 있던 디스크는 3380 모델이었다. 이 모델은 벽장 정도의 크기를 하고 있었고 1.2GB의 스토리지를 포함하고 있었으며 가격은 $200,000였다[?20]. 따라서 디스크 스토리지 1MB의 가격이 $160(1970년대 달러)를 넘었으며 이 가격은 2010년의 수천 달러와 맞먹는 금액이다[21].

일반적으로 관계형 데이터베이스 시스템은 시그너처와 연관된 보안 정보를 유지보수하지 않고 정보 조각을 정확히 한 번, 즉 최신 버전만 포함하기 때문에 감사를 수행하기가 어렵다. 예를 들어, 분쟁이 발생하는 경우에 보험 정책과 관련 소송을 감사할 수 있게 하려면 관계형 데이터베이스 시스템에서 실제 비즈니스의 기록의 사본을 저장해야 한다는 점이 곧 분명해졌다. 또한, 비즈니스 데이터를 특정 기간 동안 저장할 것을 요구하는 규정을 준수하려면 문서 시스템이 필요했다. 1980년 후반에는 종이 기록물의 이미지를 저장하기 위해 엔터프라이즈 문서 관리 시스템이라고[?23] 하는 새로운 소프트웨어 카테고리가 개발되었다. 이러한 시스템은 동일한 데이터를 관계형 테이블에 저장하는 데이터베이스와는 다르다. 21세기에는 엔터프라이즈 문서 관리를 엔터프라이즈 컨텐츠 관리로 부른다[24].

20세기에는 컴퓨터 안에서의 기록 관리의 기본 원칙이 컴퓨터가 작동하는 방식에 적합한 스토리지 모델을 도입하고 주어진 데이터 항목을 정확히 한 번만 저장하여 스토리지를 최소화하는 것이었다. 실제 종이 기록물의 정확한 사본이 필요한 경우에는 이러한 작업을 정확히 수행하기 위해 별도의 시스템을 구축했으며 이로 인해 동일한 데이터를 여러 번 저장하게 되었다. 기록의 저장 및 처리를 통제하는 규정이 계속 증가했다.

데이터 정규화 프로세스

이 섹션에서는 20세기의 두 번째 파트에서 데이터베이스가 도입된 환경과 이러한 시스템의 기본 목적을 설명한다.

이 섹션에서는 1970년 내내 도입된 정상 양식과 더불어 1970년에 처음 도입된 데이터 정규화 프로세스의 목적과 효과를 설명한다.

데이터 정규화는 스토리지가 비싸기 때문에 데이터베이스에 있는 실제 비즈니스 기록을 나타내는 테이블로 구성된 콜렉션을 계획하여 데이터가 중복되지 않도록 하기 위한 방법론이다. 데이터가 중복되지 않도록 하면 이상 항목을 업데이트하는 작업이 발생하지 않는다. 데이터 정규화는 광범위하게 매우 잘 기록되어 있다[?18]. 데이터 정규화는 실제 비즈니스 기록의 모든 특성과 기본 ID(키)를 나타내는 하나의 대용량 테이블로 시작하며 SQL과 같은 언어로 쿼리를 단순화하기 위해 계층 구조(반복 그룹)를 제거한다. 그 다음에는 결과 테이블에 있는 모든 정보 데이터와 기능적 종속 항목이 제거된다.

정규화를 달성하기 위해 필요한 모든 특성 있는 하나의 테이블을 기본 및 외부 키를 통해 링크되는 더 많은 테이블로 분리한다. 데이터 정규화의 결과로 하나의 비즈니스 기록이 수십 또는 수백 개의 테이블로 표현된다. 실제로는 존재하지 않는 다수의 인공 키와 연관 인덱스가 도입되지만, 이런 것들은 실제 비즈니스의 기록을 재구성하기 위해 필요하다. 다양한 버전의 비즈니스 기록(예: 주문)을 저장한 후, 이 주문을 개정하는 경우에는 테이블 집합체를 쿼리하고 유지보수하는 것과 관련된 모든 테이블을 버전화해야 한다. 스토리지를 보존하기 위한 또 다른 접근 방식은 전체 버전을 테이블 전체에 계단식으로 배치하여 프로그래머를 더욱 복잡하게 하는 대신에 델타만 저장하는 것이다.

1980년에는 스토리지 2MB의 비용이 미국에 있는 컴퓨터 프로그래머의 1주일 임금과 거의 비슷했다[?19][?22]. 2010년에는 스토리지 1GB의 비용이 몇 분 간의 컴퓨터 프로그래머 임금에도 미치지 못할 정도로 미미할 뿐이었으며 스토리지 가격은 계속해서 하락했다. 게다가 메모리가 풍부해졌으며 SSD(Solid State Disk)와 같은 새로운 종류의 스토리지가 등장하면서 I/O 조작 비용(지연)이 계속해서 감소하고 있다. 관계형 데이터베이스에서는 예외적으로 비정규화된 아티팩트를 저장하기 위해 일반적으로 스토리지 매체를 사용하며 이러한 예로는, 파일 서버, 웹 서버 및 컨텐츠 저장소, 애플리케이션 서버 등이 있다.

관계형 스토리지를 컴퓨터 시스템이 도입되기 전에 기록 관리를 위해 사용했고 언제나 "그대로" 저장되는 종이 기록물과 진흙판 및 엄대와 비교해 보자. 이러한 것을 다른 형식으로 쪼개거나 변환하여 저장하지 않는 이유는 여러 가지가 있다. 첫째, 일반적으로 저장 공간이 충분했으며 이 공간을 보존할 필요도 없었다. 둘째, 이러한 아티팩트를 변환하고 재구성하려면 비용이 많이 든다. 셋째, 이러한 기록을 원래의 형식으로 저장하면 스토리지에서 검색하여 사용하고 이해하기가 수월하다. 나중에 살펴보겠지만, 실제 디지털 비즈니스 기록을 비정규화된 형식으로 저장하는 이유는 오늘날에도 동일하다.

19세기와 20세기에는 종이 기록물의 사용이 급격히 증가했기 때문에 일부 라이브러리와 아카이브의 경우에는 저장 공간이 문제가 되었다. 그 결과 필요한 저장 공간을 원래 자료의 0.25% - 3% 범위로 줄일 수 있는 마이크로 필름과 마이크로 피시가 발명되었다[25]. 그러나 이는 정보를 개념적으로 다른 방식으로 표현하지 않고 단지 압축만 하는 형식에 불과하다. 마찬가지로 오늘날에도 비정규화된 비즈니스 기록이 사용하는 저장 공간을 줄이기 위해 디지털 압축을 적용할 수 있다.

높은 스토리지 비용으로 인해 촉발된 데이터 정규화는 기록을 여러 개의 부분(때로는 수백 개의 부분)으로 분해한 다음 필요에 따라 다시 재구성하는 과정을 통해 컴퓨터로 비즈니스 기록을 표현한다. 단일 기록의 여러 파트를 서로 링크하려면 인공 키와 연관 인덱스가 필요하다. 이점은 비즈니스 기록을 그대로 저장하는 이전의 기록 보관 시스템(진흙판, 엄대, 종이 등)과 차별된다. 비즈니스 기록을 정규화하면 이해하기가 훨씬 더 어려우며 이러한 기록을 분리하고 재구성하는 데 추가로 비용이 들어간다.

역정규화 프로세스

이 섹션에서는 역정규화가 일반적인 수단이 되는 상황을 설명한다. 첫 번째 사례는 데이터 웨어하우스의 데이터베이스 스키마이며 두 번째 사례는 Google BigTable[??47] 및 HBase[??49]와 같은 확장 가능한 새로운 데이터 저장소이다.

정규화의 고유한 단점은 두 가지이다. 첫째, 복잡한 비즈니스 기록으로 인해 정규화된 데이터베이스 스키마의 관계형 테이블 수가 증가하기 때문에 데이터 표현을 이해하기가 어려워진다. 결과적으로 쓰기 쿼리에 결합이 많이 필요해져서 쓰기 쿼리가 점점 더 복잡해진다[?46]. 둘째, 결합 수가 많이 증가하게 되어 데이터 검색 성능이 저하된다. 정규화된 테이블을 역정규화 하거나 비정규화된 디자인을 직접 사용하면 이런 문제점을 해결할 수 있다.

데이터 웨어하우스에서의 역정규화

1980년대와 1990년대에는 컴퓨팅 및 스토리지 디바이스의 용량이 증가한 반면에 비용은 하락했기 때문에 회사에서는 판매 보고서와 같은 대용량 히스토리 비즈니스 데이터를 축적하여 분석할 수 있었다. 직관적으로 표현된 데이터를 대상으로 복잡한 쿼리를 실행해야 하는 비즈니스 직원은 회사의 비즈니스 성능을 자세하게 파악하기 위해 이러한 웨어하우스를 사용했다. 그러나 "데이터 웨어하우스에서 정규화된 모델링을 사용하면 데이터를 직관적으로 빠르게 검색한다는 데이터 웨어하우징의 본래의 목적을 위배하게 된다"는 사실이 바로 발견되었다[??26].

결국, 역정규화된 스타 스키마가 데이터 웨어하우징을 위한 가장 인기 있는 데이터베이스 스키마가 되었다. 일반적으로 데이터 웨어하우스는 업데이트 트랜잭션을 수행하는 대신 새 데이터를 주기적으로 추가하므로 역정규화를 수행하면 스키마가 단순화될 뿐만 아니라 이상 항목 업데이트의 위험을 줄이면서 쿼리 성능을 개선할 수 있다.

스타 스키마는 "일일 판매량"과 같은 판매 기록이 포함된 하나 이상의 사실 테이블과 "상점", "제품", "날짜" 및 "고객"과 같은 여러 가지 차원 테이블로 구성된다. 각 차원과 사실 테이블 간에는 일대다 관계가 있다. 각 사실 테이블 행에는 여러 가지 수치, 즉 "수량"이나 "가격"과 같은 숫자 열뿐만 아니라 어떤 제품이 언제 어느 고객에게 어떤 상점에서 팔렸는지를 나타낼 모든 차원 테이블을 가리키는 외부 키가 포함되어 있다. 이는 비즈니스 관점에서 데이터를 직관적으로 바라본 것이며 관련된 비즈니스 차원에 따라 판매량과 같은 사실을 용이하게 분석할 수 있게 한다.

차원 테이블은 고도로 역정규화된다. 예를 들면, "product" 테이블에는 "brand" 및 "category"와 같은 열이 있으며 이 테이블에서는 여러 가지 제품에 동일한 문자열 값을 중복해서 표시할 수 있다. 정규화는 INTEGER 값을 브랜드 및 카테고리 키로 사용하고 각 브랜드 및 카테고리의 이름이 한 번만 존재하는 별도의 테이블을 사용한다. 이렇게 차원 테이블을 정규화하면 이해하기가 어려워지고 추가적인 결합이 필요한 눈송이 스키마가 발생하므로 이렇게 차원 테이블을 정규화하는 것을 피하게 된다.

데이터 웨어하우징에서 스타 스키마가 성공하면서 역정규화에는 OLAP 및 의사결정 지원 데이터베이스에 대한 이점이 있다는 사실을 일반적으로 이해할 수 있게 되었다. 예를 들면, Oracle의 데이터 웨어하우스 및 OLAP 데이터베이스 권장사항에는 "대규모의 역정규화" 및 "광범위한 중복성"이 포함되어 있다[27]. Oracle 11g의 테스트에서 다차원 쿼리는 정규화된 데이터베이스 스키마보다 역정규화된 데이터베이스 스키마에서 10 - 1000배 더 빠르게 실행된다는 사실이 확인되었다[?28]. 기타 연구 결과에서는 역정규화의 성능상 이점을 관계형 대수 및 쿼리 트리를 사용하여 이론적으로 설명했다[29].

의사결정 지원 데이터베이스에서 역정규화가 성공했음에도 불구하고 정규화는 일반적으로 강화된 OLTP 애플리케이션을 업데이트하는 데 적합했다. 그러나 21세기에 들어와서는 모든 데이터베이스 행의 전체 히스토리를 유지해야 하는 애플리케이션이 점점 더 증가하면서 OLTP 애플리케이션에 맞게 데이터베이스 스키마를 정규화해야 할 필요성이 변하고 있다. 따라서 대부분의 애플리케이션은 새 버전의 행만 삽입하지 기존 행을 업데이트하지 않으며[45], 이렇게 하면 역정규화된 스키마에서 이상 항목을 업데이트하는 위험과 정규화 필요성을 줄일 수 있다.

Google BigTable, HBase 및 기타 시스템에서의 역정규화

Google의 BigTable은 이산된 분산 다차원 정렬 맵으로 구현된 무공유 구조의 병렬 데이터베이스 시스템이다[47]. 이 시스템은 대용량 데이터 볼륨(페타 바이트)으로 확장할 수 있고 수백 또는 수천 개 이상의 컴퓨터에 분산할 수 있도록 설계되었다. 각 맵 항목에서 BigTable은 행 키, 열 키 및 시간소인으로 구성된 트리풀을 값에 맵핑한다. 또한, 열 키는 액세스 제어 및 압축의 기본 단위를 구성하는 열 패밀리로 그룹화된다.

BigTable의 데이터베이스 및 애플리케이션의 기본 설계 원칙 중 하나는 역정규화와 데이터 중복이며[?48], 이점은 기존의 관계형 데이터베이스 이론과 완전히 다르다. 그 목적은 데이터베이스를 최적화하여 읽기 액세스를 효과적이고 확장 가능하게 하는 데 있다. 역정규화는 하나의 읽기 연산으로 논리적 비즈니스 기록에 속하는 모든 필드를 검색할 경우에 사용된다.

값이 동일한 여러 개의 사본을 프로그램 방식으로 업데이트해야 할 수 있기 때문에 BigTable에서 역정규화를 수행하면 업데이트가 더욱 복잡해지고 효율성도 떨어지지만, 이러한 대가는 읽기/업데이트 비율이 높은 애플리케이션의 확장성을 강화하기 위해 허용된다. 또한, BigTable에서는 버전화를 용이하게 하기 위해 시간소인 필드를 사용하며, 이는 다수의 고객 주소 사본이나 제품 설명 사본이 특정 시점에서의 상황을 반영한다는 점을 의미한다.

논리적 일대다 관계가 있는 고객 및 주문을 저장하는 데이터베이스를 생각해 보자. 관계형 데이터베이스를 정규화하는 데는 고객 테이블 하나와 주문 테이블 하나 이렇게 최소 2개의 테이블이 필요하지만, 일반적으로 BigTable 설계에서는 고객 정보를 각 주문과 함께 반복한다. 이는 각각의 특정 주문에 대한 고객 정보의 상태를 나타낸다. 예를 들면, 고객은 주문할 때마다 동일한 주소를 사용할 수도 있고 그렇지 않을 수도 있다. 이런 점에서 역정규화된 표현은 실제 구매 주문 양식, 즉 원래의 비즈니스 기록과 유사하다.

BigTable과 비슷한 기타 구현으로는 HBase와 Cassandra가 있으며, 이러한 것도 역정규화된 데이터베이스 설계 방식을 따른다[49]. 마찬가지로 다른 연구 결과에서도 역정규화가 확장 가능한 웹 애플리케이션을 빌드하는 데 적합한 기술이라는 점을 확인할 수 있다[50].

데이터 웨어하우스는 비즈니스 사용자가 액세스하므로 저장된 데이터는 비즈니스 기록의 원래 구조와 직관적으로 비슷해야 하며 이렇게 하려면 역정규화를 사용해야 한다. 또한, 역정규화는 비즈니스 기록을 평가하는 데 필요한 관계형 결합의 수를 줄여서 성능을 개선한다. 마찬가지로 BigTable 및 HBase와 같은 새로운 데이터 저장소에서는 단순하고 확장 가능한 데이터 액세스를 제공하기 위해 역정규화를 사용한다.

웹의 영향

1990년대 중반에 시작된 비즈니스 기록의 디지털화는 웹의 상업적인 성공과 맞물려 있었다. 이번 섹션에서는 21세기 초에 비즈니스 기록을 표현하는 방법에 중요한 영향을 미친 웹의 주요 기술을 살펴본다.

1989년에는 많은 과학, 학술, 정부 및 상업적 기관에서 인터넷 인프라에 액세스해야 했기 때문에 인터넷을 기반으로 하는 프로젝트가 많이 개발되고 있었다. 이러한 프로젝트 중에는 월드 와이드 웹을[??34] 창조하는 데 기초가 된 HTML(Hypertext Markup Language) [??31], HTTP(Hypertext Transfer Protocol) [??32], URL(Universal Resource Locators)의[??33] 발명도 포함된다. HTTP에는 범용 주소 지정 스킴인 URL을 통해 HTML 문서에 주소를 지정하여 인터넷에 있는 HTML 문서를 검색하고 수정하기 위한 프로토콜이 정의되어 있다. 문서를 액세스하고 탐색하기 위해 범용 뷰어(브라우저[??35])가 많이 빌드되었으며 21세기에는 여러 가지 디바이스에서 이러한 뷰어를 사용했다.

과학 기관은 과학 문서를 공유하기 위해 불완전한 웹을 사용한 최초의 사용자였다. 1995년 경에는 상업적 커뮤니티에서 웹을 사용했다. 많은 이용자들이 자신의 직장과 집에서 인터넷에 액세스하기 시작하면서 기존의 상업용 시스템에서 웹을 사용할 수 있게 하고 관계형 데이터베이스에 있는 데이터에 액세스할 수 있는 기능을 제공하는 웹의 중요성을 부각시키려는 경쟁이 생겼으며 그 결과 이용자가 패키지를 추적하거나 서비스와 상품을 주문할 수 있었다. 과거에는 이러한 활동을 직접 전화나 편지를 통해 수행했다. 웹으로 관계형 데이터베이스에 액세스하고 컨텐츠를 유비쿼터스 HTML로 변환하기 위한 인프라가 개발되었으며 사용자 인터페이스에 HTML을 사용한 애플리케이션이 개발되었다[36].

HTML은 대단한 성공을 거두게 되었다. 이점은 1997년까지는 버전이 4.0이었던 SGML(Standard Generalized Markup Language)[??38] 문서 정의에 기술되어 있다. SGML은 1960년대의 IBM GML(Generalized Markup Language)에서 유래된 것으로 마크업 정의를 위한 ISO 표준이다. XML(eXtensible Markup Language)은 [??37] SGML이 단순화된 것으로, HTML을 필요로 하는 완전한 SGML 구문 분석기보다 구문 분석기 구현이 용이하도록 1998년에 도입되었다. 모든 시작 태그에는 종료 태그가 있어야 한다는 규정은 SGML에는 없는 것으로 XML에서 단순화된 사례라고 할 수 있다.

XML이 도입되면서 HTML 이외에도 임의의 데이터 구조를 표현할 수 있는 어휘가 많이 생겨났다. 1990년대 말에는 실제 비즈니스 기록을 디지털 형식으로 작성했기 때문에, 종이 양식이나 석판이 비정규화된 비즈니스 기록인 것과 마찬가지로 웹으로 인해 입출력 매체로 부각된 XML은 비정규화된 형식의 비즈니스 기록을 표현하기 위한 당연한 선택이었다. SGML 프로세서를 이용하여 무료 오픈 소스 XML 소프트웨어를 개발하거나 잘 구성된 XML을 구문 분석할 수 있는 새로운 프로세서가 개발되면서 사용자 정의 구문 분석기에 대한 필요성이 사라졌다.

XML을 지원하기 위해 더 많은 스펙이 추가되었으며, 예를 들면, XML 스키마는 기관과 협회에서 특정 비즈니스 기록의 허용 가능한 컨텐츠를 구성하는 것을 정확하게 지정할 수 있게 한다. 구문 분석기의 유효성을 분석하는 기능이 광범위하게 사용 가능해졌다. 네임스페이스 덕택에 해당 데이터 정의를 다른 그룹에서 소유하고 있는 데이터를 비즈니스 기록에 포함할 수 있게 되었다. 네임스페이스를 이용하면 기관에서 비즈니스 기록 구조를 재사용하거나 분할 또는 확장할 수 있다. 피지와 종이에서 서명과 봉인을 사용한 것과 마찬가지로 방법으로 XML에 디지털 서명을 적용하여 XML이 위조되지 않았다는 것을 보장할 수 있다. WSDL, SOAP, RSS 및 Atom을 포함하여 XML 기록을 전달하는 방법이 기술된 스펙이 도입되었다. 이러한 스펙은 피드 기술 및 SOA(Service-Oriented Architecture)와 같은, 비즈니스 기록의 교환과 관련된 범용 프레임워크를 빌드할 수 있게 한다.

해당 산업의 XML 비즈니스 기록 표준을 정의하는 협회의 수가 증가했다. 기업에서는 자체 XML 비즈니스 기록을 정의하는 대신에 표준화된 XML 구조를 사용하기 시작했다. 이러한 사례로는 FpML(Financial Products Markup Language ) [??52], FIXML(Financial Information eXchange Protocol)[??54], EML(Election Markup Language)[??55], HL7(Health Level 7)[??56], HR-XML(Human Resources XML)[??57], OTA(Open Travel Alliance)[??58] 및 OAGIS(Open Applications Group Integration Specification)[??53]가 있다. IS20022 범용 금융 산업 메시지 스킴과[?59] 같은 형식이 은행에서 사용되었고 UBL(Universal Business Language)이[??60] 세계 곳곳에서 의무화되고 규정을 적용 받게 되었다. 컴퓨터가 없던 시기에는 진흙판과 종이를 사용했기 때문에 처음에는 다양한 산업에서 비즈니스 기록을 직접 저장하고 조작할 수 있게 되었다. 그러나 XML 비즈니스 기록을 정규화하여 저장하는 사례가 계속 되었다.

21세기 초에는 많은 비즈니스 기록이 작성되어 XML로 표현되었다. XML 비즈니스 기록은 기관 간에 그리고 기관 내에서 파일 전송, HTTP, 웹 2.0 및 웹 서비스를 통해 교환되었다. 이러한 비즈니스 기록은 둘 이상의 당사자 간의 계약이나 비즈니스 오브젝트를 나타낸다. 일반적으로는 XML을 처리하는 것이 비효율적이라고 생각되었다. 그래서 계속해서 많은 아키텍트가 비즈니스 기록을 정규화된 관계형 테이블로 변환하는 시스템을 설계한 후, 1995년에 그랬던 것처럼 다시 HTML과 관계형 데이터를 상호 변환하고 1980년에 했던 것처럼 스캐너와 오퍼레이터를 활용하여 종이 기록과 관계형 데이터를 상호 변환한다.

요약

20세기 중반에 상업용 컴퓨팅이 도래할 때까지는 원래 비즈니스 기록을 작성한 형식과 동일한 형식으로 비즈니스 기록을 저장하고 처리했다. 석판, 엄대 및 종이 양식을 예로 들 수 있다. 컴퓨팅 시스템이 도입되면서 비즈니스 기록을 체계화하기 위해 데이터 정규화가 고안되었으며 그래서 각 데이터 항목을 정확히 한 번만 저장하여 스토리지를 보존하고 이상 항목의 업데이트를 피하게 되었다. 정규화는 그 당시의 설득력 있는 이유 때문에 1970년대에 개발되었다. 디스크 공간이 부족했고 비쌌으며, 비즈니스 기록은 지금처럼 복잡하지 않았기 때문에 각 정보의 최신 버전만 저장했다. 그래서 컴퓨터로 비즈니스 기록을 정규화된 표현으로 변환하려는 노력이 일반적으로 받아들여졌다.

1990년대 초에 데이터 웨어하우스와 비즈니스 인텔리전스가 출현하면서 정규화의 단점이 주목을 받게 되었다. 정규화된 데이터 스키마는 비즈니스 기록을 자연스럽게 표현한 것이 아니었기 때문에 비즈니스 사용자가 이해하기 어려웠고 분석적 비즈니스 쿼리를 표현하고 처리하기가 비효율적이었다. 결국 이러한 단점을 어느 정도 보완하기 위해 역정규화를 도입하게 되었다.

그리고 21세기에 들어와서도 IT 업계는 계속 변하고 있다. 디지털 스토리지의 MB당 비용이 엄청나게 하락했다. 저장 밀도와 압축 기능이 발전하면서 더 이상 정규화를 통해 공간을 절약할 필요가 없게 되었다. 마찬가지로 오늘날에는 감사 및 준수 규정에서 많은 애플리케이션이 데이터 오브젝트의 히스토리를 유지하도록 규정하고 있다. 결국, 기존 데이터를 업데이트하기 보다는 일반적으로 데이터 오브젝트의 새 버전과 변경되지 않는 버전을 삽입하게 되었으며 이로 인해 이상 항목을 업데이트하는 위험이 줄어들게 되었다. 따라서 데이터 정규화에 대한 필요성이 더 이상 1970년대에 그랬던 것처럼 보편적으로 적용되지는 않는다.

또한, 웹, 웹 서비스, 웹 2.0 기술이 성공하면서 비즈니스 기록이 디지털 형식(대부분은 XML로 작성됨)으로 작성되게 되었다. 클라이언트 측 소프트웨어에 XML과 파생 기술이 도입되었지만, 정규화가 필요한 데이터 변환으로 인해 데이터베이스를 포함하고 있는 서버측 소프트웨어를 설계하고 빌드 및 전개하려면 계속해서 사용자 정의가 많이 필요하다. 30년 동안 데이?쳤고 지금도 계속해서 시스템 설계의 핵심 부분으로 정규화를 가르치기 때문이다. 그러나 현재는 비즈니스 기록이 디지털 형식으로 되어 있을 뿐만 아니라 더 복잡하고 진화하고 있기 때문에 정규화를 사용하는 것을 조심스럽게 재검토해야 한다.

이 시리즈의 두 번째 파트에서는 XML과 기타 데이터 표현을 살펴보고 이러한 기술이 정규화의 일반적인 문제점을 언제 어떻게 완화할 수 있는지에 대해 설명할 것이다.

출처 : 한국IBM

제공 : DB포탈사이트 DBguide.net

서적 "SQL 기초2" 주에서 발최

가을의 곰을... — Sat, 07 Nov 2009 11:53:51 +0900

서적 "SQL 기초2" 주에서 발최

CHAPTER 3. 주위의 데이터를 테이블로 만든다

3-1. 테이블 설계란 무엇인가?

KEYWORD

* 데이터 정규화

* 비정규화 데이터

* 제1정규화

* 제2정규화

* 제3정규화

테이블 설계란 우리들 주변에 있는 데이터를 어떠한 형식으로 데이터베이스로 보관하면 좋을까를 생각하는 것입니다. 이 설계가 잘 되고 안 됨에 따라, 나중에 데이터의 수정이 간단하게 될지, 복잡하게 될지가 결정됩니다. ‘이렇게 설계를 하면 나중에 수정할 때 이러한 장점이나 단점이 있다’라는 점을 잘 생각하면서 배워 나가도록 합시다.

테이블 설계를 할 때에는 정규화라는 개념을 알아두어야 합니다. 어렵게 생각할 필요는 없습니다. 우리들 자신이 가지고 있는 데이터를 데이터베이스로 원활하게 운용할 수 있도록 잘게 부수는 것이라고 생각하면 됩니다. 여기에서는 신문을 예로 들어 봅니다. 기사를 쓰는 쪽(기자)를 인간으로, 기사를 읽는 쪽(독자)를 데이터베이스로 바꾸어 생각해 봅니다.

신문의 1페이지 전면이 모두 한자로 쓰여 있다고 상상해 봅니다. 전달하고자 하는 것들을 모두 적었다 하더라도, ‘독자로서는 이해하기 어려운 것’이 자명합니다. 좀 더 알기 쉽게 하려면 한글을 섞어서 쓰도록 합니다. 또 더욱 효과적인 방법으로는 문장 부호를 추가하거나 지면을 여러 틀로 나누어서 각각의 틀 안에 기사를 쓰면 좋을 것입니다. 단락을 나누어서 쓰는 것도 이해하기 쉬워질 것입니다. 이렇게 하면 지면 전체를 한자로 쓴 것에 비하여 훨씬 알기쉬운 신문이 될 것입니다.

이와 같이 인간과 데이터베이스 사이에서 진행해 나가는 것을 정규화라고 부릅니다. 앞의 예에서는 ‘전면을 한자로 쓴다’ → ‘한글을 섞어 쓴다’ → ‘문장 부호를 추가한다’ → ‘지면을 분할한다’ → ‘단락을 나눈다’라는 형태로 한자 데이터를 편집해 나감으로써 좀 더 이해하기 쉬운 데이터 구조로 만드는 방법을 설명하였습니다. 이 내용을 인간이 취급하는 데이터와 데이터베이스의 관계에도 적용시켜 봅니다. 인간이 취급하는 데이터를 ‘비정규화 데이터’라고 부릅니다. 여기에서부터 진행하는 테이블 설계의 절차는 다음과 같습니다.

비정규화 데이터 → 제1정규화 → 제2정규화 → 제3정규화

실제로는 제4정규화, 제5정규화 등도 있지만 일반적으로는 제3정규화까지 진행합니다. 신문의 예에서는, ‘한글을 섞어서 쓰고 문장 부호가 있으면 이해하기 쉽다’라는 것이 제3정규화입니다. 이처럼 사람들이 이해하기 쉬운 데이터 구조를 RDBMS가 이해하기 쉬운(관리하기 쉬운) 구조로 바꾸어 나가기 위해서 정규화가 필요합니다. 각각의 정규형에 관해서 살펴보도록 합니다.

3-2 테이블 작성 방법과 비정규형

KEYWORD

* 분석

* 비정규형

다음의 예로 테이블을 작성해 봅니다. 여기에서는 학교 성적 관리에 관해서 생각해 보기로 합니다. 다음과 같은 시험 성적표가 있습니다.

시험 성적표

이름 : 최문석

학년 : 2

반 : A

교실 : 본관2층

== 시험 결과 ==

과목 점수 교사

국어 80 이경욱

수학 70 최용호

물리 92 배정훈

사회 48 조범식

과목수 : 4

평균점수 : 72.5

이처럼 개인 정보를 데이터베이스를 사용하여 관리한다고 가정합니다.

전교생의 시험 성적표를 각 교사가 기록하고 이것을 학교 컴퓨터에 입력합니다. 물론 이 성적표를 바로 테이블로 만들 수도 있으나, 데이터베이스에는 바람직한 방법이 아닙니다. 어떠한 형식이 적합할지를 생각해 봅니다. 테이블을 설계하기 전에 시트를 잘 관찰하여 테이블 구조를 확정해야 하는데 이 작업을 분석이라고 부릅니다. 데이터의 분석 방법은 여러 가지가 있겠지만 여기에서는 이에 관해서는 언급을 하지 않습니다. 그러나 어떠한 분석 방법을 사용하든지, 테이블 설계의 첫 걸음은 어떠한 열이 있으면 이것에 데이터를 관리할 수 있을까를 고려하는 것입니다. 위의 표를 보고 어떠한 열이 있으면 좋을까를 생각해 봅니다. 표를 보면 다음과 같이 데이터를 분석할 수 있습니다.

시험 성적표 → 테이블 이름

최문석 → 이름

2 → 학년

A → 학급

본관2층 → 교실

== 시험 결과 == → 테이블 구분

국어 → 과목

80 → 점수

이경욱 → 교사

4 → 과목수

72.5 → 평균점수

이 정보들을 자세히 보길 바랍니다. 동시에 테이블을 머리 속에 그려 봅니다. 어떠한 열이 필요할까요? 이것을 테이블로 만든다고 생각할 때 다음과 같은 열이 필요합니다.

1. 테이블 이름

2. 이름

3. 학급

4. 교실

5. 테이블 구분

6. 과목

7. 점수

8. 교사

9. 과목수

10. 평균점수

이들 열을 사용하여, 바로 CREATE TABLE문을 사용해도 되지만, 여기에서 다시 한번 생각해 봅니다. 위에 들고 있는 열 후보 중에서 필요 없는 열은 없을까요?

먼저 눈에 띄는 것은 ‘1. 테이블 이름’과 ‘5. 테이블 구분’입니다. 이 항목은 인쇄상 보기 편하기 하기 위한 것이므로 데이터로는 아무 의미가 없습니다.

그리고 잘 생각해 보면, 필요 없는 열이 또 있습니다. 다른 값에 의해 계산할 수 있는 항목입니다. SELECT문이 계산이 가능하다는 것은 이미 아는 사실입니다. (예: SELECT 1+2 FROM DUAL;) 그렇기 때문에 계산에 의해 산출할 수 있는 것은 굳이 데이터로 입력할 필요가 없습니다. 오히려 같은 데이터를 여러 개 갖게 되므로 데이터가 중복됩니다. 예를 들어, 과목수는 과목을 세어보면 알 수 있고 평균 점수는 각 점수를 더해서 과목수로 나누면 됩니다. 이처럼 계산할 수 있는 데이터는 필요없는 데이터입니다. RDBMS 설계에서 중요한 것은 중복 데이터를 가지지 않고 데이터의 모순 없이 쉽게 변경하는 것입니다. 따라서, 다른 데이터에서 계산하여 얻을 수 있는 값은 테이블 설계 단계에서 제외합니다. 여기에서는 ‘9.과목수’와 ‘10.평균점수’가 해당됩니다. 이러한 관점에서 필요한 열을 다시 추려 보면 다음과 같습니다.

1. 이름

2. 학급

3. 교실

4. 과목

5. 점수

6. 교사

열이 반 정도로 줄었습니다. 그러나 결코 정보가 빠져 있지는 않습니다. 이들 데이터 정도만 알면 본래의 표 데이터는 복원될 수 있습니다. 테이블 설계에서 중요한 것은 반드시 테이블에 보관해야 하는 데이터와 다른 데이터에서 도출 할 수 있는 데이터를 가려내는 것입니다. 표에 씌여 있는 데이터는 하나의 표현에 지나지 않으므로, 그대로 모두 테이블로 가져오면 안 된다는 점을 주의하길 바랍니다.

그러면 이제 가려낸 열을 사용하여 다음과 같은 테이블을 작성해 봅니다.

이름	학급	교실	과목	점수	교사
최문석	A	본관2층	국어	80	이경욱
			수학	70	최용호
			물리	92	배정훈
			사회	48	조범식

한 명의 학생에 대한 정보는 이 정도입니다. 다른 학생의 정보도 입력해 봅니다.

? 테이블1: 성적(비정규형)

이름	학급	교실	과목	점수	교사
최문석	A	본관2층	국어	80	이경욱
			수학	70	최용호
			물리	92	배정훈
			사회	48	조범식
이원석	B	별관3층	국어	80	이경욱
			수학	55	최용호
			가정	96	도희정
문장원	B	본관3층	예술	72	이수정
			사회	87	조범식

이렇게 작성된 테이블을 비정규형 테이블이라고 부릅니다. 비정규형 테이블은 인간에게는 보기 편하지만 효율성 있는 데이터 관리를 위해서는 적합하지 않습니다. 예를 들어 2번째 행의 데이터는 어느 학생의 성적인가를 보여주지 않습니다. 그리고 앞서 테이블에는 키 열이 존재한다고 설명한 것을 기억할 것입니다. 키 열에는 반드시 값이 있어야 합니다. 앞의 테이블은 학생의 성적을 보관하는 테이블이므로 어느 한 행을 특정 짓기 위해서는 학생 이름이 필요합니다. 그러나 학생 이름 열에 값이 들어가 있지 않는 행이 여러 개 존재하고 있습니다. 이런 이유로 이 테이블을 이대로는 RDBMS 안의 테이블에 보관 할 수 없습니다. 여기서 비정규형 테이블을 제1정규형으로 변환해 봅니다.

3-3 제1정규형

KEYWORD

* 제1정규형

제1정규형으로 변환하는 작업은 테이블 안에서 반복되는 항목을 배재하는 것입니다. 따라서 테이블 안에 반복되는 항목이 없는 테이블을 제1정규형 테이블이라고 합니다.

그러면 비정규형 테이블을 제1정규형 테이블로 변환해 봅니다. ‘테이블1’에서 반복하는 항목은 무엇인가? ‘테이블1’의 2행, 3행과 4행에는 아무것도 입력되어 있지 않지만 실제로는 1행의 데이터와 같은 것이 들어 있다고 할 수 있습니다. 즉, ‘이름’열에서 ‘교실’열까지는 반복이 존재하는 열입니다.

테이블1은 아래와 같이 표현되기도 합니다.

이름	학급	교실	과목	점수	교사
최문석	A	본관2층	국어	80	이경욱
최문석	A	본관2층	수학	70	최용호
최문석	A	본관2층	물리	92	배정훈
최문석	A	본관2층	사회	48	조범식
이원석	B	별관3층	국어	80	이경욱
이원석	B	별관3층	수학	55	최용호
이원석	B	별관3층	가정	96	도희정
문장원	B	본관3층	예술	72	이수정
문장원	B	본관3층	사회	87	조범식

그러나 너무 복잡해 보기가 어려우므로 일반적으로 반복되는 항목을 생략하고 ‘테이블1’과 같이 만듭니다.

이러한 이유로 ‘테이블1’에서 반복되는 항목은 ‘이름’열에서 ‘교실’열까지라는 것을 알 수 있습니다. 지금부터 ‘테이블1’을 제1정규형으로 분해해 나가겠습니다. 이때에 주의해야 할 것이 있습니다. 그것은 분해한 2개의 테이블에서 원래의 테이블을 반드시 복원할 수 있도록 분해해야 한다는 것입니다. 기계를 분해한 후 다시 조립을 못하면 큰일나듯이 테이블도 마찬가지로 분해한 테이블을 반드시 원래의 테이블로 복원할 수 있어야 합니다.

그러면 어떻게 해야 할까요? 테이블을 분해할 때는 약간의 고려를 해 볼 필요가 있습니다. 실제로 고려해야 하는 것은 어느 열의 값이 있으면, 어느 행을 구분 지을 수 있을까라는 점입니다. 테이블1에서는 ‘이름’열과 ‘과목’열이 해당됩니다. 이 2개의 열이 있으면 특정 행을 식별 할 수 있습니다.

다음과 같이 비정규형 테이블을 2개로 나우어 봅니다.

학생(이름, 학급, 교실)

시험(이름, 과목, 점수, 교사)

여기서 밑줄이 그어져 있는 열은 키 열로 그 항목이 결정되면 행이 구분지어진다는 것을 나타냅니다. 방금 ‘테이블1’을 2개의 테이블로 분할하였습니다. 그럼, 상세하게 보기로 합니다.

먼저, ‘테이블2’입니다. ‘이름’이 키로 되어 있어 이름이 구분됨에 따라 특정한 1행을 식별할 수 있습니다.

? 테이블2: 학생

이름	학급	교실
최문석	A	본관2층
이원석	B	별관3층
문장원	B	별관3층

또 하나는 ‘테이블3’입니다. 밑줄로 나타낸 것처럼 이 테이블은 ‘이름’열과 ‘과목’열의 값을 한 조로 하여 하나의 행을 식별할 수 있습니다.

다시 말해, ‘테이블1’을 단지 2개로 나누는 것이 아니라 분해한 것에 키 열을 추가한 후 다시 하나의 테이블로 만드는 것입니다.

? 테이블3: 시험

이름	과목	점수	교사
최문석	국어	80	이경욱
최문석	수학	70	최용호
최문석	물리	92	배정훈
최문석	사회	48	조범식
이원석	국어	80	이경욱
이원석	수학	55	최용호
이원석	가정	96	도희정
문장원	예술	72	이수정
문장원	사회	87	조범식

테이블2와 테이블3을 주의해서 보시길 바랍니다. 양쪽 테이블에 포함되어 있는 열은 ‘이름’열입니다. 이 열이 양쪽에 있기 때문에 ‘테이블2’와 ‘테이블3’에서 ‘테이블1’이 복원될 수 있습니다(이것은 RDBMS의 기본!).

이렇게 제1정규형으로 변환되었습니다.

3-4 제2정규형

KEYWORD

* 제2정규형

제2정규형이란 연결 키가 있는 테이블을 찾아내어 연결 키의 일부 열에만 존재하고 있는 열을 도출하는 것을 말합니다. 연결 키가 없는(하나의 열만으로 기본 키를 만들고 있는) 테이블은 대상에서 제외됩니다.

앞의 ‘테이블2’는 기본 키가 하나인 ‘이름’열만으로 구성되어 있으므로 이미 제2정규형의 조건을 만족하고 있습니다. 그렇기 때문에 ‘테이블2’를 제2정규형으로 바꿔줄 필요가 없습니다.

연결 키의 일부 열에만 존재하고 있는 열이란 어떤 것일까요? 예를 들어, 다음의 ‘소프트 아이스크림’테이블을 살펴봅니다.

? 소프트 아이스크림

용기	맛	주원료	가격
컵	딸기맛	딸기	2,000
콘	딸기맛	딸기	2,500
컵	메론맛	메론	4,000
콘	메론맛	메론	4,500
컵	초콜릿맛	초콜릿	1,000
콘	초콜릿맛	초콜릿	1,500
컵	바나나맛	바나나	1,000
콘	바나나맛	바나나	1,500

‘소프트 아이스크림’ 테이블은 연결 키를 가지고 있어서 용기와 맛이 결정되면 특정행이 도출되는 테이블입니다. 이 테이블을 잘 보면 ‘주원료’열의 값(딸기, 메론, 초콜릿, 바나나)은‘맛’ 열의 값(딸기맛, 메론맛, 초콜릿맛, 바나나맛)에는 존재하고, ‘용기’ 열 (컵, 콘)에는 존재하지 않습니다.

다시 말해, 연결 키를 구성하는 열(맛, 용기)의 일부인 열(맛)에만 존재하는 열(주원료)을 도출해내는 작업이 제2정규화입니다.

‘가격’열은 연결 키를 구성하는 열(맛,용기) 모두에 존재하므로 도출하려는 열의 대상이 되지 않습니다. 그렇기 때문에 제2정규화로 도출하려는 열은 ‘소프트 아이스크림’ 테이블 열에서 ‘주원료’열이 됩니다.

그러면 ‘테이블3’을 살펴봅니다. ‘테이블3’은 연결 키(‘이름’ 열, ‘과목’ 열)를 가지고 있는 테이블이므로 제2정규형으로 변형할 필요가 있는지를 음미할 대상이 됩니다.

‘점수’ 열은 무엇에 의해 구분되는가를 생각해 보면, ‘이름’열과 ‘과목’열이라는 것을 알 수 있습니다. 즉, ‘점수’열은 ‘학생’열과 ‘과목’열의 양쪽(연결 키의 전체 열)에 종속되어 있으므로 어떠한 작업도 할 필요가 없습니다.

다음로 ‘교사’열을 생각해 봅니다. 교사가 어디에 종속되어 있는지 생각해 볼 때 과목이 결정되면 대응하는 교사가 자동으로 결정된다는 것을 알 수 있습니다. 학생이 누구인지에는 관계없습니다. 곧 ‘교사’열의 값은 ‘과목’열의 값(연결 키의 일부 열)에만 종속되어 있으므로 분해할 필요가 있다는 것을 알 수 있습니다. 다음고 같이 분해해 봅니다.

? 테이블4: 시험2

이름	과목	점수
최문석	국어	80
최문석	수학	70
최문석	물리	92
최문석	사회	48
이원석	국어	80
이원석	수학	55
이원석	가정	96
문장원	예술	72
문장원	사회	87

‘점수’열은 그대로 남김니다.

? 테이블5: 교사

과목	교사
국어	이경욱
수학	최용호
물리	배정훈
사회	조범식
가정	도희정
예술	이수정

이와 같이, 교사는 과목이 결정되면 자동으로 구분됩니다. ‘테이블4’와 ‘테이블5’를 잘 살펴봅니다. ‘과목’열이 양쪽 테이블에 들어 있으므로 ‘테이블4’와 ‘테이블5’에서 ‘테이블3’을 복원할 수 있습니다.

3-5 제3정규형

KEYWORD

* 제3정규형

제3정규형은 기본 키 항목 이외의 열에 종속되어 있는 열을 도출하는 것입니다. 즉, 기본 키 열 이외의 열에 종속되어 있는 열이 없는 테이블입니다.

‘테이블4’의 ‘점수’열을 봅니다. ‘점수’열은 기본 키 열(‘이름’열, ‘과목’열)에 종속(기본 키 열이 결정되면 자동으로 결정됩니다)되므로 이미 제3정규형이 되어 있습니다. 다음으로 ‘테이블5’를 봅니다. 기본 키 이외의 열은 ‘교사’열입니다. 그러나 ‘교사’열은 기본 키 열(과목)에 종속되므로 ‘테이블5’도 이미 제3정규형이 되어 있습니다.

앞의 ‘테이블2’를 다시 살펴봅시다.

? 테이블2: 학생

이름	학급	교실
최문석	A	본관2층
이원석	B	별관3층
문장원	B	별관3층

‘학급’열을 보면, ‘학급’열의 값은 기본 키 열(이름)이 결정됩니다. 그럼 ‘교실’ 열은 어떤가요? ‘교실’열은 학급이 결정되면 자동으로 결정됩니다. 즉, 기본 키 이외의 열에 종속되어 있다는 것을 알 수 있습니다. ‘테이블2’를 제3정규형으로 분해해 보면 아래와 같이 됩니다.

? 테이블6: 학생

이름	학급
최문석	A
이원석	B
문장원	B

? 테이블7: 위치

학급	교실
A	본관2층
B	별관3층

이렇게 해서, 기본 키가 아닌 모든 열은 기본 키에만 종속된 형이 되어 제3정규형이 되었습니다. ‘테이블6’, ‘테이블7’은 양쪽에 ‘학급’열이 들어 있으므로 이 2개의 테이블에서 ‘테이블2’를 복원할 수 있습니다.

‘테이블6’, ‘테이블7’은 다음과 같이 될 수도 있습니다.

이름	교실
최문석	본관2층
이원석	별관3층
문장원	별관3층

교실	학급
본관2층	A
별관3층	B

상호 어느 쪽에도 속해있다고 말할 수 없을 때는 어느 것이든 분해할 수 있습니다.

그럼 지금까지의 분해를 정리해 봅시다.

비정규형	제1정규형	제2정규형	제3정규형
‘성적’테이블	‘학생’테이블		‘학급’테이블
			‘위치’테이블
	‘시험’테이블	‘시험2’테이블
		‘교사’테이블

처음으로 비정규형 테이블을 2개로 분해해 보았습니다. 위의 그림은 ‘학생’테이블의 분해와 동시에 제2정규형 조건을 충족하는 테이블이 되었다는 것을 나타냅니다. ‘시험’테이블은 제1정규형이므로, 제2정규형 분해를 진행하여 ‘시험2’테이블과 ‘교사’테이블로 분해했다는 것을 보여줍니다. ‘시험2’테이블과 ‘교사’테이블은 제2정규형으로 분해됨과 동시에 제3정규형의 조건을 충족하는 테이블이 되었다는 것을 알 수 있습니다.

다음은 4개의 테이블 정의를 정리해 본 것입니다.

시험2(이름, 과목, 점수)

교사(과목, 교사)

학급(이름, 학급)

위치(학급, 교실)

이들의 테이블 관계를 도식으로 표현하면, 아래와 같습니다.

여기에서 CREATE TABLE문을 작성하면 다음과 같습니다.

CREATE TABLE 시험2

(

이름 VARCHAR2(20) CONSTRAINT PK_NAME PRIMARY KEY,

과목 VARCHAR2(20) CONSTRAINT FK_CLASS REFERENCES 학급(이름),

점수 NUMBER(3) CONSTRAINT NN_POINT NOT NULL

);

CREATE TABLE 학급

(

이름 VARCHAR2(20) CONSTRAINT PK_CLASS PRIMARY KEY,

학급 VARCHAR2(2) CONSTRAINT FK_SITE REFERENCES 위치(학급)

);

CREATE TABLE 위치

(

학급 VARCHAR2(24) CONSTRAINT PK_NAME PRIMARY KEY,

교실 VARCHAR2(100)

);

CREATE　TABLE 교사

(

과목 VARCHAR2(20) CONSTRAINT PK_COURSE PRIMARY KEY

교사 VARCHAR2(20)

);

단, 이들 정의는 예제일 뿐이므로 실제로는 애플리케이션에 맞추어 적용하면 됩니다. 애플리케이션의 예로 NOT NULL 제약을 엄밀하게 설정하고, 문자열에 기본 키를 붙이지 않고, 테이블에 'ID'열을 추가하고 테이터에 관리용 ID(학생 번호, 학급 번호, 직원 번호 등)를 부여해 이것을 기본 키 또는 참조 키로 할 수 있습니다.

이렇게 ‘성적’테이블을 4개의 제3정규형 테이블로 분해할 수 있습니다. 그리고 이들 4개의 테이블을 조합하면, ‘성적’테이블로 복원 할 수 있습니다. 이처럼 기본 키 열과 기본 키에만 종속되어 있는 열로만 구성되어 있는 테이블로 분해함으로써, 중복되는 데이터가 없는 효율적인 테이블을 완성할 수 있습니다.

이렇게 테이블의 CREATE TABLE문은 여러 가지로 생각할 수 있습니다. 우리 주위에 있는 데이터를 분석하고 비정규형으로 정리하여 정규화를 진행시키고 CREATE TABLE문을 작성할 수 있을 때까지 위 과정들을 체험합니다.

앞서 말했듯이 제4정규형, 제5정규형 등 좀 더 정밀한 정규형이 있으나, 일반적으로 제3정규형까지 정규형화하면 충분하다고 할 수 있습니다. 그리고 경우에 따라서 시스템의 효율성을 고려하여 제3정규형을 없애고 일부러 제2정규형으로 돌아가기도 합니다.

좀더 자세한 내용은 다른 책을 참조하도록 하고, 여기서는 다음 내용을 기억하기를 바랍니다.

1. 우리들 주변에 있는 데이터는 비정규형인 것이 많으므로 바로 테이블화 해서는 안 된다.

2. 꼭 보관할 필요가 있는 데이터가 무엇인지를 생각한다(계산으로 나오는 값은 열로 만들지 않는다 등).

3. 열 상호간의 종속 관계를 충분히 고려한다.

4. 정규형의 조건에 따라서 차근차근 데이터를 제3정규형으로 분해해 나간다.

5. 분해할 때에는 원래의 테이블을 복원할 수 있는지를 고려한다.

6. CREATE TABLE문을 생각할 때에 새로운 열(ID열)을 도입하면 설계가 편하고 보기좋게 될 수 있다.

그리고 각각의 정규화는 다음과 같은 관계에 놓여 있습니다. 제3정규형은 제2정규형 조건을 충족하고, 제2정규형은 제1정규형 조건을 충족합니다. 테이블 설계나 작성시에 이들의 관계를 잘 이해하도록 합니다.