SQL

1-1 데이터 모델링의 이해

아아네잔 2023. 6. 4. 15:42

SQLD 시험 대비 요약 정리 : 1-1 데이터 모델링의 이해

제 1절. 데이터 모델의 모델의 이해

  • 데이터모델링이란
    • 정보 시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
    • 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
    • 데이터베이스를 구축하기 위한 분석/설계의 과정
  • 모델링의 특징 (추 단 명)
    1. 추상화
    2. 현실세계를 일정한 형식에 맞추어 표현한다는 의미, 다양한 현상을 일정한 양식인 표기법에 의해 표현한다는 것
    3. 단순화
    4. 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수있도록 하는 개념
    5. 명확화
    6. 누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술하는 것
  • 모델링의 관점 (데 프 데+프)
    1. 데이터 관점 What, Data
    2. 업무가 어떤 데이터와 관련이 있는지, 데이터간의 관계는 무엇인지 모델링하는 방법
    3. 프로세스 관점 How, Process
    4. 업무가 실제 하고 있는 일은 무엇인지, 무엇을 해야하는지 모델링하는 방법
    5. 데이터와 프로세스의 상관관점
    6. 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법
  • 데이터 모델이 제공하는 기능
    • 가시화
    • 명세화
    • 구조화
    • 문서화
    • 다양한 관점 제공
    • 상세수준의 표현 방법 제공
  • 데이터 모델링의 중요성
    • 파급효과
    • 복잡한 요구사항의 간결한 표현
    • 데이터 품질
  • 데이터 모델링을 할 때의 유의점
    1. 중복
    2. 데이터베이스가 여러장소에 같은 정보를 저장하는 잘못은 하지 않도록 한다.
    3. 비유연성
    4. 데이터 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
    5. 비일관성
    6. 데이터의 중복이 없더라도 비일관성은 발생할 수 있기 때문에 데이터와 데이터간 상호 연관관계에 대한 명확한 정의가 필요하다.
  • 개념-논리-물리 데이터 모델 (개 논 물)
    1. 개념적 데이터 모델링
      • 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행, 전사적 데이터 모델링, EA 수립시 많이 이용
      • 핵심 엔터티와 그들관의 관계를 발견하고, 그것을 표현하기 위해서 엔터티 - 관계 다이어그램을 생성한다.
      • 개념 데이터 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다.
      • 현 시스템이 어떻게 변형되어야하는가를 이해하는데 유용하다.
    2. 논리적 데이터 모델링o 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다.o 이 단계에서 수행하는 중요한 활동은 정규화 이다.
    3. o 물리적인 스키마를 설계하기 전 데이터 모델의 상태이다.
    4. o 시스템으로 구축하고자하는 업무에 대해 Key, 속성, 관계등을 정확하게 표현, 재사용성이 높음
    5. 물리적 데이터 모델링o 제일 구체적인 단계의 수준
    6. o 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 스키마를 설계한다.
    실무에서는 개념적 + 논리적을 한꺼번에 수행하는 경우가 대부분이다.
  • 데이터 독립의 필요성
    1. 유지보수 비용을 절감
    2. 데이터의 복잡도를 낮춤
    3. 중복된 데이터를 줄이기 위함
    4. 화면과 데이터베이스 간에 서로 독립성을 유지하기 위한 목적
  • 데이터베이스 3단계 구조
    1. 외부단계
    2. 사용자와 가까운 단계
    3. 개념 단계
    4. 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 스키마 구조로 디자인된 형태
    5. 내부적 단계
    6. 데이터가 물리적으로 저장된 방법에 대한 스키마 구조
  • 데이터 독립성 요소
    1. 외부 스키마
    2. 사용자 관점
    3. 개념 스키마
    4. 통합 관점
    5. 내부 스키마
    6. 물리적 저장구조
  • 데이터 독립성
    • 논리적 데이터 독립성
      • 내용
        • 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것
        • 논리적 구조가 변경되어도 응용 프로그램에는 영향이 없음
      • 특징
        • 사용자 특성에 맞는 변경 가능
        • 통합구조 변경 가능
    • 물리적 데이터 독립성
      • 내용
        • 내부스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것
        • 저장장치의 구조 변경은 응용 프로그램과 개념 스키마에 영향 없음
      • 특징
        • 물리적 구조 영향없이 개념구조 변경 가능
        • 개념구조 영향 없이 물리적인 구조 변경가능
  • 사상 (Mapping)
    • 외부적/개념적 사상 (논리적 사상)
    • 외부적 뷰와 개념적 뷰의 상호관련성을 정의함
    • 개념적/내부적 사상 (물리적 사상)
    • 개념적 뷰와 저장된 데이터 베이스의 상호관련성을 정의함
  • 데이터 모델링의 세가지 요소 (Things, Attributes, Relationships)
    1. 업무가 관여하는 어떤 것
    2. 어떤 것이 가지는 성격
    3. 업무가 관여하는 어떤 것의 관계
  • ERD 작업순서
    1. 엔터티를 그린다.
    2. 엔터티를 적절하게 배치한다.
    3. 엔터티간 관계를 설정한다.
    4. 관계명을 기술한다.
    5. 관계의 참여도를 기술한다. (관계 차수)
    6. 관계의 필수여부를 기술한다.
  • 좋은 데이터 모델의 요소
    • 완정성
    • 업무에서 필요로하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다.
    • 중복 배제
    • 하나의 데이터 베이스 안에 동일한 사실은 반드시 한 번만 기록하여야 한다.
    • 업무 규칙
    • 업무 규칙을 데이터 모델에 표현하고, 해당 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공하여야 한다.
    • 데이터 재사용
    • 데이터의 통합성과 독립성에 대해 고려하여야 한다.
    • 의사소통
    • 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 한다.
    • 통합성
    • 공유데이터에 대한 구조를 여러 업무영역에대서 공동으로 사용하기 용이하게 정의할 수 있어야 한다.

제 2절. 엔터티 Entity

  • 엔티티 개념
    • 명사
    • 업무상 필요한 관심사
    • 저장이 되기 위한 어떤 것
    • 인스턴스의 집합
  • 엔티티 특징
    • 반드시 해당 업무에 필요하고 관리하고자 하는 정보여야 한다.
    • 유일한 식별자에 의해 식별이 가능해야 한다.
    • 영속적으로 존재하는 인스턴스의 집합이여야 한다.
    • 한개가 아니라 두개 이상이여야 한다.
    • 업무프로세스에 의해 이용되어야 한다.
    • 엔터티는 반드시 속성이 있어야 한다.
    • 엔터티는 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다.
  • 엔터티의 분류
    • 유 무형에 따른 분류
      • 유형 | 물리적인 형태가 있고, 안정적이며 지속적으로 활용되는 엔터티
      • 개념 | 물리적인 형태는 존재하지 않고, 관리해야 할 개념적 정보로 구분됨
      • 사건 | 업무를 수행함에 따라 발생되는 엔터티, 비교적 발생량이 많음
    • 발생시점에 따른 분류
      • 기본엔터티자신은 타 엔터티의 부모역할을 하게 된다.
      • 다른 엔터티로부터 주 식별자를 상속받지 않고 자신의 고유한 주식별자를 갖게 된다.
      • 원래 존재하는 정보, 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성 가능
      • 중심엔터티데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 행위 엔터티를 생성한다.
      • 기본 엔터티로부터 발생되고, 그 업무에 있어서 중심적인 역할
      • 행위엔터티
      • 두 개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터 양이 증가된다.
  • 엔터티 명명
    • 현업업무에서 사용하는 용어 사용
    • 약어 사용 자제
    • 단수명사 사용
    • 모든 엔터티에서 유일하게 이름이 부여되어야 한다.
    • 생성의미대로 이름 부여

제 3절. 속성 Attribute

  • 속성
    • 업무에서 필요로한다.
    • 더 이상 분리되지 않는 최소의 데이터 단위
    • 엔터티를 설명하고 인스턴스의 구성요소가 된다.
  • 속성의 특징
    • 해당 업무에서 반드시 필요하고 관리하고자 하는 정보
    • 함수적 종속성을 가져야 한다.
    • 하나의 속성에는 한 개의 값만을 가진다.
  • 속성의 범위
    • 도메인
  • 속성의 분류
    • 속성의 특징에 따른 분류
      1. 기본 속성 | 업무로부터 추출한 모든 속성, 엔터티의 가장 일반적이고 많은 속성
      2. 설계 속성 | 업무상 필요한 데이터 이외의 업무를 규칙화하기 위해 새로만들거나 변형하여 정의하는 속성
      3. 파생속성 | 다른 속성에 영향을 받아 발생하는 속성, 보통 계산된 값, 데이터정합성을 유지하기위해 유의해야할 것이 많으므로 가급적 파생속성은 적게 정의하는 것이 좋다.
    • 엔터티 구성방식에 따른 분류
      1. PK속성 | 엔터티를 식별할 수 있는 속성
      2. FK속성 | 다른 엔터티와의 관계에서 포함된 속성
      3. 일반속성 | 엔터티에 포함되어있고, PK,FK에 포함되지 않은 속성
    • 세부의미를 쪼갤 수 있는지에 따른 분류
      1. 단순속성 | 나이, 성별 등 더 이상 다른 속성들로 구성될 수 없는 단순한 속성
      2. 복합 속성 | 주소는 시,구,동,번지와 같은 여러 세부속성으로 구성 될 수 있음
    • 단일, 다중 값에 따른 분류
      1. 단일값 속성 | 주민번호같은 속성은 반드시 한 개만 존재한다.
      2. 다중값 속성 | 사람에 따라 전화번호, 집, 차 등은 여러개를 가질 수도 있다.
  • 속성의 명명
    • 해당 업무에서 사용하는 이름
    • 서술식 속성명은 사용하지 않음
    • 약어 사용 가급적 제한
    • 전체 데이터 모델에서 유일성 확보
  • 엔터티, 인스턴스, 속성, 속성값의 관계
    • 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
    • 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
    • 한 개의 속성은 한 개의 속성 값을 갖는다.

제 4절. 관계 Relationship

  • 관계
    • 인스턴스 사이의 논리적인 연관성으로서 존재 또는 행위로서 서로에게 연관성이 부여된 상태
    • 관계의 패어링
      • 각각의 엔터티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태를 관계 페어링이라고 한다.
    • 분류
      • 존재에 의한 관계 | 사원은 부서에 항상 속해 있다.
      • 행위에 의한 관계 | 주문은 고객이 주문을 할 때 발생된다.
    • 표기법
      • 관계명 | 관계의 이름
        • IE 표기법, Barker 표기법 : 포함한다, 소속된다.
      • 관계차수 | 1:1, 1:M, M:N
        • 관계에 참여하는 각각의 엔터티는 관계를 맺는 다른 엔터티의 엔터티에 대해 하나나 그 이상의 수와 관계를 가지고 있다.
      • 관계 선택 사양 | 필수 관계, 선택 관계
        • 선택참여를 하는 엔티티 쪽을 원으로 표시한다. 필수참여는 아무런 표시를 하지 않는다.
    • 관계 체크사항
      • 두 개의 엔터티 사이에 관심있는 연관 규칙이 존재하는가?
      • 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
      • 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
      • 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
    • 관계 읽기
      • 기준 엔터티를 한 개 혹은 각으로 읽는다.
      • 대상 엔터티의 관계 참여도. 즉 개수를 읽는다.
      • 관계 선택 사양과 관계명을 읽는다.

제 5절. 식별자

  • 식별자
    • 하나의 엔티티에 구성되어 있는 여러개의 속성 중에 엔터티를 대표할 수 있는 속성
    • 하나의 엔티티는 반드시 하나의 유일한 식별자가 존재해야 한다.
    • 특징
      • 주식별자에 의해 엔터티 내에 모든 인스턴스 들이 유일하게 구분되어야 한다.
      • 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
      • 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
      • 주식별자가 지정이 되면 반드시 값이 들어와야 한다.
    • 분류
      • 대표성 여부
        • 주식별자 | 엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이며, 타 엔터티와 참조관계를 연결할 수 있는 식별자
        • 보조식별자 | 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이나, 대표성을 가지지 못해 참조 관계 연결을 못함
      • 스스로 생성 여부
        • 내부식별자 | 엔터티 내부에서 스스로 만들어지는 식별자
        • 외부식별자 | 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
      • 속성의 수
        • 단일식별자 | 하나의 속성으로 구성된 식별자
        • 복합식별자 | 둘 이상의 속성으로 구성된 식별자
      • 대체여부
        • 본질식별자 | 업무에 의해 만들어지는 식별자
        • 인조식별자 | 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자
  • 주 식별자 도출 기준
    • 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
    • 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
      • 명칭이나 내역 등이 있고 인스턴스를 식별할 수 있는 다른 구분자가 존재하지 않을 경우는 새로운 식별자를 생성하도록 한다. 보통 일련번호나 코드를 사용한다.
    • 복합으로 주식별자를 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.
  • 식별자와 비식별자 관계의 결정
    • 외부 식별자는 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식 쪽에 엔터티에 생성되는 속성을 외부 식별자라 하며, 데이터베이스 생성 시 FK 역할을 한다.
    • 엔터티에 주식별자가 지정되고 엔터티간 관계를 연결하면 부모쪽의 주식별자를 자식 엔터티의 속성으로 내려보낸다. 이 때 자식 엔터티에서 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용할 것인지, 또는 부모와 연결이 되는 속성으로만 이용할 것인지 결정해야 한다.
  • 식별자 관계
    • 자식 엔터티의 주 식별자로 부모 엔터티의 주식별자가 상속이 되는 경우
    • 부모로부터 받은 식별자를 자식 엔터티의 주식별자로 이용하는 경우는 Null 값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우이다.
  • 비식별자 관계
    • 부모엔터티로부터 속성을 받았지만 자식 엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우
    • 다음의 경우에 비식별자 관계에 의한 외부속성을 생성한다.
      1. 자식 엔터티에서 받은 속성이 반드시 필수가 아니여도 무방하기 때문에 부모없는 자식이 생성될 수 있는 경우
      2. 엔터티 별로 데이터의 생명주기를 다르게 관리할 경우
      예) 부모엔터티에 인스턴스가 자식의 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우
      1. 여러개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때
      2. 자식 엔터티에 주식별자로 사용해도 되지만 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단 될 때
  • 문제점
    • 식별자 관계로만 설정할 경우 문제점
    • 주식별자 속성이 지속적으로 증가할 수 밖에 없는 구조로서, 개발자 복잡성과 오류가능성을 유발시킬 수 있는 요인이 될 수 있다.
    • 비식별자 관계로만 설정할 경우 문제점
    • 부모의 유형의 속성이 자식 엔터티로 상속이 되지 않아 자식 엔터티에서 데이터를 처리할 때 쓸데없이 부모 엔터티까지 찾아가야 하는 경우가 발생된다.
  • 식별자와 비식별자 관계 비교
항목   식별자 관계 비식별자 관계
목적  강한 연결관계 표현  약한 연결관계 표현
자식 주식별자 영 향 자식 주식별자의 구성에 포함됨 자식 일반 속성에 포함됨
표기법 실선 표현 실선 표현
연결 고려 사항 - 반드시 부모 엔터 티 종속
- 자식 주식 별자 구성에 부모 주 식별자 포함 필요
- 상속받은 주식별자 속성을 타 엔터티에 이전 필요		 - 약한 종속 관계
- 자식 주식별자 구성 을 독립적으로 구성
- 자식 주식별자 구 성에 부모 주식별자 부분 필요
- 상속받 은 주식별자 속성을 타 엔터티에 차단 필 요
- 부모쪽의 관계 참여가 선택관계
저작자표시 (새창열림)