참조 무결성

엔코아 정보 컨설팅
장희식

참조 무결성의 정의를 보면“관계 테이블의 모든 외부 식별자 값은 연관되어 있는 관계 테이블에 주식별자 값이 존재해야 한다.”라고 정의하고 있다. 참조 무결성에 의한 업무 규칙을 설명하기 전에 관계에서의 중요한 개념을 먼저 설명하겠다.

표시는 필수적(Mandatory)이라는 표시며,표시는 부모(Parent) 테이블(또는 Entity)의 PK가 자식(Child) 테이블의 PK를구성하는데 참여한다는 표시이다. 까치발과 같은 표시는 다(多)를 표시하는 것이다. 즉 고객 한 사람이 주문을 여러 번 할 수 있으며, 하나의 주문은 한 고객에 의해서만 이루어 진다는 표시다.

고객 테이블과 주문 테이블의 관계에서 선택적이라는 것과 필수적이라는 것에 대한 개념을 다시 한번 설명하겠다. 여기서 선택적이라는 말은 고객 테이블의 인스턴스(= 행)가 한 건이 입력(Insert = 생성)될 때 주문 테이블의 인스턴스가 반드시 필요 하느냐라는 것이다. 필요하다면 필수적이고 필요 없다면 선택적이다. 고객이 한건 입력될 때 주문의 어떠한 건도 필요 없으므로 선택적이다. 그러나 반대로 주문 테이블에 주문이 한 건 입력될 때 어떤 고객이 주문을 하는 것인지 반드시 필요할 것이다.

다음 예를 보자 주문 테이블과 주문 상세 테이블을 보면(여기서는 일반적인 주문에 Item이 여러 개인 것을 가정하고 있다. 선박회사 같은 경우는 주문 한건에 주문 Item이 하나이니 굳이 이런 모델이 나오지 않을 것이다.) 주문 한건이 생성될 때 그 주문건은 반드시 하나 이상의 주문상세 내역이 있어야만 하고, 반대로 주문상세 내역 한 건이 생성될 때에도 반드시 주문 건이 있어야만 업무적인 요구사항을 만족시킬 수 있을 것이다. 그래서 주문과 주문 상세는 양쪽으로 필수적인 관계이다.

참조 무결성 규칙에는 크게 입력규칙(Insert Rule)과 삭제규칙(Delete Rule)이 있다.입력규칙은 부모와 자식 테이블 중에서자식 테이블에 자료를입력할 때외부키(Foreign Key)가 되는컬럼의 값이부모 테이블에 존재하느냐 안 하느냐를 따져서 자식 테이블에 입력을 허용하거나 안 하거나 하는 규칙이고,삭제규칙은 부모와 자식 테이블 중에서부모 테이블에 자료를삭제할 때주키(Primary Key)로 선언된컬럼의 값이자식 테이블에서 사용되고 있는지를 따져서 부모 테이블 자료의 삭제를 허용하거나 안 하거나 하는 규칙이다.

예를 들어서 고객테이블에 자료를 입력한다고 할 때 자식 테이블인 주문하고는 아무 상관이 없다. 하지만 주문 테이블에 자료를 입력한다면 그 주문건은 반드시 고객을 필요로 하므로 그 고객이 고객 테이블에 없다면 고객 테이블에 그 고객을 등록(입력)하고 주문 테이블에 주문건을 입력해야 할 것이다. 반대로 자식 테이블인 주문 건을 한 건 삭제할 때 부모 테이블인 고객하고는 아무 상관이 없다. 물론 주문 상세와는 상관이 있지만 여기서의 논지는 일단 고객하고만 보자. 그러나 부모 테이블의 고객을 삭제할 때 그 고객이 주문 테이블에서 사용되어지고 있는 고객이라면 이 고객을 고객 테이블에서 삭제를 하면 안 될 것이다. 이러한 내용을 보장해 주기 위하여 즉, 데이터의 무결성을 유지하기 위하여 데이터베이스의 물리적인 측면을 보면 Oracle의 경우 Foreign Key Constraint를 생성해 주게끔 되어 있다. 그런데 대개의 경우 이러한 사항을 데이터베이스 내에 설정을 하면 관리상의 불편함과 수행속도 상에 문제점을 야기하므로 인해 설정을 안 해 놓는 경우가 대부분이다.

이제 주문 테이블과 주문상세 테이블을 보자. 고객 테이블과 주문 테이블의 관계하고는 조금 틀리다. 양쪽이 필수적인 것이다. 이런 경우 입력규지는 것과 마찬가지로 적용될 수 있다. 그런데 여기서 주문상세의 행을 하나씩 삭제해 나갈 때, 예를 들어 주문 상세 내역이 세 건 있다고 가정해 보자. 여기서 한건씩 삭제해 가다가 물론 세건 다 한꺼번에 삭제를 할 수도 있고, 어쨌든 주문상세의 마지막 건(행)을 삭제할 때, 그 주문상세의 부모인 주문건은 어떻게 해야 할까 이 주문상세건의 부모도 이 순간에는 삭제가 되야 하는 것이다. 왜냐하면 양쪽 필수적이라는 표기법이 생성될 때 항상 같이 생성되는 것을 약속했으니 삭제가 될 때도 이것들은 같이 삭제가 되어야 하는 것이 업무적인 관점에서 맞다고 보는 것이다.

필자가 여기서 강조하고자 하는 것은 논리적 ERD(Entity Relationship Diagram)에서 이러한 표기법에 따라 프로그램하는 방법이 달라야만 데이터의 무결성을 보장할 수 있는데 이러한 표기법의 정확한 이해 없이 프로그램을 하다 보니 데이터의 무결성이 다 깨져서 부모의 인스턴스가 없는데도 자식의 인스턴스가 있는 경우를 너무도 허다하게 보아왔다.다시 말해 주문과 주문상세에서 주문상세가 없는데도 주문만 있으며, 주문이 없는데도 주문상세가 있는 것이다. 또한 고객이 없는데도 주문에 고객이 있는 경우도 있으니 이런 것이 관계형 데이터베이스의 참조 무결성 규칙을 위한 논리 모델링이 제대로 이루어 지지 못하면서 발생하는 현상이라 하겠다. 이렇게 얘기하면 혹자는 그럼 Foreign Key Constraint를 반드시 설정해야 하는 것이냐고 물을 것이다. 필자가 강조하고 싶은 사항은 그러한 사항을 데이터베이스의 물리적인 장치(예로 Oracle의 Foreign Key Constraint)로 설정하느냐, 프로그램으로 이것을 해결하느냐는 별 개의 문제로 논리적으로 이러한 개념을 정확히 알고 사용하라는 것이다. 위에서도 설명 하였지만 대개의 경우는 데이터베이스의 관리목적과 수행속도를 위하여 프로그램에서 해결을 하고 있는 실정이다. 실제로 데이터 모델링 한 ERD를 업체에 나가서 보면 한쪽 선택적 한쪽 필수적, 양쪽 필수적, 양쪽 선택적인 표기법을 아무 개념 없이 혼용해서 ERD를 만들어 놓은 곳을 필자는 너무도 많이 보아온 것이다.

글을 마치며 많은 프로젝트와 강의를 수행하며, 많은 현업 사람과 엔지니어를 만나며 위와 같은 얘기를 하면 젊은 친구들 일수록 빨리 받아 들이는데, 과거에 Cobol을 경험한 구세대 일수록 생각을 잘 안 바꾸려고 하는 것을 필자는 너무도 많이 보아왔다. 위에 얘기한 내용이 어려운 내용인가 전산을 하는 사람들이 또는 전산인이 아니 여도 쭉 읽어나가면 누구나 이해할 수 있는 그런 내용이라고 본다. 구조가 어떻고, 조작은 어떻게 하며, 데이터의 무결성(정확성과 일관성)을 위하여 어떤 일을 해야 하는지 관계형 데이터베이스를 사용하면서 가장 기본이 되는 내용이기에 필자는 강조하고 있는 것이다. 이러한 기본적인 내용만 알아도 관계형 데이터베이스를 사용하면서 발생하는 많은 문제점을 해소 할 수 있을 것이다. 이 내용은 필자가 창조한 것이 아니다. 다른 사람보다 먼저 책을 통해 이해하고, 경험하고 있는 것 뿐이다. 필자가 얘기하는 것이 아니라 E.F.CODD나 C.J.DATE, Clive Finkelstein같은 훌륭한 학자들이 하는 얘기를 전달하는 것 뿐이다.

이렇게 가장 기본이 되는 내용을 다룬 것은 현실세계에서 관계형 데이터베이스 시대 이전의 분들이 분석/설계한 것을 가지고 시스템을 구축하다 보니 문제가 있고, 또한 이런 과거 세대 분들이 해 놓은 모델이 어디가 문제인지를 모르고 관계형 데이터베이스를 사용하는 신세대 전산인들을 위하여 가장 기본적인 것을 확립해 놓고 나가자는 개념으로 집필을 의도하였다. 이 외에도 관계형 데이터베이스를 사용하면서 배워야 할 것들은 상당히 많다. 오늘도 불철주야 전산을 하는 동료들을 위하여 미력하나마 도움이 됐으면 한다.

필자소개
장 희식(張 熙植) 수석 컨설턴트
성균관대학교 경제학과 졸업
STM(LG-CNS의 전신)에서 전산 시작
현재 엔코아정보컨설팅 모델링솔루션팀 수석컨설턴트로 재직중
무슨 일이든 제대로 올바로 하자는 가치관을 가지고, 자연의 법칙(원칙)이 통하는 사회를 꿈꾸며, 업무를 파악함에 빠짐없이 정확히 현업의 정보요구를 어떻게 파악할 것인가에 항상 노력을 기울여 왔다. 현재는 엔코아정보컨설팅 모델링솔루션팀의 수석컨설턴트로서 프로젝트 산출물을 통한 논리 모델과 물리 설계의 연결성에 대한 일반적인 원리를 정리하며 많은 프로젝트에서 데이터 모델링 컨설팅을 수행하고 있다

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