도서관 관리 시스템의 ER 모델링

도서관 시스템의 데이터베이스를 설계한다는 가정으로, E-R모델링을 발표하게 되었다.


E-R모델링이란, 

관계형데이터베이스의 모델링을 뜻하는 것으로,
데이터의 Entity(집합쯤으로 생각하면 된다)와
다른 Entity사이의 관계를 바탕으로
표현하는 모델링 방법이라고 할 수 있다. 

우리는 먼저 도서관의 주요 Entity로 도서와 회원을 잡았다.
주요 Entity로 도서와 회원을 잡은 이유는 도서관 시스템에서
가장 눈에 보이기 쉬운 실체이기 때문이다. 

눈에 보이기 쉬운 실체란
가장 데이터베이스로 나타내야 해야할
집합쯤으로 생각되었기 때문이다.
(생각을 해보면 도서관 시스템에서 회원과 도서의 자료가
           데이터로써 존재하지 않는다면 말이 안된다) 

그리고 이를 바탕으로 대여라는 릴레이션을 기본으로 이를 Entity로 잡았다.  
대여라는 릴레이션(Entity와 Entity사이에서 생겨나는 관계로 인한 Entity와는 구별되는 개념)을
그냥 릴레이션으로 두지 않고 Entity로 해 본 까닭은 원래 예약이라는 시스템의 한 업무 때문이었다.
이 업무가 기본적으로 대여라는 릴레이션과 관계를 맺게 되는데,
이 대여라는 릴레이션에서 다시 예약이라는 릴레이션과의 관계를 설정하게 되면,
대여라는 릴레이션의 PK 즉 도서번호와 회원번호를  자신의 PK로 잡아버리고
그러면 예약이라는 시스템에서 다시 PK로 회원의 회원번호를 잡지 못하기 때문에(제 3정규화 위배)
릴레이션으로 두지 않고 Entity로 만들어 버린 것 이었다.
이것은 사실 좋은 결과를 낳긴 했지만 우리 의도했던 봐와는 좀 다른 긍정적인 의도를 낳았다.


아래는 우리조가 최종적으로 발표한 Enwin이라는 프로그램을 사용하여 도식화한 E-R 다이어그램이다.  

하지만 아래의 E-R다이어그램은 몇 가지 지적사항이 있으니 이 점 분명히 하고 넘어간다.

먼저 다른 것 보다 보고 넘어가야 될점 몇가지만 적겠다.

먼저  대여를 릴레이션으로 끝내지 않고 Entity로 끄집어 낸 것 이었다.

물런 우리의 의도와는 다른 부분으로 칭찬을 들었다. 대여라는 릴레이션은 사실 도서관의 모든 업무의 중심이 되는 릴레이션으로

이것을 릴레이션으로 끝내기 보다는 Entity로 관리해야 효율적인 측면에서 더 효과적이라고 하셨다.

(우리는 원래 예약때문에 Entity로 끄집어 낸것이었는데...)

 

그리고 또 한가지 기억해두고 넘어가야 될 것은

대여를 릴레이션으로 나두었을 경우 PK는 도서의 도서번호와 회원의 회원번호만으로 끝내면 안된다는 것이다.

여기에 반드시 대여일시를 추가해줘야 된다.

나도 처음엔 이 생각을 못했는데, 곰곰히 생각해보면 왜 대여일시가 들어가야 되는지 알 수 있었다.

생각을 해보자 대여라는 릴레이션도 집합이다. 집합에서 한 튜플은 유일한 PK로 식별 가능해야한다.

그런데 대여일시가 없다고 쳤을 때, 같은 회원이 같은 도서를 빌렸다가 반납했다가 다시 빌리면

그 2개의 튜플을 무슨수로 식별하겠는가. 이 2개의 튜플을 식별하기 위해 대여일시가 PK에 포함 되어야 하는 것이다.

이번엔 중요한 도서 Entity에 관한 것인데, 우리는 도서관의 같은 책(책 이름이 똑같고, ISBN이 똑같은 책)이 있다는 가정하에

모델링을 했음에도 불구하고, 이것을 효율적으로 못한 모델링을 한 표본이 되고 말았다.

왜냐하면 도서번호로 분명 같은 책의 구분은 가능할지 몰라도,

똑같은 자료를 중복하게 되, 결과적으로 데이터공간을 낭비하는 결과를 초래하기 때문이다.

다시 말하면 도서관의 실제도서를 나타내는 Entity와

실제도서의 속성을 정의하는 Entity를 구분해야된다는 말이다.

그리고, 연체료. 우리조는 데이터베이스만으로 연체료를 계산할수 있음을 알고 있었다.

(대여라는 Entity에 몇번 sql문을 던져주면 계산가능하다)

 

그러나 업무측면에서 보았을 때, 그것이 굉장히 비 효율적이라고 생각했다.

(연체료를 필요로 할 때마다 그것을 계산하기 위한 연산을 해야된다니..)

 

그렇지만 결과적으로는 우리가 잘못생각했다는 것이 교수님의 지적사항이었다.

연체료의 계산은 업무적인 측면에서 보는 것이지, 데이터베이스 설계적인 측면에서 보면 안된다는 것이었다.

솔직히 잘 이해는 안되었지만, 우리가 DBMS를 이용하는 이유는 수많은 질의를 제일 효율적인 방법을

사용해 사용자에게 답해주어서 라고 알고있다.

 

이것을 연결해서 교수님의 답변과 연결해보면

우리가 연체료라는게 필요해서 질의를 던지더라도 DBMS상에서 가장 효율적인 방법을 스스로 도출해 낸다는 것으로 이해했다.

그렇기 때문에 연체료라는 attribute는 DBMS의 존재이유를 무시하는 attribute이고, 또한 쓸때없는 데이터 공간을 낭비하는

그런 까닭에 연체료가 필요없는 것이라 이해했다.

이제 다시 예약이라는 Entity로 넘어가서. 우리의 다이어그램을 보면 예약이라는 Entity는 대여와 회원과 관계를 가지고 있다.

그렇지만 사실 직관적으로 생각했을 때 예약이라는 것은 도서-회원과의 관계가 맞다. 우리조가 이렇게 한 이유는

우리가 시스템을 정의 할 때, "예약은 대여한 도서에만 가능하다"라는 시스템 제약사항 때문이었다. 다시 말해서

대여라는 릴레이션의 종속적인 성격을 지녔다고 생각했기 때문이다. 그렇지만 결과적으로 이것 또한 우리조의 오류였다.

데이터베이스의 설계를 할 때는 직관적으로 쉽게 설계하라는 것이 교수님의 주문이었다. 다시 말해서 처음에 직관적으로

생각했을 때 도서-회원간의 관계로 예약의 관계를 맺는게 맞다는 말이다. 왜냐하면 우리의 시스템 제약사항도

응용어플리케이션 상에서 충분히 제어가 가능하기 때문에 모델링은 직관적으로 하는게 맞다는 말씀이었다.

사실 나도 교수님의 지적사항을 모두다 이해하지는 못했다. 몇몇 이해가 가는 부분도 있었으나, 그렇지 못한 부분도 있었다.

아래는 위의 다이어그램을 수정해 본 다이어 그램이다.

다시 몇가지 중요한 점만 짚고 넘어가면,

1. 도서(실제도서관에 있는책들)과 도서정보의 구분된 Entity

 - 이것은 불필요한 자료의 중복을 막는다. 도서관 관리시스템에서 구분되어야할 주요 Entity중 하나라고 할 수 있다.

 - 왜냐하면 같은 ISBN의 책이 도서관에 여러권 있을경우...도서명,저자,

    출판사 등 많은 자료들이 중복하게 나타나게 되어 자료의 중복을 가져온다.

 

2. 대여 Entity

 - 대여라는 것은 원래 도서와 회원사이에서 나타나는 릴레이션이다. 하지만 도서관 관리시스템에서 주된 업무이자,

    업무의 중심이 되기 때문에, 릴레이션으로 끝내지 않고 Entity로써 구분된 대여번호라는 PK를 선정함으로써

    효율 및 사용자의 편의를 제공했다고 할 수 있다.

 - 또 지난 포스트에서도 지적했지만, 대여라는 것을 릴레이션으로 나두었을 시

    이것의 PK는 도서번호와 회원번호 2개로 끝나면 안되고,

    반드시 대여일시가 포함되어 3개의 attribute로 설정해야 된다는 점 짚고 넘어가겠다.

 

3. 예약 Entity

 - 예약 Entity는 직관적인 관계로 재설정하였다. 다시 말하면 예약은 원래 도서와 회원간의 나타나는 릴레이션인데

   우리는 그것을 대여와 연결했었다. 하지만 직관적으로 연결하는게 설계적인 측면에서 옳다는 것이다.

   (사실 이 부분을 완전히 이해하지는 못한듯....하다)

 

4. 연체료

 - 원래 회원이라는 Entity에 연체료라는 Attribute를 추가했었는데, 삭제 하였다. 연체료라는 Attribute는

   사실 대여라는 Entity에서 DBMS를 통해 계산이 가능하기 때문에 DBMS에게 맡기는 것이 옳다는 것 같다