스키마 정제
개념설계 -> 스키마 정제 (Normal Form(NF) : 정규형) - Normalization이라고 함
정규화 - 함수 종속을 기반으로 생성(Functional Dependency)
1정규형 - 중복된 튜플 제거
2정규형 - 완전 함수 종속, 키에 대해 모든 컬럼이 종속성을 지님
3정규형 - 부분 함수 종속, 기본키를 제외한 컬럼에 대해 또 다른 컬럼이 종속성을 지님
- 이행적 함수 종속 이라고 함
- 삭제이상, 중복이상
- ER 모델에서 찾기 힘들다
BCNF 정규형
-----
다치종속 (Multi Dependency)
4정규형
조인종속 (Join Dependency)
5정규형대부분 3정규형까지 가고, BCNF도 대부분 안간다
비 정규화(Denormalization) - 필요에 따라 읽는 시간을 최적화 하기 위해 중복을 사용
스키마 정제 개요
중복 이상 - 어떤 데이터는 반복적으로 저장됨
갱신 이상 - 반복 저장된 데이터 중 한 투플을 갱신할 때 다른 모든 사본을 갱신하지 않으면 불일치 발생
삽입 이상 - 한 정보를 저장하려면 다른 정보도 같이 저장하여야 함
삭제 이상 - 어떤 정보를 지우면 다른 정보도 같이 삭제됨
분해법
속성을 부자연스럽게 묶어서 한 릴레이션 스키마로 만들면 중복성이 발생
함수 종속을 이용하여 상황 식별
릴레이션을 더 작은 릴레이션의 모임으로 대치
작은 일레이션은 본래 릴레이션 속성의 부분집합으로 이루어 짐분해의 문제
- 릴레이션 분해가 필요하면
제안된 정규형으로 분해 - 분해했을 때 발생할 수 있는 문제
무손실 조인 성질에 따라 릴레이션 인스턴스 복구 종속성 유지 조건에 따라 계약 조건 유지
3 정규화 기준으로 기본키 종속을 제외한 다른 함수적 종속이 발생하면 이를 이행적 함수적 종속 이라 한다
- S N A B C D (학번(기본키), 이름, 광역자치도, 시, 구, 동)
S <- NABCD
A <- BCD
S <- N
S <- ABCD
함수 종속
함수 종속은 일종의 제약 조건이다
어떤 릴레이션 스키마를 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 T 등급에 따라 시간당 임금이 결정될 경우 두 FD가 존재
- E → ENPGWT
- G → W
- E → 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이고 Y → Z 이면 X → Z
이외의 규칙
- 결합(Union): X → Y이고 X → Z 이면 X → YZ
- 분해(Decomposition): X → YZ이면, X → Y 이고 X → Z
정규화 - 속성간의 종속성으로 인한 이상현상 발생 릴레이션을 분해하여 이상 현상 제거
데이터의 중복 방지, 무결성을 충족하기 위한 데이터의 설계 방법
릴레이션 스키마가 어떤 정규형을 만족하는지 확인하는 테스트
정규화 원칙
- 무손실 법칙: 분해된 릴레이션이 표현하는 정보는 분해되기 전의 정보를 모두 포함
- 분해시 데이터가 손실되면 안됨 - 최소 데이터 중복 법칙: 이상 현상을 제거, 데이터 중복을 최소화
- 분리 법칙: 독립된 함수 종속은 독립된 릴레이션으로 분해
장점
- 이상 현상 해결 (삽입, 삭제, 갱식)
- 새 속성 추가시 데이터베이스 변경의 최소화
- 현실 세계의 개념간의 관게 표현
1 정규형 (1NF)
- 도메인의 원소들이 나눌 수 없는 단위로 되어 있을 때 그 도메인은 원자적(Atomic)이라고 함
- 어떤 릴레이션 R에속한 모든 도메인이 원자적일 때 R은 제 1정규형(1NF)에 속함
2 정규형 (2NF)
- 완전 함수 종속 개념에 기반
- 한 릴레이션이 1NF이고 기본키에 속하지 않은 속성이 기본키에 완전 함수 종속 되는 경우
3 정규형 (3NF)
-
이행적 종속성 개념에 기반
- 릴레이션 스키마 R에서, 후보 키가 아니고 어떤 키의 부분집합도 아닌 속성 집합 Z가 있을 때, X → Z와 Z → Y가 만족될 때, 함수 종속 X → Y를 이행적 함수 종속이라고 부름 -
구분
R: 릴레이션 스키마, X: R에 속하는 릴레이션 인스턴스의 부분집합, A: R의 속성일 때 다음 중 하나에 속하면 제 3 정규형에 속함 A ∈ X, 즉 평범한 함수 종속 X가 슈퍼키 A가 R의 어떤 키의 일부
4 Boyce-Code 정규형 (BCNF)
- 어떤 정규형이 3NF 이고, 모든 결정자 X 가 후보키인 유형
R: 릴레이션 스키마, X: R에 속하는 릴레이션 인스턴스의 부분집합, A: R의 속성일 때
R이 만족하는 모든 함수 종속 X → A가 다음 중 하나에 속하면 BCNF에 속함
A ∈ X, 즉 평범한 함수 종속
X가 슈퍼키tmi)
- 3정규형까지 정규화를 해버리면 너무 속도가 느릴 수 있다
- 1정규형, 2정규형 - 중복성을 최소한으로 할 수 있다
- 코드성 테이블을 정리할때는 select 절에 서브쿼리를 쓰면 속도를 빠르게 할 수 있다
보안과 뷰
지금까지 배운 SQL - DML, DDL, DCL중 DCL이 보안에 관련된 내용을 담고 있다
DB 보안 개요 - 보안, 무결성, 가용성
- 보안 : 정보가 권한 없는 사용자에게 누출되선 안된다
- 무결성 : 권한 있는 사용자에게만 데이터 수정 허용
- 가용성 : 권한 있는 사용자의 접근이 제한되선 안된다
User 개체
- DB 관리 시스템은 SYS에 대한 모든 권한을 가지는 관리 사용자를 가짐
- DBMS에 따라 관리자가 세분되는 방법이 다르다
- DBMS은 DB 사용자를 생성/관리한다
- DB 사용자는 DB에 대한 권한을 가진다
- 운영체제와 통합/독립 관리 둘다 가능
- 사용자 생성
접근제어 - DBMS는 크게 두가지의 접근 제어 방식 제공한다
재량 접근 제어(Discretionary Access Control)
- 특권이라는 접근권한이라는 개념에 기반하며, 사용자에게 특권을 부여하는 메커니즘 사용
필수 접근 제어(Mandatory Access Control)
- 사용자 개인에 따라 변경할 수 없는 시스템 전반에 걸친 정책
- 모든 DB 개체에 비밀 등급을 매기고 사용자마다 허가 등급 부여
재량 접근 제어 - Grant 명령과 Revoke 명령을 통해 재량 접근 제어 지원
Grant - 사용자에게 기반 테이블이나 뷰에 대한 특권을 부여
GRANT <특권> ON <개체> TO <사용자> [WITH GRANT OPTIONS]Revoke - 사용자에게 부여된 특원 허가를 취소
GRANT <특권> ON <개체> FROM <사용자> [CASCADE]특권 - 특정 조치 또는 작업을 실행하는데 필요한 권한
- 권한이 부여된 사용자에는 개체를 작성하고, 소유한 개체에 접근하며, GRANT 문을 사용해 소유한 개체에 대한 권한을 다른 사용자에게 전달할 수 있음
필수 특권 제어
재량 접근 제어는 몇가지 약점이 있음
- 권한 없는 사용자가 권한 있는 사용자에게 데이터를 유출하게 속일 수 있음
- 트로이 목마에 취약
필수 접근 제어는 필수 데이터베이스 개체 각각의 보안 등급 지정 - 테이블, 뷰, 튜플, 필드 등...
모든 주체는 보안등급에 해당하는 허가 등급이 지정됨 - 사용자, 프로그램 등 주체는 허가등급 보다 높은 보안 등급을 가진 개체에는 접근 불가
뷰(View)
- 뷰 : 저장장치에 물리적으로 존재하지 않지만 사용자에게 있는 것 처럼 간주되는, 하나 이상의 테이블로부터 유도된 가상의 테이블. 데이터의 논리적 독립성을 제공하는 데이터베이스 개체
보안 때문에 생성된게 아니라 외부 스키마에 대한 접근을 위해 만들어짐
하지만? 보안을 위해 써도 좋다
뷰 개요
접근 제어 향상, 논리적 데이터 독립성 제공
- 데이터베이스 개념 스키마의 변경을 외부 사용자에게 감춤
- 보안 관점에서만 작성된 개체 형태는 아니다!
테이블과 비슷하게 동작하지만... 해당(소속) 튜플이 실제 DB에 저장된 것이 아님
필요할 때 마다 View 정의에 따라 계산됨
질의를 수행하거나 다른 View를 생성할 때 기존 View 는 Table과 같은 형태로 사용 가능
create view A as B
select foo
from boo
where woo
뷰 갱신
뷰는 insert가 될 수 있게/안되게 설정 가능. 형태에 따라 다르다
사용자는 뷰와 기반 테이블을 갱신할 필요가 없어야한다(하지만 가능할 수도 있다)
- 하나의 기반 테이블에 대해서 셀렉션 및 프로젝션 만으로 진행되고 집단 연산을 사용하지 않는 뷰에 대해서만 갱신을 허용
- 갱신 가능 뷰(Updateable View)
