관계 데이터 모델에서 연산은 원하는 데이터를 얻기 위해 릴레이션에 필요한 처리 요구를 수행하는 것으로, DB 시스템의 구성 요소 중 데이터 언어의 역할을 한다. 관계 데이터 모델의 연산을 간단히 관계 데이터 연산(relationship data operation)이라고도 한다. 대표적인 관계 데이터 연산으로 관계 대수와 관계 해석이 있다.

 관계 대수와 관계 해석은 원하는 데이터를 얻기 위한 처리 절차를 얼마나 자세히 기술하느냐에 큰 차이를 보인다. 관계 대수(relational algebra)는 원하는 결과를 얻기 위해 데이터의 치러 과정을 순서대로 기술하는 절차 언어(procedural language)다. 관계 해석(relational calculus)은 원하는 결과를 얻기 위해 처리를 원하는 데이터가 무엇인지만 기술하는 비절차 언어(noprocedural language)다.

 사용자 입장에서는 처리를 원하는 데이터가 무엇인지만 기술하는 비절차 언어가 편리하게 느껴질 수 있다. 하지만 데이터를 처리하는 기능과 처리를 요구하는 표현력에서 관계 대수와 관계 해석은 능력이 동등하다. 데이터에 대한 처리 요구를 일반적으로 질의(query)라 한다.

 새로운 데이터 언어가 제안되면 해당 데이터 언어의 유용성을 검증해야 하는데 검증의 기준 역할을 하는 것이 관계 대수와 관계 해석이다. 관계 대수나 관계 해석으로 기술할 수 있는 모든 질의를 새로 제안된 데이터 언어로 기술할 수 있으면 관계적으로 완전(relationally complete)하다고 하고, 이를 통해 해당 언어가 어느 정도 검증됐다고 판단한다.

 관계 데이터 모델에서 정의하고 있는 기본 제약 사항은 키와 관련한 무결성 제약조건이다. 무결성은 데이터에 결함이 없는 상태, 즉 데이터가 정확하고 유효하게 유지된 상태를 말한다. 무결성 제약 조건의 주요 목적은 DB에 저장된 데이터의 무결성을 보장하고, DB의 상태를 일관되게 유지하는 것이다. DB가 삽입, 삭제, 수정 연산으로 상태가 변하더라도 무결성 제약조건은 반드시 지켜져야 한다.

 보안이 권한이 없는 사용자로부터 데이터를 보호하는 것이라면, 무결성은 권한이 있는 사용자의 잘못된 요구에 의해 데이터가 부정확해지지 않도록 보호하는 것이다.

 관계 데이터 모델이 기본으로 포함하고 있는 무결성 제약조건에는 개체 무결성 제약조건과 참조 무결성 제약조건이 있다. DB의 상태를 일관성 있게 유지하기 위해서는 두 가지를 모두 만족시켜야 한다.

개체 무결성 제약조건

 개체 무결성 제약조건을 만족시키려면 새로운 튜플이 삽입되는 연산과 기존 튜플의 기본키 속성 값이 변경되는 연산이 발생할 때 기본키에 널 값이 포함되는 상황에서는 연산의 수행을 거부하면 된다. 이것은 일반 사용자가 직접 수행하기보다는 DB 관리 시스템이 자동으로 수행하므로 새로운 릴레이션을 생성할 때마다 기본키를 어떤 속성들로 구성할 것인지 DB 관리 시스템에 알려주면 된다.

참조 무결성 제약조건

 참조 무결성 제약조건을 만족시키려면 외래키가 참조 가능한 값만 가져야 하지만, 널 값을 가진다고 해서 참조 무결성 제약조건을 위반한 것으로 판단해서는 안 된다.

 참조되는 릴레이션에 새로운 튜플을 삽입하는 할 때 기본키로 지정된 속성의 값을 삽입해야 개체 무결성 제약조건을 만족한다. 또한 참조하는 릴레이션에 새로운 튜플을 삽입할 때 기본키의 속성 값으로 존재하지 않는 값을 삽입하면 참조 무결성 제약조건을 만족하지 못하게 된다. 따라서 참조하는 릴레이션에 새로운 튜플을 삽입하는 연산의 수행을 거부하면 된다.

 참조되는 릴레이션에 존재하는 튜플을 삭제하는 연산은 참조 무결성 제약조건을 위반하지 않는 경우에만 수행해야 한다. 연관된 튜플이 참조하는 릴레이션에 남아 있으면, 참조되는 릴레이션에서 해당 튜플의 삭제하는 연산은 수행하지 않거나 참조하는 릴레이션의 관련 튜플을 함께 삭제하여 참조 무결성 제약조건을 만족시켜야 한다. 그리고 참조하는 릴레이션의 속성 값을 널이나 기본 값으로 지정하는 방법도 사용할 수 있다. 반면, 참조하는 릴레이션에 존재하는 튜플을 삭제하는 것은 어떠한 제약조건도 위반하지 않는다.

관계 데이터 모델의 기본 용어

 관계 데이터 모델에서는 하나의 개체에 관한 데이터를 릴레이션(relation) 하나에 담아 DB에 저장한다.

속성

 릴레이션의 열을 속성 또는 애트리뷰트(attribute)라고 부른다. 각 속성은 서로 다른 이름을 이용해 구별한다. 릴레이션은 파일 관리 시스템에서의 파일, 속성은 해당 파일의 필드에 대응한다.

튜플

 릴레이션의 행을 튜플(tuple)이라 부른다. 각 튜플은 유저 한 명에 대한 실제 속성 값 6개를 모아놓은 것으로, 유저 개체의 인스턴스다. 튜플은 파일 관리 시스템 관점에서 해당 파일의 레코드에 대응한다.

도메인

 속성 하나가 가질 수 있는 모든 값의 집합을 해당 속성의 도메인(domain)이라 한다. 관계 데이터 모델에서는 속성 값으로 더는 분해할 수 없는 원자 값만 사용할 수 있으므로 도메인을 특정 속성이 가질 수 있는 모든 원자 값의 모임이라고도 한다.

 속성의 도메인을 정의해두면 사용자가 속성 값을 입력하거나 수정할 때 DB 시스템이 적합성을 판단하여 항상 올바른 값만 유지할 수 있다. 하지만 속성의 도메인을 정확히 정의하기 어려운 경우, 속성의 특성을 미리 고려하여 데이터 타입으로 정의한다.

 데이터 타입을 도메인, 변수를 속성으로 생각하면 이해하기 쉽다.

널 값

 릴레이션에 있는 특정 튜플의 속성 값을 모르거나, 적합한 값이 없는 경우에는 널(null)이라는 특별한 값을 사용할 수 있다. 숫자 0이나 공백 문자와는 다르다. 아직 값을 입력하지 않았거나, 결정되지 않은 등의 이유로 널 값을 표현한다.

차수

 하나의 릴레이션에서 속성의 전체 개수를 릴레이션의 차수(degree)라고 한다. 위 유저 릴레이션의 차수는 6이다. 모든 릴레이션은 최소 1 이상의 차수를 유지해야 한다. 또한 릴레이션의 차수는 자주 변하지 않는다는 정적인 특징이 있다.

카디널리티

 하나의 릴레이션에서 튜플의 전체 개수를 릴레이션의 카디널리티(cardinality)라고 한다. 위 유저 릴레이션의 카디널리티는 4다. 튜플이 없는 릴레이션이 존재할 수도 있다. 새로운 튜플이 삽입되거나 기존 튜플이 삭제될 수 있으므로 릴레이션의 카디널리티는 자주 변한다는 동적인 특징이 있다.

릴레이션과 데이터베이스의 구성

 관계 데이터 모델에서 릴레이션은 아래 그림과 같이 릴레이션 스키마와 릴레이션 인스턴스로 구성되어 있다.

릴레이션 스키마

 릴레이션 스키마(relation schema)는 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조다. 릴레이션 스키마는 DB 관리 시스템이 내부적으로 데이터 정의어를 이용해 정의하지만, 일반적으로는 다음과 같은 형태로 쉽게 표현한다.

 유저 릴레이션에서 릴레이션 스키마는 유저(유저아이디, 유저실명, 나이, 등급, 직업, 점수)이다. 릴레이션 스키마를 보면 릴레이션의 이름이 무엇이고, 어떤 속성들로 구성되어 있는지 전체 구조를 쉽게 파악할 수 있다. 릴레이션 스키마는 릴레이션 내포(relation intension)라고도 부른다.

릴레이션 인스턴스

 릴레이션 인스턴스(relation instance)는 어느 한 시점에 릴레이션에 존재하는 튜플들의 집합이다. 릴레이션 인스턴스에 포함된 튜플은 릴레이션 스키마에서 정의하는 각 속성에 대응하는 실제 값으로 구성되어 있다. 유저 릴레이션 구성의 예에서 4개의 튜플로 구성된 릴레이션 인스턴스를 확인할 수 있다. DB 관리 시스템이 내부적으로는 데이터 조작어를 이용해 릴레이션 인스턴스의 튜플을 검색하거나, 새로운 튜플 삽입과 기존 튜플 삭제 및 수정을 수행한다. 릴레이션 인스턴스는 간단히 릴레이션이라 부르기도 하고 릴레이션 외연(relation extension)이라고도 부른다.

 논리적 구조를 정의하는 릴레이션 스키마는 자주 변하지 않는다는 정적인 특징이 있는 반면, 릴레이션 인스턴스는 튜플의 삽입, 삭제, 수정이 자주 발생한다는 동적인 특징이 있다.

데이터베이스 스키마와 데이터베이스 인스턴스

 일반적으로 DB는 릴레이션 여러 개로 구성된다. DB의 전체 구조를 의미하는 DB 스키마는 DB를 구성하는 릴레이션들의 스키마를 모아놓은 것이다. 즉, 특정  DB 스키마를 설계한다는 것은 필요한 모든 릴레이션의 스키마를 모두 정의한다는 뜻이다. DB 인스턴스는 어느 한 시점에서 DB에 저장된 데이터 내용의 전체 집합을 의미한다. 즉, DB를 구성하는 모든 릴레이션의 인스턴스를 모아놓은 것이다.

릴레이션의 특성

 관계 데이터 모델의 릴레이션에는 네 가지 중요한 특성이 있다. 기본적으로 이 네 가지 특성을 만족해야 테이블이 릴레이션으로 인정받을 수 있다.

1. 튜플의 유일성 : 하나의 릴레이션에는 동일한 튜플이 존재할 수 없다.

 하나의 릴레이션에는 똑같은 튜플이 있으면 안 되고, 모든 튜플에는 다른 튜플과 구별되는 유일한 특성이 있어야 한다.

 관계 데이터 모델의 릴레이션에는 하나 또는 여러 개의 속석을 미리 선정해두고 이 속성 값을 튜플마다 다르게 저장하여 튜플의 유일성을 판단한다. 게임에 유저로 가입을 하려고 할 때, 다른 유저와 아이디가 같아 회원 가입에 실패하는 것이 아이디 속성의 값으로 유일성을 판단하는 경우다.

 이처럼 튜플을 유일하게 구별하기 위해 선정되는 속성(또는 속성들의 모임)을 키라고 부른다.

2. 튜플의 무순서 : 하나의 릴레이션에서 튜플 사이의 순서는 무의미하다.

 튜플의 순서가 바뀐다고 다른 릴레이션이 될 수 없고, 순서와 상관없이 튜플 내용이 같아야 같은 릴레이션이다. 릴레이션에는 튜플이 삽입 순서에 따라 저장되지만, 효율적인 처리를 위해 튜플의 순서를 임의로 바꾸기도 한다.

3. 속성의 무순서 : 하나의 릴레이션에서 속성 사이의 순서는 무의미하다.

 속성은 순서가 바뀌어도 다른 릴레이션이 될 수 없고, 순서와 상관없이 같은 속성들로 구성되어 있어야 같은 릴레이션이다. 속성 값은 릴레이션에서 위치가 아닌 속성의 이름으로 접근하므로 하나의 릴레이션에는 이름이 같은 속성이 존재할 수 없고, 이름도 속성의 의미가 명확히 드러나는 것으로 사용하는 것이 좋다.

4. 속성의 원자성 : 속성 값으로 원자 값만 사용할 수 있다.

 하나의 속성은 여러 개의 값, 즉 다중 값을 가질 수 없다. 물론 현실 세계의 데이터를 가져올 때, 특정 속성에 대한 다중 값이 존재할 수 있지만, 관계 데이터 모델은 이런 복잡한 개념을 배제하고 릴레이션을 단순한 구조로 정의하고자 하는 특징이 있어 다중 값을 허용하지 않는다.

키의 종류

 튜플을 유일하게 구별하기 위해 모든 속성을 이용하는 것보다 일부 속성만 이용하는 것이 효율성을 높일 수 있다. 릴레이션에 포함된 튜플들을 유일하게 구별해주는 역할은 속성 또는 속성들의 집한인 키가 담당한다. 키는 관계 데이터 모델에서 중요한 제약조건을 정의한다. 관계 데이터 모델에서는 슈퍼키, 후보키, 기본키, 대체키, 외래키의 다섯 가지로 분류할 수 있다.

슈퍼키

 슈퍼키는 유일성의 특성을 만족하는 속성 또는 속성들의 집합이다. 유일성은 키가 갖추어야 하는 기본 특성으로, 하나의 릴레이션에서 키로 지정된 속성 값은 튜플마다 달라야  한다는 의미다. 즉, 키 값이 같은 튜플은 존재할 수 없다. 또한 유일성을 만족하지 못하는 속성이라 할지라도, 유일성을 만족하는 속성과의 조합은 슈퍼키가 될 수 있다.

 슈퍼키 중에는 튜플 하나를 유일하게 구별하기 위해서 또는 2개의 튜플이 서로 다름을 판단하기 위해 불필요한 속성 값까지 확인하는 비효율적인 작업이 필요한 경우가 있다. 그래서 꼭 필요한 속성의 집합만으로 튜플을 유일하게 구별할 수 있도록 하는 또 다른 키의 개념이 필요한데, 이것이 다음으로 알아볼 후보키다.

후보키

 후보키는 유일성과 최소성을 만족하는 속성 또는 속성들의 집합이다. 최소성은 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성이다. 슈퍼키에서 최소성을 만족하는 키가 후보키가 된다.

 후보키가 되기 위해 만족해야 하는 유일성과 최소성의 특성은 새로운 튜플이 삽입되거나 기존 튜플의 속성 값이 바뀌어도 유지되어야 한다. 그리고 후보키를 선정할 때는 현재의 릴레이션 내용, 즉 릴레이션 인스턴스만 보고 유일성과 최소성을 판단해서는 안 된다. DB가 사용될 현실 세계의 환경까지 염두에 두고 속성의 본래 의미를 정확히 이해한 후 슈퍼키와 후보키를 선별해야 한다.

기본키

 릴레이션에서 튜플을 구별하기 위해 여러 개의 후보키를 모두 사용할 필요는 없다. DB 설계자나 관리자는 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택해야 하는데 이것이 기본키다. 만약 후보키가 1개만 존재하면 당연히 해당 후보키를 기본키로 선택해야 하겠지만 여러 개일 경우에는 DB 사용 환경을 고려하여 적합한 것을 기본키로 선택하면 된다. 선택한 기본키는 속성 이름에 밑줄을 그어 표현한다.

기본키를 선택할 때 고려하면 도움이 되는 기준

1. 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.

2. 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.

3. 단순한 후보키를 기본키로 선택한다.

대체키

 대체키는 기본키로 선택되지 못한 후보키들이다. 따라서 기본키로 선택되지 못한 속성 집합이 대체키가 된다.

외래키

 외래키는 어떤 릴레이션에 소속된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키다. 다시 말해 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합이 외래키다. 외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요하다.

 외래키의 개념과 필요성을 위해 인터넷 쇼핑몰을 위한 DB에서 고객 릴레이션과 주문 릴레이션의 관계를 생각해보자.

 위 그림에서 고객 릴레이션은 속성이 6개이고, 고객아이디 속성이 기본키다. 주문 릴레이션은 속성이 6개이고, 주문번호 속성이 기본키다. 여기서 주문 릴레이션의 주문고객 속성이 고객 릴레이션의 기본키인 고객아이디 속성을 참조하면 주문고객 속성을 외래키라고 한다. 일반적으로 외래키를 가진 릴레이션을 '참조하는 릴레이션'이라 하고, 기본키를 가진 릴레이션을 '참조되는 릴레이션'이라 한다.

 외래키가 되는 속성과 기본키가 되는 속성의 이름은 달라도 된다. 하지만 외래키 속성의 도메인과 참조되는 기본키 속성의 도메인은 반드시 같아야 한다. 도메인이 같아야 연관성 있는 튜플을 찾기 위한 비교 연산이 가능하기 때문이다.

 외래키가 참조되는 릴레이션의 기본키가 아닌 다른 속성을 참조하면 튜플을 유일하게 구별하기 어렵기 때문에 참조되는 릴레이션에서 관련 있는 튜플을 검색하지 못할 수 있다. 따라서 외래키는 반드시 다른 릴레이션의 기본키를 참조해야 하며 외래키의 도메인은 참조되는 기본키와 같게 정의되어야 한다.

 하나의 릴레이션에는 외래키가 여러 개 존재할 수도 있다. 그리고 외래키를 기본키로 사용할 수도 있고 외래키를 포함하여 기본키를 구성할 수도 있다.

 외래키가 다른 릴레이션의 기본키를 참조하는 키라고 정의했지만 반드시 다른 릴레이션을 참조할 필요는 없다. 참조하는 릴레이션과 참조되는 릴레이션이 같을 수도 있다. 즉, 외래키 자신이 속한 릴레이션의 기본키를 참조하도록 외래키를 정의할 수도 있다.

 외래키는 기본키를 참조하지만 기본키가 아니기 때문에 널 값을 가질 수 있다. 또한 다른 튜플과 같은 속성 값을 가질 수 있다.

논리적 데이터 모델의 개념과 특성

 개체-관계 모델은 현실 세계를 사람들의 머릿속에 그릴 수 있는 개념적인 구조로 모델링하는데 사용하므로 어떤 DB 관리 시스템으로 DB를 구축하든 상관이 없다. 하지만 E-R 다이어그램으로 표현된 개념적인 구조를 DB에 표현하는 형태를 결정하는 논리적 데이터 모델링에서는 DB 관리 시스템 종류가 중요하다.

 선택한 DB 관리 시스템에 따라 사용자 입장에서 E-R 다이어그램으로 표현된 개념적 구조를 DB에 저장한다고 할 때 저장 형태로 표현한 논리적인 구조를 논리적 데이터 모델이라 한다. 결국 논리적 데이터 모델은 논리적 데이터 모델링의 결과물이고, 사용자가 생각하는 DB의 모습 또는 구조다. 그리고 논리적 데이터 모델로 표현된 DB의 논리적 구조가 바로 DB 스키마다. 논리적 구조는 사용하는 DB 관리 시스템에 따라 달라진다.

 DB에 있는 데이터들 간의 관계를 표현하는 방법에 따라 다양한 논리적 데이터 모델이 존재한다. 일반적으로 많이 사용되는 논리적 데이터 모델은 관계 데이터 모델로, DB의 논리적 구조가 2차원 테이블 형태다. 관계 데이터 모델이 제안되기 전에는 계층 데이터 모델과 네트워크 데이터 모델이 주로 사용되었다.

계층 데이터 모델

 계층 데이터 모델(hierarchical data model)은 DB의 논리적 구조가 트리(tree) 형태다. 개체는 사각형으로 나타내고 개체들 간의 관계는 링크(연결선)로 나타내는데, 링크는 일대다 관계만 표현할 수 있다. 그리고 계층 데이터 모델은 두 개체 사이에 관계를 하나만 정의할 수 있어 관계에 이름을 붙여 구별할 필요가 없다.

 계층 데이터 모델에서는 다대다 관계를 직접 표현할 수 없어 별도의 개체를 추가로 생성하여 이를 표현한다. 위 그림에서 개체2와 개체3의 다대다 관계를 나타내기 위해 개체4를 추가로 만들어 표현하고 있다. 즉, 개체2와 개체3의 일대다 관계, 개체3과 개체4의 일대다 관계로 개체2와 개체3의 다대다 관계를 표현한다.

 계층 데이터의 모델은 트리 구조로 표현되기 때문에 출판사 개체처럼 루트 역할을 하는 개체가 존재하고 사이클이 존재하지 않는다. 그리고 일대다 관계를 맺는 개체들 사이에는 상하 관계가 성립한다. 상위에 있는 개체를 부모 개체, 하위에 있는 개체를 자식 개체라 하고, 이들 사이의 일대다 관계를 부모 자식 관계라 한다. 계층 데이터 모델에서는 트리 구조의 특성상 부모 개체 하나가 자식 개체를 여러 개 가질 수 있지만, 모든 자식 개체는 부모 개체를 하나만 가질 수 있다는 제약 사항이 존재한다.

 계층 데이터 모델은 개체 사이의 관계를 정의할 때 여러 제약이 존재하기 때문에 개념적 구조를 논리적 구조로 자연스럽게 모델링하기 어려워 구조가 복잡해질 수 있다. 그리고 데이터의 삽입, 삭제, 수정 등의 연산이나, 원하는 데이터를 검색하기가 쉽지 않다는 단점이 있다.

네트워크 데이터 모델

 네트워크 데이터 모델(network data model)은 DB의 논리적 구조가 그래프 또는 네트워크 형태다. 개체는 사각형으로 나타내고 개체들 간의 관계는 화살표로 나타내는데, 화살표는 일대다 관계만 표현할 수 있다. 그래서 네트워크 데이터 모델은 계층 데이터 모델과 달리 두 개체 간의 관계를 여러 번 정의할 수 있어 관계를 이름으로 구별하고 화살표로 표현한다.

 네트워크 데이터 모델에서도 일대다 관계만 직접 표현할 수 있으므로 두 개체 사이의 일대다 관계들을 이용해 다대다 관계를 표현한다. 위 그림에서 개체1과 개체2가 다대다의 관계를 맺고 있어 관계1과 관계2라는 두 개의 일대다 관계로 이를 표현했다. 네트워크 데이터 모델에서는 일대다 관계의 개체들을 각각 오너(owner)와 멤버(member)라 부르고, 이들 사이의 관계를 오너-멤버 관계(owner-member relationship)라 부른다.

 네트워크 데이터 모델은 같은 개체들 사이의 관계를 두 개 이상 표현할 수 있어 계층 데이터 모델보다 개념적 구조를 논리적 구조로 좀 더 자연스럽게 모델링할 수 있다. 그러나 계층 데이터 모델보다 구조가 훨씬 복잡해질 수 있어, 데이터의 삽입, 삭제, 수정 같은 연산과 데이터 검색이 계층 데이터 모델보다 더 어려워지는 문제가 발생한다.

 최근에는 객체의 개념을 도입한 객체지향 데이터 모델(object-oriented data model) 및 객체지향 데이터 모델과 관계 데이터 모델의 특성을 모두 수용하는 개체관계 데이터 모델(object-relational data model)이 사용되기도 한다. 하지만 누구나 쉽게 이해할 수 있는 데이터 구조와 데이터의 검색, 삽입, 삭제, 수정 등의 연산을 제공하는 관계 데이터 모델이 꾸준하게 인기가 높다.

 개체(entity)와 개체 간의 관계(relationship)을 이용해 현실 세계를 개념적 구조로 표현한 방법이다. 현실 세계를 개체-관계 모델을 이용해 개념적으로 모델링하여 그림으로 표현한 것을 개체-관계 다이어그램(Entity-Relationship Diagram) 또는 E-R 다이어그램이라 한다.

개체

 개체는 저장할 만한 가치가 있는 중요 데이터를 가지고 있는 사람이나 사물 등이며, 개념적 모델링을 하는 데 가장 중요한 요소다.

 개체는 사람과 사물처럼 물리적으로 존재하는 것만을 의미하지는 않는다. 개념이나 사건처럼 개념적으로만 존재하는 것도 개체가 될 수 있다.

 개체는 다른 개체와 구별되는 이름을 가지고 있고, 각 개체만의 고유한 특성이나 상태, 즉 속성을 하나 이상 가지고 있다. 개체를 고유의 이름과 속성들로 정의한 것을 개체 타입(entity type)이라 한다.

 개체를 구성하고 있는 속성이 실제 값을 가짐으로써 실체화된 개체를 개체 인스턴스(enitity instance) 또는 개체 어커런스(entity occurrence)라 한다. 객체 타입을 구성하는 각 속성에 구체적인 값을 가지는 개체 인스턴스가 여러 개 존재할 수 있다. 특정 개체 타입에 대한 개체 인스턴스들을 모아 놓은 것을 개체 집합(entity set)이라 한다. DB에서 실제로 저장하고 관리하는 것이 이 개체 인스턴스들의 모임인 개체 집합이라 할 수 있다.

 개체와 속성은 파일 구조에서 레코드와 필드 용어에 대응된다. 그리고 개체 타입은 레코드 타입에, 개체 인스턴스는 레코드 인스턴스에 대응된다.

 E-R 다이어그램에서는 개체를 사각형으로 표현하고 사각형 안에 개체의 이름을 표기한다.

속성

 속성(attribute)은 개체가 가지고 있는 고유의 특성이다. 속성은 그 자체만으로는 의미가 없지만 관련 있는 속성들을 모아 개체를 구성하면 하나의 중요한 의미를 표현할 수 있다. 속성은 일반적으로 의미 있는 데이터의 가장 작은 논리적 단위로 인식된다. E-R 다이어그램에서 속성은 타원으로 표현하고, 타원 안에 속성의 이름을 표기한다.

 속성은 다음과 같이 다양한 기준으로 분류할 수 있다.

단일 값 속성과 다중 값 속성

 특정 개체를 구성하는 속성 값이 하나면 단일 값 속성(single-valued attribute)으로 분류한다. 이와 달리 속성이 값을 여러 개 가질 수 있으면 다중 값 속성(multi-valued attribute)으로 분류한다. 다중값 속성은 이중 타원으로 표현한다.

단순 속성과 복합 속성

 단순 속성(simple attrubite)은 값의 의미가 의미를 더는 분해할 수 없는 속성이다. 반면, 복합 속성(composite attribute)은 의미를 분해할 수 있어 값이 여러 개의 의미를 포함한다. 복합 속성은 단순 속성이 여러 개 모여 만들어진 속성으로 볼 수 있다. 복합 속성은 E-R 다이어그램에서 속성 타원에서 가지를 뻗어 작은 타원으로 표현한다.

유도 속성

값이 별도로 저장되는 것이 아니라 기존의 다른 속성 값에서 유도되어 결정되는 속성을 유도 속성(derived attribute)으로 분류한다. 그리고 유도 속성을 결정하는 속성들을 저장 속성(stored attribute)이라고 한다. 실제로 값을 저장하고 있는 것은 저장 속성이고 유도 속성은 필요할 때마다 계산되므로 값을 따로 저장할 필요가 없다. 유도 속성은 E-R 다이어그램에서 점선 타원으로 표현한다.

널 속성

널(null) 값은 DB에서 여러 가지로 중요한 의미를 지니고 있다. 널 값은 아직 결정되지 않았거나 모르는 값(unknown value)을 의미한다. 또는 존재하지 않는 값의 경우도 널 값이라 한다. 하지만 공백(blank)이나 0(zero)과는 다르다. 널 값이 허용되는 속성을 널 속성(null attribute)이라 한다.

키 속성

 키 속성(key attribute)은 개체를 구성하는 속성들 중에서 특별한 역할을 한다. 모든 개체 인스턴스의 키 속성 값이 다르므로 키 속성은 개체 집합에 존재하는 각 개체 인스턴스들을 식별하는 데 사용한다. 키 속성은 간단히 키라고도 한다.

 어떤 경우에는 키를 둘 이상의 속성들로 구성하기도 한다.

 개체 타입을 정의할 때 중요한 제약조건은 키 속성의 값이 개체 인스턴스마다 달라서 이 값으로 개체 인스턴스를 식별할 수 있어야 한다는 것이다. 만약 키 속성으로 적합한 속성이 여러 개면 이 중 하나를 키로 사용하면 된다. 키 속성은 E-R 다이어그램에서 밑줄을 그어 표현한다.

관계

관계(relationship)는 개체와 개체가 맺고 있는 의미 있는 연관성으로, 개체-관계 모델의 중요한 요소다. 관계는 개체 집합들 사이의 대응 관계(correspondence), 즉 매핑(mapping)을 의미한다. 업무 처리에 대한 요구 사항을 개체들을 이용해 하나의 문장으로 만들었을 때 동시에 해당하는 것이 관계다. 관계를 통해서만 개체들 간의 연관성을 이용한 업무를 처리할 수 있다.

 관계를 여러 개체(타입) 사이에서 정의되는 관계 타입(relationship type)과 실제 속성 값으로 구성 되어 있는 특정 개체 인스턴스들 간에 맺어진 실제 관계인 인스턴스로 구분하여 표현하기도 한다.

 관계도 개체처럼 속성을 가질 수 있다. 관계를 맺음으로써 발생하는 중요한 데이터들이 관계의 속성이 된다. 관계는 E-R 다이어그램에서 마름모로 표현한다.

관계의 유형

 관계도 다양한 기준에 따라 분류할 수 있다. 먼저 관계에 참여하는 개체 타입의 수를 기준으로 이항 단계, 삼항 관계, 순환 관계 등으로 나눌 수 있다. 이항 관계는 개체 타입 두 개가 맺는 관계이고, 삼항 관계는 개체 타입 세 개가 맺는 관계다. 그리고 순환 관계는 개체 타입 하나가 자기 자신과 맺는 관계다.

 8장, 데이터베이스 설계 과정에서 중요하게 활용되는 관계의 분류 기준은 매핑 원소의 수, 즉 매핑 카디널리티(mapping cardinality)다. 매핑 카디널리티는 관계를 맺는 두 개체 집합에서, 각 개체 인스턴스가 연관성을 맺고 있는 상대 개체 집합의 인스턴스 개수를 의미한다. 관계는 매핑 카디널리티를 기준으로 일대일(1:1), 일대다(1:n), 다대다(n:n)라는 세 가지 유형으로 분류할 수 있다.

1. 일대일 관계

 개체 A의 각 개체 인스턴스가 개체 B의 개체 인스턴스 하나와 관계를 맺을 수 있고, 개체 B의 각 개체 인스턴스도 개체 A의 개체 인스턴스 하나와 관계를 맺을 수 있다.

2. 일대다 관계

 개체 A의 각 개체 인스턴스는 개체 B의 개체 인스턴스 여러 개와 관계를 맺을 수 있지만, 개체 B의 각 개체 인스턴스는 개체 A의 개체 인스턴스 하나와만 관계를 맺을 수 있다.

3. 다대다 관계

 개체 A의 각 개체 인스턴스가 개체 B의 개체 인스턴스 여러 개와 관계를 맺을 수 있고, 개체 B의 각 개체 인스턴스도 가체 A의 각 개체 인스턴스 여러 개와 관계를 맺을 수 있다.

관계의 참여 특성

 가체 A와 B 사이의 관계에서, 개체 A의 모든 개체 인스턴스가 관계에 반드시 참여해야 한다면 개체 A가 관계에 '필수적 참여한다' 또는 '전체 참여한다'라고 한다. 그리고 개체 A의 개체 인스턴스 중 일부만 관계에 참여해도 되면 개체 A가 관계에 '선택적 참여한다' 또는 '부분 참여한다'라고 한다. 개체가 관계에 선택 참여하는지, 필수 참여하는지는 DB 설계 과정에서 중요하게 고려해야 되는 사항이다. 그리고 이는 DB를 구축한 후에 새로운 개체 인스턴스를 삽입하거나, 기존 개체 인스턴스를 삭제, 변경할 때 제약 사항으로도 활용된다. 필수적 참여 관계는 E-R 다이어그램에서 이중선으로 표현한다.

관계의 종속성

두 개체가 관계에 대해 종속적인 특성을 가지는 경우도 있다. 개체 B가 독자적으로는 존재할 수 없고 다른 개체 A에 종속되면, 이는 개체 A가 존재해야 개체 B가 존재할 수 있고 개체 A가 삭제되면 개체 B도 함께 삭제되어야 함을 의미한다. 이러한 종속을 특별히 존재 종속(existence dependence)이라 한다. 이때 다른 개체의 존재 여부에 의존적인 개체 B를 약한 개체(weak entity)라 하고 다른 개체의 존재 여부를 결정하는 개체 A를 강한 개체(strong entity)라 한다. 두 개체가 종속적인 관계를 맺고 있어 약한 개체를 종속 개체, 강한 개체를 오너 개체로 부르기도 한다.

 강한 개체와 약한 개체는 일반적으로 일대다의 관계이며, 약한 개체는 강한 개체와의 관계에 필수적으로 참여한다는 특징이 있다. 약한 개체는 자신이 지닌 속성만으로는 식별이 어려워 일반적으로 강한 개체의 키를 포함하여 키를 구성한다. 약한 개체의 속성이 다른 개체와 중복될 수도 있기 때문에 강한 개체의 키를 포함하기도 한다. 이와 같이 약한 개체를 구별해주는 속성을 구별자(delimiter) 또는 부분키(partial key)라고 한다. 약한 개체는 이중 사각형으로 표현하고 약한 개체가 강한 개체와 맺는 관계는 이중 마름모로 표현한다.

E-R 다이어그램

 E-R 다이어그램은 개체-관계 모델을 이용해 현실 세계를 개념적으로 모델리한 결과물을 그림으로 표현한 것이다. 개체-관계 모델을 이용해 현실 세계로부터 개체, 속성, 개체 간의 관계를 찾아내 그림으로 표현하면 글로 작성하는 것보다 훨씬 더 이해하기 쉽기 때문에 E-R 다이어그램을 많이 선호한다.

 E-R 다이어그램은 기본적으로 개체를 표현하는 사각형, 개체 간의 관계를 표현하는 마름모, 개체나 관계의 속성을 표현하는 타원, 각 요소를 연결하는 링크(연결선)로 구성된다. 그리고 일대일, 일대다, 다대다 관계를 레이블로 표기한다.

 위 그림은 E-R 다이어그램에 사용 되는 요소들을 사용하여 만든 임의의 개체-관계 다이어그램이다.

 현실 세계에 존재하는 데이터를 컴퓨터 세계의 DB로 옮기는 변환 과정을 데이터 모델링(data modeling)이라 한다. 하지만 현실 세계의 데이터를 컴퓨터 세계에 옮기는 작업은 쉽지 않다. 따라서 현실 세계의 어떤 데이터 A에 대해 누가 들어도 머릿속에서 A를 떠올릴 수 있는 데이터를 찾아야 한다. 이런 작업을 추상화(abstraction)라고 한다. 추상화 과정을 통해 찾아넨 데이터를 실제 A 대신 DB에 저장해야 되는데, 이때 DB에 저장하는 구조를 결정할 필요가 있다.

 이를 총 3가지의 단계로 나누는데, 현실 세계 - 개념 세계 - 컴퓨터 세계로 나누어 진행한다. 현실 세계에서 A에 대한 중요 데이터를 추출하여 개념 세계로 옮기는 작업을 데이터 모델릴 과정 중에서도 개념적 모델링(conceptual modeling)이라 한다. 그리고 개념 세계의 데이터를 DB에 저정할 구조를 결정하고 이 구조로 표현하는 작업을 논리적 모델링(logical modeling)이라 한다. 일반적으로 두 모델링을 명확히 구분하지는 않고 합쳐서 데이터 모델링이라 부른다.

 하지만 현실 세계의 데이터를 개념 세계로, 컴퓨터 세계로 옮기는 작업을 결코 쉽지 않다. 이러한 데이터 모델링을 쉽게 할 수 있도록 도와주는 도구가 바로 데이터 모델(data model)이다. 이는 또 개념적 데이터 모델과 논리적 데이터 모델로 나뉜다. 개념적 데이터 모델은 사람의 머리로 이해할 수 있도록 현실 세계를 개념적 데이터 모델링하여 DB의 개념적 구조로 표현하는 도구다. 논리적 데이터 모델은 개념적 구조를 논리적 데이터 모델링하여 DB의 논리적 구조로 표현하는 도구다.

 일반적으로 데이터 모델은 데이터 구조(data structure), 연산(operation), 제약조건(constraint)으로 구성된다.

 보통 데이터 구조는 자주 변하지 않고 정적이라는 특징이 있다. 연산은 데이터 구조에 따라 개념 세계나 컴퓨터 세계에서 실제로 표현된 값들을 처리하는 작업으로, 값이 연산에 의해 계속 변경될 수 있으므로 동적이라는 특징이 있다. 마지막으로 제약조건은 구조적 측면의 제약 사항과 연산을 적용하는 경우 허용할 수 있는 의미적 측면의 제약 사항이 있다.

 데이터 모델링은 데이터에 대한 요구 사항을 잘 반영할 수 있도록 하는 설계도를 그리는 과정이라고 볼 수 있다. 그리고 데이터 모델은 이 설계도를 그릴 때 사용하는 방법이나 도구를 말한다. 보통 이 두가지를 통틀어 DB 설계라고 한다. 데이터 모델링 과정을 통해 논리적 구조가 결정되면, 컴퓨터 저장 장치에 실제로 저장되는 형태를 의미하는 물리적 구조로 변환하는 작업을 통해 현실 세계의 데이터를 컴퓨터 세계의 데이터로 저장한다.

 개념적 데이터 모델링과 논리적 데이터 모델링 작업을 지원하는 다양한 데이터 모델이 존재한다. 개념적 데이터 모델 중 대표적으로 많이 사용되는 것이 개체-관계 모델(E-R Model : Entity-Relationship Model)이다. 논리적 데이터 모델로는 관계 데이터 모델(relational data model)이 가장 많이 사용된다.

 DB를 관리하고 사용자의 데이터 처리 요구를 수행하는 DB 관리 시스템은 DB 시스템의 주요 구성 요소다. 사용자와 DB 사이에 위치하며, 기능에 따라 크게 질의 처리기와 저장 데이터 관리자로 구분할 수 있다.

질의 처리기

 질의 처리기(query processor)는 사용자의 데이터 처리 요구를 해석하여 처리하는 역할을 담당하고, 다음의 주요 구성 요소들을 포함한다.

1. DDL 컴파일러 : 데이터 정의어로 작성된 스키마의 정의를 해석한다. 저장 데이터 관리자의 도움을 받아 새로운 DB를 구축하고, 스키마의 정의를 데이터 사전에 저장한다. 데이터 정의어로 작성된 기존 스키마의 삭제나 수정 요청도 처리하여, 변경된 내용을 데이터 사전에 적용한다.

2. DML 프리 컴파일러 : 응용 프로그램에 삽입된 데이터 조작어를 추출하여 DML 컴파일러에 전달한다. 단, 데이터 조작어와 관련 없는 나머지 코드들은 해당 언어의 컴파일러에 보내진다.

3. DML 컴파일러 : 데이터 조작어로 작성된 데이터의 처리(삽입, 삭제, 수정, 검색) 요구를 분석하여 런타임 DB 처리기가 이해할 수 있도록 해석한다.

4. 런타임 DB 처리기 : 저장 데이터 관리자를 통해 DB에 접근하여, DML 컴파일러로부터 전달받은 데이터 처리 요구를 DB에서 실제로 실행한다.

5. 트랜잭션 관리자 : DB에 접근하는 과정에서 사용자의 접근 권한이 유효한지를 검사하고, DB 무결성을 유지하기 위한 제약조건 위반 여부를 확인한다. 회복이나 병행 수행과 관련된 작업도 담당한다.

저장 데이터 관리자

 저장 데이터 관리자(stored data manager)는 디스크에 저장된 DB와 데이터 사전을 관리하고, 여기에 실제로 접근하는 역할을 담당한다. 그런데 디스크에 저장된 데이터에 접근하는 것은 운영체제의 기본 기능이므로 저장 데이터 관리자는 운영체제의 도움을 받아 DB에 대한 접근을 수행한다.

 DB에서는 사용자를 대신해 DB를 구축하고 활용 및 관리하는 DB 관리 시스템에 부탁할 때 사용하는 언어가 있다. 이것이 바로 데이터 언어(data language)다.

 데이터 언어에는 상황에 따른 용법이 있다. 데이터 언어는 DB 관리 시스템의 정의, 조작, 제어 기능을 이용하기 위한 수단이기 때문에 사용 목적에 따라 데이터 정의어, 데이터 조작어, 데이터 제어어로 나눈다. 이는 하나의 데이터 언어를 기능에 따라 내부적으로 구분 짓는 것일 뿐 독립적으로 존재하는 언어들은 아니다.

데이터 정의어

 데이터 정의어(DDL : Data Definition Language)는 새로운 DB를 구축하기 위해 스키마를 정의하거나 기존 스키마의 정의를 삭제 또는 수정하기 위해 사용하는 데이터 언어다. 즉, 새로 만들려는 DB의 스키마를 설명하거나 이미 정의된 스키마의 구조나 제약조건 등을 변경 또는 삭제하고 싶어 이를 DB 관리 시스템에 알릴 때 사용한다. 데이터 정의어로 정의된 스키마는 데이터 사전에 저장되고, 삭제나 수정이 발생하면 이 내용도 데이터 사전에 반영된다. 데이터 사전에 저장된 스키마 정보는 사용자나 DB 관리 시스템이 필요할 때 참조할 수 있다.

데이터 조작어

 데이터 조작어(DML : Data Mainpulation Language)는 사용자가 데이터의 삽입, 삭제, 수정, 검색 등의 처리를 DB 관리 시스템에 요구하기 위해 사용하는 데이터 언어다. 데이터 정의어를 이용해 스키마를 정의하면 스키마에 따라 조직에 필요한 실제 데이터 값(인스턴스)이 저장되는데, 사용자가 실제 데이터 값을 활용하기 위해 사용하는 것이 데이터 조작어다. 데이터 조작어는 설명 방식에 따라 절차적 데이터 조작어와 비절차적 데이터 조작어로 나눈다.

절차적 데이터 조작어

 절차적 데이터 조작어(procedural DML)는 사용자가 어떤 데이터를 원하고 해당 데이터를 얻으려면 어떻게 처리해야 하는지를 설명한다.

비절차적 데이터 조작어

 비절차적 데이터 조작어(nonprocedural DML)는 사용자가 어떤 데이터를 원하는지만 설명한다. 즉, 해당 데이터를 얻으려면 어떻게 처리해야 하는지는 DB 관리 시스템에 맡긴다. 비절차적 데이터 조작어는 사용자가 어떤 데이터를 원하는지만 DB 관리 시스템에 선언하는 방식이기 때문에 선언적 언어(declarative language)라고도 한다.

데이터 제어어

 데이터 제어어(DCL : Data Control Language)는 DB에 저장된 데이터를 여러 사용자가 무결성과 일관성을 유지하며 문제없이 공유할 수 있도록, 내부적으로 필요한 규칙이나 기법을 정의하는 데 사용하는 데이터 언어다.

 데이터 제어어를 이용해 규칙이나 기법을 정의하는 이유는 다음과 같은 특성을 보장하기 위해서다.

1. DB에 정확하고 유효한 데이터만 유지하는 "무결성"

2. 허가받지 않는 사용자가 데이터에 접근하는 것을 차단하거나, 허가된 사용자가 접근 권한이 있는 데이터에만 접근할 수 있게 하는 "보안"

3. 장애가 발생해도 데이터의 일관성을 유지하는 "회복"

4. 여러 사용자가 같은 데이터에 동시에 접근하여 처리할 수 있게 하는 "동시성"

 DB 시스템을 구성하는 또 하나의 중요 요소가 사용자다. 사용자(user)는 DB를 이용하기 위해 접근하는 모든 사람을 의미한다. DB를 이용하는 사용자는 매우 다양한데, 이용 목적에 따라 크게 DB 관리자, 최종 사용자, 응용 프로그래머로 나눌 수 있다.

데이터베이스 관리자

 데이터베이스 관리자(DBA : DataBase Administrator)는 DB 시스템을 운영, 관리한다. DB를 직접 활용하기보다는 사용자를 위해 DB를 설계 및 구축하고, 제대로 서비스할 수 있도록 DB를 제어한다. 또한 DB 관리자는 데이터 정의어와 데이터 제어어를 이용해 DB에 접근한다.

DB 관리자의 주요 업무는 다음과 같다.

1. DB의 구성 요소를 선정한다.

2. DB의 스키마를 정의한다.

3. 물리적인 저장 구조와 접근 방법을 결정한다.

4. 무결성 유지를 위한 제약조건을 정의한다.

5. 보안 및 접근 권한에 대한 정책을 결정한다.

6. 백업 및 회복 기법을 정의한다.

7. 시스템 DB를 관리한다.

8. 시스템 성능 감시 및 성능을 분석한다.

9. 변화된 상황에 맞게 DB를 재구성 한다.

최종 사용자

 데이터를 조작(삽입, 삭제, 수정, 검색)하기 위해 DB에 접근하는 사람들을 일반 사용자 또는 최종 사용자(end user)라 한다. 최종 사용자는 캐주얼 사용자(casual end user)와 초보 사용자(native end user)로 구분할 수 있다.

 캐주얼 사용자는 DB에 대한 이론적 지식이 있으며, 주로 데이터 조작어를 이용해 원하는 데이터와 데이터에 대한 처리를 DB 관리 시스템에 직접 설명한다. 초보 사용자는 DB를 초보 수준으로 이용할 수 있어, 데이터 조작어로 자신의 요구를 직접 표현하기보다는 메뉴나 GUI(Graphic User Interface) 형태의 응용 프로그램을 통해 DB를 사용한다.

응용 프로그래머

 응용 프로그래머(application programmer)는 C 언어, 자바 등과 같은 프로그래밍 언어로 응용 프로그램을 작성할 때 DB에 접근하는 데이터 조작어를 삽입하는 사용자다. 데이터 정의어를 삽입할 수도 있지만 주로 데이터 조작어를 삽입한다.

 최종 사용자는 응용 프로그래머가 작성한 응용 프로그램을 이용해 DB에 접근할 수 있다. 도서 위치를 검색하거나 고객의 구매 요청을 처리하기 위해 서점 직원에게 제공하는 응용 프로그램이 좋은 예다.

스키마

 DB에 저장되는 데이터 구조와 제약 조건을 정의한 것을 스키마(schema)라고 한다. 아래 그림은 스키마를 그림으로 간략히 표현한 것이다. 고객과 관련된 데이터인 고객번호, 이름, 나이, 주소를 저장한다고 가정한다. 고객번호는 정수로, 이름은 최대 10자의 문자열로, 나이는 정수로, 주소는 최대 20자의 문자열만 허용하기로 했다면 이 모든 정해진 내용이 스키마다. 그리고 정의된 스키마에 따라 DB에 실제로 저장된 값이 인스턴스(instance)다. 스키마는 한 번 정의되면 자주 변경되지 않지만, 인스턴스는 계속 변하는 특성을 가지고 있다. 이는 한 번 지어진 집의 구조는 잘 바뀌지 않지만, 이사 등을 통해 사는 사람들이 계속 바뀌는 것과 같다.

3단계 데이터베이스 구조

 3단계 데이터베이스 구조의 개념

 3단계 데이터베이스 구조는 하나의 DB를 세 단계로 나누어 이해한다. 즉, 개별 사용자 관점에서 바라보는 외부 단계(external level), 조직 전체의 관점에서 바라보는 개념 단계(conceptual level), 물리적인 저장 장치의 관점에서 바라보는 내부 단계(internal level)로 나눈다. DB 하나를 세 단계로 나누고, 각 단계별로 다른 추상화(abstraction)를 제공하면 DB를 효과적으로 관리할 수 있다. 일반적으로 내부 단계에서 외부 단계로 갈수록 추상화 레벨이 높아진다. 이 구조를 통해, 모든 데이터의 저장, 유지와 관련된 복잡한 내용을 숨기고 필요한 데이터만 단순화한 외부 단계의 관점을 일반 사용자들에게 제공할 수 있다.

 3단계 데이터베이스 구조의 개념을 아파트의 예를 들어 알아보자.

 내부 단계는 건설 업체 관점으로 보고, 개념 단계는 관리인 관점으로 보고, 외부 단계는 집주인 관점으로 본다. 각 세대의 주민들은 자기 집에만 관심을 두지 다른 집까지는 알 필요가 없다. 이렇게 집주인의 관점에서 아파트를 바라보는 것이 외부 단계이다.

 이와 달리 아파트 관리인은 어느 한 집에만 관심을 두면 안 된다. 아파트를 문제없이 관리하려면 아파트 전체를 잘 알고 있어야 하는데, 이처럼 관리인 관점에서 전체 아파트를 바라보는 것이 개념 단계이다.

 하지만 아파트 관리인도 아파트 뼈대, 시멘트를 얼마나 사용했는지 등은 잘 모른다. 이것은 아파트 건설 업체의 관심사다. 아파트를 건설한 업체 관점에서 전체 아파트를 바라보는 것이 바로 내부 단계이다.

외부 단계

 외부 단계에서는 개별 사용자 관점에서 DB를 이해하고 표현한다. 하나의 DB를 조직 내의 사용자들이 함께 사용하지만 각 사용자가 DB 전체에 관심이 있는 것은 아니다. 사용자마다 업무 내용과 사용 목적이 달라 필요한 데이터 내용이 다를 수 있다.

 외부 단계에서는 개별 사용자가 DB를 어떻게 보는가를 표현하므로 사용자마다 생각하는 DB의 구조가 다르다. 이처럼 외부 단계에서 사용자에게 필요한 DB를 정의한 것을 외부 스키마(external schema)라 한다.

 DB 하나에는 외부 스키마가 여러 개 존재할 수 있고, 외부 스키마 하나를 사용 목적이 같은 사용자들이 공유할 수 있다. 외부 스키마는 전체 DB 중 사용자가 관심을 가지는 일부분으로 볼 수 있어 서브 스키마(ub schema)라고도 한다.

개념 단계

 개념 단계는 DB를 이용하는 사용자들의 관점을 통합하여, DB를 조직 전체의 관점에서 이해하고 표현한다. 이 단계에서는 모든 사용자에게 필요한 데이터를 통합하여 전체 DB의 논리적 구조를 정의한다. 그리고 이를 개념 스키마(conceptual schema)라 한다.

 개념 단계는 모든 개별 사용자가 생각하는 DB의 모습을 하나로 합친 형태이다. 이는 전체 DB에 어떤 데이터가 저장되는지, 데이터들 간에는 어떤 관계가 존재하고 어떤 제약조건이 있는지에 대한 정의뿐만 아니라, 데이터에 대한 보안 정책이나 접근 권한에 대한 정의도 포함한다. 하지만 데이터를 물리적으로 저장하는 방법이나 데이터 저장 장치와는 독립적이다.

 DB 하나에는 하나의 개념 스키마가 존재하고, 각 사용자는 개념 스키마의 일부분을 사용한다. 즉, 외부 스키마는 개념 스키마를 기초로 하여 사용자의 이용 목적에 맞게 만들어진다. 일반적으로 스키마라고 하면 개념 스키마를 의미한다.

내부 단계

 내부 단계에서는 DB를 디스크나 테이프 같은 저장 장치의 관점에서 이해하고 표현한다. 즉, 내부 단계에서는 전체 DB가 저장 장치에 실제로 저장되는 방법을 정의하며 이를 내부 스키마(internal schema)라고 한다.

 DB는 저장 장치에 파일 형태로 저장되는데 내부 스키마는 파일에 저장하는 레코드의 구조, 레코드를 구성하는 필드 크기, 인덱스를 이용한 레코드 접근 경로 등을 정의한다. 내부 스키마는 DB의 개념 스키마에 대한 물리적인 저장 구조를 표현하므로 하나의 DB에 하나만 존재한다.

 다음 그림은 쇼핑몰의 DB를 3단계 DB 구조로 표현한 예이다.

 외부 단계에는 A팀과 B팀 사용자가 존재한다. 두 사용자는 자신의 팀에 필요한 데이터로 구성된 외부 스키마를 각각 가지고 있다. A팀은 고객의 성별과 이름을 분석하는 것이 주 업무이므로 고객의 번호나 나이와 관련한 데이터는 관심이 없다. 반대로 B팀은 고객의 번호와 나이 데이터에 관심을 가지고 있다. 만약 팀들의 팀원들이 여러 명이라면 팀원들은 해당 데이터에 대한 외부 스키마를 함께 사용할 것이다. 그로 인해 불필요한 데이터 접근을 사전에 막아 보안 측면에서도 효과적이다.

 개념 단계에는 고객 DB 전체에 대한 논리적 구조를 정의하는 개념 스키마가 하나 있다. 고객 DB를 이용하는 모든 사용자에게 필요한 데이터를 종합하여 번호, 이름, 성별, 나이로 DB를 구성하고, 각 데이터의 타입도 함께 정의한다.

 내부 단계에는 고객 DB를 저장 장치에 저장하는 파일의 레코드 구조를 정의한 내부 스키마가 하나 존재한다. 내부 스키마에 정의된 고객 레코드는 필드 4개로 구성되어 있고, 레코드 총 길이는 20바이트다. 이 내부 스키마는 번호 필드에 인덱스를 정의하고 있어, 번호 필드의 값을 이용해 해당 고객 레코드에 빠르게 접근할 수 있다.

데이터 독립성

 하나의 DB에는 세 가지 유형의 스키마가 존재하지만, 각각의 스키마는 DB를 바라보는 관점이 다를 뿐 모두 같은 DB를 표현한다. 실제 데이터는 물리적 저장 장치에 저장된 DB에만 존재하므로 사용자가 자신의 외부 스키마를 통해 원하는 데이터를 얻으려면 내부 스키마에 따라 저장된 DB에 접근해야 한다. 그러므로 세 가지 스키마 사이에는 유기적인 대응 관계가 성립해야 한다.

 위 그림에서 B팀의 외부 스키마에 있는 고객 번호 데이터는 개념 스키마에 있는 번호 데이터에 대응하고, 개념 스키마에 있는 번호 데이터는 내부 스키마에 있는 번호 필드에 대응한다는 연결 관계가 미리 정의되어 있어야 한다. 그래야 사용자가 물리적 저장 장치에 저장된 고객 번호 데이터에 접근할 수 있다.

 스키마 사이의 대응 관계를 사상 또는 매핑(mapping)이라 한다. 외부 스키마와 개념 스키마는 외부/개념 사상에 의해 대응되고, 개념 스키마와 내부 스키마는 개념/내부 사상에 의해 대응된다. DB 관리 시스템은 미리 정의된 외부/개념 사상과 개념/내부 사상 정보를 이용해 사용자가 원하는 데이터에 접근할 수 있다.

 DB를 3단계 구조로 나누고, 단계별로 스키마를 유지하며 스키마 사이의 대응 관계를 정의하는 목적은 데이터 독립성을 실현하기 위해서다. 데이터 독립성은 하위 스키마를 변경하더라도 상위 스키마가 영향을 받지 않는 특성이다. 3단계 DB 구조에는 논리적 데이터 독립성과 물리적 데이터 독립성이 존재한다.

 외부 단계와 개념 단계 사이에는 외부/개념 사상에 대한 논리적 데이터 독립성이 존재하고, 개념 단계와 내부 단계 사이에는 개념/내부 사상에 대한 물리적 데이터 독립성이 존재한다.

논리적 데이터 독립성

 논리적 데이터 독립성은 개념 스키마가 변경되더라도 외부 스키마가 영향을 받지 않는 것이다. 그래서 전체 DB의 논리적인 구조가 변경되어도 관련된 외부/개념 사상 정보만 적절히 수정해주면 직접 관련이 없는 사용자를 위한 외부스키마는 변경할 필요가 없다. 외부/개념 사상은 응용 인터페이스(application interface)라고도 한다. 결국 외부 스키마의 사용자가 전체 DB의 논리적 구조가 변경되었다는 사실을 알 필요가 없다는 것을 의미한다.

 예를 들어, 개념 스키마에서 고객 번호 데이터의 이름이 고객 전화번호로 바뀌는 경우, B팀의 외부 스키마에 있는 고객 번호가 이후부터는 개념 스키마의 전화번호와 대응 관계에 있다고 외부/개념 사상만 정확히 수정해주면 된다. 또한 개념 스키마에 새로운 내용이 추가되거나 기존 내용이 삭제되는 경우에도 외부 스키마는 영향을 받지 않는다.

물리적 데이터 독립성

 물리적 데이터 독립성은 내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는 것이다. 그래서 결과적으로는 외부 스키마도 영향을 받지 않는다.

 물리적 데이터 독립성이 실현되면 DB의 저장 구조가 변경되어도 관련됨 개념/내부 사상 정보만 적절히 수정해주면 직접적으로 관련이 없는 DB의 논리적 구조는 영향을 받지 않는다. 개념/내부 사상은 저장 인터페이스(storage interface)라고도 한다.

 예를 들어, 내부 스키마에는 번호 다음에 이름 필드가 저장되어 있는데 이 순서가 바뀌어도 두 필드와 관련됨 개념/내부 사상 정보만 수정해주면 된다. 또한 내부 스키마에 새로운 인덱스가 추가 되거나 기존 인덱스가 삭제되는 경우에도 개념 스키마는 영향을 받지 않는다.

데이터 사전

 DB는 조직 운영을 위해 필요한 실제 데이터를 저장하는데, 저장된 데이터를 올바르게 관리하고 이용하려면 필요한 부가 정보도 저장해야 한다. 대표적인 부가 정보가 스키마와 사상 정보다.

 DB에 저장되는 데이터에 관한 정보를 저장하는 곳을 데이터 사전(data dictionary) 또는 시스템 카탈로그(system catalog)라고 한다. 데이터 사전은 일반 사전처럼 DB에 저장되어 있는 데이터를 정확하고 효율적으로 이용하기 위해 참고해야 되는 스키마, 사상 정보, 다양한 제약조건 등을 저장하고 있다. DB에 저장되는 데이터에 관한 정보(데이터 사전 정보)이므로 데이터에 대한 데이터(data about data)를 의미해 메타 데이터(meta data)라고도 한다.

 데이터 사전도 데이터를 저장하는 DB의 일종이기 때문에 시스템 데이터베이스(system database)라고도 한다. 그리고 이와 구별하기 위해 사용자가 실제로 이용하는 데이터가 저장되는 일반 DB를 사용자 데이터베이스(user database)라 부르기도 한다. 데이터 사전은 DB 관리 시스템이 스스로 생성하고 유지하는 것으로, DB 관리 시스템이 주로 접근하지만 일반 사용자도 접근할 수 있다. 단, DB 관리 시스템이 데이터 사전에 내용을 새로 추가하거나 수정할 수 있는 반면, 사용자는 저장 내용을 검색만 할 수 있다.

 데이터 사전에 있는 데이터에 실제로 접근하는 데 필요한 위치 정보는 데이터 디렉터리(data directory)라는 곳에서 관리한다. 데이터 사전과 데이터 디렉터리는 둘 다 시스템을 위한 DB라는 공통점이 있지만, 데이터 사전은 사용자가 접근할 수 있고 데이터 디렉터리는 시스템만 접근할 수 있다는 차이가 있다.