1장데이터 모델링 이해
1절데이터 모델링 개요
1.데이터 모델링 정의
가.데이터 모델링 탄생 배경
2)모델 정의
-데이터 모델은 현실 세계에 대해 우리가 관심있어 하는 대상을 데이터베이스화 하기 위한 개념적 도구
-물리적 모델: 현실에 실재하는 것이 아닌 복잡한 자동차의 모형, 대형 선박의 스케치 또는 설계도, 자동차의 모의 실험용으로 사용되는 바람 터널에서의 자동차 축소 모형 등
-개념적 모델: 특정 시점에 맞게 기상을 예측하기 위해서 사용되는 수리적 공식이나 원형을 파괴하지 않고 조작·수정·변경시키기 위한 경제 모형 등
3)모델링 정의
-모델링: 실체를 나타내는 일과 모형화라는 의미로 해석
-데이터 모델링이란 사용자의 요구사항으로부터 데이터의 실체를 나타내는 일
-기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무 규칙에 대하여 참 또는 거짓을 판별할 수 있는 사실을 어떻게, 누가 접근하는지 또한 이에 대한 전산화와는 별개의 관점에서 이를 명확하게 표현하는 추상화 기법
4)데이터 모델이 제공하는 것
-시스템을 현재 또는 원하는 모습으로 가시화
-시스템의 구조와 행동을 명세화
-시스템을 구축하는 틀을 제공
-우리가 결정한 것을 문서화
-다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공
-특정 목표에 따라 다양한 상세 수준을 제공
*본질적 데이터 요구사항
-이름: 모든 속성은 고유하게 식별할 수 있는 이름이 주어져야함
-명세(Description): 모든 실체는 명세가 있어야 함. 모형을 검토하는 누구든지 실체를 정확히 해석할 수 있어야 함.
-유형(Type): 속성은 Key 속성 또는 Non-Key 속성중 하나로 구분되어야 함.
2.데이터 모델링의 중요성
-프로세스 중심의 분석/설계 방법을 통해 설계한 데이터 모델은 업무 프로세스의 변화에 따라 영향을 많이 받기 때문에 상대적으로 업무 변화에 대한 영향을 적게 받으면서 유연한 시스템을 만들기 위해 데이터 중심의 설계 필요성 대두
*파급효과(Leverage): 시스템구축이 완성되어 가는 시점에서 데이터 모델이 변경되면 많은 영향을 미침.
*복잡한 정보요구사항의 간결한 표현: 데이터 모델은 구축할 시스템의 정보 요구 사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구
*데이터 품질: 낮은 품질의 데이터는 활용가치가 떨어짐
1)애플리케이션과 데이터의 통합
-데이터를 기반으로 한 통합이 효과적이며 저비용
2)개발자들의 시스템 이해
-사용자관점 데이터: 사용자가 원하는 것의 논리적 개념과 시스템이 어떻게 그것을 제공하는지의 물리적 개념이 명확
-물리적 표현 또는 사용에 관계없는 데이터 그 자체의 본질: 변화되는 물리적인 것으로부터 독립
-애플리케이션간 데이터 사용: 데이터 정의, 생명주기 정보(CRUD) 그리고 언제 어떻게 데이터가 사용되었는지를 추적할 수 있는 방법 제공(매트릭스)
3)데이터 모델링시 주의점
-중복: 중복저장 문제 해결
-비유연성: 프로세스와 분리하여 프로세스 변화에 대한 영향 감소
-비일관성: 데이터와 데이터간 상호관계에 대한 명확한 정의로 모순을 제거
2절 데이터 모델링 기법 이해
1.엔터티-관계 데이터 모델
가.추상화
-현실세계에 존재하는 개체 또는 객체들의 공통된 특징, 즉 추상적 특징을 파악하여 인식의 대상으로 삼는 행위
#유형화: 현실세계에 존재하는 같은 성질을 갖는 멤버들을 타입 또는 유형이라는 하나의 개념으로 정의
#집단화: 값을 유형화하면 속성이라는 타입이 됨
#일반화: 여러 엔터티 타입 간의 공통적인 특성을 파악하는 과정
나.타입과 인스턴스
타입(Type): 실제 발생된 사례들을 추상화한 집합
인스턴스(Instance): 현실세계에서 실제로 발생된 사례(타입의 멤버)
2.엔터티-관계 데이터 모델 구성요소
-엔터티, 관계, 속성,도메인, 식별자
가.엔터티
-조직의 업무를 수행하는데 필요로하는 사물, 사건 또는 개념을 나타내는 어떤 것.
-동일한 업무 행위나 유사한 속성을 갖는 단일 개념으로 정의한 멤버들의 집합체
나.관계
-하나 또는 두 개의 엔터티에서 인스턴스를 연관시키는 업무적인 이유. 관계도 집합
다.속성과 도메인
-속성: 엔터티에 저장되는 인스턴스들의 특성을 설명하는 항목. 값을 추상화한 타입. 동일한 특성을 갖는 값의 집합.
-도메인: 하나의 속성이 갖는 같은 종류의 모든 값들의 집합
라.식별자
-엔터티에 저장되는 특정 인스턴스 하나를 식별할 수 있는 하나 또는 하나 이상의 속성.
Not Null, 유일성, 대표성, 최소성
다.데이터 모델링 단계
1)개념 데이터 모델링
-주제별로 분류 가능한 업무를 분석한 후 핵심 엔터티를 추출하고, 그들 간의 관계를 정의하여 전체 데이터 모델의 골격을 생성
-개념ERD 작성
2)논리 데이터 모델링
-개념 데이터 모델링 단계에서 정의한 핵심 엔터티와 관계를 바탕으로 상세 속성을 정의하고 식별자를 확정하며 정규화를 수행
-논리데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조무결성 규칙 정의 등을 하고, 이력 관리에 대한 전략을 정의하여 논리 데이터 모델에 반영
3)물리 데이터 모델링
- 논리 데이터 모델을 기반으로 목표 DBMS의 특성 및 구현 환경 등을 감안한 스키마를 일정한 기준과 규칙에 의해 도출하고 컬럼의 데이터 타입과 크기를 정의
-데이터 사용량을 분석 예측하는 과정을 통해 효율적인 데이터베이스가 될 수 있도록 인덱스의 정의 및 반정규화를 수행
라.모델링 기본원칙
-커뮤니케이션,모델링 상세화 원칙,논리적 표현
1)커뮤니케이션 원칙
-모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성.
-논리데이터모델: 비즈니스 지향적인 최종 사용자 데이터 모델과 기술적인 상세 데이터 모델
#데이터 모델의 이해를 필요로하는 그룹
-최종사용자:개념화, 추상화, 정규화 기법을 통하여 중복없고 데이터의 정확성을 보장하는 데이터 구조의 이해 및 사용
-시스템분석가:시스템에서 사용되어질 정확한 데이터의 구조 및 데이터가 갖는 업무 규칙의 이해
-DBA: 논리 데이터 모델의 구조와 물리 스키마의 차이점을 이해하고 최종 사용자에게는 데이터의 제공, 시스템 분석가에게는 물리 스키마의 제공을 위한 데이터 구조의 이해
-타프로젝트 분석가: 관련 프로젝트가 데이터를 어떻게 정의하고 있는지를 알아냄. 인터페이스가 개발되어지고 데이터가 애플리케이션 또는 시스템 간에 공유되기 위한 데이터 구조 및 업무 규칙의 이해
2)모델링 상세화 원칙
-데이터의 상세화 정도를 제시하고 조직이 사용하는 정보 구조의 ‘최소 공통 분모’를 제시
-복잡한 구조는 요소적인 부분들로 쪼개야 하며 불필요한 구조와 중복은 제거
3)논리적 표현 원칙
-조직의 데이터에 대한 논리적 측면을 최대한 표현
-모델은 물리적 제약 조건 없이 비즈니스를 그대로 반영
마.좋은 데이터 모델의 요소(완중업재 안의간통)
1)완전성: 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의
2)중복배제:하나의 DB내에 동일한 사실은 반드시 한번만 기록
3)비즈니스 룰: 수많은 업무 규칙을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용 하는 모든 사용자가 그 규칙을 공유하도록 제공
4)데이터 재사용: 데이터의 통합성과 독립성에 대해서 충분히 고려. 통합모델을 구축하고, 애플리케이션에 대해 독립적으로 설계
5)안정성 및 확장성
-현재의 데이터 구조를 거의 변화하지 않고도 변화에 대응할 수 있는 데이터 구조
-아주 적은 확장을 통해 이러한 변화에 대응
-정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합,‘행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합
6)간결성: 데이터를 합리적으로 균형있고 단순하게 분류
7)의사소통: 많은 업무 규칙은 해당 정보시스템을 운용*관리하는 많은 관련자들이 설계자가 정의한 업무규칙들을 동일한 의미로 받아들이고 정보시스템을 활용
8)통합성: 조직의 전체에서 한 번만 정의되고 이를 여러 다른 영역에서 참조
1.2데이터 모델링 기법 이해
가.데이터 모델 목적
-데이터 모델은 데이터베이스 설계에 대한 계획 또는 청사진
-데이터 모델링 단계에서 업무를 잘못 이해했거나 관계를 잘못 정의한 것이 발견되었다면 해당하는 다이어그램과 일부 관련된 문서만 변경하면 됨.
-데이터베이스와 응용 프로그램 개발이 완료된 후 이러한 오류를 발견하여 수정하려면 이와 관련된 많은 프로그램과 SQL문이 변경되어야 할 뿐만 아니라 데이터가 새로운 구조로 옮겨져야 하는 등 이러한 변경을 반영하는 데 많은 비용과 시간이 필요하게 됨
나.개체-관계 모델 기법
-데이터에 대해 관리자, 사용자, 개발자들이 서로 다르게 인식하고 있는 뷰들을 하나로 통합할 수 있는 단일화된 설계안
-서로 다른 뷰를 충족시킬 수 있는 데이터 처리와 제약 조건 등의 요구 사항을 정의
다.개체-관계 모델 구성요소
-엔터티, 속성, 식별자, 관계, 카디날리티, 존재종속, 서브타입
1)엔터티
-업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서, 그 대상들 간에 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합
2)속성
- 엔터티에 저장되는 개체 집합의 특성을 설명하는 항목
-실체내에서 관리하고자 하는 정보들의 항목
-도메인: 속성이 가질 수 있는 값의 범위
-단일치 속성: 하나의 값만 존재
-다중치 속성: 여러개의 값이 존재
3)식별자
-엔터티의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자를 가짐
-복합 식별자: 두 개 이상의 속성으로 이루어진 식별자
4)관계
-엔터티와 엔터티 간 연관성을 표현
-하나 또는 두 개의 실체를 연관시키는 업무와 관련된 중요한 사항.
-식별성, 선택성, 기수성, 비전이성
-매핑 카디날리티는 ERD에서 개체와 연결될 때 나타나는 대응되는 수로 대응수. 최대대응수, 최소대응수로 구분
5)카디날리티(기수성)
-- 한 개체가 관계를 통하여 다른 개체와 관련된 개체들의 수(관계에 참여하는 엔터티의 개수)
-1:1 : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X 에 속하는 한 개체에만 연결.
-1:M : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체는 X에 속하는 여러 개체와 연결
-M:M: X에 속하는 한 개체는 Y에 속하는 여러 개체와 연결가능, Y에 속하는 한 개체도 X에 속하는 여러 개체와 연결가능
6)존재 종속
-한 엔터티의 존재가 다른 엔터티(들)의 존재에 영향을 받는 경우. 전체참여, 부분참여
7)서브타입
-엔터티의 하위 집합(부분집합). 속성을 상속함
예)학생(슈퍼) > 학부학생, 대학원생(서브)
-배타적: 슈퍼타입은 많아야 1개의 서브타입관 관련. (돔안에 X표시)
-포괄적: 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련
-모든 슈퍼타입이 구분자를 가지고 있는 것은 아님.
-서브타입은 그것의 슈퍼타입이라 불리는 다른 개체의 특별한 경우
라.객체지향 모델링
-객체지향 방법론
-객체지향 분석
-객체지향 설계
-객체지향 모델링
-객체지향 프로그래밍
-객체지향 DBMS
1)객체지향 개념
-객체는 속성과 메소드로 구성. 속성은 객체 클래스의 성질. 메소드는 하나 이상 의 속성을 접근, 조작, 수정, 삭제, 생성하는 프로세스
-연관 또는 상속을 통해서 다른 객체들에 연결, 연관은 객체 간의 자연적 관계
2)객체 모형
-주제에 연관된 기본 객체 식별, 객체간의 연관을 식별
3)객체 모형 데이터
-객체-관계 다이어그램에 모형화
4)객체 모형의 메소드
-단순한 메소드는 설명부 또는 구조화된 기법 사용
-복잡한 메소드는 정교한 문서화 접근 방식이 필요
-이벤트 지향적인 프로세스는 상태 전이 모델링과 같은 동적 프로세스 모델링 기법이 필요
-정적인 프로세스는 데이터 흐름 다이어그램이나 기능 분해와 같은 기법을 사용
5)불명료한 객체 접근 방식
-객체지향 개발의 가장 단순화된 표현: 객체지향 개발을 분명하게 이해하는데 필요한 많은 객체지향 특징을 무시하는 것
-객체지향 모델링의 미성숙: 객체가 어떻게 표현되고 기호가 어떻게 사용되어야 하는가 등의 정의는 아직까지 초기단계.
객체지향 모델링과 논리 데이터 모델링간의 관계
객체-엔터티, 속성-속성, 연결-관계, 객체클래스-엔터티유형
6)객체지향 모델링 장점
-재사용 코드, 모든 비즈니스 규칙 표현, 프로세스와 데이터 모델링을 함께 운영
-객체가 다른 객체와 연결되는 방법은 연관 또는 상속
3절 데이터 모델링 표기법 이해
가.바커 표기법
1)엔터티
-엔터티는 네 부분의 모서리가 둥근 형태인 소프트-박스(Soft-box)로 표현. 실체명은 박스안에 작성.
2)속성
-해당 속성에 어떤 값을 반드시 저장해야 하는 경우에는 * (Mandatory)를 표시하며 해당 속성에 어떤 값이 존재할 수도 있고 존재하지 않을 수도 있는 경우에는 o (Optional)를 표시
3)관계
-두 개의 엔터티간에 CONDITIONAL을 표기한 후 해당 엔터티의 가까운 위치에 관계 명칭을 표기하고 관계는 실세계의 해당 엔터티에서 발생하는 동사적 단어들을 표기
#엔터티간의 관계
1:1 관계 : A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수도 1개인 엔터티간의 관계
1:M 관계 : A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수가 여러 개인 엔터티 간의 관계
M:M 관계 : A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수가 여러 개이며, B 엔터티에 존재한 데이터 1개와 관계되는 A 엔터티에 존재하는 데이터의 개수도 여러 개인 엔터티 간의 관계
2)관계 선택성 표기법
#필수관계: 엔터티 A,B관계에서 B에 인스턴스를 입력할때 A에 하나의 인스턴스를 입력해야 하는 경우, A의 선택성은 필수
#선택관계: 엔터티 A,B관계에서 B에 인스턴스를 입력할때 A에 하나의 인스턴스를 입력할 필요가 없는 경우, A의 선택성은 선택
-선택성(Optional): 페어링의 존재여부. 하나 또는 두개의 엔터티간에 관계가 설정될때, 모든 인스턴스간에 페어링이 존재해야 하는지(Mandatory), 아니면 모든 인스턴스에 대하여 페어링이 존재할 필요가 없는지(Optional) 표시
-선택성 결정방법
->필수: 다른 엔터티에 어떤 행을 입력하기 전에 상대 엔터티에 적어도 한 건의 행이 반드시 있어야 하는 경우
->선택: 다른 엔터티에 어떤 행을 입력하기 전에 상대 엔터티에 어떤 행이 존재할 필요가 없는 경우
3)관계 식별성 표기법
#식별관계: 부모 엔터티의 식별자가 자식 엔터티의 식별자의 일부분이 되는 관계(주문-주문상품)
자식엔터티는 부모엔터티에 대해 존재종속이며, 식별종속임.
#비식별관계: 부모 엔터티의 식별자가 자식 엔터티의 일반 속성으로 표현되는 관계(부서-사원)
자식엔터티는 부모 엔터티에 대해 존재 종족이지만 식별종속은 아님
#엔터티와 엔터티간 상관 관계의조건
필수 조건: 필수 사항은 실선으로 표시하고 상대 엔터티에 대해 해당 엔터티에 조건을 만족하는 엔터티가 반드시 존재할 경우에 표시
선택 조건: 선택 사항은 점선으로 표시하고 상대 엔터티에 대해 해당 엔터티에 조건을 만족하는 엔터티가 존재할 수도, 존재하지 않을 수도, 있을 경우 표시
4)식별자
-하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성
-엔터티에 저장되는 특정 인스턴스 하나를 식별할 수 있는 하나 또는 하나 이상의 속성
#식별자의 유형
*본질 식별자: 집합의 본질을 명확하게 설명할 수 있는 의미상의 주어
*후보 식별자: 각 인스턴스를 유일하게 식별할 수 있는 속성 또는 속성들의 조합
*대체(보조) 식별자: 원래의 식별자를 대신할 수 있는 또 다른 속성들이나 릴레이션십
*인조 식별자: 식별자 확정시 기존의 본질 식별자를 그대로 실질 식별자로 인정할 수 없는 여러 가지 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을 가진 속성들로 대체하여 새롭게 구성한 식별자
*실질 식별자: 인스턴스를 식별하기 위해 공식적으로 부여된 식별자. 본질, 인조
-식별자 앞에는 # 기호를 표시하고 여러개 # 기호를 반복적으로 표시
5)서브타입
-슈퍼타입 안에 서브타입을 상자로 나타냄
6)관계의 표현 비교
나.IE 표기법(정보공학)
1)엔터티
-사용자가 추적하고자 하는 어떤 사물. 사각박스로 표현. 엔터티명은 박스 밖에 기재.
2)속성: 엔터티의 특징을 기술
3)관계
필수는 세로선(|), 선택은(o)
4)식별자
- 수평선이 식별자 밑에 그려짐
5)서브타입
배타적이라면 슈퍼타입은 많아야 1개의 서브타입과 관련(동시에 1개, 사원=정규 or 계약)
포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련(동시에 1개이상 가능, 연예인=가수&배우)
4절 관계형 모델 이론
1.릴레이션 개념
-관계형 모델에서 테이블을 의미. 테이블의 열은 애트리뷰트, 행은 튜플
#릴레이션 정의: 집합x와 집합y 사이에 관계 R을 만족하는 모든 순서쌍(곱). 수학적 정의로 보면 주어진 도메인들의 카티션 프로덕트의 부분집합
#속성과 도메인의 개념
-애트리뷰트(속성) 값은 업무에서 의미를 갖는 더 이상 분해할 필요가 없는 값, 즉, 원자값
-원자값: 업무를 수행하는데 의미 있는 데이터의 최소 단위
-도메인: 하나의 애트리뷰트(속성)가 갖는 같은 타입(유형)의 모든 원자 값들의 집합
애트리뷰트와 도메인은 프로그래밍 언어에서 변수와 데이터 타입에 비유
2.관계형 모델 이론
-데이터 구조: 사용자가 인식하는 데이터의 구성
-데이터 조작: 사용자가 관계형 데이터 구조에 행하는일련의 연산(처리)형태
-데이터 무결성: 사용자가 일련의 관계형 연산을 수행할때 테이블의 데이터 값이 어떻게 되야 하는지를 통제하는 일련의 업무 규칙
가.데이터 구조
#릴레이션의 6가지 특성
1)각 열은 하나의 값. 애트리뷰트의 원자성
2)각 열의 값은 동일한 종류. 도메인 무결성
3)각 행은 유일. 튜플의 유일성> 엔터티 무결성
4)열의 순서는 무의미. 애트리뷰트의 무순서성
5)행의 순서는 무의미. 튜플의 무순서성
6)각 열은 유일한 이름을 갖는다.
나.데이터 조작
-집합(SET)처리
-관계연산자: 조회
*Select(or Restrict): 열에 의거한 행의 부분집합
-- Example: Select all employees from the "Employee" table with a salary greater than 50000
SELECT * FROM Employee WHERE Salary > 50000;
*Project(π): 열의 부분집합(subset)
-- Example: Project only the "EmployeeID" and "Name" columns from the "Employee" table
SELECT EmployeeID, Name FROM Employee;
*Product(×): 두 관계 테이블간 행의 조합을 묶음
-- Example: Find the Cartesian product of the "Employee" and "Department" tables
SELECT * FROM Employee, Department;
*Join(⨝): 열의 기준에 의거하여 각 행을 수평적으로 묶음
-- Example: Inner join "Employee" and "Department" tables on the "DepartmentID" column
SELECT * FROM Employee INNER JOIN Department ON Employee.DepartmentID = Department.DepartmentID;
*Union(∪): 중복없이 각 행을 수직적으로 묶음(합집합)
-- Example: Combine the names of employees from "Dept_A" and "Dept_B" without duplicates
SELECT Name FROM Employee WHERE Department = 'Dept_A'
UNION
SELECT Name FROM Employee WHERE Department = 'Dept_B';
*Intersection(∩): 관계 테이블간의 공통된 행(교집합), 테이블 구조는 동일
-- Example: Find employees who are in both "Dept_A" and "Dept_B"
SELECT Name FROM Employee WHERE Department = 'Dept_A'
INTERSECT
SELECT Name FROM Employee WHERE Department = 'Dept_B';
*Difference(- 또는 제외): 하나의 관계 테이블에만 있는 행(차집합), intersection의 반대
-- Example: Find employees in "Dept_A" but not in "Dept_B"
SELECT Name FROM Employee WHERE Department = 'Dept_A'
EXCEPT
SELECT Name FROM Employee WHERE Department = 'Dept_B';
*Division(¼): 다른 관계 테이블의 모든 행에 대응하는 열을 제외한 열. (R에서 S의 레코드를 다가진 레코드)
-- Example: Find employees who have worked on all projects
SELECT EmployeeID FROM WorksOn
WHERE ProjectID IN (SELECT ProjectID FROM Project);
-처리연산자: 관계 테이블의 내용에 변화
*Insert: 행의 삽입
*Update: 행의 수정
*Delete: 행의 삭제
다.데이터 무결성
-업무규칙에 따라 데이터의 일관성과 정확성을 유지하는 특성
-사용자가 일련의 관계형 처리(입력, 수정, 삭제, 조회)를 수행할 때 관계형 엔터티의 데이터값이 어떻게 작용해야 하는지 통제하는 일련의 업무규칙
1)엔터티(실체) 무결성
-두 개의 똑같은 튜플은 한 릴레이션에 포함불가
*유일식별자: 엔터티 내 특정 인스턴스를 다른 것과 구별할 수 있도록 식별해주는 하나 이상의 속성과 관계의 집합
-식별자를 구성하는 각 속성이 NOT NULL
-엔터티내 특정 인스턴스의 유일성 보장
-최소한의 속성 집합
2)참조무결성
-데이터가 하나 또는 두 개의 관계있는 엔터티에 입력, 수정, 삭제될때 데이터가 어떻게 반응해야 하는가에 대한 업무 규칙
*엔터티의 주키와 마찬가지로 외래키도 데이터 무결성에 관한 규칙을 내포
*참조무결성규칙: 엔터티의 모든 외래키 값은 관계 있는 엔터티에 주 키 값으로 존재해야함
*DB설계관점에서 선택하지 말고, 현업의 업무규칙에 따라 적절한 규칙을 선택.
#입력규칙: 자식 엔터티의 행이 입력될때
#삭제규칙: 부모 엔터티의 행을 삭제할때 (또는 행의 주키를 수정할때)
3)도메인 무결성(길이, 허용값, 범위)
-엔터티 내의 모든 열에 관한 무결성 규칙으로 데이터 타입, 길이, 허용값, 기본값, 유일성, 널 여부 등에 관한 업무규칙
-도메인: 속성이 가질 수 있는 값의 전체 집합
-같은 도메인의 값들끼리만 비교 가능
-속성이 취할 수 있는 값의 제한
4)연쇄작용 또는 업무규칙
-연쇄작용: 입력,수정,삭제 또는 조회 등의 작업이 동일 엔터티 혹은 다른 엔터티의 속성에 영향을 미치는 업무 규칙
-업무규칙은 조직이 데이터를 인식하고 사용하는 방법에 기초
| 구분 | 관계형 | 비관계형 |
| 구조 | -6가지 특성 갖는 테이블 -Post Define Schema -DB구조변경 용이 |
-Flat File -Pre define Schema -DB구조변경 어려움 |
| 조작 | -8개 조회/처리 연산자 -집합(SET)처리 -원자값 처리 |
-READ조회, 처리연산자 -한건씩 처리 -Pointer 처리 |
| 무결성 | 엔터티,참조,무결정,연쇄작용 | 무결성 개념 없음 |
| 접근경로 | -Key와 인덱스 별개 -Data에 대한 접근경로 유연 |
-Key와 인덱스 동일 -Data에 대한 접근경로 제한적 |
2.개념 데이터 모델링
2.1개념 데이터 모델링 이해
데이터 분류/관리 체계 필요
-중복배제, 확장성, 효용성
가.개념 데이터 모델 정의
-핵심 엔터티들로 구성된 모델
-핵심엔터티: 행위의 주체나 목적물이 되는 개체 집합에 해당하는 엔터티
나.개념데이터 모델 의의
-개념적 모델은 개괄적 모델을 좀더 상세화된 형태로 진화시키거나 중요 엔터티만 선정하여 모델링
-사용자가 요구하는 데이터의 범위 및 구조 확인을 돕고, 개발범위 결정을 지원
-선진사례 적용 용이
다.데이터아키텍처 프레임워크 상에서 개념 데이터 모델
-개념 데이터 모델은 개괄 데이터 모델과 논리 데이터 모델 사이에 존재하는 모델
-개괄데이터 모델은 데이터 아키텍처상에서 최상위 수준의 관점을 정의
-개념데이터모델링은 분석초기에 수행되어 본질적으로 기술과 무관한 사양들의 집합을 형상화하여 데이터 요구사항을 정의하고 비즈니스 이해관계자들과 초기 요구사항을 논의하는데 사용
-개념데이터모델에서부터 출발하여 다른 데이터요소와 그 상호관계가 무언인지를 상위레벨에서 이해하는 것이 바람직
개념모델링 구성요소
주제영역>핵심엔터티>관계>핵심속성>식별자
2.2주제 영역 정의
가.주제영역 개념
-기업이 사용하는 데이터의 최상위 집합
예)제조의 경우, 인사,생산,자재,판매
-시스템의 대상이 되는 업무를 명백하게 구분이 가능한 단위업무로 분리하는 개념
-주제영역 내부에 존재하게될 개체들이 높은 결합성을 유지하게 해야함.
-프로세스 모델링의 기능과 매핑
*주제영역의 역할
-전사 업무를 위한 전체 데이터 구성에 대한 청사진
-전사 표준 주제 영역을 기반으로 데이터 오너쉽을 부여하고, 해당 영역 데이터에 대한 표준 및 활용/품질에 대한 권리를 수행하는 기준단위 영역
-전사 통합/단위 개념 모델 수립시 참조정보로 활용
나.주제영역 분류 원칙 및 기준
1)주제영역 분류 원칙
*데이터 중복 최소화
*데이터 확장성 보장
*데이터 관련성 및 편의성 확보: 타자원과의 인접성 고려, 고객 편의를 고려
2)주제영역 분류 기준
#데이터 관점의 분류
*업무를 발생시키는 주체, 대상 및 행위 등 데이터 관점에서 데이터를 생성시키고 사용하는 유형에 근거하여 분류
*장기적이고 전사적인 관점에서 데이터 유사성을 고려
*시스템이나 애플리케이션이 다르더라도 동일한 유형의 데이터를 유사한 방식으로 활용한다면 이를 동일한 영역으로 분류
#업무 요건 추가에 대한 유연성 보장
*업무 요건의 변경이나 추가 시 유연성을 보장할 수 있도록 전사 분류 체계를 설정
*업무 요건 변경에 대해서 데이터 구조의 변경을 최소화하려면 동일한 유형의 데이터를 본질이 희석되지 않는 한도내에서 최대한 집합으로 통합
*새로운 영역이 필요한 상황이 발생한다면 전사적인 협의를 통하여 적절한 계층의 분류 구조를 조정
#주제영역 간 균형 유지
*데이터 분류는 일부분에 국한된 것이 아니고 전체적인 균형을 유지하는 것이 중요
*특정 부분을 너무 상세하게 분류하거나, 분류 방식이 타 영역과 다른 방식으로 되어 있으면 전체적인 혼란
*데이터 분류에 대한 추가나 변경이 발생할 경우 해당 부문만을 고려하여 수행하기보다는 타 영역의 분류 체계와의 형평성 및 균형을 고려하여 분류 구조를 관리
3)주제영역 명명
-실 업무에서 보편적으로 사용하는 업무 용어 예)인사분야, 판매분야
-유일한 단수형 명사
-데이터의 그룹을 의미하는 이름 사용 업무활동을 의미하는 이름 배제
예)재무관리(기능), 재무시스템>재무분야(데이터)
4)주제영역 정의 절차
5)주제영역 분류방법
#1차분류: 주요 데이터 집합의 유형 정의
*기존의 시스템별로 제공되는 데이터의 성격 및 특성을 고려하여 영역을 분류
*업무의 변화에 민감하지 않도록 정의
*분류 예시
- 데이터를 발생시키는 주체로서의 분류 >>관계자, 상품/서비스, 자산, 채널 등
- 데이터를 발생시키는 주체 간의 상호작용으로 발생하는 대상으로서의 분류
>> 계약, 리스크, 상품, 조건
- 공통 및 관리 성격의 상위 개념으로서의 분류 >>경영 관리(정보, 방침, 지원 등)
#2차분류: Biz 활동에 필요한 데이터 분류
*Biz 활동에 필요한 분석 주제와 현황 등의 영역으로 분류
*기본(정보), 상세(정보), 관계(정보) 등과 같은 데이터의 기능적 구성 관점에서 접근하여 1차 분류를 세분화
*업무 변화 수용의 융통성을 반영하여 정의
*분류예시
- 관계자 : 관계자 기본, 관계자 상세, 관계자 관계, 관계자 분류 등
#3차분류: 2차 영역의 세부 주제 영역 분류
*Biz 활동에 필요한 분석 주제와 현황 등의 영역으로 분류
*사용자에게 제공되는 실제 데이터로서의 관점에 근거하여 정의
*업무적인 관점에서 분류
*분류예시
- 관계자(기본) : 고객, 법인, 조직, 직원 등
- 계약(기본) : 수신계약, 예금계약, 신탁계약 등
#데이터의 그룹을 의미하는 이름을 부여
다.주제영역 활용
1)목적
-데이터의 계층적 구조를 파악
-점진적인 상세화로 상위 수준에서 모델의 안정성 유지
-업무 기능과 병행하여 분석하는 경우에 분석의 최상위 단위 역할을 하여 품질 확보에 기여
-주제 영역 계층과 업무 기능 계층 간의 대응 관계를 확인
-기업의 전사 업무를 위한 전체 데이터 구성에 대한 청사진을 제공
-데이터 구성 및 통합에 대한 방향 제시
-효율적 데이터 관리를 위한 기준을 제공
2)장점
-데이터 및 업무 활동 모델의 품질 보증
-프로젝트 관리 용이
-모델 개발 조정 용이
-레파지토리 관리 용이
-상세 사항의 전개 혹은 축약 가능
-요구사항 검증 기준
라.주제영역 도출
1)업무에서 사용하는 데이터의 명사형 도출
-정보수집소스에서 명사형 찾기
2)업무 기능의 이름으로부터 도출
-데이터와 업무 활동의 상호 보완 관계
3)하향식 접근방법
-주제 영역에서 출발하여 엔터티 타입으로 전개
4)상향식 접근방법
-엔터티 타입을 그룹핑하여 주제 영역 도출
5)분석 단계에서의 도출
아키텍처 모델을 정련하는 과정에서 도출
데이터 모델을 상세화하는 과정에서 도출
마.주제 영역 정의 내용
1)주제 영역 목록
레벨 : 주제 영역의 계층 수준(1차, 2차, ... 단위)
주제 영역명
설명(단위 주제 영역의 경우)
대표 엔터티 : 해당 주제 영역 내에서 대표적인 엔터티를 기술
2.3후보 엔터티 선정
가.개념
-엔터티 정의: 엔터티의 개념 정의에 적합한 대상을 찾아 후보 검증을 거쳐 엔터티로서 확정하고, 데이터 집합으로서 해당 엔터티의 성격을 규명하는 것.
-엔터티 후보를 찾아서 검증 및 판명
절차: 엔터티 후보 선정>엔터티 형태별 분류>엔터티 자격 검증>엔터티 형태 결정>본질식별자 확정>엔터티 정의서 작성
나.엔터티 후보 수집
#기존 시스템 도큐먼트
-데이터 구조 및 프로세스 명세들이 나타나 있는 설계 자료에서부터 사용자를 위한 지침서
#현업 장표/보고서
업무의 효과적인 처리를 위하여 많은 장표, 처리된 업무의 집계·분석·관리를 위해서 많은 종류의 보고서
#현업 인터뷰
-현업 담당자들과 같이 시작
#관련 전문 서적
-현실에 적용하기 위해 고민하고 있는 문제를 해결하는 데 필요한 아이디어나 힌트
#데이터 흐름도
-데이터 저장소와 데이터 사전에 있는 정보를 이용
#타시스템 자료
-타 시스템이 가지고 있는 엔터티를 면밀히 조사해 차이점 분석
#현장 조사
-현장을 답사
다.엔터티 후보 선정시 유의사항
-엔터티 가능성이 있다고 예상되면 일단 검토 대상에 올려라
-너무 깊게 들어가지 마라
-동의어처럼 보이더라도 함부로 버리지 마라
-개념이 모호한 대상은 일차로 그 개념을 상식화하여 이해
-프로세스에 너무 연연해 하지마라
-예외 경우에 너무 집착하지마라
-단어 하나하나에 집중해서 판단
-후로를 선정했으면 핵심적인 특징 파악
-사용자에게 의존말고 자신의 이해를 바탕
-구현할 시스템의 업의 본질 염두
라.엔터티 후보 식별
1)엔터티 후보의 개념 정립
-후보 검토 대상의 최초 상태인 단어의 구체적인 집합을 정의
2)관리 대상 판정
-단어에 대해 관리하고자하는 대상이 맞는지 확인
3)집합 여부 확인
-검토 대상이 집합이 되는지 확인(가로와 세로가 각각 2개이상인가)
-가로는 속성, 세로는 개체(인스턴스:구체화한 대상)
마.수집된 엔터티 분류
-개념 데이터 모델링에서는 데이터 모델의 골격을 잡는 일부터 철저하게 수행.
-엔터티 후보를 분류하는 작업부터 수행
-개체집합, 행위집합
1)우선 적용 대상 분류
-모델링의 골격에 해당하는 주요 엔터티를 먼저 도출하여 이를 명확히 정의함으로써 모델링의 기초를 단단히 함
#키 엔터티
*자신의 부모를 가지지 않는 엔터티
예)사원, 부서, 고 객, 상품, 자재
#메인 엔터티
-키 엔터티를 제외한 다른 모든 엔터티는 부모 엔터티를 가지고 있어야만 태어남.
-업무의 중심에 해당하는 엔터티를 메인 엔터티라 정의하고, 나머지를 액션 엔터티로 정의
메인 엔터티 예) 주문, 예산편성, 매출
#액션 엔터티
-키엔터티와 메인엔터티가 아닌 엔터티. 수행된 업무를 포함
예)상태 이력, 차량 수리 내역, 상세 주문 내역
2)우선적용 대상 분류 사례
3)데이터 영역별 분류
-데이터 영역을 정의하는 방법은 접근 방법별로 볼 때 크게 하향식과 상향식 접근 방법
예)모델(사람)-엔터티후보(사원,가입자,회원,고객,협력사 직원..)
#데이터 성격에 따른 분류
-엔터티 후보들간 미묘한 차이 분석
-엔터티 통합 여부 판단
-엔터티 정의 견고하게
다.코드성 키 엔터티 선정기준
-개념모델링 단계에서는 도출하지 않아도 무관
#다음 4가지 기준에 해당하면 미리 도출
이 엔터티가 자식 엔터티를 가지는가?
이 엔터티가 자신만의 다양한 속성을 가질 것인가?
이 엔터티가 여러 엔터티에 관계를 가질 것인가?
이 엔터티가 다양한 종류의 관계를 가질 것인가?
1)자식 엔터티 유무 확인
2)속성 존재 여부 확인
3)관계 존재 여부 확인
2.4핵심 엔터티 정의
가.개념
1)엔터티란
-업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상에 대한 데이터를 저장할 수 있고 대상들 간의 동질성을 지닌 개체 또는 행위의 집합
-다른 것과 구별되어 식별될 수 있는 사물
-구별가능한 사람, 장소, 물건, 행위 또는 개념 등에 대하여 정보가 유지되어야 하는 것.
2)엔터티 정의의 요건
-우리가 관리하고자 하는 것인지를 확인
-가로와 세로를 가진 면적(집합)인지를 확인
-대상 개체들 간의 동질성이 있는지를 확인
-다른 개체와 확연히 구분되는 독립성을 가지는지를 확인
-순수한 개체이거나 개체가 행위를 한 행위 집합인지를 확인
나.의미상 주어 정의
누가,언제,무엇을,어디서에 해당
-본질 식별자
1)본질 식별자 정의의 의의
-집합의 의미를 명확하게 함
-내용(의미)상의 진정한 식별자
-누가+무엇을+언제
-직접종속이면서 절대종속
-특별한 하자가 없다면 이것이 곧 실질식별자
2)본질 식별자 정의 예
-신용카드 엔터티의 본질 식별자인 고객 번호와 상품 코드는 부모에게서 상속받은 관계 속성이며, 이 부모들은 바로 키 엔터티
-신용카드 카드번호는 인조식별자, 실질식별자에 해당.
-고객번호, 카드상품코드, 카드발급일시 등이 본질식별자.
-본질식별자를 이루는 속성이 없을때 자신이 절대로 태어날 수 없는 경우에만 해당
-인조식별자는 본질식별자가 될 수 있음
#실질식별자
-최종 확정된 공식적인 식별자
-본질식별자의 전부나 일부를 인조속성으로 치환하여 실질식별자를 생성할 수 있음
-관계를 통해 상속되는 식별자
다.코드성 키 엔터티
라.집합 순수성
1)집합 순수성 의미
-엔터티는 반드시 순수한 본질 집합이 되어야 함. 개체집합, 행위집합
-
2)집합 순수성 예
-개체집합은 고객, 상품
-행위집합은 입금, 계약
-납입자는 고객이라는 본질집합과 납입이 결합되어 만들어진 관계 집합
3)집합 순수성 적용 예외 사항
#관계의 엔터티화
-관계가 M:M이 되면 릴레이션 엔터티로 바뀜
예)피보험자=피보험+자, 보험계약 이라는 관계 엔터티 도출
#일부 집합 정의
-전체 논리적인 집합 중에서 관리하고자 하는 일부의 집합만을 엔터티로 정의
예)금융기관=금융+기관, 금융은 기관이라는 큰집합의 부분집합
#배타적 관계 대체
-엔터티가 여러 엔터티와 동일한 내용의 관계를 갖는 배타적 관계를 가질 때 배타적 관계에 있는 것들만 모아서 별도의 엔터티를 구성
예)배송처=배송+처, 처에는 여러 집합이 존재하고 앞으로 늘어날 가능성이 높음.
마.집합 동질성
1)집합 동질성 의미
-동질성: 대상들 간에 하나의 동등한 본성 또는 본체나 본질, 성질 등을 공유하고 있다는 의미
-집합에 들어갈 개체들의 동일한 성질을 어디까지로 한정할 것인가를 결정하는 것
2)집합 동질성 부여의 예
바.엔터티 명칭
1)적절한 엔터티 명칭
-엔터티를 함축시킨 의미를 포함. 의사소통시 의미를 명확히 전달
사.서브타입
1)서브타입 지정 의의
-엔터티내에 들어가는 부분집합(서브타입)의 종류를 명시
예)고객 : 개인,법인
2)서브타입 지정시 고려사항
#교집합 허용 불가
-남자와 여자의 교집합은 불가
#서브타입의 합이 전체집합
-서브타입을 모두 결합하면 반드시 전체 집합
#서브타입 표현의 기준
-물리모델에서 테이블 분할의 기준 역할
*개별 속성을 가지는 경우
*개별 관계를 가지는 경우
*가독성을 증진시키고자 하는 경우
#하나의 엔터티에 서브타입 유형은 하나만 존재해야 함(최종 모델)
>바커표기법에서는 멀티 서브타입 표현이 가능
#적용기준
-분류속성에 따라 엔터티의 정보가 차별화되는 경우
-서브타입으로 분할함으로써 관계가 필수관계로 변하는 경우
3)서브타입 도출
#분류 속성
-분류 속성에 따라 엔터티의 정보가 차별화되는 경우
#다수의 선택적 속성
#선택적 관계가 존재하는 경우
*서브타입을 분할하여 관계가 필수적으로 변하는지 확인
#도출 절차
*분류 속성을 확인(엔터티의 발생이 차별화되는 경우).
*분류 속성값에 의해 분류되는 서브타입을 파악
*분류 속성에 따라 필수적/선택적 분할을 정의
*서브타입별 속성을 할당
*슈퍼타입의 관계를 해당 서브타입에 정의
#서브타입의 활용
*엔터티의 정의를 좀더 구체화하여 데이터 모델에 대한 가독성을 향상
*속성의 선택성 제거
*관계의 선택성 제거
아.엔터티 통합과 분할
1)엔터티 독립성
-우리가 새롭게 정의하고자 하는 엔터티가 앞서 정의해 둔 어떤 엔터티에도 포함되지 않는 독립적인 집합인지를 확인
2)엔터티 분할/통합
-확장 교차된 부분을 어느 한쪽 집합에서만 가지도록 해, 둘 사이를 완전 분리하는 방법
-교차되는 부분이 있더라도 두 집합을 별개의 집합으로 간주하고 필요시 이들 간에 관계를 맺어 주는 방법
-엔터티 통합은 유연성 향상
-하위엔터티를 위해 최대한 통합을 유도
-무리한 통합은 집합의 독립성 저해
-통합을 통해 배타적관계의 가능성 감소
-키엔터티는 가능한 통합
#엔터티 분할
-한 테이블의 데이터가 많고, 특정범위만 주로 엑세스하면 수평분할
-수평분할시 각 테이블을 서로 다른 디스크에 위치하면 물리적디스크의 효용성 극대화
-테이블 컬럼수가 많고 조회위주컬럼과 갱신위주 컬럼이 구별되면 수직분할
-특정컬럼의 크기가 큰경우 수직분할
자.엔터티 정의 기술과 엔터티 정의서 작성
-데이터 집합의 개념 및 성격
-집합 구성상의 특징
-데이터 생성, 변경, 삭제 시의 특이사항 또는 데이터 오너쉽 등 기타 특이사항 등
2.엔터티 분류
가.일반적인 엔터티 분류
1)유형 엔터티: 물리적으로 존재하는 대상(고객, 상품)
2)활동 엔터티: 어떤 사건에 관한 정보(주문, 계약)
3)개념 엔터티:관리할 정보가 있는 무형의 개념(성적)
나.모델관점의 엔터티 분류
#독립 엔터티: 인스턴스를 식별하는데 있어서 어떤 다른 인스턴스에 의존하지 않는 엔터티 (고객, 제품, 사원)
#종속 엔터티: 인스턴스를 식별하는데 있어서 하나 또는 하나 이상의 다른 인스턴스에 의존하는 엔터티 (사원가족, 주문상품)
-특성 엔터티: 하나의 인스턴스에 여러 번 발생하는 속성의 그룹, 다른 인스턴스에 의하여 직접적으로 인식되지는 않는 엔터티(사원경력)
-연관 엔터티: 두개 이상의 연관된 다른 엔터티로부터 식별자를 상속받는 엔터티(다대다 관계 해소시 생성됨)
-서브타입 엔터티: 다른 부분집합과 구별되는 공통속성이나 관계를 공유하는 엔터티의 부분집합
다.발생 시점 엔터티 분류
1)키 엔터티: 자신의 부모를 가지지 않는 엔터티
-사원,부서,고객,상품,자재..
2)메인 엔터티: 키 엔터티를 제외한 엔터티 중에서 업무의 중심에 해당하는 엔터티
-주문, 매출, 사고, 청구
3)액션 엔터티: 키와 메인 엔터티가 아닌 것. 수행된 업무를 담고 있으며, 반드시 부모를 갖는다.
-상태 이력, 상세 주문내역
3.엔터티 도출
-도출방법: 기업의 전략*목표 분석, 사용자 인터뷰, 현시스템 분석, 정보요구분석, 문서*보고서 분석
가.현행 DB로부터 엔터티 도출
#현행DB분석이유
-ASIS DB가 조직의 정보요구사항을 빠짐없이 정확하게 지원하는지 확인
-ASIS DB의 구조적인 문제점 및 해결방안 도출
-목표 정보요구사항을 지원하기 위해 논리 데이터모델을 어떻게 생성할지 결정
-데이터 이행이 필요한 경우, 원천데이터 파악
나. 정보요구 분석
-정보요구: 부서가 주어진 목적을 달성하고 기능을 수행하기 위해서 필요로 하는 정보
다. 업무에서 사용하는 문서로부터 도출
-현업에서 사용하고 있는 실 데이터 값이 보이는 문서
라.사용자 인터뷰로부터 도출
-현업 업무 전문가와 인터뷰를 통해 업무규칙을 명확히 이해하는 것이 좋지만 현실은 그렇지 못함
마.아키텍처 모델로부터 도출
-ISP, EAP 의 전사 개념 데이터 모델
바.업무를 수행하는 프로세스로부터 도출
-프로세스 중심 데이터 모델링로 고려
사.엔터티 분류 기법을 활용하여 도출
-독립>종속.
4.엔터티 검증
가.조직의 업무를 수행하는데 필요한 의미있는 정보를 나타내야 함
나.특정 사례가 아닌 유사한 사물들을 대표하는 집합체 (구매부서 > 부서)
다.인스턴스가 포함할 내부 연관성 있는 속성에 의해 결정된 단일개념을 대표해야함.
라.엔터티내 인스턴스의 출현을 구별할 수 있는 능력을 제공해야 함.엔터티 무결성
마.정규화 규칙을 만족해야함.
5.엔터티 정의사항
가.엔터티명
-명명규칙 준수한 고유한 이름
1)엔터티명은 현실 세계의 인스턴스 및 정보를 대표
2)엔터티명 자체로 의미를 표현
3)물리적인 사항을 개념화한 논리적 사물을 반영
4)최소한의 어휘를 사용하여 의미를 전달
나.엔터티설명
다.엔터티분류
라.현재 발생 건수
마.발생 건수 변화
바.권한
사.식별자 속성
자.식별자 이외 속성
6.엔터티 일반화
가.일반화 정의
-현실세계의 사물, 사건을 단순화하여 표현하는 추상화 기법 중 하나로 엔터티의 부분집합 정의
#슈퍼타입: 일반화 계층의 가장 상위에 있는 엔터티
#서브타입: 다른 부분집합과 구별되며, 공통의 속성이나 관계를 공유하는 인스턴스들의 부분집합
나.일반화 특성
-슈퍼타입은 두 개이상의 독립적인 서브타입으로 구성
-슈퍼타입은 각 서브타입들의 공통적인 속성과 관계를 가짐
-서브타입은 자신의 속성이나 독립적인인 관계를 가짐
-자신의 속성이나 관계를 가지지 않는 서브타입도 존재할 수 있으나 이런 경우는 일반적인 속성으로 처리하는 것이 좋음
- 슈퍼타입과 서브타입은 결코 부모-자식 관계가 아니다
- 슈퍼타입의 인스턴스는 서브타입 중 단 하나와 반드시 연결되어야 한다．
- 서브타입은 서로 중첩되지 않아야 하며(교차 불가) 그 전쳬집합은 슈퍼타입과 1:1이다. 전체집합에 확신이 없다면 '기타' 구분을 생성
#배타적: 슈퍼타입은 많아야 1개의 서브타입관 관련. 돔안에 X표시. (사원=정규 또는 계약)
#포함적(포괄적):슈퍼타입은 1개 또는 그 이상의 서브타입과 관련(연예인=가수&배우)
다.일반화 시점
1)인스턴스가 공통적인 속성 집합을 가질때(고객=개인or법인)
2)인스턴스가 공통적인 관계 집합을 가질때
라.일반화 장단점
| 구분 | 일반화 | 상세화 |
| 장점 | ·데이터가 통합되어 있어 조회가 간편 ·한 개의 프로그램으로 업무를 처리 ·동일한 종류의 업무 추가 시 최소한의 변경으로 지원 ·전쳬적인 업무 로직 변화의 경우 신속하게 반영 |
·업무에 대한 명확한 파악 ·데이터의 추가나 변경 용이 ·특화된 업무에 대한 속성 관리나 프로그램이 용이 ·장애나 에러에 대한 파급효과가 작음 ·데이터 구조가 명확하여 업무 파악이나 인수인계를 신속하게 수행 |
| 단점 | ·공통적이지 않은 속성이 많은 경우 효과가 반감 ·여러 업무의 데이터가 서로 섞여 있어 내용을 정확하게 파악하기 어려움 ·모든 업무를 이해하는 인원만이 데이터 관리를 수행 가능 ·특정 업무에만 관련된 데이터 변경이 있을 경우 타 업무에 영향 |
·엔터티의 수효가 늘어나서 관리에 어려움 ·데이터 간의 불일치 발생 가능 ·통합적인 정보 도출이 어려움 ·동일한 로직도 별도의 프로그램으로 개발해야하므로 관리가 비효율적 |
관계
2.5관계 정의
가.관계란
-두 엔터티 간에 존재하는 업무적 연관성을 표현하는 것
:관계 표현을 통해 업무 규칙을 정의
:직접적인 관계
나.관계 이해
1)관계도 집합. 관계도 속성
-두 엔터티 사이에 그 목적과 내용이 다른 여러 개의 관계가 동시에 존재 가능
- 릴레이션 엔터티, 교차 엔터티, 제휴 엔터티
2)직접 관계를 관계라고 함
-직접 종속인 것만 관계로 봄
3)두 엔터티 간에는 하나 이상의 관계 존재 가능
4)외래키로 정의
-관계는 외래키로 구현되어 참조무결성으로 데이터 정합성을 유지
5)관계의 관점
항상 두 엔터티 간에 존재
항상 두개의 관점을 가짐
데이터의 양방향 업무 규칙을 표현
관계를 통하여 정보로서의 활용가치 상승
다.관계 표현
식별성, 선택성, 기수성
1)관계 형태
#하나 이상(many)
-하나 이상인 것이 적어도 한가지는 존재
까마귀발가락 모양
#단 하나(only one)
-단 하나임, 수평선
2)선택사양
-직선은 반드시 존재해야 함을 의미(필수)
-점선은 존재하지 않을 수도 있음(옵션)
#일반적인 형태
*주로 참조하는 엔터티(M쪽)는 참조되는 엔터티(1쪽)가 반드시 존재해야 하는 경우
*반대로 1쪽 엔터티는 M쪽 엔터티와 반드시 관계를 맺지 않아도 되는 경우
#바람직한 형태
-M쪽(자식) 관계의 선택사양을 직선관계로 만들려고 노력
3)관계명
#두 개의 관계 멤버십에 각각 부여
#현업에서 사용하는 간결한 동사형으로 표현
-두 엔터티 타입 간의 업무적 연관성을 나타내는 이름 부여
-현재 시제를 사용
-다른 관계명과의 유일성은 확보되지 못함
-능동/수동형의 사용은 가급적 배제
#업무적 의미가 없거나 애매모호한 용어는 배제
라.관계 정의 방법
-한쪽 엔터티를 기준으로 상대 엔터티와의 관계를 규명하고 다시 반대 방향으로 관계를 규명
1)관계구문 이해
2)관계정의 절차
마.관계 형태
1)1:1 관계
-반드시 단 하나씩과 관계를 가짐
#특징
*현실에서 매우 드물게 나타나는 형태
*업무의 흐름에 따라 데이터가 설계된 형태에서 많이 나타남.
*엔터티 수직분할시에 많이 나타남.
#필수-선택 형태
*한쪽은 실선이고 다른 쪽은 점선이 되는 모습. 좌측에 있는 엔터티의 개체는 대응되는 우측 엔터티의 개체가 반드시 존재해야 하지만 우측 엔터티의 개체와 대응되는 좌측 엔터티의 개체는 없을 수도 있음
-좌측 엔터티가 우측 엔터티에 집합적으로 포함되는 형태.
-예)학생-학생 프로파일(성적)
#필수-필수 형태
*양쪽 모두 실선인 모습
-예)고객-신분증(여권)
#선택-선택 상태
*양쪽 모두가 점선인 모습 (수직분할)
-예) 직원-직원의 세부정보
2)M:1 관계
-부모와 자식관계, 계층적
#특징
*내가 참조할(부모쪽) 정보는 나에 대해서 반드시 하나만 존재해야만 참조(join)할 때 내 집합에 변화가 생기지 않으므로 내가 참조하는 엔터티는 반드시 1쪽이 될 수 밖에 없음
*1:M (양쪽 필수)
예)주문-주문상품. 모든 주문에는 주문상품이 필수이며, 주문없은 주문상품은 없다.
*1:M (1측 옵션, M측 필수):
예)교사-학급, 교사는 최소 하나의 학급에 배정되나 일부 학급에 교사가 없을 수 있다.
*1:M (1측 필수, M측 옵션):
예)카테고리-책,
*1:M (양쪽 옵션): 선택성이 증가하면 모델의 모호성이 증가하므로 선택성을 해소해야 함
예)고객-주문
3)M:M 관계
#특징
*관계를 가진 양쪽 당사자 모두에서 1:M 관계가 존재할 때
4)다중 관계 처리
#특징
*다중 관계란 어떤 두 엔터티의 사이에 하나 이상의 관계를 가지고 있는 상태
여러 개의 관계로 나누어 관리하는 것을 병렬식이라고 하고, 하나로 묶어서 관리하는 것을 직렬식 관계라고 함
#병렬식 관계
*두 엔터티 사이에 존재하는 관계들을 별도의 관계로 간주
#병렬식 관계 특징
*테이블이 될 때 여러 개의 컬럼으로 나열
*하나의 행(ROW)에서 관리되므로 새로운 테이블을 추가할 필요가 없음
*인덱스 수가 증가되고 SQL이 복잡해짐
*새로운 관계의 추가, 관계 형태의 변경 등에 매우 취약한 형태
*관계 내용별로 상세 정보를 관리 불가
#직렬식 관계
*두 엔터티 사이에 존재하는 몇 개의 관계를 모아 상위 개념으로 통합함으로써 하나의 관계로 관리하는 방법
#직렬식 관계의 특징(병렬의 반대)
*관계들을 관리하는 새로운 엔터티가 추가
*관계들이 행(ROWS) 형태로 나타남
*인덱스 수가 감소하고 SQL이 단순해짐
*새로운 관계의 추가, 관계 형태의 변경 등에 매우 유연한 형태
*관계 내용별로 상세 정보를 관리가능
*관계 내용별로 자식 엔터티를 가질 수 있음.
5)특수한 형태 관계
#순환 관계
* 하나의 엔터티가 자기 자신과 관계를 맺는 관계
*특징
-하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함
-각 계층에 있는 속성은 동일하게 함
-순환 모델은 필수(직선) 관계로 취급될 수 없고(무한 LOOP 발생), 반드시 선택사양 관계
-조직의 변경(추가/삭제)에 쉽게 대응
#BOM(BILL OF Materials) 관계
*BOM 관계의 모델을 네트워크 구조(전철 노선이나 하이퍼링크를 갖는 웹 도큐먼트 같은)
M:M 순환구조: 상세 모델링 과정에서 새로운 관계 엔터티를 추가하여 두 개의 일대다(1:M) 관계로 구성된 모델로 구체화
#ARC(Mutally Exclusive)관계
*어떤 엔터티가 두 개 이상의 다른 엔터티의 합집합과 관계를 가지는 것을 배타적(Exclusive) 관계 혹은 아크(Arc) 관계라 함
*아크관계의 특징
-아크 내에 있는 관계는 보통 동일.
-아크 내에 있는 관계는 항상 필수이거나 선택.
-아크는 반드시 하나의 엔터티에만 속해야 함(하나의 아크가 여러 엔터티를 가질 수 없음)
-어떤 엔터티는 다수의 아크를 가질 수 있음. 지정된 관계는 단 하나의 아크에만 사용되어야 함
-논리적으로 엔터티간의 업무적 연관성을 명확하게 표현
-실제 DB로 구현시 엔터티를 하나로 통합할 수도 있음.
2.6개념 데이터 모델 작성
가.개념 데이터 모델의 구성요소
-개념데이터 모델은 핵심 엔터티(키엔터티, 메인엔터티)와 핵심 엔터티 사이의 관계 도출을 통해 핵심 구조라 할 수 있는 데이터 모델의 골격을 정의
-현행 시스템의 프로세스프로세스와 DB를 분석하여 분류가능한 업무를 분석
나.개념 데이터 모델의 작성 방법
1)개괄 데이터 모델로부터 상세화하는 경우
-개괄 데이터 모델 또는 전사 개념 데이터 모델로부터 개념 데이터 모델을 작성할 단위 주제영역을 결정
-도출된 핵심 엔터티를 주제영역과 매핑
-주제영역별로 해당 엔터티들 간의 관계를 정의하여 개념 데이터 모델을 작성
-개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증
2) 수집된 엔터티 후보로부터 작성하는 경우
-수집된 엔터티 후보들을 검토하고 분류하여 핵심 엔터티를 도출
-수집된 엔터티 후보들과 핵심 엔터티들을 분류하여 데이터 주제영역을 정의
-데이터 주제영역별로 해당하는 핵심 엔터티들을 배치하고 이들 간의 관계를 정의하여 개념 데이터 모델을 작성
-개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증
3)현행 데이터 리버스를 통해 작성하는 경우
-현행 물리 데이터 모델을 생성하고 상세화 및 논리화를 거쳐 현행 논리 데이터 모델을 작성
-현행 논리 데이터 모델의 엔터티들을 분류하여 핵심 엔터티를 도출하고 현행 데이터 주제영역 에 매핑
-현행 논리 데이터 모델로부터 현행 핵심 엔터티 간의 관계를 정의하여 현행 개념 데이터 모델을 작성
-사용자 요구사항이나 현행 시스템 분석 결과 또는 선진 사례 등을 검토하여 개선 사항을 반영함으로써 현행 개념 데이터 모델로부터 목표 개념 데이터 모델을 생성
-목표 개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증
3.논리 데이터 모델링
3.1논리 데이터 모델링 이해
가.논리 데이터 모델링 정의
-데이터베이스 설계 프로세스의 Input으로써 비즈니스 정보의 구조와 규칙을 명확하게 표현하는 기법
-비즈니스 데이터에 존재하는 사실을 인식/기록하는 기법
*논리: 현실세계를 추상화, 개념화.
나.논리데이터 모델링 목적 및 효과
-해당 비즈니스에 대한 데이터 관점에서의 명확한 이해
-전사적인 통합 데이터 체계 확립
-데이터의 일관성 및 정확성 유지를 위한 규칙 도출
-안정적인 데이터베이스 설계의 토대 마련
-사용자와의 명확한 의사소통을 위한 수단으로 활용
다.논리 데이터 모델링 필수 성공요소
-업무에 능통한 현업 사용자와 함께 데이터 모델링을 진행
-절차보다는 데이터에 초점을 두고 모델링을 진행
-데이터의 구조와 무결성을 함께 고려
-개념화와 정규화 기법을 적용
-가능하면 다이어그램을 이용하여 업무를 표현
-데이터 모델링을 지원하는 데이터 사전을 구축
3.2속성 정의
가.속성 개념
1)속성 정의
-엔터티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위
2)속성 특징
-속성도 일종의 집합
-관계도 속성
-속성들간은 서로 독립적, 식별자에만 종속
나.속성 후보 도출
-다양한 후보를 준비하고 이들 중에서 속성의 검증 규칙에 부합하는 것을 속성으로 최종 결정
1)속성 후보 수집처
-구시스템의 문서자료
-현업 장표/보고서
-사용자와 협의
-DFD의 DD
-전문 서적 및 자료
-다른 시스템 자료
2)후보 속성 선정 원칙
-원시 속성으로 보이는 후보는 버리지 않음
-소그룹별로 후보군을 만들고 가장 근접한 엔터티에 할당
3)속성의 기본 구성 요소
#속성명
-속성의 의미를 명확히 표현하는 함축성 있는 명사 혹은 명사구를 사용(명료,간결,자명)
-해당 업무에서 일반적으로 사용하는 용어를 사용
-실체명은 사용하지 말것
-필요시 표준 약어를 제정하여 속성명을 생성하고 그 속성명을 단 하나의 실체에만 속하도록 할 것
#도메인
-속성이 지닐 수 있는 값에 대한 업무적인 제약 조건으로 파악된 일련의 특성
-데이터 타입
-길이
-허용 값: 속성에 지정할 수 있는 모든 값들의 집합
-디폴트 값 및 디폴트 알고리즘
#선택성
선택성 조건 => 선택성이 다른 속성 값에 의해 영향을 받는 경우
필요조건 / 금지조건 / 무관계조건
다.속성 검증 및 확정
-최소단위분할, 하나의값, 추출속성
1)최소단위까지 분할(원자단위)
#검증방법
-집합 개념의 속성은 단순 개념으로 분할
-가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합
-일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않음
-분할 및 통합의 기준은 업무의 요구 사항에 따름
2)하나의 값만을 가지는지 검증(유일값)
#검증방법
-여러 값을 가지거나 반복되는 속성은 잘못된 속성
-반복되는 속성은 새로운 엔터티로 분할해야 할 1차 정규화의 대상임
3)추출 속성인지 검증(가공값)
-속성이 원천적인 값인지, 다른 속성에 의해 가공되어서 만들어진 값인지를 검증
4)관리수준 상세화 검토
-더 상세한 정보관리가 필요한지 검토
라.추출속성 규칙
-기업의 관리자들이 관심을 가지고 보는 속성으로 데이터 모델 내 반드시 기술
-추출속성은 하나 이상의 다른 데이터 속성에 축적된 여러 사례의 값을 토대로 어떤 추가 계산 작업을 수행함으로써 선택적으로 주제를 도출하는 속성에 대하여 새로운 값을 창출
-계산속성은 엔터티의 단일 사례에 대한 어떤 특성을 기술하며, 일반적으로 관련 속성의 또다른 단일 사례로부터 계산
-추출속성은 경영층이 진실로 원하고 필요로 하는 정보를 대표
-추출속성은 사용자들의 데이터 요구 사항을 나타냄
-데이터 모델에 추출 속성을 포함시키는 것은 그들의 물리적 구현에 대한 어떤 것도 내포하지 않음
-추출속성은 기본키가 되면 안됨
*추출속성 예: 최초가입일, 고객활동상태, 현주소
라.속성 정의시 유의사항
1)의미가 명확한 속성 명칭을 부여
2)유일한 복합명사 사용
3)단수형을 사용
4)표준단어제정
5)작의적인 전용 금지
-예정되어 있는 곳에 쓰지 않고 다른 데로 돌려서 쓰는 않아야 함
# 작의적인 전용 발생 케이스 3가지
*모델러가 속성의 의미를 매우 추상적이고, 모호하게 정의하여 그것을 적용하는 개발자들이 각기 다르게 이해함으로써 나타나는 경우
*개발이 막바지에 도달했거나 이미 운용 중인 시스템에서 새로운 사용자 요구 사항으로 인해 새로운 속성의 추가가 필요할 때 나타나는 경우
*ERP 패키지에서 자주 나타나는 형태로써 미리 전용의 용도로 속성을 정의해 두는 경우
3.속성 정의 사항
가.속성명
-엔터티명을 포함해서 쓰는 것을 추천. 전체 데이터 모델 내에서 유일하게
1)의미가 명확한 속성명칭 부여
2)유일한 복합명사 사용
3)단수형으로 속성명 사용
4)표준 단어 및 용어 제정
나.속성설명
다.선택성 및 선택성 조건
-필수 속성: 모든 인스턴스가 속성값을 가짐
-선택 속성: 속성값을 가지지 않을 수도 있음ㄴ
-선택성 조건: 속성의 선택이 다른 속성 값에 의하여 영향 받음
라. 속성 유형
-기본속성: 속성값이 해당 인스턴스에 원래 존재하며, 다른 속성 값으로부터 유도될 수 없는 속성.
-유도속성: 속성 값이 항상 다른 속성의 값으로부터 유도되거나 계산되는 속성
-설계속성: 업무 제약사항을 반영하거나 시스템 운영을 단순화하기 위하여 생성하는 속성
-기본과 설계 속성은 동일하게 다룸
-유도속성은 유도 알고리즘을 이용해 계산된 값을 유도 속성의 값으로 함
마. 유도 알고리즘
바.도메인
사.허용값
아.기본값
자.소유 권한
-데이터 거버넌스 차원의 속성 정의 및 승인에 대한 권한을 가지는 개인, 기능 또는 조직에 대한 기록 관리
-데이터(속성 값)를 생성하고 사용하는 것에 대한 권한을 가지는 개인, 기능 또는 조직에 대한 기록을 관리
4.속성 검증 및 확정
가.원자값 단위까지 분할
-더이상 분해할수 없는 값.
나.하나의 값만을 가지는지 검증
다.유도 속성인지 검증
-다른 속성에 의해 가공되어서 만들어진 값인지를 검증
5.유도 속성 규칙
-유도된 속성이나 계산된 속성은 반드시 기술
-유도된 속성: 하나 이상의 다른 데이터 속성에서 축적된 여러 사례의 값을 토대로 어떤 추가 계산 작업을 수행함으로써 선택적으로 주제를 도출하는 속성에 대하여 새로운 값을 창출
-계산 속성: 엔터티의 단일 사례에 대한 어떤 특성을 기술하며, 일반적으로 관련 속성의 또다른 단일 사례로부터 계산
-경영층이 진실로 원하는 정보
-사용자들의 데이터 요구사항
-식별자로서의 역할은 안됨
#속성분류
-기본 속성(Basic)
-설계 속성(Design): 업무규칙
-파생 속성(Derived): 계산
3.3엔터티 상세화
가.식별자 확정
1)본질 식별자(업무에 의해 생성)
#키 엔터티의 본질 식별자
#절대종속/상대종속
*절대종속: 내가 태어나기 위해서 절대적으로 존재했어야 하는지, 아니면 그것이 없어도 내가 태어날 수가 있는지를 확인
#직접종속/간접종속 의미
*부모 엔터티와의 관계가 1촌이면 직접 종속이고 1촌 이상이면 간접 종속
#행위 엔터티의 본질 식별자
*절대종속이면서 직접종속인 것. 자신을 태어나게 한 근본을 찾음
2)후보 식별자 도출
-각 인스턴스를 유일하게 식별
-나머지 속성들을 직접 식별
-NOT NULL
-후보 식별자로 속성 집합을 선택하는 경우에는 개념적으로 유일해야 함
-후보 식별자의 데이터는 자주 변경되지 않아야 함
3)대체(보조) 식별자
-원래의 식별자를 대신할 수 있는 또 다른 속성들이나 관계(관계속성)
4)인조식별자 지정
-식별자 확정시 기존의 본질 식별자를 그대로 실질 식별자로 인정할 수 없는 여러가지 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을 가진 속성들로 대체하여 새롭게 구성한 식별자
#인조식별자 지정 기준
-최대한 범용적인 값을 사용
-유일한 값을 만들기 위한 인조식별자를 사용
-하나의 인조식별자 속성으로 대체할 수 없는 형태를 주의
-편의성 ·단순성 확보를 위한 인조 식별자를 사용가능
-의미의 체계화를 위한 인조 식별자를 사용가능
-내부적으로만 사용하는 인조 식별자
4)식별자 확정
#UID BAR의 두 가지 의미
-식별자로서의 역할
-정보로서의 역할
#UID상속과 단절의 원리
#식별자 확정 절차
*키 엔터티 식별자 확정
*메인 엔터티 식별자 확정
*하위 엔터티 식별자 확정
나.정규화
1)정규화의 의미
#이상현상을 해결(입력/수정/삭제 이상)
*입력이상:어떤 데이터를 삽입하려고 할 때 불필요하게 원하지 않는 데이터도 함께 삽입
*삭제이상: 일부 정보를 삭제함으로써 유지되어야 할 정보까지도 삭제되는 현상
*갱신이상: 일부 속성 값을 갱신 함으로써 원하지 않는 정보의 이상 현상(무결성 파괴, 정보의 모순성)이 발생
2)정규화의 장점
-중복값 최소화
-NULL값 최소화
-복잡한 코드로 데이터 모델을 보완할 필요가 없음
-새로운 요구 사항의 발견 과정을 도움
-업무 규칙의 정밀한 포착을 보증
-데이터 구조의 안정성을 최대화
3)정규화 단계
#1차 정규형(원자값)
*모든 속성은 반드시 하나의 값을 가져야 함. 반복 형태가 있어서는 안됨(다중값 속성, 반복그룹 제거)
*각 속성의 모든 값은 동일한 형식
*각 속성들은 유일한 이름
*레코드들은 서로 간에 식별 가능
#2차 정규형(부분함수종속제거)
식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속(식별자에 부분종속하면 안됨)
물리 데이터 모델의 테이블로 말하면 기본키가 아닌 모든 컬럼들이 기본키에 종속적이어야 2차 정규형을 만족
#3차 정규형(이행함수종속제거)
*2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안됨
#BCNF 정규형(3정규화후 2정규화를 다시 수행)
*모든 결정자가 키인 릴레이션이 BCNF. 반대로 어떠한 결정자 하나라도 키가 아닌 릴레이션이라면 BCNF가 될 수 없음
*기존의 2차 정규형과 3차 정규형을 보완하려는 목적. 즉 부분 종속이나 이행 종속이 없는 3차 정규형도 변경 이상 현상이 나타날 수 있기 때문이고, 이것은 어떤 NON-KEY 속성이 결정자로 동작하기 때문에 발생
*엔터티 통합의 필요성
-유사성을 가진 데이터 집합에 대한 인수분해>복잡도 감소
-구조 단순화 > 유지보수
-데이터 오너십
-일관된 뷰 처리 가능
-데이터 품질 향상
-성능 및 관리
접근방법>개체의 본질/행위/ 관계에 대한 유사성
*엔터티의 분리
다.M:M 관계 해소
1)M:M 관계의 의미
-M:M 관계는 최종적으로 완성된 데이터 모델에는 존재할 수 없는 형태
2)M:M 관계 해소의 의의
-M:M 릴레이션십은 새로운 릴레이션 엔터티를 추가하여 M:1 관계로 변경
#즉시1:M관계 엔터티로 분해해야 하는 경우
-자식을 가져야 하는 경우
-추가적인 속성을 가져야 하는 경우
-이외에는 논리모델링 상세화 단계에서 해소.
라.참조무결성 규칙 정의
-관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주 식별자 값이 존재
-실체의 주 식별자(PK)와 마찬가지로 외부 식별자(FK)도 데이터 무결성에 관한 업무 규칙을 내포함
-데이터베이스 설계 관점에서 선택하지 말고, 사용자의 업무 규칙에 따라 적절한 규칙을 선택
1)입력규칙
-자식 엔터티의 인스턴스를 입력할 때
# DEPENDENT
대응되는 부모 실체에 인스턴스가 있는 경우에만 자식 실체에 입력을 허용
# AUTOMATIC
자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 이를 자동 생성
# NULLIFY
자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 자식 실체의 참조키 (FK)를 Null 값으로 처리
# DEFAULT
자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 참조키(FK)를 지정된 기본 값으로 처리
# CUSTOMIZED
특정한 검증 조건이 만족되는 경우에만 자식 실체 인스턴스의 입력을 허용
# NO EFFECT
자식 실체 인스턴스의 입력을 조건 없이 허용
2)삭제규칙
-부모 엔터티의 인스턴스를 삭제 또는 주식별자를 수정할 때
# RESTRICT
대응되는 자식 실체의 인스턴스가 없는 경우에만 부모 실체 인스턴스 삭제를 허용
# CASCADE
부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스를 자동 삭제
# NULLIFY
부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참조키(FK)를 Null 값으로 수정
# DEFAULT
부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참조키(FK)를 기본값으로 수정
# CUSTOMIZED
특정한 검증 조건이 만족되는 경우에만 부모 실체 인스턴스의 삭제를 허용
# NO EFFECT
부모 실체 인스턴스 삭제를 조건 없이 허용
3.4이력관리의 정의
가.이력관리란
-이력은 선분이고 현재의 순간은 점
나.이력관리 대상 선정
1)사용자 조사
변경 내역을 감시할 필요가 있는가?
시간의 경과에 따라 데이터가 변할 수 있는가?
시간의 경과에 따라 관계가 변할 수 있는가?
과거의 데이터를 조회할 필요가 있는가?
과거 버전을 보관할 필요가 있는가?
#이력 관리 대상 예
-부서와 사원의 관계,
-상품단가
-금융상품이자율
-환율
2)이력 데이터의 종류
#발생 이력
-데이터가 발생할 때마다 이력 정보를 저장
#변경 이력
-데이터가 변경될 때마다 변경 전과 후의 차이를 확인하기 위해 이력 정보를 남김
#진행 이력
-업무의 진행에 따라 이 데이터를 이력 정보로 남김
3)이력관리 형태
시점 이력 :
-데이터의 변경이 발생한 시각만을 관리
-로그성 데이터
-임의 시점 이력 조회시 비효율
-특정 시점의 환율 관리.
선분 이력 :
-데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리.
-일정기간동안 해당 정보가 유효하다는 의미
-임의시점의 데이터 조회시 유용
-특정 기간의 환율 관리.(시점별 환율 관리)
#이력관리 모델로 변환시 나타나는 상황
-관계의 형태를 변화: 속성이나 관계의 카디날리티 증가
-하나의 엔터티에 일반 속성 이력을 관리하면 1:M 관계의 하위 엔터티를 생성
-M:M 관계인 상태에서 해당 관계에 대한 이력을 관리하면 기존의 관계 엔터티에 추가적인 식별자 속성을 발생
-1:M 관계의 이력관리시 M:M관계로 변하여 새로운 관계 엔터티 생성
4)선분 이력 관리 유형
#인스턴스 레벨 이력 관리
*하나의 인스턴스의 어떤 변경이라도 발생하면 전체 인스턴스를 새롭게 생성하는 방식
*특징
-한번의 액세스로 스냅샷을 참조하는 것이 가능. 즉, 한번의 액세스로 해당 시점의 모든 데이터를 참조
-로그성 데이터를 저장할 목적인 경우 적당한 방법
-다른 이력 관리 유형에 비해서 저장 용이
-가장 큰 단점 중에 하나는 하나 이상의 컬럼에 변경이 발생했을 때 이벤트가 모호
-이벤트가 자식 정보를 가지게 된다면 매우 치명. 즉, 각각의 변경 이벤트가 하위의 데이터(엔터티)를 가지게 된다면 해당 이벤트를 찾기가 매우 어려움
-이력 관리의 다른 유형들에 비해서 저장 공간의 낭비를 초래
-실제 어떤 데이터가 변경된 것인지를 찾기 위해서는(즉, 이벤트를 찾기 위해서는) 과거의 데이터를 Merge해서 비교를 해야만 가능
-특정 순간의 스냅샷만 보는게 아니라면 처리가 복잡
-변화가 빈번하게 발생하는 상황이라면 고려(관리대상속성이 적은 경우)
#속성 레벨 이력 관리
*이력을 관리할 대상 속성에서 변화가 생길 때만 이력을 생성
*특징
-변경 이벤트가 매우 분명하게 관리. 즉, 실제 어떤 데이터가 변경되었는지가 분명
-하나의 이력 관리 엔터티에서 다른 엔터티와 통합 이력 관리가 가능
-변경된 것만 처리하기 때문에 독립적 처리가 가능
-변화가 발생할 가능성은 매우 낮으면서 이력 관리 대상 속성은 매우 많은 경우에 사용
-특정 속성들에 변화가 집중되는 경우에 해당 속성에 대해서만 이력을 관리 가능
-여러 속성에 대한 이력이 필요할 때 많은 Merge가 발생
-이력 관리의 다른 유형들에 비해서 향후 사용될 데이터 액세스 쿼리에서 조건 검색이 조금 어려움
-변화가 너무 많은 경우에는 적용이 곤란
#주제 레벨 이력 관리
*내용이 유사하거나 연동될 확률이 높은 것별로 인스턴스 레벨 이력을 관리
*특징
-인스턴스 레벨과 속성 레벨의 장점을 모두 수용하는 형태
-목적이 분명한 엔터티를 생성함으로써 확장성을 확보
-변경 부분만 처리가 가능.(독립적 처리 가능)
-다른 엔터티와 통합 이력 관리가 가능
-속성 레벨의 단점을 해소
-전체를 참조할 때 인스턴스 레벨에 비해 Merge가 발생하는 문제점이 존재.
-부문에 따라 변경 정도의 차이가 심한 경우 유리
다.선분 이력관리용 식별자 확정
1)선분 이력에서 식별자 결정 시 고려사항
-엔터티의 UID를 확정하는 것은 향후에 테이블로 만들어지고 사용될 때의 성능 측면도 고려
2)선분 이력에서 종료점 처리 시 주의사항
#종료점이 미정이므로 NULL
*논리적으로는 타당하지만 비교가 불가능
*인덱스를 사용하지 못하므로 수행 속도 저하
#수렴하므로 최대치 부여
*아직 종료되지 않았으므로 무한히 계속되는 것으로 간주
*최대치 부여 (예; 일자라면 9999/12/31)
*가능한 TABLE creation 시 Default constraints 부여
*수행 속도에 유리
*이력관리 엔터티 구성방식
-통합엔터티: 현재+과거
-분리엔터티: 현재와 과거를 분리
:단일엔터티, 주제중심 엔터티
3.5논리 데이터 모델 품질 검토
가.논리 데이터 모델 품질 검토 개요
#기준항목(물리모델과 동일)
-정확성:데이터 모델이 표기법 준수, 업무영역 또는 요구사항이 정확하게 반영
-완전성:데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최소화, 요구사항 및 업무영역 반영에 누락이 없음
-준거성:제반 준수 요건들이 누락 없이 정확하게 준수
-최신성:데이터 모델이 현행 시스템의 최신 상태를 반영, 이슈사항들이 지체없이 반영
-일관성:여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의, 이를 여러 다른 영역에서 참조·활용되면서 모델 표현상의 일관성을 유지
-활용성:작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계되어 있음
나.논리 데이터 모델 품질 검토 체크리스트의 활용
#검토대상
엔터티: 엔터티명, 엔터티정의, 통합수준, 권한, 발생건수/빈도, 다른 엔터티와의 관계
속성: 속성명, 속성정의, 속성설명, 속성유형, 식별자 정의, 법규 준수
관계: 관계명, 관계정의, 관계설명,관계표현, 식별자 상속, 요구사항 추적가능, 외래키, 참조무결성
모델전반: 주제영역 적절성, 논리모델 상세화
4.물리 데이터 모델링
4.1물리 데이터 모델링 이해
가.물리 데이터 모델 정의
-물리테이터 모델: 논리적 모델을 특정 데이터베이스로 설계함으로써 생성된 데이터를 저장할 수 있는 물리적인 스키마
-하나의 논리 모델의 엔터티는 경우에 따라 여러 개의 테이블로 생성 가능(성능 문제 고려)
-하나의 논리데이터 모델은 여러 개의 물리데이터 모델로 생성가능
-논리데이터 모델의 일부 속성만으로 물리 데이터 모델에서 테이블로 설계하는 경우도 발생
-물리 데이터 모델링: 논리 데이터 모델을 사용하고자 하는 각 DBMS의 특성을 고려하여 데이터 베이스 저장 구조로 변환
나.물리 데이터 모델 의의
-논리적 데이터 모델을 각각의 관계형 DBMS의 특성, 기능, 성능 등을 고려하여 DB의 물리적인 구조를 작성해가는 과정
-논리 데이터 모델에서 도출된 내용 변환을 포함하여 데이터의 저장공간, 데이터의 분산, 데이터 저장 방법 등을 함께 고려하는 단계
다.논리 데이터 모델-물리 데이터 모델을 여러개 구성하는 이유
1)분산DB 구축시
-노드별로 원하는 형태의 물리적 모델 생성
2)물리 데이터 모델 비교
3)물리적 환경의 변화
4)물리적 모델의 형상관리
4.2물리 요소 조사 및 분석
가.시스템 구축 관련 명명 규칙
나.하드웨어 자원 파악
-CPU: 성능과 집중적인 부하가 발생하는 시간
-Memory: 전체 메모리의 규모 및 시스템이 사용하는 메모리 영역을 포함하여 사용 가능한 메모리 영역
-Disk: 전체 디스크의 크기, 분할된 형태, 현재 디스크 활용률 등을 파악하고 사용 가능한 공간을 확인
-I/O Controller
-Network
현재 처리 가능한 속도
집중적인 부하가 발생하는 시간대
동시 접속 최대 가용 사이트 수
다.운영체제 및 DBMS 버전 파악
라.DBMS 파라미터 정보 파악
마.데이터베이스 운영과 관련된 관리요소 파악
-사용자 관리 기법 및 정책
-백업/복구 기법 및 정책
-보안 관리 정책
4.3논리-물리 모델 변환
가.논리 데이터 모델-물리 데이터 모델 변환 용어
엔터티->테이블
속성->컬럼
Primary UID -> 기본키
Secondary UID -> 유닉키
관계 -> 외래키
비즈니스 규칙 -> 제약조건
나.엔터티-테이블 변환
1)테이블 설명
-데이터를 저장하기 위해서 생성된 데이터베이스에서의 가장 기본적인 오브젝트.
-Rows: 테이블의 한 로우에 대응. 튜플, 인스턴스, 어커런스
-컬럼: 지정된 유형의 데이터 값을 저장
-기본키: 하나 혹은 몇 개의 컬럼 조합으로 테이블내에 동일한 값을 갖는 튜플은 존재하지 않음
-외래키: 외부 데이터 집합과의 관계를 구현
2)서브타입 변환(원본 참조해서 내용 파악 필요)
-서브타입의 서브타입을 별개의 테이블로 변환하는 것은 비추천
#슈퍼타입 기준 테이블 변환
-서브타입을 슈퍼타입에 통합하여 하나의 테이블로 생성
-통합된 테이블에는 모든 서브타입의 데이터를 포함
-주로 서브타입에 적은 양의 속성이나 관계를 가진 경우에 적용
-엑세스 간편, SQL단순, 속도 향상
-인덱스의 크기 증가
-서브타입의 Not Null 제약 생성 어려움.
-서브타입별 엑세스 불편
| 하나의 테이블로 통합이 유리한 경우 | 하나의 테이블로 통합이 불리한 경우 |
| ~ 데이터 액세스가 좀 더 간편 ～뷰를 활용하여 각 서브타입만을 액세스하거나 수정 가능 ～수행 속도가 좋아지는 경우가 많음 ～서브타입 구분 없는 임의 집합의 가공 용이 ～다수의 서브타입을 통합한 경우 조인 감소 효과가 큼 ～복잡한 처리를 하나의 SQL로 통합하기가 용이 |
～특정 서브타입의 NOT NULL 제한 불가 ~ 테이블의 칼럼 수가 증가 ～테이블의 블럭 수가 증가 ～처리 시마다 서브타입의 구분이 필요해지는 경우가 많음 ~ 인덱스 크기가 증가 |
#서브타입 기준 테이블 변환
-슈퍼 타입 속성들을 각 서브타입에 추가하여 각각의 서브타입마다 하나의 테이블로생성
-분할된 테이블에는 해당 서브타입의 데이터만 포함
-주로 서브타입에 많은 양의 속성이나 관계를 가진 경우에 적용
| 여러개 테이블로 분할이 유리한 경우 | 여러개 테이블로 분할이 불리한 경우 |
| ~ 서브타입 속성들의 선택 사양이 명확한 경우에 유리하다． ~ 처리 시마다 서브타입 유형 구분이 불필요 ~ 전쳬 테이블 스캔 시 유리 ～단위 테이블의 크기가 감소 |
～서브타입 구분 없이 데이터 처리하는 경우 UNION이 발생 ~ 처리 속도가 감소하는 경우가 많다 ～트랜잭션 처리 시 여러 테이블을 처리하는 경우가 증가 ～복잡한 처리의 SqL 통합이 어려움 ～부분 범위 처리가 불가능해질 수 있다． ~ 여러 테이블을 합친 뷰는 조회만 가능 UUID 유지 관리가 어려움 |
#개별타입 기준 테이블 변환
-슈퍼타입과 서브타입을 각각 테이블로 생성
-슈퍼타입과 서브타입 테이블 간에는 1:1 관계가 생성(한 쪽을 모두 합치면 전체와 같게 된다는 면에서 개념적으로 아크 관계와 유사)
~ 전체 데이터 처리가 빈번하게 발생할 경우에 적용
~ 서브타입의 처리는 주로 독립적으로 발생할 경우에 적용
~ 테이블을 통합했을 때 칼럼의 수가 너무 많아지는 경우에 적용
～서브타입의 칼럼 수가 많은 경우에 적용
～트랜잭션이 주로 공통 부분（슈퍼타입）에서 발생
～슈퍼타입의 처리 범위가 넓고 빈번하여 단일 테이블 클러스터링을 해야 할 때 적용
다.속성-컬럼 변환
1)일반 속성 변환
-엔터티에 있는 각 속성들에 대한 컬럼명을 사례 데이터 표의 컬럼명란에 기록
-컬럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나 프로그래머와 사용자의 혼동을 피하기위해 가능한 표준화된 약어 사용
-표준화된 약어의 사용은 SQL 해독 시간을 감소
-SQL 예약어의 사용을 지양
-컬럼 명칭은 짧은 것이 좋으며, 짧은 명칭은 개발자의 생산성 향상
-필수 입력 속성은 Nulls/Unique 란에 NN을 표시
-실제 테이블에 대한 설계를 검증하기 위한 목적으로 가능하다면 표본 데이터를 입력
2)Primary UID 기본키 변환
#변환절차
*사례 데이터 표의 키 형태란에 엔터티의 Primary UID에 속하는 모든 속성에 PK를 표시
*PK로 표시된 모든 컬럼은 Nulls/Unique 란에 반드시 NN,U로 표시
*여러 개의 컬럼으로 UID가 구성되어 있는 경우는 각각의 컬럼에 NN,U1을 표시
*또 다른 Unique Key(Secondary UID)가 있다면 U2로 표시
3)Primary UID(관계의 UID Bar) 기본키 변환
#변환절차
*테이블에 외래키 컬럼을 포함
*PK의 일부분으로 표시
-Nulls/Unique 란에 각각 NN,U1을 표시
-키 형태란에 PK, FK를 표시
-여러 UID BAR가 있는 경우는 (PK, FK1), (PK, FK2), …
-여러 컬럼으로 구성된 경우 PK,FK1을 각각 표시
*추가된 FK 컬럼에 표본 데이터를 추가
4)Secondary(Alternate) UID Unique Key 변환
-Primary UID 변환 절차와 동일
5)테이블 정의서
라.관계변환
-관계도 속성, 관계도 집합
-선분이력을 관리하는 상위 엔터티와 관계에서는 상위 엔터티의 식별자 전체를 하위 엔터티에서 상속받지 않아도 데이터적인 연결을 수행할 수 있으므로 식별자 상속을 시키지 않을 수 있음
1)1:M관계 변환
1(One) 에 있는 PK를 M(Many)의 FK로 변환
- FK의 명칭 결정
- 키 형태 란에 FK 표시
- Nulls/Unique 란에 NN 표시(Must Be 관계시)
- 필수 관계가 아닌 경우에는 NN를 체크하지 않음
표본 데이터 추가
UID BAR 가 있는 경우는 전단계에서 실시
# 1:M 관계에서 1 쪽이 MANDATORY 관계일 때의 변환시 주의사항
-자식 쪽의 레코드(Row)가 반드시 하나 이상은 되어야만 부모쪽의 레코드 생성 가능
-자식 쪽의 레코드를 삭제할 경우에는 전체를 다 삭제할 수는 없고 반드시 하나 이상의 자식 레코드를 남겨두거나 자식과 부모 레코드를 동시에 삭제
2)1:1관계 변환
#변환절차
-Mandatory 반대쪽에 있는 테이블의 기본키를 Mandatory 쪽 테이블의 외래키로 변환
-NN 표시
#변환시 주의사항
-1:1 관계에 의해서 생긴 모든 외래키 부분은 Unique Key가 필수
-한쪽이 Optional이고 다른 한쪽이 Mandatory라면 Mandatory쪽의 테이블에 외래키 생성
-양쪽다 Mandatory라면 변환시에 어떤 테이블에 외래키를 생성할 것인지를 선택
3)1:M 순환 관계 변환
#변환절차
-해당 테이블 내에 외래키 컬럼 추가. 외래키는 같은 테이블 내의 다른 로우의 기본키 컬럼을 참조
-외래키 컬럼 명칭은 가능한 한 관계 명칭을 반영. -외래키는 결코 NN(Not Null) 불가
4)배타적 관계 변환
#외래키 분리 방법
*각각의 관계를 관계 컬럼으로 생성하는 방법. 실제 외래키 제약조건을 생성. 각각의 키컬럼이 Optional이어야 함.
-새로운 관계를 추가할때 구조 변경 필요.
-비즈니스 규칙으로 구현하기 위해 별도의 제약조건 생성 필요.
#외래키 결합 방법
*각각의 관계를 하나의 관계 컬럼으로 생성하는 방법. 실제 외래키 제약조건을 생성불가, User-Defined Trigger 방법을 통해 해결.
마.관리상 필요한 컬럼 추가
1)개념
-관리상의 이유로 혹은 데이터베이스를 이용하는 프로그래 밍이 좀더 빠르게 수행되도록 하기 위해서 테이블이나 컬럼을 추가
2)시스템컬럼 추가 예
-예)생성일시, 프로세스ID
바.데이터 타입 선택
1)개념
-논리 데이터 모델에서 정의된 논리적인 데이터 타입을 물리적인 DBMS의 특성과 성능 등을 고려하여 최적의 데이터 타입을 선택하는 작업
2)문자타입
#세부 문자 타입 선택을 위한 기준
*영문만 사용? 유니코드는 NARCHAR
* 4000자 혹은 8000자 이상의 문자열이 포함? 큰 데이터는 TEXT
*입력되는 값의 길이가 일정한가?
3)숫자 타입
#세부 숫자 타입 선택을 위한 기준
*정말 숫자 데이터인지 판단
*세부 숫자 타입 결정
Boolean, Integer, 소수(Decimal), 화폐(Money)
4)날짜 타입
# 세부 날짜 타입 선택을 위한 기준
*일반적인 시간까지를 저장할 것이냐 아니면 정밀한 시간을 저장할 것이냐에 따라 날짜 타입을 결정
사.데이터 표준 적용
1)개념
-논리데이터모델을 물리데이터모델로 변환하는 과정에서 전사적으로 생성된 데이터 표준을 준수
표준용어, 표준도메인, 표준 명명규칙
2)데이터 표준 적용 대상
-DB, 스토리지그룹, 테이블스페이스, 테이블, 컬럼, 인덱스, 뷰
# DB
테이블의 집합으로 통합 모델링 단계의 주제 영역이나 애플리케이션 모델링 단계의 업무 영역에 대응되는 오브젝트
# 스토리지 그룹
DASD(Direct Access Storage Device) 즉, 물리적인 디스크를 묶어서 하나의 그룹으로 정의해 놓은 것이며 테이블스페이스, 인덱스 스페이스 생성시 스토리지 그룹명을 지정하여 물리적인 영역을 할당
# 테이블스페이스
테이블이 생성되는 물리적인 영역이며, 하나의 테이블 스페이스에 하나 또는 그 이상의 테이블을 저장
# 테이블
논리 설계 단계의 엔터티에 대응하는 객체
#컬럼
논리 설계 단계의 속성에 대응하는 객체
# 인덱스
테이블에서 특정 조건의 데이터를 효율적으로 검색하기 위한 색인 데이터. 대표적인 인덱스 대상으로는 기본키, 외래키등
# 뷰
테이블에 대한 재정의로서 물리적으로 테이블의 특정 컬럼, 특정 로우를 가상의 테이블로 정의
-특정 사용자만 접근이 가능하도록 설정 가능
3)데이터 표준 적용 방법
#명명 규칙에 의한 표준화 적용
-예)테이블 명명규칙
#표준 용어집에 의한 표준화 적용
-사전에 사용될 모든 객체명과 해당 객체에 대한 데이터 타입, 길이 등의 표준을 정의해 놓고 이 표준들을 적용하는 방식
4.4반정규화
-정규화된 엔터티, 속성, 관계에 대해 성능향상과 개발과 운영의 단순화를 위해 중복, 통합 등을 수행하는 기법
-테이블: 테이블병합/분할/추가
-컬럼: 중복/계산/이력 컬럼추가
-관계: 중복관계
가.테이블 분할
1)개념
-하나의 테이블을 수직 혹은 수평 분할하는 것. 파티셔닝
-파티셔닝을 고려할때 물리적인 요소중에서 DBMS 벤더와 버전을 파악하는 것이 우선(벤더별로 파티셔닝 기법이 상이함)
2)수평분할
-레코드를 기준으로 테이블을 분할
-하나의 테이블에 데이터가 너무 많이 있고, 레코드 중에서 특정한 범위만을 주로 액세스 하는 경우에 사용
-분할된 각 테이블은 서로 다른 디스크에 위치시켜 물리적인 디스크의 효용성을 극대화
-현재는 이러한 수평 테이블의 분할은 DBMS 차원에서 제공
3)수직분할
-하나의 테이블이 가지는 컬럼의 개수가 많을때 수행
-조회 위주의 컬럼과 갱신 위주의 컬럼으로 나뉘는 경우
-특별히 자주 조회되는 컬럼이 있는 경우
-특정 컬럼 크기가 아주 큰 경우
-특정 컬럼에 보안을 적용해야 하는 경우
나.중복 테이블 생성
1)개념
-많은 양의 정보들을 자주 Group By, Sum 등과 같은 집계 함수를 이용해서 실시간으로 통계 정보들을 계산하는 경우 특정 통계 테이블을 두거나 중복 테이블을 추가
2)중복테이블 생성 판단 근거
-정규화에 충실하면 종속성, 활용성은 향상되나 수행 속도가 느려지는 경우
-많은 범위를 자주 처리해야 하는 경우
-특정 범위의 데이터만 자주 처리되는 경우
-처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우
-요약 자료만 주로 요구되는 경우
-추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정
-인덱스의 조정이나 부분 범위 처리 유도 -클러스터링을 이용하여 해결할 수 있는지를 철저히 검토한 후 결정
3)중복테이블 유형
#집계(통계) 테이블 추가
-단일 테이블의 GROUP BY
-여러 테이블의 조인 GROUP BY
-넓은 범위 자주 처리하여 수행속도가 저하되는 경우
# 진행(이력) 테이블 추가
-여러 테이블의 조인이 빈번히 발생하며 처리 범위도 넓은 경우
-M:M 관계가 포함된 처리의 과정을 추적, 관리하는 경우
-검색 조건이 여러 테이블에 걸쳐 다양하게 사용되며 복잡하고 처리량이 많은 경우
#이력관리 테이블 추가
#인덱싱 테이블 추가
#Statement 테이블 추가
-여러 테이블의 조인이 빈번
다.중복 컬럼 생성
1)개념
2)중복 컬럼 생성 상황
-빈번하게 조인을 일으키는 컬럼
-조인의 범위가 다량인 경우를 온라인화해야 하는 경우처럼 속도가 중요한 컬럼
-액세스의 조건으로 자주 사용되는 컬럼
-자주 사용되는 액세스 조건이 다른 테이블에 분산되어 있어 상세한 조건 부여에도 불구하고 액세스 범위를 줄이지 못하는 경우
-복사된 컬럼의 도메인은 원본 컬럼과 동일
-접근 경로의 단축을 위해서 부모 테이블의 컬럼을 자식 테이블에 중복
-상위 레벨의 테이블에 집계된 컬럼을 추가(M:1 관계)
-하위 레벨의 테이블로 중복 컬럼을 복사(M:1 관계)
-연산된 결과를 주로 사용하는 경우에도 미리 연산
-여러 컬럼들의 수 밖에 없는 값이 검색의 조건으로 사용되는 경우에는 연산의 결과
여러 개의 로우로 구성되는 값을 하나의 로우에 나열하는 경우
-기본키의 컬럼이 길거나 여러 개의 컬럼으로 구성되어 있는 경우 인위적인 기본키를 추가
-계산된 값 이용이 빈번한 경우
4.5물리 데이터 모델 품질 검토
가.물리 데이터 모델 품질 검토 개요
#기준항목(최완일정준활)
-정확성:데이터 모델이 표기법 준수, 업무 영역 또는 요구사항이 정확하게 반영
-완전성:데이터 모델의 구성요소를 정의하는데 있어서 누락을 최소화하고, 요구사항 및 업무 영역 반영에 있어서 누락이 없음
-준거성:제반 준수 요건들이 누락 없이 정확하게 준수되었음
-최신성:데이터 모델이 현행 시스템의 최신 상태를 반영하고 있고, 이슈사항들이 지체없이 반영되고 있음
-일관성:여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조·활용되면서, 모델 표현상의 일관성을 유지하고 있음
-활용성:작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계되어 있음
나.물리 데이터 모델 품질 검토 체크리스트의 활용
#검토대상
테이블: 테이블명, 테이블설명, 테이블 정의, 통합 수준, 권한, 발생건수/빈도, 법규준수, 요구사항 추적가능성
컬럼: 컬럼명, 컬럼 정의, 컬럼 설명, 기본키, 유닉키, 법규준수, 도메인 정의, 추출컬럼의 정의, 요구사항 추적가능성, 오너쉽 정의
외래키: 참조무결성 규칙 정의, 요구사항 추적가능성, 외래키 일관성
모델전반: 반정규화, 인덱스 정의, 스토리지 정의
'IT 자격증 > DAP,DAsP' 카테고리의 다른 글
| DAP 6과목 데이터 품질 관리 이해 (0) | 2024.05.14 |
|---|---|
| DAP 5과목 데이터베이스 설계와 이용 (0) | 2024.05.14 |
| DAP 3과목 데이터 표준화 (0) | 2024.05.13 |
| DAP 2과목 데이터 요건 분석 (0) | 2024.05.13 |
| DAP 1과목 전사아키텍처 이해 (0) | 2024.05.13 |
