preview
DB가 왜 필요?, DBMS가 왜 필요?
공유하려고, 뭘? 통합된 데이터를!
이때 데이터는 중복성이 제거된 최적화된 데이터
예를 들어 한글 파일을 편집모드로 두고 => 공유 x(데이터 무결성 때문에)
클라우드 => 별도의 management system
관계형 데이터 모델
고객 ID => 중복체크
주민번호 => 식별자가 가능하나 개인정보라 지양
관계를 맺기 위한 조건 필요
바뀌지 않아야 하는 조건이 있음(DBMS에서는 제약조건을 두어서 데이터의 일관성, 정확성을 지킴)
릴레이션
행과 열로 구성된 테이블
관계
릴레이션 내에서 생성되는 관계: 릴레이션 내 데이터들의 관계
릴레이션 간에 생성되는 관계: 릴레이션 간의 관계
스키마
스키마: 구성요소
속성: 도서번호, 도서이름, 출판사, 가격
인스턴스: 실질적인 데이터 값
스키마의요소
속성(naming): 릴레이션 스키마의 열
도메인(type 및 범위): 속성이 가질 수 있는 값의 집합
차수(degree): 속성의 개수
스카마의 표현
릴레이션 이름(속성 1: 도메인1, 속성 2: 도메인2, 속성 3: 도메인3...)
ex. 도서(도서번호, 도서이름, 출판사, 가격)
인스턴스
인스턴스 요소
튜플: 릴레이션 행(중복 x)
카디날리티: 튜플의 수
릴레이션 특징
- 속성은 단일 값을 가진다.
- 속성은 서로 다른 이름을 가진다.
- 한 속성의 값은 모두 같은 도메인 값을 가진다.
- 속성의 순서는 상관없다.
- 릴레이션 내 중복된 튜플은 허용하지 않는다.
- 튜플의 순서는 상관없다.
- 관계데이터 모델은 데이터를 2차원 테이블 형태인 릴레이션으로 표현
- 릴레이션에 대한 제약 조건과 관계 연산을 위한 관계대수(여러개 테이블에서 어떤 조건을 어떻게 가져오는데 사용되는 수학적기호)를 정의
무결성 제약조건
key
특정 튜플을 식별할 때 사용되는 속성 혹은 속성의 집합
키가 되는 속성을 통해 튜플들을 서로 구별함
ex. ISBN, 고객ID
슈퍼키
튜플을 유일하게 식별할 수 있는 하나의 속성 혹은 속성의 집합
ex. 고객 릴레이션은 고객번호와 주민번호를 포함한 모든 속성의 집합이 슈퍼키가 됨.
(주민번호), (주민번호, 이름), (주민번호, 이름, 주소)...
후보키
primary key가 될 수 있는 후보 키
튜플을 유일하게 식별할 수 있는 속성의 최소 집합
기본키(primary key)
여러 후보키 중 하나를 선정해 대표로 삼는 키
제약조건
- 릴레이션 내 튜플을 식별할 수 있는 고유한 값을 가져야함.
- NULL 값은 허용하지 않음
- 키 값의 변동이 일어나지 않아야 함
- 최대한 적은 수의 속성을 가진 것이어야 함
- 향후 키를 사용하는데 있어 문제 발생 소지 없어야 함
대리키
기본키가 없을 때는 일련번호 같은 가상의 속성을 만들어 기본키로 삼는 경우가 있음
이러한 키를 대리키, 인조키라고 함
대체키
기본키로 선정되지 않은 후보키
외래키(foreign key)
다른 릴레이션의 기본키를 참조하는 속성
외래키 사용 시 참조하는 릴레이션과 참조되는 릴레이션이 꼭 다른 릴레이션일 필요는 없음. 즉, 자기 자신의 기본키를 참조할 수 있음.
