DBMS : Database Management System, 데이터베이스 관리 시스템
1. DBMS의 발전 배경
초창기는 각 응용프로그램이 데이터를 파일로 유지·관리 했으며, 이를 위해 프로그램 코드를 포함하고 있었어야 함.
- 파일 시스템의 특성
- 논리적 파일 구조를 직접 물리적 파일 구조로 구현해야 함.
- 물리적 데이터 구조에 대해 잘 알아야만 접근 방법을 효율적으로 구현 할 수 있음.
- 모든 프로그램이 파일을 가지고 있어야 하므로, 하나의 파일은 하나의 응용만을 위해 존재하게 됨.
데이터를 같이 쓸 수 없는 파일 시스템의 가장 큰 문제점은 데이터 종속성과 데이터 중복성임.
1.1. 데이터 종속성
응용 프로그램과 데이터 간의 상호 의존 관계.
데이터의 구성·접근 방법 변경시 응용 프로그램도 같이 변경 시켜야 함.
1.2. 데이터 중복성
파일 시스템에서는 내용이 같으면서도 구조만 다른 데이터가 많이 존재하게 됨. 한 시스템 내에 내용이 같은 데이터가 중복되게 저장 관리 되는 것을 데이터 중복성이라고함.
조금 발전된 파일 관리 시스템에서는 데이터 파일 처리 루틴을 하나의 공동 접근 루틴으로 구성했음. 하지만 이 시스템도 같은 데이터에 대해 다른 형태의 데이터 구조를 지원하지는 못했음. 이는 곧 불가피한 중복성으로 이어짐.
- 중복성이 불러오는 문제점
- 일관성 : 같은 데이터가 여러개 있다면 일관성(동일성)을 유지하기 힘듦. 곧 모순성을 포함하게 됨.
- 보안성 : 한 시스템 내에 존재하는 같은 내용의 데이터들은 같은 수준의 보안이 유지되어야 함. 그러나 유지되기 어려움.
- 경제성 : 중복 저장은 추가적인 저장 공간에 대한 비용을 야기함. 갱신 비용 또한 높아짐.
- 무결성 : 데이터의 정확성(= 올바른 데이터인가)을 유지하기 어려움.
이외에도 데이터에 대해 여러 프로그램의 동시 사용을 지원하지 못한다는 점 등은 새로운 방법의 필요성을 높임.
2. DBMS의 정의
: 파일 시스템에서 야기된 문제를 해결하기 위해 고안된 시스템으로, 데이터의 중재자로서 모든 응용 프로그램들이 데이터베이스를 공용할 수 있게끔 관리해 주는 소프트웨어 시스템을 말함. DB의 구성, 접근 방법, 관리 유지에 대한 책임을 지고 있음.
3. DBMS의 필수 기능
3.1. 정의
: 응용 프로그램과 DB가 서로 인터페이스 할 수 있는 방법을 제공하는 것. 각 응용 프로그램은 이 데이터 정의를 기초로 원하는 데이터를 DBMS에 표현함.
- 데이터 정의에 포함되어야 하는 내용
- DB의 논리적 구조와 특성이 DBMS가 지원하는 데이터 모델에 맞게 기술되어야 함.
- 물리적 저장을 위한 데이터의 물리적 구조의 명세도 포함해야 함.
- 논리적 구조와 물리적 구조 사이에 상호 변환이 가능하도록 두 구조간의 사상(mapping)을 명세해야 함.
3.2. 조작
: 사용자와 DB 사이의 인터페이스를 위한 수단을 제공하는 것. 데이터 언어를 통해 표현될 수 있음.
- 데이터 언어의 요건
- 사용하기 쉽고 자연스러워야 함.
- 명확하고 완전해야 함.
- 효율적이어야 함.
3.3. 제어
: DB의 정확성과 안전성을 유지하는 것.
- 제어 기능의 요건
- DB 수정이 정확히 수행되어야 하며, 무결성이 파괴되지 않도록 제어할 수 있어야 함.
- 정당한 사용자가 허가된 데이터만을 접근할 수 있도록 권한을 검사하고 보안을 유지해야 함.
- 여러 명이 동시에 정근해도 정확성이 유지되도록 병행 제어 기능이 있어야 함.
4. DBMS의 장단점
4.1. 장점
4.1.1. 데이터 중복의 최소화
데이터를 통합해 구성함으로써 중복을 사전에 통제할 수 있으며, 중복이 불가피 한 경우에도 어떤 데이터가 어디에 중복되어 있는지 알고 있음. 이러한 중복은 '제어된 중복'이라고 함.
4.1.2. 데이터 공용(Data Sharing)
같은 내용을 여러 구조로 지원해주므로 데이터 공용이 가능함.
4.1.3. 데이터 일관성 유지
중복 데이터의 제어와 통제를 통해 일관성을 유지함.
4.1.4. 데이터 무결성 유지
무결성은 현실 세계의 값이 실제 값과 일치하는 것을 의미함. DB가 처리될 때마다 제어 기능을 통해 유효성을 검사함으로써 유지됨.
4.1.5. 데이터 보안 보장
중앙 집중식으로 효율적으로 관리하므로 모든 데이터에 대해 철저한 보안 유지를 보장할 수 있음.
4.1.6. 표준화
데이터 형식, 내용, 처리 방식, 문서화 양식 등에 대한 표준화를 범 기관적으로 쉽게 시행 가능함.
4.1.7. 전체 데이터 요구의 조정
상충되는 데이터 요구는 조정해서 기관 전체에 가장 유익한 구조로 조직하여 효율적인 정보 처리 효과를 얻게 함.
4.2. 단점
4.2.1. 운영비 증대
DBMS가 고가의 소프트웨어이며, 시스템 자원을 많이 사용함. 운영비의 오버헤드를 가중시키게 됨.
4.2.2. 특정 응용 프로그램의 복잡화
특수 목적의 응용 시스템은 설계 기간이 길어지게 되고 전문적, 기술적이 되어야 하기 때문에 구조가 복잡하게 되고 성능이 저하될 수 있음.
4.2.3. 복잡한 백업과 회복
장애가 일어나면 정확한 이유나 상태를 파악하기 쉽지 않음. 백업 조치나 회복 기법을 수립해 놓지 않으면 이용에 지장을 초래할 수 있음.
4.2.4. 시스템의 취약성
장애가 일어날 경우 전체 시스템을 정지 시켜 시스템 신뢰성과 가용성을 저해할 수 있음. DB 의존도가 높은 환경에서는 치명적임.
현재는 DBMS가 불가피한 도구이며, 이런 문제점에 대한 대처가 잘 준비되어 있다고 평가 받음.
5. 데이터 독립성
: 데이터의 논리적 구조나 물리적 구조가 변경되더라도 응용 프로그램이 영향을 받지 않는 것. DBMS의 궁극적인 목적임.
5.1. 논리적 데이터 독립성
DB의 논리적 구조를 변경시키더라도 기존 응용 프로그램들에 아무런 영향을 주지 않는 것. 하나의 논리적 데이터 구조를 가지고 다양한 형태의 논리적 구조로 사상시켜 지원해 줄 수 있는 능력이 있을 때 가능함.
5.2. 물리적 데이터 독립성
논리적 DB는 하나의 물리적 구조로 구현될 수 밖에 없음. 즉, DB는 하나의 물리적 구조로 여러 응용 프로그램들을 지원해야 함.
물리적 구조를 변경하더라도 DB를 이용하는 응용 프로그램들에 아무런 변경을 요구하지 않아야 하며, 논리적 구조에도 영향을 주어서는 안됨. 이를 물리적 데이터 독립성 이라고 함.
하나의 논리적 구조와 이를 지원할 수 있는 여러 물리적 구조 사이의 사상 능력이 있어야 가능함.
6. DBMS의 역사
===== 1세대 =====
네트워크 데이터 모델, 계층 데이터 모델에 기초를 둠.
60년대 초. 찰스 바크만 - Integrated Data Store(IDS), 네트워크 데이터 모델의 기초.
60년대 후. IBM - IMS(Information Management System), 계층 데이터 모델의 기초.
70년대 초. 컴퓨터 회사들 - 각종 제품들
===== 2세대 =====
관계 데이터 모델에 기초를 둠.
E.F.코드 - 관계 데이터 모델 제안. 데이터베이스 이론의 기초가 됨.
80년대. 관계 데이터 모델이 주류가 됨. IBM - SQL 개발, 세계 표준 데이터베이스 언어가 됨.
===== 3세대 =====
80년대 후~90년대. DB응용에 대한 복잡성이 증대되어 새 시스템의 개발이 절실해짐.
객체 데이터베이스(ODBMS), 객체-관계 데이터베이스(ORDBMS)
'Major Review (학부) > Database' 카테고리의 다른 글
[DB] Ch05. 관계 대수와 관계 해석 (2) (2) | 2023.04.14 |
---|---|
[DB] Ch05. 관계 대수와 관계 해석 (1) (0) | 2023.04.13 |
[DB] Ch04. 관계 데이터베이스 (1) | 2023.04.10 |
[DB] Ch03. 데이터베이스 시스템의 구성 (0) | 2023.04.09 |
[DB] Ch01. 데이터베이스 환경 (0) | 2023.04.04 |
댓글