전문가칼럼

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

관계형 데이터베이스 분석/설계 기본으로 돌아가자! 관계형 이론을 근간으로(1)

작성자
admin
작성일
2021-02-22 16:07
조회
2003
관계형 데이터베이스 분석/설계 무엇이 문제인가

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

지난 수년간 데이터 모델링, 데이터 모델링 품질보증(Quality Assurance), 데이터베이스 진단 및 튜닝 컨설팅을 수행하면서, 본 컨설턴트는 관계형 데이터베이스(RDBMS - Relational DataBase Management System)의 가장 기본이 되는 관계형 이론(Relational Theory)의 사상이 접목된 데이터 모델 및 프로그램을 거의 찾아보지 못하였다. 관계형 데이터베이스를 이용한 많은 프로젝트에서 왜 이러한 현상이 발생하며, 이러한 잘못된 현상을 바로잡기 위하여 우리가 어떤 노력을 기울여야 하는가에 대해 관계형 이론에 대한 설명과 관계형 이론에 맞지 않는 잘못된 E-R(Entity Relationship) 모델 및 프로그램의 사례를 보면서, 관계형 데이터베이스를 올바로 쓰기 위한 가장 기초적인 사항들을 살펴보고자 한다.

img01.jpg

그림 1의 사례 테이블에서 A사의 회원 테이블(Table)은 회원번호(15) = 회원사번호(2) + 고객번호(9) + 일련번호(4)로 구성 되어 있으며, B사의 계좌 테이블은 계좌번호(14) = 지점코드(3) + 상품코드(2) + 고객번호(6) + 일련번호(3)로 구성 되어 있다. A사의 현재 총 회원 수는 6,000,000 이고, B사의 현재 계좌 수는 10,000,000 이다. A사 B사 모두 회원번호와 계좌번호 컬럼을 가지고 있으면서도 회원번호와 계좌번호를 구성하는 각각의 컬럼을 중복으로 관리하고 있다. 무엇이 문제인가 첫번째 A사는 15 * 6,000,000 = 90,000,000 Byte의 데이터를 중복으로 가지고 있고, B사는 14 * 10,000,000 = 140,000,000 Byte의 데이터를 중복으로 가지고 있는 것이다. 두 번째 더욱더 중요한 것은 회원번호와 계좌번호를 각각의 컬럼으로 분해하였을 때 분해된 컬럼(회원 번호인 경우 회원사번호, 고객번호, 일련번호)의 값(Value)이 중복으로 관리되고 있는 컬럼의 값(Value)과 일치하는지를 보장할 수 없다라는 것이다(무결성(Integrity) 위배). 만약 우리가 데이터베이스 내 어떤 정보를 조회(Select)하였을 때 그 값이 서로 틀리 다고 한다면 어느 값을 신뢰할 것인가 회원번호인가 아니면 회원사번호 + 고객번호 + 일련번호인가 관계형 데이터베이스의 기본이 되는 특성 중 속성(Attribute)의 원자성(Atomic) 개념을 알고 있는 사람이라면 적어도 이와 같은 분석, 설계를 하지는 않았을 것이다.
매인프레임 환경 하에서의 분석/설계 기법을 관계형 데이터베이스에서도 이러한 현상들은 특히 과거에 매인프레임 환경 하에서 전산을 한 사람(계층형 데이터베이스(Hierarchical Database)나 SAM(VSAM or ISAM)파일 환경에서 분석, 설계, 개발을 주로 한 사람)들이 많은 대형 기업의 데이터 모델이나 테이블을 보면 흔히 나타나는 현상들이다.
1990년대 초반 관계형 데이터베이스가 상용화되어 우리나라에 도입되었을 때, 관계형 데이터베이스를 이용하는 프로젝트가 하나 둘씩 증가하여 현재에 이르게 되었다. 초기 관계형 데이터베이스를 이용한 많은 프로젝트의 관리자들은 매인프레임 환경 하에서 분석, 설계, 개발을 한 사람들로 왜 매인프레임 환경하의 데이터베이스에서 관계형 데이터베이스로 전환을 해야 하며, 매인프레임 환경의 데이터베이스와 관계형 데이터베이스의 차이점에 대한 정확한 인식 없이 프로젝트를 진행하였던 것이다. 그 당시 미국에서는 계층형 데이터베이스에서 관계형 데이터베이스로의 전환을 역공학(Reverse Engineering 시스템이 있는 상황에서 현시스템의 문제점을 분석하고 새롭게 가고자 하는 방향을 설정하여 시스템을 구축하는 방법)기법을 이용하여 재개발하면 순공학(Forward Engineering 시스템이 없는 상황에서 시스템을 도입할 때 쓰는 방법)기법에 의하여 시스템을 구축하는 것보다 공수가 1.5배 내지는 2배가 들어간다고 하였다. 그러나 국내에서는 매인프레임 환경의 데이터베이스 내용을 다 알고 있으니 관계형 데이터베이스로 그대로 빨리빨리라는 지시만 할 뿐 계층형 데이터베이스와 관계형 데이터베이스의 근본적인 차이점을 인식 못하고 보통 순공학 방법 공수의 0.5 배로 프로젝트를 진행하였던 것이다. 즉, 계층형 데이터베이스의 Segment 하나 당 관계형 데이터베이스의 테이블 하나를 생성하여 프로젝트를 진행한 사례가 많았다. 결론은 관계형 데이터베이스는 문제가 많다라는 것과 시스템의 재구축 이었다.
현재의 상황을 보면 이렇게 시행착오를 겪으며 많은 부분이 개선되었음에도 불구하고, 아직도 관계형 데이터베이스의 기본적인 개념을 인식하지 못하고 분석, 설계가 이루어지는 경우가 종종 있는데, 이런 현상이 나타나는 프로젝트의 분석, 설계를 담당한 엔지니어를 면밀히 관찰해 보면 업무를 많이 알면서 과거 메인 프레임 하에서 분석, 설계를 담당 했다던가 아니면 이런 엔지니어에게 분석, 설계를 배운 중고참 엔지니어인 경우가 대부분이다.
새로운 패러 다임(Paradigm)으로의 전환
관계형 데이터베이스 이전의 환경에서 구축된 시스템의 문제점을 살펴보면, 첫째 중복 관리되는 데이터가 많고, 둘째 데이터의 정확성과 일관성을 유지하기가 불가능하며, 비즈니스가 변화함에 따른 정보요구에 상당히 비탄력적이고, 불필요한 개발과 유지보수 비용이 많이 든다는 것이다. 이러한 소프트웨어 개발 및 유지보수의 생산성 문제를 상당 부분 해결하고자 노력한 결과 탄생하게 된 데이터베이스가 관계형 데이터베이스인 것이다.
관계형 데이터베이스를 창시한 E.F.CODD 박사는 수학자였다. 관계형 데이터베이스는 수학의 집합(Set)이론에 근거하여 창시된 데이터베이스 이다. 테이블(Table = Relation)도 집합이고, 관계(Relationship)도 집합이고, 속성(Attribute)도 집합이며, 데이터를 처리(조회, 입력, 수정, 삭제)할 때도 이 모든 것을 집합적인 개념을 가지고 처리를 해야 한다.

img02.jpg

테이블은 가로(Tuple = Row)와 세로(Attribute = Column) 즉, 면적(집합 = Set)을 갖는 2차원의 구조로 되어있다. 이 2차원의 구조에 예를 들어 사원이라는 테이블이 있다고 보자 사원의 인스턴스(Instance = 실제 발생되는 예)를 보면 “김길동”,“홍길동”,“박길동”등 여러분 회사의 사원 테이블의 사원들을 생각해 보라. 이 사원들은 각자의 속성(Attribute)을 가지고 있다. “사원번호”, “성명”, “주소” 등등. 이렇게 여러 개의 속성을 갖는 사원 인스턴스들의 집합이 사원이라는 테이블인 것이다. 관계(Relationship)는 예들 들어 부서 테이블을 생각해 보자. 부서 테이블에는 “영업부”,“생산부”,“인사부” 등이 있다고 가정하자. 사원들 중에는 인사부에 속하는 사원, 영업부에 속하는 사원 등 한 사람의 사원이 어떤 하나의 부서에 속해 있을 것이다. 이렇게 사원 테이블과 부서 테이블의 하나의 인스턴스와 하나의 인스턴스가 연관(Associative)되어 있는 것을 짝(Pairing)이라고 표현한다. 이러한 짝(Pairing)을 집합적으로 모은 것이 관계(Relationship)인 것이다. 속성도 마찬가지로 성명이라는 속성이 있을 때 여기에 나타나는 인스턴스는 속성의 값(Value)으로 “김 - -“, “박 - -“라는 값들이 있을 것이다. 이러한 값들의 집합이 속성(Attribute)인 것이다.