ComputerScience/Database (26) 썸네일형 리스트형 DB - 18. Normalization 2 1. Universal relaction - E-R 모델링에서 테이블 R들로 변환을 하였는데 다른 approach를 알아본다. - 모든 속성을 포함하는 single relation을 하나 만드는데 이를 universal relation라고 한다. - 이 single table을 함수종속에 기반해서 쪼개어 normalization을 수행하는 방법이 다른 한가지의 approach이다. 2. Denormalization - BCNF를 만드는 방법을 배웠지만 꼭 모든 테이블이 BCNF여야 하는 것은 아니다. 이것은 설계자가 판단한다. - 만약 모든 테이블을 BCNF로 쪼개버리면 나중에 검색,조회시, 분리된 두 테이블간의 join연산이 필요할 수 있다. - 따라서 검색,조회가 빈번하고 높은 성능이 필요하다면 선택.. DB - 17. Boyce Codd Normal Form 1. BCNF - BCNF의 정의를 살펴보자. - BCNF인가를 따지려면 일단 모든 함수 종속관계를 알고 있어야 한다. - 그 종속관계중에서 trivial 한것은 당연히 아래 첫번째 조건을 만족하고 non trivial 한 관계는 아래 제시된 조건을 만족해야 한다. 그럼 BCNF가 된다. - non trivial 한 종속관계에서 결정자가 superkey이면 된다. - 이 예시를 보면 dept_name -> building, budget 이라는 non trivial 함수 종속관계가 성립은 하지만 a부분인 dept_name은 슈퍼키가 아니다. 따라서 이 테이블은 BCNF의 조건에 위배된다. - 실제로 테이블을 보면 동일한 dept_name이 여러번 나오기 때문에 고유식별성이 없다. 따라서 함수종속이 성립하더.. DB - 16. Normalization 1. Normalization - db를 구축하기 위해 거치는 단계를 정리하면 요건 분석 -> ERD -> Table 스키마 였다. - 하지만 요건분석 -> ERD는 특정한 규칙에의해 이루어진다기 보다는 설계자의 의도에 의해 정해지기 때문에 오류가 생길 가능성이 항상 있다. - 그래서 변환규칙으로 만들어진 table 스키마가 항상 good design이라고 장담할 수 없기 때문에 이를 정제하는 과정이 필요하다. 2. Good design? Bad design? - good design, bad design이 무엇인지 살펴보자. - 이 테이블은 department와 instructor가 함께 하나의 테이블로 구성되어있다. - 이 디자인이 bad design인 이유로 들 수 있는 것은 학과 데이터의 중복이다.. DB - 15. University Enterprise ER -> RDB 1. ER Model -> RDB - 이제까지 배운 내용을 가지고 ER 모델을 RDB로 바꿔보자. 2. 다:다 변환 3. Entity set 변환 4. 1대다 변환 - advisor의 경우는 null이 들어가는 것을 방지하기 위해 독립된 테이블로 변환하였다. - 겹선 다이아몬드는 변환하지 않는다. 5. 1차 변환 결과 - 밑줄은 pk, 색상은 fk를 나타낸다. 6. 정규화 - 1차로 변환한 db 스키마에 대해서 정말 절절한지 정제하는 작업을 말한다. - 문제가 없다면 넘어가고 필요하면 수정이 될 수 있다. - time_slot_id를 굳이 두 테이블로 관리할 필요가 없어보인다. - 하나로 흡수했더니 section의 time_slot_id로 Time_slot에서 고유식별이 어렵게 되었다. 따라서 time_.. DB - 14. E-R Model, RDB로 변환하기 2 1. 변환 규칙 복습 2. 일대다 relationship 변환 - relation을 table로 변환하는 예시 - relation을 table로 변환하지 않고 extra attribute를 추가하는 예시 3. 일대일 relationship 변환 - 일대일 관계를 변환한 예제이다. - 만약 별도 테이블을 만들지 않는다고 하면 아래처럼 할 수 있다. - 두가지 스키마가 가능하지만 도서가 더 많은 상황이라면 과목에 속성을 추가하는 것이 더 나을 수 있다. 왜냐하면 도서에 과목번호 속성이 추가되면 null이 들어가는 레코드가 많아질 수 있기 때문이다. - 반대로 과목에 속성을 추가하는 경우는 total participation이기 때문에 null이 들어갈 일이 없다. 4. Unary relationship 변환.. DB - 13. E-R Model 4 1. Design issues case 1. - er modeling을 할 때 생길 수 있는 애매한 상황들을 알아보자. - stud_dept가 정의되어 있는데 굳이 student에 dept_name이 속성으로 들어가 중복을 야기한다. case 2. - 학생이 수업에서 낸 과제를 채점할 수 있는 구조를 나타내고 있다. - 그런데 이 구조에서는 학생의 수업당 딱 한개의 과제만 채점이 가능하다. - 현실세계를 더 잘 반영할 수 있도록 해보자. - 이렇게 고치면 assignment는 section에 의존하는 weak entity이고 학생이 특정 section의 여러 과제들을 marks_in하도록 되어있다. - 이 방법에서는 다중값 속성으로 특정학생이 특정 수업을 들을때 여러개의 assignment와 각각의 ma.. DB - 12. E-R Model, RDB로 변환하기 1. 최종 점검 - 이제 필요한건 다 배웠으니 전체 ER Diagram을 살펴보자. - entitiy set는 모두 7개, relationship diamond는 총 10개가 있다. - weak entity 1개와 identifying relationship도 1개가 보인다. - course entity는 unary로 선수, 후수 과목 관계가 잘 나타나있다. - 겹선으로 나타낸 total participation을 보면 학생은 반드시 과가 정해져있어야하는 등의 제약들이 잘 반영되었다. 2. Redcution to Relation Schemas - 위의 ER Model로 RDB를 만들면 아래처럼 된다. - 일반적으로 entity set, relation이 하나의 table이 된다. 그 안의 속성들이 col.. DB - 11. E-R Model 2 1. Complex Attributes - attribute 하나로 충분하지 않은 상황이 생길 수 있다. - 예를들면 아래처럼 name, address등의 속성이 세분화된 composite attributes로 구성되는 경우가 있을 수 있다. - 아니면 multivalued attributes가 있을 수 있다. 예를들면 전화번호라는 속성은 집전화, 휴대전화 등 여러개의 다중값을 가질 수 있다. - derived attributes는 도출되는 속성을 말한다. 생일이라는 속성에서 나이를 꺼낼 수 있는데 나이가 도출된 속성이 된다. 다른 예로는 입사년월을 알면 근무기간을 도출할 수 있다. 근무기간을 도출된 속성이라고 한다. - 이러한 complex attribute를 표현하는 방법은 아래와 같다. - phon.. 이전 1 2 3 4 다음
