song-ps

04.

29 min read

  • 데이터 모델링 표기법 이해
    • 데이터 모델링 기법 이해
    • 데이터 모델링 개요
    • 데이터 모델링 이해 
  • 개념 데이터 모델링
    • 개념 데이터 모델링 이해
    • 주제 영역 정의
    • 후보 엔티티 선정
    • 핵심 엔티티 정의
    • 관계 정의
    • 개념 데이터 모델 작성
  • 논리 데이터 모델링
    • 논리 데이터 모델링 이해
    • 속성 정의
    • 엔티티 상세화
    • 이력관리 정의
    • 논리 데이터 모델 품질 검토
  • 물리 데이터 모델링
    • 물리 데이터 모델링 이해
    • 물리 요소 조사 및 분석
    • 논리-물리 모델 변환
    • 반정규화
    • 물리 데이터 모델 품질 검토

데이터 모델링

무결성논리 모델링에서물리 모델링에서
실체 무결성주식별자 정의를 통해 논리적으로 반영PK, UNIQUE, NOT NULL 등으로 구현
영역(Domain) 무결성속성/도메인의 의미·허용범위 등을 정의데이터 타입, 길이, CHECK 등으로 구현
참조 무결성입력/삭제 규칙 등을 명시적으로 정의FK 및 관련 Constraint로 구현
사용자 정의 무결성업무 규칙으로 식별·정의 가능CHECK, Trigger, 프로그램 등으로 구현
개념실행업무
개념주제영역, 엔티티 (후보/핵심), 관계, 개념 DM
논리속성, 엔티티 (detail), 이력관리, 정규화, 참조 무결성 규칙 정의
물리물리요소, DBMS, 반정규화, 무결성 규칙 구현
  • 모델링 기본원칙
    • 커뮤니케이션 원칙
      • 모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성
      • 논리데이터모델:  비즈니스 지향적인 최종 사용자 데이터 모델과 기술적인 상세 데이터 모델
      • 데이터 모델의 이해를 필요로 하는 그룹
    • 모델링 상세화 원칙
      • 데이터의 상세화 정도를 제시하고 조직이 사용하는 정보 구조의 ‘최소 공통 분모’를 제시
      • 복잡한 구조는 요소적인 부분들로 쪼개야 하며 불필요한 구조와 중복은 제거
    • 논리적 표현 원칙
      • 조직의 데이터에 대한 논리적 측면을 최대한 표현
      • 모델은 물리적 제약 조건 없이 비즈니스를 그대로 반영

# 데이터 모델의 이해를 필요로 하는 그룹

최종사용자
	- 개념화, 추상화, 정규화 기법을 통하여 중복없고 데이터의 정확성을 보장하는 데이터 구조의 이해 및 사용
시스템분석가
	- 시스템에서 사용되어질 정확한 데이터의 구조 및 데이터가 갖는 업무 규칙의 이해
DBA
	- 논리 데이터 모델의 구조와 물리 스키마의 차이점을 이해하고 최종 사용자에게는 데이터의 제공, 
	  시스템 분석가에게는 물리 스키마의 제공을 위한 데이터 구조의 이해
타프로젝트 분석가
	- 관련 프로젝트가 데이터를 어떻게 정의하고 있는지를 알아냄. 
	  인터페이스가 개발되어지고 데이터가 애플리케이션 또는 시스템 간에 공유되기 위한 데이터 구조 및 업무 규칙의 이해
구분관계형비관계형
구조6가지 특성 갖는 테이블Flat File
Post Define SchemaPre define Schema
DB구조변경 용이DB구조변경 어려움
조작8개 조회/처리 연산자READ조회, 처리연산자
집합(SET)처리한건씩 처리
원자값 처리Pointer 처리
무결성엔터티,참조,무결정,연쇄작용무결성 개념 없음
접근경로Key와 인덱스 별개Key와 인덱스 동일
Data에 대한 접근경로 유연Data에 대한 접근경로 제한적
  • 관계형 모델 이론
    • 데이터 구조: 사용자가 인식하는 데이터의 구성
    • 데이터 조작: 사용자가 관계형 데이터 구조에 행하는일련의 연산(처리)형태
    • 데이터 무결성: 사용자가 일련의 관계형 연산을 수행할때 테이블의 데이터 값이 어떻게 되야 하는지를 통제하는 일련의 업무 규칙

 

  • 데이터 무결성
    • 사용자가 일련의 관계형 처리(입력, 수정, 삭제, 조회)를 수행할 때 관계형 엔터티의 데이터값이 어떻게 작용해야 하는지 통제하는 일련의 업무규칙
    • 실체 무결성 (엔터티 무결성)
      • 두 개의 똑같은 튜플은 한 릴레이션에 포함불가 (유일식별자)
      • 식별자를 구성하는 각 속성이 NOT NULL
      • 엔터티 내 특정 인스턴스의 유일성 보장
      • 최소한의 속성 집합  
    • 참조무결성
      • 데이터가 하나 또는 두 개의 관계있는 엔터티에 입력, 수정, 삭제될 때 데이터가 어떻게 반응해야 하는가에 대한 업무 규칙
      • 엔터티의 주키와 마찬가지로 외래키도 데이터 무결성에 관한 규칙을 내포
        • 참조무결성규칙: 엔터티의 모든 외래키 값은 관계 있는 엔터티에 주 키 값으로 존재해야함
      • DB설계관점에서 선택하지 말고, 현업의 업무규칙에 따라 적절한 규칙을 선택.
        • 입력규칙: 자식 엔터티의 행이 입력될때
        • 삭제규칙: 부모 엔터티의 행을 삭제할때 (또는 행의 주키를 수정할때)  
    • 도메인 무결성 (길이, 허용값, 범위)
      • 데이터 타입, 길이, 허용값, 기본값, 유일성, 널 여부 등에 관한 업무규칙
      • 도메인: 속성이 가질 수 있는 값의 전체 집합
      • 같은 도메인의 값들끼리만 비교 가능
      • 속성이 취할 수 있는 값의 제한  
    • 연쇄작용 또는 업무규칙
      • 연쇄작용: 입력,수정,삭제 또는 조회 등의 작업이 동일 엔터티 혹은 다른 엔터티의 속성에 영향을 미치는 업무 규칙
      • 업무규칙은 조직이 데이터를 인식하고 사용하는 방법에 기초 

확장된 ER모델 (개체-관계 모델) 은 서브타입을 포함한다.

분류이름비고
집합 (SET) 처리
관계연산자 (조회)Select (or Restrict)열에 의거한 행의 부분집합
Project (π)열의 부분집합(subset)
Product (×)두 관계 테이블간 행의 조합을 묶음
Join (⨝)열의 기준에 의거하여 각 행을 수평적으로 묶음
Union (∪)중복없이 각 행을 수직적으로 묶음(합집합)
Intersection (∩)관계 테이블간의 공통된 행(교집합), 테이블 구조는 동일
Difference (- 또는 제외)하나의 관계 테이블에만 있는 행(차집합), intersection의 반대
Division (¼)다른 관계 테이블의 모든 행에 대응하는 열을 제외한 열. (R에서 S의 레코드를 다가진 레코드)
처리연산자 (테이블 내용 변경)Insert행의 삽입
Update행의 수정
Delete행의 삭제
  • 본질적 데이터 요구사항
    • 이름
      • 모든 속성은 고유하게 식별할 수 있는 이름이 주어져야함
    • 명세 (Description)
      • 모든 실체는 명세가 있어야 함.
      • 모형을 검토하는 누구든지 실체를 정확히 해석할 수 있어야 함.
    • 유형 (Type)
      • 속성은 Key 속성 또는 Non-Key 속성중 하나로 구분되어야 함.
      • 이 특성은 key 속성으로써의 역할 가능성보다는 실제 용도와 관련된다
  • 좋은 데이터 모델의 요소 (완중업재 안의간통)
이름비고
완전성업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의
중복배제하나의 DB내에 동일한 사실은 반드시 한번만 기록
비즈니스 룰 (업무규칙)수많은 업무 규칙을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용 하는 모든 사용자가 그 규칙을 공유하도록 제공
데이터 재사용데이터의 통합성과 독립성에 대해서 충분히 고려. 통합모델을 구축하고, 애플리케이션에 대해 독립적으로 설계
안정성 및 확장성- 현재의 데이터 구조를 거의 변화하지 않고도 변화에 대응할 수 있는 데이터 구조
- 아주 적은 확장을 통해 이러한 변화에 대응
- 정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합,‘행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합
의사소통많은 업무 규칙은 해당 정보시스템을 운용/관리하는 많은 관련자들이 설계자가 정의한 업무규칙들을 동일한 의미로 받아들이고 정보시스템을 활용
간결성데이터를 합리적으로 균형있고 단순하게 분류
통합성조직의 전체에서 한 번만 정의되고 이를 여러 다른 영역에서 참조

데이터 모델링 기법 이해

  • 데이터 모델 목적
    • DB 설계에 대한 계획 또는 청사진
    • 데이터 모델링 단계에서 업무를 잘못 이해했거나 관계를 잘못 정의한 것이 발견되었다면 해당하는 다이어그램과 일부 관련된 문서만 변경하면 됨.
    • DB와 응용 프로그램 개발이 완료된 후 이러한 오류를 발견하여 수정하려면 이와 관련된 많은 프로그램과 SQL문이 변경되어야 함
    • 뿐만 아니라 데이터가 새로운 구조로 옮겨져야 하는 등 이러한 변경을 반영하는 데 많은 비용과 시간이 필요하게 됨
  • 개체-관계 모델 기법
    • 데이터에 대해 관리자, 사용자, 개발자들이 서로 다르게 인식하고 있는 뷰들을 하나로 통합할 수 있는 단일화된 설계안
    • 서로 다른 뷰를 충족시킬 수 있는 데이터 처리와 제약 조건 등의 요구 사항을 정의
  • 구성요소
이름비고
entity업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서, 그 대상들 간에 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합
속성- 엔터티에 저장되는 개체 집합의 특성을 설명하는 항목
- 실체내에서 관리하고자 하는 정보들의 항목
- 도메인: 속성이 가질 수 있는 값의 범위
- 단일치 속성: 하나의 값만 존재
- 다중치 속성: 여러개의 값이 존재
식별자- 엔터티의 각 개체들은 인스턴스
- 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자를 가짐
- 복합 식별자: 두 개 이상의 속성으로 이루어진 식별자
관계 (식선카비)- 엔터티와 엔터티 간 연관성을 표현
- 하나 또는 두 개의 실체를 연관시키는 업무와 관련된 중요한 사항.
- 식별성, 선택성, 기수성, 비전이성
- 매핑 카디날리티는 ERD에서 개체와 연결될 때 나타나는 대응되는 수
- 대응수, 최대대응수, 최소대응수로 구분
카디날리티 (기수성)- 한 개체가 관계를 통하여 다른 개체와 관련된 개체들의 수(관계에 참여하는 엔터티의 개수)
- 1:1, 1:M, M:M
존재종속- 한 엔터티의 존재가 다른 엔터티(들)의 존재에 영향을 받는 경우
- 전체참여, 부분참여
서브타입- 엔터티의 하위 집합 (부분집합). 속성을 상속함
- ex) 학생(슈퍼) > 학부학생, 대학원생(서브)
- 배타적: 슈퍼타입은 많아야 1개의 서브타입과 관련. (돔안에 X표시)
- 포괄적: 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련
- 모든 슈퍼타입이 구분자를 가지고 있는 것은 아님.
- 서브타입은 그것의 슈퍼타입이라 불리는 다른 개체의 특별한 경우
특성의미핵심 질문
식별성 (Identification)부모와의 관계가 자식의 식별자 구성에 참여하는지부모 식별자를 자식 PK로 물려받는가?
부모가 내 식별자에 들어오는가
선택성 (Optionality)관계 참여가 필수인지 선택인지반드시 관계를 가져야 하나?
상대가 반드시 있어야 하는가
기수성 (Cardinality)상대 엔터티의 인스턴스와 몇 개까지 관계를 맺는지1개인가, 여러 개인가?
상대가 몇개까지 가능한가
비전이성 (Non-transferability)한 번 맺어진 관계를 다른 부모 인스턴스로 이전할 수 없는지부모를 다른 인스턴스로 바꿀 수 있는가?
한번 정한 상대를 다른 인스턴스로 바꿀 수 없는가
  • 객체지향 모델링
    • 객체지향 방법론-객체지향 분석-객체지향 설계-객체지향 모델링-객체지향 프로그래밍-객체지향 DBMS
    • 데이터와 프로세스를 같은 객체 안에 결합한다
  • 객체지향 개념
    • 객체는 속성과 메소드로 구성.
      • 속성은 객체 클래스의 성질.
      • 메소드는 하나 이상의 속성을 접근, 조작, 수정, 삭제, 생성하는 프로세스
    • 연관 또는 상속을 통해서 다른 객체들에 연결
      • 연관은 객체 간의 자연적 관계
  • 객체 모형
    • 주제에 연관된 기본 객체 식별,  객체간의 연관을 식별
  • 객체 모형 데이터
    • 객체-관계 다이어그램에 모형화
  • 불명료한 객체 접근 방식
    • 객체지향 개발의 가장 단순화된 표현: 객체지향 개발을 분명하게 이해하는데 필요한 많은 객체지향 특징을 무시하는 것
    • 객체지향 모델링의 미성숙: 객체가 어떻게 표현되고 기호가 어떻게 사용되어야 하는가 등의 정의는 아직까지 초기단계.-
  • 객체지향 모델링 장점
    • 재사용 코드, 모든 비즈니스 규칙 표현, 프로세스와 데이터 모델링을 함께 운영
    • 객체가 다른 객체와 연결되는 방법은 연관 또는 상속
  • 객체 모형의 메소드
분류비고
단순한 메소드설명부 또는 구조화된 기법 사용
복잡한 메소드정교한 문서화 접근 방식이 필요
이벤트 지향적인 프로세스상태 전이 모델링과 같은 동적 프로세스 모델링 기법이 필요
정적인 프로세스데이터 흐름 다이어그램이나 기능 분해와 같은 기법을 사용
  • 객체지향 모델링과 논리 데이터 모델링간의 관계
E-ROO
엔티티객체
속성속성
관계연결
엔티티 유형객체 클래스

개념 데이터 모델

  • 주제영역 개념
    • 기업이 사용하는 데이터의 최상위 집합
      • ex) 제조의 경우, 인사/생산/자재/판매
    • 시스템의 대상이 되는 업무를 명백하게 구분이 가능한 단위업무로 분리하는 개념
    • 주제영역 내부에 존재하게될 개체들이 높은 결합성을 유지하게 해야함
    • 프로세스 모델링의 기능 (function) 과 매핑
  • 특수한 형태 관계
    • 순환 관계
      • 하나의 엔터티가 자기 자신과 관계를 맺는 관계
      • 하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함
      • 각 계층에 있는 속성은 동일하게 함
      • 순환 모델은 필수(직선) 관계로 취급될 수 없고(무한 LOOP 발생), 반드시 선택사양 관계
      • 조직의 변경(추가/삭제)에 쉽게 대응
    • BOM 관계 (BILL OF Materials)
      • BOM 관계의 모델을 네트워크 구조 (전철 노선이나 하이퍼링크를 갖는 웹 도큐먼트 같은)
      • M:M 순환구조: 상세 모델링 과정에서 새로운 관계 엔터티를 추가하여 두 개의 일대다(1:M) 관계로 구성된 모델로 구체화
    • ARC 관계 (Mutally Exclusive)
      • 어떤 엔터티가 두 개 이상의 다른 엔터티의 합집합과 관계를 가지는 것을 배타적(Exclusive) 관계 혹은 아크(Arc) 관계라 함
      • 아크 내에 있는 관계는 보통 동일
      • 아크 내에 있는 관계는 항상 필수이거나 선택
      • 아크는 반드시 하나의 엔터티에만 속해야 함 (하나의 아크가 여러 엔터티를 가질 수 없음)
      • 어떤 엔터티는 다수의 아크를 가질 수 있음. 지정된 관계는 단 하나의 아크에만 사용되어야 함
      • 논리적으로 엔터티간의 업무적 연관성을 명확하게 표현
      • 실제 DB로 구현시 엔터티를 하나로 통합할 수도 있음.
구분핵심 의미대표 구조
순환 관계엔티티가 자기 자신과 관계1:M 자기참조
BOM 관계자기 자신과의 M:M 순환 관계관계 엔티티로 해소
ARC 관계여러 부모 중 하나와만 배타적으로 관계Mutually Exclusive
순환BOMARC
구분의미
입력 규칙자식 엔터티에 데이터를 넣을 때 대응되는 부모가 어떻게 존재해야 하는지 규정
삭제 규칙부모 엔터티를 삭제할 때 관련 자식을 어떻게 처리할지 규정
기반부모 PK ↔ 자식 FK의 참조 관계
DAP 위치논리 데이터 모델링 → 관계 정의 → 참조 무결성 규칙 정의
  • 참조무결성 규칙 정의
    • 관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주 식별자 값이 존재
    • 실체의 주 식별자(PK)와 마찬가지로 외부 식별자(FK)도 데이터 무결성에 관한 업무 규칙을 내포함
    • 데이터베이스 설계 관점에서 선택하지 말고, 사용자의 업무 규칙에 따라 적절한 규칙을 선택
입력규칙삭제규칙
자식 엔터티의 인스턴스를 입력할 때부모 엔터티의 인스턴스를 삭제 또는  주식별자를 수정할 때
DEPENDENT대응되는 부모 실체에 인스턴스가 있는 경우에만 자식 실체에 입력을 허용
AUTOMATIC자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 이를 자동 생성
RESTRICT대응되는 자식 실체의 인스턴스가 없는 경우에만 부모 실체 인스턴스 삭제를 허용
CASCADE부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스를 자동 삭제
NULLIFY자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 자식 실체의 참조키 (FK)를 Null 값으로 처리부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참조키(FK)를 Null 값으로 수정
DEFAULT자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 참조키(FK)를 지정된 기본 값으로 처리부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참조키(FK)를 기본값으로 수정
CUSTOMIZED특정한 검증 조건이 만족되는 경우에만 자식 실체 인스턴스의 입력을 허용특정한 검증 조건이 만족되는 경우에만 부모 실체 인스턴스의 삭제를 허용
NO EFFECT자식 실체 인스턴스의 입력을 조건 없이 허용부모 실체 인스턴스 삭제를 조건 없이 허용
  • 속성 검증 및 확정 로직
    • 원자단위 (최소단위까지 분할)
      • 집합 개념의 속성은 단순 개념으로 분할
      • 가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합
      • 일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않음
      • 분할 및 통합의 기준은 업무의 요구 사항에 따름
    • 유일값
      • 여러 값을 가지거나 반복되는 속성은 잘못된 속성
      • 반복되는 속성은 새로운 엔터티로 분할해야 할 1차 정규화의 대상임
    • 가공값 (추출 속성인지 검증)
      • 속성이 원천적인 값인지, 다른 속성에 의해 가공되어서 만들어진 값인지를 검증
      • 원천값에서 다시 계산 가능한 값을 별도로 저장하면 원천값 변경 시 가공값과 불일치할 수 있음
      • 가공값이라면 어떤 원천 속성에서 어떤 규칙으로 만들어지는지 명확히 해야 함 (산출 근거를 모델에 표현)
      • 업무상 중요한 가공정보를 누락하지 않기 위해
    • 관리수준 상세화 검토
      • 더 상세한 정보관리가 필요한지 검토
인덱스 = 기본적으로 성능 구조  
Constraint = 기본적으로 무결성 구조
  • 엔터티 검증
    • 조직의 업무를 수행하는데 필요한 의미있는 정보를 나타내야 함
    • 특정 사례가 아닌 유사한 사물들을 대표하는 집합체 (구매부서 > 부서)
    • 인스턴스가 포함할 내부 연관성 있는 속성에 의해 결정된 단일개념을 대표해야함
    • 엔터티내 인스턴스의 출현을 구별할 수 있는 능력을 제공해야 함 (엔터티 무결성)
    • 정규화 규칙을 만족해야함

Graph View

Backlinks