관계형 데이터베이스란?

streetcat·2021년 10월 6일
0

관계형 데이터베이스 정의

관계형 데이터베이스(Relational Database)는 오늘날 사용되는 데이터베이스 중 가장 흔하게 사용된다. 하나 이상의 테이블로 구성되어 있으며, 각자의 테이블은 우리가 흔히 아는 표의 형태를 가진다. 테이블의 값들은 다른 테이블의 값과 관계를 맺을 수 있는데, 이것이 관계형 데이터베이스라 불리는 이유이다. 말로는 조금 복잡하니 그림을 첨부하겠다.

테이블 구조

column (열)

각 열은 고유의 이름을 가지고 있으며, 데이터의 타입 또한 정해져 있다. 타입의 종류로는 INGEGER, TEXT, DATE, REAL 등이 있다. field 또는 attribute 라고 불리기도 한다.

row (행)

서로 관계가 있는 데이터의 모음을 의미한다. 동일 테이블의 모든 row는 같은 수의 column을 가지고 있어야 한다. tuple 이나 record 라고도 불린다.

value (값)

각 행과 열에 해당하는 특정 데이터값을 의미한다.

table

위의 value가 모여 row나 column을 만들고, row와 column이 모여 하나의 테이블을 만든다.

schema

데이터베이스 설계의 기본으로, 해당 테이블에 어떤 종류의 값이 들어가는지를 정의한다.
위의 테이블의 스키마는 아마 아래와 같이 될 것이다.

{게시글 번호: int, 작성자: TEXT, 작성자 id: TEXT, 작성 시간: DATE, 조회수: int}

관계

위의 테이블은 단순하여 처리하기 쉽다. 하지만 아래의 경우를 보자.

작성자의 id를 새로 저장하기 시작했다. 이 때 김눈이 새로운 게시글을 작성하였다. 동일한 작성자 id가 두 번이나 저장된다. 지금은 그나마 중복이 한 번이라 큰 문제가 안 되지만, 데이터가 늘어나면 늘어날수록 이러한 중복 문제가 커질 것이다.

그럼 저장 공간이 더 필요할 것이다. 문제는 거기서 끝나지 않는다. 테이블에 데이터가 많아지면 많아질수록 검색에는 더 많은 시간이 필요해진다. 게시글 검색이 느려진다. 사용자들의 불만은 커질 것이고 상사에게서 조인트를 까일 것이다. 그러니 중복되는 게 최소화되도록 테이블을 쪼개보자.

조금 더 단순한 구조의 테이블 두 개로 나뉘었다. 첫 번째 테이블은 게시글의 정보를 담고 있으며, 두 번째 테이블은 작성자의 정보를 포함한다. 이제 김눈이 새 게시글을 작성해도 동일 사용자 id가 중복 저장되는 일은 없을 것이다. 검색이 빨라졌으며, 용량도 덜 먹는다. 심지어 이제는 게시글 정보 없이 작성자를 대상으로만 검색을 할 수 있는 등 보다 다양하게 데이터를 활용할 수 있다. 이렇게 테이블을 쪼개 중복을 제거하는 과정을 정규화 라고 한다.

그런데 여전히 문제가 남아있다. 두 개 이상의 테이블에 데이터가 나누어서 들어간 건 좋은데, 하나의 테이블의 데이터만 수정되고 그 데이터에 관련된 다른 테이블의 데이터는 변경되지 않는다면, 두 테이블이 담은 정보가 달라져버리는 문제가 발생한다. 이를 데이터 불일치 라고 부른다. 이 문제를 해결하는 방법은 간단하다. 그냥 두 테이블을 사용하면서 하나로 엮여진 듯하게 묶어버리는 것이다.

첫 테이블의 작성자 코드 와 두 번째 테이블의 작성자 코드 를 연결시킨다. 이로써 비록 두 개의 테이블에 정보가 나뉘어 들어가 있지만, 하나의 테이블에 있는 듯이 모든 정보가 서로 연결되게 되었다. 이것을 관계라고 부르며, 관계가 존재하는 데이터베이스를 관계형 데이터베이스 라고 부른다.

관계 관련 용어

Primary key (기본키)

테이블의 각 행을 특정할 수 있는 한 개 이상의 컬럼.
위의 경우에선 첫 번째 테이블의 primary key는 게시글 번호, 두 번째 테이블은 작성자 코드 가 해당될 것이다.

Foreign key (외부키)

다른 테이블에서는 primary key로 활용되면서 자신의 테이블에서는 다른 테이블과 연결하는 역할을 수행하는 컬럼.
위의 경우에선 첫 번째 테이블의 작성자 코드 가 해당된다.

정규화

테이블을 분할해서 데이터의 불필요한 중복을 제거하는 것

단점

결정적인 문제가 있다. 서로 연결되어있는 건 좋은데, 하필 foreign key 중 하나의 구조를 바꿔야 한다고 쳐보자. 그럼 연결된 다른 테이블들까지 줄줄이 영향을 받게 된다. 즉 기존 구조의 변경이 엄청나게 까다롭다. 또 연결구조가 복잡해지면 복잡해질수록 관리도 힘들어진다. 비록 안정성을 얻게 될 수는 있지만, 새로운 형태의 데이터가 들어오면 작업이 상당히 곤란해진다.

이에 대한 대안으로 어떠한 관계도, 스키마도 없이 자유롭게 데이터를 추가하고 삭제할 수 있는 non-relational database 가 있다. 관계가 없기 때문에 읽고 쓰기가 자유롭다. 새로운 필드 추가도 마음 편히 할 수 있다. 처음부터 사용자가 필요로 하는 형식으로 데이터를 저장해두면 읽고 쓰는 속도도 빨라진다. 단, 중복되는 데이터가 엄청 생기게 된다. 중복 데이터를 수정하려고 하면 전체 테이블 대상으로 수정해야 한다. 데이터의 무결성이 보장되지 않는다.

관계형이든 비관계형이든 장점과 단점이 명확히 존재한다. 사용하는 데이터의 유형에 따라 신중하게 선택해야 한다.

profile
대학 다니는 백수 개발자입니다.

0개의 댓글