Transcript 제20장 고급 트랜잭션 처리

제 19장 특별 주제
보안과 무결성
 표준화
 성능 벤치마크
 성능 조율
 데이터베이스에서의 시간
 사용자 인터페이스
 능동 데이터베이스

Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
1
보안과 무결성


무결성 - 우발적인 일관성 손실로부터의 보호
- 트랜잭션 처리중의 이상
- 동시성 제어
- 여러 컴퓨터에 데이터 분산으로 야기되는 이상
- 데이터베이스 일관성의 가정을 위배하는 논리적 오류
보안 - 데이터를 훔치거나 수정하려는 악의적인 시도로부터의
보호
- 물리 단계
- 인간 단계
- 운영체제 단계
- 네트워크
- 데이터베이스 시스템 단계
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
2
물리 단계의 보안
홍수,정전 등으로부터 장비의 보호
 도둑,침입자, 물리적 손상 등으로부터 디스크의 보호
 도청,전자 도청,물리적 손상 등으로부터 네트워크와 터
미널 케이블의 보호
해결책 :
 하드웨어의 중복 :
- 거울형 디스크, 이중 버스 등
- 각 장치 쌍간의 다중 액세스 경로
 물리적 보안 : 자물쇠, 경찰 등
 물리적 보안 파괴를 탐지하는 소프트웨어 기법

Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
3
인간 단계의 보안


암호 도난, 사보타지 등으로부터의 보호
주로 관리상의 문제이다 :
- 암호의 수시 변경
- 예측 불가능한 암호의 사용
- 모든 적법하지 않은 액세스 시도의 로깅
- 데이터 감사
- 주의 깊은 고용 관행
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
4
운영체제 단계의 보안

부적절한 로그인으로 부터의 보호

파일 계층 액세스 보호(데이터베이스 보안에는 그
다지 도움이 되지는 않는다).

“최고 사용자” 권한의 부적절한 사용으로부터의
보호

특수 권한 컴퓨터 명령어의 부적절한 사용으로부
터의 보호
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
5
네트워크 단계의 보안

각 사이트는 신뢰할 수 있는 사이트(침입자가
아닌)와만 통신하도록 보장해야 한다.

링크는 메시지 도둑 또는 변경으로부터 보호되
어야 한다.

기법 :
- 식별 규약(암호 기반)
- 암호화
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
6
데이터베이스 단계 보안

네트워크, 운영체제, 인간 및 물리 단계에서의 보안은 가정
한다.

데이터베이스에 특정한 고려 사항 :
- 각 사용자는 데이터의 일부에만 읽고 쓸 권한을 가진다.
- 사용자 권한은 전체 파일 또는 릴레이션에 대응할 수도 있
지만 또한 파일 또는 릴레이션의 일부에만 대응할 수 있다.

지역 자치성은 분산 데이터베이스 내에 사이트 단계의 권한
제어를 제시한다.

전역 제어는 중앙 집중 제어를 제시한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
7
권한
데이터베이스 부분에 대한 권한의 유형 :




Read 권한 - 데이터를 읽기는 하지만 수정은 할 수
없다.
Insert 권한 - 새로운 데이터를 삽입할 수는 있지만
기존 데이터 수정은 할 수 없다.
Update 권한 - 수정은 하지만 데이터 삭제는 할 수
없다.
Delete 권한 - 데이터를 삭제할 수 있다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
8
권한(계속)
데이터베이스 스키마를 수정하는 권한의 유형 :




Index 권한 - 인덱스의 생성과 삭제를 허용
Resource 권한 - 새로운 릴레이션 생성의 허용
Alteration 권한 - 릴레이션내 애트리뷰트의
추가 또는 삭제 허용
Drop 권한 - 릴레이션 삭제의 허용
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
9
권한과 뷰

뷰 - 사용자에게 자신의 데이터베이스 모델을
제공하는 수단

데이터를 감추기 위한 뷰의 기능은 시스템 사
용의 단순화와 보안 강화 모두를 제공한다.

릴레이션 단계의 보안과 뷰 단계의 보안을 결
합해 사용자의 액세스를 사용자가 요구하는 데
이터에만 정확히 제한하는데 사용할 수 있다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
10
뷰의 예



뷰는 SQL의 create view 명령을 사용해 정의한다.
create view v as <질의 표현식>
어떤 은행원이 각 지점의 고객명을 알 필요는 있지만, 특정
대출 정보를 볼 권한은 없다. loan 릴레이션으로의 직접 액
세스는 거절되지만, 대출이 있는 지점과 고객명 만으로 구
성된 cust-loan 뷰에의 액세스는 허용된다.
cust-loan 뷰는 SQL로 다음과 같이 정의한다.
create view cust-loan as
(select branch-name,customer-name
from borrower,loan
where borrower.loan-number=loan.loan-number)
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
11
뷰의 예(계속)



행원에게 질의의 결과를 볼 권한은 있다:
select *
from cust-loan
질의 처리기가 결과를 데이터베이스 내 실제
릴레이션 상의 질의로 변환할 때, borrower와
loan에의 질의를 얻는다.
질의 처리를 시작하기 전 행원의 질의에 권한
검사가 이루어져야 한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
12
뷰 상의 권한

뷰의 생성은 resource 권한을 요구하지는 않는
다.

뷰의 생성자는 자기가 이미 가지고 권한만을
갖는다.

예를 들어, 뷰 cust-loan의 생성자가 borrower와
loan에 read 권한만을 가지고 있다면, 그는 custloan에 read 권한만을 갖는다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
13
권한 부여

한 사용자로부터 다른 사용자로의 권한 전달이 권한 그래프
로 표현될 수 있다.
- 이 그래프의 노드는 사용자이다.
- 그래프의 뿌리는 DBA이다.
- loan에의 갱신 권한에 대한 그래프를 고려해 보자.
- 간선 Ui  Uj는 사용자 Ui가 Uj에게 loan에 갱신 권한을 부
여했음을 나타낸다.
DBA
U1
U4
U2
U5
U3
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
14
권한 부여 그래프



요구 사항 : 권한 그래프 내의 모든 간선은 DBA에서 시작하는 어떤
경로의 일부이어야 한다.
DBA가 U1으로부터 권한을 취소하면 :
- U1 이 더 이상 권한을 갖지 않기 때문에 U4로부터 권한을 취소해야
한다.
- U5는 U2를 통해 DBA부터 또 다른 권한 경로를 가지기 때문에 U5로
부터 권한을 취소해서는 안 된다.
뿌리로부터 경로를 갖지 않은 권한 부여 순환을 방지해야 한다.
- DBA가 U7에게 권한 부여
- U7이 U8에게 권한 부여
- U8이 U7에게 권한 부여
- DBA가 U7로부터 권한 취소
DBA로부터 U7또는 U8로 더 이상 경로가 없기 때문에, U7에서 U8에서
U7로의 권한이 취소되어야 한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
15
SQL에서의 보안 명세




권한을 부여하는데 grant 문을 사용한다.
grant <권한 리스트>
on <릴레이션 명 또는 뷰 명> to <사용자 리스트>
<사용자 리스트>는 다음 중 하나이다:
- user - id
- public, 모든 적법한 사용자에게 권한을 부여함
뷰에 권한을 부여하는 것은 기존의 릴레이션 상에 어떤 권한
부여를 내포하지 않는다.
권한 부여자는 이미 특정 항목에 권한을 가지고 있어야 한다
(또는 DBA이거나).
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
16
SQL에서의 권한





select : 릴레이션을 읽거나 뷰를 사용해 질의할 수 있도록
한다.
- 예 : 사용자 U1, U2, U3에게 branch 릴레이션 상에 select
권한을 부여 :
grant select on branch to U1, U2, U3
insert : 튜플을 삽입할 수 있도록 한다.
update : SQL update문을 사용해 갱신할 수 있도록 한다.
delete : 튜플을 삭제할 수 있도록 한다.
references : 릴레이션을 생성할 때 외래 키를 선언할 수 있도록
한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
17
SQL에서의 권한(계속)



all privileges : 모든 허용 가능한 권한에 대해 간략한 형식으로
사용된다.
usage : SQL-92에서; 사용자들이 특정 도메인을 사용할 수
있도록 한다.
with grant option : 권한을 부여 받은 사용자가 다른 사용자
에게 권한을 부여할 수 있도록 한다.
-예:
grant select on branch to U1 with grant option
U1에게 branch상에 select 권한을 부여하고 이 권한
을 다른 사용자에게 부여할 수 있다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
18
SQL에서의 권한 취소



revoke 문은 권한을 취소하는데 사용된다.
revoke <권한 리스트>
on <릴레이션 명 또는 뷰 명> from <사용자 리스트>
예:
revoke select on branch from U1, U2, U3 cascade
어떤 사용자로부터의 권한 취소가 또한 다른 사용자들의 권
한 취소를 야기할 수 도 있다; 이를 연쇄 취소라 한다.
restrict를 지정하여 연쇄 취소를 막는다.
revoke select on branch from U1, U2, U3 restrict
restrict를 가지면, 연쇄 취소를 요구할 때 revoke 명령이 무시
된다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
19
SQL에서의 권한 취소(계속)

<권한 리스트>에 all을 지정하면 취소자가 가지고 있는
모든 권한을 취소할 수 있다.

<취소자 리스트>에 public을 가지면, 명시적으로 부여된
권한을 제외하고 모든 사용자들이 권한을 잃는다.

같은 사용자에게 같은 권한이 다른 부여자로부터 두 번
부여되면, 그 사용자는 취소 후에 권한을 유지할 수 있다.

취소중인 권한에 의존하는 모든 권한들은 또한 취소된다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
20
SQL - 3 확장




SQL - 3에서는 role의 개념을 제공한다.
권한은 사용자와 같이 역할로부터 허용되고 취소 될 수 있다.
역할은 사용자에게 배정될 수 있으며 다른 역할에도 배정될
수 있다.
예:
create role teller
create role manager
grant select on branch to teller
grant teller to alice
grant teller to manager
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
21
암호화

데이터베이스 인증 제공이 충분한 보호를 제공하지 못할
때 데이터는 암호화될 수 있다.

좋은 암호화 기법의 속성
- 권한 있는 사용자들이 데이터를 암호화하고 해독하기가
상대적으로 단순하다.
- 암호화 기법은 알고리즘의 보안 뿐만 아니라 암호화 키라는
알고리즘의 매개 변수의 보안에도 의존한다.
- 침입자가 암호화 키를 결정하기는 지극히 어렵다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
22
암호화(계속)



데이터 암호화 표준(DES)에서는 문자들을 대치해 안전한 기법
으로 권한 있는 사용자들에게 제공된 암호화 키에 따라 그 순서
를 재배열한다. 기법이 키 전용 기법보다 더 안전하지는 않다.
두 개의 키를 가진 각 사용자에 근거한 공용 키 암호화
- 공용 키 - 데이터를 암호화하는데 사용되는 알려진 키이지만,
데이터를 해독 하는 데는 사용될 수 없다.
- 개인 키 - 사용자 개개인에게만 알려진 키로 데이터를 해독
하는데 사용된다.
암호화 기법은 공용 키만 제공된 데이터를 해독하기가 불가능
하거나 지극히 어려운 그러한 것이다.
RSA 공용 키 암호화 기법은 매우 큰 수(100 자리 수)에서 소인자
를 발견하기가 어렵다는데 기반을 두고 있다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
23
통계 데이터베이스



문제점 : 통계 목적으로 데이터를 사용하도록 하면서 개인
의 사생활을 어떻게 보호할 것인가(예를 들어 수입의 중위
수, 평균 은행 잔고를 찾는 등의 일).
해결책 :
- 시스템에서 미리 정한 개인보다 적은 수를 내포하는 질의
는 거절한다.
* 하지만 여전히 개인에 관한 데이터를 유추하기 위해 여러
중첩된 질의의 결과를 사용할 가능성이 있다.
- 데이터 오염 - 질의에 대한 응답으로 제공된 데이터의 임의
변조
- 질의 자체의 임의 수정
정확성과 보안간에 손익 비교가 존재한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
24
표준화



동시대 데이터베이스 시스템의 복잡성과 그들 상호간 연산
의 필요성이 다양한 표준을 요구한다.
- 프로그래밍 언어의 구문과 시맨틱
- 어플리케이션 프로그램 인터페이스 내의 함수
- 데이터 모델(즉, 객체 지향 데이터베이스 표준)
형식적 표준은 표준 기구(ANSI, ISO)또는 공식 절차를 통해
산업체에서 개발한 표준이다.
사실상의 표준은 일반적으로 공식적인 인증 없이 표준으로
수용된다.
- 시장을 주도하는 업체가 정의한 표준이 흔히 사실상의 표
준이 된다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
25
표준화(계속)


예상 표준은 시장을 주도하며 업체들이 구현하는 기능들을 정
의한다.
- 미래 제품들의 호환성을 보장한다.
- 그러나, 표준 규격이 구현의 용이성에서 큰 주목을 받지
못하면 크게 사용되지 않는다.(예,SQL-92 또는 미래의 SQL-3)
보수 표준은 업체들이 서로 다른 방법으로 이미 구현한 기능
들을 표준화하는 것이다.
- 이미 구현한 기능들을 변경하도록 업체들을 납득시키기가
어려울 수 있다.
- 사실상의 표준이 종종 공식적인 인증 절차를 거쳐 공식적인
표준이 된다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
26
SQL 표준의 역사






SQL은 1970년대 말/1980년대 초 IBM에서 개발
SQL - 86이 첫번째 공식 표준
1987년에 IBM에서 SAA 표준 발표
SQL-89는 이미 많은 시스템에서 구현된 SQL-86에 기능을
추가함(보수 표준)
SQL-92는 SQL-89에 새로운 많은 기능을 추가함(예상 표준)
- 적응 단계를 정의함(초기,중간,완전)
- 1997년 까지도 완전 단계의 SQL-92 구현을 갖춘 데이터베이
스 업체는 거의 없었다.
SQL-3 표준은 현재 개발 중에 있음
- 새로운 많은 기능을 추가함 - 확장 데이터 형, 객체 지향성,
프로시저, 트리거, 멀티미디어 등
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
27
기타 표준

데이터베이스 내부 연결을 위한 Microsoft사의 Open
DataBase Connectivity(ODBC) 표준
- X/Open 콘소시엄에서 개발한 Call Level Interface(CLI)에
근거함
- 어플리케이션 프로그래밍 인터페이스와 서로 다른 계층에
서 지원되어야 할 SQL 기능을 정의함

X/Open XA 표준은 분산 2단계 완료를 지원하기 위한
트랜잭션 관리 표준을 정의한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
28
객체 지향 데이터베이스 표준


객체 지향 데이터베이스를 위한 Object Database Management
Group(ODMG) 표준
- 1993년에 버전 1, 1997년에 버전 2 발표
- 여러 특정 언어 바인딩과 함께 언어 독립적인 객체 정의어(ODL)
를 제공
객체에 근거한 분산 소프트웨어를 위한 Object Management
Group(OMG)
- Object Request Broker(ORB)는 분산 객체에 은밀한 메시지
보내기를 제공한다.
- 언어 독립적인 데이터 형을 정의하기 위한 Interface Definition
Language(IDL)
- Common Object Request Broker Architecture(CORBA)는 ORB와
IDL의 명세를 정의한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
29
성능 벤치마크



소프트웨어 시스템의 성능을 정량화 하는데 사용되는 태스
크의 모임
데이터베이스 시스템을 비교하는데 중요하며, 특히 시스템
들이 보다 표준을 따르고 있을 때 중요하다.
데이터베이스 어플리케이션 부류 :
- 온라인 트랜잭션 처리(OLTP)에서는 고도의 동시성과
갱신 트랜잭션의 고 비율을 지원하는 완료 처리 속도를
증가 시키기 위한 우수한 기법을 요구한다.
- 의사 결정 지원 어플리케이션(온라인 분석 처리 : OLAP
포함)에서는 좋은 질의 평가 알고리즘과 질의 최적화를
요구한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
30
성능 벤치마크(계속)



주로 사용되는 성능 측정 도구 :
- 처리율 (초당 트랜잭션 수 : TPS)
- 응답 시간(트랜잭션이 제기되어 결과를 반환하기까지의 지연
시간)
성능 평가에 사용되는 태스크들의 모임(복합 시스템에 있어서 단
일 태스크로는 부족하다)
평균 처리율을 계산해서는 안 된다.
- 예를 들어, 어떤 시스템에서는 A 유형의 트랜잭션은 99tps이고 B
유형의 트랜잭션은 1tps로 실행한다 가정하자, 유형 A와 B의 동일
조합이 제공되면, 처리율은 (99+1)/2=50 tps가 아니다.
- 각 유형의 트랜잭션을 실행하는데 걸리는 시간은 1+1/99로서
처리율은 1.98tps가 된다.
- 조화 평균을 사용해야만 한다 : n/(1/t1+1/t2+…+1/tn)
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
31
벤치마크 모임


트랜잭션 처리 위원회(TPC) 벤치마크가 널리 사용된다.
- TPC-A : 터미널과의 통신을 포함한 점대점 측정을 가진 은행
텔레 어플리케이션을 모델링하는 단순한 OLTP 어플리케이션
- TPC-B : TPC-A와 같은데, 통신은 없다.
- TPC-C : 재고 시스템을 모델링하는 보다 복잡한 OLTP
어플리케이션
- TPC-D : 복잡한 의사 결정 지원 어플리케이션(많은 집성 함수를
포함한다.)
TPC 성능 측정
- 응답시간의 특정 제약 조건을 가진 tps(transactions per second)
- 소유중인 시스템의 비용에 대한 tps당 비용(transactions per
second per dollor) 계정
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
32
벤치마크 모임(계속)

TPC 벤치마크 데이터베이스 크기는 실세계 어플
리케이션을 반영하기 위해 tps를 증가시켜 규모를
증대한다.

TPC 성능의 외부 감사는 의무적인 것으로 간주한
다(TPC 성능은 신뢰할 수 있다)

OODB 트랜잭션은 다른 벤치마크를 필요로 한다.
- OO7 벤치마크는 여러 개의 다른 연산을 가지고 있으며, 각
연산의 종류에 대해 별개의 벤치마크 번호를 제공한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
33
성능 조율



특정 어플리케이션의 시스템 성능을 증가 시키기 위해 다양한
매개 변수와 설계 대안을 조정하는 것
조율은 병목을 인지하여 그것을 제거함으로써 가장 잘 이룰 수
있다.
데이터베이스 시스템은 3 단계로 조율할 수 있다.
- 하드웨어 - 예를 들어,디스크를 추가하여 입출력 속도를 높이고,
메모리를 추가하여 버퍼 적중률을 높이고, 보다 빠른 처리기로
이동하기
- 데이터베이스 시스템 매개 변수 - 예를 들어,버퍼 크기를 늘려
버퍼 페이징 줄이기,검사점 간격을 조정하여 로그 크기 제한하기.
시스템은 자동 조율을 할 수 있다.
- 스키마, 인덱스 및 트랜잭션과 같은 고급 수준의 데이터베이스
설계
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
34
병목 인지하기






데이터베이스는 복잡한 시스템이다.
트랜잭션은 일련의 서비스를 요청한다.(예를 들어, CPU, 디스크
입출력, 로크 등)
동시 실행 트랜잭션이 있으면, 다른 트랜잭션이 처리되는 동안
트랜잭션에서 요청한 서비스를 받기 위해 기다려야 하기도 한다.
데이터베이스는 각 서비스에 대한 큐를 가진 큐잉 시스템으로 모
델링할 수 있다; 트랜잭션은 다음을 반복적으로 수행한다:서비스
를 요청하고, 큐에서 서비스를 기다리다가 서비스를 받는다.
데이터베이스 시스템내의 병목은 일반적으로 특정 서비스에 대해
매우 높은 이용률(이와 관련해 매우 긴 큐)을 보인다.
큐잉 모델을 사용한 성능 모의 실험은 실제 시스템에 액세스하지
않고도 조율 변경의 효과와 함께 병목을 예측하는데 유용하다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
35
데이터베이스 시스템 내의 큐
concurrency control
manager
lock
request
transaction
source
lock
grant
CPU manager
Transaction
manager
transaction
monitor
page
request
page
reply
page
request
disk manager
buffer
manager
page
reply
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
36
데이터베이스 설계 조율

시스템 조율
- 수직으로 분할한 릴레이션은 가장 흔히 액세스 되는 데이터
로 고립시킨다 - 필요한 정보를 가져오는 것 만으로.
*예를 들어, (account-number,branch-name)과 (account-number,
balance)로 분리된 account 릴레이션을 고려해 보자. 지점명이
필요치 않으면 가져올 필요가 없다.
- 역정규화 릴레이션을 저장해 성능을 향상시킨다.
*예를 들어, account와 depositor의 죠인을 저장하면 지점명과
잔고 정보가 각 예금 소유자에 중복되지만, 죠인을 반복해서
계산할 필요가 없다.
- 빈번히 함께 죠인되어 부합될 레코드들이 같은 디스크 페이
지에 있도록 군집 시킨다, 필요할 때 매우 효율적으로 죠인을
수행한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
37
데이터베이스 설계 조율(계속)

인덱스 조율
- 속도가 느린 질의의 속도 향상을 위해 적절한 인덱스를
생성한다.
- 과다한 인덱스를 제거하여 속도가 느린 갱신의 속도를
향상시킨다(질의와 갱신간 손익 비교).
- 가장 빈번한 질의 유형에 따라 적절한 인덱스 유형(B트리/해쉬)을 선택한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
38
데이터베이스 설계 조율(계속)

트랜잭션 조율
- 빈번한 호출들을 하나의 집합 지향 질의로 결합한다; 데이터베이스에
보다 적은 호출
- 저장된 프로시저를 사용 : 질의의 재구문 분석과 재최적화의 필요성을
없앰
- 미니-뱃치 트랜잭션을 사용해 단일 트랜잭션이 수행할 수 있는 갱신의
수를 제한한다. 예를 들어, 하나의 큰 트랜잭션에서 매우 큰 릴레이션의
모든 레코드를 갱신하면 로그가 매우 커질 수 있다.
*거대한 트랜잭션을 각각이 갱신의 일부를 수행하는 “미니-트랜잭션”의
뱃치로 분리한다.
*미니-뱃치 내 트랜잭션들에 걸쳐 로크를 유지하여 직렬성을 보장한다.
*미니-뱃치 실행중 고장이 발생하면, 원자성을 보장하기 위해 회복시
나머지 부분을 완료해야만 한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
39
데이터베이스에서의 시간





대부분의 데이터베이스가 일정 시점(현재 시간)에서의 현실
을 모델링하는 경향이 있는데, 시간 데이터베이스에서는 시
간에 걸쳐 실세계의 상태를 모델링한다.
시간 릴레이션에서의 사실은 간격의 합집합으로 표현될 수
있는 유효(valid)할 때의 시간과 연관이 된다.
사실에 대한 트랜잭션 시간은 데이터베이스 시스템 내에서
사실이 현재인 동안의 시간 간격이다.
시간 릴레이션에서는 각 튜플이 참일 때의 연관 시간을 가
진다; 시간은 유효 시간이거나 트랜잭션 시간일 수 있다.
양 시간 릴레이션에는 유효시간과 트랜잭션 시간 모두를 저
장한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
40
데이터베이스에서의 시간(계속)

시간 릴레이션의 예
branch-name account-num balance
from
to
94/1/1 09:00 94/1/24 11:30
Downtown
A-101
500
94/1/24 11:30 *
Downtown
A-101
100
95/6/2 15:30 95/8/8 10:00
Mianus
A-215
700
95/8/8 10:00 95/9/5 08:00
Mianus
A-215
900
Mianus
A-215
700
95/9/5 08:00 *
Brighton
A-217
750
94/7/5 11:00 95/5/1 16:00

시간 질의어가 시간에 관련한 질의와 함께 시간의 모델링을
단순화하기 위해 제안되었다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
41
SQL-92에서의 시간 명세





date : 년도 4자리(1-9999), 월 2자리(1-12), 일 2자리(1-31)
time : 시간 2자리, 분 2자리, 초 2자리와 선택적인 지수
2자리
timestamp : 초 필드에 대해 6개의 지수 자리수를 가진 date와
time으로 이루어진다.
시간은 천체 표준시(universal coordinated time : UTC)로 지정
된다 ; time with time zone을 지원한다.
interval : 시작 기간의 특정 시간을 명시하지 않으면 시간 기
간(예를 들어, 2일 5시간)을 의미한다; span이라는 용어가 보
다 정확할 수 있다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
42
시간 질의어






술어 precedes, overlaps 및 contains가 시간 간격에 적용될 수
있다.
두 간격에 intersect를 적용해 하나의 간격(공집합 가능)을 얻
을 수 있다; 두 간격의 union은 하나의 간격일 수도 있고 아
닐 수도 있다.
시간 t에서의 시간 릴레이션의 snapshot은 추출된 시간 간격
애트리뷰트를 가진 시간 t에서 참인 튜플들로 구성된다.
시간 선택 : 시간 애트리뷰트를 내포한다.
시간 추출 : 추출내의 튜플들은 원래 릴레이션내 튜플들로
부터 시간 간격을 상속한다.
시간 죠인 : 결과 내 튜플의 시간 간격은 죠인이 추출된 튜플
들의 시간 간격의 공통 집합이다. 공통 집합이 공집합이면,
튜플은 죠인에서 제거된다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
43
시간 질의어(계속)

함수적 종속은 주의 깊게 사용해야 한다 : 시간 필
드의 추가로 함수적 종속을 무효로 할 수 있다.

R의 모든 적법한 사례 r에 대해, r의 모든 스냅샷이
함수적 종속 XY를 만족하면 시간 함수적 종속

X
Y가 릴레이션 스키마 R에 존재한다.

시간 데이터 지원을 향상시키기 위해 SQL-92의 확
장으로 TSQL2가 제안되었다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
44
사용자 인터페이스




데이터베이스에의 사용자 인터페이스에 여러 부류가 있다.
라인 지향 인터페이스 : 대부분의 기본 인터페이스 : SQL을 사용
한 특별한 질의에는 좋지만, 데이터 입력 같은 반복 작업에는 좋지
않다.
폼 인터페이스
- 데이터 입력 및 이와 유사한 반복 업무에 널리 사용된다.
- 행위는 사용자 입력과 관련될 수 있다. 예를 들어, 고객 번호를
입력 함으로써 고객명과 주소를 불러 채워 넣을 수도 있다.
- 단순한 에러 체크는 폼 인터페이스 내에서 수행 될 수 있다.
- 폼 에디터 프로그램/패키지는 프로그램하지 않고 간단한 선언
방식으로 폼이 생성되도록 한다.
그래픽 사용자 인터페이스 : 메뉴와 아이콘 같은 기능을 사용한
가리켜서 클릭하는 패러다임 ; HTML에 기반을 둔 웹 인터페이스
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
45
주문 입력 양식
Acme Supply Company Inc.
Component Order Form
Customer Name:
Date:
Customer Number:
Order No:
Address:
Phone Number:
Part Number
Part Description
Unit Price
Quantity
Subtotal
Total
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
46
사용자 인터페이스(계속)

보고서 작성기 : 데이터베이스 내 데이터에 근거한 정기 보고서를
생성하는데 사용된다.
Acme Supply Company Inc.
Quarterly Sales Report
Period: Jan. 1 to March 31,1996
Region
North
Category
Computer Hardware
Computer Software
Sales
1,000,000
500,000
1,500,000
All categories
South
Computer Hardware
200,000
Computer Software
400,000
All categories
Subtotal
600,000
Total Sales 2,100,000

4세대 언어(4GL) : 어플리케이션 개발 도구들의 모임(예를 들어,
폼 패키지,보고서 작성기 등)
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
47
능동 데이터베이스

데이터베이스 내 규칙의 지정과 실행을 지원한다.

사건-조건-행위 모델:
on event
if condition
then action
- 규칙은 사건으로 기동 된다.
- 데이터베이스 시스템은 기동된 규칙들의 조건을 체크
한다; 조건을 만족하면, 데이터베이스 시스템은 지정한
행위를 실행한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
48
능동 데이터베이스(계속)


규칙은 다양한 목적으로 사용된다(예를 들어, 사용자에게
예외적인 행위에 경고하기, 재고 주문하기, 무결성 제약 조
건의 수행 등).
“종업원 급여 < 관리자 급여”라는 제약 조건을 수행하는 트
리거의 예
define trigger employee-sal
on insert employee
if employee.salary >
( select E.salary from employee as E
where E.name=employee.manager)
then abort
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
49
능동 데이터베이스(계속)





규칙의 행위가 같은 규칙을 기동시키는 사건을 야기할 수 있다
면, 규칙의 집합이 종료되도록 보장해야 한다.
여러 규칙은 그들의 우선 순위 값의 순서로 실행된다.
사건 실행 바인딩은 규칙이 언제 실행될 것인가를 지정한다.
- immediate : 사건이 발생하자마자 곧
- deferred : 트랜잭션이 완료하기 전 끝에서
- decoupled : 트랜잭션이 끝난 후 어떤 시간에
immediate 또는 deferred 사건 실행 바인딩을 가진 에러 처리는
트랜잭션 회복의 일부로서 처리된다.
decoupled 실행에 대한 에러 회복은 매우 어렵다 - 규칙 시스템
은 decoupled 규칙 실행 중 실행 시간 에러가 발생하지 않도록
설계되어야 한다.
Copyrightⓒ 1999 서울산업대학교 전자계산학과 석상기 교수
50