제 3 장 엔티티-관계(ER) 모델을 사용한 데이타 모델링 Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe © 2005 황규영 홍의경 음두헌 박영철 김진호 조완섭

Fundamentals of Database Systems 목 차 예제 데이터베이스 응용(COMPANY) ER 모델의 개념 엔티티와 애트리뷰트 엔티티 타입, 값 집합, 키 애트리뷰트 관계와 관계 타입 약한 엔티티 타입 역할과 관계 타입에서의 애트리뷰트 ER 다이어그램 (ERD) - 표기법 COMPANY 스키마를 위한 ER 다이어그램 다른 표기법 - UML 클래스 다이어그램, 기타 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 서론 데이터베이스 응용 데이터베이스 + 필요한 기능을 구현한 프로그램 엔티티-관계 모델링 고수준 데이터 모델: 인간의 이해를 돕기 위한 모델 개념설계 도구로서 데이터베이스 구조와 제약조건 정의 다른 모델링 기법 UML 방법론의 클래스 다이어그램을 이용한 모델링 데이터베이스 구조와 제약조건 + 연산 정의 Ch2 Fundamentals of Database Systems

3.1 DB 설계를 위한 고수준의 개념적 데이타 모델 사용 [그림 3.1] 데이타베이스 설계의 단계들 작은 세계 요구사항들의 수정과 분석 기능적 요구사항들 데이타베이스 요구사항들 DFD, 순서도, 시나리오, 순서 다이어그램 FUNCTIONAL ANALYSIS 개념적 설계 ERD 사용 High-level Transaction Specification 개념 스키마 (고수준 데이터 모델로 표현됨) DBMS-independent 논리적 설계 (DATA MODEL MAPPING) 상용 DBMS 사용 DBMS-specific 논리적(개념적)스키마 (특정 DBMS의 구현(표현) 데이터 모델로 표현됨) APPLICATION PROGRAM DESIGN 물리적 설계 내부저장구조 인덱스 접근경로 화일조직 TRANSACTION IMPLEMENTATION 내부스키마 (For the same DBMS) Application Programs Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 예제 COMPANY 데이터베이스 COMPANY 데이타베이스의 작은 세계 1. 회사는 여러 부서들로 구성된다. 각 부서마다 고유한 이름, 고유한 번호, 부서를 관리하는 특정 사원이 있다. 사원이 부서를 관리하기 시작한 날짜도 유지한다. 한 부서는 여러 위치에 있을 수 있다. 2. 한 부서는 여러 프로젝트들을 관리한다. 각 프로젝트는 고유한 이름, 고유한 번호, 한 개의 위치를 가진다. 3. 각 사원에 대해서 이름, 사회보장번호, 주소, 급여, 성별, 생년월일을 저장한다. 한 사원은 한 부서에 속하지만, 여러 프로젝트들에 관여할 수 있다. 한 사원이 관여하는 프로젝트들은 그 사원이 소속된 부서가 관리하는 프로젝트가 아니어도 무방하다. 반드시 한 부서의 각 사원이 각 프로젝트를 위해 일하는 주당 근무 시간을 기록한다. 또한 각 사원의 직속 상사도 유지한다. 4. 보험 목적을 위해서 각 사원의 부양가족들을 기록한다. 각 부양 가족에 대해서 이름, 성별, 생년월일, 사원과의 관계를 기록한다. Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 개념적 설계의 결과 - ERD Fname Minit Lname Number N 1 Name Address WORKS_FOR Name Locations Sex Salary NumberOfEmployees StartDate DEPATMENT Ssn EMPLOYEE 1 1 1 MANAGES CONTROLS Bdate Hours N supervisee supervisor M N WORKS_ON PROJECT 1 SUPERVISION N 1 Name DEPENDENTS_OF Location N Number DEPENDENT Name Sex BirthDate Relationship [그림 3.2] COMPANY 데이타베이스를 위한 ER 스키마 다이어그램 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 ER 모델은 데이터를 엔티티(개체), 관계, 애트리뷰트 (속성)로 모델링함 엔티티와 애트리뷰트 엔티티: 실세계에서 독립적으로 존재하는 실체 애트리뷰트: 엔티티를 기술하는 속성 Name = John Smith Address = 2311 Kirby, Houston, Texas 77001 Age = 55 HomePhone = 713-749-2630 e1 Name = Sunco Oil Headquarters = Houston President = John Smith c1 [그림 3.3] 두 개의 엔티티(직원 e1과 회사 c1)와 애트리뷰트 및 값 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 엔티티 & 애트리뷰트 Fname Minit Lname Number N 1 Name Address WORKS_FOR Name Locations Sex Salary NumberOfEmployees StartDate DEPATMENT Ssn EMPLOYEE 1 1 1 MANAGES CONTROLS Bdate Hours N supervisee supervisor M N WORKS_ON PROJECT 1 SUPERVISION N 1 Name DEPENDENTS_OF Location N Number DEPENDENT Name Sex BirthDate Relationship Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 애트리뷰트 유형 복합 애트리뷰트 (애트리뷰트 집합) 단순 애트리뷰트 [그림 3.4] 복합 애트리뷰트의 계층구조 단일 값 애트리뷰트 다치 애트리뷰트 {애트리뷰트 집합} 저장된 애트리뷰트 유도된 애트리뷰트 Address StreetAddress City State Zip Number Street ApartmentNumber Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 복합 애트리뷰트 특수한 애트리뷰트 Fname Minit Lname Number 다치 애트리뷰트 N 1 Name Address WORKS_FOR Locations Name Sex Salary NumberOfEmployees StartDate DEPATMENT Ssn 유도 애트리뷰트 EMPLOYEE 1 1 1 MANAGES CONTROLS Bdate Hours N supervisee supervisor M N WORKS_ON PROJECT 1 SUPERVISION N 1 Name DEPENDENTS_OF Location N Number DEPENDENT Name Sex BirthDate Relationship Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 널 값 두 가지로 사용됨; ‘적용할 수 없음’이라는 의미와 ‘알려지지 않음’의 의미 복잡한 (complex) 애트리뷰트 {AddressPhone( {Phone(AreaCode, PhoneNumber ) }, Address(StreetAddress(Number, Street, ApartmentNumber ), City, State, Zip } [그림 3.5] 복잡한 애트리뷰트 AddressPhone Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 개체(엔티티) 타입 : 개체집합 [그림 3.6] 두 개체 타입과 이에 속하는 개체들 개체 타입의 이름: 애트리뷰트 이름 EMPLOYEE COMPANY Name, Age, Salary Name, Headquarters, President c1 (Sunco Oil, Houston, John Smith) c2 (Fast Computer, Dallas, Bob King) : e1 (John Smith, 55, 80k) e2 (Fred Brown, 40, 30K) e3 (Judy Clark, 25, 20K) : 개체 집합 (외연) 애트리뷰터 값 Ch2 Fundamentals of Database Systems

3.3 개체 타입, 개체 집합, 애트리뷰트, 키 [그림 3.7] CAR 개체 타입 CAR Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, {Color} car1 ((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1989, {red,black}) car2 ((ABC 123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, {blue}) car3 ((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, {white, blue}) : Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 키 애트리뷰트 각 엔티티마다 서로 다른 값을 가지는 애트리뷰트 그림 3.2에서 COMPANY 엔티티 타입에서 키 애트리뷰트는 Name PERSON 엔티티 타입의 키 애트리뷰트는 SocialSecurityNumber 복합키 두 개 이상의 애트리뷰트들이 모여서 하나의 키 애트리뷰트 역할을 하는 키 값 집합(도메인) 각 엔티티에서 애트리뷰트가 가질 수 있는 값들의 집합 EMPLOYEE의 Age 애트리뷰트의 값 집합은 ? (16부터 70 사이의 정수 집합) Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 키 애트리뷰트 Fname Minit Lname Number N 1 Name Address WORKS_FOR Name Locations Sex Salary NumberOfEmployees StartDate DEPATMENT Ssn EMPLOYEE 1 1 1 MANAGES CONTROLS Bdate Hours N supervisee supervisor M N WORKS_ON PROJECT 1 SUPERVISION N 1 Name DEPENDENTS_OF Location N Number DEPENDENT Name Sex BirthDate Relationship [그림 3.2] COMPANY 데이타베이스를 위한 ER 스키마 다이어그램 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 COMPANY 데이타베이스에 대한 초기 개념적 설계 (엔티티 타입/애트리뷰트 정의) 엔티티 타입 DEPARTMENT는 Name, Number, Location, Manager, ManagerStartDate 애트리뷰트를 가진다. Location은 유일한 다치 애트리뷰트이다. Name과 Number는 각 부서마다 고유하기 때문에 각각 키 애트리뷰트로 지정할 수 있다. 엔티티 타입 PROJECT는 Name, Number, Locations, ControllingDepartment 애트리뷰트들을 가진다. Name과 Number가 각각 키 애트리뷰트이다. 엔티티 타입 EMPLOYEE는 Name, SSN, Sex, Address, Salary, BirthDate, Department, Supervisor 애트리뷰트들을 가진다. 사용자가 사원 Name의 각 구성요소(FirstName, MiddleInitial, LastName)와 Address의 각 구성요소를 참조할 것인지의 여부를 알기 위해서 사용자와 다시 협의해야 한다. 엔티티 타입 DEPARTMENT는 Employee, DependentName, Sex, BirthDate, Relationship(사원과의 관계) 애트리뷰트들을가진다. Ch2 Fundamentals of Database Systems

[그림 3.8] 제 3.2절의 데이타베이스를 위한 엔티티 타입들의 초기 설계 DEPARTMENT Name, Number, {Locations}, Manager, ManagerStartDate PROJECT Name, Number, Location, ControllingDepartment EMPLOYEE Name(FName, MInit, LName), SSN, Sex, Address, Salary, BirthDate, Department, Supervisor, {WorksOn (Project, Hours)} DEPENDENT Employee, DependentName, Sex, BirthDate, Relationship [그림 3.8] 제 3.2절의 데이타베이스를 위한 엔티티 타입들의 초기 설계 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.4 관계, 관계 타입, 역할, 구조적 제약조건 관계 타입과 관계 인스턴스 관계 타입 (관계 집합) R은 엔티티 간의 연관들의 집합임 : 그림 3.9에서 WORKS_FOR [그림 3.9] 관계 WORKS_FOR에서 관계 인스턴스 : 7 개 (r1 ~ r7) e1 e2 e3 e4 e5 e6 e7 . r1 r2 r3 r4 r5 r6 r7 : d1 d2 d3 EMPLOYEE WORKS_FOR DEPARTMENT Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.4 관계, 관계 타입, 역할, 구조적 제약조건 관계 타입의 차수(degree): 관계에 참여하고 있는 엔티티 타입의 수 이진(binary) 차수: [그림 3.9]의 WORKS_FOR 관계 3진(ternary) 차수 : [그림 3.10] 3진 관계 SUPPLY r1 r2 r3 r4 r5 r6 r7 : s1 s2 . p1 p2 p3 j1 j2 j3 SUPPLIER PART PROJECT SUPPLY [그림 3.10] 삼진관계 SUPPLY Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.4 관계, 관계 타입, 역할, 구조적 제약조건 애트리뷰트로서의 관계: 관계는 참여 엔티티 타입의 속성으로 볼 수도 있음 예: (EMPLOYEE의 Department 또는 DEPARTMENT의 Employees) 역할과 순환적(recursive) 관계 [그림 3.11] Employee에서의 순환적 관계 SUPERVISION은 상사(1)와 부하(2)의 두 역할로 구분할 수 있음 e1 e2 e3 e4 e5 e6 E7 ... r1 r2 r3 r4 r5 r6 2 1 EMPLOYEE SUPERVISION Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.4 관계, 관계 타입, 역할, 구조적 제약조건 관계 타입에서 제약조건 카디날리티 비율 : 엔티티가 참여할 수 있는 최대 관계 인스턴스의 수를 명시 (이진 관계 타입에 대한 카디날리티 비율은 1:1, 1:N, M:N) 참여 제약조건 : 한 엔티티의 존재가 관계 타입을 통해 연관되어 있는 다른 엔티티에 의존하는지의 여부 (부분참여와 전체참여) MANAGER 관계 : EMPLOYEE는 부분참여하고, DEPARTMENT는 전체참여(존재종속성)함 e1 e2 e3 e4 e5 e6 e7 . r1 r2 r3 : d1 d2 d3 EMPLOYEE MANAGES DEPARTMENT Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.4 관계, 관계 타입, 역할, 구조적 제약조건 [그림 3.13] M:N 관계 WORKS_ON e1 e2 e3 e4 . r1 r2 r3 r4 r5 r6 R7 p1 p2 p3 p4 EMPLOYEE WORKS_ON PROJECT Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.4 관계, 관계 타입, 역할, 구조적 제약조건 관계 타입의 애트리뷰트 1:1 관계 타입의 애트리뷰트: 양쪽 엔티티 타입으로 이동 가능 1:N 관계 타입의 애트리뷰트: N쪽 엔티티 타입으로 이동 가능 M:N 관계 관계 타입의 애트리뷰트: 엔티티 타입으로 이동 불가 EMPLOYEE EMPLOYEE StartDate EMPLOYEE 1 1 1 MANAGES StartDate MANAGES MANAGES 1 1 1 DEPARTMENT DEPARTMENT DEPARTMENT StartDate EMPLOYEE EMPLOYEE StartDate EMPLOYEE N N N WORKSFOR StartDate WORKSFOR WORKSFOR 1 1 1 DEPARTMENT DEPARTMENT DEPARTMENT StartDate Ch2 Fundamentals of Database Systems

3.5 약한 엔티티 타입(Weak Entity Type) 자신의 키 애트리뷰트가 없는 엔티티 타입 예: DEPENDENT 엔티티 타입 식별(소유) 엔티티 타입과 식별 관계 EMPLOYEE와 DEPENDENT에서 EMPLOYEE가 식별 엔티티 타입이며, 두 엔티티 타입 사이의 관계를 식별 관계라고 부름 부분 키 동일한 소유 엔티티와 연관된 약한 엔티티 집합 내의 서브 집합 (예를들어 소유 엔티티 employee e1의 dependents set) 내에서 서로를 구분할 수 있는 애트리뷰트들의 집합 (예를들어, Dependent.name) 약한 엔티티는 소유 엔티티 타입의 복합 속성으로 표현될 수도 있으나 다음의 경우에는 별도의 엔티티 타입으로 표현하는 것이 바람직함 (1) 엔티티가 많은 애트리뷰트들을 가지고, (2) 식별 관계 타입 외에 다른 관계 타입들에 독립적으로 참여하는 경우 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.4 관계, 관계 타입, 역할, 구조적 제약조건 약한 엔티티 타입으로 표현 복합 다치 애트리뷰트로 표현 EMPLOYEE EMPLOYEE 1 HAS Dependents Name Sex BirthDate Relationship N DEPENDENTS Name Sex BirthDate Relationship Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 3.6 COMPANY DB에 대한 ER 설계의 개선 그림 3.8에서 관계를 나타내는 애트리뷰트들을 관계 타입으로 변환하여 발전시킴 생성되는 관계 타입들 MANAGES : EMPLOYEE와 DEPARTMENT 사이의 1:1 관계 타입 WORKS_FOR : DEPARTMENT와 EMPLOYEE 사이의 1:N 관계 타입 CONTROLS : DEPARTMENT와 PROJECT 사이의 1:N 관계 타입 SUPERVISION : EMPLOYEE(상사역할)와 EMPLOYEE(사원역할) 사이의 1:N 관계 타입 WORKS_ON : EMPLOYEE와 PROJECT 사이의 M:N 관계 타입 DEPENDENTS_OF :EMPLOYEE와 DEPENDENT 사이의 1:N 관계 타입 Ch2 Fundamentals of Database Systems

[그림 3.8] 제 3.2절의 데이타베이스를 위한 엔티티 타입들의 초기 설계 DEPARTMENT Name, Number, {Locations}, Manager, ManagerStartDate PROJECT Name, Number, Location, ControllingDepartment EMPLOYEE Name(FName, MInit, LName), SSN, Sex, Address, Salary, BirthDate, Department, Supervisor, {WorksOn (Project, Hours)} DEPENDENT Employee, DependentName, Sex, BirthDate, Relationship [그림 3.8] 제 3.2절의 데이타베이스를 위한 엔티티 타입들의 초기 설계 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 개념적 설계의 결과 Fname Minit Lname Number N 1 Name Address WORKS_FOR Name Locations Sex Salary NumberOfEmployees StartDate DEPATMENT Ssn EMPLOYEE 1 1 1 MANAGES CONTROLS Bdate Hours N supervisee supervisor M N WORKS_ON PROJECT 1 SUPERVISION N 1 Name DEPENDENTS_OF Location N Number DEPENDENT Name Sex BirthDate Relationship Ch2 Fundamentals of Database Systems

3.7 ER 다이어그램, 명명에 관한 규칙, 설계에 관한 사항 스키마에 사용된 각 구조물에 대해 가능한 한 그 의미를 전달할 수 있는 이름 선택 복수보다 단수 이름 선택 일반적으로 자연어로 기술된 요구 사항에서 명사는 엔티티 타입 이름, 동사는 관계 타입 이름으로 해석하는 것이 도움이 됨 ER 다이어그램은 왼쪽에서 오른쪽, 위에서 아래로 읽기 쉽게 작성함 스키마 설계는 반복해서 개선하는 작업이 필요함 – 한번에 완성하기는 쉽지 않음 Ch2 Fundamentals of Database Systems

3.7 ER 다이어그램, 명명에 관한 규칙, 설계에 관한 사항 Symbol Meaning 엔티티 타입 약한 엔티티 타입 관계 타입 식별 관계 타입 애트리뷰트 키 애트리뷰트 다치 애트리뷰트 ... E1 R E2 (최대값, 최소값) E 복합 애트리뷰트 유도된 애트리뷰트 E1이 R에 전체참여 E2가 R에 부분참여 R에서 E1:E2의 카디날리티 비율이 1:N R에서 E의 참여에 대한 구조적 제약조건 E가 R의 관계를 몇 개나 가지는가? 1 N Ch2 Fundamentals of Database Systems

구조적 제약조건 – 관계에 대한 의미를 표현하는 방법 구조적 제약조건 – 관계에 대한 의미를 표현하는 방법 관계에 대한 구조적 제약조건 카디날리티 비율(2진 관계의) 1:1, 1:N, N:1, or M:N 연결된 선에 적절한 숫자를 나타냄으로써 표기함. 참여 제약조건(각 참여 엔티티에 대해) 전체 (또는 존재 종속성) 또는 부분 참여 전체 참여의 경우 연결된 선을 이중선으로 표기함. Ch2 Fundamentals of Database Systems

관계 구조적 제약조건을 위한 다른(최소값, 최대값) 표기법 관계 타입 R에서 엔티티 타입 E의 각 참여를 명시 E 내의 각 엔티티 e가 적어도 최소값 만큼 그리고 최대 최대값 만큼 R 내의 관계 인스턴스들과 참여함을 나타냄 디폴트(제약조건 무): 최소값=0, 최대값=n 반드시, 최소값최대값, 최소값0, 최대값 1 예: 부서는 정확히 한 명의 부서장을 가지며 사원은 최대 한 개의 부서를 관리할 수 있다. MANAGES의 EMPLOYEE의 참여에 (0,1)로 표기 MANAGES의 DEPARTMENT의 참여에 (1,1)로 표기 사원은 정확히 한 부서에서 일 할 수 있으며 부서는 몇 명의 사원이라도 둘 수 있다. WORKS_FOR의 EMPLOYEE의 참여에 (1,1)로 표기 WORKS_FOR의 DEPARTMENT의 참여에 (0,n)로 표기 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems (최소값, 최대값) 표기법 관계 제약조건 (0,1) (1,1) Employee Manages Department (1,1) (1,N) Employee Department Works-for Ch2 Fundamentals of Database Systems

(min, max) 표기법을 사용한 COMPANY ERD Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems UML 클래스 다이어그램 엔티티 타입  클래스 엔티티(개체)  오브젝트(객체) 관계  연관(Association), 순환적 관계  재귀연관 이름 속성 애트리뷰트 연관의 애트리뷰트 최소..최대 집단화(Aggregation) 연산: ERD와의 차이점 연관 역할이름 참여수에 상관없음 재귀연관 판별자 자격연관 자격집단화 역할이름 애트리뷰트: 도메인(애트리뷰트 값집합) Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 데이터 모델링 도구 Data Modeling Tools 개념적 모델링을 지원하고 관계 스키마 설계로 사상하는 기능을 제공하는 많은 도구들이 존재함 예: ERWin, S- Designer (Enterprise Application Suite), ER- Studio, 등 장점 응용 요구사항에 대한 문서로서의 기능 제공 사용하기 쉬운 사용자 인터페이스 – 대부분 그래픽 편집기 지원 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 현 모델링 도구의 문제점 다이어그램 기능 의미 있는 개념 표기 수단이 미약함 다이어그램 배치 및 외관을 위해 박스와 선을 주로 사용하기 때문에 결과 테이블 간의 관계만(기본과 외래 키)을 표시함 방법론 내장 방법론 지원의 미약 균형 분석 및 사용자 중심의 설계 선호 기능의 미약 설계 검증과 개선을 위한 제안 기능의 미약 Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems 데이터베이스 자동 설계 도구의 일부 리스트 COMPANY TOOL FUNCTIONALITY Embarcadero Technologies ER Studio Database Modeling in ER and IDEF1X DB Artisan Database administration and space and security management Oracle Developer 2000 and Designer 2000 Database modeling, application development Popkin Software System Architect 2001 Data modeling, object modeling, process modeling, structured analysis/design Platinum Technology Platinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus Data, process, and business component modeling Persistence Inc. Pwertier Mapping from O-O to relational model Rational Rational Rose Modeling in UML and application generation in C++ and JAVA Rogue Ware RW Metro Resolution Ltd. Xcase Conceptual modeling up to code maintenance Sybase Enterprise Application Suite Data modeling, business logic modeling Visio Visio Enterprise Data modeling, design and reengineering Visual Basic and Visual C++ Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems ER 표기법의 문제점 원래 ER 모델은 객체 모델링 기법에서 제공하는 추상화(특수화/일반화) 기능을 지원하지 못함 확장 엔티티-관계(EER) 모델 집합-부분집합 관계를 포함. 특수화/일반화 계층구조를 포함. Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems Ch2 Fundamentals of Database Systems

Fundamentals of Database Systems Ch2 Fundamentals of Database Systems