정규화
해당 릴레이션 스키마에 대한 정규화 시나리오에 대해 서술한다.
Last updated
해당 릴레이션 스키마에 대한 정규화 시나리오에 대해 서술한다.
Last updated
릴레이션에 속한 모든 속성의 도메인이 원자 값으로만 구성된 것이다. 이는 가장 기본적으로 지켜지고 있는 것이기 때문에 구성한 테이블에 대하여 부가적인 설명은 하지 않겠다.
제 2 정규형은 제 1 정규형을 만족하는 동시에 기본키가 아닌 모든 속성이 기본 키에 완전 함수 종속성을 만족해야 한다.
제 2 정규형 과정에서 가장 주목해서 봐야할 것은 building 테이블과 post 테이블이다. 가장 초기에 구성했던 post 테이블은 아래 그림과 같다.
초기의 post 테이블은 어느 건물에다 게시를 할지에 대한 정보를 함께 담으려고 했었다. 하지만, 테이블을 위와 같은 방법으로 구성하게 되면 문제가 발생한다. (건물코드, 게시글아이디)가 복합키로 다른 속성들을 유일하게 결정짓게 되는 것이다. 이러한 복합키의 속성 중 일부분인 '건물코드'가 건물명을 결정짓게 되며, '게시글 아이디'가 나머지 속성들을 결정 짓는다.
이러한 부분 함수적 종속성이 존재하기 때문에 아래의 그림과 같이 post와 building 테이블 2개의 테이블로 분할하였으며, 하나의 게시글이 여러 개의 건물에 등록될 수 있는 N:M 관계를 위하여 별도의 테이블을 따로 구성하였다.
제 3 정규형은 릴레이션이 제 2 정규형에 속하며, 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속성을 만족하지 않아야 한다.
초기의 post 테이블에서는 2-B 이미지처럼 '게시글 아이디' 속성과 '작성자' 속성이 나누어져 있지 않다. 사용자가 하나의 게시물만 작성할 수 있다는 가정을 정의하고 ERD를 구성하였기 때문이다. 하지만 이런 가정이 위험성을 초래할 수 있다는 것을 프로젝트 중 인식하게 되었다.
익명성을 보장하지 않는다 해도 게시글 아이디를 사용자 아이디로 하여 직접 데이터를 통신하는 것은 해당 사용자에 대한 정보가 유출될 가능성이 있으며, DB에서 검색을 수행할 때, 단순한 데이터 타입으로 연산을 수행함으로써 수행 속도를 높일 수도 있기 때문이다. 따라서, '게시글 아이디' 속성과 '작성자' 속성을 나누었다. 여기서 기본키인 '게시글 아이디'가 '작성자'를 결정하고 '작성자'가 다른 속성을 결정하는 이행적 함수 종속성이 해결되지 않는 것으로 판단될 수도 있다.
그러나 이러한 문제점을 우리들은 어플리케이션 서버단에서 불가능하도록 구현했으며, 현재는 하나의 사용자가 하나의 게시물만 쓸 수 잇는 1:1 관계이지만, 후의 사양 변경을 통해 확장성을 고려해 한 명의 사용자가 여러 개의 게시글을 작성할 수 있는 것으로 확장된다는 점을 고려하면 적절한 조치로 판단되었다.
요구사항을 바탕으로 설계한 세자보의 데이터베이스 스키마는 다음과 같다. 해당 ERD는 제 3차 정규화까지 적용시킨 상태이다. 1,2,3 정규화 과정을 통해 삽입,삭제,갱신 시 발생하는 문제점 및 부분 함수적 종속성을 모두 해결하였다.
Password : 07c450
