reference: "데이터베이스 개론" / 김연희 / 한빛아카데미
관계 데이터 모델과 관계 데이터베이스(RDB)
데이터 모델링을 통해 현실 세계의 데이터를 DB에 저장하려면 논리적 데이터 모델 중 하나를 선택해야 한다. 그 중 가장 인기있는 데이터 모델이 관계 데이터 모델이다. 그리고 이 관계 데이터 모델이 따라 제작된 DB를 관계 데이터베이스(Relational Database, RDB)라 한다. 그냥 DB를 말할 때 이 RDB를 의미할 만큼 많이 사용되는 모델과 DB이다.
관계 데이터 모델 기본용어
일반적으로 관계 데이터 모델에서는 하나의 개체에 관한 데이터를 릴레이션(relation) 하나에 담아 DB에 저장한다.
릴레이션은 관계형 데이터베이스에서는 '테이블'이라하고, NoSQL DB에서는 '컬렉션'이라 한다.
source: https://hoit1302.tistory.com/126
속성(attribute)
- == 필드(field)
- 릴레이션의 열
- 위 그림에선 고객과 관련한 6가지 중요한 데이터를 의미하는 고객아이디/고객이름/나이/등급/직업/적립금을 확인할 수 있는데, 이것들이 속성
- 릴레이션은 파일 관리 시스템의 파일과, 속성은 해당 파일의 필드와 대응
※ 속성, 필드 등 특정 영역에서만 쓰이는 용어는 아님.
속성 == 필드로 이해한다.
튜플(tuple)
- == 레코드
- 릴레이션의 행
- 고객 릴레이션에서 각 튜플은 고객 한 명에 대한 실제 속성 값 6개를 모아놓은 것으로, 고객 개체의 인스턴스
- 위 릴레이션에는 4개의 튜플 또는 4개의 고객 개체 인스턴스가 존재
- 튜플은 파일 시스템 관리 시스템에서 해당 파일의 레코드와 대응
※ 튜플, 레코드 등 특정 영역에서만 쓰이는 용어는 아님.
튜플 == 레코드로 이해한다.
도메인
- 속성 하나가 가질 수 있는 모든 값의 집합
- 관계 데이터 모델에서는 속성의 값으로 더는 분해할 수 없는 원자 값만 사용할 수 있음.
- 예를 들어 고객 릴레이션에서 등급 속성의 값으로 VIP, GOLD, SILVER, BRONZE 중 하나만 허용된다면, 4가지 값을 모아놓은 것이 등급 속성 도메인
- 등급 속성의 도메인을 정의해두면 사용자가 속성 값을 입력하거나 수정할 때 DB 시스템이 적합성을 판단하여 허용하지 않음으로써 올바른 값만 유지할 수 있음(데이터 무결성 유지).
- 일반적으로 속성의 특성을 고려한 '데이터 타입'으로 정의
- 고객아이디/고객이름/나이 등의 속성은 도메인을 정확히 정의하기 어려움. 모든 이름, 나이 값을 일일히 나열하기 힘들기 때문.
- 고객이름 속성의 도메인: CHAR(20)
- 나이 속성의 도메인: INT
- 데이터 타입 == 도메인, 변수 == 속성으로 해석
널 값
- 릴레이션에 있는 특정 튜플의 속성 값을 모르거나, 적합한 값이 없는 경우 널(null)이라는 특별한 값을 사용
- '특정 속성에 해당하는 값이 없음'을 의미하므로 숫자 0이나 공백 문자와는 다름.
차수
- 하나의 릴레이션에서 속성의 전체 개수
- 고객 릴레이션의 차수는 6
- 모든 릴레이션은 최소 1 이상의 차수를 유지
- 릴레이션의 차수는 일반적으로 자주 변하지 않는다는 정적이 특징이 있음.
카디널리티
- 하나의 릴레이션에서 튜플 전체 개수
- 고객 릴레이션의 카디널리티는 4
- 튜플이 없는 릴레이션이 존재할 수도 있으므로, 카디널리티가 0이 될 수 있음.
- 릴레이션의 튜플은 삽입/삭제가 속성보다 빈번하기에 일반적으로 카디널리티는 동적인 특징이 있음.
릴레이션과 DB의 구성
source: http://wiki.hash.kr/index.php/%EB%A6%B4%EB%A0%88%EC%9D%B4%EC%85%98
릴레이션 스키마
- 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조
- DBMS이 내부적으로 데이터 정의어(DDL)를 이용해 정의하지만, 일반적으로 다음과 같이 표현
- 릴레이션이름(속성이름1, 속성이름2, 속성이름3 .. , 속성이름n)
- ex) 학생 릴레이션(학번, 이름, 성별, 학과)
- 릴레이션 스키마는 릴레이션 내포(relation intension)이라고도 불림
릴레이션 인스턴스
- 어느 한 시점에 릴레이션에 존재하는 튜플의 집합
- 릴레이션 인스턴스에 포함된 튜플
- 튜플 == 개체의 인스턴스, 릴레이션 인스턴스는 개체의 인스턴스들의 집합
- DBMS가 내부적으로는 데이터 조작어(DML)를 이용해 릴레이션 인스턴스의 튜플을 검색하거나, 새로운 튜플 삽입과 기존 튜플 삭제 및 수정을 수행
- 릴레이션 인스턴스는 릴레이션 외연(relation extension)이라고도 불림
DB 스키마와 DB 인스턴스
일반적으로 DB는 릴레이션 여러 개로 구성된다. 예를 들어 쇼핑몰 운영을 위한 DB는 고객 릴레이션, 상품 릴레이션, 주문 릴레이션 등으로 구성될 수 있다.
DB의 전체 구조를 의미하는 DB 스키마는 DB를 구성하는 릴레이션들의 스키마를 모아놓은 것이다.
따라서 특정 DB 스키마를 설계한다는 의미는 필요한 모든 릴레이션의 스키마를 모두 정의하는 것이다.
그리고 DB 인스턴스는 어느 한 시점에서 DB에 저장된 데이터 내용의 전체 집합을 의미힌다. 즉 DB를 구성하는 모든 릴레이션의 인스턴스를 모아놓은 것이다.
관계 데이터 모델에서의 릴레이션 특성
관계 데이터 모델의 릴레이션에는 중요한 4가지 특성이 있다. 이 4가지 특성을 기본으로 만족시켜야 테이블이 릴레이션으로 인정받을 수 있다.
1. 튜플의 유일성: "하나의 릴레이션에는 동일한 튜플이 존재할 수 없다."
- 하나의 릴레이션에는 똑같은 튜플이 있으면 안 되고, 모든 튜플에는 다른 튜플과 구별되는 유일한 특성이 있어야 함.
- 관계 데이터 모델의 릴레이션에서는 하나 또는 여러 개의 속성을 미리 선정해두고 이 속성의 값을 튜플마다 다르게 지정하여 튜플의 유일성을 판단한다.
- 튜플을 유일하게 구별하기 위해 선정되는 속성(또는 속성들의 모임)을 키(Key)라고 한다.
2. 튜플의 무순서: "하나의 릴레이션에서 튜플 사이의 순서는 무의미하다."
- 튜플 순서가 바뀐다고 다른 릴레이션이 될 수 없고, 순서와 상관없이 튜플 내용이 같아야 같은 릴레이션이다.
- 이는 DB는 위치가 아닌 내용으로 검색되기 때문이다.
3. 속성의 무순서: "하나의 릴레이션에서 속성 사이의 순서는 무의미하다."
- 튜플의 무순서성과 동일
4. 속성의 원자성: "속성 값으로 원자 값만 사용할 수 있다.""
- 하나의 속성은 여러 개의 값, 즉 다중 값을 가질 수 없다.
- 현실에서는 '전화번호' 속성, '직업' 속성(two job을 뛰는 경우)에 다중 값을 가질 수 있지만, 관계 데이터 모델은 이러한 복잡한 개념을 배제하고 릴레이션을 단순한 구조로 정의하고자 하는 특징이 있어 이를 허용하지 않음.
릴레이션에서 키의 역할과 종류
튜플을 유일하게 구별하기 위해 모든 속성을 이용하는 것보다 일부 속성만 이용하는 것이 효율성을 높일 수 있다. 릴레이션에 포함된 튜플들을 유일하게 구별해주는 역할은 속성 또는 속성들의 집합인 키가 담당한다. 키는 관계 데이터 모델에서 중요한 제약조건을 정의한다.
source: https://ooeunz.tistory.com/3
슈퍼키(super key)
- 슈퍼키는 유일성의 특성을 만족하는 속성 또는 속성들의 집합
- 유일성은 키가 갖추어야 하는 기본 특성으로, 하나의 릴레이션에서 키로 지정된 속성의 값은 튜플마다 달라야 한다는 의미
- 고객 릴레이션에서 고객 아이디 속성 하나 또는 고객 아이디를 포함하는 속성 집합은 모두 슈퍼키가 될 수 있다.
- 유일성은 만족하지만, 최소성은 만족하지 못하다.
: 고객 아이디 하나의 속성으로만 튜플을 구분할 수 있었지만, 다른 속성들까지 확인해야 한다면 비효율적인 작업이 될 것이다.
"최소성"은 키를 구성하고 있는 여러 속성 중에서 하나라도 없으면 튜플을 유일하게 구별할 수 없는, 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성이다(하나의 속성으로 구성된 키는 당연히 최소성을 만족).
후보키(candidate key)
- 유일성과 최소성을 만족하는 속성 또는 속성들의 집합이다.
: 슈퍼키 중에서 최소성을 만족하는 것이 후보키가 된다. - 예를 들어 (고객 아이디), (고객 아이디, 고객 이름), (고객 아이디, 고객 주소) 등 슈퍼키 중에 (고객 아이디)가 후보키가 된다.
후보키가 되기 위해 만족해야 하는 유일성과 최소성의 특성은 새로운 튜플이 삽입되거나 기존 튜플의 속성 값이 바뀌어도 유지되어야 한다.
그리고 후보키를 선정할 때는 현재의 릴레이션 내용, 즉 릴레이션 인스턴스만 보고 유일성과 최소성을 판단해서는 안 된다. DB가 사용될 현실 세계의 환경까지 염두에 두고 속성의 본래 의미를 정확히 이해한 후 슈퍼키와 후보키를 선별해야 한다. 예를 들어 고객 릴레이션에서 현재 고객 이름 속성의 값이 중복되지 않았다는 이유로 이를 키로 고객 이름 만을 후보키로 두어선 안된다. 고객 이름이 언제나 다를 것이라고 보장할 수 없고, 실제 현실 세계에서도 충분히 같은 이름의 고객이 있을 수 있기 때문이다.
기본키(primary key)
- 여러 후보키 중에서 기본적으로 사용할 키를 선택하는데 이것이 기본키이다.
- 후보키가 여러 개일 경우에는 DB 사용 환경을 고려하여 적합한 것을 기본키로 선택하면 된다.
후보키 중 무엇을 기본키로?
위와 같은 고객 릴레이션이 있다. 여기서 후보키는 (고객 아이디), (고객 이름, 주소)가 있다(가족끼리 동명이인은 없음). 어떤 후보키를 기본키로 지정하는 것이 좋을까? 기본키를 선택할 때 고려하면 도움이 되는 몇 가지 기준이 있다.
1. 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
기본키가 널 값인 튜플은 다른 튜플과 구별하여 접근하기 어려우므로 이런 가능성이 있는 키는 기본키로 선택하지 않는 것이 좋다.
고객 아이디는 회원가입 시 반드시 입력해야 하지만 고객이름이나 주소는 입력하지 않아도 되는 경우가 많다. 이런 경우에는 고객 아이디를 기본키로 선택하는 것이 좋다.
2. 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
기본키는 다른 튜플과 구별되는 값을 가지고, 널 값은 허용하지 않으므로 이를 확인하는 작업이 필요하다. 그런데 값이 자주 변경되는 속성으로 구성된 후보키를 기본키로 선택하면 속성 값이 변경될 때마다 기본키 값으로 적합한 지 여부를 판단해야 하므로 번거롭다(성능이 떨어진다).
보통 주소는 고객 아이디와 이름보다 변경될 가능성이 높다. 따라서 주소 속성이 포함되지 않은 고객 아이디를 기본키로 선택하는 것이 좋다.
3. 단순한 후보키를 기본키로 선택한다.
단순한 후보키는 자리수가 적은 정수나 단순 문자열인 속성으로 구성되거나, 구성하는 속성의 개수가 적은 후보키를 말한다. DB를 실제로 처리하는 컴퓨터 시스템의 연산 복잡도를 줄이기 위해 단순 값으로 이루어진 또는 속성의 갯수가 적은 후보키를 기본키로 선택하는 것이 좋다.
대체키(alternate key)
- 기본키로 선택되지 못한 후보키를 의미
외래키(foreign key)
- 어떤 릴레이션에 소속된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키이다.
: 다시 말해 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합이 외래키이다. - 외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요하다.
- 외래키는 중복되어도 상관없다.
source: https://blog.daum.net/vkfksskfk2/10
위 그림에서 고객 릴레이션과 주문 릴레이션의 관계를 살펴보자,
고객 릴레이션의 속성은 6개이고, 고객 아이디 속성이 기본키이다.
주문 릴레이션의 속성은 6개이고, 주문번호 속성이 기본키이다.
주문 릴레이션의 주문 고객 속성이 고객 릴레이션의 기본키인 고객 아이디 속성을 참조하면 주문 고객 속성이 외래키이다.
외래키를 통해 고객 릴레이션과 주문 릴레이션이 관계를 맺어 주문 릴레이션의 튜플과 연관성 있는 고객 릴레이션의 튜플을 연결시킬 수 있다.
일반적으로 주문 릴레이션과 같이 외래키를 가진 릴레이션을 참조 릴레이션이라 하고, 고객 릴레이션과 같이 기본키를 가진 릴레이션을 참조되는 릴레이션이라 한다.
외래키가 되는 속성과 기본키가되는 속성의 이름은 달라도 되지만, 외래키 속성의 도메인과 참조되는 기본키 속성의 도메인은 반드시 같아야 한다.
만약 외래키가 참조되는 릴레이션의 기본키가 아닌 다른 속성을 참조한다면 어떻게 될까? 기본키가 아니면 튜플을 유일하게 구별하기 어렵기에 참조되는 릴레이션에서 관련있는 튜플을 검색하지 못할 수 있다. 그러므로 외래키는 반드시 다른 릴레이션의 기본키를 참조해야 하며 외래키의 도메인은 참조되는 기본키와 같게 정의되어야 한다.
조금 더 복잡한 외래키 사례
source: https://velog.io/@sunnysideup/5.-%EA%B4%80%EA%B3%84-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8
하나의 릴레이션에는 외래키가 여러 개 존재할 수 있다. 위 그림과 같이 세 개의 릴레이션(학생/상담/교사)은 외래키를 이용해 서로의 관계를 맺어진다.
참조하는 릴레이션과 참조되는 릴레이션이 같은 경우도 있다.
source: https://velog.io/@wilko97
직원 릴레이션은 직원 번호 속성이 기본키이다. 그리고 매니저 번호 속성은 직원을 관리하는 매니저 번호를 의미하는 속성이므로 같은 릴레이션의 직원 번호, 즉 기본키를 참조하는 외래키이다. 이처럼 직원 릴레이션은 기본키와 외래키가 하나의 릴레이션에서 표현되며, 이것은 직원 릴레이션이 자기 자신의 릴레이션과 관계를 맺고 있음을 의미한다.
무결성 제약(제약조건)의 의미와 필요성
관계 데이터 모델에서 정의하고 있는 기본 제약 사항은 키와 관련한 무결성 제약조건이다.
무결성은 데이터에 결함이 없는 상태, 즉 데이터를 정확하고 유효하게 유지하는 것이다.
무결성 제약조건의 주요 목적은 DB에 저장된 데이터의 무결성을 보장하고, DB의 상태를 일관되게 유지하는 것이다.
무결성 제약조건은 어느 시점에 DB에 저장된 데이터를 의미하는 DB 상태 또는 DB 인스턴스가 항상 지켜야 하는 중요한 규칙이다. DB가 삽입/삭제/수정 연산으로 상태가 변하더라도 무결성 제약조건은 반드시 지켜져야 한다.
관계 데이터 모델이 기본으로 포함하고 있는 무결성 제약조건에는 개체 무결성 제약조건과 참조 무결성 제약조건이 있다.
개체 무결성 제약조건
- 기본키에 널 값을 가지면 안 된다는 규칙
- 기본키를 구성하는 속성 전체나 일부가 널 값이 되면 튜플의 유일성을 판단할 수 없어 기본키의 본래 목적을 상실하게 됨.
- 개체 무결성 제약조건을 만족시키려면 새로운 튜플이 삽입되는 연산과 기존 튜플의 기본키 속성 값이 변경되는 연산이 발생했을 때, 기본키에 널 값이 포함되는 상황에서는 연산의 수행을 거부하면 된다. 이는 일반 사용자보다는 DBMS에서 자동으로 수행한다.
source: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=james_parku&logNo=110175820697
참조 무결성 제약조건
- 외래키는 참조할 수 없는 값을 가질 수 없다는 규칙
- 개체 무결성 제약조건이 기본키에 대한 규칙으로 각 릴레이션마다 적용되었다면, 참조 무결성 제약조건은 외래키에 대한 규칙으로 연관된 릴레이션들에 적용됨.
- 외래키가 자신이 참조하는 릴레이션의 기본키와 상관이 없는 값을 가지게 되면 두 릴레이션을 연관시킬 수 없으므로 외래키 본래의 의미가 없어진다. 그러므로 외래키는 자신이 참조하는 릴레이션에 기본키 값으로 존재하는 값, 즉 참조 가능한 값만 가져야 한다.
source: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=james_parku&logNo=110175820697
외래키의 값이 NULL이라면 참조 무결성 제약조건을 위반한 것일까? 그렇지만은 않다.
source: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=james_parku&logNo=110175820697
수강 릴레이션의 학번 속성이 널이라는 것은 수강하는 학생이 누구인지 모르는 것이지 학생 릴레이션에 존재하지 않은 학생이 수강하는 것(참조 무결성 제약조건 위반)으로 판단하기는 어렵기 때문이다. 따라서 참조 무결성 제약조건을 만족시키려면 외래키가 참조 가능한 값만 가져야 하지만, 널 값을 가진다고 해서 참조 무결성 제약조건을 위반한 것으로 판단해서는 안된다.
DB 상태 변화에도 참조 무결성 제약조건을 만족시키는 몇 가지 유형
특정 릴레이션에 새로운 튜플을 삽입하는 상황에서는 해당 릴레이션이 지정한 기본키를 바탕으로 개체 무결성 제약조건을 위반하지 않는지 확인해야 한다.
이 때 이 릴레이션이 다른 릴레이션을 참조하는 릴레이션이라면, 즉 외래키가 존재하는 릴레이션이라면 참조 무결성 제약조건도 확인해야 한다. 만약 외래키 속성 값으로 참조할 수 없는 값으로 선택되면 이 릴레이션에 새로운 튜플을 삽입하는 연산의 수행을 거부하면 된다.
case 1)
참조되는 릴레이션에 튜플 삭제 연산은 참조 무결성 제약조건을 위반하지 않는 경우에만 수행된다. 만약 삭제되는 튜플(이하 튜플 A)의 기본키 값을 참조하는 릴레이션의 튜플 중 이 삭제될 튜플을 참조하는 튜플(이하 튜플 B)이 존재하고 있다면 삭제 연산을 수행하지 못한다는 뜻이다. 하지만 다음과 같은 방식들로 삭제 연산을 수행할 수 있다.
- 튜플 A가 삭제될 때 튜플 B도 삭제한다.
- 튜플 B의 외래키 값을 널이나 기본 값으로 지정한다.
case 2)
참조되는 릴레이션의 튜플의 속성 값을 변경할 시 이 속성이 기본키 속성이라면 마찬가지로 참조 무결성 제약조건을 위반하지 않는 경우에만 수행된다. 튜플 B가 존재하는 상태에서 튜플 A의 기본키 값을 변경하려면 이 연산을 수행하지 못한다는 뜻이다. 하지만 다음과 같은 방식들로 변경 연산을 수행할 수 있다.
- 튜플 A의 기본키 값을 변경할 때 튜플 B의 외래키 값도 함께 변경한다.
DB 상태가 빈번하게 변경되는 경우 참조 무결성 제약조건을 계속 만족시키기 어렵다. 하지만 이를 DBMS에서 자동으로 수행하기에 새로운 릴레이션을 생성할 때마다 어떤 속성들이 외래키이고 어떤 릴레이션의 기본키를 참조하는지, 그리고 참조 무결성 제약조건을 위반하게 되는 경우 원하는 처리 방법도 알려주면 된다.
