The Relational Data Model and Relational Database Consarin
Relarional Data model
review
개념적 스키마를 배웠다. (외부 개념 내부 3가지 )
그중 ERD는 사람이 보깅 편한 형태 였지 DBMS, 즉 컴퓨터가 이해 할 수 있는 것이 아니였다.
본장에서는 논리 스키마(relational data model)를 배움
chapter 5
relational model definition
- relation은 table처럼 보이면 set of rows 이며
- rows는 tuples로 불린다.
- 각 column은 attribute name이로 불린다.
- 예는 아래와 같다
전체 테이블을 하나의 relation이며 student는 relation name이며
relation은 row(tuple)(set)의 집합니다.
tuple은 attribute들의 set이다.
tuple이 entity이며 entity type은 attribute,
entity set은 set of tuple
- key of relation : 각 tuple의 고유한 값
- 예 : ssn, 적당한게 없을 때는 artificial/surrogate key를 임의로 부여하기도 함
formal definitions - schema
- R(A1,A2, A3...)로 표현 relation은 attribute들의 집합이다
- R은 relation, A는 attribute
- ex) Customer(cust-id, cust-name, Address, Phone)
- 각 attribute는 value에 대한 domain(범위)을 가짐
- domain은 miniworld에서 가질 수 있는 값의 범위를 doamin이라 함
formal definitions - state
- state는 erd에서도 특정한 순간의 상태
- relation state는 attribute의 domain간의 cartesian product(가능할 수 있는 모든 집합)의 부분집합
- 막약 6개의 가능 한 조합에서 3개가 나왔다면 그 3개가 relation state
summary box
characteristics relations
- 일반적으로 tuple의 순서는 중요하지 않으며 저장되는 순서로 정리 됨
- 그러나 tuple안의 value인 attribute의 경우는 순서가 중요함
- key-value pair 형태의 self-describing의 경우는 순서가 상관긴 하다
- tuple안에 있는 모든 value는 atomic하다
- null : 실제 의미가 정확히 무엇인지 알 수 없음, 없는 건지 아님 기입을 안했는지 모름
- N/A : no answer, not available,- None : 없는 값
constraints 제약
database는 relation에 대한 집합이자 constraints에 대한 집합
1. inherent or implicit constraints : 정해진 스키마에 대한 데이터 타입에 대한 제약
2. schema-based or explicit constraints : 데이터 정의어에 의해 구축이 된 5가지 제약 조건이 존재
3. application based or semantic constraints : dbms의 규칙이 아닌 응용프로그램의 추가적인 규칙
explit schema-based 3개
- key constraints : tuple을 구분할 수 있는 구분자인데 이것이 중복되면 안된다.
- entity integrity constraints
- referential integrity constraints
schema-based constrint
- domain constraints : 데이터 타입이 다르면 안된다
- null constraints : null을 허용하는 attribute에 따라 null의 유무를 체크한다.not null인 attribute value가 null이면 안됨
key constraints
superkey는 모든 key의 집합을 의미
key는 superkey의 minimum최솟값? 최솟값이 데이터 사이즈를 의미?
구별할 수 있는 최소 단위라는 의미인데, 상황, 목적에 따라 다르게 정의되는 듯. 최종 결정은 dba가 결정
primary key는 key들 중 하나
나머지는 candidate keys가 된다. underline을 침
relational database schema
relation들의 집합과 set IC of integrity(무결성 제약 조건의 세트)로 표현 가능
Entity Integrity
primary key는 null을 가질 수 없다
referential intergrity
foreign key는 참고하는 attritude이며 이는 null이 될 수 없다.
제약조건에 위반될 때
operation을 restrict, reject함
update는 cascade option, null option, default option 또한 있음
Possible violation(위반) for each operation
-
insert가 db에 들어갈때 각 attribute가 옳은 데이터 타입인지? -> domain constraints
-
해당 attribute에 null이 존재하면 안되는데 존재하고는 있지 않은지 -> null constraints
-
primary key가 null이 아닌지 -> entity integrity
-
key가 tuple간에 중복이 있지 않은지 -> key constraints
-
operation에서 참조하는 값이 실제 데이터베이스 에 있는지 -> referential integrity
-
delete의 경우는 referential integrity만 확인하면 됨
-
참조 되는 것이 있다면 del할 수가 없음
chapter 9
ERD를 relational로 mapping
ER to relational mapping Algorithms
- mapping of regular entity types
- mapping of weak entity types
- mapping of binary 1:1 relationship types
- mapping of binary 1:N relationship types
- mapping of binary N:M relationship types
- mapping of multivalued attribute
- mapping of N-ary relationship types
week entity는 추가가 안된 상태
binary relation mapping
- 1:1 relation -three possible approach
- foreign key(2 relations) approach : 전체 참여하는 쪽에 foreign key를 넣어 참조
- merged relation(1 relations) option : 한 relation으로 합치기
- cross-reference or relationship relation(3 relations) option : relation의 관계를 알기 위한 relation -> 검색의 효율성 떨어짐. 그래서 주로 외래키 사용
1번 방법으로 mgr-ssn, mgr_start_date라는 foreign key 추가
- 1:N
- 1:N에서 N에 foreign key를 추가함
-
M:N
relationship relation을 만드는게 나음 -> foreign key를 사용하면 중복이 너무 많음 -
multivalued의 경우 table로 만들어 참조
-
N-ary relationship 다관계 relationship의 경우
관계 realtion을 만들어 핵심 key를 foreign키로 가져온다.
Summary
er(개념적 스키마)과 relational model(논리적 스키마)들 끼리 용어적인 차이가 있었다
