데이터 모델링의 개념, 엔티티, 속성, 관계, 식별자, 특징, 표기법, 명명법 등을 알아보자
모델
: 일정한 표기법에 따라 표현해 놓은 모양
모델링
: 이것을 표기법
에 따라 표기하는 것 자체
현실세계
를 단순화
해 표현사물
이나 사건
에 대한 양상이나 관점을 명확화
추상화(모형화)
한 반영추상화
: 현실세계
를 일정한 형식
에 맞추어 표현
단순화
: 복잡한 현실세계를 제한된 표기법
이나 언어
로 표현해 쉽게 이해하도록 함
명확화
: 누구나 이해하기 쉽게
하기 위해 대상에 대한 애매모호함 제거
, 정확하게 현상 기술
모델링은 계획-분석-설계
단계에서 업무 분석 및 설계할 때, 구축-운영
에서 변경 및 관리 시 이용
데이터 관점
: 업무가 어떤 데이터
와 관련 있는지, 데이터 간의 관계
는 무엇인지 (What, Data)
프로세스 관점
: 실제
하고 있는 업무는 무엇
인지, 무엇을 해야 하는지
를 모델링 (How, Process)
데이터와 프로세스의 상관 관점
: 업무가 처리하는 일의 방법
에 따라 데이터
는 어떻게
영향을 받고 있는지 (Interaction)
정보시스템
을 구축
하기 위한 데이터 관점
의 업무 분석 기법
현실세계
의 데이터
에 대해 약속된 표기법
에 의해 표현하는 과정데이터베이스
를 구축
하기 위한 분석, 설계
의 과정데이터 모델링
자체로서 업무를 설명
하고 분석
하는 부분에도 중요
현재
또는 원하는 모습
으로 가시화
하도록 도와줌구조
와 행동
을 명세화
구축
하는 구조화된 틀
제공결정
한 것을 문서화
다른 영역의 세부 사항
은 숨기
는 관점 제공구체화한 상세 수준
의 표현방법
제공시스템 구축이 완성되어 가는 시점에 테스트를 하는데, 이 시점에 데이터 모델
의 변경이 불가피하다면 데이터 구조 변경
에 따른 표준 영향 분석
, 응용 변경 영향 분석
등 많은 영향 분석
이 필요하고 이후 실제적인 변경작업이 이뤄짐
=> 전체 시스템 구축 프로젝트
에서 큰 위험요소
데이터 모델은 정보 요구 사항
과 한계
를 가장 명확
하고 간결
하게 표현
데이터의 정확성
이 떨어지면 해당 데이터로 얻을 수 있던 비즈니스 기회 상실
중복 데이터
의 미정의, 데이터 구조에서 비즈니스 정의 불충분
, 동일한 성격의 데이터를 통합하지 않고 분리
함으로써 데이터 불일치
등의 데이터 구조
문제로 인해 데이터 품질
은 바로잡기 불가능한 경우가 대부분
데이터 모델링 시 유의
중복
: 데이터베이스
가 여러 장소에 같은 정보
를 저장하지 않도록 함비유연성
: 사소한 업무 변화
에도 데이터 모델
이 수시로 변경
되어 유지보수 어려움
데이터 정의
를 데이터 사용 프로세스
와 분리
하여 데이터
혹은 프로세스
의 변화가 애플리케이션과 DB에 중대한 변화를 일으킬 가능성 줄임비일관성
: 데이터 중복이 없더라도 비일관성(Inconsistency)
발생일련의 데이터를 수정할 수 있기
때문데이터
와 데이터 간 상호 연관 관계
에 대한 명확한 정의
필요개념적 데이터 모델링
: 추상화 수준
이 높고, 업무 중심적
이고 포괄
적인 수준
ex. 전사적 데이터 모델링
, EA 수립
논리적 데이터 모델링
: 시스템
으로 구축하고자 하는 업무
에 Key
, 속성
, 관계
등을 정확
하게 표현, 재사용성 높음
물리적 데이터 모델링
: 실제로 데이터베이스에 이식
할 수 있도록 성능
, 저장
등 물리적인 성격
고려
데이터 요구사항
을 찾고 분석에서 시작
핵심 엔터티
와 그들 간의 관계
를 발견하고, 표현하기 위해 엔터티-관계 다이어그램
을 생성
전사적 데이터 모델
: 데이터 모델링 과정
이 전 조직에 걸쳐
진행시
개념 데이터 모델을 통해 조직의 데이터 요구
를 공식화
=> 사용자와 시스템 개발자가 데이터 요구사항
을 발견
지원
(개념 데이터 모델
은 추상적
이라 상위의 문제에 대한 구조화
를 쉽게
하며, 시스템 기능
에 대해 논의할 수 있는 기반 제공
)
=> 현 시스템이 어떻게 변형
되어야 하는가를 이해
하는 데 유용
데이터 설계 프로세스
의 Input
으로서 비즈니스 정보의 논리적인 구조
와 규칙
을 명확
하게 표현
논리 데이터 모델
은 데이터 모델링이 최종적으로 완료된 상태
=> 물리적인 스키마
설계 전 단계의 데이터 모델 상태
누가
데이터에 액세스, 어떻게
데이터에 액세스, 그리고 전산화와는 별개로 비즈니스 데이터
에 존재하는 사실
들을 인식하여 기록
데이터 모델링 과정
에서 가장 핵심
정규화
: 논리 데이터 모델
상세화 과정의 대표적 활동
, 논리 데이터 모델
의 일관성
을 확보하고 중복 제거
하여 속성
들이 가장 적절한 엔터티
에 배치되도록 하여 신뢰성
있는 데이터 구조 얻음
논리 데이터 모델의 상세화
: 식별자 확정
, 정규화
, M:M 관계 해소
, 참조 무결성 규칙 정의
, 이력 관리
등
논리 데이터 모델
이 데이터 저장소
로서 어떻게 컴퓨터 하드웨어
에 표현될 것인가
물리적 스키마
: 데이터가 물리적
으로 컴퓨터에 어떻게 저장
될 지에 대한 정의
=> 테이블
, 칼럼
등으로 표현되는 물리적인 저장 구조
와 사용될 저장 장치
, 자료를 추출하기 위해 사용될 접근 방법
등 결정
폭포수
: 데이터 모델링의 위치가 분석, 설계 단계로 구분되어 명확하게 정의
정보공학/구조적 방법론
: 분석
단계에서 업무 중심
의 논리적 데이터 모델링
수행, 설계
단계에서 하드웨어
와 성능
을 고려한 물리적 데이터 모델링
수행
나선형 모델
: 업무 크기
에 따라 논리적
/물리적
데이터 모델이 분석, 설계
단계 양쪽에서 수행, 일반적으로 분석 단계
에서 논리적 데이터 모델
이 더 많이 수행
객체지향 모델
: 데이터 모델링과 프로세스 모델링을 구분하지 않고 일체형
으로 진행
ex. 클래스
자신이 가지는 고유한 특징
을 명확하게 하고, 다른 기능의 변경
으로부터 쉽게 변경되지 않고
, 자신의 고유한 기능
을 가지고 기능을 제공 가능
지속적
으로 증가하는 유지보수 비용 절감
, 데이터 복잡도 낮춤
, 중복된 데이터
를 줄임
, 사용자 요구사항
에 대한 화면
과 데이터베이스
간 서로 독립성
을 유지하기 위한 목적
데이터 독립성
확보
시
=> 각 뷰
의 독립성
유지, 계층별 뷰
에 영향을 주지 않고 변경 가능
=> 단계별 스키마
에 따라 데이터 정의어
와 데이터 조작어
가 다름을 제공
외부 단계
: 사용자
와 가까운 단계, 사용자 개개인
이 보는 자료에 대한 관점
=> 사용자가 처리하고자 하는 데이터 유형/관점/방법
에 따라 다른 스키마 구조
개념 단계
: 사용자가 처리하는 데이터 유형의 공통적인 사항
을 처리하는 통합된 뷰
=> 데이터 모델
은 사용자가 처리하는 통합된 뷰
를 설계하는 도구
내부적 단계
: 데이터가 물리적
으로 저장된 방법
상호 독립적인 개념
을 연결
어떤 것(Things)
=>엔터티
성격(Attributes)
=>속성
관계(Realtionships)
=>관계
구축하려는 시스템은 데이터
에 기반한, 데이터
가 중심에 있는 정보시스템이므로, 데이터베이스 설계를 잘못했을 경우 모든 프로그램
, 시간에 따라 입력되는 모든 데이터
, 데이터베이스
에 발생되는 모든 트랜잭션
에 영향을 미침
ERD(Entity Relationship Diagram)
: 각 업무 분석에서 도출된 엔터티
와 엔터티간의 관계
를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법
=> 업무에서 데이터의 흐름
과 프로세스와의 연관성
을 이야기하는 데 가장 중요한 표기법
이자 산출물
ERD 표현 순서
ERD 작업순서
엔터티 배치
왼쪽 상단
, 업무 흐름의 중심이 되는 엔터티는 중앙
, 업무를 진행하는 중심 엔터티와 관계를 갖는 엔터티는 중심 주위
ERD 관계의 연결
Primary Key
로 속성이 상속되는 식별자 관계
설정, 중복되는 관계 X, Circle 관계 XERD 관계명의 표시
현재형
사용, 지나치게 포괄적인 용어
XERD 관계 차수와 선택성 표시
관계차수(Cardinality)
: 엔터티 내에 인스턴스
들이 얼마나 관계에 참여
하는지IE
: 하나
는 실선
, 다수 참여는 까마귀발
, 필수, 선택
은 원
바커
: 점선
과 실선
혼합
업무
에서 필요
로 하는 모든 데이터
가 데이터 모델에 정의 (Completeness)
하나의 데이터베이스 내에 동일한 사실
은 반드시 한 번만 기록
(Non-Redundancy)
=> 저장 공간
, 중복 관리
되는 데이터의 일관성
유지를 위해 데이터 조작
등 데이터 관리 비용
낭비
데이터 모델링 과정 중 도출되고 규명되는 수많은 업무 규칙(Business Rules)
을 데이터 모델에 표현
하고, 이를 해당 데이터 모델을 활용하는 모든 사용자
가 공유
할 수 있도록 제공
ex. 사원 구분별로 급여 항목을 차등적으로 지급받는 다는 업무 규칙을 데이터 모델에 표현
데이터가 애플리케이션에 독립적
으로 설계되어야 데이터 재사용성(Data Reusability)
를 높임
데이터 확장성, 유연성
을 위해 데이터 관점
의 통합
필요
데이터
를 합리적
으로 균형
있으면서, 단순
하게 분류
=> 사용/관리 측면 복잡하면 잘 만들어진 데이터 모델 X
잘 정돈된 방법
으로 데이터를 통합
하여 데이터 집합
을 정의하고, 데이터 모델
로 잘 표현, 활용하면 업무 변화에도 데이터 모델이 영향을 받지 않고 운용 가능
업무
를 데이터 관점
에서 분석하고 이를 설계하여 나오는 최종 산출물
이며, 데이터 분석 과정에서 많은 업무 규칙
들이 도출되는데 해당 규칙들은 데이터 모델
에 최대한 자세하게 표현되어야 함
=> 데이터 모델이 의사소통(Communication)
의 도구로서 역할
가장 바람직한 데이터 구조 : 동일한 데이터
는 조직 전체
에서 한 번만 정의
, 이를 여러 다른 영역에서 참조, 활용
하는 것 (Integration)
엔터티
: 업무
에 필요하고, 유용한 정보를 저장
하고 관리
하기 위한 집합적인 것(Thing)
변별 가능한 객체
업무 활동상
지속적인 관심을 가져야 할 대상동질성
을 지닌 인스턴스들 또는 행하는 행위의 집합
속성
을 가짐엔터티
는 인스턴스의 집합
엔터티
는 사각형
으로 표현
반드시 해당 업무
에서 필요
하고 관리
하고자 하는 정보여야 함
유일한 식별자
에 의해 식별이 가능
해야 함
=> 인스턴스가 식별자
에 의해 한 개씩만 존재
하는지 검증
영속적
으로 존재하는 인스턴스의 집합
이어야 함 (두 개 이상의 인스턴스
)
업무 프로세스가 그 엔터티를 반드시 이용
해야 함
=> CRUD
가 발생하지 않는 엔터티는 제거하거나 누락된 프로세스 추가
엔터티에는 반드시 속성
이 포함되어야 함
=> 주식별자
만 존재하고 일반속성은 없는 경우도 적절한 엔터티X (예외 : 관계 엔터티
)
다른 엔터티와 최소 한 개 이상
의 관계 있어야 함
관계를 생략해 표현하는 경우
통계를 위한 엔터티
: 업무진행 엔터티로부터 통계 업무만
을 위해 별도로 엔터티를 다시 정의하게 되어 엔터티 간의 관계 생략코드를 위한 엔터티
: 너무 많은 엔터티와 엔터티 간의 관계 설정으로 인해 읽기 효율성
이 저하되어 모델링 작업을 진행할 수 없게 됨, 물리적으로 테이블과 프로그램 구현 이후 외부키
에 의한 참조무결성 체크를 DB 기능에 맡기지 않으므로 관계 설정할 이유 X 시스템 처리 시 내부 필요에 의한 엔터티
: 트랜잭션이 업무적으로 연관된 테이블과 관계 설정이 필요하나, 시스템 내부적인 필요
에 따라 생성된 엔터티
이므로 관계 생략 ex.트랜잭션 로그 테이블유형엔터티
: 물리적인 형태
가 있고, 안정적
이며 지속적
으로 활용되는 엔터티 (ex. 사원, 물품, 강사)
개념엔터티
: 물리적인 형태가 존재하지 않고
, 관리
해야 할 개념적 정보
(ex. 조직, 보험상품)
사건엔터티
: 업무를 수행
함에 따라 발생
하는 엔터티, 비교적 발생량
이 많으
며 각종 통계자료
에 이용 (ex. 주문, 청구, 미납)
기본엔터티
: 업무에 원래 존재
하는 정보, 다른 엔터티와 관계에 의해 생성X
, 독립적
으로 생성 가능, 자신은 타 엔터티
의 부모 역할
, 다른 엔터티로부터 주식별자 상속X
, 자신의 고유한 주식별자
소유 (ex. 사원, 부서, 고객, 상품, 자재)
중심 엔터티
: 기본엔터티
로부터 발생
, 업무
에서 중심적인 역할
, 데이터의 양
이 많이 발생
, 다른 엔터티와의 관계
를 통해 많은 행위엔터티
생성 (ex. 계약, 사고, 청구, 주문, 매출)
행위엔터티
: 두 개 이상의 부모엔터티
로부터 발생, 자주 내용
이 바뀌거나 데이터 양 증가
, 상세 설계 단계
나 프로세스와 상관 모델링
진행 중 도출 가능 (ex. 주문목록, 사원변경이력)
현업 업무
에서 사용하는 용어 사용약어
사용 X단수 명사
모든 엔터티
에서 유일
하게 이름 부여엔터티 생성 의미
대로 이름 부여 => 업무 목적
에 따라 생성되는 자연스러운 이름 부여속성(Attribute)
: 업무
에서 필요로 하는 인스턴스
로 관리하고자 하는 의미상 더이상 분리
할 수 없는 최소의 데이터 단위
엔터티
를 설명
하고 인스턴스의 구성요소
인스턴스
는 속성
의 집합
, 하나의 속성
은 하나의 인스턴스
에만 존재
속성
은 관계로 기술될 수 없고, 자신이 속성을 가질 수도 없음
한 개의 엔터티
는 두 개 이상
의 인스턴스의 집합
한 개의 엔터티
는 두 개 이상
의 속성
한 개의 속성
은 한 개의 속성값
해당 업무
에서 필요
하고 관리
하고자 하는 정보정규화 이론
에 근거해 정해진 주식별자
에 함수적 종속성
을 가져야 함하나의 속성
은 한 개의 값
만을 가짐, 하나의 속성에 여러 개의 값
이 있는 다중값
일 경우 별도의 엔터티
를 이용해 분리기본속성
: 업무
로부터 추출한 모든 속성
, 엔터티에 가장 일반적
이고 많은 속성
설계속성
: 업무상 필요한 데이터 이외에 데이터 모델링
을 위해, 업무를 규칙화
하기 위해 속성을 새로 만들
거나 변형
하여 정의하는 속성 (ex. 코드성 속성, 일련번호)
파생속성
: 다른 속성
에 영향
을 받아 발생하는 속성, 데이터 정합성
유지를 위해 유의할 점이 많아 가급적 적게 정의 (ex. 계산된 값)
PK속성
: 엔터티를 식별
할 수 있는 속성
FK속성
: 다른 엔터티와의 관계
에서 포함된 속성
일반속성
: PK/FK에 포함되지 않은 속성
세부 의미를 쪼갤 수 있는가
단순속성
: 더이상 다른 속성들로 구성될 수 없는 단순한 속성 (ex. 나이, 성별)복합속성
: 여러 세부 속성들로 구성 (ex. 주소)가지고 있는 값의 수
단일값속성
: 속성 하나에 한 개의 값 (ex.주민등록번호)다중값속성
: 여러 개의 값 (ex.전화번호) =>1차 정규화
또는 별도의 엔터티
로 분리도메인(Domain)
: 속성
이 가질 수 있는 값
의 범위
엔터티 내
에서 속성
에 대한 데이터타입
과 크기, 제약사항
을 지정
속성 이름
을 정확하게 부여하고, 용어의 혼란을 없애기 위해 용어사전
사용
각 속성이 가지는 값
의 종류
와 범위
를 명확하게 하기 위해 도메인정의
를 미리 정의
용어사전
과 도메인 정의
를 같이 사용해 프로젝트 진행시 용어적 표준
과 데이터 타입
의 일관성
확보
업무
에서 사용하는 이름 부여서술식 속성명
X약어
사용 X전체 데이터 모델
에서 유일성
확보 => 데이터 흐름 파악 및 정합성 유지에 도움관계(Relationship)
: 엔터티의 인스턴스 사이
의 논리적인 연관성
으로서 존재
또는 행위
로서 서로에게 연관성
이 부여된 상태
패어링
: 인스턴스
가 개별적
으로 관계를 가지는 것
관계
: 패어링
의 집합
관계 패어링
: 각각의 엔터티 인스턴스
들이 자신과 관련된 인스턴스들
과 관계의 어커런스로 참여하는 형태
UML
에는 연관관계
와 의존관계
가 존재
연관관계
: 항상 이용하는 관계 (=존재적 관계
)의존관계
: 상대방 클래스의 행위
에 의해 관계 형성 (=행위적 관계
)ERD
에서는 존재적관계
와 행위적관계
를 구분 X
클래스다이어그램
에서는 연관관계
는 실선
으로 표현하고, 소스코드
에서 멤버변수
로 선언,
의존관계
는 점선
으로 표현, 소스코드
에서 Method
에서 파라미터
등으로 이용
관계명(Membership)
: 엔터티
가 관계에 참여하는 형태
지칭
각각의 관계
는 두 개의 관계명
을 가지며, 각각의 관계명
에 의해 두 가지의 관점
으로 표현
관계시작점
: 관계
가 시작
되는 편
관계끝점
: 관계
를 받는
편
관계 시작점
과 끝점
모두 관계이름
을 가져야 함
관계명 명명규칙
현재형
으로 표현관계차수(Degree/Cardinality)
: 관계에서 참여자의 수
표현
1:1 관계
1:M 관계
M:M 관계
M:N 관계
로 표현된 데이터 모델은 이후 두 개의 주식별자
를 상속받은 관계엔터티
를 이용해 3개의 엔터티
로 구분하여 표현필수참여관계
: 참여하는 모든 참여자
가 반드시 관계
를 가지는, 타 엔터티의 참여자와 연결되어야 하는 관계
선택참여관계
: 참여할 수도 있고, 참여하지 않을 수도 있는 관계, FK로 연결될 경우 Null
허용 가능, 선택참여하는 엔터티 쪽
을 원
으로 표시
두 개의 엔터티 사이
에 관심 있는 연관규칙
이 존재하는가?두 개의 엔터티 사이
에 정보의 조합
이 발생하는가?업무기술서
, 장표
에 관계연결에 대한 규칙
이 서술되어 있는가?업무기술서
, 장표
에 관계연결을 가능
하게 하는 동사(Verb)
가 있는가?기준 엔터티
를 한 개
또는 각
으로 읽는다대상 엔터티
의 관계참여도
, 즉 개수(하나, 하나 이상)
를 읽는다관계선택사양
과 관계명
을 읽는다식별자(Identifier)
: 하나의 엔터티에 구성된 여러 개의 속성 중에 엔터티를 대표
할 수 있는 속성
하나의 엔터티는 반드시 하나의 유일한 식별자
가 존재해야 함
식별자
는 논리 데이터 모델링 단계
에서 사용, 키(Key)
는 물리 데이터 모델링 단계
에서 사용
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';
외부식별자(Foreign Identifier)
: 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티
와의 관계
를 통해 자식
쪽 엔터티에 생성되는 속성, DB생성시 FK
역할
엔터티에 주식별자가 결정되고, 엔터티 간 관계를 연결하면 부모쪽의 주식별자
를 자식엔터티
의 속성
으로 내려보냄
=> 자식엔터티
에서 부모엔터티
로부터 받은 외부식별자
를 자신의 주식별자
로 이용할지, 연결되는 속성
으로만 이용할 것인지 결정
부모
로부터 받은 식별자
를 자식엔터티
의 주식별자
로 이용하는 경우Null값
이 오면 안되므로 반드시 부모엔터티
가 생성되어야 자신의 엔터티
가 생성자식엔터티
가 모두 사용
하고, 그것만으로 주식별자 구성
시 부모엔터티와 자식엔터티의 관계는 1:1
, 부모로부터 받은 속성을 포함해 다른 부모엔터티에서 받은 속성 포함하거나 스스로 가지고 있는 속성
과 함께 주식별자로 구성시 1:M 관계
부모
로부터 속성
을 받았지만 자식엔터티
의 주식별자
로 사용하지 않고, 일반적인 속성
으로만 사용자식엔터티
에서 받은 속성이 반드시 필수
가 아니어도 무방하므로 부모 없는 자식
이 생성될 수 있는 경우데이터의 생명주기
를 다르게 관리할 경우 (ex. 부모가 자식만 두고 먼저 소멸될 수 있는 경우)여러 개
의 엔터티
가 하나의 엔터티
로 통합, 표현
되었는데 각각의 엔터티
가 별도의 관계
를 가질 때자식엔터티
에 주식별자로 사용해도 되지만, 자식엔터티에서 별도의 주식별자
를 생성하는 것이 더 유리
하다고 판단될 때plant 엔터티는 한 개의 속성만 PK속성이었는데, EQPEVTSTSHST 엔터티는 부모로부터 모두 식별자관계
로 연결해 PK속성이 5개나 설정되었다.
1:M 관계의 식별자 관계
의 PK속성
의 수는 점점 늘어난다.
원 부모엔터티 : 1개
2대 부모엔터티 : 2개 이상 = 원부모 1개 + 추가 1개 이상 +
3대 부모엔터티 : 3개 이상 = 원부모 1개 + 2대 1개 + 추가 1개 이상
3대 부모엔터티 : 3개 이상 = 원부모 1개 + 2대 1개 + 3대 1개 + 추가 1개 이상
4대 부모엔터티 : 4개 이상 = 원부모 1개 + 2대 1개 + 3대 1개 + 4 1개 + 추가 1개 이상 ....
식별자관계
만으로 연결된 데이터 모델의 특징
: 주식별자 속성
이 지속적으로 증가
할 수 밖에 없는 구조로서 개발 복잡성
과 오류
유발 요인
주민등록번호, 사원번호와 같이 중요한 속성이 비식별자관계
로 설정되면 자식엔터티로 상속되지 않아 자식엔터티에서 데이터 처리 시 쓸데없이 부모엔터티
까지 찾아가야 함
비식별자관계 선택 프로세스
식별자관계
로 모든 관계
가 연결되면서 다음 조건에 해당시 비식별자관계
로 조정,자식엔터티
의 독립된 주식별자 구성
이 필요
한지 분석식별자와 비식별자관계 비교
식별자와 비식별자를 적용한 데이터 모델