데이터 베이스(6), DML, 트리거와 주장

2022. 10. 21. 19:35강의 내용 정리/데이터베이스

728x90
반응형

DML, 트리거와 주장


1. DML

1) INSERT 문

INTO 다음에 삽입하는 릴레이션을 넣을 수 있는데, 이때 선택적으로 애트리뷰트 리스트를 넣을 수 있다.

삽입되는 값은 튜플 형식으로 주는데 이를 해석하는 방법에 대해 정의를 하는 것이다. 이를 명시하지 않으면 create table을 했을 때 주어진 애트리뷰트의 순서대로 처리한다.

 

오라클의 옛날 버전에서는 empty string을 null 값으로 줬지만 이를 구분하는 것이 맞다.

null: ^

 

 

SELECT 문을 INSERT 문에서 사용하게 될 경우에는 SELECT를 통해 추출한 튜플들을 삽입하는 명령어가 된다.

이때 SELECT를 사용해서 INSERT를 하는 경우에는 어트리뷰트의 도메인이 동일해야한다. 따라서 이는 SAME이 아닌 COMPATIBLE해야한다.

 

INTO 테이블 이름 뒤에 어트리뷰트 리스트를 작성하는 이유

릴레이션 뒤에 어트리뷰트 리스트를 사용하면 CREATE TABLE을 했을 때의 순서를 기억하지 않아도 된다.

또한 일부 어트리뷰트의 값만 줘도 된다. 값을 주지 않는 경우에는 널 값이나 디폴트 값을 준다. 만약 널 값을 허용하지 않거나 디폴트 값이 없는 경우에는 삽입이 안된다. 일종의 무결성 체크를 하는 것이다.

 

ex)

INTO DEPT(DNAME, DEPTNO) VALUES ('홍보부', 5)

INTO DEPT(DEPTNO, DNAME) VALUES (5, '홍보부')

 


 

2) DELETE문

주어진 조건을 만족하는 모든 튜플을 삭제한다. 만약 조건이 없는 경우에는 모든 튜플을 삭제한다. 

cf) 릴레이션 삭제: DROP

 


3) UPDATE 문

이미 존재하는 튜플의 값을 수정한다.

 

UPDATE 뒤에 수정하고자하는 릴레이션의 이름을 전달한다.

SET 뒤에는 변경할 값을 적는다. 이때 어트리뷰트 = 값(식)을 적는다.

WHERE가 있다면 조건을 만족하는 튜플에 대해, 없다면 모든 튜플에 대해 값을 수정한다.

 


2. 트리거와 주장

1) 트리거

명시된 이벤트(데이터베이스의 갱신)가 발생할 때마다 dbms가 자동적으로 수행하는, 사용자가 정의하는 문

데이터베이스의 무결성을 유지하기 위해 사용한다.

테이블을 정의 시 표현할 수 없는 비즈니스 규칙을 수행하는 역할을 한다.

ex) 승진 -> 급여 업데이트 등등

 

(1) 트리거의 표현 요소(ECA 규칙)

(a) event

(b) condition

(c) action

 

SQL3부터 표준에 포함되어있고, 대부분의 상용 관계 DBMS에서 제공된다.

 

INSERT, DELETE, UPDATE가 일어나면 트리거가 데이터 베이스에 대해 트리거 동작을 수행한다.

 

각 질의어마다 트리거를 설정한다.

 

 

(2) 트리거의 형식

트리거의 이름은 적절하게 만든다.

AFTER: 트리거를 유발하는 이벤트를 OR로 연결된 리스트이다.  ON 뒤에 릴레이션을 준다.

cf) BEFORE: 어떤 이벤트 동작 이전에 처리하도록 한다.

WHEN: 추가적으로 조건을 줄 수 있다.

BEGIN ~ END: 추가적인 SQL문들을 사이에 적어 넣을 수 있다.

 

이벤트가 주어지더라도 WHEN 조건을 만족하지 않으면 해당 트리거는 수행되지 않는다.

 

이벤트: 새로운 사원 튜플이 삽입

조건: 급여가 1500000만보다 작을 때

동작: 급여를 10% 인상

REFERENCING NEW AS: 새로 참조할 테이블의 이름을 정의한다.

 

트리거가 연쇄적으로 활성화될 수 있다. 

 

2) 주장(ASSERTION)

제약조건을 위반한 연산이 수행되지 않도록 한다.

SQL3에는 포함되어있지만 대부분의 상용 DBMS에서 지원하고 있지는 않다.

어떤 조건을 명시해서 해당 조건이 항상 성립해야한다고 명시할 수 있다. 트리거보단 좀 더 일반적인 무결성 제약조건이지만 여러 연산에 대해 이벤트를 처리한 뒤, 해당 조건에 맞지 않으면 롤백을 해야하기에 이를 체크하는 것이 어렵다. 따라서 이는 지원하지 않는 경우가 많다.

일반적으로 두 개 이상의 테이블에 영향을 미치는 제약조건을 명시하기 위해 사용된다.

 

 

 

STUDENT 테이블: 참조되는 테이블

ENROLL 테이블: 참조하는 테이블

 

위와 같이 참조 무결성 제약조건을 정의하지 않고 ASSERTION을 사용해 체크하도록 할 수 있다.

 

Universal Quantifier: 모든 것에 대해 만족하면 True이다. sql에서는 이를 사용하지 않는다. 따라서 위와 같이 모든 x가 F를 만족한다로 표현할 수 없다.

Existial Quantifier: 존재하지 않는다라는 표현으로 바꾼다.

 

cf) EXISTS  ~ IN 을사용할 경우

ENROLL 테이블에 이미 STUDENT 테이블에 대한 값이 있기에 EXISTS는 항상 참이 된다.

728x90
반응형