권순용의 데이터모델링 이야기
데이터 모델링의 단계 및 주의사항 0 1 7,062

by axiom 데이터모델링 [2014.04.01]


데이터 모델은 우리가 데이터를 사용하고 생성하는 동안에 항상 필요한 요소다. 이와 같은 데이터 모델을 어떻게 수행히는기에 따라 데이터의 운명과 삶이 결정되므로, 데이터 모델에 대해서는 항상 주의 깊게 관찰하고 수행해야 한다.

이번 시간부터는 데이터 모델링의 단계와 주의사항에 대해 실펴본다. 이후부터는 여기서 다뤄지는 내용들을 충분히 숙지해 모델링이 수행됐으면 하는 바람이다.

모델링의 단계

데이터 모델링의 단계는 다음과 같이 4개의 단계로 나누어 진다([그림1]참조).

  • 1. 요구사항 분석
  • 2. 개념 모텔
  • 3. 논리 모텔
  • 4. 물리 모텔

  • [그림1] 데이터 모델링의 4단계
  • 데이터 모델링의 4단계

개념 모델의 목표는 고객과의 합의도출이다. 개념모델이 사용된 것은 몇 년 되지 않는다. 근래에는 많은 프로젝트에서 개념 모델을 사용하고 있으나 그 가치에 대해서는 정확히 모르는 경우가 많다.

개념 모델을 고객과의 합의 없이 단지 논리 모델의 전 단계로 사용하는 것은 아쉬운 일이다.

개념 모델은 시스템에 대해 잘 모르는 업무 담당자와 의사소통하기 위해 사용하는 만큼, 기술적인 요소는 배제되고 철저히 업무적인 관점에서 진행돼야 한다.

개념 모델의 경우에 모든 속성이 도출될 필요 없이 특히 업무개념 모델의 경우에 모든 속성이 도출될 필요 없이 특히 업무 와 관련된 엔터티와 속성이 주요 요소가 된다. 개념 모델은 실제 업무와 가장 밀접한 표현 양식으로서의 가치를 가진다.

실제로 업무 담당자와의 의사소통 문제 등으로 인해 모델이 변경돼야 하는 경우에는 개념 모델부터 변경돼야 한다.

논리 모델은 DBMS가 배제된 논리적인 관점에서의 최종 데이터 모델이다. 실제 하나의 논리 모델은 성능, 물리적인 환경을 고려해 여러개의 물리 모델로 변환될 수 있다.

이와 같은 논리 모델은 개발자들에게도 필요하다. 논리 모델의 완료는 중복 데이터가 전혀 없는 정규화된 상태로 모든 구성 요소가 정의된 상태여야한다.

물리 모델의 관점은 구현 가능성과 목표 성능의 도달에 있다. 각종 물리적인 기법을 동원하며 반정규화도 수행한다.

물리 모델은 대부분 개발자들도 거의 안 보고 있는 것이 현실이다. 개발자 관점에서 업무를 가장 잘 설명할 수 있는 것은 물리 모델이 아닌 논리 모델이다.

하지만 실제 구현 작업 자체에서는 물리 모델이 필요하게 된다. 물리 모델에는 반정규화된 내용 이외에도 MVIEW, TRIGGER, VIEW, INDEX 등의 정보가 필요하다.

이러한 모델링 과정에서 예를 들면 물리 DBMS가 변경됐다고 가정하자. 논리 모델부터 출발하는 것이 맞을까? 아니면 물리 모델부터 출발하는 것이 맞을까?

현실적으로는 물리 모델을 용하지만, 일정 부분에서 논리 모델을 참조하는 부분은 반드시 발생하게 된다.

데이터 모델링의 고려사항

데이터 모델링 시 고려사항은 바로 데이터 모델링을 하는 목적 에 해당될 것이다. 그렇기 때문에 항상 데이터의 정합성과 성능 을 고려해야 한다([그림2]참조).

  • [그림2] 논리 모델과 물리 모델
  • 논리 모델과 물리 모델

데이터 정합성

PC에 동일한 파일을 여러 곳에 보관하게 되면 시간이 지나면서 각각의 파일들은 버전이 달라지게 되며 최신 파일을 찾기 어렵게 된다.

이와 같이 중복된 데이터가 존재한다면 시간이 지남에 따라 테이터 정합성이 위험해지며 정확한 최신의 테이터를 확인할 수 없게 된다.

성능

테이터 모델링 시 성능을 고려한 Entity, Attribute 및 Relationship 도출이 필요하다.

예를 들어. 거래내역 Entity에 제조사 Attribute가 존재한다고 가정하자. 해당 Attribute에는 제조사 이름이 입력돼 있다. 이와 같은 경우 제조사가 변경된다면 거래내역 Entity에서 제조사 이름을 변경해야 하며 대용량 테이블일 경우 많은 데이터에 대한 Update 작업으로 큰 성능 저하가 발생할 수 있게 된다.

이와 같은 현상을 해결하기 위해서는 제조사 이름의 값을 별도의 Entity 로 분리해 제조사 번호와 제조사 이름 값으로 구성하도록 하며 거래내역 Entity의 제조사 Attribute에는 제조사 번호로 데이터를 관리 한다.

별도의 Entity로 구성했을 경우 거래내역 데이터를 제조사 이 룸과 함께 보고자 할 경우에는 Join을 이용해야 한다. 물론 Join 수행 시 성능 저하가 발생할 가능성은 있다.

결국 데이터 모델링 시 데이터 정합성과 성능을 어떻게 배분하는가에 따라 최적의 데 이터 모델링이 될 수 있다.

- 강좌 URL : http://www.gurubee.net/lecture/2718

- 구루비 강좌는 개인의 학습용으로만 사용 할 수 있으며, 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

- 구루비 강좌는 서비스 제공을 위한 목적이나, 학원 홍보, 수익을 얻기 위한 용도로 사용 할 수 없습니다.

by 초보 개발자 [2017.07.31 16:31:15]

좋은 글 감사드립니다.

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입