데이터 모델링

데이터 모델링은 현실 세계를 단순화하여 표현하는 기법

데이터 모델링 특징(추∙단∙명)

• 추상화 : 현실세계, 개념을 일정한 형식으로 간략하게 표현
• 단순화 : 현실세계를 정해진 표기법으로 단순하고 쉽게 표현, 핵심에 집중 + 불필요 제거
• 명확화 : 불분명함(애매모호함)을 제거하고 정확하게 현상을 기술

특징

• 업무 설명, 분석, 형상화 목적도 있음
• 개발 및 데이터 관리에도 사용

데이터 모델링의 3가지 관점

• 데이터 관점(What, Data)
  • 업무와 데이터 및 데이터 사이의 관계를 모델링
• 프로세스 관점(How, Process)
  • 업무가 실제로 하고 있는 일, 해야 하는 일 모델링
• 데이터와 프로세스의 상관 관점(Data VS Process, Intercation)
  • 데이터에 대한 업무 처리 방식의 영향을 모델링

데이터 모델링의 중요성과 유의성

① 중요성 : 파급효과, 간결한 표현, 데이터 품질 유지
② 유의점
- 중복 : 같은 데이터가 엔티티에 중복 저장되면 안된다.
- 비유연성 : 애플리케이션의 사소한 변경에도 데이터 모델이 수시로 변경되면 안된다.
-> 데이터 모델과 프로세스 분리해서 유연성 높여야한다.
- 비일관성 : 중복이 없는 경우에도 비일관성 발생 가능성 있음
-> 데이터 간의 연관 관계에 대해 명확하게 정의

데이터 모델링의 3단계(개∙논∙물)

• 개념적 모델링 : ERD 도출, 업무중심적이고 포괄적(추상화 레벨 가장 높음)
• 논리적 모델링 : 테이블 도출, (Key, 속성, 관계)를 표현, 재사용성↑, 정규화 수행
• 물리적 모델링 : DB 구축, 물리적 성격, 개념적 보다 구체적

데이터의 독립성

데이터의 구조가 변경되어도 응용 프로그램이 변경될 필요가 없음
필요성

• 유지보수 비용
• 데이터 복잡도
• 데이터 중복성
• 요구사항 대응

테이터 스키마 단계에 따른 독립성(외∙개∙내 -> 논리적, 물리적)

스키마 : 테이블이 어떠한 구성으로 되어있는지, 어떤 정보를 가지고 있는지에 대한 기본적인 테이블의 구조를 정의
USER

• 외부 스키마 : 사용자 관점, View 관점, 개개인의 사용자나 프로그래머
• 개념 스키마 : 모든(여러X) 사용자 관점 통합, 조직 전체 DB, 통합 관점
• 내부 스키마 : 물리적인 저장 구조를 나타내는 단계 -> 저장 구조, 칼럼, 인덱스 정의
  DB
• 논리적 독립성 : 개념 스키마가 변경 되어도 외부 스키마는 영향 X (외부 - 개념)
• 물리적 독립성 : 내부 스키마가 변경 되어도 개념/외부 스키마는 영향 X(외부,개념 - 내부)

ERD 작성 순서(도∙배∙관∙명∙참∙필)

1. 엔티티 도출
2. 엔티티 배치
3. 엔티티 관계 설정
4. 관계명 기입
5. 관계 참여도 기입
6. 관계 필수/선택 여부 기입
   
   

엔티티

업무에서 쓰이는 데이터들을 용도별로 분류한 데이터의 그룹
엔티티의 특징

• 업무에서 쓰이는 정보
• 식별자가 있어야함
• 2개 이상의 인스턴스를 가져야함
• 반드시 속성을 가져야함 -> 이 때 하나의 인스턴스는 2개 이상의 속성을 가짐 -> 즉, 하나의 엔티티는 2개 이상의 속성을 가짐
• 다른 엔티티와 1개 이상의 관계

엔티티의 분류

유형∙무형에 따른 분류(개사유~ 계셔유~)

• 유형 엔티티 : 물리적인 형태 O ex) 상품, 회원, 사원, 물품, 강사
• 개념 엔티티 : 물리적인 형태 X ex) 부서, 학과, 조직, 보험 상품
• 사건 엔티티 : 행위로 읺한 발생 ex) 주문, 이벤트 응모, 청구, 미납

  발생시점에 따른 분류(행기중)

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

엔티티의 명명

• 현업 업무에서 사용하는 용어
• 약어 X, 영어 대문자로 표시
• 단순 명사로 표현, 띄어쓰기 X
• 의미상 중복 X(주문, 결제 엔티티는 중복 O)
• 명확하게 표현

속성

엔티티의 특징을 나타내는 최소의 데이터 단위

특징

• 더 이상 쪼개지지 않는 레벨
• 업무에서 필요로 하는 항목
• 엔티티를 설명, 인스턴스를 설명
• 하나의 속성은 하나의 속성값만 가짐 -> 여러 개 가지면 1차 정규화
• 일반 속성은 정해진 주식별자에 함수적 종속성을 가져야 한다. -> 완전 함수적 종속이 아닌 부분 종속이면 2차 정규화 해준다.

속성 분류

특성에 따른 분류

• 기본 속성 : 업무 프로세스(기본 틀) 분석했더니 바로 정의 가능한 속성
• 설계 속성(인스턴스에 유니크함을 부여하는 속성) : 업무엔 없으니ㅏ, 모델링 하다보니 고유함 보전하기 위해 필요해져서 만들어짐 ex) 학번, 사번
• 파생 속성(성능, 편의 위해 서로 만든 엔티티의 속성) : 데이터를 조회할 때 빠른 성능 낼 수 있도록 원래 속성값을 계산하여 저장할 수 있도록 하는 속성 ex) 평균, 재고 -> 데이터 정합성 고려 & 가급적 적게 정의

구성 방식에 따른 분류

• PK 속성 : 인스턴스의 유니크함을 부여하는 속성, 일반 속성들의 종속성을 가진 키
  • (기본키, 주식별자 키) #으로 표현 ex) 학번, 사번
• FK 속성 : 다른 엔티티에서 가져온 속성(외래키), 다른 엔티티와의 관계를 맺게 해줌
  -> 주식별자에 있는 속성이 FK가 될 수 있음 ex) #사원번호(FK), g
• 일반 속성 : PK, FK를 제외한 나머지 속성

속성의 분해 가능 여부에 따른 분류

• 단일 속성 : 속성이 하나의 의미로 구성
• 복합 속성 : 여러 개의 의미로 구성(주소 = 시+구+동)
• 다중값 속성 : 속성이 여러 개 값 가짐 -> 1차 정규화 OR 별도 엔티티 생성

속성이 만들어낸 데이터 모델의 개념

도메인

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

용어 사전

: 속성의 이름을 정확, 직관적으로 부여하기 위한 용어 사전

시스템 카탈로그

: 시스템 자체에 관련있는 데이터를 가진 DB
: 시스템 테이블로 구성 & SQL로 조회 가능
: 여기 저장된 데이터 = 메타 데이터, SELECT만 가능, INSERT, UPDATE 등 불가능

관계

엔티티와 엔티티 사이에 속성끼리의 연결에 의해 만들어지는 상관 관계

종류

• 존재 관계 : 모델링 된 엔티티들이 존재로서 관계를 가짐
• 행위 관계 : 모델링 된 엔티티들이 행위에 의해 관계를 가짐

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

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

관계 표기 방법(ERD)에 따른 특성 분류

• 관계명 : 관계 이름은 시작 엔티티 - 능동적/끝 엔티티 -수동적 동사 사용
• 관계 차수 : 각 엔티티 끼리의 관계에 참여하는 속성의 수 1:1, 1:M, M:N 형식으로 구분
• 관계 선택 사양 : 필수적 관계(엔티티끼리 항상 관계), 선택적 관계(행위에 의해 관계 여부가 성립)

관계 체크 사항(두 엔티티 사이 관계 정의 시 유의할 사항)

• 두 엔티티 사이 관심있는 연관 규칙이 존재하는가
• 두 엔티티 사이 정보의 조합이 발생하는가
• 업무 기술 시, 장표의 관계 연결을 가능하게하는 동사가 있는가
• 업무 기술 시, 장표의 관계 연결을 가능하게하는 규칙이 서술 되어 있는가

식별자

각각의 인스턴스를 구분 가능하게 만들어주는 대표 속성

주식별자

PK에 해당하는 속성 -> PK는 여러 개 존재 할 수 있음

• 유일성 : 해당 속성이 인스턴스를 유일하게 식별할 수 있는 성질을 가졌는지
• 최소성 : 최소한의 속성들로만 유일성을 보장하게 하는지
• 불변성 : 속성 값이 변하지 않아야함
• 존재성 : 속성값은 NULL이 될 수 없음

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

대표성 여부

• 주식별자(PK) - #으로 표현
  : 유일성, 최소성, 불변성, 존재성을 모두 만족하는 식별자
• 보조식별자
  : 인스턴스 식별은 가능하나 엔티티를 대표하는 식별자는 아님
  -> 즉, 다른 엔티티와의 참조 관계로 연결되지 않는다.

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

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

단일 속성의 여부(주식별자 구성이 여러 속성인가)

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

대체여부

• 원조(본질)식별자
  : 업무에 의해 만들어지는 식별자, 가공되지 않은 원래 식별자
• 인조(대리)식별자
  : 인위적으로 만들어지는 식별자, 주식별자가 복잡할 때 이를 통합
  

식별자(강한 연결관계) VS 비식별자(약한 연결관계)

• 식별자 관계(트랜잭션에 의해 관계∙동시에 커밋, 롤백-하나의 커밋 단위로 엔티티들이 묶임
  : 부모 엔티티의 식별자 속성이 자식 엔티티의 주식별자가 되는 관계
  : SQL 문의 조인을 최소화 해줌
• 비식별자 관계
  : 부모 엔티티의 식별자 속성이 자식 엔티티의 일반 속성이 되는 관계

KEY의 종류

논리 모델링에서 식별자가 물리 모델링에서는 Key가 되는데 이를 Key의 특징에 따라 다음과 같이 분류
① 기본키(PK)

• 엔티티를 대표할 수 있는 키
  ② 후보키(Candidate Key)
• 유일성과 최소성을 만족하는 키
• 결국 후보키들 중 하나가 기본키가 되고, 나머지를 대체키라고 부름
  ③ 슈퍼키(Super Key)
• 유일성은 만족하지만 최소성은 만족하지 않는 키
  ex) 학생 테이블에서 학번으로만 PK를 구성해도 되는데, (학번+이름)으로 구성한다면 이는 슈퍼키
  ④ 대체키(AlternateKey)
• 여러 후보키 중 기본키가 아닌 키
  ⑤ 외래키(FK)
• 다른 테이블의 기본키를 참조하는 키
• 참조 테입를은 하나 또는 여러 개 가능

참고문헌

https://www.youtube.com/watch?v=xmkaOqbTQRE