데이터 독립성과 DB Architecture

k_bell·2024년 9월 10일

목록 보기

4/12

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

: 우리가 사용하는 DBMS들은 프로그램과 데이터 간의 독립성을 제공한다고 하였다. 따라서 데이터의 변화가 최종 사용자가 사용하는 응용 프로그램에는 영향을 미치지 않게 된다. 그렇다면 이러한 데이터 독립성을 어떻게 구현할 수 있는지에 대해서 알아보도록 하겠다.

ANSI/SPARC Architecture

: 현재의 대부분의 관계 DBMS 구현에서 사용되는 일반적인 아키텍처는 1978년에 제안된 ANSI/SPARC 아키텍처이다. ANSI/SPARC 아키텍처의 3단계는 내부, 개념, 외부 단계로 이루어진다.

외부 단계
: 데이터베이스의 각 사용자가 갖는 뷰이다. 여러 부류의 사용자를 위해 동일한 개념 단계로부터 다수의 서로 다른 외부 뷰가 제공될 수 있다. 그 이유는, 일반적으로 최종 사용자와 응용 프로그래머들은 데이터베이스의 전체가 아닌 일부분에만 관심을 가지기 때문이다.
개념 단계
: 조직체 전체에 관한 스키마를 포함한다. 데이터베이스에 어떤 데이터가 저장되어 있으며, 데이터 간에는 어떤 관계까 존재하고, 어떤 무결성 제약조건들이 명시되어 있는가를 기술한다. 데이터베이스마다 오직 한 개의 개념 스키마가 존재한다.
내부 단계
: 데이터의 물리적인 저장 구조에 관한 스키마이다. 데이터베이스에 어떤 데이터가 어떻게 저장되어 있는가를 기술하며, 인덱스, 해싱 등과 같은 접근 경로 등을 기술한다. 데이터베이스의 개념 스키마에는 영향을 미치지 않으면서 성능을 향상시키기 위해 내부 스키마를 변경하는 것이 바람직하다.

데이터를 정렬하여 저장하는 것이 데이터 접근 속도에 더 유리하다면 데이터를 정렬한 후 저장시킬 수 있다. 데이터의 정렬은 상위 레이어에 영향을 미치지 않는다.

스키마 간의 사상 (Mapping)

DBMS가 데이터 독립성을 제공할 수 있는 이유는 세 스키마 간의 매핑을 책임지기 때문이다.

위의 그림을 보면 사용자의 외부 뷰에 정의된 EMP_NAME 이란 필드는 개념 스키마에 존재하지 않는다. 하지만 EMP_NAME이 ENO와 ENAME을 입력 파리미터로 받고 있는데, 이때 개념 스키마의 EMP 필드의 EMO, ENAME과 매핑되어 있는 것을 확인할 수 있다.

이러한 매핑을 이용하여 데이터 독립성을 제공할 수 있다. 예를 들어 개념 스키마의 ENO의 이름이 바뀌더라도 외부 뷰와 다시 적절하게 매핑해주면 외부 뷰에서는 개념 스키마에서의 변화를 알 필요가 전혀 없다.

즉, 하위 레이어에서 변화가 일어나더라도 매핑만 다시 해주면 되기 때문에 상위 레이어에 영향을 미치지 않는다는 것이다.

외부 / 개념 사상 (External / Conceptual Mapping)

: 외부 단계의 뷰를 사용해서 입력된 사용자의 질의를 개념 단계의 스키마를 사용한 질의로 변환 (논리적 데이터 독립성)

개념 / 내부 사상 (Conceptual / Internal Mapping)

: 이를 다시 내부 단계의 스키마로 변환하여 디스크의 데이터베이에 접근 (물리적 데이터 독립성)

데이터 독립성
상위 단계의 스키마 정의에 영향을 주지 않으면서 어떤 단계의 스키마 정의를 변경할 수 있음을 의미한다.

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

위의 그림에 대해서 간단히 설명하자면 우선 데이터베이스 관리자가 데이터베이스 정의어를 통해 스키마를 생성한다. 이후 데이터 정의어 컴파일러가 데이터베이스 스키마 구조에 이상이 없는지 확인한다. 문제가 없다고 판단되면 시스템 카탈로그에 데이터 스키마를 저장하게 된다.

최종 사용자 및 프로그래머는 기작성 트랜잭션과 데이터 조작어를 통해 데이터베이스의 원하는 데이터에 접근하게 된다. SQL DBMS에서는 비절차적으로 데이터에 접근하기 때문에 질의 처리기에서 해당 질의에 대한 최적화를 진행하게 된다.

비절차적 접근이라는 것은 원하는 데이터에 대한 접근 방식을 명시하지 않고, 원하는 데이터만 명시하면 DB에서 알아서 데이터에 접근하는 것을 의미한다. 따라서 데이터에 어떻게 접근하는 것이 더욱 효율적인지를 질의 처리기에서 판단하는 것이다.

이후 런타임 데이터베이스 관리기가 시스템 카탈로그를 확인해서 질의가 유효한지, 사용자에게 권한이 있는지 등을 확인해서 해당 질의를 수행하게 된다.

데이터 정의어 컴파일러 모듈
: 데이터 정의어를 사용하여 테이블 생성을 요청하면, 테이블을 파일 형태로 데이터베이스에 만들고, 테이블에 대한 명세를 시스템 카탈로그에 저장
질의 처리기 (query processor) 모듈
: 데이터 조작어를 수행하는 최적의 방법을 찾는 모듈을 통해서 기계어 코드로 변역한다. 질의 최적화 (query optimizer)
런타임 데이터베이스 관리기 (run-time database manager) 모듈
: 디스크에 저장된 데이터베이스를 접근

데이터베이스 API

ODBC (Open Database Connectivity)
: 마이크로소프트 사가 주도적으로 개발한 데이터베이스 API
JDBC (Java Database Connectivity)
: 자바가 운영되는 플랫폼에서 지원되는 데이터베이스 API

ODBC 또는 JDBC를 지원하는 DBMS 간에는 서로 상대방의 데이터베이스를 접근할 수 있다. 이전에는 다른 DBMS 간에는 서로의 데이터베이스가 호환되지 않아 접근이 불가능했다. 이러한 문제점을 극복하고자 개발된 것이 ODBC와 JDBC이다.

중앙 집중식 데이터베이스 시스템

데이터베이스 시스템이 하나의 시스템에서 운영되는 체제이다. 관리가 용이하지만, 데이터베이스의 규모가 커지거나 주변 시스템들의 접근이 늘어나는 경우 중앙 시스템의 스펙이 과도하게 커져야 한다는 문제점이 존재한다.

분산 데이터베이스 시스템

네트워크로 연결된 여러 사이트에 데이터베이스 자체가 분산되어 있으며, 데이터베이스 시스템도 야러 컴퓨터 시스템에서 운영된다. 사영자는 다른 사이트에 저장된 데이터베이스도 접근할 수 있다.

클라이언트-서버 데이터베이스 시스템

데이터베이스가 하나의 서버에 저장되어 있지만, 컴퓨팅 능력을 가진 클라이언트들이 데이터베이스 시스템의 기능을 분담하고 있다. 따라서 PC, 노트북, 스마트폰처럼 자체 컴퓨팅 능력을 가진 클라이언트를 통해 데이터베이스 서버에 접근한다.

서버는 기존과 같이 데이터베이스를 저장하고 DBMS를 운영하면서 여러 클라이언트의 질의를 최적화한다. 권한 검사, 동시성 제어, 회복 기능, 무결성 유지 등의 기존 기능을 그대로 담당한다.

클라이언트에서 사용자 인터페이스를 관리하고 응용 프로그램을 수행한다.

2-Tier Model
: 지금 위에서 설명한 클라이언트-서버 데이터베이스 시스템이 2계층 모델이다. 응용 프로그램 수행과 인터페이스를 클라이언트에서 담당하는 개념이다. 따라서 응용 프로그램에 대한 업데이트가 필요한 경우 모든 클라이언트들에서 업데이트를 진행해야 하는 어려움이 있다.
3-Tier Model
: 클라이언트와 데이터베이스 서버 사이에 응용 서버가 추가된 모델이다. 따라서 응용 프로그램에 대한 처리는 응용 서버에서 담당하게 된다.