새소식

Computer science - 2022.05.22

[SQLD] 데이터 모델링 파트 내용 정리

  • -

SQL 자격검정 실전문제집(노랭이)를 풀면서 정리한 내용입니다.

모델링

현실 세계에 대해서 표현

  1. 정보 시스템 구축을 위한 데이터 관점, 프로세스 관점 업무 분석
  2. 데이터 베이스 구축을 위한 분석 및 설계하는 과정
  3. 현실 세계의 데이터(what)에 대해 약속된 표기법에 의해 표현

모델링의 특징

  • 추상화 : 현실 세계를 일정한 형식에 맞추어 표현
  • 단순화 : 복잡한 현실 제한된 언어나 표기법을 통해 이해하기 쉽게 표현
  • 명확화(정확화) : 애매모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술

모델링 중요한 이유

  • 업무 정보를 구성하는 기초가 되는 정보들을 일정한 표기법에 의해 표현하기 위해서
  • 분석된 모델을 가지고 데이터베이스를 생성하여 개발 및 데이터 관리에 사용하기 위해서
  • 데이터 모델링 자체 업무의 흐름을 설명하고 분석하는 의미를 가지기 때문에

모델링 유의점

  • 중복(Duplication)을 고려

여러 장소의 데이터베이스에 같은 정보를 저장하지 않도록 중복성을 최소화

  • 최소화 ? → 반정규화로 중복될 수 있으므로.
  • 비유연성(Inflexibility)을 고려

사소한 업무 변화에도 데이터 모델이 수시로 변경 유지 보수의 어려움을 가중시키지 않도록 데이터의 정의 사용 프로세스와 분리. 이를 통해 데이터 혹은 프로세스 작은 변화 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성 줄임.

  • 비일관성(Inconsistency)을 고려

연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정하면 문제 발생. 데이터 모델링 때 데이터와 데이터 간 상호 연관에 대해 명확하게 정의 위협을 사전에 예방 가능.

모델링 종류

  1. 개념적 데이터 모델링
    • 추상화 수준 
    • 업무 중심적이고 포괄적이며 전사적
    • EA 수립 시 이용
  2. 논리적 데이터 모델링
    • 시스템 구축 업무에 따라 key, 속성, 관계 등을 정확하게 표현
    • 재사용성이 높음
  3. 물리적 데이터 모델링
    • 실제로 데이터베이스에 이식
    • 성능, 저장 등 물리적 성격을 고려하여 설계

DB 스키마 구조 3단계(ANSI-SPARC에서 정의)

각각 상호 독립적인 의미, 고유한 기능 보유

  1. 외부 스키마(개별 사용자 관점)
  2. 개념 스키마(통합 관점)
  • 모든 사용자 관점 통합한 조직 전체 관점의 통합 표현
  • 모든 응용 시스템, 사용자들이 필요로하는 데이터를 통합 조직 전체 DB를 기술
  • DB에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마
  • 데이터 모델링은 통합 관점의 개념 스키마를 만드는 과정
  1. 내부 스키마
  • DB 어떤 데이터가 어떻게 저장되어 있는 가를 기술

엔터티

  • 엔터티 : 테이블
  • 속성 : columns
  • 인스턴스 : rows

엔터티 특징

  • 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
  • 유일한 식별자에 의해 식별이 가능
  • 영속적으로 존재하는 인스턴스의 집합(최소 두개 이상의 인스턴스로 구성)
    • 계속 존재하는 인스턴스들의 집합 → 잠깐 있다가 사라지면 X
  • 업무 프로세스에 의해 이용
  • 반드시 속성이 있어야 함(최소 두개 이상)
  • 최소 한 개 이상의 다른 엔터티와의 관계가 있음

엔터티 명명 기준

  1. 업무 용어를 사용
  2. 약어 사용 자제
  3. 단수 명사 사용
  4. 유일한 이름 부여
  5. 생성하는 의미대로 이름 부여

엔터티 분류

발생 시점에 따른 분류

  1. 기본/키 엔터티
    • 해당 업무에 원래 존재하는 정보.
    • 다른 엔터티와의 관계에 의해 생성되지 않고 독립적으로 생성이 가능.
    • 타 엔터티의 부모 역할
    • 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가짐
    • ex) 사원, 부서, 고객, 상품, 자재
  2. 중심 엔터티
    • 기본 엔터티로부터 발생
    • 업무에서 가장 핵심적인 역할
    • ex) 계약, 대출, 주문
  3. 행위 엔터티
    • 2개 이상의 부모 엔터티로부터 발생
    • 자주 내용이 바뀌거나 데이터 양이 증가
    • ex) 변경 이력, 주문 목록

물리적 형태의 유무에 따른 분류

  1. 유형 엔터티
    • 물리적 형태가 있음
    • 안정적이고 지속적으로 활용
    • ex ) 사원, 상품
  2. 개념 엔터티
    • 물리적 형태 없음
    • 관리해야 할 개념적 정보
    • ex) 회사, 조직
  3. 무형 엔터티
    • 업무 수행에 따라 비교적 많이 발생
    • 통계 자료에 활용 가능
    • ex) 주문, 배송

예외 엔터티

다른 엔터티와의 관계를 생략할 수 있음

  • 통계성 엔터티
  • 코드성 엔터티

ERD

  • 1976 : 피터첸 Entity-Relationship Model(E-R Model)
  • 존재적 관계 행위에 의한 관계를 구분하지 않

작성 순서

https://computerhanashi.tistory.com/entry/sqld-데이터-모델링-이론-및-ERD

 

  1. 엔터티를 그린다.
  2. 엔터티를 적절하게 배치한다.
    1. 왼쪽 위 → 오른쪽 아래 순으로 배치
  3. 엔터티 사이 관계를 설정한다.
    1. 엔터티 사이 연결
  4. 관계명을 기술한다.
  5. 관계의 참여도를 기술한다.
    1. 1 : 1, 1: M
  6. 관계의 필수 여부를 기술한다.
    1. | : 필수, O : 선택

클래스 다이어 그램(UML)

  • 존재적 관계(연관 관계) 행위에 의한 관계(의존 관계)를 구분
  • 연관 관계(실선), 의존 관계(점선)로 표현

속성

인스턴스에서 관리하는 의미 상 더 이상 분리되지 않는 최소의 데이터 단위

  • 한 개의 속성 한 개의 속성 값을 갖는다.
  • 속성도 집합이다.

속성의 도메인

  • 엔터티 내 속성이 가질 수 있는 값의 범위
  • 데이터 타입 크기, 제약 사항 지정

속성의 명칭 부여

  • 업무에서 사용하는 용어 사용
  • 서술식 속성명은 사용하지 않
  • 약어 사용은 가급적 제한
  • 데이터 모델에서 유일성을 확보

속성 분류

속성의 특성에 따른 분류

  1. 기본(BASIC) 속성
    • 업무상 필요한 데이터에 대해 정의
    • 코드 성 데이터, 일련번호, 계산에 의해 생성된 속성은 제외
  2. 설계(DESIGNED) 속성
    • 업무 규칙을 위해 새로 만들거나 변형한 속성
    • 코드 성 데이터, 일련 번호
  3. 파생(DERIVED) 속성
    • 다른 속성의 영향을 받아 생성
    • 계산  → 데이터를 조회할 때 빠른 성능 얻음
    • 가급적 적게 정의

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

  1. PK 속성
  2. FK 속성
  3. 일반 속성

관계

관계 표기법

https://www.youtube.com/c/전광철OCP

  1. 관계 명 : 관계 시작, 끝 점 (고객, 주문)
  2. 관계 차수 : 1 : 1, 1 : M, M : N
  3. 관계 선택 사양 : 필수/선택(|/O) 표기

관계 구분

  1. 존재 의한 관계 ex) 부서 - 사원
  2. 행위 의한 관계 ex) 고객 - 주문
  • 클래스 다이어그램(UML)은 구분하여 연관 관계, 의존 관계로 표현

관계 체크 사항

  1.  엔터티 사이에 관심 있는 연관 규칙이 존재하는지.
  2.  엔터티 사이 정보의 조합이 발생하는지.
  3. 업무 기술서, 장표에 관계 연결을 가능하게 하는 동사가 있는지.
    1. 존재/행위 관계 여부 확인
  4. 업무 기술서, 장표에 관계 연결에 대한 규칙이 서술돼 있는지.

관계 읽기

  • 기준 엔터티를 한 개 또는 각으로 읽는다.
  • 대상 엔터티의 관계 참여도 개수를 읽는다.
  • 관계 선택 사양과 관계명을 읽는다.
  • ex) 고객 당 선택적으로 M개의 주문 수행 가능

식별자

하나의 엔터티에 구성되어 있는 여러 속성들에 대해  속성을 구분하기 위한 구분자

  • 논리 데이터 모델링 단계 → 물리적 데이터 모델링에서 KEY 구현 

식별자의 종류

  1. 엔터티 내에서 대표성을 가지는 지.
    •  식별자
    • 보조 식별자
  2. 엔터티 내에서 스스로 생성되었는지 여부.
    • 내부 식별자
    • 외부 식별자
  3. 단일 속성으로 식별이 되는지
    • 단일 식별자
    • 복합 식별자
  4. 식별자 속성 그대로 사용했는지 여부에 따라서.
    • 본질 식별자
    • 인조 식별자

주 식별자

엔터티 내 각 인스턴스를 구분하며 해당 엔터티에 대한 대표성을 가짐

따라서 타 엔터티 참조 관계를 연결할 수 있음

  • 해당 업무에서 자주 이용되는 속성 주 식별자로 지정

지정 시 고려 사항

  • 유일성
    • 주 식별자에 의해 엔터티 내 모든 인스턴스들이 유일하게 구분되어야 함
  • 최소성
    • 주 식별자를 구성하는 속성의 수 유일성을 만족하는 최소의 수가 되어야 함
  • 불변성
    • 지정된 주 식별자 값은 자주 변하지 않아야 
  • 존재성
    • 주 식별자가 지정이 되면 반드시 값이 있어야 

식별자 / 비식별자 관계

https://www.youtube.com/c/전광철OCP

  1. 식별자 관계(실선)
    • 부모 엔터티로부터 속성을 받아와 자식 엔터티 주 식별자로 사용
    • 강한 연결 관계
    • 부모 엔터티에 종속
    • 상속 받은 주 식별자 속성을 다른 엔터티에도 이전 필요
  2. 비 식별자 관계(점선)
    • 부모 엔터티로부터 속성을 받아와지만 자식 엔터티 주 식별자로 사용하지 않는 경우
    • 약한 연결 관계
    • 일반 속성으로 포함
    • 상속 받은 주 식별자 속성 타 엔터티 차단
    • 부모의 관계 참여 선택 관계
    • 모든 관계가 식별자 관계로 연결되면 SQL WHERE 절에서 비교하는 항목이 증가 돼 조인에 참여하는 테이블에 따라 SQL 문장이 길어져 SQL문의 복잡성이 증가 되는데 이를 방지하고 싶을 때 비 식별자 관계를 이용할 수 있음

데이터 무결성(Data Integrity)

  • 데이터 값 정확한 상태

데이터 정합성

  • 데이터 값들이 일치하는 상태
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.