[데이터베이스설계] 2-2 keys

keys

Keys = 테이블의 컬럼. n개의 컬럼이 모여 하나의 키를 구성하기도 함  (= composite key)   * superkey (슈퍼키) : 고유식별성만 가지면 최소가 아니어도 슈퍼키    - K에 대한 값이 각 가능한 relation r (R) (= relation instance)의 고유한 튜플을 구분하기 충분하면    - ID 자체가 고유식별자라서, 혼자서도 슈퍼키, 조합해서도 슈퍼키임         --> { ID }, { ID, name } 둘 다 instructor의 슈퍼키임        // 고유식별자 포함, 2나머지개수   * candidate key (후보키) : 슈퍼키 중 최소인 것. - 고유식별성을 갖기 위해 정말 필요한 컬럼만 있는 경우     --> { ID } 가 instructor의 후보키임     - RDB 안에는 후보키가 복수 개 존재 가능함   * primary key (기본키) : 후보키 중 하나가 기본키로 선택됨.   (+) 만약 A, B, C 중 A, B 두개가 합성해야만 고유식별성을 갖는다면   * superkey = { A, B }, { A, B, C }  --> 2개   * candidate = { A, B }           --> 1개   * primalykey = { A, B }          --> 1개   * foreign key (외래키) : 참조관계에 관련된 키.     - 다른 릴레이션의 기본키를 속성(들)으로 포함할 수 있음     - RDB에 relation (테이블)이 복수 개 존재할 수 있음.         그 테이블들이 서로간 독립적(무관)하지 않고 테이블 간 참조관계가 존재하게 됨 **  외래키 제약 조건 (Foreign key constraint) : 한 relation의 값은 아래의 relation들에 나타나야 함. (1) Referencing relation [FK 외래키]  //교수자 테이블의 dept_name 컬럼이 외래키 (2) Referenced relation [PK 기본키]   //학과 테이블의 dept_name 컬럼이 참조되는 기본키   --> 외래키에 나타난 null이 아닌 값은 반드시 그것이 참조하는 기본키에 존재해야 함       -> 이 반대는 성립할 필요 없음     // null이 외래키에 들어가는 것은 가능함. 이 경우에는 기본키에 나타나지 않음     // 기본키 pk에는 null이 들어갈 수 없음, pk의 값들은 서로 달라야 한다는 제약도 있음   è 참조당하는 쪽은 항상 그 테이블의 고유 식별자로 선정된 primary key가 된다 -> 이 반대는 성립하지 않아도 됨  (FK 말고 다른것도 PK 참조할 수 있음 : 참조무결성?) // 참조대상의 컬럼이 그 테이블의 PK 여야 FK가 될 수 있음.   //교재 1장 12쪽 교수테이블, 학과테이블… 교수테이블의 dept_name 컬럼이 외래키가 되어서 학과테이블의 dept_name 컬럼을 참조하고 있음 = 교수테이블의 dept_name 컬럼의 값이 학과테이블에서 반드시 찾을 수 있어야 함   section 테이블에서 <building, room number>은 합성키로서 외래키임.     -> classroom 테이블의, <building, room number> 합성키로서 PK인 것을 참조함   --> PK가 부분으로 외래키로 동작할 수 있음. 각각 따로 갈라져 다른 PK를 가리킬 수 있다는 뜻 -> takes 테이블에서 <ID>, <나머지> 가 각각 외래키로 동작함. PK가 갈라짐   --> FK와 PK의 컬럼 명은 다를 수 있음     -> 둘의 이름을 다르게 하는 게 실생활에서 더 적절한 표현일 수도 있음 (스키마 가독성)     -> 그러나 자연조인 구문에서는 FK와 PK의 컬럼 이름이 같아야 함   --> 참조하는 릴레이션과 피참조 릴레이션은 동일한 릴레이션일 수도 있음 -> PK, FK이름 다를 수 밖에 없다   --> PK이면서 동시에 FK일 수 있음   --> 후보키 2개인 경우 (ex. 학번도 가능, 주민번호도 가능) PK를 하나 선택해야 하는데,      다른 릴레이션의 FK가 특정 컬럼을 참조중이라면 그건 무조건 PK여야 함을 고려하기   --> 릴레이션을 표현한 테이블 à 그 안 식별자들 개체에 대한 정보를 저장한 테이블을 참조하게         -> 예) works( employee, company 양 개체의 식별자를 짝짓기해 관계를 표현한 테이블 )             --> 해당 개체를 가리키게 설정하기   --> takes 테이블 -> (학번, 과목번호) 합성해서 PK임. 각각이 다른 PK를 가리키는 FK일 수 있음         -> 반대방향으로 참조되면 (=합성키가 PK인 테이블을 참조한다면)             피참조컬럼이 그 테이블의 PK가 아님... 혼자서 PK가 되지 못하고, 의미상 안맞을수도   * composite key (합성키) : n개의 컬럼이 모여 하나의 키를 구성