sql 정리4

울·2026년 1월 29일
sql김영한인프런

SQLD

목록 보기
7/7

1. Data의 유일한 이름표 : 식별자

  • 다른 Data와 유일하게 구별해주는 이름표로 DB Table에서 '기본키'

2. 카디널리티와 참여도

  • 종류
    ex) 1:1, 1:N, M:1, M:N

  • 카디널리티란 엔터티 인스턴스 하나가 다른 엔터티 인스턴스와 몇개나 관계를 갖는지를 표현해준다.

3. 연관 엔터티 : 다대다(M:N) 관계를 해결

  • 아래 사진 N:M 관계
    1) 문제 M:N은 물리적으로 만들 수 가 없다.
    2) 관계에 속한 Data를 저장할 장소가 없다.
    A) 그러면 관계를 엔터티로 만들자!

  • 아래 사진이 관계 -> 엔터티

  • 실무적 팁
    M:N 관계를 본다면 이는 반드시 풀어내고, 속성을 찾아라
    -> M:N은 그자체로 추가적은 속성을 가진다. 다대다를 본다면 분석해라

5.KEY

  • 기본키(Primary Key)

    • Null을 가질 수 없다.
    • 반드시 유일해야(유일성)
    • 값이 변하지 않는다.

  • 후보키(Candidate Key)

    • 기본키가 될 수 있는 키
    • 유일성을 만족
    • 희소성 : 행을 유일하게 식벽하는데 꼭 필요한 최소한의 컬럼만을 표함

  • 대체키(Alternate Key)

    • 후보키중 기본키로 선택되지 않은 키들

  • 외래키(Foregin Key)

    • Table간의 관계를 연결하는 역할

6. 자연키와 대리키

  • 자연키(Natural Key) : 우리의 비즈니스 로직안에서 자연스레 생성된 키
    • 장점 : 직관성, 중복방지
    • 단점 : 변경의 가능성
      - 이는 치명적 약점이다. 현대 DB설계에서 가장 중요한 원칙 '기본키는 영원히 변하지 않아야한다'에서 비즈니스에 종속된 자연키는 이 원칙을 지키기 어렵다.

  • 대리키(인조키) : 비즈니스 로직과 무관한, 오로지 Data를 식별하기 위한 용도로 임의값을 사용
    ex) UUID, 자동생성 값

    • 대리키는 자연키의 단점을 대안하기 위한 역할로 주로 사용된다.

    • 대리키로 완벽하게, 느슨하게 결합된 이상적 구조를 만들 수 있다.


  • 현대 DB 설계 표준 패턴
    • PK : 대리키
    • unique : 자연키
    • 왜?
        1. 비즈니스 요구사항의 폭발적인 변화속도
        1. ORM 기술의 등장, 패러다임 전환
        1. 분산 System 과 MSA

  • Tade-Off
    • 자연키의 장점
        1. 조회 단순성 (대리키를 사용시 Join이 필요)
    • 대리키의 장점
        1. 뛰어난 쓰기 성능
        1. 외래키의 크기 최소화

1. 복합키 설계

Q. 왜 복합키가 필요할까?
영화 예매를 예시를 보면
1. 영화 정보
2. 상영 정보
3. 예매 정보
이를 명확히 구분해야만 한다.
좌석 예매를 '영화제목+상영시간+좌석정보의 속성' 3가지를 조합한다.

  • 자연키를 복합키로 사용하는 예시에서 발견되는 문제점
      1. 변경 가능성으로 인한 불안정성
      1. 외래키 참조의 복잡성과 크기 증가
    • 대안 : 대리키를 사용하자

  • 다대다 관계와 복합키
    • 상황 : 연결 Table을 만들었을 경우
      • 방법1. 연결하는 PK 두개로 복합키 만들기
      • 방법2. 대리키를 PK로 사용하며, 기존 PK를 Unique조건으로 갖고 있기

1. 논리적 모델링 관계

RDBMS에는 방향이 없다.

  • RDBMS는 Join를 통해 Fk로 양방향 조회가 가능.
  • 가장 중요한 것은 FK의 위치

1. 1:N, M:N 관계에서 외래키의 위치

N(다) 위치에 FK를 위치시킨다.

  • 왜?
    • ㄱ. PK는 유일하다 -> 한 Table에 여러 PK존재 X
    • ㄴ. FK는 단일행만 참조
		MEMBER
		- member_id (PK)

		ORDER
		- order_id (PK)
		- member_id (FK)
        
        1. 한 주문은 여러 회원을 가리킬 수 없음
		2. FK 컬럼 하나에 여러 PK를 담을 수 없음
  • ㄷ. 컬럼은 원자적이다.

1. 1:1 관계

하나의 행이 다른 Table의 단 하나의 행과 관계를 맺는다.

  • 왜 1:1 관계를 사용할까?
    • 성능 최적화로 분리 ex) 핵심 정보, 가끔 사용하는 상세 정보
    • 보안 강화로 분리 ex) 주민번호, 여권 번호
    • 선택적 정보 (0 or 1) 표현 및 확장
    • 비즈니스 모델에 따른 분리

  • Table 분리시 장점
    • 관심사의 분리
    • 독립적인 확장성

  • 왜래키를 어디에 위치 할까?
      1. 보조 Table에 위치 (권장)
      1. 주 Table에 위치 (언제?)
      • 관계가 필수 일때.
      • 조회 성능이 극도로 중요할 떄

보조 Table에 위치한 경우 -> OCP를 만족함

  • 장점
    • 주 Table의 독립성, 확장성
    • 논리적 명확성
    • 선택적 관계표현의 용이성
    • 관계 확장의 유연성
  • 단점
    • 관계 존재 여부의 확인

1. 식별 vs 비식별 관계

  • 구분
    • 부모의 기본키를 물려받아 자식의 기본키로 사용 : 식별
    • 부모의 기본키를 단순히 일반 컬럼으로 사용 : 비식별
    1. 식별 관계 (약한 Entity)
    • 부모가 자식을 식별하는데 사용하는 관계
    • 자식은 부모 엔터티의 PK를 가져와 유일하게 식별 가능
    • 즉 부모의 관계가 자식의 신원에 일부가 됌

    1. 비식별 관계(강한 Entity)
    • 부모가 자식을 식별하는데 사용되지 않는 관계
    • 자식은 고유의 PK를 가짐

2. 식별 vs 비식별 에서 1:N (일대다)

    1. 비식별 관계

    • 장점
      ㄱ. 단순 -> 명확
      ㄴ. 유연하다.
      ㄷ. ORM 친화적
    • 단점
      ㄱ. PK만 보고, 부모와의 관계를 명확하기 어렵다.

    1. 식별 관계
      업로드중..
    • 장점
      ㄱ. PK가 비즈니스 의미를 가짐
      ㄴ. Data 정합성 강화
      ㄷ. 쿼리 최적화
    • 단점
      ㄱ. 복잡하다
      ㄴ. 유연성 저하
      ㄷ. 확장성 저하
      ㄹ. ORM 매핑이 복잡
    1. 식별관계의 문제점 (강한 결함)
      ㄱ. 유연성 부족
      ㄴ. PK컬럼의 전파와 복잡성
      ㄷ. 현대 DB설계의 스타일은 비식별 관곌 선호

실무적 이야기
옛날에 주민등록번호를 PK로 식별관계로 사용했었다 한다.
이제 주민등록번호를 가입할때 안받게 변경할떄 -> 대공사의 시작...
그래서 현대 DB설계에서 "대리키 + 비식별 관계"를 사용한다~라는 이야기

    1. 식별 vs 비식별 의 SQL 성능

    • 1) 비식별

        1. 단순함이 주는 강력함
        1. Api, Url 설계의 단순성
          비식별 관계
GET /orders/1001
GET /order-items/50001
    
 식별 관계   
 GET /orders/1001/items/3
        1. 개발 편의성, 실수 방지
        1. 객체 지향, ORM 조화

    • 2) 식별관계가 유리할 때

      • 부모 PK가 변경/삭제 시 자식도 함께 관리되는 모델

3. 비식별 vs 식별 (1:1 관계)

    1. 비식별
    • 장점
      • 독립성, 유연성
      • 일관성있는 설계

    • 단점
      • 1:1 보장을 위한 유니크 제약 조건의 추가
    1. 식별
    • 장점
      • 강한 논리적 결합

    • 단점
      • 유연성

4. 비식별 vs 식별 (M:N 관계)

    1. 비식별
    • 장점
      • 유연성, 데이터 정합성의 확보
      • ORM 천화적

    1. 식별
    • 장점
      • 비즈니스의 강한 규칙
      • 인덱스 효율의 증가

    • 단점
      • 유연성 감소
      • 복잡성 증가
profile
울
# h
이전 포스트

sql - 정리3

0개의 댓글