Introduction Relational Model(1)

Relational Model

 

Relational Model의 정의, 용어 그리고 사용 예시들에 대한 설명을 진행하려고 합니다.

 

Relational Model는 관계 모델로 우리에게 익숙한 테이블을 사용해서 데이터를 표현하는 것이지만 용어는 조금 다릅니다.

 

테이블은 Relation이고, 테이블의 row는 튜플, 테이블의 column는 attribute(속성)입니다.

 

위의 이미지를 예시로 들면, instructor relation을 보면 instructor relation은 ID,name,department name, salary와 같은 네 개의 컬럼 헤드를 갖고 각 행의 튜플들은 ID, name, department name, salary로 구성된 한 명의 교수에 관한 정보입니다.

 

이러한 교수님들의 정보가 ID에 의해서 구별되는 것이 relation입니다.

relation 용어

 

Relational model에서 relation은 각자 고유한 이름을 갖고 relation의 각 행은 독립된 값들의 관계를 표현하고, 이러한 관계들의 모임을 말합니다.

 

테이블이 릴레이션이라고 불리는 것은 독립적인 데이터들 사이의 릴레이션쉽을 보여주기 때문입니다.

 

각 행은 각 값들 사이의 관계를 표현하므로, instructor relation은 각 행이 특정 아이디와 나머지 name, department name, salary 값들 사이이 릴레이션쉽을 가지고 있기 때문입니다.

 

튜플은 테이블의 행을 의미하고, 여러 개의 튜플이 릴레이션 안에 있고, n튜플은 n개의 값의 관계를 의미하고 n개의 값을 가지는 하나의 튜플이 하나의 행이 되는 것을 말합니다.

 

참고로, 하나의 릴레이션의 튜플들의 개수를 cardinality이고, 여기의 attribute는 테이블의 열이고, 릴레이셔널 데이터베이스는 테이블의 컬렉션으로 구성이 됩니다.

 

즉, 여러 개의 릴레이션이 구성되어 하나의 데이터베이스를 구성하는 것으로 릴레이셔널 모델 관계 모델에서 우리가 명심해야 할 것은 테이블은 어떤 순서가 있지만, 릴레이션은 순서를 갖고 있지 않다는 것입니다.

 

Relational Instructor

 

참고로, 릴레이션은 튜플들의 집합이어서 튜플들의 순서는 상관이 없기에 튜플을 임의의 순서로 저장할 수 없고, 튜플의 내용이 같을 경우 다른 순서로 정렬되어 있어도 동일한 릴레이션이 됩니다.

 

즉, 순서에 대한 개념은 릴레이션에게 없고 정렬되지 않은 Instructor relation은 어떤 튜플이 먼저 와도 상관이 없습니다.

그러나, 중복된 튜플을 갖고 있는 것은 집합의 정의를 따르기에 안됩니다.

 

속성(Attribute)

 Attribute(속성)에 대해서 자세히 설명을 하려고 합니다.

속성은 도메인을 가지고 있고, 도메인은 각 속성들의 허락되어진 값들의 집합을 의미하는 것으로 정수 도메인 혹은 문자형 도메인을 가질 수 있습니다.

 

그리고, 도메인(프로그래밍에서 변수의 타입 정보)을 보는 것은 정말 쉽게 데이터베이스에서 데이터 타입을 볼 수 있습니다.

그래서, 이러한 릴레이션의 모든 속성의 도메인은 atomic 해야 하는 것으로 더이상 나눠질 수 없고 하나의 값만 가져야 합니다.

 

위의 instructor relation을 생각해보면, department name 속성은 값으로, Pyhsics, Finance,History, Computer Science 같은 하나의 값을 가지고 있기에 여러 개를 저장하려고 하시는 시도는 절대로 하면 안되고 딱 하나의 값만 저장해야 합니다.

왜냐하면, atomic이 아니므로 모아높은 값들은 하나의 속성의 값을 저장할 수 없습니다.

 

참고로, 속성에선  Null이란 개념을 사용할 수 있고, 이 널 값은 특별한 값을 의미하는데 모든 도메인들은 가질 수 있습니다.

널의 의미는 아예 모르거나, 아직 모르거나, 존재하지 않은 값을 의미하므로 여러분들의 데이터가 이러한 상태일 경우 Null을 넣어주면 될 것 같습니다.

 

실제로, 널은 숫자의 영이나 아니면 빈 문자열과는 다른 의미를 가지고 있습니다.

 

그래서, 널 값은 많은 연산이 필요한 릴레이션의 경우 복잡함을 야기시킬 수 있고, 고려해야하는 부분들이 많아지기에 널 값을 사용하지 않는 것이 좋습니다. 이래서, 파이썬이나 DB에서 널 값을 제거하는 것입니다.

 

Relation Schema and Instance

 

Relation Schema

속성에 리스트와 도메인으로 구성이 됩니다.

예를 들어, 위의 이미지를 보면 a1, a2,..an,이 속성으로 주어져 있고, 이러한 속성을 가진 릴레이션의 스키마는 R은 릴레이션의 이름, 등호 이후에 괄호를 열고 그 안에 릴레이션에 포함되는 모든 속성의 이름을 적고 괄호를 닫아주면서 이 하나의 릴레이션의 스키마를 정의할 수 있습니다.

 

계속 봤던 예시를 이야기하자면, relation instructor의 schema는 지금 보시는 것처럼 표현할 수 있고 릴레이션의 이름이 인스트럭트를 써주고 equal을 해주고 괄호를 열고 이 인스트럭트를 구성하는 속성인 ID,Name,Deparment Name, Salary를 적어주고 괄호를 닫아주면 됩니다.

 

그러면,  Relational Instructor는 ID,Name,Deparment Name, Salary 속성으로 이뤄지고 스키마 표현법을 사용하여 릴레이션의 스키마를 표현할 수 있고, 각 속성에 대한 도메인의 집합 D1,D2..Dn이 주어지면 다시 말하면 속성 A1의 도메인 D1, 속성 A2의 도메인인 D2 그리고 An의 도메인인 Dn이 주어질 때 릴레이션 R은 각 속성의 도멘인의 조합의 부분 집합이 됩니다.

 

즉, A1은 D1에 있는 모든 값을 가질 수 있지만 모든 값을 다 가질 필요는 없기에 릴레이션은 도메인의 모든 값이 아닌 그 중 일부분이 릴레이션으로 만들어지게 되고, n개의 attribute 값을 가지는 하나의 튜플인 n튜플들의 집합인 것입니다.

 

고로, n 튜플들의 A1, A2 그리고 An은 각각의 그 속성의 도멘인에 포함되고 릴레이션 스키마를 보면 릴레이션의 이름이 뭐고 어떤 속성들로 구성되어 있는지 전체 구조를 쉽게 파악할 수 있습니다.

 

Instance

인스턴스는 프로그램 언어에서 변수의 값과 비슷하고, 현재 릴레이션의 값들을 의마하고 이는 테이블로 명기되어 집니다.

 

릴레이션 아래 요소 T는 튜플이며 테이블에 열로 표현이 됩니다. 그래서, 릴레이션 인스턴스르 보면 현재 릴레이션의 실제 내용을 파악하는 동시에 변화하는 튜플의 값도 체킹이 되지만 스키마는 변화하지 않습니다.

 

Keys

 

Superkey

 

키의 개념을 되게 가볍게 여기가나 중요하지 않게 생각을 하는데 SQL을 사용할 때 키에 대한 개념이 굉장히 중요합니다.

 

먼저, 키를 사용하는 이유는 릴레이션 안에서 튜플들을 구별하는 방법이 필요합니다. 왜냐하면, 속성들의 값이 모두 동일한 튜플이 존재하면 안되고 값들을 통해서 각각의 튜플을 구별할 수 있어야 하기 때문입니다.

 

K는 릴레이션의 부분집합으로 릴레이션 R의 속성들의 일부로 만들어지고 유니크한 튜플을 식별하기 충분하다면 슈퍼키라고 부릅니다.

 

예를 들면, department name으로 원하는 한 가지의 튜플을 가져오고 구별할 수 있나여..?라는 질문들을 통해서 키를 구분하면서 나아간다고 생각을 하시면 됩니다.

 

만약, department name이 physics인 값을 갖고 싶을 때, 유일한 하나의 튜플을 구할 수 없기에 키가 될 수 없습니다.

그러나, ID는 유일한 값이기에 각각의 튜플을 구할 수 있고 동일한 튜플이 존재하지 않게 됩니다.

 

그래서, 우리는 ID를 슈퍼키로 볼 수 있고, ID+name을 통해서 슈퍼키를 설정할 수도 있습니다.

즉, 하나의 속성으로만 슈퍼키가 생기는 것이 아니라 여러 개의 슈퍼키로 만들어질 수 있다는 것을 인지하면 됩니다.

 

정리하면, 릴레이션의 튜플을 식별할 수 있는 유일한 attribute의 집합을 슈퍼키라고 하고 SPA키는 attribute 하나로 만들어 질 수 있고 여러 개로도 만들어질 수 있고 ID 하나가 슈퍼키가 될 수 있고 두 개의 속성을 합쳐서 될 수도 있습니다.

 

 

Candidate key(후보키)

작은 의미로는 더 이상 줄어들 수 없는 형태(슈퍼키를 구성하는 속성 중 하나라도 제거할 경우 유일성을 잃는)를 가진 것으로 필요없는 attribute를 가지지 않는 것이지만 필요한 attribute가 하나라도 없으면 안된다.

 

예를 들면, ID-name로 만들어진 슈퍼키를 보았을 때 ID에는 name이라는 속성을 가지지 않지만 하나의 속성만으로 각각의 튜플들을 구별할 수 있는데  우린 이때 아이디 하나로 구성된 것을 candidate key라고 할  수 있습니다.

 

생각해보면, name은 동명이인이 생기지만 ID는 그렇지 않는 것과 같습니다.

 

Primary key(기본키)

릴레이션 안에서 튜플을 구별하기 위해서 데이터베이스 설계자가 후보키 중에서 하나를 선택하는 것으로 DB 만들 때 꼭 필요한 개념입니다.

왜냐하면, 어떤 것을 기본키로 정하는 기준은 무슨 키가 가장 많이 사용하고 어떤 것이 가장 이 릴레이션에서 의미가 있는가에 의해서 정의가 되기 때문입니다.

 

예를 들면,  Instructor relation에선 ID가 기본 키가 될 수 있습니다. 왜냐하면 기본 키는 각각의 튜플들을 구별해야 하므로 유일한 값이고 Null값이 없어야 합니다.(기본 키 제약 조건)

 

기본 키가 되는 속성들은 릴레이션에서 주로 다른 attribute보다 앞 부분에 적어주는 것이 일반적인 표기법입니다.

 

Foreign key(외래키)

 

릴레이션들 사이의 관계를 올바르게 표현해 주는 것으로 서로 다른 릴레이션들의 튜플을 연결시키는 것으로 릴레이션에서 공통적인 attribute를 사용하는데 튜플을 의미합니다.

 

한 릴레이션의 값이 다른 릴레이션에 나타나야 하는 것을 foregin key constraint(외래키 제약조건)입니다.

 

예를 들면, instructor relation 중 department name 속성은 computer science, physics, finance, history등의 값을 가집니다.

또 다른 테이블은 instructor relation에서 department 속성들이 가지고 있는 값을 반드시 갖고 있어야 합니다.

 

즉, instructor relation은 department relation 릴레이션의 name값을 참조하므로 어떤 값이 삽입되기 전에는 그 값들을 갖고 있어야합니다.

 

 

위의 이미지를 보면, 화살표 방향을 보시먄 name의 어떤 값이 들어가기 전에 참조할 이 department relation의 department name에는 그 값들이 미리 그 값이 무엇인지 저장이 되어야하고, 만약 없는 값을 참조할 경우 문제가 발생합니다

 

Referencing  relation 참조하는 릴레이션으로 foreign을 가지는 릴레이션이고 Referenced relation 은 참조되는 릴레이션을 의미합니다.

 

위의 그림에서 foregin key가 기본 키인 지금은 department relation을 의미하고 참조하는 릴레이션의 foreign key 값은 반드시 참조되는 릴레이션에 있어야 하는데 우린 이것을 referencial integrity 참조 무결성입니다.

 

 

스키마 다이어리그램

데이터베이스는 기본 키와 외래 키 속성을 가지고 아래의 그림처럼 시각적으로 표현이 가능합니다.

 

위의 그림은 대학의 스키마 다이어그램으로 각 릴레이션은 네모 상자로 나타내지고, 우리가 계속 예시를 들었던 instructor를 이런 네모 상자로 표현하고 department relation도 가능합니다.

 

눈치를 채셨겠지만, 릴레이션의 속성들은 위의 네모칸처럼 relation의 이름은 위에 써주고 기본 키로 사용되는 속성들은 선으로 이어서 그어진 애가 "기본 키"다 라는 것을 표현합니다.

추가적으로, 외래 키 종속성은 참조하는 릴레이션으로부터 참조되는 릴레이션의 기본 키 방향으로 화살표로 표현이 됩니다.

 

위의 이미지를 기반으로, department name이 외래 키이고 이를 참조하는 department relation의 department name쪽으로 화살표를 그어서 표현을 합니다.

 

student relatino의 경우 department name는 department relation의 department name을 참조하고 있습니다.

즉,  department relation의 department name은 기본키이자 유일한 값을 가져야합니다.

 

composit key(복합키)

 department relation의 department name의  링크들이 이어지는 것을 보면 foreign key constraints를 보여주므로 student relation의 모든 department name값들은 department relation의 department name 값 중에서 하나를 가져야 합니다.

 

추가적으로, advisor이라는 relation은  s가 쭉 가서 화살표를 따라가면 id를 참조하고 있고 반대쪽으로 가보면 instructor relation의 id를 또 참조하고 있습니다.

 

즉, advisor relation의 역할은 student id와 그 다음에 instructor id를 매핑해주는 역할입니다.

그래서, 이러한 역할을 하는 릴레이션은 teaches(instructor-section) or takses(student-section)도 있습니다.

 

그리고, section relation의 기본키(밑줄 그어진)를 보면 course id, section id, semester,year들로 구성되어 있기에 각각의 모든 정보를 가지고 있어야만 유일한 수업을 구별할 수 있게 됩니다.