데이터베이스 시스템 문서 원본 보기

== 개요 ==
Database-management system(DBMS)란 연관된 data들과 그러한 데이터들에 접근하는 프로그램의 집합이다.이를 통해서 사용하기 편리하고 효율적인 환경을 이용자에게 제공한다.
Database System(DB system)은 매우 많고 가치있기 때문에 다수의 유저와 application들에 의해 동시에 접근되는 정보를 관리하도록 설계되었다. 
이를 위해 정보 저장을 위한 구조를 정의하거나 정보를 수정하는 메커니즘을 제공한다. 
또한 DB system은 system crash나 허가되지 않은 접근들에 맞서서 저장된 정보들의 안전성을 담보해야 한다.

이런 DB system의 예시는 다음과 같다.
* 기업 정보
** 판매: 소비자, 상품, 구매
** 회계: 가격, 영수증, 자산
** 인적 자원: 직원 정보, 급여

==목적==
DB system은 file system을 통한 data관리의 어려움을 타파하기 위해 만들어졌다. 아래와 같은 어려움들이 존재한다.
#Data redundancy and inconsistency
#* 서로 다른 프로그래머들이 파일과 응용 프로그램을 장기간에 걸쳐 만드므로 다양한 파일들이 서로 다른 구조로 이루어질 가능성이 높다. 또한 응용 프로그램들이 서로 다른 프로그래밍 언어로 짜여질 가능성 또한 존재한다. (inconsistency)
#* 추가로 동일한 정보가 여러 파일에 동시에 존재할 가능성이 있다.
# Difficulty in accessing data
#* 유저가 data에 접근하여 이를 활용하고자 할때 그에 대한 응용 프로그램을 각각 만들어야 한다. 아니면 사용자가 수작업으로 데이터를 가공하여야 한다.
#* 예시로 유저가 60점 이상인 학생들의 목록을 추출할 때, 특정 주소지에 있는 학생들의 목록을 추출할 때, 모두 별개의 프로그램이 필요하다.
# Data isolation
#* 데이터가 여러곳에 분산되어 있고, 파일 형식 등이 다를 수 있으므로 적절한 응용 프로그램의 개발이 어렵다.
# Integrity
#* 어떤 데이터에 대한 응용 프로그램의 경우는 특정한 제약 조건이 필요하다. (예를 들면 몸무게 > 0 등...) 하지만 새로운 제약이 추가되거나 기존의 제약이 수정될 경우에는 이를 응용 프로그램에 적용하는 것이 어렵다.
#Atomicity of Updates
#* 컴퓨터가 응용 프로그램의 실행 중 문제가 발생하였을 때 이를 이전의 상태로 복원을 하여야 한다. 이는 DB의 일관성에 필수적인 요소이다. 예를 들어 은행에 500만원을 입금하였을 때 장애가 생기면 500만원이 입금되었으나 실제로는 계좌에 돈이 입금되지 않는 경우가 생길 수 있으므로 이를 취소해야 한다. 즉 반만 실행되서는 안되며, 완전히 성공하는 경우가 아니라면 아예 DB의 상태가 바뀌어서는 안된다. 하지만 파일 기반 시스템의 경우 이런 속성을 구현하는 것이 어렵다.
# Concurrent access by multiple users
#* DB 관리의 효율성과 속도를 위해서는 다수의 사용자가 동시에 접속할 수 있어야 한다. 하지만 이러한 경우 다음과 같은 문제가 생길 수 있다. 계좌 A의 잔액이 10,000달러인 상황에서 두 명의 은행 직원이 동시에 500달러와 100달러를 인출한다고 가정하자. 두 프로그램이 동시에 실행되면, 두 프로그램이 각각 이전 잔액인 10,000달러를 읽고, 차감한 후 새로운 값을 기록할 수 있다. 이 경우, 최종 잔액은 9,500달러 또는 9,900달러로 잘못 저장될 수 있다.
#* 이러한 문제를 해결하기 위해서는 시스템이 감독 기능을 제공해야 한다. 하지만 기존의 파일 처리 시스템에서는 여러 응용 프로그램들이 사전에 조율되지 않았기 때문에 이를 제공하기가 어렵다.
# Security problem
#* 사용자는 그 신분에 따라 접근할 수 있는 data의 범위가 달라져야 한다. 예를 들어 학생을 교수의 이름과 이메일 주소는 볼 수 있어도 교수의 연봉 등의 정보에는 접근할 수 없어야 한다. 하지만 파일 관리를 기반으로 DB를 관리하면 이러한 경우를 통제하기 어렵다.

==View of Data==
DB system의 기본적인 목적은 data에 관한 abstract view를 제공하는 것이다. abstract view란 사용자가 data가 어떻게 관리되고 저장되는 지에 대한 지식이 없어도 해당 data에 접근하고 조작할 수 있다는 개념을 의미한다. 

===Data Models===
DB의 구조를 뒷받침하기 위해서는 Data Model이 필요하다. 이는 데이터를 설명하고, 데이터 간의 관계와 의미, 그리고 consistency 제약 조건을 정의하는 개념적인 도구들의 집합이다. Data Model에는 대표적으로 다음 예시들이 있다.
# [[Relational Model]]
# Entity-Relationship Model(E-R Model): 해당 모델은 entity라고 불리는 기본 객체들과 해당 객체들 간의 관계들의 집합을 통해 data를 나타낸다.
#Semi-structured Data Model
#* 동일한 유형의 개별 data 항목들이 서로 다른 속성 집합을 가질 수 있도록 허용한다.
#* 대표적인 예시로는 XML이 있다.
#Object-Based Data Model
#* 객체지향 프로그래밍의 대두와 함께 개발된 data model이다.
#* 해당 모델은 relatinal model을 캡슐화, 메서드, 객체 식별 개념과 결합하여 확장한 방식이다.

===Data Abstraction===
[[파일:ArchitecureOfDBSystem.png|섬네일|An architecture for a database system]]
DB는 복잡한 데이터 구조를 가지고 해당 DB 내의 데이터를 표현한다. 하지만 대부분의 DB 사용자들은 해당 방법에 대한 전문적인 지식이 없기 때문에 개발자들은 여러 단계의 Data Abstraction을 통해 이런 복잡성을 숨긴다. 이를 통해 사용자가 시스템과 상호작용하는 것을 더욱 쉽게 할 수 있다. 이러한 Data Abstraction은 오른쪽 그림과 같이 세가지 수준에서 구현된다.
# Physical Level: 가장 낮은 추상화 수준으로 데이터가 실제로 어떤 방식으로 저장되는지에 대해 기술한다. 
# Logical Level
#* 그 다음으로 높은 수준이지만 Physical Level에 비해 상대적으로 단순한 구조로 데이터베이스에 저장된 데이터가 무엇인지와 해당 데이터들 사이의 관계에 대해서 서술한다. 
#*데이터 베이스 관리자는 DB에 어떤 정보를 저장할지를 결정할 때 논리적 수준의 추상화를 이용한다.
#* physical data independence: 해단 수준에서 사용되는 단순한 구조를 실행시킬 때 복잡한 physical level에서의 구조를 통해서 구현될 수 있음에도, Logical Level과는 독립적이므로 사용자는 이에 대해서 몰라도 된다는 것이다.
#View Level
#* 가장 높은 수준으로 사용자에게 전체 데이터 베이스의 일부만을 표시한다. 이는 대부분의 DB 사용자들은 전체의 DB 정보를 필요로 하지 않고 특정 부분만 접근하면 되기 때문이다. 이는 하나의 DB에 대해 여러 개의 뷰를 제공하여 구현된다. 그리고 이를 통해서 이런 사용자들의 상호작용을 단순화할 수 있다.
#* 논리적 수준은 단순하지만 전체 DB는 매우 거대하고 다양한 데이터로 이루어져 있으므로 여전히 복잡성이 남아있다.

====예시====
다음과 같이 record 타입을 다음과 같이 추상적으로 정의한다고 치자.
<pre>
type instructor = record
    ID : char(5);
    name : char(20);
    dept_name : char(20);
    salary : numeric(8,2);
end;
</pre>
위의 코드에서는 instructor라는 새로운 record 타입을 정의하며, 해당 자료구조는 이름과 데이터 타입을 가지는 4개의 필드를 가진다.
예를 들어서 char(20)은 최대 20개의 문자로 이루어진 문자열을 의미한다. 또한 numeric(8,2)는 8자리 숫자 중 소수점 이하 2자리까지 표현 가능한 숫자를 의미한다. 또한 다음과 같은 레코드 타입이 존재할 수 있으며, 대학교의 데이터 베이스가 이를 포함할 수 있다.
* department 레코드: dept_name, building, budget
* course 레코드: course_id, title, dept_name, credits 
* student 레코드: ID, name(이름), dept_name, tot_cred
이제 이를 바탕으로 Data Abstraction이 어떻게 구현되는지 살펴보자
# Physical Level에서 교수, 학과, 학생의 레코드는 연속적인 바이트 블록으로 표현한다. 하지만 컴파일러는 이러한 수준의 정보를 프로그래머로부터 숨긴다.
# Logical Level에서 각 레코드는 위에서 설명했듯이 type 정의를 통해서 설명되며, 레코드 유형간의 관계 또한 논리적 수준에서 정의된다. 예를 들어서 instructor 테이블의 dept_name 값은 반드시 department table에 존재해야 한다는 것등이 있다. 또한 프로그래밍 언어를 사용하는 프로그래머들은 이 수준에서 작업한다. 또한 DB 관리자들도 대부분 이 수준에서 작업한다.
#View 수준에서는 컴퓨터 사용자들이 데이터를 다룰때, 데이터 타입과 관련된 상세한 정보(Logical Level)를 숨긴 애플리케이션 프로그램의 형태로 DB를 접한다. 이 수준에서는 여러 개의 DB 뷰가 정의되어 사용자는 이러한 뷰 중 일부 혹은 전체를 볼 수 있다. 또한 이를 통해서 특정 사용자가 DB의 일부에만 접근할 수 있도록 하는 보안 메커니즘을 제공한다. 예를 들어서 학생은 학생의 정보를 볼 수 있지만, 교수이 salary 항목은 볼 수 없다.

===Instances and Schemas===
데이터베이스는 시간이 지남에 따라 정보가 삽입되고 삭제되며 변화한다. 이때 특정 시점에 DB에 저장된 정보의 모음을 DB의 instance라고 한다. 반면 DB의 전체 설계를 DB schema라고 한다. 데이터베이스 스키마와 인스턴스 개념은 프로그래밍 언어로 작성된 프로그램과 유사한 방식으로 이해할 수 있다. 데이터베이스 스키마는 프로그램 내의 변수 선언과 이에 따른 타입 정의에 해당한다. 각 변수는 특정 시점에서 하나의 값을 가진다. 특정 순간의 프로그램 내 변수들의 값이 데이터베이스 인스턴스에 해당한다.

====Schema의 종류====
# Physical schema: physical level에서의 DB 설계를 나타내며, 데이터가 실제로 어떻게 저장되는 지를 설명한다.
# Logical Schema: logical level에서의 DB 설계를 나타내며, 데이터가 어떻게 구조화되었는 지와 데이터 간의 관계를 설명한다. application 개발자들은 logical schema를 기반으로 코딩한다.
#View Schema: view level에서 여러개의 schema(subschema)를 가질 수 있으며 이를 통해서 DB의 서로 다른 부분은 사용자마다 다르게 보여줄 수 있다.

===Database Language===
DB는 Data-Definition Language(DDL)이라는 언어를 제공해 DB schema를 지정할 수 있도록 한다. 또한 Data-Manipulation Language(DML)을 제공하여 DB에 대한 query와 갱신을 가능하도록 한다. 이때 DDL과 DML은 별개의 언어가 아니며, SQL과 같이 단일한 DB 언어의 일부를 구성한다. SQL은 거의 모든 Relational DB 시스템이 사용하는 DB 언어이다.

====Data Definition Language====
DDL은 정의들의 집합을 이용하여 DB schema를 지정하는데 사용된다. 
DDL 명령문을 실행하면 출력(table templates)이 생성되며, 이는 data dictionary에 저장된다.
data dictionary는 metadata(DB schema, integrity constraints, authorization)를 포함한다. 이때 data dictionary는 DB 시스템에서 특별한 유형의 table로 간주되며, 일반 사용자는 이에 접근하거나 수정할 수 없다. 또한 DB 시스템은 데이터를 읽거나 수정하기 전에 데이터 사전을 참조한다.

====Data Manipulation Language====
DML은 query language라고도 하며, 적절한 데이터 모델에 의해 조직된 데이터를 갱신하거나 접근하는 데 사용되는 언어이다. DML은 기본적으로 두가지로 구분된다.
# Procedural(절차적) DML: 사용자가 필요한 데이터가 무엇인지(What)뿐만 아니라, 데이터를 어떻게 가져올지(How)도 명시해야 한다.
# Declarative(선언적) DML: 사용자가 필요한 데이터가 무엇인지(What)만 지정하면 되고, 데이터를 어떻게 가져올지는 명시할 필요가 없다.

====SQL Query Language====
SQL Query Language는 비절차적이며, 이로인해 사용자는 어떤 데이터를 가져올지(What)를 지정할 뿐, 데이터를 가져오는 방법(How)은 지정하지 않는다. Query는 하나 이상의 테이블을 입력으로 받아 단일 테이블을 출력한다. 다음 예시를 살펴보자
<pre>
SELECT name
FROM instructor
WHERE dept_name = 'Comp. Sci.';
</pre>
해당 query 명령어는 dept_name이 'Comp. Sci.'인 교수들의 name 속성만 검색하여 결과로 반환한다.

또한 SQL은 Turing Comlete한 언어가 아니다.(유저에게 입력받기, 디스플레이에 대한 출력, 네트워크를 통한 통신 기능 등을 지원하지 않는다.) 따라서 복잡한 연산이나 논리, 알고리즘등을 구현해야 할 경우 C++, JAVA같은 host language와 함께 사용해야 한다. 이때 SQL을 상위 수준의 언어에서 사용하는 데에는 다음 두가지 방법이 존재한다.
* SQL을 사용하기 위해서 Language Extension을 사용한다.
* API(응용 프로그램 인터페이스)을 통해 SQL을 DB에 전송할 수 있다.
위 방법을 바탕으로 DB와 상호작용하는 데 사용되는 프로그램을 Application program이라고 한다.

==Database Design==
추상적인 데이터 모델에서 실제 DB 구현으로 전환하는 과정은 두 개의 최종 설계 단계를 거친다.
# Logical Design: 설계자는 추상적으로 존재하는 schema를 몇가지 결정을 통해 실제 데이터베이스 시스템의 구현 데이터 모델로 변환한다.
#* Business decision: 해당 DB 내에 우리는 어떤 속성을 기록해야 하는가?
#* Computer Science decision: 어떤 relation schema를 가지고 속성들을 다양한 relation schema 사이에서 어떻게 그룹화해야 하는가? (Relation는 속성들의 집합으로 구성된 table을 의미)
#Physical Design: 논리적 설계에서 얻은 DB schema를 바탕으로 DB의 physical layout을 결정해 데이터의 물리적인 저장 방식을 결정한다. 

==Database Engine==
DB 시스템은 전체 시스템의 각 기능을 담당하는 여러 모듈로 구분된다. 
===Storage Manager===
DB에 저장된 low-level 데이터와 application 프로그램과 시스템에 전송되는 query들 사이의 인터페이스를 제공하는 프로그램이다.
이는 다음의 작업을 담당한다.
# OS file manager와의 상호작용
#* 이는 데이터베이스 시스템은 디스크와 메모리 간 데이터 이동을 최소화할 수 있도록 데이터를 구조화해야 하기 때문이다.
# 데이터를 효율적으로 저장하고 출력하고 갱신하기
Storage manager는 다음 요소들을 포함한다.
* Authorization and integrity manager
* Transation manager
* File manager
* Buffer manager
Storage manager는 다음 자료구조들을 주로 활용한다. 
* Data file: DB 자체를 저장함
* Data dictionary: DB의 구조에 대한 정보를 포함하는 metadata를 저장함
* Indices: 특정한 값을 가지는 데이터 항목에 대한 포인터를 제공하는 인텍스를 통해 해당 항목에 대한 빠른 접근을 제공함 

===Query Processor===
질의 처리기는 DB 시스템이 시스템이 데이터를 쉽게 접근하고 효율적으로 처리할 수 있게 한다. 이를 통해서 사용자가 View 수준에서 데이터를 다룰 수 있도록 한다. 이는 Logical 수준에서 비절차적인 언어로 작성된 query와 갱신 요청을 physical 수준에서 실행할 수 있는 최적의 연산 순서로 변환하여 구현된다. 이는 다음과 같은 요소들을 통해서 구현된다.
[[파일:QueryProcessing.png|섬네일|Query Processing]]
* DDL interpreter: DDL 명령어들을 해석하고 data dictionary에 정의들을 기록한다.
* DML compiler: query 언어로 되어있는 DML 명령어들을 query evaluation engine이 이해할 수 있는 low level의 명령어로 된 evaluation plan으로 번역한다.
** DML compiler는 query 최적화를 수행한다. 이를 통해서 여러 plan으로부터 가장 효율적인 evaluation plan을 선택한다.
* Query evaluation engine: DML complier에 의해 만들어진 low level 명령어를 실행한다.
Query Processors는 다음과 같은 과정을 통해서 Query Processing을 진행한다.
# Parsing and translation
# Optimization
# Evaluation

===Transaction Management===
Transaction이란 일련의 데이터 접근 작업을 DB application의 함수를 통해 하나의 단위로 묶어 처리하는 것이다. Transaction Management는 Transaction이 완전히 실행(Commit)되거나 전혀 실행되지 않도록(Rollback) 보장한다. 이를 통해서 DB가 일관적인 상태를 system failure에도 불구하고 유지하도록 한다. 

또한 Concurrency control manager는 동시적인 Transaction 사이에서의 상호작용을 스케쥴링하여 DB의 일관성을 유지한다. 이를 통해서 Transaction 실행 중 시스템 오류나 동시 접근(concurrent access) 문제를 신경쓰지 않도록 해준다.

==Database and Application Architecture==
<gallery>
파일:Architecture.png|100000픽셀|System Structure
파일:TierArchitecture.png|1000픽셀|Tier Architecture
</gallery>
위 그림은 다양한 유저들이 DB와 어떻게 상호작용하는지, 그리고 DB 내의 다양한 여러 요소들이 어떻게 서로 연관되어 있는지를 나타낸다. 


[[:Category:데이터베이스 시스템]]
[[분류:컴퓨터 공학]]