#title 관계형 데이터 모델
[[TableOfContents]]

작성 중..

==== 관계 모델 ====
 * 데이터베이스는 릴레이션(Relation, 행x열)들의 집합
 * 릴레이션은 투플(Tuple, 행)의 집합
 * 투플은 애트리뷰트(Attribute, 속성, 열)의 집합

attachment:관계형데이터모델/r_model02.png

엄밀히 따지면 릴레이션(Relation)과 릴레이션쉽(Relationship)은 의미가 다르다. 현재까지의 대부분의 DBMS는 관계형이거나 객체-관계형으로 우리가 흔이 이야기 하는 까마귀발 모양의 '관계'는 릴레이션쉽이다. 집합론에서의 관계는 'Relation'이라고 했으나, 집합론에서 설명된 것을 보면 우리가 이야기하는 'Relationship'을 말하고 있어 혼동하기 쉽다. 아래는 네이버 백과사전의 관계에 대한 정의다.

 ''집합론에서는 관계가 순서쌍의 집합으로 정의된다. R가 집합 A의 원소 a와 B의 원소 b 사이의 관계일 때 aRb를 성립시키는순서쌍 (a,b) 전체의 집합 G={(a,b)|aRb}를 관계 R의 그래프라 한다. ''

필자의 생각에 '릴레이션'이라고 명명된 것은 애트리뷰트들과 투플들이 어떤 관계에의해 모여진 집합이기 때문이라고 여겨진다. 실제로 Relation은 표형태를 의미한다. ('Relation'을 '관계형'으로 번역된 것은 대표적인 오역 사례다.) 예를 들어, 학생을 추상화에서 대표적인 애트리뷰트들 추려내어 애트리뷰트 집합을 만든 것이 위 그림이다. 대표적이라는 말은 추려진 애트리뷰트들(Name, SSN, HomePhone, Addess, OfficePhone, Age, GPA)이 있어야만 학생을 표현하고 학생과 관련된 업무를 처리하는데 무리가 없다는 것을 의미한다. 그러므로 업무에 따라서 추상화 레벨이 정해진다. 달리 표현하자면 추상화 레벨은 업무에 종속적이다라고 말 할 수 있다. 예를 들어, 기호의 의미해서 사람을 표현한다면 머리, 몸통, 팔, 다리 정도(동그라미 1개, 직선 4개)만 있어도 표현(추상화 레벨이 높음)이 가능하다. 하지만, 범죄자를 식별하는 업무라면 머리, 몸통, 팔, 다리가지고는 부족하다. 적어도 눈, 코, 입의 사람이 눈으로 식별 가능한 정도의 데이터로 표현(추상화 레벨이 낮음)되어야 한다. 

릴레이션이 의미하는 바를 알기 위해서는 논리적인 기술(desciption, 또는 설명)이 필요하다. 이러한 논리적인 기술을 릴레이션 스킴(Schem)이라고 하며, 다음과 같은 형식으로 기술한다.

 ''Student(Name, SSN, HomePhone, Addess, OfficePhone, Age, GPA)''

투플은 개체의 인스턴스이다. 즉, 릴레이션에서 애트리뷰트과 관계되는 값의 집합을 말한다. 위의 그림에서는 {한 명의 학생 = 투플}은 다음과 같다.

 ''Charies Cooper, 489-22,1100, 376-9821, 256 Lark Lane, 749-1253-28, 3.93''

애트리뷰는 속성이다. 각각의 애트리뷰트은 도메인(domain)을 가진다. 도메인은 애트리뷰트이 가질 수 있는 값의 범위를 말한다. 예를 들어, 성별이라면 2byte의 '남', '여'의 값만 가질 수 있으며, null 값을 가지지 못한다와 같이 애트리뷰트의 도메인을 정의할 수 있다. 위의 그림에서 Student 릴레이션은 7개의 애트리뷰트을 가지는데 이는 

 ''차수(degree)가 7 이다''

라고 표현한다. 또한 투플이 5개인데 이는

 ''카디널리티(cadinality)가 5 다.''

라고 표현한다. 

==== 릴레이션의 특징 ====
관계 모델에서 릴레이션은 다음과 같은 특징을 가진다. 관계형 데이터베이스는 이러한 특징으로 논리적인 독립성을 유지하고 파일 시스템에 비해 변화에 빨리 적응되도록 발전되어져 왔다. 

 * 튜플의 유일성
 * 튜플들의 무순서
 * 애트리뷰트들의 무순서
 * 애트리뷰트의 원자값

투플의 유일성은 각각의 투플을 식별할 수 있어야 함을 의미한다. 차수가 5인 릴레이션에서 적어도 애트리뷰트 5개의 값의 조합이 유일(unique)해야 함을 의한다. 물론 5개가 아닌 2개, 1개의 애트리뷰트으로도 각각의 투플을 식별할 수 있어도 된다. 각각의 투플을 구분할 수 있는 모든 속성 또는 속성들의 조합을 슈퍼키(super key)라고 하며, 이들 중에서 기본키가 될 만한 것들로 추려진 것으로 후보키(cadidate key)라고하며, 후보키들 중에 각각의 투플들을 식별하는데 대표적인 의미를 가져서 선정된 속성(들)이 기본키가 된다. 만약 필요에 의해 DB설계자가 특정 목적으로 원래의 기본키 대신 다른 임의의 속성을 추가하여 기본키 역할을 시키면 대체키(alternate key)가 된다. 

투플의 무순서는 다른 데이터 모델과는 다른 관계 모델만의 특징이다. 만약 투플의 순서에 의미를 부여하고 싶다면 정렬 연산을 하면 된다. 예를 들어, 위의 그림에서 Dick Davidson이 Charies Cooper보다 먼저 존재한다고 해도 먼저 입학하거나, 성적이 우수하거나 나이가 많거나 하는 어떤 가치판단의 기준이 되는 것이 아니다. 그러한 가치판단은 애트리뷰트값으로 결정한다. 예를 들어, '입학일' 이라는 속성을 오름차순으로 정렬했을 때 투플의 순서는 입학을 먼저 했는지 나중에 했는지의 가치판단을 할 수 있게 된다. 릴레이션이 물리적으로 구현될 때에 입력의 순서와 상관없이 create index, table rebuild와 같은 작업에 의해 순서가 변경될 수 있다. 그러므로 투플의 순서에 어떤 의미를 부여했다면 관계 모델의 사상에 반하는 것이 되어 데이터의 품질 떨어뜨릴 수 있다. (커뮤니티의 [http://www.sqlleader.com/mboard.asp?exec=view&strBoardID=SSQUERYQNA&intSeq=4021 질문]을 보라. 투플의 무순서라는 것을 무시한 설계나 사상으로 인한 복잡성을 가중시키는 예다.)

에트리뷰트들의 무순서도 논리적인 독립성을 유지하는데 필수적인 역할을 하는 특징이다. 애트리뷰트가 무순서는 릴레이션에서 필요한 속성을 사용자로 하여금 취사 선택하도록 하고 있다. 관계 모델은 [3단계 스키마 구조]의 '개념적 스키마'에 해당되므로 모든 관점을 통합해 놓았기 때문에 애트리뷰트의 순서에 의미를 부여한다면 관계 모델은 변화에 취약하고, 최소한의 중복을 지향할 수 없게 되어 결국은 쓸모없는 모델이 된다. 그러므로 실제로 SQL에서 'select * from tableA'와 같이 '*'의 사용은 관계 모델의 특징에 반하는 것으로 종속성을 가지게 되어 유지보수 비용을 증가시키게 된다. 

애트리뷰트의 원자값은 속성의 값의 범위가 한 가지 값만을 가진다는 것을 의미한다. 원자값이라고 해서 무조건 쪼개지지 않는 단위로 쪼개는 것이 아니다. 예를 들어, 성명를 성, 명으로 쪼개는 것이 반드시 원자값은 아니다. 원자값의 원자 단위는 업무 처리가 어떻게 이루어지느냐에 따라서 다르다. 우리나라의 경우는 성과 이름을 같이 붙여서 사용하므로 성명이 원자값이지만, 외국의 경우는 결혼을 하면 성이 변경되는 경우가 있기 때문에 성, 명을 분리하는 것이 원자값이 된다. 이는 데이터 모델링이나 DB설계 단계에서 결정되는 매우 중요한 특징이다. 원자값에 대한 고려를 하지 않는다면 DB를 사용하는 사용자(사람, 정보시스템..)가 고생을 하게 된다. 이는 비용증가다.

==== 제약조건 ====
다음과 같은 제약조건이 있다. 
 * 도메인 제약 조건(domain constraints)
  * 도메인(데이터형, 길이 등)에 위배되는지..
 * 엔티티 무결성 제약조건(entity integrity constraints)
  * 릴레이션에서 각각의 투플을 유일하게 식별할 수 있는지...
 * 참조 무결성 제약조건(referential integrity constraints)
  * 제한(restricted) -> 참조하는 테이블이 있으면 삭제
  * 연쇄(cascade) -> 참조하는 테이블이 있으면 참조하는 테이블의 관계를 맺고 있는 rows도 삭제
  * 널값(nullify) -> 참조화는 테이블이 있으면 참조하는 테이블의 관계를 맺고 있는 rows를 null값으로 
  * 기본(default) -> 참조화는 테이블이 있으면 참조하는 테이블의 관계를 맺고 있는 rows를 default 값으로
 * 업무 제약 조건(business constraints)
  * 특정한 업무 제약 조건에 위배되는지..