1. 데이터 모델링의 이해

데이터 모델

• 데이터 모델링은 현실 세계를 데이터베이스로 표현하기 위해서 추상화 한다.
• 데이터 모델링을 하기 위해서는 고객과의 의사소통을 통해 고객의 업무프로세스를 이해해야 한다.
• 고객의 업무 프로세스를 이해한 후 데이터 모델링 표기법을 사용해서 모델링을 한다.
• 데이터 모델링은 고객이 쉽게 이해할 수 있도록 복잡하지 않게 모델링 해야 한다.
• 데이터 모델링은 고객의 업무 프로세스를 추상화하고, 소프트웨어를 분석, 설계하면서 점점 더 상세해진다.
• 데이터 모델링은 고객의 비즈니스 프로세스를 이해하고 비즈니스 프로세스의 규칙을 정의
  정의된 비즈니스 규칙을 데이터 모델로 표현
• 데이터 모델링 자체로서 업무의 흐름을 설명(별도의 표기 필요없음)하고 분석하는 부분에 의미를 가짐.
• 분석된 모델을 가지고 데이터베이스 생성하여 개발 및 데이터관리에 사용하기 위함

데이터 모델링 유의점 및 3가지 관점 및 중요 3요소

유의점

• 중복(Duplication) : 같은 데이터가 엔티티에 중복 저장되면 안된다.
  
• 비유연성(Inflexibility) : 애플리케이션의 ‘사소한 변경’에도 데이터 모델이 수시로 변경되면 안된다. → 데이터 모델과 프로세스 분리해서 유연성 높여야한다.
  
• 비일관성(Inconsistency) : 중복이 없는 경우에도 비일관성 발생 가능성 있음 → 데이터 간의 연관 관계에 대해 명확하게 정의
  

관점

• 데이터 관점 (What, Data) : 어떤 데이터들이 업무와 얽혀있는지
  
• 프로세스 관점 (How, Process) : 업무가 실제로 처리하고 있는 일이 무엇인지
  
• 데이터와 프로세스의 상관 관점 (Data vs Process, Intercation) : 프로세스 흐름에 따라 데이터가 어떤 영향을 받는지
  

중요 요소

• Things : 대상(Entity)
• Attribute : 속성
• Relationships : 관계

데이터 모델링의 특징

• 데이터 모델링은 추상화 해야 한다. → 추상화는 공통적인 특징을 찾고 간략하게 표현한다.
• 데이터 모델링은 단순화 해야 한다. → 복잡한 문제를 피하고 누구나 이해할 수 있게 표현한다.
• 데이터 모델링은 명확해야 한다. → 의미적 해석이 모호하지 않고 명확하게 해석 되어야 한다.

데이터 모델링의 종류

① 개념적 모델링(Conceptual Data Modeling)

• 고객의 비즈니스 프로세스를 분석하고 업무 전체에 대해서 업무 중심적이고 포괄적인 수준의 데이터 모델링을 정한다.
• 복잡하게 표현하지 않고 중요한 부분을 위주로 모델링하는 단계
• 업무적 관점에서 모델링하며 기술적인 용어는 가급적 사용하지 않는다.
• 추상화 수준이 가장 높은 수준의 모델
• 엔터티(Entity)와 속성(Attribute)을 도출하고 개념적 ERD(Entity Relationship fingar)를 작성한다.
  (엔터티란 실체, 객체라는 의미. 즉 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것)
  (사람, 장소, 물건, 사건, 개념 등의 명사에 해당, 업무상 관리가 필요한 관심사에 해당한다.

② 논리적 모델링(Logical Data Modeling)

• 개념적 모델링을 논리적 모델링으로 변환하는 작업으로 특정 데이터베이스 모델에 종속한다.
• 식별자를 도출하고 필요한 모든 관계, 속성 등을 정의한다.
• 정규화를 수행해서 데이터 모델의 독립성을 확보하고 재사용성을 높인다.
• 정규화의 기본 목표는 테이블 간에 중복된 데이터를 허용하지 않는다는 것이다.
• 중복된 데이터를 허용하지 않음으로써 무결성(Integrity)를 유지할 수 있으며, DB의 저장 용량 역시 줄일 수 있다.
• M:N 관계형 식별자 확정, 정규화, 무결성 정의 등을 수행
• 비즈니스 정보의 논리적 구조 및 구축을 파악

③ 물리적 모델링(Physical Modeling)

• 데이터베이스를 실제 구축하는 단계. 즉, 테이블, 인덱스, 함수 등을 생성하는 단계
• 성능, 보안, 가용성을 고려해서 데이터베이스를 구축
• 데이터베이스 이식

데이터 모델링의 관점

데이터 관점, 프로세스 관점, 데이터와 프로세스 관점

외부 스키마

• 사용자 관점, 업무상 관련 있는 데이터 접근(권한 설정), 사용자가 보는 개인적 DB 스키마
• 관련 데이터베이스의 일부를 표시. 뷰(View)를 표시
• 응용 프로그램이 접근하는 데이터베이스를 정의

개념 스키마

• 설계자 관점, 사용자 전체 관점을 통합한 전체 데이터베이스 구조
• 전체 데이터베이스 내의 규칙과 구조를 표현
• 통합 데이터베이스 구조

내부 스키마

• 개발자 관점, 데이터베이스의 물리적 저장 구조
• 데이터 저장 구조, 레코드 구조, 필드 정의, 인덱스 등을 의미
• 운영체제와 하드웨어에 종속적

논리적 독립성 : 개념 스키마가 변경되도 외부 스키마가 영향 받지 않음

물리적 독립성 : 내부 스키마가 변경되도 개념 스키마가 영향 받지 않음

ERD 표기법

1976년 피터첸(Peter Chen)에 의해 Entity-Relationship Model(E-R Model)이라는 표기법이 만들어졌다.

ERD 작성순서

1. 엔티티 그리기
2. 엔티티를 적절하게 배치하기
3. 엔티티 간 관계 설정하기
4. 관계명 기술하기(❉ 관계 명칭은 관계 표현에 있어 매우 중요한 부분에 해당됨)
5. 관계의 참여도 기술하기
6. 관계의 필수여부 기술하기

2. 엔터티

엔터티의 개념

엔터티 : 데이터베이스의 구성요소 중 독립적으로 식별 가능한 객체

엔터티 특징

• 유일한 식별자에 의해 식별 가능해야 한다. (EX. 성별 같은 식별자는 중복성이 커서 불가능함)
• 영속적으로 존재하는 인스턴스의 집합이어야한다.(한 개가 아니라 두 개 이상)
• 엔터티는 반드시 업무 프로세스에 의해 이용된다.
• 반드시 속성을 가져야 한다. 그리고 1개의 엔터티는 무조건 2개 이상의 속성을 가진다.
• 엔터티는 다른 엔터티와 최소한 1개 이상의 관계를 맺는다.
• 엔터티 명은 약어를 지양해야 한다.

** 빈출유형 **

• 엔터티를 그린다(혹은 도출한다).
• 엔터티를 적절하게 배치한다.
• 엔터티간 관계를 설정한다.
• 관계명을 기술한다.
• 관계의 참여도를 기술한다.
• 관계의 필수여부를 기술한다.

엔티티 명명 규칙

1. 가능하면 현업 업무에서 사용하는 용어 사용하기
2. 가능하면 약어 사용하지 않기
3. 단수 명사 사용
4. 모든 엔티티에서 유일한 이름 부여하기
5. 엔티티가 생성되는 의미대로 이름을 자연스럽게 부여하기

엔터티의 분류과 그에 따른 종류

유형, 무형에 따른 분류 → 개사유~ 계셔유~

• 유형 엔티티 : 모델링 대상이 물리적인 형태가 존재 ex) 상품, 회원
• 개념 엔티티 : 모델링 대상이 형태 없음 ex) 부서, 학과
• 사건 엔티티 : 모델링 대상이 행위로 인해 발생하는 것 ex) 주문, 이벤트 응모

발생 시점에 따른 분류 → 행기중 !

• 기본 엔티티ex) 상품, 회원, 부서
• : 모델링 대상이 업무에 대해 원래 존재하는 요소 → 독립적, 자식 엔티티 가질 수 있음
• 중심 엔티티ex) 주문, 매출, 계약
• : 모델링 대상의 업무 과정 중 하나, 기본 엔티티로부터 파생, 행위 엔티티 생성
• 행위 엔티티ex) 주문 내역, 이벤트 응모 이력 등
• : 2개 이상의 엔티티로부터 파생

인스턴스

인스턴스는 데이터베이스에 저장된 데이터 내용의 전체 집합을 의미한다.

• 스키마에 대한 실제 데이터, 테이블의 각 행ㅇㄹ 의미
• 시간에 따라 자주 변경이 이루어짐
• 인스턴스의 집합 : 데이터베이스 상태
• 주어진 시점에서 데이터베이스에 있는 데이터의 스냅 샷
  
  

3. 속성

속성이란 ?

• 어떤 사물 또는 개념에 없어서는 안 될 징표의 전부(사전적 정의)

• 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위(모델링 관점의 정의)
  
  ** 빈출개념 ***

• 한 개의 속성은 반드시 한 개의 속성값만을 가집니다.

• 한 개의 엔터티는 최소 2개 이상의 속성을 가집니다.

• 한 개의 엔터티는 최소 1개 이상의 다른 엔터티와의 관계를 가집니다.

• 한 개의 엔터티는 최소 2개 이상의 인스턴스 집합이어야 한다.

속성의 특징

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

속성의 분류

• 속성의 특징에 따라
  • 기본속성 : 업무상 필요한 데이터에 대해 정의
  • 설계속성 : 업무를 규칙화하기 위해 새로 만들거나 변형한 속성
  • 파생속성 : 다른 속성의 영향을 받아 발생. 주로 계산하는 값들이 이에 해당.

속성 명칭 부여할 때 유의할 점

1) 해당업무에서 사용하는 이름을 부여 한다.

2) 서술식 속성명은 사용하지 않는다.

3) 약어사용은 가급적 지양한다.

4) 유일성을 통해 구분할 수 있도록 하자.

함수적 종속성

• 한 속성의 값이 다른 속성의 값에 종속적인 관계를 갖는 특징을 말함
• 즉, 어떤 속성 A 의 값에 의해 다른 속성 B 도 유일하게 결정된다면, B 는 A 에 함수적으로로 종속됐다 하고,
• 이를 수식으로 나타내면 A → B 라고 표현함

1) 완전 함수적 종속

• 특정 컬럼이 기본키에 대해 완전히 종속될 때를 말함

• PK 를 구성하는 컬럼이 2 개 이상일 경우 PK 값 모두에 의한 종속관계를 나타낼 때 완전 함수 종속성 만족
  2) 부분 함수적 종속

• 기본키 전체가 아니라, 기본키 일부에 종속될 때를 말함

도메인

각각의 속성이 가질 수 있는 값의 범위

ex) 주문이라는 엔터티가 있을 때 단가라는 속성 값의 범위는 100 ~ 10000 사이의 실수 값이며 제품명이라는 속성은 길이가 20자리 이내의 문자열로 정의가 가능하다.

'범위' 가 언급되면 도메인에 대한 이야기입니다.

4. 관계

관계란 ?

ERD에서 관계를 연결할 때는 따로 구분하지 않고 단일화된 표기법으로 통일해서 사용한다.

관계의 종류

• 존재적 관계 : 존재 자체로 서로 연관성을 갖는 관계

ex) 부서와 사원의 관계는 존재에 의한 관계

• 행위적 관계 : 한 엔터티가 특정 행위나 이벤트를 일으킨 경

ex) 고객과 주문의 관계는 행위에 의한 관계 -> 고객이 제품을 '주문'한다는 개념이므로

두 개의 엔터티 사이에서 관계를 도출할 때 체크할 사항

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

관계차수
1:1 , 1:M , M:N 으로만 있음. 그 이외의 것은 틀린 말.

관계선택사양
필수관계인지 선택관계인지

UML의 클래스다이어그램에 의해 나뉘는 종류

• 연관 관계 : 필수적 관계(존재적 관계, 식별자 관계) - 항상 서로 이용(실선) : 멤버 변수로 선언
  
• 의존 관계 : 선택전 관계(비식별자 관계) - 상대 클래스 행위에 따라 이용(점선) : 행위 코드 오퍼레이션에서 파라미터로 사용
  

관계의 페어링

• 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것
• 관계란 페이링의 집합을 의미함

관계와 차수, 페어링 차이

• 학생과 강의 엔터티는 관계를 가짐
• 한 학생은 여러 강의를 수강할 수 있고, 한 강의도 여러 학생에게 수강될 수 있으므로 M 대 N 관계이며, 이 때 차수는 M:N 가 됨
• 인스턴스의 관계를 보면 "학생 A 가 강의 B 를 2023 년 1 학기에 수강했고 성적은 'A+'를 받았다"와 같은 특정한 페어링이 형성
• 이런식으로 관계의 차수는 하나의 엔터티와 다른 엔터티 간의 레코드 연결 방식을 나타내는 반면, 관계의 페어링은 두 엔터티 간의 특정 연결을 설명하고 추가 정보를 제공하는 용도로 사용.

5. 식별자

식별자란 ?

엔터티를 대표할 수 있는 유일성을 만족하는 속성

하나의 엔티티는 반드시 하나의 유일한 식별자가 존재해야 한다.

식별자의 특징

• 유일성 - 주식별자에 의해 엔터티내에 모든 인스턴스들이 유일하게 구분되어야 한다.
• 최소성 - 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
• 불변성 - 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
• 존재성 - 주식별자가 지정이 되면 반드시 값이 들어와야 한다.

식별자의 종류

◾대표성에 따라

• 주 식별자(Primary identifier) : 대표성을 만족하는 식별자로 다른 엔터티와 참조관계를 연결 할 수 있다.
• 보조 식별자(Alternate identifier) : 대표성을 가지지 못해 참조관계 연결 할 수 없다. 즉 유일성과 최소성만 만족하는 식별자

주식별자 도출기준

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

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

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

  • 주식별자로 선정하기 위한 속성이 복합으로 구성되어 주식별자가 될 수 있을 때 가능하면 주식별자 선정하기 위한 속성의 수가 많지 않도록 해야 한다.
  • 식별자의 속성의 개수가 많을 때(일반적으로 7~8개 이상)는 새로운 인조식별자를 생성하여 데이터 모델을 구성하는 것이 데이터 모델을 한층 더 단순하게 하고, 애플리케이션을 개발할 때 조건절을 단순하게 할 수 있는 방법이 될 수 있다.

• 해당 업무에서 자주 이용되는 속성

  ◾ 생성 여부에 따라

• 내부 식별자 : 엔터티 내부에서 스스로 만들어지는 식별자 즉 자연스럽게 존재하는 식별자

• 외부 식별자(Foreign identifier) : 다른 엔터티와의 관계를 통해 생성 되는 식별자

→ 데이터베이스 생성 시 FK역할을 함

◾ 속성 수에 따라

• 단일 식별자(Single identifier) : 하나의 속성을 가진 식별자

• 복합 식별자(Composit identifier) : 둘 이상의 여러 속성으로 구성된 식별자

  ◾ 대체여부에 따라

• 본질 식별자 : 업무에 의해 만들어지며 ,대체될 수 없는 식별자

• 인조 식별자 : 인위적으로 만들어지는 대체가능한 식별자

식별자의 특성과 특정 여부에 따른 분류

대표성 여부

• 주 식별자(PK) - # 으로 표현 : 유일성, 최소성, 불변성, 존재성을 모두 만족하는 식별자 → PK는 여러 속성이 존재 할 수 있으나, 여러 속성이 존재 할 경우 나머지 일반 속성들이 해당 PK들 속성들에 대해 함수적 종속성을 띄어야함 → 그렇지 않으면 2차 정규화하여 부분 종속에 해당하는 속성들만 따로 추가 엔티티를 생성한다.
  • 주 식별자 도출 기준
    • 해당 업무에서 자주 이용되는 속성
    • 명칭, 내역 등의 이름은 피함
    • 속성 수를 최대한 적게 구성
    • 자주 변하지 않는 값
• 보조 식별자 : 인스턴스 식별은 가능하나 엔티티를 대표하는 식별자는 아님 → 즉 다른 엔티티와의 참조 관계로 연결되지 않는다. ex) 회원 엔티티에서 #회원번호 *회원명 *아이디 → 에서 아이디는 다른 인스턴스랑 중복될 수 없기 때문에 해당 엔티티에서 인스턴스를 구분짓게 할 수 있는 식별자이나 → 이게 엔티티를 대표하지는 못 함
  

스스로 생성 되었는가에 대한 여부

• 내부 식별자 : 다른 엔티티 참조 없이 해당 엔티티 내부에서 스스로 생성된 식별자
  
• 외부 식별자 : 다른 엔티티에서 온 식별자 - 다른 엔티티와 연결고리 역할 → 만약 부모 엔티티의 FK를 받아서 이를 주식별자로 사용하면 → 해당 자식 엔티티의 PK는 SQL 조인에서 반드시 사용되고 WHERE 절에서 사용 가능성이 높음
  

단일 속성인지에 대한 여부(주 식별자 구성이 여러 속성인가)

• 단일 식별자 : 주 식별자가 1개의 속성으로 구성
• 복합 식별자 : 주 식별자가 2개 이상의 속성으로 구성 → 주 식별자가 2개 이상이면 해당 속성들의 우선순위를 잘 매겨서 잘 복합시킨 후 일반 속성들에게 종속시켜야 주 식별자로서 기능을 다 하게 된다.
  

대체되었는지 기존에 있는지에 대한 분류

• 원조(본질) 식별자 : 업무에 의해 만들어지는 식별자, 가공되지 않은 원래 식별자
• 인조(대리) 식별자 : 인위적으로 만들어지는 식별자, 주 식별자가 복잡할 때 이를 통합 → ex) 주문번호 - 대표적 인조, 대리 식별자 → 기존 : 사번+주문일자+순번을 주 식별자로 두고 주문을 처리하다가 → 이를 “주문번호” 라는 단일 속성의 주 식별자로 만들면 이게 인조, 대리 식별자가 됨
  

단점) 1. 중복 데이터 발생 가능성 → 데이터 품ㅈㄹ 저하

 2. 불필요한 인덱스 생성 → 저장공간 낭비 및 DML 성능 저하

비식별자

 비식별자는 '약한 연결관계이고, 부모엔터티와 자식엔터티 간에 상호작용이 의무가 아닌 선택사항이다.

비식별자의 특징

• 연관성이 약하다
• 자식테이블에서 독립적인 PK구조 , 부모와 자식 사이가 종속적인게 아니라 독립적이므로 약한 연결관계
• 복잡성이 증가되는 것을 방지
• 문제풀이
  Q. 프로젝트를 전개할 때는 식별자와 비식별자를 선택하여 연결해야 하는 높은 수준의 데이터모델링 기술이 필요하다. 다음 중 비식별자관계를 선택하는 기준으로 부적절한 것은?

  1. 관계의 강약을 분석하여 상호간에 연관성이 약할 경우 비식별자관계를 고려한다.

  2. 자식테이블에서 독립적인 PK(Primary Key)의 구조를 가지기 원할 때 비식별자관계를 고려한다.

  3. 모든 관계가 식별자 관계로 연결되면 SQL Where절에서 비교하는 항목이 증가되어 조인에 참여하는 테이블에 따라 SQL문장이 길어져 SQL문의 복잡성이 증가되는 것을 방지하기 위해 비식별자관계를 고려한다.

  4. 부모엔터티의 주식별자를 자식엔터티에서 받아 손자엔터티까지 계속 흘려보내기 위해 비식별자관계를 고려한다.

     자, 문제가 좀 길죠? 이 문제를 토대로 비식별자의 특징을 알기 위함입니다.

  • 1번부터 봅시다. '연관성이 약할 경우' 라는 말이 나왔네요? 그럼 비식별자입니다.

  • 2번 봅시다. 자식테이블에서 독립적인 PK구조 라는 말이 나왔습니다. 부모와 자식 사이가 종속적인게 아니라 독립적이므로 약한 연결관계입니다. 비식별자입니다.

  • 3번 봅시다. 제가 설명했던 특징은 아니지만, 여기서 중요한 키워드는 '복잡성이 증가되는 것을 방지' 입니다. 이것 역시 비식별자의 중요한 특징입니다. 외웁시다.

  • 4번은 부모엔터티의 주식별자 -> 자식 -> 손자엔터티와 같은 유대관계를 보이고 있습니다. 이런 연결관계는 비식별자보단 상대적으로 강한 식별자관계의 특징에 해당합니다.

    따라서 답은 4번입니다.

식별자 관계 vs 비식별자 관계

식별자 관계

→ 트랜잭션에 의한 관계 - 동시에 커밋, 롤백 - 하나의 커밋 단위로 엔티티들이 묶임

: 부모 엔티티의 식별자 속성이 자식 엔티티의 주 식별자가 되는 관계

• 강한 연결 관계
• 실선(항시 연결)
• 부모-자식 관계가 항시 유지
• SQL문의 조인을 최소화 해줌
• 데이터의 생명주기가 같은 경우

비식별자 관계

: 부모 엔티티의 식별자 속성이 자식 엔티티의 일반 속성이 되는 관계

• 약한 연결 관계
• 점선(선택적 연결)
• 부모-자식 관계가 유지 안 될 수 있음 → 일반 속성 값은 NULL이 들어갈 수 있기 때문에 부모 엔티티의 식별자 속성에 값이 없을 때 자식 엔티티의 속성 값(인스턴스)이 생성 가능하다.