[DATABASE] 관계 데이터베이스의 모델

릴레이션(relation) : 행과 열로 구성된 테이블

ex)

도서번호	도서이름	출판사	가격
1	축구의 역사	굿스포츠	7000
2	축구 아는 여자	나무수	13000
3	축구의 이해	대한미디어	22000
4	골프 바이블	대한미디어	35000
5	피겨 교본	굿스포츠	8000

관계(relationship) 

1. 릴레이션 내에서 생성되는 관계 : 릴레이션 내 데이터들의 관계

2. 릴레이션 간에 생성되는 관계 : 릴레이션 간의 관계

테이블 개념 :

스키마의 요소

+) 스키마란? 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것입니다.

               DB에 어떤 구조로 데이터에 저장되는 가를 나타내는 데이터베이스 구조를 스키마라고 합니다.

1. 속성(Attribute) : 릴레이션 스키마의 열

2. 도메인(Domain) : 속성이 가질 수 있는 값의 집합

+) 도메인을 사용하는 이유?

만약 사원 번호라고 하는 필드가 존재할때 변수를 변경하고 싶으면 선언되어 있는 테이블 모두를 찾아다니면서 수정해주어야하겠지만

domain을 설정해놓으면 도메인 하나만 수정하면 도메인을 사용하는 모든 테이블 구조가 변경

ex) 

CREATE DOMAIN CUSTNO AS 
INTEGER 
CHECK (VALUE > 1000) 

CREATE DOMAIN JOBGRADE AS 
SMALLINT 
CHECK (VALUE BETWEEN 0 AND 6) 

참고 : http://firebird.borlandforum.com/impboard/impboard.dll?action=read&db=fb_faq&no=9

3. 차수 : 속성의 개수

인스턴스 요소

1. 튜플(tuple) : 릴레이션의 행

2. 카티날리티(cardinality) : 튜플의 수

-> 튜플이 가지는 속성의 개수는 릴레이션 스키마의 차수와 동일하고 

    릴레이션 내의 모든 튜플들은 서로 중복되지 않아야함

릴레이션의 특징

1. 속성은 단일 값을 가짐

2. 속성은 서로 다른 이름을 가짐

3. 한 속성의 값은 모두 같은 도메인 값을 가짐

-> 한 속성에 속한 열은 모두 그 속성에서 정의한 도메인 값만 가질 수 있음

4. 속성의 순서는 상관 없음

5. 릴레이션 내의 중복된 튜플은 허용하지 않음

6. 튜플의 순서는 상관 없음

관계 데이터 모델

: 관계 데이터 모델은 데이터를 2차원 테이블 형태인 릴레이션으로 표현하며 

 릴레이션에 대한 제약조건과 관계 연산을 위한 관계대수를 정의

키

- 특정 튜플을 식별할 때 사용하는 속성 혹은 속성의 집합

- 릴레이션은 중복된 튜플을 허용하지 않기 때문에 각각의 튜플에 포함된 속성들 중 어느 하나는 값이 달라야함

  즉 키가 되는 속성은 반드시 값이 달라서 튜플들을 서로 구별할 수 있어야함

- 키는 릴레이션 간의 관계를 맺는 데도 사용

슈퍼키

- 튜플을 유일하게 식별할 수 있는 하나의 속성 혹은 속성의 집합

  튜플을 유일하게 식별할 수 있는 값이면 모두 슈퍼키가 될 수 있음

ex)

고객 번호 : 고객별로 유일한 값 -> 식별 가능

이름 : 동명이인

주민번호 : 유일 -> 식별 가능

주소 : 가족 같은 경우 동일

핸드폰 : 여러개의 핸드폰 사용가능

ex)

(주민번호) (주민번호 이름) (주민번호 이름 주소) (주민번호 이름 핸드폰) (고객번호) (고객번호 이름 주소) 

(고객번호 이름 주민번호 주소 핸드폰) 등

후보키

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

- 2개 이상의 속성으로 이루어진 키를 복합키(composite key)라고 함

기본키(Primary key)

: 후보키 중에서 기본적으로 사용하기 위해 선택한 키

- 릴레이션 내 튜플을 식별 할 수 있는 고유한 값을 가져야함

- NULL 값은 허용하지 않음

- 키 값의 변동이 일어나지 않아야함

- 최대한 적은 수의 속성을 가진 것이라야 함

- 향후 키를 사용하는 데 있어서 문제 발생 소지가 없어야함

대체키

: 기본키로 선택하지 못한 후보키

외래키

: 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합

 릴레이션들 간의 관계를 표현

 참조하는 릴레이션 : 외래키를 가진 릴레이션

 참조되는 릴레이션 : 외래키가 참조하는 기본키를 가진 릴레이션

특징

- 참조되는 (기본키)값이 변경되면 참조하는(외래키)값도 변경

- NULL값과 중복이 허용

- 자기 자신의 기본키를 참조하는 외래키도가능

- 외래키가 기본키의 일부가 될 수 있음

키의 포함 관계 : 

무결성 제약조건

1. 데이터 무결성 : 데이터베이스에 저장된 데이터의 일관성과 정확성을 지키는 것

2. 도메인 무결성 제약조건 : 도메인 제약, 릴레이션 내의 튜플들이 각 속성의 도메인에 지정 된 값만을 가져야한다.

3. 개체 무결성 제약조건 : 기본키 제약. 기본키는 NULL을 가져서는 안되며 릴레이션 내에 오직 하나의 값만 존재

- 기본키 값이 같으면 삽입 금지

- 기본키 값이 같거나 NULL로 수정 금지

- 특별한 확인이 필요하지 않으면 즉시 삭제

4. 참조 무결성 제약조건 : 외래키 제약. 자식릴레이션의 외래키는 부모 릴레이션의 기본키와 도메인이 동일해야함

                            자식 릴레이션의 값이 변경될 때 부모 릴레이션의 제약을 받음

- 부모 릴레이션에서 튜플을 삭제할 때 참조 무결성 조건을 만족하기 위한 고려사항

1) 즉시 작업을 중지

2) 자식 릴레이션의 관련 튜플 삭제

3) 초기에 설정된 다른 값으로 변경

4) NULL값으로 설정

RESTRICTED	자식 릴레이션에서 참조하고 있을 경우 부모의 릴레이션의 삭제작업을 거부 (ERROR처리)
CASCADE	자식 릴레이션의 관련 튜플을 같이 삭제 처리함
DEFAULT	자식 릴레이션의 관련 튜플을 미리 설정해둔 값으로 변경
NULL	자식 릴레이션의 관련 튜플을 NULL값으로 변경

명령어

CREATE TABLE Book (

 bookid       INT PRIMARY KEY,

 bookname     VARCHAR(40),

 publisher   VARCHAR(40),

 price       INT 

);

CREATE TABLE  Customer (

 custid      INT PRIMARY KEY,  

 name      VARCHAR(40),

 address   VARCHAR(40),

 phone     VARCHAR(30)

);

CREATE TABLE Orders (

 orderid INT  PRIMARY KEY,

 custid INT  REFERENCES Customer(custid),

 bookid INT  REFERENCES Book(bookid),

 saleprice INT,

 orderdate DATE

);

INSERT INTO Book VALUES(1, '축구의 역사', '굿스포츠', 7000);

INSERT INTO Book VALUES(2, '축구 아는 여자', '나무수', 13000);

INSERT INTO Book VALUES(3, '축구의 이해', '대한미디어', 22000);

INSERT INTO Book VALUES(4, '골프 바이블', '대한미디어', 35000);

INSERT INTO Book VALUES(5, '피겨 교본', '굿스포츠', 8000);

INSERT INTO Book VALUES(6, '역도 단계별 기술', '굿스포츠', 6000);

INSERT INTO Book VALUES(7, '야구의 추억', '이상미디어', 20000);

INSERT INTO Book VALUES(8, '야구를 부탁해', '이상미디어', 13000);

INSERT INTO Book VALUES(9, '올림픽 이야기', '삼성당', 7500);

INSERT INTO Book VALUES(10, 'Olympic Champions', 'Pearson', 13000);

INSERT INTO Customer VALUES (1, '박지성', '영국 맨체스타', '000-5000-0001');

INSERT INTO Customer VALUES (2, '김연아', '대한민국 서울', '000-6000-0001');  

INSERT INTO Customer VALUES (3, '장미란', '대한민국 강원도', '000-7000-0001');

INSERT INTO Customer VALUES (4, '추신수', '미국 클리블랜드', '000-8000-0001');

INSERT INTO Customer VALUES (5, '박세리', '대한민국 대전', NULL);

INSERT INTO Orders VALUES (1, 1, 1, 6000, '2013-07-01'); 

INSERT INTO Orders VALUES (2, 1, 3, 21000, '2013-07-03');

INSERT INTO Orders VALUES (3, 2, 5, 8000, '2013-07-03'); 

INSERT INTO Orders VALUES (4, 3, 6, 6000, '2013-07-04'); 

INSERT INTO Orders VALUES (5, 4, 7, 20000, '2013-07-05');

INSERT INTO Orders VALUES (6, 1, 2, 12000, '2013-07-07');

INSERT INTO Orders VALUES (7, 4, 8, 13000, '2013-07-07');

INSERT INTO Orders VALUES (8, 3, 10, 12000, '2013-07-08'); 

INSERT INTO Orders VALUES (9, 2, 10, 7000, '2013-07-09'); 

INSERT INTO Orders VALUES (10, 3, 8, 13000, '2013-07-10');

프로그래머는!! 사용자가 어떤 정보를 원하는 지 알고 빠르게 서비스 할 수 있어야한다.