유튜브 강의 정리본 입니다
1과목 1단원, 데이터 모델의 이해
기초 용어
- DB : 데이터의 집합
- DBMS : 데이터를 보다 잘 관리하기 위해 만든 시스템
- ex) Oracle, MSSQL ...
1. 데이터 모델링
정의 : 현실의 데이터 요구사항을 구조화/단순화시키는 과정 => 관계를 정의
특징 : 추상화(일정한 형식으로), 단순화(단순하고 쉽게), 명확화(불분명함을 제거하여)
1-1. 용어
Table(Entity) : 엑셀의 표와 유사한 개념
논리적 - Entity, Attribute, Instance
물리적 - Table, Column, Row
1-2. 데이터 모델링의 세 관점
데이터 관점: 업무간, 업무와 데이터간의 관계를 모델링
프로세스 관점: 업무의 프로세스 상에서 무엇이 필요한지, 무엇을 해야하는지를 모델링
데이터와 프로세스 관점: 업무 프로세스에 따라 각 데이터가 받는 영향을 모델링
1-3. 데이터 모델링의 3가지 요소
대상(Entity): 업무가 관리하고자 하는 대상
속성(Attribute): 대상이 갖는 속성
관계(Relationship): 대상과 대상 사이의 관계
1-4. 데이터 모델링의 3단계
1단계 : 개념적 모델링
- 필요한 데이터를 개념적으로 설계
- 업무 분석 후 핵심 엔터티를 추출, 이들 간의 관계를 표현하기 위해 ERD를 작성
- 특징 : 업무 중심적, 포괄적
2단계 : 논리적 모델링
- 개념적 모델링을 토대로 세부속성, 식별자, 관계 등을 표현
- 데이터 정규화(데이터를 어떻게 분리할지) 수행
- 재사용성이 높음
3단계 : 물리적 모델링
- 설계한 것을 바탕으로 물리적으로 (실제 데이터 베이스를) 만드는 과정
- 성능, 저장구조, 보안성, 권한 등을 규정
아래로 갈수록 구체화, 위로갈수록 추상화
cf. 유의점
중복(중복 데이터 지양), 비유연성(유지보수가 쉽게), 비일관성(타 데이터와의 연관성 고려) )-> 이것들을 피해야 함
2. 스키마의 3단계 구조
개념
- 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합
=> 모든 객체들에 대한 정보
1단계 : 외부 스키마
사용자가 보는 관점에서, 업무적인 관점에서 필요한 데이터를 정의 (사용자가 접근하는 대상)
2단계 : 개념 스키마
데이터베이스의 전체 논리적 구조를 정의
전체 데이터베이스의 개체, 속성, 관계, 데이터 타입 등을 정의
3단계 : 내부 스키마
물리적으로 어떻게 저장되는지를 정의
데이터의 저장 구조, 컬럼, 인덱스 등을 정의
2-1. 3단계 스키마의 독립성
독립성 : 한쪽이 바뀌어도 다른쪽(응용 프로그램)에 영향을 주지 않는 특성
- 논리적 독립성 : 논리적 데이터구조가 바뀌어도(개념 스키마가 달라져도) 응용 프로그램에 영향을 주지 않는 특성
- 물리적 독립성 : 물리적 구조가 변경되어도(내부 스키마가 달라져도) 응용 프로그램에 영향을 주지 않는 특성
2-2. 데이터 모델의 표기법 (ERD: Entity Relationship Diagram)
논리적 설계 단계에서 만들어지는 엔터티와 이들의 관계를 시각적으로 표현한 다이어그램
2-3. ERD 작성 절차 (6단계)
- 엔터티를 도출한 후 그린다
- 엔터티 배치
- 엔터티 간의 관계를 설정
- 관계명을 설정
- 관계의 참여도 기술
- 관계의 필수 여부를 확인
1과목 2단원, 엔터티
엔터티 : 독립적으로 식별 가능한 객체나 사물 => 대상
- 인스턴스(행)와 속성(열)으로 구성
ex)
엔터티(Entity) : Student
속성(Attribute) : id, name, department
인스턴스(Instance)
- id : 20233022
- name : 박호건
- department : 글로벌미디어학부특징
- 식별자가 요구됨 (식별자 ~= 변수명)
- 유일성이 보장되어야 함 - 업무에서 관리하고자하는 정보
- 인스턴스들의 집합
- 인스턴스가 하나 있다면 DB를 쓸 이유가 없음 - 엔터티는 속성을 가짐
- 2개 이상의 속성을 가짐 - 업무 프로세스에 의해 이용
- 안쓰이면 지워야 - 다른 엔터티와 최소 1개 이상의 관계 성립
- 관계가 없다면 도출 과정에 문제가 있는 것
분류
유형과 무형에 따른 분류
- 유형엔터티 : 물리적 형태가 있음 (ex. 사원, 물품 ...)
- 개념엔터티 : 물리적인 형태가 없음 (ex. 조직, 보험상품 ...)
- 사건엔터티 : 업무를 수행함에 따라 발생하는 엔터티 (ex. 주문, 청구 ...)
발생 시점에 따른 분류
기본 엔터티
- 원래 존재하는 정보
- 독립적으로 생성 (다른 엔터티의 관계로 생성되는게 아님)
- 자신의 고유한 주식별자를 가짐 (주식별자를 상속받지 않음)
- ex) 사원, 부서, 고객, 상품 ...
중심 엔터티
- 기본엔터티로부터 발생되고 그 업무에서 중심적인 역할
- ex) 계약, 사고, 청구, 주문, 매출 ...
행위 엔터티 <- 중심 엔터티의 확장
- 2개 이상의 부모엔터티로부터 발생
- 자주 내용이 바뀌거나 데이터 양이 증가
- ex) 주문(<-고객,상품), 사원변경이력
엔터티의 명명
현업에서 사용하는 용어
가능하면 약자 사용을 자제
단수 명사 사용
유일성을 가져야 함
생성 의미대로 이름 부여
엔터티 & 인스턴스 표기법
엔터티 : 사각형
관계 : 선
속성
- IE 표기법 : 엔터티 이름 밑에 주식별자, 그 밑에 일반 속성 나열
- Barker 표기법 : 엔터티 이름 밑에 속성 표기
- 주식별자는 앞에#을 붙임
- 그 외 nullable 등 역시 앞에 뭘 붙여서 표기
1과목 3단원, 속성
속성의 개념
업무적으로 필요로하는 고유한 성질, 특징을 의미
더 이상 분리되지 않는 최소의 데이터 단위
ex) 학생 - 신상정보 - 이름, 학번, 학과 <- 신상정보가 이름, 학번, 학과로 분리될 수 있음
-> 신상정보는 속성이 아니고 이름, 학번, 학과는 속성에 해당함
엔터티, 인스턴스, 속성의 관계
한 개의 엔터티는 2개 이상의 인스턴스 집합이어야 한다
한 개의 엔터티는 2개 이상의 속성을 갖는다
한 개의 속성은 1개의 속성값을 갖는다
특징
업무에서 필요해야함
주식별자에 함수적 종속성을 가져야 함
- ex) 학생의 주식별자 : 학번, 학번에 의해 결정되는 요인이어야 함. = 학번에 함수적 종속성을 띈다.
- 학번이 다르면 이름이 다름 -> 이름은 학번에 함수적 종속성을 띔
원자성 : 인스턴스가 해당 속성에 대해 단일하고 명확한 값을 가지는 것 - 각 속성은 하나의 값을 가짐
함수적 종속성
- 어떤 속성의 값에 의해 다른 속성도 유일하게 결정되는 것 => 함수 종속 관계
완전 함수적 종속 - PK를 구성하는 컬럼이 2개 이상일 경우, PK 값 모두에 의한 종속관계를 나타낼 때
- ex) 쇼핑을 한다고 가정해보자. 주문번호와 상품번호가 있음 -> 수량은 2개 모두를 봐야 알 수 있겠지
부분 함수적 종속 - 기본키 일부에 대해 종속될 때
- ex) 인강을 본다고 가정해보자. 학생ID와 과목이 PK겠지만, 강사 이름은 오직 과목에만 종속됨
분류
특성에 따른 속성
기본 속성 : 업무로 부터 추출된 모든 속성 (사실상 가장 많음)
설계 속성 : 업무를 규칙화할 때 새로 만들어지는 속성 (ex. 상품코드, 지점코드)
파생 속성 : 기본/설계 속성에서 파생되는 속성 (일반적으로 계산된 값, ex. 합계, 평균, 이자 ...)
엔터티 구성방식에 따른 분류
PK(Primary Key, 기본키, 주식별자) : 인스턴스를 식별할 수 있는 속성
FK(Foreign Key, 외래키) : 다른 엔터티와의 관계에서 포함된 속성
일반 속성 : 그 외
분해 여부에 따른 속성
단일 속성 : 하나의 의미로 구성 (ex. 회원ID, 이름)
복합 속성 : 여러개의 의미로 구성 (ex. 주소 - 시, 구, 동 등으로 분해 가능)
다중값 속성 : 여러개의 값을 가질 수 있음 (ex. 구매한 상품 <- 하나의 고객이 여러개를 가지겠지)
속성의 명명규칙
- 업무에서 사용되어야
- 서술식으로는 사용되지 않음
- 약어 가급적 제한
- 유일한 명칭
도메인(Domain) - 속성이 가질 수 있는 값의 범위
- 속성에 대한 데이터 타입, 크기, 제약사항 지정
- ex) 중학교 - 학년 -
1, 2, 3
1과목 4단원, 관계
관계 : 엔터티간의 연관성
- 인스턴스간의 연관성을 파악하여 정의해야 함
관계의 종류
존재적 관계 : 하나의 엔터티가 다른 엔터티의 존재에 영향을 줌
- ex) 사원 - 부서, 부서가 사라지면 사원은...
행위적 관계 : 엔터티간의 행위를 의미 - ex) 고객 - 주문, 주문이 사라진다고 고객이 사라지는건 아님
cf. ERD에서는 존재적 관계와 행위적 관계를 구분하지 않음
관계의 구성
- 관계명 (ex. 수강 이력)
- 차수 (Cardinality, 1:1, 1:多 ...)
- 선택성 (Optionality, 필수 여부)
관계의 차수
관계가 어떤식으로 연결되는지
- 1 대 1 관계
- 완전 1 대 1 관계
- 선택적 1 대 1 관계 - 1대 N 관계
- ex) 하나의 개체에 여러 사원이 종속 - N 대 N 관계
- 카테시안 곱이 발생함
- 카테시안 곱(Cartesian Product) : join의 WHERE 조건절이 잘못 기술되거나 없을 경우, 두 테이블의 행의 개수의 곱 만큼의 결과값이 산출됨 <- 조합폭발 같은 느낌인듯
- 관계 엔터티를 하나 더 둬서 1대 N 관계로 해소하는 것이 모범적
- ex) 학생 - 강의는 多 : 多 관계 => 학생 - 구매이력 (1 : 多) + 구매 이력 - 강의 (1 : 多)
관계의 페어링
엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것
관계 : 학생 - 강의
- 학생 테이블의과 강의 테이블의 카디널리티가 각각 N과 M이라면 차수는 N:M
-> 학생 A가 강의 B를 1월에 수강했고 성적은 A+을 받았다와 같은 페어링이 형성
1과목 5단원, 식별자
식별자의 개념
- 엔터티를 대표할 수 있는 속성
- 유일한 식별자가 존재해야 함
식별자는 논리 모델링에서 사용하는 용어, 물리 모델링에서는키(key)라고 표현
주식별자 특징
- 유일성, 최소성(최소한의 속성), 불변성, 존재성(값이 존재해야 함 = Null을 허용하지 않음)
식별자 분류
대표성 여부에 따른 분류
- 주식별자
- 대표성을 가짐
- 유일성, 최소성 만족
-> 참조관계 연결 - 보조식별자
- 대표성을 갖지 않음
- 유일성과 최소성 만족
-> 참조관계 연결 불가
주민번호가 학생의 식별자가 될 수 있겠지만, 보통은 학번을 쓰겠죠? -> 주식별자 : 학번, 보조식별자 : 주민번호
생성 여부에 따른 분류
- 내부식별자 : 타 엔터티 참조 없이 스스로 생성
- 외부식별자 : 타 엔텉티와 갖는 관계로 만들어지는 식별자 (외래키)
속성 수에 따른 분류
- 단일식별자 : 하나의 속성
- 복합식별자 : 2개 이상
대체 여부에 따른 분류
- 본질식별자 (원조식별자) : 비지니스 프로세스에서 만들어지는 식별자
- 인조식별자 : 인위적으로 만들어지는 식별자, ex) AUTOINCREMENT, Hash, UUID
식별자 표기법
주식별자 도출 기준
업무에서 자주 이용되는 속성을 주식별자로 지정
가급적 명칭이나 내역같은 이름은 피함
코드를 부여하여 주식별자로 사용
속성의 수를 최소한으로 구성 (7~8개 이상의 주식별자 구성은 인조식별자를 만드는게 나음)
관계간 엔터티 구분
강한 개체
- 보다 독립적으로 존재할 수 있는 엔터티
- ex) 고객과 계좌가 있다면 고객은 강한 개체
약한 개체
- 독립적으로 존재할 수 없는 엔터티
- ex) 고객과 계좌가 있다면 계좌는 약한 개체
식별 관계와 비식별 관계
식별관계 : 하나의 엔터티의 기본키를 다른 기본키로 공유
- ERD서 실선으로 표시
비식별관계 : 강한 개체의 기본 키를 다른 엔터티의 일반 속성으로 관계를 가짐 - ERD서 점선으로 표시
- ex) : 사원서의 부서번호는 비식별관계
Key의 종류
기본키(Primary Key)
- 엔터티를 대표할 수 있는 키
후보키 (Candidate Key)
- 유일성과 최소성을 만족하는 키
- 후보키 중 하나가 기본키가 되고 나머지는 대체키가 됨
슈퍼키(Super Key)
- 유일성은 만족하지만 최소성을 만족하지 않는 키
- (학번 + 이름)이 있다면 슈퍼키 (학번만 있어도 되니까)
대체키(Alternate Key)
- 여러 후보키 중 기본키가 아닌 키
외래키(Foreign Key)
- 다른 테이블의 기본키를 참조하는 키
1과목 6단원, 정규화
개념
- 최소한의 데이터만을 하나의 엔터티에 넣는식으로 데이터를 분해하는 과정
- 중복 제거, 데이터 모델의 독립성 확보 -> 이상현상을 줄이기 위함
- 이상현상 : 정규화를 하지 않아 발생하는 현상
- 삽입 이상 : 정의하지 않아도 될 속성까지 반드시 입력해야하는 상황
- 갱신 이상 : 중복되는 데이터 중 일부만 수정되어 모순이 발생하는 상황
- 삭제 이상 : 어떤 정보를 삭제할 때, 의도하지 않은 다른 정보까지 삭제되어버리는 현상 - 논리 데이터 모델링 수행 시점에서 고려됨
- 5정규화까지 있지만 실질적으로는 3 정규화까지만 수행
정규화의 단계
제 1 정규화
테이블의 컬럼이 원자성을 갖도록 테이블을 분해
제 2 정규화
제 1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만들도록 테이블을 분해
완전 함수 종속 : 기본 키를 구성하는 컬럼의 값이 다른 컬럼을 결정짓는 상태 => PK와 나머지가 1:1 대응되어야
위에 있는 테이블의 PK는 학생 번호와 강의명
- 하지만 학생 번호에 의해 강의실이 결정되는 것이 아님, 강의명과 성적의 관계도 마찬가지
- 따라서 기본 키인
학생번호와강의명에 따라 나머지 컬럼이 결정되도록 분해
=> 제 2 정규화
제 3 정규화
제 2 정규화를 진행한 테이블에 대해 이행적 종속을 없에도록 테이블을 분리
- 이행적 종속 : A -> B, B -> C 관계가 성립할 때, A -> C가 성립되는 것
- 즉, 제 3 정규화는 (A,B)와 (B,C)로 테이블을 분리하는 과정
- 고객 번호 -> 상품명, 상품명 -> 가격
=> (고객 번호, 상품명), (상품명, 가격)으로 분리
cf. BCNF 정규화, 제 4 정규화, 제 5 정규화
BCNF(Boyce-Codd Normal Form) 정규화
- 모든 결정자가 후보키가 되도록 테이블을 분해하는 것 (결정자가 후보키가 아닌 다른 칼럼에 종속되면 안됨)
제 4 정규화 - 여러 컬럼들이 하나의 컬럼을 종속시키는 경우 분해하여 다중값 종속성을 제거
제 5 정규화 - 조인에 의해서 종속성이 발생되는 경우 분해
반정규화(역정규화, De-Normalization)
- 정규화된 데이터 모델을 중복, 통합, 분리하는 데이터 모델링 기법
- DB의 성능 향상을 위해 데이터 중복을 허용하고 조인을 줄이는 데이터베이스 성능 향상 방법
- 조회(SELECT) 속도는 향상됨 / 데이터 모델의 유연성은 낮아짐
- 비정규화(처음부터 정규화를 수행하지 않는 것)를 하는 것은 아님
- (어차피 계속 JOIN해서 쓸거면 합쳐두는게 낫잖아)
수행 케이스 - 속도가 느려지는 경우
- 다량의 범위를 자주 처리해야 하는 경우
- 특정 범위의 데이터만 자주 처리하는 경우
- 요약/집계 정보가 자주 요구되는 경우
내가 시도하는 정규화
UNF(비정규형)
1NF(제 1 정규형)
2NF(제 2 정규형)
3NF(제 3 정규형)
1과목 7단원, 관계와 조인의 이해
관계 : 엔터티간의 연관성 ~= 페어링(인스턴스간의 연관성)
관계를 맺는다 = 부모의 식별자를 자식에게 상속하고, 상속된 속성을 매핑키(조인키)로 활용
관계의 분류
존재 관계 : 엔터티간의 상태 (ex. 사원과 부서 관계)
행위 관계 : 엔터티 간의 행위 (ex. 고객과 주문 관계)
조인이 갖는 의미
정규화를 통해 분리된 데이터를 동시에 처리해야할 때, 관계가 있는 테이블을 참조하기 위해 연결하는 과정
100111의 관리점이 어디 있는지를 찾으려면
- 계좌 번호의 관리점 코드를 확인, 관리점 테이블에서 관리점 코드에 해당하는 관리점을 찾음
SELECT A.계좌번호, B.관리점 -- 4. 출력하고자 하는 정보를 작성
FROM 계좌 A, 관리점 B -- 1. 조인을 수행할 두 테이블 명시, 계좌의 별칭(ALIAS)은 A, 관리점은 B
WHERE A.관리점코드 = B.관리점코드 -- 2. 연결고리 작성 Oracle 표준
AND A.계좌번호 = '100111' -- 3. 일반 조건도 작성계층형 데이터 모델
SELF-JOIN, 즉 자기 자신끼리 관계가 발생
- 사원번호
7360을 가진 SMITH씨의 상위관리자는 사원번호7902를 가진 Ford씨. - 하지만 FORD씨 역시 상위관리자를 가짐
그러다 보니 SELF-JOIN이 발생할 수밖에 없다.
SELECT E1.ENAME AS 사원 이름,
E2.ENAME AS 매니저 이름
FROM EMP E1, EMP E2 -- 1. 테이블 명이 같기에 Table Alias가 필수적
WHERE E1.MGR = E2.EMPNO -- 2. E1은 사원의 정보를, E2는 매니저의 정보를 의미
상호베타적 관계
두 테이블 중 하나만 가능한 관계
1과목, 8단원, 모델이 표현하는 트랜잭션의 이해
개념
하나의 연속적인 업무 단위
트랜잭션에 의한 관계는 필수적인 관계 형태를 가짐
하나의 트랜잭션에는 여러 SELECT, INSERT, DELETE, UPDATE 등이 포함될 수 있음
ex) A 고객이 B 고객에게 100만원을 이체하려 한다면...
- A 고객의 잔액이 100만원 이상인지 확인
- 이상이면, A 고객 잔액을 -100 UPDATE
- B 고객 잔액에 +100 UPDATE
=> 이 과정은 동시에 수행되어야 함 = 모두 성공하거나 모두 취소되어야 함 = 필수적인 관계를 가짐
=> 절대 독립적으로 발생하면 안됨, 부분 커밋 불가 -> 동시 COMMIT / 동시 ROLLBACK
ERD서의 선택적 관계와 필수적 관계
IE 표기법 : 원을 이용 (선택적 관계서만 원을 그림)
바커 표기법 : 실선과 점선을 이용 (필수적 관계는 실선, 선택적 관계는 점선)
1과목 9단원, Null 속성의 이해
DBMS에서 아직 정해지지 않은 값을 의미 (0이나 빈 문자와는 다른 개념)
모델 설계시 컬럼별로 Null을 허용할지를 결정
Null의 특성
- Null을 포함한 연산 결과는 항상 NULL (연산하고 싶으면 Null을 치환 후 연산해야 함)
-
- NVL : Null 치환 함수, NVL(COMM, 0) = COMM 값이 Null이면 0으로 치환해서 계산해라 - 그룹 함수는 NULL을 제외하고 연산을 수행한다.
- SUM, AVG, MIN, MAX 등의 그룹 함수는 항상 NULL을 무시하고 연산
- COUNT는 NULL이 아닌 값의 수만 세지만 COUNT(*)은 모든 행의 수를 리턴
NULL의 ERD 표기법
IE 표기법에서는 NULL 허용 여부를 알 수 없음 (표기되지 않음)
바커 표기법에서는 속성 앞에 동그라미가 NULL 허용 속성을 의미함
1과목 10단원, 식별자 구분(대체 여부에 따른)
본질 식별자 : 업무에 의해 만들어지는(업무에 필요한) 식별자
인조 식별자 : 업무에 필요하지는 않지만 관리의 편의성 등을 이유로 인위적으로 만들어지는 식별자
4. PK : 주문번호 + 상품번호
- 본질 식별자가 됨
- 하나의 주문번호로 같은 상품의 주문 결과를 저장할 수 없음
5. PK : 주문번호 + 주문순번
- 하나의 주문에 여러 상품에 대한 주문 결과 저장 가능
- 
- 동일한 상품을 주문할 때마다 주문 횟수를 파악해야 함
6. PK : 주문상세번호(인조식별자 생성)
- 
- 중복 데이터 발생 가능성(1, 2번 주문 처럼 중복이 될 수 있으니)
- 불필요한 인덱스 생성 -> DML 성능 저하
cf. INDEX SPLIT : DML(INSERT/UPDATE/DELETE) 사용 시 인덱스도 모두 바꿔줘야하기에 인덱스 증가는 DML에 치명적
우왕 짱 도움 많이 되잖아?bb