1. 외래키 제약 조건
-
1) 참조 무결성이란
- "두 테이블의 관계가 항상 유효하고, 일관된 상태를 유지한다"는 원칙
- "두 테이블의 관계가 항상 유효하고, 일관된 상태를 유지한다"는 원칙
-
2) 외래키 역할
- 유령 Data 생성 방지
- 기존 Data를 유령 Data 변화 방지
-
3) On Delete / Update
- Restrict(default값) : 자식 Table에 참조하는 행이 있다면, 부모 Table 의 행을 삭제, 수정 불가
- Cascade : 자식 Table에 참조하는 행이 있다면, 부모 Table 의 행을 삭제, 수정 가능
- Set Null : 부모 Table에 행이 삭제, 수정시 -> 자식 Table의 외래키에 Null을 입력.
-
추가적으로 check 제약 조건 : 특정 컬럼의 입력 가능한 값의 범위를 지정
``` discount_rate Decimal(5,2) Defaulr 0.00 check(discount_rate Between 0.00 and 100.00) ``` -
Data 검증 실무 이야기
- Data검증은 어디에서? -> 애플리케이션 코드에서!
- DB check는? 가장 핵심 Data만, "최후의 방어선" 으로 사용하기
2. 트랜잭션이 왜 필요한가?
만약 ㄱ.주문 -> ㄴ. 재고수량 -> ㄷ. 처리. 이 세 단계는 서로 떨어질 수 없는 하나의 작업
- 트랜잭션이 없을 때 문제점
상황 1.
- ㄱ. 주문 생성 O
- ㄴ. 재고 수량 감소 X (에러 발생)
- ㄷ. 처리 X
결과:
- 주문은 있는데 재고는 줄지 않음
- 실제로는 팔리지 않았는데 주문만 존재하는 데이터 불일치
상황 2.
- ㄱ. 주문 생성 O
- ㄴ. 재고 수량 감소 O
- ㄷ. 처리 X (서버 다운)
결과:
- 재고는 줄었는데 주문은 처리되지 않음
- 재고 유령 감소 발생
그래서!
BEGIN(= start) TRANSACTION
ㄱ. 주문 생성
ㄴ. 재고 수량 감소
ㄷ. 주문 처리
COMMIT
-
ACID 속성
- Atomicity (원자성) : 전부 성공 or 전부 실패
- Consistency (일관성) : 트랜잭션 전후 규칙 유지
- Isolation (격리성) : 동시에 실행돼도 서로 간섭 X
- Durability (지속성) : 커밋된 데이터는 영구 저장
-
트랜잭션 격리 수준
Q. 완벽한 격리는 항상 좋은 가? A. 완벽한 고립은 마치 한줄로 서서 코드가 실행되듯이 안정성은 잡을 순 있어도, 수천, 수만명이 이용시 거북이처럼 천천히 실행돼. 사용하지 않을 것이다. 그래서 마주하는 것이 "정합성" vs "동시성 / 성능"의 Trade-Off이다.-
1) 격리성 수준이 낮을 때
-
ㄱ. 더티리드 : 한 트랜잭션이 commit되지 않은 수정중인 Data 읽기
-
ㄴ. 반복 불가능 읽기 : 한 트랜잭션에서 Select가 여러 번 실행. 그 사이 다른 트랜잭션이 value 수정 후 commit. 그래서 쿼리 결과가 달라짐.
-
ㄷ. 유령 읽기 : 한 트랜잭션 내에서 특정 범위의 Data를 두 번 읽었는 데, 첫 번째 조회에서 없던 Data가 2번째 조회에서 읽히는 것.
-
-
3. DB 설계의 첫 걸음
-
- 설계의 3 단계
-
1) 개념적 단계(큰 밑그림)
Q. 우리가 다룰 엔터티는 무엇인가?
Q. 그 엔터티의 관계는?
Q. 더 나아가 ERD는?
-
2) 논리적 단계 (설계도, RDBMS에 맞게 이론적으로)
Q. 개념 모델의 각 요소들은 어떤 Table 구조로 표현할까?
Q. Data 중복을 막기 위해 어떤 정규화 규칙을 사용할까? -
3) 물리적 설계 (재료들)
Q. 각 컬럼에 어떤 타입을 쓸까?
Q. 어떤 컬럼엔 어떤 인덱스를 사용하지?
-
- 개념적 모델링
-
1) 요구사항 분석 및 핵심 요소 식별
요구사항 속 우리가 만들어야 할 Data의 뼈대를 찾자 어떻게? 명사 -> 엔터티 ex) 회원, 아이디... 동사 -> 관계 ex) 가입하다, 수정하다... 그리고 행위(동사) vs 행위의 기록(명사)를 구분하자 -
2) 엔터티 분류( 기준 : 존재 형태, 생성 시점 & 역할, 존재 종속성)
- ㄱ.존재 형태
- 유형 엔터티 : 물리적 형태 O , 업무로 부터 식별
- 개념 엔터티 : 물리적 형태 X , 업무 규칙, 제도, 분류 기준
- 사건 엔터티 : 업무 프로세스를 진행함에 따라 발생, Data가 지속적으로 누적
실무 전략 1. 인덱스 2. Data파티셔닝 3. 아카이빙-
ㄴ. 역할 및 발생 시점 : Data의 발행 순서 및 의존성을 명확히 -> 모델의 논리적 흐름을 체계화
- 기본 엔터티 : 업무에 원래 존재하는 엔터티로 다른 엔터티로 부터 주식별자를 상속받지 않음, 자신 고유의 주식별자를 갖는다.
- 중심 엔터티 : 주로 기본 엔터티 간의 관계에서 발생, 업무 프로세스의 중심적 역할
- 행위 엔터티 : 두개 이상의 부모 엔터티로 부터 발생
-
ㄷ. 존재 종속성 : 다른 엔터티와의 관계 속 자신의 존재 여부
- 강한 엔터티 : 독립적으로 존재 가능
- 약한 엔터티 : 독립적으로 존재 불가능 (주로 부모 엔터티의 기본키 + 자신의 속성으로 복합 기본키를 생성)
- ㄱ.존재 형태
# h