Introduction

1. DBMS란

데이터베이스 관리 시스템(DBMS)은 서로 관계있는 데이터들의 모임과 그 데이터에 접근하기 위한 프로그램의 집합으로 구성된다. 데이터베이스(database)는 보통 이 데이터들의 모임을 일컫는 말로서, 흔히 조직과 관련된 정보들을 포함한다. DBMS의 주요 목적은 데이터베이스에 정보를 저장하고 이를 검색하기 위한 편리하고 효율적인 환경을 제공하는 데 있다.

2. 데이터베이스 시스템의 목적

2.1 파일-처리 시스템(file-processing system)

전형적인 파일-처리 시스템은 보통 OS에 의해 지원된다. 이러한 시스템에서는 영속적 레코드가 여러 가지 서로 다른 파일들에 저장되는 경우가 생기게 되는데, 이는 레코드를 검색하거나 새로 입력할 때, 해당 파일에 따라 여러 가지 프로그램들이 서로 다르게 작성되어야 함을 의미한다. DBMS가 등장하기 전까지는, 대개 이러한 시스템에 정보를 저장했다.

2.2 파일-처리 시스템의 단점

• 데이터의 중복(redundancy)과 비일관성(inconsistency) : 파일과 응용 프로그램은 장기간에 걸쳐 서로 다른 많은 프로그래머들에 의해 개발된다. 그래서 동일한 정보가 여러 파일에 중복 저장될 수 있다. 예를 들어, 만약 한 학생이 복수전공(디자인, 컴퓨터)을 한다고 할 때, 그 학생의 정보는 디자인 전공생의 파일에도 나타나고 컴퓨터 전공생의 파일에도 나타날 수 있다. 이러한 중복은 저장 공간의 낭비를 초래하고, 액세스 비용도 늘어나게 한다.
  뿐만 아니라, 이는 곧 데이터의 비일관성-동일한 데이터의 여러 사본이 서로 다른 값을 보유하는 상태-으로 이어진다.

• 데이터 액세스 시의 어려움 : 파일-처리 시스템 환경에서는 필요한 데이터를 편리하고 효율적으로 검색하기가 어렵다. 어떤 조건에 맞는 데이터를 검색하기 위해서는 그때 그때 알맞은 응용 프로그램을 개발해야 한다.

• 데이터의 고립(isolation) : 데이터가 여러 파일에 흩어져 있는데다 파일 형식이 서로 다르기 때문에 원하는 데이터를 검색하는 프로그램을 새로 작성하기 어렵다.

• 무결성(integrity) 문제 : 데이터베이스 내에 저장된 데이터 값들은 어떤 형식의 일관성 조건(consistency constraint)을 만족해야 한다.
  예를 들어, 대학이 각 학과의 계좌를 유지하고 각 계좌의 잔고를 저장하려고 한다고 하자. 또한 대학교가 학과의 계좌 잔고가 0 이하로 떨어지지 않기를 원한다고 하자. 프로그램 개발자는 여러 프로그램들 내에 적절한 코드를 첨가함으로써, 시스템 내에서 이런 제약조건이 잘 지켜지도록 해야 한다. 그러나 새로운 제약 조건이 추가되었을 때, 기존 프로그램을 일일이 변경하여 해당 제약조건을 새로 만족시키기는 어렵다. 특히, 새로운 제약조건이 서로 다른 파일 내의 여러 데이터 항목들을 포함하게 될 때, 문제는 더 복잡해진다.

• 원자성(atomicity) 문제 : 컴퓨터 시스템이 고장 났을 때, 데이터를 고장 전의 일관성 있는 상태로 유지하는 일이 중요하다. 데이터베이스의 일관성을 지키기 위해서는 all or nothing 조건을 만족해야 한다. 즉, 일련의 과정 전체가 수행되든지 아니면 어느 것도 수행되지 않아야 한다. 기존의 파일-처리 시스템은 이러한 원자성을 보장하기가 어렵다.

• 동시(concurrent) 액세스 문제 : 시스템의 전반적인 성능을 향상시키고 응답 시간을 단축시키기 위해, 많은 시스템들은 여러 사용자가 데이터를 동시에 갱신할 수 있도록 한다. 이러한 상황 하에서는 동일한 데이터가 여러 사용자에 의해 동시에 갱신될 수 있는데, 이는 데이터의 비일관성을 야기할 수 있다.

• 보안 문제 : 데이터베시으 시스템의 모든 사용자가 모든 데이터를 액세스하는 것은 아니다. 파일-처리 시스템에서는 응용 프로그램이 그때그때 바로 추가되므로 보안에 관한 제약조건을 지키기 어렵다.

3. 데이터의 관점

3.1 데이터 추상화(Abstraction)

시스템이 원활하게 사용되려면, 데이터 검색이 효율적으로 이뤄져야 한다. 이러한 목적을 위해, 데이터베이스 내의 데이터를 효율적으로 표현하기 위한 여러 가지 복잡한 데이터 구조가 제안되었다. 많은 데이터베이스 시스템의 경우, 사용자의 대부분이 컴퓨터를 잘 다루지 못하는 일반 사람들이므로, 여러 단계의 추상화를 통해 이러한 복잡한 구조를 되도록이면 감추어, 사용자의 이해와 편의를 도와야 한다.

• physical level : 추상화의 최하위 단계. 데이터가 실제로 어떻게 저장되는지 기술한다. 물리적 단계에서는 복잡한 하위 단계의 데이터 구조들이 상세히 기술된다.
• logical level : 어떤 데이터가 저장되었는지 그리고 데이터들 사이에는 어떤 관계가 있는지 기술한다. 논리적 단계에서는 전체 데이터베이스를 몇 개의 비교적 간단한 데이터 구조를 이용하여 기술한다.
• view level : 추상화의 최상위 단계. 전체 데이터베이스의 일부분만을 기술한다. 논리적 단계의 데이터 구조가 간단하다고는 해도, 커다란 데이터베이스에 저장되는 정보의 다양성 때문에 여전히 상당한 복잡함이 내재되어 있는 것이 사실이다. 대부분의 데이터베이스 시스템 사용자는 데이터베이스에 저장된 모든 데이터에 관심이 있는 것이 아니라, 극히 일부분에만 관심이 있다. 뷰 단계는 이러한 사용자들이 시스템을 간단히 이용할 수 있도록 정의된다. 한 데이터베이스에 대해 수많은 뷰가 존재할 수 있다.

아래의 코드는 네 개의 필드(field)를 가지는 instructor라는 새로운 레코드(record)를 정의하고 있다. 각 필드는 고유한 이름과 그에 적당한 형(type)을 가진다.

type instructor = record
			ID : char(5);
            		name : char(20);
            		dept name : char(20);
            		salary : numeric(8, 2);
             	  end;
            

물리적 단계에서 instructor, department, student 등의 레코드는 연속된 기억 장소에 위치한 하나의 블록 단위로 기술될 수 있다. 데이터베이스 시스템은 낮은 단계의 상세한 저장 구조를 데이터베이스 프로그래머에게 숨긴다.
논리적 단계에서 각 레코드는 위의 코드에서처럼 데이터 타입 정의에 의해 기술되며, 레크드들 사이의 관계도 이 단계에서 잘 정의되어 있어야 한다.
뷰 단계에서 컴퓨터 사용자는 데이터 타입의 상세한 부분을 숨기고 있는 응용 프로그램들을 사용한다. 이 단계에서 동일한 데이터베이스에 대해 여러 개의 뷰가 정의되고, 데이터베이스 사용자는 이러한 뷰의 일부 혹은 전체를 보게 된다. 데이터베이스의 논리적 단계의 상세함을 숨기는 것과 동시에 뷰는 사용자가 데이터베이스의 어떤 부분에는 액세스하지 못하도록 하는 보안 매커니즘도 제공한다.

3.2 인스턴스와 스키마

데이터베이스는 정보가 추가되고 삭제됨에 따라, 시시각각 변한다. 어느 특정한 순간에 데이터베이스에 저장되어 있는 정보의 모임을 데이터베이스의 인스턴스(instance)라고 한다. 이와 대조적으로, 데이터베이스의 전체적인 설계를 이야기할 때는 데이터베이스(schema)라고 한다. 스키마가 변경되는 일은 드물다.
데이터베이스 시스템에는 추상화의 단계에 따라 여러 개의 스키마가 존재한다. 물리적 스키마는 물리적 단계에서, 논리적 스키마는 논리적 단계에서 데이터베이스 설계를 기술한다. 이들 가운데, 응용 프로그램에 가장 큰 영향을 미치는 것은 논리적 스키마인데, 이는 대부분의 응용 프로그램들이 논리적 스키마의 기반에서 작성되기 때문이다. 물리적 스키마는 논리적 스키마 아래에 감추어져 있으나, 대개 상위의 응용 프로그램에 영향을 주지 않고서도 이를 쉽게 변경할 수 있다. 응용 프로그램이 물리적 스키마에 의존하지 않아서 물리적 스키마가 변경되어도 고칠 필요가 없는 것을 가리켜 물리적 데이터 독립성(physical data independence)을 가졌다고 한다.

3.3 데이터 모델

데이터 모델(data model)은 데이터베이스 구조의 기반이 되는 것으로서 데이터, 데이터들 사이의 관계, 데이터의 의미, 일관성 제약조건 등을 기술하기 위한 개념적 표현들의 집합이다. 데이터 모델은 물리적, 논리적, 뷰 단계에서의 데이터베이스를 설계하는 방법을 제공한다.

• 관계형 모델(Relational Model) : 데이터와 이들 데이터 사이의 관계를 나타내기 위해 테이블들의 모임을 사용한다. 각 테이블은 고유한 이름을 가진 여러 개의 column으로 구성된다. 테이블은 relation이라고도 부른다.
  관계형 모델은 레코드-기반 모델의 한 예이다. record-기반 모델이라고 하는 이유는 데이터베이스가 몇 개의 type으로 이루어진 고정 형식의 record로 구성되기 때문이다. 각 테이블은 특정한 type의 record들을 포함한다. 각 record type은 정해진 수의 field(attribute)를 정의한다. 테이블의 각 열은 record type의 속성에 대응한다.
• 개체-관계 모델(Entity-Relationship Model) : 개체-관계 데이터 모델(E-R 모델)은 기본적인 객체들의 집합인 개체(entity)들과 이러한 개체들 간의 관계(relationship)를 사용한다.
• 객체-기반 데이터 모델(Object-Based Data Model) : 객체 지향 프로그래밍은 점차 중요한 SW개발의 방법론이 되어가고 있다. 이것은 E-R 모델에 캡슐화, 메소드, 객체 identity의 개념을 더해 E-R모델을 확장한 것이다.
• 반구조형 데이터 모델(Semistructured Data Model) : 반-구조형 데이터 모델은 같은 형식을 갖고 있으나 다소 다른 속성들을 가진 개별적 데이터 항목들을 기술하기 위한 비정형 데이터 모델이다. 이는 앞에서 소개한 모델들이 특정 형식의 데이터 항목에 대해서는 동일한 속성의 집합만을 갖도록 허용한다는 점에서 대조를 이룬다. 예컨대 XML은 반-구조형 데이터를 나타내는데 널리 쓰이고 있다.

4 데이터베이스 언어

데이터베이스 시스템은 데이터베이스 스키마를 기술하는 데이터 정의 언어(data definition language: DDL)와 데이터베이스 질의 및 갱신을 표현하는 데이터 조작 언어(data manipulation language: DML)를 제공한다.

4.1 데이터 조작 언어

데이터 조작 언어는 사용자가 적절한 데이터 모델로 구성된 데이터를 접근하거나 조작할 수 있도록 하는 언어이다. 접근의 형태는 다음과 같다.

• 데이터베이스 내에 저장된 정보를 검색
• 데이터베이스에 새로운 정보를 삽입
• 데이터베이스로부터 정보를 삭제
• 데이터베이스 내에 저장된 데이터를 수정

기본적으로 두 가지 형태의 DML이 있다.

• 절차식(procedural) DML : 어떤 데이터가 필요하며 그 데이터를 어떻게 구할지 지정할 것을 요구함
• 선언전(declartive) DML : 필요한 데이터를 어떻게 구할지 명시할 필요 없이, 어떠한 데이터가 필요한지 지정할 것만을 요구함

선언적 DML은 보통 절차적 DML보다 배우기 쉽고 사용하기도 쉽다. 그러나 사용자가 데이터를 어떻게 구할지를 구체적으로 명시하지 않기 때문에 데이터베이스 시스템이 스스로 데이터를 효율적으로 액세스하는 방법을 찾아야 한다.
질의(query)는 정보의 검색을 요청하는 문장이다. 데이터 조작 언어에서 정보의 검색을 담당하는 부분을 질의어(query language)라고 한다. 질의어와 데이터 조작 언어를 같은 의미로 사용하는 것이 보통이다.

4.2 데이터 정의 언어

데이터베이스 스키마는 데이터 정의 언어라는 특수한 언어로써 표현된 정의들의 집합으로 구체화된다. 또한 DDL은 데이터의 추가적인 특성을 표현하는 데에도 사용된다.
데이터베이스 시스템에 의해 사용되는 저장 구조(storage structure)와 액세스 방법은 데이터 저장 및 정의 언어(data storage and definition language)라고 하는 특별한 형태의 DDL문의 집합으로 지정된다. 이 DDL 문들은 보통 사용자에게는 보이지 않는 데이터베이스 스키마 구현상의 세부 사항을 정의한다.
데이터베이스에 저장된 데이터들은 해당 데이터베이스가 요구하는 일관성 제약조건을 만족해야만 한다. 데이터베이스 시스템은 데이터베이스가 갱신될 때마다 이러한 제약조건을 검토한다. 일반적으로 이러한 검토를 하는 데는 처리 비용이 많이 들기 때문에 데이터베이스 시스템은 최소한의 비용으로 검증될 수 있는 무결성 제약조건을 이행한다.

• 도메인 제약조건(Domain Constraints) : 가능한 값들의 도메인은 모든 속성들과 연관되어 있어야 한다. 속성을 선언하는 데 있어서 각각의 도메인들은 값에 대한 제약조건으로서 작용한다. 도메인 제약조건은 가장 기본적인 형태의 무결성 제약조건이다. 이는 새로운 데이터 항목이 데이터베이스에 입력될 때 시스템에 의해 쉽게 검증될 수 있다.
• 참조 무결성(Referential Integrity) : 주어진 속성들의 집합에 대한 릴레이션의 한 값이 다른 릴레이션에 대한 속성 집합의 값으로 반드시 나타나야 할 경우가 있다. 예를 들어, course 레코드의 dept_name 값은 department 릴레이션의 일부 레코드의 dept_name 속성에 나타나야만 한다.
• 주장(Assertions) : 주장은 데이터베이스가 항상 만족시켜주어야 하는 조건이다. 도메인 제약조건과 참조 무결성 제약조건은 주장의 특수한 형태이다. 하지만 이 특수한 형태만으로는 표현할 수 없는 많은 제약조건이 존재한다. 예를 들면 "모든 학과는 매 학기에 최소 다섯 개의 수업을 개설해야만 한다"는 주장으로 표현되어야 한다.
• 권한(Authorization) : 데이터베이스의 다양한 데이터들에 대해서 사용자들마다 접근을 다르게 하고 싶을 때 이러한 차별을 일반적으로 권한이라 표현한다. 여기에는 읽기 권한, 삽입 권한, 갱신 권한, 삭제 권한 등이 있다.

DDL은 다른 프로그래밍 언어와 마찬가지로 명령문을 입력으로 받아 결과를 생성한다. DDL의 결과는 메타데이터(metadata)-즉 데이터를 위한 데이터-를 수록하는 데이터 사전(data dictionary)에 위치한다. 데이터 사전은 특별한 형태의 테이블로서 오직 데이터베이스 시스템에 의해서만 접근되고 갱신될 수 있다. 데이터베이스 시스템이 실제 데이터를 읽거나 갱신할 때에는 데이터 사전을 참조하여 작업을 수행한다.

5. 데이터베이스 구조

데이터베이스 시스템의 다양한 구성 요소와 그 구성 요소들 사이의 접속 관계가 하나의 그림으로 나타난다.

데이터베이스 시스템의 구조는 데이터베이스 시스템이 동작하는 컴퓨터 시스템에 의해서 크게 영향을 받는다. 데이터베이스 시스템은 중앙 집중 방식 또는 하나의 서버와 다중 클라이언트 장치들이 함께 작업을 수행하는 클라이언트-서버 방식이 있을 수 있다. 데이터베이스 시스템은 병렬 컴퓨터 구조를 이용하도록 설계될 수도 있다. 분산 데이터베이스는 여러 개의 지리적으로 분리된 컴퓨터 시스템에서 동작한다.
대부분의 데이터베이스 시스템 사용자들은 시스템에서 작업하기보다는 대개 네트워크를 통해 데이터베이스에 접속한다. 그러므로 원격으로 데이터베이스에 접속하여 작업하는 클라이언트와 데이터베이스 시스템이 실제로 설치되어 있는 서버를 구별해야 한다.

데이터베이스 응용 프로그램은 그림 1.6과 같이 두 부분 또는 세 부분으로 나눠진다. 2-계층 구조에서는 응용 프로그램이 클라이언트 상에 존재하며 질의문을 보냄으로써 서버에 있는 데이터베이스 시스템의 기능을 불러온다. 이때 클라이언트와 서버 사이의 교신을 위해 ODBC나 JDBC와 같은 응용 프로그램 인터페이스 표준이 사용된다.
이와는 반대로, 3-계층 구조에서 클라이언트는 어떤 데이터베이스 호출도 직접적으로 수행하지 않고 단지 전처리 시스템으로서만 역할을 한다. 대신, 클라이언트와 응용 프로그램 서버 사이의 교신은 대개 form 인터페이스를 통해 이뤄진다. 다음으로, 응용 프로그램 서버는 데이터에 액세스하기 위해 데이터베이스 시스템과 통신한다. 어떤 행동이 어떠한 조건 하에서 수행되는지를 가리키는 비즈니스 로직은 어떤 클라이언트에 분산되어 있는 것이 아니라 응용 프로그램 서버 쪽에 포함되어 있다. 3-계층 구조는 world wide web이나 대규모의 응용 프로그램에 보다 적합하다.

참고

Database System Concepts 6th Edition 1장