교재(유동오 지음 디비안(주) 2020)
: + 수업 + 검색. 구분 안함.
제1장 데이터 모델링 이론
데이터 모델링
: 정보로서 의미있는 대상 인지, 식별, 추상화, 구체화하는 것
ERM > RDM > RDBMS
개념 > 논리 > 물리(DB)
개념 단계부터 차례로 살펴보기
개념적 모델링 : 개체-관계 Entity-Relation 모델
개념적 데이터 모델 단계 CDM Conceptual Data Model
ER 모델
: 현실 세계를 '개체'와 '관계' 두 가지 개념으로 표현
| 집합 | 개체 | |
|---|---|---|
| Thing | Entity Type | Entity |
| Entity | Instance | |
| Occurance | ||
| ------------------ | --------------- | ---------------- |
| Association | Relationship | Pairing |
| btw things | ||
| ------------------ | --------------- | ---------------- |
| Characteristics | Attribute | |
| of a thing | value |
엔티티
Thing
※엔티티는 데이터베이스나 SQL에 존재하는 것이 아니고 개념적 단계, 테이블이 데이터 베이스나 SQL에 존재하는 물리적 구조.
엔티티는 테이블이 될 수도 있고, 안될 수도 있다. 근데 책도 그렇고 그냥 막 섞어서 많이 쓰는 것 같다. 여기서도 섞임.
엔티티 분류
유형
: 유형(물리적, 안정, 지속적 활용),
무형
: 개념(물리 형태X), 사건(비교적 발생량 多)
기본/핵심
: 관계 전에 독립적 생성, 부모 역할
중심/중요
: 기본 E에서 발생, 중심 역할
행위
: 둘 이상의 부모E로부터 발생, 자주 바뀜
슈퍼 타입
: 서브 타입의 공통 속성 관리
서브 타입
: 서브 타입 고유 속성 관리
강한
: 독립적, 자체식별자
약한
: 종속적, 다른 E 식별자 상속
독립(kernel, master)
: 원래 현실에 존재
업무중심(transaction)
: 업무 처리하며 발생하는 데이터, 주제영역에서 가장 핵심
종속
: 주로 업무중심에서 분리된 엔티티
교차(associative, relative)
: 두 개 이상 E간 발생하는 트랜잭션에 의해 생성되는 E, 다대다 관계를 해소하기 위해 도출
관계
개체 타입 간의 관계
관계의 기수성/관계수/관계 차수(cardinality) 닭발로 표시
: 1 : 1
: 1 : M
: M : M -> 중복 생김. 관계 E 늘려서 중복 줄이기
관계 유형
: 기본 관계(E-R-E)
: 재귀적/순환 관계(자기 자신과 관계)
: 병렬 관계(E-R-..R-E두 개 이상의 관계)
: 슈퍼/서브타입 관계(배타적/포괄적 관계를 가짐)
: 배타적 관계/아크(Arc)(E가 다른 E의 합집합과 관계 가짐)
관계 분류
필수
: 반드시(선에 세로줄)
선택
: 때때로(선에 동그라미)
식별하는 관계 (둥근 네모)
: 부모가 자식을 식별하고 나누는경우. 부모가 없어지면 자식 의미가 없어짐.
: 예) 주문-주문 상품 : 주문 상품은 주문에 의해 식별(identify)됨, 주문 상품은 주문에 종속됨.
: 주문이 없으면 주문 상품은 의미 없다.
: 주문-강한E, 주문 상품-약한E
: fk가 pk인 것
식별하지 않는 관계 (직각 네모)
: 부모가 자식을 식별하지 않음.
: 예) 저자-책 : 책은 저자가 없어도 의미있다. 예시가 딱 들어맞는진 모르겠지만 암튼.
단항, 이항, 삼항 관계
※집단화
: 개체-관계-개체
|
관계는 연결할 수 없다.
: 이를 해결하기위해 E-R-E를 집단화하여 하나의 E로 취급하여 R과 연결
속성
데이터 표현하는 가장 작은 단위
단순 속성, 복합 속성, 저장 속성, 파생 속성, 단일 값, 다중 값
※관계형 데이터 모델의 기본키/외래키 개념을 포함
식별자
E에서 인스턴스 개별을 식별 가능 속성(들)
인스턴스에 유일성, 최소성, 불변성, 존재성 만족하는 속성
관계 관리 모델링 : 관계형 데이터Relational Data 모델
물리적 단계
RDM
: 모든 데이터를 2차원 테이블 형식(릴레이션)으로 정의, 표현
키
키 제약 조건
: 릴레이션은 튜플들의 집합/"set"이다.
: 튜플들은 서로 중복되어서는 안된다.(튜플의 요소들의 세트가 유니크해야된다는 말)
슈퍼 키
: 키 제약 조건을 지키는 스키마 R이 있을 때,
: R의 속성의 subset 중에서 튜플끼리 값이 안겹치는 조합은 다 슈퍼키
: 모든 릴레이션은 최소 하나의 슈퍼 키가 있다.
: 후보 키(유니크)+안 후보 키(안유니크) 조합도 유니크니까 다~~ 슈퍼 키
키
: 슈퍼 키는 조합이구, 최소 단위의 슈퍼 키는 키.
후보 키
: 키들은 다 후보 키
기본 키
: 후보 키 중 하나를 릴레이션의 기본 키로 선택할 수 있다.
대체 키
: 후보 키 중 기본 키 아닌 후보 키
외래 키
: 속성 값이 다른 릴레이션의 기본 키를 참조하는 경우 외래 키가 됨.
제약조건(RDM 단계에서)
무결성?? Integrety Constraints 온전함 제약
'데이터의 온전함data integrity'은 '데이터 깨짐data corruption'의 반대되는 말.
물리적 온전함, 논리적 온전함 나뉘는데 물리적 온전함은 데이터 잘 저장, 불러오는 것 관련.
논리적 온전함은 데이터가 자기 환경에서 논리적으로 말이 되게 하는 것 관련.
데이터를 온전하게 유지해서 의도된대로 잘 있고 잘 쓰이게 하기위해 data integrity technique란게 생겼다.
밑에 나오는 것들은 논리적 온전함을 지키기 위해서 거는 제약들에 해당한다.
개체(Entity) 온전함(무결성)
: 모든 테이블이 pk를 가져야하고 그 pk 컬럼은 유니크한 값을 가져야하고, 널이 아니어야한다.
참조 온전함(무결성)
: 두 릴레이션 간에 특정되는 제약
: 어느 하나가 다른 하나의 pk를 참조하는 두 릴레이션의 튜플들이 일관성 갖도록 한다.
: fk는 다른 테이블 pk를 가져와서 쓰는 것이다.
: 모든 fk는 두 가지 상태만 가능하다. 다른 테이블의 pk 값이거나, null이거나.
: (null이면 관계가 없거나, 관계를 모른다.)
영역(Domain) 온전함(무결성)
: 모든 관계형 데이터베이스의 컬럼은 미리 정의된 도메인 이내의값을 가져야한다. 도메인에 충실해야한다.
※도메인: 데이터 요소가 가질 수 있는 데이터 타입의 값 컬렉션(값의 enum)
다른 제약도 많이 있고, 사용자가 자기만의 제약을 만들 수도 있다.
함수 종속성
어느 속성군의 값이 정해지면 다른 속성군의 값이 정해지는 것.
| X | | Y |
| 결정자 | -> | 종속자 |
| 고객 번호 | -> |고객명,생일,주소...|
고객번호 -> (고객명, 생일, 주소)
고객명, 생일, 주소...등이 고객 번호 칼럼에 함수적으로 종속된다.
완전 함수 종속
: (속성 혹은 속성들의 집합인 X에 대해)
: X이면 Y(X->Y), 그러나 X의 부분집합에는 Y가 종속되지 않을 때.
: 예)주문내역의 기본키가 주문번호와 상품코드로 구성된 경우, 주문 수량은 주문번호 또는 상품 코드에 종속되지 않고, 주문번호, 상품 코드에 종속
부분 함수 종속
: 여러개 속성이 하나기본키 이룰 때 기본키 구성 일부 속성만으로도 종속 관계가 결정되면 부분 함수 종속
이행적 함수 종속
: X->Y, Y->Z이면 X->Z
: Z는 X에 이행적 함수 종속성을 갖는다.
: 데이터가 꼬리에 꼬리를 물고 관계, 데이터 변경시에 안좋아.
정규화
데이터 입력, 수정, 삭제 발생하는 이상 최소화 위해 좀 더 작은 단위 테이블로 설계하는 과정
제1정규형
중복되는 행이 없어야한다.
회원번호 회원 수업
회원번호 회원 수업2
회원번호 회원 수업3
이런걸 수업 테이블 따로만들어서 중복없게 하는 것.
제2정규형
제1정규형 했어
이제는 테이블의 후보 키에 종속적이지 않은 속성이 있으면 별도 릴레이션으로 분리
제3정규형
제2정규형도 했어.
이제는 키가 아닌 속성이 다른 속성에 종속된 경우 별도 릴레이션으로 분리
RDBMS
이제 데이터 저장, 읽어올 수 있는 물리적 데이터 베이스를 설계하는 단계다.
PDMs 물리적 데이터 모델 단계
교재에 나오는 현업 관련 내용
하향식은 개념->논리->물리 순으로 상세화하면서 진행하게된다.
탑다운 방식은 현업과 의사소통하며 같이 진행
상향식은 규모가 작거나 현업 참여 한정된 경우
데이터 모델링 절차
현행 분석(현행 업무 분석/현행 데이터 분석)/방향성 수립 -> 개념 모델링(주제 영역 정의/핵심 엔티티 정의) -> 논리 모델링(엔티티 정의/관계 정의/속성 정의) -> 물리 모델링(테이블 설계/무결성 설계/인덱스 등 설계)
얘네가 표준 단어, 표준 용어, 표준 도메인, 표준 코드 등 데이터 표준 형식을 따라서 Repository로 저장~~~!!
현행 분석
현행 업무 분석, 현행 데이터 분석
기본 지식 습득, 현행 ERD(ER 다이어그램), 테이블 정의서 등 수집
실제 데이터 분석
데이터 구조나 성능적 이슈 중심으로 자료 분석
요구사항 정의(제안 요청서, 제안서, 인터뷰 등을 통해 요구사항 상세화)
방향성 수립
현행 분석을 통해 문제점, 시사점을 찾고 개선 방향을 마련한다.
방법 : 현업과 협업, 문서 통한 파악, 리버스 모델 활용
리버스 모델
: 현행 ERD 없거나 현행화가 이루어지지 않은 경우
: 현행 시스템 DB 메타정보 이용하여 엔티티와 속성 도출, 관계 식별 ERD 작성하며 데이터 모델을 현행화 하는 과정
: 상세화 작업은 리버스 과정에서 가장 중요, 시간 오래걸린다.
: 리버스 이용하여 빠르게 접근하되 새로운 관점에서 생각하는 습관 필요, 현업 지원이 반드시 필요하다.
: 쓸모 없는 테이블도 있다. 삭제에 과감해지자. 꼭 필요하면 나중에 다시 식별/설계 될 것이다.
: 1차적으로 리버스 대상은 테이블 명을 기준으로 이관,백업,임시등 제외, 날짜형식 제외...
개념 모델링
일반적으로 주제 영역 도출, 주제 영역 분류 및 정의, 핵심 엔티티 정의 및 관계 정의와 같은 작업을 통해 진행.
주제 영역
데이터를 일관된 기준을 가지고 최상위 단계에서 분류한 데이터 집합.
주제 영역은 독립된 단위로 이루어지며, 주제 영역 내 데이터는 상호 밀접 관계, 다른 주제 영역 데이터와 멸확 분리.
주제 영역 도출
업무 용어, 업무 지침서의 목차, 기업의 조직 및 팀 구성 등의 자료를 통해 얻을 수 있다.
현행 시스템의 주제 영역, 테이블 참고하여 파악할 수도 있다.
후보 도출하기
주제 영역 분류
주제 영역 후보를 도출했으면 일정 기준에 따라 데이터를 분류, 통합하는 과정
주제 영역 프레임 워크
Who 주체 What/how 대상/자원 Where 장소
Biz, Event(Whem, Why 포함) 약정/계약
Additional Bizm Event, Status 행위/이벤트/상태
(출처:비투엔 자료)
위 같은 주제 영역 프레임워크 이용, 분류할 수 있다.
MECE 원칙
: 주제 영역 의믹 명확, 중복x, 누락x
주제 영역을 계층에 따라 상세화, 응집력 높이는 관점에서 분류
데이터 관점에서 분류(데이터 통합 개념 포함)할 수 있을 뿐 아니라 서비스, 업무, 기능 관점에서 분류할 수도 있다.
데이터 관점만 강조하면 의견 일치 어렵다. 현업이 우리 업무는 어디있느냐 한다.
그러나 업무 관점에서 통합하면 업무 조직도, 시스템 메뉴 구조와 유사해지기도한다.
'데이터 주제 영역을 정의하는 목적이 무엇일까?'를 생각해보기 추천
주제 영역 정의
주제 영역 설명, 해당 데이터 범위나 내용 명확희 정의하는 과정
중복 없는지, 주제 영역 간 동일 기준 적용되었는지
주제 영역 정의 작성, 영역 내 정보 유형 및 항목 정의
명명 규칙
: 주제 영역 명은 관리하는 정보 설명하는 단수형 명사
: 한글과 영문 대문자를 사용, 숫자 및 특수 문자 안쓴다.
: 주제 영역에 대한 영문 약어는 알파벳 대문자와 숫자로 구성
: 1레벨 주제 영역은 영문 2자리, 하위 주제 영역은 상위 주제 영역 약어에 숫자 2자리 붙여 구성(CU, CU01, CU0101)
문제점
개념 부족
: 현업의 주제 영역 개념에 대한 이해도 낮을 때 의사 소통 오려움
의견 차이
: 데이터 관점 vs 실제 업무 기능과 흐름
: 데이터 측면에서 접근하되 다양 관점에서 생각하는 습관 필요, 업무 이해 노력
확신 부족
: 해당 산업 경험이 없는 모델러
: 잘 정의했나 판단 어렵고 마땅 검증 방법도 없을 수 있다. 동료와 토론하며 논리적 오류 체크, 이해 관계자와 자료 공유 등으로 풀기
: 주제 영역에 정답은 없다. 최대한 간단, 일관 기준 적용하여 이해 당사자들 간의 생각 차이 좁히는 수밖에
오너십
: 오너십이 주제 영역 기준이 될 수도 있으나, 오너십 때문에 이해 관계자 동의 얻는데 어려움 얻을 수도 있다.
: 데이터 오너십의 범위도 명확하지 않다.
: 여러 업무 공통 데이터는 데이터 관점에서는 통합해야하지만, 데이터 오너십 때문에 어려울 수도.
: 현업이나 개발자 반발 최소화 위해서 주제 영역 정의하며 데이터에 대한 역할 및 책임 일정 부분 정의하는 것 필요
오너십?????? 찾아보기
핵심 엔티티 식별
주제 영역 확정되면 최하위 데이터 주제 영역 별로 대표성 갖는 핵심 엔티티를 도출, 식별
모든 최 하위 데이터 주제 영역은 하나 이상의 핵심 엔티티 포함해야. 없으면 타 주제 영역과 통합할지 검토
핵심 엔티티는 주제 영역과 마찬가지로 업무 주체, 대상, 자원, 장소등에 해당하는 엔티티
핵심 엔티티 얼마나, 어느레벨까지 상세화?는 정해지지 않음. 해당 주제 영역 대표 엔티티를 설계하는 것이기 때문에 전반적 데이터 구조와 관계 파악할수 있을 만큼 식별하는 것이 좋다.
식별자 및 속성 정의
속성은 모두 도출해야하는 것 아니지만, 식별자 및 주요 속성은 가급적 식별하여 데이터 집합을 명확히. 이해 당사자와 의사 소통 문제없도록.
식별자는 엔티티 개념 가장 명확하게 표현할 수 있는 속성으로.
개념 모델링 필수, 안하면 주제 영역 분류라도 해야.
논리 모델링
비즈니스 데이터를 명확, 구체적 정의 과정
비즈니스 전체 영역에 대한 상세한 수준의 데이터 구조를 설계
개념 데이터 모델과 구조적 일관성 유지하며 진행
DBMS 물리적 특성까지 고려할 필요는 없다.
엔티티 정의 및 상세화
결제도 몇 단계로 나누고 정의할지 등 어렵다.
핵심(key) 엔티티
업무 처리와 상관없이 독립적
모든 업무 행위는 핵심 엔티티에 의해 정의되거나, 핵심 엔티티 간의 관계에 의해 정의된다고 해도 과언이 아니다.
예들어 카페, 가게 오픈 전 이미 매장이 있고 상품 정보, 정책 등 있다.
언제 신규로 생성, 언제 속성 갱신, 삭제시 인스턴스 삭제 수반하는지, 물리적으로 완전 삭제인지 "삭제" 표시만 하는지, 언제 삭제할것인지 등 인스턴스 생애 주기에 대한 이해를 바탕으로 설계
중요 부분 도출, 서브 타입 설계하고 엔티티 인스턴스 식별위한 식별자 정의, 주요 속성 도출
유형 및 분류 엔티티
분류 엔티티 구조는 간단하지만, 분류 체계를 만드는 일은 어렵고 중요
업무 규칙 및 지식
업무 요건을 데이터로 관리하면 프로그램 수정않고도 데이터에 반영하면 됨
업무 주체 및 대상
고객은 누구인가? 주민번호 없어도 고객인가? 개인과 개인사업자는 동일한 고객인가? 등등 검토
장소
장소 자체가 의미 있을 수 있지만, 다른 핵심 엔티티의 속성으로 존재하기도 한다. 독립 엔티티인지 속성인지
통신 회사는 조직과 별도로 국사 정보를 관리할 필요가 있다.
중요(main) 엔티티
상위 엔티티의 주 식별자를 상속받지 않고, 독립적 주 식별자를 가짐
업무 주체와 대상간 거래나 업무 행위에 의해 발생
예)주문(-주문상품)-배송(-배송상품)-발주(-발주상태, -발주상품)
핵심 엔티티 간의 관계 엔티티 성격
행위(action) 엔티티
중요 업무 중심으로 상세 업무 데이터, 이력, 상태, 첨부파일, 품의거래처...
상태 관리가 중요한데 잘 못한다.
몇 차 결재까지 갔는지, 부결됐는지, 완료됐는지...
이력
: 대부분 속성의 이력을 관리하면 동일형태로 이력 엔티티 설계
: 일부 속성 관리하면 일부 관리할 속성을 식별, 코드화하여 행으로, 해당속성 변경된 경우만 데이터 생성
: 상태 바뀔 때 마다? 아니면 최종 완료될 때 마다?
: 이력이 언제 바뀌었는지 변경 시점을 이벤트로 관리 or 변경 시작 일자와 변경 종료 일자를 표시해서 구간으로 관리하면 찾을 때 where 변경시작일자 <= '찾는날짜' AND 변경종료일자 <= '찾는날자'라고 쿼리써야돼서 from to 복잡하나 찾기는 쉽다. 인서트는 복잡. 전자는 찾을 때 where 변경일자 <= '찾는날짜'라고 해야하고, 인서트는 쉽다.
: 이력 테이블에 최종을 제외할 것이냐, 포함할 것이냐? 포함안하면 최종은 조인해서 찾아야할 것이다.
엔티티 도출 및 식별
관심 대상되는 데이터 분석, 엔티티로 구체화하는 과정
가장 일반적/호과적 방법은 현행as-is 데이터모델 바탕으로 현업의 기능 및 데이터 요구사항 정의하며 엔티티 도출, 식별
예)고객으로 보이는 엔티티가 여럿이면 대락젹인 고객으로 모아서 추가
예) 단어 및 용어가 통일안됐으면 통일. 데이터 표준화 안됐어도 to-be 데이터 표준화 염두에 두고 하기.
엔티티 명명
기본 업무 의미, 설명하는 최적화된 단수형 명사
예) 고객, 부서, 상품, 주문, 계약
속성은 수식어 붙여서 명확하게
예) 고객주소, 계약입금내역
교차 엔티티는 교차되는 엔티티의 이름 조합으로
예)계약+상품->계약상품
~별 ~및같은 낱 단어 쓰지말기
예)고객별실적->고객단위실적
한글 알파벳 대문자사용, 숫자와 언더바 제한적 허용, 띄어쓰기나 특수문자 X
엔티티 정의
엔티티로 관리하는 데이터 집합을 규정
데이터 발생 규칙 및 업무 규칙 등을 기술함으로써 엔티티 정의
독립적 엔티티인지, 종속적 엔티티인지에 따라 다르다.
독립적 엔티티
: 우선 실체인지, 관계(역할)인지 따져봐야
: 이미 식별자 존재, 식별자 중심으로 데이터 집합을 정의
종속적 엔티티
: 엔티티간 관계의 성격(거래, 이벤트, 역할) 파악, 집합 단위나 데이터 발생 기준을 정의하는게 좋다.
예) 만약 부모가 자녀 어린이 보험 드는 경우,
계약자
: 부모
피보험자
: 자녀
이렇게된다.
이는
고객-│------O＜계약관련자＞O------│-보험계약
이와 같이 정의할 수 있다.
'고객'도 누가 고객, 어디/언제까지 고객, '고객a'(개인회원 홍길동)검색해서 '고객b'(법인회원 홍길동)도 나와야하는가...등등 고민
엔티티 통합
일반화와 특수화
개인 고객과 법인 고객을 일반화->고객 엔티티로 통합.
개별 속성은 특수화 통해 개인 고객과 법인 고객 서브 타입 엔티티로 정의.
데이터 통합 과정
분류 체계 일원화
: 동일, 유사 데이터를 동일 유형으로 분류/식별
: 예) 고객->개인고객, 법인고객, 사업자고객, 단체고객...
식별 체계 일원화
: 동일 분류 내 데이터를 유일하고 중복없이 식별
: 예) 개인->주민번호, 외국인번호, 여권번호..
속성 체계 일원화
: 동일 분류 내 데이터는 관리 속성도 동일하거나 유사해야
: 예) 고객->고객명, 주소, 연락처
