앞의 강좌의 마직막 부분의 퀴즈의 정답은 Tempdb 입니다. 임시테이블은 Tempdb에 만들어졌다가 사라지게 됩니다. 만일 실제 테이블을 Tempdb에 만들어 놓게 되면 일반 테이블과 다를 바가 없지만 SQL Server가 Restart 되면 이 테이블들은 사라지게 됩니다.
테이블에 저장되는 데이터의 무결성을 위해서 몇가지 제약(constraints)를 걸 수 있습니다. 예를 들면 전화번호 컬럼에는 숫자만 허용한다든지, 주민번호 컬럼에는 주민번호가 유일해야 한다든지 등입니다. 이러한 제약을 통해서 잘못된 데이터가 테이블에 들어오게 되는 것을 미리 방지할 수 있게 됩니다. 이러한 제약(constraints)에 대하여 살펴보도록 하겠습니다.
1. DEFAULT
INSERT 시에 별도의 값이 지정되지 않으면 특정 값이 기본값으로 해당 컬럼에 채워지게 하는 것입니다. 당연히 하나의 컬럼에는 오직 하나만의 DEFAULT 제약이 가능합니다.
예를 들어 Friend 테이블의 Address 컬럼에 별도의 값이 지정되지 않으면 '알수없음' 이라는 문자열로 대신 채우고 싶으면 다음과 같이 DEFAULT 제약을 주면 됩니다.
CREATE TABLE Friend ( |
위 예에서 처음의 INSERT문에서는 주소가 지정되었지만 두번째 INSERT문에는 주소가 생략되었습니다. 이 경우 Address 컬럼에는 '알수없음' 이라는 문자열이 주소를 대신하게 됩니다.
2. CHECK
특정 컬럼에 값이 입력될 때 특정 조건을 만족하는 경우만 받아 들이게 할 경우 사용합니다. 예를 들어 Member 테이블의 Age 컬럼에는 20 에서30 까지의 수만 입력이 되게 하고싶다면 다음과 같이 CHECK 제약을 주면 됩니다.
CREATE TABLE Member ( |
마지막 INSERT문에서는 다음과 같은 오류가 발생합니다.
서버: 메시지 547, 수준 16, 상태 1, 줄 1 |
3. PRIMARY KEY
너무나 중요하죠?
테이블에 Primary Key를 선언해서 중복되는 row 가 없도록 하는 것입니다. PRIMARY KEY 제약은 다음의 특징이 있습니다.
o 유일한 값이 들어와야 합니다.
o null값이 들어올 수 없습니다.
o 한 테이블에 오직 한개의 PRIMARY KEY 제약을 걸 수 있습니다.
o 자동으로 UNIQUE 인덱스가 만들어집니다. CLUSTERED 또는 NONCLUSTERED 인덱스중 한가지를 선택 할 수 있습니다. 별도로 지정하지 않으면 CLUSTERED 인덱스가 됩니다.
CREATE TABLE Member2 ( |
Member_ID 컬럼 선언시 NOT NULL로 지정한 것이 보입니다. 만일 NOT NULL 이 지정되지 않으면 Member_ID에 대하여 PRIMARY KEY 제약을 걸 수 없습니다.
위의 두 INSERT문에서 마지막 INSERT문은 다음과 같은 오류를 발생시킵니다.
서버: 메시지 2627, 수준 14, 상태 1, 줄 1 |
데이터 무결성 차원에서 PRIMARY KEY 제약은 그 어떤 제약보다 중요하다고 생각합니다. 테이블을 디자인 할 때 Primary Key가 없으면 무언가 잘못되었다고 생각 할 수 있습니다. 예전에 실무에서 사원 테이블에 Primary Key가 선언되어 있지 않아 동일한 사번이 두개 있어 문제가 발생한 적이 있습니다.
만일 Application을 개발한다면 테이블에 여러가지 제약을 주는 것도 중요하지만 위와 같은 오류가 발생 했을 때 Application 사용자에게 메세지를 정확하게 출력해 주는 부분을 개발해야 합니다. 그렇지 않으면 Runtime 오류가 발생해서 Application 사용자를 짜증나게 합니다.
4. UNIQUE
컬럼의 값이 중복되지 않게 합니다. 같은 주민등록 번호가 들어오지 못하게 한다거나, 사원번호가 중복되어 들어오지 못하게 한다거나 할 때 사용합니다. 얼핏 보면 PRIMARY KEY 제약과 같아 보이나 null 도 하나의 값으로 인식된다는 것과 한 테이블에 여러개(즉 주민번호도 중복되지 않으면서 사원번호도 중복되지 않게) 사용할 수 있다는 점에서 다릅니다.
CREATE TABLE Member3 ( |
마지막 INSERT문에서는 다음과 같은 오류가 발생합니다.
서버: 메시지 2627, 수준 14, 상태 2, 줄 1 |
5. FOREIGN KEY
만일 부서 테이블이 있고 사원 테이블이 있다고 가정을 하겠습니다. 부서 테이블에는 부서 코드와 그 부서에 대한 몇가지 정보가 있을 것입니다. 그리고 사원 테이블에는 사원번호와 사원에 대한 몇가지 정보가 있을 터인데 그중에 어느 부서에 근무하는지 표시하기 위해 부서 코드가 존재할 것입니다. 이때 우리는 사원 테이블에 기록되는 부서 코드는 분명히 부서 테이블에 등록된 부서 코드일거라 확신을 하게 됩니다. 이러한 확신을 도와주기 위해서 FOREIGN KEY 제약을 겁니다. 즉, 사원테이블의 부서코드는 부서 테이블의 부서코드를 참조(Reference)하는 Foreign Key라고 선언하는 것입니다.
다음의 예를 보면서 그 기능을 확인해 보도록 하겠습니다.
CREATE TABLE Department ( |
o 1) 에 의해서 Department 테이블에서 Dept_Code는 Primary Key입니다.
o 2) 에 의해서 Employee 테이블에서 Dept_Code는 Department 테이블의 Dept_Code를 참조하는 Foreign Key 입니다.
o 마지막 INSERT문 3) 에서는 다음과 같은 오류가 발생합니다. 왜냐하면 INSERT되는 '30000' 값은 Department 테이블에 존재하지 않기때문입니다.
서버: 메시지 547, 수준 16, 상태 1, 줄 1 |
만일 이 상태에서 다음의 쿼리문을 수행하면 어떻게 될까요?
DELETE FROM Department WHERE Dept_Code = '10000' |
위 DELETE문은 수행되지 않고 오류가 발생합니다. 그 이유는 Dept_Code '10000'은 Employee 테이블에 처음 INSERT 된 '이장래' 가 참조하고 있는 값이기 때문입니다. 그래서 다음과 같은 오류가 발생합니다.
서버: 메시지 547, 수준 16, 상태 1, 줄 1 |
위 DELETE문이 수행되기 위해서는 우선 Dept_Code 가 '10000'인 레코드를 Employee 테이블에서 DELETE해야 합니다.
위와 같이 FOREIGN KEY 제약은 데이터의 무결성을 유지시켜줍니다.
다음 퀴리문은 어떠한 의미를 가지고 있는지 분석해 보시기 바랍니다.
CREATE TABLE Employee2 (
|
출처 : http://www.sqlworld.pe.kr
"쇼핑몰·홈페이지·오픈마켓
블로그·페이스북·이메일 등의 각종 마케팅 글쓰기, 각종 광고, 영업, 판매, 제안서, 전단지 반응율 3배×10배 이상 높이는 마법의 8단계 공식" |
☞자세히보기 |
|
|