슈퍼키

Superkey

관계형 데이터 모델에서 수퍼키는 관계의 각 튜플을 고유하게 식별하는 속성 집합이다.[1][2] 슈퍼키 값이 고유하기 때문에 슈퍼키 값이 같은 튜플도 비키 속성 값이 같아야 한다. 즉, 비키 속성들은 기능적으로 슈퍼키에 의존한다.

모든 속성의 집합은 항상 슈퍼키(사소한 슈퍼키)이다. 관계에서 튜플은 정의상 고유하며, 각 작업 후에 중복이 제거되므로 모든 속성 집합은 모든 튜플에 대해 항상 고유하게 평가된다. 후보 키(또는 최소 슈퍼키)는 속성을 제거하여 단순한 슈퍼키로 줄일 수 없는 슈퍼키다.[3]

예를 들어, 속성 직원이 있는 직원 스키마에서ID, 이름, 작업 및 부서ID(직원인 경우)ID 값은 직원보다 고유함ID는 일부 또는 모든 다른 속성과 결합되어 표의 튜플을 고유하게 식별할 수 있다. 각 조합, {종업원ID}, {종업원ID, 이름}, {종업원아이디, 이름, 직업 등등이 슈퍼키다. {employeeID}은(는) 후보 키로, 그 속성의 하위 집합도 슈퍼키도 아니다. {employeeID, 이름, 직업, 부서ID}은(는) 사소한 슈퍼키다.

속성 집합 K가 관계 R의 슈퍼키인 경우, 항상 K대한 R의 투영이 R 자체동일한 카디널리티를 갖는 경우다.

잉글랜드의 군주들
모나크 이름 모나크 번호 왕가
에드워드 II 플랜타게넷
에드워드 III 플랜타게넷
리차드. III 플랜타게넷
핸리다. IV 랭커스터

먼저 모든 속성 집합을 나열하십시오.

• {Monarch Name}
• {Monarch Number}
• {로얄 하우스}
• {모나치 이름, 모나크 번호}
• {모나치 이름, 로열 하우스}
• {모나치 번호, 로열 하우스}
• {Monarch Name, Monkron Number, Royal House}

둘째, 슈퍼키의 요건을 충족하지 못하는 세트를 모두 제거한다. 예를 들어 {Monarch Name, Royal House}은(는) 동일한 속성 값(Edward, Plantagenet)에 대해 다음과 같은 두 가지 고유한 튜플이 있기 때문에 수퍼키가 될 수 없다.

  • (Edward, II, Plantagenet)
  • (Edward, III, Plantagenet)

마지막으로, 제거 후 나머지 속성 집합은 이 예에서 가능한 유일한 수퍼키들이다.

  • {Monarch Name, Monarch Number}(후보 키)
  • {모나치 이름, 모나크 번호, 로열 하우스}

실제로, 슈퍼키는 단순히 관계에서 하나의 튜플 세트를 조사한다고 해서 결정될 수 없다. 슈퍼키는 해당 관계 스키마의 가능한 모든 인스턴스 관계를 유지해야 하는 관계 스키마의 기능 종속성 제약조건을 정의한다.

참고 항목

참조

  1. ^ Date, Christopher (2015). "Codd's First Relational Papers: A Critical Analysis" (PDF). warwick.ac.uk. Retrieved 2020-01-04. Note that the extract allows a “relation” to have any number of primary keys, and moreover that such keys are allowed to be “redundant” (better: reducible). In other words, what the paper calls a primary key is what later (and better) became known as a superkey, and what the paper calls a nonredundant (better: irreducible) primary key is what later became known as a candidate key or (better) just a key.
  2. ^ Introduction to Database Management Systems. Tata McGraw-Hill. 2005. p. 77. ISBN 9780070591196. no two tuples in any legal relation
  3. ^ Saiedian, H. (1996-02-01). "An Efficient Algorithm to Compute the Candidate Keys of a Relational Database Schema". The Computer Journal. 39 (2): 124–132. doi:10.1093/comjnl/39.2.124. ISSN 0010-4620.

추가 읽기

외부 링크