2장 물리 데이터베이스 설계
Section 88 인덱스 설계
1. 인덱스(Index) 개념
- 데이터 레코드를 빠르게 접근하기 위해 <키 값, 포인터> 쌍으로 구성되는 데이터 구조이다.
- 인덱스는 데이터가 저장된 물리적 구조와 밀접한 관계가 있다.
- 인덱스는 레코드가 저장된 물리적 구조에 접근하는 방법을 제공한다.
- 인덱스를 통해서 파일의 레코드에 대한 액세스를 빠르게 수행할 수 있다.
- 레코드의 삽입과 삭제가 수시로 일어나는 경우에는 인덱스의 개수를 최소화 하는 것이 효율적이다.
- 인덱스가 없으면 특정한 값을 찾기 위해 모든 데이터 페이지를 확인하는 TABLE SCAN이 발생한다.
- 기본키를 위한 인덱스를 기본 인덱스라 하고, 기본 인덱스가 아닌 인덱스들을 보조 인덱스라 한다. 대부분의 관계형 데이터베이스 관리 시스템에서는 모든 기본키에 대해서 자동적으로 기본 인덱스를 생성한다.
- 레코드의 물리적 순서가 인덱스의 엔트리 순서와 일치하게 유지되도록 구성되는 인덱스를 클러스터드(Clustered) 인덱스라고 한다.
- 인덱스는 인덱스를 구성하는 구조나 특징에 따라 트리 기반 인덱스, 비트맵 인덱스, 함수 기반 인덱스, 비트맵 조인 인덱스, 도메인 인덱스 등으로 분류된다.
※ 클러스터드 인덱스 / 넌클러스터드 인덱스
클러스터드 인덱스
- 인덱스 키의 순서에 따라 데이터가 정렬되어 저장되는 방식이다.
- 실제 데이터가 순서대로 저장되어 있어 인덱스를 검색하지 않아도 원하는 데이터를 빠르게 찾을 수 있다.
- 데이터 삽입, 삭제 발생 시 순서를 유지하기 위해 데이터를 재정렬해야 한다.
- 한 개의 릴레이션에 하나의 인덱스만 생성할 수 있다.
넌클러스터드 인덱스
- 인덱스의 키 값만 정렬되어 있을 뿐 실제 데이터는 정렬되지 않는 방식이다.
- 데이터를 검색하기 위해서는 먼저 인덱스를 검색하여 실제 데이터 위치를 확인해야 하므로 클러스터드 인덱스에 비해 검색 속도가 떨어진다.
- 한 개의 릴레이션에 여러 개의 인덱스를 만들 수 있다.
2. 트리 기반 인덱스
- 인덱스를 저장하는 블록들이 트리 구조를 이루고 있는 것으로, 상용 DBMS에서는 트리 구조 기반의 B+ 트리 인덱스를 주로 활용한다.
B 트리 인덱스
- 일반적으로 사용되는 인덱스 방식으로, 루트 노드에서 하위 노드로 키 값의 크기를 비교해 나가면서 단말 노드에서 찾고자 하는 데이터를 검색한다.
- 키 값과 레코드를 가리키는 포인터들이 트리 노드에 오름차순으로 저장된다.
- 모든 리프 노드는 같은 레벨에 있다.
B+ 트리 인덱스
- B+ 트리는 B트리의 변형으로 단말 노드가 아닌 노드로 구성된 인덱스 세트와 단말 노드로만 구성된 순차 세트로 구분된다.
- 인덱스 세트에 있는 노드들은 단말 노드에 있는 키 값을 찾아갈 수 있는 경로로만 제공되며, 순차 세트에 있는 단말 노드가 해당 데이터 레코드의 주소를 가리킨다.
- 인덱스 세트에 있는 모든 키 값이 단말 노드에 다시 나타나므로 단말 노드만을 이용한 순차 처리가 가능하다.
3. 비트맵 인덱스
- 인덱스 컬럼의 데이터를 Bit 값인 0 또는 1로 변환하여 인덱스 키로 사용하는 방법이다.
- 비트맵 인덱스의 목적은 키 값을 포함하는 로우(Row)의 주소를 제공하는 것이다.
- 비트맵 인덱스는 분포도가 좋은 컬럼에 적합하며, 성능 향상 효과를 어등ㄹ 수 있다.
- 데이터가 Bit로 구성되어 있기 때문에 효율적인 논리 연산이 가능하고 저장 공간이 작다.
- 비트맵 인덱스는 다중 조건을 만족하는 튜플의 개수 계산에 적합하다.
- 비트맵 인덱스는 동일한 값이 반복되는 경우가 많아 압축 효율이 좋다.
4. 함수 기반 인덱스
- 컬럼의 값 대신 컬럼에 특정 함수나 수식을 적용하여 산출된 값을 사용하는 것으로, B+ 트리 인덱스 또는 비트맵 인덱스를 생성하여 사용한다.
- 함수 기반 인덱스는 데이터를 입력하거나 수정할 때 함수를 적용해야 하므로 부하가 발생할 수 있다.
- 사용된 함수가 사용자 정의 함수일 경우 시스템 함수보다 부하가 더 크다.
- 함수 기반 인덱스는 대소문자, 띄어쓰기 등에 상관없이 조회할 때 유용하게 사용된다.
- 적용 가능한 함수의 종류 : 산술식(Arithmetic Expression), 사용자 저으이 함수, PL/SQL Fucntion, SQL Function, Package, C Callot 등
5. 비트맵 조인 인덱스
- 비트맵 조인 인덱스는 다수의 조인된 객체로 구성된 인덱스로, 단일 객체로 구성된 일반적인 인덱스와 액세스 방법이 다르다.
- 비트맵 조인 인덱스는 비트맵 인덱스와 물리적 구조가 동일하다.
6. 도메인 인덱스
- 개발자가 필요한 인덱스를 직접 만들어 사용하는 것으로, 확장형 인덱스라고도 한다.
- 개발자가 필요에 의해 만들었지만 프로그램에서 제공하는 인덱스처럼 사용할 수도 있다.
7. 인덱스 설계
- 인덱스를 설계할 때는 분명하게 드러난 컬럼에 대해 기본적인 인덱스를 먼저 저장한 후 개발 단계에서 필요한 인덱스의 설계를 반복적으로 진행한다.
인덱스 설계 순서
① 인덱스의 대상 테이블이나 컬럼 등을 선정한다.
② 인덱스의 효율성을 검토하여 인덱스 최적화를 수행한다.
③ 인덱스 정의서를 작성한다.
8. 인덱스 대상 테이블 선정 기준
- MULTI BLOCK READ 수에 따라 판단 (테이블 액세스시 메모리에 한 번에 읽어 들일 수 있는 블록의 수)
- 랜덤 액세스가 빈번한 테이블
- 특정 범위나 특정 순서로 데이터 조회가 필요한 테이블
- 다른 테이블과 순차적 조인이 발생되는 테이블
9. 인덱스 대상 컬럼 선정 기준
- 인덱스 컬럼의 분포도가 10~15% 이내인 컬럼
(분포도 = (컬럼값의 평균 Row 수/ 테이블의 총 Row 수)) X 100
- 분포도가 10~15% 이상이어도 부분 처리를 목적으로 하는 컬럼
- 입∙출력 장표 등에서 조회 및 출력 조건으로 사용되는 컬럼
- 인덱스가 자동 생성되는 기본키와 Unique 키 제약 조거을 사용한 컬럼
- 가능한 한 수정이 빈번하지 않은 클럽
- ORDER BY, GROUP BY, UNION이 빈번한 컬럼
- 분포도가 좁은 컬럼은 단독 인덱스로 생성
- 인덱스들이 자주 조합되어 사용되는 경우 하나의 결합 인덱스로 생성
10. 인덱스 설계 시 고려사항
- 새로 추가되는 인덱스는 기존 액세스 경로에 영향을 미칠 수 있다.
- 인덱스를 지나치게 많이 만들면 오버헤드가 발생한다.
- 넓은 범위를 인덱스로 처리하면 많은 오버헤드가 발생한다.
- 인덱스를 만들면 추가적인 저장 공간이 필요하다.
- 인덱스와 테이블 데이터의 저장 공간이 분리되도록 설계한다.
Section 89 뷰(View) 설계
1. 뷰(View)의 개요
- 사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 테이블로부터 유도된, 이름을 가지는 가상 테이블이다.
- 뷰는 저장장치 내에 물리적으로 존재하지 않지만, 사용자에게는 있는 것처럼 간주된다.
- 뷰는 데이터 보정 작업, 처리 과정 시험 등 임시적인 작업을 위한 용도로 활용된다.
- 뷰는 조인문의 사용 최소화로 사용상의 편의성을 최대화한다.
- 뷰를 생서하면 뷰 정의가 시스템 내에 저장되었다가 생성된 뷰 이름을 질의어에서 사용할 경우 질의어가 실행될 때 뷰에 정의된 기본 테이블로 대체되어 기본 테이블에 대해 실행된다.
2. 뷰의 특징
- 뷰는 기본 테이블로부터 유도된 테이블이기 때문에 기본 테이블과 같은 형태의 구조를 사용하며, 조작도 기본 테이블과 거의 같다.
- 뷰는 가상 테이블이기 때문에 물리적으로 구현되어 있지 않다.
- 데이터의 논리적 독립성을 제공할 수 있다.
- 필요한 데이터만 뷰로 정의해서 처리할 수 있기 때문에 관리가 용이하고 명령문이 간단해진다.
- 뷰를 통해서만 데이터에 접근하게 되면 뷰에 나타나지 않은 데이터를 안전하게 보호하는 효율적인 기법으로 사용할 수 있다.
- 기본 테이블의 기본키를 포함한 속성 집합으로 뷰를 구성해야만 삽입, 삭제, 갱신 연산이 가능하다.
- 일단 정의된 뷰는 다른 뷰의 정의에 기초가 될 수 있다.
- 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동으로 삭제된다.
3. 뷰의 장•단점
장점
- 논리적 데이터 독립성을 제공한다.
- 동일 데이터에 대해 동시에 여러 사용자의 상이한 응용이나 요구를 지원해 준다.
- 사용자의 데이터 관리를 간단하게 해준다.
- 접근 제어를 통한 자동 보안이 제공된다.
단점
- 독립적인 인덱스를 가질 수 없다.
- 뷰의 정의를 변경할 수 없다.
- 뷰로 구성된 내용에 대한 삽입, 삭제, 갱신 연산에 제약이 따른다.
4. 뷰 설계 순서
① 대상 테이블을 선정한다.
- 외부 시스템과 인터페이스에 관여하는 테이블
- CRUD 매트릭스를 통해 여러 테이블이 동시에 자주 조인되어 접근되는 테이블
- SQL문 작성 시 거의 모든 문장에서 인라인 뷰 방식으로 접근되는 테이블
② 대상 컬럼을 선정한다.
- 보안을 유지해야 하는 컬럼은 주의하여 선별한다.
③ 정의서를 작성한다.
5. 뷰 설계 시 고려 사항
- 테이블 구조가 단순화 될 수 있도록 반복적으로 조인을 설정하여 사용하거나 동일한 조건절을 사용하는 테이블을 뷰로 생성한다.
- 동일한 테이블이라도 업무에 따라 테이블을 이용하는 부분이 달라질 수 있으므로 사용할 데이터를 다양한 관점에서 제시해야 한다.
- 데이터의 보안 유지를 고려하여 설계한다.
Section90 클러스터 설계
1. 클러스터(Cluster)의 개요
- 클러스터는 데이터 저장 시 데이터 액세스 효율을 향상시키기 위해 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 물리적 저장 방법이다.
- 클러스터링키로 지정ㄷ왼 컬럼 값의 순서대로 저장되고, 여러 개의 테이블이 하나의 클러스터에 저장된다.
2. 클러스터의 특징
- 클러스터링 된 테이블은 데이터 조회 속도는 향상시키지만 데이터 입력, 수정, 삭제에 대한 성능은 저하시킨다.
- 클러스터는 데이터의 분포도가 넓을수록 유리하다.
- 데이터 분포도가 넓은 테이블을 클러스터링 하면 저장 공간을 절약할 수 있다.
- 클러스터링된 테이블은 클러스터링키 열을 공유하므로 저장 공간이 줄어든다.
- 대용량을 처리하는 트랜잭션은 전체 테이블을 스캔하는 일이 자주 발생하므로 클러스터링을 하지 않는 것이 좋다.
- 처리 범위가 넓은 경우에는 단일 테이블 클러스터링을, 조인이 많이 발생하는 경우에는 다중 테이블 클러스터링을 사용한다.
- 파티셔닝된 테이블에는 클러스터링을 할 수 없다.
- 클러스터링을 하면 비슷한 데이터가 동일한 데이터 블록에 저장되기 때문에 디스크 I/O가 줄어든다.
- 클러스터링된 테이블에 클러스터드 인덱스를 생성하면 접근 성능이 향상된다.
3. 클러스터 대상 테이블
- 분포도가 넓은 테이블
- 대량의 범위를 자주 조회하는 테이블
- 입력, 수정, 삭제가 자주 발생하지 않는 테이블
- 자주 조인되어 사용되는 테이블
- ORDER BY, GROUP BY, UNION이 빈번한 테이블
Section 91 파티션 설계
1. 파티션의 개요
- 데이터베이스에서 파티션은 대용량의 테이블이나 인덱스를 작은 논리적 단위인 파티션으로 나누는 것을 말한다.
- 대용량 DB의 경우 중요한 몇 개의 테이블에만 집중되어 데이터가 증가되므로, 이런 테이블들을 작은 단위로 나눠 분산시키면 성능 저하를 방지할 뿐만 아니라 데이터 관리도 쉬워진다.
- 테이블이나 인덱스를 파티셔닝 하면 파티션키 또는 인덱스키에 따라 물리적으로 별도의 공간에 데이터가 저장된다.
- 데이터 처리는 테이블 단위로 이뤄지고, 데이터 저장은 파티션별로 수행된다.
2. 파티션의 장•단점
장점
- 데이터의 접근 시 액세스 범위를 줄여 쿼리 성능이 향상된다.
- 파티션별로 데이터가 분산되어 저장되므로 디스크의 성능이 향상된다.
- 파티션별로 백업 및 복구를 수행하므로 속도가 빠르다.
- 시스템 장애 시 데이터 손상 정도를 최소화할 수 있다.
- 데이터 가용성이 향상된다.
- 파티션 단위로 입•출력을 분산시킬 수 있다.
단점
- 하나의 테이블을 세분화하여 관리하므로 세심한 관리가 요구된다.
- 테이블간 조인에 대한 비용이 증가한다.
- 용량이 작은 테이블에 파티셔닝을 수행하면 오히려 성능이 저하된다.
3. 파티션의 종류
- 파티션의 종류는 파티셔닝 방식에 따라 범위 분할, 해시 분할, 조합 분할 등으로 나뉜다.
범위 분할
- 지정한 열의 값을 기준을 ㅗ분할한다.
해시 분할
- 해시 함수를 적용한 결과 값에 따라 데이터를 분할한다.
- 특정 파티션에 데이터가 집중되는 범위 분할의 단점을 보완한 것으로, 데이터를 고르체 분산할 때 유용하다.
- 특정 데이터가 어디에 있는지 판단할 수 없다.
- 고객번호, 주민번호 등과 같이 데이터가 고른 컬럼에 효과적이다.
조합 분할
- 범위 분할로 분할한 다음 해시 함수를 적용하여 다시 분할하는 방식이다.
- 범위 분할한 파티션이 너무 커서 관리가 어려울 때 유용하다.
4. 파티션키 선정 시 고려 사항
- 파티션키는 테이블 접근 유형에 따라 파티셔닝이 이뤄지도록 선정한다.
- 데이터 관리의 용이성을 위해 이력성 데이터는 파티션 생성주기와 소멸주기를 일치시켜야 한다.
- 매일 생성되는 날짜 컬럼, 백업의 기준이 되는 날짜 컬럼, 파티션 간 이동이 없는 컬럼, I/O 병목을 줄일 수 있는 데이터 분포가 양호한 컬럼 등을 파티션키로 선정한다.
5. 인덱스 파티션
- 인덱스 파티션은 파티션된 테이블의 데이터를 관리하기 위해 인덱스를 나눈 것이다.
- 인덱스 파티션은 파티션된 테이블의 종속 여부에 따라 Local Partitioned Index와 Global Partitioned Index로 나뉜다.
Local Partitioned Index : 테이블 파티션과 인덱스 파티션이 1:1 대응되도록 파티셔닝한다.
Global Partitioned Index : 테이블 파티션과 인덱스 파티션이 독립적으로 구성되도록 파티셔닝한다.
- Local Partitioned Index가 Global Partitioned Index에 비해 데이터 관리가 쉽다.
- 인덱스 파티션은 인덱스 파티션키 컬럼의 위치에 따라 Prefixed Partitioned Index와 Non-prefixed Partitioned Index로 나뉜다.
Prefixed Partitioned Index : 인덱스 파티션키와 인덱스 첫 번째 칼럼이 같다.
Non-prefixed Partitioned Index : 인덱스 파티션키와 인덱스 첫 번째 칼럼이 다르다.
Section 93 분산 데이터베이스 설계
1. 분산 데이터베이스 정의
- 논리적으로는 하나의 시스템에 속하지만 물리적으로는 네트워크를 통해 연결된 여러 개 컴퓨터 사이트에 분산되어 있는 데이터베이스를 말한다.
- 분산 데이터베이스는 데이터의 처리나 이용이 많은 지역에 데이터베이스를 위치시킴으로써 데이터의 처리가 가능한 해당 지역에서 해결될 수 있도록 한다.
2. 분산 데이터베이스의 구성 요소
분산 처리기 : 자체적으로 처리 능력을 가지며, 지리적으로 분산되어 있는 컴퓨터 시스템을 말한다.
분산 데이터베이스 : 지리적으로 분산되어 있는 데이터베이스로서 해당 지역의 특성에 맞게 데이터베이스가 구성된다.
통신 네트워크 : 분산 처리기들을 통신망으로 연결하여 논리적으로 하나의 시스템처럼 작동할 수 있도록 하는 통신 네트워크를 말한다.
3. 분산 데이터베이스 설계 시 고려 사항
- 작업부하의 노드별 분산 정책
- 지역의 자치성 보장 정책
- 데이터의 일관성 정책
- 사이트나 회선의 고장으로부터의 회복 기능
- 통신 네트워크를 통한 원격 접근 기능
4. 분산 데이터베이스의 목표
- 위치 투명성(Location Transparency) : 액세스하려는 데이터베이스의 실제 위치를 알 필요 없이 단지 데이터베이스의 논리적인 명칭만으로 액세스할 수 있다.
- 중복 투명성(Replication Transparency) : 동일 데이터가 여러 곳에 중복되어 있어라도 사용자는 마치 하나의 데이터만 존재하는 것처럼 사용하고, 시스템은 자동으로 여러 자료에 대한 작업을 수행한다.
- 병행 투명성(Concurrency Transparency) : 분산 데이터베이스와 관련된 다수의 트랜잭션들이 동시에 실현되더라도 그 트랜잭션의 결과는 영향을 받지 않는다.
- 장애 투명성(Failure Transparency) : 트랜잭션, DBMS, 네트워크, 컴퓨터 장애에도 불구하고 트랜잭션을 정확하게 처리한다.
5. 분산 데이터베이스의 장•단점
장점
- 지역 자치성이 높다.
- 자료의 공유성이 향상된다.
- 분산 제어가 가능하다.
- 시스템 성능이 향상된다.
- 중앙 컴퓨터의 장애가 전체 시스템에 영향을 끼치지 않는다.
- 효율성와 융통성이 높다.
- 신뢰성 및 가용성이 높다.
- 점진적 시스템 용량 확장이 용이하다.
단점
- DBMS가 수행할 기능이 복잡하다.
- 데이터베이스 설계가 어렵다.
- 소프트웨어 개발 비용이 증가한다.
- 처리 비용이 증가한다.
- 잠재적 오류가 증가한다.
6. 분산 데이터베이스 설계
- 분산 데이터베이스 설계는 애플리케이션이나 사용자가 분산되어 저장된 데이터에 접근하게 하는 것을 목적으로 한다.
- 잘못 설계된 분산 데이터베이스는 복잡성 증가, 응답 속도 저하, 비용 증가 등의 문제가 발생한다.
- 분산 데이터베이스의 설게는 전역 관계망을 논리적 측면에서 소규모 단위로 분할한 후, 분할된 결과를 복수의 노드에 할당하는 과정으로 진행된다. 노드에 할당된 소규모 단위를 분할(Fragment)이라 부른다.
- 분산 설계 방법에는 테이블 위치 분산, 분할(Fragmentation), 할당(Allocation)이 있다.
7. 테이블 위치 분산
- 데이터베이스의 테이블을 각기 다른 서버에 분산시켜 배치하는 방법을 의미한다.
- 테이블 위치를 분산할 때는 테이블의 구조를 변경하지 않으며, 다른 데이터베이스의 테이블과 중복되지 않게 배치한다.
- 데이터베이스의 테이블을 각각 다른 위치에 배치하려면 해당 테이블들이 놓일 서버들을 미리 설정해야 한다.
8. 분할(Fragment)
- 분할은 테이블의 데이터를 분할시켜 분산시키는 것이다.
분할 규칙
- 완전성(Completeness) : 전체 데이터를 대상으로 분할해야 한다.
- 재구성(Reconstruction) : 분할된 데이터는 관계 연산을 활용하여 본래의 데이터를 재구성할 수 있어야 한다.
- 상호 중첩배제(Dis-jointness) : 분할된 데이터는 서로 다른 분할의 항목에 속하지 않아야 한다.
주요 분할 방법
- 수평 분할 : 특정 속성의 값을 기준으로 행(Row) 단위로 분할
- 수직 분할 : 데이터 컬럼(속성) 단위로 분할
9. 할당(Allocation)
- 할당은 동일한 분할을 여러 개의 서버에 생성하는 분산 방법으로, 중복이 없는 할당(Allocation)과 중복이 있는 할당(Allocation)으로 나뉜다.
비중복 할당 방식
- 최적의 노드를 선택해서 분산 데이터베이스의 단일 노드에서만 분할이 존재하도록 하는 방식이다.
- 일반적으로 애플리케이션에는 릴레이션을 배타적 분할로 분리하기 힘든 요구가 포함되므로 분할된 테이블 간의 의존성은 무시되고 비용 증가, 성능 저하 등의 문제가 발생할 수 있다.
- 중복 할당 방식 : 동일한 테이블을 다른 서버에 복제하는 방식으로, 일부만 복제하는 부분 복제와 전체를 복제하는 완전 복제가 있다.
Section 96 데이터베이스 보안 -접근 통제
1. 접근통제
- 데이터가 저장된 객체와 이를 사용하려는 주체 사이의 정보 흐름을 제한하는 것.
- 접근 통제는 데이터에 대해 다음과 같은 통제를 함으로써 자원의 불법적인 접근 및 파괴를 예방한다.
- 비인가 사용자의 접근 감시
- 접근 요구자의 사용자 식별
- 접근 요구의 정당성 확인 및 기록
- 보안 정책에 근거한 접근의 승인 및 거부 등
- 접근 통제 기술에는 임의 접근통제(DAC), 강제 접근통제(MAC)가 있다.
임의 접근통제(Discretioanry Access Control)
- 임의 접근통제는 데이터에 접근하는 사용자의 신원에 따라 접근 권한을 부여하는 방식이다.
- 통제 권한이 주체에 있어 주체가 접근통제 권한을 지정하고 제어할 수 있다.
- 일반적으로 특정 객체에 대한 조작권한은 데이터베이스 관리 시스템으로부터 부여받지만 임의 접근 통제에서는 객체를 생성한 사용자가 생성된 객체에 대한 모든 권한을 부여받고, 부여된 권한을 다시 사용자에게 허가할 수도 있다.
- 임의 접근통제에 사용되는 SQL 명령어에는 GRANT와 REVOKE가 있다.
강제 접근통제(Mandatory Access Control) :
- 강제 접근통제는 주체와 객체의 등급을 비교하여 접근 권한을 부여하는 방식이다.
- 제3가자 접근통제 권한을 지정한다.
- 데이터베이스 객체별로 보안 등급을 부여할 수 있고, 사용자별로 인가 등급을 부여할 수 있다.
- 주체는 자신보다 보안 등급이 높은 객체에 대해 읽기, 수정, 등록이 모두 불가능하고, 보안 등급이 같은 객체에 대해서는 읽기, 수정, 등록이 가능하고, 보안 등급이 낮은 객체는 읽기가 가능하다.
- 접근 통제의 3요소는 접근통제 정책, 접근통제 매커니즘, 접근통제 보안모델이다.
2. 접근통제 정책
- 어떤 주체가(Who) 언제(When), 어디서(Where), 어떤 객체(what)에게, 어떤 행위(How)에 대한 허용 여부를 정의하는 것으로, 신분 기반 정책, 규칙 기반 정책, 역할 기반 정책이 있다.
신분 기반 정책
- 주체나 그룹의 신분에 근거하여 객체의 접근을 제한하는 방법으로, IBP와 GBP가 있다.
IBP(Individual-Based Policy) : 최소 권한 정책으로, 단일 주체에 하나의 객체에 대한 허가를 부여한다.
GBP(Group-Based Policy) : 복수 주체에 하나의 객체에 대한 허가를 부여한다.
규칙 기반 정책
- 주체가 갖는 권한에 근거하여 객체의 접근을 제한하는 방법으로, MLP와 CBP가 있다.
MLP(Multi-Level Policy) : 사용자 및 객체별로 지정된 기밀 분류에 따른 정책
CBP(Compartment-Based Policy) : 집단별로 지정된 기밀 허가에 따른 정ㅇ책
역할 기반 정책
- GBP의 변형된 정책으로, 주체의 신분이 아니라 주체가 맡은 역할에 근거하여 객체의 접근을 제한하는 방법이다.
3. 접근통제 매커니즘
- 정의도니 접근통제 정책을 구현하는 기술적인 방법으로, 접근통제 목록, 능력 리스트, 보안 등급, 패스워드, 암호화 등이 있다.
- 접근통제 목록(Access Control List): 객체를 기준으로 특정 객체에 대해 어떤 주체가 어떤 행위를 할 수 있는지를 기록한 목록이다.
- 능력 리스트(Capability List) : 주체를 기준으로 주체에게 허가된 자원 및 권한을 기록한 목록이다.
- 보안 등급(Security Level) : 주체나 객체 등에 부여된 보안 속성의 집합으로, 이 등급으 기반으로 접근 승인 여부가 결정된다.
- 패스워드 : 주체가 자신임을 증명할 때 사용하는 인증 방법이다.
- 암호화 : 데이터를 보낼 때 지정된 수신자 이외에는 내용을 알 수 없도록 평문을 암호문으로 변환하는 것으로, 무단 도용을 방지하기 위해 주로 사용된다.
4. 접근통제 보안 모델
- 보안 정책을 구현하기 위한 정형화 모델로, 기밀성 모델, 무결성 모델, 접근통제 모델이 있다.
기밀성 모델
- 군사적인 목적으로 개발된 최초의 수학적 모델로, 기밀성 보장이 최우선인 모델이다.
- 군대 시스템 등 특수한 환경에서 주로 사용된다.
제약 조건
- 단순 보안 규칙: 주체는 자신보다 높은 등급의 객체를 읽을 수 없다.
- ★-보안 규칙 : 주체는 자신보다 낮은 등급의 객체에 정보를 쓸 수 없다.
- 강한 ★ 보안 규칙 : 주체는 자신과 등급이 다른 객체를 읽거나 쓸 수 없다.
무결성 모델
- 기밀성 모델에서 발생하는 불법적인 정보 변경을 방지하기 위해 무결성을 기반으로 개발된 모델이다.
- 데이터 일관성 유지에 중점을 두어 개발되었다.
- 기밀성 모델과 동일하게 주체 및 객체의 보안 등급을 기반으로 한다.
제약 조건
- 단순 무결성 규칙 : 주체는 자신보다 낮은 등급의 객체를 읽을 수 없다.
- ★-무결성 규칙 : 주체는 자신보다 높은 등급의 객체에 정보를 쓸 수 없다.
접근통제 모델
- 접근통제 매커니즘을 보안 모델로 발전시킨 것으로, 대표적으로 접근통제 행렬(Access Control Matrix)이 있다.
접근통제 행렬
- 임의적인 접근통제를 관리하기 위한 보안 모델로, 행은 주체, 열은 객체 즉, 행과 열로 주체와 객체의 권한 유형을 나타낸다.
행 : 주체로서 객체에 접근을 시도하는 사용자이다.
열 : 객체로서 접근통제가 이뤄지는 테이블, 컬럼, 뷰 등과 같은 데이터베이스의 개체이다.
규칙 : 주체가 객체에 대하여 수행하는 입력, 수정, 삭제 등의 데이터베이스에 대한 조작이다.
5. 접근통제 조건
- 접근통제 매커니즘의 취약점을 보완하기 위해 접근통제 정책에 부가하여 적용할 수 있는 조건이다.
- 값 종속 통제(Value-Dependent Control) : 일반적으론느 객체에 저장된 값에 상관없이 접근통제를 동일하게 허용하지만 객체에 저장된 값에 따라 다르게 접근통제를 허용해야 하는 경우에 사용한다.
- 다중 사용자 통제(Multi-User Control) : 지정된 객체에 다수의 사용자가 동시에 접근을 요구하는 경우에 사용된다.
- 컨텍스트 기반 통제(Context-Based Control) : 특정 시간, 네트워크 주소, 접근 경로, 인증 수준 등에 근거하여 접근을 제어하는 방법으로, 다른 보안 정책과 결합하여 보안 시스템의 취약점을 보완할 때 사용된다.
6. 감사 추적
- 사용자나 애플리케이션이 데이터베이스에 접근하여 수행한 모든 활동을 기록하는 기능이다.
- 감사 추적은 오류가 발생한 데이터베이스를 복구하거나 부적절한 데이터 조작을 파악하기 위해 사용된다.
- 감사 추적 시 실행한 프로그램, 사용자, 날짜 및 시간, 접근한 데이터의 이전 값 및 이후 값 등이 저장된다.
Section 99 논리 데이터 모델의 물리 데이터 모델 변환
1. 테이블(Table)
- 테이블은 데이터를 저장하는 데이터베이스의 가장 기본적인 오브젝트이다.
- 테이블은 컬럼(Column, 열)과 로우(Row, 행)로 구성되며, 컬럼에는 지정된 유형에 따라 데이터가 저장된다.
- 테이블의 구성 요소
로우(Row) : 튜플 인스턴스, 어커런스라고도 한다.
컬럼(Column) : 각 속성 항목에 대한 값을 저장한다.
기본키(Primary key) :기본키는 후보키 중에서 선택한 주키이며 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성이다.
외래키(Foreign key) : 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합을 의미한다. 한 릴레이션에 속한 속성 A와 참조 릴레이션의 기본키인 B가 동일한 도메인 상에서 정의되었을 때의 속성 A를 외래키라고 한다.
2. 엔티티(Entity)를 테이블로 변환
- 논리 데이터 모델에서 정의된 엔티티를 물리 데이터 모델의 테이블로 변환하는 것이다.
- 엔티티를 테이블로 변환한 후 테이블 목록 정의서를 작성한다.
- 테이블 목록 정의서: 전체 테이블을 목록으로 요약 관리하는 문서로, 테이블 목록이라고도 한다.
엔티티 – 테이블
속성 – 컬럼
주 식별자 – 기본키
외부 식별자 – 외래키
관계 – 관계
변환 시 고려사항
- 일반적으론느 테이블과 엔티티 명칭은 동일하게 하는 것을 권고한다.
- 엔티티는 주로 한글명을 사용하지만 테이블은 소스 코드의 가독성을 위해 영문명을 사용한다.
- 메타 데이터 관리 시스템에 표준화된 용어가 있을 때는 메타에 등록된 단어를 사용하여 명명한다.
3. 슈퍼타입/서브타입을 테이블로 변환
- 논리 데이터 모델에서 이용되는 형태이므로 물리 데이터 모델을 설계할 때는 슈퍼타입/서브타입을 테이블로 변환해야 한다.
- 슈퍼타입/서브타입 모델을 테이블로 변환하는 방법에는 슈퍼타입 기준 테이블 변환, 서브타입 기준 테이블 변환, 개별타입 기준 테이블 변환이 있다.
슈퍼타입 기준 테이블 변환
- 서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만드는 것
- 서브타입에 속성이나 관계가 적을 경우에 적용하는 방법으로, 하나로 통합된 테이블에는 서브타입의 모든 속성이 포함되어야 한다.
장점
- 데이터 액세스가 상대적으로 용이하다.
- 뷰를 이용하여 각각의 서브타입만을 액세스하거나 수정할 수 있다.
- 서브타입 구분이 없는 임의 집합에 대한 처리가 용이하다.
- 여러 테이블을 조인하지 않아도 되므로 수행 속도가 빨라진다.
- SQL 문장 구성이 단순해진다.
단점
- 테이블의 컬럼이 증가하므로 디스크 저장 공간이 증가한다.
- 처리마다 서브타입에 대한 구분(TYPE)이 필요한 경우가 많이 발생한다.
- 인덱스 크기의 증가로 인덱스 효율이 떨어진다.
서브타입 기준 테이블 변환
- 슈퍼타입 속성들을 각각의 서브타입에 추가하여 서브타입을을 개별적인 테이블로 만드는 것이다.
- 서브타입 속성이나 관계가 많이 포함된 경우 작용한다.
장점
- 각 서브타입 속성들의 선택 사양이 명확한 경우에 유리하다.
- 처리할 때마다 서브타입 유형을 구분할 필요가 없다.
- 여러 개의 테이블로 통합하므로 테이블당 크기가 감소하여 전체 테이블 스캔 시 유리하다.
단점
- 수행 속도가 감소할 수 있다.
- 복잡한 처리를 하는 SQL의 통합이 어렵다.
- 부분 범위에 대한 처리가 곤란해진다.
- 여러 테이블을 통합한 뷰는 조회만 가능하다.
- UID(Unique Identifier, 식별자)의 유지 관리가 어렵다.
개별타입 기준 테이블 변환
- 슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환하는 것이다.
- 슈퍼타입과 서브타입들은 각각 1:1관계가 형성된다.
개별타입 기준 테이블 변환을 적용하는경우
- 전체 데이터에 대한 처리가 빈번한 경우
- 서브타입의 처리가 대부분 독립적으로 발생하는 경우
- 통합하는 테이블의 컬럼 수가 많은 경우
- 서브타입의 컬럼 수가 많은 경우
- 트랜잭션이 주로 슈퍼타입에서 발생하는 경우
- 슈퍼타입의 처리 범위가 넓고 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우
장점
- 저장 공간이 상대적으로 적다
- 슈퍼타입 또는 서브타입 각각의 테이블에 속한 정보만 조회하는 경우 문장 작성이 용이하다.
단점
- 슈퍼타입 또는 서브타입의 정보를 같이 처리하면 항상 조인이 발생하여 성능이 저하된다.
4. 속성을 컬럼으로 변환
- 논리 데이터 모델에서 정의한 속성을 물리 데이터 모델의 컬럼으로 변환한다.
일반 속성 변환
- 속성과 컬럼은 명칭이 반드시 일치할 필요는 없으나, 개발자와 사용자 간 의사소통을 위하여 가능한 한 표준화된 약어를 사용하여 일치시키는 것이 좋다.
- 칼럼명은 SQL의 예약어 사용을 피한다.
- 칼럼명은 SQL 가독성을 높이기 위해 가능한 한 짧게 지정한다.
- 복합 단어를 칼럼명으로 사용할 때는 미리 정의된 표준을 따른다.
- 테이블의 컬럼을 정의한 후에는 한 로우(Row)에 해당하는 샘플 데이터를 작성하여 컬럼의 정확성을 검증한다.
5. 관계를 외래키로 변환
- 논리 데이터 모델에서 정의된 관계는 기본키와 이를 참조하는 외래키로 변환한다.
1:1 관계
- 개체 A의 기본키를 개체 B의 외래키로 추가하거나 개체 B의 기본키를 개체 A의 외래키로 추가하여 표현한다.
1:M 관계
- 개체 A의 기본키를 개체 B의 외래키로 추가하여 표현하거나 별도의 테이블로 표현한다.
N:M 관계
- 릴레이션 A와 B의 기본키를 모두 포함한 별도의 릴레이션으로 표현한다.
이 때 생성된 별도의 릴레이션을 교차 릴레이션 또는 교차 엔티티라고 한다.
1:M 순환 관계
- 개체 A에 개체 A의 기본키를 참조하는 외래키 컬럼을 추가하여 표현한다.
6. 관리 목적의 테이블/컬럼 추가
- 논리 데이터 모델에는 존재하지 않는 테이블이나 컬럼을 데이터베이스의 관리 혹은 데이터베이스를 이용하는 프로그래밍의 수행 속도를 향상시키기 위해 물리 데이터 모델에 추가할 수 있다.
7. 데이터 타입 선택
- 논리 데이터 모델에서 정의된 논리적인 데이터 타입을 물리적인 DBMS의 물리적 특성과 성능을 고려하여 최적의 데이터 타입과 데이터의 최대 길이를 선택한다.
- 주요 타입에는 문자 타입, 숫자 타입, 날짜 타입이 있다.
'정보처리기사' 카테고리의 다른 글
| 정보처리기사 4과목 데이터베이스 구축 3장 응용 SW 기초 기술 활용 요점 정리 (0) | 2020.04.16 |
|---|---|
| 정보처리기사 4과목 프로그래밍 언어 활용 2장 요점 정리 (0) | 2020.04.16 |
| 정보처리기사 3과목 데이터베이스 구축 1장 논리 데이터베이스 설계 요점 정리 (0) | 2020.04.16 |
| 정보처리기사 2과목 소프트웨어 개발 5장 인터페이스 구현 요점 정리 (0) | 2020.04.16 |
| 정보처리기사 2과목 소프트웨어 개발 4장 애플리케이션 테스트 관리 요점 정리 (0) | 2020.04.16 |
