1일차

데이터 모델링의 이해

모델링 : 현실 세계를 단순화 하여 표현

  ◆ 특징

  추상화 : 일정한 형식에 맞춰 표현함

  단순화 : 제한된 표기법이나 언어로 표현

  명확성 : 이해가 쉽게 표현됨

  ▸ 정리하자면 모델링 == ‘현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법’으로 정리

 

  ◆ 관점

  데이터 관점 : 업무가 어떤 데이터와 관련이 있는지 또는 데이터간의 관계는 무엇인지에 대해서 모델링하는 방법(What, Data) 

  프로세스 관점 : 업무가 실제하고 있는 일은 무엇인지 또는 무엇을 해 야 하는지를 모델링하는 방법(How, Process) 

  상관 관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받는지 모델링하는 방법(Interaction)으로 설명 될 수 있다.

◆ 데이터 모델링 : 정보 시스템 구축을 위한 데이터 관점의 업무 분석 기법

 

- 목적 : 정보에 대한 표기법을 통일하여 업무 내용 분석 정확도 증대 / 데이터 모델을 기초로 DB 생성

- 기능 : 1) 가시화 2) 명세화 3) 구조화 4) 문서화 5) 다양한 관점 제공 6) 구체화

- 중요성 

 1) 파급효과(Leverage) : 데이터 구조의 변경에 따른 프로젝트 리스크가 크다는 점

 2) 간결한 표현(Conciseness) : 간결하게 그려져 있는 데이터 모델을 통한 공유의 힘

 3)데이터 품질(Data Quality) : 유일성 / 유연성(데이터 정의와 실 사용프로세스 분리) / 일관성

 

◆ 데이터 모델링 3단계

 - 개념적 모델링 : 엔티티와 속성을 도축하여 ERD를 작성 

 - 논리적 모델링 : 물리적인 스키마 설계를 하기 전 단계의‘데이터 모델’상태 / Key, 속성, 정규화, 관계 등 데이터 모델링 완료 상태

 - 물리적 모델링 : DB를 구축함, 서능 및 보안 등 물리적 성격 고려

◆ 프로젝트 생명 주기에서의 데이터 모델링

- 계획 > 분석 > 설계 > 개발 > 테스트 > 전환/이행 

- 보통 계획 또는 분석 단계에서 개념적 모델링 / 분석 단계에서 논리적 모델링 / 설계단계에서 물리적 모델링

- 단, 객체지향 개념은 데이터와 프로세스 를 한꺼번에 바라보면서 모델링을 전개하므로 데이터 모델링과 프로세스 모델링을 구분하지 않고 일체형으로 진행(대표적인 예가 데이터(속성)와 프로세스(Method)가 같이 있는 클래스(Class))하게 된다.

 

◆ 데이터 모델링에서 데이터 독립성의 이해

- DB 독립성의 필요성 : 데이터 복잡도 증가로 인한 유지보수의 어려움 / 요구사항 대응 저하

 

- DB의 3단계 구조 (내부 - 개념 - 외부) for 데이터 독립성 ( <=> 데이터종속성 )

 

- 데이터 독립성 3단계

  ・ 외부단계 : 사용자(클라이언트) / 개인적 스키마 / 응용프로그램의 접근

  ・ 개념적 단계 : 조직 전체의 통합된 DB스키마 / 설계자 관점 / 데이터 모델링의 지향점

  ・ 내부 단계 : 물리적으로 데이터가 저장되는 방법을 표현하는 스키마, 개발자 관점, 물리적 저장 구조

  >  데이터 모델링은 통합관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정으로 이해할 수 있다.

 

- 두 영역의 데이터 독립성

  ・ 논리적 독립성 : 외부 스키마가 개념 스키마 변화에 무관 / 논리구조가 변경 되어도 응용 프로그램에 영향 없음

  ・ 물리적 독립성 : 내부 스키마가 변경되어도 외부,개념 스키마는 변화에 무관 /  개념구조 영향 없이 물리적 구조 변경 가능

 

◆ 사상(Mapping) : 상호 독립적인 개념을 연결시켜주는 다리

  ・ 외부적/개념적 사상 : 논리적 사상 / 외부 - 개념을 연결 / 

  ・ 개념적/내부적 사상 : 물리적 사상 / 개념 - 내부를 연결 / 

 

◆ 데이터 모델링의 3요소 : 엔티티(), 속성, 관계

- 실제 업무시스템을 구축하는 실전 프로젝트에서는 데이터베이스를 전문적으로 하는 이른바 DBA(DataBase Administrator)가 데이터 모델링을 전적으로 하는 예는 거의 없다. 오히려 업무시 스템을 개발하는 응용시스템 개발자가 데이터 모델링도 같이 하게 된다. 그 이유는 데이터 모델링 이라는 과정이 단지 데이터베이스를 설계한다는 측면보다 업무를 이해하고 분석하여 표현하는 것이 중요하고, 표현된 내용을 바탕으로 프로젝트 관련자와 의사소통하고 프로그램이나 다른 표기법과 비교 검증하는 일을 수행하는 등 많은 시간을 업무를 분석하고 설계하는데 할애하기 때문에 업무영역별 개발팀에서 보통 데이터 모델링을 진행하게 되는 것이다.
물론 시스템이 대형화되면 모델링만을 전문적으로 담당하는 모델러를 투입하여 진행하는 경우도 있지만 이와 같은 경우도 실제 모델링 작업은 응용개발을 하는 사람이나 업무분석가(역할분담이 잘 되어 있을 경우)가 담당하고 모델러나 DBA 는 정확하게 모델링이 진행될 수 있도록 교육하고 제시 하며 현안별로 직접 모델링을 진행하는 역할을 수행한다.
이와 같이 응용시스템을 개발하는 모든 시스템 엔지니어가 데이터 모델을 하거나 할 기회가 있음에 도 불구하고 대부분의 사람들은 데이터 모델에 많은 관심을 갖지 않고 단지 프로그램을 개발하기 위한 프로그래밍 언어(Programming Language)에만 많은 관심을 두고 애플리케이션을 개발하는 데에 훨씬 많은 시간을 투자하는 경우가 많다. 그러나 분명한 사실은 정보 시스템을 개발 한다고 할 때 데이터 모델링 데이터 베이스 구축 구축된 데이터의 적절한 활용은 다른 어떤 일(Task) 보다 중요하다는 점이다

 

◆ 데이터모델의 표기법 ERD 이해 (Entity Relationship Diagram)

 - 1) 엔터티는 사각형 2) 관계는 마름모 3) 속성은 타원

 - ERD 작업 순서

   엔터티 도출 > 엔티티 배치 > 엔티티 관계 설정 > 관계명 기술 > 관계 차수(Cardinality)(참여도) > 관계 선택 사양(필수, 선택)

 

◆ 좋은 데이터 모델링 요건

 - 완전성 : 필요한 데이터는 모두 데이터 모델에 정의 되어 있어야 함

 - 중복 배제 : 동일한 사실은 반드시 한 번만 기록

 - 업무 규칙 : 서로가 알아야 하는 데이터 간의 논리적 관계는 공유되어야 함

 - 데이터 재사용 : 통합 모델을 통한 데이터 재사용성 향상 , 데이터가 애플리케이션에 대해 독립적으로 설계

 - 의사소통 : 분석 과정에서는 자연스럽게 많은 업무 규칙들이 도출 >  데이터 모델을 통한 의사소통이 되어야 함

 - 통합성 : 동일한 데이터 > 공유 데이터