데이터베이스 이론 – 모델링 #.1

 

데이터베이스란?

그동안 각 DB가 가지는 기술적인 부분들에 집중하느라 기초적인 부분들을 많이 잊고 지냈습니다. 처음으로 돌아가는 마음으로 데이터베이스에 대한 기초적인 내용들을 정리 해보려 합니다. RDBMS에 대한 이론에 대해서 말이죠.

데이터베이스의 목적은 사람들이 필요로 하는 어떤것들을 추적하는 것을 도와주는데 있습니다. 가장 많이 사용하는 데이터베이스 형태는 관계형 데이터베이스(RDBMS)이며 최근에는 비관계형 데이터베이스(NoSQL)들의 활용도 높아지고 있습니다. 쉽게 말하면 업무에 필요한 데이터를 저장하고, 조회하는데 사용하는 것이죠.

RDBMS에는 Oracle, MySQL, PostgreSQL 등이 있으며, RDBMS는 어떤 DB를 사용하더라도 모델링을 하는 방법이나 데이터를 추적하는 방식에 있어서는 대부분 비슷합니다. 약간의 데이터베이스를 다루는 명령어나 각각의 DB가 가지는 특성에 따라 차이는 있습니다. NoSQL의 경우에는 NoSQL이라고 명칭된 각각의 데이터베이스가 모두 모델링 방식도, 저장 방식도, 아키텍처도 모두 다르기 때문에 각각에 DB에 맞는 방식을 공부해야 합니다.

그럼 데이터베이스가 저장하는 데이터는 다음과 같이 정의 할 수 있습니다.

데이터 = 기록된 사실이나 숫자

RDBMS의 특징은 데이터를 테이블에 저장하며, 테이블은 행과 열을 가지고 있습니다. 그리고 데이터베이스는 여러개의 테이블을 가지고 있습니다.

 

관계형 데이터베이스를 사용하는 이유

• 높은 신뢰성이 필요로 하며, 데이터의 무결성을 보장해야 할때
• 트랜잭션 보장이 필요한 경우
• 데이터 구조가 명확할 때, 즉 스키마 변경이 필요로 하지 않을때

RDBMS가 가지는 장점은 데이터의 정렬, 분류, 탐색이 빠르다는 점이 있으며, 정규화된 테이블을 이용해 원하는대로 SQL문을 통해 데이터를 가공할 수 있는 것에 있습니다. 단점으로는 스키마 변경이 어렵고, 수평적인 샤딩이 어려워 부하분산 처리에 있어서 어려움이 있습니다.

1982년 MS Access 출시 이후 가장 많은 회사들이 선택한 방식이 RDBMS를 이용하는 것이기 때문에 그만큼 학습에 대한 자료도 많고 접근하기가 쉽습니다.

반면 최근에 엄청난 발전을 이루고 있는 NoSQL들의 경우 다양한 목적과 다양한 환경의 특수성으로 인해 사용 범위를 넓혀가고 있습니다.

유연한 스키마, 개발친화적인 데이터 관리, 부하분산 및 대용량 처리에 특화된 샤드 기능, 복잡한 Join 연산을 필요로 하는 데이터 등 다양하게 사용합니다.

한때 객체지향 DBMS(ODBMS or OODBMS)라는 데이터베이스도 존재했습니다. ODBMS는 캡슐화된 데이터를 OOP 객체에 쉽게 저장하도록 설계된 데이터베이스입니다. 프로그래밍에 관심이 있으신 분들은 아마 객체지향 프로그래밍이라는 용어를 들어보신적 있을거라고 생각합니다. 바로 그것과 동일합니다. 하지만 ODBMS는 대중화에 실패 하였으며 실패한 이유는 다음과 같습니다. 우선 관계형 데이터를 객체지향 데이터로 변환해야 했는데, 많은 회사들이 여기에 발생하는 비용을 부담하기 싫어했습니다. 그리고 관계형 데이터베이스 보다 딱히 나은점이 없었기 때문에 비용을 들여서 굳이 전환할 필요가 없었던것이죠. 하지만 NoSQL은 환경과 목적에 따라서 극적인 성능 개선 효과나 뛰어난 데이터 처리 성능을 보여주기 때문에 점점 사용 추세가 늘어나고 있습니다.

 

데이터베이스 모델의 정규화

데이터베이스 이론을 공부하다보면 특히 RDBMS를 사용하는데 있어서, 정규화라는 용어를 자주 접하게 됩니다. 이 정규화라는 것은 DB 설계시 중복을 최소화 해서 구조화하는 프로세스를 말합니다. RDBMS의 경우 데이터 모델링을 설계하는데 필수적인 요소이며 성능에 따라 비정규화(반정규화), DW나 데이터마트를 위한 역정규화를 하기도 합니다.

데이터베이스를 설계할 때 반드시 필요한 부분으로 정규화가 되어 있지않는 데이터베이스는 데이터를 처리하는데 있어서 오류를 발생하거나, 데이터의 중복, 데이터베이스 성능 저하등의 문제를 겪을수 있습니다.

데이터베이스 설계가 필요한 상황은 다음과 같습니다.

• 기존의 데이터로부터 설계: 정규화 원칙을 적용하여 설계
• 새로운 시스템 개발: 응용 요구사항을 데이터모델링으로 구현, 개체관계 (ER) 데이터 모델링
• 데이터베이스 재설계: 다수의 데이터베이스 통합, 정규화 원칙과 데이터 모델 변환을 통해 새로운 데이터베이스에 이관

RDBMS의 데이터 모델링을 설계 하는데 있어서는 반드시 필요한 부분입니다.

판독 전용 데이터베이스(DW 또는 데이터마트 등)의 데이터는 운영 데이터베이스에서 추출되어 저장됩니다. 이러한 데이터를 저장할 때  정규화된 데이터를 SQL 질의(Join)를 통해 나온 결과 값을 저장하는 것을 역정규화라고 합니다. 역정규환된 데이터는 코딩의 대한 부담이 줄어들고 조인과 부속질의를 수행할 필요가 없다는 장점이 있습니다.

데이터 정규화는 다음과 같은 장단점을 가집니다.

• 장점: 수정이상 제거, 데이터중복 감소, 데이터 무결성 문제 제거, 파일 공간 절약
• 단점: 다중 테이블 부속질의와 조인에 보다 복잡한 SQL이 요구됨, DBMS의 추가작업으로 인해 응용의 속도가 저하될 수 있음.

바로 비정규화는 이런 단점을 극복하고자 너무 많은 정규화를 통한 성능저하를 방지하고자 하는 것입니다.

정규화를 하기 위해서는 우선적으로 꼭 알아둬야 할 것들이 있습니다.

 

함수종속

일반적으로 함수 종속은 하나 이상의 속성이 다른 속성 값을 결정할 때 존재합니다. 예를 들면 테이블에 수량과 가격을 나타내는 컬럼이 있고, 합계값이 있는 컬럼이 있다면 합계는 수량과 가격의 값에 따라 결정됩니다. 이렇게 특정 컬럼에 의해 결정되는 다른 컬럼이 있는 것을 함수 종속의 예로 볼 수 있습니다.

 

키(Key)

일반적으로 키(key)란 한 릴레이션에서 특정 행을 식별하기 위해 사용되는 하나 이상의 열의 조합을 의미합니다. 두 개 이상의 열로 구성된 키를 복합키라고 합니다.

• 후보키(candidate key) : 주어진 릴레이션에서 다른 모든 열들을 결정하는 결정자
• 기본키(primary key) : 후보키중 하나가 선택되어 pk가 된다.
• 대리키(surrogate key) : 기본키로 사용하기 위해 테이블에 추가된 인위적인 열. 복잡한 키를 대신에 의미 업는 키를 할당. 시퀀스 넘버 등.
• 외래키(foreign key) : 테이블들의 행들 간의 관계를 표현

 

수정이상

정규화를 이해하기 위한 수정이상은 다음과 같이 몇가지로 정의됩니다.

• 삭제이상: 특정 키를 지웠을때 다른 데이터가 같이 삭제
• 삽입이상: 데이터를 입력할때 입력하는 부서에서는 모르는 데이터가 있는 경우 입력 불가
• 갱신이상: 같은 후보키가 다른 두가지 데이터를 가지는 경우

대부분의 수정이상은 함수종속의 문제로 발생합니다.

 

릴레이션

릴레이션은 업무에서 대화할 때는 대부분 테이블이라고 말하는 편입니다. 릴레이션은 어떻게 보면 학술적 용어이고, 테이블은 실무 용어라고 볼수도 있겠네요. 릴레이션의 열은 속성(attribute) 행은 튜플(tuple)이라고 하지만, 대부분의 실무자들은 학술적 용어 대신 행(row)과 열(column)을 사용합니다. 하지만 실제로 릴레이션 = 테이블은 아닙니다.

릴레이션은 정확히는 정규화된 테이블의 특수한 경우를 말하며, 이 것은 모든 릴레이션은 테이블이지만, 모든 테이블이 릴레이션은 아님의 의미합니다. 릴레이션이 가지는 특성은 다음과 같습니다.

• 행은 개체에 대한 데이터를 포함
• 열은 개체의 속성에 대한 데이터를 포함
• 한 열의 모든 항목은 동일한 종류임
• 각 열은 유일한 이름을 가짐
• 테이블의 셀은 단일값을 포함
• 열의 순서는 중요하지 않음
• 행의 순서는 중요하지 않음
• 어떤 두개의 행도 동일하지 않음

이런 조건을 가진 테이블을 릴레이션이라고 하는데, 실제 업무에 있어 정규화는 필수이고, 정규화된 테이블들은 이런 특성을 가지고 있기 때문에 그냥 현업에서는 테이블이라고 부릅니다. 위의 조건을 충족했다고 해서 모든 릴레이션이 동등하지 않습니다. 일부는 용이하게 처리할 수 있지만, 어떤 릴레이션은 문제를 일으키기도 합니다. 그들이 가지고 있는 문제의 유형에 따라 정규형으로 분류합니다.

 

정규형

• 1차 정규형 (1NF) : 릴레이션의 특성을 모두 만족시키는 테이블
• 2차 정규형 (2NF) : 1NF에 속하고 모든 비-키 속성이 기본키 전체에 의해서 결정이 되는 릴레이션
• 3차 정규형 (3NF) : 2NF에 속하고 이행종속이 없는 릴레이션. (2NF에 속하고 다른 비-키 속성에 의해 결정되는 비-키 속성이 존재하지 않는 릴레이션)
  다른 비-키. 속성에 의해 결정되는 비-키 속성을 나타내는 기술용어가 이행종속(transitive dependency)
• 보이스-코드(Boyce-Codd, BCNF) 정규형 : 3NF이고 모든 결정권자가 후보키인 릴레이션

1,2,3차 정규형과 보이스-코드 정규형은 함수종속으로 인해 발생합니다. 함수종속으로 인한 현상은 모든 테이블을 BCNF로 만들어 제거할 수 있습니다. 수정이상으로 인한 문제는 심각함으로 모든 테이블을 BCNF로 만들어야 합니다. 4차, 5차 정규형은 조금 다릅니다.

• 4차 정규형 (4NF) : 다치 종속의 이상현상 제거, 다치 종속은 한 결정자가 특정 값들의 집합과 관련될 때 발생.
• 5차 정규형 (5NF) : 프로젝트-조인 정규형(PJ/NF)라고 하는데, 일반적으로 4NF이면 5NF에 포함되기도 합니다.

4차 정규형은 다치종속으로 발생하는 문제인데, 이러한 경우는 함수종속으로 발생하는 문제보다 심각한 문제를 일으킬수 있기 때문에 반드시 제거할 필요가 있습니다. 다치종속(Multivalued Dependency)이란 하나의 결정자가 특정값들의 집합과 관련될 때 발생합니다.

Mary가 math, physics를 가지고 있고, Sekiro역시 physic와 science를 가지고 있습니다. Student의 값이 하나만 매칭되는 것이 아니라 두 가지 이상 매칭되는 경우 “Student가 Subject를 다치 결정한다.” 라고 말합니다.

 

데이터베이스 설계에서 발생하는 문제들

데이터베이스 모델링을 하다보면 여러가지 문제가 발생합니다.

 

다치, 다중열 문제

• 컬럼수를 늘려서 저장하는 것, 저장가능한 항목수 고정에 대한 문제, SQL 질의시 문제 발생.

만약 전화번호를 저장하는데, 요즘 사용자들이 번호를 여러개를 사용한다면 전화번호를 저장하는 컬럼역시 늘어나야 합니다. tel1, tel2 이런식의 컬럼을 가진다면 물론 관리하기는 편할수 있으나, 다치종속의 문제를 피할수 없고, 만약 같은 컬럼값으로 3개 이상의 데이터를 저장해야 한다면 컬럼을 늘려 테이블을 수정하는것 보다 다른 테이블로 독립시키는게 더 좋은 방법입니다. 테이블에 컬럼을 추가하는 작업은 테이블이 사용중인 경우, 즉 운영중인 데이터베이스에서는 병경하기 어려운 작업입니다. 그렇기에 매번 컬럼을 추가하는 것보다는 설계단계에서 분리하는 편이 좋습니다.

 

모순적인 값

• 사용자 마다 다른 입력 방식, A는 Coffee, Americano 순서로 입력, B는  Americano, Coffee 로 순서를 바꿔 입력
• 철자가 틀린 경우. Coffee와 coffeee

PK와 FK의 경우 모순적인 값으로 인해 관계가 손실됩니다. Group by를 통해 철자의 오류나 모순성을 체크할 수 있습니다.

 

Null 값

• Null 값이 있는 열은 기본키로 할당할 수 없고, IS NULL SQL 문법을 통해 확인이 가능합니다.

Null값을 처리하는 데 있어서 DBMS 마다 조금 다른 사용 방식을 가집니다. 따라서 Null 값을 처리하는데 있어 사용하는 DBMS의 특성을 이해하고 있어야 합니다.

 

범용 설명 열

• 서술형 또는 많은 단어로 표현된 데이터를 가진 열을 말합니다.

상이한 목적들을 식별해서 목적별로 새로운 열을 생성하고 해당 데이터를 추출해 적절한 새 열에 저장해야 합니다.

 

데이터베이스 모델링에 대한 기본인 정규화에 대해 정리해 보았습니다.

연차가 쌓여가면서 여기저기 면접을 보면 DBA에게 모델링에 대한 요구를 하는 업체가 많이 늘었다는 것을 느낍니다. Oracle DBA가 업계 DBA 주류이던 시절에는 모델링은 어디까지나 연차가 높은 DA들의 몫이었습니다. 하지만 오픈소스DB가 추세가 되면서 DBA에게 모델링, 튜너 역할을 요구하는 업체들도 많아졌고, 심지어는 DW, 데이터 마트 관련 업무를 하는 데이터 엔지니어들의 업무도 요구하는 곳도 많네요. 점점 DBA도 만능이 되어야 하는 시대가 오는것 같습니다.

다음 포스팅에서는 E-R 개체-관계형 모델링에 대해 정리해 보겠습니다.