웹기획 이해하기 - 강좌11, 웹기획자가 알아야될 관계형데이터베이스

웹기획 이해하기 - 강좌11, 웹기획자가 알아야될 관계형데이터베이스

# RDBMS의 탄생

데이터베이스 내에 저장된 자료들의 접근방법과 관리방안에 대해 많은 연구들이 과거에 진행되었으며 IBM에서 1968년에 개발한 IMS(Information Management System) , Cullinet Software가 1970년도에 발표한 IDMS 등이 존재 하였다. 관계형데이터모델의 개념이 나오기 이전 이와 같은 데이터베이스 관리 시스템들은 서로 다른 종류의 레코드 들을 한 계층 구조 내에 연결하는 계층 데이터 모델(hierarchical data model)이라고 할 수 있다.
예를 들면, 은행 데이터베이스는 본사의 주소 및 전화번호 등의 정보를 갖는 본사 개체 레코드를 최상위에 위치하고 그 아래는 금전 출납 계원들과 직원들에 관한 레코드를 위치 시킨다. 그래서 특정 금전 출납 계원에 대한 정보를 처리하기 위해서 프로그램은 계층적 층을 통해 아래로 운행이 되는 형식이다.
또한 IDMS 제품은 Industry Database Task Group의 1971 CODASYL 보고서의 결과로 제시되었는데, 한계층 내에 있는 레코드들의 집합이 상위계층에 존재하는 두개의 서로다른 공유계층을 가질 수 있도록 하는 계층적 모델을 일반화 시킨 ‘네트워크 데이터 모델’이 생겨났다.
이러한 제품들의 문제점은 전문프로그래머 측면의 복잡한 데이터 운행구조를 요구하기 때문에 데이터 검색을 위한 질의어들을 구성하기가 매우 어렵다.
- O’NEIL DATABASE-Principles, Programming, Performance 참조

위와 같은 이유로 관계형데이터모델을 기초로한 관계형데이터베이스 시스템 (RDBMS) 가 생겨났으며 현실세계(Real world)의 복잡한 정보구조를 개체와 개체의 관계로 표현함으로써 자료집합간의 결합, 분할이 자유롭게 가능하며 새로운 레코드의 추가 또한 쉽도록 되어 있어 사용자와 개발자간의 의사소통을 원활하게 하는 구조적인 단순함이 가장 큰 장점이라 할수 있다.

관계형데이터베이스에서는 데이터모델링이 굉장히 중요하다. 그래서 전문적으로 데이터모델링만을 다루는 사람이 필요하나 현실적으로 중,소규모의 프로젝트에서는 참여하는 경우가 적고, 엔지니어출신 PM이 모델링하는 경우가 많다. 모델링이 어떻게 되느냐에 따라 퍼포먼스의 차이는 굉장히 크다 할 수 있다. 또 어떤 프로젝트에서는 개발자가 전문적인 지식없이 모델링 하는 경우도 많이 보아왔다. 물론 처음에는 문제가 되지 않겠지만 사이트의 장기적인 안목을 볼 때 너무 위험한 행동이며 나중에 데이터베이스부터 다 뜯어 고쳐야 되는 대형 수술을 하게 되는 경우가 많다. 일반적으로 데이터모델링과 데이터베이스설계는 나누어져야 하나 보통은 머리속에서 생각나는데로 바로 설계작업에 들어가는 경우가 많아서 제대로 정규화 되지 못하고 엉성하게 모델링 되어버리는 경우가 많으므로 사내 데이터베이스 관리자나 엔지니어출신 PM은 반드시 데이터모델링에 대한 개념을 확실히 인지하고 있어야 한다.

# 관계형 데이터 모델은 무엇인가?

<그림 1>

위 그림을 보면 관계형 데이터 모델을 쉽게 이해할 수 있을 것이다. 회원이라는 개체와 강좌라는 개체 사이에는 수강이라는 관계를 갖고 있다. 회원정보 안에는 ‘주민번호’,’성명’,’주소’,’전화번호’ 등등이 있겠고 강좌에는 ‘영어강좌’,’일어강좌’,’중어강좌’ 와 같은 경우가 들어갈 수 있다. 그러면 회원은 ‘영어강좌’를 수강할 수도 있고 나머지 강좌도 ‘수강’할수 있는데 이 ‘수강’ 개체에는 회원이 강좌를 신청하고 수강한 정보들 예를들면 언제 어떤강좌를 들어서 진도는 어느 정도이고 결과는 어떤지 알 수 있는 정보가 들어가게 되는 것이다. 그러면 내부를 들여다 보도록 하자.

<그림2>

사실 속성(주민번호,성명 등등과 같은 것들)은 업무에 따라 지금보다 훨씬 많이 추가 될 것이다. 그리고 관계도 더 복잡해진다. 위의 그림은 간단하게 예를 들었으며 전공자가 아니더라도 쉽게 이해할 수 있는 구조로 되어 있다. 이것이 관계형데이터베이스의 장점이다.

위와 같은 구조에서 알 수 있는 것. 예를 들어보자. 그리고 위의 그림을 눈으로 따라가며 보도록 하자

- 영어강좌를 수료한 명단.
- 영어강좌를 수료하고 점수가 80점 이상인 사람의 명단
- 진도가 50% 이상인 사람의 이름과 주민등록번호
- 성별이 남자인 사람과 여자인 사람의 점수비교

또한 위의 속성에는 나와 있지 않지만 더 추가한다면 아래와 같은 것도 가능하다.

- 지금 수강중인 사람 중 나이대별 진도율 현황
- 영어강좌를 수강한 사람의 수료 비율
- 강좌 개설 대비 수료율

등등.. 무수히 많은 현실세계에서 가능한 모든 것을 분석해 낼 수 있다.

이와 같은 개체(entity)들이 무수히 존재하고 그들간에 관계(relation entity)를 형성해 놓음으로써 Real-world의 관계를 나타낼 수 있다. 이것을 관계형데이터모델 이라 하고 이 모델을 가지고 데이터베이스를 구체적으로 설계하게 된다. 그리고 하나 이상의 데이터베이스를 관리할 수 있는 시스템을 바로 관계형데이터베이스시스템, RDBMS 혹은 DBMS 라고 말한다.

그래서 프로젝트시작 전에는 이러한 개체와 개체의 관계도를 가지고 있어야 한다. 그것을 ER-다이어그램(D)이라고 한다. 물론 개발자에게는 필수적인 문서이다. 또한 기획자도 ER-D를 보고 어떤서비스를 제공할지 고민할 수 있는 수준이 되면 금상첨화라 할 수 있겠다. 지금 개발자난 데이터베이스를 담당하시는 분들에게 요청하자 ER-D좀 보여 달라고!! (없으면 만들어 달라고 하자)

# 우리 DB는 정규화 과정을 거친 것일까?

이러한 관계형 모델링은 일반적으로 지켜야 할 규칙이 있다. 그것을 정규화라고 이야기 하는데 일반적으로 제1정규화, 제2정규화, 제3정규화, 제4정규화 과정을 거치는 것이 RDB를 제대로 구성되게 해주기 때문에 되도록이면 반드시 적용을 해야 한다. 단. 속도를 증가시키기 위해 정규화된 테이블을 비정규화 하는 때도 간혹 있으나 많지는 않다. 또 어떤 이는 일부로 비정규화 했다 말하기도 하는데 정규화 과정을 거친 후에 비정규화를 고려해야지 처음부터 비정규화라는 개념으로 접근해서는 안 된다. 아래는 제1정규화부터 제4정규화까지 간략하게 소개한다.(웹기획자도 정확히 알아둘 필요가 있다.)

제1정규화(1NF)
: 여러 값을 가진 칼럼이 존재할 수 없다.

맨 끝의 칼럼 ‘관심분야’를 보자 물론이 관심분야를 처리하는 방법은 여러가지가 있다 코드화해서 코드를 컴마(,)로 구분하여 넣을 수도 있지만 우선 그건 생각하지 말고 정규화만 생각한다면 홍길동 레코드와 같이 관심분야가 두 개 이상 있으면 안 된다. 이 이야기는 ‘관심분야라는 것이 두 개 이상 되면 안 된다!’ 라는 것이 아니라 두개 이상 같기 위해서는 이와 같은 구조로 하면 안된다는 것을 의미한다.

제2정규화(2NF)
: Key가 아닌 칼럼은 기본 키 전체에 의존적이어야 한다.

그림2의 회원 테이블을 보자, 주민번호를 기본키(PK, Primary Key)로 잡는다면 그 키로 모든 레코드를 구분 할 수 있어야 한다는 것이다. PK는 하나 이상의 칼럼에 중복적으로 잡을 수도 있다. 그렇다면 그 PK에 나머지가 의존적이어야 한다는 의미이다.

사실 많은 기업의 시스템중에는 PK가 제대로 잡혀져 있지 않은 곳을 발견할 수 있다. 데이터베이스 설계의 기초임에도 되어 있지 않아 궁극적으로 퍼포먼스 및 유지보수에 어려움을 준다.

제3정규화(3NF)
:키가 아닌 칼럼은 다른키가 아닌 칼럼에 의존적이면 안된다.

그림2의 회원테이블에서 키(PK)를 주민번호로 잡는다고 생각하면, 키가 아닌 ‘주소’ 칼럼은 ‘성명’ 칼럼에 의존적이어서는 안 된다. ‘성명’이라는 칼럼이 주소를 구분할 수 있어서는 안된다는 의미이다. ‘성명’은 얼마든지 중복되어 동명2인 3인 될수 있으므로 구분할 수 없다. 또는 구분할 수 있다 하더라도 구분되도록 하지 않게 키를 잡아야 된다는 말이다.

제4정규화(4NF)
: 제3정규화(3NF)된 테이블은 의존적인 다 대 다 관계를 가질 수 없다.

그림2의 ‘회원’ 테이블과 ‘강좌’테이블을 비교해 보자 한명의 회원은 여러강좌를 들을 수 있고 하나의 강좌는 여러 회원을 듣도록 할 수 있다. 그러므로 회원테이블과 강좌테이블은 ‘다 대 다’ 관계인 것이다. 이와 같은 경우 Relation table인 ‘수강’테이블을 만들어 주면 제4정규화가 된 것이다.

* 용어 설명
레코드: 엑셀에서 행, 실제 데이터 행 하나.
칼럼: 주민번호,주소,전화번호 와 같은 열, 속성
PK(Primary Key, 기본키) : 모든 레코드를 구별해 낼 수 있는 다른 칼럼에 의존할수 있는 유일한 키, 물론 여러 개의 칼럼을 묶어서 PK로 잡을 수 있다. 모든 테이블에는 당연히 잡여야 하면 PK를 잡으면 클러스터 색인이 자동으로 된다.(속도가 빨라진단 말임)

우선 이번 강좌엔 여기까지 이야기를 마무리 하려고 한다. 데이터베이스에 대해 이야기 하자면 지금까지 한 강좌 만큼이나 할 이야기가 많다. 사실 그렇게 재미있지 않은 내용이고 약간 길어진 감이 있어서 블로그 안부게시판에 누가 뭐라 할지 모르겠다.

웹사이트를 설계하고 운영함에 있어 데이터베이스 만큼 중요한 것도 없을 것이다. 프로그램에서 퍼포먼스를 높이기 위해서 10시간 노력한다면 데이터베이스에 1시간 투자해 튜닝하는 것이 훨씬 낳다라고 필자는 생각한다. 지금 우리가 사용하고 있는 데이터베이스는 관계형 데이터베이스 이다. 그러므로 데이터모델링은 정규화과정을 거쳐 정말 잘해야 하며, 잘