기본 키와 외래 키는 여러 테이블을 효율적인 관계형 데이터베이스로 구성하는 접착제입니다. 기본 키와 외래 키의 설계는 물리적 데이터베이스의 성능과 가용성에 결정적인 영향을 미칩니다.
데이터베이스 스키마는 이론적 논리적 설계에서 실제 물리적 설계로 변환되어야 합니다. 기본 키와 외래 키의 구조는 이 설계 프로세스의 핵심입니다. 설계된 데이터베이스가 프로덕션 환경에서 사용되면 이러한 키를 수정하기가 어려우므로 개발 단계에서 기본 키와 외래 키를 설계하는 것이 매우 필요하고 가치가 있습니다.
기본 키:
관계형 데이터베이스는 데이터베이스의 물리적 스키마의 초석인 기본 키에 의존합니다. 기본 키에는 물리적 수준에서 두 가지 목적만 있습니다.
1. 행을 고유하게 식별합니다.
2. 외래 키가 효과적으로 참조할 수 있는 객체입니다.
위의 두 가지 용도를 바탕으로 물리적 수준에서 기본 키를 설계할 때 따르는 몇 가지 원칙은 다음과 같습니다.
1. 기본 키는 사용자에게 의미가 없어야 합니다. 사용자가 다대다 관계를 나타내는 조인 테이블의 데이터를 보고 거의 쓸모가 없다고 불평한다면 이는 기본 키가 잘 설계되었음을 증명합니다.
2. 조인 및 필터 작업의 효율성을 높이려면 기본 키가 단일 열이어야 합니다.
참고: 복합 키를 사용하는 사람들은 일반적으로 두 가지 이유로 변명하는데, 둘 다 잘못된 것입니다. 하나는 기본 키가 실제 의미를 가져야 한다는 것입니다. 그러나 기본 키를 의미 있게 만드는 것은 데이터베이스를 인위적으로 파괴하는 편의를 제공할 뿐입니다. 두 번째는 이 방법을 사용하여 다대다 관계를 설명하는 조인 테이블에서 두 개의 외래 키를 기본 키로 사용할 수 있다는 것입니다. 또한 복합 기본 키는 종종 잘못된 외래 키로 이어지기 때문에 이 접근 방식에 반대합니다. 즉, 테이블을 조인할 때 위의 두 번째 방법에 따라 다른 슬레이브 테이블의 마스터 테이블이 되어 이 테이블의 기본 키의 일부가 됩니다. 그러나 이 테이블은 다른 슬레이브 테이블의 마스터 테이블이 되고 해당 기본 키가 될 수도 있습니다. 다른 슬레이브 테이블의 마스터 테이블이 될 수 있습니다. 기본 키의 일부로 이러한 방식으로 전달되면 슬레이브 테이블이 나중일수록 기본 키에 더 많은 열이 포함됩니다.
3. 기본 키를 절대 업데이트하지 마세요. 실제로 기본 키에는 행을 고유하게 식별하는 것 외에 다른 목적이 없으므로 이를 업데이트할 이유가 없습니다. 기본 키를 업데이트해야 하는 경우 기본 키는 사용자에게 의미가 없어야 한다는 원칙을 위반합니다.
참고: 이 원칙은 데이터 변환이나 여러 데이터베이스 병합 중에 종종 구성해야 하는 데이터에는 적용되지 않습니다.
4. 기본 키에는 타임스탬프, 생성 시간 열, 수정 시간 열 등과 같이 동적으로 변경되는 데이터가 포함되어서는 안 됩니다.
5. 기본 키는 컴퓨터에서 자동으로 생성되어야 합니다. 기본 키 생성에 사람이 개입하는 경우 이는 행을 고유하게 식별하는 것 이상의 의미를 갖게 됩니다. 이 경계를 넘으면 기본 키를 수정하려는 인센티브가 있을 수 있으므로 이 시스템에서 레코드 행을 연결하고 관리하는 데 사용하는 키 수단은 데이터베이스 설계를 이해하지 못하는 사람들의 손에 넘어갈 것입니다.
외래 키는 데이터베이스 수준의 무결성 제약 조건으로, 데이터베이스 기본 이론서에서 언급한 "참조 무결성"의 데이터베이스 구현 방법입니다.
물론 외래 키 속성을 제거할 수 있습니다. 이 제약 조건을 더 이상 사용하지 않으려면 프로그래밍에 아무런 영향을 미치지 않지만 데이터를 입력할 때 입력된 데이터에 대해 "참조 무결성" 검사가 수행되지 않습니다. .
예를 들어, 두 개의 테이블이 있습니다.
A(a,b): a는 기본 키이고, b는 외래 키(Bb의)입니다.
B(b,c,d): b는 기본 키입니다.
필드 b의 외래 키 속성을 제거해도 프로그래밍에는 아무런 영향이 없습니다.
위와 같이 A의 b는 비어 있거나 B의 b에 존재하는 값입니다. 외래 키가 있는 경우 데이터베이스는 A의 b가 B의 b에 존재하는지 자동으로 확인합니다.
1. 외부 표현은 참조 무결성을 표현합니다. 이는 데이터에 내재되어 있으며 프로그램과는 아무 관련이 없습니다. 그러므로 DBMS에 맡겨야 한다.
2. 외부 데이터베이스를 사용하는 것은 간단하고 직관적이며 데이터 모델에 직접 반영될 수 있습니다. 특히 기존 데이터베이스를 분석할 때 이점이 매우 분명합니다. 오래 전에 기존 엔터프라이즈 데이터베이스를 찾았는데, 참조 무결성 제약 조건 중 일부는 외래 키로 설명되어 있고 일부는 트리거를 사용하여 구현되었습니다. 물론 문서에 있을 수도 있지만 완전하지 않을 수도 있지만 외래 키는 매우 명확하고 직관적입니다.
3. 이 작업을 완료하기 위해 트리거나 프로그램을 사용할 수 있는데(참조 무결성 제약 참조) DBMS가 수단을 제공했는데 왜 우리가 직접 수행해야 합니까? 그리고 우리가 하는 일이 RDBMS만큼 좋지는 않다고 해야 할까요. 사실 초기 RDBMS에는 외래 키가 없었지만 이제는 데이터베이스 공급업체가 이 기능을 추가하는 것이 타당하다고 생각합니다. 이러한 관점에서는 외래 키가 더 편리합니다.
4. 편의성 측면에서 제가 주도한 프로젝트에 따르면 프로그래머들은 주로 디버깅 중에 데이터를 입력하는 것이 번거롭다고 보고했습니다. 데이터가 참조 무결성을 위반할 수 있다면 참조 무결성 자체는 이때 평판 비즈니스와 충돌하지 않습니다. 트리거 선물 프로그램을 사용해서는 안 됩니다. 그렇지 않으면 데이터가 잘못되어 데이터베이스에 전혀 입력되어서는 안 됩니다! 게다가 이는 불법 데이터를 차단하는 테스트 시스템의 일부이기도 합니다. 실제로 프런트엔드 프로그램은 이러한 제출 실패를 처리해야 합니다. 데이터는 프로그램에 속하지 않고 기업에 속합니다. 저장된 프로그램은 가능한 한 데이터와 분리되어야 하며, 그 반대도 마찬가지입니다.
마지막으로 키 구축을 위한 몇 가지 원칙에 대해 이야기하겠습니다.
1. 관련 필드에 대한 외래 키를 생성합니다.
2. 모든 키는 고유해야 합니다.
3. 복합키 사용을 피하세요.
4. 외래 키는 항상 고유 키 필드와 연결됩니다.
이 기사는 CSDN 블로그에서 가져온 것입니다. 재인쇄할 때 출처를 표시하십시오: http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx