Database2018. 4. 24. 11:15

Relational data model: 1970년대 IBM ResearchTed Codd가 처음 제시한 것으로, 특유의 간단함과 수학적인 기반으로 즉각적인 관심을 받았다. 모든 데이터와 그 사이의 관계를 테이블로 일관되게 구성하였다. 명확한 쿼리를 통해 데이터에 접근하며, 데이터 독립성을 제공한다. 두 개의 주된 RDBS 프로토타입들이 1970년대에 만들어졌으며, 그것들은 UCBIngres developedIBMSystem R이다. IngresMS SQL ServerSybase의 개발에 기여하였다. 한편, System RSQL/DS, DB2, 그리고 Oracle의 개발에 기여하였다.



관계형 모델 개념


관계형 모델: 데이터베이스를 관계의 모음으로 보여준다.


Relation (Table): 2차원 테이블로 기록의 모음이다.


Attribute (Column): 속성들은 테이블 열의 표제이다. 속성의 개수를 degree라고 부른다. 유효한 relation의 최소 degree1이다. Relationdegree는 보통 변하지 않는다.


Tuple (Row): 속성 값의 모음이다. 실제 세상의 엔티티나 관계와 대응하는 사실을 보인다. Relation의 행 전체 개수를 cardinality라고 부른다. Cardinality는 터플이 추가되거나 제거되는 것으로 증가하거나 감소한다.



Domains, Attributes, Tuples, and Relations

Domain: 각 속성에 허용된 값의 모음이다. 프로그래밍 언어에서 데이터 타입과 비슷하다. 속성 값들은 일반적으로 atomic해서 나눌 수 없다. 특별한 값 NULL은 모든 domain의 멤버이다. 여러 속성이 같은 도메인을 갖는 것도 가능하다.

Relation 스키마 R(A)Relation(혹은 relation state)r(R)로 쓴다.


Current Relation State: 모든 가능한 조합이 주어졌을 때 relation state. 실제 세상의 특정 상태를 보여주는 유효한 튜플들만 반영함.

튜플의 구성 값: t[Ai] 혹은 t.Ai는 튜플 t의 특성 Ai값을 나타낸다.



Relations의 특징

Relation에서 튜플의 순서: Relation은 튜플들의 집합으로 정의된다. 임의로 저장 될 수 있으므로 순서는 무의미하다.

튜플에서 값의 순서: 속성과 값의 순서는 속성과 값 사이의 대응 관계만 유지된다면 중요하지 않다.


Relation의 대체 정의: 각 튜플은 (속성, ) 쌍으로 간주될 수 있다. 각 쌍은 매핑 값을 제공한다.


튜플의 값들: 튜플의 각 값들은 atomic하다. Flat relational modelnested relation을 허용하지 않는다. Nested relation modelrelation model의 확장으로 도메인이 atomic할수도, relation-valued 일수도 있다.

NULL : 속성의 값이 알려지지 않았거나 tuple에 적용되지 않았음을 보여준다. 혼란을 피하기 위해서 NULL 값은 피할 수 있는 한 피해야 한다.



Relational Model Constraints

제약 조건: 유효한 값에 대한 제한이다. DB가 보여주고 있는 실제 세상의 규칙에서 파생된다.

1.     Inherent model 기반 제약 혹은 암시적(implicit) 제약: ex) Relation은 중복된 튜플을 가질 수 없다.

2.     스키마 기반 제약 혹은 명백한 제약: 데이터 모델의 스키마로 정확하게 설명될 수 있으며, 일반적으로 DDL에서 지정한다. Ex) 도메인 제약, Key 제약, 엔티티 무결성 제약, NULL 제약, 참조 무결성 제약

3.     Application 기반 혹은 시맨틱 제약 조건 혹은 business rules: 스키마에서 직접적으로 표현될 수 없다. Triggerassertion같은 일부 메커니즘이나 application program에 의해서 서술되고 강요(시행)된다.

4.     Functional & Multivalued 종속성과 같은 데이터 종속성: 주로 Relational DB 설계의 장점을 테스트하고 normalization(정규화)라 불리는 프로세스에서 사용된다.



Domain Constraints

각 속성에 허용된 값들의 집합이다. 각 튜플의 각 속성 A의 값은 도메인으로부터 atomic value여야만 한다. 데이터 타입은 도메인에 연관되어 값의 타입을 제한한다. Integer, real number와 같은 숫자형 타입과 character, Boolean, 고정/가변 길이 문자열, 날짜, 시간, 타임스탬프, 금액, 그리고 여러 특수한 데이터 타입이 있다. 속성의 기본 값, 유효값 범위, 혹은 ‘NOT NULL’ 옵션 등을 정할 수 있다. SQL2는 명확하게 도메인을 정의하는 것을 허용한다. (CREATE DOMAIN DeptNameType AS CHAR(10) DEFAULT ‘Sales’;) 도메인은 이름, 데이터 타입, 심지어는 형식까지 주어진다.



Key Constraints

Relation은 튜플들의 집합으로 정의되기 때문에, relation에 속한 각 튜플들을 구분하는 방법을 가지고 있어야만 한다. 만약 K의 값이 가능한 relation r(R)의 각 튜플들에 대해 구분하기에 충분하면, ’K Í R & K’ Rsuperkey라고 하자. Superkey K K가 더 이상 축소시킬 수 없을 경우 key이다. , K로부터 어떠한 속성 A를 제거하는 순간 R에 대한 superkey가 아니게 된다. 만약 relation 스키마가 1개 이상의 key를 가지고 있을 경우, 각각을 Candidate key라고 부른다. Candidate key 중 하나가 primary key가 되며, 다른 candidate keyssecondary keys(alternate keys)로 불리며, 고유 키로 지정된다.



RDBs and Relational Database Schemas

Invalid state: DB의 상태가 모든 무결성 제약 조건을 따르지 않았을 때

Valid state: DB의 상태가 무결성 제약 조건 집합에 속한 모든 제약 조건들을 만족시킬 때

무결성 제약 조건들은 DB 스키마에 지정되어 있으며, 그 스키마의 모든 유효한 DB 상태를 유지할 것으로 예상되도록 한다.



Entity Integrity, Referential Integrity, Foreign Keys

엔티티 무결성 제약 조건: Primary key의 값은 NULL이 될 수 없다. Relation에 속한 각 튜플들을 구분하기 위해서 primary key의 값을 사용하기 때문이다.


참조 무결성 제약 조건: relations간에 지정되며 두 relations 사이에 있는 튜플들의 일관성을 유지하기 위해서 사용된다. 비공식적으로, 다른 relation을 참조하는 한 relation의 튜플은, 그 다른 relation에 존재하는 튜플을 참조해야 한다.


Foreign key: relation에 있는 속성으로 다른 relation의 튜플을 구분할 수 있도록 해준다. Foreign key의 속성은 이것을 참조하는 relationprimary key 속성과 같은 도메인을 가진다. 또한, r1(R1)의 튜플 t1에서의 Foreign Key 값은 r2(R2)의 일부 튜플 t2에 대해 Primay key의 값이 되거나 NULL 값이다.

Foreign key는 자신의 관계를 참조할 수 있다.



다른 타입의 제약 조건들

Application 기반 혹은 시맨틱 무결성 제약 조건: Relational DB에서 지정되고 지켜져야 한다. Triggers assertions라 불리는 메커니즘이 사용될 수 있다. Application programs에서 이러한 유형의 제약 조건들을 검사하는 것도 가능하다.

Functional dependency constraint: 속성 XY로 이루어진 집합 사이에 functional relationship을 세운다. 이 제약 조건은 X의 값이 고유한 Y값을 결정하도록 지정한다(X Y). 품질을 향상하기 위해서 relations을 정규화(normalize)하는데 functional dependencies와 다른 타입의 의존성을 도구로써 사용한다.


*) Normalize: RDBS에서 중복을 최소화하게 데이터를 구조화하는 프로세스

*) Functional dependency: Relation에서 두 개의 속성 집합 간 제약의 일종.


State(Static) constraints: DB가 만족시켜야만 하는 적절한 state를 결정하는 제약 조건을 정의한다. 함수와 같이 어떠한 값을 통해 종속 관계에 있는 다른 값을 유일하게 결정할 수 있다는 것이다.


Transition(Dynamic) constraints: DB에서 state가 변경되는 것에 대응하기 위해 정의한다.



Update Operatinos, Transactions, and Dealing with Constraint Violations

Relational modeloperations는 검색과 수정으로 분류할 수 있다.

Insert, Delete, UpdateDBrelations의 상태를 변경하는 기본적인 operations들이다. operations가 적용될 때마다, 관계형 DB 스키마에 지정된 무결성 제약 조건을 위반해서는 안된다.


Delete Operation: 삭제된 튜플이 다른 튜플들에게 foreign key로써 영향을 주면 참조 무결성 제약 조건만을 위반할 수 있다.


Insert Operation: 네 가지 제약 조건 모두를 위반할 수 있다.


Update Operation: 대체로 수정되는 속성이 primary key 혹은 foreign key가 아닐 경우에는 문제를 일으키지 않는다. DBMS는 새로운 값이 알맞은 데이터 타입 그리고 도메인인지만 확인하면 된다. 하지만 Primary/foreign key를 수정하는 경우에는 Insert/Delete와 비슷한 문제가 발생할 수 있다.


참조 무결성 제약 조건 위반을 다루기 위한 4가지 옵션이 있다.

-       Restrict option: 기본 값으로, 명령을 거부한다.

-       Cascade option: 삭제하려는 튜플을 참조하는 모든 튜플들을 삭제한다.

-       Set Null 혹은 Set default option: 위반을 유발하는 참조하는 속성 값을 null이나 default 값으로 수정한다.



CREATE TABLE EMPLOYEE ( 

        EMPNO      INTEGER  NOT NULL,

        DNO          INTEGER,

        PRIMARY KEY (EMPNO),

        FOREIGN KEY (DNO) REFERENCES DEPARTMENT (DEPTNO)

               ON DELETE SET NULL; ON UPDATE CASCADE  );



트랜잭션 개념

트랜잭션: 하나의 논리적 일의 단위를 이루는 operations의 모음. 트랜잭션은 데이터 무결성을 보존하기 위해서 ACID 속성을 소유해야한다.

-       Atomicity: 트랜잭션의 모든 operationsDB 내부를 적절히 반영되거나 없어야 한다.

-       Consistency: 트랜잭션의 실행은 DB의 일관성을 보존해야한다.

-       Isolation: 각 트랜잭션은 다른 트랜잭션과 독립적으로 실행되어야 한다.

-       Durability: 트랜잭션이 성공적으로 실행되고 나서는, 시스템에 장애가 있더라도 DB에 대한 변경사항은 지속되어야 한다.


대부분의 DBS는 각 SQL문을 하나의 논리적인 일의 단위로 간주한다.


BEGIN TRANSACTION, COMMIT, 그리고 ROLLBACK(혹은 이와 동등한) 키워드들은 트랜잭션을 구분하기 위해서 DML에서 사용 가능하다.



BEGIN TRAN
     INSERT publishers VALUES (1111,
PEARSON, Seoul, ‘’, South Korea)
     UPDATE publishers SET pub_name =
Old BookWHERE pub_id = 0736

          IF @@ERROR = 0  COMMIT TRAN
          ELSE                   ROLLBACK TRAN

END TRAN


'Database' 카테고리의 다른 글

[Database] 5. The Basic SQL  (0) 2018.04.24
[Database] 3. Entity-Relationship Model  (0) 2018.04.24
[Database] 2. DB System Concepts and Architectures  (0) 2018.04.24
[Database] 1. DB and Users  (0) 2018.04.24
Posted by BinZIP