Integrity Constraints: 두 판 사이의 차이

youngwiki
편집 요약 없음
34번째 줄: 34번째 줄:
unique (Aj1, Aj2, ..., Ajm)
unique (Aj1, Aj2, ..., Ajm)
</syntaxhighlight>
</syntaxhighlight>
'''unique 제약'''은 '''나열된 속성들이 [[Relational Model#Keys|superkey]]를 이룬다는 것을 의미'''한다. 즉, 이 속성들의 값이 모두 같은 두 튜플은 존재할 수 없다.  
'''unique 제약'''은 '''나열된 속성들이 [[Relational Model#Keys|superkey]]를 이룬다는 것을 의미'''한다. 즉, 이 속성들의 값이 모두 같은 두 튜플은 존재할 수 없다. 이때 <code>not null</code>로 명시하지 않는 이상, null 값이 허용되기 때문에, null 값이 사용된 중복된 두 튜플은 중복 가능하다.  


==The check cluase==
릴레이션 선언에 '''<code>check(P)</code> 절을 적용하면, ''모든 튜플이 조건 P를 만족'''해야 한다는 뜻이 된다. check 저른 속성 값이 특정 조건을 만족하는지 보장하는데 자주 사용된다. 예를 들어
<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
 
check (budget > 0)
</syntaxhighlight>
</syntaxhighlight>
 
위와 같은 코드가 <code>create table</code> 명령어에 포함되면, budget 값이 0보다 커야함을 나타낸다. 또한 아래와 같이 사용될 수도 있다:
<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
 
create table section (
  course_id varchar(8),
  sec_id varchar(8),
  semester varchar(6),
  year varchar(4,0),
  building varchar(15),
  room_number varchar(7),
  time_slot_id varchar(4),
  primary key (course_id, sec_id, semester, year),
  check (semester in ('Fall', 'Winter', 'Spring', 'Summer'))
);
</syntaxhighlight>
</syntaxhighlight>
위 코드에서는 check 절을 이용해 semester 속성의 값을 'Fall', 'Winter', 'Spring', 'Summer' 중 하나로 열거형(enum)처럼 제한하고 있다.


==각주==
==각주==
[[분류:데이터베이스 시스템]]
[[분류:데이터베이스 시스템]]

2025년 4월 9일 (수) 14:54 판

상위 문서: SQL

개요

Integrity constraint는 승인된 사용자에 의해 데이터베이스에 적용된 갱신(update)에 의한 변경 데이터의 일관성(consistency)를 잃지 않도록 보장해준다. 즉, integrity constraint는 데이터베이스를 우발적인 손상으로부터 보호하는 역할을 한다.[1] Integrity constraint의 예는 다음과 같다:

  • 강사(instructor)의 이름은 null일 수 없다.
  • 두 명의 강사가 동일한 ID를 가질 수 없다.
  • course 릴레이션의 모든 학과(department) 이름은 department 릴레이션에 존재해야 한다.
  • 학과의 예산은 반드시 $0.00보다 커야 한다.

일반적으로 데이터베이스에 관련된 임의의 논리 조건(predicate)은 integrity constraint가 될 수 있다. 하지만 어떤 조건은 검사 비용이 높을 수 있기 때문에 대부분의 DBMS는 비용이 적게 드는(minimal overhead) 제약 조건(constraint) 만을 명시하도록 한다.
Integrity constraint는 보통 데이터베이스 스키마(schema) 설계 과정의 일부로 인식되며, create table 명령의 일부로 릴레이션을 생성할 때 선언된다. 또한 아래와 같이 기존 릴레이션에 integrity constraint를 추가할 수 있다.

alter table <table name> add <constraint> ...

Integrity constraint에는 primary key constraintforeign key constraint도 존재하지만 해당 문서에는 다른 종류의 제약 조건 대해 알아본다.

Constraints on a Single Relation

create table 명령은 테이블을 정의하는 것 외에도 integrity constraint를 포함할 수 있다. 이때 primary key 외에도 다음과 같은 integrity constraint가 포함될 수 있다:

  • not null
  • unique
  • check(<조건>)

해당 문서에서는 위 constraint에 대해 설명한다.

Not null constraint

null 값은 모든 속성(atrribute)의 도메인에 포함되기 때문에 기본적으로 모든 속성에서 허용되지만 특정 속성에서는 null 값의 사용이 부적절하다. 에를 들어 student 릴레이션에서 name이 null인 튜플은 누군지 모르는 학생에 대한 정보를 담게 되므로 부적절하다다. 마찬가지로 학과의 예산(budget)이 null인 것도 바람직하지 않다. 이런 경우, 해당 속성에 null 값이 사용되는 것을 막기 위해 다음과 같이 create table 명령어를 작성할 수 있다.

name varchar(20) not null
budget numeric(12,2) not null

not null 제약 조건은 해당 속성에 null 값의 삽입을 금지하며, 이는 도메인 제약(domain constraint)의 한 예이다. 만약 not null로 선언된 속성에 null을 삽입하려는 데이터베이스 수정이 시도되면, 오류 메시지가 발생한다. 이처럼 null을 피하고 싶은 상황은 많다. 특히, SQL은 primary key에 null 값 사용을 허용하지 않는다. 예를 들어, department 릴레이션에서 dept_name이 기본 키로 선언되어 있다면, 별도로 not null을 선언하지 않아도 null은 자동으로 금지된다.

Unique Constraints

SQL은 다음과 같은 integrity constraint도 지원한다:

unique (Aj1, Aj2, ..., Ajm)

unique 제약나열된 속성들이 superkey를 이룬다는 것을 의미한다. 즉, 이 속성들의 값이 모두 같은 두 튜플은 존재할 수 없다. 이때 not null로 명시하지 않는 이상, null 값이 허용되기 때문에, null 값이 사용된 중복된 두 튜플은 중복 가능하다.

The check cluase

릴레이션 선언에 check(P) 절을 적용하면, 모든 튜플이 조건 P를 만족해야 한다는 뜻이 된다. check 저른 속성 값이 특정 조건을 만족하는지 보장하는데 자주 사용된다. 예를 들어

check (budget > 0)

위와 같은 코드가 create table 명령어에 포함되면, budget 값이 0보다 커야함을 나타낸다. 또한 아래와 같이 사용될 수도 있다:

create table section (
  course_id varchar(8),
  sec_id varchar(8),
  semester varchar(6),
  year varchar(4,0),
  building varchar(15),
  room_number varchar(7),
  time_slot_id varchar(4),
  primary key (course_id, sec_id, semester, year),
  check (semester in ('Fall', 'Winter', 'Spring', 'Summer'))
);

위 코드에서는 check 절을 이용해 semester 속성의 값을 'Fall', 'Winter', 'Spring', 'Summer' 중 하나로 열거형(enum)처럼 제한하고 있다.

각주

  1. 이는 무단 사용자의 접근을 막는 security constraint와는 대조적이다.