[SQLP] 데이터 모델링의 이해

당당·2024년 4월 17일
1

SQLP

목록 보기
1/12

📔설명

데이터 모델링의 개념, 엔티티, 속성, 관계, 식별자, 특징, 표기법, 명명법 등을 알아보자


🍕데이터 모델의 이해

1. 모델링의 이해

모델링의 정의

모델 : 일정한 표기법에 따라 표현해 놓은 모양
모델링 : 이것을 표기법에 따라 표기하는 것 자체

  • 복잡한 현실세계단순화해 표현
  • 사물이나 사건에 대한 양상이나 관점을 명확화
  • 현실세계를 추상화(모형화)한 반영

모델링의 특징

추상화 : 현실세계일정한 형식에 맞추어 표현
단순화 : 복잡한 현실세계를 제한된 표기법이나 언어로 표현해 쉽게 이해하도록 함
명확화 : 누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함 제거, 정확하게 현상 기술

모델링은 계획-분석-설계 단계에서 업무 분석 및 설계할 때, 구축-운영에서 변경 및 관리 시 이용

모델링의 세 가지 관점

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


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

데이터 모델링의 정의

  • 정보시스템구축하기 위한 데이터 관점업무 분석 기법
  • 현실세계데이터에 대해 약속된 표기법에 의해 표현하는 과정
  • 데이터베이스구축하기 위한 분석, 설계의 과정

데이터 모델링 자체로서 업무를 설명하고 분석하는 부분에도 중요

데이터 모델이 제공하는 기능

  • 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와줌
  • 시스템의 구조행동명세화
  • 시스템을 구축하는 구조화된 틀 제공
  • 시스템 구축 과정에서 결정한 것을 문서화
  • 다른 영역의 세부 사항숨기는 관점 제공
  • 특정 목표에 따라 구체화한 상세 수준표현방법 제공

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

파급효과

시스템 구축이 완성되어 가는 시점에 테스트를 하는데, 이 시점에 데이터 모델의 변경이 불가피하다면 데이터 구조 변경에 따른 표준 영향 분석, 응용 변경 영향 분석 등 많은 영향 분석이 필요하고 이후 실제적인 변경작업이 이뤄짐
=> 전체 시스템 구축 프로젝트에서 큰 위험요소

복잡한 정보 요구 사항의 간결한 표현

데이터 모델은 정보 요구 사항한계를 가장 명확하고 간결하게 표현

데이터 품질

데이터의 정확성이 떨어지면 해당 데이터로 얻을 수 있던 비즈니스 기회 상실
중복 데이터의 미정의, 데이터 구조에서 비즈니스 정의 불충분, 동일한 성격의 데이터를 통합하지 않고 분리함으로써 데이터 불일치 등의 데이터 구조 문제로 인해 데이터 품질은 바로잡기 불가능한 경우가 대부분


데이터 모델링 시 유의

  • 중복 : 데이터베이스가 여러 장소에 같은 정보를 저장하지 않도록 함
  • 비유연성 : 사소한 업무 변화에도 데이터 모델수시로 변경되어 유지보수 어려움
    => 데이터 정의데이터 사용 프로세스분리하여 데이터 혹은 프로세스의 변화가 애플리케이션과 DB에 중대한 변화를 일으킬 가능성 줄임
  • 비일관성 : 데이터 중복이 없더라도 비일관성(Inconsistency) 발생
    => 개발자가 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문
    => 데이터 모델링 시, 데이터데이터 간 상호 연관 관계에 대한 명확한 정의 필요

4. 데이터 모델링의 3단계 진행

개념적 데이터 모델링 : 추상화 수준이 높고, 업무 중심적이고 포괄적인 수준
ex. 전사적 데이터 모델링, EA 수립

논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무Key, 속성, 관계 등을 정확하게 표현, 재사용성 높음

물리적 데이터 모델링 : 실제로 데이터베이스에 이식할 수 있도록 성능, 저장물리적인 성격 고려

개념적 데이터 모델링

데이터 요구사항을 찾고 분석에서 시작

핵심 엔터티와 그들 간의 관계를 발견하고, 표현하기 위해 엔터티-관계 다이어그램을 생성

전사적 데이터 모델 : 데이터 모델링 과정전 조직에 걸쳐 진행시

개념 데이터 모델을 통해 조직의 데이터 요구공식화
=> 사용자와 시스템 개발자가 데이터 요구사항발견 지원
(개념 데이터 모델추상적이라 상위의 문제에 대한 구조화쉽게 하며, 시스템 기능에 대해 논의할 수 있는 기반 제공)
=> 현 시스템이 어떻게 변형되어야 하는가를 이해하는 데 유용

논리적 데이터 모델링

데이터 설계 프로세스Input으로서 비즈니스 정보의 논리적인 구조규칙명확하게 표현

논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태
=> 물리적인 스키마 설계 전 단계의 데이터 모델 상태

누가 데이터에 액세스, 어떻게 데이터에 액세스, 그리고 전산화와는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록

데이터 모델링 과정에서 가장 핵심

정규화 : 논리 데이터 모델 상세화 과정의 대표적 활동, 논리 데이터 모델일관성을 확보하고 중복 제거 하여 속성들이 가장 적절한 엔터티에 배치되도록 하여 신뢰성있는 데이터 구조 얻음

논리 데이터 모델의 상세화 : 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의, 이력 관리

물리적 데이터 모델링

논리 데이터 모델데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가

물리적 스키마 : 데이터가 물리적으로 컴퓨터에 어떻게 저장될 지에 대한 정의
=> 테이블, 칼럼 등으로 표현되는 물리적인 저장 구조사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등 결정


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

폭포수 : 데이터 모델링의 위치가 분석, 설계 단계로 구분되어 명확하게 정의
정보공학/구조적 방법론 : 분석 단계에서 업무 중심논리적 데이터 모델링 수행, 설계 단계에서 하드웨어성능을 고려한 물리적 데이터 모델링 수행
나선형 모델 : 업무 크기에 따라 논리적/물리적 데이터 모델이 분석, 설계단계 양쪽에서 수행, 일반적으로 분석 단계에서 논리적 데이터 모델이 더 많이 수행
객체지향 모델 : 데이터 모델링과 프로세스 모델링을 구분하지 않고 일체형으로 진행
ex. 클래스


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

데이터 독립성의 필요성

자신이 가지는 고유한 특징을 명확하게 하고, 다른 기능의 변경으로부터 쉽게 변경되지 않고, 자신의 고유한 기능을 가지고 기능을 제공 가능

지속적으로 증가하는 유지보수 비용 절감, 데이터 복잡도 낮춤, 중복된 데이터줄임, 사용자 요구사항에 대한 화면데이터베이스서로 독립성을 유지하기 위한 목적

데이터 독립성 확보
=> 각 독립성 유지, 계층별 뷰에 영향을 주지 않고 변경 가능
=> 단계별 스키마에 따라 데이터 정의어데이터 조작어가 다름을 제공

데이터베이스 3단계 구조

외부 단계 : 사용자와 가까운 단계, 사용자 개개인이 보는 자료에 대한 관점
=> 사용자가 처리하고자 하는 데이터 유형/관점/방법에 따라 다른 스키마 구조

개념 단계 : 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰
=> 데이터 모델사용자가 처리하는 통합된 뷰를 설계하는 도구

내부적 단계 : 데이터가 물리적으로 저장된 방법

데이터 독립성 요소

두 영역의 데이터 독립성

사상(Mapping)

상호 독립적인 개념연결


7. 데이터 모델링의 중요한 세 가지 개념

데이터 모델링의 세 가지 요소

  • 업무가 관여하는 어떤 것(Things) =>엔터티
  • 어떤 것이 가지는 성격(Attributes) =>속성
  • 업무가 관여하는 어떤 것 간의 관계(Realtionships) =>관계

단수와 집합(복수)의 명명


8. 데이터 모델링의 이해관계자

이해관계자의 데이터 모델링 중요성 인식

구축하려는 시스템은 데이터에 기반한, 데이터가 중심에 있는 정보시스템이므로, 데이터베이스 설계를 잘못했을 경우 모든 프로그램, 시간에 따라 입력되는 모든 데이터, 데이터베이스에 발생되는 모든 트랜잭션에 영향을 미침

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


9. 데이터 모델의 표기법인 ERD 이해

데이터 모델 표기법

ERD 표기법으로 모델링하는 방법

ERD(Entity Relationship Diagram) : 각 업무 분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법
=> 업무에서 데이터의 흐름프로세스와의 연관성을 이야기하는 데 가장 중요한 표기법이자 산출물

ERD 표현 순서

  • ERD 작업순서
  • 엔터티 배치
    => 가장 중요한 엔터티는 왼쪽 상단, 업무 흐름의 중심이 되는 엔터티는 중앙, 업무를 진행하는 중심 엔터티와 관계를 갖는 엔터티는 중심 주위
  • ERD 관계의 연결
    => Primary Key로 속성이 상속되는 식별자 관계 설정, 중복되는 관계 X, Circle 관계 X
  • ERD 관계명의 표시
    => 현재형 사용, 지나치게 포괄적인 용어 X
  • ERD 관계 차수와 선택성 표시
    => 관계차수(Cardinality) : 엔터티 내에 인스턴스들이 얼마나 관계에 참여하는지
    => IE : 하나실선, 다수 참여는 까마귀발, 필수, 선택
    => 바커 : 점선실선 혼합

10. 좋은 데이터 모델의 요소

완전성

업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의 (Completeness)

중복 배제

하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록 (Non-Redundancy)
=> 저장 공간, 중복 관리 되는 데이터의 일관성 유지를 위해 데이터 조작데이터 관리 비용 낭비

업무 규칙

데이터 모델링 과정 중 도출되고 규명되는 수많은 업무 규칙(Business Rules)을 데이터 모델에 표현하고, 이를 해당 데이터 모델을 활용하는 모든 사용자공유할 수 있도록 제공
ex. 사원 구분별로 급여 항목을 차등적으로 지급받는 다는 업무 규칙을 데이터 모델에 표현

데이터 재사용

데이터가 애플리케이션에 독립적으로 설계되어야 데이터 재사용성(Data Reusability)를 높임

데이터 확장성, 유연성을 위해 데이터 관점통합 필요

데이터합리적으로 균형있으면서, 단순하게 분류
=> 사용/관리 측면 복잡하면 잘 만들어진 데이터 모델 X

잘 정돈된 방법으로 데이터를 통합하여 데이터 집합을 정의하고, 데이터 모델로 잘 표현, 활용하면 업무 변화에도 데이터 모델이 영향을 받지 않고 운용 가능

의사소통

업무데이터 관점에서 분석하고 이를 설계하여 나오는 최종 산출물이며, 데이터 분석 과정에서 많은 업무 규칙들이 도출되는데 해당 규칙들은 데이터 모델에 최대한 자세하게 표현되어야 함
=> 데이터 모델이 의사소통(Communication)의 도구로서 역할

통합성

가장 바람직한 데이터 구조 : 동일한 데이터조직 전체에서 한 번만 정의, 이를 여러 다른 영역에서 참조, 활용하는 것 (Integration)



🍔엔터티

1. 엔터티의 개념

엔터티 : 업무에 필요하고, 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)

  • 변할 수 있는 사물
  • 데이터베이스 내에서 변별 가능한 객체
  • 정보를 저장할 수 있는 어떤 것
  • 업무 활동상 지속적인 관심을 가져야 할 대상
  • 그 대상들 간에 동질성을 지닌 인스턴스들 또는 행하는 행위의 집합
  • 속성을 가짐
  • 엔터티인스턴스의 집합

2. 엔터티와 인스턴스에 대한 내용과 표기법

엔터티사각형으로 표현


3. 엔터티의 특징

업무에서 필요로 하는 정보

반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 함

식별 가능해야

유일한 식별자에 의해 식별이 가능해야 함
=> 인스턴스가 식별자에 의해 한 개씩만 존재하는지 검증

인스턴스의 집합

영속적으로 존재하는 인스턴스의 집합이어야 함 (두 개 이상의 인스턴스)

업무 프로세스에 의해 이용돼야

업무 프로세스가 그 엔터티를 반드시 이용해야 함
=> CRUD가 발생하지 않는 엔터티는 제거하거나 누락된 프로세스 추가

속성 포함

엔터티에는 반드시 속성이 포함되어야 함
=> 주식별자만 존재하고 일반속성은 없는 경우도 적절한 엔터티X (예외 : 관계 엔터티)

관계의 존재

다른 엔터티와 최소 한 개 이상의 관계 있어야 함

관계를 생략해 표현하는 경우

  • 통계를 위한 엔터티 : 업무진행 엔터티로부터 통계 업무만을 위해 별도로 엔터티를 다시 정의하게 되어 엔터티 간의 관계 생략
  • 코드를 위한 엔터티 : 너무 많은 엔터티와 엔터티 간의 관계 설정으로 인해 읽기 효율성이 저하되어 모델링 작업을 진행할 수 없게 됨, 물리적으로 테이블과 프로그램 구현 이후 외부키에 의한 참조무결성 체크를 DB 기능에 맡기지 않으므로 관계 설정할 이유 X
  • 시스템 처리 시 내부 필요에 의한 엔터티 : 트랜잭션이 업무적으로 연관된 테이블과 관계 설정이 필요하나, 시스템 내부적인 필요에 따라 생성된 엔터티이므로 관계 생략 ex.트랜잭션 로그 테이블

4. 엔터티의 분류

유무형에 따른 분류

유형엔터티 : 물리적인 형태가 있고, 안정적이며 지속적으로 활용되는 엔터티 (ex. 사원, 물품, 강사)
개념엔터티 : 물리적인 형태가 존재하지 않고, 관리해야 할 개념적 정보 (ex. 조직, 보험상품)
사건엔터티 : 업무를 수행함에 따라 발생하는 엔터티, 비교적 발생량많으며 각종 통계자료에 이용 (ex. 주문, 청구, 미납)

발생시점에 따른 분류

기본엔터티 : 업무에 원래 존재하는 정보, 다른 엔터티와 관계에 의해 생성X, 독립적으로 생성 가능, 자신은 타 엔터티부모 역할, 다른 엔터티로부터 주식별자 상속X, 자신의 고유한 주식별자 소유 (ex. 사원, 부서, 고객, 상품, 자재)
중심 엔터티 : 기본엔터티로부터 발생, 업무에서 중심적인 역할, 데이터의 양많이 발생, 다른 엔터티와의 관계를 통해 많은 행위엔터티 생성 (ex. 계약, 사고, 청구, 주문, 매출)
행위엔터티 : 두 개 이상의 부모엔터티로부터 발생, 자주 내용이 바뀌거나 데이터 양 증가, 상세 설계 단계나 프로세스와 상관 모델링 진행 중 도출 가능 (ex. 주문목록, 사원변경이력)


5. 엔터티의 명명

  • 현업 업무에서 사용하는 용어 사용
  • 약어 사용 X
  • 단수 명사
  • 모든 엔터티에서 유일하게 이름 부여
  • 엔터티 생성 의미대로 이름 부여 => 업무 목적에 따라 생성되는 자연스러운 이름 부여


🍟속성

1. 속성의 개념

속성(Attribute) : 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더이상 분리할 수 없는 최소의 데이터 단위

엔터티설명하고 인스턴스의 구성요소


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

엔터티, 인스턴스, 속성, 속성값의 관계

인스턴스속성집합, 하나의 속성하나의 인스턴스에만 존재

속성은 관계로 기술될 수 없고, 자신이 속성을 가질 수도 없음

  • 한 개의 엔터티두 개 이상인스턴스의 집합
  • 한 개의 엔터티두 개 이상속성
  • 한 개의 속성한 개의 속성값

속성의 표기법


3. 속성의 특징

  • 해당 업무에서 필요하고 관리하고자 하는 정보
  • 정규화 이론에 근거해 정해진 주식별자함수적 종속성을 가져야 함
  • 하나의 속성한 개의 값만을 가짐, 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용해 분리

4. 속성의 분류

속성의 특성에 따른 분류

기본속성 : 업무로부터 추출한 모든 속성, 엔터티에 가장 일반적이고 많은 속성
설계속성 : 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성 (ex. 코드성 속성, 일련번호)
파생속성 : 다른 속성영향을 받아 발생하는 속성, 데이터 정합성 유지를 위해 유의할 점이 많아 가급적 적게 정의 (ex. 계산된 값)

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

PK속성 : 엔터티를 식별할 수 있는 속성
FK속성 : 다른 엔터티와의 관계에서 포함된 속성
일반속성 : PK/FK에 포함되지 않은 속성

세부 의미를 쪼갤 수 있는가

  • 단순속성 : 더이상 다른 속성들로 구성될 수 없는 단순한 속성 (ex. 나이, 성별)
  • 복합속성 : 여러 세부 속성들로 구성 (ex. 주소)

가지고 있는 값의 수

  • 단일값속성 : 속성 하나에 한 개의 값 (ex.주민등록번호)
  • 다중값속성 : 여러 개의 값 (ex.전화번호) =>1차 정규화 또는 별도의 엔터티로 분리

5. 도메인

도메인(Domain) : 속성가질 수 있는 값범위

엔터티 내에서 속성에 대한 데이터타입크기, 제약사항을 지정


6. 속성의 명명

속성 이름을 정확하게 부여하고, 용어의 혼란을 없애기 위해 용어사전 사용

각 속성이 가지는 종류범위를 명확하게 하기 위해 도메인정의를 미리 정의

용어사전도메인 정의를 같이 사용해 프로젝트 진행시 용어적 표준데이터 타입일관성 확보

  • 해당 업무에서 사용하는 이름 부여
  • 서술식 속성명 X
  • 약어 사용 X
  • 전체 데이터 모델에서 유일성 확보 => 데이터 흐름 파악 및 정합성 유지에 도움


🌭관계

1. 관계의 개념

관계의 정의

관계(Relationship) : 엔터티의 인스턴스 사이논리적인 연관성으로서 존재 또는 행위로서 서로에게 연관성이 부여된 상태

관계의 패어링

패어링 : 인스턴스개별적으로 관계를 가지는 것
관계 : 패어링집합

관계 패어링 : 각각의 엔터티 인스턴스들이 자신과 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태


2. 관계의 분류

UML에는 연관관계의존관계가 존재

  • 연관관계 : 항상 이용하는 관계 (=존재적 관계)
  • 의존관계 : 상대방 클래스의 행위에 의해 관계 형성 (=행위적 관계)

ERD에서는 존재적관계행위적관계를 구분 X
클래스다이어그램에서는 연관관계실선으로 표현하고, 소스코드에서 멤버변수로 선언,
의존관계점선으로 표현, 소스코드에서 Method에서 파라미터 등으로 이용


3. 관계의 표기법

관계명

관계명(Membership) : 엔터티가 관계에 참여하는 형태 지칭

각각의 관계두 개의 관계명을 가지며, 각각의 관계명에 의해 두 가지의 관점으로 표현

관계시작점 : 관계시작되는 편
관계끝점 : 관계받는

관계 시작점끝점 모두 관계이름을 가져야 함

관계명 명명규칙

  • 애매한 동사 피하기 (ex. 관계된다, 이다, 한다 등은 구체적이지 않아 관계 파악 어려움)
  • 현재형으로 표현

관계차수

관계차수(Degree/Cardinality) : 관계에서 참여자의 수 표현

  • 1:1 관계
  • 1:M 관계
  • M:M 관계
    M:N 관계로 표현된 데이터 모델은 이후 두 개의 주식별자를 상속받은 관계엔터티를 이용해 3개의 엔터티로 구분하여 표현

관계선택사양

필수참여관계 : 참여하는 모든 참여자가 반드시 관계를 가지는, 타 엔터티의 참여자와 연결되어야 하는 관계

선택참여관계 : 참여할 수도 있고, 참여하지 않을 수도 있는 관계, FK로 연결될 경우 Null 허용 가능, 선택참여하는 엔터티 쪽으로 표시


4. 관계의 정의 및 읽는 방법

관계 체크사항

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

관계 읽기

  • 기준 엔터티한 개 또는 으로 읽는다
  • 대상 엔터티관계참여도, 즉 개수(하나, 하나 이상)를 읽는다
  • 관계선택사양관계명을 읽는다



🍿식별자

1. 식별자 개념

식별자(Identifier) : 하나의 엔터티에 구성된 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성

하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야 함

식별자논리 데이터 모델링 단계에서 사용, 키(Key)물리 데이터 모델링 단계에서 사용


2. 식별자의 특징


3. 식별자 분류 및 표기법

식별자 분류

식별자 표기법


4. 주식별자 도출기준

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

ex. 사원번호와 주민등록번호 중 회사에서 직원 관리 시 사원번호가 흔히 사용되므로 사원번호를 주식별자

명칭, 내역 등과 같이 이름으로 기술되는 것은 피함

ex. 부서 이름이 100개가 있을 때, 부서 이름을 주식별자로 지정하면 where 조건절에 정확한 부서 이름을 기술하기 쉽지 않으므로 보통 일련번호코드를 새로 생성해 주식별자로 지정

속성의 수가 많아지지 않도록 함

주식별자를 선정하기 위한 속성의 수가 많지 않도록 해야 하므로, 보통 새로운 인조 식별자를 생성해 데이터 모델을 구성

-- 많은 주식별자 속성을 가진 경우
SELECT 계약금 
FROM 접수 
WHERE 접수.접수일자 = '2010.07.15'
AND 접수.관할부서 = '1001'
AND 접수.입력자사번 = 'AB45588'
AND 접수.접수방법코드 = 'E' 
AND 접수.신청인구분코드 = '01' 
AND 접수.신청인주민번호 = '7007171234567' 
AND 접수.신청횟수 = '1';

--인조식별자 대체
SELECT 계약금 
FROM 접수 
WHERE 접수.접수일자 = '100120100715001';

5. 식별자관계와 비식별자관계에 따른 식별자

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

외부식별자(Foreign Identifier) : 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식쪽 엔터티에 생성되는 속성, DB생성시 FK역할

엔터티에 주식별자가 결정되고, 엔터티 간 관계를 연결하면 부모쪽의 주식별자자식엔터티속성으로 내려보냄
=> 자식엔터티에서 부모엔터티로부터 받은 외부식별자자신의 주식별자로 이용할지, 연결되는 속성으로만 이용할 것인지 결정

식별자관계

  • 부모로부터 받은 식별자자식엔터티주식별자로 이용하는 경우
  • Null값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자신의 엔터티가 생성
  • 부모로부터 받은 속성을 자식엔터티모두 사용하고, 그것만으로 주식별자 구성시 부모엔터티와 자식엔터티의 관계는 1:1, 부모로부터 받은 속성을 포함해 다른 부모엔터티에서 받은 속성 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성시 1:M 관계

비식별자관계

  • 부모로부터 속성을 받았지만 자식엔터티주식별자로 사용하지 않고, 일반적인 속성으로만 사용
  • 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하므로 부모 없는 자식이 생성될 수 있는 경우
  • 엔터티별로 데이터의 생명주기를 다르게 관리할 경우 (ex. 부모가 자식만 두고 먼저 소멸될 수 있는 경우)
  • 여러 개엔터티하나의 엔터티통합, 표현되었는데 각각의 엔터티별도의 관계를 가질 때
  • 자식엔터티에 주식별자로 사용해도 되지만, 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때

식별자 관계로만 설정할 경우의 문제점

plant 엔터티는 한 개의 속성만 PK속성이었는데, EQPEVTSTSHST 엔터티는 부모로부터 모두 식별자관계로 연결해 PK속성이 5개나 설정되었다.

1:M 관계의 식별자 관계PK속성의 수는 점점 늘어난다.

원 부모엔터티 : 12대 부모엔터티 : 2개 이상 = 원부모 1+ 추가 1개 이상 + 
3대 부모엔터티 : 3개 이상 = 원부모 1+ 21+ 추가 1개 이상 
3대 부모엔터티 : 3개 이상 = 원부모 1+ 21+ 31+ 추가 1개 이상 
4대 부모엔터티 : 4개 이상 = 원부모 1+ 21+ 31+ 4 1+ 추가 1개 이상 ....

식별자관계 만으로 연결된 데이터 모델의 특징
: 주식별자 속성지속적으로 증가할 수 밖에 없는 구조로서 개발 복잡성오류 유발 요인

비식별자관계로만 설정할 경우의 문제점

주민등록번호, 사원번호와 같이 중요한 속성이 비식별자관계로 설정되면 자식엔터티로 상속되지 않아 자식엔터티에서 데이터 처리 시 쓸데없이 부모엔터티까지 찾아가야 함

식별자관계와 비식별자관계 모델링

  • 비식별자관계 선택 프로세스
    : 기본적으로 식별자관계모든 관계가 연결되면서 다음 조건에 해당시 비식별자관계로 조정,
    가장 중요한 요인은 자식엔터티독립된 주식별자 구성필요한지 분석
  • 식별자와 비식별자관계 비교
  • 식별자와 비식별자를 적용한 데이터 모델
profile
MSSQL DBA 신입

0개의 댓글