DBMS는 Database를 관리해주는 소프트웨어 패키지 집합이다.

DBMS가 생기기 이전에는, 사용자의 응용이 운영체제의 파일 시스템을 직접 사용해서 스토리지에 데이터를 관리했다.

이는, 응용 프로그램이 파일을 다루는 역할과 책임을 가져야했기에, 추후 파일 내의 데이터가 추가/수정/변경될 경우 응용의 코드 또한 바꿔주어야 했다.

즉, 코드 수정 시 A 코드와 연관된 부분(B코드)에서 오류가 나고, B 코드를 고치면 C코드에서 오류가 나는.. 리팩토링이 리팩토링을 부르는 총체적 난국 상황이었다고 할 수 있겠다.

객체지향 개념 중, 단일 책임 원칙을 지키지 못하는 구조였고, 이에 따라 유지보수 비용이 많고, 데이터 무결성 또한 지켜지기 어려웠다 할 수 있다.

이렇게 되면 응용에 대한 사용자의 신뢰 또한 없어질 것이고, 그러면 이 응용은 아무도 사용하지 않을 것이다.

응용의 논리와 DB관리라는 두가지 역할&책임을 분리하기 위해서는
추상적인 I/F와, I/F가 제시하는 Spec에 맞춘 구현을 가진 서비스가 필요했다. 이것이 바로 DBMS이라 할 수 있다.

DBMS가 지켜야할 Spec = 요구사항

• 데이터 독립성 ( 프로그램 - 데이터 간의 독립성 : 둘 중 어느 부분이 변해도, 다른 부분에 영향을 끼치지 않는다 )
• 효율적인 데이터 접근 ( SQL, 폼 기반 데이터 접근 I/F 등으로 구현 )
• 데이터에 대한 동시 접근 ( Concurrency Issue : Transcation과 ACID 속성 구현을 통한 구현 )
• 백업과 회복
• 중복을 줄이거나 제어해서, 일관성을 유지한다 ( 제 1,2,3정규화 )
• 데이터 무결성 ( 무결성 제약조건 )
• 데이터 보안 ( 권한 관리 )
• 쉬운 질의어 ( 비절차적 언어, 내가 원하는 데이터를 명시하기만 하면 되는 SQL )
• 다양한 사용자 인터페이스 ( CLI, GUI, 최종 사용자가 사용하는 기작성 트랜잭션의 폼 기반 I/F 등등 )

ANSI/SPARC 아키텍처와 데이터 독립성

• ANSI/SPARC 아키텍처의 3단계는 물리적, 개념적, 외부 단계로 이루어짐.

외부 단계( external level ) : 각 사용자의 뷰 (

최종 사용자들은 각자의 니즈에 맞춰, 전체 조직의 데이터 중 일부분에만 관심을 가짐
ex. 서울 지하철 노선도의 2호선 중 낙성대역 - 강남역까지의 지도
ex. 3호선의 고속터미널역 - 양재역까지의 지도 )

=> 데이터베이스의 각 사용자가 갖는 뷰
=> 여러 부류의 사용자를 위해 동일한 개념 단계로부터 다수의 서로 다른 뷰가 제공될 수 있음.
=> 일반적으로, 최종 사용자와 응용 프로그래머들은 데이터베이스의 일부분에만 관심을 가짐.

개념 단계 ( conceptual level ) : 사용자 공동체의 뷰

( ex. 서울시 지하철 노선도 전체 )

=> 조직체의 정보 모델로서, 물리적인 구현은 고려하지 않으면서 조직체 전체에 관한 스키마를 포함
=> 데이터베이스에 어떤 데이터가 저장되어 있으며, 데이터 간에는 어떤 관계가 존재하고, 어떤 무결성 제약조건들이 명시되어 있는가를 기술한다.
=> 데이터베이스에 대한 사용자 공동체의 뷰를 나타낸다.
=> 데이터베이스마다 오직 한 개의 개념 스키마가 존재한다.

• 내부 단계 ( internal level ) : 물리적 또는 저장 뷰
  ( ex. 서울시 지하철 노선도 데이터가 Storage 상에서 어떤 형식으로 저장되는가? 빠른 검색을 위한 어트리뷰트 상의 인덱스는 어떻게 구성되어 있는가? )

=> 실제의 물리적인 데이터 구조에 관한 스키마
=> 데이터베이스에 어떤 데이터가 어떻게 저장되어 있는가를 기술한다.
=> 인덱스, 해싱 등과 같은 접근 경로, 데이터 압축 등을 기술한다.
=> 데이터베이스의 개념 스키마에는 영향을 미치지 않으면서 성능을 향상시키기 위해 내부 스키마를 변경하는 것이 바람직하다.
=> 내부 단계 아래는 물리적 단계이다.
=> 물리적 단계는 DBMS의 지시에 따라 운영체제가 관리한다.

스키마 간의 사상

• DBMS는 세 가지 유형의 스키마 간의 사상을 책임진다.
• 외부/개념 사상 ( external/conceptual mapping )
  - 외부 단계의 뷰를 사용해서 입력된 사용자의 질의를 개념 단계의 스키마를 사용한 질의로 변환한다.
• 개념/내부 사상( conceptual/internal mapping )
  - 이를 다시 내부 단계의 스키마로 변환하여, 디스크의 데이터베이스를 접근한다.

데이터 독립성

• 상위 단계의 스키마 정의에 영향을 주지 않으면서, 어떤 단계의 스키마 정의를 변경할 수 있음을 의미한다.
  - 논리적인 데이터 독립성( logical data independence )
  • 물리적인 데이터 독립성( physical data independence )

논리적 데이터 독립성

• 개념 스키마의 변화로부터 외부 스키마가 영향을 받지 않음을 의미한다.
• 기존의 외부 스키마에 영향을 미치지 않고, 응용 프로그램을 다시 작성할 필요 없이 개념 스키마에 대한 변화가 가능해야 함.

물리적 데이터 독립성

• 내부 스키마의 변화가 개념적 스키마에 영향을 미치지 않으며, 따라서 외부 스키마( or 응용 프로그램 )에도 영향을 미치지 않음을 의미한다.
• 내부 스키마 변화의 예시
  - 파일의 저장 구조를 바꾸거나, 인덱스를 생성 및 삭제

데이터베이스 시스템 아키텍처

1) 데이터 정의어 컴파일러 모듈 ( DDL Compiler )

• 데이터 정의어를 사용하여, 테이블 생성을 요청하면
  테이블을 파일 형태로 데이터베이스에 만들고, 이 테이블에 대한 명세 ( = 스키마 )를 시스템 카탈로그에 저장

2) 질의 처리기 모듈 ( Query Processor ) 모듈

• 데이터 조작어를 수행하는 최적의 방법을 찾는 모듈을 통해서 기계어 코드로 번역

3) 런타임 데이터베이스 관리기( Runtime Database Manager ) 모듈

• 디스크에 저장된 데이터베이스를 접근

4) 트랜잭션 관리( Transaction Management ) 모듈

• 동시성 제어( Concurrency Control ) 모듈
• 회복( Recovery ) 모듈

데이터베이스 API

ODBC ( Open Database Connectivity )

• MS 사가 주도적으로 개발한 데이터베이스 간 API
• ODBC를 지원하는 DBMS 간에는 서로 상대방의 데이터베이스를 접근할 수 있음.
  

중앙 집중식 데이터베이스 시스템 vs 분산 데이터베이스 시스템 vs 클라이언트 - 서버 데이터베이스 시스템

중앙 집중식 데이터베이스 시스템( Centralized Database System )

• 데이터베이스 시스템이 하나의 컴퓨터 시스템에서 운영된다.
  

분산 데이터베이스 시스템 ( Distributed Database System )

• 네트워크로 연결된 여러 사이트에 데이터베이스 자체가 분산되어 있으며, 데이터베이스 시스템도 여러 컴퓨터 시스템에서 운영됨.

• 사용자는 다른 사이트에 저장된 데이터베이스도 접근할 수 있음.
  

클라이언트-서버 데이터베이스 시스템 ( Client-Server Database System )

• PC 또는 Workstation처럼, 자체 컴퓨팅 능력을 가진 클라이언트를 통해 데이터베이스 서버를 접근

• 데이터베이스가 하나의 데이터베이스 서버에 저장되어 있음.

• 데이터베이스 시스템의 기능이 서버와 클라이언트에 분산됨.

• 서버는 데이터베이스를 저장하고, DBMS를 운영하면서 여러 클라이언트에서 온 질의를 최적화하고, 권한 검사를 수행하고, 동시성 제어와 회복 기능을 수행한다.
  데이터베이스의 무결성을 유지하고, 데이터베이스 접근을 관리한다.

• 클라이언트는 사용자 인터페이스를 관리하고 응용들을 수행한다.