제 1장. 데이터 모델링의 이해
1번. 모델링의 특징
1) 추상화 : 현실세계를 일정한 형식에 맞춰 표현
2) 사전 작업 : 시스템 구현, 업무분석, 업무 형상화를 목적으로 하는 사전 단계의 작업
3) 단순화 : 복잡한 현실을 제한된 언어나 표기법을 통해 이해 쉽게
4) 정확화 : 누구나 이해 가능하게 정확히 현상 기술
2번. 데이터 모델링 필요 이유
- 데이터 모델링 : 업무 정보를 구성하는 기초 정보들을 일정한 표기법에 의해 표현
- 필요 이유 1 : 분석된 모델로 디비 생성해서 개발 or 데이터 관리에 사용하기 위함
- 필요 이유 2 : 데이터 모델링을 통해 그 자체로서 업무의 흐름을 설명/분석하는데에 도움
3번/4번. 데이터 모델링 중 유의 사항
- 중복 : 여러 디비에 같은 정보 저장하지 않도록 해야함
- 비유연성 : 데이터 정의와 사용 프로세스를 분리해야함 --> 작은 변화가 애플리케이션 or 디비에 큰 영향 줄 수 없도록
- 비일관성 : 서로 연관된 데이터 중 하나만 업데이트 할 때 발생 --> 데이터 간의 연관 관계에 대해 명확한 정의 필요
5번. 데이터 모델링 종류
- 개념적 모델링 : 전사적 데이터 모델링 수행 시 많이 함. 추상화 수준 높음. 업무 중심적. 포괄적 수준의 모델링
- 물리적 모델링 : 실제로 디비에 이식 할 수 있도록 성능/저장 등의 물리적 성격을 고려한 모델링
6번. 데이터 베이스 스키마 구조 3단계
- 외부 스키마 : 실세계의 데이터를 어떤 구조로 사용자에게 보여줄 것인지 논리적 구조를 정의.
- 개념 스키마 : 모든 사용자 통합 관점의 스키마. 모든 응용시스템이나 사용자들이 필요로하는 데이터 통합.
- 내부 스키마 : 물리적인 저장장치 중심으로, 어떻게 디비를 저장할건지 물리적 저장 구조를 정의.
7번.
8번. ERD
- 1976년 피터첸이 Entity Relationship Model 개발
- 작성 방법 : 엔티티 도출(그리기) -> 엔티티 배치 -> 관계 설정 -> 관계명 기술 -> 관계 참여도 기술 -> 관계 필수여부 기술
- 관계 명칭은 관계 표현에 있어서 매우 중요
9번.
10번/11번. 엔티티 특징
- 유일한 식별자에 의해 식별 가능해야함
- 두 개 이상(영속적으로 존재)의 인스턴스 집합
- 업무 프로세스에 의해 이용되어야 함 ( 데이터가 있지만 업무에서 필요하지 않으면 해당 업무의 엔티티 성립 X)
- 반드시 속성이 있어야 함
- 다른 엔티티와 최소 한 개 이상의 관계 있어야 함 (통계성, 코드성 엔티티는 관계 생략 가능)
12번. 엔터티 분류
[유무형에 따른 분류]
- 유형 : 물리적 형태 (사원, 물품, 강사)
- 개념 ; 개념적 정보 (조직, 보험 상품)
- 사건 : 업무 수행시 발생 (주문, 청구, 미납)
[발생 시점에 따른 분류]
- 기본(키) 엔터티 : 원래 존재하는 정보. 다른 엔터티와의 관계에 이해 생성되지 않고 독립적으로 생성 가능. 자신은 타 엔터티의 부모 역할함. 다른 엔터티로부터 주식별자를 상속받지 않고 고유한 주식별자 가짐. (사원,부서,고객,상품)
- 중심 : 기본 엔터티로부터 발생. 다른 엔터티와의 관계로 많은 행위 엔터티 생성 (계약, 사고, 주문)
- 행위 : 2개 이상의 부모 엔터티로부터 발생. 자주 바뀌거나 양이 증가함 (주문 목록, 사원 변경 이력)
13번. 엔터티 명명 기준
- 현업에서 사용하는 용어
- 가능하면 약어 사용 X
- 단수명사 사용
- 모든 엔터티 중 유일한 이름으로
- 엔터티 생성 의미대로 이름 부여
14번. 속성이란
속성이란 : 업무에서 필요로 하는 인스턴스에서, 관리하고자 하는, 의미상 더 이상 분리되지 않는 최소의 데이터 단위
15번. 속성에 대한 설명
- 엔터티에 대한 자세한 정보임
- 하나의 엔터티는 두 개 이상의 속성 가짐
- 하나의 인스턴스에서 각 속성은 한개의 속성값을 가짐
- 한개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 함
16번/17번. 속성 분류
- 기본 : 업무로부터 추출한 모든 일반적인 속성
- 설계 : 업무를 규칙화하기 위해 새로 만들거나 변형한 속성 (일련 번호)
- 파생 : 다른 속성의 영향을 받아 발생하는 속성. 빠른 성능 낼 수 있게 원래 속성 값을 계산, 적을 수록 좋음 (합, 이자)
18번. 도메인
도메인이란? : 속성에 대한 데이터 타입, 크기, 제약사항 지정 --> 각 테이블 속성에 어떤 유형의 값이 들어가는지 정의하는 개념
19번. 속성 명칭 부여 주의 사항
- 해당 업무에서 사용하는 이름 부여
- 서술식 속성명 X
- 약어 사용 지양
- 유일성 확보
20번. 데이터 모델링 관계에 대한 설명
- ERD에서 : 존재적 관계와 행위에 의한 관계 구분 표기법 없음 (단일화된 표기)
- 클래스다이어그램에서 : UML에서는 이것을 연관관계와 의존관계로 표현하며. 다르게 표기됨 (연관은 실선, 의존은 점선)
21번/22번. 관계에 대한 설명
- 구분 : 존재적 관계, 행위에 의한 관계
- 관계 표기법 : 관계명, 관계차수(1:M), 관계선택성(필수or선택)
- 소속 관계 : 존재적 관계 (부서 - 사원)
23번/24번. 엔터티 사이의 관계 체크 사항
- 두 개의 엔터티 사이에 관심 있는 연관 규칙 존재?
- 두 개의 엔터티 사이에 정보의 조합 발생?
- 업무기술서, 장표에 관계 열결을 가능케 하는 '동사' 존재?
- 업무기술서, 장표에 대한 규칙 서술됨?
25번. 주식별자 지정 시 고려할 사항
- 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되어야 함
- 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함
- 지정된 주식별자의 값은 자주 변하지 않는 것이어야 함
- 주식별자가 지정되면 반드시 값이 들어와야 함
26번. 식별자의 종류 (구분)
- 엔터티 내에서 대표성을 가지는가? --> 주식별자 / 보조 식별자
- 엔터티 내에서 스스로 생성되었는가? --> 내부 식별자 / 외부 식별자
- 단일 속성으로 식별 되는가? --> 단일 식별자 / 복합 식별자
- 업무적으로 의미를 가지는가? --> 본질 식별자(ex. 사원)/ 인조 식별자(ex. 일련번호 - 시스템적으로 부여된 것)
28번. 주식별자 도출 기준
- 해당 업무에서 자주 이용되는 속성을 주식별자로 지정
- 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정 X
- 복합적으로 주식별자 구성 시 너무 많은 속성이 포함되지 않도록 함
* 주식별자 특징 : 유일성 / 최소성 / 불변성 / 존재성(Not NULL)
29번/30번. 비식별자 관계
- 비식별자 관계란? : 부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우
- 비식별자관계의 연결 고려사항
1) 약한 종속 관계
2) 자식 주식별자를 독립적으로 구성
3) 자식 주식별자 구성에 부모 주식별자 부분 필요
4) 상속받은 주식별자 속성을 타 엔터티에 차단 필요
5) 부모쪽의 관계 참여가 선택 관계
6) 여러 개의 엔터티를 하나로 통합하면서 각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합되는 경우