데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
데이터 무결성(Data Integrity) 데이브 메르켈 파이어아이 CTO, 위협 방어 프로세스 구축 필요 역설 관계형 모델 이론을 설명하면서 데이터 무결성에 대한 개념을 잠깐 설명하였다. 관계형 모델이 갖는 중요한 특장점 중의 한가지가 데이터 관점에서의 다중(실체, 참조, 속성 등) 무결성을 보장한다는 것이다. 관계형 테이블 내의 의미 있는 속성(Column)들은 어떤 무결성 규칙을 가져야만 한다. 이러한 무결성 규칙은 테이블 내의 속성의 값을 정확한 것으로 보장하는 것이다. 사실상 이러한 제약이 없다면 데이터의 값은 부정확하고, 불완전하며, 잘못된 결과를 우리에게 보여줄 것이다. 이러한 무결성 규칙은 우리가 관계형 모델에서 릴레이션을 설명할 때 집합을 정의하면서 집합의 특성상 가져야만 하는 규칙으로 정의 하였던 것이다. 논리 데이터 모델링에서 소개한 바와 같이 논리 데이터 모델링의 대상은 실체유형 (Entity Type), 관계(Relationship), 속성(Attribute)이다. 이 세 가지의 요소가 무결성 개념을 모두 가져야 한다. 이러한 이유로 관계형 데이터베이스는 다중 무결성을 보장한다는 것이다. 데이터 구조를 설명하면서 릴레이션의 구조 특성 세 번째에서 각 행(Row)은 유일해야 한다고 하였다. 수학적 의미의 집합(set)은 분별할 수 있는 원소의 모임이기 때문에 한 집합에 분별할 수 없는 똑 같은 원소가 중복해서 포함될 수 없는 특성을 튜플(Tuple)의 유일성이라고 하였다. 즉, 두 개의 똑 같은 튜플(행-Row)은 한 릴레이션(테이블)에 포함될 수 없고, 이것은 릴레이션(테이블)의 인스턴스가 튜플(행-Row)을 원소로 갖는 집합이라는 데서 나오는 당연한 성질이라고 하였다.데이터 무결성(Data Integrity)
그림 데이터 무결성에 정의된 바와 같이 데이터 무결성이라는 개념을 보면 입력, 수정, 삭제뿐만 아니라 조회 시에도 데이터의 일관성과 정확성이 유지 되야 한다고 하고 있다. 이러한 무결성에 대한 개념을 좀 더 상세히 살펴보기 전에 앞에서도 설명이 있었지만 다시 한번 강조한다면 관계형 데이터베이스 모델이 아닌 다른 것들은 이러한 무결성 개념을 데이터베이스 시스템 내에서 강력하게 보장해 주지를 못한다는 것이다. 이러한 무결성을 프로그램의 로직으로 보장할 뿐이라는 것이다. 이러한 이유로 현재 발생하는 많은 프로젝트에서 데이터의 일관성과 정확성을 위한 규칙의 파악이 대개 데이터 전문가의 역할이 아니라 프로그램 담당자의 역할인 경우가 다반사이다.
문제는 데이터는 통합 관리되어야 하는데 프로그램 관점에서 데이터를 접근하는 사람들은 데이터 전문가 보다는 상대적으로 통합의 개념이 약하다. 프로그램 전문가들은 본인이 담당하는 프로그램이 문제 없이 잘 수행되는 것에 당연히 더 관심이 많은 것이다. 즉, 애플리케이션의 위주의 절차 중심의 분석, 설계는 데이터 통합이라는 너무도 중요한 사상을 놓칠 수 있는 가능성이 높은 것이다.
많은 프로젝트나 데이터 모델 QA(Quality Assurance)를 수행하면서 만들어 놓은 데이터 모델을 필자가 살펴본 경우에 있어서 90%이상이 이러한 무결성 개념을 데이터 모델에 잘 표현해 놓지 못하고 있었다. 이러한 원인은 데이터 무결성에 대한 정확한 개념을 이해 못하고 있는 것이 대부분의 경우이다. 다시 한번 강조하지만 과거에 프로그램 로직으로 처리하던 데이터 무결성의 개념을 반드시 논리 데이터 모델에 반영을 하고, 이러한 무결성을 보장하는 것을 프로그램으로 할지 관계형 데이터베이스 시스템 내에 설정할 지는 시스템 설계 단계에서 수행해야 하는 것이다.
데이터 무결성 유형
이러한 네 가지 무결성 이외에도 우리가 논리 데이터 모델링에서 다루는 속성 중에 유도(Derived) 속성이 있는데 이러한 유도 속성들은 대부분 다른 속성에 의해 영향을 받는 계산(Calculated) 속성들이 대부분이다. 예를 들면 주문총액(주문 테이블에 표현되는 주문내역 테이블내의 주문금액의 합계), 보험료(보험계약원장에 표현되는 각각의 보장내역에 따른 보험료의 합계 금액), 이자(원금과 이자율 기간에 의해 결정되는 속성)와 같은 속성들은 다른 속성의 값을 이용하여 표현되는 값인 것이다. 이러한 속성을 논리 데이터 모델에 표현하느냐 안 하느냐의 문제는 속성 정의 파트에서 상세히 설명할 것이다. 계산되어야만 하는 이러한 속성들의 특성을 우리는 업무 규칙(계산 공식)을 갖는 다라고 표현할 수 있을 것이다. 이러한 계산 속성 들 뿐만 아니라 많은 속성들이 업무 규칙에 따라서 입력, 수정, 삭제 시에 유지 관리 되야 하는 특성들을 가지고 있다. 예를 들어 제품의 납품일자는 주문일자로부터 3일 이내여야 한다는 규정도 이 회사의 데이터가 갖는 중요한 업무 규칙인 것이다. 이러한 특성을 업무 규칙(Business Rule) 또는 연쇄 작용(Triggering Operation)이라는 표현을 사용한다.
사실 논리 데이터 모델링 과정 중에 찾아 내야 할 무결성 규칙은 실체, 참조, 속성(도메인) 무결성 규칙보다도 맨 나중에 얘기한 업무 규칙(Business Rule) 또는 연쇄 작용(Triggering Operation)이라는 이름으로 찾아야 할 업무 규칙들이 대부분일 것이다. 그런데 본 필자는 프로젝트 현장에서 이러한 업무 규칙을 논리 데이터 모델 표현한 모델을 한 번도 못 보았다. 이러한 업무 규칙이 양이 많아서 논리 데이터 모델 내에 정리 할 수 없다면 참고 자료를 작성하여 논리 데이터 모델과 연계성을 갖도록 해야 하는데 대부분의 프로젝트에 있어서 이러한 임무는 프로그래머의 프로그램 내에 녹아 들어가 있는 경우가 대부분이다.
데이터는 통합되어 있고 이 데이터를 사용하는 프로그램은 다양하게 많을 것이다. 그런데 데이터가 가지고 있어야 하는 업무 규칙을 업무 분석 관점에서 정리하고, 이것을 이용하여 설계 단계에 프로그램 스팩(Spec)을 작성하고, 코딩을 해야 할 것인데, 업무 분석 단계 처음부터 프로그램 스팩을 작성하여 여기 저기 프로그램에 데이터가 갖는 업무 규칙을 중복으로 정의하고 프로젝트를 진행한다. 이러다가 업무 규칙에 수정 사항이 발생하면 이제부터 많은 문제가 발생하기 시작한다. 프로젝트의 기간은 대체로 짧고 업무 파악이 잘 못 되어 수정 사항은 많아지고 하니 당연히 프로젝트 납기가 지연되는 현상이 발생하게 되는 것이다. 이러한 위험 요소를 줄이려면 최대한 데이터 중심의 업무 분석을 선행하는 것이 본 필자가 추천하는 방식이다.
이러한 업무 규칙 또는 연쇄 작용 외에도 데이터 구조에서 구조의 첫 번째 특성을 얘기할 때 정규화에 대한 얘기를 하였다. 정규화에 대한 얘기를 하면서 정규화의 가장 중요한 목적 중에 하나가 입력 이상, 수정 이상, 삭제 이상이라는 데이터 이상 현상을 제거하는 것이라고 하였다. 이렇듯 정규화도 데이터 무결성을 보장하는 중요한 개념 중에 하나인 것이다.
실체 무결성 규칙
실체 무결성의 정의는 “식별자(Identifier)는 널(Null) 값을 포함하지 않는다.”라고 하고 있다. 즉, 물리적으로는 프라이머리 키(PK: Primary Key)에 대한 것을 규정하고 있다. 프라이머리 키(PK)를 가지지 않으면 이는 테이블로 간주하지 않는다.
널(Null)이라는 값은 논리적으로는 “모르는 값”이라는 의미를 가진다. 우리가 현실 세계에서 어떤 하나의 개체 또는 실체를 인식하고자 할 때, 그 개체 또는 실체를 인식할 수 있는한 값)이 주어져 있지 않더라도 어떤 형태만 있다면 그 개체를 인식할 수 인식할 수 있다. 설령 그 개체의 이름을 모른다 하더라도 인식할 수 있는 것이다. 이 떠오르는 그 무엇이 그 개체의 형상(Image)이든, 어떤 숫자이든 상관 없이 그것은 Null(모르는 것)이 아니라는 것이다. 이런 이유에서 테이블에서 하나의 개체 또는 실체를 인식하려면 Null(모르는 것)이어서는 안 되는 것이다.
식별자 즉, 프라이머리 키(PK)가 Null값을 가지면 어떤 현상이 발생하는가 T1 테이블의 PK가 Null값을 갖는다고 가정을 해보자.
관계 연산자를 이용하여 T1 테이블에서 T2 테이블과 T3 테이블을 만든 후 조인(Join)을 하여 T4라는 테이블을 만들면 원래는 두 개의 행(Row)만 있었는데 조인을 하면서 NULL은 모르는 값이므로 조인 조건에 빠지게 되어 원래는 2개였던 행(Row)이 1개의 행(Row)만 생긴다(빨간색 행이 없어짐). 이런 경우도 우리는 무결성(Integrity) 깨졌다고 한다.
그런데 필자가 베토벤이라는 것에 대해서 얘기하고 있다고 가정을 해보자. 여기에서 필자가 말하는 베토벤을 어떤 사람은 음악가 베토벤으로 인식할 것이고, 어떤 사람은 영화에 나오는 개 베토벤이라고 인식할 수 있다. 인간은 전후 문맥이나, 전체적인 상황을 판단하면서 이것이 음악가를 얘기하는 것인지 영화에 나온 개를 얘기하는 것인지를 판단할 수 있는 지적 능력을 보유하고 있다. 하지만 컴퓨터는 이러한 인간이 지니고 있는 지적 능력을 가지고 있지 않다. 단지 인간의 명령에 의하여 컴퓨터의 임무를 수행할 뿐이다.
컴퓨터는 베토벤이라는 것으로만 정보를 찾으려면 이 베토벤이 악성 베토벤인지 영화에 출연한 개 베토벤인지를 구별 못한다. 이러한 이유로 식별자는 반드시 유일해야 한다는 것이다. 그러므로 식별자를 선정 할 때는 무엇인가 값을 가지며(Not Null), 항상 유일(Unique)한 값을 가져야만 하나의 개체 또는 실체를 정확하게 찾아낼 수 있는 것이다.
식별자가가 유일하지 않으면 어떤 현상이 발생하는가 T1 테이블의 프라이머리 키(PK)가 유일하게 구성되지 않았다고 가정을 해보자.
관계 연산자를 이용하여 T1 테이블에서 T2 테이블과 T3 테이블을 만든 후 조인(Join)을 하여 T4라는 테이블을 만들면 원래는 두 개의 행(Row)만 있었는데 조인을 하면서 2 * 2 = 4 인 곱 집합이 생겨 원래는 없었던 2 개의 행(Row)이 더 생겼다. 이런 경우도 우리는 무결성(Integrity)이 깨졌다고 한다.
이러한 특성 외에 우리가 별도로 Primary Key의 선정 기준을 좀 더 살펴보면 Primary Key를 구성하는 각각의 컬럼 수를 최소한의 집합(Minimal Set)으로 할 것과, 값의 수정이 없는 것, 업무적으로 활용도가 높은 것 등을 들 수 있다. 최소한의 집합이 아니면 유일성(Unique)이 깨질 수 있으며, 값의 수정이 있는 것은 상기의 예에서 지점코드가 통폐합에 의해서 바뀐다던가 상품이 증가하여 자릿수가 늘어난다든가 하면, 자식 테이블에 미치는 영향이 많으므로 될 수 있으면 이런 컬럼들은 Primary Key 선정에서 제외한다. 식별자의 구성 속성이 최소한의 속성으로 구성되지 않으면 어떤 현상이 발생하는지를 알아보자.
그림 식별자는 최소한의 속성으로 구성의 오른쪽을 보면 식별자가 사원번호와 사원명으로 구성되어 있다. 물론 현실에서 이렇게 구성하는 예를 찾아 보기는 힘들겠지만 이해를 돕고자 간단한 예를 든 것이니 개념을 이해하기 바란다.
최소한의 속성으로 구성되어야 할 식별자가 최소한의 속성으로 구성되지 않아 우리가 업무적으로 유일성을 보장해야 하는 특성이 파괴되고 있는 것이다. 만약에 예로든 사원번호를 가지고 다른 테이블과 조인을 하게 된다면 카티젼 프러덕트(다:다의 곱 집합)가 발생하여 상기의 경우에는 데이터가 2배로 증가되어 보여질 것이다.