스키마 정제와 정규형
- 정제되지 않은 스키마에서의 문제
- 중복 이상
어떤 데이터는 반복적으로 저장됨
- 갱신 이상
반복 저장된 데이터 중 한 투플을 갱신할 때 다른 모든 사본을 갱신하지 않으면 불일치 발생
- 삽입 이상
한 정보를 저장하려면 다른 정보도 같이 저장하여야 함
- 삭제 이상
어떤 정보를 지우면 다른 정보도 같이 삭제됨
스키마 정제
분해법
- 속성을 부자연스럽게 묶어서 한 릴레이션 스키마로 만들면 중복성이 발생
- 함수 종속(Functional Dependency)를 이용하여 상황을 식별
- 릴레이션을 더 작은 릴레이션의 모임으로 대치
- 작은 일레이션은 본래 릴레이션 속성의 부분집합으로 이루어 짐
- 분해의 문제
- 릴레이션의 분해가 필요한가?
- 제안된 정규형(Normal Form)으로 분해
- 분해했을 때 발생할 수 있는 문제는 무엇인가?
- 무손실 조인(Lossless Join) 성질에 따라 릴레이션 인스턴스 복구
- 종속성 유지(Dependency Preservation) 조건에 따라 계약 조건 유지
함수 종속
- 함수 종속(Functional Dependency)는 일종의 제약 조건
- 어떤 릴레이션 스키마를 R이라고 하고 X와 Y를 R에 속한 속성 집합이라고 하고, R의 인스턴스 r에 속한 투플 t1과 t2가 다음의 조건을 만족하면 FD X → Y가 존재한다고 한다
$t1.X = t2.X 이면 t1.Y = t2.Y$
- 한 릴레이션에 대해 적법한 인스턴스가 되려면 명세된 모든 FD를 만족해야 함
- 기본 키는 FD의 특수한 경우
- 키에 대한 속성은 X의 역할을 하게 되며, 나머지 속성은 Y의 역할을 함
- X → Y가 만족되고 X의 진부분집합 V가 있어서 V → Y가 만족되면 X는 수퍼키이지 키는 아님
스키마 정제
{EmpID} → {EmpID, Name, Parkingslot, Grade, WagePerHr, Workingtime}
E E N P G W H
- 등급에 따라 시간당 임금이 결정될 경우 두 FD가 존재
E → ENGWH G → W
- 부분적 함수 종속
- 기본 키 구성 속성의 일부에 종속되거나, 기본 키가 아닌 다른 속성에 종속되는 경우
- 이행적 함수 종속
- 함수 종속에 이행이 있을 때 (A → B, B → C = A → C)
- 완전 함수 종속
- 함수 종속 X → Y에서 X로부터 속성 A를 제거하면 함수 종속 X → Y가 성립하지 않는 경우
- 즉, 임의의 속성 A ∈ X 에 대해서 Y가 (X{A})에 함수 종속되지 않는 경우
함수 종속 이해
- 암스트롱의 공리
- 반사(Reflexivity): X ⊇ Y 이면 X → Y
- 첨가(Augmentation): X → Y 이면 어떠한 Z에 대해서도 XZ → YZ
- 이행(Transitivity): X → Y이고 X → Z 이면 X → Z
- 이외의 규칙
- 결합(Union): X → Y이고 X → Z 이면 X → YZ
- 분해(Decomposition): X → YZ이면, X → Y 이고 X → Z
정규화와 정규형
정규화
- 속성간의 종속성으로 인한 이상 현상이 발생하는 릴레이션을 분해하여 이상 현상을 없애는 과정
- 데이터의 중복 방지, 무결성을 충족하기 위한 데이터의 설계 방법
- 릴레이션 스키마가 어떤 정규형을 만족하는지 확인하는 테스트
- 정규화 원칙
- 무손실 법칙: 분해된 릴레이션이 표현하는 정보는 분해되기 전의 정보를 모두 포함
- 최소 데이터 중복 법칙: 이상 현상을 제거, 데이터 중복을 최소화
- 분리 법칙: 독립된 함수 종속은 독립된 릴레이션으로 분해
- 장점
- 이상 현상 해결
- 새 속성 추가시 데이터베이스 변경의 최소화
- 현실 세계의 개념간의 관게 표현
정규형
제 1정규형
- 도메인의 원소들이 나눌 수 없는 단위로 되어 있을 때 그 도메인은 원자적(Atomic)이라고 함
- 어떤 릴레이션 R에속한 모든 도메인이 원자적일 때 R은 제 1정규형(1NF)에 속함
제 2정규형
- 완전 함수 종속 개념에 기반을 둠
- 한 릴레이션이 1NF이고 기본 키에 속하지 않은 속성이 기본 키에 완전 함수 종속되는 경우
제 3정규형
- 이행적 종속성(Transitive dependency) 개념에 기반
- 릴레이션 스키마 R에서, 후보 키가 아니고 어떤 키의 부분집합도 아닌 속성 집합 Z가 있을 때,
- X → Z와 Z → Y가 만족될 때, 함수 종속 X → Y를 이행적 함수 종속이라고 부름
- Codd의 정의
- 릴레이션 스키마 R이 2NF이고
- R의 어떤 비주요 속성도 기본 키에 이행적으로 종속하지 않으면 R은 3NF에 속함
- 구분
- R: 릴레이션 스키마, X: R에 속하는 릴레이션 인스턴스의 부분집합, A: R의 속성일 때
- 다음 중 하나에 속하면 제 3 정규형에 속함
- A ∈ X, 즉 평범한 함수 종속
- X가 슈퍼키
- A가 R의 어떤 키의 일부
보안과 뷰
데이터베이스 보안
- 안전한 데이터베이스 응용 설계
- 보안(Security)
정보가 권한 없는 사용자에게 누출되어서는 안된다
- 무결성(Integrity)
권한 있는 사용자에게만 데이터의 수정이 허용된다
- 가용성(Availability)
권한 있는 사용자의 접근이 제한되어서는 안된다
- 명확하고 일관성 있는 보안 정책의 설정 필요
- DBMS는 데이터 보안에 대한 메커니즘을 제공
User 개체
- 데이터베이스 관리 시스템은 시스템에 대한 모든 권한을 가지는 관리 사용자를 가짐
- DBMS에 따라 관리 사용자가 세분화되는 방식이 다름
- 데이터베이스 관리 시스템은 데이터베이스의 사용자를 생성/관리
- 운영체제와 통합되거나, 독립적으로 관리
- 데이터베이스의 사용자는 데이터베이스에 대한 권한을 가짐
- 사용자 생성
CREATE USER <User ID> IDENTIFIED BY <Password>
접근 제어
- 대부분의 데이터베이스 사용자들은 자신의 업무를 수행하는데 필요한 데이터에만 접근
- DBMS는 크게 두 가지의 접근 제어 방식을 사용
- 재량 접근 제어(Discretionary Access Control)
- 특권(Privileges)이라는 접근 권한의 개념에 기반함
- 사용자에게 특권을 부여하는 메커니즘 사용
- 필수 접근 제어(Mandatory Access Control)
- 사용자 개개인에 따라 변경할 수 없는 시스템 전반에 걸친 정책 사용
- 모든 데이터베이스 개체에 비밀 등급을 매기고 사용자 마다 허가 등급을 부여
- SQL 1999 표준은 필수 접근 제어를 허용하지 않음
재량 접근 제어
- SQL1999 표준은 GRANT 명령과 REVOKE 명령을 통해 재량 접근 제어를 지원
- GRANT
- 사용자에게 기반 테이블이나 뷰에 대한 특권을 부여
GRANT <특권> ON <개체> TO <사용자> [WITH GRANT OPTIONS]
GRANT <특권> ON <개체> FROM <사용자> [CASCADE]
특권
- 특정 조치 또는 작업을 실행하는데 필요한 권한
- 권한이 부여된 사용자에는 개체를 작성하고, 소유한 개체에 접근하며, GRANT 문을 사용해 소유한 개체에 대한 권한을 다른 사용자에게 전달할 수 있음
필수 접근 제어
- 재량 접근 제어는 일반적으로 효과가 있으나 몇 가지 약점을 가지고 있음
- 권한 없는 불순한 사용자가 권한 있는 사용자로 하여금 민감한 데이터를 유출할 수 있도록 속일 수 있음
- 트로이 목마 방식에 특히 취약함
- 필수 접근 제어는 필수 데이터베이스 개체에 각각의 보안 등급을 지정함
- 테이블, 뷰, 투플, 필드 등 모든 개체는 개별 보안 등급을 가짐
- 모든 주체는 보안 등급에 해당하는 허가 등급이 지정됨
- 사용자, 프로그램 등의 주체는 허가 등급보다 높은 보안 등급을 가진 개체에는 접근 불가
- SQL 1999 표준은 필수 접근 제어를 지정하지 않음
뷰
- 관계 데이터베이스 관리 시스템의 매우 강력한 기능의 하나
- 접근 제어를 향상시키며, 논리적 데이터 독립성을 제공함
- 데이터베이스 개념 스키마의 변경을 외부 사용자에게 감추는 역할
- 보안 관점에서만 작성된 개체 형태는 아님
- 테이블과 같은 방식으로 동작하지만, 소속 투플이 실제로 데이터베이스에 저장된 것이 아님
- 필요할 때 마다 뷰 정의에 따라 계산됨
- 질의를 생성하거나 다른 뷰를 생성할 때 기본 뷰는 테이블과 같은 형태로 사용할 수 있음
뷰 생성과 삭제
- DDL 구문을 사용해 뷰 생성
- 읽기 전용 또는 업데이트 가능 상태로 정의
CREATE VIEW <뷰 이름> AS <쿼리 식>
DROP VIEW <뷰 이름>
뷰에 대한 갱신
- 사용자는 뷰와 기반 테이블을 갱신할 필요가 없어야 함
- SQL 92 표준에서는 뷰에 대한 갱신 기준을 정의
- 하나의 기반 테이블에 대해서 셀렉션 및 프로젝션 만으로 진행되고 집단 연산을 사용하지 않는 뷰에 대해서만 갱신을 허용
- 갱신 가능 뷰(Updateable View)
