문제 제기
프로젝트를 하면서 경험한 일 입니다. 요구사항에 분명히 기재되어 있는 사실 혹은 요구사항에 반영을 미처 못해 실제 설계 과정에서 누락된다면 추후에 데이터베이스를 구축하여 운용할 때 관리해야 할 사실들을 저장하지 못하는 경우가 발생합니다. 예를들어 회원이 삭제된다면 외래키로 갖고 있던 주문 테이블이 문제가 생기기 때문에 회원을 완전 삭제하는 대신 status 필드명을 추가하여 상태만 변경하는 식으로 문제를 해결해야 합니다. 하지만 저는 이러한 문제가 생길지 예상하지 못하여 회원테이블에 status필드명을 추가하지 않았고 추후에 이 문제를 발견하여 테이블을 나중에 수정을 하게 되었습니다.
규모가 작은 프로젝트에서는 뭐 이러한 문제가 생겨도 그때 그냥 바로바로 테이블을 수정하지 뭐 이런 마인드가 별로 문제가 되지 않지만 테이블이 수십~수백개의 테이블이 이미 생성된 상태의 엄청난 프로젝트에서 이런 마인드로 했다간 status필드명을 추가하며 어느 곳에서 또 문제가 터질지도 모르고 감당할 수 없게 됩니다.
따라서 이러한 문제를 미연에 방지하기 위해 요구사항부터 개념적 설계=>논리적설계=>물리적설계까지 각 단계마다 검증하는 과정이 필수적입니다.
이번 시간에는 개념적 모델링 부터 논리적 모델링까지 어떻게 해야 하는지 예시를 통해 배워보도록 하겠습니다.
이번 글은 이미 개념을 안다는 가정하에 작성되는 글 입니다. 부과적인 설명 없이 어떻게 해야하는지만 보여드리겠습니다.
그리고 크게 Peter-Chen 표기법 / 까마귀 발 표기법 이 있으며 까마귀 발 표기법 중 IE 표기법이 실무에서 가장 많이 쓰입니다. 하지만 전 이번에 흔히 대학교에서 배우는 Peter-Chen ERD 표기법으로 설명하겠습니다.
개념적 모델링
요구사항을 보고 ERD를 그려야 합니다.
다음 요구사항을 보고 ERD를 그리겠습니다. 설명을 위해 부족한 요구사항을 들고 왔습니다. 실제로 실무에서는 요구사항 명세서가 최소 몇백장이 된다고 하지만 배우는 입장에서 짧은 요구사항으로 약간의 변형을 하며 만들어보겠습니다. 정답은 없으므로 이런 느낌으로 하는 거구나 라고 생각하셨으면 좋겠습니다.
요구사항
항공사의 예약 데이터베이스는 비행기와 승객 예약에 대한 데이터를 저장한다.
우선 보유하고 있는 비행기의 기종,엔진종류,생산 연도,좌석 수에 대한 정보가 있다.
또한 스케쥴이 잡힌 각 비행기에 대해 출발지와 도착지 및 일시를 알 수 있다.
각 비행기에 대해서는 중간 기착지 없이 하나의 출발지와 도착지에 연결되는 것으로 가정한다.
출발지와 도착지는 공항 이름,국가,도시이름,인구에 대한 정보가 있다.
각 승객은 이름,성별,전화번호 및 좌석, 흡연 여부, 마일리지를 알 수 있고 각 승객은 복수 예약이 가능하며 예약을 취소할수도 있다.
1단계: 개체 집합 정의
먼저 개체로 표현되는 것 부터 빨간줄로 표시하였습니다.
항공사의 예약 데이터베이스는 비행기와 승객 예약에 대한 데이터를 저장한다.
우선 보유하고 있는 비행기의 기종,엔진종류,생산 연도,좌석 수에 대한 정보가 있다.
또한 스케쥴이 잡힌 각 비행기에 대해 출발지와 도착지 및 일시를 알 수 있다.
각 비행기에 대해서는 중간 기착지 없이 하나의 출발지와 도착지에 연결되는 것으로 가정한다.
출발지와 도착지는 공항 이름,국가,도시이름,인구에 대한 정보가 있다.
각 승객은 이름,성별,전화번호 및 좌석, 흡연 여부, 마일리지를 알 수 있고 각 승객은 복수 예약이 가능하며 예약을 취소할수도 있다.
우선 개체라는 것은 현실적으로 존재하는 개별적으로 식별할 수 있는 것을 말하는데
비행기, 승객이 눈에 띕니다. 따라서 빨간줄로 표시하였습니다. 스케줄 역시 개별적으로 출발지와 도착지 일시를 알수 있게 하므로 개체라고 생각하겠습니다.
이제 속성이 필요합니다. 찾은 개체에 속성을 부여하겠습니다. 파란줄로 표시합니다.
항공사의 예약 데이터베이스는 비행기와 승객 예약에 대한 데이터를 저장한다.
우선 보유하고 있는 비행기의 기종,엔진종류,생산 연도,좌석 수에 대한 정보가 있다.
또한 스케쥴이 잡힌 각 비행기에 대해 출발지와 도착지 및 일시를 알 수 있다.
각 비행기에 대해서는 중간 기착지 없이 하나의 출발지와 도착지에 연결되는 것으로 가정한다.
출발지와 도착지는 공항 이름,국가,도시이름,인구에 대한 정보가 있다.
각 승객은 이름,성별,전화번호 및 좌석, 흡연 여부, 마일리지를 알 수 있고
각 승객은 복수 예약이 가능하며 예약을 취소할수도 있다.
비행기(기종,엔진종류,생산연도,좌석수)승객(이름,성별,전화번호,좌석,흡연여부,마일리지)스케줄(출발지,도착지,일시)
로 표현을 했는데 공항이름,국가,도시이름,인구를 어디에 표시를 할지 난감해집니다.
이 속성은 출발지와 도착지의 속성으로 볼수도 있습니다. 하지만 중복된 테이블을 두개 만들수도 있지만 저의 경우에는 두가지 테이블의 공통점인 공항이라는 개체를 새롭게 만들었습니다.
공항(공항이름,국가,도시이름,인구)
다시 체크해보겠습니다 비행기와 승객 그리고 공항에 구별할수 있는 번호 속성도 추가하겠습니다. 또한 스케줄의 출발지와 도착지 속성은 공항을 나타내므로 지우겠습니다.
비행기(비행기번호,기종,엔진종류,생산연도,좌석수)
승객(승객번호,이름,성별,전화번호,좌석,흡연여부,마일리지)
스케줄(출발일시)
공항(공항번호,공항이름,국가,도시이름,인구)
위에서 도출된 각 개체집합을 개체관계 다이어그램으로 1단계를 표현하였습니다.
2단계: 개체집합 간 관계 형성
다음으로 개체들 간의 관계를 결정해야 합니다. 요구사항을 보면 다음과 같은 관계가 형성될 수 있습니다.
● 스케줄은 비행기를 배정한다.
● 스케줄은 출발지와 도착지를 정할 수 있다.
● 승객은 스케줄을 예약한다.
스케줄이 약성 개체 집합이냐(기본키가 없어 강성개체집합에 의존하는 개체) 고민이 있었는데 스케줄이 비행기와 출발지공항 그리고 도착지공항이 각각 하나씩 필요하므로 약성개체집합으로 그릴수 있습니다. 하지만 아직 배정되지않은 비행기 혹은 출발지 혹은 도착지가 있지만 스케줄에는 표시될수도 있기 때문에 약성개체집합으로 하지 않았습니다.
해당 관계에 대해 설명하면 하나의 스케줄은 하나의 비행기만을 배정할수 있지만 하나의 비행기는 여러개의 스케줄에 포함될수 있습니다.
하나의 스케줄은 출발지 공항을 하나만 배정하지만 공항은 여러개의 스케줄에 포함될수 있습니다. 마찬가지로 하나의 스케줄은 도착지 공항을 하나만 배정하지만 하나의 공항은 여러개의 스케줄에 포함될수 있습니다.
하나의 스케줄은 여러명의 승객을 배정할수 있습니다 또한 한 승객은 여러개의 스케줄을 예약할 수 있습니다.
3단계: 완성된 개체관계 다이어 그램
이로서 다이어그램을 완성을 하게되었습니다.
논리적 모델링
1단계: 강성개체집합=>테이블로 변환합니다.
비행기(비행기번호, 기종, 엔진종류, 생산연도, 좌석수)
스케줄(출발일시)
승객(승객번호, 전화번호, 성별,마일리지,흡연여부,이름,좌석)
공항(공항번호,공항명,인구,국가,도시명)
2단계: 약성개체집합=>테이블로 변환합니다.
현재 이 다이어그램에는 없으므로 할 필요가 없습니다.
3단계: 관계집합=>테이블로 변환합니다.
관계된 테이블들의 기본키와 관계의 속성을 조합해서 만듭니다
예약(승객 번호, 출발일시)
배정(비행기번호,출발일시)
출발지(출발일시,공항번호)
도착지(출발일시,공항번호)
4단계: 테이블의 중복과 결합
- 약성개체집합이 있는 경우 강성과 약성사이의 관계테이블은 중복이 발생하므로 생략해도 무방합니다.
- 다대일관계를 갖는 테이블에서 생기는 관계 테이블 생략하고 외래키를 추가합니다.
1. 스케줄과 비행기 사이의 배정관계집합을 생략하고 스케줄에 비행기번호의 외래키를 추가합니다.
스케줄(출발일시,비행기번호)
2. 스케줄과 공항 사이의 출발지와 도착지 관계집합을 생략하고 스케줄에 출발지공항번호,도착지공항번호의 외래키를 추가합니다.
스케줄(출발일시,비행기번호,출발지공항번호,도착지공항번호)
5단계~
다중값속성변환, 복합속성변환, 일반화관계의 변환의 단계가 추가적으로 필요하지만 이번 다이어그램에는 포함되지 않습니다.
최종 테이블 스키마
비행기(비행기번호, 기종, 엔진종류, 생산연도, 좌석수)
승객(승객번호, 전화번호, 성별,마일리지,흡연여부,이름,좌석)
스케줄(출발일시,비행기번호,출발지공항번호,도착지공항번호)
공항(공항번호,공항명,인구,국가,도시명)
예약(승객 번호, 출발일시)
'공부방 > 데이터베이스' 카테고리의 다른 글
| 말만 들어도 어려워 보이는 트랜잭션에 대해 자세히 살펴보자 3편 (0) | 2023.06.02 |
|---|---|
| 말만 들어도 어려워 보이는 트랜잭션에 대해 자세히 살펴보자 2편 (0) | 2023.05.30 |
| 말만 들어도 어려워 보이는 트랜잭션에 대해 자세히 살펴보자 1편 (0) | 2023.05.22 |