CS

데이터 베이스(2)

시롱시롱 2023. 4. 8. 16:24

Chap5. 데이터베이스 설계와 ER모델

  • 개념적 수준은 실제 구현과 관계없이 정보 사용의 모델을 개발하는 과정
  • 대표적인게, 엔티티-관계모델 (ER모델)
  • 구현 단계에서 사용되는 데이터 모델 : 관계,계층,네트워크 데이터 모델
  • 데이터 베이스 설계 단계
    • 요구 사항 수집,분석
    • 개념적 설계 (ER모델)
    • 논리적 설계 (여기서부터 DBMS 의존적 설계, 관계dbms에서는 er스키마를 릴레이션으로 사상)
    • 정규화
    • 물리적 설계
  • ER모델 : 실세계를 엔티티,애트리뷰트,관계로 표현함, 관계 데이터 모델로 쉽게 사상가능
    • 엔티티 : 사람,장소 등과 같이 독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체
    • 엔티티 타입은 관계 모델 릴레이션의 “내포”(스키마)에 해당, 엔티티 집합은 “외연”(상태?)에 해당
      • 강한 엔티티 타입 : 자신의 키를 사용해서 고유하게 엔티티들을 식별할 수 있는 엔티티 타입
        • 단일선 직사각형으로 표시
      • 약한 엔티티 타입 : 소유 엔티티 타입이 있어야 존재가능, 소유 엔티티 타입의 키를 이용해서 식별
        • 이중선 직사각형으로 표시
        • 부분 키가짐(한 사원의 dependent중에서는 고유하지만, 전체 사원의 dependent에서는 고유하지 않은 키) (점선)
    • 애트리뷰트 : 요구 명세에서 명사나 형용사로 표현됨, er diagram에서 타원형으로 나타냄
      • 단순 애트리뷰트 : 더 나눌 수 없는 애트리뷰트 (실선 타원)
      • 복합 애트리뷰트 : 두개 이상의 애트리뷰트로 이루어진 애트리뷰트(주소애트리뷰트 밑에 시 구 동)
      • 단일 값 애트리뷰트 : 엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트, 대부분이 단일 값임( 단순 애트리뷰트와 동일하게 표현 )
      • 다치 애트리뷰트 : 여러개의 값을 가질 수 있는 애트리뷰트 , 이중선 타원으로 표현
      • 저장된 애트리뷰트 : 다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트, 대부분이 저장된 애트리뷰트
      • 유도된 애트리뷰트 : 다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트, 점선 타원으로 표시
    • 관계 : 요구명세에서 동사, 다이아몬드로 표기
      • 관계의 특징을 나타내는 애트리뷰트를 가질 수 있음
      • 키 애트리뷰트는 없음
    • 차수 : 관계로 연결된 엔티티 타입의 개수를 의미 ( 관계 없으면 1진, 관계가 두개의 엔티티 타입을 연결하면 2진, 3개연결하면 3진..)
    • 카디날리티 : 한 엔티티가 참여 할 수 있는 관계의 수를 나타냄 (1:1, 1:N, M:N)
      • 실선위에 적음 (min,max)형태로, 여기서 min=0이면 관계 참여 의무가 없다는 뜻, max=*면 원하는 만큼 참여가능 하다는 뜻
    • 역할 : 하나의 관계에 하나의 엔티티가 재귀적으로 연관된 경우(순환적 관계)에 주로 씀 ( ex, supervisor, supervisee)
    • 전체참여 : E1이 전부다 E2와 R관계에서 참여하는 경우 (약한 엔티티 타입은 항상 관계에 전체 참여)
      • 이중 실선으로 표시

    • 이렇게 관계를 새발표기법으로 나타내기도 함
      • 엔티티 타입과 애트리뷰트를 사각형,타원으로 나타내는 것이 아닌, 직사각형에 맨위에 엔티티 타입을 적고 하위에 속하는 애트리뷰트들을 쭉 나열하는 것
  • ER스키마를 관계모델의 릴레이션으로 사상하기
    • 엔티티 타입, 단일 값 애트리뷰트 사상
      • 단계 1: 정규 엔티티 타입과 단일 값 애트리뷰트
        • 단순 애트리뷰트를 릴레이션으로 사상, 복합 애트리뷰트의 경우 복합 애트리뷰트를 구성하는 애들만 포함(시,구,동 ..)
      • 단계 2: 약한 엔티티 타입과 단일 값 애트리뷰트
        • 약한 엔티티 타입(이중 네모)을 찾아서 그놈의 부분키와 이 놈을 소유하는 엔티티 타입의 기본 키를 참조하는 외래키를 기본키로 가지는 릴레이션 생성
    • 2진 관계 타입 사상
      • 단계 3: 2진 1:1 관계 타입
        • 2진 1:1 관계인 애들을 찾아서, 두 릴레이션 중 하나를 선택해서 다른 놈의 기본키를 외래키로 포함시킴,(보통 전체 참여하는 애가 외래키를 추가하는 릴레이션 역할)
      • 단계 4: 정규 2진 1:N 관계 타입
        • N측에 해당하는 릴레이션에 1측에 해당하는 릴레이션의 기본키를 외래키로 포함시킴
      • 단계 5: 2진 M:N 관계 타입
        • 관계 R에 해당하는 릴레이션을 생성하고 해당 관계에 연관된 릴레이션들의 기본키를 외래키로하고 이 둘의 조합을 기본 키로 한다.
    • 3진 이상의 관계 타입 사상
      • 단계 6: 3진 관계 타입
        • M:N이랑 비슷함, 그냥 연관된 애들 전부 기본키를 외래키로 가지고 이걸로 기본키를 만듬, 관계 자체에 애트리뷰트 있으면 당연히 추가
    • 단계 7: 다치 애트리뷰트
      • 다치 애트리뷰트와 이 애트리뷰트가 속한 엔티티 타입의 기본키의 조합을 기본키로 하는 릴레이션 생성(그냥 다치 애트리뷰트 이름으로 생성함)

Chap6.물리적 데이터 베이스 설계

  • BLOB : 큰 크기의 데이터를 저장하는데 사용됨
  • 채우기 인수 : 블록에 레코드를 채우는 비율, 남겨두는 이유는 나중에 레코드 추가될 때를 위해서임
  • 블로킹 인수 : 한 블록에 포함되는 레코드 수
  • 고정길이 레코드 vs 가변 길이 레코드 : 가변의 경우, 특정 레코드를 접근하기 힘들고, 레코드의 끝을 나타내는 문자를 사용해야 하며, 레코드 삭제하고 거기에 더 긴놈 넣으려면 레코드들의 위치를 조정해줘야 함
  • 화일 내의 클러스터링 vs 화일 간의 클러스터링
    • 화일 내 : 한 화일 내에서 클러스터링(같이 검색될 가능성 높은 것끼리 모아놓음)
    • 화일 간 : 논리적으로 연관되어서 함께 검색될 가능성 높은 애들끼리 모아놓음
  • 화일 조직 : 화일내의 데이터를 배치하는 것
    • 히프 파일 : 삽입 순서대로 저장, 검색시 모든 레코드 순차적 접근, 삭제시 해당 공간 재활용 하지 않음
      • 모든 레코드들을 참조하고 접근하는 경우(순서 중요하지 않은)
      • 삽입은 좋음
    • 순차 화일: 어떤 필드 값(탐색키)에 따라 순서대로 저장됨, 삭제시 해당 공간 재활용 안함
      • 삽입시 시간 오래걸릴 수 있음
      • 레코드들을 순차 접근하는 경우 주로 사용
      • 즉, 탐색 키를 가지고 탐색하는 경우에만 효율적
    • indexed sequential file
      • 단일 단계 인덱스 : 탐색 키,실제 릴레이션의 레코드를 가르키는 포인터로 이루어진 인덱스 테이블
        • 인덱스 테이블은 탐색 키 기준으로 오름차순 정렬
        • 이진 탐색시 블록이 n개있으면 접근 횟수는 ceil(log2(n)) (인덱스 블록 접근 횟수) +1(인덱스 블록에서 찾은 포인터로 데이터 블록으로 접근하는 횟수)
        • 인덱스를 정의하는 타입
          • 기본 인덱스 : 기본 키의 값에 따라 정렬된 데이터 파일에 대해 정의됨,흔히 희소인덱스로 유지할 수 있음
            • 희소 인덱스 : 탐색키의 값을 전부 저장하는게 아니라 각 데이터 블록마다 하나의 탐색키 값만 인덱스 테이블에 저장하는 방식
          • 클러스터링 인덱스 : 키가 아닌 특정 필드 값에 따라 정렬된 데이터 파일에 대해 정의됨
            • 범위 질의에 유용
            • 데이터 파일의 레코드들과 인덱스 엔트리들이 정렬기준값에 따라 오름차순으로 정렬
          • 보조 인덱스 : 탐색 키의 값에따라 정렬되지 않은 데이터 파일에 대해 정의됨
            • 보통 밀집 인덱스 이므로, 보조 인덱스를 이용한 순차 접근은 기본 인덱스를 통한 순차 접근에 비해 비효율적
            • 밀집 인덱스 : 데이터 필드에 존재하는 탐색키의 값을 전부 인덱스 테이블에 저장함
              • count질의처럼 인덱스만 접근해서 질의 수행이 가능한 경우 밀집 인덱스가 희소 인덱스보다 유리하다.
      • 다단계 인덱스 : 단일단계 인덱스를 하나의 단계로하고 이러한 단계를 여러개로 만드는 것.
        • 제일 상위 단계의 경우 주기억 장치에 상주할 수 있고 이 경우, 디스크 접근이 필요없음
        • B+-트리 사용
        • 3단계(최상위)에서 2단계의 특정 블록으로 이동(1번) 2단계에서 1단계의 특정 블록으로 이동(1번) 1단계에서 찾는 레코드가 있는 데이터 블록으로 이동(1번), 이렇게 총3번의 디스크 접근으로 파일을 찾을 수 있음
  • SQL에서 기본키로 명시한 놈은 자동으로 기본 인덱스 생성되고, unique옵션주면 자동으로 보조 인덱스 생성
    • 다른 애트리뷰트에 추가로 인덱스 정의하기 위해서는 CREATE INDEX 인덱스이름 ON 테이블이름(attr1,attr2 …);
    • 이경우에 attr1,attr2순으로 검색에 사용하거나, attr1만 단독으로 검색에 사용하는 경우는 해당 인덱스가 활용되지만, attr2만 단독으로 사용되는 경우, 해당 인덱스의 애트리뷰트 순서와 다른 순서로 검색을 진행하는 경우에는 이 인덱스는 활용되지 않음
  • 인덱스의 장점과 단점
    • 검색 속도를 향상시킴, 소수의 레코드들을 수정하거나 삭제할때는 향상됨
    • 삽입,삭제,수정의 속도를 저하시킴, 데이터 파일이 갱신되면 그거랑 연관된 모든 인덱스를 갱신해야 하므로 성능 저하

Chap7.

  • 정규화는 주어진 릴레이션 스키마를 함수적 종속성과 기본 키를 기반으로 분석하여 원래의 릴레이션을 분해함으로써 중복과 세가지 갱신 이상을 최소화 한다.
  • 갱신이상
    • 수정이상
    • 삽입이상
    • 삭제이상
  • 정보가 중복된 경우(사원 릴레이션에서 한 사원이 두개의 부서에 종속될 수 있는 경우)
    • 어떤 부서의 이름이 바뀌고 이 부서의 일부 사원만 이름 변경하면 불일치 상태 → 수정이상
    • 어떤 부서를 신설했는데 아직 사원이 아무도 없으면 이 부서에 관한 정보를 입력할 수 없음 → 삽입이상
    • 어떤 부서에 사원이 하나인데 이 사원을 삭제하면 부서에 관한 정보도 삭제됨 → 삭제이상
    • 이런 경우, 릴레이션을 분해 해야 함 ← 이게 정규화
  • 함수적 종속성 : 제2정규형~BCNF까지 적용됨, 애트리뷰트 A가 B의 결정자 이면 B가 A에 함수적으로 종속한다고 말함
    • 결정자 : 어떤 애트리뷰트의 값이 다른 애트리뷰트의 값을 고유하게 결정할 수 있을 때 이를 결정자라 함
      • A가 B를 결정한다, A→B
    • 즉, 각 A에 대해 반드시 한개의 B값이 대응된다는 것
    • 완전 함수적 종속성(FFD) : B가 A에 함수적으로 종속하면서 A의 진부분집합중 어떠한 것에도 함수적으로 종속하지 않을 때 B가 A에 완전하게 함수적으로 종속한다고 말함 (! 여기서A는 복합 애트리뷰트)
    • 이행적 함수적 종속성 : B가 A에 종속하고 C가 B에 종속하면 C가 A에 이행적으로 종속한다고 말함
  • 무손실 분해 : 분해한 두 릴레이션을 조인했을 떄 원래의 정보를 완전하게 얻을 수 있는 경우
  • 제 1 정규형 : 릴레이션 R의 모든 애트리뷰트가 원자값만을 가질때 릴레이션이 제1정규형을 만족한다.
    • 한 애트리뷰트의 값이 원자적이지 않다면
      • 이걸 그냥 두개의 튜플로 나눠서 원래의 릴레이션에 추가하거나
      • 반복되는 애트리뷰트를 제외한 릴레이션과, 반복된 애트리뷰트와 기본키로 이루어진 릴레이션(여기서도 중복값은 튜플추가로 처리)으로 나누어 준다.
    • 수정이상: 한 학과의 전화번호가 수정되면 그 학과에 소속된 학생 튜플의 전화번호를 수정해야 한다.
    • 삽입이상 : 어떤 학과에 학생이 한명도 없다면 이 학과에 관한 학생 튜플을 삽입할 수 없다( 해당 학과와 관련된 학번이 기본키 인데 이게 NULL이면 안되기 때문)
    • 삭제이상 : 학생이 한명인 학과의 학생 튜플을 삭제하면 이 학생이 소속된 학과에 관한 정보(전화번호,학번형식)도 삭제된다.
  • 제 2 정규형 : 제 1정규형에서 부분 함수적 종속성이 존재하지 않도록(모두 완전하게 함수적으로 종속하도록) 분해한다.
    • 즉, 어떤 후보키가 아닌 애트리뷰트는 완전 함수적 종속성을 가져야 한다.
    • 수정이상 : 제 1 정규형과 마찬가지
    • 삽입 이상 : 제 1 정규형과 마찬가지
    • 삭제 이상 : 제 1 정규형과 마찬가지
  • 제 3 정규형 : 제 2정규형에서 이행적 종속성이 존재하지 않도록 분해
    • 수정 삽입 삭제 모두 마찬가지로 발생
      • 키가 아닌 애트리뷰트가 다른 애트리뷰트를 결정하기 때문이라고 함, 여기서 강사가 과목을 결정한다는데 왜?
  • BCNF : 제 3정규형에서 모든 결정자가 후보 키인 경우
  • 역 정규화 : 정규화를 하면 중복 감소하고 갱신 이상 최소화 되고 코드양도 감소되지만 분해된 릴레이션을 대상으로 질의하는 경우 조인의 필요성이 증가하게 됨
    • 따라서, 역으로 정규화 단계를 낮춰 성능을 높이는 것

Chap8. 뷰와 시스템 카탈로그

  • 뷰 : 다른 릴레이션으로부터 유도된 릴레이션
    • 기본 릴레이션에 대한 select문의 기능을 함
    • 스냅샷 : 비슷한데 얘는 어느 시점에서 릴레이션을 찰칵찍은 것을 릴레이션처럼 담고 있는 것
    • CREATE VIEW name (애트리뷰트 이름(선택사항)) AS SELECT문(select from, where, …) (WITH CHECK OPTION)
    • 체크옵션을 주면 뷰의 조건에 맞지 않는 작업을 거절함
    • 뷰는 외부단계에 있기에, 내부스키마(실제 릴레이션)의 구조가 변경되어도(분할) 영향을 받지 않음.. 이게 논리적 데이터 독립성..(근데 말이 안됨)
      • 걍 접근하던 릴레이션이 분해되면 걔네 조인한 뷰를 하나 더만들어서 원래 릴레이션 처럼 사용
    • 뷰는 실제 릴레이션의 일부 정보만 접근가능하게 하니 데이터 보안 기능을 제공한다
    • 뷰의 갱신 : 아래의 조건 중 하나라도 만족하면 갱신 불가능
      • 한 릴레이션 위에서 정의 되었지만 기본 키 애트리뷰트를 포함되지 않은 뷰
      • 기본 릴레이션에 NOT NULL이 박혀있는 애트리뷰트를 포함하지 않은 뷰
      • 집단 함수가 사용된 뷰
      • 조인이 사용된 뷰 (릴레이션 2개이상 다 안됨)
  • 시스템 카탈로그 : 시스템 내의 객체(기본 릴레이션,뷰,인덱스,접근권한 등등)에 관한 정보를 포함
    • 메타데이터 라고 함
    • 하는 일
      • select문의 문법적 정확성 검사,뭐 실제로 릴레이션이 존재하는지,애트리뷰트가 있는지,타입 맞는지 등등 이것저것 체크함
      • where절에 인덱스 체크하는데 만약 두개의 애트리뷰트가 where에 있고 이게 둘다 인덱스가 있으면 이 중에서 애트리뷰트의 값이 더 다양한 놈을 선택해서 인덱스 당 튜플의 수를 줄임
      • 질의 최적화 : DBMS가 질의를 수행하는 과정에서 가장 비용이 적게 드는 방법을 찾는 것
    • 시스템 테이블이므로 SELECT문으로 조회가 가능함
    • 근데, 이외의 갱신은 허용하지 않음(DBMS가 알아서 만듬)
    • 유지되는 통계 정보
      • 릴레이션 (튜플의 수,크기,블로킹인수 등등)
      • 뷰 (뷰의 이름,정의)
      • 애트리뷰트 (애트리뷰트의 데이터 타입,크기,범위 등등)
      • 사용자 (접근권한,릴레이션)
      • 인덱스 (인덱스된 애트리뷰트, 밀집/희소 인덱스 여부 등등)
    • UPDATE STATISTICS문을 사용하여 통계 정보를 수동으로 업데이트도 가능하지만, 알아서 DBMS가 업데이트해줌
    • table_catalog는 데이터베이스의 이름, table_schema 소유자의 식별자, table_name은 릴레이션이나 뷰의 이름, table_type은 릴레이션의 유형(base table, view)

Chap9. 트랜잭션

  • 많은 사용자들이 동시에 DB를 이용함
  • 정보를 수정하다가 시스템이 재부팅되면 로그를 이용해서 수정을 계속함
  • DB에서 수행하는 작업은 트랜잭션이란 단위로 실행되는데, 어떤 연쇄적으로 이루어 져야 하는 작업을 하나의 트랜잭션으로 합쳐야 일관성이 유지됨
  • 트랜잭션의 특성 ACID
    • 원자성(Atomicity) : 한 트랜잭션 내의 연산은 모두 수행되거나 전혀 수행되지 않는다.
    • 일관성(Consistency) : 트랜잭션 수행 전 일관된 상태에서 트랜잭션 수행 후 다시 다른 일관된 상태를 가짐( 물론 트랜잭션 수행 중에는 일관적이지 않을 수 있음)
    • 고립성(Isolation) : 한 트랜잭션이 실행 중이면 다른 트랜잭션은 대기해야 함, 설령 동시에 실행되더라도 어떤 순서에 따라 순차적으로 실행한 것과 같은 결과를 내야 함
    • 지속성(Durability) : 한 트랜잭션이 완료되면 그 후 시스템이 고장나더라도 손실되지 않음
  • COMMIT : 성공적인 종료를 의미, 트랜잭션의 작업을 DB에 반영해야 한다
  • ROLLBACK : 철회를 의미, 트랜잭션의 작업이 DB에 일부만 반영된 경우 이 작업을 철회한다.
  • DB연산
    • INPUT(X) : 데이터베이스에서 X를 포함한 블록을 주기억 장치의 버퍼로 가져옴
    • OUTPUT(X) : X가 포함된 블록을 디스크에 기록
    • read_item(x) : 주기억 버퍼에서 프로그램 변수로 복사
    • write_item(x) : 프로그램에서 주기억 버퍼로
  • 동시성 제어 : 동시에 다수의 사용자가 DB를 사용하도록 하면서 DB의 일관성을 유지함
    • 직렬 스케줄 : 한번에 하나씩 실행
    • 비직렬 스케줄 : 여러개 동시 실행
    • 직렬가능 : 비직렬로 했는데 직렬로 한거랑 결과가 같음
    • 동시성 제어가 없을 시 생길 문제
      • 갱신손실 : 수행 중인 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어 써서 갱신이 무효화 되는 것
      • dirty read : 완료되지 않은 트랜잭션이 갱신한 데이터를 읽는 것
      • unrepeatable read : 한 트랜잭션이 동일한 데이터를 두 번 읽을 때 서로 다른 값을 읽는 것
    • 로킹(locking)
      • 말그대로 잠구는 거임
      • 이런 lock에 관한 정보는 lock table에 유지됨
      • 트랜잭션이 갱신을 하려하면 X-lock(독점 로크)요청
      • 읽을 목적이면 S-lock(공유 로크) 요청
      • 할거 다하면 unlock
      • X-lock된 애는 접근 불가능(못 읽게 해야지 당연히 수정중이니까..)
    • 2단계 로킹 프로토콜 : 로크 요청과 해제가 2단계로 이루어짐
      • 1단계 : 로크 확장 단계 : 트랜잭션이 새로운 로크를 요청할 수는 있지만 보유하고 있던 로크를 해제할 수는 없음
      • 2단계 : 로크 수축 단계 : 보유 로크를 해제할 수 있지만, 요청은 못함
      • 로크 포인트 : 한 트랜잭션에서 필요로 하는 모든 로크를 걸어놓은 시점
      • 데드락 발생가능
    • 다중 로크 단위
      • 트랜잭션이 접근하는 튜플의 수에 따라 로크를 하는 데이터 항목의 단위를 구분하는 것이 필요함
      • 한 트랜잭션에서 로크할 수 있는 데이터 항목이 두 가지 이상이면 다중 로크 단위라 말함
      • 로크 단위가 작을 수록 로킹 오버헤드 증가
      • 쉽게말하면 튜플단위,디스크 블록단위, 릴레이션단위 등등 이런 단위를 의미하는 것
  • 회복
    • 트랜잭션이 버퍼에 갱신 사항을 반영했는데 버퍼의 내용이 디스크에 기록되기전에 고장 발생 가능
    • 즉, 고장 발생 전에 트랜잭션이 완료 되면 회복 모듈이 REDO(재수행)
    • 고장 발생 전에 트랜잭션이 완료하지 못하면 UNDO(취소)
    • 안전 저장 장치 : 두 개 이상의 사본을 중복해서 저장해서 구현함
    • 재해적 고장 : 디스크 손상으로 DB를 읽을수 없는 고장
      • DB를 백업해 놓은 디스크를 이용하여 회복
      • 지난 번 백업에서 갱신된 내용만 백업하는 점진적인 백업이 바람직하다
    • 비재해적 고장 : 그 이외의 고장, 대부분의 회복 알고리즘이 적용됨
      • 로그를 기반으로 한 즉시 갱신,지연갱신, 그림자 페이징 등등
        • 로그를 기반으로 한 즉시갱신 : 트랜잭션이 DB를 갱신한 사항이 트랜잭션 완료되기 전에도 버퍼에서 디스크로 기록하기도 함, 완료된 결과 뿐아니라 철회된 결과도 반영될 수 있음, 로그 레코드는 로그 순서 번호로 식별함
          • 주 기억장치의 로그 버퍼에 로그 레코드를 기록하고 꽉차면 디스크에 기록, 안전 저장 장치에 일반적으로 저장
          • 이중 로그 : 로그를 두 개의 디스크에 중복해서 저장하는 것
          • 로그 레코드의 유형
            • Trans-ID, start : 트랜잭션 생성시 기록되는 로그 레코드
            • Trans-ID, old_value,new_value : 수정을 의미하는 로그 레코드
            • commit, abort도 있음
          • 트랜잭션은 갱신을 끝내고 로그에 기록되었을 때 완료된다. 트랜잭션의 완료점 이라 함
            • 회복 모듈은 start~commit이면 재수행, start만있으면 취소
          • 로그 먼저 쓰기 (WAL, wirte ahead logging)
            • 데이터 버퍼가 로그 버퍼보다 먼저 기록하고 로그 버퍼 기록전에 다운되면 트랜잭션의 회복이 불가능함
            • 따라서, 로그 버퍼를 데이터 버퍼보다 먼저 디스크에 기록해야 함
          • 체크포인트
            • 좀 오래 된 트랜잭션의 경우 로그를 사용해도 회복이 힘듬
            • DBMS는 회복시 재수행할 트랜잭션의 수를 줄이기 위해 주기적으로 체크포인트 생성
            • 체크포인트 시점에 버퍼내용이 디스크에 전부 기록되므로 디스크 상의 로그와 데이터베이스 내용이 일치하게됨
            • 체크포인트 작업 후에 로그에 checkpoint 로그 레코드가 기록됨
            • 체크포인트 시점에 진행중인 작업은 잠시 중단했다가 기록후 재개
            • 체크포인트 지점 이전에 완료된 작업은 이후 생긴 시스템 다운에 대한 회복에서 무시됨
  • 그냥 SQL문 박아서 시작하거나 begin transaction으로 트랜잭션의 시작을 표시
  • commit 또는 rollback으로 트랜잭션의 끝을 표시
  • 고립수준
    • 사용자가 동시성의 정도를 명시할 수 있음
    • 고립 수준이 낮으면 동시성이 높아지지만 데이터의 정확성이 떨어짐
    • 높아지면 동시성이 저하되지만 데이터의 정확성이 높아짐
    • read uncommitted : 가장 낮은 수준, 트랜잭션 내의 질의가 공유 로크를 안걸고 데이터를 읽음( 갱신에서는 독점 로크 걸고함)
    • read committed : 읽을때 공유로크 걸고 읽고, 다 읽으면 바로 로크해제, 동일 데이터를 다시 읽으려고 공유 로크 걸고 읽으면 이전 값과 달라질 수 있음, 디폴트값이다
    • repeatable read : 공유 로크 걸고 트랜잭션 끝날때까지 보유
    • serializable : 가장 높은 수준, 인덱스에 대해서도 공유로크 걸고 트랜잭션 끝날 때까지 보유

Chap10 . 데이터베이스 보안과 권한 관리

  • 보안
    • 물리적보호,권한보호,운영보호
  • 보안 기법
    • 임의 보안 기법 : 사용자들에게 접근 권한을 허가,취소하는 기법
    • 강제 보안 기법 : 데이터와 사용자들을 다양한 보안 등급으로 분류
  • 권한 없는 사용자가 데이터베이스 갱신했다고 생각되면 데이터베이스 감사를 함
    • 특정 기간동안 수행된 연산들을 검사하는 것(로그조사)
  • 권한 허가
    • GRANT 권한 [애트리뷰트 리스트] ON 객체 TO 사용자,역할,public [with grant option];
    • 권한은 select,insert등등
    • with grant option주면 이 사용자도 다른 사용자에게 권한을 부여할 수 있음
    • public한테주면 모든 사용자에게 허가
  • 권한 취소
    • REVOKE {권한|ALL} ON 객체 FROM {사용자|역할|public}
  • 역할
    • 여러 사용들에 대한 권한 관리를 단순화 하기 위해 사용
    • ex) grant create table to programmer; grant programmer to kim;
저작자표시 (새창열림)