이론적인 내용이 굉장히 많네요. 그래도 한번쯤은 숙지할 필요가 있을 테니 꾹참고 공부해보겠습니다.(즐겨보겠습니다?)
데이터 베이스의 설계적 기법인 데이터모델을 이해하고
엔터티, 속성, 관계, 식별자에 대한 표현방법과 이것을 이용하여 표현하는 기술을 이해하도록 한다.
데이터 모델은 데이터베이스의 설계적 기법을 말합니다.
좀더 근본적이 용어부터 처리해봅시다. 모델이 무엇일까요? 모형, 축소형의 의미로서 사람이 살아가면서 나타날 수 있는 다양한 현상에 대해서 일정한 표기법에 의해 표현해 놓은 모형이라고 할 수 있습니다.
모델링은 커뮤니케이션의 효율성을 극대화하기위해 고급화된 표현방법으로 설명할 수 있습니다.
즉, 다양한 현상 또는 대상을 표기법에 의해 규칙을 가지고 표기하는 것 자체를 모델링이라고 합니다.
복잡한 현실세계를 일정한 표기법에 의해 표현하는 일
데이터 모델을 왜 이해해야할가요? 데이터베이스의 골격을 이해하고 그 이해를 바탕으로 SQL문장을 기능과 성능적인 측면에서 효율적으로 작성하기 위해서 입니다.
업무정보를 구성하는 기초가 되는 정보들을 일정한 표기법에 의해 표현함으로써 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하는 것이 첫번째 목적입니다.
시스템 구축이 완성되어가는 시점에서는 많은 어플리케이션이 테스트를 수행하고 대규모의 데이터 이행을 성공적으로 수행하기 위해 많은 단위 테스트 와 이어서 병행테스트, 통합테스트를 수행하게 됩니다.
만약, 이러한 시점에 데이터 모델의 변경이 불가피한 상황이 발생한다고 가정해보면 이를 위해서 데이터 구조의 변경에 따른 파급효과에 대해 생각해봐야합니다.
큰 시스템에서 데이터 구조의 변경으로 인한 일련의 변경작업은 큰 위험요소가 아닐 수가 없습니다. 이러한 이유로 시스템 구축 작업 중에서 다른 어떤 설계과정보다 데이터 설계가 더 중요하다.
정보 요구사항을 파악하는 가장 좋은 방법은 수많은 페이지의 기능적인 요구사항을 파악하는 것보다 간결하게 그려져 있는 데이터 모델을 리뷰하면서 파악하는 것이 훨씬 빠른 방법입니다. 데이터 모델을 건축물에 비교하면 건축물의 설계 도면입니다.
요구사항과 한계를 간결하고 명확하게 표현할 수 있어야합니다.
데이터 품질 기간이 오래될 수록 활용가치는 훨씬 높아진다. 그런데 이렇게 오래도록 저장되어진 데이터가 그저 그런 데이터, 정확성이 떨어지는 데이터라고 한다면 어떨까요? 데이터 품질 문제는 데이터 구조가 설계되고 초기에 데이터가 조금쌓일때는 인지하지 못하는 경우가 대부분입니다.
데이터 품질의 문제가 야기되는 중대한 이유 중 하나는 바로 "데이터 구조"의 문제이다.
중복 데이터의 미정의, 비즈니스 정의의 불충분, 동일한 성격의 데이터를 통합하지않고 분리함으로써 나타나는 데이터 불일치 등의 데이터 구조의 문제로 인한 데이터 품질의 문제는 치유하기에 불가능한 경우가 대부분이다.
데이터 모델링을 할 때 유의점은 다음과 같다.
데이터 모델은 데이터베이스를 만들어내는 설계서로서 분명한 목표를 가지고 있다.
실질적인 현실 프로젝트에서는 개념적 데이터 모델링 => 논리적 데이터 모델링 => 물리적 데이터 모델링
으로 수행하는 경우는 드물며, 개념적 데이터 모델링과 논리적 데이터 모델을 한꺼번에 수행하여 논리적인 데이터 모델링으로 수행하는 경우가 대부분이다.
추상화 수준이 높고 업무중식적이고 포괄적인 수준의 모델링을 진행합니다. 전사적 데이터 모델링(Enterprise), EA수립시 많이 이용
조직, 사용자의 요구사항을 찾고 분석하는데서 시작합니다. 이 과정에서 어떤 자료가 중요하며 어떠한 자료가 유지되어야하는지를 결정하는 것도 포함합니다.
핵심 엔터티와 그들관의 관계를 반경하고 그것을 표현하기위해 엔터티-관계 다이어그램을 생성합니다.
엔터티-관계 다이어그램은 조직과 다양한 데이터베이스 사용자에게 어떠한 데이터가 중요한지를 나타내기 위해 사용된다.
개념 데이터 모델을 통해 조직의 데이터 요구를 공식화하는 것은 두가지 중요한 기능을 지원한다.
첫째, 개념 데이터 모델은 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원한다. 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다.
둘째, 현 시스템이 어떻게 변형되어야하는가를 이해하는데 유용하다.
비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다.
논리 데이터 모델은 "데이터 모델링이 최종적으로 완료된 상태"라고 정의할 수 있다.
이 단계에서 수행하는 또 한가지 중요한 활동은 정규화이다. 정규화는 논리적 데이터 모델 상세화 과정의 대표적인 활동으로, 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 신뢰성 있는 데이터 구조를 얻는데 목적이 있다.
논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 다룬다.
어떤 단위에 대해 독립적인 의미를 부여하고 그것을 효과적으로 구현하게 되면 자신이 가지는 고유한 특징을 명확하게 할 뿐만 아니라 다른 기능의 변경으로부터 쉽게 변경되지않고 자신의 고유한 기능을 가지고 기능을 제고하는 장점을 가지게 된다.
데이터 독립성은 지속적으로 증가하는 유지보수 비용을 절감하고 데이터 복잡도를 낮추며 중복된 데이터를 줄이기 위한 목적이 있다.
데이터 독립성르 확보하게 되면 다음과 같은 효과를 얻을 수 있다.
ANSI/SPARC의 3단계 구성의 데이터 독립성 모델 외부단계와 개념적 단계, 내부적 단계로 구성된 서로 간섭되지않는 모델을 제시한다.
위 그림에서 View들이 있는 단계가 외부단계입니다. 사용자와 가까운 단계로 사용자 개개인이 보는 자료에 대한 관점과 관련이 있는 부분이다. 즉, 사용자가 처리하고자하는 데이터 유형에 따라, 관점에 따라, 방법에따라 다른 스키마 구조를 가지고 있습니다.
개념단계(Conceptual Schema)는 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 스키마 구조로 디자인한 형태입니다.
마지막으로 내부적 단계(Internal Schema)는 데이터가 물리적으로 저장된 방법에 대한 스키마 구조를 말한다.
데이터 모델링은 통합관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정으로 이해할 수 있다.
1) 업무가 관여하는 어떤 것(Thing)
2) 어떤 것이 가지는 성격(Attribute)
3) 업무가 관여한느 어떤 것 간의 관계(Relationships)
모든 유형의 정보들을 세가지 관점의 접근 방법을 통해 모델링을 진행하는 것이다.
실제 업무 시스템을 구축하는 실전 프로젝트에서는 데이터베이스를 전문적으로 하는 이른바 DBA(Database Administrator)가 데이터 모델링을 전적으로 하는 예는 거의없다. 오히려 업무 시스템을 개발하는 응용시스템개발자가 데이터 모델링도 같이 하게 된다. 그 이유는 데이터 모델링이라는 과정이 단지 데이터베이스를 설계한다는 측면보다 업무를 이해하고 분석하여 표현하는 것이 중요하기 때문.
즉, 정보시스템을 구축하는 모든 사람은 데이터 모델링도 전문적으로 할 수 있거나 적어도 완성된 모델을 정확하게 해석할 수 있어야한다.