관계형 모델 이론(Relational Theory)을 이해하자!

엔코아 정보 컨설팅의 장희식

p> 관계형 데이터베이스의 창시자 E.F.CODD 박사나 그 이후 관계형 데이터베이스에 대한 이론을 발전시켜온 C.J.DATE, Clive Finkelstein 등이 말하는 관계형 모델 이론을 살펴봄으로써 관계형 데이터베이스의 올바른 분석, 설계로의 첫발을 내 딛고자 한다.
관계형 모델 이론은 데이터 구조(Data Structure), 데이터 조작(Data Manipulation), 데이터 무결성(Data Integrity)에 관한 이론이다. 물론 관계형 데이터베이스 이전에도 데이터 구조와 데이터 조작이라는 개념은 있었다. 하지만 관계형 데이터베이스에서 논하는 이론과는 상당한 차이가 있다. 게다가 데이터 무결성 이라는 개념은 관계형 데이터베이스 이전에는 없었던 개념이다. 업무규칙(Business Rule)에 따라서 데이터의 일관성과 정확성을 유지하는 것을 무결성(Integrity)이라고 하는데 이러한 무결성을 관계형 데이터베이스 이전의 데이터베이스에서는 관리를 할 수 없었던 것이다. 이러한 구조와 조작과 무결성의 개념을 정확히 이해하면서 관계형 데이터베이스를 사용한다면, 관계형 데이터베이스 이전의 시스템에서 발생한 많은 문제(새로운 패러다임으로의 전환 앞부분에 기술)점들을 해결할 수 있을 것이다.

관계형 모델 이론(Relational Theory)

관계형 모델 이론에 대한 정의는 Candace C. Fleming & Barbara von halle 이 공저한 “Handbook of Relational Database Design”이란 저서에 잘 나타나 있다. 이 내용을 그대로 인용해 보겠다.
“The relational model is an orderly, predictable, and (for the most part) intuitive approach to perceiving, organizing, and manipulating business data. As such, the relational model is a template for how data appear to a user, how a user performs operations on the data, and how the data behave when they are manipulated. It is important to note that the relational model is an intellectual concept defining user perception of data.”
“관계형 모델은 비즈니스 데이터를 인식, 구성하고, 조작하는 잘 정돈되고, 예견가능하며, 직관적인 접근 방식이다. 관계형 모델은 데이터가 사용자에게 어떻게 보여지며, 사용자는 데이터에 어떤 작용(조작)을 하며, 데이터가 운영될 때 어떻게 유지되어야 하는가에 대한 템플릿이다. 그것은 사용자가 인식하는 데이터를 정의하는 지적인 개념이라는 것이다.”
관계형 모델 이론의 핵심(Core)에는 “데이터”가 있다. 이는 기업의 업무 프로세싱의 중심에 “데이터”가 있다는 말과 같은 맥락이다. 관계형 데이터베이스 이전의 시스템에서 발생하는 많은 문제점들이 “기업의 비즈니스 목적이 변하지 않는 한 거의 변화가 없는 데이터를 정확히 파악하지 못해서 발생하는 것이다.”라는 것이 E.F.CODD 박사의 기본적인 생각이며, 과거 프로세스를 중심으로 시스템을 분석, 설계하는 구조적(Structured) 방법론을 따르지 않고 데이터 중심의 분석, 설계를 하고자 하는 사람들의 기본적인 생각인 것이다. 관계형 모델 이론은 기업의 데이터가 가지는 업무규칙을 정확히 파악하고자 하는 것이다.
데이터 구조(Data Structure)
- 사용자가 데이터를 인식하는 구성.(organization of the data, as users perceive them) “ 6가지 특성을 가진 행(Row)과 열(Column)로 구성된 2차원의 관계테이블로 표현.”
1) 각 열은 하나의 값만을 가진다.(Entries in Columns are single-valued.)
2) 각 열은 동일한 성격의 값을 가진다.(Entries in Columns are of the same kind.)
3) 각 행은 유일하다.(Each row is unique.)
4) 열의 순서는 의미가 없다.(Sequence of columns(left to right) is insignificant.)
5) 행의 순서는 의미가 없다.(Sequence of rows(top to bottom) is insignificant.)
6) 각 열은 유일한 이름을 가진다.(Each column has a unique name.)
데이터 조작(Data manipulation)
- 사용자가 관계테이블에 행하는 일련의 처리형태.(types of operations users perform on the relational data structure)
* SET 처리(set at a time)
* 관계 연산자 : 조회
Select(or Restrict) : 열(Column)에 의거한 행(Row)의 Subset.
Project : 열(Column)의 Subset.
Product : 두 관계 테이블간 행(Row)의 조합을 묶음.
Join : 열(Column)의 기준에 의거하여 각 행(Row)을 수평적으로 묶음.
Union : 중복을 없이하여 각 행(Row)을 수직적으로 묶음.
Intersection : 관계 테이블간의 공통된 행(Row).
Difference : 하나의 관계 테이블에만 있는 행(Row).
Division : 다른 관계 테이블의 모든 행에 대응하는 열을 제외한 열.
처리 연산자: 관계 테이블의 내용에 변화
Insert : 행의 입력. Update : 행의 수정. Delete : 행의 삭제.
데이터 무결성(Data integrity)
사용자가 관계연산자를 수행할 때 데이터 값을 관장하는 업무규칙.(set of business rules that govern how relational data values behave when users perform relational operations)
* 실체 무결성 규칙(entity integrity rule): 주식별자(특정 행을 유일하게 인식하는 하나 이상의 열)는 Null 값을 포함하지 않는다.
* 참조 무결성 규칙(referential integrity rule): 관계 테이블의 모든 외부 식별자 값은 연관되어 있는 관계 테이블에 주식별자 값이 존재해야 한다.
* 영역 무결성 규칙(domain integrity rule): 테이블 내의 모든 열에 관한 무결성 규칙으로 데이터 타입, 길이, 허용 값, 기본값, 유일성, Null 여부 등에 관한 제한이다.
속성의 원자성(Atomic) 개념
각 열(Column)은 하나의 값만을 가진다. 테이블의 구조에서 가지는 첫번째 특성인데, 이 예기는 E.F.CODD 박사의 12가지 관계형 규칙 중 두 번째 규칙 보장된 접근 규칙(Guaranteed Access Rule) 관계형 데이터베이스의 모든 자료(더 이상 분리되지 않는 단위 값(Atomic Value))는 테이블명, 주키값, 그리고 열 이름을 조합 함으로써 논리적으로 접근이 보장되어야 한다.- 과 연관 지어 생각해 보겠다. 다시 한번 설명하면 관계형 테이블의 열(Column)은 더 이상 분리되지 않는 단위 값(Atomic Value)의 단일 값(Single Value)을 가져야 한다는 것이다.
서두에 사면 내부에 업무적인 의미를 갖는 여러 개의 컬럼이 복합되어 하나의 회원번호와 계좌번호를 이루고 있는 것이다. 여기에서 중요한 것이 업무적인 의미를 갖는다는 것인데 이것을 다른 말로 표현하면 회원번호 내 고객번호나, 계좌번호 내 상품코드, 고객번호를 이용하여 정보를 조회하고자 하는 비즈니스적인 요구가 있느냐 하는 것이다. 이러한 업무적인 요구가 있다면 회원번호나 계좌번호는 각각의 컬럼으로 분리되는 것이 더 이상 분리되지 않는 단위 값(Atomic Value 원자값)인 것이다. 다시 말하면 테이블 내 모든 속성은 원자 속성으로 업무에 대한 단일 사실(single fact)을 나타내며 그 안에 의미가 있지만 모델 사용자들에게 “숨겨져” 있을지도 모르는 어떠한 다른 사실들을 포함해서는 안 된다.
이렇게 컬럼이 원자값(Atomic Value)으로 분리되지 않으면 무엇이 문제인가 사례의 계좌번호를 가지고 문제점을 설명해 보겠다.
첫째, 속성은 단일 사실, 단일 개념을 나타내야 한다는 정의를 어기고 있다. 명백히 계좌번호에 많은 사실을 기록하고 있다.
둘째, 회사가 계속 성장하여 지점이나 상품의 개수가 늘어난다면 이 자릿수 만으로는 만족을 못 시킬 것이고, 또한 은행의 지점은 수시로 통폐합이 발생하는데, 이 계좌번호가 여기서는 Primary Key로 역할을 하며 분명 다른 테이블과 관계를 맺고 있을 것인데 그 하위 테이블에 나타나는 참조 값들의 변경은 어떻게 감당할 것인가
셋째, 구성요소(지점코드, 상품코드, …)의 특성들을 숨기거나 모호하게 하여 계좌번호만 보고는 업무적으로 계좌번호가 구성된 업무 규칙을 못 보여주며, 모델의 다른 요소들에 대한 여러 가지 종속성(예, 지점, 상품, 고객과의 관계)을 모호하게 하고 있는 것이다.
넷째, 원자값이 아닌 속성은 접근경로(Access Path)를 잃어 버린다는 것이다. 위에서 업무적인 의미가 있느냐 없느냐를 설명할 때 각각의 컬럼으로 조회를 하고자 하는 비즈니스 적이 요구가 있느냐를 물었다. 이러한 경우 SQL 구현 시 원자값으로 컬럼이 구성되어 있지 않으면 접근경로를 잃어버릴 것이다. 예를 들어 SQL의 WHERE 조건에 substr(계좌번호,4,2) = 상품코드 식으로 SQL을 구사하는 경우를 가끔 볼 텐데 WHERE 조건의 좌변이 가공되면 인덱스 사용을 못하고 FULL TABLE SCAN을 하게 된다. 물론 ORACLE의 경우 FBI(Function Based Index)를 사용하면 접근경로를 잃어 버리지 않지만 이는 어디까지나 특정 제품에 한정된 것이고, 이를 사용하려면 정기적으로 Analyze를 해줘야 하는 부담이 있다. 이렇게 접근경로를 잃어버리게 설계가 되어 있다 보니 이 접근경로를 잃어버리지 않기 위하여 각각의 원자 속성으로 중복관리를 하고 있는 것이다.
관계형 데이터베이스 내 컬럼의 원자단위 속성 규칙이 현실에서 위배되는 경우는 이 외에도 제조회사의 제품코드 등 각종 식별자, 그리고 텍스트 블록(예를 들어 취미 컬럼)이나 주석 속성들 등에서 우리는 많이 볼 수 있다.
속성이 원자속성으로 분리되지 못하고, 복합적인 성격을 갖는 속성으로 정의되어 설계되는 이러한 현상이 발생하는 이유는 무엇 때문인가 가장 근본적인 문제는 과거 데이터베이스나 File 시스템에서 분석/설계한 개념을 가지고 있는 고참 직원들이 그 개념 그대로 관계형 데이터베이스를 분석/설계하는 데에 문제가 있는 것이다. 이러한 현상을 규명하기 위해서 먼저 관계형 데이터베이스의 데이터 조작(Data Manipulation) 개념과 Key와 Index의 개념을 설명하겠다.