[DB개념] :: The Relational Data Model (관계형 데이터 모델)

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

3 Steps to data modeling
STEPS	설명
1. 개념적 데이터 모델링	업무중심적이며 포괄적인, 추상적 모델링
2. 논리적 데이터 모델링	구축하고자 하는 업무에 대해 Key, Attribute, Relation 등을 정확하게 표현. (재사용성 높음)
3. 물리적 데이터 모델링	실제로 DB에 이식할 수 있도록 성능, 저장 등 물리적인 성격까지 고려하여 설계

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

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은 그림과 같이 구성되어 있다.

Relation
구성요소	설명
Attributes	table의 맨 위에 표시되며 각 column의 이름을 명세  (E/R Model의 entity set과 동일)
Tuples	table 맨 윗줄을 제외한 나머지 행들을 각각 일컬음  각 attribute에 대해 하나의 구성 요소를 가짐  괄호와 쉼표를 사용하여 표기한다.  예 : (Star Wars, 1977, 124, color)
Instance	relation의 주어진 모든 tuple들의 집합을 칭함
Component	table의 한 '칸'을 의미

Schemas

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

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

Words
이름	설명
필드(Field)	어떤 의미를 지니는 정보의 한 조각으로,  DB 시스템에서 처리의 최소 단위를 뜻함
레코드(Record)	정보를 처리하는 기본적인 단위로,  필드(혹은 다른 items)의 모임을 뜻함
도메인(Domain)	필드 값에 주어지는 값의 유효한 범위  (어떠한 조건을 만족하는 범위)를 정해줌  수학에서는 정의역

각 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) 등이 있다.

Constraints
종류	설명
도메인 제약조건 (Domain constraint)	각 component들이 Data type/size 등 도메인에 위배되는지에 대한 제약조건
엔티티 무결성 제약조건 (Entity integrity constraint)	Entity의 기본 키(Primary key)를 구성하는 어떤 열도 NULL 값을 포함할 수 없다는 것에 대한 제약조건
참조 무결성 제약조건 (Referential integrity constraint)	외래 키(Foreign key)의 값은 참조된 relation의 기본 키 값들 중 하나와 같다는 제약조건

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)라고 따로 정의하기도 한다.

마침.