개요
DB 스튜디오 과목에서 매주 요구사항에 맞게 데이터 모델링을 하고, 개념적 설계를 진행한다.
각각의 팀이 설계한 과제물에 대해 게시판을 통해 1차 토의하고, 강의시간에 교수님과 2차 토의를한다.
토의에서 나왔던 내용을 중심으로 과제에 대한 리뷰를 작성해보도록 한다.
요구사항
첫 설계의 요구사항은 다음과 같다.
하나는 UNIVERSITY DB로, 일반적으로 대학교에서 학생, 학부, 과목 등을 관리하는 요구사항이다.
두 번째는 MAIL_ORDER DB로, 쉽게 말해 구매 서비스다.
개체와 속성, 관계 추출
먼저 ERD를 그리기 전, 텍스트로 개체와 속성, 관계를 추출하는 과제를 수행하였다. 이때 composite, complex attribute 등의 속성 특징과 관계를 속성으로 나타내는 것을 활용하였다. 특히 속성의 종류는 설계에 있어서 중요하다고 생각이 들어 여기에 미리 정리해두었다.
이 단계에서 주의할 것은 다음과 같다.
개념 설계에서는 특정 DB를 전제하지 말자.
보통 DB를 RDBMS로 먼저 접하는 사람이 많아서 그런지, 개념 설계 단계에 RDBMS의 특징을 보이는 팀이 종종 있었다. 예를 들어, 다른 개체(Entity)의 식별값을 통해 관계를 정의하는 케이스가 가장 많았다.
- 개념 설계 단계에서는 요구사항을 명확히 파악하고 청사진같은 존재이므로, 특정 DB를 전제하에 설계하지 않도록 주의하자.
- ER 모델에서 참조 관계는 속성이 아니라 관계로 표현된다.
개념과 표기법을 숙지하자.
composite, mutiple, complex 등 다양한 속성의 종류가 있다. 그런데 이 개념들을 헷갈려하는 팀들이 많았다. 또한, ERD에서 표기하는 것까지 착각한 팀도 있었다. 위 노션 페이지에 정리한 것을 토대로 각각의 개념과 표기법을 숙지하자.
- 주소와 휴대폰 번호를 연락처라는 complex attribute로 구조화 AddressPhone({Phone(current, permanent), Address(current, permanent(city, state, zip-code))}) 하였다.
- Course와 Section, Grade가 많이 헷갈렸는데 사실 내 과제물에서는 특이 점이 없었다.
- 잘못 설계한 점은 Course Entity에 section_number라는 속성을 추가함으로써 외래키를 사용했다는 점이다.
여기서 좀 크리티컬한 실수를 했다.
나는 요구사항에서 하나의 Order는 Customer에 의해 생성되고, 또 Employee에 의해 관리된다는 점에 주목해서 각각의 Entity마다 해당 정보를 가질 수 있도록 작성하였다.
- 데이터가 중복된다는 단점이 있다. 하나의 Entiry에만 정보를 잘 담아두면 된다.
- 이때 어떤 개체에 정보를 담을 것이냐?를 유의해야 한다. (위 예시같은 경우는 EMPLOYEE에도 담을 수 있고, COUSTOMER에도 담을 수 있다.)
결론적으로 ORDER를 제외하고, 다른 Entity에 정의한 관계는 모두 제거하였다.
ORDER 개체가 part, customer, employee와 모두 직접적으로 연관되어있으므로 ORDER를 대표로 관계 속성을 정의하였다.
데이터 모델링, ERD
이 단계에서는 여러 표기법을 통해 그림으로 도식화한다.
DATA Refining
① Participation ② Cardinality를 고려한 Refining을 진행한다.
사실 이 DATA Refining이라는 것이 잘 이해가 안되었는데 GeekInterview에서 상세히 설명하고 있다. 좋은 자료라 첨부한다!
각각의 세부 단계에서는 다음과 같은 개념이 활용된다.
- Relationship Type, Sets and Instances
- Relational Model
- Realationships as Attributes
- Role Names and Recursive Relationships
- Constraints on Relationship Types
- Cardinality Ratios for Binary Relationships
- Participations Constraints and Existenxe Dependencies
- 여러 개체 타입에 자주 등장하는 경우는 속성을 Entity로 승격하고, Entity로 두기에 애매한 것은 속성으로 강등한다.
=> 일단 과제 리뷰 포스팅이니 위와 같은 내용은 따로 DB 개념 등으로 포스팅할 것이다.
위 주의사항을 토대로 ERD를 그린 건 다음과 같다.
- [표기법] Composite 속성과 Multiple 속성의 표기를 혼동하였다. name, phone, address 속성은 multiple attribute를 의도하였으므로, 표기를 수정해주어야 한다.
- [설계 관점]Grade Weak Entity의 문법상 의미는 맞다. 그러나 문맥상 의미는 좋아보이지 않는다. 차라리 Student의 속성으로 강등하는 것이 나을 수도 있다.
- [설계 관점] 주전공/부전공을 나타내는 관계속성은 그 의미는 맞으나, 오해의 소지가 있다. (ex. (1,2) min-max를 설정하면 부전공이 2개로 들어갈 수 있는데 이걸 구별하는 값이 없다. 차라리 major_department와 minor_department 두 관계로 구분짓자.
- [설계 관점] Section Entity는 개별적으로 구분이 안되며 종속적인 개체이기에 (1,n)은 맞지만 문맥상 완전 틀렸다. 학생이 수강하는 것은 Course가 아니라 Section이다. 따라서 Section의 Course의 Weak Entity이어야 하고, Section은 Studer와 연관관계 매핑이 된다.
- [중복 데이터] Student와 Grade를 연관관계 매핑해놓고, partial key에 student, section을 주었다. 이는 중복 데이터다.
- [표기법] Partial/Total Participation과 Chen 기법을 혼용하였다. 하나로 통일하는 것이 좋다.
속성들은 생략하고 수정해보았다.
이 과정을 생략하고 바로 ERD 도식화에 들어가서 놓치는 부분이 많을 수밖에 없었다.
교수님께서도 이 과정을 통해 중복된 값을 제거하는 것이 중요하다고 강조하셨다.
배운 게 많은 만큼 다음 과제는 더 명확하게 해봐야겠다~~
'DB > DB 설계 과제' 카테고리의 다른 글
| [DB] DB스튜디오 과제 리뷰 2 | 데이터 모델링과 개념적 설계 (0) | 2024.04.17 |
|---|
댓글