데이터 모델링의 이해
모델링(Modeling)이란?
⤷ 다양한 현상을 추상화, 단순화하여 일정한 표기법에 의해 표현
⤷ 모델이란 현실 세계의 추상화된 반영
모델링 특징
- 추상화 : 일정한 형식에 맞춰 표현
- 단순화 : 제한된 표기법이나 언어로 표현
- 명확화(정확화) : 애매모호함을 제거해 이해 쉽게 표현
모델링 목적
⤷ 단순히 DataBase나 시스템을 구축하기 위한 것이 아닌 업무 설명, 분석, 형상화 목적
⤷ 분석된 모델로 실제 DataBase 생성하며 개발 및 데이터 관리에도 사용됨
모델링 관점
- 데이터 관점(What, Data) : 업무와 데이터 및 데이터 사이 관계를 모델링
- 프로세스 관점(How, Process) : 업무가 실제로 하고 있는 일과 해야 하는 일 모델링
- 데이터와 프로세스의 상관 관점(Data vs Process, Interaction) : 데이터에 대한 업무 처리 방식 영향을 모델링
데이터 모델링의 중요성
⤷ 파급효과
⤷ 간결한 표현
⤷ 데이터 품질 유지
데이터 모델링 주요 요소
⤷ 엔터티(Entities)
⤷ 속성(Attributes)
⤷ 관계(Relationships)
데이터 모델링의 유의점
- 중복(Duplication) : 같은 시간 같은 데이터 제공함, 여러 장소에 같은 정보를 저장하면 안 됨
- 비유연성(Inflexibility) : 사소한 업무 변화에 데이터 모델이 수시로 변경되면 안됨, 데이터 정의를 사용함
- 비일관성(Inconsistency) : 데이터 간 상호 연관 관계에 대해 명확히 정의해야 함
데이터 모델링의 3단계
- 개념적(계획, 분석) : EDR 도출, 업무 중심, 포괄적 수준 모델링
⤷ 전사적으로 수행, 추상화 레벨이 가장 높음
- 논리적(분석) : 테이블 도출, (key, 속성, 관계) 표현, 재사용성, 정규화 수행
⤷ 논리 데이터 모델을 대상으로 정규화 하는 것
- 물리적(설계) : DB 구축, 물리적 성격, 개념적보다 구체적
⤷ 성능 및 가용성 등 물리적 요소를 고려하는 단계
스키마(Schema)란?
⤷ 테이블이 어떤 구성으로 되어있는지 또는 어떤 정보를 가지고 있는지에 대한 기본적인 테이블 구조를 정의한 것
데이터 스키마의 구조
USER
⤷ 외부 스키마 : 각(여러) 사용자가 보는 스키마 정의 및 표현
⤷ 개념 스키마 : 모든(여러x) 사용자가 보는 데이터 정의 및 표현과 관계를 정의
⤷ 내부 스키마 : 물리적인 저장 구조를 나타냄, 저장 구조 및 칼럼, 인덱스 정의
DB
⤷ 논리적 독립성 : 개념 스키마가 변경되어도 외부 스키마에는 영향 x (외부 - 개념)
⤷ 물리적 독립성 : 내부 스키마가 변경되어도 개념, 외부 스키마에는 영향 x (개념, 외부 - 내부)
데이터 독립성의 필요성
⤷ 데이터 중복성과 복잡도가 증가 → 요구사항 대응 저하, 유지 보수 비용 증가
ERD 작성 순서
1. 엔터티 도출
2. 엔터티 배치
3. 엔터티 관계 설정
4. 관계명 기입
5. 관계 참여도 기입
6. 관계 필수, 선택 여부 기입
참고
엔터티는 네 부분의 모서리가 둥근 형태인 Soft-Box로 표현
엔터티 이름은 Box 내부 상단에 표시
속성 중 필수로 값을 입력하며 식별자인 속성은
⤷ # (Mandatory)를 표시
속성 중 필수로 값을 입력하여야 하는 속성은
⤷ * (Mandatory)를 표시
속성 중 선택적인 입력을 하여야 하는 속성은
⤷ o (Optional)를 표시
좋은 데이터 모델의 요소
- 완전성 : 업무에 필요한 모든 데이터가 정의되어 있어야 함
- 중복 배제 : 하나의 DataBase 내에 동일한 사실은 한 번만
- 업무 규칙 : 모든 사용자가 해당 규칙을 공유
- 데이터 재사용 : 데이터의 독립성을 고려하여 재사용성을 높임
- 의사소통 : 업무규칙은 엔터티, 속성, 관계 등의 형태로 최대한 자세하게 표현
- 통합성 : 동일한 데이터는 한 번만 정의
엔터티(Entity)란?
⤷ 업무에서 쓰이는 데이터들을 용도별로 분류한 데이터의 그룹
엔터티 특징
- 업무에서 쓰이는 정보여야 함
- 식별자가 있어야 함
- 2개 이상의 인스턴스를 가져야 함
- 반드시 속성을 가져야 함
⤷ 이때 하나의 인스턴스는 2개 이상의 속성을 가짐
⤷ 즉 하나의 엔터티는 2개 이상의 속성을 가짐
- 다른 엔터티와 1개 이상의 관계
엔터티 분류 방법
유형, 무형 분류
⤷ 유형 엔터티 : 모델링 대상이 물리적인 형태가 존재 (ex 상품, 회원)
⤷ 개념 엔터티 : 모델링 대상이 형태 없음 (ex 부서, 학과)
⤷ 사건 엔터티 : 모델링 대상이 행위로 인해 발생하는 것 (ex 주문, 이벤트 응모)
발생 시점 분류
⤷ 기본 엔터티 : 모델링 대상이 업무에 대해 원래 존재하는 요소 (독립적, 자식 엔터티 가질 수 있음)
⤷ 중심 엔터티 : 모델링 대상의 업무 과정 중 하나, 기본 엔터티로부터 파생 및 행위 엔터티 생성 (ex 주문, 매출, 계약)
⤷ 행위 엔터티 : 2개 이상의 엔터티로부터 파생 (ex 주문 내역, 이벤트 응모 이력)
엔터티 명명 주의점
- 업무에서 사용하는 용어 사용
- 한글은 약어 사용 불가, 영어 대문자로 표시
- 단수 명사로 표현, 띄어쓰기 불가
- 의미상 중복 불가 (주문, 결제 엔터티는 중복 가능)
- 명확한 표현
속성(Attribute)이란?
⤷ 엔터티의 특징을 나타내는 최소의 데이터 단위
속성 특징
- 더 이상 나눠지지 않음
- 업무에서 필요로 하는 항목
- 엔터티 및 인스턴스를 설명
- 하나의 속성은 하나의 속성값만 가짐
⤷ 여러 개를 가지면 1차 정규화
- 일반 속성은 정해진 주식별자에 함수적 종속성을 가져야 함
⤷ 완전 함수적 종속이 아닌 부분 종속이면 2차 정규화
속성 분류 방법
일반적 분류
⤷ 기본 속성 : 업무 프로세스(기본 틀)를 분석했더니 바로 정의 가능한 속성
⤷ 설계 속성 : 인스턴스에 유니크함을 부여하는 속성 (PK의 토대), 업무엔 없으나 모델링 하다 보니 고유함 보전을 위한 필요로 의해 만들어짐 (ex 학번, 사번)
⤷ 파생 속성 : 그냥 파생에 들어가면 성능, 편의 위해 새로 만든 엔터티의 속성, 데이터를 조회할 때 빠른 성능을 낼 수 있도록 원래 속성값을 계산하여 저장할 수 있도록 하는 속성 (ex 평균, 재고)
- 데이터 정합성 고려 및 가급적 적게 정의
구성 방식(각 속성 및 엔터티와의 관계) 분류
⤷ PK 속성 : 인스턴스의 유니크함을 부여하는 속성, 일반 속성들의 종속성을 가진 키로 기본키, 주식별자키 #으로 표현 (ex 학번, 사번)
⤷ FK 속성 : 다른 엔터티에서 가져온 속성(외래키), 다른 엔터티와의 관계를 맺게 해줌, 주식별자에 있는 속성이 FK가 될 수 있음 (ex #사원번호 FK)
⤷ 일반 속성 : PK, FK를 제외한 나머지 속성
속성 분해 가능 여부에 따른 분류
⤷ 단일 속성 : 속성이 하나의 의미로 구성
⤷ 복합 속성 : 여러개의 의미로 구성 (주소 = 시+구+동)
⤷ 다중값 속성 : 속성이 여러개 값을 가짐 (1차 정규화 또는 별도의 엔터티 생성)
속성성 명명 주의점
- 해당 업무에서 사용하는 단어 이용
- 서술식 속성명 불가
- 약어 사용 불가
- 전체 데이터 모델에서 유일성 확
속성이 만든 데이터 모델의 개념
- 도메인 : 속성이 가질 수 있는 속성 값의 범위
- 시스템 카탈로그
⤷ 시스템 자체에 관련 있는 데이터를 가진 DataBase
⤷ 시스템 테이블로 구성, SQL로 조회 가능
⤷ 저장된 데이터 : 메타 데이터, SELECT만 가능
관계(Relationships)란?
⤷ 엔터티와 엔터티 사이에 속성끼리의 연결에 의해 만들어지는 상관관계
관계 종류
⤷ 존재 관계 : 모델링 된 엔터티들이 존재로서 관계를 가짐
⤷ 행위 관계 : 모델링 된 엔터티들이 행위에 의해 관계를 가짐
UML의 Class Diagram에 의해 나뉜 종류
⤷ 연관 관계 : 필수적 관계(존재적, 식별자 관계), 항상 서로 이용(실선으로 표시), 멤버 변수로 선언
⤷ 의존 관계 : 선택적 관계(비식별자 관계), 상대 클래스 행위에 따라 이용(점선으로 표시), 행위 코드 오퍼레이션에 따라 파라미터로 사용
ERD 특성 분류
- 관계명(Membership) : 관계 이름
⤷ 시작은 엔터티 → 능동적, 끝은 엔터티 → 수동적 (동사 사용)
- 관계 차수(Cardinality) : 각 엔터티끼리의 관계에 참여하는 속성의 수
⤷ 1:1 - 하나의 엔터티에 관계되는 엔터티가 반드시 하나로 존재하는 경우 (완전 1:1 관계), 하나의 엔터티에 관계되는 엔터티가 하나이거나 없을 수 있는 경우 (선택적 1:1 관계)
⤷ 1:M - 엔터티에 하나의 행에 다른 엔터티의 값이 여러 개 있는 관계
⤷ M:N - 두 엔터티가 다대다의 연결관계를 갖고 있음, 이 경우 join 시 카테시안 곱(Cartesian Product)이 발생하므로 두 엔터티를 연결하는 연결 엔터티의 추가로 1:N 관계로 해소할 필요가 있음
- 관계 선택 사양(Optionality) : 필수(엔터티끼리 항상 관계)인지 선택(행위에 의해 관계 여부가 성립)인지의 여부
참고
관계 체크 사항
⤷ 두 엔터티 사이 관계 정의 시 유의점
- 두 엔터티 사이 관심 있는 연관 규칙 존재 여부
- 두 엔터티 사이 정보의 조합 발생 여부
- 업무 기술 시 장표의 관계 연결을 가능하게 하는 동사 존재 유무
- 업무 기술 시 장표의 관계 연결을 가능하게 하는 규칙의 서술 유무
식별자(Identifiers)란?
⤷ 각각의 인스턴스를 구분 가능하게 만드는 대표 속성
주식별자(Primary Identifier)란?
- 기본키, PK(Primary Key)에 해당하는 속성
⤷ 하나의 속성이 주식별자가 될 수도 있고 여러 개의 속성이 주식별자가 될 수도 있음
⤷ 유일성 : 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 함
⤷ 최소성 : 유일성을 보장하는 최소 개수의 속성이어야 함
⤷ 불변성 : 속성값이 되도록 변하지 않아야 함
⤷ 존재성 : 속성값이 NULL이 될 수 없음
+ 유일성과 최소성을 만족하는 속성은 보조키로 존재할 수 있음
+ 특정 특성을 만족함에 따라 속성은 특정 키로서 존재가 가능함
주식별자 도출 기준
- 해당 업무에서 자주 이용되는 속성을 주식별자로 지정
⤷ 같은 식별자 조건을 만족하더라도 업무적으로 더 많이 사용되는 속성을 주식별자로 지정
⤷ (ex 학생 번호와 주민번호 중 학생 번호가 주식별자, 주민번호는 보조식별자)
- 명칭이나 내역같은 이름은 사용하지 않음
⤷ 이름 자체를 주식별자로 사용하지 않음
⤷ (ex 부서명보다 부서 코드를 부여하여 부서 코드를 주식별자로 사용)
- 속성의 수를 최대한 적게 구성
⤷ 주식별자를 너무 많은 속성으로 구성하면 join으로 인한 성능 저하 발생
식별자 분류
- 대표성 여부
⤷ 주식별자(Primary Identifier) : 유일성, 최소성, 불변성, 존재성을 모두 만족하는 식별자, 다른 엔터티와 참조 관계로 연결
⤷ 보조식별자(Alternate Identifier) : 인스턴스 식별은 가능하나 엔터티를 대표하는 식별자는 아님, 다른 엔터티와 참조 관계로 연결되지 않음
- 스스로 생성되었는지 여부
⤷ 내부식별자(Internal Identifier) : 엔터티 내부에서 스스로 생성된 식별자
⤷ 외부식별자(Foreign Identifier) : 다른 엔터티에서 온 식별자, 다른 엔터티와 연결고리 역할
- 단일 속성의 여부
⤷ 단일식별자(Single Identifier) : 하나의 속성으로 구성된 식별자
⤷ 복합식별자(Composite Identifier) : 2개 이상의 속성으로 구성된 식별자
- 대체 여부
⤷ 원조식별자(Original Identifier) : 업무 프로세스에 존재하는 식별자, 가공되지 않은 원래의 식별자 (본질식별자)
⤷ 대리식별자(Surrogate Identifier) : 주식별자의 속성이 2개 이상인 경우 그 속성들을 하나로 묶어 사용하는 식별자 (인조식별자)
강한 개체
- 독립적으로 존재할 수 있는 엔터티
⤷ 고객과 계좌 엔터티 중 고객은 독립적으로 존재할 수 있음
약한 개체
- 독립적으로 존재할 수 없는 엔터티
⤷ 고객과 계좌 엔터티 중 계좌는 독립적으로 존재할 수 없음 (고객에 의해 파생되는 엔터티)
식별자 관계(Identification Relationship)란?
- 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 되는 관계
- 트랜잭션(Transaction)에 의한 관계로 동시에 commit과 rollback으로 하나의 commit 단위로 엔터티들이 묶임
참고
트랜잭션(Transaction)이란?
DataBase의 상태를 변화시키기 해서 수행하는 작업의 단위를 뜻함
- 주식별자는 반드시 존재해야 하므로(존재성) 부모 엔터티가 있어야 생성 가능
- 자식 엔터티는 부모 엔터티에 의존적
- 단일식별자인지 복합식별자인지에 따라 1:1 또는 1:N 관계가 결정
⤷ 강한 연결 관계
⤷ 실선 (항시 연결)
⤷ 부모와 자식 관계가 항상 유지
⤷ SQL 문의 join을 최소화해 줌
비식별자 관계(Non-Identification Relationship)란?
- 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 아닌 일반 속성이 되는 관계
- 일반 속성의 값은 NULL이 될 수 있으므로 부모 엔터티가 없는 자식 엔터티의 생성이 가능
- 자식 엔터티가 존재하는 상태에서 부모 엔터티만 삭제할 수도 있음
⤷ 약한 연결 관계
⤷ 점선 (선택적 연결)
⤷ 부모와 자식 관계가 유지 안 될 수도 있음