Chapter 5: 관계형 데이터베이스 설계

💡

학습 주제

관계형 데이터 모델, 관계형 데이터베이스 제약 조건 및 ER-관계 매핑

업데이트 작업으로 인한 무결성 위반 및 위반 처리 방법

배경 관계형 모델 개념 비공식 정의 공식 정의 - 스키마 공식 정의 - 튜플 공식 정의 - 도메인 공식 정의 - state 공식 정의 요약 공식 정의 - 예시 예시: STUDENT 릴레이션 릴레이션의 특징 관계형 모델 제약 조건 및 관계형 데이터베이스 스키마 제약 조건 (Constraints)카테고리 2: 스키마 기반 또는 명시적 제약 조건 키 제약 조건 (Key constraints)관계형 모델 제약 조건 및 관계형 데이터베이스 스키마 관계형 데이터베이스 상태 구축된 데이터베이스 상태 개체 무결성 제약조건 참조 무결성 제약조건 다른 유형의 제약 조건 엔티티-관계 매핑을 통한 관계형 데이터베이스 설계 관계에 대한 Update 작업들 INSERT 작업에 대한 가능한 위반 사례들 DELETE 작업에 대한 가능한 위반 사례들 DELETE 작업에 대한 요약 UPDATE 작업에 대한 가능한 위반 사례들 UPDATE 작업에 대한 요약 트랜잭션 개념 (쿼리와 비교하여)주요 포인트

배경

첫 번째 관계형 데이터 모델은 E. Codd에 의해 1970년에 다음 논문에서 소개되었음

"A Relational Model for Large shared Data Banks” Communications of the ACM, June 1970
이 모델이 매력적인 이유: 간결성과 수학적 기초 덕분
이 논문은 데이터베이스 관리 분야에서 큰 혁명을 일으킴
논문 저자는 ACM Turing Award (컴퓨터 과학의 노벨상)을 수상하게 됨

관계형 모델:

수학적인 관계 (값들의 표와 같은) 개념을 기본 구성 요소로 사용하며,

이론적 기반은 집합 이론과 1차 술어 논리에 있음

이를 통해 우리는 관계형 모델의 기본적인 특성과 제약 조건에 대해 논의할 것임

관계형 모델의 첫 상용 구현은 1980년대 초에 등장했음

IBM의 MVS 운영 체제에서의 SQL/DS 시스템
Oracle DBMS: 현재 수업에서 사용

이후로 이 모델은 다음과 같은 많은 기관에서 구현되었음

상용으로 많이 사용되는 관계형 DBMS(RDBMS)

IBM의 DB2, Oracle의 Oracle, SAP으로 이전된 Sybase DBMS, 그리고 Microsoft의 SQL Server 및 Microsoft Access

오픈 소스로 많이 사용되는 RDBMS

Oracle로 이전된 MySQL, PostgreSQL, SQLite(모바일용), MariaDB 등

관계형 모델 개념

비공식 정의

릴레이션: "집합" 개념을 기반으로 한 수학적인 개념

관계형 모델에서 데이터베이스는 릴레이션의 모음

릴레이션은 값들의 테이블 (테이블: 비공식적인 용어) 또는 레코드의 평면 파일처럼 보임 (평면 구조 때문).

이전 수업에서의 STUDENT 테이블을 상기

릴레이션은 일련의 행(행: 비공식적인 용어)을 포함하는 것이 일반적

각 행의 데이터 요소는 일반적으로 실제 세계의 엔터티 또는 릴레이션과 일치하는 특정한 사실을 나타냄
형식적인 모델에서는 행을 튜플(튜플: 공식적인 용어)이라고 부름

각 열에는 열 헤더(헤더: 비공식적인 용어)가 있으며 해당 열의 데이터 항목의 의미를 전달

형식적인 모델에서는 헤더를 애트리뷰트(애트리뷰트: 공식적인 용어)라고 부름

릴레이션의 키 (가장 중요)

각 행에는 해당 테이블에서 그 행을 고유하게 식별하는 데이터 "요소"의 값인 키가 있음
STUDENT 테이블에서 키 애트리뷰트는 무엇인가?
때로는 행 ID 또는 시퀀셜 번호가 사용될 수 있으며, 이것을 키라고 하며 대체(또는 artificial)키라고도 하며, 단순히 테이블에서 행을 식별하기 위한 것

공식 정의 - 스키마

릴레이션의 스키마

와 같이 표기

: 릴레이션 이름,
: 애트리뷰트 목록

관계를 설명하는 데 사용됨
관계 의 차수 (또는 고도): 의 애트리뷰트 수

예시:


CUSTOMER (Cust-id, Cust-name, Addr, Phone#)

관계 이름은 무엇인가?
네 개의 애트리뷰트로 정의되었는데 이는 무엇인가?

각 애트리뷰트는 유효한 값 집합인 도메인을 가짐

예) Cust-id의 도메인은 6자리 숫자

무부호 32비트 정수의 도메인과 비교:

공식 정의 - 튜플

튜플: 값들의 순서 있는 집합. < ... > 꺾쇠 괄호로 둘러싸인 형태

각 값은 적절한 도메인에서 유래한 것임

CUSTOMER 릴레이션(테이블)의 튜플(행)은 다음과 같은 형태를 가짐

<632895, "홍길동", "대구 북구 대학로 80 IT-5 41566", "053-950-6372">
4-튜플이라고 불림

관계(테이블)는 이러한 튜플(행)들의 집합

공식 정의 - 도메인

도메인: 원자적 (분할할 수 없는) 값들의 집합.

논리적인 정의 (또는 이름)

예) Korea_cell_phone_numbers (일반적으로) 한국에서 유효한 01로 시작하는 11자리 전화번호 집합을 나타냄

해당 도메인에 대해 정의된 데이터 타입이나 데이터 포맷이 있음

예1) Korea_cell_phone_numbers는 다음 형식을 따름: (01X)-dddd-dddd
예2) 날짜는 다양한 형식을 가짐: 년, 월, 일 형식으로 표시됨

yyyy-mm-dd 또는 dd/mm/yyyy

관계 (테이블)에서 속성 (열) 이름은 해당 도메인에 대한 역할을 함

해당 속성에 해당하는 날짜 요소의 의미를 해석하는 데 사용됨

예) 도메인 Date를 사용하여 Invoice-date 또는 Payment-date와 같이 두 가지 다른 의미로 속성을 정의할 수 있음

공식 정의 - state

relation state: 속성 도메인들의 카테시안 곱의 부분집합

각 도메인에는 해당 속성이 가질 수 있는 모든 가능한 값을 포함함
예: 속성 Cust-name: 최대 길이의 문자열 도메인을 기반으로 정의.

30자로 정의 - dom(Cust-name): varchar(30)

이러한 문자열이 CUSTOMER 관계에서 수행하는 역할은 고객의 이름임

공식 정의 요약

주어진 릴레이션

: 릴레이션의 스키마

: 릴레이션의 이름
: 릴레이션의 속성

: 릴레이션 의 특정 state (또는 "값" 또는 "population")

의 특정 상태인 튜플(행)의 집합
, 여기서 는 -튜플
, 여기서 각 는 의 요소

Informal한 용어	Formal한 용어
테이블 (Table)	릴레이션 (Relation)
열 헤더 (Column Header)	어트리뷰트 (Attribute)
열 내 모든 가능한 값 (All posible values in a column)	도메인 (Domain)
행 (Row)	튜플 (Tuple)
테이블 정의 (Table Definition)	릴레이션의 스키마 (내용) (Schema (intension) of a Relation)
데이터가 채워진 (로드된) 테이블 (Populated (Loaded) Table)	릴레이션의 상태 (확장) (State (extension) of the Relation)

공식 정의 - 예시

관계 스키마 을 다음과 같이 가정

그러면, 로 가능한 모든 조합을 포함함

예를 들어 와 같음

관계 상태인

예를 들어, 이다.

과 에 정의된 관계 의 경우 릴레이션 의 한 가지 가능한 상태(또는 확장)인 임.
예시의 에는 네 개의 2-tuple이 있음. 무엇인가?

정의 요약

비공식적인 용어	공식적인 용어
테이블	릴레이션
열 헤더	속성
가능한 모든 열 값	도메인
행	튜플
테이블 정의	릴레이션의 스키마 (내포)
인기있는 (로드된) 테이블	릴레이션의 상태 (외연)

예시: `STUDENT` 릴레이션

릴레이션의 특징

릴레이션 내 튜플의 순서

튜플은 순서가 있는 것으로 간주되지 않으며, 비록 표 형태로 나타나지만 집합과 같음
튜플의 순서는 릴레이션 정의의 일부가 아니며, 릴레이션은 논리/추상 수준에서 사실을 표현
예를 들어, 튜플의 순서가 다른 STUDENT 릴레이션 → 이전 것과 동일한 것으로 간주됨

관계 스키마 에서 속성의 순서 (그리고 각 튜플 내의 값들의 순서)

의 속성들
튜플 내의 값들, 또는

순서가 고려되었다고 간주됨

관계의 정의에 따르면, -튜플은 개의 값의 순서가 지정된 목록(또는 일종의 텐서)
참고: 그러나 "더 일반적인" 대체 정의에는 속성의 이름과 각 속성의 값이 한 쌍으로 포함되어 있어 순서가 존재하지 않음

→ 속성과 값의 순서가 관계 정의의 일부가 아닐 때 동일함

→ 튜플들은 "자기 기술"임. 왜?


시스템이 데이터 자체 외에도 그 데이터의 구조(스키마)에 대한 설명을 저장하고 있음을 의미합니다. 이는 데이터와 함께 데이터를 설명하는 메타데이터가 함께 저장되어, 시스템이 어떤 데이터가 있는지, 그리고 그 데이터가 어떻게 구성되어 있는지를 '알고' 있다는 것을 의미합니다.

튜플이 자기 기술적이라는 것은 다음과 같은 이유 때문입니다:

1. 메타데이터: 각 튜플은 그 자체로 정보를 가지고 있지 않습니다. 그러나 데이터베이스 관리 시스템(DBMS) 내의 시스템 카탈로그나 메타데이터에 저장된 스키마 정보를 통해, 각 튜플이 어떤 데이터필드를 가지고 있는지, 그리고 그 필드들이 어떤 데이터 유형에 속하는지에 대한 정보를 제공합니다.
2. 스키마와의 연동: 튜플은 해당 데이터베이스의 스키마와 밀접한 관련이 있습니다. 스키마는 튜플의 구조와 제약 조건을 정의하며, 이는 데이터베이스 내의 각 튜플이 어떻게 구성되어야 하는지에 대한 명확한 지침을 제공합니다.
3. 데이터 추출과 사용: 자기 기술적 특성 덕분에, 응용 프로그램이나 사용자는 DBMS가 제공하는 쿼리 언어(SQL 등)를 사용하여 필요한 데이터를 추출할 수 있습니다. 이러한 쿼리는 데이터베이스 스키마를 기반으로 작성되므로, 데이터의 구조와 의미를 이해하고 있는 시스템을 통해 처리됩니다.

결론적으로, "자기 기술적" 특성은 데이터베이스 시스템이 데이터의 의미와 구조를 이해하고 관리할 수 있도록 지원하며, 이는 데이터베이스의 유연성과 확장성을 향상시키는 중요한 요소입니다.

튜플 내 값:

모든 값은 원자적으로 간주

복합 및 다중값 속성은 허용되지 않음

이것은 나중에 논의할 첫 번째 정규 형식 가정을 기반으로 한 플랫 릴레이션 모델이라고 불림
복합 속성 → 단순 속성
다중값 → 별도의 릴레이션

튜플 내 각각의 값은 반드시 해당 열의 속성 도메인에서 가져온 값이어야 함
만약 가 의 릴레이션 상태 의 튜플(행)이라면

각 는 의 값이어야 함

특정 튜플에서의 NULL 값

다음과 같은 값을 나타내는 데 사용됨

Unknown (진짜 모를 경우)
Not Available (집 전화 번호가 없음)
Inapplicable (건강 검진에서 여성 또는 남성을 고를 때)

표기법:

: 릴레이션 의 속성 이름 (예: STUDENT.Name)

그러나 특정 관계의 모든 속성 이름은 고유해야 함

우리는 튜플 의 구성 요소 값을 다음과 같이 참조함

이것은 튜플 에 대한 속성 의 값 를 나타냄
비슷하게, (또는, ): 튜플 에서 각각 의 값을 포함하는 서브튜플

STUDENT 관계의 첫 번째 튜플 를 고려해볼 것

관계형 모델 제약 조건 및 관계형 데이터베이스 스키마

제약 조건 (Constraints)

데이터베이스에서 결정해야 할 사항:

허용되는 값
허용되지 않는 값

3 가지 주요 범주(또는 유형)가 존재

카테고리 1: 본질적 또는 내재적 제약 조건

데이터 모델 그 자체에 기반함
예) 관계 모델은 어떤 속성에 대한 값으로 목록을 허용하지 않음

카테고리 2: 스키마 기반 또는 명시적 제약 조건

데이터 모델 스키마에서 직접 표현됨. 예) 고유 제약조건
참고) ER 모델에서의 전체/부분 참여 또는 최소/최대 카디널리티 비율

카테고리 3: 응용 프로그램 기반 또는 의미적 제약 조건 (또는 비즈니스 규칙)

응용 프로그램 프로그램에서 적용되어야 하며 모델로는 설명할 수 없음
예) 직원의 나이는 65세 미만이어야 함

카테고리 2: 스키마 기반 또는 명시적 제약 조건

제약 조건은 "모든" 유효한 관계 상태에서 유지되어야 하는 조건 (예외 없음)

관계 모델의 주요 제약 조건 유형 3가지 (’카테고리 2’에 관한 내용)

키 제약 조건

유일 제약 조건

엔터티 무결성 제약 조건

참조 무결성 제약 조건

더불어, 도메인 제약 조건

튜플의 모든 값은 반드시 해당 속성의 도메인에서 가져와야 함
값은 허용된 경우 해당 속성에 대해 null이 될 수 있음

키 제약 조건 (Key constraints)

정의에 의하면, 릴레이션 내의 모든 튜플은 고유해야 함

릴레이션은 튜플의 집합이기 때문에, 동일한 요소가 없음을 의미함

릴레이션 의 슈퍼키?

의 속성 중 하위 집합 는 다음 조건을 충족함
어떤 유효한 관계 상태 에서도 두 개의 튜플이 에 대해 동일한 값을 가지지 않는다는 고유성 속성 예)

즉, 내의 서로 다른 튜플 과 에 대해 임
이 조건은 어떤 "유효한" 상태 에서도 유지되어야 함

릴레이션 의 키?

"최소한의" 수퍼키
즉, 키는 슈퍼키 인데, 에서 속성을 제거하면 슈퍼키가 아닌 속성의 집합이 결과로 나오는 것임

[Pair Question (PQ)] 슈퍼키는 키인가?

예시: CAR 관계 스키마를 고려

CAR (State, Reg#, VIN*, Make, Model, Year)
[Q] CAR은 두 개의 슈퍼키를 가지고 있음. 이것들은 무엇인지?

SuperKey1 = {State, Reg#}
SuperKey2 = {VIN}

둘 다 CAR의 슈퍼키임
[Q] {VIN, Make}는 키인가, 슈퍼키인가, 아니면 둘 다인가?

{VIN, Make}는 슈퍼키에 해당합니다. 왜냐하면 VIN(차대번호)는 자동차를 고유하게 식별하기 때문에, 자동차의 제조사(Make) 정보를 추가할 필요가 없기 때문입니다. 즉, VIN 하나만으로 각 행을 식별할 수 있습니다. 여기서 "Make"는 불필요한 정보가 되어 슈퍼키의 정의에 부합하지만 키 (특히 후보키)의 최소성 요건을 만족시키지 않습니다.

[Q] {State, Reg#}는 키인가, 슈퍼키인가, 아니면 둘 다인가?

{State, Reg#} 조합은 키이자 슈퍼키입니다. 이 조합은 각 행을 고유하게 식별할 수 있는 최소한의 속성으로 구성되어 있으며, 따라서 후보키 (키가 될 수 있는 조건을 갖춘 슈퍼키)가 됩니다. 각각의 자동차는 고유한 등록 번호(Reg#)를 가지고 있으며, 이 번호는 주(State)에 따라 다를 수 있기 때문에, 이 두 속성의 조합이 각 차량을 고유하게 식별하는 데 사용됩니다. 따라서 이는 키의 조건을 충족시키는 동시에 슈퍼키의 정의에도 부합합니다.

일반적으로,

모든 키는 슈퍼키임(하지만 그 반대는 아님)
키를 포함하는 모든 속성 집합은 슈퍼키임. 왜?
최소한의 슈퍼키는 또한 키임
또한, 관계 스키마는 여러 개의 키를 가질 수 있고, 그 각각을 후보 키라고 함. 그 중 하나는 “임의로” 기본 키로 선택됨

예) CAR (State, Reg#, VIN, Make, Model, Year)

VIN: 기본 키 속성으로 선택되었음 Q: 왜?

일반적으로 관계형 스키마에서 밑줄로 표시됨
다른 후보 키들은 고유 키로 지정되고 밑줄로 표시되지 않음. SQL에서는 “unique (State, RegNo)”로 표현함

기본 키 값은

관계 내 각 튜플을 고유하게 식별하기 위해: 튜플 식별자를 제공함

다른 튜플에서 튜플을 참조하기 위해; 참조하는 관계에서 외래 키로 지정됨

키에 대한 일반 규칙:

크기 측면에서 속성의 수가 가장 적은 후보 키를 기본 키로 선택함

하지만 항상 그런 것은 아니며... 때때로 디자이너가 결정

관계형 모델 제약 조건 및 관계형 데이터베이스 스키마

관계형 데이터베이스 스키마란?

동일한 데이터베이스에 속하는 관계 스키마의 집합 임

: 전체 데이터베이스 스키마의 이름
및 무결성 제약 조건 (ICs)의 집합

IC: 데이터베이스의 일관성/무결성을 유지해야 하는 제약 조건

키, Not-Null, 도메인, 그리고 다른 두 종류의 제약 조건

은 데이터베이스 내의 개별 관계 스키마의 이름들임

우리는 COMPANY의 ER 스키마를 회상하고, 그것의 관계형 스키마를 여섯 개의 관계 스키마와 함께 볼 것임

COMPANY = {EMPLOYEE, DEPARTMENT, DEPT_LOCATIONS, PROJECT, WORKS_ON, DEPENDENT}

관계형 데이터베이스 상태

정식으로, S의 관계형 데이터베이스 상태 DB는 다음과 같이 정의됨

관계 상태의 집합, 으로

각각의 는 의 상태임
관계 상태는 IC에서 명시된 무결성 제약 조건을 만족함

관계형 데이터베이스 상태는 가끔 관계형 데이터베이스 스냅샷(또는 인스턴스)라고도 불림

(하지만 우리는 인스턴스라는 용어를 사용하지 않음. 왜냐하면 인스턴스는 단일 튜플에도 적용되기 때문)

제약 조건을 충족하지 않는 데이터베이스 상태는 유효하지 않다고 말함

구축된 데이터베이스 상태

각 관계는 현재의 관계 상태에서 여러 튜플을 가지게 될 것임

관계형 데이터베이스 상태는 모든 개별 관계 상태의 합집합임

데이터베이스가 변경될 때마다 (즉, 튜플이 수정, 삽입, 삭제되는 경우), 새로운 상태가 생성됨

관계형 데이터베이스를 변경하기 위한 기본 작업

INSERT: 관계에 새 튜플 삽입
DELETE: 관계에서 기존 튜플 삭제
MODIFY 또는 UPDATE: 기존 튜플의 속성 수정

→ SQL의 DML 문은 이러한 작업들을 지원함

개체 무결성 제약조건

데이터베이스 스키마 내 각 관계 스키마 의 기본 키 속성은 의 어떤 튜플에서도 NULL 값을 가질 수 없음

기본 키 값은 NULL이 될 수 없음

r(R) 내 어떤 튜플 t에서도 t[PK] ≠ null
만약 PK가 여러 속성을 포함하면, 그 중 어느 것도 NULL이 허용되지 않음

왜냐하면 기본 키 값은 개별 튜플을 식별하는 데 사용됨. 만약 그들이 NULL이라면?
그러나, Non-PK 속성의 경우 NULL 값이 허용되거나 허용되지 않을 수 있음

참조 무결성 제약조건

(둘 이상의) 두 관계에 관련됨

지금까지의 제약 조건은 “단일” 관계에 적용되었음을 유의

두 관계 내 튜플 간의 “일관성”을 유지하는 데 사용됨

예) EMPLOYEE의 Dno: 각 직원이 일하는 부서 번호

모든 EMPLOYEE 튜플의 값은 DEPARTMENT 관계의 어떤 튜플의 Dnumber 값과 일치해야 함

두 관계 내 튜플 간의 관계를 명시하는 데 사용됨

참조 관계: 이것은 무엇인지
참조된 관계: 이것은 무엇인지

참조 관계 내의 튜플은 외래 키 속성이라고 불리는 속성을 가지며, 이는 참조된 관계 의 기본 키 속성 를 참조함

의 튜플 이 의 튜플 를 참조하게 되면, 임

참조 무결성 제약 조건은 관계형 데이터베이스 스키마에서 화살표로 표시할 수 있음

에서 로 (예: : EMPLOYEE, : DEPARTMENT, : Dno, : Dnumber)

참조 관계 의 외래 키 속성의 값은 다음 중 하나가 될 수 있음

: 즉, 참조된 관계 내의 대응되는 기본 키 의 기존 기본 키 값의 값이거나

null (아직 할당되지 않았다?!)

만약 가 null이라면(2번 케이스에서 볼 수 있듯이), 그러면 내의 는 그 자체의 기본 키의 일부가 되어서는 안 됨

왜냐하면, 그렇게 되면 개체 무결성 제약조건을 위반하게 됨

다른 유형의 제약 조건

의미적 무결성 제약 조건

응용 프로그램 의미 기반

모델로는 표현할 수 없음

예) "한 직원이 모든 프로젝트에 대해 일하는 시간은 주당 최대 52시간으로 제한됩니다." 모델로는 불가능한가?

응용 프로그램 내에서 명시될 수 있음

일반적인 제약 사양 언어를 사용하여 강제할 수 있음

트리거와 단언문(assertions)을 위한 CREATE TRIGGER 및 CREATE ASSERTION 문장 (SQL-99에서 확인)

CREATE TABLE 문은 다음을 선언하는 데 사용될 수 있음 • (i) 키, (ii) 후보 키 (고유 제약), (iii) NOT NULL, (iv) 엔터티 무결성, (v) 외래 키, (vi) 참조 무결성 등에 대한 다양한 제약 조건

엔티티-관계 매핑을 통한 관계형 데이터베이스 설계

관계에 대한 Update 작업들

(1) 튜플 삽입(INSERT), (2) 삭제(DELETE), 또는 (3) 수정(MODIFY/UPDATE).

이러한 작업이 적용될 때, 관계형 DB에서 무결성 제약 조건의 위반은 발생하지 않아야 함

다음 사항에 대해 논의함

위반될 수 있는 제약 조건의 유형
위반 발생시 취해질 수 있는 조치의 유형

여러 업데이트 작업이 그룹화되어야 할 수도 있음

업데이트가 자동으로 다른 업데이트를 유발할 수 있음

이는 무결성 제약 조건을 유지하는 데 필요할 수 있음
예) 새로운 직원이 오면, 직원의 총 수가 하나 증가

무결성 위반의 경우, 대략 4가지 조치를 취할 수 있음

위반을 일으키는 작업을 취소함

RESTRICT (작업 없음) 또는 REJECT 옵션; 많은 DBMS에서 채택됨

작업을 수행하지만 사용자에게 위반에 대해 알림

원치 않음; 대부분의 DBMS에서 이렇게 하지 않음

위반을 수정하도록 추가 업데이트를 트리거함

CASCADE (갱신이 전파됨), SET NULL, 또는 SET DEFAULT 옵션: 참조에서 참조된 것으로

사용자 지정 오류 수정 루틴을 실행함

프로그램이 작성되어야 합니다.

INSERT 작업에 대한 가능한 위반 사례들

EMPLOYEE에 <'Cecillia', 'F', 'Kolonsky', NULL, '1960-04-05', '6357 Windy Lane, Katy, TX', 'F', 28000, NULL, 4> 삽입.

문제가 있는지? 있다면 어떤 제약이 위반되는지?

EMPLOYEE에 <'Alicia', 'J', 'Zelaya', '999887777', '1960-04-05', '6357 Windy Lane, Katy, TX', 'F', 28000, '987654321', 4> 삽입. 문제가 있는지?

EMPLOYEE에 <'Cecilia', 'F', 'Kolonsky', '677678989', '1960-04-05', '6357 Wind, Katy, TX', F, 28000, '987654321', 7> 삽입. 문제가 있는지?

또한, 도메인 제약조건이 위반될 수 있거나 삽입이 허용될 수 있음

DELETE 작업에 대한 가능한 위반 사례들

Essn = ‘999887777’ 및 Pno = 10인 WORKS_ON 튜플 삭제.

Ssn = ‘999887777’인 EMPLOYEE 튜플 삭제.

2가지의 옵션

튜플을 참조하는 여러 튜플로 인해 거부 또는

삭제하고 WORKS_ON에 삭제를 전파

Ssn = ‘333445555’인 EMPLOYEE 튜플 삭제

많은 튜플이 영향을 받는 최악의 경우

예) 위의 WORKS_ON 테이블을 참조

DELETE 작업에 대한 요약

DELETE는 참조 무결성 제약 조건만을 위반할 수 있음

왜냐하면 삭제되는 튜플이 데이터베이스 내의 다른 튜플로부터 "참조되고" 있기 때문

세 가지의 옵션

RESTRICT 옵션: 삭제를 거부함

CASCADE 옵션: 튜플을 삭제한 다음, 삭제된 튜플을 참조하는 튜플들을 삭제함

SET NULL 또는 SET DEFAULT 옵션: 삭제 후 참조하는 튜플의 외래 키를 NULL 또는 기본값으로 설정함

외래 키 제약 조건 각각에 대해 위 옵션 중 하나가 논리적 데이터베이스 설계 중에 지정되어야 함

예) SQL에서 CREATE TABLE products (p_id numeric(10) not null, s_id numeric(10) not null, FOREIGN KEY (s_id) REFERENCES supplier(s_id) ON DELETE CASCADE);

UPDATE 작업에 대한 가능한 위반 사례들

Ssn = ‘999887777’인 EMPLOYEE 튜플의 연봉을 100000으로 업데이트. 문제가 있는지?

만약 연봉이 99999를 초과할 수 없다면?


만약 연봉이 99999를 초과할 수 없는 도메인 제약 조건이 있다면, 이 업데이트 작업은 도메인 제약 조건을 위반하게 됨

Ssn = '999887777'인 EMPLOYEE 튜플의 Dno를 7로 업데이트. 문제가 있는지?


Dno를 7로 업데이트 하는 것이 기존에 존재하는 DEPARTMENT 테이블의 Dnumber 값과 일치하는지 확인해야 함. 만약 Dnumber = 7인 튜플이 DEPARTMENT 테이블에 없다면, 이 업데이트 작업은 참조 무결성 제약 조건을 위반하게 됨

Ssn = ‘999887777’인 EMPLOYEE 튜플의 Ssn을 ‘987654321’로 업데이트. 문제가 있는지?


이 업데이트 작업은 EMPLOYEE 테이블의 기본 키에 대한 제약을 위반할 가능성이 있음. 만약 ‘987654321’이 이미 EMPLOYEE 테이블에 존재하는 Ssn이라면, 이 업데이트는 기본 키 제약을 위반하므로 작업이 거부되어야 함. 또한, 다른 테이블에서 ‘999887777’를 참조하는 외래 키가 있을 경우, 참조 무결성 제약도 확인해야 함

Ssn = ‘999887777’인 EMPLOYEE 튜플의 Ssn을 NULL로 업데이트. 문제가 있는지?


Ssn이 EMPLOYEE 테이블의 기본 키라면, NOT NULL 제약 조건을 위반하게 됨. 기본 키는 NULL 값을 가질 수 없기 때문에, 이 작업은 거부되어야 함. 또한, Ssn이 외래 키로 다른 테이블에서 참조되고 있다면 참조 무결성 제약도 위반될 수 있음

UPDATE 작업에 대한 요약

UPDATE 작업은 (i) 도메인 제약 조건과 (ii) 수정되는 속성에 대한 NOT NULL 제약 조건을 위반할 수 있음

업데이트되는 속성에 따라 다른 제약 조건들도 위반될 수 있음

해당 속성(업데이트 대상)이 기본 키(PK) 속성이라면

튜플 하나를 삭제하고 그 자리에 새 튜플을 삽입하는 것과 유사

처리하기 위해 DELETE에 대한 유사한 옵션이 지정되어야 함

해당 속성이 외래 키(FK) 속성이라면,

참조 무결성 제약 조건을 위반할 가능성이 가장 높음

처리하기 위해 DELETE에 대한 유사한 옵션이 지정되어야 함

해당 속성이 PK도 FK도 아닌 경우,

도메인 제약 조건이나 not-null 제약 조건만을 위반할 수 있음

아마도, 단순히 거부함

트랜잭션 개념 (쿼리와 비교하여)

관계형 데이터베이스를 대상으로 하는 데이터베이스 응용 프로그램은 일반적으로 하나 이상의 트랜잭션을 실행함

트랜잭션: 원자적으로 수행되어야 하는 일련의 데이터베이스 작업(쿼리, 삽입, 삭제 및/또는 업데이트)을 포함함

예: 은행 이체

온라인 트랜잭션 처리 시스템에서 관계형 데이터베이스를 대상으로 실행되는 대다수의 상업용 응용 프로그램은 초당 수백 또는 수천 건의 트랜잭션을 실행함

관계형 데이터베이스를 대상으로 실행되는 데이터베이스 응용 프로그램

주요 포인트

데이터의 관계형 모델:

모델링 개념

관계, 튜플, 속성, 도메인, 상태, ...

데이터 구조
(명시적 스키마 기반) 제약 조건: 키, 엔터티 무결성, 참조 무결성 및 도메인 제약 조건

게다가, 내재적인 모델 기반 제약 조건 및 의미론적 제약 조건

관계의 특성

튜플에 대해서는 순서에 민감하지 않지만, 속성과 값에 대해서는 그렇지 않음
Null은 가능한 한 피해야 함

관계형 데이터베이스 수정 작업:

삽입, 업데이트 및 삭제
작업 후 제약 조건을 위반하지 않도록 주의해야 함

트랜잭션의 개념 (쿼리와 대비)