DB 설계의 단계
- 개념적 설계
- 논리적 설계
- 물리적 설계
개념적 설계
기업이나 조직은 운영에 필요한 자료들을 DB에 모아둡니다.
그러한 자료들을 효과적으로 보관하기위해 DB 설계가 필요합니다.
개념적 설계 단계에서는
어떠한 데이터가 저장되어야 하는지,
저장된 데이터를 어떻게 그룹화 할 것인가에 대해 결정합니다.
예를들어 은행 DB를 설계를 한다고 가정합니다.
그러면 어떠한 데이터가 저장되어야 할까요.
고객 이름, 고객 계좌번호, 고객 전화번호, 기업 이름, 기업 계좌번호, 고객센터 직원 이름 등 아주 다양한 데이터가 저장 될 것입니다.
이러한 속성들은 DB 설계자가 아닌 고객(클라이언트)가 제공하는 정보입니다.
고객(클라이언트)가 제공하는 정보를 요구 명세서(specification of user requirements)라고 합니다.
그럼 어떻게 그룹화를 해야할까요.
고객정보로 그룹화를 해서 <고객 이름>, <고객 계좌번호>, <고객 전화번호> 로 그룹화를 하는것이 좋을까요
아니면 계좌번호로 그룹화를 해서 <고객 계좌번호>, <기업 계좌번호>, <가상 계좌번호> 로 그룹화를 하는것이 좋을까요
이러한 문제를 해결하기 위해 개체-관계 모델(e-r model)과 정규화(nomalization)를 이용합니다.
위 과정을 모두 완료하여 나온 결과물을 개념적 스키마라고 합니다.
개념적 스키마는 기능 요구사항 명세서를 잘 만족하는지 검토하여야 합니다.
기능 요구사항 명세서는 DB에 사용될 기능들을 적어놓은 명세서입니다.
예를들어 ‘고객이 보유한 계좌의 목록을 출력해주는 기능’, ‘고객의 전화번호를 수정하는 기능’ 등을 모아놓은 명세서입니다.
논리적 설계
논리적 설계는 개념적 스키마를 바탕으로 DB에 적용(?)할 수 있게 설계하는 것을 말합니다.
예를들어 고객이름, 고객 계좌번호, 고객 전화번호가
각각 어떤 자료형을 가질지를 정하고,
각각 어떤 제약조건을 가질지,
기본키는 어떻게 할지,
다른 테이블과의 관계는 어떻게 되는지 등을 설계하는 단계입니다.
위의 개념적 스키마를 논리적 스키마로 변환한 모습입니다.
기본키, 제약조건 등은 안적긴 했지만, 개념적 스키마와 논리적 스키마의 차이점을 확인할 수 있다고 생각합니다.
논리적 설계가 필요한 이유가 무엇일까요.
대학교 과제로 DB를 선정해서 과제를 하는게 있었습니다.
논리적 설계를 하기 귀찮아서 구현부터 다 하고, 결과물에서 논리적 설계를 뽑아내려고 했었습니다.
구현을 하면할수록 테이블 간의 관계가 많아지고 그로인해 구현하면서 정했던 기본키를 계속 바꾸게 되고,
자료형도 수시로 바꾸게 되는 경험을 하였습니다.
이러한 경험으로 볼 때, 제대로 설계를 하지않고 구현을 하게되면 시간을 필요이상으로 소모하게 될 수 있습니다.
또한 위 사례는 혼자서 하였기 때문에 시간이 오래 걸린 선에서 그쳤지만 작업을 여러명이서 하게 된다면, 설계단계 없이 임의로 정하면서 구현하는것은 불가능할거라고 생각이 됩니다.
물리적 설계
모름.
대충 논리적 설계를 바탕으로 물리적 설계를 한다.
물리적 저장장치에 어떻게 저장할 지,
또 어떻게 해야 접근이 빠를지를 설계한다는 것 같음.
말고는 잘 모름. 내가 설명할 수준이 안됨.