[데이터 아키텍처 준전문가(DAsP)] 과목 4. 데이터 모델링 (2) 개념 데이터 모델링

1. 주제 영역 정의

1) 주제 영역 분류 원칙 및 기준

항목	상세 내용
주제 영역 분류 원칙	• 데이터 중복 최소화 • 데이터 확장성 보장 • 데이터 관련성 및 편의성 확보
주제 영역 명명	• 업무에서 사용되는 업무 영역 부여 • 유일한 단수형 명사 사용 • 데이터 그룹 의미 이름 부여
주제 영역 정의 절차	데이터 현황 분석/DA 원칙 및 방향성 분석/선진 모델 분석 → 데이터 분류 지침 정의 → 주제 영역 분류 및 정의 → 주제 영역 도식화
주제 영역 분류 방법	• 1차 분류 : 기존 시스템별 데이터 성격 및 특성을 고려하여 주요 데이터 집합 유형 정의 • ex) 데이터 발생 주체, 데이터 발생 주체 간의 상호작용으로 발생하는 대상, 공통/관리 성격의 상위 개념으로서 분류 • 2차 분류 : 비즈니스 활동에 필요한 분석 주제와 현황 등의 영역으로 분류 (1차 분류를 세분화) • ex) 관계자 기본, 관계자 상세 등 • 3차 분류 : 2차 분류 세분화 • ex) 관계자 : 고객, 법인, 조직, 직원 등 / 계약 : 수신계약, 예금계약, 신탁계약 등 • ⇒ 업무 활동을 의미하는 이름 배제 / 데이터 그룹을 의미하는 이름 사용

 

 

2) 주제 영역 활용

• 주제 영역은 데이터의 계층 구조 파악, 품질 확보에 기여
• 효율적 데이터 관리를 위한 기준 제공
• 데이터 구성 및 통합에 대한 방향 제시
• 기업의 전체 데이터 구성에 대한 청사진 제공

 

3) 주제 영역 정의 내용 도출

• 업무에서 사용하는 데이터의 명사형 도출
• 업무 기능의 이름으로부터 도출
• 하향식 (Top-dowm) 접근 방법 : 주제 영역에서 출발하여 엔터티 타입으로 전개
• 상향식 (Bottom-up) 접근 방법 : 엔터티 타입을 그룹화하여 주제 영역 도출
• 분석 단계에서의 도출 : 아키텍처 모델 정련 과정 / 데이터 모델 상세화에서 도출

 

2. 후보 엔터티 선정 ✅️

항목	상세 내용
엔터티 후보 수집	•  기존 시스템 도규먼트 •  현업 장표/보고서 : 자료에 기술된 항목을 속성이라고 가정하여, 본질적인 집합(원재로) 도출 •  데이터 흐름도 (DFD) : 데이터 저장소, 데이터 사전 등 •   현업 인터뷰 •   관련 전문 서적 •   타 시스템 자료 •   현장 조사 •   자료 흐름도 (애플리케이션 개발 표준 정의서 x)
엔터티 후보 식별	•  엔터티 후보 개념 정립 : 단어가 의미하는 집합 정의 (사원 : 근무자 or 사단법인, 관계사, 협력사) •  관리 대상 판정 •  집합 여부 확인 : 가로(속성) * 세로(개체) = 면적 = 집합
엔터티 후보 선정 시 유의사항	•  엔터티 가능성이 있을 경우, 검토 대상에 올림 (후보 자격의 여부만 따지기) •  동의어처럼 보이더라도 함부로 버리지 않음 (모델링 뒷부분에서 동의어로 보이는 후보를 집합의 정의에 따라 통합) •  개념이 모호한 대상은 1차로 개념을 상식화하여 이해 •  프로세스/예외 경우에 너무 연연하지 말기 •  단어 하나하나에 집중해서 판단

 

 

✔️ 엔터티 분류

항목	상세 내용
키 엔터티	• 자신의 부모를 가지지 않는 엔터티 • 모델 내 주어 역할 • 하위 엔터티의 탄생 유도 • 시스템의 기본 정보 • ex) 사원, 부서, 고객, 상품, 자재 등
메인 엔터티	• 업무의 중심에 해당하는 엔터티 • 키 엔터티의 관계에 의해 만들어짐 (고객과 상품 관계에서 주문이 만들어짐) • ex) 보험계약 사고, 구매의뢰, 주문, 매출 등
액션 엔터티	• 키/메인 엔터티 제외한 나머지 엔터티 • 부모 없이 존재할 수 없음 • 상위 엔터티들의 영향을 크게 받기에 모델링 후반에 크게 변경될 수 있음 • ex) 상태 이력, 차량 수리 내역 등

 

 

3. 핵심 엔터티 정의

1) 엔터티 정의 요건

항목	상세 내용
엔터티 정의	• 관리하고자 하는 것인지 확인 • 가로, 세로를 가진 면적인지 확인 • 대상 개체 간의 동질성 있는지 확인 • 다른 개체와 구분되는 독립성을 가지는지 확인 • 순수한 개체 or 행위 집합인지 확인
엔터티 정의 시 고려사항	• 특정 업무를 수행하는 과정에서 파생되는 엔터티는 데이터로서 안정성 고려 • 의미있고 직관적으로 이해 가능한 간단명료한 이름 부여 • 현업 사용자와 공동 작업을 통한 반복적인 검토 및 수정 필요
엔터티 결정 기준 단계 ✅️	1) 향후 관리 여부 확인 (필요한 데이터인지 확인) 2) 관리 대상 판정 (실제 업무에서 관리해야 하는 대상인지 확인) 3) 집합 여부 확인 (엔터티가 될 수 있는 집합 형태인지 확인)
엔터티 파악 요령	• 업무 기술서 활용 • 현업 담당자와의 인터뷰 활용 • 기준 시스템 산출물 검토 • DFD를 통해 업무 분석을 진행했다면, DFD의 Data Store 활용 • 현업 업무를 직접 견학 → 인터뷰와 업무 기술서에서 누락된 정보있는지 검토 • 현재 업무에 나타나지 않았지만 BPR (Business Processing Reengineering)에 의해 업무를 재정의한 경우, 관련 엔터티 찾아야 함
엔터티 특징	• 업무에 필요한 정보 • 의미 있는 식별자에 의해 인스턴스는 1개씩만 존재 (중복 배제) • 2개 이상의 인스턴스 집합으로 구성 • 업무 프로세스에 의해 이용 • 속성 포함해야 함 (식별자만 있으면 x) • 관계 존재해야 함 • 엔터티는 집합이어야 하지만 모든 집합이 모두 엔터티가 되는 것은 아님
엔터티 도출 산출물	• 현행 업무 분장표 • 현행 업무 흐름도 • 현행 시스템 분석서 • 현행 요구사항 정의서

 

 

✔️ 엔터티 분류

항목	명칭	설명
유무형	유형 엔터티	물리적 형태가 있음 (ex. 사원, 물품, 강사)
	개념 엔터티	물리적 형태가 없음 (ex. 조직, 보험 상품)
	사건 엔터티	업무 수행에 따라 발생 (ex. 주문, 청구, 미납)
발생 시점	기본 엔터티	원래 존재하는 정보 (ex. 사원, 부서, 고객, 상품)
	중심 엔터티	• 기본 엔터티로부터 발생, 다른 엔터티와의 관계를 통해 많은 행위 엔터티 발생 • 업무에 있어 중심 역할 • ex. 계약, 사고, 청구, 주문
	행위 엔터티	• 2개 이상의 부모 엔터티로부터 발생 • 내용이 자주 변경 및 데이터 양 증가 • ex. 주문 목록, 로그인 이력

 

 

✔️ 엔터티 정의서 예시

엔터티명	엔터티 설명	동의어/유의어	관련 속성
도서	인터넷을 통해 판매하고자 하는 책의 정보	책	• 도서 번호 • 도서명
회원	인터넷을 통해 등록한 회원의 정보	일반 회원	• 주민번호 • 주소 • 전화번호 • 이메일
주문	도서를 구매하기 위해 회원이 입력한 배송지, 결제 방법에 대한 정보	주문서, 주문내역	• 주문번호 • 주문일자 • 배송지 주소 • 배송방법 • 결제방법
주문목록	회원이 주문한 도서 목록에 대한 수량 및 가격	구매 도서 목록	• 수량 • 단가

 

 

2) 의미상 주어 정의 (본질 식별자)

• 가주어 : 인조 식별자 / 진주어 : 엔터티의 의미상 주어 (본질 식별자)
• 본질 식별자 : 집합의 인스턴스가 생성되는 단위
• 집합의 의미가 명확하게 정의되지 않은 모호한 집합에 인위적인 유일한 이름을 붙인다고 해서 집합의 정의가 명확해지지 않음

 

3) 코드성 키 엔터티 모델링

• 코드성 키 엔터티를 개념 모델링 단계에서 모두 도출하면, 추후 복잡해질 수 있기 때문에 아래의 기준에 맞게 도출하는 것이 좋음
  • 자식 엔터티를 가지는지?
  • 자신만의 다양한 속성을 가지는지?
  • 여러 엔터티에 관계를 맺을 것인지?
  • 다양한 종류의 관계를 맺을 것인지?
• 다른 엔터티의 본질 식별자가 되고 있는지 판단
  • 해당 엔터티로 인해 다른 엔터티의 존재 종속의 문제가 발생하면 반드시 도출해야 함
• 단순한 코드명, 코드 의미에 대한 설명 외에 또 다른 속성을 가지는지 확인
  • 독립적인 개체 집합으로서 의의가 있음
• 관계 존재 여부 확인
  • 다양한 관계를 많이 맺고 있는 엔터티를 누락시키면 앞으로 정의할 관계도 같이 누락될 가능성이 이 있음

 

4) 집합 순수성

• 순수한 본질 집합
• 사람, 상품 등과 같이 단위 사물을 정의한 개체 집합
• 입금, 계약 등과 같은은 행위 집합
• 서로 결합된 형태 → 관계
• ex) 납입자 : 순수 본질 집합인 ‘고객’과 ‘납입’이 결합된 관계임

✔️ 집합 순수성 적용 예외 사항

항목	상세 내용
관계의 엔터티화	관계가 M:N이 되면 관계로 존재할 수 없기에 엔터티로 바꾸게 됨 → 이를 릴레이션 엔터티, 제휴 엔터티, 교차 엔터티 등으로 부름
일부 집합 정의	전체 집합 중 일부 집합만 엔터티로 정의할 때 ex) 금융기관 : 기관의 부분으로서 엔터티, 수납기관 : 관계
배타적 관계 대체	여러 엔터티와 동일한 내용의 관계를 갖는 배타적 관계를 맺을 때, 배타적 관계의 변화 가능성이 높다면 별도의 엔터티 구성

 

 

5) 집합 동질성

• 집합에 들어갈 개체들의 동일한 성질을 어디까지로 한정할 것인가를 결정
• ex) 사람의 집합이라고 규정
  • 사람만의 집합, 상품과 구체적인 관계를 맺은 사람만 존재하는 집합으로 정의했다는 특수성이 나타나야 함
• ex) 사람 또는 법인이라고 규정
  • 위의 집합들을 분명하게 포함시켰다는 것을 내포

 

6) 엔터티 명칭

• 함축적인 의미를 담고 있어 설명하지 않아도 오해를 최소화할 수 있어야 함
• 엔터티 명칭 정할 때, 실무자와 해당 분야 전문가의 의견을 종합하고 이를 구성원 간에 합의하는 것 필요

 

7) 서브타입

항목	상세 내용
서브타입 지정 의의	• 구체적인 부분 집합의 종류 (서브타입) 명시 • ERD를 입체적, 구체적으로 작성하기 위해 집합의 부분집합을 표현해야 함 • 실세계에서 동일한 것 • 추가 속성 • 서브타입에서 상호배타적인 다수의 카테고리가 형성될 수 있음 • ex) 서브타입 (의사, 간호사, 기술직, 사무직)은 수퍼타입(직원)의 부분집합
서브타입 지정 시 고려사항	• 교집합 허용 불가 • 서브타입의 합이 전체 집합 • 서브타입 표현 기준 : 개별 속성/개별 관계를 가질 때, 가독성 증진시킬 때
서브타입 도출	• 분류 속성 : 엔터티의 정보가 차별화되는 경우 • 다수의 선택적 속성 • 선택적 관계가 존재하는 경우 : 분할함으로써 관계가 필수적으로 변하는지 확인 [도출 절차] 1) 분류 속성 확인 (엔터티 발생이 차별화되는 경우) 2) 분류 속성값에 의해 분류되는 서브타입 파악 3) 분류 속성에 따라 필수적/선택적 분할 정의 4) 서브타입별 속성 할당 5) 슈퍼타입의 관계를 해당 서브타입에 정의
서브타입 활용	• 데이터 모델에 업무 규칙을 명확히 표현하여 업무를 정확히 이해하고, 속성 및 관계의 선택성을 제거 • 서브타입의 표현은 업무 규칙의 명확성과 표현의 복합성이라는 트레이드 오프 관계가 적절히 조화를 이루어야 함
서브타입 이해	• 인스턴스들의 집합인 엔터티라는 전체 집합에서 일부의 인스턴스들만 모아놓은 부분집합 • 하나의 엔터티에 무수히 많은 부분집합을 만들 수 있음
서브타입 명	• 하나의 엔터티에서 만들어진 서브타입에 부여된 이름 • 어떤 인스턴스들의 집합인지 잘 나타낼 수 있는 용어
서브타입 세트	• 하나의 기준으로 도출된 서브타입의 모임 • ex) ‘고객유형’이라는 특성으로 구분 → 개인고객, 법인 고객 ⇒ 서브타입 세트
서브타입 세트명	• 서브타입을 도출하기 위해 사용된 기준이 되는 속성 • ex) 고객유형 • 서브타입을 표현하기 위한 속성이 반드시 물리적으로 존재할 필요 없음
서브타입 특징	• 서브타입의 전체집합이 반드시 엔터티일 필요 없음 • 하나의 서브타입을 전체집합으로 하는 하위 서브타입 정의 가능 • 전체집합을 ‘슈퍼타입’으로 부름 • ex) 엔터티가 서브타입 생성 → 엔터티 : 슈퍼타입 / 하나의 서브타입에 하위 서브타입 생성 → 상위 서브타입 : 슈퍼타입

 

 

8) 엔터티 통합과 분할

항목	상세 내용
엔터티의 독립성	• 새롭게 정의할 엔터티가 기존의 엔터티에 포함되지 않는 독립적인 집합인지 확인
엔터티의 분할/통합	집합의 일부가 겹쳐 있을 때 • 어느 한 집합을 확장하여 나머지 포함 • 교차된 부분을 한쪽 집합에서만 가지도록 분리 • 교차되는 부분이 있더라도 두 집합을 별개의 집합으로 간주 & 필요 시, 관계 설정
유연성 향상을 위한 통합	• 동질성을 확장해 중첩된 집합을 포함시키면 집합적 관계는 명확해짐 • 유연성과 단순성 향상되지만 지나친 확장은 집합의 의미를 희석시킴

 

 

4. 관계 정의

항목	상세 내용
관계 정의	개체 간의 관계 또는 속성 간의 관계 [관계 유형] •  1:1 : 개체 집합 A의 각 원소가 B의 원소 1개와 대응하는 관계 •  1:N : 개체 집합 A의 각 원소가 B의 원소 여러 개와 대응하는 관계 & B의 각 원소는 A의 원소 1개와 대응하는 관계 •  N:M : 개체 집합 A의 각 원소가 B의 원소 여러 개와 대응하는 관계 & B의 각 원소는 A의 원소 여러 개와 대응하는 관계
관계 이해	•   관계도 집합에 해당 •   직접 종속인 것만 관계라고 함 •   두 엔터티 간에는 하나 이상의 관계가 존재할 수 있음 •   외래키 (FK)로 정의 [관계의 관점] •   항상 두 엔터티 간에 존재, 항상 2개의 관점을 가짐 •   데이터의 양방향 업무 규칙을 표현 •   관계를 통해 정보로서의 활용 가치 상승 •   관계는 외래키로 구현되어 참조 무결성으로 데이터 정합성 유지의 역할을 함
관계 표현	[관계 형태 (Degree / Cardinality)] •  하나 이상 (Many) : 1:M 관계는 1:1 관계가 포함되어 있음 •  단 하나 (Only One) [선택 사양 (Optionality)] •  점선은 존재하지 않을 수 있으며, 직선은 반드시 존재 [관계명의 부여] •  2개의 관계 멤버십에 각각 부여 •  현업에서 사용하는 가결한 동사형으로 표현     •   현재 시제 사용, 다른 관계명과의 유일성은 확보되지 못함     •   능동/수동형은 가급적 배제 •  업무적 의미가 없거나 애매모호한 용어 배제 •  관계명 부여의 중심이 되는 엔터티에서 봤을 때, 관계의 시계방향에 위치 [관계 수]
관계의 패어링 (pairing)	•  엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것 •  패어링의 집합 → 관계
관계의 표기법	•  관계명 (Membership) : 관계의 이름 •  관계차수 (Cardinality) : 1:1, 1:M, M:N •  관계선택사양(Optionality) : 필수관계 (not null), 선택관계 (nullable, O 표시)

 

 

 

✔️ 관계 형태

관계	상세 내용	이미지
1:1 관계	- 필수-선택 관계 : 한쪽은 실선, 한쪽은 점선 - 필수-필수 관계 : 양쪽 모두 실선, 수직 분할 시 발생 - 선택-선택 관계 : 양쪽 모두 점선, 나중에 테이블 설계 시, 합집합을 만들어야 함
1:M 관계	- Both Side Mandatory : 주문 - 주문품목 - One Optional : 사원 - 부서 - Many Optional : 대금청구 - 납품 - Both Side Optioanl : 고객 - 좌석예약
M:N 관계	- 모델링이 완료된 후, M:N은 존재하지 않으며, 새로운 관계를 도출하여 해소해야 함 - M:N을 분해 시, 1:M으로 되는 것은 아니며 완전 해소까지 분해해야 함
다중 관계 처리	- 두 엔터티 간에 하나 이상의 관계를 가지고 있는 형태 - 병렬식 관계 : 별도의 관계로 간주하여 여러 개의 관계 선으로 나타냄     - 테이블이 될 때 여러 개의 컬럼으로 나열     - 하나의 로우에서 관리되므로 새로운 테이블 추가 필요 없음     - 인덱스 수가 증가하고 SQL이 복잡해짐     - 새로운 관계의 추가, 관계 형태의 변경 등에 매우 취약함     - 관계 내용 별로 상세 정보를 관리할 수 없으며, 관리하려면 새로운 엔터티를 추가해야 함 - 직렬식 관계 : 몇 개의 관계를 모아 상위 개념으로 통합하여 하나의 관계로 관리     - 관계들을 관리하는 새로운 엔터티가 추가되어야 함     - 관계들이 로우 형태로 나타남     - 인덱스 수가 감소하고 SQL이 단순해짐     - 새로운 관계의 추가, 관계 형태의 변경 등에 매우 유연함     - 관계 내용별로 상세 정보 관리 가능 (자식 엔터티를 거느릴 수 있음)
특수 형태 관계	- 순환 관계 : 자기 자신과 관계를 맺음     - 하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함해야 함     - 각 계층에 있는 속성은 동일하게 하는 것이 좋음     - 순환 모델은 필수(직선) 관계로 할 수 없고, 반드시 선택 관계     - 조직의 변경(추가/삭제)에 쉽게 대응 가능 - BOM (Bill of Materials) 관계 : 네트워크 구조 - Arc (Mutually Exclusive) 관계 : 어떤 엔터티가 2개 이상의 엔터티의 합집합과 관계를 가짐     - 아크 내 관계는 보통 동일함     - 관계는 항상 필수거나 선택 사양이어야 함     - 아크는 반드시 하나의 엔터티에만 속해야 함 (하나의 아크가 여러 엔터티를 가질 수 없음)     - 어떤 엔터티는 다수의 아크를 가질 수 있으나, 지정된 관계는 단 하나의 아크에만 사용되어야 함

 

 

5. 관계 데이터 모델

1) 관계 데이터 모델 ✅️

• 개념적 구조를 논리적 구조로 표현하는 논리적 데이터 모델
• 하나의 개체에 대한 데이터를 하나의 릴레이션에 저장

용어	상세 내용
릴레이션 (relation)	• 하나의 개체에 대한 데이터를 2차원 테이블의 구조로 저장한 것 • 파일 관리 시스템 관점에서 파일에 대응
속성 (attribute)	• 릴레이션의 열에 해당 • 파일 관리 시스템 관점에서 필드에 대응
투플 (tuple)	• 릴레이션의 행에 해당 • 파일 관리 시스템 관점에서 레코드에 대응
도메인 (domain)	• 하나의 속성이 가질 수 있는 모든 값의 집합 • 속성 값을 입력 및 수정할 때 적합성의 판단 기준이 됨 • 속성의 특성을 고려한 데이터 타입으로 정의
널 (null)	• 속성 값을 모르거나 해당되는 값이 없음을 표현 • 정보 부재를 나타내기 위해 사용 • 공백, 0 과는 다른 의미
차수 (degree)	하나의 릴레이션에서 속성의 전체 개수
카디널리티 (cardinality)	하나의 릴레이션에서 투플의 전체 개수

 

 

2) 릴레이션의 구성

항목	상세 내용
릴레이션 스키마	• 릴레이션의 논리적 구조 • 릴레이션의 이름과 릴레이션에 포함된 모든 속성 이름으로 정의 • ex) 고객 : 고객ID, 고객이름, 나이, 등급, 직업 등 • 릴레이션 내포 (relation intension)라고 함 • 정적인 특징이 있음
릴레이션 인스턴스	• 어느 한 시점에 릴레이션에 존재하는 투플의 집합 • 릴레이션 외연 (relation extension)이라고 함 • 동적인 특징

 

 

3) 릴레이션의 특성

관계 데이터 모델에서 4가지 특성을 모두 만족해야 릴레이션으로 인정 받음

항목	상세 내용
투플의 유일성	하나의 릴레이션에는 동일한 투플이 존재할 수 없음
투플의 무순서	하나의 릴레이션에서 투플 사이의 순서는 무의미함
속성의 무순서	하나의 릴레이션에서 속성 사이의 순서는 무의미함
속성의 원자성	속성값으로 원자값만 사용 가능함

 

 

4) 데이터베이스 구성

• 데이터베이스 스키마 : 데이터베이스 전체 구조 / 데이터베이스를 구성하는 릴레이션 스키마 모음
• 데이터베이스 인스턴스 : 데이터베이스를 구성하는 릴레이션 인스턴스 모음

 

✔️ 데이터베이스 특성 ✅️

• 데이터베이스는 계속적으로 변화함
• 데이터베이스는 실시간으로 접근함
• 데이터베이스는 동시 공용임

 

5) 키 (key)

• 릴레이션에서 투플을 구별하는 구별하는 속성 또는 속성의 집합
• 중복 여부를 알 수 있는 수단

• 유일성 : 하나의 릴레이션에서 모든 투플은 서로 다른 키 값을 가져야 함
• 최소성 : 꼭 필요한 최소한의 속성들로만 키를 구성해야 함

항목	상세 내용	예시
슈퍼키 (super key)	유일성을 만족하는 속성 또는 속성 집합	고객ID, (고객ID, 고객이름), (고객이름, 주소) 등
후보키 (candidate key)	유일성과 최소성을 만족하는 속성 또는 속성 집합	고객ID, (고객이름, 주소) 등
기본키 (primary key)	후보키 중 투플을 식별하는데 사용할 키	고객ID
대체키 (alternate key)	후보키 중 기본키로 선택되지 못한 키	(고객이름, 주소)
외래키 (foreign key)	• 다른 릴레이션의 기본키를 참조하는 속성 또는 속성 집합 • 릴레이션 간 관계 표현 • 외래키가 여러 개 존재할 수 있고, 기본키로도 사용 가능 • 같은 릴레이션의 기본키를 참조하는 외래키도 정의할 수 있음 • 외래키 속성은 null값을 가질 수 있음

 

 

6) 관계 데이터 모델의 제약

• 무결성 : 데이터의 결함이 없는 상태, 정확하고 유효하게 유지
• 개체 무결성 제약조건 : 기본키를 구성하는 모든 속성은 null값을 가질 수 없다
• 참조 무결성 제약조건 : 외래키는 참조할 수 없는 값을 가질 수 없다

---

 

✔️ Role name (역할명)

• 부모 엔터티로부터 속성(주식별자)을 상속 받았을 때, 자식 엔터티에서 그 속성이 수행하는 역할을 명확히 하기 위해 이름을 다르게 붙이는 것
• 다른 개체의 속성을 가져와서 속성명을 다르게 정의
• 여러 개체가 동일한 개체를 참조하는 경우, 속성명을 다르게 정의해야 할 필요성이 높아짐

---

 

📌 참고 포스팅 📌

[데이터 모델링] 2. 개념적 데이터 모델링