데이터베이스 - 관계 데이터 모델(릴레이션, 무결성 제약조건)

릴레이션(Relation, table, file)

행(투플, tuple)과 열(속성, attribute)로 구성된 테이블

 

	속성1↓(스키마)	속성2↓(스키마)	속성3↓(스키마)	속성4↓(스키마)
투플1(인스턴스)→	도메인1-1	도메인1-2	도메인1-3	도메인1-4
투플2(인스턴스)→	도메인2-1	도메인2-2	도메인2-3	도메인2-4
투플3(인스턴스)→	도메인3-1	도메인3-2	도메인3-3	도메인3-4
투플4(인스턴스)→	도메인4-1	도메인4-2	도메인4-3	도메인4-4

※ degree(차수, 속성 수) : 4개

※ cardinality(투플 수) : 4개

릴레이션 스키마(Schema, intension, header)

• 속성(attribute) : 릴레이션 스키마의 열
• 도메인(domain) : 속성이 가질 수 있는 값의 집합. int, char, varchar(40) 등 지정된 값의 범위.
• 차수(degree) : 속성의 개수

스키마의 표현

릴레이션 이름(속성1 : 도메인1, 속성2 : 도메인2, 속성3 : 도메인3 ...)

 

 

릴레이션 인스턴스(Instance, extension, data)

• 투플(tuple) : 릴레이션의 행
• 카디날리티(cardinality) : 투플의 수

※투플이 가지는 속성의 개수는 릴레이션 스키마의 차수와 동일하고, 릴레이션 내의 모든 투플은 서로 중복되지 않아야 함

 

릴레이션의 특징

• 속성은 단일 값을 가진다
  각 속성의 값은 도메인에 의해 정의된 값 만을 가진다 -> 그 값은 모두 단일 값이어야 함.
• 속성은 서로 다른 이름을 가진다
  한 릴레이션 안에서 속성은 서로 다른 이름을 가져야 한다
• 한 속성의 값은 모두 같은 도메인 값을 가진다
  한 속성에 속한 열은 모두 그 속성에서 정의한 도메인 값만 가질 수 있다
• 속성의 순서는 상관없다
  속성의 순서가 달라도 릴레이션 스키마는 같음. 독립적인 set이기 때문에...
• 릴레이션 내의 중복된 투플은 허용하지 않는다
  하나의 릴레이션 인스턴스 내에서는 서로 중복된 값을 가질 수 없다 -> 모든 투플은 서로 값이 달라야 한다
• 투플의 순서는 상관없다
  투플의 순서가 달라도 릴레이션 이다. 데이터의 삭제, 수정, 삽입에 따라 순서가 바뀔 수 있다.

 

예) 릴레이션의 특징에 위배된 경우...

 

 

무결성 제약조건

데이터베이스는 데이터 저장 시 일관성을 유지하고 중복을 최소화 -> 데이터의 신뢰성 유지

데이터의 삽입, 삭제, 수정 시 여라가지 제약조건이 따른다...

 

키(Key)

특정 투플을 식별(Primary Key)

키 릴레이션 간의 관계를 맺는데(Foreign Key) 사용한다.

 

슈퍼키

투플을 유일하게 식별할 수 있는 속성(혹은 속성의 집합)

• ex) 고객 릴레이션
  고객번호 : 고객별로 유일한 값이 부여되어 투플 식별 가능
  이름 : 동명이인이 있을 수 있으니까 유일 식별 불가능
  주민번호 : 개인별로 유일한 값이라 투플 식별 가능
  주소 : 주소가 같을 수도 있으니까(가족이라던가), 식별 안됨
  핸드폰 : 한 사람이 여러개의 번호를 사용할 수도 있고, 폰 없는 사람도 있으니 식별 불가능

 

후보키

투플을 유일하게 식별할 수 있는 속성의 최소 집합

• ex) 주문 릴레이션
  고객번호 : 한 고객이 여러 주문을 할 수 있으므로 후보키가 될 수 없음
  도서번호 : 도서번호가 2인 '어떤 책'은 n 회의 주문 기록이 있으므로 투플을 유일하게 식별할 수 없음
• 주문 릴레이션의 후보키는 2개의 속성을 합한 (고객번호, 도서번호)가 된다.
  2개 이상의 속성으로 이루어진 키 -> 복합키(composite key)

 

기본키(Primary Key)

여러 후보키 중 하나를 선정하여 대표로 삼는 키

후보키가 하나 뿐이라면 그 후보키 = 기본키, 여러개라면 릴레이션의 특성을 반영하여 하나를 선택하면 된다

• 기본키 선정 시 고려사항
  릴레이션 내 투플을 식별할 수 있는 고유한 값
  null은 허용치 않는다
  값의 변동이 없어야 함
  최대한 적은 수의 속성 집합으로 이루어져 있어야 함
  문제 발생 소지가 없어야 함(주민등록번호라던가 말이지)

 

대리키(surrogate key) : 

마땅한 기본키가 없을 때 일련번호 같은 가상의 속성을 만들어서 기본키로 삼는다

 

대체키(alternate key) : 키워드 UNIQUE

기본키로 선정되지 않은 후보키 (후보키이지만 기본키가 될 가능성이 있다)

ex) 고객 릴레이션, 고객번호와 주민번호 중 [고객번호 = 기본키] 로 지정하면, [주민번호 = 대체키] 가 됨.

 

외래키(foreign key)

다른 릴레이션(테이블)의 기본키를 참조하는 속성. 다른 릴레이션의 기본키를 참조하여 릴레이션 간의 관계를 표현한다.

 

- 외래키 특징 -

• 관계 데이터 모델의 특징인 릴레이션 간의 관계를 표현한다
• 다른 릴레이션의 기본키를 참조
• 참조하는 키(외래키)와 참조되는 키(기본키)의 양 쪽 릴레이션의 도메인(값의 범위)이 서로 같아야 한다
• 참조되는 기본키 값이 변경되면 외래키 값도 변경된다
• null값과 중복값 허용된다
• 자기자신의 기본키를 참조하는 외래키도 가능하다
• 외래키가 기본키의 일부가 될 수 있다

이것이 Foreign Key ! (코드라 생각하면)

Customer customer = new Customer();

class Customer (

Product product;

Customer(Product product){
this.product = product;
}
)

 

 

 

 

무결성 제약조건

• 데이터 무결성(integrity)
  저장된 데이터의 일관성과 정확성을 지키는 것
• 도메인 무결성 제약조건
  도메인 제약. 릴레이션 내의 투플들이 각 속성의 도메인에 지정된 값 만을 가져야 한다는 조건.
  SQL문에서 데이터형식(type), null, 기본값(default), check 등을 사용하여 지정할 수 있다
• 개체 무결성 제약조건
  기본키 제약(primary key constraint).
  릴레이션은 기본키를 지정하고 그에 따른 무결성... 즉 기본키는 null이면 안되고, 릴레이션 내에 오직 하나의 값만 존재해야 한다
• 참조 무결성 제약조건
  외래키 제약(foreign key constraint). 릴레이션 간의 참조관계를 선언하는 제약조건.
  자식 릴레이션의 외래키는 부모 릴레이션의 기본키와 도메인이 동일해야 한다.
  자식 릴레이션 값이 변경될 때, 부모 릴레이션의 제약을 받는다.