- (1점) 통제된 중복성(controlled redundancy) 과 통제되지 않은 중복성(uncontrolled redundancy) 의 차이점은 무엇인가요? 예를 들어 설명해주세요.
답: 1주차 강의자료의 31페이지를 참고해주세요.
중복성(redundancy)이란 동일한 정보가 데이터베이스의 여러 위치에 여러 번 저장될 때 발생합니다. 예를 들어, GRADE_REPORT 테이블에서 학생 번호가 8인 학생의 이름이 Brown으로 여러 번 저장되는 경우를 말합니다. 중복성은 데이터베이스의 성능을 향상시키는 데 사용될 수 있지만, 중복성이 통제되지 않으면 데이터베이스의 일관성을 유지하는 데 문제가 발생할 수 있습니다.
통제된 중복성은 중복성이 데이터베이스의 일관성을 유지하는 데 문제가 발생하지 않도록 보장합니다. 예를 들어 (b)의 예시 테이블을 보면, 이러한 레코드가 데이터베이스에 들어오면 학생 번호가 17번인 학생의 이름이 Smith인지 Brown인지를 더 이상 보장할 수 없게 됩니다. 이러한 경우를 통제되지 않은 중복성이 발생했다고 말할 수 있습니다.
- (1점) 아래에 표시된 데이터베이스(교재 그림 1.2)에 적용해야 할 무결성 제약 조건(integrity constraints) 의 예를 들어주세요.
답: 다음과 같은 무결성 제약 조건이 있을 수 있습니다(이 외에 어떤 답도 주어진 데이터베이스의 레코드들을 만족하면 정답으로 처리됩니다).
(a) 각 STUDENT 레코드에 대해 StudentNumber는 고유해야 합니다 (키 제약 조건).
(b) 각 COURSE 레코드에 대해 CourseNumber는 고유해야 합니다 (키 제약 조건).
(c) SECTION 레코드의 CourseNumber 값은 특정 COURSE 레코드에 반드시 존재해야 합니다 (참조 무결성 제약 조건).
(d) GRADE_REPORT 레코드의 StudentNumber 값은 특정 STUDENT 레코드에 반드시 존재해야 합니다 (참조 무결성 제약 조건).
(e) GRADE_REPORT 레코드의 Grade 값은 {A, B, C, D, F, I, U, S} 집합 내의 값 중 하나여야 합니다 (도메인 제약 조건).
(f) COURSE의 모든 레코드는 CourseNumber의 값을 가져야 합니다 (엔터티 무결성 제약 조건).
(g) STUDENT 레코드는 해당 학생이 학점이 24학점 이상인 수업의 총 CreditHours를 완료하지 않은 경우에는 Class=2 (2학년)의 값을 가질 수 없습니다 (일반적인 의미 무결성 제약 조건).
-
(3점) 학생의 성적을 기록하기 위해 사용되는 대학 데이터베이스에 대한 다음의 요구 사항들을 고려해보세요. 이는 교재의 그림 1.2에 표시된 데이터베이스와 비슷하지만 동일하지는 않습니다.
(a) 대학은 각 학생의 이름, 학번, 주민등록번호, 현재 주소 및 전화번호, 영구 주소 및 전화번호, 생년월일, 성별, 학년 (신입생, 2학년, …, 대학원생), 주전공, 부전공 (해당되는 경우), 학위 프로그램 (B.A., B.S., …, Ph.D.)에 대한 정보를 추적합니다. 일부 사용자 애플리케이션은 학생의 영구 주소의 도시, 주, 우편번호 및 학생의 성에 대한 정보가 필요합니다. 주민등록번호와 학번은 각 학생에게 유일한 값을 갖습니다.
(b) 각 학과는 이름, 학과 코드, 사무실 번호, 사무실 전화번호, 대학 이름으로 설명됩니다. 이름과 코드는 각 학과별로 유일한 값을 갖습니다.
(c) 각 과목은 과목 이름, 설명, 과목 번호, 학기 학점 수, 레벨, 제공 학과에 대한 정보를 갖습니다. 과목 번호의 값은 각 과목별로 유일합니다.
(d) 각 섹션은 강사, 학기, 연도, 과목, 섹션 번호에 대한 정보를 갖습니다. 섹션 번호는 동일한 학기/연도에 가르쳐지는 동일한 과목의 다른 섹션을 구별하는 데 사용되며, 그 값은 1, 2, 3, …으로, 각 학기에 가르쳐지는 섹션 수에 따라 결정됩니다.
(e) 성적 보고서에는 학생, 섹션, 글자 성적, 숫자 성적 (F, D, C, B, A에 각각 0, 1, 2, 3, 4)이 포함됩니다.
이 응용 프로그램에 대한 ER 스키마를 설계하고, DB 모델링 도구
[ERDCloud](https://erdcloud.com/)
를 사용하여 해당 스키마에 대한 ER 다이어그램을 그려주세요. 각 엔터티 유형의 주요 속성과 각 관계 유형에 대한 구조적 제약을 지정합니다. 지정되지 않은 요구 사항을 참고하고, 사양을 완료하기 위해 적절한 가정을 합니다.이상민 조교님이 작성하신 가이드라인를 읽어보신 후 사용해보시기를 권유합니다. ERDCloud가 아닌 다른 DB 모델링 도구를 사용해도 좋습니다. 다른 도구를 사용하는 경우 ER 다이어그램을 PDF 형식으로 제출해주세요.
답:
- (1점) 아래에 주어진 ER 다이어그램(교재 그림 3.21)을 고려하면, 항공 예약 시스템의 간단한 스키마를 보여줍니다. ER 다이어그램에서 이 스키마를 생성하기 위한 요구 사항과 제약 조건을 추출해주세요. 요구 사항과 제약 조건의 명세에서 가능한 한 정확해야 합니다.
힌트: 요구 사항과 제약 조건을 작성하는 방법에 대해서는 문제 3을 참조하세요.
답: 다음과 같은 요구 사항과 제약 조건들을 추출할 수 있습니다.
(1) 데이터베이스는 각 공항(AIRPORT)을 나타내며 해당 공항의 고유한 공항 코드(Airport_code), 공항 이름(Name), 그리고 해당 공항이 위치한 도시(City)와 주 정보(State)를 저장합니다.
(2) 각 항공사의 항공편(FLIGHT)은 고유한 번호(Number), 항공사 정보(Airline), 그리고 항공편이 예정된 요일 (Weekdays) 정보를 가지고 있습니다.
(3) 항공편(FLIGHT)은 하나 이상의 항공편 구간(FLIGHT_LEG)으로 구성됩니다. 예를 들어, 뉴욕에서 로스앤젤레스로 가는 CO1223 항공편은 뉴욕에서 휴스턴으로 가는 구간 1과 휴스턴에서 로스앤젤레스로 가는 구간 2로 구성될 수 있습니다. 각 항공편 구간에는 출발 공항(DEPARTURE_AIRPORT)과 예정된 출발 시간(Scheduled_dep_time), 그리고 도착 공항(ARRIVAL_AIRPORT)과 예정된 도착 시간(Scheduled_arr_time)이 있습니다.
(4) 항공편 구간 인스턴스(LEG_INSTANCE)는 특정 날짜(Date)에 대한 항공편 구간의 인스턴스입니다(예를 들어, 1989년 7월 30일에 CO1223 구간 1의 경우). 항공편 구간이 종료된 후에는 각 항공편 구간에 대한 실제 출발 및 도착 공항 및 시간(DEPARTS의 Dep_time과 ARRIVES의 Arr_time)이 기록됩니다. 항공편 구간 인스턴스에서 사용 가능한 좌석 수(No_of_avail_setas)와 사용된 비행기 정보(AIRPLANE)도 저장됩니다.
(5) 각 항공편 구간 인스턴스의 고객 예약(RESERVATION)에는 고객 이름(Customer_name), 전화번호(Cphone) 및 각 예약에 대한 좌석 번호(Seat_no)가 포함됩니다.
(6) 항공기(AIRPLANE)와 항공기 유형(AIRPLANE_TYPE)에 관한 정보도 유지됩니다. 각 항공기 유형(예를 들어, DC-10)에 대해 유지되는 정보에는 유형 이름(Type_name), 제조 회사(Company) 및 최대 좌석 수(Max_seats)가 포함됩니다. 이 유형의 비행기가 착륙할 수 있는(CAN_LAND) 공항 정보도 데이터베이스에 유지됩니다. 각 항공기에는 비행기 ID(Airplane_id), 총 좌석 수(Total_no_of_seats) 및 유형 정보(TYPE)가 유지됩니다.
-
(1점) 아래에 제시된 ER 다이어그램(교재 그림 3.22)을 고려하여 BANK 데이터베이스의 일부를 살펴보세요. 각 은행은 여러 지점을 가질 수 있으며, 각 지점은 여러 계좌와 대출을 가질 수 있습니다.
(a) ER 다이어그램에서 강한 (약하지 않은) 엔터티 유형을 나열하세요.
(b) 약한 엔터티 유형이 있나요? 있다면, 그 이름, 부분 키, 그리고 식별 관계를 제시하세요.
(c) 이 다이어그램에서 약한 엔터티 유형의 부분 키와 식별 관계는 어떤 제약사항을 지정하나요?
(d) 모든 관계 유형의 이름을 나열하고, 관계 유형에서 엔터티 유형의 참여에 대한 (최소, 최대) 제약 조건을 지정하세요. 선택 사항을 정당화하세요.
답:
(a) BANK, ACCOUNT, LOAN, CUSTOMER
(b) 약한 엔티티 타입: BANK_BRANCH 부분 키: Branch_no 식별 관계: BRANCHES
(c) 은행의 지점(BANK_BRANCH)는 특정 은행(BANK)에 속해야 합니다. 이러한 제약 조건은 BRANCHES 관계 유형에 의해 지정됩니다.
(d) BRANCHES - BANK:BANK_BRANCH, 1:N ACCTS - BANK_BRANCH:ACCOUNT, 1:N LOANS - BANK_BRANCH:LOAN, 1:N A_C - ACCOUNT:CUSTOMER, N:M L_C - LOAN:CUSTOMER, N:M
-
(1점) 아래에 제시된 그림(교재 그림 5.6)에서 보여지는 데이터베이스 상태에 직접 다음의 Update 연산이 적용된다고 가정하십시오. 각 연산에 의해 위반되는 모든 무결성 제약 조건을 논의하고, 이러한 제약 조건을 집행하는 다양한 방법에 대해 논의하십시오.
(a) EMPLOYEE에 <’Robert’, ‘F’, ‘Scott’, ‘943775543’, ‘1972-06-21’, ‘2365 Newcastle Rd, Bellaire, TX’, M, 58000, ‘888665555’, 1> 삽입. (b) PROJECT에 <’ProductA’, 4, ‘Bellaire’, 2> 삽입.
(c) DEPARTMENT에 <’Production’, 4, ‘943775543’, ‘2007-10-01’> 삽입.
(d) WORKS_ON에 <’677678989’, NULL, ‘40.0’> 삽입.
(e) DEPENDENT에 <’453453453’, ‘John’, ‘M’, ‘1990-12-12’, ‘spouse’> 삽입.
(f) Essn = ‘333445555’인 WORKS_ON 튜플 삭제.
(g) Ssn = ‘987654321’인 EMPLOYEE 튜플 삭제.
(h) Pname = ‘ProductX’인 PROJECT 튜플 삭제.
(i) Dnumber = 5인 DEPARTMENT 튜플의 Mgr_ssn과 Mgr_start_date를 각각 ‘123456789’와 ‘2007-10-01’로 수정.
(j) Ssn = ‘999887777’인 EMPLOYEE 튜플의 Super_ssn 속성을 ‘943775543’로 수정.
(k) Essn = ‘999887777’ 및 Pno = 10인 WORKS_ON 튜플의 Hours 속성을 ‘5.0’로 수정.
답:
(a) 이 삽입은 모든 제약 조건을 만족하므로 허용됩니다.
(b) 이 삽입은 Dnum에 지정된 참조 무결성 제약 조건을 위반합니다. 왜냐하면 DNUMBER = 2인 DEPARTMENT 튜플이 존재하지 않기 때문입니다. 이 제약 조건을 강제하려면 Dnumber = 2인 DEPARTMENT 튜플을 삽입한 다음 위의 삽입 작업을 수행하는 것입니다. 그렇지 않으면 위의 튜플의 DNUMBER를 5, 4 또는 1과 같은 유효한 Dnumber로 변경해야 합니다.
(c) 이 삽입은 키 제약 조건을 위반합니다. 왜냐하면 이미 동일한 Dnumber를 가진 다른 튜플 (즉, Administration)이 존재하기 때문입니다. 이 제약 조건을 강제하려면 Production의 Dnumber를 Department 관계에서 사용되지 않는 유효한 값으로 변경해야 합니다.
(d) 이 삽입은 엔터티 무결성 제약 조건 (주 키 Pno에 대한 null)을 위반합니다. 또한 SSN에 지정된 참조 무결성을 위반합니다. 왜냐하면 SSN = ‘677678989’인 EMPLOYEE 튜플이 존재하지 않기 때문입니다. 이 제약 조건을 강제하려면 null 값을 유효한 Pno로 변경하거나, SSN = ‘677678989’인 직원 튜플을 삽입한 다음 위의 삽입 작업을 수행해야 합니다. 또 다른 방법은 ESSN을 EMPLOYEE 테이블에서 유효한 SSN으로 변경하는 것입니다. 예를 들어 666884444와 같은 값으로 변경할 수 있습니다.
(e) 이 삽입은 모든 제약 조건을 만족하므로 허용됩니다.
(f) 이 삭제는 허용됩니다.
(g) 이 삭제는 EMPLOYEE, DEPARTMENT, WORKS_ON 및 DEPENDENT에서 튜플이 이를 참조하기 때문에 허용되지 않습니다. 따라서 튜플이 삭제되면 참조 무결성 위반이 발생합니다. 이 제약 조건을 강제하려면 삭제되는 튜플을 참조하는 튜플을 삭제해야 합니다. 또 다른 방법은 참조 속성을 null 또는 유효한 튜플 값으로 수정하는 것입니다.
(h) 이 삭제는 WORKS_ON에서 튜플이 이를 참조하기 때문에 허용되지 않습니다. 따라서 참조 무결성 위반이 발생합니다. 이 제약 조건을 강제하려면 삭제되는 튜플을 참조하는 튜플을 삭제해야 합니다. 또 다른 옵션은 참조 속성을 null 또는 유효한 튜플 값으로 수정하는 것입니다.
(i) 이 수정은 모든 제약 조건을 만족하므로 허용됩니다.
(j) 이 수정은 모든 제약 조건을 만족하므로 허용됩니다.
(k) 이 수정은 모든 제약 조건을 만족하므로 허용됩니다.
-
(2점) 자동차 판매점의 자동차 판매에 대한 기록을 유지하는 데이터베이스에 대한 다음 관계를 고려하십시오 (OPTION은 자동차에 설치된 선택적 장비를 나타냅니다):
- CAR(Serial_no, Model, Manufacturer, Price)
- OPTION(Serial_no, Option_name, Price)
- SALE(Salesperson_id, Serial_no, Date, Sale_price)
- SALESPERSON(Salesperson_id, Name, Phone)
먼저 이 스키마의 외래 키를 지정하고, 어떠한 가정을 하는지 명시하십시오. 다음으로, 몇 가지 샘플 튜플로 관계를 채우고, SALE 및 SALESPERSON 관계에 참조 무결성 제약 조건을 위반하는 삽입 예와 그렇지 않은 다른 삽입 예를 제시하십시오. 또한 이 문제를 해결하기 위해 `ERDCloud’ DB 모델링 도구를 사용해야 합니다. 도구 사용 방법은 문제 3을 참조하십시오.
답: 이 스키마에는 다음 세 개의 외래 키를 지정할 수 있습니다:
- OPTION 관계의 속성 Serial_no는 CAR 관계를 참조합니다.
- SALE 관계의 속성 Salesperson_id는 SALESPERSON 관계를 참조합니다.
- SALE 관계의 속성 Serial_no는 CAR 관계를 참조합니다.