- 관계 데이터 모델의 정의는 무엇인가?
- 관계 데이터 모델을 사용하는 이유?
- 도메인의 예시와 장점은?
- 릴레이션의 4가지 특성
- 키의 종류와 차이점
- 기본키를 선택할 때 고려해야 하는 기준?
- 기본키를 참조하는 외래키의 특성 (이름 동일 여부, 도메인 동일 여부)
- 외래키의 특성 (외래키는 기본키만 참조할 수 있는가?)
- 무결성 제약조건의 종류와 예시
관계 데이터 모델의 개념
관계 데이터 모델이란 무엇인가?
데이터베이스 시스템을 구현하기 위해선, 먼저 개념적 모델링을 통해 데이터베이스에서 다룰 개념들 간의 관계를 정의해야 한다. 일반적으로 개체-관계 모델을 이용하며, E-R 다이어그램을 도구로 사용한다. 이후 개념적 모델링 결과물을 이용하여 데이터베이스의 테이블과 컬럼, 각 테이블의 관계, 제약 조건 등을 정의하는 것을 논리적 데이터 모델링이라 한다.
논리적 데이터 모델 중 가장 대표적인 것이 바로 관계 데이터 모델로서, 데이터를 표현하고 저장하는 데 가장 널리 사용된다.
관계 데이터 모델의 기본 용어
릴레이션 (relation)
행과 열로 구성된 테이블을 의미한다.
속성 (attribute) | 열 (coloum)
릴레이션의 열을 의미한다. 위 고객 릴레이션에는 고객과 관련된 여섯 가지 중요한 데이터를 속성으로 가진다.
튜플 (tuple) | 행 (row) [ 인스턴스 (instance) & 레코드 (record) ]
릴레이션의 행을 의미한다. 위 예시에서 각 튜플은 고객 한 명에 대한 실제 속성 값 6개를 모아놓은 것으로, 고객 개체의 인스턴스다.
튜플, 레코드, 인스턴스는 엄밀히 따지면 문맥에 따라 다른 의미를 가질 수 있다.
- 튜플 : 수학에서 정의된 개념으로, 순서가 있는 고정된 길이의 요소(element)들의 집합으로 구성된다.
- 레코드 : 데이터베이스의 테이블에 저장되는 개별 항목을 나타내는 데 자주 사용된다.
- 인스턴스 : 개체 지향 프로그래밍에서 정의된 개념으로, 클래스를 기반으로 생성된 실제 객체를 나타내는 용어이다.
도메인 (domain)
속성이 가질 수 있는 값의 범위(range)를 정의하는 데이터 타입과 제약 조건의 집합이다.
예를 들어 "성별"이란 속성이 있다. 성별은 '남성' 또는 '여성'이라는 값만 가질 수 있다.
또 "고객 등급"이란 속성이 있다면, 'bronze', 'silver', 'gold' 중 하나만 선택할 수 있다.
이렇게 속성의 도메인(영역)을 정의해둬 속성 값 입력과 수정에 있어서 데이터베이스 시스템이 적합성을 판단할 수 있게 만든다. 이는 항상 올바른 값만 유지할 수 있다는 장점을 가진다.
물론 위와 같이 속성 값의 도메인을 명확히 구분할 수 없는 경우가 더 많다. "고객 이름", "고객 나이", "고객 주소"는 특정 값으로 한정지을 수 없기 때문이다. 그래서 일반적으로 속성의 특성을 고려한 데이터 타입으로 정의한다. 고객 이름과 고객 주소 속성의 도메인은 CHAR(20), 즉 문자 20개로 구성된 문자 타입으로 정의하며, 고객 나이는 INT, 즉 정수 타입으로 정의하는 것이다. 따라서 데이터 타입을 도메인으로 이해해도 무방하다.
동일한 도메인이란 뜻은 똑같은 데이터 타입이라는 의미이다. 그래서 도메인이 같은 속성 값끼리의 비교가 가능하지 여부도 쉽게 알 수 있다.
데이터베이스 시스템에서는 도메인을 정의하고, 이를 속성에 할당함으로써 데이터의 무결성을 보장하고, 잘못된 데이터가 저장되는 것을 방지할 수 있다.
null 값
릴레이션에 있는 특정 튜플의 속성 값을 모르거나, 적합한 값이 없는 경우에 사용한다.
널 값은 특정 속성에 해당되는 값이 없음을 나타내기 때문에 숫자 0이나 공백 문자와는 다르다.
차수 (degree)
하나의 릴레이션에서 속성의 총 개수를 의미한다. 당연히 모든 릴레이션은 최소 1 이상의 차수를 유지해야 한다. 일반적으로 차수는 잘 변하지 않는 정적인 특징을 가진다.
카디널리티 (cardinality)
하나의 릴레이션에서 튜플의 총 개수를 의미한다. 튜플이 없는 릴레이션은 존재할 수 있으며, 새로운 튜플이 계속 삽입되거나 기존 튜플이 삭제될 수 있으므로 릴레이션의 카디널리티는 일반적으로 자주 변한다는 동적인 특징이 있다.
데이터베이스와 릴레이션 구성
데이터베이스 스키마
데이터베이스는 여러 개의 릴레이션으로 구성된다. 예를 들어 인터넷 쇼핑몰을 위한 데이터베이스는 "고객 릴레이션", "상품 릴레이션", "주문 릴레이션"으로 구성할 수 있다.
데이터베이스 스키마는 데이터베이스를 구성하는 릴레이션들의 스키마를 모아놓은 것이다. 그래서 특정 데이터베이스 스키마를 설계한다는 것은 필요한 모든 릴레이션의 스키마를 모두 정의한다는 뜻이다.
데이터베이스 인스턴스
어느 한 시점에서 데이터베이스에 저장된 데이터 내용의 전체 집합을 의미한다. 즉, 데이터베이스를 구성하는 모든 릴레이션의 인스턴스를 모아놓은 것이다.
릴레이션 스키마
릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조다.
릴레이션 스키마는 DBMS가 내부적으로 DDL을 이용해 정의하는데, 일반적으로 다음과 같은 형태로 표현한다.
릴레이션이름(속성이름1, 속성이름2, ... , 속성이름n)
ex) 고객(고객아이디, 고객이름, 나이, 직업, 전화번호, 등급)
릴레이션 스키마를 보면 릴레이션의 이름과 어떤 속성들로 구성되어 있는지 전체 구조를 파악할 수 있다.
릴레이션 인스턴스
특정 시점에서 릴레이션에 존재하는 튜플들의 집합이다. 릴레이션 인스턴스에 포함된 튜플은 릴레이션 스키마에서 정의하는 각 속성에 대응하는 실제 값으로 구성된다. 릴레이션 인스턴스를 보면 현재 릴레이션의 실제 내용을 쉽게 파악할 수 있다.
DMBS는 내부적으로 DML을 이용해 릴레이션 인스턴스의 튜플을 검색, 삽입, 삭제, 수정을 수행한다.
릴레이션의 4가지 특성
관계 데이터 모델의 릴레이션에는 4가지 특성이 있다.
(1) 튜플의 유일성
하나의 릴레이션에는 동일한 튜플이 존재할 수 없다.
모든 튜플은 다른 튜플과 구별되어야 한다. 즉 똑같은 튜플이 존재할 수 없다.
관계 데이터 모델의 릴레이션에서는 하나 또는 여러 개의 속성 값을 튜플마다 다르게 지정하여 튜플의 유일성을 판단한다. 이를 키(key)라고 한다.
(2) 튜플의 무순서
하나의 릴레이션에서 튜플 사이의 순서는 무의미하다.
튜플의 순서가 서로 바뀌어도 상관없다. 데이터베이스는 위치가 아닌 내용으로 검색되므로 튜플의 순서는 중요하지 않다.
(3) 속성의 무순서
하나의 릴레이션에서 속성 사이의 순서는 무의미하다.
속성의 순서가 서로 바뀌어도 상관없다. 데이터베이스는 위치가 아닌 내용으로 검색되므로 속성의 순서는 중요하지 않다.
(4) 속성의 원자성
속성 값으로 원자 값만 사용할 수 있다.
모든 속성 값은 더는 분해할 수 없는 하나의 값, 즉 원자 값만 가질 수 있다. 다시 말해 다중 값을 가질 수 없다!
오잉? 개념적 데이터 모델링의 개체-관계 모델에선 분명 다중 개체가 존재했는데 말이다. 개체-관계 모델과 달리, 관계 데이터 모델에서 속성 값은 복잡한 개념을 배제하고 릴레이션을 단순한 구조로 정의하고자 다중 값을 허용하지 않는다.
키의 종류
위에서 본 튜플의 유일성을 지키기 위해 튜플을 유일하게 구별할 수 있어야 한다.
릴레이션에 포함된 튜플들을 유일하게 구별해주는 역할은 속성 값 중 키(key)가 담당한다. 키는 총 다섯 가지로 분류할 수 있다.
슈퍼키 (super key)
유일성의 특성을 만족하는 속성 또는 속성들의 집합이다.
고객 아이디는 '유일성'을 만족하기 때문에 슈퍼키가 될 수 있다. 반면 '이름', '나이'는 중복된 값을 가질 수 있어서 유일성을 만족하지 않는다.
슈퍼키는 유일성만 충족하면 될 수 있다. 하지만 '학번'과 '주민번호'를 조합해 유일성을 만족시키는 경우처럼, 불필요한 작업도 슈퍼키로 인정 받는다. 그래서 꼭 필요한 속성의 집합만으로 튜플을 구별할 수 있도록 하는 다른 키의 개념이 등장했다.
후보키 (candidate key)
유일성 + 최소성을 만족하는 속성 또는 속성들의 집합이다.
후보키는 슈퍼키의 유일성을 물려 받으며 동시에 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성을 가진다. 튜플을 유일하게 구별하기 위해 최소한의 속성들로만 이루어지므로 슈퍼키 중에서 최소성을 만족하는 것이 후보키가 된다.
'고객 아이디' 속성은 단독으로 고객 튜플을 유일하게 구별할 수 있으므로 후보키가 될 수 있다.
하지만 ('고객 아이디', '고객이름') 조합에선 '고객이름'이 없어도 유일성을 만족시키기 때문에 최소성을 충족시키지 못해 후보키가 될 수 없다.
기본키 (primary key)
하나의 릴레이션에 여러 후보키가 존재할 수 있지만, 튜플을 구별하는 데 모든 후보키를 사용할 필요는 없다. 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택해야 하는 데 이것이 기본키이다.
만약 후보키가 여러 개일 경우엔 데이터베이스 사용 환경을 고려하여 적합한 것을 기본키로 선택하면 된다.
대체키 (alternative key)
기본키로 선택되지 못한 후보키들이다.
외래키 (foreign key)
어떤 릴레이션에 소석된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키다. 다른 릴레이션의 기본키를 참조하는 속성의 집합이라고 할 수 있다.
일반적으로 외래키는 다른 테이블의 기본키를 참조하지만, 유일성과 최소성을 만족하는 대체키를 참조할 수도 있다.
기본키 속성의 이름과 외래키가 되는 속성의 이름은 서로 달라도 된다.
위 예시에서 고객 릴레이션의 기본키 속성 이름은 "고객 아이디"이고, 그것을 참조하는 주문 릴레이션의 외래키 속성 이름은 "주문고객"이다. 서로 이름이 다르지만 참조가 가능하다.
하지만 이름은 달라도 기본키 속성의 도메인은 반드시 같아야 한다. 위에서 배웠듯 도메인이란 속성의 데이터 타입이다. 즉 "고객 아이디"와 "주문고객"의 데이터 타입이 동일해야 기본키, 외래키 관계가 성립될 수 있다.
또한 하나의 릴레이션엔 두 개 이상의 외래키가 존재할 수 있다.
위 예시를 보면 상담 릴레이션은 "학번"과 "교사번호"를 참조하는 두 개의 외래키를 가진다. 그리고 두 외래키인 "학번"과 "담당교사" 속성의 조합을 기본키로 사용한다. 외래키를 기본키로 사용할 수도 있고, 외래키를 포함하여 기본키를 구성할 수도 있다.
외래키가 반드시 다른 릴레이션의 기본키를 참조할 필요는 없다. 외래키 자신이 속한 릴레이션의 기본키를 참조하도록 외래키를 정의할 수도 있다.
위 예시에선 "추천고객"이란 속성은 본인이 위치한 고객 릴레이션의 "고객아이디" 기본키를 참조한다. 이것은 고객 릴레이션이 자신과 관계를 맺고 있음을 의미한다.
외래키는 null 값을 가질 수 있고, 동일한 값을 가질 수도 있다.
여러 후보키 중 기본키 선택 원칙
여러 후보키 중에서 어떤 속성을 기본키로 선택할 것인지 고민이 많이 될 수 있다. 여기에 몇 가지 기준이 있다.
- 널 값을 가질 수 있는 속성이 포함된 후보키는 지양하자
- 값이 자주 변경될 수 있는 속성이 포함된 후보키는 지양하자
- 단순한 후보키를 선택하자
관계 데이터 모델의 제약
관계 데이터 모델은 키와 관련한 무결성 제약조건을 지켜야 한다.
무결성 제약조건(integrity constraint)이란 데이터베이스 내의 데이터의 일관성, 정확성, 유효성 등을 보장하기 위해 사용되는 제약조건이다. 데이터베이스의 상태를 일관되게 유지하기 위한 이 중요한 규칙은 데이터베이스 인스턴스가 항상 지켜야만 한다. 데이터베이스가 삽입, 삭제, 수정 연산으로 상태가 변하더라도 무결성 제약조건은 반드시 지켜져야 한다.
개체 무결성 제약조건 (entity integrity constraint)
기본키를 구성하는 모든 속성은 널(null) 값을 가지면 안된다는 규칙이다.
관계 데이터 모델에선 기본키를 통해 릴레이션에 포함된 튜플들을 유일하게 구별하고 접근한다. 그런데 기본키를 구성하는 속성 일부가 널 값이 되면 투플의 유일성을 판단할 수 없어 원래 목적을 상실하게 된다.
위 예시에선 기본키인 "고객아이디" 속성에 null 값이 있으므로 개체 무결성 제약조건을 위반했다.
참조 무결성 제약조건 (referential integrity constraint)
외래키는 참조할 수 없는 값을 가질 수 없다는 규칙이다.
외래키는 다른 릴레이션의 기본키를 참조하는 속성이고 릴레이션 간의 관계를 표현하는 역할을 수행한다. 그런데 외래키가 자신이 참조하는 릴레이션의 기본키와 상관이 없는 값을 가지게 되면 외래키 본래의 의미가 없어진다. 그러므로 외래키는 자신이 참조하는 릴레이션에 기본키 값으로 존재하는 값, 즉 참조 가능한 값만 가져야 한다.
위 예시에선 주문 릴레이션의 "주문고객" 외래키에 'cherry'라는 값을 가지는데, 이는 고객 릴레이션의 기본키에 존재하지 않는 값이다. 따라서 이 고객 릴레이션과 주문 릴레이션은 참조 무결성 제약조건을 위반한 예가 된다.
그렇다고 외래키가 null 값을 가진 것 자체가 참조 무결성 제약조건을 위반한 건 아니다.
데이터베이스의 상태가 변해도 참조 무결성 제약조건은 만족되어야 한다. 고객 릴레이션에 새로운 튜플을 삽입하는 것은 상관없지만, 주문 릴레이션에 새로운 주문 튜플을 삽입할 때는 참조 무결성 제약조건을 위반하지 않는지 확인해야 한다. 즉 기본키의 속성 값으로 존재하지 않는 값을 지정하지 않아야 한다.
삭제도 마찬가지다. 고객 릴레이션에 존재하는 튜플을 삭제하는 연산은 주의해야 하는데, 기본키가 삭제되었을 때 주문 릴레이션엔 참조할 수 없는 값을 가지고 남아버리기 때문에 참조 무결성 제약조건을 위반하기 때문이다. 존재하지 않는 고객이 주문한 내역이 되어 부정확한 데이터가 된다.
'데이터 베이스' 카테고리의 다른 글
| Ch.7 데이터베이스 언어 SQL [데이터베이스 개론] (0) | 2023.04.26 |
|---|---|
| Ch.6 관계 데이터 연산 [데이터베이스 개론] (0) | 2023.04.25 |
| Ch.4 데이터 모델링 [데이터베이스 개론 도서] (1) | 2023.04.21 |
| Ch.3 데이터베이스 시스템 [데이터베이스 개론 도서] (0) | 2023.04.20 |
| [MySQL] 데이터베이스, 테이블, 열 정보를 찾는 쿼리문 (0) | 2022.10.29 |
