Ryumaker

Everyday Together!

개발을 하기 위해 필수불가결한 요소가 바로 데이터베이스입니다.
그렇다면, 데이터베이스란 정확히 무엇을 말하는 것일까요?
단순하게 데이터들을 저장하고만 있으면 데이터베이스라고 부르는 것일까요?
이를 알아보기 위해서는 먼저 File System과 DB의 차이를 살펴볼 필요가 있습니다.

File System

File System이 무엇인지부터 알아보아야겠죠.
컴퓨터 C 드라이브의 속성에만 들어가도 ‘파일 시스템 : NTFS’와 같은 항목이 있는 것을 바로 확인할 수 있습니다. File System이란 게 어디 멀리 떨어져 있는 게 아니라 바로 가까이에서 당연한 듯이 쓰고 있다는 의미겠죠.
File System이 무엇인지에 대해 요약하면 다음과 같습니다.

:pencil2: ‘우리가 사용하는 컴퓨터를 떠올려보면 수많은 directory와 file이 존재할텐데
이들을 체계적으로 관리하고 접근할 수 있도록 하는 OS 내부 프로그램’

FAT, EXT, UFS, NTFS 등 다양한 File System이 존재합니다.
DBMS가 등장하기 이전에는 File System을 통해 Data를 관리하였고
File System의 단점들을 보완하면서 나온 것이 DB라고 볼 수 있기 때문에
이 둘의 차이점을 비교하며 DB가 무엇인지를 파악하면 좋습니다.

File System과 DB의 차이점

무언가를 저장해둔다는 점에서는 File System과 DB가 유사해 보입니다.
그렇다면 둘은 과연 어떠한 점들에서 차이를 보일까요?

1. Data Redundancy와 Data Consistency

File System은 다양한 목적의 응용 프로그램에 대해서 각각의 독립된 file이 존재하므로 똑같은 데이터가 중복으로 저장되는 것을 피할 수 없습니다.
즉, 해당 응용 프로그램이 사용할 file이 각각 별도로 존재하기 때문에 여러 file에 데이터가 중복으로 저장되어 저장 공간의 낭비가 발생할 수 있고,
혹여나 업데이트가 모든 file이 아닌 일부 file에만 부분적으로 일어날 경우에는 file들에 저장된 data가 일관성이 있는지에 대한 의문이 생깁니다.

:arrow_right: DB는 여러 사람들이 공유할 목적으로 통합하여 관리하는 데이터들의 집합체이기 때문에 중복성이 낮고, 일관성이 유지됩니다.

2. Data Dependency

File System에서는 응용 프로그램이 file에 직접 접근하여 처리하는 방식 때문에 해당 file의 구조에 종속적일 수밖에 없다는 문제가 존재합니다.
즉, file 구조가 바뀌면 해당 file을 사용하는 모든 프로그램을 하나하나 수정해야 한다는 의미입니다.

:arrow_right: DB는 DBMS를 통해서 데이터를 받는 방식이므로 File System처럼 모든 프로그램을 하나하나 바꿀 필요가 없어서 유지보수 비용이 줄어듭니다.

3. 동시성 제어

File System에서는 어떤 하나의 응용 프로그램이 사용 중인 file에 대해 동시성 제어가 힘듭니다.

:arrow_right: DB에서는 우선 순위 부여를 비롯한 동시성 제어가 편리합니다.

4. 검색

File System에서는 필요한 Data를 검색하기 위한 ‘질의어’가 제공되지 않고, 필요한 Data를 찾기 위해서는 사용하려는 file을 sequential하게 scan해야 합니다.

:arrow_right: DB에서는 SQL과 같은 질의어가 제공되며, 데이터에 대한 Random Access가 가능합니다.

5. Transaction

File System에서는 Transaction이 존재하지 않습니다.

:arrow_right: DB에서는 Transaction이 존재하여 예기치 못한 다양한 오류에 ACID를 기반으로 Rollback 등의 유연한 대처가 가능합니다.

6. 보안

File System에서는 각각의 프로그램마다 데이터를 별도로 가지고 있기 때문에 데이터 접근에 대한 보안 조치가 어렵습니다.

:arrow_right: DB에서는 하나의 통합된 DB에 대해 접근이 이뤄지므로 여러 사용자들에 대해 서로 다른 권한을 부여하는 등의 보안 조치가 편리합니다.

Database

위에서 알아본 File System과 Database의 차이점을 바탕으로 Database가 무엇인지에 대해 요약하면 다음과 같습니다.

:pencil2: ‘어떤 필요와 목적에 의해 생성되고 저장되는 데이터들의 집합 체계’
:pencil2: ‘여러 사람 및 응용 시스템이 공유할 목적으로 체계적이고 조직적으로 구조화한 통합 데이터’

특히나, Database는 다음과 같은 특징들을 가지고 있습니다.

  • 실시간 접근성 : 수시로 발생하는 데이터 요청에 대해 실시간 처리 및 응답이 가능해야 합니다.
  • 계속적인 변화 : 항상 새로운 데이터의 Insert, Delete, Update를 통해 최신 상태를 데이터베이스에 정확하게 반영해야 합니다.
  • 동시 공유 : 다수의 사용자가 동시에 같은 데이터를 이용할 수 있어야 합니다.
  • 내용에 의한 참조 : 데이터를 찾을 때 그 데이터가 실제로 저장된 주소나 위치에 의해서가 아니라, 사용자가 요구하는 구체적인 데이터 내용으로 데이터를 찾습니다.

DBMS

그렇다면 이러한 DB를 관리하는 무언가가 있어야겠죠?
File System과 DB의 차이가 무엇이었습니까?
바로, 하나의 통합된 Data인 DB에서 정보를 받아와 응용 프로그램에 넘겨주는 것이었죠. 응용 프로그램들과 DB 사이에서 관리자이자 연결 다리 역할을 해주는 것이 바로 DBMS입니다.

DBMS는 ‘데이터베이스를 관리하고 운영하는 software’ 입니다.

  • 사용자가 쉽고 효율적으로 DB를 사용할 수 있도록 도와줍니다.
    :arrow_right: DB 접근부터 시작해서 DB 복구 등의 관리 기능을 제공합니다.
  • 종류로는 MySQL, Oracle, SQL Server 등이 있습니다.
  • 사용자들에게 서로 다른 권한을 부여하여 DB 접근을 제한하는 등의 보안 조치가 가능하여 데이터를 보호할 수 있습니다.
  • 데이터들의 중복을 최소화하고 문제 발생 시 복구할 수 있는 기능을 제공하여 데이터의 관리가 용이합니다.

지금까지는 DB가 어떤 것이며, 어떤 특징을 가지고 있는지를 살펴보았습니다.
이어서는 DB의 골격체라고 할 수 있는 Schema에 대해 이야기해보겠습니다.

Schema

DB에는 Schema(스키마) 라는 것이 존재합니다.
Schema는

:pencil2: ‘데이터베이스의 구조와 제약 조건 등 logical한 명세를 전반적으로 정리한 것’

입니다. 다시 말해, DB에 어떤 구조로 데이터가 저장될지를 정리한 것이죠.
DB에는 총 3단계의 Schema가 존재합니다.

  1. 외부 스키마
    • ‘사용자 개인’의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것입니다.
    • 말 그대로 어떤 하나의 개체에서 지금 내가 필요한 속성들만 뽑아서 모아놓은 것!
    • 하나의 DB 시스템에 여러 개의 외부 스키마가 존재할 수 있습니다.
  2. 개념 스키마
    • 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 데이터베이스의 ‘전체적’인 논리 구조입니다.
    • 하나의 데이터베이스에 1개만 존재합니다.
    • 개체 간의 관계와 제약 조건을 명시합니다.
    • 데이터베이스의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의합니다.
    • 단순히 스키마(Schema)라고 하면 개념 스키마를 의미합니다.
    • DBA에 의해서 구성됩니다.
  3. 내부 스키마
    • 물리적 저장 장치와 관련된 스키마입니다.
    • 실제로 데이터베이스에 저장되는 레코드의 물리적 구조 및 물리적 순서 등을 나타냅니다.
    • 말 그대로 저장 장치에 물리적으로 어떻게 저장할 것인지를 정리한 것!
    • 시스템 프로그래머나 시스템 설계자가 관리합니다.

즉, 외부 스키마 :left_right_arrow: 개념 스키마 :left_right_arrow: 내부 스키마의 관계인 거죠.
그렇다면 왜 굳이 이렇게 3단계의 스키마를 분리했을까요?
이유는 바로 ‘데이터 독립성’ 과 관련이 있습니다.

데이터 독립성

데이터 독립성은 다음과 같습니다.

  • 하위 스키마가 변경되더라도 상위 스키마에 영향을 미치지 않는 속성
  • 데이터베이스 구조의 변화로 인한 영향을 프로그램에 미치지 않도록 하여 최종적으로는 응용 프로그램이 데이터에 종속되지 않게 하는 것

초반부에 언급했듯이 File System은 File에 종속적일 수밖에 없지만 DB는 유연한 대응이 가능합니다.
스키마를 분리하여 한쪽이 변경되더라도 다른 쪽에 영향을 미치지 않게 함으로써 추후에 수정해야될 부분도 줄어들고, 수정 난이도 또한 쉬워져서 궁극적으로 유지보수 비용이 감소하는 효과를 볼 수 있습니다.
또한, 데이터 복잡도와 중복성도 감소합니다.

스키마 사이의 대응 관계를 mapping이라고 하는데
외부 스키마 :left_right_arrow: 개념 스키마의 대응 관계를 외부 / 개념 mapping,
개념 스키마 :left_right_arrow: 내부 스키마의 대응 관계를 개념 / 내부 mapping이라 합니다.

mapping과 연관 지어서 데이터 독립성은 크게 2가지로 나눠볼 수 있습니다.

  1. 논리적 데이터 독립성
    • 개념 스키마가 변경되어도 외부 스키마는 영향을 받지 않는 특성입니다.
    • 데이터베이스의 전체적인 논리 구조가 변경되어도 그와 관련된 외부 / 개념 mapping 정보만 적절히 수정하면 외부 스키마에는 영향이 가지 않는다는 특성입니다.
  2. 물리적 데이터 독립성
    • 내부 스키마가 변경되어도 개념 스키마는 영향을 받지 않는 특성입니다.
    • 데이터베이스의 물리적인 저장 구조가 변경되어도 그와 관련된 개념 / 내부 mapping 정보만 적절히 수정하면 개념 스키마, 즉 논리적인 구조에는 영향이 가지 않는다는 특성입니다.
    • 인덱스 추가와 삭제 혹은 성능 개선을 위해 저장 방식 변경 등의 튜닝을 실행할 때를 예시로 생각해보면 좋습니다.

DB에도 여러 종류가 있지만, 가장 많이 사용되는 DB는 바로 관계형 데이터베이스가 아닐까 하는데요!
개발하면서 아마 가장 처음 접하거나 가장 많이 접하셨을 DB가 바로 RDB(Relational Database) 일 것입니다.

관계형 데이터베이스란

  • 관계형 데이터베이스는 데이터들을 테이블 형태로 저장합니다.
  • 각각의 테이블은 unique한 이름이 붙여져 구별됩니다.
  • 데이터의 종속성을 관계(relationship)로 표현합니다.

  • 관계형 데이터베이스를 관리하고 운영하는 software를 RDBMS 라고 합니다.

  • ex. 학생 테이블
  • ID Name Dept Year
    1 Kevin History 4
    2 Kyle Comp.Sci. 3
    3 Lee Mathematics 2
    4 Albert Music 1

용어 설명

  1. tuple (or row)
    • 서로 관계가 있는 데이터의 모음입니다.
    • 테이블에서 각 데이터 항목을 저장하는 하나의 가로줄입니다.
  2. attribute (or column)
    • 각 항목의 속성을 표시합니다.
    • 데이터의 타입이 정해져있습니다.
    • 테이블에서 각각의 세로줄을 의미합니다.
  3. domain
    • 각 속성에서 domain이란 해당 속성에 부합할 수 있는 값들의 set입니다.
    • 즉, 각 속성에 들어갈 수 있는 값들의 모임!
    • null은 모든 domain에 들어갈 수 있는 요소입니다.
    • domain의 각 값들은 atomic, 즉 더 이상 분리되지 않는 값이어야 합니다. 
       예를 들어, 위 예시 학생 테이블에서 Year가 (4, 3)처럼 복합적인 값이 될 수 없습니다.
    • Atomic한 타입에는 Integer, real, char, varchar 등이 있으며 Non-Atomic한 타입에는 set, list, bag 등이 있습니다.
    • 각각의 domain들을 D1, D2, … , Dn이라 할때,
      D1 x D2 x … x Dn의 subset을 relation 이라고 합니다.
    • 즉, relation은 (a1, a2, a3, … , an) 형태의 tuple 들의 집합입니다. (ai ∈ Di)
  4. relation과 relationship의 비교
    • relation은 n-tuples의 집합이며, 서로 다른 속성으로 구성된 테이블 혹은 개체
      :arrow_right: 말 그대로, relation은 데이터들을 table의 형태로 표현한 것!
    • relationship은 두 개의 테이블들 혹은 개체들이 어떻게 연결되었는지 그 방식을 나타내는 것!
  5. relation schema
    • relation 이름(속성 1, 속성 2, … , 속성 n) 식으로 해당 relation에 어떤 속성의 정보가 담길지를 정의하는 일종의 ‘틀’ 입니다.
  6. relation instance
    • 스키마에 따라 실제로 저장된 데이터의 집합을 의미합니다.
    • ‘instance’가 보통 실제로 사용하려고 구현한 객체를 뜻하는 것처럼 어느 한 시점에 relation에 존재하는 구체적인 데이터 값의 tuple 집합을 의미합니다.
  7. Degree & Cardinality
    • Degree (차수) : Attribute의 수
    • Cardinality (카디널리티) : 전체 Row들에 대한 특정 Column의 중복 수치를 나타내는 지표
      :arrow_right: 해당 Column에 있는 고유한(distinct) 값의 개수를 의미합니다.
      :arrow_right: 중복도가 ‘낮으면’ 카디널리티가 ‘높고’, 중복도가 ‘높으면’ 카디널리티가 ‘낮습니다’.

:pencil2: 각각의 테이블에서 tuple이 어떤 순서로 나열되어 있는지는 중요하지 않습니다.

이번 포스팅에서는 File System과 DB의 차이점부터 시작해서
관계형 데이터베이스의 개념까지 폭넓게 알아보았습니다.
혼동할 수 있는 용어들이 있기도 하고,
DB를 공부하는 데에 있어서 가장 기초적인 지식들이므로 꼭 짚고 넘어가시면 좋겠습니다.

참고

Transaction

Transaction에 대하여 알아보겠습니다.