외래키

Foreign key

외래 키는 다른 테이블의 기본 키를 가리키는 표의 속성 집합이다. 외국 열쇠는 이 두 테이블을 연결한다. 다른 말로 하자면: 관계형 데이터베이스의 맥락에서, 외부 키는 특정 종류의 포함 종속성 제약조건에 따르는 속성 집합이며, 특히 한 관계에서 외래 키 속성으로 구성된 튜플이 반드시 다른 (불확실할 필요는 없는) 관계, S, 그리고 더 나아가 그러한 속성으로도 존재해야 하는 제약조건이다.s는 또한 S에서 후보 키여야 한다.[1][2][3] 간단히 말해서, 외래 키는 후보 키를 참조하는 속성 집합이다. 예를 들어 TEAM이라는 테이블에는 Person 테이블에 후보 키인 Person_NAME을 참조하는 외래 키인 MEMPER_NAME 속성이 있을 수 있다. MEMENT_NAME은 외래 키이기 때문에, TEAM의 멤버 이름으로 존재하는 모든 가치는 Person 테이블에 개인 이름으로 존재해야 한다. 즉, TEAM의 모든 멤버도 Person이다.

요약

외래 키가 들어 있는 표를 차일드 테이블이라고 하고, 후보 키가 들어 있는 테이블을 참조 테이블 또는 상위 테이블이라고 한다.[4] 데이터베이스 관계 모델링 및 구현에서 후보 키는 0개 이상의 속성 집합이며, 그 값은 관계에서 각 튜플(행)에 대해 고유하게 보장된다. 튜플에 대한 후보 키 속성 값 또는 값의 조합은 해당 관련 다른 튜플에 중복될 수 없다.

외래 키의 목적은 참조된 테이블의 특정 행을 식별하는 것이므로, 일반적으로 외래 키는 기본 테이블의 일부 행에 있는 후보 키와 동일하거나, 그렇지 않으면 값이 없는(NULL 값)[2]이 필요하다. 이 규칙을 두 표 사이의 참조 무결성 제약이라고 한다.[5] 이러한 제약조건의 위반은 많은 데이터베이스 문제의 원인이 될 수 있기 때문에, 대부분의 데이터베이스 관리 시스템은 모든 Null이 아닌 외부 키가 참조된 표의 행에 부합하도록 보장하는 메커니즘을 제공한다.[6][7][8]

예를 들어, 모든 고객 데이터를 포함하는 Customer 테이블과 모든 고객 주문을 포함하는 ORDER 테이블의 두 테이블이 있는 데이터베이스를 고려해 보십시오. 각 주문이 단일 고객을 참조해야 한다고 가정해 보십시오. 이를 데이터베이스에 반영하기 위해 ORDER 테이블(예: CUSTERID)에 외부 키 열이 추가되어 CUSTER의 기본 키(예: ID)를 참조한다. 표의 기본 키는 고유해야 하며, CUSTERID는 해당 기본 키 필드의 값만 포함하므로, 값이 있을 때 CUSTERID가 주문을 한 특정 고객을 식별한다고 가정할 수 있다. 단, 고객 테이블의 행이 삭제되거나 ID 열이 변경되어 이러한 테이블과 함께 작업하기가 더 어려워질 수 있는 경우 주문 테이블을 최신 상태로 유지하지 않으면 더 이상 가정할 수 없다. 많은 실제 데이터베이스는 마스터 테이블 외부 키를 물리적으로 삭제하는 대신 '비활성화'하거나 변경이 필요할 때 외부 키에 대한 모든 참조를 수정하는 복잡한 업데이트 프로그램에 의해 이 문제를 해결한다.

외래 키는 데이터베이스 설계에서 필수적인 역할을 한다. 데이터베이스 설계의 한 가지 중요한 부분은 표에서 표로 참조하기 위해 외래 키를 사용하여 실제 실체 간의 관계를 데이터베이스에 반영하도록 하는 것이다.[9] 데이터베이스 설계의 또 다른 중요한 부분은 테이블이 분리되고 외부 키가 테이블의 재구성을 가능하게 하는 데이터베이스 표준화다.[10]

참조(또는 하위) 테이블의 여러 행은 참조(또는 상위) 테이블의 동일한 행을 가리킬 수 있다. 이 경우 두 표의 관계를 참조표와 참조표 사이의 일대다관계라고 한다.

또한, 아동과 부모 테이블은 사실상 동일한 테이블일 수 있다. 즉, 외래 키가 동일한 테이블을 다시 가리킨다. 이러한 외부 키는 SQL:2003에서 자체 참조 또는 재귀적 외부 키로 알려져 있다. 데이터베이스 관리 시스템에서 이것은 종종 첫 번째와 두 번째 참조를 동일한 표에 연결함으로써 이루어진다.

테이블에는 여러 개의 외래 키가 있을 수 있으며, 각 외래 키는 다른 상위 테이블을 가질 수 있다. 각 외부 키는 데이터베이스 시스템에 의해 독립적으로 시행된다. 따라서 외래 키를 사용하여 테이블 간의 계단식 관계를 설정할 수 있다.

외부 키는 다른 관계에서 기본 키와 일치하는 값을 가진 관계에서 속성 또는 속성 집합으로 정의된다. 이러한 제약조건을 기존 테이블에 추가하기 위한 구문은 아래와 같이 SQL:2003에 정의되어 있다. 에서 열 목록 생략 REFERENCES 절은 외부 키가 참조된 표의 기본 키를 참조해야 함을 의미한다. 마찬가지로 외부 키도 의 일부로 정의할 수 있다. CREATE TABLE SQL 문. 

만들다 테이블 child_table (   col1 정수 1차 키,   col2 캐릭터 변화무쌍한(20),   col3 정수,   col4 정수,   외국 키(col3, col4) 참고 자료 parent_table(col1, col2) 켜기 삭제 캐스케이드 )

외부 키가 단일 열인 경우 다음 구문을 사용하여 열로 표시할 수 있다. 

만들다 테이블 child_table (   col1 정수 1차 키,   col2 캐릭터 변화무쌍한(20),   col3 정수,   col4 정수 참고 자료 parent_table(col1) 켜기 삭제 캐스케이드 )

외래 키는 저장 프로시저 문으로 정의할 수 있다. 

sp_외국어키 child_table, parent_table, col3, col4
  • child_table: 정의할 외래 키를 포함하는 테이블 또는 뷰의 이름.
  • parent_table: 외부 키가 적용되는 기본 키가 있는 테이블 또는 뷰의 이름. 기본 키는 이미 정의되어 있어야 한다.
  • col3 및 col4: 외부 키를 구성하는 열의 이름. 외부 키에는 적어도 하나의 열과 최대 8개의 열이 있어야 한다.

참조 동작

주요 기사: 전파 제약 조건

데이터베이스 관리 시스템은 참조 제약 조건을 적용하기 때문에 참조된 테이블의 행을 삭제(또는 업데이트)하려면 데이터 무결성을 보장해야 한다. 참조 테이블의 종속 행이 여전히 존재하는 경우, 그러한 참조를 고려해야 한다. SQL:2003은 다음과 같은 경우에 수행되어야 하는 5가지 다른 참조 작업을 지정한다.

캐스케이드

상위(참조) 테이블의 행이 삭제(또는 업데이트)될 때마다 일치하는 외부 키 열이 있는 하위(참조) 테이블의 각 행도 삭제(또는 업데이트)된다. 이것을 계단식 삭제(또는 업데이트)라고 한다.

제한

참조 테이블의 값을 참조하는 참조 테이블 또는 하위 테이블에 행이 있는 경우 값을 업데이트하거나 삭제할 수 없다.

마찬가지로 참조 또는 하위 테이블에서 행에 대한 참조가 있는 한 행을 삭제할 수 없다.

RESTRICT (및 CASCADE)를 더 잘 이해하려면, 즉시 명확하지 않을 수 있는 다음과 같은 차이를 알아채는 것이 도움이 될 수 있다. 참조 작용 CASCADE는 CASCADE라는 단어가 사용되는 (어린이) 테이블 자체의 "행동"을 수정한다. 예를 들어, ON DELETE CASDAED는 "참조된 행이 다른 테이블(마스터 테이블)에서 삭제된 경우, 그 다음 나에게도 삭제"라고 효과적으로 말한다. 그러나 참조 액션 RESTRICT는 RESTITY라는 단어가 마스터 테이블이 아니라 하위 테이블의 "행동"을 수정한다. 단, RESTITY라는 단어는 마스터 테이블이 아니라 하위 테이블의 "행동"을 수정한다! 따라서 ON DELETE LESTRICTED는 효과적으로 다음과 같이 말하고 있다: "다른 테이블(마스터 테이블)에서 행을 삭제하려고 할 때, 다른 테이블에서 삭제하는 것을 방지하십시오(물론, 나도 삭제하지 마십시오, 하지만 여기서 중요한 것은 아니다)."

RESTRICT는 Microsoft SQL 2012 및 이전 버전에서 지원되지 않는다.

조치 없음

어떤 행동과 제한은 매우 비슷하다. NO ACTION과 RESTRICTED의 주요 차이점은 NO ACTION을 사용할 경우 표 변경을 시도한 후 참조 무결성 검사가 수행된다는 것이다. RESTRICT는 UPDATE 또는 DELETE 문을 실행하기 전에 점검한다. 두 참조 작업은 참조 무결성 검사가 실패할 경우 동일하게 작용한다. UPDATE 또는 DELETE 문에서 오류가 발생한다.

즉, 참조 조치 NO ACTION을 사용하여 참조 테이블에서 UPDATE 또는 DELETE 문이 실행될 때, DBMS는 문 실행의 끝에서 참조 관계가 하나도 위반되지 않았음을 확인한다. 이는 초기에 작업이 제약조건을 위반한다고 가정하는 LESTRICT와는 다르다. NO 조치(NO Action)를 사용하면, 문장의 트리거나 의미론 자체가 제약조건을 최종 점검할 때까지 어떠한 외국의 키 관계도 위반되지 않는 최종 상태를 산출하여, 문장이 성공적으로 완료되도록 할 수 있다.

SET NULL, SET DEFAULT

일반적으로 SET NULL 또는 SET DEFAULT에 대해 DBMS가 수행한 작업은 ON DELETE 또는 ON UPDATE에 대해 모두 동일하며, 영향을 받는 참조 속성의 값은 SET NULL에 대해 NULL로, SET DEFAULT에 대해 지정된 기본값으로 변경된다.

트리거스

참조 작용은 일반적으로 암시적 트리거(즉, 종종 숨겨지는 시스템 생성 이름의 트리거)로 구현된다. 이와 같이, 사용자 정의 트리거와 동일한 제한사항을 적용하며, 다른 트리거에 대한 실행 순서를 고려할 필요가 있을 수 있다. 적절한 실행 순서를 보장하기 위해 참조 작업을 동등한 사용자 정의 트리거로 대체하거나 돌연변이 테이블 제한에 대한 작업이 필요할 수 있다.s

트랜잭션 격리와 함께 또 다른 중요한 제한사항이 나타난다. 행은 트랜잭션에서 "보이지" 못하는 데이터에 의해 참조되므로 행에 대한 변경사항이 완전히 계단식으로 수행되지 않을 수 있다. 예: 거래에서 고객 계정의 번호를 변경하려고 하는 동안 동시 거래에서 동일한 고객에 대한 새로운 송장을 작성하려고 시도함. CASCADE 규칙이 거래에서 볼 수 있는 모든 송장 행을 수정하여 번호가 변경된 고객 행과 일관성을 유지할 수 있지만, 다른 트랜잭션으로 수정하지 않음 그곳의 데이터; 데이터베이스는 두 개의 트랜잭션이 커밋할 때 일관된 데이터를 보장할 수 없기 때문에, 그들 중 한 가지는 강제로 롤백될 것이다(선착된 선착순). 

만들다 테이블 회계 (acct_num INT, 분량 십진법(10,2));  만들다 트리거 ins_sum 이전 삽입 켜기 회계      for 각 배를 젓다 세트 @합계를 내다 = @합계를 내다 + 새로운.분량;

예

첫 번째 예로서, 계정 데이터베이스에 송장 표가 있고 각 송장이 특정 공급업체와 연관되어 있다고 가정해 보십시오. 공급업체 세부사항(이름 및 주소 등)은 별도의 표에 보관되며, 각 공급업체에는 이를 식별하기 위한 '공급업체 번호'가 부여된다. 각 송장 기록에는 해당 송장에 대한 공급업체 번호가 포함된 속성이 있다. 그러면 '공급자 번호'가 공급자 테이블의 기본 키 입니다. 송장 표의 외부 키는 해당 기본 키를 가리킨다. 관계 스키마는 다음과 같다. 기본 키는 굵게 표시하고 외래 키는 기울임꼴로 표시한다. 

 공급업체(공급업체 번호, 이름, 주소) 송장(음성 번호, 텍스트, 공급업체 번호)

해당 데이터 정의 언어 문장은 다음과 같다. 

만들다 테이블 공급자. (   공급업체 번호 정수 NOT NULL,   이름           바카르(20) NOT NULL,   주소.        바카르(50) NOT NULL,   구속조건 공급업체_properties 1차 키(공급업체 번호),   구속조건 number_value 체크(공급업체 번호 > 0) )  만들다 테이블 송장 (   송장번호  정수 NOT NULL,   텍스트           바카르(4096),   공급업체 번호 정수 NOT NULL,   구속조건 invoice_properties 1차 키(송장번호),   구속조건 inumber_value 체크 (송장번호 > 0),   구속조건 공급업체_fk     외국 키(공급업체 번호) 참고 자료 공급자.(공급업체 번호)     켜기 갱신하다 캐스케이드 켜기 삭제 제한 )

참고 항목

참조

  1. ^ Coronel, Carlos (2010). Database Systems: Design, Implementation, and Management. Independence KY: South-Western/Cengage Learning. p. 65. ISBN 978-0-538-74884-1.
  2. ^ a b Elmasri, Ramez (2011). Fundamentals of Database Systems. Addison-Wesley. pp. 73–74. ISBN 978-0-13-608620-8.
  3. ^ Date, C. J. (1996). A guide to the SQL standard. Addison-Wesley. p. 206. ISBN 978-0201964264.
  4. ^ Sheldon, Robert (2005). Beginning MySQL. John Wiley & Sons. pp. 119–122. ISBN 0-7645-7950-9.
  5. ^ "Database Basics — Foreign Keys". Retrieved 2010-03-13.
  6. ^ MySQL AB (2006). MySQL Administrator's Guide and Language Reference. Sams Publishing. p. 40. ISBN 0-672-32870-4.
  7. ^ Powell, Gavin (2004). Oracle SQL: Jumpstart with Examples. Elsevier. p. 11. ASIN B008IU3AHY.
  8. ^ Mullins, Craig (2012). DB2 developer's guide. IBM Press. ASIN B007Y6K9TK.
  9. ^ Sheldon, Robert (2005). Beginning MySQL. John Wiley & Sons. p. 156. ISBN 0-7645-7950-9.
  10. ^ Garcia-Molina, Hector (2009). Database Systems: The Complete Book. Prentice Hall. pp. 93–95. ISBN 978-0-13-187325-4.

외부 링크