2024-12-22

Suhyeon Lee·2024년 12월 22일

자기주도학습

목록 보기

64/83

CodeKata

SQL

20일 풀었던 'Interviews' 문제 관련 정리

어려운 문제이기도 하고 팀 프로젝트 진행하느라 문제를 곱씹을 시간이 없었기 때문에 다시 한번 살펴보고 정리하기로 결정!
- 문제 이해에 도움을 준 블로그 글
- 유튜브
  - The Coding Mentor
테이블 구조
※ 특정 컨테스트는 한 개 이상의 대학에서 후보자를 선별하는데 활용될 수 있지만, 각 대학은 하나의 컨테스트만 개최합니다.
- 구해야 하는 것
  - contest별 total_submissions, total_accepted_submissions, total_views, total_unique_views 값의 합계
- JOIN 구조
  - contest에 속한 challenge 확인을 위해 Contests, Colleges, Challenges 테이블 INNER JOIN(파란색 IJ로 표시)
  - View_Stats에만 데이터가 있거나 Submission_Stats에만 데이터가 있을 경우를 생각해 OUTER JOIN → LEFT JOIN 하면 됨!
- POINT
  - Contests 테이블에 있는 Hacker는 contest를 만든 해커임(심사를 받는 후보자들이 아님)
  - Contests, Colleges, Challenges 테이블을 INNER JOIN한 테이블에 View_Stats, Submission_Stats 테이블을 바로 JOIN할 경우 1:0 or N 관계이기 때문에 Challenge_id의 중복된 row만큼 값이 커짐! 따라서 먼저 Challenge_id로 그룹핑해서 1:0 or 1 관계가 되도록 준비해야 함

SDL

: Self-Directed Learning

스키마 디자인

데이터베이스 스키마 설계?

데이터베이스 스키마를 구성하기 위한 전략과 관행을 말함

그래서 '데이터베이스 스키마'가 뭐라구요?

데이터베이스에서 데이터가 어떻게 구조화되거나 조직화되는지를 설명하는 것
특정 데이터베이스의 구조 또는 구성에 대한 형식적인 설명
관계형 데이터베이스, 즉 테이블에 정보를 구성하고 SQL 쿼리 언어를 사용하는 데이터베이스와 관련하여 가장 일반적으로 사용
- 비관계형(즉, "NoSQL") 데이터베이스는 여러 다른 형식으로 제공되며, 기본 구조가 있음에도 불구하고 일반적으로 관계형 데이터베이스와 동일한 방식으로 "스키마"가 있는 것으로 간주되지 않는다고 함
두 가지 기본 구성 요소 존재
- 물리적 데이터베이스 스키마
  - 데이터가 스토리지 시스템에 물리적으로 저장되는 방식과 사용되는 스토리지 형태(파일, 키-값 쌍, 인덱스 등)를 설명
- 논리적 데이터베이스 스키마
  - 데이터에 적용되는 논리적 제약 조건을 설명하고 필드, 테이블, 관계, 보기, 무결성 제약 조건 등을 정의
  - 프로그래머가 데이터베이스의 물리적 설계에 적용할 수 있는 유용한 정보를 제공
  - 논리적 모델에 정의된 규칙 또는 제약 조건은 서로 다른 테이블의 데이터가 서로 관련되는 방식을 결정하는 데 도움이 됨
- 스키마의 물리적 테이블에 대한 정의는 논리적 데이터 모델로부터 온다!
  - 예를 들어 엔터티는 테이블이 되고, 엔터티의 속성은 테이블 필드가 됩니다.
일반적인 데이터베이스 스키마 유형
- 플랫 모델
  - 데이터를 2차원의 단일 배열로 구성
  - Microsoft Excel 스프레드시트나 CSV 파일
  - 서로 다른 엔터티 간에 복잡한 관계가 없는 간단한 테이블 및 데이터베이스에 가장 적합
- 계층 모델
  - 루트 데이터 노드에서 분기되는 하위 노드가 있는 "트리와 같은" 구조
  - 가계도 또는 생물학적 분류와 같은 중첩 데이터를 저장하는 데 적합
- 네트워크 모델
  - 계층적 모델과 마찬가지로 데이터를 서로 연결된 노드로 취급하지만, 다대다 관계, 다대다 주기 등 보다 복잡한 연결을 허용
  - 위치 간의 상품 및 자재 이동이나 특정 작업을 수행하는 데 필요한 워크플로 모델링 가능
- 관계형 모델 ★★★
  - 일련의 테이블, 행, 열로 데이터를 구성하고 서로 다른 엔터티 간의 관계를 사용
- Star 스키마
  - 데이터를 "팩트"와 "차원"으로 구성하는 관계형 모델의 발전된 형태
  - 팩트 데이터는 숫자(예: 제품 판매량)이고 차원 데이터는 설명(예: 제품 가격, 색상, 중량)
- Snowflake 스키마
  - Star 스키마를 추가로 추상화한 것
  - 팩트 테이블은 자체 차원 테이블이 있을 수도 있는 차원 테이블을 가리키며 데이터베이스 내에서 가능한 설명을 확장함
  - 눈송이 결정(Snowflake)의 복잡한 패턴에서 명명됨
- 더 알고 싶다면 여기
올바른 데이터베이스 스키마 설계는 엔터프라이즈 데이터를 더 잘 활용하는 데 도움이 됨

테이블 간의 관계 시각화

: dbdiagram.io

공부하며 참고한 블로그 글은 여기
- 해당 블로그에 SQL 관련 좋은 글이 많으니 꼭 다 읽어보기!

관계형 데이터베이스의 관계

참고

구조화된 데이터는 하나의 테이블로 표현 가능
- 사전에 정의된 테이블을 릴레이션(relation)이라 하고, 테이블을 사용하는 데이터베이스를 관계형 데이터베이스(Relational database)라 함
- 각 테이블 사이에는 관계라는 개념이 존재
관계 종류 예시
- 1:1(일대일)
  - 하나의 레코드가 다른 테이블의 레코드 한 개와 연결된 경우
  - 한 명의 사용자는 하나의 전화번호를 가질 수 있으며, 하나의 전화번호는 한 명의 사용자만을 가질 수 있을 때
- 1:N(일대다)
  - 하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우
  - 한 명의 사용자는 여러 개의 전화번호를 가질 수 있으나, 여러 명의 유저가 하나의 전화번호를 가질 수는 없는 구조
  - 일반적으로 데이터베이스를 사용할 때 가장 많이 사용되는 관계
- N:M(다대다)
  - 여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우
  - N:M 관계를 위해 스키마를 디자인할 때에는 Join 테이블을 만들어 관리함
  - 1:N 관계와 비슷하지만, 양방향에서 다수의 레코드를 가질 수 있음
  - 한 명의 고객은 여러 개의 여행 패키지를 구매할 수 있고, 여행 패키지 하나는 여러 명의 고객이 구매할 수 있음
  - 이를 데이터베이스에서 관계를 표현하기 위해서는 두 개의 1:N 관계와 모양이 유사하게 표현할 수 있음 → 두 개의 테이블과 1:N 관계를 형성하는 새로운 테이블로 N:M 관계를 나타내는 것
  - customer_package는 고객과 여행 상품을 중간에서 1:N 관계로 묶어주는 역할 → 이 테이블을 통해 고객이 몇 개의 여행 상품을 구매하였는지 또는, 어떤 여행 상품이 몇 명의 고객을 가지고 있는지 등을 확인
  - customer_package는 cp_id와 같은 기본키가 반드시 존재해야 함
- 자기 참조 관계(Self Referencing Relationship)
  - 하나의 테이블 내에서 관계를 표현
  - 특정 서비스에서 회원 가입을 진행할 때, 추천인 ID를 입력하는 등의 기능
  - 한 명의 사용자(user_id)는 한 명의 추천인(recommend_id)을 가질 수 있으며 한 명의 추천인(recommend_id)은 여러 명의 사용자(user_id)에게 추천인으로 등록될 수 있음
    ※ 1:N 관계와 매우 유사하지만 일반적으로 1:N 관계는 서로 다른 테이블의 관계를 나타낼 때 사용하는 표현이라는 걸 기억하자!

관계형 데이터베이스 다대다 예시

고객-상품관계
- 고객은 여러 상품을 구매할 수 있고, 상품은 여러 고객에게 팔릴 수 있음
다대다 관계가 항상 헷갈려서 쉽게 설명된 글을 찾아보았음
- 여기
  - 고객이 어떤 상품을 몇 개 샀는지, 신라면은 누구에게 팔렸는지 어떻게 알 수 있을까?
    → 매핑 테이블(상품_고객) 만들어 일대다, 다대일로 풀어주기