03.08~03.09) SQLD정독 후 다시해보는 요약

SQLD공부

03.08~03.09) SQLD정독 후 다시해보는 요약_1-1장.

초코맛 2019. 3. 27. 03:33

제 1절 데이터 모델의 이해

1.데이터 모델의 이해

모델링의 이해

모델 : 모형, 축소형의 의미로 사람이 살며 나타날 수 있는 다양한 현상에 대해 일정한 표기법에 의해 표현해 놓은 모형
모델링 : 모델을 만들어가는 일 자체(일정한 표기법에 의해 표현하는 기법)
모델링의 특징

추상화-일정한 형식에 맞추어 표현
단순화-규약에 의해 제한된 표기법이나 언어로 쉽게 이해
명확화-정확하게 현상을 기술

모델링의 세가지 관점
모델링=데이터 관점+프로세스 관점
상관 관점

데이터 관점-어떤 데이터황 관련있는지, 관계는 무엇인지(지금 하는것)(What, Data)
프로세스 관점-실제하는 일, 무엇을 하는지 모델링(How, Process)
데이터와 프로세스의 상관관점-방법에 따른 영향(Interaction-Data vs Process)

2.데이터 모델의 기본개념의 이해

데이터 모델링의 정의

정보시스템을 구축하기위한 데이터 관점의 업무 분석 기법. 현실세계의 데이터(What)에 대해 약속된 표기법에 의해 표현하는 과정. 데이터 베이스를 구축하기 위한 분석/설계의 과정

데이터 모델이 제공하는 기능

가시화,명세화,구조화된 틀 제공, 문서화, 다양한 관점 제공(추상화), 구체화 된 상세 수준의 표현 방법 제공

3.데이터 모델링의 중요성 및 유의점

파급효과 : 구축중 문제가 발생하면 많은 수정이 필요(오류 많음)
복잡한 정보 요구사항의 간결한 표현

요구사항보다 데이터 모델 리뷰가 빠른 방법, 데이터 모델은 시스템을 구축하는 많은 관련자들이 설계자의 생각대로 정보 요구사항을 이해하고 이를 운용할 수 있는 애플리케이션을 개발하고 데이터 정합성을 유지할 수 있도록 하는것, 중요한 점은 정보요구사항이 정확하고 간결하게 표현되어야 한다.

데이터 품질 : 그저 그런 정확성이 떨어지는 데이터 방지를 위한 유의점->중복(최소화)/비유연성(하면x)/비일관성(하면x)

4.데이터 모델링의 3단계 진행

=>추상화 수준에 따라 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델로 정리됨.
개념적 데이터 모델링 (Conceptual Data Modeling)

: 데이터 요구사항을 찾고 분석, 관계-엔티티 다이어그램 생성. 데이터 모델링 과정이 전 조직에 걸쳐 이루어 진다면 전사적 데이터 모델(Enterprise Data Model)

논리적 데이터 모델링(Logical Data Modeling)

: 논리데이터 모델링이 핵심 =>조사+ERD+대부분의 사항 모두 정의, 또 한가지 중요 활동은 "정규화"인데, 논리데이터 모델 상세화 과정의 대표적활동으로, 일관성을 확보하고, 중복을 제거하여 속성이 적절한 엔티티에 배치되도록 함으로 신뢰성있는 데이터 구조를 얻는데 목적(상세화 : 식별자 확정, 정규화, M:M관계 해소, 참조 무결성 규칙 정의 등)

물리적 데이터 모델링(physical Data Modeling)

: 데이터 저장소로 어떻게 표현될지 다룬다. 이렇게 어떻게 저장될것인가에 대한 정의를 물리적 스키마라고 한다. 테이블, 컬럼 등의 구조와 저장장치등이 있다. 계층적 데이터 베이스 관리 시스템 환경에서는 많은 시간을 투자하여야 한다.

=>현실 프로젝트에서는 개념적 데이터 모델링->논리적 데이터 모델링->물리적 데이터 모델링으로 순차적으로 하지 않고 개념+논리 를 한번에 논리적 데이터 모델링으로 수행

5.프로젝트 생명주기(Life Cycle) 에서 데이터 모델링

=>Waterfall 기반에서는 데이터 모델링의 위치가 분석과 설계단계로 명확히 정의. 분석에서 업무중심의 논리적 데이터모델링 수행, 설계단계에서 하드웨어와 성능을 고려한 물리적 데이터 모델링 수행
=>나선형 모델(RUP나, 마르미) 에서는 업무 크기에 따라 논리,물리가 분석, 설계 양쪽에서 수행되며, 비중은 분석 단계의 논리적 데이터 모델이 더 많은 형태
=>데이터 축과 어플리케이션 축으로 구분되어 진행되며 상호검증을 지속적으로 수행하면서 단계별 완성도를 높이게 된다.(절차 지향) 단, 객체 지향 개념은 데이터와 프로세스를 한꺼번에 바라보면서 모델링을 전개하므로 구분하지 않고 일체형으로 진행한다.( ex,클래스(속성+일))

6.데이터 모델링에서 데이터 독립성의 이해

데이터 독립성의 필요성 : 어떤 단위에 의미를 부여하고 그것을 효과적으로 구현하게 되면 고유한 특징을 명확하게 하고, 다른 기능의 변경으로 부터 쉽게 변경되지 않고 고유한 기능을 가지고 기능제공의 장점이 있다.(반댓말 : 데이터 종속성) 데이터 독립성은 지속적으로 증가하는 유지보수 비용을 절감하고 데이터 복잡도를 낮추며 중복된 데이터를 줄이기 위한 목적이 있다. 또한 끊임없이 요구되는 사용자 요구사항에 대해 화면과 데이터 베이스 간에 서로 독립성을 유지하기 위한 목적으로 데이터 독립성 개념이 출현했다고 할 수 있다.
=>데이터 독립성을 확보하게 되면 얻는 효과 : 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경이 가능하다, 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공한다. 데이터 독립성을 이해하기 위해서 3단계인 구조, 독립성, 사상(Mapping)의 3가지를 이해하면 된다.
데이터 베이스 3단계 구조 : 외부 단계, 개념적 단계, 내부적 단계
데이터 독립성 요소 : 스키마 구조는 3단계로 구분되고 각각은 상호 독립적인 의미를 가지고 고유한 기능을 가진다. 데이터 모델링은 통합 관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정으로 이해할 수 있다.
두 영역의 데이터 독립성 : 논리적인 데이터 독립성은 외부의 변경에도 개념스키마가 변하지 않는 특징을 가짐
사상(Mapping) : 상호 독립적인 개념을 연결시켜주는 다리를 뜻함.
=>즉, 외부 화면이나 사용자에게 인터페이스하기 위한 스키마 구조는 전체가 통합된 개념적 스키마와 연결된다는 것이 논리적 사상이다. 또한 통합된 개념적 스키마 구조와 물리적으로 저장된 구조의 물리적인 테이블스페이스와 연결되는 구조가 물리적 사상이다.

7.데이터 모델링의 중요한 세 가지 개념

데이터 모델링의 세가지 요소 :
단수와 집합(복수)의 명명

8.데이터 모델링의 이해 관계자

이해관계자의 데이터 모델링 중요성 인식
데이터 모델링의 이해관계자 : 첫번째는 정보시스템을 구축하는 모든 사람/ 두번째는 IT기술에 종사하거나 전공하지 않았더라도 해당업무에서 정보화를 추진하는 위치에 있는 사람

9.데이터 모델의 표기법인 ERD의 이해

데이터 모델 표기법
ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법 : ERD는 각 업무분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법으로서 실제 프로젝트에서는 도식화된 그림 정도로만 생각하지 않고 해당 업무에서 데이터의 흐름과 프로세스와의 연관성을 이야기 하는데 가장중요한 표기법이자 산출물 이다.
2)엔터티 배치 : 가장 중요한 엔터티를 왼쪽 상단에 배치하고 이것을 중심으로 다른엔터티를 나열하면서 전개하면 사람의 눈이 따라가기에 편리한 데이터 모델링을 전개 할 수 있다.
3)ERD 관계의 연결 : 분석서를 보고 관련있는 엔터티간에 관계를 설정
4)ERD 관계명의 표시 : 대부분의 관계는 엔터티의 성질과 주식별자를 보고 유추 가능
5)ERD 관계 관계차수와 선택성 표시 : IE표기법으로 하나의 관계는 실선으로 Barker표기법으로는 점선과 실선을 혼합하여 표기한다. 다수참여의 관계느 까마귀 발과 같은 모양으로, 또한 관계의 필수/선택 표시는 관계선에 원을 표현하여 ERD를 그리도록 한다.

10.좋은 데이터 모델의 요소

완전성(Completeness) : 업무에 필요한 모든 데이터가 데이터 모델에 정의
중복 배제(Non-Redundancy) : 동일한 사실은 반드시 한번만 기록(나이와 생년월일도 중복이라 볼 수 있음)
업무 규칙(Business Rules) : 업무규칙을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용하는 모든 사용자가 공유 할 수 있도록 제공하는 것.(논리 데이터 모델에 포함 중요)
데이터 재사용(Data Reusability) : 데이터의 재사용성을 향상시키고자 한다면 데이터의 통합성과 독립성에 대해 충분히 고려(합리적으로 균형이 있으면서 단순히 분류/간결한 모델의 기본적인 전제는 통합으로 잘 데이터를 통합하여 데이터의 집합을 정의.
의사소통(Communication) : 데이터 모델의 의사소통 역할이 중요. 업무를 데이터 관점에서 분석하고 이를 설계하여 나오는 최종 산출물. 도출되는 많은 업무 규칙들을 데이터 모델에 엔터티,서브타입,속성,관계 등의 형태로 최대한 자세하게 표현.
통합성(Integration) : 가장 바람직한 데이터 구조의 형태는 동일한데이터는 조직의 전체에서 한번만 정의 되고 이를 여러 다른 영역에서 참조, 활용하는 것이다. 한번만 정의하기 위해서는 공유 데이터에 대한 구조를 여러 업무 영역에서 공동으로 사용하기 용이하게 정의할 수 있어야 한다.

제 2절 엔터티(Entity)

1.엔터티의 개념

=>우리말로 실체, 객체로 엔터티는 사람,장소,물건,사건,개념 등의 명사에 해당/업무상 관리가 필요한 관심사/저장이 되기 위한 어떤 것(Thing)=>따라서 엔터티란? 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)
=>인스턴스의 집합, 반대로 인스턴스라는 것은 엔터티의 하나의 값에 해당한다고 정의

2.엔터티와 인스턴스에 대한 내용과 표기법

그림에서 과목, 강사, 사건은 엔터티에 해당하고 수학, 영어는 과목이라는 엔터티의 인스턴스, 이춘식, 조시형은 강사라는 엔터티의 인스턴스이며 사건번호는 사건 엔터티에 대한 인스턴스에 해당한다.

3.엔터티의 특징

반드시 해당 업무에서 필요하고 관리하고자하는 정보이어야 한다 : 해당 업무에서 그 엔터티를 필욜 하는지
유일한 식별자(Unique Identifier)에 의해 식별이 가능
영속적으로 존재하는 인스턴스의 집합(한개 가 아니라 두개 이상)
엔터티는 업무 프로세스에 의해 반드시 이용되어야 한다. : 프로세스 모델링을 하면서 데이터 모델과 검증을 하거나, 상관 모델링을 할 때 엔터티와 단위 프로세스를 교차점검하면서 문제점이 도출된다.(create,read,update,delete등이 발생하지 않는 고립된 엔터티의 경우, 제거하거나 누락 프로세스가 존재하는지 살펴보고 해당 프로세스를 추가한다.)
엔터티는 반드시 속성이 있어야 한다. : 속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우는 관계가 생략되어있거나 업무분석이 미진하여 속성정보가 누락되는 경우에 해당한다. 또한 주식별자만 존재하고 일반속성은 없는 경우도 적절한 엔터티라고 할 수 없다. 단, 예외적으로 관계엔터티의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정한다.
엔터티는 다른 엔터티와 최소 한개 이상의 관계가 있어야 한다. : 부적절한 엔터티가 도출되었거나 적절한 관계를 찾지 못했을 가능성이 크다.(누락)
단) 데이터 모델링을 하면서 관계를 생략하여 표현해야 하는 경유는 다음과 같은 통계성 엔터티 도출,코드성 엔터티 도출,시스템 처리시 내부필요에 의한 엔터티 도출과 같은 경우이다.

1.) 통계를 위한 엔터티의 경우는 업무 진행 엔터티로 부터 통계업무만(Read Only)을 위해 별도로 엔터티를 다시 정의하게 되므로 엔터티 간의 관계가 생략 되는 경우에 해당.
2.) 너무많은 엔터티와 엔터티간의 관계설정으로 인해 데이터 모델의 읽기효율성(Readability)이 저하되어 도저히 모델링 작업을 진행할 수 없게 된다. 또한 코드성 엔터티는 물리적으로 테이블과 프로그램 구현 이후에도 외부키에 의한 참조무결성을 체크하기 위한 규칙을 데이터베이스 기능에 맡기지 않는경우가 대부분이기 때문에 논리적으로나 물리적으로 관계를 설정할 이유가 없다.
3.) 시스템 처리시 내부 필요에 의한 엔터티(ex/트랜잭션 로그 테이블 등)의 경우 트랜젝션이 업무적으로 연관된 테이블과 관계설정이 필요하지만 이 역시 업무적인 필요가 아니고 시스템 내부적인 필요에 의해 생성된 엔터티이므로 관계를 생략하게 된다.

4.엔터티의 분류

=>엔터티는 엔터티 자신의 성격에 의해 실체 유형에 따라 구분하거나 업무를 구성하는 모습에 따라 구분이 되는 발생 시점에 의해 분류해 볼 수 있다.
유무 형에 따른 분류

유형 엔터티(Tangible Entity)- 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티(업무로부터 구분하기가 가장 용이)
개념 엔터티(Conceptual Entity)- 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 되는 엔터티.
사건 엔터티로 구분(Event Entity)- 업무를 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다.

발생시점에 따른 분류 : 발생 시점에 따라

기본/키 엔터티(Fundamental Entity, key Entity)-그 업무에 원래 존재하는 정보.관계에 의해 생성되지 않고 독립적으로 생성 가능하고 자신은 타 엔터티의 부모의 역할.주식별자를 상속받지 않고 고유한 주식별자를 가지게 된다.
중심 엔터티(Main Entity)-기본엔터티로부터 발생되고 그 업무에 있어 중심역할, 다른엔터티와 관계를 통해 데이터의 양이 많이 발생되고 많은 행위엔터티를 생성
행위 엔터티(Active Entity)- 두개 이상의 부모엔터티로부터 발생되고, 자주내용이 바뀌거나 데이터량이 증가. 분석초기는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관 모델링을 진행하며 도출될 수 있다.
로 구분 할 수 있다.

엔터티 분류 방법의 예
이 밖에도 엔터티가 스스로를 생성될 수 있는지 여부에 따라 독립엔터티인지 의존 엔터티인지를 구분할 수도 있다.

5.엔터티의 명명

=>현업 업무에서 사용하는 용어 사용, 가능하면 약어를 사용하지 않는다. 단수명사를 사용한다. 모든 엔터티에서 유일하게 이름을 부여, 엔터티 생성의미대로 이름을 부여(업무목적에 따라 생성되는 이름)

제 3절 속성(Attribute)

1.속성(Attribute)의 개념

업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더이상 분리되지 않는 최소한의 데이터 단위
=>업무에서 필요
=>의미상 더 이상 분리되지 않는다
=>엔터티를 설명하고 인스턴스의 구성요소가 된다.

2.엔터티,인스턴스와 속성, 속성값에 대한 내용과 표기법

엔터티,인스턴스,속성,속성값의 관계

엔터티에는 두 개 이상의 인스턴스가 존재하고 각각의 엔터티에는 고유의 성격을 표현하는 속성정보를 두개 이상 갖는다. 각각의 인스턴스는 속성의 집합으로 설명될 수 있으며, 하나의 속성은 하나의 인스턴스에만 존재 할 수 있다. 속성은 관계로 기술될 수 없고 자신이 속성을 가질 수도 없다. 엔터티 내에 있는 하나의 인스턴스는 각각의 속성들의 대해 한 개의 속성값만을 가질 수 있다.
=>한개의 엔터티는 두개 이상의 인스턴스의 집합이어야 한다.
=>한개의 엔터티는 두개 이상의 속성을 갖는다
=>한개의 속성은 한 개의 속성값을 갖는다.
속성은 엔터티에 속한 엔터티에 대한 자세하고 구체적인 정보를 나타내며 각각의 속성은 구체적인 값을 갖게 된다.

3.속성의 특징

업무에서 필요하고, 관리하고자 하는 정보
정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
하나의 속성에는 한 개의 값만을 가지고, 하나의 속성에 여려개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여 분리한다.

4.속성의 분류

속성의 특성에 따른 분류

기본속성 : 업무로 부터 추출한 모든 속성. 가장 일반적이고 많은 속성을 차지
설계속성 : 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화 하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성(ex/일련번호)
파생속성 : 다른 속성에 영향을 받아 발생하는 속성. 보통 계산된 값들이 이에 해당. 영향을 받기 때문에 프로세스 설계시 데이터 정합성을 유지하기 위해 유의할점이 많아 적게 정의하는것이 좋다.

엔터티 구성방식에 따른 분류

PK(Primary Key)속성
FK(Foreign Key)속성
그외를 일반속성
또는
속성 안에 세부 의미를 쪼갤 수 있는지에 따라 단순형/복합형(ex/주소)
세부 속성들로 구성될 수 있는 복합 속성(Composite Attribute)
더 이상 다른 속성들로 구성될 수 없는 단순한 속성은 단순 속성(Simple Attribute)
또는
동일한 성질의 여러개의 값이 나타나는 경우 다중값(Multi Value)속성(이땐 1차정규화 또는 별도의 엔터티 관계로 연결)
속성 하나에 한개의 값을 가지는 경우를 단일값(Single Value))속성

5.도메인

각 속성의 가질수 있는 값의 범위. 엔터티 내에서 속성에 대한 데이터 타입과 크기 그리고 제약사항을 지정하는 것이라 할 수 있다.

6.속성의 명명(Naming)

=>용어의 혼란을 없애기 위해 용어사전이라는 업무사전을 프로젝트에 사용, 또한 도메인 정의를 미리 하여 용어적 표준과 데이터 타입의 일관성 확보.
해당업무(현업)에서 사용하는 이름 부여
서술식 속성명x
약어사용은 가급적 제한
전체 데이터모델에서 유일성 확보

제 4절 관계(Relationship)

1.관계의 개념

관계의 정의 : 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태
관계의 페어링

=>관계는 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것(페어링: 값 하나하나의 이어짐)이고 이것의 집합을 관계로 표현한다는 것. 따라서. 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 엔터티 사이에 두개이상의 관계가 형성될 수 있다.
=>각각의 엔터티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태를 관계의 페어링(Relationship Paring)이라 한다.
=>관계의 표현에는 이항,삼항,n항 관계가 존재할 수 있는데 실제에 있어서 삼항 관계 이상은 잘 나타나지 않는다.

2.관계의 분류

관계가 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있는 것은 관계를 연결함에 있어 어떤 목적으로 연결되었느냐에 따란 분류하기 때문이다.
=>UML(Unified Modeling Language)에는 클래스 다이어그램의 관계중 연관관계(Association)와 의존관계(Dependency)가 있다. 연관관계는 항상 이용한느 관계로 존재적 관계에 해당하고, 의존관계는 상대방클래스의 행위에 의해 관계가 형성될 때 구분하여 표현하는 것이 차이점이다. 즉, ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않고 표현했다면 클래스 다이어크램에서는 구분하여 연관관계는 실선->,소스코드에서는 멤버변수로 선언해 사용하고, 의존관계는 점선-->,행위를 나타내는 코드인 Operation(Method)에서 파라미터등으로 이용할 수 있도록 되어 있다.(비교주의)

3.관계의 표기법

관계명(Membership) : 관계의 이름

관계에 참여하는 형태, 두개의 관계명을 가지고 있다.
엔터티에서 관계가 시작되는편인 관계시작점(The Beginning)이라고 부르고 받는 편을 관계끝점(The End)라고 부른다. 양쪽 다 관계명을 가지고 참여자의 관점에 따라 관계이름이 능동적(Active)이거나 수동정(Passive)으로 명명된다.
명명규칙 : 애매한 동사를 피한다. (구체적)/현재형으로 표현한다

관계차수(Cardinality/Degree) : 1:1, 1:M, M:N

두 개의 엔터티간 관계에서 참여자의 수를 표현하는 것을 관계차수(Cardinality)라고 한다.
일반적인 관계차수 표현방법은 1:1, 1:M, M:N이다. 이때 한 개의 관계가 존재하는지 두개이상의 관계명이 존재하는지 파악이 중요
표현하는 방법으로는 Crow' s Foot모델에서 선을 이용하여 표현하는 것으로, 한개면 실선, 다수참여는 까마귀발과 같은 모양.
1:M) 관계에 참여하는 각각의 엔터티는 관계를 맺는 다른 엔터티의 엔터티에 대해 하나나 그 이상의 수와 관계를 가지고 있다. 그러나 반대의 방향은 단지 하나만의 관계를 가지고 있다.
M:N) 이렇게 M:N의 관계로 표현된 데이터 모델은 이후에 두개의 주식별자를 상속받은 관계엔터티를 이용하여 3개의 엔터티로 구분하여 표현한다.

관계선택사양(Optionality) : 필수관계, 선택관계

반드시 실행되어야 하는 필수적인 관계를 필수 참여관계(Mandatory), 관련은 있지만 서로가 필수적인(Mandatory)관계는 아닌 선택적인 관계(Optional)이 된다.
이와같은 것이 데이터 모델 관계에서는 선택참여관계(Optional)가 된다. 참여하는 엔터티가 항상 참여하는지 아니면 참여할 수도 있는지를 나타내는 방법이 필수(Mandatory Membership)와 선택참여(Optional Membership)이다.
필수참여는 참여하는 모든 참여자가 반드시 관계를 가지는, 타 엔터티의 참여자와 연결이 되어야 하는 관계이다.
선택참여된 항목은 물리속성에서 Foreign Key로 연결될 경우 Null을 허용할 수 있는 항목이 된다.
선택참여관계는 ERD에서 관계를 나타내는 선에 선택참여 하는 엔터티쪽을 원으로 표시 한다. 필수참여는 아무표시x
만약 관계가 표시된 양쪽 엔터티에 모두 선택참여가 표시된다면, 즉 0:0(Zero to Zero)의 관계가 된다면 그 관계는 잘못될 확률이 많으므로 관계 설정이 잘못되었는지 검토해야 한다.
=>관계선택사양은 관계를 통한 상대방과의 업무적인 제약조건을 표현하는 것으로서 간단하면서 아주 중요한 표기법, 이것을 어떻게 설정했는지에 따라 참조무결성 제약조건의 규칙이 바뀌게 되므로 주의 깊게 모델링을 해야한다.

4.관계의 정의 및 읽는 방법

관계 체크사항

두 개의 엔터티 사이에 관김있는 연관규칙이 존재?
두 개의 엔터티 사이에 정보의 조합이 발생?
업무기술서, 장표에 관계연결에 대한 규칙이 서술되어있는지?
업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는지?

관계 읽기

방법 : 먼저 관계에 참여하는 기준엔터티를 하나 또는 각(Each)으로 읽고 대상 엔터티의 개수(하나, 하나이상)을 읽고 관계선택사양과 관계명을 읽도록 한다.
기준(Source) 엔터티를 한 개 또는 각으로 읽는다
대상(Target) 엔터티의 관계참여도 즉 개수를 읽는다
관계선택사양과 관계명을 읽는다.
=>위의 관계를 정의한 사항에 대해 뒤를 의문문으로 만들면 관계도출을 위한 질문 문장으로 만들 수 있다. 이러한 질문 방법은 엔터티간 관계설정뿐 아니라 업무의 흐름도 분석이 되는 실제 프로젝트에서 효과적인 방법이 된다.

제 5절 식별자

1.식별자(Identifiers) 개념

=>식별자는 하나의 엔터티에 구성되어 있는 여러 개의 속성중에 엔터티를 대표할 수 있는 속성을 의미하며 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야 한다.

2.식별자의 특징

주식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분되어야 한다.
주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
주식별자가 지정이 되면 반드시 값이 들어와야 한다.
=>대체식별자의 특징은 주식별자의 특징과 일치하지만 외부식별자는 별도의 특징을 가지고 있다. 외부식별자의 경우 주식별자 특징과 일치하지 않으며 참조무결성 제약조건(Referential Integrity)에 따른 특징을 가지고 있다.

3.식별자 분류 및 표기법

식별자 분류

식별자 표기법

4.주식별자 도출기준

해당 업무에서 자주 이용되는 속성을 주식별자로 지정

명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.

이름 같은 경우 20자 이상이 될 수 있어 조건절에 정확하게 기술하기가 쉽지 않다. 따라서 이와 같이 명칭이나 내역이 있고 인스턴스들을 식별할 수 있는 다른 구분자가 존재하지 않을 경우는 새로운 식별자를 생성하도록 한다. 보통 일련번호와 코드를 많이 사용한다.

복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.

복잡한 데이터 모델이 구현되어 물리데이터베이스에서 조인으로 인한 성능저하가 예상되는 모습을 가지고 있다면 속성의 반정규화 측면에서 하나의 테이블에 많은 속성이 있는 것이 인정될 수도 있다. 하지만 일 반적으로 주식별자의 속성의 갯수가 많다는 것(일반적으로 7~8개 이상)은 새로운 인조식별자(Artificial Identifier)를 생성하여 데이터 모델을 구성하는 것이 데이터 모델을 한층 더 단순하게하고 애플리케이션을 개발할 때 조건절을 단순하게 할 수 있는 방법이 될 수 있다.
왼편의 복잡한 주식별자를 임의의 주식별자를 생성하여 단순화한 예)
접수번호라고 하는 인조식별자로 대체하면서 SQL문장이 훨씬 간단하게 할 수 있다.

5.식별자관계와 비식별자관계에 따른 식별자

식별자관계와 비식별자 관계의 결정

중요 고려 사항) 엔터티에 주식별자가 지정되고 엔터티간 관계를 연결하면 부모쪽의 주식별자를 자식엔터티의 속성으로 내려 보낸다. 이 때 자식엔터티에서 부모엔터티로부터 받은 외부식별자를 자식의 주식별자로 이용할 것인지 또는 부모와 연결이 되는 속성으로서만 이용할 것인지를 결정해야 한다.
=>엔터티 사이 관계유형은 업무특징, 자식엔터티의 주식별자구성, SQL전략에 의해 결정된다.

식별자 관계

=>부모로 부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우는 Null값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우. (1:1,1:M)
=>이와 같이 자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우를 식별자 관계(Identifying Relationship)이라고 지칭한다.

비식별자관계(Non-Identifying Relationship)

=>부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우
1) 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우
2) 엔터티 별로 데이터의 생명주기(Life Cycle)을 다르게 관리할 경우.(Foreign Key를 연결하지 않는 임시 방법을 사용하기도 하지만 데이터 모델상에서 관계를 비식별자관계로 조정하는것이 가장 좋은 방법)
3) 여러개의 엔터티가 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때 식별자 관계가 비식별자 관계로 될 수 밖에 없게 됨.

4) 자식엔터티에 주식별자로 사용하여도 되지만 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때 비식별자 관계에 의한 외부식별자로 표현한다.

식별자 관계로만 설정할 경우의 문제점

=> 부모에서 자식으로 식별자관계로 연결되므로 인해 주식별자의 속성수가 많아지게 된다.
즉, PLANT엔터티에는 PK속성의 수가 1개이고, 관계가 1:M으로 전개되었으므로 자식엔터티는 PLANT엔터티 PK속성의 수+1이 성립된다. 물론 1개 이상의 속성이 추가되어야 1:M의 관계를 만족할 수 있다.
이와 같은 원리에 의해 1:M 관계의 식별자관계의 PK속성의 수는 다음과 같다.
이와 같은 규칙에 의해 지속적으로 식별자 관계를 연결한 데이터 모델의 PK속성의 수는 데이터 모델의 흐름이 길어질수록 증가할 수 밖에 없는 구조를 가지게 된다.
=>3개의 엔터티를 조인했을 뿐인데 SQL구문의 where절이 매우 길어진 사실을 확인할 수 있다. 정리하면 식별자 관계만으로 연결된 데이터 모델의 특징은 주식별자 속성이 지속적으로 증가할 수 밖에 없는 구조로서 개발자 복잡성과 오류가능성을 유발시킬 수 있는 요인이 될 수 있다는 사실을 기억해야 한다.

비식별자 관계로만 설정할 경우의 문제점

=>데이터 모델링을 전개할 때 각 엔터티간의 관계를 비식별자 관계로 설정하면 이런 유형의 속성이 자식엔터티로 상속이 되지않아 자식엔터티에서 데이터를 처리할 때 쓸데없이 부모엔터티까지 찾아가야 하는 경우가 발생된다.
=>비식별자 관계로 자식엔터티로 내려가는 것을 차단, 이러한 모델에서 만약 맨 하위에 있는 REP007T엔터티에서 어떤 점검에 대한 정보를 보려고 하면 불필요한 조인이 다량으로 유발되면서 SQL구문도 길어지고 성능이 저하되는 현상 발생

식별자와 비식별자관계 비교

=>비식별자관계는 SQL구문에 많은 조인이 걸리게 되고 그에따라 복잡성이 증가하고 성능이 저하,
식별자 관계는 부모의 모든 주식별자 속성을 상속받음으로 인해 원하는 정보를 바로 가져올 수 있다.
이러한 경우 당연히 성능과 개발의 용이성 측면에서는 식별자관계까 우위에 있음을 보여준다.
따라서 이 두가지 경우에 대해서 일정한 규칙을 가지고 데이터 모델링을 하는 기술이 필요하며, 다음에 제시된 고려사항을 데이터 모델링에 반영한다면 효과적인 데이터 모델을 만들어 내는데 유용하게 활용할 수 있다.