Intro
SQLD 시험이 5일도 안남았다!
다시 한 번 정리해보자 😎👍
벼락맞기 여러분 모두 화이팅~!!
데이터 모델의 이해
모델
현실 세계에서 일어날 수 있는 다양한 현상을 일정한 표기법에 의해 표현해놓은 모형
모델링
현실 세계를 추상화, 단순화, 명확화하여 표현하는 기법
모델링의 특징
- 추상화
- 현실 세계를 일정한 현식으로 표현
- 아이디어나 개념을 간략하게 표현
- 단순화
- 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현
- 명확화
- 불분명함을 제거하고 명확하게 해석할 수 있도록 기술
모델링의 세가지 관점
- 데이터 관점
- 데이터 위주의 모델링
- 데이터가 얽혀있는 업무와 데이터 간의 관계에 대해 모델링
- 프로세스 관점
- 프로세스 위주의 모델링
- 이 업무의 현재와 미래에 대해 모델링
- 데이터와 프로세스의 상관 관점
- 데이터와 프로세스의 관계를 위주로 한 모델링
- 프로세스의 흐름에 따라 데이터가 받는 영향에 대해 모델링
모델링의 세가지 단계
- 개념적 데이터 모델링
- 추상화 레벨이 가장 고점
- 업무 중심적이고 포괄적인 수준의 모델링이 진행
- 논리적 데이터 모델링
- 재사용성이 가장 높은 모델링
- 모델에 대한 Key, 속성, 관계 등을 모두 표현
- 물리적 데이터 모델링
- 실제 데이터베이스로 옮기는 단계
- 성능과 가용성 등의 물리적인 성격 고려
데이터
데이터의 품질
- 중복
- 같은 데이터가 엔티티에 중복으로 저장되는 현상을 지양
- 비유연성
- 애플리케이션의 사소한 변경에 데이터 모델이 자주 변경되는 것을 지양
- 데이터 모델과 프로세스를 분리하여 유연성을 높임
- 비일관성
- 연관성을 고려하지 않고 데이터를 변경할 가능성
- 데이터 간의 연관 관계에 대해 명확하게 정의 지향
데이터의 독립성
-
ANSI-SPARC
-
3단계 스키마 구조
- 외부 스키마
- 각 사용자가 보는 데이터베이스의 스키마를 정의
- 개념 스키마
- 모든 사용자가 보는 데이터베이스의 스키마를 통합
- 데이터베이스에 저장되는 데이터 들을 표현하고 데이터 간의 관계를 나타냄
- 내부 스키마
- 물리적인 저장 구조
- 실질적인 데이터의 저장 구조, 컬럼 정의, 인덱스 등이 포함
-
3단계 스키마 구조가 보장하는 독립성
- 논리적 독립성
- 개념 스키마가 변경되어도 외부 스키마에는 영향을 주지 않는다.
- 물리적 독립성
- 내부 스키마가 변경되어도 외부/개념 스키마에는 영향을 주지 않는다.
ERD
시스템에 어떤 엔티티들이 있고, 그들 간 어떤 관계가 있는지를 표현
ERD 작성 순서
- 엔티티를 도출하고 그린다.
- 엔티티를 적절하게 배치한다.
- 엔티티 간 관계를 표현한다.
- 관계명을 기입한다.
- 관계의 참여도를 기입한다.
- 관계의 필수 여부를 기입한다.
엔티티
식별이 가능한 객체
업무에서 쓰이는 데이터를 용도 별로 분류한 그룹
엔티티의 특징
- 업무에서 쓰이는 정보여야 함
- 유니크함을 보장할 수 있는 식별자가 있어야 함
- 2개 이상의 인스턴스를 가지고 있어야 함
- 반드시 속성을 가지고 있어야 함
- 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함
엔티티의 분류
- 유무형에 따른 분류
- 발생 시점에 따른 분류
- 기본 엔티티
- 업무에 원래 존재하는 정보
- 독립적으로 생성, 자식 엔티티를 가질 수 있음
- 중심 엔티티
- 기본 엔티티로부터 파생, 행위 엔티티 생성
- 업무에 있어 중심적인 역할
- 데이터의 양 많음
- 행위 엔티티
- 2개 이상의 엔티티로부터 파생
- 데이터가 자주 변경/증가
엔티티 명명 규칙
- 업무에서 실제 사용하는 용어
- 한글은 약어를 금하고, 영어는 대문자로 표기
- 단수 명사, 띄어쓰기 X
- 다른 엔티티와 의미상으로 중복될 수 없음
- 해당 엔티티가 가지고있는 데이터가 무엇인지 명확하게 표현
속성
사물이나 개념의 특징을 설명해 줄 수 있는 것
- 의미 상 더 쪼개질 수 없음
- 프로세스에 필요한 항목
속성값
- 각각의 속성은 속성값을 가짐
- 하나의 속성에 속성값이 여러개라면 별도의 엔티티로 분리하는 것이 바람직
속성의 분류
- 특성에 따른 분류
- 기본 속성
- 업무 프로세스 분석을 통해 바로 정의 가능한 속성
- 설계 속성
- 업무에 존재 X
- 그러나 설계 시 필요하다 느껴 도출된 속성
- 파생 속성
- 다른 속성값을 계산/특정 규칙으로 변형하여 저장한 속성
- 구성방식에 따른 분류
도메인
속성이 가질 수 있는 속성값의 범위
용어사전
- 속성의 이름을 정확하고 직관적으로 부여
- 영어의 혼란 방지
시스템 카탈로그
- 시스템 자체에 관련이 있는 데이터 저장 (메타데이터)
- 시스템 테이블로 구성, SQL로 조회 가능
관계
앤티티와 엔티티 간의 관계
존재 관계
행위 관계
표기법
식별자
엔티티가 가진 속성 중 인스턴스를 구분 가능하게 해주는 대표격인 속성을 의미한다.
주식별자
- 기본티(PK)에 해당
- 1개 이상의 속성이 주식별자가 된다
- 유일성
- 최소성
- 불변성
- 존재성
식별자의 분류
- 대표성 여부
- 주식별자
- 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자
- 다른 엔티티와 참조관계 연결
- 보조식별자
- 인스턴스 식별가능 But 대표 식별자가 아님
- 다른 엔티티와 참조관계 연결 X
- 스스로 생성되었는지 여부
- 내부식별자
- 외부식별자
- 다른 엔티티에서 생성
- 다른 엔티티와의 연결고리
- 단일 속성의 여부
- 대체 여부
- 원조/본질식별자
- 대리/인조식별자
- 주식별자의 속성이 2개 이상인 경우
- 속성을 하나로 묶어 사용
식별자/비식별자 관계
- 식별자 관계
- 부모 엔티티의 식별자가 자식 엔티티의 주식별자
- 자식 엔티티는 부모 엔티티가 있어야 생성이 가능
- 단일/복합 여부에 따라 1:1/1:N이 결정
- 비식별자 관계
- 부모 엔티티의 식별자가 자식 엔티티의 일반속성
- 부모 엔티티가 없어도 자식 엔티티를 생성할 수 있음
- 자식 엔티티가 존재할 때 부모 엔티티를 삭제할 수 있음
정규화
데이터의 정확성과 일관성을 유지하고 보장하기 위헤 엔티티를 작은 단위로 분리하는 과정
데이터의 조회 성능은 향상되는 경우도, 저하되는 경우도 있음
다만 입력, 수정, 삭제 성능은 일반적으로 향상
제 1정규형
제 2정규형
- 모든 속성은 모든 주식별자에 종속되어야 한다
- 주식별자가 복합식별자인 경우 신경써줘야 함
- 일부 속성이 주식별자의 일부에만 종속될 수 있음
제 3정규형
- 주식별자가 아닌 모든 속성간의 종속은 허용하지 않는다
정규화의 주의사항
- 지나친 정규화는 되려 불필요한 성능저하가 일어날 수 있음
반정규화
일반적으로 데이터의 조회 성능을 향상시키기 위해 시행
데이터의 중복을 허용/데이터를 그룹핑하는 과정
조회 성능은 향상될 수 있으나 입력, 수정, 삭제 성능은 저하될 수 있다
데이터 정합성 이슈가 일어날 수도;;
반정규화는 정규화가 끝난 뒤 시행
테이블 반정규화
- 테이블 병합
- 업무 프로세스 상 JOIN이 많은 경우 시행
- 1:1 관계 테이블 병합
- 1:N 관계 테이블 병합
- 슈퍼 서브타입 테이블 병합
- 테이블 분할
- 테이블 수직 분할/속성 분할
- 엔티티의 일부 속성을 병도의 엔티티로 분할
- 자주 사용하는 속성이 아닐 때
- 대부분의 인스턴스가 해당 속성값을 NULL로 가질 때
- 테이블 수평 분할/인스턴스 분할/파티셔닝
- 엔티티의 인스턴스를 특정 기준으로 분할(파티셔닝)
- 테이블 추가
- 중복 테이블 추가
- 데이터의 중복을 감안
- 성능사아 반!드!시! 필요하다 판단할 경우 별도의 엔티티로 추가
- 통계 테이블 추가
- 속성값을 계산하여 별도의 엔티티의 속성으로 관리
- 이력 테이블 추가
- 부분 테이블 추가
- 자주 요구되는 기능에 필요한 속성을 뽑아 테이블로 관리
컬럼 반정규화
- 중복 컬럼 추가
- 업무 프로세스에서 JOIN이 많을 때 성능 측면을 고려
- 파생 컬럼 추가
- 이력 테이블 컬럼 추가
관계 반정규화
JOIN이 많을 때 성능 측면을 고려
트랜잭션
데이터를 조작하기 위한 하나의 논리적인 작업 단위
NULL
존재하지 않음, 값이 없음
NULL의 연산
- 가로 연산
- NULL이 포함되어 있으면 결과값이 NULL이 된다
- 세로 연산
- 다른 인스턴스의 데이터와 연산할 때는 NULL을 제외한다.