상세 컨텐츠

본문 제목

SQLD 1과목 1장(데이터 모델링의 이해) 정리

Data/SQL

by 에스프리터 2021. 5. 23. 21:51

본문

Contents

모델링의 이해

  1. 모델링의 정의
    • 웹스터 사전 : 가설적, 일정 양식에 맞춘 표현
    • 복잡한 현실세계를 단순화해서 표현
    • 현상세계를 추상화한 반영
    • 사물 또는 사건에 대한 양상(aspect)나 관점(perspective)를 연관된 사람이나 그룹을 위해 명확하게 하는 거
  1. 모델링의 특징
    • 추상화 : 현실세계를 일정 형식에 맞춰 표현
    • 단순화 : 복잡한 현실세계를 제한된 표기법이나 언어로 표현
    • 명확화 : 누구나 이해하기 쉽게 현상 기술
  1. 모델리의 3가지 관점
    • 데이터 관점 : 업무가 어떤 데이터와 연관이 있는지, 데이터 간 관계가 무엇인지에 대해 모델링(what, data)
    • 프로세스 관점 : 실제하고 있는 업무는 무엇인지, 무엇을 해야하는지 모덜렝(how, process)
    • 데이터와 프로세스의 상관 관점 : 업무가 처리하는 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링(interaction)

데이터 모델의 기본 개념 이해

  1. 데이터 모델링의 정의
    • 정보시스템을 구축하기 위해, 해당 업무에 어떤 데이터가 존재하는지 또는 업무가 필요로 하는 정보는 무엇인지를 분석하는 방법
    • 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무 규칙(business rule)에 대하여 참(true) 혹은 거짓(false)를 판별할 수 있는 사실을 데이터에 접근하는 방법(how), 사람(who), 전산화와 별개의 관점에서 이를 명확하게 표현하는 추상화 기법
    • 실무적으론... 업무에 필요로 하는 데이터를 방법론에 따라 분석하고 설계하여 정보시스템 구축하는 과정
  1. 데이터 모델링이란...
    • 정보 시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
    • 현실세계의 데이터(what)에 대해 약속된 표기법에 의해 표현하는 과정
    • 데이터 베이스를 구축하기 위한 분석,설계의 과정
  1. 데이터 모델 제공 기능
    • 시스템을 현재 또는 원하는 모습으로 가시화
    • 시스템의 구조, 행동 명세화
    • 시스템 구축하는 구조화된 틀 제공
    • 시스템 구축 과정에서 결정한 것을 문서화
    • 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 관점
    • 특정 목표에 따라 구체화한 상세 수준의 표현 방법

데이터 모델의 중요성과 유의점

  1. 데이터 모델의 중요성
    • 파급 효과 : 데이터 모델 변경하면 다른 것도 전부 영향 받음
    • 복잡한 정보 요구사항의 간결한 표현 : 요구사항을 이해하고 이를 운용할 수 있는 앱을 개발하고 데이터 정합성을 유지
    • 데이터 품질 : 데이터 정확성 보장
    • 중복 : 동일 데이터가 저장되지 않게...
    • 비유연성 : 데이터 혹은 프로세스의 작은 변화가 DB에 영향을 주지 않도록 한다.
    • 비일관성 : 상호 연관관계에 따른 명확한 정의는 비일관성 위협을 감소.

데이터 모델의의 3단계 진행

  1. 데이터 모델링의 3단계 진행(아래로 갈 수록 추상적 → 구체적)
    • 개념적 데이터 모델링 : 추상화 수준 높고, 업무 중심-포괄적인 모델링 진행
      • 사용자 요구사항 분석에 따라 '엔터티-관계 다이어그램' 생성 & 전 조직에 이뤄질 경우 전사적 데이터 모델(Enterpricse Data Model).
      • 사용자와 개발자가 데이터 요구사항 발견하는 것을 지원
      • 추상적이므로 구조화를 쉽게 한다.
      • 현 시스템이 어떻게 변형되어야 하는 가를 이해
    • 논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등 표현
      • 어떻게 데이터에 엑세스하고, 누가 데이터에 엑세스하는지 등을 모델링
      • 시스템 전 과정을 지원하는 과정의 도구
      • 정규화를 통해 일관성을 확보하고, 중복을 제거하여 속성들이 적절한 엔터티에 배치하도록 한다.
    • 물리적 데이터 모델링 : 실제로 DB에 이식할 수 있도록 성능, 저장 등 고려하여 설계
      • 논리 데이터 모델이 어떻게 하드웨어에 표현될 것인가를 다룬다.
      • 물리적 스키마, 저장장소, 저장장치, 접근 방법 등에 대한 정의

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

  1. 프로젝트 생명주기에서 데이터 모델링
    • 폭포수 기반 모델링에서는 데이터 모델링의 위치가 분석과 설계 단계로 분리되어 정의된다.

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

  1. 데이터 독립성의 필요성
  1. 데이터의 독립성 확보 시 이점
    • 각 뷰(view)의 독립성 유지, 계층별 뷰에 영향을 주지 않고 변경
    • 단계 별 스키마에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공
  1. 데이터베이스 3단계 구조
    • ANSI/SPARC의 3단계 구성의 데이터 독립성 모델 : 외부(사용자의 관점) - 개념(공통 사항을 처리하는 통합된 뷰를 스키마 정의) - 내부적 단계(물리적으로 저장된 방법에 대한 스키마 구조)
    • 독립성 요소 상세
    • 2개 영역의 데이터 독립성
  1. 사상(Mapping) : 상호 독립된 개념을 연결시켜주는 다리

 

데이터 모델리의 3가지 요소

  1. 업무가 관여하는 어떤 것(Things) → 엔터티
  1. 어떤 것이 가지는 성격(Attributes) → 속성
  1. 업무가 관여하는 어떤 것 간의 관계(Relationships) → 관계
  1. 단수와 집합의 명명 차이 → 헷갈리면 아래 링크 참조
    데이터베이스의 구성 요소
    데이터베이스에서 개체 또는 엔터티(entity)는 데이터베이스에서 표현하려고 하는 무형, 유형의 객체(object)로써 서로 구별되는 것을 뜻한다. 이 개체는 현실 세계에 대해 사람이 생각하는 개념이나 정보의 단위로서 의미가 있다. 개체는 단독으로 존재할 수 있으며, 정보로서의 역할을 한다. 하나의 개체는 하나 이상의 속성, 즉 애트리뷰트(attribute)로 구성되고 각 속성은 그 개체의 특성이나 상태를 기술해 준다.
    https://m.blog.naver.com/PostView.naver?blogId=k97b1114&logNo=140153616568&proxyReferer=https:%2F%2Fwww.google.com%2F

데이터 모델리의 이해관계자

  1. DBA가 단독으로 데이터 모델링을 하지는 않음
  1. 업무 시스템을 개발하는 응용 시스템 개발자가 업무에 대해 더 이해하기 때문에 데이터 모델링까지 하는 경우가 많음

 

데이터 모델리의 표기법 ERD 이해

  1. ERD(Entity Relationship Diagram)은 업무 분석에서 도출된 엔터니와 엔터티 간의 관계를 도식화된 다이어그램으로 표현
  1. 엔터티 배치는 가장 중요한 엔터티를 왼쪽 상단에 배치하고, 그것을 중심으로 다른 엔터티를 나열하면서 전개한다.
  1. 엔터티 배차 이후 관계 있는 엔터티 간의 관계를 설정 → 초기에는 Primary Key로 속성이 상속되는 식별자 관계 설정, Circle 관계도 발생하지 않도록 유의
  1. 관계 설정이 완료되면 연결 관계에 관계 이름을 부여 (지나치게 포괄적인 의미는 사용주의)
  1. ERD 관계 차수와 선택성 표시
    • 엔터티 내의 인스턴스들이 얼마나 관계에 참여하는지를 나타내는 관계차수(Cardinality)를 표현
    • IE 표기는 하나(1)의 관계는 실설, 바커는 점선과 실선을 혼합하여 표기
    • 다수 참여(Many)의 관계는 까마귀발과 같은 모양
    • 필수-선택 표시는 관계선에 원 표현하여 ERD

좋은 데이터 모델의 요소

  1. 완전성 : 모든 데이터가 데이터 모델에 정의(Completeness)
  1. 중복 배제 : 동일 사실은 한번만 기록
  1. 업무 규칙 : Business Rules를 데이터 모델에 표현하고, 사용자에게 제공
  1. 데이터 재사용 : 재사용성을 증가시키려면 통합성과 독립성에 대해 고려
    • 외부의 변화에 대해 데이터 구조적으로 영향을 덜 받기 위해 확장성, 유연성에 힘을 기울임
    • '행위의 주체'가 되는 집합의 통합, '행위의 대상'이 되는 집합의 통합, '행위 자체'에 대한 통합 필요
  1. 의사소통 : 설계자가 정의한 많은 업무 규칙들을 동일한 의미로 받아들이고 활용하게끔 하는 역할
  1. 통합성 : 바람직한 데이터 구조는, 조직 전체에서 1번만 정의되고, 다른 영역에서 참조-활용(integration) 되는 것

 

엔터티의 개념

  1. 엔터티 정의 모음
    • 변별할 수 있는 사물
    • 데이터베이스 내에서 변별 가능한 객체
    • 정보를 저장할 수 있는 어떤 것
    • 정보가 저장될 수 있는 사람, 장소, 물건, 사건 개념 등
  1. 1번 문항의 공통점
    • 엔터티는 사람, 장소, 물건, 사건, 개념등의 명사
    • 엔터티는 업무상 관리가 필요한 관심사
    • 엔터티는 저장이 되기 위한 어떤 것(Thing)
  1. 요약하면...
    • 엔터티란 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것
    • 인스턴스의 집합

엔터티와 인스턴스 내용, 표기법

  1. 정의 예시

엔터티의 특징

  1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
  1. 유니크한 식별자에 의해 식별 가능
  1. 영속적으로 존재하는 인스턴스의 집합
  1. 엔터티는 업무 프로세스에 의해 이용
  1. 엔터티는 반드시 속성 포함
  1. 엔터티는 타 엔터티와 최소 1개 이상 관계 존재

 

엔터티의 분류

  1. 유무형에 따른 분류
    • 유형 엔터티(Tangible Entity) : 물리적인 형태 ,안정적, 지속적 활용 → 사원, 물품, 강사 같은 것
    • 개념 엔터티(Conceptual Entity) : 물리형태 미존재, 개념적 정보 → 조직, 보험상품
    • 사건 엔터티(Event Entity) : 업무 수행 시 발생하는 엔터티 → 주문, 청구, 미납
  1. 발생시점에 따른 분류
    • 기본 엔터티(Fundamental Entity) : 그 업무에 원래 존재하는 정보, 독립 생성 가능, 부모 역할 → 사원, 부서, 고객 등
    • 중심 엔터티(Main Entity) : 기본 엔터티로부터 발생, 업무에서 중심 역할, 행위 엔터티 생성 → 계약, 사고, 예금원장, 청구, 주문 등
    • 행위 엔터티(Active Entity) : 2개 이상의 부모 엔터티로부터 발생, 내용 변경, 데이터 증가 → 주문 목록, 사원 변경 이력 등

 

엔터티의 명명

  1. 현업 사용 용어부터 시작
  1. 가능하면 약어 자제
  1. 단수 명사
  1. 모든 엔터티에서 유일한 이름 부여
  1. 생성 의미대로 이름 부여

 

속성의 개념

  1. 사물의 성질, 본질적인 성질 등으로 정의
  1. 업무에서 필요로 하는 정의
  1. 의미 상 더 이상 분리되지 않는 정의
  1. 엔터티를 설명하고 인스턴스를 구성하는 요소

 

엔터티, 인스턴스, 속성, 속성값에 대한 내용과 표기법

  1. 엔터티 내에 하나의 인스턴스는 각각의 속성에 대해 한개의 속성값 만을 가질 수 있음
  1. 하나의 엔터티는 2개 이상의 인스턴스 집합
  1. 하나의 엔터티는 2개 이상의 속성
  1. 하나의 속성은 하나의 속성값

 

속성의 표기법

  1. 아래와 같이 엔터티 내에 이름 포함 표현

 

속성의 분류

  1. 기본 속성(Basic Attribute) → 코드성 데이터, 엔터티 분류위한 일련번호, 다른 속성을 계산,영향을 받아 생성된 속성을 제외한 모든 속성은 기본 속성
  1. 설계 속성(Designed Attribute) → 데이터 모델링을 위해 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성
  1. 파생 속성(Derived Attribute) → 다른 속성에 영향을 받아 생성되는 속성으로 보통 계산된 값

 

엔터티 구성 방식에 따른 분류

  1. 엔터티를 식별할 수 있는 속성을 PK(Primary Key) 속성, 다른 엔터티와의 관계에서 포함된 속성을 FK(Foreign Key) 속성, 엔터티에 포함되어 있고, PF,FK에 미포함 속성을 일반 속성이라 함. 이 외 단수형, 복합형으로 도 분류할 수 있음.

도메인

  1. 속성은 가질 수 있는 값의 범위가 있는데 그 속성의 도메인(Domain)이라 함. 예를 들어 학점이라는 속성의 도메인은 0.0 ~ 4.0 사이의 값으로 정의하는 것과 유사.

속성의 명명

  1. 용어사전이라는 업무 사전을 프로젝트에 사용
  1. 아랭와 같이 명명하여 데이터 타입의 일관성 확보

 

관계(Relation)

  1. 정의 : 상호 연관성이 있는 상태
  1. 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태나 행위로서 서로에게 연관성이 부여된 상태
  1. 관계의 페어링(paring)
  • 엔터티 안의 인스터스는 개별적으로 관계를 가지고(pairing)이고, 이것의 집합을 관계로 표현
  • 각각의 엔터티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태를 관계 페어링(Relation Pairing)으로 표현

 

관계(Relation)의 분류

  1. 관계는 '존재에 의한 관계'와 '행위에 의한 관계'로 분류할 수 있음.

 

관계의 표기법

  1. 관계명(Membership) : 관계의 이름으로 관계에 참여하는 형태 지칭
  1. 관계차수(Cardinality) : 1:1, 1:M, M:N (수학적인 의미론 집합의 크기를 의미)
  1. 관계선택사양(Optionality) : 필수관계, 선택관계 → 예를 들어 지하철 출발과 지하철문 닫힘은 필수적으로 연결관계가 있는 것과 같이, 데이터 모델의 관계에서는 필수 참여 관계(Mandotory)가 됨. 반면 지하철 방송은 지하철 출발과 필수 참여 관계가 아닌 선택적 관계(Optional)이 됨
  1. 만약 관계가 표시된 양쪽 엔터티에 모두 선택 참여가 표시된다면, 즉 0:0의 관계가 된다면 잘못되었을 확률이 높음

 

관계의 정의 및 읽는 방법

  1. 관계 체크 사항
    • 엔터티 사이에 관심있는 연관 규칙 존재
    • """"... 정보의 조합 발생
    • 업무기술서, 장표 관계 연결 규칙 서술
    • 업무기술서, 장표 관계 연결 가능하게 하는 동사 존재
  1. 관계 읽기
  • 기준 엔터티를 하나 또는 각(Each)로 읽고, 대상 엔터티의 개수를 읽고 관계선택사양과 관계명 읽기

 

식별자(Identifier)

  1. 식별자는 엔터티 내에서 인스턴스들을 구분할 수 있는 구분자
  1. 엔터티를 대표할 수 있는 속성
  1. 하나의 엔터티에는 유일한 식별자가 존재하여야 함

 

식별자 특징

  1. 주 식별자에 의해 엔터티 내의 모든 인스턴스가 구분 가능
  1. 주 식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수
  1. 지정 주 식별자 값은 자주 변하지 않아야 함
  1. 주 식별자 지정 시 반드시 값이 들어와야 함
  1. 대체 식별자 → 주 식별자의 특징과 유사하지만, 참조무결성 제약조건(Referntial Integrity) 특징

 

식별자 분류

  1. 주식별자(Primary Identifier)와 보조 식별자(Alternate Identifier)로 구분
  1. 엔터티 내 스스로 생성 유무에 따라, 내부 식별자와 외부 식별자로 구분
  1. 단일 속성으로 식별 유무에 따라 단일 식별자, 복합 식별자로 구분 가능

 

주 식별자 도출 기준

  1. 해당 업무에서 자주 이용되는 속성을 주 식별자로 지정
  1. 명칭, 내용 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자 미지정
  1. 복합으로 주식별자 구성될 경우 너무 많은 속성이 포함되지 않도록 한다

 

식별자관계와 비식별자관계의 결정

  1. 외부식별자는 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식 쪽에 엔터티에 생성되는 속성을 의미.
  1. FK 의 역할을 수행
  1. 식별자관계 : 부모로부터 받은 식별자를 자식엔터티의 주식별자로 사용하는 경우, Null 값이 오면 안되므로 반드시 부모 엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우
  1. 비식별자 관계 : 부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용되지 않고, 일반적인 속성으로만 사용되는 경우
  1. 식별자 관계로만 데이터 모델을 개발할 경우 문제점 → 주식별자 속성이 지속적으로 증가할 수 밖에 없다. → 연결되는 만큼 PK 가 늘어난다
  1. 비식별자 관계로만 데이터 모델 개발 시 문제점 → 연결되지 않은 비식별자 관계로 인해 SQL 구문이 길어짐
  1. 식별자 관계와 비식별자 관계 모델링 파악 기준

 

REF

태그

관련글 더보기

댓글 영역