관계 데이터 모델과 제약조건 개념, 특성, 키, 무결성 제약조건.

Presentation on theme: "관계 데이터 모델과 제약조건 개념, 특성, 키, 무결성 제약조건."— Presentation transcript:

1 관계 데이터 모델과 제약조건 개념, 특성, 키, 무결성 제약조건

2 목차 I. 관계 데이터 모델의 개념 II. 릴레이션의 특성 III. 릴레이션의 키 IV. 무결성 제약조건

3 2. 관계 데이터 모델과 제약조건 관계 데이터 모델은 지금까지 제안된 데이터 모델들 중에서 가장 개념이 단순한 데이터 모델의 하나 IBM 연구소에 근무하던 E.F. Codd가 1970년에 관계 데이터 모델을 제안함 관계 데이터 모델을 최초로 구현한 가장 중요한 관계 DBMS 시제품은 1970년 대에 IBM 연구소에서 개발된 System R 1980년대 후반부터 여러 가지 데이터 모델들이 새로 등장했지만 관계 DBMS는 여전히 가장 널리 사용되는 DBMS

4 2. 관계 데이터 모델과 제약조건 다수 사용자용 ORACLE MS SQL Server DB2(SQL/DS) INFORMIX
[표2. 1] 관계 DBMS 제품 다수 사용자용 ORACLE MS SQL Server DB2(SQL/DS) INFORMIX SYBASE 개인용 MSFT/Access 자바기반 InstanceDB Simple Text

5 2. 관계 데이터 모델과 제약조건 관계 데이터 모델이 큰 성공을 거둔 요인
바탕이 되는 데이터 구조로서 간단한 테이블(릴레이션)을 사용 중첩된 복잡한 구조가 없음 집합 위주로 데이터를 처리 숙련되지 않은 사용자도 쉽게 이해할 수 있음 표준 데이터베이스 응용에 대해 좋은 성능을 보임 다른 데이터 모델에 비해 이론이 잘 정립되었음 관계 데이터베이스 설계와 효율적인 질의 처리 면에서 뛰어난 장점을 가짐

6 2.1 관계 데이터 모델의 개념 관계 데이터 모델 관계 데이터 모델은 동일한 구조(릴레이션)의 관점에서 모든 데이터를 논리적으로 구성 선언적인 질의어를 통한 데이터 접근을 제공 응용 프로그램들은 데이터베이스 내의 레코드들의 어떠한 순서와도 무관하게 작성됨 관계 데이터 모델의 목적은 높은 데이터 독립성을 제공하는 것 사용자는 원하는 데이터(what)만 명시하고, 어떻게 이 데이터를 찾을 것인가(how)는 명시할 필요가 없음 논리적으로 연관된 데이터를 연결하기 위해서 링크나 포인터를 사용하지 않음

7 2.1 관계 데이터 모델의 개념 기본적인 용어 릴레이션(relation): 2차원의 테이블(스프레드 시트와 유사)
레코드(record): 릴레이션의 각 행 튜플(tuple): 레코드를 좀더 공식적으로 부르는 용어 애트리뷰트(attribute): 릴레이션에서 이름을 가진 하나의 열

8 2.1 관계 데이터 모델의 개념 열(애트리뷰트) 릴레이션이름 기본키 EMPNO EMPNAME TITLE DNO SALARY
2106 김창섭 대리 2 3426 박영권 과장 3 3011 이수민 부장 1 1003 조민희 EMPLOYEE 행(튜플) 애프티뷰트값 [그림2. 1] 릴레이션의 예

9 2.1 관계 데이터 모델의 개념 도메인(domain) 한 애트리뷰트에 나타날 수 있는 값들의 집합
각 애트리뷰트의 도메인의 값들은 원자값 프로그래밍 언어의 데이터 타입과 유사함 동일한 도메인이 여러 애트리뷰트에서 사용될 수 있음 복합 애트리뷰트나 다치 애트리뷰트는 허용되지 않음 도메인 정의 CREAT DOMAIN EMPNAME CHAR(10) CREAT DOMAIN EMPNO INTEGER CREAT DOMAIN DNO INTEGER

10 2.1 관계 데이터 모델의 개념 예:도메인 EMPLOYEE 릴레이션의 EMPNAME 애트리뷰트에는 김창섭, 박영권, 이수민, 조민희, …등의 이름이 나타날 수 있다. 그림 2.2는 EMPNAME 도메인을 보여준다. 김창섭 박영권 이수민 조민희 김동수 안영석 … EMPNAME에 나타날 수 있는 모든 가능한 값들의 집합 [그림2. 2] EMPNAME 도메인

11 차수(degree)와 카디날리티(cardinality)
2.1 관계 데이터 모델의 개념 차수(degree)와 카디날리티(cardinality) 차수: 한 릴레이션에 들어 있는 애트리뷰트들의 수 유효한 릴레이션의 최소 차수는 1 카디날리디: 릴레이션의 튜플 수 유효한 릴레이션은 카디날리티 0을 가질 수 있음 릴레이션의 차수는 자주 바뀌지 않음 릴레이션의 카디날리티는 시간이 지남에 따라 계속해서 변함

12 2.1 관계 데이터 모델의 개념 공식적인 용어 자주 사용되는 용어 파일 시스템의 용어 릴레이션 테이블 파일 튜플 행/레코드
[표2. 2] 용어들의 대응관계 공식적인 용어 자주 사용되는 용어 파일 시스템의 용어 릴레이션 테이블 파일 튜플 행/레코드 레코드 애트리뷰트 열 필드

13 2.1 관계 데이터 모델의 개념 널값(null value)
‘알려지지 않음’ 또는 ‘적용할 수 없음’을 나타내기 위해 널값을 사용 예: 사원 릴레이션에 새로운 사원에 관한 튜플을 입력하는데, 신입 사원의 DNO(부서번호)가 결정되지 않았을 수 있음 널값은 숫자 도메인의 0이나 문자열 도메인의 공백 문자 또는 공백 문자열과 다름 DBMS들마다 널값을 나타내기 위해 서로 다른 기호를 사용함

14 릴레이션 스키마(relation schema)
2.1 관계 데이터 모델의 개념 릴레이션 스키마(relation schema) 릴레이션의 이름과 릴레이션의 애트리뷰트들의 집합 릴레이션을 위한 틀(framework) 표기법 릴레이션이름(애트리뷰트1, 애트리뷰트2, ... 애트리뷰트N) 기본 키 애트리뷰트에는 밑줄 표시 내포(intension)라고 함

15 릴레이션 인스턴스(relation instance)
2.1 관계 데이터 모델의 개념 릴레이션 인스턴스(relation instance) 릴레이션에 어느 시점에 들어 있는 튜플들의 집합 시간의 흐름에 따라 계속 변함 일반적으로 릴레이션에는 현재의 인스턴스만 저장됨 외연(extension)이라고 함

16 2.1 관계 데이터 모델의 개념 EMPNO EMPNAME TITLE DNO SALARY 2106 김창섭 대리 2 2000000
3426 박영권 과장 3 3011 이수민 부장 1 1003 조민희 EMPLOYEE 내포 외연 [그림2. 3] 릴레이션의 내포와 외연

17 관계 데이터베이스(relational database) 스키마
2.1 관계 데이터 모델의 개념 관계 데이터베이스(relational database) 스키마 하나 이상의 릴레이션 스키마들로 이루어짐 DEPARTMENT(DEPTNO, DEPTNEMA, FLOOR) EMPLOYEE(EMPNO, EMPNAME, TITLE, DNO, SALARY) [그림2. 4] 관계 데이터베이스 스키마

18 2.1 관계 데이터 모델의 개념 관계 데이터베이스 인스턴스 릴레이션 인스턴스들의 모임으로 구성됨 DEPARTMENT
DEPTNO DEPTNAME FLOOR 1 영업 8 2 기획 10 3 개발 9 EMPLOYEE EMPNO EMPNAME TITLE DNO SALARY 2106 김창섭 대리 2 3426 박영권 과장 3 3011 이수민 부장 1 1003 조민희 [그림2. 5] 관계 데이터베이스 인스턴스

19 목차 I. 관계 데이터 모델의 개념 II. 릴레이션의 특성 III. 릴레이션의 키 IV. 무결성 제약조건

20 2.2 릴레이션의 특성 릴레이션 릴레이션의 특성 튜플들의 집합 각 릴레이션은 오직 하나의 레코드 타입만 포함
한 애트리뷰트 내의 값들은 모두 같은 유형 애트리뷰트들의 순서는 중요하지 않음 DEPARTMENT DEPTNO DEPTNAME FLOOR 1 영업 8 2 기획 10 3 개발 9 FLOOR DEPTNO DEPTNAME 8 1 영업 10 2 기획 9 3 개발 [그림2. 6] 애트리뷰트의 순서가 달라도 동일한 릴레이션

21 2.2 릴레이션의 특성 릴레이션의 특성(계속) 동일한 튜플이 두 개 이상 존재하지 않음
키가 존재함 한 튜플의 각 애트리뷰트는 원자값을 가짐 DEPARTMENT DEPTNO DEPTNAME FLOOR 1 영업 {8, 9} 2 기획 10 3 개발 {7, 9} [그림2. 7] 튜플의 각 애트리뷰트는 원자값만 가져야 함

22 2.2 릴레이션의 특성 릴레이션의 특성(계속) 각 애트리뷰트의 이름은 한 릴레이션 내에서만 고유 튜플들의 순서는 중요하지 않음
DEPARTMENT DEPTNO DEPTNAME FLOOR 1 영업 8 2 기획 10 3 개발 9 = DEPARTMENT DEPTNO DEPTNAME FLOOR 3 영업 9 2 기획 10 1 개발 8 [그림2. 8] 튜플들의 순서가 달라도 동일한 릴레이션

23 목차 I. 관계 데이터 모델의 개념 II. 릴레이션의 특성 III. 릴레이션의 키 IV. 무결성 제약조건

24 2.3 릴레이션의 키 릴레이션의 키 수퍼 키 각 튜플을 고유하게 식별할 수 있는 하나 이상의 애트리뷰트들의 모임
수퍼 키(superkey), 후보 키(candidate key), 기본 키(primary key), 대체 키(alternate key), 외래 키(foreign key) 수퍼 키 한 릴레이션 내의 특정 튜플을 고유하게 식별하는 하나의 애트리뷰트 또는 애트리뷰트들의 집합 예: 신용카드 회사의 고객 릴레이션에서 (신용카드번호, 주소) 또는 (주민등록번호, 이름) 또는 (주민등록번호) 튜플들을 고유하게 식별하는데 꼭 필요하지 않은 애트리뷰트들을 포함할 수 있음

25 2.3 릴레이션의 키 후보 키 각 튜플을 고유하게 식별하는 최소한의 애트리뷰트들의 모임
예: (신용카드번호, 주소)는 신용카드 회사의 고객 릴레이션의 후보 키가 아니지만 (신용카드번호)는 후보 키 모든 릴레이션에는 최소한 한 개 이상의 후보 키가 있음 후보 키도 두 개 이상의 애트리뷰트로 이루어질 수 있으며 이런 경우에 복합 키(composite key)라고 부름 예: (학번, 과목번호)가 후보 키 수강 학번 과목번호 학점 11002 CS310 A0 CS313 B+ 24036 CS345 B0 A+ [그림2. 9] 수강 릴레이션

26 2.3 릴레이션의 키 릴레이션의 인스턴스와 키 그림 2.10의 학생 릴레이션에서 이름이 후보 키가 될 수 있는가?
그림 2.10의 학생 릴레이션에서 이메일이 후보 키가 될 수 있는가? 수강 학번 과목번호 학점 11002 이홍근 24036 김순미 13427 박상웅 [그림2. 10] 학생 릴레이션

27 2.3 릴레이션의 키 기본 키 한 릴레이션에 후보 키가 두 개 이상 있으면 설계자 또는 데이터베이스 관리자가 이들 중에서 하나를 기본 키로 선정함 예: 신용카드 회사의 고객 릴레이션에서 신용카드번호와 주민등록번호가 후보 키가 될 수 있음. 이 중에서 신용카드 번호를 기본 키로 선정 자연스러운 기본 키를 찾을 수 없는 경우에는 레코드 번호와 같이 종종 인위적인 키 애트리뷰트를 릴레이션에 추가할 수 있음

28 2.3 릴레이션의 키 기본 키 선정 시 고려사항 애트리뷰트가 항상 고유한 값을 가질 것인가
애트리뷰트가 확실하게 널값을 갖지 않을 것인가 애트리뷰트의 값이 변경될 가능성이 높은 애트리뷰트는 기본 키로 선정하지 말 것 가능하면 작은 정수 값이나 짧은 문자열을 갖는 애트리뷰트 가능하면 복합 기본 키를 피할것

29 2.3 릴레이션의 키 대체 키 외래 키 기본 키가 아닌 후보 키
예: 신용카드 회사의 고객 릴레이션에서 신용카드번호를 기본 키로 선정하면 주민등록번호는 대체 키 외래 키 어떤 릴레이션의 기본 키를 참조하는 애트리뷰트 관계 데이터베이스에서 릴레이션들 간의 관계를 나타내기 위해서 사용됨 외래 키 애트리뷰트는 참조되는 릴레이션의 기본 키와 동일한 도메인을 가져야 함 자신이 속한 릴레이션의 기본 키의 구성요소가 되거나 되지 않을 수 있음

30 2.3 릴레이션의 키 슈퍼키 대체키 후보키 기본키 [그림2. 11] 키들의 포함 관계

31 2.3 릴레이션의 키 외래 키의 유형 다른 릴레이션의 기본 키를 참조하는 외래 키 참조 EMPLOYEE DEPARTMENT
EMPNO EMPNAME DNO 2106 김창섭 2 3426 박영권 3 3011 이수민 1 1003 조민희 3427 최종철 DEPTNO DEPTNAME FLOOR 1 영업 8 2 기획 10 3 개발 9 기본키 기본키 외래키 [그림2. 13] 다른 릴레이션을 참조하는 외래 키

32 2.3 릴레이션의 키 외래 키의 유형(계속) 자체 릴레이션의 기본 키를 참조하는 외래 키 참조 EMPNO EMPNAME
MANAGER DNO 2106 김창섭 3426 2 박영권 3011 3 이수민 ^ 1 1003 조민희 3427 최종철 [그림2. 13] 자체 릴레이션을 참조하는 외래 키

33 2.3 릴레이션의 키 외래 키의 유형(계속) 기본 키의 구성요소가 되는 외래 키 각각 외래키(합쳐서기본키) 기본키 기본키 학생
수강 과목 학번 이름 … 11002 이홍근 24036 김순미 학번 과목번호 학점 11002 CS310 A0 CS313 B+ 24036 CS345 B0 A+ 과목번호 과목이름 CS310 데이터베이스 CS313 운영체제 CS345 자료구조 참조 참조 [그림2. 14] 기본 키의 구성요소가 되는 외래 키

34 목차 I. 관계 데이터 모델의 개념 II. 릴레이션의 특성 III. 릴레이션의 키 IV. 무결성 제약조건

35 데이터 무결성(data integrity)
2.4 무결성 제약조건 데이터 무결성(data integrity) 데이터의 정확성 또는 유효성을 의미 일관된 데이터베이스 상태를 정의하는 규칙들을 묵시적으로 또는 명시적으로 정의함 무결성 제약조건은 데이터베이스 상태가 만족시켜야 하는 조건이다. 사용자에 의한 데이터베이스 갱신이 데이터베이스의 일관성을 깨지 않도록 보장하는 수단이다. 일반적으로 데이터베이스 상태가 실세계에 허용되는 상태만 나타낼 수 있도록 제한한다. 데이터베이스가 갱신될 때 DBMS가 자동적으로 일관성 조건을 검사하므로 응용 프로그램들은 일관성 조건을 검사할 필요가 없음

36 도메인 제약조건(domain constraint)
2.4 무결성 제약조건 도메인 제약조건(domain constraint) 각 애트리뷰트 값이 반드시 원자값이어야 함 애트리뷰트 값의 디폴트 값, 가능한 값들의 범위 등을 지정할 수 있음 데이터 형식을 통해 값들의 유형을 제한하고, CHECK 제약 조건을 통해 값들의 범위를 제한할 수 있음 SQL2는 도메인을 명시적으로 정의하는 것을 허용 키 제약조건(key constraint) 키 애트리뷰트에 중복된 값이 존재해서는 안됨

37 기본 키와 엔티티 무결성 제약조건(entity integrity constraint)
2.4 무결성 제약조건 기본 키와 엔티티 무결성 제약조건(entity integrity constraint) 릴레이션의 기본 키를 구성하는 어떤 애트리뷰트도 널값을 가질 수 없음 대체 키에는 적용되지 않음 사용자가 릴레이션을 생성하는 데이터 정의문에서 어떤 애트리뷰트가 릴레이션의 기본 키의 구성요소인가를 DBMS에게 알려줌

38 외래 키와 참조 무결성 제약조건(referential integrity constraint)
2.4 무결성 제약조건 외래 키와 참조 무결성 제약조건(referential integrity constraint) 참조 무결성 제약조건은 두 릴레이션의 연관된 튜플들 사이의 일관성을 유지하는데 사용됨 관계 데이터베이스가 포인터 없이 오직 릴레이션들로만 이루어지고, 릴레이션 사이의 관계들이 다른 릴레이션의 기본 키를 참조하는 것을 기반으로 하여 묵시적으로 표현되기 때문에 외래 키의 개념이 중요 릴레이션 R2의 외래 키가 릴레이션 R1의 기본 키를 참조할 때 참조 무결성 제약조건은 아래의 두 조건 중 하나가 성립되면 만족됨 외래 키의 값은 R1의 어떤 튜플의 기본 키 값과 같다 외래 키가 자신을 포함하고 있는 릴레이션의 기본 키를 구성하고 있지 않으면 널값을 가진다 R1 R2 외래키 기본키

39 2.4 무결성 제약조건 무결성 제약조건의 유지 데이터베이스에 대한 갱신 연산의 수행 결과에 따라서는 무결성 제약조건이 위배될 수 있음 데이터베이스에 대한 갱신 연산은 삽입 연산, 삭제 연산, 수정 연산으로 구분함 DBMS는 각각의 갱신 연산에 대하여 데이터베이스가 무결성 제약조건들을 만족하도록 필요한 조치를 취함 DBMS는 외래 키가 갱신되거나, 참조된 기본 키가 갱신되었을 때 참조 무결성 제약조건이 위배되지 않도록 해야 함 EMPLOYEE 릴레이션의 DNO 애트리뷰트가 DEPARTMENT 릴레이션의 기본 키인 DEPTNO를 참조하는 외래 키이므로, DEPARTMENT를 참조된 릴레이션, EMPLOYEE를 참조하는 릴레이션으로 부르기로 함

40 2.4 무결성 제약조건 EMPLOYEE DEPARTMENT EMPNO EMPNAME DNO 2106 김창섭 2 3426 박영권
3011 이수민 1 1003 조민희 3427 최종철 DEPTNO DEPTNAME FLOOR 1 영업 8 2 기획 10 3 개발 9 4 홍보 [그림2. 17] 관계 데이터베이스 인스턴스

41 2.4 무결성 제약조건 삽입 참조되는 릴레이션에 새로운 튜플이 삽입되면 참조 무결성 제약조건은 위배되지 않음
DEPARTMENT에 새로 삽입되는 튜플의 기본 키 애트리뷰트의 값에 따라서는 도메인 제약조건, 키 제약조건, 엔티티 무결성 제약조건 등을 위배할 수 있음 참조하는 릴레이션에 새로운 튜플을 삽입할 때는 도메인 제약조건, 키 제약조건, 엔티티 무결성 제약조건 외에 참조 무결성 제약조건도 위배할 수 있음 예: EMPLOYEE 릴레이션에 (4325, 오혜원, 6)라는 튜플을 삽입하면 참조 무결성 제약조건을 위배하게 됨

42 2.4 무결성 제약조건 삭제 참조하는 릴레이션에서 튜플이 삭제되면 도메인 제약조건, 키 제약조건, 엔티티 무결성 제약조건, 참조 무결성 제약조건 등 모든 제약조건을 위배하지 않음 참조되는 릴레이션에서 튜플이 삭제되면 참조 무결성 제약조건을 위배하는 경우가 생기거나 생기지 않을 수 있음 예1: DEPARTMENT 릴레이션에서 네 번째 튜플인 (4, 홍보, 8)을 삭제하더라도 참조 무결성 제약조건을 위배하지 않음 예2: DEPARTMENT 릴레이션에서 세 번째 튜플인 (3, 개발, 9)를 삭제하면 참조 무결성 제약조건을 위배하게 됨

43 참조 무결성 제약조건을 만족시키기 위해서 DBMS가 제공하는 옵션
2.4 무결성 제약조건 참조 무결성 제약조건을 만족시키기 위해서 DBMS가 제공하는 옵션 제한(restricted) 위배를 야기한 연산을 단순히 거절 예: DEPARTMENT 릴레이션에서 (3, 개발, 9)를 삭제하면 참조 무결성 제약조건을 위배하게 되므로 삭제 연산을 거절 연쇄(cascade) 참조되는 릴레이션에서 튜플을 삭제하고, 참조하는 릴레이션에서 이 튜플을 참조하는 튜플들도 함께 삭제 예: DEPARTMENT 릴레이션에서 (3, 개발, 9)를 삭제하면 EMPLOYEE 릴레이션에서 부서번호 3을 참조하는 두 번째 튜플과 다섯 번째 튜플도 함께 삭제

44 2.4 무결성 제약조건 EMPLOYEE DEPARTMENT EMPNO EMPNAME DNO 2106 김창섭 2 3426 박영권
3011 이수민 1 1003 조민희 3427 최종철 DEPTNO DEPTNAME FLOOR 1 영업 8 2 기획 10 3 개발 9 4 홍보 연쇄 ②삭제 ①삭제 [그림2. 18] 연쇄 삭제

45 참조 무결성 제약조건을 만족시키기 위해서 DBMS가 제공하는 옵션(계속)
2.4 무결성 제약조건 참조 무결성 제약조건을 만족시키기 위해서 DBMS가 제공하는 옵션(계속) 널값(nullify) 참조되는 릴레이션에서 튜플을 삭제하고, 참조하는 릴레이션에서 이 튜플을 참조하는 튜플들의 외래 키에 널값을 삽입 예: DEPARTMENT 릴레이션에서 (3, 개발, 9)를 삭제하면 EMPLOYEE 릴레이션에서 부서번호 3을 참조하는 두 번째 튜플과 다섯 번째 튜플의 부서번호에 널값을 삽입 디폴트값 널값을 넣는 대신에 디폴트값을 넣는다는 것을 제외하고는 바로 위의 옵션과 비슷함

46 2.4 무결성 제약조건 수정 DBMS는 수정하는 애트리뷰트가 기본 키인지 외래 키인지 검사함
수정하려는 애트리뷰트가 기본 키도 아니고 외래 키도 아니면 수정 연산이 참조 무결성 제약조건을 위배하지 않음 DBMS는 수정하려는 애트리뷰트의 새로운 값이 올바른 데이터 타입과 도메인을 만족하는지 확인하기만 하면 됨 기본 키나 외래 키를 수정하는 것은 하나의 튜플을 삭제하고 새로운 튜플을 그 자리에 삽입하는 것과 유사하므로, 삽입 및 삭제에서 설명한 제한, 연쇄, 널값, 디폴트값 규칙이 수정 연산에도 적용됨