관계형 데이터 모델과 관계대수(1)

데이터 모델

 

스키마가 아니라, 설계를 위한 도구(방법론): 데이터를 추상화하고 구조화한다.

-> 데이터모델의 결과로 나오는 것이 스키마

 

데이터 모델의 결과

 

다음과 같은 것들이 결정되어야 한다.

 

- 데이터, 데이터가 저장되는 구조

- 데이터 관계

- 데이터 의미

- 데이터 제약 조건(무결성, 일관성 유지를 위해)

 

그래서 산출물은

- 스키마

- 다이어그램

- 문서/명세

 

데이터 모델의 종류

=> 개념적 데이터 모델은 데베의 종류와 무관하고, 논리적 데이터 모델은 데베의 종류에 따라 다르게 

 

<개념적 데이터 모델>

- 개념적 설계 단계에 사용

- 데이터베이스 종류에 무관

- 개체와 개체들 간 관계 정의(ER diagram)

 

<논리적 데이터 모델>

- 특정 데이터베이스와 관련(어떤 데이터, 구조, 제약조건, 관계 등 정의)

 

스키마 & 인스턴스

 

스키마를 적으세요 = 어떤 속성들의 집합으로 저장되어 있는지만 서술하면 됨(=파란색만 쓰면 됨)

* 아래는 관계 데이터 모델을 기반으로 설계된 스키마이기 때문에 "릴레이션 스키마"라고 부른다.

 

 

<스키마>

: 데이터베이스에 저장되는 데이터 구조와 제약조건 등의 명세

: DDL로 구현(데이터 구조, 제약조건 명시) -> 데이터 사전에 저장 및 유지

: 한 번 정의되면 자주 변경되지 않음

 

1. "인식의 범위 관점"의 스키마

: "어느 정도의 범위와 깊이에서 데이터베이스를 인식할 것인가?"

개념/내부 스키마는 조직 전체 범위를, 외부 스키마는 일부 범위만을 인식한다.

내부스키마는 그에 더해 저장 매체 관점도 추가적으로 인식한다.

 

 

- 외부 단계: 외부 스키마(Subschema)

: 조직의 일부 범위

: 각자(최종 사용자/응용 프로그래머)에게 필요한 것만 추출해서 사용

ex. 학적과는 Sn,Name,Grade,Dept 사용/ 학생과는 Sno, Sname,Year,Addr만 골라서 사용

: 데이터베이스 설계 단계 후 애플리케이션 설계 단계에서 결정

: View Level에서의 데이터베이스 이해

 

- 개념 단계: 개념 스키마(Logical Schema)

: 조직 전체 범위

: DBA 관점, DBMS 관점

: 데이터베이스 설계 단계에서 결정(개념적 설계 -> 논리적 설계)

: Logical Level에서의 데이터베이스 이해

 

-내부 단계: 내부 스키마(Physical Schema)

: 조직 전체 범위

: 저장 매체 관점

: 데이터베이스 설계 단계에서 결정(물리적 설계)

: Physical Level에서의 데이터베이스 이해

 

2. "설계 관점"의 스키마

: "현실 세계의 데이터를 데이터베이스에 저장하기 위해 어느 정도로 추상화/구체화했는가?"

: "얼마나 구체적으로 데이터베이스를 설계했는가?"

외부, 개념, 내부 단계 모두 조직 전체 범위 !!

- 외부 단계

- 개념 단계: 개념적 설계 -> logical(논리적) 설계

개념 스키마(ER 다이어그램)와 논리적 스키마(릴레이션 스키마) 둘 다 산출

 

 

* "인식의 범위 관점"에서는 개념 스키마와 논리적 스키마를 동일시했지만, "설계 관점"에서는 둘을 따로 둠

=> 문맥에 따라 적절히 판단할 것 ! (하지만 시험 문제를 헷갈리게 내지는 않는다고 하심)

ex. 범위 강조(조직 전체 데이터베이스 구조 어쩌구) -> 둘을 동일시

설계 강조(논리적 스키마를 설계하기 위해서~) -> 둘을 구분

 

- 내부 단계: 물리적 설계

물리적 스키마

 

===> "인식의 범위 관점"과 "설계 관점"이 다른 것은 개념 단계 뿐이다! 외부/내부 단계는 같은 역할 !

 

 

<인스턴스>

: 정의된 스키마에 따라서 데이터베이스에 실제로 저장된 값

: 계속해서 변함

=> 밑에서 자세히

 

관계 대수를 위한 수학적 정의

 

릴레이션 스키마와 인스턴스

 

: 관계 대수의 대상

 

릴레이션 스키마에 들어 있는 관계 데이터 모델 구성요소에는 다음 네 가지가 있다.

 

1. 데이터 및 데이터가 저장되는 구조

Instructor=(ID, name, dept_name, salary)

 

2. 데이터 관계

: 외래키

 

3. 데이터 의미

: 각 속성의 의미와 타입

 

4. 데이터 제약 조건

: 지금은 있다고만 알아두기

 

<릴레이션 스키마: 설계 관점 vs 수학적 관점>

- 설계 관점: 릴레이션 구조(속성의 종류, 타입, 제약 조건 등에 대한 정의) 필요

- 수학적 관점: 릴레이션을 구성하는 속성들의 종류로만 정의

 

<인스턴스>

 

R: 스키마 -> r: 인스턴스

 

- "릴레이션" = "테이블" = r(R)

 

<투플(tuple) = 행(row) = 인스턴스>

- 투플의 유일성: 하나의 릴레이션에는 동일한 투플이 존재할 수 없음(속성 4개 중 하나는 달라야 함)

- 투플의 순서는 중요하지 않음

- 카디널리티: 투플 개수

 

<속성(attribute) = 열(column)>

- 도메인(domain): 각 애트리뷰트에 대하여 허용된 값의 집합

ex. 남자 혹은 여자 둘 중 하나

- 애트리뷰트: (중요)원자값(더 이상 나누어지지 않는 값)만을 가질 수 있음

ex. "과목명"은 원자값을 가지지만, "수강과목 리스트"는 원자값을 갖지 않음

- 애트리뷰트의 순서는 중요하지 않음

- 차수(degree): 속성 개수

- (중요)null

: 애트리뷰트가 가질 수 있는 특별한 값 -> 모든 도메인에서 정의 가능

: 값을 알 수 없는 상태

: 다양한 연산 정의함에 있어 복잡함 야기 -> null값이 포함된 연산의 결과가 어떻게 정의되는지 알아야 함.

 

키(keys)

 

슈퍼키, 후보키, 기본키, 대체키는 공통적으로 투플을 유일하게 구분

 

- 슈퍼키: 튜플 유일하게 구별할 수 있는 속성 집합(유일성)

- 후보키: 투플 유일하게 구별할 수 있는 최소한의 속성 집합(유일성+최소성)

- 기본키(중요): 후보키 중 시스템 특징에 맞는 대표적인 키(유일성+최소성+대표성)

ex. 학사 시스템에서 후보키에 학생의 학번&주민번호가 있으면, 학번을 후보키로 설정

* 복합기본키: 최소 개수지만 하나만 있어야 하는 건 아님 !

- 대체키: 기본키로 선택되지 못한 키(유일성+최소성)

- 외래키: 어떤 릴레이션의 속성 중 다른 릴레이션의 기본키로 사용되는 속성 집합 -> 릴레이션 간 참조 관계에 사용

ex. 예컨대 다음 학사 시스템 구조에서,,, "dept_name"은

* "department 릴레이션"의 기본키

* "instructor 릴레이션"의 속성 => "instructor 릴레이션"의 외래키

(instructor가 dept_name을 매개로 department를 참조하고 있기 때문)

학사시스템

<예제>-시험문제 냄

 

=> 이름과 전공은 동일할 수 있지만, 학번과 주민번호는 동일할 리 없기 때문에

적어도 학번, 주민번호 중 하나를 포함한 속성 집합이면 가능 -> 경우의 수 세기!

 

1. "슈퍼키"

학생(학번, 주민번호, 이름, 전공)에 대하여 

4개: {학번, 주민번호, 이름, 전공}

3개: {학번, 주민번호, 이름}, {학번, 주민번호, 전공}, {학번, 이름, 전공}, {주민번호, 이름, 전공}

2개: {학번, 주민번호}, {학번, 이름}, {학번, 전공}, {주민번호, 이름}, {주민번호, 전공}

1개: {학번}, {주민번호}

 

2. "후보키"

 {학번}, {주민번호}

 

3. "기본키"

{학번}

 

4. "대체키"

{주민번호}

 

데이터베이스 스키마&인스턴스

 

- 데이터베이스 스키마

: 데이터베이스의 논리적 구조

: 데이터베이스를 구성하는 모든 릴레이션의 릴레이션 스키마 집합

 

- 데이터베이스 인스턴스

: 특정 시점에 데이터베이스에 저장된 데이터에 대한 스냅샷

: 특정 시점에 데이터베이스에 저장된 모든 릴레이션들의 인스턴스 집합

 

Schema Diagram

 

내 필기 잘 보기