과거의 트리(tree) 기반 데이터베이스는 다루기 불편했다. 트리 기반 데이터베이스는 RDBMS의 외부 스키마와 같은 개념을 제공하지 않기 때문에, 데이터베이스에 접근하는 애플리케이션은 데이터베이스 내부의 데이터에 접근하는 방법을 모두 알고 있어야 하며, 데이터의 계층 구조까지 파악해야 하는 어려움이 있었다. 즉, 데이터 독립성을 제한하는 대신 데이터의 접근을 직접 통제할 수 있으므로 경우에 따라 최적의 효율을 내는 애플리케이션을 작성할 수 있다. 즉, DBMS에서의 데이터 독립성은 데이터 추상화 복잡도 증가와 트레이드 오프 관계에 있으며, 데이터 접근 / 탐색을 얼마만큼 효율적으로 구현하는가의 책임은 DBMS에게 넘어가게 된다.
관계형 데이터베이스는 기본적으로 테이블(table) 구조로 데이터를 표현 할 수 있다. 이에 비해 개체 기반(object oriented database)는 비정형 데이터를 다루는데 좀 더 유리하다. 관계형 데이터베이스는 속성(attribute)에 집합을 속성값으로 설정 할 수 없고, 멀티미디어 데이터 같은 비정형 데이터를 다루는데 어려움이 있다. 속성에 집합을 값으로 설정한다는 것은 관계 포함(relationship aggregation)과 다른 개념으로, 값 자체가 하나 이상의 값을 가질 수 있다는 의미이다. RDBMS보다 유연하다는 장점에도 불구하고, 실제 시장에서 개체 기반 데이터베이스들이 실패한 것은 데이터를 다루는 표준적인 방법의 부재에 있다. RDBMS는 SQL이란 강력한 표준적인 수단을 제공하는데 비해 개체 기반 데이터베이스들은 이와 같은 요구 조건을 만족하는 공통의 강력한 언어가 존재하지 않았다.
관계 모델에서 데이터를 구성하는 주된 구성 요소는 관계(relationship)이며, 이것은 스키마와 인스턴스로 구성된다. 인스턴스는 테이블을 의미하며, 스키마는 테이블의 형식적인 틀(필드나 레코드)를 기술한다. 즉, 인스턴스는 스키마에 의해서 실제로 존재하는 데이터 집합을 말하며, 스키마는 이 테이블을 형성 할 수 있는 규칙을 의미한다고 할 수 있다. SQL은 이 스키마를 정의 할 수 있는 수단을 제공하는데, 그것을 DDL(data definition language)라고 하며, 이 외에도 DCL(data control language), DML(data manipulation language)가 있다.
스키마는 형식적으로 레코드의 열을 기술하는 것으로, 데이터 무결성 조건을 명시하며, 인스턴스는 이 제약 조건을 모두 통과한 상태의 데이터 스냅샷으로 간주할 수 있다. 즉, 데이터 무결성 조건을 위반하는 인스턴스는 존재해서는 안된다. 어떤 튜플(tuple)들이 존재한다고 하자. 여기서, 이 튜플의 속성들은 전체 테이블에서 유일 할 수도 있고, 그렇지 않을 수도 있다. 여기서, 후보 키(candidate key)는 키를 구성하는 어떠한 부분 집합도 튜플에 대해서 구별자가 될 수 없다. 이런 것은 슈퍼 키(super key)가 된다. 즉, 후보 키는 이 튜플들을 구별 할 수 있는 유일한 값이어야 한다. 다시 말해서, 후보 키가 될 수 있는 조건은, 유일성(uniqueness)과 최소성(minimulity)를 만족해야 하는데, 슈퍼 키는 유일성 조건을 만족하지만, 최소성 조건을 만족하지 못하는 키다. 슈퍼 키의 부분 집합을 살펴보면, 수퍼 키의 부분 집합 중에서 후보 키가 될 수 있는 집합이 존재한다. 후보 키는 최소성 조건을 만족해야 하며, 기본 키(primary key)는 이런 후보 키들 중에서 선택할 수 있다.선택된 후보 키(= 기본 키)는 데이터베이스가 데이터를 구별하는데 기준이 된다. 키를 정리하면 다음과 같다.
슈퍼 키(super key) : 엔티티 집합에서 엔티티를 구별할 수 있게 해주는 하나 이상의 속성을 가지는 집합
후보 키(candidate key) : 최소의 슈퍼키
기본 키(primary key) : DBA(database administrator)에 의해 선택된 후보 키
대체 키(alternate key, or secondary key) : 기본 키를 제외한 나머지 후보 키
외래 키(foregin key) : 기본 키를 참조하는 다른 테이블의 키
후보 키는 튜플들을 구별 할 수 있게 만들어주기 때문에, 이 필드 값에 대해서는 몇 가지 제약이 존재한다. 즉, 이 키를 참조하는 외부의 테이블이 이 값을 다룰 때는 신중해야 한다. 이것을 외래키 제약조건이라 하는데, 이 키를 참조하는 외부의 테이블 그 자체에서는 널(null)값을 가질 수 있지만, 널이 아닌 다른 값이라면 반드시 참조하려는 테이블에 원하는 값이 존재해야 한다. 즉, 외부 키로 선언되어 있다면 그 키를 포함하는 레코드를 삭제하는 경우, 자신의 테이블 외 참조하는 테이블에서도 해당 레코드가 같이 삭제되거나 삭제를 거부해야 한다. 이것은, 데이터의 무결성을 유지하기 위해서 반드시 필요한 부분이다.
Library/Database