CHAPTER 4 관계 데이터 모델과 관계 데이터베이스 제약조건

Chapter Outline Relational Model Concepts Relational Model Constraints and Relational Database Schemas Update Operations and Dealing with Constraint Violations

관계 모델의 개념 관계 데이터 모델은 관계/릴레이션(relation) 개념을 기반으로 함 데이터 관리에 대한 관계형 접근 방식의 강점은 관계 이론이 제공하는 공식적인/이론적인 (formal) 기초에서 비롯됩니다. 이 장에서 공식적인 관계 모델의 필수 사항을 검토합니다. 실제로는, SQL 기반의 표준 모델이 있습니다. 이는 5 장과 6 장에 언어로 설명되어 있습니다. Note: 공식적인 모델과 실제 모델 사이에는 몇 가지 중요한 차이점이 있음

관계 모델의 개념 릴레이션 집합의 아이디어에 기초한 수학적 개념 이 모델은 1970 년 IBM Research의 E.F. Codd 박사가 다음 논문에서 처음 제안했음 : "A Relational Model for Large Shared Data Banks," Communications of the ACM, June 1970 위의 논문은 데이터베이스 관리 분야에서 큰 혁명을 일으켰으며 영광스러운 ACM Turing Award를 수상했음

비공식적인 정의 비공식적으로, 릴레이션/관계(relation)는 값들의 표처럼 보임. 릴레이션은 보통 행들의 집합을 포함함. 각 행의 데이터 요소는 실제 세계의 엔티티 또는 관계 (relationship)에 해당하는 특정 사실을 나타냄. 공식적인 모델에서, 행은 튜플이라고 부른다. 각 열에는 해당 열에있는 데이터 항목의 의미를 나타내는 열 제목을 가짐. 공식적인 모델에서, 열 제목은 애트리뷰트 이름(또는 그냥 애트리뷰트)라고 부른다.

릴레이션의 예 4.1

비공식적인 정의 릴레이션의 키: STUDENT 테이블에서, SSN이 키이다. 각 행에는 테이블에서 해당 행을 고유하게 식별하는 데이터 항목 (또는 항목의 집합) 값이 있다. 이를 키라고 부름 STUDENT 테이블에서, SSN이 키이다. 가끔 행-ID 또는 일련 번호가 테이블에서 행을 식별하기 위한 키로 지정됩니다. 이를 가상 키 (artificial key) 또는 대리 키 (surrogate key) 라고 함

공식적인 정의 - 스키마 릴레이션의 스키마 (또는 설명) : 예제: R(A1, A2, .....An)로 표기 R은 릴레이션의 이름 A1, A2, ..., An는 릴레이션의 애트리뷰트이다. 예제: CUSTOMER (Cust-id, Cust-name, Address, Phone#) CUSTOMER는 릴레이션의 이름 4개의 애트리뷰들로 정의됨: Cust-id, Cust-name, Address, Phone# 각 속성에는 도메인 또는 유효한 값의 집합이 있음 예를 들어, Cust-id의 도메인은 6자리 숫자이다.

공식적인 정의 - 튜플 튜플은 값들의 순서 집합임 (삼각 괄호 ‘<…>’로 묶음) 각 값은 적절한 도메인에서 나옴 CUSTOMER 릴레이션의 한 행은 4-튜플(4-tuple, 4-쌍) 4개의 값을 가질 수 있다. 예를 들면: <632895, "John Smith", "101 Main St. Atlanta, GA 30332", "(404) 894-2000"> 이것은 4개 값을 값는 4-튜플 (4-쌍)이라 부른다 CUSTOMER 릴레이션내에 있는 한 튜플(행)이다 릴레이션은 이른 튜플 (행)들의 집합임

공식적인 정의 - 도메인 도메인은 논리적인 정의임: 도메인에는 그것을 위해 정의된 데이터 타입 또는 형식이 있음 예제: “USA_phone_numbers” 미국에서 유효한 10자리 전화번호 숫자이다. 도메인에는 그것을 위해 정의된 데이터 타입 또는 형식이 있음 USA_phone_numbers의 형식: (ddd)ddd-dddd, 여기서 d는 10진수 날짜는 yyyy-mm-dd 또는 dd mm, yyyy 형식의 년, 월, 일과 같은 다양한 형식을 갖는다. 애트리뷰의 이름은 릴레이션에서 도메인이 수행하는 역할을 지정함: 해당 애트리뷰트에 해당하는 데이터 요소의 의미를 해석하는 데 사용됨 예: 도메인 날짜는 서로 다른 의미를 갖는 를 사용하여 다른 의미로 “Invoice-date(송장 날짜)"및 “Payment-date(지급 날짜)"라는 두 애트리뷰트를 정의하는 데 사용될 수 있다

공식적인 정의 - 상태 릴레이션 상태는 해당 애트리뷰트 도메인의 카테이션 곱(Cartesian product)의 부분 집합임. 각 도메인에는 애트리뷰트가 취할 수 있는 모든 가능한 값들의 집합이 포함됩니다. 예: 애트리뷰트 Cust-name는 최대 길이가 25 인 문자열 도메인에 대해 정의됨 dom(Cust-name)은 varchar(25) 이 문자열이 CUSTOMER 관계에서 하는 역할은 고객 이름임

공식적인 정의 - 요약 공식적으로, R(A1, A2, …, An)은 릴레이션의 스키마임 R은 릴레이션의 이름임 r(R)  dom (A1) X dom (A2) X ....X dom(An) R(A1, A2, …, An)은 릴레이션의 스키마임 R은 릴레이션의 이름임 A1, A2, …, An는 릴레이션의 애트리뷰트들임 r(R): 릴레이션 R의 특정 상태 – 튜플(행)들의 집합임 r(R) = {t1, t2, …, tn} 여기서 각 ti는 n-튜플이다 ti = <v1, v2, …, vn> 여기서 각 vj는 dom(Aj)의 원소이다

공식적인 정의 - 예제 R(A1, A2)을 릴레이션의 스키마라고 가정: dom(A1) X dom(A2)는 모든 가능한 조합임: dom(A2) = {a,b,c}로 가정 dom(A1) X dom(A2)는 모든 가능한 조합임: {<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> } 릴레이션 상티 r(R)  dom(A1) X dom(A2) 예: r(R)은 {<0,a> , <0,b> , <1,c> }이 될 수 있음 이것은 A1과 A2에 대해 정의 된, 관계 R의 가능한 상태 (또는“인구”또는“확장”) 중의 하나인 r입니다. 이것은 세개의 2-튜플을 가짐: <0,a> , <0,b> , <1,c>

정의 요약 Informal Terms Formal Terms 테이블/표 릴레이션 열 제목 애트리뷰트 모든 가능한 열의 값들 도메인 행 튜플 테이블 정의 릴레이션의 스키마 채워진 테이블 릴레이션의 상태

예제 – STUDENT 릴레이션 4.1

릴레이션의 특징 릴레이션 r(R)에서 튜플들의 순서: 튜플들은 테이블 형식인 것처럼 보이지만, 순서를 갖지 않는 것으로 간주된다. 릴레이션의 튜플들의 집합으로 정의됨. 수학에서 집합은 원소들의 순서가 없음. 릴레이션 스키마 R에서 애트리뷰트들의 순서 (및 각 튜플내에서 값들의 순서): R (A1, A2, ..., An)의 속성과 t = <v1, v2, ..., vn>의 값을 순서대로 고려합니다. (그러나 릴레이션에 대한 보다 일반적인 대체 정의에는 이 순서가 필요하지 않습니다. 여기에는 각 애트리뷰트의 이름과 값을 모두 포함하도록 합니다). Example: t= { <name, “John” >, <SSN, 123456789> } 이 표현을 "자체 서술"이라고 할 수 있습니다

이전 그림과 동일한 상태 (튜플의 순서는 서로 다름) 4.2

릴레이션의 특징 튜플내의 값: 모든 값은 (나누어질 수 없는) 원자로 간주된다. 튜플의 각 값은 해당 열의 애트리뷰트 도메인에서 가져와야 합니다. 튜플 t = <v1, v2,…, vn>가 R (A1, A2,…, An)의 릴레이션 상태 r에 있는 튜플 (행)이라면, 그런 다음 각 vi는 dom (Ai)의 값이어야 합니다 특수한 NULL 값은 특정 튜플에서 알 수 없거나 사용할 수 없거나 적용할 수 없는 값을 나타내는 데 사용됩니다.

릴레이션의 특징 릴레이션 r(R)에서 튜플들은 중복되지 않음: 릴레이션은 튜플들의 집합으로 정의됨 수학에서 집합은 중복된 원소를 갖지 않음 (예) {a, b, c} = {a,a,b,b,c} (참조) {a,b,c} = {b,c,a}

릴레이션의 특징 표기방법: 튜플 t의 구성 요소 값을 다음과 같이 참조함: t[Ai] 또는 t.Ai 튜플 t를 위한 애트리뷰트 Ai의 값 vi를 표시함 유사하게, t [Au, Av, ..., Aw]는 t내에 있는 애트리뷰트 Au, Av, ..., Aw의 값을 포함하는 t의 부분 튜플을 나타낸다.

제약조건 제약 조건은 데이터베이스내에 허용 가능한 값과 그렇지 않은 값을 결정함. 제약조건에는 세가지의 중요한 형태가 있음: 1. 고유한 또는 묵시적인 제약조건: 데이터 모델 자체를 기반으로 함. (예 : 관계 모델에서는 목록(list)을 속성 값으로 허용하지 않음) 2. 스키마 기반 또는 명시적인 제약조건: 모델에서 제공하는 기능을 사용하여 스키마내에 표현됨. (예 : ER 모델의 최대 카디널리티 비율 제약조건) 3. 응용 기반 또는 의미적 제약조건: 이는 모델의 표현력을 넘어서는 응용 프로그램에 의해 지정되고 적용됨

관계 모델의 고유한 무결성 제약조건 제약 조건은 모든 유효한 릴레이션 상태들이 유지해야 하는 제약조건임. 관계 모델로 표현할 수 있는 세 가지 형태의 주요 (명시적 스키마 기반) 제한 조건이 있음: 키 (Key) 제약조건 엔터티 무결성 (Entity integrity) 제약조건 참조 무결성 (Referential integrity) 제약조건 또 다른 스키마-기반 제약조건으로 도메인 제약조건이 있음. 튜플의 모든 값은 해당 애트리뷰트의 도메인에서 가져와야 합니다 (또는 해당 애트리뷰트에 대해 NULL이 허용될 경우, NULL일 수 있음).

키 제약조건 R의 슈퍼키 (Superkey): R의 키 (Key): 유효한 릴레이션 상태 r (R)의 두 튜플은 SK에 대해 동일한 값을 갖지 않습니다 즉, r (R)에서 서로 다른 두 튜플 t1과 t2은 t1[SK]  t2[SK] 임 이 조건은 어떤 유효한 상태 r (R)에서도 유지돼야 함 R의 키 (Key): “최소” 슈퍼키 즉, 키는 수퍼키 K이므로 K에서 어떤 애트리뷰트를 제거하면 슈퍼키가 아닌 애트리뷰트 집합이 됨 (슈퍼키의 고유성 속성이 없어짐) 키는 슈퍼키이지만 그 역은 성립되지 않음

키 제약조건 (continued) 예: CAR 릴레이션 스키마의 경우: 일반적으로: CAR(State, Reg#, SerialNo, Make, Model, Year) CAR는 두 개의 키를 가짐: Key1 = {State, Reg#} Key2 = {SerialNo} 두 개의 키는 모두 CAR의 슈퍼키가 됨 {SerialNo, Make}는 슈퍼키이지만 키는 아님 일반적으로: 키는 슈퍼키임 (그 역음 성립하지 않음) 키를 포함하는 애트리뷰트 집합은 슈퍼키 임 최소 슈퍼키는 키가 됨

키 제약조건 (continued) 릴레이션이 여러 후보키 (candidate keys)를 가지면, 그 중에서 임의의 한 개를 기본키 (primary key)로 선택함 기본 키 애트리뷰트는 밑줄을 쳐서 표시함 예: CAR 릴레이션 스키마의 경우: CAR(State, Reg#, SerialNo, Make, Model, Year) SerialNo를 기본키로 선택함 기본 키 값은 릴레이션에서 각 튜플을 고유하게 식별하는 데 사용됨 튜플 식별(ID)를 제공함 다른 튜플에서 이 튜플을 참조하기 위해서도 사용됨 일반적인 규칙: 최소 크기의 후보 키를 기본 키로 선택함 항상 적용되는 규칙은 아님 – 가끔 주관적으로 선택함

두개의 후보키를 가진 CAR 테이블 – LicenseNumber를 기본키로 선택

관계 데이터베이스 스키마 관계 데이터베이스 스키마: 동일한 데이터베이스에 속하는 관계 스키마 집합 S S는 전체 데이터베이스 스키마의 이름임 S = {R1, R2, ..., Rn} 및 무결성 제약조건 집합 IC R1, R2,…, Rn은 데이터베이스 S 내의 개별 관계 스키마의 이름들임 다음 슬라이드는 6 개의 관계 스키마를 가진 회사 데이터베이스 스키마를 보여줌

COMPANY 데이터베이스 스키마

관계 데이터베이스 상태 S의 관계 데이터베이스 상태 DB는 관계 상태들의 집합 DB = {r1, r2, ..., rm}으로, 각 ri는 Ri의 상태이고 릴레이션 상태 ri는 IC에 지정된 무결성 제약 조건을 만족함 관계 데이터베이스 상태를 관계 데이터베이스 스냅 샷 또는 인스턴스라고도 함 인스턴스라는 용어는 단일 튜플에도 적용되므로 사용하지 않음 제한 조건을 충족하지 않는 데이터베이스 상태는 유효하지 않은 상태임

채워진 데이터베이스 상태 각 릴레이션은 현재 릴레이션 상태에 있는 많은 튜플을 가짐 관계 데이터베이스 상태는 모든 개별 릴레이션 상태를 합친 것임 데이터베이스가 변경 될 때마다 새로운 상태가 발생함 데이터베이스 변경을위한 기본 연산들: 릴레이션내에 새로운 튜플을 삽입 (INSERT) 릴레이션으로부터 기본 튜플을 삭제 (DELETE ) 기존 튜플의 애트리뷰트를 수정 (MODIFY) 다음 슬라이드 (Fig. 4.6)는 그림 4.5에 표시된 COMPANY 데이터베이스 스키마의 상태를 보여줌

COMPANY를 위한 채워진 데이터베이스 상태

엔터티 무결성 제약 엔터티 무결성 제약 (Entity Integrity): S에서 각 관계 스키마 R의 기본 키 속성 PK는 r (R)의 튜플에서 널 값을 가질 수 없습니다. 기본 키 값은 개별 튜플을 식별하는 데 사용되기 때문입니다. r (R)의 임의의 튜플 t에 대해, t[PK]  null 임 PK에 여러 애트리뷰트가 있는 경우, 이들 모든 애트리뷰트에 null이 허용되지 않습니다 참고 : R의 다른 애트리뷰트가 기본 키의 구성원이 아니더라도 널 값을 허용하지 않도록 제한할 수 있습니다 .

참조 무결성 제약 두 릴레이션 간의 제약조건 두 릴레이션에 있는 튜플들간의 관계를 명시하는 데 사용됨: 앞의 제약조건들은 한 릴레이션에 대한 것임. 두 릴레이션에 있는 튜플들간의 관계를 명시하는 데 사용됨: 참조하는 릴레이션과 참조되는 릴레이션

참조 무결성 제약 참조하는 릴레이션 R1내에 있는 튜플들은, 참초되는 릴레이션 R2의 기본키 애트리뷰트 PK를 참조하는, (외래키 라고 부르는 애트리뷰트) 애트리뷰트 FK를 가짐. 만약 t1[FK] = t2[PK]이면, R1에 있는 튜플 t1이 R2에 있는 튜플 t2를 참조한다고 말한다. 참조 무결성 제한 조건은 관계 데이터베이스 스키마내에 R1.FK에서 R2로의 방향성 아크로 표시될 수 있음

참조 무결성 (또는 외래키) 제약조건 제약조건의 선언 Statement of the constraint 참조하는 릴레이션 R1의 외래 키 열 (또는 열들) FK의 값은 다음 중 하나 일 수 있습니다: (1) 참조되는 릴레이션 R2에서 해당 기본 키 PK에 존재하는 기본 키 값, 또는 (2) null 값. (2)의 경우, R1의 FK는 자신의 기본 키의 일부가 아니어야 함

관계 데이베이스 스키마와 제약조건 표시 각 관계 스키마는 애트리뷰트 이름의 행으로 표시 될 수 있음 릴레이션 이름은 애트리뷰트 이름 위쪽에 작성됨 기본 키 애트리뷰트에 밑줄이 표시됨 외래 키 (참조 무결성) 제약 조건은 외래 키 애트리뷰트로에서 참조되는 테이블로 가는 방향성 아크 (화살표)로 표시됨 명확하게 하기 위해, 참조되는 릴레이션의 기본 키를 가리키게 할 수도있다. 다음 슬라이드는 참조 무결성 제약 조건을 가진 COMPANY 관계 스키마 다이어그램을 보여줌

COMPANY 데이터베이스를 위한 참조 무결성 제약조건

제약조건의 다른 종류들 의미적 무결성 제약조건: 응용의 의미를 기반으로 하며, 모델 자체에서는 표현할 수 없음 예: “모든 프로젝트에서 사원들의 최대 근무 시간은 주당 56시간이다” 이를 표현하기 위해, 제약조건 표현 언어가 사용될 수 있음 이들 의미적 제약조건들을 표현하기 위해, SQL-99는 CREATE TRIGGER 및 CREATE ASSERTION을 제공함 키, 널값 허용, 후보 키(SQL 유일성), 외래 키, 참조 무결성 등은 SQL의CREATE TABLE문으로 표시됨

릴레이션에 대한 갱신 연산 튜플을 삽입 (INSERT) 튜플을 삭제 (DELETE) 튜플을 수정 (MODIFY) 갱신 연산으로 무결성 제약 조건을 위반해서는 안됨 여러 갱신 작업들을 함께 그룹화해야 할 수도 있음 한 갱신이 다른 갱신을 자동으로 발생하도록 전파할 수 있음. 무결성 제약 조건을 유지하기 위해 이것이 필요할 수 있음.

릴레이션에 대한 갱신 연산 무결성 제약을 위반하는 경우, 다음의 몇가지 조치를 취할 수 있음: 위반의 원인이 되는 작업 취소 (RESTRICT 또는 REJECT 옵션) 작업을 수행하되 사용자에게 위반 사실을 알림 위반이 수정되도록 추가 업데이트를 트리거함 (CASCADE 옵션, SET NULL 옵션) 사용자 지정 오류 수정 루틴 실행

각 연산에 대한 가능한 위반들 INSERT는 아래 제약조건을 위반할 수 있음: 도메인 제약조건 (Domain constraint): 새 튜플에 제공된 애트리뷰트 값 중 하나가 지정된 애트리뷰트 도메인이 아닌 경우 키 제약조건 (Key constraint): 새 튜플의 키 애트리뷰트 값이 릴레이션의 다른 튜플에 이미 존재하는 경우 참조 무결성 제약 (Referential integrity): 새 튜플의 외래 키 값이 참조되는 릴레이션에 존재하지 않는 기본 키 값을 참조하는 경우 엔터티 무결성 제약 (Entity integrity): 새 튜플의 기본 키 값이 null인 경우

각 연산에 대한 가능한 위반들 DELETE는 참조 무결성 제약만 위반할 수 있음: 삭제중인 튜플의 기본 키 값이 데이터베이스의 다른 튜플에서 참조되는 경우 RESTRICT, CASCADE, SET NULL 등의 여러 동작으로 해결할 있습니다 (자세한 내용은 6 장 참조). RESTRICT 옵션: 삭제를 거부함 CASCADE 옵션: 참조하는 튜플의 외래키 값으로 새로운 기본키 값을 전파함 SET NULL 옵션: 참조하는 튜플의 외래키 값을 NULL로 지정함 각 외래 키 제약 조건에 대해 데이터베이스 설계 중에 위 옵션 중 하나를 지정해야 합니다.

각 연산에 대한 가능한 위반들 UPDATE는 도메인 제약조건 및 수정될 애트리뷰트에 대한 NOT NULL 제약조건을 위반할 수 있음 다른 제약조건들의 위반은 수정될 애트리뷰트에 따라 달라질 수 있음: 기본키 (PK)를 수정: INSERT 후에 DELETE하는 것과 유사함 DELETE와 유사한 옵션을 지정해야 함 외래키 (FK)를 수정: 참조 무결성 제약을 위반할 수 있음 (PK도 FK도 아닌) 보통 애트리뷰트를 수정: 도메인 제약만 위반할 수 있음

요약 Presented Relational Model Concepts Definitions Characteristics of relations Discussed Relational Model Constraints and Relational Database Schemas Domain constraints Key constraints Entity integrity Referential integrity Described the Relational Update Operations and Dealing with Constraint Violations

연습문제 (Taken from Exercise 4.16) Consider the following relations for a database that keeps track of student enrollment in courses and the books adopted for each course: STUDENT(SSN, Name, Major, Bdate) COURSE(Course#, Cname, Dept) ENROLL(SSN, Course#, Quarter, Grade) BOOK_ADOPTION(Course#, Quarter, Book_ISBN) TEXT(Book_ISBN, Book_Title, Publisher, Author) Draw a relational schema diagram specifying the foreign keys for this schema.