문헌데이터베이스론 과제 레포트 - 데이터베이스 설계 과정 단계별 설명하시오.

I. 서론

동아리 회원 명단을 엑셀 한 장에 적을 때는 데이터베이스 설계가 거창하게 느껴질 수 있다. 이름, 전화번호, 가입일을 열로 만들면 금방 끝난다. 그런데 회원이 빌린 물품, 반납일, 연체 여부, 행사 참가 기록까지 한 시트에 붙이기 시작하면 같은 이름이 여러 번 나오고 한 곳을 고쳐도 다른 줄에는 옛 정보가 남는다. 데이터베이스 설계는 이런 혼란이 커지기 전에 정보의 종류와 관계를 정리하는 과정이다. 잘 설계된 데이터베이스는 자료를 저장할 뿐 아니라 잘못된 중복을 줄이고 필요한 질문에 빠르게 답할 수 있게 한다. 설계 과정은 보통 요구사항을 이해하고 개념을 정리한 뒤 논리 구조로 옮기고 실제 저장환경에 맞추는 흐름으로 이어진다.

II. 본론

1) 화면을 만들기 전에 묻는 요구사항과 개념 구조

설계의 출발점은 요구사항 분석이다. 데이터베이스를 만들 사람보다 실제로 데이터를 쓰는 사람이 무엇을 해야 하는지 알아내는 단계다. 도서 대출 시스템을 예로 들면 "책 정보를 저장한다"만으로 부족하다. 같은 책의 복본을 구분해야 하는지, 회원은 한 번에 몇 권까지 빌리는지, 예약 순서는 어떻게 관리하는지, 분실 자료는 어떤 상태로 남기는지, 회원 탈퇴 뒤 대출기록을 얼마나 보관할지 같은 질문이 필요하다. 요구사항을 건너뛰고 테이블부터 만들면 나중에 규칙이 바뀔 때 구조를 크게 고쳐야 할 수 있다.

요구사항은 기능 요구와 데이터 요구로 나누어 생각하면 편하다. 기능 요구는 등록, 검색, 수정, 대출, 반납, 통계 출력처럼 시스템이 해야 할 행동이다. 데이터 요구는 그 행동에 필요한 정보가 무엇인지 묻는다. 대출을 처리하려면 회원번호, 자료 식별값, 대출일, 반납예정일 같은 값이 필요하다. 예약을 관리하려면 순서를 기록할 값이 필요할 수 있다. 여기서 중요한 점은 화면에 보이는 항목과 데이터베이스에 저장해야 하는 항목이 항상 같지 않다는 사실이다. 화면에는 회원 이름이 보여도 내부 연결에는 이름보다 고유 회원번호를 쓰는 편이 안전하다.

요구사항을 모을 때는 현재 업무만 보지 말고 예외 상황도 확인해야 한다. 책 한 권을 여러 사람이 예약하면 어떻게 되는지, 회원 연락처가 바뀌면 과거 대출기록에는 어떤 영향이 있는지, 같은 ISBN을 가진 복본은 어떻게 구분할지 같은 질문이 구조를 바꾼다. 현장에서는 정상 흐름보다 예외가 문제를 만든다. 담당자 인터뷰, 기존 서식, 업무 규정, 실제 데이터 샘플을 함께 살펴보면 말로 설명할 때 빠진 규칙을 찾기 쉽다. 요구사항 문서는 개발자만 읽는 기술문서가 아니라 사용자와 합의하는 기준이어야 한다.

개념적 설계에서는 현실의 대상을 개체, 속성, 관계로 정리한다. 도서관 사례라면 회원, 서지자료, 소장자료, 대출, 예약 같은 개체를 생각할 수 있다. 회원에는 회원번호와 이름 같은 속성이 있고, 소장자료에는 등록번호와 위치, 상태가 붙는다. 회원과 소장자료는 대출이라는 관계로 연결된다. 이런 구조를 그림으로 나타낼 때 개체 관계 다이어그램을 많이 쓴다. 프로그램 코드나 특정 데이터베이스 제품보다 업무 세계의 구조를 먼저 표현하는 단계다.