데이터모델링의 이해

데이터 모델링

모델링

일정한 표기법으로 현실 세계를 추상화/단순화/명확화하여 표현한다

• 추상화: 현실세계를 일정한 형식에 맞추어 표현
• 단순화: 복잡한 현실세계를 약속 및 제한한 표기법/언어를 이용해 쉽게 이해할 수 있도록 함
• 명확화: 누구나 이해하기 쉽게 애매모호함을 제거한다. 정확하게 현상을 기술한다.

데이터 모델링

의사결정 과정을 지원한다

통합관점 뷰인 개념 스키마를 만드는 과정이라고 볼 수 있다.

시스템 구현을 포함한 업무분석 및 업무형상화 + DB 구축

• 정보시스템을 구축하기 위한 데이터 관점의 업무 분석
• 현실세계의 데이터에 대해 약속된 표기법으로 표현
• 데이터베이스를 구축하기 위한 분석 및 설계의 과정

제공하는 기능

• 시스템을 현재 또는 원하는 모습으로 가시화
• 시스템의 구조/행동 명세화
• 시스템을 구축하는 구조화한 틀
• 시스템 구축 과정에서 결정한 것을 문서화
• 다양한 관점(집중할 곳에 집중하기 위해 그 외 세부사항 숨김)
• 목표에 따라 구체화한 상세 수준의 표현 방법

유의점

• 중복
• 비유연성: 데이터 정의와 사용 프로세스의 분리. 데이터/프로세스의 변화가 애플리케이션이나 DB의 중대한 변화로 이어지지 않음.
• 비일관성: 데이터간 상호 연관 관계를 명확히 정의. 프로세스와 프로그램/테이블 연계를 높이면 비일관성 확률이 높아진다

데이터 모델링의 3요소

• Thing: Entity 업무가 관여하는 어떤 것 Entity Type > Entity > Instance, Occurence
• Attribute: 어떤 것이 가지는 성격
• Relationship: 업무가 관여하는 어떤 것과의 관계 Relationship > Paring

추상화 수준에 따른 데이터 모델

개념 - 논리 - 물리 순으로 추상적이지 않다

• 개념적: 가장 추상적. 업무 중심. 포괄적/전사적 데이터 모델링. EA 수립에 활용
• 논리적: 데이터 모델링이 완료된 상태(물리적 스키마 전) 시스템으로 구축하고자 하는 업무에 대해 key, 속성, 관계 등을 정확하게 표현 재사용성이 좋음. 정규화 수행.
• 물리적: 실제 DB에 이식할 수 있도록 물리적 성격을 고려한 설계

좋은 데이터 모델

• 완전성: 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 함
• 중복 배제
• 업무 규칙: 업무 규칙이 모델에 표현되고 사용자들이 공유할 수 있음
• 데이터 재사용: 통합성(회사 전체 관점 공용 데이터), 독립성(데이터가 애플리케이션에 대해 독립적임)
• 의사소통

데이터 독립성

구성요소

추상화 수준에 따른 데이터 모델 3단계와 비교!

• 외부 스키마: 뷰 단계. 여러 개의 사용자 관점. 개인적 DB 스키마
• 개념 스키마: 하나의 개념으로 모든 사용자 관점을 통합하여 전체 DB 기술
• 내부 스키마: DB가 물리적으로 저장된 형식

독립성

• 논리적(논리적 구조 변경이 응용 프로그램에 영향을 주지 않는다)통합 구조 변경 가능
• 사용자 특성에 맞는 변경
• 개념 스키마 변경이 외부 스키마에 영향을 주지 않는다
• 물리적(저장장치의 구조를 변경한다고 응용 프로그램이나 개념 스키마에 영향을 주지 않는다)개념 구조 영향 없이 물리적 구조 변경
• 물리적 구조 영향 없이 개념 구조 변경
• 내부 스키마 변경이 외부/개념 스키마에 영향을 주지 않는다

사상

Mapping

데이터 독립성을 보장하기 위해 사상을 하는 스크립트(DDL)를 DBA가 필요하는 때마다 변경해야 한다

• 외부적/개념적(논리적)사용자가 접근하는 형식에 따라 다른 타입 필드를 가질 수 있음외부 화면이나 사용자에게 인터페이스하기 위한 스키마 구조는 전체가 통합된 개념적 스키마와 연결된다
• 개념적 뷰의 필드 타입은 변화 없음
• 외부적 뷰와 개념적 뷰의 상호 관련성 정의
• 개념적/내부적(물리적)저장된 DB 구조가 바뀌면 개념적/내부적 사상이 바뀜(그래야 개념적 스키마가 그대로 남아 있음)
• 통합된 개념적 스키마 구조와 물리적인 테이블 스페이스가 연결되는 구조
• 개념적 뷰와 저장된 DB의 상호 관련성 정의

ERD 표기법

Entity Relationship Diagram

피터 첸. 1976

엔터티와 엔터티간의 관계를 도식화한다

• ERD 작업 순서
  1. 엔터티 그리기
  2. 적절하게 엔터티 배치하기(왼쪽 상단이 중요. 업무 흐름 중심은 중앙)
  3. 엔터티간 관계 설정하기(PK 식별자 관계. 중복/circle 지양)
  4. 관계명 기술하기(현재형. 너무 포괄적이지 않게)
  5. 관계의 참여도 기술하기(관계차수)
  6. 관계의 필수여부 기술

ERD 표기법

엔터티 Entity

개념

• 사람, 장소, 물건 등 명사
• 업무상 관리가 필요한 관심사
• 저장이 되기 위한 어떤 것

엔터티는 그 집합에 속하는 개체들의 특성인 속성을 가진다

공통 속성과 개별 속성이 있다(개별 속성은 일부 인스턴스에만 해당)

엔터티는 인스턴스의 집합

눈에 보이지 않는 개념 등도 엔터티

특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
• 유일한 식별자에 의해 식별 가능
• 영속적으로 존재하는 인스턴스의 집합: 두 개 이상
• 업무 프로세스에 의해 이용됨
• 반드시 속성을 가짐: 관계 엔터티는 주식별자만 가지고 있어도 인정
• 다른 엔터티와 최소 한 개 이상의 관계를 가짐

데이터 모델링 중 관계를 생략해서 표현하는 경우

• 통계를 위한 엔터티: Read only
• 코드를 위한 엔터티: 너무 관계가 많음
• 시스템 처리시 내부 필요에 의한 엔터티는 트랜잭션이 업무적으로 연관된 테이블과 관게 설정 필요

분류

유/무형

• 유형: 안정적, 지속적
• 개념
• 사건: 업무를 수행함에 따라 발생하는 엔터티. 발생량이 많음. 통계에 이용

발생시점

• 기본/키: 독립적으로 생성되는 고유한 주식별자(상속받은 것이 아님)
• 중심/메인: 기본 엔터티로부터 발생. 업무에서 중심적인 역할. 데이터량 많음.
• 행위: 중심 엔터티와 다른 엔터티간 관계에서 행위 엔터티 생성.(두 개 이상의 부모 엔터티) 내용이 자주 바뀌고 데이터량이 증가한다

명명

• 현업에서 사용하는 용어
• 가능한 약어 사용 지양
• 단수 명사
• 모든 엔터티에서 유일한 이름
• 엔터티의 생성 의미

속성

정의

• 업무에서 필요로 한다
• 의미상 더 이상 분리되지 않는 최소의 데이터 단위
• 엔터티를 설명하고 인스턴스의 구성요소가 된다

엔터티와 인스턴스, 속성

• 한 개의 엔터티는 두 개 이상의 인스턴스 집합
• 한 개의 엔터티는 두 개 이상의 속성을 가짐
• 한 개의 속성은 한 개의 속성값을 가짐

하나의 속성은 하나의 인스턴스에만 존재한다

속성은 관계로 기술될 수 없고, 스스로 속성을 가질 수도 없다

속성도 집합이다

특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
• 정규화 이론에 근거하여 정해진 주식별자에 함수적 종속성을 가진다
• 하나의 속성은 한 개의 값

분류

특성

• 기본(basic): 업무로부터 추출한 모든 속성 코드성 데이터, 엔터티 식별용 일련번호, 다른 속성 계산/영향으로 생성된 속성을 제외한 모든 속성
• 설계(designed): 데이터 모델링, 업무 규칙화 위해 만든 속성
• 파생(derived): 다른 속성에 영향을 받아 발생. 보통 계산된 값. 가능한 지양. 조회 성능 향상

엔터티 구성 방식

• PK: 엔터티 식별
• FK: 다른 엔터티와의 관계에서 포함됨. 관계 속성
• 일반 속성: 엔터티에 포함되었지만 PK와 FK가 아님

세부 의미로 쪼개지는지

• 복합속성(composite): 여러 세부 속성들로 구성될 수 있음(주소가 시, 구, 동, 번지 등이 있는 것처럼)
• 단순속성(simple)

속성 값 개수

• 단일값: 1:1. 보통의 경우
• 다중값: 한 속성에 동일한 성질의 여러 값 나타나기도.. 전화번호에 집, 휴대폰, 회사 등.. 다중값 속성은 하나의 엔터티에 넣을 수 없으므로 1차 정규화.다른 엔터티를 만들어 연결

명명

• 업무에서 사용하는 이름
• 서술형 x, 약어 사용 x, 애매모호함 x
• 복합 명사 사용해 구체성 높이기
• 전체 데이터모델에서 유일: 반정규화/통합시 좋음

도메인

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

속성의 데이터타입, 크기, 제약사항 지정

관계

엔터티의 인스턴스 사이에 논리적인 연관성으로서 존재 또는 행위로서 서로에게 연관성이 부여된 상태

엔터티와 속성 관계의 정의에 영향을 받는다

관계의 패어링

관계는 엔터티 안의 인스턴스가 개별적으로 관계를 가지는 것(패어링)

이 패어링을 집합의 관계로 표현한다

개별 인스턴스가 각각 다른 관계를 가지고 있다면 두 엔터티 사이에 두 개 이상의 관계 형성 가능

관계의 패어링: 각 엔터티의 인스턴스들이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태

분류

관계 연결의 목적에 따른 분류

• 연관 관계: 항상 이용하는 관계. 존재적 관계. 부서에 소속된 사원. 실선
• 의존 관계: 상대 클래스의 행위에 의해 관계 형성됨. 고객의 주문. 점선

ERD는 구분하지 않고

클래스다이어그램(UML)은 실선과 점선으로 차이를 둠

표기법

관계명, 관계차수, 관계선택사양

관계명

엔터티가 관계에 참여하는 형태

구체적 동사, 현재형

각각의 관계는 두 개의 관계명을 가진다

• 부서는 사원을 포함한다

• 사원은 부서에 소속된다

참여자 관점에 따라 능동적/수동적 관계명

관계차수(degree/cardinality)

두 개의 엔터티간 관계에서 참여자의 수를 표현하는 것

1:1, 1:M, M:M

관계선택사양

• 필수(mandatory)
• 선택(optional)

양쪽이 모두 선택참여관계라면 재검토 필요

관계 체크사항

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

관계 읽는 방법

기준 엔터티를 하나로 읽고

대상 엔터티의 개수를 읽고

관계선택사양, 관계명

부서와 사원이 1:M이고 부서 입장에서 사원이 선택관계일 때.

• 각 부서에는 여러 사원이 때때로 소속된다
• 각각의 사원은 한 부서에 항상 속한다

식별자(Identifier)

하나의 엔터티에 속한 속성 중 엔터티를 대표할 수 있는 속성

하나의 엔터티에는 반드시 하나의 유일한 식별자 존재

식별자는 엔터티 내에서 인스턴스들을 구불할 수 있는 구분자이다

식별자는 논리 데이터 모델링 단계에서(키는 물리 데이터 모델링 단계)

주식별자의 특징

외부식별자는 다름(참조무결성 제약조건에 따른 특징)

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

분류

대표성

• 주식별자: 각 어커런스 구분. 타 엔터티와 참조관계 연결 가능
• 보조식별자: 각 어커런스 구분

스스로 생성하는지

• 내부식별자
• 외부식별자: Null 가능

속성 수

• 단일식별자
• 복합식별자

대체 여부

• 본질식별자: 업무에 의해 만들어진다
• 인조식별자: 원조식별자가 복잡하여 만들어진다

주식별자이자 내부/단일/본질식별자 이렇게 분류 가능..!

주식별자 도출 기준

• 해당 업무에서 자주 이용되는 속성
• 명칭, 내역 등 이름은 가능한 지양부서명보다는 부서코드, 부서번호를 주식별자로 하고 부서명은 보조
• 이름은 길어질 수 있음
• 복합식별자로 주식별자 할 때는 너무 많은 속성이 포함되지 않게
• 만약 거듭해 상속된 속성으로 조인시 성능 저하가 예견된다면 많이 넣어도 됨

기본키가 될 자격을 갖춘 속성을 후보키라고 한다. 여러 개 존재 가능

후보키 중 선택되면 기본키,

기본키가 되지 못 하면 대리키가 된다

모든 후보키는(기본키 포함) 불필요한 속성을 포함하지 않는다

슈퍼키는 불필요한 속성이 덧붙여진 후보키로 지양해야 한다

PK 순서 결정 기준

인덱스를 효율적으로 이용하기 위해서

여러 개의 속성이 하나의 인덱스이면 앞쪽의 속성이 비교자인 것이 효율이 좋다

=, BETWEEN, <>가 앞으로

식별자 관계

엔터티간 관계를 통해 형성된 부모 엔터티의 주식별자는 자식 엔터티의 속성이 된다.

이 FK를 자식이 주식별자로 이용할지 그냥 부모엔터티와 연결이 되는 속성(FK)으로만 이용할지를 결정해야 한다

식별자 관계(Identifying relationship)

부모엔터티의 주식별자가 자식엔터티의 주식별자

주식별자는 NULL이 안 되니까 부모가 생성되야만 자식을 생성할 수 있다

• 상속받은 식별자만 주식별자로 이용한다면 1:1(엔터티 통합의 대상이 된다)

• 상속받은 식별자에 다른 부모의 속성/내부식별자가 주식별자면 1:M 식별자 관계이자 1:M 관계일 때 자식 엔터티의 주식별자 수는 부모로부터 상속받은 식별자 N개에 최소 한 개 이상을 더해야 한다(최소 N+1개)

상속이 거듭되면 PK 속성 수가 너무 많아진다(개발 복잡성, 오류 가능성 상승)

상속받은 주식별자 속성을 타엔터티에 이전해야 한다

비식별자 관계(Non-Identifying relationship)

상속받은 식별자가 자식의 일반 속성

연결관계가 약함

부모 주식별자의 일부분이 자식 주식별자에 포함될 수 있다

상속받은 주식별자 속성을 타엔터티에 차단해야 한다

• 자식이 받은 속성이 반드시 필수가 아니어도 무방함 부모 없이 자식 생성 가능(부모쪽의 관계 참여가 선택)
• 엔터티별로 데이터의 생명주기를 다르게 관리할 경우 부모가 자식보다 먼저 삭제될 수 있음
• 여러 개의 엔터티를 하나로 통합/표현했는데 각각의 엔터티가 별도의 관계를 가질 때 방문 접수와 인터넷 접수가 내방고객, 인터넷 회우너과 식별자관계였는데 두 접수가 접수라는 엔터리로 통합되면서, 접수번호가 PK가 되고 방문접수와 인터넷접수의 FK였던 주민번호, Email은 주식별자가 아니게 된다. 자식과의 식별자 관계도 비식별자 관계로 전환된다
• 자식엔터티가 별도의 주식별자를 생성하는 것이 더 유리할 것으로 판단된다

주민등록번호, 주문번호처럼 부모 뿐 아니라 자식 데이터 조회에도 쓰이는 기준 속성들이 비식별자일 경우, 부모까지 거슬러올라가야 한다(상속되지 않았으니까): 조인이 많이 필요하고 복잡성이 높아 성능이 저하된다.

 

 

데이터 모델과 SQL

정규화(normalization)

데이터의 중복을 최소화한다

제1정규형

모든 속성은 반드시 하나의 값을 가져야 한다

제 1차 정규화 대상

• 한 엔터티가 전화번호1, 전화번호2처럼 유사 속성을 컬럼단위로 반복하는 것도 다가속성으로(multivalued attribute) 속성의 원자성을 위배한 1차 정규화 대상이다 1차 정규화를 통해 1:M 관계의 두 엔터티로 분리한다
• 반복적 속성값을 가지면 각 속성에 대해 OR로 연결한다. 어느 하나의 속성에라도 인덱스 정의가 안 되면 모든 조건절들이 인덱스 없이 전체 데이터를 스캔해야 해서 성능이 저하된다. 모든 반복 속성에 인덱스 만들면 조회 성능은 향상되고 입력, 수정, 삭제 성능은 저하된다. 1차 정규화 수행 후 인덱스 적용
• 로우 단위든 컬럼 단위든 중복속성 분리는 1차 정규화 대상
• 1차 정규화 대상이 아니다 = 1차 정규형

제2정규형

엔터티의 일반속성은 주식별자 전체에 종속적이어야 한다

• 주식별자가 상품번호, 일반속성이 상품명 상품번호는 기준값, 결정자가 되고 상품명은 종속자가 된다
• 주식별자가 상품번호와 주문번호(FK), 일반속성이 상품명 이 때, 상품명은 부분 종속되어 있다(식별자 일부에만 종속)

이처럼 제2정규형을 위반하면, 상품명 변경시 주문상세의 상품명을 모두 변경해야 한다

데이터가 중복되었기 때문으로 성능과 정합성에 문제가 생기게 된다

JOIN을 통해 각기 구분된 엔터티를 연결하는 데이터로 만든다

제3정규형

엔터티의 일반속성 간에는 서로 종속적이지 않다

• 주문: 주) 주문번호 일) 고객번호, 고객명
• 주문상세: 주, 외) 주문번호, 상품번호
• 상품: 주) 상품번호 일) 상품명

세 엔터티는 제 2정규형은 충족하지만 제 3정규형을 위배한다

주문번호 - 고객번호 - 고객명으로 종속되므로 이행적 종속이다. 이를 배제하는 것이 제3정규화

고객명이 식별자가 아닌 일반 속성에 종속되어 고객명변경시 주문 엔터티의 모든 고객명을 갱신해야 하므로 데이터 중복으로 인한 과부화 및 정합성 오류가 가능하다

고객 엔터티를 만들어야 한다

정규화는 필수 작업이지만 무조건적이지는 않다

상황에 따른 반정규화도 필요하다.

중요한 건 정규화 작업 후 반정규화하기

(정규화가 항상 조회 성능을 저하하는 것은 아니다)

반정규화

정규화의 반대로 연정규화라고 하기도 함

넓은 의미로 정규화된 데이터 모델에서 중복, 통합, 분리 등을 수행하는 모든 과정

성능을 위해 데이터 중복을 허용하는 것

조회성능은 향상시키지만 입력, 수정, 삭제 등 성능은 저하될 수 있다

데이터 불일치로 인한 정합성 문제뿐 아니라 불필요한 트랜잭션으로 인한 성능 문제 발생 가능 이를 감안하고도 조회 성능의 이점을 취해야 할 때 반정규화를 진행한다

• 다량의 데이터로 인해 인덱스 써도 랜덤이라 성능이 저하될 때, 꼭 반정규화 안 해도 파티션, 데이터 클러스터링 등 물리 저장 기법을 활용할 수 있다 하나의 결과셋 추출 위해 다량 데이터 탐색이 자주, 반복적으로 필요할 때 반정규화 고려
• RDBMS는 현재 레코드 기준 이전/이후 레코드 접근 불가 반정규화가 아니라 윈도우 함수로 해결
• 반정규화 고려시 재현의 적시성이 중요하다 빌링의 잔액은 다수 테이블-다량 조인이 불가피해서 재현의 적시성 위해 필수 반정규화 대상
• 반정규화 이유
  • 데이터 조회시 디스크 I/O량이 많아 성능 저하
  • 경로가 너무 멀어 조인으로 인한 성능 저하
  • 칼럼 계산하여 읽을 때 성능 저하
• 로우체이닝이 발생할 정도로 한 테이블에 많은 칼럼이 있으면 디스크 I/O로 인한 성능 저하가 일어날 수 있으므로 트랜잭션이 접근하는 컬럼의 유형을 분석하고 빈도별로 구분하여 1:1 테이블로 분리한다
• 반정규화로 인한 성능 향상 쇼핑몰 결제창에서 최근 결제정보를 띄우려할 때, 고객번호가 주문테이블에만 있고 결제 테이블에 없다면 조인이 필요하다. 하지만 반정규화로 결제테이블에 고객번호를 추가하면 조인으로 인한 성능 부하를 개선할 수 있다. 더 나아가 고객번호 + 결제수단구분코드 + 결제일시로 인덱스를 생성하면 Index Range Scan Descending으로 1건의 제일 최근 데이터만 읽을 수 있다
• 반정규화로 인한 성능 저하 쇼핑몰의 배송 정보를 빠르게 불러오려고 주문 테이블에는 없고 배송 테이블에만 있던 송장번호를 주문 테이블에 반정규화하면 조회는 빨라지지만 처음 주문 엔터티 생성시 넣을 수 없는 데이터라 갱신 로직이 필요하다(불필요할 뿐 아니라 클라우드 시스템의 과금이 늘어나는 로직이라고 할 수 있다)

테이블의 반정규화

집계 테이블, 다수 테이블의 키 연결 테이블 등 다양한 유형에 적용 가능

1. 테이블 병합
   • 1:1 관계
   • 1:M 관계
   • 슈퍼/서브타입
     • 슈퍼/서브 타입 데이터 모델의 변환 기술
       • 개별 발생 트랜잭션: 개별 테이블
       • 슈퍼/서브타입에 대한 트랜잭션: 슈퍼 + 서브타입 테이블
       • 전체를 하나로 묶어서 트랜잭션: 한 테이블
2. 테이블 분할
   • 수직
   • 수평
3. 테이블 추가
   • 중복테이블
   • 통계테이블
   • 이력테이블
   • 부분테이블: 한 테이블 중 자주 이용하는 집중화된 컬럼이 있을 때, 디스크 I/O 줄이기 위해 해당 칼럼을 별도로 모으는 기법

칼럼의 반정규화

1. 중복칼럼 추가: 조인 감소
2. 파생칼럼 추가
3. 이력테이블 칼럼 추가: 최신값을 처리하는 이력의 특성 고려
4. PK에 의한 칼럼 추가
5. 응용시스템 오작동을 위한 칼럼 추가

반정규화 절차

1. 반정규화 대상 조사
   • 범위처리 빈도수
   • 대량의 범위 처리
   • 통계성 프로세스
   • 테이블 조인 개수
2. 다른 방법 유도 검토
   • 뷰 테이블: 다량의 조인 필요
   • 클러스터링: 대량의 데이터 처리, 부분처리
   • 인덱스 조정: 대량의 데이터 처리, 부분처리
   • 파티셔닝: PK에 따라 다르지만 대량 데이터 부분 테이블로 분리 논리적으로 한 테이블이지만 물리적으로 분리한다
   • 응용 애플리케이션: 로직 구사방법 변경-
3. 반정규화 적용
   • 테이블
   • 속성
   • 관계

성능 데이터모델링

DB 성능 향상 목적으로 설계 단계의 데이터모델링부터 성능을 고려한다

• 문제 발생 시점의 SQL보다 데이터 모델의 튜닝으로 성능을 개선한다
• 성능을 튜닝하면서 데이터모델링 개선 가능
• 성능 저하에 따른 재작업 비용을 낮출 수 있음

성능 데이터 모델링 절차

1. 정규화
2. DB용량 산정
3. 트랜잭션 유형 파악
4. 용량/트랜잭션 고려한 반정규화
5. 이력모델 조정, PK/FK 조정, 슈퍼타입/서브타입 조정
6. 성능관점에서 데이터모델 검증

계층형 데이터 모델

계층 구조를 가진 데이터

• EMP 엔터티에서 사원의 관리자를 MGR로 표현하고 데이터값은 EMPNO를 넣는다. 그러면 한 사원의 관리자를 찾으려면 셀프 조인이 필요하다. 관계를 맺으면 식별자를 상속하는데, 이 때 상속된 식별자가 바로 MGR. MGR은 어차피 EMPNO이므로 둘을 맵핑한다
• SELECT B.ENAME FROM EMP A, EMP B
  WHERE A.ENAME = 'SMITH' AND A.MGR = B.EMPNO;
• 사원간 관계나 쇼핑몰 카테고리 정보 등이 이에 속한다
• 상호 배타적 관계: Exclusive-OR 개인고객과 법인고객이 있을 경우, 한 주문에 대해 개인고객과 법인고객 중 하나만 관계를 맺는다

트랜잭션

데이터베이스의 논리적 연산단위

• 계좌이체
  1. 송금계좌에서 이체금액 차감
  2. 입금계좌에서 이체금액 가산
  위 두 단계가 모두 실행되든지 모두 취소 되든지 해야 데이터 정합성에 부합한다
• 두 개가 한 트랜잭션으로 처리되어야 한다
• 커밋의 단위가 한 트랜잭션이어야 한다
• 부모-자식간 필수 관계라면 부모와 자식 레코드 입력이 한 트랜잭션이어야 한다.

NULL 속성의 이해

• Null 값의 연산은 언제나 Null이다아직 정의되지 않은 미지의 값으로 현재 데이터를 입력하지 않은 것이다
• 어떤 값보다 크다/작다로 표현할 수 없다
• Null은 공백도 아니고, 0도 아니다
• NULL로 가능한 연산은 IS (NOT) NULL뿐
• 집계함수는 Null 값을 제외하고 처리한다
• SUM, AVG, COUNT 등...
• Null값과의 비교 연산은 False
• INSERT INTO exam VALUES('001', ''); 오라클은 두 번째 칼럼이 NULL로 입력되지만 SQL서버는 ''로 입력된다 오라클은 WHERE 2nd_Col IS NULL로 조회해야 하고 SQL서버는 WHERE 2nd_Col = ''로 조회해야 한다
• WHERE GRADE IN ('A', 'B', NULL)로 찾아도 NULL값이 출력되지 않는다
• GRADE가 A, B, C, D, E, NULL로 배정된 데이터들이 있을 때, SELECT COUNT(*) FROM EMP GROUP BY GRADE; 하면 A, B, C, D, E, NULL을 센 6이 답이다 COUNT(*)는 NULL값도 세기 때문

본질식별자 vs. 인조식별자

식별자: 엔터티에서 데이터를 식별할 수 있는 속성으로 반드시 필요하다

• 본질: 업무에 의해 만들어진 식별자
• 인조: 본질식별자가 복잡한 구성이라 인위적으로 만든 식별자 식별자 구조를 단순화하여 SQL조인도 단순화함 데이터 모델 변경에 따른 유연성, 확장성이 좋지만 업무정의에 위배되는 데이터 입력이 가능하다(본질식별자를 대체키로 하고 고유키 제약주면 됨) 남용할 경우 성능이 저하될 수 있다 본질식별자는 조인과 필터링을 함께하지만 인조식별자는 조인 후 필터링을 한다(인조식별자는 인덱스를 하나 이상 더 생성해서 저장공간이 많이 필요하고 DML 속도가 느리다) NULL 입력 가능 본질식별자 값이 변경될 수 있을 때 사용

외부식별자(FK)의 문제점

1. 중복 데이터로 인한 품질 문제

외부식별자 사용시 중복 데이터를 막을 수 없다.

만약 PK를 .NEXTVAL을 사용하고 주문번호를 FK로 하는 INSERT문이 에러로 인해 중복으로 발생되었다면,

PK는 자동으로 +되어 중복 삽입이 가능하고

그래서 같은 주문번호를 가진 데이터가 오류 없이 생성될 수 있다

DBMS에서 중복 데이터를 못 막아주니까 애플리케이션에서 방어해야 한다

최대한 본질식별자를 쓰는 게 좋음

> A.NEXTVAL은 A의 다음 값을 말한다

2. 불필요한 인덱스 생성

본직식별자는 PK 인덱스 사용

인조식별자는 인덱스의 추가 생성 필요

 

기타

• 인덱스는 값의 범위에 따라 일정하게 정렬됨범위조회 유형이 그 다음에 위치
• 상수값으로 =조건으로 조회되는 칼럼이 첫번째
• 0/300 = 0 300/0은 에러가 난다(분모 0은 에러)
• 엔터티간에 논리적 관계가 있다면(엔터티 간에 관계를 정의하여 상호 업무적 연관성 있음) 업무적 관련성으로 조인이 자주 발생한다데이터 모델에서는 관계를 연결하고 DB에 FK 제약을 생략했어도 조인이 필요하므로 인덱스 생성은 필요하다
• 이 때, DBMS가 제공하는 FK 제약 생성과 무관하게 조인 성능 향상 위한 인덱스 설정이 좋음
• 분산DB공통코드, 기준 정보 등 마스터 데이터는 분산DB에 복제분산한다
  • 장점
    • 지역 자치성
    • 점증적 시스템 용량 확장, 시스템 규모의 적절한 조절
    • 신뢰성, 가용성
    • 효용성, 융통성, 각 지역 사용자의 요구 수용 증대
    • 빠른 응답 속도, 통신비용 절감, 실시간 업무처리
    • 백업 사이트 구성
  • 단점
    • SW 개발 비용, 처리 비용
    • 설계, 관리 복잡성/비용
    • 통제 어려움, 오류의 잠재성 증가
    • 데이터 무결성 위협
    • 불규칙한 응답 속도
• cf) GSI(global single instance): 통합DB
• 데이터가 여러 곳에 분산되어 있지만 한 DB처럼 사용한다
  • 테이블은 칼럼과 행의 2차원 구조데이터 모델상 엔터티를 관계형 DB에서 물리적으로 구현
  • 데이터를 저장하는 객체
  • 칼럼은 테이블의 세로 구조
  • 데이터 모델의 속성
  • 행은 테이블의 가로 구조따지자면 인스턴스
  • 테이블에 저장된 개별 데이터
• 순수관계 연산자를 SQL로 바꾸면?
  • SELECT => WHERE
  • PROJECT => SELECT
  • NATURAL JOIN => 다양한 JOIN
  • DIVIDE => 이제 사용하지 않는다
• 한 주문에 같은 상품을 여러번 주문할 수 있을까?
  • 주문과 상품을 잇는 엔터티인 주문상세
    주문에서 받은 주문번호 FK와 상품에서 받은 상품번호 FK 두 개를 주문상세의 주식별자로 쓴다
    고객과 주문은 1:M 주문 선택. 비식별
    주문과 주문상세는 1:M.
    상품과 주문상세는 1:M 주문상세 선택.
    한 주문에 여러 상품 주문 가능동일 상품 여러번 주문 가능한 주문에 같은 상품 여러번 주문할 수는 없음(상품번호가 주식별자라)고객은 한 번 이상 주문 가능
  • 주문번호 FK와 내부식별자 주문순번 두 개를 주식별자로 쓴다
    한 주문에 같은 상품 여러번 주문 가능(주문순번이 다르기 때문)