22. 데이터 베이스 구축 과정
DB 구축 단계와 개발과의 관계
데이터 베이스가 엑셀의 표와 비슷한 테이블로 이루어져 있다는 것을 알았다. 특히 관계형 데이터 베이스는 데이터 중복을 최소화하기 위해 테이블을 가능하면 분리하고, 분리된 테이블은 동일한 키 필드로 관계를 맺어 필요한 데이터가 연결될 수 있도록 했다.
데이터 베이스를 구축하는 과정은 궁극적으로 테이블을 만드는 과정이라 할 수 있다. 프로그램 개발자가 현실의 일처리를 코딩해서 컴퓨터가 일하게 하듯, 데이터 베이스는 현실의 일에서 발생하는 데이터를 DB가 관리할 수 있도록 테이블과 그 테이블 간에 관계를 만드는 것이다.
데이터 베이스 구축과정
데이터 베이스 구축과정은 현실의 일에 관련된 데이터를 DB에 담은 과정이다. 그렇게 하기 위해서 일을 분석하고 데이터 관리에 적합하도록 모델링하여야 한다. 데이터 구축과정은 [데이터 설계]라는 모델링 과정과 모델링한 데이터 구조를 실제 DBMS라는 SW에 테이블과 같은 물리적으로 만드는 구축하는 [데이터 베이스 구축]의 크게 두 단계로 진행된다.
데이터 베이스 구축 과정DA(데이터 아키텍터)는 시스템을 구축하려는 업무에서 필요한 데이터와 사용자의 요구사항을 분석한다. 업무를 분석하기 위해 업무처리에 사용되는 문서, 프로세스, 인터뷰 등을 통해 어떤 데이터가 중요하고 데이터가 전체 업무 과정에 어떻게 흘러 다니는지를 파악하여야 한다. 또한 사용자 수와 거래 처리 건수 등을 파악해서 데이터의 양, 처리 속도 등에 대한 정보도 파악하여야 한다. 이러한 분석과정을 통해 DA는 데이터 베이스 설계를 시작한다.
｜데이터 베이스 설계의 필요성 ｜
데이터 베이스 설계과정은 현실의 일을 시스템에 필요한 데이터 베이스로 만들기 위해 한 단계씩 접근하는 과정이다. 동창회 관리 같은 간단한 시스템이면 굳이 분석과 모델링을 거치지 않더라도 바로 테이블을 만들 수 있다.
그러나 쿠팡과 같은 온라인 쇼핑몰을 만든다고 생각하면 이야기가 달라진다. 그 많은 쇼핑 몰의 상품 데이터를 관리할 수 있어야 하고, 초당 몇 천 건 이상 상품 데이터가 1초 안에 조회되어야 하고, 또 구매 데이터가 빠짐없이 기록되어야 한다. 테이블 몇 개로는 이런 대형 시스템을 커버하기는 불가능하다.
데이터 베이스는 첫 번째로 시스템의 업무처리와 같은 거래가 문제없도록 구성되어야 한다. 거래에 필요한 데이터는 빠짐없어야 한다. 또한 빠른 처리가 가능하도록 성능이 보장되도록 데이터 베이스가 만들어져야 한다. 상품 데이터를 조회하는데 몇 초씩 걸린다면 DB설계에 문제가 있을 수 있다.
두 번째는 거래 또는 업무처리의 결과 데이터를 잘 활용할 수 있도록 구성되어야 한다. 온라인 거래 처리는 문제가 없지만, 데이터가 지저분하거나 데이터가 서로 맞지 않으면 실적과 같은 데이터를 만들 수 없다. 그래서 데이터를 어떻게 활용할 것인지 처음부터 분석하여 그런 요구사항을 담아서 설계가 되어야 한다.
대형 시스템인 경우에는 데이터 베에스 설계 과정을 거쳐 데이터 베이스를 구축한다. 그러나 작은 시스템이라든지 비용을 절약하기 위해 데이터 베이스 전문가가 아닌 개발자에 의해 주먹구구식으로 DB를 만드는 경우가 많다. 개발자가 DB에 대해 지식이 좋아 문제가 없으면 다행이다.
하지만 그렇지 않은 경우가 많다. 초기에는 데이터가 적어 문제가 안되던 시스템이 데이터가 많아지면서 현저히 속도가 느려지거나, 데이터가 제대로 맞지 않아 데이터를 활용할 수 없어 곤욕을 치른다. 그래서 다시 DB를 재구축하는 경우가 흔하다. 시스템에서 DB가 변경된다면 모든 것이 프로그램이 변경되어야 하는 것이나 다름없다. 관련 프로그램을 일일이 다 찾아 고쳐야 한다. 따라서 초기 DB구축이 제대로 안되어 재구축한다면 더 많은 비용이 발생할 수 있다.
따라서 시간이 들더라도 데이터 베이스 설계과정이라는 방법론에 따라 데이터 베이스를 구축하는 것이 필요하다. DB구축 방법론뿐만 아니라 업무에 대한 인더스트리 지식(이를 IT에서는 '도메인' 지식이라 한다.)을 갖춘 경험 많은 DA, DBA가 필요하다. 처음부터 잘 밟아도 모든 것을 만족하는 DB를 구축하는 일을 결코 쉽지 않은 매우 어려운 작업이다.
｜데이터 베이스 설계｜
데이터 베이스 설계 과정에 대한 깊은 내용을 여기서 다 다룰 수 없다. 이런 것이 데이터 베이스 모델링이구나, 이러한 과정을 거쳐서 시스템에서 필요한 데이터 베이스를 설계하는구나 하는 정도로 이해하도록 하자.
개념적 설계(Conceptual Design)
업무 분석과 요구사항 결과를 기반으로 데이터 베이스를 구성하는데 필요한 개체, 속성, 개체 간의 관계를 추출하는 단계이다.(뭔 말인지 모르겠어요ㅠㅠ)
개체(영어로 엔티티 Entity)라는 것은 쉽게 말하면 일에서 명사로 표현되는 덩어리라고 보면 된다. 온라인 쇼핑 몰을 생각하자. 온라인 쇼핑 몰을 구성하는 것에는 어떤 개체가 있을까? 그렇다. 상품이 떠 오를 것이다. 또 상품을 구매하는 고객이 있을 것이다. 고객은 상품을 주문해서 구매하므로 주문이라는 개체도 있다. 이러한 덩어리(적절한 비유인지 모르겠어나?), 즉 개체를 먼저 도출한다.
속성(영어로 어트리뷰트 Attribute)은 개체가 가진 내용이다. 예를 들어 고객 엔티티는 '이름', '아이디', '전화번호'와 같은 속성이 있고, 주문 엔티티에는 '주문번호', '주문상품', '주문고객', '주문일자' 등과 같은 속성을 뽑아낼 수 있다.
개체 즉 엔티티는 속성을 가지고 있으며, 이들 엔티티 간에는 관계를 가진다. 즉 고객은 상품을 주문한다. 이 말은 고객 엔티티와 상품 엔티티는 주문이라는 엔티티로 서로 관계를 맺게 된다는 것이다.
이렇게 엔티티와 엔티티 간의 관계를 추출하는 것이 개념적 설계 단계이다. 엔티티와의 관계를 그림으로 나타 낸 것을 ERD(Entity Relation Diagram)이라 한다. ERD는 엔티티와 엔티티의 관계를 나타내는 다양한 약속된 기호로 표시된 그림이다.(보통 전문적인 ERD 작성 도구를 사용한다.)
개념 설계 ERD 예시논리적 설계(Logical Design)
개념적 설계가 전체 데이터에 대한 스케치라면 논리적 설계 단계에서는 스케치한 것을 더 구체화된 업무 중심의 데이터 모델을 만드는 단계이다. 개체와 개체 간의 관계를 명확하게 하고, 데이터 중복이 발생하는 개체는 분리하여 신뢰성 있는 데이터 구조를 만든다.
추상적인 개념 ERD를 더 구체적인 데이터로 작성한다. 각 데이터 간의 관계를 정밀하게 상호 관련 키를 구체적으로 지정한다.
예를 들어 [학생] 개체와 [과목별 성적] 개체의 관계를 정의하기 위해 [학생] 개체의 키가 되는 <학번> 필드를 [과목별 성적] 개체의 <학번> 필드 서로 관련 필드(FK, Foregin Key)로 만들어 관계를 맺어 준다.
물리적 설계(Physical Design)
데이터 베이스를 만들 수 있도록 테이블 이름(영문), 테이블의 필드 이름(영문), 필드 속성(문자, 숫자-정수/실수 등, 날짜 등)을 정한다. 또 테이블의 인덱스와 같은 필요한 DB 요소를 설계한다. 책 본문을 빨리 찾기 위해 책 끝에 인덱스를 만드는 것과 마찬가지로 테이블에서 데이터를 빨리 찾기 위해 특정 칼럼에 대해 인덱스를 생성할 수 있다.
｜테이블 인덱스(Index)｜
인덱스(Index)는 데이터베이스의 테이블에 대한 검색 속도를 향상하는 자료구조이다. 테이블의 특정 컬럼(Column)에 인덱스를 생성하면, 해당 컬럼의 데이터를 정렬한 후 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장된다.(자료:위키)
｜데이터 베이스 구축｜
DA에 의해 데이터 베이스 설계가 완료되면 구체적인 테이블과 테이블의 필드가 정해진 ERD가 완성된다. 완성된 ERD로 각 테이블의 명세서를 작성하고, 테이블의 명세서를 가지고 DBA는 실제 DB에서 물리적인 테이블, 인덱스를 만든다. 이제 DBMS에 시스템에 필요한 데이터 베이스가 만들어졌다.
테이블 명세서DB에 테이블이 만들어지면 개발자들은 본격적인 개발을 할 수 있다. 테이블의 필드에 데이터를 넣는 프로그램을 작성하거나 필요한 테이블을 연결하여 데이터를 추출하는 코딩을 할 것이다. 개발자들이 개발 내내 두고 있는 문서 중의 하나가 테이블 명세서이다. 테이블 명세서에는 테이블의 컬럼명과 데이터 타입 등의 테이블 속성이 있어 개발자들은 코딩을 하기 위해 항상 봐야 하는 문서이다. 당연히 컬럼명이 틀린다던지 컬럼의 데이터 타입이 다르면 오류가 발생한다.
개발과 데이터 베이스
시스템을 구축하려면 프로그램을 개발하는 개발자와 데이터 베이스를 만들고 관리하는 DA, DBA와의 협력은 필수적이다. DB 쪽에서 테이블이 만들어지지 않으면 개발자는 크게 개발할 것이 없다. 또한 개발 중이라도 필요한 데이터가 있거나 샘플 테이터에 대한 도움을 보으려면 DA나 DBA의 협조가 필요하다.
개발과 데이터 베이스 협업 관계앞서 말했듯 시스템에서 가장 바꾸기 어려운 것이 DB다. 테이블의 컬럼명이 하나 바뀌거나(예를 들어 주문번호 컬럼 명을 order_no에서 jumun_no로 변경) 데이터 타입이 변경되면 관련 코딩을 다시 바꾸어야 한다. 모든 개발자가 나눠준 테이블 명세서 기준으로 코딩을 하고 있다. 많은 개발자이 만들어 내는 코딩은 엄청나지만 개발자들이 사용하는 DB는 하나이다. 따라서 DB변경은 개발 지연의 주원인이 되기도 한다.
DB가 바뀌면 안 되지만 어디 세상일이 그렇게 되나?(그래서 이런 것을 분석하는 도구도 있다. 테이블 컬럼명이 바뀌면 해당 테이블을 사용하는 코딩을 다 찾아 준다. 그래서 바꾸어야 하는 코드를 빨리 파악할 수 있다. 그런데도 빠뜨리는 경우가 꼭 있어 예상치 못한 오류가 나서 당황하게 한다.) 갑자기 테이블이 바뀌면 개발자와 DA/DBA사이의 한랭전선이 발생하기도 한다.
체계적이고 보완된 내용으로 브런치 글과 같은 이름으로 출간을 하게되었습니다. 아래의 링크를 통해 자세한 내용을 확인할 수 있습니다.
교보문고
나에게 맞는 IT 직업 찾기
예스24
나에게 맞는 IT 직업 찾기
알라딘
나에게 맞는 IT 직업 찾기
데이터 베이스와 그 구축과정을 간단하게 설명하려니 매우 힘들었다. 방대한 내용을 쉽게 또 짧게 하려니 만만치 않다. 전문가가 보기에는 약간 이상한 부분이 있을 수 있다. 그러나 이해해 주길 바란다. 가능하면 어려운 용어를 안 쓰려고 했다. 용어하나가 튀어나오면 또 설명해야 하고, 설명하려면 또 상당한 지면을 할애해야 한다. 지면을 할애하는 것이 문제가 아니라, 내용이 어려워진다는데 있다. 부족하다면 DB에 대해 더 많은 자료를 참조하기 바란다.
데이터 베이스 구축은 개발과 마찬가지로 시스템 구축에 있어 또 다른 영역이며, 또 다른 중요한 부분이다. 데이터 전문가와 개발자는 일의 성격과 자격, 기술에 있어 확연히 구별된다. 다음 글에서는 DA와 DBA에 자격과 기술에 대해 상세하게 살펴볼 것이다.
