The Relational Data Model

Data modeling

What is data modeling?

• 컴퓨터에 저장할 데이터의 구조를 논리적으로 표현하기 위한 행위.
• 주어진 개념으로부터 논리적인 데이터 모델을 구성하는 작업을 말하며,
  일반적으로 이를 물리적인 데이터베이스 모델로 환원하여 고객의 요구에 따라
  특정 정보 시스템의 데이터베이스에 반영하는 작업을 포함한다.
• DB구조 기반으로 데이터, 데이터 관계, 데이터 의미, 데이터 제약 등을 기술하기 위한 개념적 표현 방법.
• 시스템의 대상이 되는 업무를 분석하여 정보시스템으로 구성하는 과정에서 
  업무의 내용과 정보시스템의 모습을 적절한 표기법으로 표현하는 것.
  
  

즉, 추상적인 데이터베이스 구조를 가시적으로 구현화(형태화)시키는 것으로, 
데이터베이스 설계 시 어려움을 도와주는 등의 역할을 한다. 

Why do we use it?

• Leverage(파급력) : 계속 변화되는 데이터들을 변경하는 데 용이하다. 즉, 유지보수의 이점이 있다.
• Conciseness(간결한 표현) : 설계도면처럼, 가시적인 Diagram으로 표현하여
  복잡한 유저들의 요구를 쉽게, 직관적으로 이해할 수 있다.
• Data Quality(품질) : 데이터들의 중복, 비유연성, 비일관성 등 기존 file system의
  단점들을 극복할 수 있다.
  
  

3 Steps to data modeling

아래로 내려올수록 구체적이며 위에 있을수록 추상적이다.

Relational Data Model

About Relation

• Data를 담은 2차원 Table, ROW(행)과 COLUMN(열)로 이루어진다.
  
• Relation의 특징
  
  1. 튜플의 유일성, 무순서
     
     • 유일성 : 각각의 튜플을 식별할 수 있어야 한다. 즉, 릴레이션에서 애트리뷰트들의 값의 조합이 유니크 해야한다. 
       ( 물론 1개로도 각각의 튜플을 식별할 수 있어도 상관없다. )
       
     • 무순서 : 순서를 부여하면 오히려 품질을 떨어트릴 수 있다. 튜플의 순서는 가치판단의 기준이 되는 것이 아니기 때문이다. 
       
  2. 애트리뷰트들의 무순서, 원자값 
     
     • 무순서 : 마찬가지로, 필요한 속성을 사용자로 하여금 취사 선택하도록 설계되었다. 
       오히려 순서에 의미를 부여하면 변화에 취약하게 되어 유지보수 비용이 증가될 염려가 있다.
       
     • 원자값 : 속성의 값의 범위가 하나여야만 한다는 의미이다. 그렇지 않으면 역시 비용이 증가될 염려가 농후하다.
       
       

Then, What is RDM?

Relation을 이용한 Data model

데이터를 표현하는 방법 중 하나인 '데이터 모델'의 여러 갈래 중 하나이며
설계의 의미보단 '데이터를 어떻게 표현할까'하는 개념적 의미이다.

Issues about RDM

• 단순하며 유용하다. (실제로 DB implementation의 대부분이 RM 기반)
• SQL(Structured Query Language)이라는 high-level language를 이용하여 Relation의 Data를 원하는 대로, 쉽게 조작할 수 있다.
  
  

Design

• Design 측면에서는, E/R(Entity Relationship) 표기법을 기반으로,
  Entity(개체), Relationship(관계), Attribute(속성)들을 적절하게 
  RM 표기법으로 변형하여 Design 할 수 있다.
  
• 이러한 설계 방식으로 각 Relation 간의 제약(Constraint), 함수 종속(Functional Dependency), 
  Key 등을 명확하게 이해하고, 보다 정확한 Relation을 설계할 수 있다.
  
  

Structure of RDM

RDM은 그림과 같이 구성되어 있다.

Schemas

Data Model에 대해 이야기할 때 항상 'Schema(스키마)'를 언급한다.
Schema란, DB를 구성하는 레코드의 크기, 키(key), 레코드들의 관계(relationship), 
검색 방법 등 '자료를 저장하는 구조와 표현법을 정의한 것'이라고 칭할 수 있다.
relation 이름 뒤에 괄호로 묶어 표기하며 (예 : Movies(title, year, length, filmType))
Relational database schema (혹은 그냥 Database schema)라고 한다.

주의 : 여기서 attributes들은 list등의 레코드가 아니라 set이다 !

각 component 값들은 structure, set, list 등의 record 타입이 아닌, atomic해야 한다. 
또한 같은 column에 존재하는 component 값들 모두 같은 타입(이거나 정해진 값 중 하나)이어야 한다.

Relation은 tuple들의 set이기 때문에 제시된 tuple들의 '순서'는 중요하지 않다.
즉, tuple들의 순서가 바뀌어도 동일한 Relation으로 본다.
더 나아가 attribute들의 순서 역시 재배치할 수 있다.
하지만 데이터가 섞이거나 변경되는 일 없이 재배치해야 한다. 
결과적으로 각각의 tuple은 attribute 순서대로 정렬된다.
그러므로 그림과 같은 두 개의 Relation은 완전히 '같다' 라고 할 수 있다.

 

Schema vs Instance

스키마와 인스턴스의 구별은 확실히 해두자.
스키마는 Relation의 attribute와 name이며 대개 '변하지 않는다.'
반면, 인스턴스는 tuple의 집합으로 값이 바로바로 변한다.
디자인 시 인스턴스는 고려하지 않는다.
다만, 어떤 구조로 설계할 지만 고려하자.

Functional Dependencies

Constraint

E/R design을 Relational schema로 컨버팅 시 Application의 요구에만
Relational schema를 제공하면 큰 위험이 따를 수 있다. ( 바꾸기 쉽지 않음에도 불구하고 )
또한 별개로 빈번히 특정 제약(Constraint)에 얽매일 수밖에 없다. 이 때 생기는 제약들 중
가장 중요한 것은 'Functional dependency'(이하 FD)라고 불리는 unique-value 제약이다.
이 제약은, 중복을 제거하는 Database redesign에 있어 아주 위험할 수 있다.
이 밖에도, 도메인 제약조건(Domain constraint), 참조 무결성(Referential integrity) 등이 있다.

NULL value

널 값(null value)은 공백, 0, 길이가 0인 문자열들과는 다른, 말 그대로의
아직 입력되지 않은 데이터를 의미한다. RM에서 NULL 허용을 하면,
한 개의 Relation으로 모든 데이터를 표현할 수 있다는, 이론상으로 좋아보이지만
쿼리 및 갱신이 복잡해지며 제약 조건을 위배할 수 있다는 문제점도 따른다.
따라서, 일반적으로 NULL 값은 허용하지 않는 것이 좋다.

Definition of Functional Dependency

Relation R의 두 튜플 T1, T2에 대해 n개의 attribute(A1, A2, ... An)값이 같다면
T1, T2의 m개의 attribute(B1, B2, ... Bn)도 반드시 같은 값이다.
즉, An이 결정되면 그 값에 따른 Bn도 단 하나의 값으로 결정된다.

• 표기 : A1A2...An -> B1B2...Bn
  

Functional dependency의 'Functional'이란?

마치 정의역의 한 값을 대입하면 그에 해당하는 치역이 단 한 개만 나온다는
수학의 'function'과 같기 때문 ! 

Keys of Relations

Key란, 

1. Relation 내 다른 모든 attributes를 unique하게 결정하는(hold, identify) attribute(s)이다.
   즉, 두 개의 distinct한 tuple의 모든 attribute값들은 각각 다 다른값이다.
2. Key 외엔 다른 attribute를 unique하게 결정하는 다른 부분집합이 없어야 한다.
   즉, Key는 minimal해야 한다. (key가 하나의 attribute A를 포함하면, A를 key라고 한다.) 
   
   

Key is minimal, not minimum'''

• Primary key : 여러 key 중 user가 지정한 key를 일컫는다.
  (Implementation issue가 될 수 있기 때문에 underline으로 명확하게 표시함)
  
• Superkeys(Superset of key) : Key의 제약이 걸려있는 attribute(들).
  Key는 모두 Superkey이지만, Superkey이면 Key는 아니다. (minimal의 조건)
  
• Foreign key : 다른 Relation의 Primary key attribute를 참조하는 key로,
  참조 무결성 제약조건과 더불어 두 Relation들의 일관성을 유지하는 데 사용한다.
  또한 외래 키는 일종의 'key'개념이라고 보기엔 다소 무리가 있다.
  
  

혹자는 Key개념을 다르게 설명한다. 

Superkey 중 최소의 Key(s)를 
후보 키(Candidate Key)라고 따로 정의하기도 한다.

마침.