Download as PDF, PPTX
Uploaded byChoonghyun Yang
데이터 모델링
개인적으로 교육받았던 데이터 모델링에 대해서 정리한 내용입니다. 혹시나 틀린점이있으면 말씀해주세요. 감사합니다.
![[AWSKRUG] 데이터 얼마까지 알아보셨어요?](https://cdn.slidesharecdn.com/ss_thumbnails/aa-190614060527-thumbnail.jpg?width=640&height=640&fit=bounds)
![[2016 데이터 그랜드 컨퍼런스] 1 3. bk3(엔코아)데이터그랜드컨퍼런스 4차산업혁명의 핵심-데이터경제-엔코아](https://cdn.slidesharecdn.com/ss_thumbnails/1-3-161125004936-thumbnail.jpg?width=640&height=640&fit=bounds)
데이터 모델링
- 1.
- 2. 모델링이란 현실세계 데이터모델 추상화 단순화 명확화 복잡한 현실세계를일정한 표기법에 의해 표현하는 일
- 3. 개념적 데이터 모델 논리적데이터 모델 물리적 데이터 모델
- 4. 개념적 데이터 모델 핵심엔티티핵심엔티티핵심엔티티 *핵심 엔티티는 행위의 주체나 목적물이 되는 개체 집합
- 5. 주제영역(Subject Area) • 기업이사용하는 데이터의 최상위 집합 • 유사한 성격의 데이터를 체계화해 그룹으로 묶은것 을 의미 • Ex. 제조업체 • 인사, 생산, 자제, 판매등이 주제 영역 • 가장 근본적인 목적은 기업의 정보체계 구조를 한눈 에 파악하고 관리.
- 6. 주제영역 분류 원칙 •데이터 중복의 최소화 • 동일한 기능을 하는 자원이 중복정의되지 않게 • 데이터 확장성 보장 • 가까운 미래에 추가 되어지는 정보에 대해서 확장 성을 고려
- 7. 주제영역 분류기준 • 데이터관점의 분류 • 업무를 발생시키는 주체, 대상및 행위등에서 데이터를 생 성하는 기준으로 분류 • 데이터 유사성 • 시스템이 다르더라도 동일한 유형의 데이터를 발생시키면 같이 관리 • 업무요건 추가에 대한 유연성 보장 • 주제영역간 균형 유지
- 8. 주제영역 명명 • 실제사용하는 업무용어로 부여 • Ex. 인사, 생산, 판매, 직원, 구매 • 단수형 명사 • 데이터 그룹을 의미하는 이름을 부여
- 9. 주제영역 분류방법 • 1차분류 : 주요 데이터집합의 유형정의 • 2차 분류 : Biz 활동에 필요한 데이터 분류 • 3차 분류 : 2차 영역의 세부 주제 영역 분류
- 10. 1차 분류 : 주요데이터 집합 유형의 정의 • 기존 시스템별로 제공되는 데이터의 성격 및 특성을 고려하여 분류 • 업무의 변화에 민감하지 않도록 정의
- 11. 1차 분류 Ex 관계자 상품/서비스 자산 채널 계약 리스크 주문 경영관리 데이터발생 시키는 주체 데이터를 발생시키는 주체간 상호 작용으로 발생하는 대상 공통 및 관리 성격
- 12. 2차분류: Biz 활동에 따른필요한 데이터 분류 • 데이터의 기능적 구성관점에서 접근 1차 분류를 세 분화 • 업무 변화에 따른 확장성을 고려하여 분류 • 분류 Ex • 관계자 : 관계자 기본, 관계자 상세, 관계자 관계, 관계자 분류
- 13. 3차 분류: 2차영역의 세부주제 영역 분류 • 업무적인 관점에서 분류 • 분류 Ex • 관계자(기본) : 고객, 법인, 조직, 직원 • 계약(기본) : 수신계약, 예금계약, 신탁계약
- 14. 주제영역 분류 Ex 국내A은행 주제영역 분류 사례
- 15. 주제영역 장점 • 데이터의계층적 구조를 파악이 쉬움 • 데이터 및 업무 활동 모델의 품질 보증 • 프로젝트 관리 용이 • 모델 개발 조정 용이 • Repository 관리 용이 • 상세사항의 전개 혹은 축약가능
- 16. 주제영역 도출 • 업무에서사용하는 데이터의 명사형 도출 • 업무 기능의 이름으로부터 도출 • 하향식 접근방법(Top-down) • 상향식 접근방법(Bottom-up) • 분석 단계에서의 도출
- 17. 엔티티는 업무를 수행하는데필요 한 데 이터를 특성이 유사한것 끼리 모아 놓은 집합
- 18. 엔티티 설계 • 관리하고자하는 데이터인지 판단. • 주식별자(PK) • 속성이나 관계와 혼동하면 안됨.
- 19. 식별자 • 인조 식별자(가주어) • 유니크 • 본질 식별자 (진주어) • PK
- 20. 서브 타입 • 엔티티를명확하게 하기위해서 구체적으로 부분집합 의 종류를 명시 • Ex • 고객등급 : 일반, VIP, VVIP
- 21. 서브타입 지정시 고려사항 •교집합 허용불가 • 서브타입의 합이 전체 집합 • 서브타입 또한 추후 물리모델에서 테이블 분할의 기 준 역할을 하기에 아래의 기준을 가져야 한다. • 개별 속성 • 개별관계
- 22. 서브타입 도출 • 두개이상의 유사한 엔티티에서 공통속성을 분류 • 하나의 엔티티에서 유사한 속성끼리 분류
- 23. 두개 이상의 엔티티에서공통 속성을 분류하는 방법 Ex before
- 24. 두개 이상의 엔티티에서공통 속성을 분류하는 방법 Ex after
- 25. 하나의 엔티티에서 유사한속 성끼리 분류하는 방법 Ex before
- 26. 하나의 엔티티에서 유사한속 성끼리 분류하는 방법 Ex after
- 27. 엔티티 후보 수집 •기존시스템 도큐먼트 • 현업 보고서 • 현업 담당자들과 인터뷰 • 관련 전문 서적 • 데이터 흐름도 • 타 시스템 자료 • 현장 조사
- 28. 엔티티 후보 식별 •엔티티 후보의 개념 정립 • 관리 대상 판정 • 집합 여부 확인
- 29. 엔티티 후보 선정시유의사항 • 엔티티 가능성이 있다고 예상되면 일단 검토 대상에 올려라 • 너무 깊게 생각하지마라 • 동의어처럼 보이더라도 함부로 버리지마라 • 개념이 모호한 대상은 그 개념을 상식화하여 이해하라 • 프로세스에 너무 연연해 하지마라 • 예외인 경우에 너무 집착하지마라 • 단어 하나하나 집주에서 판단해라
- 30.
- 31. 키 엔티티 • 자신의부모를 가지지 않는 엔티티 • Ex • 사원, 부서, 고객, 상품, 자재
- 32. 메인 엔티티 • 업무중심에해당하는 엔티티 • 키엔티티를 제외하고는 모두 부모엔티티를 가진다 • Ex • 보험 계약, 사고, 주문, 매출
- 33. 액션 엔티티 • 키,메인 엔티티를 제외한 모든 엔티티 • 주로 행위로 발생되어지는 엔티티들 • 자식을 가지지 않는다 • Ex • 상태 이력, 차량 수리 내역, 주문 내역
- 34. 바커 표기법(Baker’s Notation) 정보공학 기법(IENotation)
- 35. 엔티티 표현 • 소프트박스 및 직사각형으로 표현 • 이름은 단수명사로 표현 • 박스안에 혹은 박스 위에 엔티티명 표현 채용 채용
- 36. 속성 표현 제품 # 제품코드 *제품명 o 단가 #: 본질 식별자 * : not null o : nullalble
- 37.
- 38. 식별관계와 비 식별관계 식별관계 (Identification Relationship) 부모실체의 식별자가 자식 실체의 식별자의 일부분이 되는 관계 비 식별관계 (Non-Identification Relationship) 부모실체의 식별자가 자식 실체의 식별자의 일부분이 아닌 관계
- 39.
- 40. 관계 읽기 • 각고객은 하나의 주문을 할지도 모른다. • 각 주문은 하나의 고객을 반드시 포함해야한다. • 각 주문은 하나이상의 주문상세를 반드시 포함한다 • 각 주문상세는 하나의 주문에 반드시 포함된다. • 각 제품은 하나의 주문상세에 반드시 포함된다. • 각 주문상세는 하나의 제품에 반드시 포함된다.
- 41. M : M M: M 관계 해소
- 42. 배타적 관계 • 어떤엔티티가 두개 이상의 다른 엔티티을 가지는것을 배타적관계 • 항상 필수 이거나 선택 이어야한다 • 반드시 하나의 엔티티에 속해야한다
- 43. 데이터 모델링 작성규칙 •엔티티 정의 • 엔티티 후보 도출 • 엔티티 후보 자격조건 식별하여 최종 엔티티 도출 • PK속성 도출 하여 엔티티의 주식별자 표기 • 관계 정의 • 다대다 관계 제거 • 속성 정의 • 정규화 검증
- 44. 데이터 모델링 실습 병원에는많은 의사가 근무하고 있으며, 많은 환자가 진료를 받고 있다. 각 환자에게는 여러가지 실시된 검 사기록이 유지된다.
- 45. 엔티티 후보 도출 병원에는많은 의사가 근무하고 있으며, 많은 환자가 진료를 받고 있다. 각 환자에게는 여러가지 실시된 검 사기록이 유지된다.
- 46.
- 47.
- 48.
- 49.
- 50. 데이터 모델링은 프로세스 관점이아닌, 데이터 관점 으로 설계