Chap2. 관계 데이터 모델과 제약 조건
관계 데이터 모델 제안 목적
1. 데이터베이스 관리의 논리적인 면과 물리적인 면을 명확하게 구분하여 데이터 독립성 향상
2. 기존 데이터베이스 모델보다 단순한 구조
3. 한꺼번에 다수의 레코드들의 집합을 조작할 수 있는 기능을 제공
-> 프로그래머가 데이터베이스를 레코드 단위로 처리하지않음
4. 데이터베이스 관리 분야에서 튼튼한 이론적 근거를 제공
관계 데이터 모델의 역사
관계 데이터베이스의 성공 요인
- 바탕이 되는 데이터 구조로서 간단한 테이블(릴레이션: 관계형 데이터베이스에서 정보를 구분하여 저장하는 기본 단위(하나의 집합))을 사용
- 관계 데이터베이스 설계와 효율적인 질의 처리 면에서 뛰어난 장점을 가짐
2.1 관계 데이터 모델의 개념
관계 데이터 모델 => 높은 데이터 독립성 제공
릴레이션 스키마(relation schema)
- 릴레이션을 위한 틀(framework)
릴레이션이름(애트리뷰트1, 애트리뷰트2, ... 애트리뷰트N)
관계 데이터 베이스 스키마
관계 데이터 베이스 인스턴스
2.2 릴레이션의 특성
2.3 릴레이션의 키
릴레이션의 키 : 각 투플을 고유하게 식별할 수 있는 하나 이상의 애트리뷰트들의 모임
종류 : 수퍼 키(superkey), 후보 키(candidate key), 기본 키(primary key), 대체 키(alternate key), 외래 키(foreign key)
수퍼 키
: 한 릴레이션 내의 특정 투플을 고유하게 식별하는 하나의 애트리뷰트 또는 애트리뷰트들의 집합
- 투플들을 고유하게 식별하는데 꼭 필요하지 않은 애트리뷰트들을 포함할 수 있음
후보 키
: 각 투플을 고유하게 식별하는 최소한의 애트리뷰트들의 모임
- 모든 릴레이션에는 최소한 한 개 이상의 후보 키가 있음
문제) 이름이 후보키가 될수있나? 이메일이 후보키가 될수있나?
답) 학생의 이름은 일반적으로 고유하지않으므로 후보키가 될 수 없음, 인터넷 상에서 모든 이메일 주소는 고유하므로 후보키가 될 수 있음
기본 키(PK, Primary key)
: 한 릴레이션에 후보 키가 두 개 이상 있으면 설계자 또는 데이터베이스 관리자가 이들 중에서 하나를 기본 키로 선정함
EX) 신용카드 회사의 고객 릴레이션에서 신용카드번호와 주민등록번호가 후보 키가 될 수 있음. 이 중에서 신용카드 번호를 기본 키로 선정
=> 자연스러운 기본 키를 찾을 수 없는 경우에는 레코드 번호와 같이 종종 인위적인 키 애트리뷰트를 릴레이션에 추가할 수 있음
대체 키(AK, Alternate Key)
: 기본 키가 아닌 후보키
EX) 위 신용카드 회사 사례에서는 주민등록번호가 대체키가 됨
외래 키(FK, Foreign Key)
: 어떤 릴레이션의 기본 키를 참조하는 애트리뷰트
- 관계 데이터베이스에서 릴레이션들 간의 관계를 나타내기 위해서 사용됨
- 외래 키 애트리뷰트는 참조되는 릴레이션의 기본 키와 동일한 도메인을 가져야 함
- 자신이 속한 릴레이션의 기본 키의 구성요소가 되거나 되지 않을 수 있음
외래 키의 유형
- 다른 릴레이션의 기본 키를 참조하는 외래 키
- 자체 릴레이션의 기본 키를 참조하는 외래 키
2.4 무결성 제약조건(Integrity Constraint)
무결성 제약 조건 : 데이터의 정확성 또는 유효성, 일관된 데이터베이스 상태를 정의하는 규칙들을 묵시적으로 또는 명시적으로 정의함
- 데이터베이스가 갱신될 때 DBMS가 자동적으로 일관성 조건을 검사하므로 응용 프로그램들은 일관성 조건을 검사할 필요가 없음
무결성 제약 조건의 특징
- 스키마의 한 부분
- 데이터베이스의 상태(또는 상태들의 순서)에 대한 제한
- DBMS가 시행
- 릴레이션 내의 무결성 제약 조건 : 오직 한 릴레이션만 포함
=> 릴레이션 스키마의 한 부분
- 릴레이션 사이의 무결성 제약 조건 : 여러 릴레이션을 포함
=> 릴레이션 스키마 또는 데이터베이스 스키마의 한 부분
무결성 제약조건 예시
무결성 제약조건의 종류
- 도메인 제약조건(domain constraint)
- 키 제약조건(key constraint)
- 기본 키와 엔티티 무결성 제약조건(entity integrity constraint)
- 외래 키와 참조 무결성 제약조건(referential integrity constraint)
도메인 제약조건(domain constraint)
- 각 애트리뷰트 값이 반드시 원자값이어야 함
- 애트리뷰트 값의 디폴트 값, 가능한 값들의 범위 등을 지정할 수 있음
- 데이터 형식을 통해 값들의 유형을 제한하고, CHECK 제약 조건을 통해 값들의 범위를 제한할 수 있음
- SQL2는 도메인을 명시적으로 정의하는 것을 허용하지만, 오라클은 지원하지 않음
키 제약조건(key constraint)
- 키 애트리뷰트에 중복된 값이 존재해서는 안됨
기본 키와 엔티티 무결성 제약조건(entity integrity constraint)
- 릴레이션의 기본 키를 구성하는 어떤 애트리뷰트도 널값을 가질 수 없음
- 대체 키에는 적용되지 않음(PK(기본키)에만 적용된다)
- 사용자는 릴레이션을 생성하는 데이터 정의문에서 어떤 애트리뷰트가 릴레이션의 기본 키의 구성요소인가를 DBMS에게 알려줌
외래 키와 참조 무결성 제약조건(referential integrity constraint)
- 참조 무결성 제약조건은 두 릴레이션의 연관된 투플들 사이의 일관성을 유지하는데 사용됨
- 관계 데이터베이스가 릴레이션들로만 이루어지고, 릴레이션 사이의 관계들이 다른 릴레이션의 기본 키를 참조하는 것을 기반으로 하여 묵시적으로 표현되기 때문에 외래 키의 개념이 중요
- 릴레이션 R2의 외래 키가 릴레이션 R1의 기본 키를 참조할 때 참조 무결성 제약조건은 아래의 두 조건 중 하나가 성립되면 만족됨
=> 외래 키의 값은 R1의 어떤 투플의 기본 키 값과 같다
=> 외래 키가 자신을 포함하고 있는 릴레이션의 기본 키를 구성하고 있지 않으면 널값을 가질 수 있음
1. 삽입
- 참조되는 릴레이션( DEPARTMENT )에 새로운 투플이 삽입되면 참조 무결성 제약조건은 위배되지 않음
- DEPARTMENT에 새로 삽입되는 투플의 기본 키 애트리뷰트의 값에 따라서는 도메인 제약조건, 키 제약조건, 엔티티 무결성 제약조건 등을 위배할 수 있음
- 참조하는 릴레이션(EMPLOYEE)에 새로운 투플을 삽입할 때는 도메인 제약조건, 키 제약조건, 엔티티 무결성 제약조건 외에 참조 무결성 제약조건도 위배할 수 있음
2. 삭제
- 참조하는 릴레이션에서 투플이 삭제되면 도메인 제약조건, 키 제약조건, 엔티티 무결성 제약조건, 참조 무결성 제약조건 등 모든 제약조건을 위배하지 않음
- 참조되는 릴레이션에서 투플이 삭제되면 참조 무결성 제약조건을 위배하는 경우가 생기거나 생기지 않을 수 있음
EX) DEPARTMENT 릴레이션에서 네 번째 투플인 (4, 홍보, 8)을 삭제 => 위배X, DEPARTMENT 릴레이션에서 세 번째 투플인 (3, 개발, 9)를 삭제 => 위배O
참조 무결성 제약조건을 만족시키기 위해서 DBMS가 제공하는 옵션
제한(restricted)
- 위배를 야기한 연산을 단순히 거절
EX) DEPARTMENT 릴레이션에서 (3, 개발, 9)를 삭제하면 참조 무결성 제약조건을 위배하게 되므로 삭제 연산을 거절
연쇄(cascade)
- 참조되는 릴레이션에서 투플을 삭제하고, 참조하는 릴레이션에서 이 투플을 참조하는 투플들도 함께 삭제
EX) DEPARTMENT 릴레이션에서 (3, 개발, 9)를 삭제하면 EMPLOYEE 릴레이션에서 부서번호 3을 참조하는 두 번째 투플과 다섯 번째 투플도 함께 삭제
3. 수정
- DBMS는 수정하는 애트리뷰트가 기본 키인지 외래 키인지 검사함
- 수정하려는 애트리뷰트가 기본 키도 아니고 외래 키도 아니면 수정 연산이 참조 무결성 제약조건을 위배하지 않음
- 기본 키나 외래 키를 수정하는 것은 하나의 투플을 삭제하고 새로운 투플을 그 자리에 삽입하는 것과 유사하므로, 삽입 및 삭제에서 설명한 제한, 연쇄, 널값, 디폴트값 규칙이 수정 연산에도 적용됨