[J STORY] SQLP - 데이터 모델링의 이해2

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

 가. 데이터 독립성의 필요성

  1. 데이터 독립성 필요

    - 유지보수 비용 증가

    - 데이터 중복성 증가

    - 데이터 복잡도 증가

    - 요구사항 대응 저하

 

 나. 데이터베이스 3단계 구조

  1. 외부스키마 : View 단계, 여러 개의 사용자 관점으로 구성, 즉 개개 사용자 단계로서 개개 사용자가 보는 개인적 DB 스키마 - DB의 개별 사용자나 응용프로그래머가 접근하는 DB정의

 

  2. 개념스키마 : 개념단계, 하나의 개념적 스키마로 구성, 모든 사용자 관점을 통합한 조직 전체의 DB를 구성하는 것 - 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들간의 관계를 표현한 스키마

 

  3. 내부스키마 : 내부단계, 스키마로 구성, DB가 물리적으로 저장된 형식 - 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마

 

 라. 두 영역의 데이터 독립성

  1. 논리적 독립성 : 개념스키마가 변경되어도 외부스키마에는 영향을 미치지 않도록 지원하는 것 - 논리적 구조가 변경되어도 응용프로그램에 영향 없음

    - 특징 : 사용자 특성에 맞는 변경 가능, 통합 구조 변경 가능

  

  2. 물리적 독립성 : 내부스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것 - 저장장치의 구조변경은 응용프로그램과 개념스키마에 영향 없음

    - 특징 : 물리적 구조 영향 없이 개념구조 변경 가능 - 개념구조 영향 없이 물리적 구조 변경 가능

 

 마. 사상(Mapping)

  1. 외부적/개념적 사상(논리적 사상)

    - 외부적 뷰와 개념적 뷰의 상호 관련성을 정의함

    - 사용자가 접근하는 형식에 따라 다른 타입의 필드를 가질 수 있음, 개념적 뷰의 필드타입은 변화가 없음

 

  2. 개념적/내부적 사상(물리적 사상)

    - 개념적 뷰와 저장된 데이터베이스의 상호 관련성을 정의함

    - 저장된 데이터베이스 구조가 바뀐다면 개념적/내부적 사상이 바뀌어야 함,  개념적 스키마가 그대로 남아있게 됨

 

 

7. 데이터 모델링의 중요한 세 가지 개념

 가. 데이터 모델링의 세 가지 요소

  - 업무가 관여하는 어떤 것(Things)

  - 어떤 것이 가지는 성격(Attributes)

  - 업무가 관여하는 어떤것 간의 관계(Relationships)

 

 나. 단수와 집합(복수)의 명령

세 가지 요소

 

8. 데이터 모델링의 이해관계자

 가. 이해관계자의 데이터 모델링 중요성 인식

  1. 대부분의 기업에 있어서 정보시스템의 데이터베이스 구조는 사용자에게 숨겨진 형태로 구축되어 왔다.

     -> 정보의 고립화

 

  2. 프로그램은 6가지 유형의 데이터베이스 유지절차, 정보 검색, 보고서 산출, 분석/통계 보고서 산출, 비정규 조회

 

 나. 데이터 모델링의 이해관계자

  1. 프로젝트 개발자

  2. DBA

  3. 데이터모델링 기술/이해

  4. 현업업무전문가

  5. 전문 모델러

 

 

9. 데이터 모델링의 표기법인 ERD의 이해

 가. 데이터 모델 표기법

데이터 모델 표기법

 

 나. ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법

  1. ERD 작업순서

• 1. 엔터티를 그린다.
• 2. 엔터티를 적절하게 배치한다.
• 3. 엔터티간 관계를 설정한다.
• 4. 관계명을 기술한다.
• 5. 관계의 참여도를 기술한다.
• 6. 관계의 필수여부를 기술한다.

  2. 엔티티 배치

• 좌에서 우로, 위에서 아래로
• 가장 중요한 고객과 주문을 좌측 상단에 배치
• 주문에 따른 출고 및 재고 를 주문의 아래에 차례로 배치
• 업무 흐름의 중심이 되는 엔터티(주문, 출고, 주문목록, 출고목록)를 중앙에 배치
• 중심 엔터티와 관계있는 엔터티(창고, 고객, 사원, 재고)를 주위에 배치

  3. ERD 관계의 연결

• 서로 관련있는 엔터티간의 관계를 설정
• 초기에는 모두 PK 로 속성이 상속되는 식별자 관계를 설정
• 중복관계, Cycle 관계 등을 유의

  4.

• 관계이름은 현재형을 사용
• 지나치게 포괄적인 용어(예, 이다, 가진다 등)은 사용하지 않도록
• 실무에서는 생략해도 무방 - 관계명이 없어도 ERD의 흐름을 알 수 있다.

  5. ERD 관계 관계차수와 선택성 표시

표기법

 

10. 좋은 데이터 모델의 요소

 가. 완전성(Completeness)

• 업무에서 필요로 하는 모든 데이터가 모델에 정의되어 있어야 한다.

 나. 중복배제(Non-Redundancy)

• 하나의 데이터베이스에 동일한 사실은 반드시 한번만 기록되어야 한다.
• 중복시 문제점
  • 저장공간의 낭비
  • 일관성 유지를 위한 추가 비용 발생

 다. 업무규칙(Business Rules)

• 업무규칙(Business Rules)을 데이터 모델링에 표현하고, 모든 사용자가 공유한다.
• 모든 사용자(개발자, 관리자)가 해당 규칙에 대해 동일하게 판단하고 데이터를 조작할 수 있게 된다.
• 업무규칙이 명확하게 표현되지 않았다면
  • 각각의 사용자가 같은 업무를 다르게 판단 할 수 있다.

 라. 데이터 재사용(Data Reusability)

• 통합성
  • 과거 시스템은 각각의 업무 영역별 데이터 별도 관리
  • 전사적 관점에서 공통데이터를 도출하고 이를 전 영역에서 사용하기 적절한 형태로 설계하여야 한다.
  • 이러한 통합 데이터 모델이어야 데이터 재사용성을 향상시킬 수 있다.

• 독립성
  • 과거 시스템은 데이터 모델이 별도로 없이 어플리케이션의 부속품 정도로 여겨졌다.
  • 이경우 데이터는 각각의 업무 프로세스에 종속적일수밖에 없고
  • 중복데이터 발생, 일관성 저하, 재사용성이 떨어지게 된다.
  • 따라서 데이터가 어플리케이션에 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다.

• 확장성, 유연성
  • 정보시스템은 비즈니스 변화에 대해 최적의 적응을 요구한다.
  • 비즈니스 변화에 유연하게 대처하고 확장이 용이한 데이터 설계가 필요하다
  • 확장성, 유연성이 떨어질 경우 작은 업무 변경에도 시스템 기반이 흔들리게 된다.

• 합리적 균형이 있으면서도 단순하게 분류하는 것
  • 예를 들면, 동일한 계약 업무를 수행하기 위한 테이블이 A보험사는 10개, B보험사는 100개라면?
  • A사의 데이터 모델은 단순하지만 새로운 업무환경 변화에 대해서 확장성을 가지고 있다.
  • B사는 업무환경 변화(신규상품출현 등)에 적응하지 못하고 데이터 모델의 한계로 테이블 갯수를 늘려왔다.
  • 간결한 모델의 전제조건은 통합.

 마. 의사소통(Communication)

• 데이터 모델은 대상 업무를 데이터 관점에서 분석하고 설계하여 나오는 최종 산출물이다.
• 분석과정에서 도출되는 수많은 업무 규칙들은 최대한 자세하게 표현되어야 한다.
• 모든 관련자들이 데이터 모델을 통해 의사소통을 할 수 있도록 자세하게 기술해야 한다.

 바. 통합성(Integration)

• "라. 데이터 재사용" 부분 참조.