juuuding
[데이터베이스] CH 1 데이터베이스 시스템 (2) 본문
3. DBMS 발전 과정
- 데이터 모델
1. 데이터 모델
- 데이터베이스의 구조를 기술하는데 사용되는 개념들의 집합인 구조 (데이터 타입과 관계), 이 구조 위에서 동작하는 연산자들, 무결성 제약 조건들
- 사용자에게 내부 저장 방식의 세세한 사항은 숨기면서 데이터에 대한 직관적인 뷰를 제공하는 동시에 이들 간의 사상을 제공 (실제 구조와는 다르지만, 어떻게 작동되는지에 대한 과정은 잘 설명 돼 있음)
- 쉽게 말해서 데이터를 구성하고 저장하는 방식을 말한다.
2. 데이터 모델의 분류
(1) 고수준 또는 개념적 데이터 모델
- 사람이 인식하는 것과 유사하게 데이터베이스의 전체적인 논리적 구조를 명시
ex) 엔티티-관계 데이터 모델과 객체 지향 데이터 모델
(2) 표현(구현) 데이터 모델
- 최종 사용자가 이해하는 개념이면서 컴퓨터 내에서 데이터가 조직되는 방식과 멀리 떨어져 있지는 않음
ex) 계층 데이터 모델(트리 구조), 네트워크 데이터 모델(그래프 구조), 관계 데이터 모델(테이블 형태)
(3) 저수준 또는 물리적 데이터 모델
- 데이터베이스에 데이터가 어떻게 저장되는가를 기술
ex) ISAM, VSAM
- DBMS 발전 과정
1. 계층 DBMS
- 1960 후반 최초 계층 DBMS 등장 (ex: IBM사의 IMS)
- 트리 구조를 기반으로 하는 계층 데이터 모델을 이용한 DBMS
- 계층 데이터 모델은 네트워크 데이터 모델의 특별한 사례
- 장점: 어떤 유형의 응용에 대해서는 빠른 속도와 높은 효율성의 제공
- 단점: 어떻게 데이터를 접근하는가를 미리 응용 프로그램에 정의해야 함
데이터베이스가 생성될 때 각각의 관계를 명시적으로 정의해야 함
레코드들이 링크로 연결되어 있으므로 레코드 구조를 변경하기 어려움
2. 네트워크 DBMS
- 1960초에 Charles Bachman이 하니웰 사에서 최초의 네트워크 DBMS인 IDS를 개발
- 레코드들이 노드로, 레코드들 사이의 관계가 간선으로 표현되는 그래프를 기반으로 하는 네트워크 데이터 모델을 사용
- 네트워크 DBMS에서도 레코드들이 링크로 연결되어 있으므로 레코드 구조를 변경하기 어려움
3. 관계 DBMS
- 1970에 E.F.Codd가 IBM 연구소에서 관계 데이터 모델을 제안
- 미국 IBM 연구소에서 진행된 System R과 캘리포니아 버클리대에서 진행된 Ingres project
- 장점: 모델이 간단하여 이해하기 쉬움
사용자는 자신이 원하는 것만 명시하고, 데이터가 어디에 있는지, 어떻게 접근해야 하는지는 DBMS가 결정
- ex) 오라클, MS SQL Server, Sybase, DB2, Informix 등
4. 객체 지향 DBMS
- 1980 후반 들어 새로운 데이터 모델인 객체 지향 데이터 모델이 등장
- 객체 지향 프로그래밍 패러다임을 기반으로 하는 데이터 모델
- 장점: 데이터와 프로그램을 그룹화하고, 복잡한 객체들을 이해하기 쉬우며, 유지와 변경이 용이함
- ex) ONTOS, OpenODB, GemStone, ObjectStore, Versant, O2 등
5. 객체 관계 DBMS
- 1990 후반 관계 DBMS에 객체 지향 개념을 통합한 객체 관계 데이터 모델이 제안됨
- ex) 오라클, Informix, Universal Server 등
- 새로운 데이터베이스 응용과 DBMS의 분류
1. 새로운 데이터베이스 응용
- CAD DB, 소프트웨어 공학 DB(재사용이 가능한 소프트웨어들의 라이브러리), 게놈 DB, 데이터 웨어하우스, 데이터 마이닝, OLAP 멀티미디어 DB, 웹 DB
4. DBMS 언어
1. 데이터 정의어 (데이터 구조 정의)
- 사용자는 데이터 정의어를 사용하여 데이터베이스 스키마 (구조)를 정의
- 데이터 정의어로 명시된 문장이 입력되면 DBMS는 사용자가 정의한 스키마에 대한 명세를 시스템 카탈로그 또는 데이터 사전에 저장
* 명세: 시스템 또는 소프트웨어 구성 요소의 동작 방식, 인터페이스, 입력과 출력 등에 대한 정확하고 상세한 설명서
- 데이터 정의어의 기본적인 기능
ex) SQL - CREATE TABLE(데이터 구조 생성), ALTER TABLE(데이터 구조 변경), DROP TABLE(데이터 구조 삭제), CREATE INDEX(데이터 접근을 위해 특정 애트리뷰트 위에 인덱스 정의)
2. 데이터 조작어 (데이터 관리)
- 사용자는 데이터 조작어를 사용하여 데이터베이스 내의 원하는 데이터를 검색, 수정, 삽입, 삭제 (SQL- SELECT, UPDATE, DELETE, INSERT)
- 절차적 언어와 비절차적 언어가 있음
- 관계 DBMS에서 사용되는 SQl은 대표적인 비절차적 언어
- 대부분의 데이터 조작어는 SUM, COUNT, AVG와 같은 내장 함수들을 갖고 있음
- 데이터 조작어는 단말기에서 대화식으로 입력되어 수행되거나, C, 코볼 등의 고급 프로그래밍 언어로 작성된 프로그램에 내포되어 사용됨
3. 데이터 제어어
- 사용자는 데이터 제어어를 사용하여 데이터베이스 트랜잭션을 명시하고 권한을 부여하거나 취소
* 트랜잭션: 데이터베이스에서 데이터를 변경하는 모든 작업 단위. DB에서는 여러 개의 쿼리가 동시 실행될 수 있는데, 이 때 각 쿼리를 개별적인 작업 단위로 처리하는 것이 아니라, 하나의 트랜잭션으로 묶어서 처리. 트랜잭션은 DB에서 데이터를 변경하는 모든 작업(삽입, 삭제, 갱신)에 적용
* 쿼리: DB에서 데이터를 검색하거나 조작하기 위해 사용되는 명령어 또는 질의문.
+ 그러면 트랜잭션은 데이터를 변경하는 '작업'이고 쿼리는 그 작업을 하기 위한 명령어/질의문, 따라서 트랜잭션에서는 여러 쿼리를 포함하여 데이터를 변경하는 것??
ex) 은행에서 고객이 계좌에 돈을 인출하는 상황
-트랜잭션: 고객이 계좌에서 돈을 인출하는 작업은 DB에서 하나의 트랜잭션으로 처리. 트랜잭션은 한번에 모든 작업이 완료되거나, 아무런 작업도 수행되지 않은 상태로 롤백됨. 따라서 고객이 계좌에서 돈을 인출하는 작업은 트랜잭션 안에서 안전하게 처리
- 쿼리: 고객이 계좌에서 돈을 인출하는 작업을 처리하기 위해서는 DB에서 해당 계좌의 잔액을 확인해야함. 이때 사용되는 것이 쿼리. 쿼리는 DB에서 원하는 정보를 검색하거나 조작하는 작업을 말함. 예를 들어, "SELECT balance FROM account WHERE account_number = '12345'"와 같은 쿼리를 사용하여 계좌 잔액을 조회할 수 있음
∴ 위 예시에서 고객이 계좌에서 돈을 인출하는 작업이 트랜잭션으로 처리되고, 이를 위해 DB에서 해당 계좌의 잔액을 확인하는 쿼리가 사용됨
5. DBMS 사용자
1. 데이터베이스 관리자 (DBA: Database Administrator)
- DB 관리자는 조직의 여러 부분의 상이한 요구를 만족시키기 위해서 일관성 있는 DB 스키마를 생성하고 유지하는 사람
- DB 관리자의 역할
+ DB 스키마의 생성과 변경
+ 무결성 제약조건을 명시
+ 사용자의 권한을 허용하거나 취소하고, 사용자의 역할을 관리
+ 저장 구조와 접근 방법(물리적 스키마) 정의
+ 백업과 회복
+ 표준화 시행
2. 응용 프로그래머
- DB 위에서 특정 응용(ex: 고객 관리, 인사 관리, 재고 관리)이나 인터페이스를 구현하는 사람
- 고급 프로그래밍 언어인 C, 코볼 등으로 응용 프로그램을 개발하면서 DB에 접근하는 부분은 내포된 데이터 조작어 사용
- 이들이 작성한 프로그램은 최종 사용자들이 반복해서 수행하므로 기작성 트랜잭션(canned transaction)이라 부름
* 기작성 트랜잭션: ACID 트랜잭션과 달리 일부 불일치와 충돌이 허용되는 일관성 모델 사용 트랜잭션.데이터의 불일치 허용하면서도, 분산 시스템에서의 데이터의 일관성과 무결성을 유지하기 위해 노력. ACID보다 데이터 일관성은 떨어짐
3. 최종 사용자
- 질의하거나 갱신하거나 보고서를 생성하기 위해서 DB를 사용하는 사람
- 최종 사용자는 캐주얼 사용자, 초보 사용자로 구분
+ 캐주얼 사용자: DB 질의어를 사용하여 매번 다른 정보 찾음
+ 초보 사용자: 기작성 트랜잭션을 주로 반복 수행
4. 데이터베이스 설계자
- ERWin 등의 CASE 도구들을 이용해서 DB 설계 담당
- DB의 일관성을 유지하기 위해 정규화 수행
* 정규화: DB 설계의 한 과정. 중복을 최소화하고 데이터를 구조화하여 일관성 유지. 데이터의 불일치, 모순, 비효율성 등의 문제가 발생하지 않게 하는 것.
5. 오퍼레이터
- DBMS가 운영되고 있는 컴퓨터 시스템과 전산실 관리하는 사람
6. ANSI/SPARC 아키텍처와 데이터 독립성
- ANSI/SPARC 아키텍처
1. ANSI/SPARC 아키텍처
- 현재의 대부분 상용 DBMS 구현에서 사용되는 일반적인 아키텍처는 1978년에 제안된 ANSI/SPARC 아키텍처
- ANSI/SPARC 아키텍처의 3단계는 물리적, 개념적, 외부 단계로 이루어짐
① 외부 단계: 각 사용자의 뷰
② 개념 단계: 사용자 공동체의 뷰
③ 내부 단계: 물리적 또는 저장 뷰
2. 외부 단계
- DB의 각 사용자가 갖는 뷰
- 여러 부류의 사용자를 위해 동일한 개념 단계로부터 다수의 서로 다른 뷰가 제공될 수 있음
- 최종 사용자와 응용 프로그래머들은 DB의 일부분에만 관심을 가짐
3. 개념 단계
- 조직체의 정보 모델로서, 물리적인 구현은 고려하지 않으면서 조직체 전체에 관한 스키마 포함
- DB에 어떤 데이터가 저장되어 있으며, 데이터 간에는 어떤 관계가 존재하고 어떤 무결성 제약조건들이 명시되어 있는가를 기술함
- DB에 대한 사용자 공동체의 뷰를 나타냄
- DB마다 오직 한 개의 개념 스키마가 존재
* 개념 스키마: DB의 전체 구조를 정의. DB 내의 모든 데이터와 관련 개념, 업무 규칙, 제약 조건 등의 정보를 포함. 개념 스키마는 DB의 논리적인 구조를 설계하고, 이를 DBMS에 등록하여 DB를 생성하는 과정에서 생성됨.
ex) 그림 1.20에서 개념 단계가 세 테이블 EMP, PROJ, WORKS로 구성되어 있다.
4. 내부 단계
- 실제의 물리적인 데이터 구조에 관한 스키마
- DB에 어떤 데이터가 어떻게 저장되어 있는가를 기술함
- 인덱스, 해싱 등과 같은 접근 경로, 데이터 압축 등을 기술함
- DB의 개념 스키마에는 영향을 미치지 않으면서 성능을 향상시키기 위해 내부 스키마를 변경하는 것이 바람직
- 내부 단계 아래는 물리적 단계
- 물리적 단계는 DBMS의 지시에 따라 운영체제가 관리함
ex) 그림 1.20 내부 단계는 EMP 테이블의 ENO 애트리뷰트, PROJ 테이블의 PNO 애트리뷰트, WORKS 테이블의 (ENO, PNO) 애트리뷰트에 인덱스가 정의되어 있으며 세 테이블 모두 비순서 파일로 저장되어 있음을 알 수 있다.
5. 스키마 간의 사상
- DBMS는 세 가지 유형의 스키마 간의 사상을 책임짐
- 외부/개념 사상 : 외부 단계의 뷰를 사용해서 입력된 사용자의 질의를 개념 단계의 스키마를 사용한 질의로 변환
- 개념/내부 사상: 이를 다시 내부 단계의 스키마로 변환하여 디스크의 DB를 접근
- 데이터 독립성
1. 논리적 데이터 독립성
- 개념 스키마의 변화로부터 외부 스키마가 영향을 받지 않음을 의미
ex) 개념 스키마에서 새로운 속성 추가하거나 삭제하는 등의 변경이 있을 경우, 이로 인해 외부 스키마에 영향을 주게 된다면, 해당 스키마를 사용하는 모든 응용 프로그램이나 사용자의 코드를 수정해야할 수도 있음. 따라서 개념 스키마의 변경이 외부 스키마에 영향을 주지 않도록 하여, DB의 논리적 데이터 독립성을 유지함으로써, DB의 유지보수 및 확장성 높임
+ 개념 스키마에 새로운 데이터나 처리 구조가 추가되면 데이터베이스 시스템은 이를 반영하기 위해 내부적으로 DB 스키마를 업데이트하고, 이를 기반으로 새로운 데이터를 저장하고 관리함. 외부 스키마에서는 이러한 업데이트가 자동으로 반영이 되므로 외부 스키마를 따로 수정할 필요가 없음. 업데이트 될 때 외부 스키마가 직접적으로 변경되는 것은 아니기 때문에 독립성 유지.
Q) 개념 스키마의 변경으로 외부 스키마가 직접적으로 변경되지 않는다는 것의 의미?
A) 개념 스키마에서 새로운 속성이 추가된다면, 이를 반영하기 위해 DBS의 내부에서 일련의 과정이 진행되고 그 과정에서 개념 스키마의 변경 사항을 반영하는 새로운 데이터 구조가 생성되고, 이 구조를 기반으로 외부 스키마가 업데이트 됨. 외부 스키마가 개념 스키마의 변경으로 인해 영향을 받더라도, 이는 DBS 내부에서 자동으로 처리되는 과정이므로 외부 스키마는 직접적으로 변경되지 않음
2. 물리적 데이터 독립성
- 내부 스키마의 변화가 개념적 스키마에 영향을 미치지 않으며, 따라서 외부 스키마에도 영향을 미치지 않음을 의미
7. 데이터베이스 시스템 아키텍처
1. 모듈
(1) 데이터 정의어 컴파일러 모듈
- 데이터 정의어를 사용하여 테이블 생성을 요청하면 테이블을 파일 형태로 DB에 만들고, 이 테이블에 대한 명세를 시스템 카탈로그에 저장
(2) 질의 처리기 모듈
- 데이터 조작어를 수행하는 최적의 방법을 찾는 모듈을 통해서 기계어 코드로 번역
(3) 런타임 데이터베이스 관리기 모듈
- 디스크에 저장된 데이터베이스를 접근
(4) 트랜잭션 관리 모듈
- 동시성 제어 모듈
- 회복 모듈
2. 데이터베이스 API(Application Program Interface)
- ODBC(Open Database Connectivity)는 마이크로소프트 사가 주도적으로 개발한 DB API
- ODBC를 지원하는 DBMS 간에는 서로 상대방의 DB에 접근할 수 있음
3. 중앙 집중식 데이터베이스 시스템
- DBS가 하나의 컴퓨터 시스템에서 운영됨
4. 분산 데이터베이스 시스템
- 네트워크로 연결된 여러 사이트에 DB 자체가 분산되어 있으며, DBS도 여러 컴퓨터 시스템에서 운영됨
- 사용자는 다른 사이트에 저장된 DB도 접근할 수 있음
5. 클라이언트-서버 데이터베이스 시스템
- PC 또는 워크스테이션처럼 자체 컴퓨팅 능력을 가진 클라이언트를 통해 DB 서버 접근
- DB가 하나의 DB 서버에 저장되어 있음
- DBS의 기능이 서버와 클라이언트에 분산됨
- 장점: 데이터를 보다 넓은 지역에서 접근, 다양한 컴퓨터 시스템 사용 가능
- 단점: 보안이 다소 취약할 수 있음
'컴퓨터공학 > 데이터베이스' 카테고리의 다른 글
[데이터베이스] CH 7 릴레이션 정규화 (2) (1) | 2023.05.17 |
---|---|
[데이터베이스] CH 7 릴레이션 정규화 (1) (1) | 2023.05.17 |
[데이터베이스] CH 6 물리적 데이터베이스 설계 (2) (0) | 2023.05.16 |
[데이터베이스] CH 6 물리적 데이터베이스 설계 (1) (0) | 2023.05.16 |
[데이터베이스] CH 1 데이터베이스 시스템 (1) (0) | 2023.04.06 |