Data Model 이란?

데이터 모델은 우리가 가지고 있는 데이터를 표현하는 방법을 의미한다. 그리고 데이터 모델은 일반적으로 세 영역으로 나뉘어져 있다.

1. Structure of data 데이터 구조라는 용어는 우리가 자료구조라는 이름으로 너무나 자주 들었던 이야기이다. 그러나 데이터베이스 시스템에서의 데이터 구조는 물리적으로 데이터들을 구조화할 것인지에 대한 이야기이다.
2. Operations on the data 데이터베이스 시스템에서는 query를 통한 데이터의 탐색과 modification을 통한 데이터베이스 변경에 대한 연산만을 허용한다. 제한적으로 느껴질 수 있겠지만, 이런 제한 때문에 우리는 데이터베이스 시스템을 효과적으로 사용할 수 있다.
3. Constraints on the data 데이터 베이스 시스템은 어떤 데이터들에 제한을 만들어서 특정한 데이터들만 관리하도록 할 수 있다.

Types of the models

Relational Model

1. Structure of data: Relational model은 테이블(표)에 모든 정보다 들어가 있다. 그리고 데이터들이 모여있는 표의 한 행은 한 데이터구조를 의미하게 된다(tuple).
2. Opertations of the data: Relational model에서의 연산은 데이터 베이스가 Relation이라는 표로 구성되어져 있기 때문에 relational algebra를 통해 데이터를 관리하는 연산을 수행하게된다.
3. Constraints on the data: Relational model에서도 데이터의 constraints를 만들 수 있는데, 예를 들어 한 행 안에 최대 몇개의 요소들이 들어갈지 정할 수도 있고, 한 데이터의 범위를 정하는 것도 가능하다.

The Semistructured Model

1. Structure of data: Semistructered model은 트리 혹은 그래프로 만들어지는 경우가 많다. 그리고 데이터를 표현하기 위해서 XML이라는 형테를 사용하는데, 태그를 이용해서 행이나 열을 표현하는 방식으로 구현한다.
2. Operations of the data: 트리나 그래프 구조를 사용하는 모델이기 때문에 한 요소에서 하위 요소로 쭉 따라내려가는 방법으로 연산을 수행한다. 그리고 태그로 표기된 요소들을 통해서 어떤 요소가 어디에 속하는지 구분하게 된다.
3. Constarints on the data: Semistructured model에서 데이터의 constraint는 사용되는 태그를 통해 표현할 수 있다.

이 두 가지 외에도 여러 다른 종류의 데이터베이스 모델이 있지만 relation model이 DBMS에서는 가장 흔하게 사용되는 모델이다. 왜냐하면 relation model은 표로 구성되어 있어서 직관적이고, 사용하기 편하다. 또한, SQL을 지원한다는 것은 엄청나게 큰 장접이다.

Let’s Dive into R-DBMS!

그렇다면 그렇게 좋다는 Relation-Database Management System 을 더 살펴보자. 위에서 언급했던 것 처럼 RDBMS는 기본적으로 2차원 배열, 혹은 표라고 부르는 relation으로 이루어져 있다. 그리고 R-DBMS을 구성하는 다양한 용어들을 이제 살펴보자.

Attribute

Attribute는 relation을 구성하는 하나의 요소들이다. relation에서는 열(column)을 이루는 특징들을 attribute라고 한다. 우리는 attribute를 통해서 해당 열에 들어올 값들이 무엇을 의미하는지 정의할 수 있다.

Schema

Schema 는 relation의 이름, 즉 데이터들로 만들어지는 표의 이름을 의미한다. 우리는 어떤 relation을 나타낼 때, Schema와 attribute을 함께 표기하는 방법을 사용하는데 다음과 같이 나타낸다.

Department(Name, Number of Student, Number of Professor, Number of Alumni)

이런식으로 나태낼 때, Department는 Shema, 그리고 괄호 안에 들어가는 것들이 attribute의 집합이 된다. 중요한 것은 attribute들은 list가 아니라 set으로 들어간다는 것이다.

대부분의 경우에서, 데이터베이스는 하나의 relation이 아닌 여러개의 relation들의 집합으로 이루어진다. 그래서 우리는 어떤 데이터베이스를 구성하는 relation들의 집합을 relational database schema 라고 부른다.

Tuples

Relation에서 첫 header가 되는 한 행을 제외한 행들을 tuple 이라고 부른다. 첫 행을 제외하는 이유는 첫 행은 항상 attribute들의 이름을 가지고 있기 때문이다. Relation은 모든 attribute 마다 component를 가진다. 만약 우리가 Schema에서 예로 만들었던 relation의 tuple 을 만든다면 다음과 같이 만들 수 있을 것이다:

(CSEE, 300, 20, 2300)

이런식으로 각 attribute에 해당하는 component들이 콤마로 구분되어 표현되어진다.

Domains

Relation을 구성하는 component들이 가지는 값은 반드시 단순한 종류의 값들이어야 한다. 단순하다는 것은 기초적인 자료형들을 의미한다. 정수, 문자열 같은 녀석들 말이다. 리스트, 셋 과 같은 상대적으로 복잡한 타입들은, 새로운 여러개의 components 들로 또 다시 분리가 가능하기 때문에 component로 만들 수 없는게 어쩌면 당연한 것이다.

Domain 은 이 component들이 가질 수 있는 type을 말해준다. 위 예시를 그대로 사용하면, Department라는 Relation은 각 tuple이 String, Integer, Integer, Integer 의 attribute들을 가지고 있다고 할 수 있다. 그리고 schema를 나타낼 때, domain도 함께 표현할 수 있는 방법이 다음과 같다:

Department(Name:String, Number of Student:Integer, Number of professor:Integer, Number of alumni:Integer)

Does an Order Matter in Relation?

Relation은 tuple들의 set이다. 그러므로 relation 안에서 tuple들의 순서는 그다지 중요하지 않다. 그렇다면 attribute들의 순서를 바꾸는 것도 가능할까? 대답은 가능하다 이다! 다만 relation 안에 있는 모든 attribute 의 순서가 모두 바뀌어야 한다. 왜냐하면 hear에 tuple component의 정보가 그대로 들어있기 때문에, 하위에 있는 모든 row들의 정보의 domain이 header와 일치해야하기 때문이다.

Maintaing Update History of DB?

Relation에는 새로운 tuple이 생성되어 추가될 수도 있고, 기존의 tuple의 component가 업데이트 되어서 그 값이 변경될 수도 있다. 그리고 우리는 한 relation 안에 들어있는 tuple들의 집합을 instance 라고 부른다. 데이터베이스는 일반적으로 하나의 버전의 relation만 가지고 있다. 그리고 이 relation안에는 현재 시점의 데이터 베이스가 들어있게 된다. 이런 instance 를 current instance라고 하고, 과거의 버전까지 기억하고 있는 데이터베이스를 temporal database 라고 한다.

Key

Relation 안에서 사용될 수 있는 constraint 들 중 가장 기초가 되고 중요한 constraint가 key 라는 녀석이다. attribute 들의 집합에서 key를 설정하면 우리는 다수의 tuple들이 같은 attribute 값을 가지는 것을 막을 수 있다.

예를 들어 계속 예시로 사용하고 있는 Department relation에서 “Name”과 “Number of Student” attribute를 key로 지정하게 되면, Department relation 안(정확히는 Department relation instance)에서는 각 tuple들이 서로 다른 이름과 학생수를 가져야 한다. 단, key가 두 개이기 때문에 두 attribute에 대해 모두 같은 tuple들만 중복으로 생각한다. 그리고 우리가 key를 표기할 때는 밑줄을 치는 것으로 표기한다.

Department(Name, Number of Student, Number of Professor, Number of Alumni)

key 를 선택하는 작업은 상당히 중요한 일이다. 위 예시처럼 key를 설정하는 것은 좋은 것은 아니다. 아마도 Name을 단독으로 사용하는게 더 좋은 key가 될 것이다. 일반적으로 실제 필드에서는 어떤 지원들의 데이터베이스를 관리할 때 특수한 ID를 만들어서 각 직원에게 부여한다. 이 ID는 unique 하게 만들어져 있고 데이터베이스 안에서 key로 지정되어 있기 때문에 회사는 어떤 직원이 어떤 데이터를 가지고 있는지 쉽게 파악할 수 있게 된다.

자 이제 기본적은 concept과 terminology는 끝났다. 이제 SQL에 빠져들어가 보자!