DB와 DBMS

DB와 DBMS에 대해서 알아봅니다. RDBMS의 주요 개념과 NoSQL, DB를 모델링을 하는 원칙을 알아봅니다.
DB, DBMS, NoSQL, 데이터 모델링, RDBMS


DB와 DBMS

DB(Database)는 데이터의 집합을 의미하는 용어입니다. 즉 지난 장에서 TodoList의 데이터를 저장해 둔 파일은 일종의 DB로 볼 수 있습니다. 그리고 이 때 DB의 접근과 관리를 좀 더 추상화한 소프트웨어들을 DBMS(Database Management System)라고 합니다. 지난 장에서 작성한 model 모듈도 일종의 저수준 DBMS라고 할 수는 있겠습니다. 상용 DMBS들이 일반적으로 제공하는 기능은 아래와 같습니다.

DBMS의 기능

특성비고
속도파일을 읽고 쓰는 것보다 빠르게 데이터를 읽고 씀
확장성단순히 단일 파일로 관리되지 않으며, 그 규모를 쉽게 확장 가능
동시성서버로 작동하여 다수의 요청을 안정적으로 처리
관계데이터간의 관계를 정의 가능
무결성데이터의 구조를 엄밀하게 정의하고, 쉽게 변경 가능
정의된 구조에 적합하지 않은 데이터를 방지
데이터의 중복을 방지
데이터 간에 성립할 수 없는 관계를 방지
'A통장에서 100만원 감소, B통장에서 100만원 증가’처럼 이체와 같이 중도에 중지되면 안되는 작업에 대한 보장
질의필요한 데이터를 질의(Query)하는 방식으로 쉽게 추출
보안로그인을 통한 인증 수단과 DB 제어에 대한 권한을 설정 가능

위에서 예로 든 통장 이체와 같이 일련의 작업을 트랜잭션(Transaction)이라고 합니다. DBMS는 트랜잭션이 상호 독립적이며, 트랜잭션의 요소들이 모두 성공하거나(commit), 모두 실패하도록(rollback) 지원하기도 합니다.

DBMS 서버

DBMS는 서버 프로그램DBMS는 서버 프로그램

DBMS는 프로그램에 내장되어 로컬(local)에서 작동 할 수도 있지만 많은 DBMS는 TCP 기반의 서버-클라이언트 구조를 취하고 있습니다. 즉, 일반적인 DBMS는 단일한 서버 프로그램으로 운영이되며, 마치 웹 서버처럼 다수의 클라이언트 프로그램의 요청에 응답하게 됩니다. 이를 통해 데이터를 프로그램에서 분리 할 수 있고, 또 물리적인 확장성을 가질 수 있습니다.

MySQL CLI ClientMySQL CLI Client

이 때 DBMS는 서버 프로그램과 함께 CLI 클라이언트 프로그램을 제공합니다.

MySQL GUI ClientMySQL GUI Client

또 GUI 클라이언트 프로그램을 제공하기도 합니다.

Mysql Client Module for Node.jsMysql Client Module for Node.js

또한 당연히 DBMS의 프로토콜을 따라 TCP 수준에서 직접 클라이언트 프로그램을 개발 할 수도 있겠지만, 응용프로그램에서 DBMS와 통신 할 수 있도록, 각종 플랫폼 별로 클라이언트 모듈을 제공합니다.

RDBMS

Relational ModelRelational Model

DBMS의 대표적인 종류로 RDBMS(Relational DBMS)가 있습니다. RDBMS는 위 그림처럼 데이터의 독립적인 주체들을 각각의 테이블로 표현하고, 테이블간의 관계를 정의함으로써 데이터를 모델링합니다.

RDBMS의 구조

항목설명
데이터베이스
Database
DBMS 서버에는 여러개의 DB가 존재 할 수 있으며, DB별로 인증과 권한을 설정할 수 있음
테이블
Table
하나의 DB는 모델을 추상화한 테이블/모델/스키마를 여러개 갖음

Column
테이블은 여러개의 열/컬럼/속성/필드를 갖고, 각 열은 이름과 데이터 타입 등 여러 옵션을 갖음
주 키
Primary Key
테이블의 각 행을 고유하게 대표하는 열, 값이 고유하지 않으면 거부됨
외래 키
Foreign Key
다른 테이블의 PK를 가리키는 열, 다른 테이블의 존재하지 않는 행을 참조하면 거부됨
색인
Index
특정 열에 대한 색인을 생성하면 데이터 조회시 성능을 향상 시킬 수 있음, PK는 기본적으로 색인을 갖음 (색인과 테이블은 독립적)

Row
테이블은 여러개의 행/로우/레코드/튜플/데이터를 갖고, 각 행은 속성에 맞는 값들의 그룹으로 이루어짐

RDMBS에서는 DB를 생성하고, 모델들을 각각 독립적인 테이블로 정의 한 뒤, 테이블 간의 관계를 설정하고, 이를 기반으로 테이블에 데이터를 저장하며, 또 테이블 간의 데이터를 조합하여 조회(join) 할 수 있습니다. 이 때 데이터의 조회, 삽입, 수정, 삭제 및 테이블의 정의 및 수정, DB의 생성 등 모든 작업은 SQL(Structured Query Language)이라는 언어를 통해 DBMS 서버에 요청됩니다. SQL 문법을 바탕으로 작성된 문장을 질의(Query)라고 합니다.

예시 Query

select students.name, departments.name
    from students, departments
    where students.dept_id=departments.id;

SQL 문법에 대해서는 이후에 자세히 알아보도록 하겠습니다.

RDB의 관계들

RDB의 관계RDB의 관계

PK는 테이블 내의 특정 데이터를 고유하게 식별해주는 역할을 합니다. 따라서 일반적으로 모든 테이블은 하나의 PK를 갖습니다. 또한 서로 다른 테이블의 데이터 간의 관계는 일반적으로 PK와 FK의 값을 일치시켜 표현합니다. 테이블간에 구성 할 수 있는 관계의 종류에 대해서 알아보겠습니다.

일 대 일 관계

한 부서에 한 매니저(직원)가 있다한 부서에 한 매니저(직원)가 있다

  • 일대일 관계(1:1, One-to-One, HasOne/BelongsTo)에선 A 테이블의 데이터가 B 테이블의 데이터 하나와만 연관이 있습니다.
  • 이 때 FK는 두 테이블 중 어디에 있어도 상관 없습니다.

일 대 대 관계

한 선생님은 여러 과목을 가르친다한 선생님은 여러 과목을 가르친다

  • 다대일 또는 일대다 관계(1:N, One-to-Many, HasMany/BelongsTo)에선 A 테이블의 데이터가 B 테이블의 데이터 여러개와 연관이 있습니다.
  • A has many B일 때 FK는 B 테이블에 존재해야 합니다.

다 대 다 관계

한 학생은 여러 과목을 수강하고, 한 과목은 여러 학생에게 수강된다한 학생은 여러 과목을 수강하고, 한 과목은 여러 학생에게 수강된다

  • 다대다 관계(M:N, Many-to-Many, belongsToMany)에서는 A 테이블의 데이터와 B 테이블의 데이터가 서로 여러개와 연관 될 수 있습니다.
  • 다대다 관계는 A/B 테이블의 관계를 나타내기 위한 추가적인 테이블이 필요합니다 이를 피벗 테이블(Pivot Table)이라하며 이 피벗 테이블에 두개의 FK가 필요합니다.

NoSQL

스케일 업, 스케일 아웃스케일 업, 스케일 아웃

인터넷이 발전하면서 빅데이터라는 용어가 생길만큼 데이터의 규모가 기하급수적으로 커지고 있습니다. 이에 따라 DBMS 서버의 머신은 많은 사용자의 요청을 처리하고, 대규모의 데이터를 저장하기 위해서 그 성능과 규모를 확장해야 할 필요가 있습니다. 이 때 단일 머신의 성능과 규모를 확장하는 스케일 업을 통한 확장은 그 한계가 있으며 기하급수적으로 비용이 증가합니다.

스케일 업과 스케일 아웃의 비용스케일 업과 스케일 아웃의 비용

따라서 일반적인 사양의 머신을 여러대로 늘려서, 사용자의 요청을 분산해서 처리하며, 데이터를 분산 저장하는 스케일 아웃을 통한 확장을 통해 비용을 절감 할 수 있습니다. 하지만 이 때 RDBMS는 데이터 처리에 무결성과 관계성을 갖는 특성상, 스케일 아웃을 통한 규모 확장을 꾀하기가 힘듭니다. 이러한 배경에서 RDBMS의 한계를 극복하고 분산 DB를 구축하기 위한 DBMS들이 등장했습니다.

RDBMS vs. NoSQLRDBMS vs. NoSQL

NoSQL은 RDBMS의 강력한 무결성과 관계성을 버린 DBMS들을 포괄하는 용어입니다. NoSQL은 무결성과 관계성을 적당히 포기하면서 스케일 아웃을 통해 대규모의 분산 DB를 구축 할 수 있는 배경을 마련했습니다. 또한 정해진 테이블의 정의에 딱 맞는 평면적인 데이터만을 저장 할 수 있는 RDBMS와 다르게, NoSQL에서는 비정형화된 데이터를 저장할 수 있는 특성을 갖습니다. NoSQL에는 단순한 Key-Value 형식의 DB, JSON과 같은 Document 형식의 DB, 그래프 형식의 DB 등 다양한 종류가 있습니다.

DBMS의 선택과 모델링

DBMS의 선택 기준

종류기준
RDBMS데이터를 독립적인 모델들과 그 관계로 표현 할 수 있다.
데이터 처리에 신뢰성과 무결성이 필요하다.
NoSQL데이터를 정형화 하기 힘들다.
신뢰성과 무결성보다는 확장성(Scale-Out)과 빠른 속도가 필요하다.
파일 시스템주로 그래픽, 영상 같은 바이너리 데이터들을 다룬다.
확장성이나 신뢰성, 무결성, 데이터의 구조화가 필요하지 않다.
DBMS 서버와 통신하는 비용(속도)을 감당 할 수 없다.

데이터 모델링

적절한 DBMS를 선택했다면, 다음 단계로는 데이터를 모델링해야 합니다. 서비스에서 이용 될 데이터를 추상화하고 그 형태와 관계를 설계하는 일을 데이터 모델링(Data Modeling)이라고 합니다. 서비스 개발의 전체적인 흐름이 데이터 모델에 크게 의존적이기 때문에, 시작부터 모델을 잘 정의 할 필요가 있습니다. 모델링 방식은 그 프로젝트의 성격에 따라 천차만별일 수 있지만, 일반적으로 지켜야 할 기본적인 원칙들이 있습니다.

개념적 데이터 모델링개념적 데이터 모델링

데이터 모델링의 기본 원칙

항목설명
추상화현실 세계의 객체를 추상화를 통해, 단순하고 명확하게 표현합니다. 불필요한 속성은 최대한 제거하고, 속성들은 최대한 단순한 데이터로써 표현합니다.
분리(RDB의 경우) 중복적으로 사용 될 수 있는 데이터들은 새로운 모델로 분리합니다. 직원 모델에 부서명이라는 속성이 있을 수 있지만, 부서라는 모델을 새로 분리하면 중복 데이터의 제거, 모델의 확장 및 변경에 유리합니다.
확장성서비스에서 다루는 데이터가 변경 또는 확장 될 경우를 따져 유연하게 모델링합니다.
비즈니스 로직서비스 기획을 바탕으로, 사용자가 서비스와 상호작용하는 과정을 하나씩 고려해보며 모델을 점검 합니다.

비즈니스 로직(Business Logic)은 컴퓨터 프로그램에서 실세계의 규칙에 따라 데이터를 생성·표시·저장·변경하는 부분을 일컫는다… (위키백과)

데이터 모델의 완성도를 판단하는 절대적인 척도는 없습니다. 또한 서비스의 변화에 따라서 모델은 끊임 없이 변할 수 있습니다. 특히 개발 초기에는 무결성, 확장성, 효율성을 점검하며 모델을 빈번하게 개선해야합니다.

목차
5. 데이터베이스
6. 개발과 배포
저자

김동욱

개발 경력 약 10년, 전문 분야는 웹 및 각종 응용 소프트웨어 플랫폼입니다. Codeflow를 운영하고 있습니다.

2018년 05월 16일 업데이트

지원되지 않는 웹 브라우저거나 예기치 않은 오류가 발생했습니다.