Chapter2 - 데이터베이스 스키마

• 데이터베이스 스키마
  

     데이터베이스에 대해서 언급할 때, 데이터베이스의 논리적 설계인 데이터베이스 스키마(database schema)와, 어떤 한 순간에 데이터베이스에 저장되어 있는 데이터의 스냅샷인 데이터베이스 인스턴스(database instance)를 잘 구별해야 한다.

    릴레이션 개념은 프로그래밍 언어에서 변수의 개념에 해당된다. 마찬가지로 릴레이션 스키마(relation schema)의 개념은 프로그래밍 언어에서의 형정의(type definition)에 해당된다.

    일반적으로 릴레이션 스키마는 속성과 그 속성이 가지는 도메인의 명세로 구성된다. 각 속성의 도메인에 대해 정확히 정의하는 것은 SQL을 배울 때까지 일단 보류해 두기로 한다.

    릴레이션 인스턴스의 개념은 프로그래밍 언어에서 변수의 값과 비슷하다. 주어진 변수의 값은 시간에 따라 변한다. 마찬가지로, 릴레이션 인스턴스의 투플도 릴레이션이 변경됨에 따라 변하게 된다. 하지만 일반적으로 릴레이션의 스키마는 변하지 않는다.

    릴레이션 스키마와 릴레이션 인스턴스의 차이를 아는 것도 중요하지만, instructor 처럼 같은 이름으로 스키마와 인스턴스를 지칭한다는 것을 알아야 한다. 앞으로 릴레이션 스키마인지 릴레이션 인스턴스인지 정확히 구분해야 하는 경우에는 "instructor 스키마", "instructor 릴레이션의 인스턴스" 와 같이 명시적으로 사용할 것이다. 하지만 릴레이션 스키마인지 릴레이션 인스턴스인지 명백한 경우에는 간단히 릴레이션의 이름을 사용할 것이다.

     department 릴레이션을 생각해 보자. 이 릴레이션의 스키마는 다음과 같다.

dept_name 속성은 instructor 스키마와 department 스키마에 모두 나타나는 것을 알 수 있다. 이러한 중복은 우연히 아니다. 릴레이션 스키마에서 공통적인 속성을 하용하는 것은, 서로 다른 릴레이션에 있는 투플을 관련짓는 방법 중 하나이다. 예를 들어, Watson building 에서 일하는 교수에 대한 모든 정보를 찾고 싶다고 하자. 이를 위해서는 department 릴레이션에서 building이 Watson 인 모든 dept_name 을 찾아야 한다. 그리고instructor 릴레이션에서 해당 dept_name 을 가지고 있는 모든 교수의 정보를 찾아야 한다.

    대학교의 데이터베이스 예제를 생각해 보자.. 각 수업은 학기마다 한번, 혹은 한 학기 안에서도 여러 번 열릴 수 있다. 그렇기 때문에 수업의 관계를 표현할 수 있는 스키마를 제공해야 한다.

section(course_id, sec_id, semester, year, building, room_number, time_slot_id)

그림 2.6은 section 릴레이션의 인스턴스의 한 예이다.

    이러한 상황에서 교수와 수업 사이의 관계를 표현할 수 있는 릴레이션이 필요하게 된다. 이러한 관계를 표현할 수 있는 릴레이션의 스키마는 다음과 같다.

실제 대학교의 데이터베이스는 훨씬 더 많은 릴레이션이 존재한다. 이미 언급된 instructor, department, course, section, prereq, teaches 이외에도 다음과 같은 릴레이션을 사용할 것이다.

• instructor( ID, name, dept_name, tot_card)

• advisor(s_id, i_id)

• takes(ID, course_id, sec_id, semester, year, grade)

• classroom(building, room_number, capacity)

• time_slot(time_slot_id, day, start_time, end_time)