다이어그램은 엔티티를 박스로, 관계를 선으로 표현하여 엔티티 간의 관계를 명확하게 보여줍니다.
다이어그램은 관계의 유형(일대일, 일대다, 다대다)과 함께 속성을 나타냅니다.
논리적 데이터 모델
개념적 구조를 논리적 데이터 모델링하여 데이터베이스의 논리적 구조로 표현하는 도구
논리적 데이터 모델에서 데이터 구조는 데이터를 어떤 모습으로 저장할 것인지를 표현하는 논리적 구조
예시
계층 데이터 모델(트리)
개념: 데이터를 트리 구조로 구성하는 데이터 모델입니다. 각 노드는 한 개의 부모 노드를 가질 수 있으며, 여러 개의 자식 노드를 가질 수 있습니다.
특징: 데이터의 관계가 상하 관계로 명확히 정의됩니다. 예를 들어, 회사의 조직도나 파일 시스템의 디렉토리 구조 같은 상황에 적합합니다.
한계: 유연성이 부족하며, 복잡한 관계를 표현하기 어렵습니다.
네트워크 데이터 모델(그래프)
개념: 데이터 간의 다양한 관계를 그래프 구조로 표현하는 데이터 모델입니다. 여기서 레코드들은 노드로, 관계들은 에지로 표현됩니다.
특징: 계층 모델보다 더 복잡한 관계를 나타낼 수 있으며, 노드는 여러 부모 노드를 가질 수 있습니다.
한계: 관계형 모델에 비해 쿼리가 복잡하고, DBMS 구현이 어려울 수 있습니다.
관계 데이터 모델
개념: 데이터를 서로 관련된 테이블의 모음으로 구성합니다. 테이블은 행과 열로 이루어져 있으며, 각 행은 튜플(또는 레코드)로, 각 열은 속성으로 표현됩니다. (가장 널리 사용되는 데이터 모델)
특징: 뛰어난 유연성을 가지고 있으며, SQL과 같은 선언적 쿼리 언어를 사용하여 데이터에 접근할 수 있습니다.
장점: 데이터 무결성과 독립성을 지원하며, 복잡한 쿼리와 데이터베이스 관리가 상대적으로 용이합니다.
데이터 모델링과 데이터 모델 비교
아파트 짓는 일
사람들의 요구 사항을 반영하여 설계도를 그리는 과정 -> 개념적 데이터 모델링
설계도를 그릴 때 사용하는 방법이나 도구 -> 개념적 데이터 모델
설계도를 토대로 모델하우스를 만드는 과정 -> 논리적 데이터 모델링
모델하우스를 만들 때 사용하는 방법이나 도구 -> 논리적 데이터 모델
개체-관계 모델(Entity-Relationship Model, E-R Model)
개체-관계 모델 설명
개념적 데이터 모델 대표적인 예시
개체(entity)간 관계(relationship)를 이용해 현실 세계를 개념적 구조로 표현하는 방법
현실 세계를 개체-관계 모델을 이용해 개념적으로 모델링하여 그림으로 표현한 것을 개체-관계 다이어그램(Entity-Relationship Diagram, ERD) 또는 E-R 다이어그램이라고 합니다.
개체(entity)
설명
개체(entity)는현실 세계에서 조직을 운영하는데 꼭 필요한 사람이나 사물과 같이 구별되는 모든 것을 의미합니다. 즉, 개체는 저장할 만한 가치가 있는 중요 데이터를 가지고 있는 사람이나 사물 등입니다.
개체는 꼭 사람과 사물처럼 물리적으로 존재하는 것만을 의미하는 것은 아닙니다. 개념이나 사건처럼 개념적으로만 존재하는 것도 개체가 될 수 있습니다. (ex. 학과, 과목 등)
개체는 다른 개체와 구별되는 이름을 가지고 있고, 각 개체만의 고유한 특성이나 상태, 즉 속성을 하나 이상 가지고 있어야 합니다.
개체를 고유한 이름들과 속성들로 정의한 것을 개체 타입(entity type)이라고 합니다.
개체를 구성하고 있는 속성이 실제 값을 가짐으로써 실체화된 개체를 개체 인스턴스(entity instance) 또는 개체 어커런스(entity occurrence)라고 합니다.
특정 개체 타입에 대한 개체 인스턴스들을 모아 놓은 것을 개체 집합(entity set)이라고 합니다.
파일 구조 용어와 비교
개체 = 레코드(record)
속성 = 필드(field)
개체 타입 = 레코드 타입(record type)
개체 인스턴스 = 레코드 인스턴스(record instance)
E-R 다이어그램에서 개체를 사각형으로 표현
고객 개체 E-R 다이어그램
예시
고객 개체 타입과 고객 개체 인스턴스
속성(attribute)
설명
속성(attribute)은 개체가 가지고 있는 고유한 특성
속성은 일반적으로 의미 있는 데이터의 가장 작은 논리적 단위로 인식됩니다.
E-R 다이어그램에서 속성은 타원으로 표현
속성의 분류
속성 값의 개수
단일 값 속성(single-valued attribute)
특정 개체를 구성하는 속성이 하나의 값만을 가지는 경우
예를 들면 고객 개체를 구성하는 이름, 아이디 등은 한 명의 고객 인스턴스에 대해 하나의 값만 가지므로 단일 값 속성입니다.
다중 값 속성(multi-valued attribute)
특정 개체를 구성하는 속성이 값을 여러 개 가질수 있는 경우
예를 들면 고객 개체를 구성하는 연락처 속성은 한 명의 고객 인스턴스에 대해 집 전화번호와 휴대폰 번호 등 값을 여러 개 가질 수 있으므로 다중 값 속성입니다.
E-R 다이어그램에서 다중 값 속성은 이중 타원으로 표현
의미의 분해 가능성
단순 속성(simple attribute)
단순 속성은 의미를 더는 분해할 수 없는 속성입니다. 즉, 단순 속성의 값은 의미가 하나입니다.
예를 들어 고객 개체를 구성하는 고객아이디 속성의 경우 의미가 더는 분해되지 않기 때문에 단순 속성입니다.
복합 속성(composite attribute)
복합 속성은 의미를 분해할 수 있어 값이 여러 개의 의미를 포함하는 속성입니다.
예를 들어 생년월일 속성을 년도, 월, 일로 세분화할 수 있는 경우 복합속성이라고 합니다. 또 다른 예시로 주소속성과 같이 도, 시, 동, 우편번호 등으로 의미를 나눌 수 있는 복합 속성이 있습니다.
E-R 다이어그램에서 복합 속성은 아래와 같이 표시합니다.
기존 속성 값에서 유도
유도 속성(derived attribute) 과 저장 속성(stored attribute)
값이 별도로 저장되는 것이 아니라 기존의 다른 속성 값에서 유도되어 결정되는 속성을 유도 속성(derived attribute)으로 분류합니다.
예시
책 개체를 구성하는 가격과 할인율 속성을 통해 계산되는 판매가격 속성은 유도 속성이 됩니다.
여기서 판매가격 속성(유도 속성)을 계산하는 데 사용되는 가격과 할인율 같은 속성을 저장 속성(stored attribute)라고 합니다.
저장 속성인 출생년도에서 나이 속성을 유도하는 것도 유도 속성의 예시입니다.
실제로 값을 저장하고 있는 것은 저장 속성이고, 유도 속상은 필요할 때마다 계산되므로 값을 따로 저장할 필요가 없습니다.
E-R 다이어그램에서 유도 속성은 점선 타원으로 표현합니다.
널(null) 속성
널(null) 이란?
널(null) 값은 아직 결정되지 않았거나 모르는 값(unknown value)을 의미합니다. 또는 해당되는 값이 없는, 즉 존재하지 않는 값의 경우도 널 값이라고 합니다.
즉 , 널 값은 값을 아직 갖지 않은 것이므로 공백(blank)이나 0(zero)과는 다릅니다.
널 값이 허용되는 속성을 널 속성(null atribute)이라고 합니다.
예시
고객 개체 인스턴스의 등급 속성 값이 널이라면 고객의 등급이 아직 결정되지 않았음을 의미합니다.
고객 개체 인스턴스의 취미 속성이 널 값이면 가입 시 고객이 취미를 입력하지 않았음을 의미합니다.
사원 개체를 구성하는 병역 속성은 사원 개체 인스턴스의 성별이 여자인 경우에는 해당 사항이 없으므로 널 값을 가질 수밖에 없습니다.
키(key) 속성
모든 개체 인스턴스의 키 속성 값은 다릅니다. 따라서 키 속성은 개체 집합에 존재하는 각 개체 인스턴스들을 식별하는 데 사용됩니다.
어떤 경우에는 키를 둘 이상의 속성들로 구성하기도 합니다.
개체 타입을 정의할 때 중요한 제약조건은 키 속성의 값이 개체 인스턴스마다 달라서 이 값으로 개체 인스턴스를 식별할 수 있어야 합니다. 만약 키 속성으로 적합한 속성이 여러 개면 이 중 하나를 키로 사용하면 됩니다.
예시
고객 개체의 고객아이디 속성은 고객마다 다르기 때문에 고객 개체의 키 속성이 될 수 있습니다.
책 개체에서는 ISBN 속성이 키 속성으로 사용될 수 있습니다.
고객 개체에 고객아이디 속성이 없는 경우에는 고객명과 집전화번호 속성을 조합하여 키를 구성할 수도 있습니다.
함께 사는 가족의 집전화번호가 같을 수는 있지만, 가족들 중에서 이름이 같은 사람은 없으므로 고객명과 집전화번호 속성을 조합하면 고객들을 구별할 수 있습니다.
E-R 다이어그램에서 키 속성은 밑줄을 그어 표현합니다.
관계(relationship)
설명
관계는 개체와 개체가 맺고 잇는 의미 있는 연관성입니다.
개체들을 이용해 하나의 문장으로 만들었을 때 동사에 해당하는 것이 관계입니다.
관계를 관계 타입(relationship type)과 관계 인스턴스로 구분하여 표현하기도 합니다.
관계 타입(relation type) : 여러 개체 사이에서 정의
관계 인스턴스 : 실제 속성 값으로 구성된 특정 개체 인스턴스들 간에 맺어진 실제 관계
예시
고객 개체와 책 개체 사이에 정의된 구매 관계는 관계 타입
이름 속성의 값이 홍길동인 고객 개체 인스턴스와 제목 속성의 값이 데이터베이스개론인 책 개체 인스턴스 사이에 맺어진 실제 관계는 관계 인스턴스
(개체 타입 - 개체 인스턴스 와 유사한 관계)
관계도 개체처럼 속성을 가질 수 있습니다.
관계를 맺음으로써 발생하는 중요한 데이터들이 관계의 속성이 됩니다.
예를 들어 고객이 책을 구매하면 발생하는 구매일자, 결제방식 등이 구매 관계의 속성이 될 수 있습니다.
E-R 다이어그램에서 관계는 마름모로 표현
관계의 유형
매핑 카디널리티(mapping cardinality) 기준 분류 (매핑 카디널리티 : 각 개체 인스턴스가 연관성을 맺고 있는 상대 개체 집합의 인스턴스 개수)
일대일(1:1)
개체 A의 각 개체 인스턴스가 개체 B의 개체 인스턴스 하나와 관계를 맺을 수 있고, 개체 B의 각 개체 인스턴스도 개체 A의 개체 인스턴스 하나와 관계를 맺을 수 있는 경우
예시
남편 개체와 아내 개체
일대다(1:n)
개체 A의 각 개체 인스턴스는 개체 B의 개체 인스턴스 여러 개와 관계를 맺을 수 있지만, 개체 B의 각 개체 인스턴스는 개체 A의 개체 인스턴스 하나와만 관계를 맺을 수 있는 경우
예시
부서 개체와 사원 개체 (소속 관계)
다대다(n:m)
개체 A의 각 개체 인스턴스가 개체 B의 개체 인스턴스 여러 개와 관계를 맺을 수 있고, 개체 B의 각 개체 인스턴스도 개체 A의 개체 인스턴스 여러 개와 관계를 맺을 수 있는 경우
예시
고객 개체와 책 개체(구매 관계)
다대다 관계는 보통 두 개의 일대다 관계로 나누어서 표현합니다.
예를 들어, '학생'과 '수업' 사이의 다대다 관계를 생각해 볼 수 있습니다. 하나의 '학생'은 여러 '수업'에 등록할 수 있으며, 하나의 '수업'은 여러 '학생'에 의해 수강될 수 있습니다. 이 관계를 데이터베이스에서 표현하기 위해서는 '학생_수업'이라는 연결 테이블이 필요하며, 이 테이블은 '학생'의 ID와 '수업'의 ID를 외래 키로 포함합니다.
이렇게 다대다 관계를 두 개의 일대다 관계로 나누어 표현하는 방식은 데이터를 더 효율적으로 관리할 수 있게 해주며, 데이터베이스의 정규화를 돕고, 중복을 줄이며, 데이터 무결성을 유지하는 데 도움을 줍니다.
관계의 참여 특성
필수적 참여 (전체 참여)
개체 A와 B 사이의 관계에서, 개체 A의 모든 개체 인스턴스가 관계에 반드시 참여해야 된다면, 개체 A가 관계에 "필수적 참여한다" 또는 "전체 참여한다"라고 합니다.
선택적 참여 (부분 참여)
개체 A와 B 사이의 관계에서, 개체 A의 개체 인스턴스 중 일부만 관계에 참여해도 되면 개체 A가 관계에 "선택적 참여한다" 또는 "부분 참여한다"라고 합니다.
예시
고객 개체와 책 개체 사이의 구매 관계에서 모든 고객이 책을 반드시 구매해야 한다는 제약조건이 존재한다면, 고객 개체가 구매 관계에 필수적 참여한다고 할 수 있습니다.
반대로 고객이 구매하지 않은 책이 존재할 수 있다면 책 개체가 구매 관계에 선택적 참여한다고 할 수 있습니다.
필수적 참여 관계는 E-R 다이어그램에서 이중선으로 표현합니다.
(위 예시를 표현한 E-R 다이어그램입니다.)
고객은 관계에 필수적 참여, 책은 관계에 선택적 참여
관계의 종속성
존재 종속(existence dependence)
개체 B가 독자적으로 존재할 수 없고 다른 개체 A의 존재 여부에 의존적이라면, 개체 B가 개체 A에 종속되어 있다고 합니다.
개체 B가 개체 A에 종속되면, 이는 개체 A가 존재해야 개체 B가 존재할 수 있고, 개체 A가 삭제되면 개체 B도 함께 삭제되어야 함을 의미합니다. 이러한 종속을 특별히 존재 종속(existence dependence)이라 합니다.
이때 다른 개체의 존재 여부에 의존적인 개체 B를 약한 개체(weak entity)라 하고 다른 개체의 존재 여부를 결정하는 개체 A를 강한 개체(strong entity)라고 합니다.
강한 개체와 약한 개체는 일반적으로 일대다의 관계이며, 약한 개체는 강한 개체와의 관계에 필수적으로 참여한다는 특징이 있습니다.
약한 개체는 자신이 지닌 속성만으로는 식별이 어려워 일반적으로 강한 개체의 키를 포함하여 키를 구성합니다.
E-R 다이어그램에서 약한 개체는 이중 사각형으로 표현하고 약한 개체가 강한 개체와 맺는 관계는 이중 마름모로 표현합니다. (또한 만약 부양가족이 부양 관계에서 필수적으로 참여하고 있다면 이중선으로 표시까지 해주어야 합니다.)
예시
학생 개체와 학부모 개체 사이의 보호 관계
학교 입장에서는 학부모 개체만으로는 의미가 없습니다. 학생 개체가 있어야 학생을 보호하는 학부모 개체가 존재할 수 있으며, 학생 개체가 없으면 학부모 개체도 필요가 없습니다.
따라서 학생이 입학하면 보호 관계를 맺는 학부모가 생기지만, 학생이 졸업하면 학부모 데이터도 함께 삭제됩니다.
즉, 학생 개체가 강한 개체가 되고 학부모 개체는 약한 개체가 됩니다.
직원 개체와 부양가족 개체 사이의 부양 관계
회사에 새로운 직원이 입사하면 해당 직원의 부양가족에 대한 데이터도 함께 저장되지만, 직원이 퇴사하면 퇴사한 직원의 부양가족 데이터도 함께 삭제합니다.
즉, 직원 개체가 강한 개체가 되고 부양가족 개체는 약한 개체가 됩니다.
강한 개체인 직원 개체와 약한 개체인 부양가족 개체는 일반적으로 일대다 관계를 맺습니다.
부양하는 직원이 없으면 부양가족이 존재하지 않으므로, 부양가족이 존재하는 것이라면 반드시 해당 부양가족은 부양하는 직원과 관계를 가집니다. 따라서 부양가족은 부양 관계에 필수적으로 참여하고 있습니다.
한 직원의 부양가족 이름은 모두 다를 것입니다. 하지만 다른 직원의 부양가족 이름과는 같을 수 있기 때문에 부양가족 개체는 이름 속성만으로 부양가족을 구별하기 어렵습니다.
이럴 때는 먼저 직원번호 속성으로 직원 개체를 식별하고, 식별된 직원의 부양가족 개체를 이름 속성으로 구별하면 됩니다.
즉, 강한 개체인 직원 개체에 직원 번호라는 키 속성이 존재한다면, 직원번호 속성과 이름 속성을 조합하여 약한 개체인 부양가족 개체의 키를 구성할 수 있습니다.
부양가족 개체의 키는 (직원번호, 이름)이 됩니다. 이때 이름과 같이 약한 개체를 구별해 주는 속성을 구별자(delimiter) 또는 부분키(partial key)라고 합니다.
E-R 다이어그램(ERD)
개념적인 수준의 E-R 다이어그램 정리
개체 - 사각형
속성 - 타원
다중 값 속성 - 이중 타원 ( 한 속성 값이 여러 개의 값을 가질 수 있는 속성 / ex. 연락처 (접전화번호, 휴대폰 번호)
1:M 관계는 연결테이블을 만들 필요가 없습니다. M 쪽 테이블에 관계 내용까지 같이 적어주면 됩니다.
회원 - 게시글 (1:M)
회원 테이블 : 회원 ID (기본키), 이름, ~
게시글 테이블 : 게시글 ID (기본키), 회원 ID (외래키), 제목, 내용, 게시 날짜~
즉, 관계에 대한 정보를 게시글 테이블에 모두 적어주면 됩니다.
상품 - 제조업체 (M:1)
상품 테이블 : 상품 ID (기본키), 제조업체ID(외래키), 상품명, 공급일자, 공급량
제조업체 테이블 : 제조업체 ID (기본키), 제조업체명, ~
관계에 대한 정보를 상품 테이블에 모두 적었습니다.
물리적인 수준의 ERD
실제 구축 시에는 물리적 ERD가 더 적함
Primary Key는 굵게 또는 PK라고 표기, Foreign Key는 FK라고 표기
관계표현(일대일, 일대다, 다대다)
오른쪽 : 왼쪽 개체 인스턴스 1개가 오른쪽 개체 인스턴스를 최소/최대 몇 개 가질 수 있는지 표현
회원 한 명에 대해 주문내역이 0개일 수도 있고 여러 개 일수도 있습니다.
왼쪽 : 오른쪽 개체 인스턴스 1개가 왼쪽 개체 인스턴스를 최소/최대 몇 개 가질 수 있는지 표현
주문내역 1개에 대해 회원은 반드시 1개가 지정되어야 합니다. (최소 1개, 최대 1개)
개념적 ERD 관계를 물리적 ERD 테이블로 전환
일대일 관계(1:1): 한쪽의 기본 키를 다른 쪽 테이블의 외래 키(Foreign Key)로 추가하거나, 두 테이블을 하나로 합칩니다.
일대다 관계(1:M): '다' 쪽 엔티티의 테이블에 '일' 쪽 엔티티의 기본 키를 외래 키로 추가합니다.
일대다 관계에서는 관계에 대한 정보를 '다'쪽 테이블에 추가시켜줍니다.
다대다 관계(M:N): 새로운 연결 테이블(Join Table)을 생성하여, 관계에 참여하는 두 엔티티의 기본 키를 외래 키로 포함시킵니다.
다대다 관계에서 생성된 연결 테이블에는 해당 관계에 대한 추가 정보(예: 주문 날짜, 수량 등)가 포함될 수 있습니다. 이러한 속성들을 연결 테이블에 추가합니다.
관계 데이터 모델(Relational Data Model)
관계 데이터 모델 설명
개념적 구조를 논리적 구조로 표현하는 논리적 데이터 모델 중 대표적인 예시
일반적으로 관계 데이터 모델에서는 하나의 개체에 관한 데이터를 릴레이션(relation) 하나에 담아 데이터베이스에 저장합니다.
예시 (인터넷 쇼핑몰을 위한 데이터베이스에서 고객 개체를 표현한 고객 릴레이션)
관계 데이터 모델의 기본 용어
릴레이션(relation)
릴레이션이란관계형 데이터베이스에서 정보를 구분하여 저장하는 기본 단위
릴레이션은 DB 테이블
정확히는 테이블이 4가지 특성을 만족해야 릴레이션으로 인정받을 수 있습니다.
하나의 릴레이션은 현실세계의 어떤 개체(entity)를 표현하고 저장
하나의 개체에 관한 데이터를 2차원 테이블의 구조로 저장한 것
속성(attribute)
릴레이션의 열
위의 예시에서 고객아이디, 고객이름, 나이, 등급, 직업, 적립급 속성이 존재
각 속성은 서로 다른 이름을 이용해 구별
릴레이션은 파일 관리 시스템의 파일 / 속성은 해당 파일의 필드(field)에 대응하는 개념
도메인(domain)
릴레이션에 포함된 속성들이 각각 가질 수 있는 값들의 집합
위의 예시에서 등급 속성이 가질 수 있는 도메인은 bronze, silver, gold, vip가 될 수 있습니다. (가능한 값들이기 때문에 bronze는 추가적으로 넣어주었습니다.)
투플(tuple)
릴레이션의 행
고객 릴레이션에서 각 투플은 고객 한 명에 대한 실제 속성 값 6개를 모아놓은 것으로, 고객 개체의 인스턴스
고객 4명이 존재할 경우, 고객 릴레이션에는 4개의 투플 또는 4개의 고객 개체 인스턴스가 존재
투플은 파일 관리 시스템에서 해당 파일의 레코드(record)에 대응
차수(degree)
하나의 릴레이션에서 속성의 전체 개수
위의 고객 릴레이션의 예시에서는 차수가 6입니다.
모든 릴레이션은 최소 1 이상의 차수를 유지해야 합니다.
릴레이션의 차수는 일반적으로 자주 변하지 않는다는 정적인 특징이 있습니다.
카디널리티(cardinality)
하나의 릴레이션에서 투플의 전체 개수
위의 고객 릴레이션의 예시에서 카디널리티가 4입니다.
투플이 없는 릴레이션이 존재할 수도 있습니다.
새로운 투플이 계속 삽입되거나 기존 투플이 삭제될 수 있으므로 릴레이션의 카디널리티는 일반적으로 자주 변하다는 동적인 특징이 있습니다.
릴레이션과 데이터베이스의 구성
관계 데이터 모델에서 릴레이션은 릴레이션 스키마와 릴레이션 인스턴스로 구성되어 있습니다.
릴레이션 스키마(relation schema)
릴레이션 스키마는 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조
릴레이션 스키마는 데이터베이스 관리 시스템(DBMS)이 내부적으로 데이터 정의어를 이용해 정의하지만, 일반적으로는 다음과 같은 형태로 쉽게 표현합니다.
릴레이션 인스턴스(relation instance)
릴레이션 인스턴스는 어느 한 시점에 릴레이션에 존재하는 투플들의 집합
데이터베이스 관리 시스템이(DBMS)이 내부적으로 데이터 조작어를 이용해 릴레이션 인스턴스의 투플을 검색하거나, 새로운 투플 삽입과 기존 투플 삭제 및 수정을 수행합니다.
릴레이션 인스턴스는 간단히 릴레이션이라 부르기도 합니다.
집의 전체 구조는 자주 바뀌지 않지만 집에 사는 사람은 수시로 바뀔 수 있는 것처럼 논리적 구조를 정의하는 릴레이션 스키마는 자주 변하지 않는다는 정적인 특징이 있는 반면, 릴레이션 인스턴스는 투플의 삽입, 삭제, 수정이 자주 발생한다는 동적인 특징이 있습니다.
데이터베이스 스키마와 데이터베이스 인스턴스
일반적으로 데이터베이스는 릴레이션 여러 개로 구성
예를 들면 인터넷 쇼핑몰을 위한 데이터베이스는 고객 릴레이션, 상품 릴레이션, 주문 릴레이션으로 구성할 수 있습니다.
데이터베이스의 전체 구조를 의미하는 데이터베이스 스키마는 데이터베이스를 구성하는 릴레이션들의 스키마를 모아놓은 것입니다. 즉, 특정 데이터베이스 스키마를 설계한다는 것은 필요한 모든 릴레이션의 스키마를 모두 정의한다는 뜻입니다.
데이터베이스 인스턴스는 어느 한 시점에서 데이터베이스에 저장된 데이터 내용의 전체 집합을 의미합니다. 즉, 데이터베이스를 구성하는 모든 릴레이션의 인스턴스를 모아놓은 것입니다.
참고 : 개체 인스턴스는 하나의 행을 의미합니다.
릴레이션의 특성
관계 데이터 모델의 릴레이션에는 네 가지 주요한 특성이 있습니다. 기본적으로 이 네 가지 특성을 만족해야 테이블이 릴레이션으로 인정받을 수 있습니다.
(투플의 유일성 / 투플의 무순서, 속성의 무순서, 속성의 원자성)
릴레이션은 모두 테이블이지만, 모든 테이블은 다 릴레이션이 아닙니다.
1. 투플의 유일성 : 하나의 릴레이션에는 동일한 투플이 존재할 수 없다.
키를 이용해 투플의 유일성을 판단합니다.
고객 릴레이션에서 고객 아이디 속성의 값으로 모든 고객 투플을 유일하게 구별하여 같은 고객이 중복 가입하는 일을 방지합니다.
릴레이션을 투플의 모임인 집합의 개념으로 이해한다면, 하나의 집합에 동일한 원소가 존재할 수 없다는 특성과 연관 지어 생각 가능
2. 투플의 무순서 : 하나의 릴레이션에서 투플 사이의 순서는 무의미하다.
투플 순서가 바뀐다고 다른 릴레이션이 될 수 없고, 순서와 상관없이 투플 내용이 같아야 같은 릴레이션입니다.
데이터베이스는 위치가 아닌 내용으로 검색되므로 투플의 순서는 중요하지 않습니다.
집합과 연관지어 생각해 보면 집합의 원소 사이에 순서가 없다는 특성과 같습니다.
3. 속성의 무순서 : 하나의 릴레이션에서 속성 사이의 순서는 무의미하다.
속성은 순서가 바뀌어도 다른 릴레이션이 될 수 없고, 순서와 상관없이 같은 속성들로 구성되어 있어야 같은 릴레이션입니다.
예를 들어 고객(고객아이디, 고객이름, 나이, 등급, 직업, 적립금)으로 표현된 릴레이션 스키마와 고객(등급, 나이, 고객이름, 적립금, 직업, 고객아이디)으로 표현된 릴레이션 스키마는 동일하므로 두 릴레이션은 같습니다.
속성 값은 릴레이션에서 위치가 아닌 속성의 이름으로 접근하므로 하나의 릴레이션에는 이름이 같은 속성이 존재할 수 없고, 이름도 속성의 의미가 명확히 드러나는 것으로 사용하는 것이 좋습니다.
4. 속성의 원자성 : 속성 값으로 원자 값만 사용할 수 있다.
모든 속성 값은 더는 분해할 수 없는 하나의 값, 즉 원자 값만 가질 수 있습니다. 다시 말해 하나의 속성은 여러 개의 값, 즉 다중 값을 가질 수 없습니다.
아래 예시에서 고객 릴레이션은 (회사원, 학생)과 같이 값이 여러 개인 직업 속성을 포함하므로 관계 데이터 모델의 릴레이션으로 적합하지 않습니다.
물론 현실에서 직업이 둘 이상인 고객이 존재할 수 있지만, 관계 데이터 모델은 이런 복잡한 개념을 배제하고 릴레이션을 단순한 구조로 정의하고자 하는 특징이 있어 다중 값을 허용하지 않습니다.
정규화 과정 필요
키의 종류
투플을 유일하게 구별하기 위해 모든 속성을 이용하는 것보다 일부 속성만 이용하는 것이 효율성을 높일 수 있습니다. 릴레이션에 포함된 투플들을 유일하게 구별해 주는 역할은 속성 또는 속성들의 집합인 키가 담당합니다.
키 설명을 위한 예시
키의 관계
관계 데이터 모델에서 키의 분류
슈퍼키(super key)
유일성의 특성을 만족하는 속성 또는 속성들의 집합
유일성(uniqueness)은 키가 갖추어야 하는 기본 특성으로, 하나의 릴레이션에서 키로 지정된 속성 값은 투플마다 달라야 한다는 의미입니다. 즉, 키 값이 같은 투플은 존재할 수 없습니다.
예시
예시에서 고객아이디 속성은 모든 고객 투플마다 값이 달라야 하고 이를 통해 다른 투플과 유일하게 구별할 수 있으므로 슈퍼키가 될 수 있습니다. 그러나 나이, 등급, 직업, 적립금 속성은 값이 같은 고객이 있을 수 있으므로 유일성을 만족시키지 못해 슈퍼키가 될 수 없습니다.
고객아이디 속성만으로도 모든 투플을 구별할 수 있으므로, (고객아이디, 고객이름) 속성값의 조합도 유일성을 만족합니다.
즉, 고객아이디를 포함하는 속성 집합은 모두 슈퍼키가 될 수 있습니다.
후보키(candidate key)
유일성과 최소성을 만족하는 속성 또는 속성들의 집합
최소성(minimality)은 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성입니다.
슈퍼키 중에서 최소성을 만족하는 것이 후보키가 됩니다.
후보키를 선정할 때는 현재의 릴레이션 내용, 즉 릴레이션 인스턴스만 보고 유일성과 최소성을 판단해서는 안됩니다. 데이터베이스가 사용될 현실 세계의 환경까지 염두에 두고 속성의 본래 의미를 정확히 이해한 후 슈퍼키와 후보키를 선별해야 합니다.
예시
예시에서 슈퍼키 중에서 고객아이디 속성은 단독으로 고객 투플을 유일하게 구별할 수 있으므로 후보키가 될 수 있습니다.
하지만 (고객아이디, 고객이름)은 후보키가 될 수 없습니다. 고객이름 속성이 없어도 고객아이디 속성만으로 유일성을 만족할 수 있기 때문입니다.
예시에서 현재 고객이름 속성의 값이 중복되지 않지만 새로 삽입되는 고객 투플의 고객이름이 언제나 다를 것이라고 보장할 수 없기 때문에 고객이름 속성은 슈퍼키는 물론 후보키로도 선택하지 않는 것이 바람직합니다.
기본키(primary key)
릴레이션에서 투플을 구별하기 위해 여러 개의 후보키를 모두 사용할 필요는 없습니다.
데이터베이스 설계자나 관리자는 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택해야 하는데 이것이 기본키입니다.
만약 후보키가 1개만 존재하면 당연히 해당 후보키를 기본키로 선택해야 하겠지만, 여러 개일 경우에는 데이터베이스 사용 환경을 고려하여 적합한 것을 기본키로 선택하면 됩니다.
예시
예시에서 고객 아이디 속성만 후보키이기 때문에 자연스럽게 고객아이디 속성이 기본키가 됩니다. 선택한 기본키는 아래처럼 속성 이름에 밑줄을 그어 표현합니다.
만약 아래와 같이 고객 릴레이션에 주소 속성이 추가된다면, 고객아이디 속성과 함께 (고객이름, 주소) 속성 집하도 후보키가 될 수 있습니다. (일반적으로 같이 사는 가족의 주소는 같지만 이름까지 같은 경우는 없기 때문입니다.)
그렇다면 위와 같이 후보키가 여러 개일 경우 고객아이디와 (고객이름, 주소) 중 무엇을 기본키로 선택해야 할까요?
기본키를 선택할 때 고려하면 도움이 되는 기준 몇 가지
널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합합니다.
기본키는 투플을 식별할 뿐만 아니라 릴레이션에서 원하는 투플을 찾기 위한 기본 접근법을 제공하므로 매우 중요합니다. 따라서 기본키가 널 값인 투플은 다른 투플들과 구별하여 접근하기 어려우므로 이런 가능성이 있는 키는 기본키로 선택하지 않는 것이 좋습니다.
예를 들어 (고객아이디)와 (고객이름, 주소)라는 두 후보키 중에서는 고객아이디 후보키를 기본키로 선택하는 것이 좋습니다.
고객아이디는 꼭 입력해야 하지만 고객이름이나 주소는 입력하지 않아도 되는 경우가 많기 때문입니다.
값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합합니다.
기본키는 다른 투플과 구별되는 값을 가지고 널 값은 허용하지 않으므로 이를 확인하는 작업이 필요합니다. 그런데 값이 자주 변경되는 속성으로 구성된 후보키를 기본키로 선택하면 속성 값이 바뀔 때마다 기본키 값으로 적합한지 여부를 판단해야 하므로 번거롭습니다. 그러므로 값이 자주 변경되지 않는 속성으로 구성된 후보키를 기본키로 선택하는 것이 좋습니다.
예를 들어 (고객아이디) 와 (고객이름, 주소)라는 두 후보키 중에서는 고객아이디 후보키를 기본키로 선택하는 것이 좋습니다.
보통 주소는 고객아이디와 고객이름보다 변경될 가능성이 높기 때문입니다. 그러므로 주소 속성이 포함되지 않은 고객아이디 후보키를 기본키로 선택하는 것이 좋습니다.
단순한 후보키를 기본키로 선택합니다.
단순한 후보키는 자릿수가 적은 정수, 단순 문자열인 속성으로 구성되거나, 구성하는 속성의 개수가 적은 후보키입니다. 데이터베이스를 이용하는 일반 사용자뿐 아니라 데이터베이스를 실제로 처리하는 컴퓨터 시스템도 단순 값 처리를 선호합니다.
예를 들어 (고객아이디)와 (고객이름, 주소)라는 두 후보키 중에서는 고객아이디 후보키를 기본키로 선택하는 것이 좋습니다.
속성 2개로 구성된 후보키보다는 하나로 구성된 후보키가 이해하기도 쉽고 처리하기도 쉬울 것이기 때문입니다.
대체키(alternate key)
대체키는 기본키로 선택되지 못한 후보키들입니다.
기본키 예시에서 (고객아이디) 와 (고객이름, 주소)라는 두 후보키 중 기본키로 선택되지 못한 (고객이름, 주소) 속성 집합이 대체키가 됩니다.
외래키(foreign key)
외래키는 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합이 외래키입니다.
참고로 외래키가 다른 테이블의 대체키를 참조하는 것도 가능합니다. 기본키로 선택받지 못했지만 유일성과 최소성을 만족하는 대체키를 참조하더라도 관련 있는 투플을 구분할 수 있기 때문입니다. 다만, 외래키는 다른 릴레이션의 기본키를 참조하는 경우가 많습니다.
외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요합니다.
일반적으로 주문 릴레이션과 같이 외래키를 가진 릴레이션을 "참조하는 릴레이션"이라 하고, 고객 릴레이션과 같이 기본키를 가진 릴레이션을 "참조되는 릴레이션"이라 합니다.
외래키를 통해 고객 릴레이션과 주문 릴레이션이 관계를 맺어, 주문 릴레이션의 투플과 연관성 있는 고객 릴레이션의 투플을 연결시킬 수 있습니다.
예시 2 (학생 - 상담 - 교사)
학생 상담 데이터베이스 스키마
상담 릴레이션의 학번 속성은 학생 릴레이션의 기본키인 학번 속성을 참조하는 외래키이고, 담당교사 속성은 교사 릴레이션의 기본키인 교사번호 속성을 참조하는 외래키입니다.
상담 릴레이션의 기본키는 두 외래키인 학번과 담당교사 속성의 조합으로 구성되어 있습니다.
이처럼 하나의 릴레이션에는 외래키가 여러 개 존재할 수도 있습니다. 그리고 외래키를 기본키로 사용할 수도 있고, 외래키를 포함하여 기본키를 구성할 수도 있습니다. 물론 예시 1처럼 외래키가 기본키로 사용되지 않을 수도 있습니다.
예시 3 (기본키와 외래키의 관계가 함께 정의된 릴레이션)
외래키가 다른 릴레이션의 기본키를 참조하는 키라고 정의했지만 반드시 다른 릴레이션을 참조할 필요는 없습니다.
참조하는 릴레이션과 참조되는 릴레이션이 같을 수 도 있습니다.
즉, 외래키 자신이 속한 릴레이션의 기본키를 참조하도록 외래키를 정의할 수도 있습니다.
위 예시에서 정지영 고객은 다른 고객의 추천을 받지 않고 가입하였기 때문에 추천고객 속성값이 NULL입니다. 이처럼 외래키는 기본키를 참조하지만 기본키가 아니기 때문에 NULL 값을 가질 수 있습니다.
또한, 외래키가 기본키가 아니기 때문에 서로 다른 투플이 같은 값을 가질 수 있습니다.(김현준 고객과 정소화 고객의 추천고객 속성 값이 같습니다.)
관계 데이터 모델의 제약
관계 데이터 모델에서 정의하고 있는 기본 제약 사항은 키와 관련한 무결성 제약조건(integrity constraint)입니다.
무결성은 데이터에 결함이 없는 상태, 즉 데이터가 정확하고 유효하게 유지된 상태입니다.
무결성 제약조건은 어느 시점에 데이터베이스에 저장된 데이터를 의미하는 데이터베이스 상태 또는 데이터베이스 인스턴스가 항상 지켜야 하는 중요한 규칙입니다. 데이터베이스가 삽입, 삭제, 수정 연산으로 상태가 변하더라도 무결성 제약조건은 반드시 지켜져야 합니다.
무결성 vs 보안
데이터베이스 내부의 데이터를 보호한다는 관점에서 무결성은 보안과 유사합니다.
하지만 보안이 권한이 없는 사용자로부터 데이터를 보호하는 것이라면, 무결성은 권한이 있는 사용자의 잘못된 요구에 의해 데이터가 부정확해지지 않도록 보호하는 것입니다.
관계 데이터 모델이 기본으로 포함하고 있는 무결성 제약조건에는 개체 무결성 제약조건과 참조 무결성 제약조건이 있습니다. 데이터베이스의 상태를 일관성 있게 유지하기 위해서는 두 가지를 모두 만족시켜야 합니다.
무결성 제약조건
개체 무결성 제약조건 : 기본키를 구성하는 모든 속성은 널 값을 가질 수 없다.
참조 무결성 제약조건 : 외래키는 참조할 수 없는 값을 가질 수 없다.
개체 무결성 제약조건(entity integrity constraint)
개체 무결성 제약조건은 기본키를 구성하는 모든 속성은 널 값을 가지면 안 된다는 규칙입니다.
기본키를 구성하는 속성 전체나 일부가 널 값이 되면 투플의 유일성을 판단할 수 없어 기본키의 본래목적을 상실하게 되기 때문입니다.
개체 무결성 제약조건을 만족시키려면 새로운 투플이 삽입되는 연산과 기존 투플의 기본키 속성 값이 변경되는 연산이 발생할 때 기본키에 NULL값이 포함되는 상황에서는 연산의 수행을 거부하면 됩니다.
이것은 데이터베이스 관리 시스템(DBMS)이 자동으로 수행하므로 새로운 릴레이션을 생성할 때마다 기본키를 어떤 속성들로 구성할 것인지 데이터베이스 관리 시스템에 알려주면 됩니다.
개체 무결성 제약조건을 위반한 릴레이션 예
정소화 고객과 정지영 고객 투플에서 기본키인 고객아이디 속성의 값이 NULL입니다.
NULL 값은 아직 결정되지 않았거나 모르는 값을 의미하기 때문에, 이 경우에는 정소화 고객과 정지영 고객의 아이디가 다른 고객의 아이디와 다른지 판단하기 어렵습니다.
참조 무결성 제약조건(referential integrity constraint)
개체 무결성 제약조건이 기본키에 대한 규칙으로 각 릴레이션마다 적용된다면, 참조 무결성 제약조건은 외래키에 대한 규칙으로 연관된 릴레이션들에 적용됩니다.
참조 무결성 제약조건이란 외래키는 참조할 수 없는 값을 가질 수 없다는 규칙입니다.
외래키는 자신이 참조하는 릴레이션에 기본키 값으로 존재하는 값, 즉 참조 가능한 값만 가져야 합니다.
예시
예시 1 (참조 무결성 제약조건을 위반한 릴레이션)
참조 무결성 제약조건을 만족하려면 주문고객 속성 값이 현재 고객 릴레이션에 존재하는 고객아이디 속성 값 중 하나여야 합니다. 하지만 주문번호가 1001인 cherry라는 주문고객의 속성 값은 현재의 고객 릴레이션에 존재하지 않는 고객아이디입니다.
즉, 존재하지 않는 고객이 주문했다는 의미가 되므로 이것은 현실 세계를 올바르게 반영한 것이 아닙니다. 그러므로 이 고객 릴레이션과 주문 릴레이션은 참조 무결성 제약조건을 위반한 예입니다.
예시 2 (다양한 예시)
외래키가 NULL 값인 경우
외래키가 NULL 값인 경우 참조 무결성 제약조건을 위반한 것이 아닙니다. 주문고객 속성 값이 NULL이라는 것은 주문한 고객이 누구인지 모를 뿐, 고객 릴레이션에 존재하지 않는 고객이 주문한 것으로 판단하기는 어렵기 때문입니다.
데이터베이스의 상태가 변해도 참조 무결성 제약조건을 만족시켜야 합니다.
고객 릴레이션에 새로운 고객 투플 삽입 -> 참조 무결성 제약조건을 위반하는 작업이 아님
다만, 개체 무결성 제약조건을 위반하지 않도록 고객릴레이션에 고객아이디 속성 값을 삽입해야 합니다.
주문 릴레이션에 새로운 주문 투플 삽입 -> 참조 무결성 제약조건을 위반하지 않는 작업인지 확인 필요
고객 릴레이션의 기본키인 고객아이디 속성 값으로 존재하지 않는 값은 주문 고객 속성값으로 지정하지 않아야 합니다.
만약 고객아이디 속성 값으로 존재하지 않는 것이 주문고객 속성 값으로 선택되면 주문 릴레이션에 새로운 투플을 삽입하는 연산의 수행을 거부하면 됩니다.
고객 릴레이션에 존재하는 투플 삭제 -> 참조 무결성 제약조건을 위반하지 않는 경우에만 수행
만약 주문 릴레이션에 주문 고객이 apple인 고객이 주문한 투플이 존재하는데 고객 릴레이션에서 고객아이디가 apple인 고객 투플을 삭제하면 존재하지 않는 고객이 주문한 내역이 되어 부정확한 데이터가 됩니다.
이처럼 삭제 시에 연관된 투플이 주문 릴레이션에 남아 있으면, 고객 릴레이션에서 해당 고객의 투플을 삭제하는 연산을 수행하지 않거나 주문 릴레이션의 관련 투플을 함께 삭제하여 참조 무결성 제약조건을 만족시켜야 합니다. 또는 주문 고객의 속성 값을 널이나 기본 값으로 지정하는 방법도 사용할 수 있습니다.
주문 릴레이션에 존재하는 투플 삭제 -> 참조 무결성 제약조건을 위반하는 작업이 아님
...
예시 2 처럼 데이터베이스 상태가 빈번하게 변경되는 경우 참조 무결성 제약조건을 계속 만족시키기가 쉽지 않습니다. 이러한 작업을 데이터베이스 관리 시스템(DBMS)이 자동으로 수행해 줍니다.
사용자는 새로운 릴레이션을 생성할 때마다 어떤 속성들이 외래키이고 어떤 릴레이션의 기본키를 참조하면 되는지 데이터베이스 관리 시스템(DBMS)에 알려주면 됩니다.
그리고 참조 무결성 제약 조건을 위반하게 되는 경우에 원하는 처리 방법도 알려주면 됩니다.
관계 데이터 연산 (관계 데이터 모델의 연산)
관계 데이터 모델에서 연산은 원하는 데이터를 얻기 위해 릴레이션에 필요한 처리 요구(query)를 수행하는 것으로, 데이터베이스 시스템의 구성 요소 중 데이터 언어의 역할을 합니다.
데이터에 대한 처리 요구 = 질의(query)
관계 데이터 모델의 연산을 간단히 관계 데이터 연산(relationship data operation)이라고도 합니다.
대표적인 관계 데이터 연산
관계 대수(relational algebra)
원하는 결과를 얻기 위해 데이터의 처리 과정을 순서대로 기술
관계 대수는 사용자가 어떤 데이터를 얻기 위해 수행해야 할 연산의 순서를 명시적으로 지정해야 하는 절차적 쿼리 언어
연산으로 표현
절차 언어(procedural language)
관계 해석(relational calculus)
원하는 결과를 얻기 위해 처리를 원하는 데이터가 무엇인지만 기술
관계 해석은 사용자가 원하는 결과를 얻기 위해 수행해야 할 연산의 순서를 명시하지 않아도 되는 비절차적 쿼리 언어입니다. 사용자는 원하는 결과의 조건만을 명시하고, 데이터베이스 시스템이 어떻게 그 결과를 도출할지 결정합니다.
언어(SQL)로 조건을 표현
비절차 언어(nonprocedural language)
관계 대수(relational algebra)
관계 대수는 원하는 결과를 얻기 위해 릴레이션을 처리하는 과정을 순서대로 기술하는 언어입니다.
연산자들의 집합으로도 정의할 수 있습니다.
관계 대수는 릴레이션을 연산합니다. 피연산자인 릴레이션에 연산자를 적용해 얻은 결과도 릴레이션입니다.
관계 대수에 속하는 대표적인 연산자
일반 집합 연산자(set operation)
수학의 집합 관련 연산자 차용
합집합, 교집합, 차집합, 카티션 프로덕트
순수 관계 연산자(relational operation)
릴레이션의 구조와 특성을 이용하는 것으로 관계 데이터 모델에서 새로 제시된 연산자
셀렉트, 프로젝트, 조인, 디비전
일반 집합 연산자
일반 집합 연산자 제약조건
일반 집합 연산자는 연산을 위해 피연산자 2개 필요
합집합, 교집합, 차집합은 피연사자인 2개의 릴레이션이 합병 가능(union-compatible)해야 합니다. (단, 카티션 프로덕트는 합병 가능 여부와 상관없이 연산이 가능합니다.)
다음 조건을 만족해야 2개의 릴레이션이 합병 가능한 것입니다.
두 릴레이션의 차수가 같다. 즉 두 릴레이션은 속성 개수가 같습니다.
2개의 릴레이션에서 서로 대응되는 속성의 도메인이 같습니다. 단, 도메인이 같으면 속성의 이름은 달라도 됩니다.
합병이 불가능한 예시
차수는 3개로 같지만, 고객 릴레이션의 나이 속성은 도메인이 INT이지만 이에 대응되는 직원 릴레이션의 직위 속성은 도메인이 CHAR(20)이라 서로 다릅니다.
합병이 가능한 예시
차수가 3개로 같고, 서로 속성의 이름은 다르지만 도메인이 같으므로 합병이 가능합니다.
합집합(union)
교집합(intersection)
차집합(difference)
카티션 프로덕트(cartesian product)
순수 관계 연산자
셀렉트(select)
릴레이션에서 주어진 조건을 만족하는 투플만 선택하여 결과 릴레이션을 구성
결과 릴레이션은 주어진 릴레이션을 수평으로 절단한 모양입니다. 즉, 해당 릴레이션에서 수평적 부분집합(horizontal subset)을 생성한 것과 같습니다.
셀렉트 연산은 하나의 릴레이션을 대상으로 수행합니다.
셀렉트 연산의 기호
조건식은 비교 연산자(>, >=, <, <=, =, ≠ )를 이용해 구성하는데, 조건식을 비교식 또는 프레디킷(predicate)이라고도 합니다.
비교 연산자와 함께 논리 연산자(,,)를 사용해 조건식을 좀 더 복잡하게 구성할 수 있습니다.
조건식을 속성과 상수의 비교나 다른 속성들 간의 비교로 표현할 수 있습니다.
속성과 상수의 비교로 구성할 때는 상수의 데이터 타입이 속성의 도메인과 일치해야 합니다.
다른 속성들 간의 비교로 구성할 때는 속성들의 도메인이 같아야 비교가 가능합니다.
셀렉트 연산의 일반적인 데이터 언어의 형식
셀렉트 연산의 교환적 특징
예시
고객 릴레이션에서 등급이 gold인 투플을 검색하시오.
고객 릴레이션에서 등급이 gold이고, 적립금이 2000 이상인 투플을 검색하시오.
다른 표현
프로젝트(product)
프로젝트 연산은 릴레이션에서 선택한 속성에 해당하는 값으로 결과 릴레이션을 구성
결과 릴레이션은 주어진 릴레이션의 일부 열로만 구성되어 해당 릴레이션에서 수직적 부분집합(vertical subset)을 생성하는 것과 같습니다.
프로젝트 연산의 기호
프로젝트 연산의 일반적인 데이터 언어의 형식
예시
고객 릴레이션에서 고객이름, 등급, 적립금을 검색하시오.
고객 릴레이션에서 등급을 검색하시오.
프로젝트 연산을 한 결과 릴레이션에도 동일한 투플이 중복되지 않고 한 번만 나타납니다.
프로젝트 연산의 결과도 릴레이션이기 때문에 중복되는 투플이 존재할 수 없다는 릴레이션의 기본 특성을 유지하는 것입니다.
조인(join)
릴레이션 하나로 원하는 데이터를 얻을 수 없어 관계가 있는 여러 릴레이션을 함께 사용해야 하는 경우 조인join 연산을 이용합니다.
조인 연산은 조인 속성을 이용해 두 릴레이션을 조합하여 하나의 결과 릴레이션을 구성합니다.
조인 속성은 두 릴레이션이 공통으로 가지고 있는 속성으로, 두 릴레이션이 관계가 있음을 나타냅니다.
조인 연산의 결과는 두 릴레이션에 대해 카티션 프로덕트 연산을 수행한 후 조인 속성의 값이 같은 조건을 만족하는 투플을 반환하는 셀렉트 연산을 수행한 것과 같습니다.
동등 조인(equal-join) 연산
예시
세타 조인(theta-join) 연산
AθB는 조인 조건으로, θ는 비교연산자 (>, >=, <, <=, =,≠)입니다. 속성 값에 대한 비교 연산이 가능하도록 A와 B는 같은 도메인으로 정의되어야 합니다.
θ 연산자가 = 인 세타 조인이 동등 조인입니다. 따라서 동등 조인은 다음과 같이 좀 더 명확히 표현하는 것이 좋습니다.
자연 조인(natural join) 연산
자연 조인은 동등 조인의 결과 릴레이션에서 중복된 속성을 제거하여 조인 속성이 한 번만 나타나는 것입니다.
즉, 세타 조인에서 "=" 연산자를 이용해 조인 조건을 표현한 것이 동등 조인이고, 동등 조인의 결과 릴레이션에서 중복된 조인 속성을 제거하는 것이 자연 조인입니다.
예시
예시 1
예시 2 (조인 속성이 여러 개의 속성으로 구성되어 있는 경우)
디비전(division)
는 릴레이션 S의 모든 투플과 관련 있는 릴레이션 R의 투플로 결과 릴레이션을 구성합니다.
단, 릴레이션 R이 릴레이션 S의 모든 속성을 포함하고 있어야 연산이 가능합니다.
이는 릴레이션 S의 모든 속성과 도메인이 같은 속성을 릴레이션 R이 포함하고 있어야 한다는 의미입니다.
디비전 연산 기호
예시
예시 1
예시 2
제품 1로 디비전 하게 되면 진짜우동과 그대로만두를 모두 주문한 고객의 아이디와 제조 업체를 검색하는 것과 의미가 같습니다.
자연 조인 연산을 확장한 세미 조인과 외부 조인(확장된 관계 대수 연산자)
세미 조인(semi-join)
세미 조인 기호
는 릴레이션 S의 조인 속성으로만 구성한(프로젝트한) 릴레이션을 릴레이션 R에 자연 조인하는 것입니다.
세미 조인은 교환적 특성이 없어 R과 S를 바꿔 작성하면 결과 릴레이션이 다릅니다.
외부 조인(outer-join)
외부 조인 기호
왼쪽(left) 외부 조인
오른쪽(right) 외부 조인
완전(full) 외부 조인
예시
예시
자연 조인 결과
고객 릴레이션의 마지막 투플은 조인 속성인 고객아이디 값에 대응하는 속성 값이 주문 릴레이션에 존재하지 않아 조인 연산에서 제외되었습니다.
세미 조인 결과
먼저 주문 릴레이션에 조인 속성인 고객아이디 속성으로 프로젝트 연산을 수행한 후, 이 결과 릴레이션과 고객 릴레이션을 자연 조인하면 최종 결과를 얻을 수 있습니다.
결과적으로 세미 조인은 고객 릴레이션에서 자연 조인 연산에 참여할 수 있는 투플만 선택하여 결과 릴레이션을 구성합니다.
주문을 한 적이 있는 고객의 데이터만 검색하고 싶을 때 세미 조인을 이용하면 검색에 불 필요한 속성을 미리 제거하여 조인 연산의 비용을 줄일 수 있다는 장점이 있습니다.
왼쪽 외부 조인 결과
관계 대수를 이용한 질의 표현
등급이 gold인 고객의 이름과 나이를 검색하시오.
고객이름이 원유선인 고객의 등급과, 원유선 고객이 주문한 주문제품, 수량을 검색하시오.
주문수량이 10개 미만인 주문 내역을 제외하고 검색하시오.
관계 해석
관계 해석의 대표적 비절차 언어로는 SQL이 있습니다.
SQL(Structured Query Language)은 사용자로 하여금 데이터에 대해 비절차적 쿼리를 작성할 수 있게 하는 언어
,
,
)를 사용해 조건식을 좀 더 복잡하게 구성할 수 있습니다.
는 릴레이션 S의 모든 투플과 관련 있는 릴레이션 R의 투플로 결과 릴레이션을 구성합니다.
는 릴레이션 S의 조인 속성으로만 구성한(프로젝트한) 릴레이션을 릴레이션 R에 자연 조인하는 것입니다.
