SQLD: 데이터 모델링의 이해 #1

임동혁 Ldhbenecia·2024년 8월 2일

DataBase

목록 보기
5/15
post-thumbnail

SQLD 학습을 진행하며 기억할 내용을 간략히 기록합니다.
용어로 Entity(엔티티)를 엔터티라고 발음하지만 엔티티로 정리합니다.

데이터 모델링

  • 유의점
    중복, 비일관성, 비유연성

모델링 특징

  • 추상화
  • 명확화(정확화)
  • 단순화

데이터 모델링의 세 가지 관점
1. 데이터 관점 : 업무가 어떤 데이터와 관련이 있는지 또는 데이터 간의 관계는 무엇인지에 대해서 모델링 하는 방법(What, Data)
2. 프로세스 관점 : 업무가 실제로 하고 있는 일은 무엇인지 또는 무엇을 해야 하는지를 모델링 하는 방법(How, Process)
3. 데이터와 프로세스의 상관 관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법(Interaction)

스키마

외부스키마: 여러 사용자 관점으로 구성- View
개념스키마: 통합된 모든 사용자의 관점
내부스키마: 물리적인 저장구조를 표현

외부스키마 -- 논리적 데이터 독립성 -- 개념스키마 -- 물리적 데이터 독립성 -- 내부 스키마

사상

  • 상호 독립적인 개념을 연결시켜주는 다리
  • 논리적 사상: 외부화면 및 사용자 인터페이스 스키마 구조는 개념스키마와 연결
  • 물리적 사상: 개념스키마 구조와 물리적 저장된 구조와 연결

데이터 독립성

논리적 독립성: 개념 스키마가 변경되어도 외부 스키마에는 영향을 주지 않는다.
논리적 구조가 변경되어도 응용 프로그램에는 영향이 없음, 통합구조 변경 가능
-> 개념 스키마가 변경되어도 외부 스키마는 영향 X
외부 스키마를 변경하지 않으면서 개념적 스키마(또는 논리적 스키마)를 변경할 수 있는 성질

물리적 독립성: 물리 스키마가 변경되어도 논리 스키마에 영향을 주지 않는다.
물리적 독립성은 파일 저장구조의 변경이 논리 스키마와 응용 프로그램에 영향을 주지 않음
-> 내부스키마가 변경되어도 외부/개념 스키마는 영향 X
개념 스키마를 변경하지 않으면서 내부 스키마를 변경할 수 있는 성질

정리
외부, 개념, 내부 순서로 스키마가 이루어져있음
외부와 개념 사이에는 논리적 독립성, 개념과 내부 사이에는 물리적 독립성을 가지고 있음
논리적 독립성에 의해 개념은 변경되어도 상위 외부 스키마에 영향이 없음
물리적 독립성에 의해 내부는 변경되어도 상위 외부, 개념 스키마에 영향이 없음

엔티티 특징

  1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
  2. 유일한 식별자에 의해 식별이 가능해야함
  3. 영속적으로 존재하는 두 개 이상의 인스턴스 집합
  4. 업무 프로세스에 의해 이용되어야 함
  5. 반드시 속성이 있어야함 (콜럼)
  6. 다른 엔티티와 최소 한 개 이상의 관계가 있어야 함

공통코드, 통계성 엔티티의 경우 관계 생략 가능

발생 시점

  • 기본, 키 엔티티
  • 중심 엔티티
  • 행위 엔티티

엔티티 명명규칙

  1. 현업 업무에서 사용하는 용어 사용
  2. 가능하면 약어 사용 x
  3. 단수명사 사용
  4. 모든 엔티티를 통틀어 유일하게 이름이 부여
  5. 생성의미대로 이름 부여

속성

기본 속성:
설계 속성:
파생 속성: 데이터를 조회할 때 성능을 빠르게 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성

  • 도메인
    각 엔티티(테이블)의 속성에 대해 어떤 유형의 값이 들어가는지를 정의하는 개념

데이터 모델링 시 속성 명명규칙

  1. 속성의 이름에 약어를 사용할 경우 지나친 약어 사용 제한
  2. 속성의 이름에는 서술식 용어 사용 x
  3. 현업 업무에서 사용하는 용어를 주로 이용
  4. 애매모호하지않게, 복합 명사를 사용하여 구체적으로 명명하여 유일성을 확보할 것

데이터 모델링의 관계

관계
존재에 의한 관계, 행위에 의한 관계로 구분 가으
ERD에서는 이 두 가지를 구분하지 않고 단일화된 표기법을 사용
UML에서는 이 두 가지를 구분하여 연관관계는 실선, 의존관계는 점선으로 표현

  • 관계의 표기법
    관계명, 관계차수, 선택성

  • 존재에 의한 관계
    소속된다

  • 행위에 의한 관계
    주문한다

두 엔티티 사이의 정의한 관계에 대해 확인해야 할 사항

  1. 두 개의 엔티티 사이에 관심 있는 연관규칙이 존재하는가?
  2. 두 개의 엔티티 사이에 정보의 조합이 발생되는가?
  3. 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb) 가 있는가?
  4. 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

주식별자 고려사항

  1. 주식별자에 의해 엔티티 내의 모든 인스턴스들이 유일하게 구분되어야 함
  2. 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함
  3. 지정된 주식별자의 값은 자주 변하지 않는 값이어야 함
  4. 주식별자가 지정이 되면 반드시 값이 들어와야 함

명칭, 내역 등과 같이 번호가 아닌 이름으로 기술 되는 것들은 주식별자로 지정하기에 적절하지 않음
특히 사람의 이름은 동명이인이 있을 수 있기 때문에 더욱이 부적절

주식별자 특징

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

데이터 모델링에서 비식별자 관계로 연결하는 경우

비식별자: 부모 속성을 자식의 일반 속성으로 사용
1. 부모 없는 자식이 생성될 수 있는 경우
2. 부모와 지식의 생명주기가 다른 경우
3. 여러 개의 엔티티가 하나의 엔티티로 통합되어 표현되었는데 각각의 엔티티가 별도의 관계를 가진 경우
4. 자식 엔티티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
5. SQL 문장이 길어져 복잡성이 증가되는 것을 방지

  • 엔티티와 엔티티가 1:M 관게의 부모가 자식관계에서 데이터가 부모없이 자식쪽 엔티티의 인스턴스가 먼저 생성될 수 있는 경우
  • 부모 엔티티의 인스턴스가 지식 엔티티의 인스턴스보다 먼저 소멸하는 경우
  • SQL 문의 조인관계를 최소화 하는 경우 비식별자가 아닌 식별자 관계로 연결
  • 자식 엔티티의 식별자가 부모 엔티티의 주식별자를 상속받아 생성하는 것보다 별도의 주식별자를 생선하는 것이 더 유리하다고 판단되는 경우

여러 식별자

주식별자: 대표성을 가짐, 여러 인스턴스 중 하나를 유일하게 구분 가능
보조식별자: 여러 인스턴스 중 하나를 유일하게 구분 가능하나 대표성을 가지지 못함
본질식별자: 집합을 명확하게 설명할 수 있는 업무족으로 의미가 부여
외부식별자: 다른 엔티티로부터 상속되어 정의
인조 식별자: 인위적으로 만듦

속성이 가질 수 있는 값의 범위: 도메인

속성

기본 속성: 업무분석을 통해 바로 정의한 속성
설계 속성: 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성
파생 속성: 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성

0개의 댓글