소규모 프로젝트를 위한 데이터베이스 모델링과 설계 1

소규모 프로젝트를 위한 데이터베이스 모델링과 설계 1

데이터베이스 모델링

 

곽중선｜웹에이젼시

 

데이터베이스 모델링 분야는 매우 전문적이고 어렵다는 시각이 지배적이다. 이론 위주의 학습 과정은 물론 실전적인 가이드가 부족한 현실 때문이다. 대용량 데이터베이스 설계는 고도의 기술이 필요하지만, 대다수의 개발자는 소규모 프로젝트에서 DB 설계를 시작한다. 소규모의 데이터베이스 모델링을 위한 실전 가이드를 소개한다.

 

소프트웨어 개발자 치고 관계형 데이터베이스라는 단어를 들어보지 못한 사람은 거의 없을 것이다. 그러나 프로그래머 혹은 개발자들에게 데이터베이스 설계를 요구하면 대부분 고개를 가로젓는다. 너무 어렵다거나, 전문적인 기술이라고 대개 고개를 흔든다. 누구나 데이터베이스를 사용하지만, 제대로 설계할 수 있는 개발자가 드문 게 현실이다. 데이터베이스는 과연 전문가의 전유물인가. 소규모 데이터베이스 정도는 직접 설계해야 할 필요도 있지 않을까? 게다가 데이터베이스 관련 프로젝트의 대다수는 전문 컨설턴트 없이 수행되는 것이 현실이다. 소규모 DB를 설계하는데 필요한 실전 기법을 중심으로 DB설계의 참맛을 느껴보도록 하자.

 

왜 관계형 데이터베이스인가?

 

관계형 데이터베이스란 1970년 IBM의 E. F.Codd 박사가 발표한 논문의 이론에 기반한 데이터 관리 시스템을 통틀어 부르는 명칭이다. Codd 박사는 모든 자료를 2차원 형태의 테이블로 저장하고, 각 테이블의‘관계’를 강조하는 기술을 이용해 복잡한 형태의 자료들을 단순하면서도 일관성 있게 관리할 수 있다는 것을 수학적으로 증명하였다. 컴퓨터를 활용하는 이유는 복잡하고 반복적인 작업을 정확하고 빠르게 수행하기 위한 것인데, 이러한 과정을 수학적 체계에 따라 정립했다는 점에서 RDBMS의 신뢰성, 정확성이 보장된다는 것에 주목해야 한다. 관계형 데이터베이스가 30년 넘게 발전하며, 여전히 중요하게 활용되는 이유는 자료를 단순한 2차원 표 형태로 저장하면서도 매우 복잡한 자료를 정교하게 조합할 수 있다는 양면성에 기인 한다고 할 수 있다. 대용량의 복잡한 데이터 저장용으로만 관계형 데이터베이스를 활용하는 것은 아니다. 관계형 데이터베이스 이전에 Text file, ISAM file, 계층형 DBMS, 네트워크 DBMS가 개발되었고, 관계형 데이터베이스 이후로는 객체형 DBMS 등이 소개되었다. 그러나 복잡한 대용량의 자료를 처리하는데 있어 요구되는 신뢰성, 처리 속도 그리고 이론적인 체계의 완성도 면에서 관계형 데이터베이스를 뛰어넘는 기술이나 솔루션은 없었다. 따라서 인터넷 포털, 쇼핑몰, 대형유통업체, 정부 기관에서 소규모 자료관리 시스템에 이르기까지 체계적으로 자료를 저장하는 모든 영역에서 관계형 데이터베이스가 활용되고 있다. IT 종사자의 경우 RDBMS는 필수적으로 이해해야 하는 기초 기술이 라고 해도 과언이 아니다. 거의 모든 IT 관련 학과와 교육기관에서 RDBMS를 필수과목으로 가르치고 있음에도 불구하고 자신 있게 DBMS를 설계하고 구축할 수 있는 개발자를 찾아보기 어려운 이유는 무엇일까? 교육현장에서는 지나치게 이론 위주로 가르치고 있다는 점을 지적하지 않을 수 없다. 이론이 불필요하다는 것은 아니다. 왜 모델링을 해야 하는가. 왜 DBMS를 사용하는가에 대한 근원적인 설명이나 데이터베이스 모델을 설계하는 실습을 충분히 거치지 않기 때문이라고 생각된다. 설계 관련 실습을 하더라도 지나치게 복잡하고 어려운 예제를 이용하기 때문에 현장에서 필요로 하거나 응용기술을 익히기 어려운 경우가 대부분이다. 논리적으로 완성도가 높은 모델링이 무의미한 것은 아니지만, 한정된 시간과 인력을 활용해 시스템을 구축해야 하는 현실과는 괴리감이 없지 않다. 정교하고 완벽한 설계 기법은 수십 억, 수천 억건 이상의 자료를 관리하는 대규모의 시스템을 개발할 때나 필요하다. 소규모 정보시스템이나, 인터넷 정보조회 시스템을 설계하는 데 있어서는 좀 더 현실적이고 실질적인 기술이 필요하다(어떤 분야에서나 고급 기술과 범용 기술이 함께 공존하는 법인데 데이터베이스 분야에서는 고급 기술만 우대받는 경향이 강하다).

 

왜 모델링을 해야 하는가?

 

시스템 분석 및 설계 단계에서‘모델링’과‘설계’라는 단어가 혼용되는 경우가 많지만 모델링과 설계는 분명히 다른 의미이다. 데이터 모델링이란 현실 세계의 업무(예를 들면 재무회계, 쇼핑몰, 물류관리 등)를 추상화하는 것이다. 반면 데이터 설계라는 것은 모델링 과정을 통해 추출된 정보를 컴퓨터 내부에서 관리할 수 있는 형태로 구체화하며 구조와 관계를 표현하는 것이다. 따라서 모델링과 설계 과정을 분리하여 설명하도록 하겠다. 모델링은 현실을 추상화하는 작업이라고 표현했다. 추상화(abstraction)라는 용어에 대해 거부감을 느끼는 독자도 있을 것이다. 그런데, 추상화는‘요약’이라는 뜻으로도 해석된다. 소프트웨어 공학에서 말하는 추상화는 형이상학적 개념이라기보다는 복잡한 것을 단순화하는 과정이다. 모델링 역시 복잡한 현실을 단순화시켜 컴퓨터 시스템 내부로 이식할 수 있도록 꼭 필요한 요소만 도출하는 과정이다. 만화가가 인물을 그리는 모습을 떠올려 보자. 사람의 외모에서 특징만 강조하고 세부적인 요소는 배제한다. 완벽함이란 더 이상 추가할 것이 없는 상태가 아니라, 더 이상 제외할 것이 없을 때 이뤄진다는 말이 있다. 추상화 혹은 모델링은 달리 말하면 완벽함을 추구하는 과정으로 요약할 수 있겠다. 현실 세계는 무수히 많은 정보로 구성되어 있다. 사람’을 표현할 수 있는 정보는 얼마나 될까? 이름, 신체조건, 나이, 주민번호, 경력사항, 직업, 취미, 학력 등 열거하자면 끝이 없다. 그런데 인터넷 쇼핑몰을 구축할 때‘사람’이라는 대상은‘고객’혹은‘관리자’라는 단어를 통해 좀 더 단순하게 표현되고‘ID’,‘ 주소‘,‘ 나이’,‘ 성별’등 거래 혹은 마케팅에 필요한 정보만 도출해야 한다. 이러한 과정을 모델링이라 한다. 복잡한 현실 혹은 업무에서 ‘관리 및 기록이 필요한 정보’를 추출하는 작업이다. 동시에 필요 없는 정보를 제거하는 작업을 데이터 모델링이라고 한다. 물론 관리 대상을 찾아내고 나열하는 데 그치지 않는다. 이를 이해 하기 쉽고 의사소통이 원활하도록 도와주는 표준화된 표기법으로 문서화하는 작업을 통틀어 말한다. 또한 시스템 구상 단계에서 스케치를 그리는 것, 데이터베이스를 만들기 위한 청사진을 만드는 것으로도 표현할 수 있을 것이다. 모델링 결과는 데이터베이스 설계를 위한 중요한 준비 작업이다. 목표 시스템이 어떤 정보를 포함할지 사전 검증할 수 있는 근거가 된다. 개발팀원 간 혹은 개발팀과 고객 간 의사소통을 위한 중요한 도구가 되며, 시스템을 설계하는 과정에서 아이디어를 체계화하고 정리하는데 도움이 된다. 또한, 현실업무를 파악하는 과정을 기록해 시행착오가 발생했을 때 원인을 파악할 수도 있으므로 시스템 설계 노하우를 축적하는 데도 안성맞춤이다. 예컨대 모델링은 현실 세계의 무수한 정보 가운데 컴퓨터 시스템으로 이식하려는 대상을 추출해 단순화하고 요약하는 과정이다. 설계는 모델링을 통해 확정된 이식 대상을 데이터베이스 설계 규칙에 맞춰 세밀하게 재구성하고, 정해진 표기 방법에 따라 문서화하는 작업이다. 모델링과 설계의 의미는 분명히 다르지만, 프로젝트 수행 과정에서는 모델링과 설계를 순환하면서 진행한다.

 

데이터베이스의 발전 과정
● ISAM(Indexed Sequential Access Method) : 원하는 정보를 찾기위해 순차적으로 접근하거나, 색인(index)을 통해 선택적으로 접근할 수 있는 파일 시스템. 데이터베이스가 보편화된 이후에도 소규모 정보시스템에서 활용된다.

● 계층형 DBMS : 자료를 트리형태로 저장하는 데이터베이스. 윈도우 파일 시스템의 디렉터리 구조를 연상하면 되겠다. 정보를 디렉터리 형태로 분류하기 때문에, 복잡한 구조를 묘사할 수 없다는 단점이 있다.

● 네트워크형 DBMS : 계층형 데이터베이스의 단점을 보완하기 위해 자료간 연결(link)을 망(network) 형태로 자유롭게 연결할 수 있도록 개선했다. 그러나 자료구조가 복잡해지면 이해가 어려운 데다가 자료구조 변경시 디스크에 저장된 데이터의 물리적 구조를 재구성해야 하며, 애플리케이션 역시 다시 개발해야 한다.

● 관계형 DBMS : 모든 데이터를 2차원 형태의 테이블에 저장하며, 자료간 관계를 표현하기 위해 키라는 데이터 값을 이용한다. 관계형이라는 이름을 사용하는 이유는 테이블간 관계를 설정하는 방법에 대한 연구가 주된 과제이기 때문이다. 관계형 데이터베이스의 장점은 장부, 엑셀 문서 등에서 일상적으로 사용하는 표 형태를 사용해 단순한 설계인 경우 구조를 이해하거나 만들기가 용이하다. 확장도 용이하다. 테이블을 생성한 후 손쉽게 항목을 추가할 수 있고, 자료구조가 변경되더라도 이미 개발된 프로그램을 변경하지 않고 확장할 수 있다.

● 객체형 DBMS : 객체지향이라는 패러다임이 도입되면서 프로그램 상에서 생성되는 객체를 그대로 디스크에 저장하거나, 읽어 들이는 제품이 개발되었다. 다양한 제품이 출시되었지만 널리 보급되지는 못했다. 대용량의 자료를 처리하는데 있어 많은 연구가 이뤄졌으나, 강력한 검색 성능으로 시장을 석권하고 있는 관계형 데이터베이스의 아성을 넘기에는 역부족이다. 지금까지 다양한 DBMS 이론이 연구되었으나, 한동안 관계형 데이터베이스의 지위를 뛰어넘는 새로운 기술이 나타나기는 어려울 것이다. 달리 말하면, 세월이 지나도 사장되지 않을 기술이니 익혀두면 지속적으로 적용할 수 있다.


<그림 1> 데이터베이스 유형 개념도

 

데이터 모델의 종류

 

데이터 모델은 일반적으로 개념, 논리, 물리 등 3단계로 분류하며, 세 개의 모델을 순서대로 작성하는 절차를 거친다. 개념 모델과 논리 모델은 추상화 작업에 가까우며, 물리 모델은 설계 작업이라 할 수 있다.

● 개념 모델
가장 먼저 작성하는 모델로 구축하려는 시스템에 대한 각종 요구 조건을 기술하는 것이다. 목표 시스템에 어떤 정보를 담을 것인가, 어떤 결과를 출력할 것인지 등의 요구 조건을 개략적으로 작성한다. 그러나 화면에 표시할 세부 데이터 항목을 모두 기술해야 하는 것은 아니다. 논리 모델은 말 그대로 설계에 반영하는 것이 아닌 시스템 구상 단계의 대략적인 스케치이며, 논리 모델을 만들기 위한 기초 단계이다. 따라서 일단 개략적인 요구사항을 작성한 후 거의 수정하지 않는다. 예를 들어 인터넷 쇼핑몰을 구축할 때 상품 정보, 고객(혹은 회원), 판매자 등 서비스를 운영하는데 필요한 기본적인 관리 대상을 명시한다. 더불어 고객에게 보여줘야 하는 물품 분류, 재고 및 배송 정보 등 업무를 진행하면서 표시해야 하는 결과물을 도출한다. 각 관리 대상에 대한 상세정보는 표현하지 않는데 지나치게 자세히 표현하면 시스템 전체를 한눈에 들여다보기 어렵기 때문이다.

 

● 논리 모델
개념 모델에 시스템이 필요로 하는 데이터 항목을 상세히 기입한 것이 논리 모델이다. 구축 시스템의 이미지를 확고히 하기 위해 실제 화면을 스케치 하거나, 보고서, 차트, 출력물 등 최종 사용자에게 보이는 결과를 확정해 간다. 또한 각 대상(혹은 테이블)에 포함되는 항목(혹은 컬럼)들을 상세히 표현한다. 여기서 파악된 데이터 항목을 골라 데이터베이스 모델 다이어그램을 그린다. 논리 모델을 작성한 후 가급적 시스템을 사용할 사용자와 함께 설계 결과를 검토해봐야 한다. 꼭 필요한 항목임에도 누락되면, 시스템 개발 중 다시 설계단계로 복귀해야 하는 경우도 발생한다. 관계형 데이터베이스는 운영 중 항목을 추가하기 쉽지만 너무 믿어서는 크나큰 손실을 입는다. 프로젝트가 난관에 봉착할
수도 있다. 예외 상황은 언제나 발생할 수 있지만, 그것을 해결하는 것은 시스템이 아니라 개발자의 몫이기 때문이다.

● 물리 모델
실제 운영 가능한 상태 혹은 자료를 입력할 테이블의 형태를 구체적으로 표현하는 것이다. 이 단계에서는 테이블 내역, 컬럼 및 기본 키(primary key), 외부 키(foreign key), 인덱스 등을 설정한다. 논리 모델에서는 특정 데이터베이스 제품에 의존하지 않지만 물리 모델에서는 오라클, DB2, MySQL, MS-SQL 등 다양한 데이터베이스의 문법(규칙)에 따라 표현 방식이 달라진다. 따라서 하나의 논리 모델에 대해 여러 개의 물리 모델이 존재할 수도 있다. 데이터베이스 제품마다 조금씩 작성 규칙이 다르기에 주로 사용하는 데이터베이스를 정해 세부 기법을 익히는 것이 좋다. 개념이나 논리 모델을 작성하는 단계에서 어떤정보를 관리해야 하느냐 하는 문제를 파악하고 분석하는데 집중해야 한다. 그러나 물리 모델은 복잡한 자료들을 어떻게 구성할 것인가 - 집중할 것인가, 분산할 것인가 -와 각 항목의 크기와 타입을 설정하고 각종 제약사항(필수 입력 여부, 기본 키, 외래 키등)을 명시한다. 시스템 성능에 직결되는 인덱스 등을 지정하므로 신중하게 접근하는 것이 좋다. 규모가 작거나 프로젝트 기간이 짧은 경우에는 논리 모델 작성을 건너뛰고 바로 물리 모델을 작성하거나, 간략히 수행하는 경향이 있는데, 가능하다면 논리 모델 작성을 제대로 수행하는 것
이 시스템 완성도를 높이는 길이다. 개발 단계에 진입했을 때 발생할 위험 요소를 방지하기 위해서다. 문제는 급변하는 경영환경으로 단기간에 시스템 구축을 요구받고, 적은 수의 인력으로 수행되는 프로젝트가 만연한 현실에서 이상만을 주장하고 있을 수만은 없다는 것이다. 그렇기 때문에 논리 모델 보다는 물리 모델을 작성하는 방법과 유의사항에 집중하여 논의할 것이다. 물론 처음 데이터베이스 모델링을 접하거나 체계적으로 지식을 습득하고자 한다면 개념 모델 작성 경험을 쌓는 것이 좋다.

 

<그림 2> 개념, 논리, 물리 모델 다이어그램

 

 

데이터 모델링의 구성요소

 

데이터 모델은 엔티티(entity), 속성(attribute), 관계(relation)라는 3대 요소로 구성된다. 데이터 모델링은 이러한 세 가지 요소를 현실 업무에서 추출해 나가는 과정이다. 작업 대상 혹은 목표의 의미를 정확히 이해하는 것은 매우 중요하니 지나치지 말고 이 세 가지 용어의 의미를 주의 깊게 새겨보기 바란다.

 

● 개체 혹은 엔티티(entity)
엔티티(entity)는‘개체’로 번역하며, 물리적 모델에서는 테이블(table)이라고 칭한다. 개체라는 것은 무엇인가? 명백히 다른 것과 구분되어 존재하는 것, 실체나 개념을 의미한다. 사람, 물건, 문서 등을 예로 들 수 있지만 현실 세계에 존재하지 않는 것도 분명 개체가 될 수 있다.‘ 동일한 특성을 가진 정보들의 집합’ 이라 할 수 있고,‘ 관리 대상인 데이터 집합’이라고도 표현한다.2차원 테이블 형태로 표현할 수 있는 모든 자료로 이해해도 될것이다. 모델링 다이어그램에서는 사각형 박스로 표현한다.

● 속성(attribute)
속성이란 개체의 구성요소로 이름, 가격, 시간, 수량 등의 간단한 데이터 항목을 의미한다. 데이터베이스에서 속성은 숫자, 문자, 문자열, 날짜, 이진 데이터(binary data) 등의 단일 값(single value)을 기록하며, 다른 항목과 구분을 위한 이름이 부여되는 최소 저장 단위이다. 모델링 다이어그램에서는 엔티티 박스 내에 표기된다.

 

● 관계(relation)
데이터모델을 구성하는 엔티티간 의존성 혹은 연결 정보를 표현한 것을 관계(relation)라고 한다. 개체는 단독으로 의미를 가지는 경우도 있지만, 대체로 여러 종류의 개체가 조합되어 의미 있는 정보가 된다. 쇼핑몰에서 물건을 구매하는 프로세스에서 ‘상품 구매 기록’을 관리하는 경우를 가정해보자. 구매 기록은 상품, 구매자, 판매자 등의 개체에 대한 정보와 판매 기록 그 자체 (판매금액, 일시, 지불방법)가 조합되어야만 쓸모 있는 정보이다. 이렇듯 다양한 개체간 상관관계 혹은 연결(link)을 정의하는 것이 관계 설정이다. 일 대 일, 일 대 다, 다 대 다 등의 관계가 있으며 비즈니스 규칙을 표현하는데 있어 중요한 역할을 수행한다. 다이어그램 상에서는 점선 혹은 실선으로 표기한다.

<그림3> 데이터베이스의 3대 구성요소

 

 

데이터베이스 모델링 절차

 

● 업무 흐름(Business Workflow) 파악

당연한 이야기일지 모르지만, 모델링에 앞서 사용자의 요구사항을 문서화하는 작업이 선행되어야 한다. 현실 업무에 대한 지침서(manual)가 있다면 다행이지만 참고할만한 문서가 없거나, 업무 흐름을 새롭게 정리해야할 경우도 있다. 일정에 쫓기고, 번거롭다고 해서 간단한 대화만으로 업무 파악을 끝내는 경우가 비일비재하지만 정확한 용어로 업무 흐름을 세심하게 문서화하길 바란다. 의뢰인으로부터 업무 흐름에 대해 설명을 들어가면서 정리하는 내용이 바로 모델링을 위한 재료가 된다. 그 중에서 다양한 정보가 발생하고 관리해야 하는 명사는 개체와 속성이 되고 각 개체를 묘사하는 형용사는 속성이 된다. 각각의 개체가 어떻게 조합되는지 설명하는 동사 혹은 문장은 관계가 된다. 업무 흐름을 상세히 정리할수록 모델링 및 설계 단계가 편해지기 마련이다. 귀찮다고 건너뛰지 말자. 개발자들이 사용자와 마주하는 업무로 인해 많은 스트레스를 받지만, 피하면 모델링 단계에서부터 일이 지연되는 경우가 많다.

● 개체(entity) 추출

개체란 시스템의 관리 대상으로 사람, 물건 등의 실체나 개념을 의미한다. 구축 대상 업무에서 무엇을 개체로 파악해야 하는가에 대한 정답이나 절대적인 공식은 존재하지 않는다. 하지만, 대략적인 선정 기준을 제시할 수는 있다. 업무명세 중에서 명사는 개체가 될 수 있는 후보가 되며, 그 가운데서 장기간 보존해야 하거나, 시스템이 종료한 후에도 지워져 서는 안 되는 정보를 추출한다. 예를 들면 다음과 같다.

- 사람(고객, 직원)이나 조직 체계 (회사, 부서, 대리점)
- 물품 혹은 서류(재고 상품, 문서, 부품), 각종 설비 (건물, 운송수단)
- 각종 개념 (주문 및 거래 기록, 통화 내역, 배송 정보, 은행계좌)위에 나열한 명사들을 살펴보면 현실세계에서 존재하는 대상은 손쉽게 파악할 수 있다. 실물로 존재하는 대상을 찾는 것은 그리 어렵지 않다. 하지만, 관리할 대상 중 개념적으로 존재하는 것을 개체로 선정하지 못하고 자칫 지나치는 경우가 있다. 이러한 불상사를 막기 위해서는 업무흐름(workflow) 혹은 활동을 그려보고 각 단계에서 새롭게 발생하거나, 변화하는 자료가 없는지 점검해 봐야한다. 종이와 펜을 놓고 대략적인 플로우 차트를 그려가면서 입출력되는 정보가 있는지 점검해보는 것도 좋다. 입출력되는 정보 중 보존해야할 정보가 없는지 살펴보기 바란다. 쇼핑몰 구축을 예로 들면 상품에 대한 주문과 발송, 배송 정보
가 발생했을 때, 거래 시점에만 사용한다면 상관없지만, 거래 종료 이후에도 해당 정보를 조회하려 한다면 개체로 선정되어야 한다. 데이터 모델링을 수행함에 있어 시스템 구축을 위한 기술적인 지식보다는 고객이 원하는 바가 무엇인가, 무엇을 관리해야 하는가, 현실 세계의 업무가 어떻게 흘러가는가에 대한 이해가 더욱 중요하다. 개체를 추출하는 작업은 기록 가능한 모든 것을 찾아내는 것이 아니라, 기록할 필요가 있는 것을 찾는 것이기 때문이다.

 

● 개체간의 관계 설정

데이터베이스는 자료를 저장하기 위한 시스템으로 설명할 수 있지만, 그보다 중요한 것은 가치 있는 정보를 어떻게 효율적으로 정확히 조회할 수 있는가 하는 점이다. 다수의 개체가 어떻게 연결되며, 각 개체들은 어떤 관계를 가지고 있는가를 정의하는 작업을 통해 효율적인 검색 조회를 위한 기초가 다져진다. 개체를 추출한 후에는 개체 간 의존 관계(부모 자식 관계)를 파악한다. 또한, 개체간 관계를 분석하다보면 새로운 개체가 나타나기도 한다. 부서와 팀원이라는 두 개의 개체를 추출했다고 가정해보자. 목표 시스템이 인사관리 시스템이라면, 각 팀원은 특정 부서에 속한다는 관계를 파악할 수 있으며, 이러한 관계를 표현하기 위해 나타내는 소속이라는 개체(혹은 개념)를 추가해야 한다.

 

● 주요 키(primary key)와 속성(attribute) 파악 및 제약 설정

데이터베이스 시스템에서는 둘 이상의 개체를 조합하여 정보를 추출하는 경우가 많다. 또한 각 개체에 포함된 정보를 정확하게 검색할 수 있도록 개체에 포함된 데이터를 유일하게 구분할수 있는 정보(주요 키)를 설정해야 한다. 그리고 각 속성 크기와 자료 유형을 결정하며, 속성에 빈 값이 들어가서는 안 되는 식의 제약 사항을 지정한다.

 

● 상향식 분석을 통한 재구성

하향식 분석을 통해 구축 대상 개체, 관계, 속성 등을 파악한 후 사용자에게 나타나는 화면, 통계 보고 등을 확인하고 누락된 항목은 없는지 다시금 모델을 검토하는 작업을 수행해야 한다. 상향식 분석 과정에서는 새로운 개체를 추출하기 보다는 속성을 추가하고, 관계를 더욱 명확히 파악하는 데 중점을 둬야 한다. 이번 호에서는 데이터베이스 모델링 절차의 개괄적인 흐름을 설명했다. 아직 구체적인 사례를 들지 않아 뜬구름 잡는 느낌이겠으나 이론이 뒷받침되지 못한 채 실전 작업에 투입되면 복잡한 시스템 설계 시 난관에 부딪치기 십상이다. 일단 개념, 용어, 그리고 절차에 익숙해지길 바란다. 다음 호에는 이론을 실무와 적용하는 사례를 소개하고, 최종적으로 물리적 DB 설계시 꼭 알아야 두어야할 기법들을 소개한다.

 

 

정리｜문경수 objectfinder@imaso.co.kr

 

필자 메모
데이터베이스의 개념을 처음 접하고, 모델링을 배우고 실습하다 보면 자연스럽게 어떤 데이터를 관리할 것인가에 집중하게 된다. 데이터의 관계나 속성을 추출할 때도 실 세계에 존재하는 자료 항목들을 빠짐없이 추출했는가에 관심을 쏟게 된다. 자료를 쌓는데 집중하는 것이다. 이런 태도가 항상 옳은가? 절반은 맞고 절반은 틀리다. 데이터베이스의 우선적인 목표는 자료를 모으는 것이기 때문이다. 하지만, 쌓기만 하면 자료로써 얼마나 가치가 있는가? 원하는 자료를 손쉽게 검색할 수 없다면, 아무리 많은 자료를 모은다고 한들 소용없다. 제대로 된 모델링이란 자료를 손쉽게 찾을 수 있는가? 라는 질문에 그렇다고 답할 수 있어야 한다. 구축된 데이터를 활용하는 다양한 방법이나 목적(통계, 실시간 조회, 변화 추이 분석)에 적합하지 않은 모델링은 필연코 실패할 수밖에 없다. 모델링 단계를 충분히 수행하고도 실패하는 프로젝트는 모델링 단계에서 자료의‘활용’방법(목적)을 예측하지 못했기 때문이다. 모델링 실습 단계에서 이 문제를 하나하나 살펴보기로 하자.

 

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