SQL - 데이터 집합 연산

이번 시간에는, 두둥-
관계형 데이터베이스에서의 SQL에서 데이터 집합 연산에 대해 소개를 맡았습니다.

데이터 집합 연산은 관계형 데이터베이스에서 볼 수 있는 SQL의 꽃(?)입니다.

NoSQL(비관계형 데이터베이스)처럼 관계형 데이터베이스가 아닌 데이터베이스에는 데이터 집합 연산이 따로 없습니다.

 

---

 

산으로 가기 전에, 오늘 이 시간의 목표와 목차를 보고 바로 시작해보도록 하겠습니다.
여러분의 시간은 귀중하니까요. 

 

우선 오늘 이 시간의 목표는 바로 데이터 집합 연산의 존재 이유입니다.
데이터 집합 연산을 하는 법은 배웠지만, 왜 하는 지를 안다면 더 도움이 될 거라 생각했습니다.
아니라면... 어쩔 수 없...

 

알아볼 순서는!

1. 관계형 데이터베이스가 뭘까요?
2. 관계형 데이터베이스를 왜 쓸까요?
3. 관계형 데이터베이스를 어떻게 쓸까요?
4. 집합 연산이 여기서 등장합니다!
5. 마무리!

 

바로 시작해보겠습니닷.

+ 정확하지 않은 정보가 포함되어 있을 수 있습니다. 하핳
+ 사실과 다른 부분은 꼭 지적해주세요! 우리 모두, 특히 저에게 도움이 됩니다!

 

---

 

관계형 데이터베이스는 뭘까요?

 

데이터베이스는 데이터를 모아서 저장하는 무언가라는 것은 쉽게 알 수 있습니다.

하지만 관계형이 붙어 있는 데이터베이스란 무엇일까요?

 

우선 데이터베이스를 사용하는 목적 대해 빠르게 알아보자면,

• 데이터를 저장하고 읽고 쓰는 것에만 집중하기 위한 목적이 있습니다.
• 저장한 데이터를 쉽게 동시에 똑같은 데이터를 공유하려는 목적이 있습니다.
• 중복된 데이터를 최소화시키려는 목적이 있습니다.
• 저장된 데이터가 참(True)인 경우를 유지하여, 데이터에 대한 신뢰성(무결성)을 지키려는 목적이 있습니다.

자세한 설명은 산으로 갈 수 있으니, 일단 여기서 이 이야기는 멈추겠습니닷.

 

자 그럼 관계형의 의미는 무엇일까요?

바로, 데이터 간의 관계를 만들어 저장한다는 의미입니다.

 

예를 들어,

A님의 점심 메뉴.
B님의 점심 메뉴.
사람과 점심 메뉴가 서로 관계를 가지고 있는 모습입니다. 

C님의 취미.
D님의 취미.
사람과 취미가 서로 관계를 가지고 있는 모습입니다.

필요하다면 취미와 점심 메뉴의 관계를 만들 수도 있겠습니다.

 

즉, 관계형 데이터베이스란,
데이터와 그 데이터들 간의 관계를 저장한 집합체라고 할 수 있겠습니다.

 

---

 

관계형 데이터베이스를 왜 쓸까요?

 

그럼 관계형 데이터베이스는 왜 쓸까요?

그 이유는,
데이터베이스 종류 중에 가장 현실 세계의 데이터를 잘 담을 수 있다고 평가되었기 때문입니다.
물론 지금에 와서야 NoSQL(비관계형 데이터베이스) 등 다른 데이터베이스 종류도 많이 생겼습니다.

 

현실 세계에서 관계가 없는 물질은 아마도 없습니다. 있다면 어쩔 수 없구욧...

A님의 아이폰
A님과 아이폰은 종속 관계입니다.

군대에서의 병장과 이병
병장과 이병은 계층 관계입니다.

의리의 으리고침
새로고침 팀 안에 우리는 소속(관계)되어 있습니다.

아이폰 vs 갤럭시
이 둘은 라이벌 관계입니다.

등등등... 이러한 관계 형태를 데이터베이스 안에서도 표현할 수 있는 것이죠.

 

---

 

관계형 데이터베이스를 어떻게 쓸까요?

 

근데 그 관계를 어떻게 표현하는 것일까요?

 

일단, 관계의 상세한 명칭은 구분하지 않습니다.
종속이든, 계층이든, 소속이든, 라이벌이든...

그게 무슨 관계인지는 모르겠지만 일단 관계가 되어 있다고 표현하는 것입니다.
(물론 프로젝트에 관련되어 있다면, 또는 데이터베이스 안에 있는 데이터에 대한 이해가 필요하다면 반드시 알아야 합니다.)

 

데이터베이스를 만들기 전에,
예시 데이터를 먼저 살펴보겠습니다.

강남구에 사는 남자 A님의 아이폰
강남구에 사는 남자 A님의 애플 워치
강서구에 사는 남자 B님의 갤럭시
강동구에 사는 여자 C님의 아이패드
강북구에 사는 남자 D님의 LG 그램
강남구에 사는 여자 E님의 맥북
강북구에 사는 여자 F님의 갤럭시
강북구에 사는 여자 F님의 갤럭시 탭
강북구에 사는 여자 F님의 갤럭시 워치
아무 것도 갖고 있지 않은 강북구에 사는 남자 Z님

살펴보니, 사람과 전자기기의 관계가 되겠습니다.

즉, 사람과 관련된 정보를 한 곳(유저 테이블)에 모으고,
전자기기에 관련된 정보를 한 곳(전자기기 테이블)에 모으도록 설계가 되겠습니다.
(테이블 설계에 관련된 이야기는 1년으로도 부족하니... 넘어가도록 하죠!)

(+ 저는 테이블에 중복된 데이터가 들어가는 것을 극도로 싫어하기 때문에, 테이블 3개로 표현하고 싶었지만,
원활한 이해를 위해, 2개의 테이블로 작성하였습니다.)

(+ 데이터베이스(옵티마이저)가 짜는 쿼리 실행 계획에 따라 2개로 표현하는 것이 실행 속도가 빠를 수 있습니다.)

 

생성된 유저 테이블

유저 인덱스	이름	주소	성별
1	A	강남구	남자
2	B	강서구	남자
3	C	강동구	여자
4	D	강북구	남자
5	E	강남구	여자
6	F	강북구	여자
7	Z	강북구	남자

 

생성된 전자기기 테이블

전자기기 인덱스	유저 인덱스	전자기기
1	1	아이폰
2	1	애플 워치
3	2	갤럭시
4	3	아이패드
5	4	LG 그램
6	5	맥북
7	6	갤럭시
8	6	갤럭시 탭
9	6	갤럭시 워치

 

유저 테이블과 전자기기 테이블이 만들어 졌습니다.
그리고 전자기기 테이블의 '유저 인덱스'를 통해, 이 전자기기가 누구의 것인지 알 수가 있습니다!

그리고 이렇게 전자기기 테이블에 들어가 있는 '유저 인덱스'를 왜래 키(Foreign Key, FK, 포링키, 에프키)라고 합니다.

+ 유저 테이블에서 '유저 인덱스'는 기본 키(Primary Key, PK, 프라이머리키, 피키)라고 합니다.
마찬가지로 전가기기 테이블에서 '전자기기 인덱스'도 기본 키(Primary Key, PK, 프라이머리키, 피키)라고 합니다.

+ 왜 A, B, C, D, E, F, Z라는 이름 대신, '유저 인덱스'로 사람을 표현할까요?
중복된 데이터를 최소화 하고, 데이터에 대한 신뢰성(무결성)을 확보하기 위함입니다.
즉, '유저 인덱스'가 아니라면, 전자기기 테이블에 주소, 성별을 모두 기록해주어야 합니다.
또는 유저 테이블에 전자기기를 기록해주어야 합니다. 하지만 Z는 전자기기가 없습니다.

 

---

 

드디어, 집합 연산이 여기서 두둥등장합니다.

 

위에서 보았듯 관계가 테이블의 인덱스(기본 키, Primary Key, PK, 프라이머리키, 피키)로 표현되었습니다.
하지만, 저렇게 숫자로만 표현되어 있다면, 우리가 읽기 힘들게 되겠지요.

그래서 필요한 것이 집합 연산(JOIN)입니다.

수업 시간에 많이 했던,
FROM 유저 JOIN 전자기기 ON 유저.'유저 인덱스' = 전자기기.'유저 인덱스' 가
바로 저장된 데이터 간의 관계를 우리가 알아볼 수 있도록 불러오는 과정이었던 것입니다.
빌드업 좀 만족스럽네요. 뿌듯.

즉, 이러한 데이터들의 관계를 이해하고 사용한다면,
집합 연산(JOIN, LEFT JOIN, 라이트이너아우터 JOIN)을 더 능숙하게, 또 효율적으로 사용할 수 있겠습니다.

+ JOIN과 LEFT JOIN로 모두 해결할 수도 있습니다. 하하하핳 LEFT JOIN, JOIN 만세 만세 만만세

 

---

 

마무리.

 

사실, 데이터에 대한 이해는 정말 개인적인 취미의 영역이기 때문에 강요할 수는 없습니다.
하지만, 그걸로 돈을 번다면, 해야 합니다...

+ 이러한 (비즈니스) 데이터에 대한 지식을 도메인 지식이라고 부르기도 합니다.
(도메인 지식이라는 틀 안에 해당 비즈니스 데이터에 대한 지식이 들어가 있다고 볼 수 있습니다.)

 

따라서...

집합 연산에 익숙해지려면, 특정 데이터 셋을 정말 애뜻하고 사랑하는 마음으로 다루거나...

데이터베이스를 직접 설계해보거나... (자식이 생기는 듯한 마음입니다...)

관심없는 데이터이더라도, 원하는 데이터 모양대로 가져오도록,
SQL을 무한히 반복하는 수 밖에는 없습니다... (특히 SQL은 그렇습니다.)

 

두서 없지만... 읽고 들어주셔서 감사합니다.!