대체키

**대체키**(영어: surrogate key, synthetic key, pseudokey, entity identifier, factless key, technical key)는 데이터베이스에서 모델링된 세계의 엔티티 또는 데이터베이스의 객체에 대한 고유 식별자이다. 대체키는 자연키와 달리 애플리케이션 데이터에서 파생되지 않는다.access-date=2020-02-21
# 정의
대체(surrogate)의 정의는 적어도 두 가지가 있다. ; 대체 (1) - Hall, Owlett, Todd (1976): 대체는 외부 세계의 엔티티를 나타낸다. 대체는 시스템에 의해 내부적으로 생성되지만 사용자나 애플리케이션에 여전히 가시적이다.P A V Hall, J Owlett, S J P Todd, "Relations and Entities", Modelling in Data Base Management Systems (ed GM Nijssen), North Holland 1976. ; 대체 (2) - Wieringa, De Jonge (1991): 대체는 데이터베이스 자체의 객체를 나타낸다. 대체는 시스템에 의해 내부적으로 생성되며 사용자나 애플리케이션에는 보이지 않는다. 대체 (1) 정의는 데이터 모델과 관련되며 저장 모델이 아닌 이 문서 전체에서 사용된다. Date (1998)를 참조하라. 대체와 기본 키의 중요한 차이점은 데이터베이스가 현재 데이터베이스인지 이력 데이터베이스인지에 달려 있다. 현재 데이터베이스는 현재 유효한 데이터만 저장하기 때문에 모델링된 세계의 대체와 데이터베이스의 기본 키 간에는 일대일 대응 관계가 있다. 이 경우 대체는 기본 키로 사용될 수 있으며 결과적으로 대체키라는 용어가 사용된다. 그러나 이력 데이터베이스에서는 기본 키와 대체 간에 다대일 관계가 있다. 단일 대체에 해당하는 데이터베이스에 여러 객체가 있을 수 있으므로 대체키를 기본 키로 사용할 수 없다. 각 객체를 고유하게 식별하기 위해 대체키외에 다른 속성이 필요하다. Hall et al. (1976)은 이에 대해 아무 말도 하지 않지만, 다른 이들은 대체키가 다음과 같은 특성을 가져야 한다고 주장했다. * 값은 재사용되지 않는다. * 값은 시스템에 의해 생성된다. * 값은 사용자나 애플리케이션에 의해 조작될 수 없다. * 값은 의미론적 의미를 포함하지 않는다. * 값은 사용자나 애플리케이션에 보이지 않는다. * 값은 서로 다른 도메인의 여러 값으로 구성되지 않는다.
# 실무의 대체키
현재 데이터베이스에서 대체키는 데이터베이스 관리 시스템에 의해 생성되고 데이터베이스의 애플리케이션 데이터에서 파생되지 않는 기본 키일 수 있다. 대체키의 유일한 의미는 기본 키 역할을 하는 것이다. 대체키는 데이터베이스에서 생성된 범용 고유 식별자(예: 각 직원의 UUID 외에 각 직원의 HR 번호) 외에 존재할 수도 있다. 대체키는 종종 순차 번호이다(예: 사이베이스 또는 마이크로소프트 SQL 서버 "identity column", PostgreSQL 또는 IBM 인포믹스의 `serial`, 오라클 (기업) 또는 SQL 서버의 `SEQUENCE` 또는 MySQL의 `AUTO_INCREMENT`로 정의된 열). 일부 데이터베이스는 대체키에 대한 가능한 데이터 유형으로 UUID/GUID를 제공한다(예: PostgreSQL의 `UUID`date=9 May 2024 또는 SQL 서버의 `UNIQUEIDENTIFIER`date=23 May 2023). 다른 모든 열과 독립적인 키를 가지면 데이터 값이나 데이터베이스 디자인의 변경으로부터 데이터베이스 관계가 보호된다Surrogate+key (애자일 소프트웨어 개발을 더욱 민첩하게 만듦) 그리고 고유성을 보장한다. 이력 데이터베이스에서는 대체키와 자연키를 구별해야 한다. 모든 행은 비즈니스 키와 대체키를 모두 갖는다. 대체키는 데이터베이스에서 하나의 고유한 행을 식별하고, 비즈니스 키는 모델링된 세계의 하나의 고유한 엔티티를 식별한다. 한 테이블 행은 정의된 시간 범위 동안 엔티티의 모든 속성을 보유하는 시간 조각을 나타낸다. 이 조각들은 하나의 비즈니스 엔티티의 전체 수명을 묘사한다. 예를 들어, EmployeeContracts 테이블은 계약 근무 시간을 추적하기 위한 시간적 정보를 보유할 수 있다. 두 행 모두에 대한 한 계약의 비즈니스 키는 동일(고유하지 않음)하지만 각 행에 대한 대체키는 고유하다. {| class="wikitable" |- ! SurrogateKey !! BusinessKey !! EmployeeName !! WorkingHoursPerWeek !! 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 |} 일부 데이터베이스 설계자는 다른 후보 키의 적합성에 관계없이 체계적으로 대체키를 사용하는 반면, 다른 설계자는 데이터에 이미 존재하는 키가 있는 경우 이를 사용한다. 일부 대체 이름("system-generated key")은 대체 개념의 특성보다는 새로운 대체 값을 생성하는 방법을 설명한다. 대체 생성 접근 방식에는 다음이 포함된다. * 범용 고유 식별자(UUID) * GUID * 객체 식별자(OID) * 사이베이스 또는 SQL 서버 아이덴티티 컬럼(identity column) `IDENTITY` 또는 `IDENTITY(n,n)` * 오라클 (기업) `SEQUENCE` 또는 `GENERATED AS IDENTITY` (12.1 버전부터)title=Database SQL Language Reference * SQL 서버 `SEQUENCE` (SQL 서버 2012부터)date=29 December 2022 * PostgreSQL 또는 IBM 인포믹스 serial * MySQL `AUTO_INCREMENT` * SQLite `INTEGER PRIMARY KEY` (`AUTOINCREMENT`를 사용하면 이미 사용되었지만 사용 가능한 번호의 재사용을 방지한다)quote= * 마이크로소프트 액세스의 AutoNumber 데이터 유형 * IBM DB2 및 PostgreSQL의 `AS IDENTITY GENERATED BY DEFAULT`. * 데이터 정의 언어(DDL)에 구현된 테라데이타의 identity column * 시퀀스가 ​​프로시저와 필드가 있는 시퀀스 테이블(id, sequenceName, sequenceValue, incrementValue)에 의해 계산될 때의 Table Sequence
# 장점

## 안정성
대체키는 일반적으로 행이 존재하는 동안 변경되지 않는다. 이것은 다음과 같은 장점을 갖는다. * 애플리케이션은 데이터베이스의 행에 대한 참조를 잃지 않는다(식별자가 변경되지 않으므로). * 외래 키 간의 캐스케이딩 업데이트를 지원하지 않는 데이터베이스에서도 기본 또는 자연키 데이터를 항상 수정할 수 있다.
## 요구 사항 변경
엔티티를 고유하게 식별하는 속성이 변경될 수 있으며, 이는 자연키의 적합성을 무효화할 수 있다. 다음 예를 생각해 보자. :직원의 네트워크 사용자 이름을 자연키로 선택한다. 다른 회사와 합병 시 새로운 직원을 삽입해야 한다. 일부 새로운 네트워크 사용자 이름은 회사 분리 시 독립적으로 생성되었기 때문에 충돌이 발생한다. 이러한 경우 일반적으로 자연키에 새 속성을 추가해야 한다(예: original_company 열). 대체키를 사용하면 대체키를 정의하는 테이블만 변경해야 한다. 자연키를 사용하면 자연키를 사용하는 모든 테이블(및 다른 관련 소프트웨어)이 변경되어야 한다. 일부 문제 영역에서는 적합한 자연키를 명확하게 식별하지 못한다. 대체키는 잘못될 수 있는 자연키를 선택하는 것을 방지한다.
## 성능
대체키는 4바이트 정수와 같은 압축된 데이터 유형인 경향이 있다. 이를 통해 데이터베이스는 단일 키 열을 여러 열(자주 텍스트인데, 이는 훨씬 느림)보다 빠르게 쿼리할 수 있다. 또한 키의 비중복 분포는 결과 B 트리 인덱스가 완전히 균형을 이루도록 한다. 대체키는 복합 키보다 조인하는 비용이 적다(비교할 열이 적음).
## 호환성
루비 온 레일즈 또는 하이버네이트와 같은 여러 데이터베이스 애플리케이션 개발 시스템, 드라이버 및 객체 관계 매핑 시스템을 사용할 때, 데이터베이스 시스템에 독립적인 작업과 객체-행 매핑을 지원하기 위해 자연키 대신 모든 테이블에 정수 또는 GUID 대체키를 사용하는 것이 훨씬 쉽다.
## 균일성
모든 테이블에 균일한 대체키가 있으면 테이블에 독립적인 방식으로 코드를 작성하여 일부 작업을 쉽게 자동화할 수 있다.
## 유효성 검사
잘 알려진 패턴이나 구조를 따르는 키 값을 설계하여 자동으로 확인할 수 있다. 예를 들어, 특정 테이블의 특정 열에서 사용하기 위한 키는 다른 열이나 테이블에서 사용하기 위한 키와 "다르게 보이도록" 설계될 수 있어 키가 잘못 배치된 애플리케이션 오류 감지를 단순화한다. 그러나 대체키의 이러한 특성은 애플리케이션 자체의 논리를 구동하는 데 사용되어서는 안 된다. 이는 데이터베이스 정규화의 원칙을 위반하기 때문이다.
## 관계 단순성
대체키는 단일 열만 필요하기 때문에(여러 열이 필요한 복합 키와 달리) 외래 키 관계 생성을 단순화한다. 데이터베이스에서 쿼리를 만들 때 테이블을 조인할 때 복합 외래 키의 모든 열을 포함하는 것을 잊으면 의도하지 않은 곱집합의 형태로 예상치 못한 결과가 발생할 수 있다.
# 단점

## 비관련성
생성된 대체키의 값은 행에 포함된 데이터의 실제 의미와 관련이 없다. 대체키를 사용하여 다른 테이블에 대한 외래 키 참조를 포함하는 행을 검사할 때, 대체키자체에서 대체키행의 의미를 파악할 수 없다. 관련된 데이터 항목을 보려면 모든 외래 키를 조인해야 한다. 적절한 데이터베이스 제약 조건이 설정되지 않았거나 참조 무결성이 사용되지 않은 레거시 시스템에서 데이터를 가져온 경우, 기본 키 값에 해당하지 않는 유효하지 않은 외래 키 값이 있을 수 있다. (이 점에서 C. J. Date는 대체키의 무의미함을 장점으로 간주한다.C.J. Date. The primacy of primary keys. From "Relational Database Writings, 1991-1994. Addison-Wesley, Reading, MA.) 이러한 오류를 발견하려면 외래 키가 있는 테이블과 기본 키가 있는 테이블 간에 왼쪽 외부 조인을 사용하는 쿼리를 수행하여 레코드를 구별하는 데 필요한 필드 외에 두 키 필드를 모두 보여야 한다. 유효하지 않은 모든 외래 키 값은 기본 키 열이 NULL이 된다. 이러한 검사를 수행해야 하는 필요성이 너무 흔해서 마이크로소프트 액세스는 실제로 사용자에게 대화 상자를 안내한 후 적절한 SQL을 생성하는 "일치하지 않는 쿼리 찾기" 마법사를 제공한다. (하지만 이러한 쿼리를 수동으로 작성하는 것은 너무 어렵지 않다.) "일치하지 않는 쿼리 찾기"는 일반적으로 레거시 데이터를 상속할 때 데이터 정제 프로세스의 일부로 사용된다. 대체키는 내보내고 공유하는 데이터에 대해 자연스럽지 않다. 특히 두 개의 다른 유사한 스키마(예: 테스트 스키마 및 개발 스키마)의 테이블이 비즈니스 의미에서 동등하지만 키가 다른 레코드를 포함할 수 있다는 점이 어렵다. 이는 임시 데이터(가장 명확하게는 데이터베이스에 "실시간" 연결이 있는 실행 중인 애플리케이션에서)를 제외하고 대체키를 내보내지 않음으로써 완화할 수 있다. 대체키가 자연키를 대체하면 도메인별 참조 무결성이 손상된다. 예를 들어, 고객 마스터 테이블에서 동일한 고객이 자연키(고객 이름, 생년월일, 이메일 주소의 조합)는 고유하지만 별도의 고객 ID로 여러 레코드를 가질 수 있다. 손상을 방지하려면 테이블의 자연키를 대체해서는 안 된다. 제약 조건이 나중에 추가되는 경우 SQL의 `CREATE TABLE` 문 또는 `ALTER TABLE ... ADD CONSTRAINT` 문을 사용하여 테이블을 정의할 때 자연키의 역할을 유일 제약으로 유지해야 한다.
## 질의 최적화
관계형 데이터베이스는 테이블의 기본 키에 고유 인덱스가 적용된다고 가정한다. 고유 인덱스는 두 가지 목적을 수행한다. (i) 행 전체에 기본 키 데이터가 고유해야 하므로 엔티티 무결성을 강제하고 (ii) 쿼리 시 행을 빠르게 검색한다. 대체키는 테이블의 식별 속성(즉, 자연키)을 대체하고 식별 속성은 쿼리될 가능성이 높은 속성이므로 질의 최적화 프로그램은 가능성 있는 쿼리를 충족하기 위해 전체 테이블 스캔을 수행해야 한다. 전체 테이블 스캔에 대한 해결책은 식별 속성 또는 해당 집합에 인덱스를 적용하는 것이다. 이러한 집합 자체가 후보 키인 경우 인덱스는 고유 인덱스가 될 수 있다. 그러나 이러한 추가 인덱스는 디스크 공간을 차지하고 삽입 및 삭제 속도를 늦춘다.
## 정규화
대체키는 자연키에 중복 값을 초래할 수 있다. 중복을 방지하려면 제약 조건이 나중에 추가되는 경우 SQL의 `CREATE TABLE` 문 또는 `ALTER TABLE ... ADD CONSTRAINT` 문을 사용하여 테이블을 정의할 때 자연키의 역할을 유일 제약으로 유지해야 한다.
## 비즈니스 프로세스 모델링
대체키는 자연스럽지 않기 때문에 비즈니스 요구 사항을 모델링할 때 결함이 나타날 수 있다. 자연키에 의존하는 비즈니스 요구 사항은 대체키로 변환되어야 한다. 한 가지 전략은 논리적 모델(대체키가 나타나지 않음)과 해당 모델의 물리적 구현 간에 명확한 구분을 설정하여 논리적 모델이 정확하고 합리적으로 잘 정규화되었는지 확인하고 물리적 모델이 논리적 모델의 올바른 구현인지 확인하는 것이다.
## 의도치 않은 공개
순차적으로 생성된 대체키를 사용하면 독점 정보가 유출될 수 있다. 이전에 생성된 순차 키를 최근에 생성된 순차 키에서 빼면 해당 기간 동안 삽입된 행 수를 알 수 있다. 이는 예를 들어 기간당 트랜잭션 수 또는 새 계정을 노출할 수 있다. 예를 들어 독일 전차 문제를 참조하라. 이 문제를 극복하는 방법에는 몇 가지가 있다. * 순차 번호를 무작위 값만큼 증가시킨다. * 범용 고유 식별자와 같은 무작위 키를 생성한다.
## 의도치 않은 가정
순차적으로 생성된 대체키는 더 높은 키 값을 가진 이벤트가 더 낮은 값을 가진 이벤트 이후에 발생했음을 암시할 수 있다. 삽입이 실패하고 나중에 채워질 수 있는 공백을 남길 수 있으므로 이러한 값이 시간 순서를 보장하지 않기 때문에 반드시 사실은 아니다. 시간 순서가 중요하다면 날짜와 시간은 별도로 기록해야 한다.
# 참고 자료
참고 자료 시작 * isbn = 0-7204-0459-2 * Engles, R.W.: (1972), A Tutorial on Data-Base Organization, Annual Review in Automatic Programming, Vol.7, Part 1, Pergamon Press, Oxford, pp. 1–64. * 란게포르스, 베리에 (1968). Elementary Files and Elementary File Records, Proceedings of File 68, an IFIP/IAG International Seminar on File Organisation, Amsterdam, November, pp. 89–96. * access-date = 2022-12-02 * publisher = Addison-Wesley * access-date = 2006-12-03 * archive-date = 2008-01-30 * access-date = 2006-12-03 참고 자료 끝 - 데이터베이스 위키데이터 속성 추적 분류:데이터베이스 관리 시스템 분류:데이터 모델링