SQLD 자격증 1과목 데이터 모델링의 이해(개념+노랭이)

 

 

데이터 모델링

 

 

데이터 모델링

 

 

• 현실 세계를 데이터 베이스에 표현하기 위한 추상화 과정 -> 추상화의 의미
• 고객을 이해해야 함

 

 

데이터 모델링 특징

 

 

추상화	일정한 양식에 맞게
단순화	누구나 이해하기 쉽게, 약속된 규약에 의한 제한된 표기법이나 언어 사용
명확화	애매모호함 제거, 정확하게 기술, 분석된 모델

 

 

데이터 모델링 단계

 

 

개념적 모델링	- 업무측명 모델링 -포괄적/전사적 모델링(추상화 수준 가장 높음) - 핵심 엔터티 도출 - ERD작성
논리적 모델링	- 특정 데이터 모델에 종속 - 세부속성/식별자/관계 등 표현 - 데이터 정규화 완료 - 재사용성 가장 높음
물리적 모델링	-물리적인 성능과 데이터 저장을 고려한 설계 - 가장 구체적(추상화 수준 가장 낮음) - 성능/보안/가용성 고려

 

 

데이터 모델링 3가지 관점

 

 

• 데이터 관점: ex) 구조분석, 정적분석
• 프로세스 관점: 실제하는 업무에 따라 무엇을 어떻게 하는지 모델링 ex) 시나리오분석, 도메인분석, 동적분석
• 데이터와 프로세스의 상관관점: ex) CRUD

 

 

ERD

 

 

ERD

 

 

• Entity Relationship Diagram, 1976 피터첸
• 대표적인 표기법: chen, IE/Crow's Foot, Barker, UML
• 관계의 명칭 관계 표현에서 매우 중요하다
• 엔터티 위치는 필수 사항이 아니지만 가장 중요한 엔터티는 왼쪽 상단 배치, 이것을 중심으로 다른 엔터티 나열(가장 중요한 엔터티는 왼쪽 상단 아래에서 조금 아래 중앙에 위치하는게 좋음)
• 참고 -> https://itwiki.kr/w/ER_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

 

 

ERD 작성순서

 

 

1. 엔터티 도출
2. 엔터티 배치
3. 엔터티 관계 설정
4. 관계명 기술
5. 관계 참여도 기술
6. 관계 필수 여부 기술

 

 

3단계 구조 스키마

 

 

3단계 구조 스키마

 

 

• 데이터 베이스의 독립성을 위해 존재
• 각 계층은 뷰로 불리며 3단계로 분리되어 독립성 확보
• 장점: 데이터 복잡도 감소, 중복제거, 사용자 요구사항 변경에 따른 대응력 향상, 관리 및 유지보수 비용 절감

 

 

논리적 데이터 독립성

 

 

• 응용 프로그램에 영향을 주지 않고 데이터 베이스 논리적 구조를 변경할 수 있는 능력
• 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원
• 외부 스키마에 영향을 미치지 않으면서 개념 스키마에 적용되는 제약 조건을 변경 가능

 

 

물리적 데이터 독립성

 

 

• 응용 프로그램이나 데이터 베이스의 논리적 구조에 영향을 미치지 않고 데이터의 물리적 구조를 변경할 수 있는 능력
• 내부 스키마가 변경되어도 외부 또는 개념 스키마가 영향을 받지 않도록 지원
• 데이터 베이스의 색인 구조의 변화가 응용 프로그램에 영향을 주지 않음

 

 

3단계 구조 스키마 단계

 

 

외부 스키마(외부단계)	- 개별 사용자 관점(여러 사용자 관점)의 이해와 표현 - 응용 프로그램이 접근하는 데이터 베이스 - 여러개의 외부 스키마 존재
개념 스키마(개념단계)	- 관리자 관점(통합된 모든 사용자 관점)으로 규칙과 구조 표현 - 일반적인 스키마 - 데이터 베이스의 전체적인 논리 구조(저장되는 데이터와 그들의 관계 표현)
내부 스키마(내부단계)	- 시스템의 설계자 관점으로 저장 차이 관점의 이해 및 표현 - 데이터가 실제로 데이터 베이스에 물리적으로 어떻게 저장되는지 확인

 

* 외부 스키마, 개념 스키마 -> 논리적인 데이터 독립성 고려하는 단계

* 외부 스키마 - 개념적 스키마 사이 논리적 데이터 독립성 적용

  개념적 스키마 - 내부적 스키마 사이 물리적 데이터 독립성 적용

 

 

엔터티(Entity)

 

 

엔터티(Entity)

 

 

데이터의 집합, 저장되며 관리되는 데이터

 

 

엔터티 특징

 

 

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 함 ex) 한자, 토익 응시 횟수
• 유일한 식별자에 의해 식별이 가능해야 함
• 영속적으로 존재하는(2개 이상의) 인스턴스 집합이어야 한다
• 엔터티는 업무 프로세스에 의해 이용되어야 한다
• 엔터티는 반드시 속성이 있어야 한다
• 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다(공통코드, 통계성 엔터티는 생략 가능)

 

 

엔터티 분류

 

 

• 무형과 유형에 따른 분류

유형 엔터티	물리적, 지속적, 안정적 엔터티 ex) 사원, 제품, 교수 ...
개념 엔터티	물리적이진 않지만 개념적으로 존재하며 정보로 구분됨 ex) 강의, 금융상품, 부서...
사건 엔터티	비즈니스 프로세스에 따라 발생 ex) 구매, 판매, 영업...

 

• 발생 시점에 따른 분류

기본엔터티	키 엔터티, 독립적으로 생성 및 관리 ex) 고객, 부서, 판매상품...
중심 엔터티	기본 엔터티로부터 발행되는 행위 엔터티를 생성하는 중간 엔터티 ex) 계좌, 주문, 수납...
행위 엔터티	상위에 있는 2개 이상의 엔터티로부터 발생되는 엔터티 ex) 주문이력, 접속이력, 수납이력...

 

 

엔터티 이름 부여

 

 

• 가능한 현업 업무에 사용하는 용어
• 가능한 약어사용 피한다
• 단수명사 사용
• 모든 엔터티 통틀어 유일하게 이름 부여
• 엔터티 생성 의미대로 이름 부여

 

 

속성

 

 

속성

 

 

• 엔터티가 가지는 항목(자세하고 구체적인 정보)
• 더 이상 분리되지 않음, 인스턴스의 구성요소-> 하나의 값만 가진다
• 주식별자에게 함수적으로 종속된다 -> 기본키에 따라 속성의 값도 변경될 수 있다

 

 

특성에 따른 속성 종류

 

 

기본속성	비즈니스 프로세스에서 도출한 본래의 속성 ex) 이름, ID, 전화번호, 등록일시...
설계속성	데이터 모델링 과정에서 발생되는 속성 ex) 상품코드, 지점코드...
파생속성	데이터 조회시 빠른 성능을 낼 수 있도록 하기 위해서 만들어진 속성 (원래 속성값 계산하여 저장할 수 있도록 만들어진 속성) ex) 합계 평균

 

 

속성의 명칭

 

 

• 약어 사용 가급적 피한다
• 서술식 용어 사용하지 않는다
• 해당 업무에서 사용하는 이름이나 용어 사용
• 전체 데이터 모델에서는 유일성 확보하는 것이 좋다

 

 

도메인

 

 

도메인

 

 

속성이 가지는 값의 범위

 

 

관계

 

 

관계

 

 

• 엔터티 사이 논리적 연관성을 의미
• 엔터티 정의에 따라 영향을 받을 수 있다
• 속성 정의 및 관계 정의에 따라서 다양하게 변화할 수 있다
• ERD에서는 관계를 연결할 때 존재와 행위는 기술하지 않고 단일화된 표기법을 사용한다
• UML에서의 클래스 다이어그램의 관계

연관관계	- 항상 이용, 실선표기 - 소스코드에서 멤버변수로 선언하여 사용
의존관계	- 점선표기 - 상대방 클래스의 행위에 의해 관계 형성 - 오퍼레이션에서 파라미터 등으로 이용

 

 

관계 분류

 

 

• 존재에 의한 관계
• 행위에 의한 관계

 

 

관계 표기법

 

 

관계명	- 관계에 엔터티가 참여하는 행태 정의 - 각 관계는 두개의 관계명을 가짐 - 능동적 또는 수동적으로 명명 - 애매한 동사 피하고 현재형으로 표현
관계차수	관계있는 엔터티간 참여하는 수 (1:1, 1:M, M:M)
관계 선택사양	- 참여하는 엔터티가 항상 참여하는지, 참여하지 않을수도 있는지 나타냄 - 필수관계(관계에 의한 참여, 부서-사원) / 선택관계(선택적 참여, 고객-주문)