1. 데이터 모델링의 이해 I

Daisy 🌼·2022년 8월 12일
0

SQL

목록 보기
1/2
post-thumbnail

1. 모델링

정의 : 실무적으로 해석하면 업무에서 필요로 하는 데이터를 시스템 구축 방법론에 의해 분석하고, 설계하여 정보시스템을 구축하는 과정

목적 : 일정한 표기법에 의해 표현함으로써 정보시스템 구축의 대상이 되는 업무 내용을 정확히 분석하고, 분석된 모델을 통해 실제 DB를 생성하여 개발 및 데이터관리에 사용하기 위함


2. 데이터 모델이 제공하는 기능

1) 시스템을 원하는 모습으로 가시화
2) 시스템의 구조와 행동을 명세화
3) 시스템을 구축하는 구조화된 틀 제공
4) 시스템 구축 과정에서 결정된 것을 문서화
5) 선택과 집중 : 타 영역의 세부사항을 숨겨 다양한 관점 제공
6) 목표에 따라 구체화된 상세수준의 표현방법 제공


3. 모델링의 특징

  • 현실세계 → 추상화, 단순화, 정확화 → 모델
    1) 추상화 : 다양한 현상을 일정한 양식인 표기법에 의해 표현
    2) 단순화 : 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현
    3) 명확화 : 애매모호함을 제거하고 정확하게 현상을 기술

4. 모델링의 세 가지 관점

1) 데이터 관점 : 어떤 데이터와 관련이 있는지 혹은 데이터 간 관계는 무엇인지에 대해 모델링 하는 방법 (What, data)
2) 프로세스 관점 : 업무가 실제하고 있는 일은 무엇인지 또는 무엇을 해야하는지를 모델링하는 방법 (How, process)
3) 데이터와 프로세스의 상관 관계 관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링 하는 방법 (Interaction)


5. 데이터 모델링의 중요성 및 유의점

1) 파급효과 (Leverage) : 각 단위의 테스트들이 성공적으로 완료되면 이를 전체로 묶어 병행, 통합 테스트를 수행하는데, 만약 이 시점에 데이터 모델의 변경이 불가피한 상황이 발생한다고 가정하면, 이 시기의 데이터
구조 변경으로 인한 일련의 변경 작업은 전체 시스템 구축 프로젝트에서 큰 위험요소가 될 수 있으므로, 시스템 구축 작업 중 다른 어떤 설계과정보다 데이터 설계가 가장 중요

2) 간결한 표현 (Conciseness) : 데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구로, 시스템을 구축하는 많은 관련자들이 설계자의 생각대로 정보 요구사항을 이해
하고 이를 운용할 수 있는 앱을 개발하고 데이터 정합성을 유지할 수 있도록 하기 위해, 정보 요구사항이 정확하고 간결하게 표현해야 함

3) 데이터 품질 (Data Quality) : 데이터 품질의 문제는 데이터 구조의 문제로, 중복 데이터의 미정의, 데이터 구조의 비즈니스 정의의 불충분, 동일성격의 데이터를 통합하지 않고 분리함으로써 나타나는 데이터 불인치
등의 문제로 인한 품질 문제는 치유하기 불가능한 경우가 대부분으로, 데이터 모델링 시 하기 3가지 유의해야 함

  • 유의사항 3가지
    (1) 중복(Duplication) 데이터 모델
    같은 데이터를 사용하는 사람, 시간, 장소 파악에 도움을 주나, 이러한 지식 응용이 DB가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 해야 함

    (2) 비유연성(Inflexibility) 데이터 모델
    설계 방법에 따라 사소한 업무 변화에도 데이터 모델이 수시로 변경 돼 유지보수의 어려움을 가중시킬 수 있어, 데이터의 정의를 사용 프로세스와 분리하여 작은 변화에도 데이터 모델이 수시로 변경되면 안 됨

    (3) 비일관성(Inconsistency) 데이터
    모델링을 할 때 데이터들 간 상호연관 관계에 대한 명확한 정의는 위험의 사전 예방 가능


6. 데이터 모델링의 3단계 진행

1) 개념적 (추상적) : 업무중심적이고 포괄적, 전사적 데이터 모델링, EA 수립 시 많이 이용하며 핵심 엔터티와 그들 간 관계를 발견하고 이를 표현하기 위한 다이어그램 생성
→ 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원하며 상위 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해 논의할 수 있는 기반 형성, 현 시스템이 어떻게 변형돼야 하는가를 이해하는데 유용

2) 논리적 (중간) : Key, 속성, 관계 등을 정확히 표현하며 재사용성 높고, DB 설계 프로세스의 Input으로 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 혹은 과정으로 데이터 모델링이 최종적으로
완료된 상태, 즉 물리적인 스키마 설계 하기 전 단계의 데이터 모델 상태
→ 정규화 : 논리 데이터 모델 상세화과정의 대표적인 정규화는 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치하여 신뢰성 있는 데이터 구조를 얻어야 함

3) 물리적 (구체적) : 실제 DB에 이식 할 수 있도록 성능, 저장 등 물리적 성격을 고려하여 설계, 논리 데이터 모델이 데이터 저장소로써 어떻게 HW에 표현될 것인가를 다루는 것을 물리적 스키마라고 함
→ 이 단계에서는 테이블, 칼럼 등으로 표현되는 물리적 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근방법 등이 있음


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


8. 데이터 독립성

필요성 : 어떤 단위에 대해 독립적 의미를 부여하고 그것을 효과적으로 구현하면 고유한 특징을 명확히 할 뿐만 아니라, 다른 기능의 변경으로 부터 쉽게 변경되지 않고 자신의 고유한 기능을 가지고, 또한 제공하는 장점을
가지게 됨, 지속적으로 증가하는 유지보수 비용을 절감하고 복잡도를 낮추며 중복된 데이터를 줄이기 위한 목적, 끊임없이 요구되는 사용자 요구사항에 대해 화면과 DB간 서로 독립성을 유지하기 위한 목적으로 데이
터 독립성 개념 출현


9. 데이터 독립성 요소

외부 스키마 : 개개 사용자가 보는 개인적 DB 스키마
개념 스키마 : 모든 사용자 관점을 통합한 전체 DB
내부 스키마 : 물리적 장치에서 데이터가 실제적 저장


10. 데이터 독립성

1) 논리적 독립성
(1)개념스키마 변경 → 외부스키마 영향 x
(2)논리적 구조 변경 → 응용 프로그램 영향 x
(3) 사용자 특성 및 퉁합구조 변경 가능

2) 물리적 독립성
(1)내부스키마 변경 → 외부/개념스키마 영향 x
(2)저장장치의 구조변경 → 응용프로그램과 개념스키마 영향 x
(3)물리적 구조 (혹은 개념) 영향없이 개념구조 (혹은 물리적) 변경가능


11. Mapping (사상)

정의 : 상호 독립적인 개념을 연결시켜주는 다리
1) 논리적 사상 : 외부 스키마 - 개념 스키마 (외부적 뷰 - 개념적 뷰)
2) 물리적 사상 : 개념 스키마 - 내부 스키마 (개념적 뷰 - 저장된 DB)


12. 데이터 모델링의 3요소

1) 어떤 것(Things) : 업무과 관여하는 어떤 것
2) 성격(Attributes) : 어떤 것이 가지는 성격
3) 관계(Relationships) : 업무가 관여하는 어떤 것 간의 관계


13. 데이터 모델 표기법

1976년 피터첸이 Entity Relationship Model 개발

  • IE, Baker 기법이 많이 쓰임
  • 엔터티, 관계, 속성으로 이뤄짐

14. ERD 작업순서 (엔터티 = 사각형 / 관계 = 마름모)

  1. 엔터티 그림 2. 엔터티 배치 3. 엔터티 관계 설정
  2. 관계명 기술 5. 관계의 참여도 기술 6. 관계필수 여부 기술

15. How to drawing ERD

1) 해당업무에서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래 쪽 중앙에 배치하여 전체 엔터티와 어울릴 수 있도록 하면 효율적
2) 중복 관계가 발생하지 않도록 하고 Circle 관계도 발생하지 않도록 유의
3) 관계이름은 현재형을 사용하고 지나치게 포괄적인 용어 지양
4) 엔터티 내 인스턴스들이 관계에 참여하는지를 나타내는 관계차수 표현
5) 필수/선택 표시는 관계선에 원을 표현


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

  1. 완전성 : 업무에 필요한 모든 데이터가 모델에 정의되어야 함

  2. 중복배제 : 하나의 DB내에 동일한 사실은 한번만 기록

  3. 업무규칙 : 많은 규칙을 사용자가 공유하도록 제공

  4. 데이터 재사용 : 재사용성 향상을 위해 데이터가 독립적 설계되어야 함.
    통합 모델이어야만 데이터 재사용성 향상, 확장성, 유연대응 가능

  5. 의사소통 : 업무규칙은 엔터티, 서브타입, 속성, 관계 등 형태로 최대한 자세히 표현

  6. 통합성 : 동일한 데이터는 한 번만 정의, 참조 활용


17. 엔터티 (Entity)

업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것, 보이지 않는 개념 포함


18. 엔터티의 특징

1) 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
2) 유일한 식별자에 의해 식별 가능 (Ex : 사번, 고객사 코드 등)
3) 두 개 이상의 인스턴스의 집합
4) 업무 프로세스에 의해 이용되어야 함
5) 반드시 속성이 있어야 함 → 예외적으로 관계 엔터티는 주식별자 속성만 가지고 있어도 인정
6) 다른 엔터티와 최소 1개 이상의 관계가 있어야 함 → 통계성/코드성 엔터티는 관계 생략 가능


19. 엔터티의 분류

1) 유무형에 따른 엔터티 분류
(1) 유형 : 물리적이고 안정 및 지속적 형태 (Ex : 사원, 물품, 강사)
(2) 개념 : 개념적 정보 (Ex : 조직, 보험상품)
(3) 사건 : 업무 수행 시 발생 (Ex : 주문, 청구, 미납)

2) 발생시점에 따른 엔터티 분류
(1) 기본 : 원래 존재한 정보, 부모 역할, 고유한 주식별자 (Ex : 사원, 부서)
(2) 중심 : 기본 엔터티에서 발생, 관계로 행위 엔터티 생성 (Ex : 계약, 사고)
(3) 행위 : 2개 이상 부모 엔터티에서 발생, 자주 바뀌고 양 증가 (Ex : 주문목록, 사원변경 이력)


20. 엔터티의 명명

현업업무에서 사용하는 용어 사용, 약어 사용금지, 단수명사 사용, 고유한 이름 사용, 생성의미대로 부여

profile
세상을 이롭게하는 AI Engineer

0개의 댓글