대리 키

Surrogate key

데이터베이스의 대리 키(또는 합성 키, 유사 키, 엔티티 식별자, 사실 없는 키 또는 기술[citation needed] 키)는 모델링된 월드의 엔티티 또는 데이터베이스의 오브젝트에 대한 고유한 식별자다. 대체 키는 자연(또는 비즈니스) 키와 달리 애플리케이션 데이터에서 파생되지 않는다.[1]

정의

대리모에는 적어도 두 가지 정의가 있다.

대리 (1) – 홀, 오울렛 및 토드(1976)
대리인은 외부 세계의 실체를 나타낸다. 대리모는 시스템에 의해 내부적으로 생성되지만 그럼에도 불구하고 사용자나 애플리케이션에 보인다.[2]
대리모 (2) – Wieringa 및 De Jonge(1991)
대리모는 데이터베이스 자체에서 개체를 나타낸다. 대리모는 시스템에 의해 내부적으로 생성되며 사용자나 애플리케이션에 보이지 않는다.

대리모(1) 정의는 스토리지 모델이 아닌 데이터 모델과 관련되며 이 문서 전반에 걸쳐 사용된다. 날짜(1998년)를 참조하십시오.

대리 키와 기본 키의 중요한 구분은 데이터베이스가 현재 데이터베이스인지 아니면 임시 데이터베이스인지에 따라 달라진다. 현재 데이터베이스는 현재 유효한 데이터만 저장하므로, 모델링된 세계의 대리인과 데이터베이스의 기본 키 사이에는 일대일 일치성이 있다. 이 경우 대리 키가 1차 키로 사용되어 결과적으로 대리 키라는 용어가 생길 수 있다. 그러나 시간적 데이터베이스에서는 기본 키와 대리 키 사이에 다대일 관계가 있다. 하나의 대리모에 해당하는 여러 개의 개체가 데이터베이스에 있을 수 있기 때문에 우리는 대리모를 1차 키로 사용할 수 없다; 대리모 외에도 각 개체를 고유하게 식별하기 위한 또 다른 속성이 필요하다.

홀 외 연구진(1976)은 이에 대해 아무 말도 하지 않지만, 다른 이들은[specify] 대리인이 다음과 같은 특성을 가져야 한다고 주장해왔다.

  • 그 값은 결코 재사용되지 않는다.
  • 시스템이 생성되는 값
  • 사용자나 응용 프로그램에 의해 값을 조작할 수 없음
  • 그 값에는 의미적 의미가 없다.
  • 값이 사용자 또는 응용 프로그램에 표시되지 않음
  • 이 값은 서로 다른 도메인의 여러 값으로 구성되지 않는다.

실제 대리점

현재 데이터베이스에서 대리 키는 데이터베이스 관리 시스템에 의해 생성되고 데이터베이스의 애플리케이션 데이터에서 파생되지 않는 기본 키가 될 수 있다. 대리키의 유일한 의의는 1차 키의 역할을 하는 것이다. 또한 대리 키가 데이터베이스 생성 UUID 외에 존재할 가능성도 있다(예를 들어, 각 직원의 UUID가 아닌 각 직원의 HR 번호).

대리 키는 종종 순차적인 숫자(예: Sybase 또는 SQL Server "identity column", Postgre)이다.SQL 또는 Informix serial, 오라클 또는 SQL 서버 SEQUENCE 또는 다음과 같이 정의된 열 AUTO_INCREMENT MySQL). 일부 데이터베이스는 UUID/GUID를 대리 키에 대한 가능한 데이터 유형으로 제공(예: Postgre)SQL 또는 SQL 서버 ).

키가 다른 모든 열에 독립적으로 있으면 데이터 값이나 데이터베이스 설계의 변화로부터 데이터베이스 관계가 절연되며(데이터베이스의 민첩성이 향상됨) 고유성이 보장된다.

임시 데이터베이스에서는 대리 키와 비즈니스 키를 구별할 필요가 있다. 모든 행에는 비즈니스 키와 대리 키가 둘 다 있을 것이다. 대리 키는 데이터베이스에서 하나의 고유한 행을 식별하고, 비즈니스 키는 모델링된 세계의 하나의 고유한 실체를 식별한다. 하나의 표 행은 정의된 시간 범위에 대한 모든 기업의 속성을 보유하는 시간의 조각을 나타낸다. 그 조각들은 한 사업체의 전체 수명을 묘사한다. 예를 들어, 계약된 근로시간을 추적하기 위해 직원 계약 표는 시간 정보를 보유할 수 있다. 한 계약의 비즈니스 키는 두 행 모두에서 동일하지만(비유일) 각 행의 대리 키가 고유하다.

대리 키 비즈니스 키 직원 이름 작업당 시간주간 RowValidFrom RowValidTo
1 BOS0120 존 스미스 40 2000-01-01 2000-12-31
56 P0000123 밥 브라운 25 1999-01-01 2011-12-31
234 BOS0120 존 스미스 35 2001-01-01 2009-12-31

일부 데이터베이스 설계자는 다른 후보 키의 적합성과 상관없이 체계적으로 대리키를 사용하는 반면, 다른 설계자는 데이터에 이미 존재하는 키를 사용한다.

대체 이름 중 일부("시스템 생성 키")는 대리 개념의 속성보다는 새로운 대리 값을 생성하는 방법을 설명한다.

대리인을 생성하는 방법에는 다음이 포함된다.

이점

안정성

일반적으로 행이 존재하는 동안에는 대리 키가 변경되지 않는다. 이것은 다음과 같은 장점을 가지고 있다.

  • 애플리케이션은 식별자가 변경되지 않기 때문에 데이터베이스의 행에 대한 참조를 잃을 수 없다.
  • 기본 키 또는 자연 키 데이터는 관련 외부 키에 걸쳐 계단식 업데이트를 지원하지 않는 데이터베이스에서도 항상 수정할 수 있다.

요구사항변경

기업을 고유하게 식별하는 속성이 변경될 수 있으며, 이는 자연 키의 적합성을 무효화할 수 있다. 다음 예를 고려해 보십시오.

직원의 네트워크 사용자 이름은 자연 키로 선택된다. 다른 회사와 합병할 때는 반드시 신입 사원을 투입해야 한다. 새로운 네트워크 사용자 이름 중 일부는 사용자 이름이 독립적으로 생성되었기 때문에 충돌을 일으킨다.

이러한 경우 일반적으로 새로운 속성을 자연 키(예: original_company column)에 추가해야 한다. 대리 키를 사용하는 경우 대리 키를 정의하는 테이블만 변경해야 한다. 자연 키를 사용하면 자연 키를 사용하는 모든 테이블(및 기타 관련 소프트웨어)이 변경되어야 한다.

일부 문제 영역은 적합한 자연 키를 명확하게 식별하지 않는다. 대리 키는 잘못되었을 수 있는 자연적인 키를 선택하지 않는다.

퍼포먼스

대리 키는 4바이트 정수처럼 콤팩트한 데이터 유형인 경향이 있다. 이를 통해 데이터베이스는 단일 키 열을 여러 열보다 빠르게 쿼리할 수 있다. 게다가, 키의 비중복 분포는 결과 b-트리 지수를 완전히 균형 있게 만든다. 대리 키도 복합 키보다 결합(비교할 열) 비용이 덜 든다.

호환성.

Ruby on Rails 또는 Hwipernate와 같은 여러 데이터베이스 애플리케이션 개발 시스템, 드라이버 및 객체 관계 매핑 시스템을 사용하는 동안 데이터베이스 시스템 불가지론 작업과 객체 대 행 매핑을 지원하기 위해 자연 키 대신 모든 테이블에 정수 또는 GUID 대리 키를 사용하는 것이 훨씬 쉽다.

균일성

모든 테이블에 동일한 대리 키가 있을 경우 테이블 독립적으로 코드를 작성함으로써 일부 작업을 쉽게 자동화할 수 있다.

확인

잘 알려진 패턴이나 구조를 따라 자동으로 검증할 수 있는 키 값을 설계할 수 있다. 예를 들어, 일부 표의 일부 열에 사용하고자 하는 키는 다른 열이나 표에서 사용하고자 하는 것과 "다르게" 보이도록 설계되어 키가 잘못 배치된 응용 프로그램 오류의 탐지를 단순화할 수 있다. 그러나, 이러한 대리 키의 특성은 데이터베이스 정규화 원칙을 위반할 수 있으므로, 응용 프로그램 자체의 논리를 추진하는데 사용되어서는 안 된다.

단점들

연결 끊기

생성된 대리 키의 값은 연속해서 보유하는 데이터의 실제 의미와 아무런 관계가 없다. 대리 키를 사용하여 다른 테이블에 외래 키 참조가 있는 행을 검사할 때, 대리 키 행의 의미를 키 자체에서 식별할 수 없다. 관련 데이터 항목을 보려면 모든 외래 키를 연결해야 한다. 적절한 데이터베이스 제약조건이 설정되지 않았거나 참조 무결성이 채택되지 않은 레거시 시스템에서 가져온 데이터가 있다면, 1차 키 값에 해당하지 않아 무효인 외래 키 값을 가질 수 있다. (이런 점에서 C.J. Date는 대리키의 무의미함을 장점으로 여긴다.)[5]

이러한 오류를 발견하려면 외부 키가 있는 테이블과 기본 키가 있는 테이블 사이에 왼쪽 외부 조인을 사용하는 쿼리를 수행하여 레코드를 구별하는 데 필요한 필드 외에 두 키 필드를 모두 표시해야 한다. 모든 잘못된 외부 키 값은 기본 키 열이 NULL로 지정된다. Microsoft Access는 실제로 사용자를 대화창으로 안내한 후 적절한 SQL을 생성하는 "Find Unmatched Query" 마법사를 제공할 정도로 이러한 검사를 수행할 필요가 흔하다. (그러나 이러한 쿼리를 수동으로 구성하는 것은 그리 어렵지 않다.) "미합치 찾기" 쿼리는 일반적으로 레거시 데이터를 상속할 때 데이터 정리 프로세스의 일부로 채택된다.

내보내고 공유하는 데이터에는 대리 키가 부자연스럽다. 특별한 어려움은 다른 두 개의 동일한 스키마(예: 테스트 스키마 및 개발 스키마)의 테이블이 비즈니스적 의미에서는 동일하지만 키는 다른 레코드를 저장할 수 있다는 것이다. 임시 데이터(대개 데이터베이스와의 "실시간" 연결이 있는 응용프로그램을 실행할 때)를 제외하고 대리 키를 내보내지 않음으로써 이 문제를 완화할 수 있다.

대리 키가 자연 키를 대체하면 도메인별 참조 무결성이 손상된다. 예를 들어, 고객 마스터 테이블에서, 비록 자연적인 키(고객 이름, 생년월일, 이메일 주소의 조합)가 독특하더라도, 동일한 고객이 별도의 고객 ID로 복수의 기록을 가질 수 있다. 절충을 방지하기 위해 테이블의 자연키를 대체해서는 안 되며, 자연키장 조합에 대한 고유 지수로 구현되는 고유한 제약조건으로 보존해야 한다.

쿼리 최적화

관계형 데이터베이스는 테이블의 기본 키에 고유한 인덱스가 적용된다고 가정한다. 고유 인덱스는 (i) 기본 키 데이터가 행에 걸쳐 고유해야 하므로, (i) 엔티티 무결성을 강제하는 것과 (i) 쿼리할 때 행을 신속하게 검색하는 두 가지 목적을 제공한다. 대리 키가 테이블의 식별 속성(자연 키)을 대체하고 식별 속성이 쿼리가 될 가능성이 높기 때문에 쿼리 최적화 장치는 가능한 쿼리를 수행할 때 전체 테이블 스캔을 수행하도록 강제된다. 전체 테이블 스캔에 대한 해결책은 식별 속성 또는 해당 속성 집합에 색인을 적용하는 것이다. 그러한 집합 자체가 후보 키인 경우 지수는 고유한 인덱스가 될 수 있다.

그러나 이러한 추가 인덱스는 디스크 공간을 차지하며 삽입 및 삭제 속도를 늦출 것이다.

정규화

대리 키가 있으면 자연 키에 값이 중복될 수 있다. 복제를 방지하려면 SQL의 CREATE TABLE 문 또는 ALTER TABLE ...을 사용하여 테이블을 정의할 때 고유 제약조건으로 자연키의 역할을 보존해야 한다.제약조건이 사후 고려로 추가되는 경우 제약조건 문구를 추가한다.

비즈니스 프로세스 모델링

대리 키가 부자연스럽기 때문에 비즈니스 요구사항을 모델링할 때 결함이 나타날 수 있다. 자연적인 키에 의존하는 비즈니스 요구사항은 대리 키로 변환되어야 한다. 전략은 (대리 키가 나타나지 않는) 논리 모델과 그 모델의 물리적 구현 간에 명확한 구별을 이끌어 내고, 논리 모델이 정확하고 합리적으로 잘 정규화되도록 하며, 물리적 모델이 논리 모델의 올바른 구현임을 확인하는 것이다.

우발적 공개

대리 키가 순차적으로 생성되면 독점 정보가 유출될 수 있다. 최근에 생성된 순차적 키에서 이전에 생성된 순차적 키를 빼면 그 기간 동안 삽입된 행의 수를 알 수 있다. 예를 들어, 기간당 거래 또는 신규 계정 수가 노출될 수 있다. 예를 들어 독일 탱크 문제를 참조하십시오.

이 문제를 극복하는 몇 가지 방법이 있다.

  • 순차 수를 임의의 양만큼 증가시킨다.
  • UUID와 같은 임의 키를 생성하십시오.

부주의한 가정

순차적으로 생성된 대리 키는 더 높은 키 값을 가진 이벤트가 더 낮은 값을 가진 이벤트 이후에 발생했음을 의미할 수 있다. 이러한 값이 인서트가 고장나 나중에 채워질 수 있는 간격을 남길 수 있기 때문에 시간 순서를 보장하지 않기 때문에 반드시 그렇지는 않다. 연대기가 중요한 경우 날짜와 시간은 별도로 기록해야 한다.

참고 항목

참조

인용구

  1. ^ "What is a Surrogate Key? - Definition from Techopedia". Techopedia.com. Retrieved 2020-02-21.
  2. ^ P A V Hall, J Owlett, S J P Todd, "관계와 실체", Modeling in Data Base Management Systems (ed GM Nijssen), 1976년 노스 홀랜드.
  3. ^ "Database SQL Language Reference".
  4. ^ https://msdn.microsoft.com/en-us/library/ff878091.aspx
  5. ^ C.J. 데이트. 기본 키의 기본 키. 출처: "관계 데이터베이스 문서, 1991-1994. 애디슨 웨슬리, 레딩, MA.

원천