[SQLD] 1과목 요약 정리: 1-1 데이터 모델링의 이해
Note/Certificate

[SQLD] 1과목 요약 정리: 1-1 데이터 모델링의 이해

728x90
반응형


데이터 모델링

  • 모델링 특징
    1. 추상화: 현실 세계를 일정한 형식에 맞춰 표현
    1. 단순화: 복잡한 현실 세계를 약속된 규약을 통해 쉽게 이해할 수 있도록 함
    1. 명확화: 애매모호함 제거, 정확한 현상 기술
  • 모델링 관점
    1. 데이터 관점(what)
    1. 프로세스 관점(how)
    1. 상관 관점(interaction)
  • 데이터 모델링
    • 중요성
      1. 파급효과: 시스템 구축 작업 중 데이터 설계가 중요
      1. 간결한 표현: 복잡한 정보의 요구사항에 대한 간결한 표현
      1. 데이터 품질: 정확성이 높은 데이터, 데이터 구조의 문제
    • 유의점
      1. 중복: 여러 장소에 같은 정보 저장
      1. 비유연성: 사소한 업무 변화에 데이터 모델이 수시로 변경되면 안됨
      1. 비일관성: 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보 갱신 안됨 (연계성 하락)
  • 데이터 모델링 과정
    • 모델링 3요소: things, attributes, relationships
    1. 개념적 데이터 모델: 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링(추상적)
      • 전사적 데이터 모델링, EA수립 시 많이 이용
      • 엔티티-관계 다이어그램 생성
    1. 논리적 데이터 모델: 시스템으로 구축하고자 하는 업무에 대해 key, 속성, 관계 등을 정확하게 표현, 재사용성 높음
      • 정규화 수행
    1. 물리적 데이터 모델: 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적 성격 고려(구체적)
  • 데이터 독립성 요소
    1. 외부 스키마: 사용자가 보는 관점, 개인적 DB 스키마, 응용프래머가 접근하는 DB
    1. 개념 스키마: 모든 사용자 관점을 통합한 조직 전체의 DB
      • 논리적 독립성: 개념 스키마가 변경되어도 외부 스키마에 영향 없음
      • 논리적 사상: 외부적 뷰와 개념적 뷰의 상호 관련성
    1. 내부 스키마: 실제 데이터 저장되는 방법 표현(물리적)
      • 물리적 독립성: 내부 스키마가 변경되어도 외부/개념 스키마에 영향 없음
      • 물리적 사상: 개념적 뷰와 저장된 데이터베이스의 상호관련성
  • 데이터 모델 표기법
    • 1976, 피터첸이 E-R Model 표기법 만듦
    • ERD 작업순서
      1. 엔티티 그림(사각형) → 적절히 배치
      1. 엔티티간 관계 설정 → 관계명 기술
      1. 관계 참여도 기술 (관계차수 표현)
      1. 관계 필수여부 기술
    • 가장 중요한 엔티티: 왼쪽 상당에서 조금 아래쪽 중앙에 배치
    • 업무 흐름의 중심인 엔티티: 타 엔티티와 많은 관계를 가지고 있으므로 중앙에 배치
    • 하나의 관계는 실선 표기, 다수 참여의 관계는 까마귀발 모양
  • 좋은 데이터 모델
    1. 완전성: 업무에서 필요로 하는 모든 데이터가 정의
    1. 중복배제: 동일한 사실은 반드시 한 번만 기록
    1. 업무 규칙: 모든 사용자가 공유
    1. 데이터 재사용: 통합 모델, 데이터가 애플리케이션에 대해 독립적으로 설계, 확장성
    1. 의사소통: 업무 규칙들이 데이터 모델에 자세하게 표현, 의사소통의 도구
    1. 통합성: 데이터가 한 번만 정의되고 다른 영역에서 참조 및 활용, 데이터 아키텍처의 중요성 부각

엔티티(entity)

  • 특징
    1. 업무에서 필요로 하고 관리하고자 하는 정보
    1. 유일한 식별자에 의해 식별이 가능해야 함
    1. 영속적으로 존재하는 인스턴스의 집합
    1. 업무 프로세스에 의해 이용
    1. 두 개 이상의 속성 포함 (관계엔티티: 주식별자만 있어도 인정)
    1. 다른 엔티티와 최소 한 개 이상의 관계 존재 (통계, 코드성 엔티티는 관계 생략 가능)
  • 유무형 분류
    1. 유형엔티티: 물리적 형태 존재, 안정적이며 지속적으로 활용 (사원, 물품, 강사 등)
    1. 개념엔티티: 물리적 형태 존재하지 않음, 개념적 저오로 구분 (조직, 보험상품 등)
    1. 사건엔티티: 업무를 수행함에 따라 발생되는 엔티티, 통계 자료에 이용 가능 (주문, 청구, 미납 등)
  • 발생시점 분류
    1. 기본엔티티: 업무에 원래 존재하는 정보, 독립적으로 생성 가능, 부모 역할, 고유한 주식별자 (사원, 고객, 상품 등)
    1. 중심엔티티: 기본엔티티로부터 발생, 업무에 있어 중심적 역할 (계약, 사고, 청구, 주문 등)
    1. 행위엔티티: 두 개 이상의 부모엔티티로부터 발생, 자주 변경, 분석 초기단계에서는 잘 나타나지 않음 (주문 목록, 사원변경이력 등)
  • 스스로 생성 여부: 독립엔티티, 의존엔티티
  • 명명 기준
    1. 협업 업무에서 사용하는 용어 사용
    1. 가급적 약어 사용하지 않음
    1. 단수 명사 사용
    1. 모든 엔티티에서 유일하게 이름 부여
    1. 엔티티 생성 의미대로 이름 부여: 문제 야기 가능성

속성(attribute)

  • 업무에서 필요로 하는 인스턴스, 관리하고자 하는 최소의 데이터 단위
  • 관계
    • 한 개의 엔티티는 두 개 이상의 인스턴스 집합
    • 한 개의 엔티티는 두 개 이상의 속성을 가짐
    • 한 개의 속성은 한 개의 속성값을 가짐
  • 특징
    • 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
    • 주식별자에 함수적 종속성을 가져야 함
  • 속성의 특성 분류
    1. 기본 속성: 업무분석을 통해 정의한 속성
    1. 설계 속성: 업무상 존재하지 않지만 설계 하면서 도출 (코드성 속성, 일련번호)
    1. 파생 속성: 다른 속성으로부터 계산이나 변형되어 생성, 다른 속성의 영향 받아 변함 (계산된 값) → 꼭 필요한 경우에만 정의, 업무로직이 속성 내부에 숨지 않도록 함
  • 도메인: 속성 값의 범위 (제약사항)
  • 도메인 정의 + 용어사전 ⇒ 용어적 표준과 데이터 타입의 일관성 확보
  • 명명 기준
    1. 현업에서 사용하는 이름 부여
    1. 서술식 사용 금지, 명사형 사용, 수식어/소유격 자제
    1. 가급적 약어 사용 금지
    1. 모든 속성의 이름은 유일하게 작성 (충돌 해결)

관계(relation)

  • 엔티티와 엔티티 간 연관성 표현
  • 관계 페어링: 각 엔티티의 인스턴스들은 자신이 관련된 인스턴스와 관계의 어커런스로 참여하는 형태
  • 클래스 다이어그램 관계
    1. 연관관계(존재): 항상 이용하는 관계 ⇒ 실선
    1. 의존관계(행위): 상대방 행위에 대해 관계가 형성 ⇒ 점선
  • 표기법
    1. 관계명: 애매한 동사 피하기, 현재형으로 표현
    1. 관계차수: 참여자의 수 표현 (1:1, 1:M, M:N)
    1. 관계선택사양: 필수 관계, 선택 관계
  • 관계 체크사항
    1. 두 개의 엔티티 사이에 관심있는 연관규칙이 존재하는가?
    1. 두 개의 엔티티 사이에 정보의 조합이 발생하는가?
    1. 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
    1. 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?
  • 식별자
    • 하나의 엔티티에 구성된 여러 개의 속성 중에 엔티티를 대표할 수 있는 속성 (하나의 엔티티는 반드시 하나의 유일한 식별자가 존재)
    • 특징
      1. 유일성: 주식별자에 의해 유일하게 구분
      1. 최소성: 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함
      1. 불변성: 주식별자의 값은 자주 변하지 않는 것이어야 함
      1. 존재성: 주식별자가 지정되면 반드시 값이 들어와야 함
    • 분류
      • 대표성 여부: 주식별자, 보조식별자
      • 스스로 생성 여부: 내부식별자, 외부식별자
      • 속성의 수: 단일식별자, 복합시결자
      • 대체 여부: 본질식별자(업무), 인조식별자(인위적)
    • 주식별자 기준
      1. 업무에서 자주 사용되는 특성
      1. 이름으로 기술되는 것은 가능하면 지정하지 않음
      1. 복합으로 구성 시, 너무 많은 속성이 포함되지 않도록 함
    • 식별자 관계: 부모로부터 받은 식별자를 자식 엔티티의 주식별자로 사용 (강한 연결관계) ⇒ 실선
      • null 불가, 반드시 부모 엔티티 생성 (1:1 또는 1:M 관계)
      • 단점: 지속적으로 연결하면 PK가 증가 → 개발 복잡성, 오류 가능성
    • 비식별자 관계: 부모로부터 속성을 받았지만 자식 엔티티의 일반적인 속성으로 사용 (약한 연결관계) ⇒ 점선
      • 부모 없는 자식 생성 가능
      • 자식 엔티티에 별도의 주식별자를 생성하는 것이 유리하다고 판단될 때 외부식별자로 표현
      • 단점: 기준 속성이 상속되지 않음 → 불필요한 조인 증가, 성능 저하
728x90
반응형