SQL(Structured Query Language)
(1) 데이터 정의어(DDL) : 테이블 생성, 변경, 삭제
모델링 하는 이유
나는 친구가 없어 단추에게 이름을 붙여... "단추명"
단: 단순화(누구나 쉽게 이해)
추: 추상화(주요 특징을 간략 표현)
명: 명확화(모호함X)
데이터베이스의 모델링 단계
우리집 흰둥이가 놀고난 물 "개논물"
개:ERD 작성
논:정규화, 재사용성
물:물리적 구조
ERD 작성 순서 "도배설명차선"
엔터티 도출 → 배치 → 관계 설정 → 관계명 기술 → 관계 차수 기술 → 필수/선택사양 기술
순서 묻는 문제는 한번도 못봄...
스키마 구조(전체적인 설계도, 모델링 단계 이후 데이터 구조)
배성우 발표 수준 "외개내"
외: 사용자 입장
개: 전체적 논리 구조, 전체 사용자 입장
내: 물리적 저장장치 입장
독립성
1) 논리적 독립성
: 개념 스키마 변경 시, 외부 스키마 영향 없음
2) 물리적 독립성
: 내부 스키마 변경 시, 개념/외부 영향 없음
엔터티
유일한 식별자
인스턴스가 2개 이상
2개 이상의 속성 (1개인 특수경우도 있어 ㅠㅠ)
엔터티 분류
흰둥이가 생각하면? "개사유"
속성에 의해 B가 유일하게 결정됨 (A → B)
(2) 명명법 : 업무에 사용하는 명칭 사용, 서술식 표현 금지, 약어 사용 지양, 유일성(중복X)
속성의 분류
(1) 특성에 따른 분류
너 무슨 떡 좋아해? 난 "설기파"
1) 기본 속성 : 본래 가지고 있는 속성 (이름, 학번, 고객ID)
2) 설계 속성 : 필요로 인하여 도출된 속성 (주문번호, 일련번호)
3) 파생 속성 : 변형되어 만들어진 속성으로, 계산된 값들이 해당 (합계, 평균)
(2) 분해 가능 여부에 따른 분류
1) 단일 속성 : 하나의 의미로 구성 (이름, 학번)
2) 복합 속성 : 여러 개의 하위 속성으로 나눌 수 있음 (주소 → 시/도, 도로명, 건물번호)
3) 다중값 속성 : 여러 값을 가질 수 있으며, 별도 테이블로 분리 관리 (전화번호, 이메일, 취미)
(3) 구성방식에 따른 분류
1) 기본키(PK, Primary Key) 속성 : 인스턴스를 유일하게 구별 가능하게 하는 속성
2) 외래키(FK, Foreign Key) 속성 : 다른 엔터티의 관계로 연결된 속성
3) 일반 속성 : PK/FK가 아닌 나머지 속성
☞ 자식 엔터티는 부모의 기본키(PK)를 외래키(FK)로 포함
주식별자 특성
화장실에서는 "대소변재일"
대표성, 유일성, 최소성, 불변성, 존재성(Not Null)
식별자/키 차이
식별자는 논리 모델링 단계에서 사용하고, 키는 물리 모델링 단계에서 사용
정규화 단계
3이2부
제1정규화 : 도메인이 원자 값만으로 구성
제2정규화 : 부분적 함수 종속을 제거하여, 완전 함수 종속을 만족
제3정규화 : 이행 함수 종속 관계를 제거
트랜잭션의 4대 특성
르센느 원이는 지금 고지에 있다. "원일고지"
(1) 원자성(Atomicity) : 수행되거나 전혀 수행되지 않아야 함(All or Nothing)
(2) 일관성(Consistency) : 트랜잭션 실행 전후로 오류가 없어야 함
(3) 고립성(Isolation) : 트랜잭션끼리 서로 간섭하면 안됨
(4) 지속성(Durability) : 수행된 결과는 영구적으로 저장
SELECT 문의 구조
공격수(FW)가해써오 "FWGHSO"
뷰의 장점 : 보안성(전체데이터 노출X), 독립성(구조변경시 일관성 유지), 편의성(쿼리 단순화)
계층형 질의
PRIOR
1) PRIOR 자식 = 부모 : 순방향(부모 → 자식)
2) PRIOR 부모 = 자식 : 역방향(자식 → 부모)
PRIOR 가 붙은 쪽이 화살표 시작
PIVOT 절과 UNPIVOT절
PIVOT : 길 걷다가 넘어짐 | -> 집계함수가 필요 (여러 개의 열을 하나의 행에 대응)
UNPIVOT : 먼지 털고 일어남 -> |