DBMS 2 - Relational Model

 

Relation Data model : ted codd 박사가 수리논리학과 집합론의 relation 개념을 가져와 관계형 데이터베이스를 만들었다. 따라서 데이터 베이스는 relation의 collection(관계의 총집합체)이다. SQL은 결국 이런 수학적 모델을 기술하는 구문이며 DBMS는 이 데이터베이스를 조작하고 연산, 컨트롤 하는 전체 시스템이다.

Relation이라는 Data structure과 Data integrity(Key & constraints = integrity), Data manipulation(relation algebra/calculus)를 통해 relation model을 구축할 수 있다. Relation은 2차원 table로 데이터를 나타내는 것이다. 즉, RDB도 역시 동일하게 데이터를 2차원 table에 저장한다.

Relation : Data structure on 2D to compare data. Head( = relation schema/intension, 데이터를 설명하기 위한 가장 맨 윗 줄의 항목들. 이들은 변하지 않는 값들이다.) 와 body( = relation instance/extension, 각 레코드 column에 알맞은 값들, 시간이 변함에 따라 값이 변화함)로 구성되어 있다. 데이터는 시간에 따라 실시간으로 변하므로 특정 시간에 가지고 있는 값들을 snapshot 혹은 instance라 한다. Relation schema = R(A1, A2 …. Ad) : R이라는 relation에 포함된 attribute {A}의 집합이다. 또한, relation instance r(R)의 schema는 tuple의 ordered list 로 고려할 수 있다. 단, 이 때 tuple은 서로 순서가 바뀌면 안되므로 (attribute, value) pair로 정의해야만 가능하다. 앞서 attribute는 서로 순서가 바뀌어도 column과 라벨 자체가 같이 바뀌므로 상관없지만, tuple의 값이 바뀌면 헤드와 맞지 않게 되므로 틀린 값이 저장되게 된다. 따라서 (attribute , value) pair로 정의가 필요하다.  

Attribute 나 tuple은 모두 집합이므로 순서라는 것이 존재하지 않는다. 따라서 관계형 데이터베이스에서 ‘몇 번쨰 데이터’ 를 가져오는 방법은 없다.

Tuple(행) : 여러 도메인에 있는 데이터들이 관계를 가지고 묶여 있는 것.

Attribute(열) : 속성, 각 인스턴스들이 가지고 있는 값들. Attribute는 반드시 서로 다른 값을 가진다. 왜냐하면 이들의 집합이 schema이기 때문(집합은 중복되지 않음).

Degree : attribute의 개수 /  Cardinality : Tuple의 개수

Domain : attribute 속성을 가지는 값의 범위. 즉, 해당 attribute column의 모든 칸의 값은 해당 도메인의 조건을 만족하는 값들이다. 수학적으로 표기하면 (Name, Type, Format)의 값을 가지는 집합이다.

 

Data structure properties.

1. tuple uniqueness (단, attribute에 따라 허용되는 경우도 있다. 그러나 수학적으로는 반드시 중복이 있으면 안된다. 집합이기 때문에)

2. uniqueness of attribute(마찬가지로 집합이므로, 또한 항목이므로 당연)

3. 4 tuple과 attribute에는 순서가 없다.(이유 동일)

5. attribute에는 같은 data type이 들어가야 한다.(Domain Integrity)

6. attribute의 값들은 반드시 단일한 값이어야 한다. 한 항목에 두 개 이상의 값이 들어가면 안된다. 이런 경우(혹은 이렇게 만드는 과정)를 Normalized(정규화) 되어 있다고 한다. 해당 데이터의 종류/품목 등의 종류에 따라 n차원이 되고, 이를 모두 분리하여 1^st normal form relation으로 만들어야 된다. (1 dimension = 1 attribute)

 

Key : 임의의 tuple을 식별하기 위해 필요한 값. 검색을 하기 위한 자료. 학번/군번 등. 따라서 Key는 반드시 tuple을 유일하게 식별할 수 있는 값이 되어야 한다. 반대로 말하면, 겹치는 값이 있는 attribute는 key가 될 수 없다. (함수가 x값 하나에 반드시 y값 하나가 매칭 되어야 하는 것과 동일)

키는 포함관계가 있는 여러 종류로 나눌 수 있다.  Super key 아래 candidate key, 그리고 그 아래 primary key가 있다. Super key는 가장 근간이 되는 key이다. 모든 tuple을 유일하게 식별할 수 있는 attribute의 subset. 그러나 한 개의 attribute만으로는 유일하게 식별이 안되는 경우에는 두 개 이상의 attribute를 선택할 수도 있다. 이런 조건을 만족하는 키들 중에 attribute를 최소로 선택할 수 있는(최소 조건 만족) key를 candidate key라 한다. 또한, 이 후보군에서 내가 사용하기로 결정한 키가 Primary key이다. (따라서 SK > CK > PK의 포함관계가 된다. 또한 SK가 결정되면 CK는 바로 결정된다. 또한 Candidate key 중 primary key로 선택되지 않은 여집합 = alternate key) 따라서 candidate key 계산 단계, Primary key 선택 단계의 두 단계가 필요하다. 또한 이는 정답이 없으므로 최대효율을 내는 키를 잘 찾아야 한다.

Foreign key : 어떤 relation의 attribute가 다른 relation을 참조하여 값을 찾을 수 있게 해주는 키. 예를 들어 이름과 학번이 있을 때, 이름으로 학번을 찾고, 이 학번으로 다른 표에서 이 학번의 성적을 찾게 해주는 경우에 학번이 외래 키가 된다. 그러나 이 역시도, 다른 relation(표)에서 값을 찾을 때 반드시 primary key를 참조해야 유일한 tuple을 찾을 수 있다. 따라서 이 역시도 키라고 부른다.

 

Data Integrity(constraint)

1. entity integrity : 각 데이터가 무결하기 위해 필요한 조건. PK인 attribute에는 null이 있으면 안된다. Pk는 tuple을 유일하게 식별할 수 있어야 한다. Pk는 attribute의 minimal set이어야 한다. (앞에서 key를 정의할 때 모두 말한 것들. 이들을 만족해야 한다.) 따라서 primary key가 잘 설정되어 있다면 개체의 무결성은 대부분 완성된다.

2. referential integrity : 참조 관계(Foreign Key)에서의 무결성. 이들은 데이터 삽입/업데이트/삭제 에서 발생할 수 있는 문제를 예방한다. 삽입에 있어서는 참조하는 relation에 없는 ID 데이터는 삽입할 수 없는 것, 수정이나 삭제에 있어서 참조하는 데이터의 변경을 반영해야 하는 것이 모두 자동으로 되야 하는 것이 참조 무결성이다. 즉, 연결된 referencing하는 relation은 referenced relation의 변화를 당연히 반영해야 하는 것이다. (FK를 잘 설정하면 일반적으로 문제없이 잘 됨. 단, referenced의 값이 변화될 때 그대로 받거나, 삭제하거나, 새로운 것으로 받아들이는 것 등으로는 내가 설정할 수 있다)

그러나 실제로는 이를 안 적용하는 경우도 많다. 왜냐하면 이런 relation이 존재하면 referencing하는 관계에 따라 ordering이 생겨서 데이터를 순서대로 전부 넣어줘야 하기 때문이다. 또한, 여러 사람이 동시에 데이터베이스에 접속할 때, 어떤 사람이 하나의 relation을 보고 있을 때도 연결된 referenced relation이 모두 잠길 수가 있다. 따라서 이 참조 무결성은 안지키는 경우도 많다.

3. Domain integrity : 도메인은 (이름, 타입, 포맷)으로 구성되어 있으므로 comparability(비교), type enforcement(타입을 설정)가 되야 한다. 그러나 타입을 설정해도 입력하는 사람이 서로 다르게 표현할 수도 있기 때문에 format을 설정하고 디자인하는 문제와 밀접하게 관련이 있다.

4. Business Rules(semantic integrity) : 실제 현실에 존재하는 제약사항을 넣기가 매우 어렵다. 그러나 실제 사용하는 입장에서는 이런 업무 규칙이 반드시 지켜지길 바란다. 따라서 이런 요구사항을 식별하여 DB 또는 그것을 사용하는 애플리케이션에 적용하는 것이 중요하다.(이것도 역시 어디에서 밴을 먹일 것인지 결정하는 것도 어려운 문제다) 그리고 이런 요구사항을 문서화하고 체계화 하는 것이 중요하다. 또한 이러한 설계가 어려운 이유는 요구사항이 변화할 수 있기 때문에 이를 수용할 수 있는 확장성을 갖출 수 있어야 하기 때문이다.

SQL은 relation을 받아서 relation을 반환하는 함수의 집합으로 정의할 수 있다. 관계 연산을 통해 Create, read, update, delete 등의 process를 할 수 있게 하는 것.

인위적으로 key를 만드는 것(ID 등) : surrogate key, 이미 있는 attribute로 FK/PK를 사용하는 것이 Natural key가 된다. 이 두 키를 쓸 수 있는 상황이 각각 정해져 있고, 일반적으로는 자연키를 쓰는 것이 좋다. 왜냐하면 새로 attribute(column)을 안 만들어도 되기 때문이다. DB의 크기가 커질수록 attribute 하나가 늘어날수록 크기가 기하급수적으로 늘어난다. 반면에 자연키를 쓰면 이런 문제가 없다. 반대로, attribute를 묶어서 복합 자연키로 사용하는 경우에는 key 자체의 크기가 커진다는 문제가 있다. DB 내부에서는 이 pk를 index 자료구조로 사용하기 때문에 이 기본 사이즈가 커질수록 부담이 증가한다. 따라서 지나치게 많은 attribute를 묶어서 사용하면 DB가 느려지고 자료구조의 크기가 지나치게 늘어난다.

또한 relation을 따로 분리하여 만드는 것과 합쳐서 만드는 것도 차이가 있다. 이는 정규화 기법을 통해 결정할 수 있다. 적당히 분리된 relation으로 구성되는 것이 (그림이 예쁜 상황) 이상적이다.

Constraint : 어떤 attribute가 가져야 하는 제약 조건. Integrity와 거의 비슷하지만 개념이 살짝 다르다. 해당 attribute는 반드시 혹은 절대로 PK, FK, Not null, unique, default, check(확인 조건) 가 되거나 되지 말아야 하는 등의 조건이 있다.