데이터 모델링8 - 데이터 모델링은 2차원 표에 어떻게 데이터를 담을 것인지 고민하는 과정

데이터 독립성과 데이터 모델링의 실질적 정의

 

물리데이터와 논리데이터

모델을 우리말로 번역하면 모형 정도가 될 것이다. 모형은 사전적 의미 그대로 실물을 모방하여 간단하게 만든 물건이다. 그렇다면 데이터 모델의 실물은 무엇일까? 우리는 데이터라는 콘텐츠를 담을 그릇이 필요하 것이고, 이 그릇을 IT스럽게 얘기하면 구조 정도로 표현할 수 있을 테니, 실물은 결국 데이터의 저장 구조가 될 것이다. 따라서 우리가 만드는 모델은 데이터가 최종적으로 저장되는 구조를 백지 위에 네모 박스와 선으로 그린 그림이다.

 

그림 6-1 파일시스템에서 물리적 블록과 논리적 파일의 관계

 

윈도우에서 디스크 조각 모음을 해본 경험이 있다면, 사람이 파일시스템에서 정보의 최소 단위로 인식하는 파일이 실제로는 디스크의 여기저기에 물리적으로 흩어진 블록조각들의 모음이라는 사실을 이해할 것이다. 연속적이지 않ㅇ은 블록들을OS가 묶어서 하나의 논리적이 파일로 인식할 수 있도록 도와주는 것이다.  

 

사실 우리가 물리적으로 존재한다고 생각하는 파일은 물리적 실체가 없다. 디스크에 할당되어 데이터가 저장된 블록만이 실재할 뿐이다. OS 덕분에 논리적 개념인 파일이 물리적 실체와 대응한다고 믿게되는 것이다. 하지만 결국 파일은 논리적인 개념이다. 디스크에 블록들의 모음으로서의 파일이라는 개념이 상위에 존재하기 때문에 우리는 블록 수준을 인지하지 않고, 또 이해할 필요도 없이 더 수월하게 자료를 복사하고 삭제하는 등의 작업을 할 수 있다.

 

3단계 데이터 독립성 스키마 구조

그림 6-2 단계 데이터 독립성 스키마

 

다음은 ANSI/SPARC의 3단계 데이터 독립성 스키마 구조에 대한 개념도다. 데이터 독립성의 개념은 데이터베이스의 근간이 되는 사상으로, 반드시 이해하고 넘어가야 한다. 외부, 개념, 그리고 내부의 데이터 계층(layer)에 대한 이해가 부족하여 외부 스키마를 개념 스키마 계층에 생성하는 등 데이터의 통합성을 저해하고 중복 데이터를 양산하는 경우를 현장에서 자주 목격하게 된다.  최종 사용자가 보는 화면별, 업무 흐름의 프로세스 별로 테이블을 생성하는 경우가 대표적이다. 그럼 3단계 데이터 독립성 스키마에 대해 살펴보자.

 

데이터 독립성 스키마 구조의 내부 스키마와 실제 디스크의 저장 구조와의 관계는 앞서 설명한 파일 시스템의 파일과 블록의 관계와 유사하다 실제 데이터가 저장되는 디스크의 저장 구조, 즉 [그림6-2]에서 내부 스키마 아래쪽은 굉장히 복잡해서 일반 개발자가 완전히 이해하여 설계와 구현에 반영하기는 쉽지 않으면, 또 그렇게 할 필요도 없다. 오라클과 같은 DBMS는 데이터 독립성을 유지하고 과도한 복잡함을 숨기기 위해 한 단계(계층) 더 추상화된 내부 스키마를 제공하기 때문이다. 내부 스키마는 우리가 보통 2차원 표 구조로 인식하는 엑셀 시트와 같은 모습이다.

 

따라서 모델을 만들때는 2차원 표 구조를 염두에 두고 만들면 된다. 실제로 DBMS는 데이터를 우리가 생각하느 표 형태로 차곡차곡 담지 않는다. 이런 맥락에서 내부 스키마를 DBMS가 데이터를 담는 논리적인 구조라고도 할 수 있다. 내부 스키마에는 RDB의 테이블, 파티션, 클러스터와 같은 물리 모델이 만들어지게 된다. 

 

결국 내부 스키마 덕분에 저장 구조를 표 형태로 이해하고 사용할 수 있게 된다. 서로 독립적인 내부 스키마와 실제 물리적 저장 구조를 어떻게 연결하느냐는 각각 DBMS마다 다르다.

 

 

데이터 독립성 모델의 의미를 정리하면 다음과 같다. 3단계 스키마 구조의 최상단 1)외부 스키마는 사용자 개개인이 보고자 하는 정보 관점의 스키마다. 테이블들을 조인하여 원하는 집합을 만들어 보여주는 뷰가 정확히 이에 해당한다. 2)개념 스키마는 개별 사용자 관점을 데이터 관점 혹은 데이터 유형으로 통합한 뷰다.  논리 데이터 모델이 이 계층에 위치한다. 마지막으로 3)내부 스키마는 데이터가 저장되는 스키마 구조로서 테이블 수준의 물리 데이터 모델을 의미하지만, 통상적으로는 물리 데이터 모델과 그 이하 OS 수준에서의 저장 구조까지 포함한다.

 

여기서 주의해서 관심을 가져야 하는 영역이 '개념 스키마'이다. 개념스키마는 외부 스키마와 독립된 계층이다. 하지만 흔하게  개념스키마를 외부 스키마 다루듯이 테이블을 화면별, 보고서 장표별, 심지어 업무 프로세스별로 만드는 함정에 빠지는 경우가 많다. 이렇게 하면 스키마 계층의 독립성이 무너지고 결합도만 높아진다. 결국 화면이 변경될 때마다 새로운 테이블을 만들거나 기존 테이블을 변경해야하며, 프로그램도 새로 개발하고 테스트해야 한다. 따라서 데이터 독립성의 가티를 정확히 이해하고, 데이터 독립성을 해치지 않도록 개념 스키마에 근거해서 모델링을 해야한다. 당연히 개념 스키마는 외부 스키마보다 데이터의 본질에 가깝다.

 

정리

DB로 만드는 것은 결국 저장 구조다. RDB의 저장 구조는 스프레드시트와 같은 2차원 표며, 그 표에 관리하 데이터를 어떻게 담는 것이 최적인지 고민하는 과정이 데이터 모델링이다.  다시 말해 어떤(what)데이터를 어떻게(how) 관리할지 2차원 테이블의 관점으로 생각하는 것이 데이터 모델링이다. 표에 담긴 하나의 행(row)이 하나의 개체(instance)며, 이러한 개체들을 구성 요소로 갖는 집합이 바로 엔티티(entity)다. 

 

 

출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저