1 RDBMS
1.1 관계형 데이터베이스 모델(Relational DatBbase Model)의 특징
- 현실세계를 데이터베이스에 표현하기 위해 데이터, 데이터 간의 관계, 데이터가 가진 의미 및 데이터 제약 조건 등을 단순화하고 추상화된 형태로 표현하는 개념적 모형이다.
- 상대 수학적인 이론을 기반으로 한다. 특히, 집합론과 논리 분야의 개념을 사용했다.
- 데이터 모델을 개발하기 위해서 테이블 관계로 묘사하는 이론적 모델 과정이 발생하는데 이를 개체 관계 모델(Entity Relaional Model)이라고 한다.
- 테이블 형식의 데이터를 조작할 수 있는 관계 연산자를 제공한다.
- 개체를 관심 있는 속성에 따른 형태로 표현하는 것이다.
- 개념적인 데이터 모형을 데이터베이스에 저장하기 위해 DBMS에 적합한 구조로 생각하는 것이다.
s 관계형 데이터 모델: 데이터와 데이터 간의 관계를 2차원 테이블로 표현
s 계층형 데이터 모델: 네트워크 데이터 모델, 객체 지향 데이터 모델 등
1.2 주요 RDBMS
|
이름 |
특징 |
|
Oracle |
전 세계에서 가장 많이 사용하는 상용 RDBMS |
|
Access |
Microsoft사 Office군의 RDBMS |
|
Microsoft SQL Server |
Microsoft사의 상용 EDBMS |
|
PostgreSQL |
MySQL과 마찬가지로 오픈 소스 RDBMS |
|
MySQL |
전 세계에서 가장 많이 사용되는 오픈 소스 RDBMS |
1.3 관계형 데이터베이스의 기본 용어
- 관계형 데이터베이스의 논리적 구조를 나타내는 여러 행과 열로 이루어진 2차원적 구조의 메트릭스이다.
- 즉, 테이블(Table)이라고도 한다.
- 릴레이션의 행을 의미한다.
- Cardinality: 한 릴레이션 내에 포함된 튜플의 개수이다.
- 릴레이션의 열을 의미한다.
- 도메인(Domain): 하나의 속성이 가질 수 있는 값의 집합을 말한다.
- 차수(Degree): 한 릴레이션 내에 포함된 속성의 개수이다.
- Tuple의 유일성: 한 릴레이션 내에서 튜플들은 모두 서로 다른 데이터를 가지고 있어야 한다는 성질을 가진다.
- Tuple의 무순서성: 한 릴레이션 내에서의 튜플의 순서는 무의미한 것이다.
- Attribute의 무순서성: 한 릴레이션 내에서의 속성(Attribute)의 순서 역시도 무의미하다.
- Attribute의 원자성: 릴레이션 내의 모든 속성의 값은 더 이상 분해할 수 없는 원자 값이어야 한다.
1.4 키(Key)의 종류
1.4.1 슈퍼키 (Super Key)
- 데이터베이스에서 관계의 행을 고유하게 식별할 수 있는 속성 또는 속성의 집합을 말한다.
- 슈퍼키는 대상관계의 모든 속성이 함수 종속하는 속성의 집합으로 정의할 수 있다.
- 후보키와의 차이는 슈퍼키는 고유하게 식별하는 모든 조합을 뜻한다는 점이다. 즉, 후보키에 불필요한 속성을 덧붙여 장황하게 한 것은 후보키는 아니지만 여전히 슈퍼키이다.
1.4.2 후보키 (Candidate Key)
- 행의 식별을 위해 필요한 특성 또는 그 집합을 뜻한다.
- 슈퍼키 중 더 이상 줄일 수 없는 형태를 가진 것을 말한다. 더 이상 줄일 수 없다는 것은 슈퍼키를 구성하는 속성 중 어느 하나라도 제외될 경우 유일성을 확보할 수 없게 되는 것을 말한다.
- 행의 식별자이다. 후보키라는 이름은 그것이 기본키로 선정될 수 있는 후보이기 때문이다.
1.4.3 기본키 (Primary Key)
- 관계형 데이터베이스에서 조(레코드)의 식별자로 이용하기에 가장 적합한 것을 관계(테이블마다 단 한 설계자에 의해 선택, 정의된 후보키를 말한다.
- 관계에 저장된 레코드를 고유하게 식별하는 후보키(속성 또는 속성의 집합) 가운데, 설계자가 일반적으로 이용되어야 한다고 정해 놓은 것을 가리킨다.
- 기본키에는 NULL의 존재가 허용되지 않지만, 후보키에는 허용되는 차이가 있다. 따라서 반드시 기본키를 사용해야만 하는 경우가 아니면, 다른 후보키로 대체가 가능하다.
1.4.4 대리키 (Alternate Key)
- 후보키 중 기본키로 설정되지 않은 키를 말한다.
1.4.5 외래키 (Foreign Key)
- 한 테이블의 키 중 다른 테이블의 튜플(행)을 식별할 수 있는 키를 말한다.
1.5 데이터의 구성 및 표현
- 데이터베이스에 표현하려고 하는 유형적이거나 무형적인 정보의 대상이다.
- 속성(Attribute): 개체가 가지는 자신의 특성, 데이터베이스에 저장되는 중요한 부분이다.
- 도메인(Domain): 한 속성이 취할 수 있는 모든 값이다.
- 개체 인스턴스[1](Instance): 개체를 나타내는 실제 값이다.
1.5.2 속성 (Property)
- 개체의 특성을 표현한 것으로 값을 가질 수 있다.
- 하나의 개체는 관련된 여러 속성들로 이루어진다.
1.5.3 개체 타입 (Entity Type)
- 동일한 속성들로 이루어진 개체들의 집합에 대한 스키마를 의미한다.
- 두 개 이상의 개체들 사이의 연관성을 의미한다.
- 속성 관계: 어떤 특정 개체를 표현하는 속성들 간의 관계이다.
- 개체 관계: 개체 집합 사이의 관계이다.
1) 1 : 1 관계
- 하나의 개체 집합에 속한 하나의 개체가 반드시 다른 개체 집합의 개체와 일대일로 대응하는 관계이다.
2) 1 : N 관계
- 가장 일반적인 형태의 관계이다.
- 한 개체가 다른 개체 집합에 있는 여러 개체와 대응하는 관계이다.
3) M : N 관계
- 두 개체집합 상호간에 일대다 관계가 성립하는 관계이다.
1.6 무결성 제약조건
1.6.1 개요
- 데이터의 정확성 또는 유효성을 의미한다.
- 일관된 데이터베이스 상태를 정의하는 규칙들을 묵시적 또는 명시적으로 정의하기 위함이다.
- 대부분의 프로그래밍 언어에서 데이터 타입을 선언하기 위해 제공되는 기능들을 포함한다.
- 데이터베이스 보안 문제는 권한이 없는 사용자가 데이터베이스를 접근하여 검색하거나 갱신하지 못하도록 데이터베이스를 보호하는 반면에, 데이터베이스 무결성은 권한을 가진 사용자들로부터 데이터베이스의 정확성을 지키는 것이다.
- 무결성 제약조건의 장점은 스키마를 정의할 때 일관성 조건을 오직 한 번만 명시하고, 데이터베이스가 갱신될 때 DBMS가 자동적으로 일관성 조건을 검사하므로 응용 프로그램들은 일관성 조건을 검사할 필요가 없다는 점이다.
1.6.2 특징
- 스키마의 한 부분이다.
- 데이터베이스의 상태(또는 상태들의 순서)에 대한 제한을 한다.
- DBMS가 시행된다.
- 릴레이션 내의 무결성 제약조건: 오직 한 릴레이션만 포함한다. (릴레이션 스키마의 한 부분)
- 릴레이션 사이의 무결성 제약조건: 여러 릴레이션을 포함한다. (릴레이션 스키마 또는 데이터베이스 스키마의 한 부분)
1.6.3 도메인 제약조건 (Domain Constaint)
- 가장 간단한 형태의 제약조건이다.
- 각 애트리뷰트 값이 반드시 원자 값이어야 하며, 데이터 형식을 통해 값들의 유형(정수형, 실수형, 문자형 등)을 제한하고, 애트리뷰트의 default 값을 지정하고, 애트리뷰트에 저장되는 값들의 범위를 제한할 수 있다. 또한, 릴레이션 정의할 때 애트리뷰트 선언에 ‘NOT NULL’ 구분을 붙이면 모든 튜플에서 해당 애트리뷰트의 값이 존재하도록 보장한다.
1.6.4 키 제약조건 (Key Constraint)
- 키 애트리뷰트에 중복된 값이 존재해서는 안 된다는 것이다.
- 릴레이션을 정의할 때 기본키로 정의하거나 UNIQUE를 명시한 애트리뷰트에는 중복된 값이 허용되지 않는다.
1.6.5 기본키와 엔티티 무결성 제약조건 (Entity Integrity Constraint)
- 기본키는 튜플들을 고유하게 식별하고, 효율적으로 빠르게 접근하는데 사용된다.
- 두 개 이상의 튜플이 동일한 기본키 값을 가질 수 없다.
- 기본키를 구성하는 애트리뷰트가 널 값을 가지면 튜플들을 고유하게 식별할 수 없게 되므로 엔티티 무결성 제약조건은 릴레이션의 기본키를 구성하는 어떤 애트리뷰트도 널 값을 가질 수 없다는 것이다.
- 이 제약조건은 대체키에는 적용되지 않는다.
1.6.6 외래키와 참조 무결성 제약조건 (Referential Integrity Constraint)
- 도메인 제약조건과 엔티티 무결성 제약조건 등은 각 릴레이션에 적용된다. 그러나 두 엔티티 간의 관계 모델에서는 릴레이션으로 표현된다.
- 참조 무결성 제약조건은 두 릴레이션의 연관된 튜플들 사이의 일관성을 유지하는데 사용된다.
- 관계 데이터베이스가 포인터 없이 오직 릴레이션들로만 이루어지고, 릴레이션 사이의 관계들이 다른 릴레이션의 기본키를 참조하는 것을 기반으로 하여 묵시적으로 표현되기 때문에 외래키의 개념이 중요하다.
1.6.7 무결성 제약조건의 유지
- 데이터베이스가 모든 무결성 제약조건을 만족한다고 가정하면, 데이터베이스에 대한 검색 연산의 수행 결과는 아무런 제약조건을 위배하지 않는다.
- 그러나 데이터베이스에 대한 갱신 연산의 수행 결과에 따라서는 무결성 제약조건이 위배될 수 있다.
- DBMS는 각각의 갱신 연산에 대하여 데이터베이스가 무결성 제약조건들을 만족하도록 조치를 취한다.
- DBMS는 외래 키가 갱신되거나, 참조된 기본키가 갱신되었을 때 참조 무결성 제약조건이 위배되지 않도록 해야 한다.
- 참조 무결성 제약조건의 유지를 위해 DBMS는 갱신 연산을 거절하거나, 갱신을 전차하여 다른 갱신들이 자동적으로 수행되도록 한다.
1.7 트리거(Trigger)와 주장(Asertion)
- 테이블 정의와 별도로 데이터베이스의 무결성을 시행하는 메커니즘이다.
- 하지만 제약조건이 트리거보다 성능이 우수하고, 코딩이 불필요하고, 선언하고 수정하기가 용이하므로 가능하면 제약조건을 사용하는 것이 좋다.
1.7.1 트리거 (Trigger)
- 명시된 이벤트(DB의 갱신)가 발생할 때마다 DBMS가 자동적으로 수행하는 사용자가 정의하는 문(프로시저)이다.
- 데이터베이스의 무결성을 유지하기 위한 일반적이고 강력한 도구이다. 이를 위해 데이터베이스 갱신을 모니터링하고, 데이터베이스 갱신을 전파한다.
- 트리거를 이벤트-조건-동작(ECA[2]) 규칙이라고도 부른다.
- 트리거가 데이터베이스의 일관성을 유지하는데 매우 유용하지만 트리거를 과도하게 사용하면 복잡한 상호 의존성을 야기할 수 있다. 대규모 데이터베이스 응용에서는 복잡한 상호 의존성을 관리하는 것이 어렵다.
- 각 사용 관계 DBMS마다 표준과 조금씩 다른 구문을 사용한다.
- MySQL은 각 테이블에 각 형태의 단 하나의 트리거만 허용한다. (즉, 인서트 이전에 하나, 인서트 이후에 하나, 업데이트 이전에 하나, 업데이트 이후에 하나, 삭제 전후에 각각 하나씩)
- MySQL은 구문을 외부에서 격발하지 않는다. (즉, API, 외래 키 캐스캐이드)
- 트리거의 형식
|
CREATE TRIGGER <트리거 이름> AFTER <트리거를 유발하는 이벤트들이 OR로 연결된 리스트> ON <릴레이션> [WHEN <조건>} BEGIN <SQL문(들)> END |
← 이벤트 ← 조건 ← 동작 |
1.7.2 주장 (Assertion)
- 주장의 조건은 그 조건을 위배할 가능성이 있는 각 갱신문마다 검사된다.
- 트리거는 제약조건을 위반했을 때 수행할 동작을 명시하는 것이고, 주장은 제약조건을 위반하는 연산이 수행되지 않도록 하는 것이다.
- 주장은 트리거보다 좀 더 일반적인 무결성 제약조건이다.
- 일반적으로 두 개 이상의 테이블에 영향을 미치는 제약조건을 명시하기 위해 사용된다.
- 주장이 명시되었을 때, DBMS는 이 주장의 유효성을 검사한다. 그러므로 주장이 복잡하면 유효성 거사가 상당한 오버헤드(질의의 평가)를 유발할 수 있으므로 주장을 신중하게 사용해야 한다.
- 도메인 제약조건과 참조 무결성 제약조건은 주장의 특별한 유형이다. 여러 테이블이 연관되어 도메인 제약조건과 참조 무결성 제약조건으로 표현할 수 없는 제약조건도 주장으로 명시할 수 있다.
- 주장의 형식
|
사용 예 |
CREATE ASSERTION 이름 CHECK 조건 ; |
[1] 일반적으로 실행 중인 임의의 프로세스, 클래스의 인스턴스 내의 오브젝트를 가리킴.
[2] ECA: Event – Condition - Action
'와사비크래커 IT Tip > DB' 카테고리의 다른 글
| [DB] SQL (Structured Query Language) (0) | 2020.08.24 |
|---|---|
| [DB] 관계 대수와 관계 해석 (0) | 2020.08.24 |
| [DB] Data Model (0) | 2020.08.21 |
| [DB] DBMS (Database Management System) (0) | 2020.08.20 |
| [DB] DBS (Database System) (0) | 2020.08.20 |
