#모델링의 기본 원칙
1) 커뮤니케이션 원칙
3) 모델링의 상세화 원칙
3) 논리적 표현 원칙
# 참조 무결성 규칙 - 관계 실체의 모든 외부 식별자 값은 관련 있는 실체에 주식별자 값이 존재해야 한다는 규칙
#개체-관계 모델에 대한 설명
1) 모델의 단순성 때문에 현재 광범위하게 사용되고 있다.
2) 확장된 개체-관계 모델은 서브타입을 포함한다.
3) 개체-관계 모델은 관계 클래스와 관계 인스턴스를 모두 포함한다.
#데이터의 특성
1) 데이터는 조직과 기술에 비해 독립적이다.
2) 데이터는 프로세스에 비해 안정적이다. 즉, 변화가 적다.
3) 데이터는 여러 프로세스 또는 기능에서 사용된다.
#소프트웨어 생산성 향상을 위한 객체지향 모델링의 장점
1) 재사용 코드와 같은 개념이 실제로 가능한 환경을 제공한다.
2) 모든 비즈니스 규칙이 표현될 수 있는 유일한 환경을 제공한다.
3) 프로세스와 데이터 모델링을 함께 운영한다.
# ‘논리 데이터 모델링’ 이라는 용어에서 ‘논리’라는 단어가 사용된 이유?
- 논리적이라는 용어는 논리 데이터 모델링이 현실 세계를 추상화하기 때문에 사용한다.
개념화 기법을 적용하여 모델을 만드는데도 이유가 될 수 있다.
#‘관계형 모델 이론’과 ‘비관계형 모델 이론’의 차이점
1) 관계형 모델 이론은 데이터 중심의 분석 기법이고, 비관계형 모델 이론은 일반적으로 프로세스 중심의 분석 기법이다.
2) 관계형 모델 이론은 데이터의 구조와 조작 및 무결성을 정의하고, 비관계형 모델 이론은 데이터의 구조와 조작을 정의한다.
3) 관계형 모델 이론은 데이터를 집합적으로 처리를 요구하고, 비관계형 모델 이론은 데이터의 레코드 처리(한 건씩 처리)를 요구한다.
#논리 데이터 모델링에 대한 설명
1) 논리 데이터 모델의 특징은 초기에 엔터티 사이가 다대다 관계, 순환 관계, 베타적 관계 등의 관계로 연결된 엔터티들이 많이 보인다.
2) 논리 데이터 모델링은 프로세스 중심의 설계보다 데이터 중심 설계를 주로 사용한다.
3) 논리 데이터 모델은 하나의 엔터티가 반드시 물리적으로 하나의 테이블이나 세그먼트가 되지 않을 수 있다.
#관계연산자의 설명
1) Select : 열에 의거한 행
2) Product : 두 관계 테이블 간의 행 조합의 묶음
3) Division : 다른 관계 테이블의 모든 행에 대응하는 열을 제외한 열
#처리연산자의 설명
1) Updata : 행의 수정
2) Delete : 행의 삭제
3) Insert : 행의 입력
#본질적 데이터 요구 사항이며 데이터베이스 설계를 시작하기 위한 필수 사항
1) 이름 : 모든 속성은 고유하게 식별할 수 있는 이름이 주어져야 한다.
2) 명세 : 모든 실체는 명세가 있어야 하며, 명세는 모형을 검토하는 누구든지 그 실체를 정확히 해석할 수 있도록 해주어야 한다.
3) 유형 : 속성은 두가지 유형 즉, 키 속성 또는 비키 속성 중 하나로 구분되지 않으면 안된다. 이 특성은 키 속성으로써의 역할 가능성 보다는 실제 용도와 관련된다.
4) 도출 공식 : 데이터 모델링 팀은 업무 전문가의 참여 하에 도출 공식을 확립해야 한다.
#속성이름을 부여할 때, 주요 규칙에 대한 설명
1) 속성 이름은 해당 속성에 의해 구체화된 논리적 개념을 현업에게 즉시 전달해야 한다.
그러므로 속성 이름은 명료, 간결, 자명해야 한다.
2) 모델러들은 논리 데이터 모형을 구축하고 있는 것이다. 물리적 특징들로 개념을 제한 또는 왜곡해서는 안 된다. 즉 물리적 특성이 아닌 논리적 고려에 따라 속성이름을 부여 한다.
3) 속성의 개념을 구체적이고 명확하게 정의하였다면 보편적인 용어를 적절히 결합한 복합명사를 만들어서 구체적인 표현을 할 수 있게 속성이름을 부여해야 한다.
#실체 무결성 규칙 - 주 식별자(특정 행을 유일하게 인식하는 하나 이상의 열)는 Null 값을 포함하지 않는다.
#아크(Arc) 관계의 특징
1) 아크 내에 있는 관계는 보통 동일하다
2) 아크 내에 있는 관계는 항상 Mandatory거나 Optional이어야 한다.
3) 아크는 반드시 하나의 엔터티에만 속해야 한다.(하나의 아크가 여러 엔터티를 가질 수 없다).
4) 어떤 엔터티는 다수의 아크를 가질 수 있다. 그러나 지정된 관계는 단 하나의 아크에만 사용되어야 한다.
#참조무결성 규칙 중 입력 규칙에 대한 설명
1) Dependent : 대응되는 부모 실체에 인스턴스가 있는 경우에만 자식 실체에 입력을 허용한다.
2) Nullify : 자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 자식 실체의 Foregin Key를 Null 값으로 처리한다.
3) Customized : 특정한 검증조건이 만족되는 경우에만 자식 실체 인스턴스의 입력을 허용한다.
4) Default : 자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우
Foreign Key를 지정한 기본값으로 처리한다.
#속성을 검증하는 작업
1) 원자단위 검증 : 사물의 본질을 이루는 고유한 특성이나 성질이 속성이다.
즉, 속성은 독자적인 성질을 가져야 한다
2) 유일값 검증 : 속성에서 관리되어야 할 값이 반드시 단 하나만 존재해야 한다는 것이다.
3) 추출값 검증 : 속성이 원천적인 값인지 다른 속성에 의해 가공되어서 만들어진 값인지를 검증해야 한다.
#엔터티 검증
1) 엔터티의 개념을 확실하게 모델러들이 정립해야 한다.
2) 새로운 목적 시스템에서 관리하고자 하는 대상 집합이 있는지 확인해야 한다.
3) 엔터티에 가로(속성)와 세로(개체)를 가진 면적(집합)을 가진 속성이 존재하는지 확인해야 한다.
#데이터 모델링의 단계와 설명
1) 개념 모델 단계 : 엔터티를 추출하고 속성과 관계를 정의하여 개체-관계 도표를 구성하는 단계
2) 논리 모델 단계 : 개체-관계 도표를 맵핑 룰에 의해 스키마를 설계하고 정규화 과정을 수행하는 단계
3) 물리 모델 단계 : 데이터 사용량을 분석 예측을 통해 데이터베이스의 인덱스 정의 및 역정규화 과정을 수행하는 단계
#실체 정의
1) 구별 가능한 사람, 장소, 물건, 행위 또는 개념 등에 대하여 정보가 유지되어야 하는 것
2) 다른 것과 구별되어 식별될 수 있는 사물
#속성 정의
1) 더 이상 분리되어지지 않는 단위 값(Atomic Value)
2) 실체를 서술하여 양을 계수화하고 자격을 부여:분류하며 구체적으로 기입하는 정보항목
#식별자에 대한 설명
1) 식별자는 하나 또는 그 이상의 개체 속성으로 구성된다.
2) Barker 표기법은 식별자를 ‘#’로 표현한다.
3) 직원 인스턴스인 경우 봉급이나 입사일은 식별자가 될 수 있다.
#서브타입에 대한 설명
1) 서브타입 개체는 그것의 슈퍼타입이라고 불리는 다른 개체의 특별한 경우이다.
2) 모든 슈퍼타입이 구분자를 가지고 있는 것은 아니다.
#객체지향 모델링과 논리 데이터 모델링의 대응개념
1) 객체 - 엔티티
2) 연결 - 관계
3) 메시지 - 대응 개념 없음
#표현식
1) 식별성 표시
2) 선택성 표시
3) 기수성 표시
#전체 비즈니스를 데이터 관점에서 분류하는 작업
1) 주제영역은 기업이 사용하는 데이터의 최상위 집합이다.
2) 데이터를 하향식으로 분석하는데 유용하다.
3) 주제영역을 분해하면 하위 수준의 주제영역이나 엔터티가 나타난다.
#주제 영역에 대한 설명
1) 주제 영역은 시스템의 대상이 되는 업무를 명백하게 구분이 가능한 단위 업무로 분리하는 개념이다.
2) 주제 영역을 결정할 때는 주제 영역 내부에 존재하게 될 개체들이 높은 결합성을 유지하게 해야 한다.
3) 데이터 모델과 프로세스 모델은 별개로 진행될 수 있지만 상호 보완적인 위치에 있고 주제 영역은 프로세스 모델링의 기능과 매핑되는 것이 보통이다.
#주제영역 활용의 장점
1) 데이터 및 업무활동 모델의 품질보증이 용이함
2) 프로젝트 관리가 용이함
3) 모델 개발조정이 용이하고 요구사항 검증 시 기준으로 활용 가능함
#엔티티 후보 선정을 수행할 때 유의사항
- 동의어처럼 보이더라도 함부로 버리지 않는다.
#모델러가 개념 데이터 모델링 단계에서 엔티티 후보를 도출하고 엔티티 후보들에 대한 자격검증을 위한 엔터티 식별 단계를 수행하고 있다. 모델러가 이 단계에서 수행해야 하는 행동
1) 후보 엔터티가 정확히 어떤 개념인지를 파악하기 위해서 동종의 비즈니스 관련 서적에서 관련 개념을 파악한다.
2) 인터넷을 통하여 해당 후보 엔터티의 용어적인 의미를 파악하기 위해서 자료를 검색한다.
3) 특정 업종에서만 사용하는 용어라서 모델러가 판단하기 힘들면 주변에 존재하는 비유를 들어서 업무 담당자와 개념에 대한 동질성을 파악한다.
'Computer > Database' 카테고리의 다른 글
데이터 아키텍처 - 데이터 모델링 [3] (0) | 2013.05.26 |
---|---|
데이터 아키텍처 - 데이터 모델링 [2] (0) | 2013.05.26 |
데이터 아키텍처 - 데이터 표준화 (0) | 2013.05.20 |
데이터 아키텍처 - 데이터 요건 분석 (0) | 2013.05.16 |
데이터 아키텍처 - 전사아키텍처(EA, Enterprise Architecture) (0) | 2013.05.13 |