728x90
반응형
경희대학교 이영구 교수님의 데이터베이스 강의를 기반으로 정리한 글입니다.
데이터베이스 설계
- 개념적 데이터베이스 설계와 물리적 데이터베이스 설계로 구분
- 개념적 데이터베이스 설계: 실제로 데이터베이스를 어떻게 구현할 것인가와는 독립적으로 정보 사용의 모델을 개발하는 과정
- 물리적 데이터베이스 설계: 물리적인 저장 장치와 접근 방식을 다룸
개념적 데이터베이스 설계
- 조직체(실세계)의 엔티티, 관계, 프로세스, 무결성 제약조건 등을 나타내는 추상화 모델을 구축
- 엔티티는 서로 구분이 되면서 조직체에서 데이터베이스에 나타내려는 객체(사람, 장소, 사물 등)를 의미
- 관계는 두 개 이상의 엔티티들 간의 연관을 나타냄
- 프로세스는 관련된 활동을 나타냄
- 무결성 제약조건은 데이터의 정확성과 비즈니스 규칙을 의미
개념적 수준의 모델
- 특정 데이터 모델과 독립적으로 응용 세계를 모델링할 수 있도록 함
- 데이터베이스 구조나 스키마를 하향식으로 개발할 수 있기 위한 틀(framework)를 제공
- 인기 있는 개념적 수준의 모델: 엔티티-관계(ER: Entity-Relationship) 모델
- ER 모델과 같은 개념적인 데이터 모델이 사상될 수 있는 다수의 구현 데이터 모델(implementation data model)이 존재
- 구현 단계에서 사용되는 세 가지 데이터 모델: 관계 데이터 모델, 계층 데이터 모델, 네트워크 데이터 모델
5.1 데이터베이스 설계의 개요
데이터베이스 설계의 개요
- 한 조직체의 운영과 목적을 지원하기 위해 데이터베이스를 생성하는 과정
- 목적은 모든 주요 응용과 사용자들이 요구하는 데이터, 데이터 간의 관계를 표현하는 것
- 데이터베이스 개발은 일반적인 프로젝트 라이프 사이클 과정을 따름
- 훌륭한 데이터베이스 설계
- 시간의 흐름에 따른 데이터의 모든 측면을 나타냄
- 데이터 항목의 중복 최소화
- 데이터베이스에 대한 효율적인 접근 제공
- 데이터베이스의 무결성 제공
- 이해하기 쉬움
- 데이터베이스 개발의 라이프 사이클: 요구사항 분석 단계 → 설계 단계 → 구현 단계 → 데이터를 적재하거나 변환 → 기존의 응용 변환
데이터베이스 설계의 주요 단계
- 요구사항 분석, 개념적 설계, DBMS 선정, 논리적 설계, 스키마 정제, 물리적 설계와 튜닝 등 여러 작업으로 이루어짐
- 일반적으로 데이터베이스 설계의 완성도를 높이기 위해 이런 작업들을 앞뒤로 왔다갔다할 필요가 있음

요구사항 수집과 분석
- 기존의 문서 조사, 인터뷰, 설문조사 등 시행
- 요구사항에 관한 지식을 기반으로 관련 있는 엔티티들과 이들의 애트리뷰트들이 무엇인가, 엔티티들 간의 관계가 무엇인가 등을 파악
- 데이터 처리에 관한 요구사항에 대해 전형적인 연산들은 무엇인가, 연산들의 의미, 접근하는 데이터의 양 등을 분석
개념적 설계
- 모든 물리적인 사항과 독립적으로, 한 조직체에 사용되는 정보의 모델을 구축하는 과정
- 사용자들의 요구사항 명세로부터 개념적 스키마가 만들어짐
- 높은 추상화 수준의 데이터 모델을 기반으로 정형적인 언어로 데이터 구조를 명시함
- 대표적인 데이터 모델: ER 모델
- 엔티티 타입, 관계 타입, 애트리뷰트들을 식별하고, 애트리뷰트들의 도메인을 결정하고, 후보 키와 기본 키 애트리뷰트들을 결정
- 완성된 개념적 스키마(ER 스키마)는 ER 다이어그램으로 표현됨
DBMS 선정
- 여러 가지 요인들을 검토한 후 DBMS를 선정
- 기술적인 요인: DBMS가 제공하는 데이터 모델, 저장 구조, 인터페이스, 질의어, 도구, 제공되는 서비스 등
- 정치적인 요인: 고수준의 전략적인 결정 등
- 경제적인 요인: DBMS 구입 비용, 하드웨어 구입 비용, 유지 보수(서비스) 비용, 기존의 시스템을 새로운 DBMS에 맞게 변환하는데 소요되는 비용, 인건비, 교육비 등
논리적 설계
- 데이터베이스 관리를 위해 선택한 DBMS의 데이터 모델을 사용하여 논리적 스키마(외부 스키마도 포함)를 생성
- 개념적 스키마에 알고리즘을 적용하여 논리적 스키마 생성
- 논리적 스키마를 나타내기 위해 관계 데이터 모델을 사용하는 경우 → ER 모델로 표현된 개념적 스키마를 관계 데이터베이스 스키마로 사상
- 관계 데이터베이스 스키마를 더 좋은 관계 데이터베이스 스키마로 변환하기 위해 정규화 과정 적용
- 데이터베이스 설계자가 요구사항 수집과 분석 후에 바로 논리적 설계 단계로 가는 경우 → 좋은 관계 데이터베이스 스키마가 생성되지 않음
물리적 설계
- 처리 요구사항들을 만족시키기 위해 저장 구조와 접근 경로 등을 결정
- 성능상의 주요 기준
- 응답 시간: 질의와 갱신이 평균적으로 또는 피크 시간 때 얼마나 오래 걸릴 것인가?
- 트랜잭션 처리율: 1초당 얼마나 많은 트랜잭션들이 평균적으로 또는 피크 시간 때 처리될 수 있는가?
- 전체 데이터베이스에 대한 보고서 생성에 얼마나 오래 걸릴 것인가?
트랜잭션 설계
- 요구사항 수집과 분석 후에 데이터베이스 설계 과정과 별도로 트랜잭션 설계를 진행할 수 있음
- 트랜잭션: 완성될 데이터베이스에서 동작할 응용 프로그램
- 데이터베이스 스키마는 트랜잭션에서 요구하는 모든 정보를 포함해야 함
- 검색, 갱신, 혼합 등 세 가지 유형으로 구분하여 입력과 출력, 동작 등을 식별
5.2 ER 모델
ER 모델
- 데이터베이스 설계를 용이하게 하기 위해 P.P. Chen이 1976년에 제안
- 현재는 EER(Enhanced Entity Relationship) 모델이 데이터베이스 설계 과정에 널리 사용됨
- 개념적 설계를 위한 인기 있는 모델로, 많은 CASE 도구들에서 지원됨
- 실세계를 엔티티, 애트리뷰트, 엔티티들 간의 관계로 표현
- 쉽계 관계 데이터 모델로 사상됨
- 기본적인 구문: 엔티티, 관계, 애트리뷰트
- 기타 구문: 카디날리티 비율, 참여 제약조건
- 적은 노력으로 쉽게 배울 수 있고, 전문가가 아니어도 이해하기 쉬움
- 자연어보다 정형적, 구현에 독립적 → 데이터베이스 설계자들이 최종 사용자와 의사 소통 하는데 적합
- ER 모델을 기반으로 만들어진 다수의 CASE 도구(ex. ERWin 등)들이 존재 → 이런 도구들은 ER 설계를 자동적으로 오라클, SQL Server, 사이베이스 등의 데이터 정의어로 변환, 어떤 도구는 XML로 변환
- 현재는 데이터베이스 설계를 위한 다소 구형 그래픽 표기법
엔티티
- 하나의 엔티티는 사람, 장소, 사물, 사건 등과 같이 독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체
- 사원처럼 실체가 있는 것도 있지만 생각이나 개념과 같이 추장적인 것도 있음

엔티티 타입
- 엔티티들은 엔티티 타입(또는 엔티티 집합)들로 분류됨
- 엔티티 타입: 동일한 애트리뷰트들을 가진 엔티티들의 틀 → 관계 모델의 릴레이션의 내포
- 엔티티 집합: 동일한 애트리뷰트들을 가진 엔티티들의 모임 → 관계 모델의 릴레이션의 외연
- 하나의 엔티티는 한 개 이상의 엔티티 집합에 속할 수 있음
- 엔티티 집합과 엔티티 타입을 엄격하게 구분할 필요는 없음
- ER 다이어그램에서 엔티티 타입은 직사각형으로 나타냄
- ex. Person(이름, 나이, 성별): 엔티티 타입 / (영희, 철수, 나경, 영희) : 엔티티 집합

강한 엔티티 타입
- 독자적으로 존재
- 엔티티 타입 내에서 자신의 키 애트리뷰트를 사용하여 고유하게 엔티티들을 식별할 수 있는 엔티티 타입
약한 엔티티 타입
- 키를 형성하기에 충분한 애트리뷰트를 갖지 못한 엔티티 타입
- 존재하려면 소유 엔티티 타입이 있어야 함
- 소유 엔티티 타입의 키 애트리뷰트를 결합해야만 고유하게 약한 엔티티 타입의 엔티티들을 식별할 수 있음
애트리뷰트
- 엔티티: 연관된 애트리뷰트들의 집합으로 설명됨
- ex. 사원 엔티티 → 사원번호, 이름, 직책, 급여 등
- 도메인: 한 애트리뷰트가 가질 수 있는 모든 가능한 값들의 집합
- ex. 사원번호 → 1000 ~ 9999 값을 가짐
- 여러 애트리뷰트가 동일한 도메인을 공유할 수 있음
- ex. 사원번호와 부서번호가 네 자리 정수를 가질 수 잇음
- 키 애트리뷰트: 한 애트리뷰트 또는 애트리뷰트들의 모임으로서 한 엔티티 타입 내에서 각 엔티티를 고유하게 식별
- ER 다이어그램에서 기본 키에 속하는 애트리뷰트는 밑줄을 그어 표시
- 요구사항 명세에서 명사나 형용사로 표현됨
- 엔티티는 독립적인 의미를 가짐 → 애트리뷰트는 독립적인 의미를 갖지 않음
- ER 다이어그램에서 타원형으로 나타냄
- 애트리뷰트와 엔티티 타입은 실선으로 연결
단순 애트리뷰트(simple attribute)
- 더 이상 다른 애트리뷰트로 나눌 수 없는 애트리뷰트
- ER 다이어그램에서 실선 타원으로 표현
- ER 다이어그램에서 대부분의 애트리뷰트는 단순 애트리뷰트

복합 애트리뷰트(composite attribute)
- 두 개 이상의 애트리뷰트로 이루어진 애트리뷰트
- 동일한 엔티티 타입이나 관계 타입에 속하는 애트리뷰트들 중에서 밀접하게 연관된 것을 모아놓은 것

단일 값 애트리뷰트(single-valued attribute)
- 각 엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트
- ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현됨
- ex. 사원의 사원번호 애트리뷰트는 어떤 사원도 두 개 이상의 사원번호를 갖지 않으므로 단일 값 애트리뷰트
- ER 다이어그램에서 대부분의 애트리뷰트는 단일 값 애트리뷰트
다치 애트리뷰트(multi-valued attribute)
- 각 엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트
- ER 다이어그램에서 이중선 타원으로 표현

저장된 애트리뷰트(stored attribute)
- 다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트
- ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현
- ER 다이어그램에서 대부분의 애트리뷰트는 저장된 애트리뷰트
- ex. 사원 엔티티 타입에서 사원이름, 급여는 다른 애트리뷰트와 독립적으로 존재
유도된 애트리뷰트(derived attribute)
- 다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트
- 관계 데이터베이스에서 릴레이션의 애트리뷰트로 포함시키지 않는 것이 좋음
- ER 다이어그램에서 점선 타원으로 표현

약한 엔티티 타입
- 키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티 타입
- 약한 엔티티 타입에게 키 애트리뷰트를 제공하는 엔티티 타입을 소유 엔티티 타입(owner entity type) 또는 식별 엔티티 타입(identifying entity type)라고 부름
- ER 다이어그램에서 이중선 직사각형으로 표기
- 약한 엔티티 타입의 부분 키는 점선 밑줄을 그어 표시
- 부분 키(partial key): 부양가족의 이름처럼 한 사원에 속한 부양가족 내에서는 서로 다르지만 회사 전체 사원들의 부양가족들 전체에서는 같은 경우가 생길 수 있는 애트리뷰트

관계와 관계 타입
- 관계: 엔티티들 사이에 존재하는 연관이나 연결로서 두 개 이상의 엔티티 타입들 사이의 사상
- 관계 집합: 동질의 관계들의 집합
- 관계 타입: 동질의 관계들의 틀
- 요구사항 명세에서 흔히 동사는 ER 다이어그램에서 관계로 표현
- ER 다이어그램에서 다이아몬드로 표기
- 관계 타입이 서로 연관시키는 엔티티 타입들을 관계 타입에 실선으로 연결


관계의 애트리뷰트
- 관계 타입은 관계의 특징을 기술하는 애트리뷰트들을 가질 수 있음
- 관계 타입은 키 애트리뷰트를 갖지 않음

차수(degree)
- 관계로 연결된 엔티티 타입들의 개수를 의미
- 실세계에서 가장 흔한 관계 → 두 개의 엔티티 타입을 연결하는 2진 관계

카디날리티 비율
- 한 엔티티가 참여할 수 있는 관계의 수
- 관계 타입에 참여하는 엔티티들의 가능한 조합을 제한
- 흔히 1:1, 1:N, M:N으로 구분
- 카디날리티 비율에 관한 정보는 간선 위에 나타냄

1:1 관계
- E1의 각 엔티티가 정확하게 E2의 한 엔티티와 연관되고, E2의 각 엔티티가 정확하게 E1의 한 엔티티와 연관된 관계
- ex. 각 사원에 대해 최대 한 개의 PC가 있고, 각 PC에 대해 최대 한 명의 사원
1:N 관계
- E1의 각 엔티티가 E2의 임의의 개수의 엔티티와 연관되고, E2의 각 엔티티는 정확하게 E1의 한 엔티티와 연관된 관계
- ex. 각 사원에 대해 최대 한 대의 PC가 있고, 각 PC에 대해 여러 명의 사원들
M:N 관계
- 한 엔티티 타입에 속하는 임의의 개수의 엔티티가 다른 엔티티 타입에 속하는 임의의 개수의 엔티티와 연관된 관계
- ex. 각 사원에 대해 여러 대의 PC가 있고, 각 PC에 대해 여러 명의 사원들
카디날리티 비율의 최소값과 최대값
- ER 다이어그램에서 관계 타입과 엔티티 타입을 연결하는 실선 위에 (min, max) 형태로 표기
- min: 이 엔티티 타입 내의 각 엔티티는 적어도 min번 관계에 참여함
- max: 이 엔티티 타입 내의 각 엔티티는 최대한 max번 관계에 참여함
- min=0: 어떤 엔티티가 반드시 관계에 참여해야 할 필요는 없음
- max=*: 어떤 엔티티가 관계에 임의의 수만큼 참여할 수 있음을 의미


→ 하나의 car에 대해 가능한 customer, salesperson 조합은 하나씩만 연결 가능: 차는 한 번만 팔림
→ 하나의 salesperson에 대해 customer, car 조합은 여러 개 연결 가능: 누구에게 어떤 차를 팔았는지
→ 하나의 customer에 대해 car, salesperson 조합은 여러 개 연결 가능: 누구에거 어떤 차를 샀는지
역할(role)
- 관계 타입의 의미를 명확하게 하기 위해 사용
- 특히 하나의 관계 타입에 하나의 엔티티 타입이 여러 번 나타나는 경우 → 반드시 역할 표기
- 관계 타입의 간선 위에 표시

전체 참여와 부분 참여
- 전체 참여: 어떤 관계에 엔티티 타입 E1의 모든 엔티티들이 관계 타입 R에 의해서 어떤 엔티티 타입 E2의 어떤 엔티티와 연관되는 것을 의미
- 부분 참여: 어떤 관계에 엔티티 타입 E1의 일부 엔티티만 참여하는 것을 의미
- 약한 엔티티 타입은 항상 관계에 전체 참여
- 전체 참여는 ER 다이어그램에서 이중 실선으로 표시
- 카디날리티 비율과 함께 참여 제약조건은 관계에 대한 중요한 제약조건

다중 관계
- 두 엔티티 타입 사이 두 개 이상의 관계 타입이 존재할 수 있음

순환적 관계
- 하나의 엔티티 타입이 동일한 관계 타입에 두 번 이상 참여하는 것

ER 스키마를 작성하기 위한 지침
- 엔티티: 키 애트리뷰트 이외에 설명 정보를 추가로 가짐
- 다치 애트리뷰트는 엔티티로 분류
- 가능한 한 복합 식별자를 피함
- 어떤 개념을 엔티티 타입과 관계 타입 중 어느 것으로 모델링할 것인지를 절대적으로 구분하는 것은 어려움
애트리뷰트 vs. 엔티티
- 엔티티 타입과 애트리뷰트를 구분하는 절대적인 기준 없음
- ex. 공급자에 대한 정보 → 공급자 번호, 공급자 이름, 신용, 공급자 도시
- 공급자가 엔티티인 것은 명확
- 공급자 도시: 어느 도시에 위치하느냐만 궁금하면 애트리뷰트, 공급자 도시에 관한 정보(시설, 도로망 등)를 유지할 필요가 있다면 엔티티
- 고려 사항
- 도시가 조직체에 관심이 있는 객체인가?
- 도시에 관한 애트리뷰트들을 유지할 필요가 있는가?
- 도시를 여러 엔티티 타입들이 공유하는가?

데이터베이스 설계 과정
- 응용의 요구사항을 수집하여 기술
- 응용과 연관이 있는 엔티티 타입들을 식별
- 응용과 연관이 있는 관계 타입들을 식별
- 관계가 1:1, 1:N, M:N 중에서 어느 것에 해당하는지 결정
- 엔티티 타입과 관계 타입들에 필요한 애트리뷰트들을 식별, 각 애트리뷰트가 가질 수 있는 값들의 집합을 식별
- 엔티티 타입들을 위한 기본 키를 식별
- 응용을 위한 ER 스키마 다이어그램
- ER 스키마 다이어그램이 응용에 대한 요구사항과 부합되는지 검사
- ER 스키마 다이어그램을 DBMS에서 사용되는 데이터베이스 모델로 변환

ER 모델의 또 다른 표기법
- 수십 개 이상의 애트리뷰트가 엔티티 타입에 연결된 다이어그램을 나타내려면 매우 불편하고 공간 많이 차지
- ERWin 등의 CASE 도구들에서는 새발(crow-feet) 표기법이 흔히 사용됨

1:1 관계

1:N 관계

M:N 관계

엔티티 타입과 애트리뷰트


5.4 ER 스키마를 관계 모델의 릴레이션으로 사상
- 논리적 설계 단계에서는 ER 스키마를 관계 데이터 모델의 릴레이션들로 사상함
- ER 스키마에는 엔티티 타입과 관계 타입이 존재하지만 관계 데이터베이스에는 엔티티 타입과 관계 타입을 구분하지 않고 릴레이션들만 있음
- 릴레이션으로 사상할 대상에 따라 사상하는 방법이 달라짐
- ER 스키마에서 엔티티 타입인지 또는 관계 타입인지
- 엔티티 타입이라면 정규 엔티티 타입인지 또는 약한 엔티티 타입인지
- 관계 타입이라면 2진 관계 타입인지 3진 이상 관계 타입인지
- 애트리뷰트가 단일 값 애트리뷰트인지 또는 다치 애트리뷰트인지
- ER 모델을 릴레이션들로 사상하는 7개의 단계로 이루어진 알고리즘


ER-관계 사상 알고리즘
단계 1: 정규 엔티티 타입과 단일 값 애트리뷰트
- ER 스키마의 각 정규 엔티티 타입 E에 대해 하나의 릴레이션 R을 생성
- E에 있던 단순 애트리뷰트들을 릴레이션 R에 모두 포함
- E에서 복합 애트리뷰트는 그 복합 애트리뷰트를 구성하는 단순 애트리뷰트들만 릴레이션 R에 포함
- E의 기본 키가 릴레이션 R의 기본 키

단계 2: 약한 엔티티 타입과 단일 값 애트리뷰트
- ER 스키마에서 소유 엔티티 타입 E를 갖는 각 약한 엔티티 타입 W에 대하여 릴레이션 R을 생성
- W에 있던 모든 단순 애트리뷰트들을 릴레이션 R에 포함
- 소유 엔티티 타입에 해당하는 릴레이션의 기본 키를 약한 엔티티 타입에 해당하는 릴레이션에 외래 키로 포함
- 약한 엔티티 타입에 해당하는 릴레이션 R의 기본 키는 약한 엔티티 타입의 부분 키와 소유 엔티티 타입에 해당하는 릴레이션을 참조하는 외래 키의 조합

단계 3: 2진 1:1 관계 타입
- ER 스키마의 각 2진 1:1 관계 타입 R에 대하여, R에 참여하는 엔티티 타입에 대응되는 릴레이션 S와 T를 찾음
- S와 T 중에서 한 릴레이션을 선택 → 만일 S를 선택했다면 T의 기본 키를 S에 외래 키로 포함
- S와 T 중에서 관계 타입에 완전하게 참여하는 릴레이션을 S의 역할을 하는 릴레이션으로 선택
- 관계 타입 R이 가지고 있는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우, 복합 애트리뷰트를 구성하는 단순 애트리뷰트)들을 S에 대응되는 릴레이션에 포함
- 두 엔티티 타입이 관계 타입 R에 완전하게 참여할 때는 두 엔티티 타입과 관계 타입을 하나의 릴레이션으로 합치는 방법도 가능


단계 4: 정규 2진 1:N 관계 타입
- 정규 2진 1:N 관계 타입 R에 대하여 N측의 참여 엔티티 타입에 대응되는 릴레이션 S를 찾음
- 관계 타입 R에 참여하는 1측의 엔티티 타입에 대응되는 릴레이션 T의 기본 키를 릴레이션 S에 외래 키로 포함
- N측의 릴레이션 S의 기본 키를 1측의 릴레이션 T에 외래 키로 포함시키면 애트리뷰트에 값들의 집합이 들어가거나 정보의 중복이 많이 발생
- 관계 타입 R이 가지고 있는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우, 복합 애트리뷰트를 구성하는 단순 애트리뷰트)들을 S에 해당하는 릴레이션에 포함

단계 5: 2진 M:N 관계 타입
- 2진 M:N 관계 타입 R에 대해서 릴레이션 R 생성
- 참여 엔티티 타입에 해당하는 릴레이션들의 기본 키를 릴레이션 R에 외래 키로 포함, 이들의 조합이 릴레이션 R의 기본 키
- 관계 타입 R이 가지고 있는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우, 복합 애트리뷰트를 구성하는 단순 애트리뷰트)들을 릴레이션 R에 포함

단계 6: 3진 이상의 관계 타입
- 3진 이상의 각 관계 타입 R에 대해 릴레이션 R 생성
- 관계 타입 R에 참여하는 모든 엔티티 타입에 대응되는 릴레이션들의 기본 키를 릴레이션 R에 외래 키로 포함
- 관계 타입 R이 가지고 잇는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우, 복합 애트리뷰트를 구성하는 단순 애트리뷰트)들을 릴레이션 R에 포함
- 일반적으로 외래 키들의 조합이 릴레이션 R의 기본 키
- 관계 타입 R에 참여하는 엔티티 타입들의 카디날리티가 1:N:N이면 카디날리티가 1인 릴레이션의 기본 키를 참조하는 외래 키를 제외한 나머지 외래 키들의 조합이 릴레이션 R의 기본 키

단계 7: 다치 애트리뷰트
- 각 다치 애트리뷰트에 대해 릴레이션 R 생성
- 다치 애트리뷰트에 해당하는 애트리뷰트를 릴레이션 R에 포함, 다치 애트리뷰트를 애트리뷰트로 갖는 엔티티 타입이나 관계 타입에 해당하는 릴레이션의 기본 키를 릴레이션 R에 외래 키로 포함
- 릴레이션 R의 기본 키는 다치 애트리뷰트와 외래 키의 조합


728x90
반응형
'Computer Science > Database' 카테고리의 다른 글
| [데이터베이스] 7장. 릴레이션 정규화 (0) | 2026.02.11 |
|---|---|
| [데이터베이스] 6장. 물리적 데이터베이스 설계 (0) | 2026.02.11 |
| [데이터베이스] 4장. 관계 대수와 SQL (0) | 2026.02.10 |
| [데이터베이스] 2장. 관계 데이터 모델과 제약조건 (0) | 2026.02.10 |
| [데이터베이스] 1장. 데이터베이스 시스템 (0) | 2026.02.10 |