도서 정보 제공 웹 서비스 - 스키마 설계

 데이터베이스는 여러 의미 있는 값을 지닌 기록들인 데이터를 관련 있게 모아놓은 것을 말한다고 한다.

데이터베이스를 배우기 전까지는 나는 파일의 형태로밖에 데이터를 다루지 못했다.

가령 성적을 입력하면 평점과 이수 학점을 보기좋게 계산해서 DOS창에 일일이 수작업으로 GUI를 구성하여 출력하는

C 프로그램을 제작했던 경험이 있는데, 이 프로그램의 문제는. txt 파일의 형태로 데이터를 기록하다 보니

당연히 띄어쓰기가 잘못되거나, 파일의 경로가 달라지거나, 이름이 같은 사람에 대해서는 서비스를 제공할 수 없다거나...

 

 

 

 

 

 

 

 데이터를 체계적으로 관리할 수 없었다는 것이었다. 때문에 프로그램의 규모가 상당히 작아질 수밖에 없었다.

그러나, 데이터베이스와 DBMS에 대한 공부를 하면서 이제 실전에 적용할 수 있겠다는 생각이 들었다.

 

 

 

 

 

 

 

 기본키니, 외래 키니, 복합 질의, 제약조건, 스키마 등등... 데이터베이스를 공부한 것을 복습할 겸

다가오는 겨울방학에 스프링 프레임워크와 마이 바티스 프레임워크를 익히기 위해 JSP, Servlet을 복습할 겸

해서 어떤 웹 서비스를 구현할 것인지를 고민했다.

 

 

 

 

 

 

 

 

웹 서비스가 제공하는 기능은 대략적으로 아래와 같이 결정하였다.

 

1 - 로그인, 로그아웃, 회원 가입, 탈퇴 등의 계정 사용 및 관리 기능을 제공하는 서비스

2 - 다른 사람들과 의견을 주고받을 수 있도록 게시판, 쪽지, 문의 등등의 커뮤니티 기능을 제공하는 서비스

3 - 앞선 부가서비스 외에 실용적인 주 서비스를 제공하는 서비스

4 - 마지막으로 사용자 계정 외에 체계적으로 설계된 객체를 다루는 서비스

 

 

 

 

 

 

 

상기된 서비스를 모두 제공할 수 있는 웹 서비스에는 멜론이나 벅스 같은 음악과 관련된 웹 서비스

에브리타임과 같이 다른 학생들과 게시판, 쪽지를 통해 소통하면서 동시에 자신의 성적을 관리할 수 있는 웹 서비스

등등 여러 가지 서비스들이 있을 수 있다.

 

 

 

 

 

 

 

 

 그러나, 최근에 책을 구매하고 읽으면서 문득 책과 관련된 서비스를 구현해봐야겠다는 생각이 들었다.

4가지 기능을 모두 제공하면서 동시에 책이라는 것이 얼마나 체계적으로 구성된 존재인지를 깨달았다.

가령 ISBN 번호, 출판사, 정가, 저자, 리뷰, 대여, 대출, 중고거래 등등... 책을 주제로 서비스를 구성한다면

얼마나 많이 체계적으로 데이터베이스를 설계하고, 이를 적절하게 활용할 수 있을까?

 

 

 

 

 

 

 

 

 그래서 아래와 같은 미니월드를 작성해보았다. 쉽게 말하면 해당 웹서비스의 요구 조건이라고 할 수 있다.

 

 

 

관리자 요구사항
1. 책, 출판사를 새로 등록할 수 있다.
2. 고객들의 대출정보를 조회할 수 있다.
3. 대출기간이 지난 대출에 대하여, 해당 대출자에게 반납 독촉 알림을 보낼 수 있다.
4. 관리자는 고객센터에 고객이 남긴 문의에 대해 답변을 할 수 있다.
5. 관리자는 고객의 악의적인 문의, 리뷰 등에 대하여 삭제할 권한이 있다.

 

 

 

 

고객 요구사항
1. 고객은 어떤 책에 대하여, 해당 책이 1개 이상 이용 가능한 경우

   해당 책을 1개만 대출할 수 있다. 이때 연체된 책이 없어야 한다.

2. 고객은 자신이 대출한 책을 언제든지 반납할 수 있다.

3. 고객은 최대 3권의 책을 대출할 수 있다.
4. 고객은 각 대출에 대하여 대출 기간을 1회 연장할 수 있다.
5. 고객은 고객센터에 문의를 할 수 있다.
6. 고객은 해당 책에 대하여 리뷰와 평점을 남길 수 있다. 

   리뷰는 한 사람당 한 책에 대하여 한 번만 남길 수 있다. 리뷰 수정은 가능하다.
7. 고객은 다른 고객이나 관리자에게 메시지를 보낼 수 있다.
8. 고객은 송신, 수신 메세지를 조회할 수 있으며 자신이 송, 수신한 메세지를 자신의 메세지함에서 삭제할 수 있다.

 

 

 

 

 

 

 

 

 이는 어느 정도 뼈대를 만들어둔 것으로, 언제든지 세밀하게 조정될 여지는 있지만

대략 이렇게 구성됨을 보인다. 이에 대해 관계형 다이어그램을 구성하면 다음과 같다.

 

 

 

도서 정보 웹 서비스의 스키마 다이어그램

 

 

 

 한눈에 보기에도 상당히 복잡해 보인다. 우선 관계형 다이어그램을 작성하기 전에 당연히 엔티티 - 관계

다이어그램을 공책에 먼저 그림으로 그린 후에 작성했기 때문에 좀 더 체계적으로 구성할 수 있었다.

 

 

 

 

 

 

 

 각 릴레이션에서 기본키, 후보 키, 외래 키, 외래 키이자 기본키를 구성하는 키로 나타내었다.

이에 따라 데이터 타입을 잘 정의했으나, SYS_GUID( )함수로 RAW(16)형태의 데이터타입을 사용하는 애트리뷰트들은

아직 수정의 여지가 존재한다. 메시지나, 질문, 응답, 저자, 출판사의 ID는 사실 고유한 값이어야 하지만

SYS_GUID( )의 값은 정확하게는 중복이 발생할 수도 있고, 값을 1씩 증가시키면서 할당하는 것이 효율적일 것이란

생각이 들기 때문이다. 물론, 웹 서비스를 제작하면서 차근차근 어떤 식으로 이들에 대한 ID를 부여할 것인지

판단하고 결정할 것이다.

 

 

 

 

 

 

 

 가령, 저자나 출판사의 경우 이름이 같은 경우가 존재할 수도 있기 때문에, 이름을 기본키로 정하기엔 무리가 있고

그렇다고 해서 이름과 다른 애트리뷰트를 묶어 키로 사용하기에는 전화번호의 변경이 있을 수 있으므로

처음에는 GUID_SYS( )를 사용하려 했던 것인데, 막상 이를 키로 사용하려니 도대체 이 책의 저자의 GUID_SYS( ) 값이

어떤 것인지 동명의 저자들이 각자 쓴 책에 대한 정보가 데이터베이스에 아직 저장되지 않았다면

그들의 ID를 분간할 수 없기 때문이다. 어떤 식으로 해결해야 할지 좀 더 진지하게 생각해야겠다.