[DAP 요약] 제 2장 식별자, 정규화 - (2/5)

2025.01.07 - [자격증/DAP] - [DAP 요약] 제 1장 데이터 모델링 이해 - (1/5)

[DAP 요약] 제 1장 데이터 모델링 이해 - (1/5)

 

(과제를 해보니 슬슬 어려워진다.. 모델을 그려본 적이 없어서 그런거겠지 자기최면하고.. 일단 해보자..)

* 시작 전 시험 팁

실기 시험 때는 특정 기준으로 채점이 될 텐데 그 중에 시간이 없어서 속성들을 다 못 적더라도 엔터티와 식별자는 꼭 그리라고 한다. 가장 배점이 크단다!
(속성을 적을 시간이 없다면 그냥 .... 으로 표현해 버리고 엔터티와 식별자나 제대로 그리라는 뜻)
가장 우선으로 챙겨야 할 실기 시험 채점의 4가지 기준 : 엔터티, 식별자, 관계, 서브타입

 

* 식별자

식별자 종류 : 

본질 식별자 / 인조 식별자 / 후보 식별자 / 대체 식별자 / 실질 식별자

 

식별 관계의 의미

- 식별자 또는 정보로서의 역할

* 본질 식별자는 1. 누가/1. 무엇을/2. 언제/3. 어디서 로 생성함

보통 1번인 누가와 무엇을은 필수로 구성되고, 2번인 언제와 간혹 3번인 어디서가 포함됨

절대종속 & 직접종속 인 것을 찾기 위함이며, 자신을 태어나게 한 근본을 찾기 위함이다

 

* 부모로부터 식별자를 물려 받았다면(본질 식별자 사용 시), 부모를 거치지 않고도 조상을 직접 찾을 수 있음

인조 식별자를 사용했다면.. 못찾지. 대신 조인 관계에서 매우 간결한 조인문으로 사용 가능함.

* 따라서 인조 식별자를 사용한다면 보통 조인 관계가 많이 생성되는 "메인" 엔터티에서 사용하고, 반드시 인조식별자 1개로만 식별자를 생성한다.

같은 의미로.. Action(행위) 엔터티는 반드시 본질 식별자(부모로부터 식별자를 상속)를 사용해라.. 인조 식별자를 채번하지 마라!!

 

식별자 확정

- 식별자 확정 절차

ㄴ 1. 키 엔터티 식별자 확정

    ㄴ 본질 식별자와 동일할테니 본질 식별자 결정 단계에서 미리 확정한다

ㄴ 2. 메인 엔터티 식별자 확정

    ㄴ 상위 엔터티(자식이 많아질 테니)이므로 식별자 속성 개수를 적게 하는 것이 좋다(조인 복잡) 

    ㄴ 따라서 인조 식별자를 사용하기도 한다

ㄴ 3. 액션 엔터티

    ㄴ 정보로서의 가치가 감소하는 인조식별자 대신 본질 식별자를 지정하라! 

    ㄴ = 이력, 현황 등의 엔터티에서 이력번호 등의 인조식별자는 절대 쓰지 말라는 것!

 

관계

관계 형태

1. 선택사항

- 일반적인 형태로는 1:M 관계일 시 1측이 선택(Optional) M측이 필수(Mendentory)로 많이 나타난다.(필수는 아님)

2. 바람직한 형태  

- 가능한 직선 관계(필수)를 가지도록 노력한다. 특히 자식 엔터티!

 

관계명

- 각자 상대방 입장에서의 관계명을 기술한다..

* 라고 되어 있지만 실기 땐 그냥 자식 기준에서 자식의 속성명을 쓰면 정확하다

* 라고 했지만 객관식 에서는 현업에서 사용하는 간결한 동사형 으로 표현한다고 외우자

 

관계 형태

병렬식 vs 직렬식

병렬식 

테이블이 될 때 여러개의 컬럼으로 나열됨

단점) 인덱스 수가 증가됨. 새로운 관계의 추가 시 관계 형태 및 속성 추가 등 변경에 매우 취약함  .

직렬식

관계들이 로우 형태로 나타남

인덱스 수가 감소됨

새로운 관계의 추가 등 변경에 유연함

단점) 관계들을 관리하는 새로운 엔터티가 필요함.

직렬식으로 통합 시 교차 Entity가 필요함

 

특수한 형태 관계

1. 순한 관계

Recursive Relationship.

하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함해야 한다

순환 모델은 필수(직선) 관계로 취급할 수 없고(무한 루프됨) 반드시 선택 사항(점선)으로 그려야 한다

순환 모델은 조직의 변경 등에 쉽게 대응이가능하다

(조직번호 + 상위조직번호 등으로 관리되는 것) 

 

2. BOM 관계

M:M 순환관계

부모가 여럿이다..

굉장히 유연하고 모든 상황에 대처 가능하지만... 복잡하고 어렵다

http://www.gurubee.net/wiki/pages/983056

 

3. Arc 관계

아크는 반드시 하나의 엔터티에만 속해야함. 여러 엔터티가 모여서 아크를 이룰 수 없음.

아크 내의 릴레이션십은 모두 필수거나 모두 선택이거나여야함. 필수나 선택이 섞여있으면 안됨!

하나의 엔터티에서 여러 아크가 있을 수는 있음.

 

논리 데이터 모델

데이터의 일관성 및 정확성(무결성) 유지를 위한 규칙 도출

- 모델링 필수 성공 요소

* 업무에 능통한 현업 사용자와 함께 데이터 모델링을 진행하라

(여기서 현업이 개발자로 바뀌면 틀린 말임.)

절차 보다는 데이터에 초점을 둬라.

데이터의 구조와 무결성을 함께 고려하라.

개념화와 정규화 기법을 적용하라.

데이터 사전을 구축하라.

ERD로 업무를 표현하라.

 

속성

- 속성 후보 수집처

구 시스템의 문서 자료

협업 장표/ 보고서

사용자 협의

Data Flow Diagram, Data Dictionary

전문서적 및 자료

* 다른 시스템 자료(도 후보 맞다)

 

- 속성 후보 선정 원칙

원시 속성으로 보이는 후보는 버리지 않는다.

    다른 속성에 의해 재현될 수 있는 가공(추출) 속성이 아닌 속성!

    이 속성이 없다면 다시는 재현될 수 없는 속성

 

- 속성의 기본 구성 요소

- 속성명

    속성의 의미를 명확히 표현하는 함축성 있는 명사 또는 명사구를 사용

    ㄴ 그냥 "일자" 로만 하지 말고 "납입일자" 처럼 명확하게 표현하라!

    해당 업무에서 일반적으로 사용하는 용어를 사용하라

    실체명은 속성명으로 사용하지 마라

    ㄴ 엔터티 명을 속성으로 쓰지 말라는 것

    * 필요시 표준 약어를 어쩌구.. 하는데 그냥 단어의 조합으로 표준단어를 생성해서 그 표준단어로만 사용하도록 하라는 것

 

- 속성의 검증 및 확정

가. 최소 단위까지 분할

집합 속성의 개념은 단순 개념으로 분할하라..

다만, 일자, 시간, 성명, 주민번호, 우편번호 등은 일반적으로 분할하지 않는 것이 좋다. 

(* 주민번호를 분할해서 940420과 1****** 등으로 나누면서 성별을 추출하지 말고, 그냥 성별 속성을 별도로 두라는 것)

* 분할 및 통합의 기준은 업무의 요구사항에 따른다

 

나. 하나의 값인지?

여러 값을 가지거나 반복되는 속성은 잘못된 것!

반복되는 속성은 1차 정규화 대상이다

 

다. 추출 속성인지 검증

현재 정보만 관리하는 형태 : 현주소, 고객등급

최초 정보만 보관하는 형태 : 최초 가입일자 등

집계 정보 : 인원수 등

추출 속성의 경우 초반에는 중복으로 판단하여 모델에 표현하지 말아라고 했음.

그러나 현재는 기업의 관리자들이 원하는 속성으로 데이터 모델 내 반드시 기술할 것을 권장함.

도출 속성이나 계산 속성 등을 말하는 것.

도출 속성은 사용자들의 데이터 요구사항을 나타냄.

다만 기본키의 역할을 맡아서는 절대 안된다!

 

라. 보다 상세하게 관리할 것인지 체크

 

 

식별자(UID, Unique Identifier)

유일성을 보장하기 위함.

 

- 본질 식별자

Key 엔터티에서 본질 식별자 구분의 의미

ㄴ 엔터티의 모호성을 해결하기 위함?

 

행위 엔터티에서 본질 식별자 구분의 의미(메인 엔터티 포함)

ㄴ 부모가 누군지 확인하기 위함

 

- 절대종속 / 상대종속의 의미

절대종속 : 나를 태어나게 하는 엔터티와의 관계

상대종속 : 나의 탄생과는 관계없으나 관계를 맺고 있는 것(각종 코드)

 

직접/간접종속 : 1촌인가?

본질식별자는

누가 / 무엇을 / 언제 / 어디서로 식별할 수 있다

보통 누가, 무엇을로 많이 식별하며, 언제가 가끔 붙고 어디서는 아~주 가끔!

 

* 식별자 확정 절차

하향식 방식, 즉 상위 엔터티에서 하위 엔터티 순으로 결정하는 것이 좋다

- 키 엔터티 식별자 확정

ㄴ 본질 식별자를 결정하는 단계에서 미리 식별자를 확정하는 것이 현실적

ㄴ 본질 식별자를 사용함.(아니 어차피 인조 식별자나 본질이나 큰 의미가 없다. 똑같이 생기겠지. 키 엔터티라 부모가 없는데) 

- 메인 엔터티 식별자 확정

ㄴ 상위 엔터티 이므로(자식이 많으므로) 식별자 속성의 개수를 적게 하는 것이 좋다. 

    따라서 인조 식별자를 생성하기도 한다.

- 하위 엔터티 식별자 확정

ㄴ 정보로서의 가치가 감소하는 인조식별자는 쓰지 않으며, 본질 식별자를 사용하라.

  

* 정규화

가장 중요하다는 정규화, 모든 사람이 알지만 아무도 모른다는 정규화다.

1, 2, 3, BCNF, 4정규화 까진 달달 외우라고 하신다.

책에선 업무에선 3정규화까지만 진행하라고 했다하는데, 강사님은 4정규화까지 필요하다 하셨다.

 

* 1차 정규형

Single Value!

1. 모든 속성은 하나의 값을 가져야 한다.

2. 값이 반복되면 안된다.(Single value)

고객 레벨 엔터티에 주문일자 등의 컬럼이 있다면, 고객이 주문 할때마다 데이터가 쌓이면서 고객 엔터티에 고객 정보 데이터가 반복될 것임!

3. 비슷한 유형의 속성이 반복되면 안된다!

자택 전화번호, 직장전화번호, 휴대폰번호 등등..

 

1차 정규화 진행 시 자식 엔터티가 탄생한다 

 

* 2차 정규형

식별자가 아닌 모든 일반 속성들은 식별자에 완전 종속이어야 한다

= pk가 아닌 모든 컬럼은 pk에 종속이어야 한다.

 

2차 정규화 진행 시 부모 엔터티가 탄생한다 

 

* 3차 정규형

식별자를 제외한 모든 일반 속성들끼리는 종속 관계가 있으면 안된다

 

3차 정규화 진행 시 참조관계 상위 엔터티가 탄생한다 

 

시험팁!

정규화는 ERD 박아놓고 이건 몇정규화냐~ 정규화 몇 한거냐 등등 문제 오지게 나오니까.. 꼭 잘봐두자!

 

*  BCNF

식별자는 결정자 이어야 한다..

식별자가 종속자가 되어서는 안된다! (분리가 필요하다) 

일반속성인 A 속성을 알면 식별자인 B 속성을 알 수 있는 경우가 있다면, 이때 A속성과 B 속성을 분리해야 한다는 뜻.

 

* 제 4 정규형

관계 있는 것끼리만! 교차 엔터티를 만들어라..

교차 엔터티에 관계 없는 속성이 껴있으면! 별도 교차 엔터티도 빼라!

 

 

- M:M 관계 해소

M:M 관계는 논리 모델링에서 많이 보인다.

아직 모델링이 덜 완성된 경우인데,

최종적으로는 있으면 안되는 형태이다.

만약 존재한다면, 상세화 과정을 통해야 하며

이 과정에서 액션 엔터티가 새롭게 도출된다.