[SQLD 암기] 데이터 모델링의 이해

* 모델링의 특징

 - 현실세계를 일정한 형식에 맞추어 표현하는 추상화 의미를 가짐 (추상화)

 - 시스템 구현을 포함한 업무 분석 및 업무형상화를 하는 목적

 - 복잡한 현실을 제한된 언어나 표기법으로 이해하기 쉽게 하는 단순화 의미를 가짐 (단순화)

 - 애매모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술 (명확화)

 

* 모델링 세가지 관점

 - 데이터 관점 : 업무가 어떤 데이터와 관련 있는지, 데이터 간 관계는 무엇인지에 대해 모델링

 - 프로세스 관점 : 업무가 실제 하는 일이 무엇이고 무엇을 해야 하는지 모델링하는 방법

 - 데이터와 프로세스의 상관 관점 : 업무가 처리하는 일의 방법에 따라 데이터가 어떻게 영향 받는지 모델링하는 방법

 

* 데이터 모델링이란

 - 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법

 - 현실세계 데이터에 대해 약속된 표기법에 의해 표현하는 과정

 - 데이터를 구축하기 위한 분석/설계의 과정

 

* 데이터 모델링

 - 개념적 데이터 모델링 : 추상화 수준이 높고, 업무 중심, 포괄적 수준의 모델링, 전사적 데이터모델링, EA 수립 시 사용

 - 논리적 데이터 모델링 : 시스템 구축하려는 업무에 대해 KEY, 속성, 관계를 정확하게 표현, 재사용성 높음

 - 물리적 데이터 모델링 : 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적 성격을 고려하여 설계

 

* 개념적 데이터 모델링

 - 엔티티 – 관계 다이어그램 생성 (조직과 사용자에게 어떤 데이터가 중요한지 나타내기 위해 사용)

 - 전사적 데이터모델이라고 불림

 - 데이터 요구를 공식화 (데이터 요구사항 발견, 어떻게 변형되어야 하는지 이해)

 

* 논리적 데이터 모델링

 - 정규화

 - key, 속성, 관계를 정확히 표현, 재사용성 높음

 - 일관성 확보, 중복 제거, 속성 배치, 신뢰성 있는 데이터 구조

 - 상세화 : 식별자 확정, 정규화, M:M관계 해소, 참조무결성 규칙 정의

 

* 데이터 모델링의 주요 이유

 - 업무정보의 기초가 되는 정보를 일정한 표기법으로 표기하여 정보시스템 구축 대상 업무 내용을 정확히 분석

 - 분석된 모델로 데이터베이스를 생성하여 개발 및 데이터 관리에 사용하기 위한 것

 - 데이터 모델링 자체로서 업무를 설명하고 분석하는 부분에 의미를 가짐

 

* 데이터 모델링 유의점

 - 중복 : 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 함

 - 비유연성 : 데이터의 정의를 데이터의 사용 프로세스와 분리하여

                 데이터 모델링 또는 프로세스의 작은 변화에 영향을 받지 않게 함

 - 비일관성 : 데이터 간의 상호 연관관계를 명확하게 정의하여 일관성 있게 데이터가 유지되도록 함

 

* 데이터베이스 스키마 구조 3단계

 - 외부스키마 : 뷰 단계 여러 개의 사용자 관점으로 구성, 개개 사용자 단계로서 개개 사용자가 보는 개인적 DB스키마

 - 개념스키마 : 개념단계 하나의 개념적 스키마로 구성, 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것

 - 내부스키마 : 내부단계, 내부스키마로 구성, DB가 물리적으로 저장된 형식

 

* 논리적 독립성

 - 개념 스키마가 변경돼도 외부 스키마에는 영향을 미치지 않도록 지원

 - 논리적 구조가 변경돼도 응용 프로그램에 영향 없음

 - 사용자 특성에 맞는 변경 가능, 통합 구조 변경 가능

 

* 물리적 독립성

 - 내부 스키마가 변경돼도 외부/개념 스키마는 영향 받지 않도록 지원

 - 저장장치의 구조 변경은 응용 프로그램과 개념 스키마에 영향 없음

 - 물리적 구조 영향 없이 개념 구조 변경 가능, 개념 구조 영향 없이 물리적 구조 변경 가능

 

* 사상

  외부적/개념적 사상 (논리적 사상) : 외부적 뷰와 개념적 뷰의 상호 관련성을 정의

  개념적/내부적 사상 (물리적 사상) : 개념적 뷰와 저장된 데이터베이스의 상호 관련성 정의

 

* ERD

 - 1976년 피터챈에 의해 표기법 만들어짐

 - 일반적으로 ERD 작성 방법은 엔티티 도출 -> 엔티티 배치 -> 관계 설정 -> 관계명 기술 흐름

 - 관계의 명칭은 관계 표현에 있어서 매우 중요한 부분에 해당

 - 가장 중요한 엔티티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치

 

* 좋은 데이터 모델의 요소

 - 완전성 : 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의됨

 - 중복배제 : 하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록

 - 업무규칙 : 데이터 모델링 과정에서 도출되고 규명되는 많은 업무규칙을 데이터 모델에 표현, 모든 사용자가 공유

 - 데이터 재사용 : 재사용성을 향상시키고자 하면 데이터의 통합성과 독립성 고려

 - 의사소통 : 해당 정보 시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무규칙을 받아드리고 활용

 - 통합성 : 동일 성격의 데이터를 한 번만 정의하기 위해 여러 업무에서 사용하기 용이하게 구조 정의

 

* 엔티티의 특징

 - 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 함

 - 유일한 식별자에 의해 식별이 가능해야 함

 - 영속적으로 존재하는 두 개 이상의 인스턴스의 집합이어야 함

 - 업무 프로세스에 의해 반드시 이용되어야 함

 - 반드시 속성이 있어야 함

 - 다른 엔티티와 최소 한 개 이상의 관계가 있어야 함, 공통코드나 통계성 엔티티의 경우 생략 가능

 

* 발생시점에 따른 엔티티 분류

 - 기본 엔티티 : 업무에 원래 존재하는 정보, 관계로 생성되지 않고 독립적으로 생성, 다른 엔티티로부터 상속 받지 않음

 - 중심 엔티티 : 기본 엔티티로부터 발생, 업무 중심 역할, 데이터 양 많음, 관계를 통해 많은 행위 엔티티를 생성

 - 행위 엔티티 : 두 개 이상의 부모 엔티티로부터 발생, 자주 바뀌거나 데이터 양 증가,

                     상세설계나 상관 모델링 시 도출될 수 있음

 

* 유무형에 따른 엔티티 분류

 - 유형 엔티티 : 물리적 형태가 있음, 안정적이고 지속적으로 활용, 업무로부터 엔티티 구분이 용이

 - 개념 엔티티 : 물리적인 형태가 없음, 관리해야 할 개념적 정보로 구분

 - 사건 엔티티 : 업무 수행에 따라 발생되는 엔티티, 발생량이 많고 각종 통계 자료에 이용

 

* 엔티티가 스스로 생성될 수 있는 지의 여부로 독립 엔티티, 의존 엔티티 구분

 

* 엔티티 명명 기준

 - 가능하면 현업 업무에서 사용하는 용어 사용

 - 가능하면 약어를 사용하지 않음

 - 단수명사 사용

 - 모든 엔티티를 통틀어서 유일하게 이름이 부여되어야 함

 - 엔티티 생성 의미대로 이름을 부여

 

* 속성 

  업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

  업무에서 필요로 함, 의미상 더 이상 분리되지 않음, 엔티티를 설명함, 인스턴스의 구성요소

 

* 속성 특징

 - 반드시 해당 업무에서 필요하고 관리하고자 하는 정보

 - 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속을 가짐

 - 하나의 속성에는 한 개의 값만 가짐, 다중 값일 경우 별도의 엔티티를 이용하여 분리

 

* 엔티티, 인스턴스, 속성, 속성값 관계

 - 한 개의 엔티티는 두 개 이상의 인스턴스의 집합 (엔티티에는 두 개 이상의 인스턴스가 존재)

 - 한 개의 엔티티는 두 개 이상의 속성을 가짐

 - 한 개의 속성은 한 개의 속성 값만 가짐

 - 엔티티 내의 하나의 인스턴스는 각 속성들에 대해 한 개의 속성 값만 가질 수 있음

 - 속성도 집합임

 - 분석 단계 : 엔티티 내 존재하는 여러 인스턴스가 갖는 동일한 성격이 무엇인지 파악하고 이름 부여

 - 인스턴스는 속성의 집합

 - 속성은 하나의 인스턴스에만 속할 수 있음

 

* 속성의 특성에 따른 분류

 - 기본 속성 : 업무분석을 통해 바로 정의한 속성, 이미 업무상 코드로 정의한 속성이면 기본 속성 아님

 - 설계 속성 : 업무상 존재하지 않지만 설계하면서 도출한 속성,

                  모델링과 업무 규칙화를 위해 속성을 만들거나 변형하여 정의

 - 파생 속성 : 다른 속성으로부터 계산이나 변형되어 생성되는 속성,

                  정합성 유지를 위해 유의할 점이 많고 적게 정의하는 것이 좋음

 

* 엔티티 구성 방식에 따른 속성 분류

 - PK 속성 : 엔티티를 식별할 수 있는 속성

 - FK 속성 : 다른 엔티티와의 관계에서 포함된 속성

 - 일반 속성 : PK, FK에 속하지 않는 속성

 

* 속성의 쪼갤 수 있는지에 따라 분류

 - 복합 속성 : 여러 세부 속성들로 구성

 - 단순 속성 : 더 이상 다른 속성들로 나눌 수 없는 단순한 속성

 

속성은 하나의 값을 갖지만 그 안에 동일한 성질 여러 값이 나타남 – 다중 값, 한 개의 값만 가짐 – 단일 값

 

* 도메인

 속성이 가질 수 있는 값의 범위, 엔티티 내에서 속성에 대한 데이터 타입과 크기, 제약사항을 지정

 

* 속성 명칭 부여

 - 해당 업무에서 사용하는 이름을 부여

 - 서술식 속성명을 사용하지 않음

 - 약어사용은 가급적 제한

 - 전체 데이터모델에서 유일성 확보하는 것이 좋음

 

* ERD

 관계는 존재에 의한 관계와 행위에 의한 관계로 구분

 ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법 사용

 

* UML

 클래스 다이어그램의 관계 중 연관관계와 의존관계가 있고 실선과 점선의 표기로 다르게 표현

 

* 관계의 표기법

 - 관계명 : 관계의 이름

 - 관계 차수 : 1:1, 1:M, M:N

 - 관계 선택사양 : 필수관계, 선택관계

 

* 관계의 분류

 - 연관 관계 : 항상 이용하는 관계, 존재적 관계, 실선, 소스코드에서 멤버변수로 선언하여 사용

 - 의존 관계 : 상대방 클래스의 행위에 의해 관계가 형성될 때 구분하여 표현, 점선, 오퍼레이션에서 파라미터로 사용

 - ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않지만 클래스 다이어그램에서는 구분함

 

* 관계 선택 사양

 - 필수 참여 : 참여하는 모든 참여자가 반드시 관계를 가짐

 - 선택 참여 : 물리속성에서 외부키로 연결되는 경우 NULL을 허용할 수 있는 항목

 

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

 - 두 개의 엔티티 사이에 관심 있는 연관 규칙이 존재하는 지

 - 두 개의 엔티티 사이에 정보의 조합이 발생되는지

 - 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는지

 - 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는지

 

* 식별자 분류

 - 대표성의 여부 / 주식별자 : 엔티티 내에서 각 어커런스를 구분 가능 구분자, 타 엔티티와 참조관계를 연결함

                      / 보조식별자 : 엔티티 내에서 각 어커런스 구분 가능 구분자, 대표성을 갖지 못해 참조관계 연결 불가

 - 스스로 생성 여부 / 내부식별자 : 엔티티 내부에서 스스로 만들어지는 식별자

                          / 외부식별자 : 타 엔티티와의 관계를 통해 타 엔티티로부터 받아오는 식별자

 - 속성의 수 / 단일 식별자 : 하나의 속성으로 구성된 식별자

                / 복합 식별자 : 둘 이상의 속성으로 구성된 식별자

 - 대체 여부 / 본질 식별자 : 업무에 의해 만들어지는 식별자

                / 인조 식별자 : 업무적으로 만들어지지는 않지만 원조식별자가 복잡해서 인위적으로 만든 식별자

 

* 주식별자 지정 시 고려할 사항

 - 주식별자에 의해 엔티티 내 모든 인스턴스들이 유일하게 구분되어야 함

 - 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함

 - 지정된 주식별자의 값은 자주 변하지 않는 것이어야 함

 - 주식별자가 지정되면 반드시 값이 있어야 함

 

* 주식별자 도출 기준

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

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

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

 

* 주식별자 특징

 - 유일성 : 주식별자에 의해 엔티티 내에 모든 인스턴스들을 유일하게 구분

 - 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함

 - 불변성 : 주식별자가 한 번 특정 엔티티에 지정되면 그 식별자의 값은 변하지 않아야 함

 - 존재성 : 주식별자가 지정되면 반드시 데이터 값이 존재해야 함, NULL 안됨

 

* 식별자 관계

 - 부모로부터 받은 식별자를 자식 엔티티의 주식별자로 이용할 때 NULL 있으면 안됨

 - 부모로부터 받은 속성을 자식 엔티티가 모두 사용하고 주식별자로 사용하면 1:1 관계

   부모로부터 받은 속성과 다른 부모 엔티티에서 받은 속성을 포함하여

   스스로 갖는 속성으로 주식별자를 구성하면 1:M 관계

 - 강한 연결관계, 실선 표현

 - 반드시 부모 엔티티 종속, 자식 주식별자 구성에 부모 주식별자 포함,

   상속받은 주식별자 속성을 타 엔티티에 이전 필요

 

* 비식별자 관계

 - 자식 엔티티에서 받은 속성이 필수가 아니어도 무방해서 부모 없는 자식이 생성될 수 있는 경우

 - 엔티티 별로 데이터 생명 주기를 다르게 관리할 경우, 자식은 남기고 부모 엔티티가 먼저 소멸될 경우

 - 여러 엔티티가 하나의 엔티티로 통합되어 표현됐는데, 각 엔티티가 별도의 관계를 가질 때

 - 약한 연결관계 표현, 점선 표현

 

* 비식별자 관계를 선택하는 기준

 - 관계의 강약을 분석하여 상호간 연관성이 약할 경우

 - 자식테이블에서 독립적인 PK의 구조를 가지기를 원할 때 비식별자 관계

 - 모든 관계가 식별자 관계로 연결되면 SQL WHERE 절에서 비교하는 항목이 증가, SQL 문 복잡성 증가 방지를 위함

 - 부모 엔티티에 참조 값이 없어도 자식 엔티티의 인스턴스가 생성될 수 있는 경우

 - 여러 개의 엔티티를 하나로 통합하면서 각 엔티티가 갖던 여러 개별 관계가 통합되는 경우

 - 자식쪽 엔티티의 주식별자를 부모 엔티티와는 별도로 생성하는 것이 유리하다고 판단할 경우