[SQLD 오답] -3- 데이터모델링의 이해

. 모델링의 특징

• • 추상화: 현실세계를 일정한 형식에 맞추어 표현
  • 시스템 구현을 포함한 업무분석 및 업무형상화
  • 복잡한 현실을 제한된 언어,표기로 단순화
  • 애매성 제거하고 누구나 이해하도록 정확하게 기술

2. 데이터 모델링

• • 현실세계 데이터(what)에 대해 약속된 표기법으로 표현하는 과정
  • 데이터베이스를 구축하기 위한 분석/설계과정
  • 정보시스템을 구축하기 위한 데이터 관점의 업무분석
    • 단지 DB구축만을 위한 용도로 쓰이는 것이 아니라 데이터 모델링 자체로서 업무를 설명하고 분석하는 부분에서 중요한 의미를 가짐

3. 데이터 모델링 유의점

• • 중복: 같은정보 저장 X
  • 비유연성: 데이터 정의와 프로세스를 분리하여 모델 수시 변경에 따른 유지보수의 어려움 감소시키자 --> 유연성 높이기
  • 비일관성: 데이터 간의 상호 연관관계에 대해 명확히 정의
    • 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점!! --> 유연하지 못한 경우

4. 비유연성

5. 데이터 모델링 개념

• • 개념적 데이터 모델링: 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링, 전사적 데이터 모델링, EA수립시 이용
  • 논리적 데이터 모델링: 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성 높음
  • 물리적 데이터 모델링: 실제 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려한 설계

6. ANSI-SPARC [three-level-architecture]

• • 데이터베이스 스키마구조 3단계
  • [외부/개념/내부] 각각은 상호 독립적인 의미를 가지고 고유한 기능을 가짐
    • 개념스키마: 통합관점의 스키마구조 표현, 데이터 모델링은 통합관점의 뷰를 가진 개념스키마를 만들어 가는 과정으로 이해
      • 모든 사용자 관점을 통하한 조직 전체 관점의 통합적 표현
      • 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마

7. ERD [고객/주문] -- 도식 --

8. ERD

• • 1976 피터첸에 의해 ERM표기법이 만들어짐
  • 관계의 명칭은 관계표현에 있어 매우 중요
  • 엔터티 배치는 데이터 모델링 툴 사용 여부와 상관없이 데이터 모델의 가독성 측면에서 중요, 따라서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 모델 작성
    • ERD작성순서
      • 엔터티 그림(엔터티 도출)
      • 엔터티 배치
      • 엔터티간 관계 설정
      • 관계명 기술
      • 관계의 참여도 기술
      • 관계의 필수여부 기술

9. 엔터티 (시나리오)

• • s병원에는 여러명의 환자 존재, 각 환자에 대한 이름, 주소 등을 관리해야하는 경우

--> <엔터티> 는 2개이상의 속성, 2개이상의 인스턴스를 가져야 함. 따라서 병원은 성립X, 따라서 <환자>는 '여러명'의 복수 인스턴스, 그리고 이름, 주소 등의 복수 속성을 가지므로 환자가 엔터티임.

10. 엔터티의 특징

• • 반드시 해당 업무에서 필요하고 관리하고자하는 정보
  • 유일한 식별자에 의해 식별가능
  • 영속적으로 존재하는 인스턴스의 집합(한개X, 두개이상O)
  • 업무프로세스에 이용되어야 함
  • 반드시 속성이 있어야함
  • 다른 엔터티와 최소 한개 이상의 관계가 있어야 함
    • 단, 통계성 엔터티나, 코드성 엔터티의 경우 관계 생략 가능 [​공통코드/통계성 예외]

11. 엔터티의 일반적 특징: 다른 엔터티와 관계를 가져야 함.

12. 발생시점에 따른 엔터티 분류

• • 기본(키): 그 업무에 원래 존재하는 정보, 타 엔터티와의 관계에 의한 형성X,--> 독립적 생성, 타 엔터티의 부모역할, 타 엔터티로부터 주식별자 상속X, 고유한 주식별자
  • 중심(메인): 데이터 양이 많고 기본엔터티로부터 발생, 업무의 중심적 역할, 타 엔터티와의 관계를 통해 행위엔터티 생성
  • 행위: 두개이상의 부모엔터티로부터 발생, 자주 내용이 바뀌어 데이터양 증가 --> 분석초기에는 잘 없고 모델링하며 도출가능

13. 엔터티 명명

• • 현업업무용어/약어사용 자제/단수명사/모든 엔터티에서 유일한 이름/생성의미대로 부여

14. 속성

• • 업무에서 필요로하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

15. 속성 설명

• • 하나의 엔터티는 두개 이상의 속성을 가짐
  • 엔터티에 대한 자세하고 구체적 정보 나타냄
  • 속성도 집함임
  • 하나의 인스턴스에서 각각의 속성은 하나의 속성값을 가져야 함

16. 속성 특성에 따른 분류

• • 기본/설계(규칙화를 위한 변형)/파생(계산된 값)
  • 예시)
    • 원금/예치기간/이자율: 기본속성
    • 예금분류(001,002,...): 설계속성
    • 이자: 파생속성

17. 파생속성

• • 데이터를 조회할 때 빠른성능을 낼 수 있도록 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성

18. 도메인: 각 속성이 가질 수 있는 값의 범위, 엔터티 내에서 속성에 대한 데이터 타입 및 제약사항을 지정

19. 속성명칭

• • 해당 업무에서 사용하는 이름/서술식X/약어X/전체 데이터 모델에서 유일성 확보
    • 복합명사를 사용하여 구체적으로 명명!

20. 관계

• • ERD는 존재/행위에 의한 관계를 구분X
  • UML의 클래스 다이어그램은 연관/의존 관계를 구분
    • 실선(식별)과 점선(비식별)의 표현법으로 ex. 카디널리티

21. 관계의 표기법

• • 관계명/관계차수/선택성(선택사양)
  • 존재/행위적 관계로 나뉨

22. 관계차수== 관계의 기수성(참여자수)을 나타내는 것

23. 관계도출 체크사항

• • 두개 엔터티 사이에 관심있는 연관규칙 있음?
  • .. 정보의 조합 발생함?
  • 업무기술서, 장표에 관계연결에 대한 규칙 있음?
  • .. 가능하게 하는 동사가 있음?

24. 관계도출 체크사항

---

식별자부분 공부안해서 갑자기 공부시작 :-)

식별자 종류

• 대표성 여부 (주식별자/보조식별자)
• 스스로생성 여부 (내부식별자/외부식별자)
• 단일속성으로 식별여부 (단일식별자/복합식별자)
• 대체여부 (본질식별자/인조식별자)

주식별자의 특징 ex. 학번 생각해보셈

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

​	식별자관계	비식별자관계
목적	강한 연결관계 표현	약한 연결관계 표현
자식주식별자 영향	자식 주식별자의 구성에 포함됨	자식 일반 속성에 포함됨
표기법	실선	점선
연결 고려사항	반드시 부모 엔터티 종속 자식 주식별자구성에 부모 주식별자 포함필요 상속받은 주식별자속성을 타엔터티에 이전필요	약한 종속관계 자식 주식별자구성을 독립적으로 구성 자식 주식별자구성에 부모 주식별자 부분 필요 상속받은 주식별자 속성을 타 엔터티에 차단 필요 부모쪽의 관계참여가 선택관계

---

하구서 다시 문제풀기 ~ :-)

​

25. 주식별자 고려사항

• • 엔터티내의 모든 인스턴스들이 유일하게 구분
  • 주식별자를 구성하는 속성의 수는 유일성을 만족하느 ㄴ최소의 수
  • 지정된 주식별자의 값은 변하지 않아야 함
  • null안됨

26. 사원 엔터티에서 식별자의 특성

• 사원 |​사번| 부서번호(FK) 주민등록번호
  • <사번: 식별자>
    • 업무적으로 의미있는 식별자로 일반적으로 업무에 의해 만들어지는 식별자임
    • --> 주식별자, 단일식별자, 내부식별자, 본질식별자임

27. 식별자로서 명칭/내역/이름 으로 기술되는 것들은 부적절, 특히 이름은 동명이인이 있을 수 있기 때문에 더더욱 부적절

28. 주식별자 도출기준

• 해당 업무에서 자주 이용되는 속성을 주식별자로 지정
• 명칭, 내역같이 이름으로 기술되는 것들은 지정하지 않음
• 복합으로 주식별자 구성할 경우 너무 많은 속성이 포함되지 않도록 함
  • 자주 수정되는 속성이 주식별자가 되면 자식 엔터티에 대한 연쇄 수정이 필요해서 시스템 부하의 원인이 될 수 있으므로 부적절

29. 비식별자 선택기준

• 부모엔터티의 주식별자를 손자 엔터티까지 보내기 위해서는 비식별자관계가 아닌 식별자 관계를 고려해야 한다.
• 모든 관계가 식별자 관계이면 SQL where 절에서 비교하는 항목이 증가되어 조인에 참여하는 테이블에 따라 문장이 길어저 복잡성이 증가되는 것을 방지하기 위해 비식별관계를 고려해야 하지만, 단순히 SQL문장의 복잡도를 낮추는 목적에서 고려되는 것은 바람직하지 않음

30. 비식별자 관계연결을 고려해야하는 경우

• 부모엔터티 참조값이 없이도 자식 엔터티의 인스턴스가 생성가능한 경우
• 자식 쪽 엔터티의 주식별자를 부모 엔터티와는 별도로 생성하는 것이 유리한 경우
• 여러개의 엔터티를 하나로 통합하면서 각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합되는 경우
  • 엔터티별로 데이터 생명주기를 다르게 관리할 경우 ex. 부모엔터티의 인스턴스가 자식 엔터티와의 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸하는 경우 비식별자관계로 연결하는 것이 적절, --> 부모 엔터티의 인스턴스가 자식 엔터티와 같이 소멸되는 경우(즉, 데이터 생명주기가 동일하게 소멸되는 경우) 식별자 관계로 정의 하는 것이 더 적합.