정의 및 관리 목적

데이터베이스는 물리 데이터 모델을 구현한 결과물이며 구축된 실제 데이터가 저장되는 데이터 저장소를 의미한다. 물리 데이터 모델이 구현된 데이터베이스 저장소인 테이블과 속도를 위한 인덱스, 비즈니스 규칙이 반영된 제약 사항 및 데이터베이스를 효과적으로 운영하기 위한 객체를 정의하고 관리한다.

데이터베이스 내에서 생성된 모든 객체는 DBMS 자체의 데이터 사전에 의해 관리된다. 데이터 사 전에서는 항상 현재의 상태와 DBMS 객체 자체의 정보만 관리되므로 논리 데이터 모델과의 정렬이 나 각 DBMS 객체에 대한 논리적 정보가 데이터 품질 관리 관점에서 함께 관리된다면 데이터 아키 텍처 관점에서 더 유효할 것이다. 참고로 데이터 사전(Data Dictionary) 정보와 DBMS 객체 관리 를 위한 정보는 구분되어야 한다. DBMS의 데이터 사전은 DBMS의 객체를 운영하기 위한 정보이므 로 데이터 구조상의 논리적 정보를 같이 관리하지는 않는다. 이는 논리 데이터 모델과 DBMS 객체 정보가 분리되어서 운영되고 상호의 형상 유지가 따로 관리되는 구조적 차이이기도 하나 이로 인한 데이터 아키텍처 관점에서 구조 정렬이 유지되지 않는 문제로 확대된다. 따라서 논리 데이터 모델과 DBMS 객체가 데이터 아키텍처 관점에서 논리적 연계성을 유지하는 방안이 데이터 품질 관리 방안 에서 무엇보다 중요한 사항이라 할 수 있다.

세부 관리 대상

저장 공간

저장 공간은 데이터베이스에서 데이터를 저장할 공간을 필요로 하는 테이블과 인덱스를 정의하는 영역(Tablespaces, Data File)이다. 데이터베이스에서 운영하는 모든 정보는 대표적으로 테이블과 인덱스로 구분되어 저장되며, 데이터의 관리는 기본적으로 저장 공간의 관리로부터 시작될 수 있다. 다음과 같은 기준에 따라 관리되어야 한다.

안전성

저장 공간을 위한 시스템의 디스크 영역은 시스템의 다른 프로그램 수행 영역으로부터 분리되어 다른 프로그램으로부터 안전하게 보호되어야 한다. 이를 위하여 보통의 업무 시스템은 DBMS 전용 서버를 운영하기도 한다. 또한 데이터가 물리적으로 저장되는 실제 공간이므로 외부의 위협이나 재해로부터 저장공간의 존재가 보호되어야 한다.

보안성

데이터가 물리적으로 저장되는 실제 공간이므로 허가 받지 않은 프로그램이나 사용자에 대하여 완전하게 접근 제어가 이루어져야 한다.

확장성

데이터는 지속적으로 증가할 수 있으므로 저장 공간의 확장과 물리적 디스크 영역의 할당이 충분하고 편리하게 수행되어야 한다.

성능 보장

대용량의 데이터가 DBMS 운영 중 수시로 호출되고 저장되므로 저장 공간을 할당한 물리적 디스크는 빠른 성능을 유지할 수 있는 제품과 구조적 배치가 이루어져야 한다.

데이터베이스 관리자(DBA, Database Administrator)는 관리 기준에 따라 성능과 보안을 고려 하여 시스템의 저장 공간을 수시로 확인하여 데이터의 최종 보안과 안전성을 제일의 목적으로 관리 해야 한다. 또한 개발자나 사용자의 편의에 따라 무분별하게 데이터가 확장되는 것을 제어하고 적절한 수준의 저장 공간에 대한 백업도 병행되어야 한다.

테이블

테이블은 엔터티와 속성으로 정의한 것이다. 데이터의 특성에 따라 클러스터, 파티션 등의 다양한 방법이 적용될 수 있다. 데이터의 증가 추이도 관찰되고, 이에 따른 물리적 성질 변화도 필요할 수 있 다. 다음과 같은 기준에 따라 관리되어야 한다.

주기성

테이블 내의 데이터는 일정한 주기에 따라 백업되거나 성능을 위하여 재생성 될 수 있다.

다양성

테이블 내의 데이터는 성능을 위하여 적절한 분산 전략과 테이블 저장 공간 정의 방식에 따라 파티 션(Partition), 클러스터(Cluster), 인덱스 구성 테이블(IOT, Index Organized Table)등 여러 형태로 정의될 수 있다.

보안성

테이블은 권한과 사용에 따라 제한된 범위의 사용자에게 테이블 단위, 칼럼 단위로 접근, 생성, 변경, 삭제 규칙이 정의되어야 한다.

논리성

테이블의 추가와 칼럼의 추가는 반드시 논리 데이터 모델을 참조하여 반영되어야 한다. 논리 데이터 모델을 근거로 하지 않은 DBMS상의 테이블과 칼럼의 추가는 무분별한 중복 데이터를 양산하 게 되어 결과적으로 데이터의 품질을 보장할 수 없다.

데이터베이스 관리자는 관리 기준에 따라 성능과 보안을 고려하여 테이블의 데이터를 관리해야 하 고 개발자나 사용자의 편의에 따라 무분별하게 테이블이 생성되는 것을 적절하게 제한하여야 한다. 테이블 생성에 대한 예로 [그림 6-2-10]을 들 수 있다.

제약 조건

제약 조건은 NOT NULL, DEFAULT, FOREIGN KEY CONSTRAINT, CHECK 조건 등의 비즈니스 규칙은 칼럼에 정의할 것을 권장하나 테이블 간의 관계 적용 제약 규칙은 애플리케이션과 병 행하여 적용할 수 있으며, 다음과 같은 기준에 따라 관리되어야 한다.

NOT NULL

테이블에 데이터 생성시 데이터가 반드시 존재해야 하는 칼럼을 정의한다.

DEFAULT

데이터가 반드시 존재해야 하는 칼럼에 확정 값을 정의할 수 없을 때 기본 데이터를 정의할 수 있다.

FOREIGN KEY

물리 데이터 모델에서 정의한 관계의 입력, 삭제, 생성 규칙을 정의하여 관리한다.

CHECK

특정 칼럼에는 미리 정의한 데이터 종류 혹은 범위 내의 데이터만 존재하도록 정의한다.

칼럼에 대한 제약 조건의 반영 역시 논리 데이터 모델의 속성 정의와 맞추어져야 한다. 관계에 대한 규칙은 애플리케이션에 의해 유지될 수 있다.

인덱스

인덱스는 논리 데이터 모델에는 반영되어 있지 않으나 데이터의 접근 속도를 빠르게 하기 위한데 이터 저장소의 하나이다. 인덱스는 업무 요건에 따라 다양하게 정의될 수 있다. 그러나 구성하는 칼럼의 중복도가 높을수록 저장 공간의 낭비와 데이터 입력, 삭제, 갱신시에 오히려 속도에 악영향을 줄 수 있다. 인덱스는 사용하는 상용 RDBMS의 종류에 따라 다양한 종류가 존재할 수 있다. 일반적 으로 B*Tree 형태로 유지된다. 인덱스는 저장 공간의 재사용이 거의 없으므로 주기적으로 인덱스를 재생성 하는 것을 권장한다.

트리거

트리거는 테이블과 연계되어서 미리 규정된 함수를 수행한다. 트리거의 생성 시 이전(Before) 키 를 사용하여 Tuple(Row, Record)에 어떤 이벤트가 발생하기 전에 기동될 수 있도록 규정할 수 있 으며, 반대로 이후(After) 키수도 있다. 트리거는 실 행될 때 다른 트리거를 연쇄적으로 기동할 수 있다. 따라서 트리거의 생성과 사용은 신중하게 정의되 어야 하며 잘못된 트리거의 사용으로 원하지 않는 결과를 얻을 수도 있다. 또한 동일한 테이블에 동 일한 이벤트를 지정하는 하나 이상의 트리거를 정의할 수 있으나, 이는 트리거의 기동 순서를 예측할 수 없게 하므로 보다 주의 깊은 관리가 필요하다.

DB 링크

DB 링크(Link)는 원격지에 있는 데이터베이스를 연결하여 한 곳의 서버에서 다른 서버에 있는데 이터를 하나의 SQL문 내에서 다룰 수 있다. 분산 서버 환경에서 하나의 서버에서 다른 서버 혹은 다른 데이터베이스 인스턴스에 위치하는 테이블의 데이터를 손쉽게 호출하고자 할 때 정의한다. DB 링크가 제대로 생성되었으나 실제 질의시 연결에 실패하는 경우가 자주 발생하므로 실제 사용에서 작동 여부에 주의가 필요하다. 또한 DB 링크의 남용은 SQL 수행 속도의 저하를 가져올 수 있다.

프로시저

함수(Function)와 프로시저(Procedure)를 사용자가 정의하여 사용할 수 있다. 함수와 프로시저는 프로그램 SQL 문으로 작성되며 사용자 함수는 SQL 문과 더불어서, 프로시저는 해당 프로시저의 이름을 호출함으로써 사용할 수 있다. 테이블의 데이터는 SQL 문에 의해서 입력, 수정, 삭제가 수행 되나 복잡한 업무를 수행할 때 혹은 같은 유형의 SQL이 반복 사용될 때 사용자 업무에 맞게 개선된 프로그램 유형의 SQL을 함수나 프로시저로 정의한다. (함수와 프로시저가 공용성이 보다 강조되면 동의어를 선언하여 다른 스키마에서 정의한 함수와 프로시저의 재사용률을 높이도록 한다.) 함수나 프로시저 내에 잘못 사용한 SQL 문장은 전체적인 수행 속도를 크게 저하시킬 수 있음을 주의한다.

뷰

뷰(View)는 사용자 관점의 데이터를 보기 위하여 생성한 객체로 실제 물리적인 저장 공간을 필요로 하는 것이 아닌 사용자가 정의한 SQL문의 수행 결과를 보여주는 가상 데이터 영역이다. 상용 RDBMS의 종류에 따라 실제 물리적인 저장 공간을 갖는 뷰도 존재할 수 있다. 중요한 데이터에 대 한 접근 제한과 데이터베이스 복잡 완화, 복잡한 데이터베이스 디자인 숨김, 이질 데이터에 대한 분 산 질의를 포함한 복잡한 질의 단순화, 사용자 접근 관리 단순화 등을 위하여 생성한다. 뷰의 장점은 뷰의 단점이 될 수 있다. 복합적인 뷰는 사용자의 의도를 제대로 파악할 수 없고 전체적으로 수행되 는 SQL의 업무를 파악하기 힘들게 하며 속도에도 영향을 줄 수 있으므로 중첩 뷰의 사용과 너무 복 잡한 뷰의 사용은 자제해야 할 것이다.

동의어

동의어(Synonym)는 테이블에 대한 별명을 의미한다. 일반 동의어는 모든 유저가 만들 수 있고, 소 유권은 만든 자신만이 사용할 수 있다. 공용 동의어는 PUBLIC을 사용한 동의어로, 데이터베이스 관 리자만이 만들고 삭제할 수 있는 동의어이다. 주제 영역을 스키마로 정의했을 때 다른 스키마에 정의 했지만 업무상 자주 상호 참조해야 하는 테이블 데이터에 대하여 동의어를 정의할 수 있다. 동의어는 하나의 객체를 여러 스키마에서 공용으로 사용하고자 할 때 생성하는 것을 권장한다. 다른 스키마에 서 생성된 객체를 읽기 권한이 있어도 객체에 대한 접근이 번거로울 때 동의어를 사용하여 간편화할 수 있다.

롤

롤(Role)은 데이터베이스 객체에 대하여 생성, 삭제, 읽기 변경 권한에 대한 그룹(Group)을 만든다. 롤을 부여하고 제거할 수 있는 사람은 데이터베이스 관리자 뿐이다. 데이터베이스 객체를 관리할 때는 사용의 편리함도 중요하나 테이블 내의 데이터의 보안과 관리도 중요하다. 권한 그룹을 생성하여 데이터베이스를 사용하는 사용자의 권한을 적절히 제한하여 데이터베이스 객체를 보호하고 객체 내의 데이터를 보호하기 위해 롤을 정의할 수 있다. 상용 RDBMS에서는 자주 사용되는 것과 중요도가 높은 권한들을 묶어서 몇 개의 기본적인 롤을 제공한다. 롤의 사용은 기본적으로 상용 RDBMS에서 제공하는 것을 사용하는 것에서 시작하되 시스템 내의 보안 규칙에 따라 보다 다양하게 정의하여 사용할 수 있다.