[데이터베이스] 2장. 관계 데이터 모델과 제약 조건

 

2장. 관계 데이터 모델과 제약 조건 | Notion

 

 

2.1 관계 데이터 모델의 개념

 

2.2 릴레이션의 특성

 

2.3 릴레이션의 키

릴레이션의 키 : 각 tuple을 고유하게 식별할 수 있는 하나 이상의 attribute들의 모임.

키의 종류 - 수퍼키, 후보키, 기본키, 대체키, 외래키.

• 수퍼 키 (super key) : relation key의 정의와 동일
  • 예) 주민등록번호만으로도 super key지만, 추가적인 attribute들을 더 가지고 있는 것도 super key.
• 후보 키 (candidate key) : 각 투플을 고유하게 식별하는 최소한의 attribute들의 모임.
  • 모든 릴레이션에는 최소한 한 개 이상의 후보 키가 존재함. (릴레이션의 tuple들은 서로 고유하게 구분이 돼야 하는 거니.)
• 기본 키 (primary key) : 릴레이션을 다루는 데 있어서, 투플을 대표할 수 있는 attribute 집합.
  • 후보 키가 2개 이상 있으면, 이 중 하나를 기본키로 선정해서 사용.
    • 자연스러운 걸 기본 키로 설정. (학번 vs email → 학번)
    • 자연스러운게 뭔지 모르겠으면, 임의적으로 key attribute를 추가함. (일련 번호 붙이기)
• 대체 키 (alternate key) : 후보 키 여러 개가 있었을 때, 기본키로 선정되지 않은 나머지 키
• 외래 키 (foreign key) : 어떤 릴레이션의, 기본 키를 참조하는 attribute.
  • 앞에서 정의한 의미(tuple들을 고유하게 식별할 수 있는 것)에서의 “키”는 아님.
  • 릴레이션들 간의 관계를 표현하기 위해서 사용됨.
  • 자신이 속한 릴레이션의 기본 키의 구성요소가 되거나 되지 않을 수 있음.

 

외래 키의 유형

1. 다른 릴레이션의 기본 키를 참조하는 외래 키

2. 자체 릴레이션의 기본 키를 참조하는 외래 키

3. 기본 키의 구성요소가 되는 외래 키

 

2.4 관계 데이터 모델과 제약조건

데이터베이스가 갱신될 때 (데이터베이스에서 데이터가 업데이트 될 때) 데이터 무결성이 깨질 것 같으면, 일종의 에러를 내서 업데이트가 되지 않도록 DBMS가 막아줌.

제약 조건 4가지가 있음.

• 도메인 제약조건 (domain constraint)
• 키 제약조건 (key constraint)
• 엔티티 무결성 제약조건 (entity integrity constraint)
• 참조 무결성 제약조건 (referential integrity constraint)

2.4.1 도메인 제약조건 (domain constraint)

• attribute의 값이 원자값이어야 하니, 도메인도 원자값이어야 함.
• attribute 값의 default 값이나, 가능한 값의 범위 등을 지정할 수 있음.
• 데이터 형식 (데이터 타입, int 같은..)을 통해 우리가 어떤 값들을 가질 수 있는지 그 유형을 제한하고, CHECK라는 구문을 통해 좀 더 강력하게 제약 조건을 걸 수도 있음.

 

2.4.2 키 제약조건 (key constraint) 

: key attribute에 중복된 값이 존재해서는 안 됨.

• key는, PRIMARY KEY 라는 키워드를 가지고 나타낼 수 있음.
• UNIQUE라고 하는 키워드도, PRIMARY KEY와 유사.

 

2.4.3 엔티티 무결성 제약조건 (entity integrity constraint) 

: 기본 키를 구성하는 어떠한 attribute도 null 값을 가질 수 없다.

→ 기본 키에 해당되고, 대체 키는 적용되지 않음. 그건 null 가능.

 

2.4.4 참조 무결성 제약조건 (referential integrity constraint) 

: 외래 키 값은 자기가 참조되는 쪽에 있는 기본 키 값 중 하나를 가져야 함.

→ 사원이 부서 번호를 가지고 있던 예제에서, 회사에 없는 부서 번호를 가지고 있으면 안된다라는 것. (이미 부서 테이블에 있는 부서 중에 하나의 부서에 속해야 하는거지, 회사에 없는 부서에 속하면 안된다는 것.)

→ 하지만 NULL 값을 가지는 건 가능.(아직 부서 배정이 안됐거나, 부서가 어떤 건지 아직 알려지지 않았을 때. 등)

기존의 투플의 삭제시, 참조 무결성 제약 조건이 위배될 가능성이 존재.

• 참조하는 쪽에서의 삭제 → 아무 문제 없음.
• 참조되는 쪽에서의 삭제 : 3번 부서가 삭제되면, EMPLOYEE relation에서 부서 relation에 없는 3번이 남아있게 됨. 이런 경우 위배.

 

→ 이때 참조 무결성 제약 조건이 위배되지 않도록 해주는 법.

• 제한(restricted) - 연산을 거절함.
• 연쇄(cascade) - 연쇄적으로 삭제하는 것.
  • 3번 부서를 삭제했다고 하면, 3번 부서를 참조하고 있는 tuple들도 다 함께 삭제하는 것.
• 널 값(nullify)
  • 3번 부서가 삭제되었다고 하면, 3 → null 값으로 바꾸는 것.
• 디폴트 값 - NULL 값을 지정하는 대신, default값으로 채워 넣는 것.

ON DELETE 구문으로. 이 4가지 중에 하나 주면 됨.