데이터베이스를 공부하며 배운 내용들을 나름의 방식대로 정리합니다.
데이터베이스의 무결성이란
데이터의 정확성 또는 유효성을 의미
무결성 규칙의 종류
도메인 무결성 규칙: 주어진 속성의 값이 그 속성이 정의된 도메인에 속한 값이어야 한다.
ex) 전화번호 필드에는 숫자와 하이픈을 제외한 문자는 올 수 없다.릴레이션 무결성 규칙: 어느 한 튜플이 릴레이션에 삽입 가능한가 or 다른 릴레이션 간의 관계가 적절한가
ex) 어느 한 릴레이션이 다른 릴레이션의 기본키를 가리키는 외래키일 때, 기본키 릴레이션에 없는 값을 삽입할 수가 없다.
무결성 규칙 정의 방법 3가지
- 애트리뷰트 제약 조건
- 기본 테이블 제약 조건
주장(assertion): 제약조건을 위반하는 연산이 수행되지 않도록 하는 것
트리거(trigger)
'방아쇠' 를 뜻하는 트리거는 마치 방아쇠를 당겼을 때 총알이 나가듯이, 어떤 일이 일어나면 자동으로 실행되는 특별한 저장 프로시저를 의미한다.
트리거의 특징
- 테이블에 수정, 삭제, 삽입 등의 작업이 발생할 때 자동으로 작동함
- 직접 실행시킬 수 없다.
- IN, OUT 매개변수를 사용할 수 없다
- 하나의
트랜잭션(transaction) 이다.
트리거의 장점
- 사용자 정의 에러메시지 사용 가능
- 비정규화된 DB 테이블에서도 사용 가능
- 데이터의 전후 상태 비교 가능
- CHECK보다 더 복잡한 데이터 무결성 강화 가능
트리거 사용 시 고려사항
- 트리거는 실행 후, 제약조건은 실행 전 수행된다.
- 테이블은 여러 개의 트리거를 가질 수 있다.
- 테이블 소유자만이 트리거를 생성 및 제거할 수 있다.
- 트리거는 결과 세트를 리턴할 수 있다.
- 트리거는 다중 행 동작을 처리할 수 있다.
트리거 예시
CREATE TRIGGER STUDENT_INS
AFTER INSERT ON 학생
BEGIN UPDATE 학과테이블
SET 학생수 = 학생수 + 1
WHERE 학과코드 = NEW_STUDENT.학과코드;
END;
CREATE TRIGGER STUDENT_DEL
AFTER DELETE ON 학생
BEGIN UPDATE 학과테이블
SET 학생수 = 학생수 - 1
WHERE 학과코드 = OLD_STUDENT.학과코드;
END;보안
권한이 없는 데이터 엑세스, 악의적인 데이터 파괴 및 유출로부터 DB를 보호함
사용자마다 계정과 비밀번호를 부여하고, 특정 사용자에게 특정 부분에 특정 작업만 가능하도록 제한하는 방법이 있다. 이를 접근 제어 라고 한다.
DBMS는 특정 사용자에게 지정된 영역만 접근 가능하도록 통제할 수 있는 권한 관리 모듈 을 갖고 있다.
DBA의 역할
- DB 시스템 전체에 대한 보안
- 사용자에게 새로운 계정/암호 생성
- 어떤 사용자에게 권한을 부여/박탈
- 보안 사고 시 DB에 대한 책임 및 감사
데이터베이스 보안 기법
1) 권한 부여 테이블 사용
권한 부여 테이블(Authorization table)
각각의 사용자가 어떤 데이터 객체에 접근 가능하고, 어떤 연산을 수행 가능한지 표시한 하나의 테이블
2) 뷰 기법
민감한 데이터를 권한이 없는 사용자로부터 은닉함
CREATE VIEW 학생뷰
AS
SELECT 학번, 성명, 학과
FROM 학생
WHERE 학과 = '컴퓨터';약점 : 갱신이나 삽입, 삭제와 같은 연산에 제한이 있음
3) GRANT, REVOKE 기법
특정 데이터와 연산을 특정 사용자만 수행할 수 있게 권한 부여를 명세
- 테이블의 생성자 : 테이블에 대한 모든 권한을 가진다
- DBA : DBMS에 있는 모든 자원에 접근 권한을 가진다
테이블의 생성자와 DBA는 GRANT 문을 사용하여 다른 사용자에게 권한을 부여할 수 있다.
권한 부여 및 박탈 형식
GRANT 권한리스트 ON 객체 TO 사용자 [WITH GRANT OPTION]
REVOKE [GRANT OPTION FOR] 권한리스트 ON 객체 FROM 사용자 {CASCADE, RESTRICT}- WITH GRANT OPTION : 다른 사용자에게 권한을 줄 수 있는 권한을 준다
- GRANT OPTION FOR : 다른 사용자에게 권한을 줄 수 있는 권한 박탈
- CASCADE : 권한 부여 트리를 삭제 (이 사용자가 다른 사용자에게 준 권한도 삭제)
- RESTRICT : 지정한 권한을 제거 할 경우 타 사용자에게 영향이 가면 실패 처리
예시
GRANT SELECT, INSERT ON 학생 TO A;
REVOKE SELECT ON 학생 FROM B CASCADE;4) 데이터 암호화
허가 받지 않은 사람들이 내용을 쉽게 바꾸지 못하도록 데이터를 암호화
암호화 시스템
- 암호화 알고리즘 E : encryption algorithm
- 암호화키 K : encryption key
- 해독 알고리즘 D : decryption algorithm
- 평문 P (plaintext) : 원시 데이터
- 암호문 C (ciphertext) : 암호화된 결과
암호화 기법 1) 전치 암호화 기법
문자들을 일정한 간격으로 나누고 위치를 변경시킴
공백도 문자로 취급, ♭ 으로 표시
암호화 기법 2) 대체 암호화 기법
평문의 문자를 다른 문자 정보로 대체
그 외 암호화 방법
DES (Data Encryption Standard): 미국 정부가 일반 대중이 사용할 수 있도록 개발한 암호화 기법. 대체 암호화 기법 + 순열 사용공개키 암호화 기법 (Public Key Encryption): 암호키와 해독키 두 개의 키를 사용
mySQL에서 테이블 암호화 하기 : 마지막에 ENCRYPTION='Y' 옵션 추가
CREATE TABLE encryption_test (
id int,
txt varchar(100)
) ENCRYPTION='Y';회복
회복이란? 장애가 일어났을 때 데이터베이스를 장애 이전의 상태, 즉 일관된 상태 (consistent state) 로 복원시키는 것.
일관된 상태란? 데이터베이스에 오류나 모순이 없는 상태
장애란? 시스템이 정해진 명세대로 동작하지 않는 상태
장애의 종류에는 트랜잭션 장애, 시스템 장애, 미디어 장애 등이 있다.
장애의 원인에는 내부적 원인(프로그램 오류, 하드웨어/소프트웨어의 결함) 또는 외부적 원인(화재, 정전) 등이 있다.
데이터 저장 장치의 종류
휘발성 저장장치 (volatile storage): 메인 메모리, 시스템 고장 시 저장된 정보 유실비휘발성 저장장치 (nonvolatile storage): 디스크나 자기테이프, 시스템 고장 시에도 저장된 정보 유실 X, DB에서 디스크 많이 사용, 자기테이프는 주로 백업용안정 저장장치 (stable storage):RAID(Redendant Array of Inexpensive Disk) 기법 : 서로 다른 디스크에 블록 사본 저장
데이터베이스 입출력 연산
-
Input(B): 데이터 B가 포함되어 있는 디스크 블록을 메인 메모리로 이동시킴
요청에 의해(On demand) -
Output(B): 데이터 B가 포함되어 있는 버퍼 블록을 디스크 블록에 이동시켜 기록
버퍼 관리자에 의해(By Buffer Manager)
회복의 기본원리
덤프 (dump): 주기적으로 DB 전체를 다른 저장장치로 복제 (아카이빙)로그 (log): DB가 변경될 때마다 변경되는 데이터의 이전 값과 이후 값을 별도의 로그 파일에 저장
장애 발생 시 회복을 위한 조치
REDO
RE-DO, 즉 말그대로 재수행. DB 내용 자체가 손상된 경우에 사용
복사본과 로그 파일을 이용한 복구. 가장 최근에 덤프받은 복사본을 적재
이 복사본 이후에 일어난 변경만을 로그를 이용해 재수행
UNDO
UN-DO, 즉 DO를 취소함. DB가 손상되지는 않았으나 변경된 내용에 대한 신뢰성을 잃었을 경우에 사용
로그 파일을 이용하여 모든 변경사항들을 취소함
즉 DB를 원래 상태로 복원시키는 것!
변경 과정에서 수틀렸을 때, REDO는 변경 작업을 한번 더 수행, UNDO는 변경 사항을 취소.
데이터베이스 로그를 이용한 회복 기법
데이터베이스 로그 : 데이터베이스의 변경에 대한 기록
로그 레코드의 유형
<T, start>: 트랜잭션 T가 시작되었음을 기록<T, X, V1, V2>: 트랜잭션 T의 데이터 항목 X를 이전 값 V1에서 V2로 변경되었음을 기록<T, commit>: 트랜잭션 T가 모든 갱신을 성공적으로 완료했음을 기록<T, abort>: 트랜잭션 T가 철회되었음을 나타냄. 모든 변경사항을 취소
즉시 갱신 회복 기법 (immediate update)
데이터 변경 연산이 발생할 때마다 데이터 변경 결과를 데이터베이스에 반영함
트랜잭션 수행 중 실패가 발생해 트랜잭션을 철회해야 할 때 로그 파일을 참조해 UNDO 작업을 수행. 실행되기 전 상태로 되돌림
로그 레코드 값에서 이전 값이 사용됨
<트랜잭션ID, 데이터항목, 이전 값, 이후 값>
- 트랜잭션이 write를 실행할 경우 로그에 적절한 레코드 기록 후 Output 연산 실행
- T가 부분 완료할 경우
- 로그에 커밋 레코드 기록
- 로그가 데이터베이스 회복에 사용될 수 있기 위해서 로그 레코드가 기록되기 전에 데이터베이스 갱신 X
- 로그를 안정 저장소에 기록 후 Output 실행
- 만약 로그에
start만 있고commit레코드가 없으면 T는UNDO되어야 한다 - 만약 로그에
start와commit이 둘 다 있다면 T는REDO되어야 한다
T1이 commit하기 전에 시스템 붕괴 : T1 UNDO
T1이 commit되었고 T2가 commit하기 전에 시스템 붕괴 : T2 UNDO, T1 REDO
T2가 commit되었고 시스템 붕괴 : T1 REDO, T2 REDO
지연 갱신 회복 기법 (deferred update)
트랜잭션이 부분 완료될 때까지 모든 변경 사항을 로그 파일에만 저장함
만약 트랜잭션 수행 중 완료하기 전에 장애가 발생하면 로그에 저장된 정보는 무시하고 버림. 따라서 UNDO 연산이 필요 없음
즉 REDO 연산만 있으면 되므로 레코드에는 이전 값 필드가 필요 없음
<트랜잭션ID, 데이터항목, 이후 값>
- 만약 로그에
start만 있고commit이 없으면 DB에 저장된 내용이 없으므로 로그 폐기 - 만약 로그에
start와commit모두 있다면REDO
T1이 commit하기 전에 시스템 붕괴 : 아무 조치 X (반영이 되어있지 않음)
T1이 commit되었고 T2가 commit하기 전에 시스템 붕괴 : T1 REDO
T2가 commit되었고 시스템 붕괴 : T1 REDO, T2 REDO
commit된 작업에 대해서만 REDO
검사 시점 회복
로그를 이용한 기법에서 REDO와 UNDO 되어야 할 트랜잭션을 결정할 때 원칙적으로는 로그를 모두 분석해야 함. 이 방법은 시간이 너무 많이 걸리게 될 뿐만 아니라 할 필요가 없는 REDO 연산까지 반복하므로 비효율적임.
이러한 문제를 해결하기 위해 일정 간격마다 검사 시점(checkpoint)를 만들어 둔다.
트랜잭션을 하나하나 살펴보자
- T1 : 검사 시점 이전에 실행 완료되었으므로 회복 작업 필요 X
- T2 : 검사 시점 이전에 시작하여 장애 시점 이전에 완료되었으므로 검사 시점 c 이후에 발생된 변경 부분에 대해서만 REDO
- T3 : 검사 시점 이후에 시작하여 장애 시점 이전에 완료되었으므로 전체 REDO
- T4 : 검사 시점 이전에 시작하여 장애 시점까지 미완료 되었으므로 전체 UNDO (검사 시점 이전 수행부분까지 모두 UNDO)
- T5 : 검사 시점 이후에 시작하여 장애 시점까지 미완료 되었으므로 전체 UNDO
최근 검사 시점 이전에 끝남 -> 회복 작업 X
검사 시점 이후, 장애 시점 이전에 끝남 -> REDO
장애 시점까지 끝나지 않음 -> UNDO
미디어 회복
최근 디스크 이중화 및 삼중화를 통해 비휘발성 장치의 내용이 손상되는 경우까지 회복 개념을 만들어 놓음
