2.2 Tables and Keys

관계형 모델(Relational Model)에서 테이블은 기본 엔티티(Basic Entitiy)입니다. 각 테이블은 실제 세계의 엔티티를 나타내야 하며, 이러한 엔티티는 실제 세계의 객체(Object)나 이벤트(Event)가 될 수 있습니다. 예를 들어, 고객은 실제 세계의 객체이고, 고객이 주문하는 것은 이벤트입니다.

테이블은 행(row)과 열(column)로 구성됩니다. 관계형 모델에서는 테이블의 각 행은 프로그래밍을 통해 유일하게 지정할 수 있도록 해야되며 각 행은 유일해야 합니다. 행의 고유성은 해당 테이블의 기본 키(primary key)를 정의하여 보장됩니다. 테이블의 기본 키(primary key)는 해당 행을 유일하게 식별할 수 있게 해주는 하나 이상의 필드로 구성됩니다. 각 테이블은 테이블의 기본 키(primary key)를 하나만 가질 수 있습니다. 테이블의 기본 키(primary key)로 사용될 수 있는 모든 필드를 후보 키(candidate key)라고 합니다. 테이블의 다른 필드에서는 여러 개의 보조 키(secondary key)를 가져올 수 있습니다.

보조 키는 고유한(unique)하거나 비고유(nonunique)할 수 있습니다. 보조 키(secondary key)는 일반적으로 데이터 검색 속도를 높이기 위해 테이블에 보조 키(secondary index)를 정의하는 데 사용됩니다. 키는 간단할 수도(simple) 또는 복합할 수(composite)도 있습니다. 키가 하나의 필드로 구성되면 simple key라고 하고, 키가 두 개 이상의 필드로 구성되면 composite key라고 합니다.

테이블 모델링 시, 해당 테이블의 후보 키 중에서 비즈니스 요구사항에 따라 어떤 후보 키들이 기본 키로 구성될지 결정해야 합니다. 테이블의 기본 키를 정의하는 데 규칙은 없습니다. Fabian Pascal의 "SQL and Relational Basics" 책에서는 이러한 결정은 최소주의 원칙( Minimalism : 필요한 필드를 가장 적게 선택 ), 안정성( stability : 변경이 적게 일어나는 키 선택), 간결성/익숙함(사 simplicity,familiarity : 사용자에게 친숙하고 간단한 키 선택)에 따라 결정해야 한다고 언급합니다.

예를 들어, 직원 세부 정보를 저장하는 테이블이 있다고 가정해 봅시다. 이 테이블은 직원 ID, 이름, 성, 주소, 전화번호 및 우편번호 등의 정보를 포함할 것입니다. 이 중 어떤 필드가 좋은 기본 키(primary key)로 사용될까요? Pascal의 지침을 따르면, 주소와 전화번호는 자주 변경되므로 제외할 수 있습니다. 또한, 결혼 등의 이유로 이름이 바뀔 수 있으며, 이름을 잘못 입력하는 경우가 있으며, 두 명의 직원이 동일한 이름을 가질 가능성이 높습니다.

직원 ID는 조직 전체에서 유일하기 때문에 최적의 후보가 됩니다. 비록 기본 키(primary key)를 선택하는 것에 고정된 규칙은 없지만, 대부분의 개발자는 숫자 기본 키(numeric primary key)를 선택하는 것을 선호합니다. 이는 숫자 필드에서의 검색이 텍스트 필드에서의 검색보다 효율적이기 때문입니다.