[database] DBMS는 무엇이며 왜 사용할까? (Feat. Data Independence, RDBMS)

본 게시글은

서울대학교 데이터사이언스대학원 이상원 교수님의

데이터사이언스 응용을 위한 빅데이터 및 지식관리시스템 수업을

학습을 목적으로 재구성하였습니다

---

제대로 된 database 수업의 첫번째 시간

수업의 시작 내용은

DBMS의 정의였다

 

 

What is a DBMS?

 

DBMS가 뭔지 알아보기 이전에

Database가 무엇인지부터 알아보자

 

Database란 수많은 데이터들의 집합이다

이 세상의 수많은 데이터들은 서로 어떤

연관 관계를 갖고있는데,

database란 이러한 서로 관계를 갖고있는

큰 데이터들의 집합이다

 

이러한 데이터베이스를 구축하는 가장 근본적인 이유는

결국 실세계의 데이터들을 컴퓨터에서 다루기 위함이다

 

이런 데이터베이스는 크게

Entites, Relationships 2가지로 구분할 수 있는데

만약 학교에 관련한 정보들을 data로 표현한다고 하면

students, courses, instructors, classroom, time과 같은 것들이

entites로 정의된다

Relationship은 말 그대로 entities들 간의

관계를 표현하는 것들이라고 할 수 있다

예를 들면 길동이는 DB-41수업을 수강하고,

이교수는 DB-41 수업을 가르치는 것과 같이

학생, 교수, 강의끼리의 관계를 표현하는 것이

relationship이 될 수 있다

 

그렇다면 DBMS는 이러한 database를

효과적으로 관리하기 위해 만들어진 시스템

즉, 큰 데이터를 효율적으로 관리하기 위해 만들어진 소프트웨어이다

 

이런 DBMS의 예시로는

Oracle, MsSQL, Altibase, Postgres, MySQL 등이 있다

 

 

 

DBMS가 만들어지기 이전에는

대부분 데이터를 file로 관리했다

 

또 사실 프로그래밍을 하다보면

연동이 복잡하고 이것저것 지켜야할게많은 DB보다

간편하게 json 혹은 csv 파일에 데이터를 저장한 뒤

그냥 쉽게 불러오고 저장하는게 더 편할 때가 있다

 

그럼에도 불구하고 왜 우리는

file보다 DBMS를 사용해야하는가?

 

물론 작은 데이터를 저장하는 경우 file도 큰 문제가 없지만

큰 데이터의 경우 DBMS를 사용하는 것이 훨씬 좋다

 

DBMS같은 경우 시스템 내에서

데이터를 조회할 수 있는 SQL이라는 언어가 존재해서

내부적으로 원하는 조건으로 데이터를 빠르게 조회하거나 수정할 수 있다

 

 

 

또한 나중에 가면 배우겠지만

동시에 여러 명의 사용자가 데이터에 접속했을 때

동시접속을 control 해주고

어떤 원인에 의해서 시스템에 손상이 발생했을 때

손상되기 이전으로 돌리는 recovery도

DBMS에서는 구현이 되어있다

 

보안의 측면에서도

DBMS는 유저를 설정하고

각 유저에게 read, write 등의 권한을 부여할 수 있기 때문에(RBAC)

파일에 비해서 보안에서도 훨씬 유리하다

 

하지만 그 중에서 가장 중요한 것은

DBMS의 Data Independence라는

중요한 특징 때문이다

 

 

 

이번에는 Data Model에 대해서 알아보자

 

보통 우리가 흔히 부르는 Data Model은

Relational Data Model과 동일한 개념이며

data model이란 data를 표현하고

data를 조작하는데 필요한 high-level의 concept를 말한다

 

이러한 data model은 사용자에게 보여주기위해

아래의 복잡한 low-level은 숨기고

abstract하게 표현하는 것이 특징이다

 

entity와 relationship을 어떤 자료구조로

표현할 것인가 등이 대표적인 data model의 예시이다

 

 

그렇다면 Schema는 무엇일까?

Schema의 정의는 data model을 기반으로하여

특정 데이터 집합의 구체적인 description이라고 하는데,

간단하게 말하면 2차원 table database에서

각 column들과 column들의 데이터타입이다

 

relational database에서 data를 표현하는 model은

2차원의 table 형태이며

이러한 data model에서 schema는 column혹은 field를 말한다

 

 

 

이제 간단한 개념과 용어들을 보자

위에서부터 용어에 혼동이 올 수 있을 것 같은데

attribute = field = column은 모두 같은 말이다

 

2차원의 table database에서

각 column은 attribute, field라는 용어로 불리기도한다

 

또한 각 데이터들의 row를

row = record = tuple이라고 부른다

 

또한 데이터에는 Integrity Constraint

우리나라 말로 무결성 제약조건이라는 것이 있는데

한마디로 데이터가 당연히 만족해야할 조건들을

만족시켜아한다는 것이다

 

예를 들어서 사람의 나이는 음수가 될 수 없기 때문에

그런 것들을 지켜주는 것이

데이터의 무결성을 지키는 것이다

 

Abstratcion 단계에 대해서 알아보자

 

크게 3가지의 단계로 구성이 되는데

가장 추상화된 것이 View

그 다음이 Conceptual(Logical) Schema

그 다음이 Physical Schema이다

 

View Schema는 사용자가 자기가 필요한 것만 볼 수 있도록

따로 생성해주는 것인데

view table을 생성하게 되면

실제 데이터가 아닌 가상의 데이터가 들어있다

 

Conceptual(Logical) Schema는

우리 database에는 이러이러한 relation(table)들이

들어가있다는 것을 표현하는 스키마이다

 

마지막 Physical Schema는 말 그대로

물리적 스키마이다

우리같은 사용자의 눈에는 database의 table은

그냥 하나의 큰 table처럼 보이겠지만
(주로 속도를 빠르게 하기 위해서)

하지만 컴퓨터 내부에서 물리적으로는 그렇지 않을 수 있다

대표적인 예시로는 여러 개의 물리적인 테이블로 쪼개는

partition이 있을 수가 있고

index를 생성해서 index로 검색할 때는

해당 table이 아닌 index를 이용하여 검색한다거나

하는 것들이 있다

 

 

 

위에서 본 각 3가지의 단계를

RDBMS에서 DDL문으로는

이렇게 3가지로 구분할 수 있다

 

 

 

위에서 DBMS를 사용하는 이유 중

가장 중요한 것이라고 했던

Data Independence에 대해 알아보자

 

Data Independence는 데이터의 논리적 또는 물리적 구조가

변경되더라도 상위 레벨의 데이터 모델이

영향을 받지 않는 것을 뜻한다

 

각 예시를 통해 Data Independence를 설명해보겠다

 

우리는 각 사용자마다 전체 데이터를 보여주고싶은게 아닌

특정 데이터만을 보여주고싶을 때 view를 사용한다

기존에 view를 create한 다음

logical schema에서 어떤 field를 추가하는 등

logical 단계에서 변경이 일어나더라도

기존에 생성했던 view에는 영향을 미치지 않는다

이것이 논리적 데이터 독립성이다

 

그렇다면 물리적 데이터 독립성을 살펴보자

우리는 흔히 DB를 쓸 때

검색속도를 향상시키고자 index table을 생성한다

우리가 기존의 table에서 index table을 생성하더라도

기존의 logical 단계에서의 테이블 구조는 변하지 않는다

 

또한 Index table을 생성했다가 drop해도

logical 단계에서의 테이블 구조나

SQL 쿼리에는 아무런 영향이 없다

이게 물리적 데이터 독립성이다

 

이러한 Data Independence는

RDBMS의 가장 큰 장점 중 하나이다

 

 

 

이제 DBMS에서 Query에 대해 알아보자

 

query는 데이터가 쌓여있고

그 쌓여있는 데이터를 기반으로

특정 데이터를 조회하고 싶을 때 사용한다

 

자연어로 된 질문을 SQL이라는

query language로 표현한다

 

중요한 것은 query에서 우리는

how와 what을 분리해야한다

 

우리같은 사용자가 query를 통해 하는 행위는

WHAT이다

어떤 정보를 어떤 필터를 통해 조회할것인가?

이게 바로 WHAT이다

사람에게 친숙한 언어라고 할 수 있다

 

이렇게 사용자가 WHAT을 던져주면

컴퓨터 내부에서 optimizer를 통해

효율적으로 원하는 답을 내보내주는 과정은 how이다

 

아주 간단한 예시로

employ라는 table이 있고

이 employ table에 department_no라는 int column을

index를 생성했다고하자

 

그럼 우리는 department_no를 이용해서 employ를 검색할 때

그냥 동일한 쿼리인

select * from emp where deptno = 30;

이런식으로 사용하겠지만

(WHAT)

DBMS 내부에서는 index table이 있는지 없는지를 파악하고

있다면 index table을 통해서

없다면 그냥 전체를 scanning하는 방법으로해서

결과를 조회한다

(HOW)

 

 

앞에서 잠깐 나왔단 transaction에 대해서 알아보자

우리 일상생활의 대부분은 transaction으로 이루어져있으며

우리는 모두 transaction의 유발자이다

 

DBMS는 transaction에서 ACID를 지원하는데

Atomicity, Consistency, Isolation, Durability의 약자이다

 

ACID를 guarantee하는 예시로는

transaction을 수행하던 중 시스템이 멈춘다면

DBMS는 transaction을 수행하기 아예 이전 상태로 돌아가야한다

이를 recovery라고 부르는데

이게 DBMS가 ACID를 보장하는 대표적인 예시 중 하나이다

 

한 가지 주목해야할 점은

file system에서는 ACID는 지키기 어렵다는 것이다

 

이 때 교수님이 Oracle로 한 가지 실험을 해보셨는데

user1과 user2의 계정으로 동일한 서버의 oracle DB에 접속했다

user1에서 어떤 table의 row를 update해주기 위해서

BEGIN transaction을 해준 다음

update문을 이용해서 'SMITH'라는 사용자의

salary를 1000에서 100을 더해줬다

 

이때 user2가 'SMITH'의 salary를 조회하는

select 쿼리를 날리면 1100으로 보일까

아니면 기존의 1000으로 보일까?

 

정답은 당연히 기존의 1000으로 보인다

왜나하면 BEGIN transaction 이후

update를 하고 COMMIT;을 해주지 않았기 때문이다

 

사실 원론적으로 들어가면

다른 user가 table의 데이터를 update하고 있는데

그 데이터에 접근해도 되냐부터 따져야하지만

이건 DB마다 다른 정책을 갖고있고

oracle의 경우 데이터에 접근하는 것은 허용하지만

commit을 하지 않았다면 update이전의 값을 보여주도록 되어있다

 

비록 commit을 하지는 않았지만

user1로 접속했을 때

update한 'SMITH'의 salary를 조회하면

1100으로 보여지게된다

 

그렇다면 여기서 의문이 생긴다

oracle DB는 어떤 계정에서는 1100으로

어떤 계정에서는 1000으로

'SMITH'의 salary가 보여지게 되는데

동일한 데이터를 갖고있어야하는데

이게 어떻게 되는 것일까?

 

이처럼 DB는 데이터를 update하는 등

데이터에 어떠한 변경사항이 있을 때

그 데이터를 version별로 따로 저장하고있다

이를 versioning이라고 해주고

특정 시점의 데이터들을 계속해서 갖고있다가

더이상 필요없다고 생각되면

그 오래된 version의 데이터는 삭제하는 방식으로

version을 관리하고있다

 

아무튼 이게 동시접속을 관리하는 DB의

대표적인 사례이고

user1가 commit을 하지 않아도

user2에서 select는 가능하지만

update를 하거나 데이터를 변경하려고하면

oracle에서 에러를 띄운다

 

그런 다음 user1이 COMMIT;을 입력해주면

user1이 수행했던 update transaction은 끝이나게되고

그럼 user2도 해당 데이터를 변경할 수 있게 된다

 

하지만 위와같은 상황에서 이런 일이 발생할 수 있다

user1이 1000에서 1100으로 SMITH의 salary를 올렸고

commit 이전일 때

user2가 SMITH의 salary를 조회하면

변경 전의 값인 1000이 나오게 된다

이때 user1이 commit을 수행하여

모든 사용자에게 salary가 1100이 반영이되었는데

이때 user2가 user1이 값을 변경했다는 사실을 모른채

SMITH의 salary를 10% 인상하도록 update를 해준다면

user2는 당연히 1000에서 10%인상한 1100이 되기를 원했지만

user1이 이미 1100으로 인상해놓았기 때문에

user2의 update수행 결과는 1210이 된다

 

이는 교수님 말로는 oracle의 아쉬운 점인데

원래 DB transaction은

마치 한 명의 사용자가 혼자서 이 DB 전체를 사용하고있는 것처럼

만들어줘야하는 것인데 이를 ACID에서 Isoloation이라고 하고

oracle은 이를 제대로 해주지 못하고 있다는 것이다

 

원칙적으로 isolation을 제대로 지켜주려면

어느정도 transaction의 속도를 포기해야하는데

oracle은 속도와 data의 정확성 중에서

속도를 높이고 정확성을 어느 부분 포기한 경우에 해당한다

속도 <-> 정확성의 trade off가 있는 것이다

 

 

 

RDBMS의 전체 구조이다

본 수업에서는 이 구조를 기준으로

모든 내용을 설명한다고한다

 

 

 

RDBMS에는 두 개의 큰 개념이 있다

 

첫 번째는 Declarative interfaces인데

흔히 말해 우리가 알고있는 SQL이다

DBMS에서 관리하고있는 database와

우리같은 사용자가 어떤 교류(?)를 할 수 있는 방법이고

이를 RDBMS에서는 SQL이라는

query language로 지원하고있다

 

DBMS의 가장 핵심 기능은

OLTP이고 이러한 OLTP를 유저는

SQL같은 쿼리로 수행할 수 있다

 

하지만 보통 유저가 이런 query를 짤 때는

그냥 단순하게 로직만 작성하지

그 내부의 어떤 작업을 세세하게 관리하지는 않는다

이렇기 때문에 SQL은 로직만 간단하게 표현하는

declarative interface가 되는 것이다

내부의 복잡한 과정은 DBMS가 알아서 처리한다

 

 

 

이제 본격적으로

Relational Model에 대해서 배워보자

 

 

본 Relational Model 수업은

오른쪽 학자분이 처음으로 고안한 내용이고

오른쪽 아래의 논문 내용을 기반으로 구성되었다

 

관계형 모델을 다루는 언어는

크게 3가지가 있는데

DDL

DML

DCL

이 있다

 

뒤에가서 더 자세하게 나올 것 같지만

간단하게만 설명하면

 

DDL은 database를 정의하는 언어이고

대표적으로 CREATE, ALTER, DROP 등이 있다

DataGrip과 같은 DB 에디터에서

DDL보기를 누르면 사용자가 어떤 DDL로

본 table을 만들었는지 보여주는 기능이 있다

(늘 3개 헷갈렸지만

이것때문에 DDL은 확실하게 기억함)

 

DML은 database를 조작하는 언어이고

우리가 흔히 가장 많이 사용하는

select, delete, insert, update가 있다

 

DCL은 database를 제어 혹은 관리하는 언어이고

누군가에게 권한을 준다거나

데이터의 보안 및 회복을 관리하는 언어이다

대표적으로는

revoke, rollback, commit, grant가 있다

 

 

 

관계형 데이터베이스의 정의를 보자

우리가 정말 흔히 말하는 관계형 데이터베이스

Relational Database(RDB)는

relation의 집합을 뜻한다

 

이전에 잠깐 나왔지만

tuple = row = relation

모두 같은 뜻이다

 

한마디로 2차원 table에서

row들의 집합이

RDB의 정의가 되는 것이다

 

relation은 2개의 부분으로 구성되어있는데

schema와 instance로 구성되어있다

schema는 앞에서 말했던 것처럼

2차원 table의 column을 생각하면 쉽다

예시에서 student라는 table이 있으면

그 column은 sid, name, login, age, gpa 등이 되고

이 column들이 schema를 구성하는 것이다

 

그다음은 instance는

그 table의 row와 column들을 말한다

 

따라서 relation의 집합이라는 뜻은

tuple, row의 집합이라는 뜻이고

set이라는 정의에서 알 수 있겠지만

RDB 2차원 table에서 모든 row는 다 달라야한다

중복을 허용하지 않는다는 뜻이다

 

 

 

Student라는 table로 예시를 살펴보자

 

이 student라는 table의 schema는 일단

sid: string,

name: string,

login: string,

age: integer,

gpa:real

이렇게 구성되어있다

 

이 중에서 sid, name, login, age, gpa는

column이라고 부르며

column = attribute = field

모두 같은 용어이다

 

여기서 각 row들은

row라고도 부르고

tuple, record, relation이라고도 부른다

 

가장 첫번째 row는

(50000, Dave, dave@cs, 19, 3.3)

이런 tuple이 저장되어 있는 것이다

 

여기서 cardinality와 degree의 개념이 나오는데

degree는 차수로

column(=field, attribute)의 개수를 뜻한다

그리고 cardinality는 row(=tuple, relation, record)의 개수를 뜻한다

 

따라서 위 예시에서

degree = 5

cardinality = 6이 된다

 

아까 앞에서 각 row들은 중복이 되면 안된다고했다

위 예시를 살펴보면 name에서

Smith가 2개가 있고

age나 gpa같은 경우는 충분히 중복 데이터가 발생할 수 있다

하지만 이 각 row들을 중복이 되지 않기 위해

sid 필드를 만들어 준 것이다

이름, 나이, 학점이 같아도 결국 다른 학생이기때문에

그 학생들을 가리키는 sid는 다르기 때문이다

 

 

 

위 예시로 다시 용어를 살펴보자

2, 3, 4는 다 column이지만

각 EMPNO, JOB, DEPTNO로 역할이 다르다

 

5번은 TURNER라고 하는 사람의

SAL 필드의 값이 된다

 

MGR은 여기서 매니저의 사번을 뜻하는데

6번을 보면 값이 비어있다

이 이유는 상사가 없어서 값이 없는 것이고

이를 Null 값이라고 한다

 

 

지금까지 RDB를 살펴봤는데

사실 그냥 우리가 흔히 아는

엑셀의 형식

2차원의 table 형식이다

 

그런데 이를 왜 Tabular라고 정의하지않고

Relational이라고 정의했을까?

 

이러한 이유는 relation의 개념을

수학에서 가져왔기 때문이다

 

보통 우리가 흔히 말하는 table에서는

각 tuple들의 순서가 중요하다

하지만 수학적인 측면에서는

tuple들의 순서는 중요하지 않다

 

이러한 database의 특성 때문에

순서가 중요한 tabular라고 하지 않고

relational이라고 정의하게 된 것이다

 

쉽게 이해하기 위해 예를 들자면

우리가 흔히 excel을 다루다보면

위 ppt 예시에서 BLAKE의 DEPTNO를 찾고싶을 때

2번째 row의 8번째 column과 같은 식으로 

데이터를 찾아오지만

RDB에서는 index가 전혀 중요하지 않다

 

RDB에서는 data를 addressing 할 때

오직 값과 이름만으로 하기 때문이다

---

여기까지 이번 DB수업 내용 정리 끝-!