[KB IT's your life 7기] DB 설계부터 SQL 실습까지 데이터베이스 활용과 모델링 후기

안녕하세요, KB IT's Your Life 7기 기자단입니다!

오늘 정리할 내용은 DB 설계 부터 SQL 실습까지 입니다!
이번에 SQLD 시험을 보는데 여기서 배우는 내용들이 많이 도춤이 되고 재밌었어요!!
그럼 시작해볼게요~

---

DB 모델링

솔직히 처음엔 모델링? 싶었어요.
데이터베이스 수업인데 갑자기 설계 얘기가 나오니까요..

테이블을 그냥 막 만들면 나중에 다 갈아엎어야 되는데
그래서 미리 어떤 데이터가 필요하고 어떻게 관리할지를 단계별로 정리해야해요
이 과정이 모델링이에요.

단계가 세 개 있는데요,
개념적 모델링은 고객이랑 개발자가 "이런 데이터 맞죠?" 확인하는 단계,
논리적 모델링은 개발자들끼리 ERD 그림 그려가며 테이블 구조 잡는 단계,
물리적 모델링은 실제로 CREATE TABLE 같은 SQL로 구현하는 단계예요.

---

왜 테이블을 굳이 두 개로 나누는 거야?

이게 오늘 제일 인상 깊었던 파트예요.

쇼핑몰 예제로 설명해주셨는데요, 고객 정보랑 구매 이력을 한 테이블에 다 넣으면 어떻게 될까요?

구매 안 한 고객 행은 오른쪽이 텅텅 비고, 같은 고객이 여러 번 사면 이름·주소·연락처가 중복으로 계속 쌓여요.
강사님이 중복 데이터의 진짜 문제는 수정이나 삭제할 때라고 하셨어요.
주소 하나 바뀌면 그 고객 행을 전부 다 찾아서 고쳐야 되니까요.

그래서 테이블을 두 개로 분리해요.
고객 테이블엔 Primary Key 배정 (중복 없음, NULL 불가),
구매 테이블엔 고객 테이블의 PK를 Foreign Key로 참조하는 구조로요.

이렇게 연결하면 구매 테이블에서 "누가 샀냐"를 알 수 있고, 주소 같은 정보는 고객 테이블 타고 가서 찾으면 돼요.

부모 없으면 자식도 없다는 말도 오늘 처음으로 제대로 이해했어요.
고객이 없으면 구매 이력도 없는 거니까, 고객 데이터를 삭제하려고 하면 시스템이 자동으로 막아준다고 하더라고요.
데이터 일관성을 지키기 위해서요!

---

SQL 실습 — SELECT 파헤치기

오후엔 직접 쿼리 짜는 실습이었어요.
오늘의 주인공은 SELECT!

SELECT 컬럼명
FROM 테이블명
WHERE 조건
ORDER BY 컬럼명 DESC
LIMIT 5;

그냥 외우면 되는 게 아니라 각 절이 처리되는 순서가 따로 있어요.
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY 이 순서인데,
이게 나중에 별칭(alias)을 어디서 쓸 수 있는지랑 연결되는 중요한 포인트예요.

오늘 실습하면서 주의사항으로 계속 나온 게 NULL이었어요.
NULL은 일반 비교 연산자로 비교가 안 돼요!
WHERE price = NULL 이런 거 안 되고, 반드시 IS NULL / IS NOT NULL을 써야 해요.
그리고 AVG, MIN, MAX 같은 집계함수는 전부 NULL을 무시하고 계산한다는 것도 기억해두기!

LIKE 연산자도 실습했는데, 앞뒤로 % 붙이면 속도가 엄청 느려진다고 해요.

WHERE prod_name LIKE '%아이스%'  -- 데이터 많아지면 진짜 느려짐 

데이터 천 건만 넘어도 체감된다고 하더라고요. 실전에서는 Elastic Search 같은 검색 엔진을 써야 한다고!

---

GROUP BY

사용자별 구매 금액, 카테고리별 상품 수 이런 거는
같은 값을 가진 행들을 묶어서 집계함수로 통계를 내는 거예요.

SELECT user_id, SUM(amount * price) AS 총구매액
FROM buy
GROUP BY user_id
ORDER BY SUM(amount * price) DESC
LIMIT 1;

이렇게 하면 구매액 1등 고객을 뽑을 수 있어요.

주의할 점이 있는데, GROUP BY 쓸 때 SELECT절엔 GROUP BY에 참여한 컬럼이랑 집계함수 결과만 올 수 있어요.
다른 일반 컬럼 넣으면 Only FULL GROUP BY Mode 에러가 뜨거든요.

그리고 ORDER BY에서 별칭을 쓰면 동작 안 해요.
별칭은 쿼리 처리가 다 끝나고 결과가 나갈 때 적용되는 거라서, ORDER BY 시점엔 아직 그 이름을 모른다는 거죠.
처음엔 이게 왜 안 되지? 싶었는데 처리 순서 생각하니까 바로 이해됐어요

LIMIT

LIMIT 5는 앞에서 5개, LIMIT 10, 5는 10번 인덱스부터 5개.
(여기서 인덱스는 0부터 시작이에요!)

페이지네이션 할 때 꼭 쓰는 기능인데요, 오늘 강사님이 인상 깊은 얘기를 하셨어요.
천 건짜리 데이터를 다 가져와서 앱에서 10개만 보여주는 개발자랑,
DB에서 처음부터 10개만 요청하는 개발자의 차이라고요.

네트워크 비용이며 처리 속도며 당연히 후자가 훨씬 낫죠.
근데 실제로 전자처럼 짜는 사람이 꽤 있다고 하더라고요...
나중에 제가 그러지 않도록 꼭 기억해야겠어요!

---

SELECT로 테이블을 뚝딱 만들어버린다고?

마지막엔 신기한 기법도 배웠어요.
SELECT 결과로 아예 새 테이블을 만드는 것!

CREATE TABLE members AS (
    SELECT emp_no AS user_id, first_name AS name
    FROM employees.employees
    LIMIT 100
);

다른 DB에 있는 데이터 100개 뽑아서 테스트용 회원 테이블 뚝딱 만드는 거예요.
테스트 데이터 구축할 때 진짜 편하겠다 싶었어요.

근데 주의할 게 있는데, Primary Key, Foreign Key는 복사가 안 돼요!
나중에 ALTER로 따로 추가해줘야 한다고 하더라고요.

---

오늘 하루 배운 내용이 많았는데, 의외로 다 연결되는 느낌이어서 이해하기 좋았어요.
모델링 → 테이블 분리 → SELECT 실습 → GROUP BY 통계까지 하나의 흐름이었달까요.

다음엔 JOIN이랑 서브쿼리를 본격적으로 한다는데,
오늘 살짝 맛봤으니까 그나마 덜 무섭겠죠? (아마도)

그럼 이만 끝내보겠습니다
읽어주셔서 감사합니당 다음 포스팅에서 봐요!

---

이미지는 AI로 생성되었습니다