DATOR


데이터베이스 모델의 과거와 현재...(주)엔코아 정민수 선임 연구원 커버 스토리


cs.jpg


데이터베이스 모델이라고 하면 보통 ER모델을 떠올리기 마련이지만, 여기서는 좀 다른 얘기를 해보려고 합니다. 데이터베이스 기술은 몇 세대에 걸쳐 발전해 왔으며, 데이터베이스 모델 또한 데이터베이스에 발맞춰 같이 발전해 왔습니다. 요사이 BigData니 NoSQL이니 하는 말을 자주 듣게 되는데요, 이제 우리는 새로운 세대로 변화하려는 단계에 있는 것 같습니다. 그렇다면 데이터베이스 모델도 새로운 세대에 맞게 어떤 변화가 일어나겠지요. 그렇다 해도 아무런 배경도 없이 갑자기 새로운 기술이 출현하진 않을 것이고, 과거와 현재에 어떤 모델들이 있는지 살펴보면 어느 정도 예상이 되리라 생각합니다.

이 글은 WIKIPEDIA의 Database model 관련 글을 참고해서 작성했음을 미리 밝힙니다.


데이터베이스 모델이란?

데이터 모델의 한 갈래로서, 데이터베이스의 논리적 구조를 결정하고, 데이터가 저장되고 구성되고 가공되는 방식을 결정합니다. 참고로, 데이터베이스 모델은 데이터 모델의 한 유형에 속하며, 익히 알고 계신 UML 모델은 데이터 모델에 속하고, ER 모델은 데이터베이스 모델에 속합니다.


데이터베이스 모델의 과거


Flat model


번호

이름

성별

나이

몸무게

101

김길동

23

177

77

220

이임영

25

163

55


테이블 모델이라고도 하며, 2차원 테이블의 형태로 구성되어 있습니다. 과거 스프레드시트 프로그램에서 주로 사용하던 방식으로, 현재까지도 Excel로 대표되는 프로그램에서 많이 사용되고 있습니다. 한 줄에 하나의 record가 담겨 있으며, 인덱스 구조가 없고, 대부분 레코드간의 구조적 관계도 없습니다. 과거에는 메모리 부족으로 대량의 데이터가 메모리에 올라갈 수 없었기 때문에 파일 구조로 관리되었으며, 이런 데이터를 저장하고 관리하는 데이터베이스를 flat file database라고 불렀습니다.


Hierarchical model


cs01.png


IBM Information Management System (IMS)과 같은 메인프레임 데이터베이스 시스템에서 많이 사용되던 모델이며, 현재 XML 문서의 구조를 기술할 때도 사용됩니다. record에 오직 하나의 부모가 존재하며, 수평 관계의 record끼리는 순서가 있습니다. 위에서 아래로의 탐색은 쉽지만, 아래서 위로 탐색하거나 수평(형제)관계끼리 정렬하거나 할 때는 비효율이 있었으나 이후 보정되었습니다. 하지만, 부모가 1개뿐인 한계로 인해, 1:1 1:M 관계만 맺을 수 있습니다.


Network model


cs02.png


위의 그림처럼, 계층 모델에서 발전한 형태로, 부모가 둘 이상이 될 수 있습니다. 이 때부터 many-to-many 관계가 가능해 졌습니다. 하지만 여전히 단방향 그래프입니다. 관계형 모델로 대체되기 전까지, 널리 사용되었습니다.


Inverted file model

파일에 저장된 데이터의 내용이, 다른 테이블을 검색하는 key로써 사용되는 방식으로, 기존 flat database의 부가적인 set로 사용되었습니다. 이 후 relational model에 이 개념이 도입되면서, index가 탄생하게 됩니다.



데이터베이스 모델의 현재

Relational model

1970년대에 E.F. Codd에 의해 소개된 모델로, 특정 응용프로그램에 종속되지 않는 database management system을 만드는 방법으로서, predicate logic 과 set theory의 관점에서 정의되는 수학적 모델입니다. 이 모델에서는 관계, 속성, 도메인, 이렇게 3가지 핵심 용어가 존재합니다. 여기서의 관계는 행과 열로 구성된 테이블이며, 이 관계 중에 이름이 붙은 열이 속성이고, 도메인은 이들 속성이 가질 수 있는 값의 집합을 말합니다. 즉, 관계형 데이터베이스에서의 "관계"란 (관계선이 아니고) 데이터베이스 내의 다양한 테이블을 뜻하는 것입니다. 각각의 테이블은 행과 열로 구성되어 있으며, flat database model에 있는 것과 유사한 형태입니다.


cs03.gif

이 모델의 강점은, 서로 다른 두 record에 동일한 값이 들어있다면, 이론상 두 record간에는 연관성이 내포되어 있다고 한 점입니다. 이를 기반으로 Key와 연관성(relationship) 개념이 탄생한 것입니다. 이 모델이 점차 발전되어, 우리가 익히 알고 있는 Entity-Relationship(ER) model이 생겨났으며, ER model에 서브클래스, 슈퍼클래스 개념이 추가되어 enhanced entity–relationship(EER) model이 생겨났습니다. DA# 모델의 경우 super/sub type이 이러한 역할을 해주기 때문에, EER model로 분류할 수 있습니다.

Dimensional model
Dimensional model이란, data warehouse에 들어있는 데이터가, OLAP 쿼리를 통해 쉽게 요약될 수 있도록 표현된, 관계형 모델의 특수한 형태입니다.Dimensional model에서는 데이터베이스 스키마가, dimension과 measure로 기술된 fact에 대한, 단일 대형 테이블로 구성되어 있습니다. dimension은 fact의 문맥 (누가 참여하는지, 언제 어디서 발생하는지, 유형은 무엇인지 등등)을 제공하며, 연관 fact들을 서로 묶기 위한 쿼리에 사용됩니다. measure는 fact를 기술하는 (수익 등의) 수치 값입니다.주로 star schema로 구현되는 경우가 많은데, 각 dimension을 보관하는 반 정규화 된 테이블들이, fact를 보관하는 정규화된 하나의 큰 테이블 주위를 둘러싸고 있는 형태로 구성됩니다.
cs04.png

또는 snowflake(눈송이) schema의 형태로 구현되기도 합니다. star schema에서는 각 dimension이 단일 테이블로 반정규화 되지만, snowflake schema에서는 각 dimension이 정규화된 다계층 테이블로 구현됩니다.



cs05.png


Post-relational database model
요즘은, 관계형 모델에 비해 좀 더 일반적인 데이터 모델들이 제공되고 있습니다. 때때로, 이들을 묶어서 post-relational로 분류하기도 합니다. 유사하게 쓰이는 다른 용어로는, hybrid database, Object-enhanced RDBMS 등이 있습니다. 이들의 특징은, E.F. Codd의 정보 원칙인,
"데이터베이스 내의 모든 정보는, 오직 관계 속의 값의 측면으로만 제시되어야 한다" 라는 요건에 얽매이지 않는다는 점입니다. 이러한 모델 중 몇 가지를 아래에서 살펴보겠습니다.

cs06.png

Graph 데이터베이스는, 데이터를 표현하고 저장하기 위해 node, edge, property를 갖고 있으며, 쿼리를 수행하기 위해 graph 구조를 이용하는 데이터베이스입니다. Graph 모델은 네트워크 데이터베이스보다 더 보편적인 구조를 허용합니다. 예를 들면 네트워크 모델의 경우 하위 node가 상위 node를 가리킬 수 없는 반면, Graph 모델은 어떤 node건 다른 node에 연결될 수 있습니다. 이 데이터베이스는 그래프 이론에서 node, property, edge라는 개념을 도입했습니다. Graph 데이터베이스에서의 node는 엔터티를 표현하고, property는 node의 연관 정보이며, edge는 node간 또는 node와 property간을 연결하는 선입니다. 대부분의 중요한 정보는 edge에 저장됩니다.관계형 데이터베이스와 비교하면, 연관 데이터 집합에서 더 빠른 성능을 보이며, 객체지향 응용프로그램에 더 직관적으로 매핑됩니다. 비용이 큰 join 연산을 필요로 하지 않기 때문에, 대량의 데이터 셋으로 확장하기가 수월합니다. 고정된 schema 구조에 의존하지 않기 때문에, schema의 변경으로 인한 데이터 변경 및 관리가 수월합니다. 반대로 관계형 데이터베이스는, 대량의 데이터 요소에 동일한 작업을 수행했을 때 더 빠른 모습을 보입니다. 그래프 구조를 기반으로 하기 때문에, 그래프에서 두 node 간의 최단 거리를 계산한다거나 하는 식의 쿼리에 강점을 보입니다.요약하면, 관계형 데이터베이스에 비해 대량의 데이터 처리 속도는 느리지만, 특정한 용도로 사용할 때는 더 빠른 모습도 보이며, 보다 유연한 구조를 갖고 있고, 객체 지향 응용 프로그램과 잘 어울린다는 강점이 있습니다. 특히 도표나 지도와 같은 그래프 데이터를 저장하고 검색할 때 유용하게 사용될 것으로 보입니다.

Multivalue model
NoSQL 및 다차원 데이터베이스의 일종입니다. 관계형 데이터베이스에서라면 sub-table로 나누어서 저장하던 데이터들을, Multivalue model에서는 하나의 테이블로 저장할 수 있습니다. 하나의 속성에 여러 개의 값을 저장할 수 있기 때문입니다. 이런 저장방식으로 인해, 더 적게 읽게 되고, 잘못된 참조(FK)로 인한 오류를 줄일 수 있으며, 트랜잭션 처리가 더 단순해 집니다. 이 방식은 XML이 데이터를 표현하는 방식과 유사하기 때문에, XML과 같은 구조의 데이터를 저장하는 데에 유리할 것입니다.

Object-oriented database model

cs07.png


이전 세대의 SW개발에서는, 데이터의 집합이 array형태였기 때문에, 구조적 복잡성이 덜했고, RDBMS로 충분히 표현 가능한 형태였습니다. 그러나 객체 지향 프로그래밍으로 넘어오면서, RDBMS와 응용 프로그램 간의 불일치가 생겨났습니다. 때문에, object model이라는 새로운 데이터베이스 모델이 생겨나게 되었습니다. 데이터베이스에 데이터 타입을 정의할 수 있게 되고, 캡슐화 및 다형성 개념이 도입된 것입니다. 표준화 문제로 인해 어려움을 겪고 있지만, 많은 수의 DBMS들이 객체의 개념을 조금씩 도입하고 있습니다. 실제로 Oracle DB만 보아도, 사용자가 데이터 타입을 직접 정의할 수 있게 되어 있습니다.

정리
앞에서 몇 가지 post-relational database model을 살펴보았는데요, 이 들의 공통점은 현재 많이 사용되고 있는 응용프로그램의 데이터 구조와 닮아 있다는 점입니다. Graph model은 그래프를 사용하는 응용프로그램, 대표적으로 다이어그램 SW나 온라인 지도 App등의 프로그램과 잘 어울릴 것이고, Multivalue model은 XML 형태의 Data와, Object-oriented database model은 OOP 기반 응용프로그램과 잘 어울릴 것입니다. 이러한 모델만 보더라도, 응용프로그램이 database에서 중요한 위치를 차지하고 있다는 걸 알 수 있습니다. 때문에, database 쪽에서 상호간의 불일치를 줄이기 위한 노력이 끊이지 않고 지속될 것이고, 필연적으로 database 모델의 형태 또한 점차 다양하게 변화해 갈 것입니다. 앞으로 더 다양한 형태의 database가 출현하게 되면, 응용 프로그램이 특정 database에 맞춰서 개발되기 보다는, 응용 프로그램이 자신의 요건에 가장 잘 맞는 형태의 database를 선택하는 방식으로 변화가 일어날 것입니다. 그렇게 되면, 정해진 형식의 모델보다는, 데이터와 그 다양한 형태를 잘 표현할 수 있는 모델이 채택될 것입니다. 즉, 앞으로의 데이터베이스는 데이터베이스 모델을 구현하는 데에 국한되지 않고, 다양한 데이터 모델을 수용하는 형태로 확장될 가능성이 높아 보입니다. 어쩌면, 이미 NoSQL을 통해 어느 정도 현실화 되었는지도 모르겠습니다.

Tag :

Leave Comments