pile·
DB / 데이터·똑똑한개발자똑똑한개발자·

데이터베이스 관계

데이터베이스 연재의 세 번째 글로 개체 사이의 관계 개념을 정리한다. 관계의 형태와 종류를 먼저 나누고, 관계형 데이터베이스가 그것을 어떤 구조로 표현하는지로 이어진다. 용어를 정의 중심으로 짚는 정리 성격의 글이다.

핵심 포인트
  • 관계는 개체와 개체 사이의 논리적인 연결이며 개체 간 관계와 속성 간 관계가 있다.
  • 형태는 일대일, 일대다, 다대다 셋으로 나뉜다.
  • 종류로는 종속 관계와 중복 관계, 재귀 관계, 배타 관계가 있다.
  • 배타 관계는 조건에 따라 하나만 고르는 AND와 하나 이상 고를 수 있는 OR로 나뉜다.
  • 관계형 데이터베이스는 개체와 관계를 모두 표 형태로 표현한다.
  • 표는 구조를 나타내는 스키마와 실제 값인 인스턴스로 구성된다.
상세 정리
  • 관계의 정의: 개체와 개체 사이의 논리적인 연결을 뜻하며 개체 간의 관계와 속성 간의 관계로 나뉜다.
  • 일대일: 한쪽 집합의 각 원소가 다른 집합의 원소 하나와 대응한다.
  • 일대다: 한쪽 집합의 각 원소는 상대 집합의 원소 여럿과 대응하지만 상대 쪽 각 원소는 하나와만 대응한다.
  • 다대다: 양쪽 집합의 각 원소가 서로 여럿과 대응한다.
  • 종속 관계: 두 개체 사이의 주와 종 관계를 표현한 것으로 식별 관계와 비식별 관계로 다시 나뉜다.
  • 중복 관계: 두 개체 사이에 종속 관계가 두 번 이상 발생하는 경우다.
  • 재귀 관계: 개체가 자기 자신과 관계를 갖는 것으로 순환 관계라고도 한다.
  • 배타 관계: 개체의 속성이나 구분자를 기준으로 특성을 분할하는 관계다.
  • 배타 AND: 하위 개체들 중 속성이나 구분자 조건에 따라 하나만 선택할 수 있다.
  • 배타 OR: 조건에 따라 하나 이상을 선택할 수 있다.
  • 관계형 모델의 유래: 1970년 코드에 의해 처음 제안됐다.
  • 표현 방식: 구성하는 개체나 관계를 모두 릴레이션이라는 표로 표현한다.
  • 릴레이션의 구분: 개체를 표현하는 개체 릴레이션과 관계를 나타내는 관계 릴레이션으로 나눌 수 있다.
  • 장점: 간결하고 보기 편하며 다른 데이터베이스로 변환하기 용이하다.
  • 단점: 성능이 다소 떨어진다는 점을 든다.
  • 구조: 릴레이션은 데이터를 표 형태로 표현한 것이며 구조를 나타내는 스키마와 실제 값인 인스턴스로 구성된다.
  • 형태 판별의 기준: 어느 쪽에서 보느냐에 따라 대응 개수가 달라지므로 양방향을 모두 따져야 형태가 확정된다.
  • 다대다의 처리: 관계형 모델에서는 표로 직접 표현하기 어려워 중간에 별도의 표를 두어 두 개의 일대다로 풀어내는 것이 일반적이다.
  • 식별과 비식별: 종속 관계에서 상위 개체의 키가 하위 개체의 키에 포함되면 식별, 일반 속성으로만 들어가면 비식별로 갈린다.
  • 재귀 관계의 예: 사원과 상급자처럼 같은 개체 안에서 상하가 생기는 구조가 여기 해당한다.
  • 용어 정리의 쓸모: 이런 구분을 알아두면 ERD를 읽거나 그릴 때 선의 의미를 말로 설명할 수 있게 된다.
왜 읽나ERD를 그리다 배타 관계나 재귀 관계 같은 용어에서 막힌 적이 있다면 형태와 종류를 한 번에 정리해둘 수 있다.
똑똑한개발자
똑똑한개발자 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5