[N312] TIL 및 회고

Sea Panda·2022년 12월 12일
0

부트캠프 TIL

목록 보기
26/46

0.학습목표

  • SQL 특징을 설명할 수 있다.
  • 데이터베이스 관계를 설정할 수 있다.
  • SQL 싱글 테이블 관련 문법을 활용할 수 있다.

1. 주요개념

이전에 SQL을 공부하고 정리해둔 글이 있다. 수업은 현재 SQLite기준으로 진행되고 내가 정리한 것은 MYSQL이다. 대다수가 동일하다. 다만 SQL문을 날리는 프로그램의 차인지 SQL 어플리케이션 자체의 문법 차이인지 CREATE TABLE에서 괄호 안에 들여쓰기하는 점이 다르다.

여하튼 정리해둔 글들을 참조하자. 그 글에서 이번 수업에서 다룬 대다수의 개념을 다뤘다. 안다룬 개념은 밑에 따로 정리하자.

아 참고로 명령어도 같이 정리되어 있다. 따라서 이번에 따로 정리하는 명령어는 적을 거 같다. 사실 아직 명령어 안뽑아봐서 모르긴 하는데 과제하면서 웬만한 거는 다 있었다.

💡 MYSQL 내용정리(내 Velog)
1. SQL-1
2. SQL-2
3. SQL-3
4. SQL-4
5. SQL-5

1. SQL 종류(역할에 따른 분류)

이번 수업에서 중요하게 다룬 개념은 아니다. 그냥 이런게 있구나 식으로 넘어가고 나중에 기술면접 등을 준비할 때 바짝 외워서 가자.

1-1. DDL

"Data Definition Language"의 약자로 데이터베이스의 테이블과 같은 오브젝트를 정의할 때 사용되는 언어를 가리킨다.

/*사용 예시*/
CREATE TABLE  /*테이블 생성*/
DROP          /*테이블 및 데이터베이스 제거 */

1-2. DML

"Data Manipulation Language"로 데이터베이스에 데이터를 변경할 때 사용되는 언어를 가리킨다.

INSERT  /*새로운 레코드 추가*/
DELETE  /*데이터 삭제*/
UPDATE  /*데이터 변경*/

1-3. DCL

"Data Control Language"로 데이터베이스에 대한 접근 권한과 관련된 문법이다. 어느 유저가 데이터베이스에 접근할 수 있는지에 대한 권한을 설정하거나 없애는 역할을 수행한다.

GRANT   /*권한 부여*/
REVOKE  /*권한 삭제*/

1-4. DQL

Data Query Language"로 정해진 스키마 내에서 Query를 할 수 있는 언어이다. 따로 분류하여 말하긴 하지만 DQL을 DML의 일부로 말하기도 한다.

SELECT /*출력 필드 선택*/

1-5. TCL

Transaction Control Language"로 DML을 거친 데이터의 변경사항을 수정할 수 있다.

COMMIT     /*DML이 작업한 내용을 데이터베이스에 기록*/
ROLLBACK   /*커밋했던 내용을 다시 취소*/

2. 관계종류

테이블 간의 관계는 크게 4개로 나눌 수 있다. 이 중 하나는 테이블 자체 관계로 Self referencing 관계, 즉 자기참조 관계라고 한다.

각 관계에 대해서 상세히 알아보자.

위는 Entity-Relationship Diagram(ERD)에서 나타나는 연결 선이 의미하는 바이다.

2-1. 1:1 관계

테이블의 레코드(혹은 tuple이라고도 함.) 하나당 다른 테이블의 한 레코드와 연결되어 있는 경우이다. 하지만 이러한 관계는 흔치 않다. 1대 1관계라면 두 개의 테이블을 하나로 합쳐서 표현하는 것이 더 보편적이기 때문이다.

<예시>

User 테이블에서는 유저의 이름과 phone_id라는 외래키를 가지고 있다.
Phonebook테이블에서는 전화번호를 보관하고 있다.

만일 한 개의 전화번호당 한 명의 유저를 가지고 그 반대도 동일하다면 이것을 1:1관계라고 볼 수 있다. 하지만 이는 앞서 말했듯이 한 유저당 하나의 전화번호만 있다면 따로 관리하는 것이 아니라, 유저 테이블에 추가하여 관리할 수 있다. 실제로 그 편이 더 보편적이다.

하지만 추후 관계형 데이터베이스에서 정규화를 다루면서 1:1관계의 데이터베이스가 생성되는 경우가 있다.

2-2. 1:N관계

테이블의 레코드 하나당 여러 개의 레코드와 연결되어 있는 경우이다. 가장 흔하게 사용되는 관계이다.
<예시>

위 사진을 보면 한 유저가 한 전화번호를 가질 수 있는 것이 아니라 여러 개의 전화번호를 가질 수 있다. 하지만 하나의 전화번호는 여러명의 유저를 가질 수 없다. 즉, 한 전화번호는 한 명의 유저만이 가질 수 있다. 이것이 1:N관계이다.

2-3. N:M관계

여러 개의 레코드가 여러 개의 레코드를 가지는 관계이다. 이는 생각해보면 두 개의 1:N관계라고 볼 수 있다. 따라서 양 테이블에서 1:N관계를 형성할 수 있는 "JOIN TABLE"을 만들어서 관리하게 된다.

1:N관계와 비슷하지만 이 경우에는 양방향에서 다수를 가질 수 있는 경우에 해당한다.

예를 들어 여행 상품이 있다하자. 여러 개의 여행 상품이 있고, 이를 선택하는 여러 명의 고객들이 있다. 이때, 한 고객은 여러 개의 여행 상품을 사용할 수 있다. 마찬가지로 한 여행 상품은 여러 명의 고객을 가질 수 있다.

사진을 보게 되면 customer_package테이블의 역할은 그저 customer_idpackage_id를 묶어주는 역할을 한다. 이 테이블을 통해서 어떤 고객이 어떤 여행 상품들을 가지고 있는지 혹은 어떤 여행 상품이 어떤 고객들을 가지고 있는지 등을 확인할 수 있다. 중요한 것은 이를 따로 테이블로 생성했을 때에도 동일하게 기본키가 있어야 한다는 것이다.

2-4. 자기참조 관계(Self Referencig Relationship)

때로는 테이블 내에서도 관계가 필요할 때가 있다. 예를 들어 추천인이 누구인지 파악하거나, 조직 내에 상하 관계 등을 표현하기 위해서 사용할 수 있다.

위의 사진을 보면 유저와 그 유저가 사이트에 가입하도록 유도한 추천인에 대한 정보가 담긴 recommend_id가 존재한다.

이 관계를 살펴보면 한 유저당 한 명의 추천인을 입력할 수 있다. 하지만 추천인 입장에서는 여러 개의 유저를 가질 수 있다. 복수로 추천될 수 있다는 뜻이다.

정리하면 각 유저당 한 명만 추천하지만 추천 받은 사람은 여러 명에게서 추천을 받게 되는 셈이다. 이는 1:N관계와 유사하나 다른 테이블이 아닌 자체 테이블 내에서 관계를 가진다는 것이 차이이다.

2. 명령어

앞서 설명했듯이 이전 SQL공부 정리에서 많은 명령어를 정리하였고, 이번 수업에서 다룬 대부분의 명령어가 정리되어 있다.

1. JOIN

1-1. INNER JOIN

 SELECT <열 목록>
 FROM <첫 번째 테이블>
          INNER JOIN <두 번째 테이블>
          ON <조인될 조건>
 [WHERE 검색 조건]
 SELECT <열 목록>
 FROM <첫 번째 테이블>,<두 번째 테이블>,...,
 WHERE 첫 번째 테이블.KEY = 두 번째 테이블.KEY;

두 테이블을 연결할 때 가장 많이 사용하는 것이 내부 조인이다. 그냥 JOIN이라고 하면 보통 INNER JOIN을 의미한다. 따라서 INNER JOIN 대신 그냥 JOIN을 써도 상관없다.

1-2. OUTER JOIN

내부 조인은 두 테이블에 모두 데이터가 있어야만 결과가 나오지만, 외부 조인은 한쪽에만 데이터가 있어도 결과가 출력된다.

 SELECT <열 목록>
 FROM <첫 번째 테이블(LEFT 테이블)>
          <LEFT | RIGHT | FULL> OUTER JOIN <두 번째 테이블(RIGHT 테이블)>
           ON <조인될 조건>
[WHERE 검색 조건]

  • LEFT OUTER JOIN: 왼쪽 테이블의 모든 값이 출력되는 조인이다.
  • RIGHT OUTER JOIN: 오른쪽 테이블의 모든 값이 출력되는 조인이다.
  • FULL OUTER JOIN: 왼쪽 또는 오른쪽 테이블의 모든 값이 출력되는 조인이다.

OUTER는 생략해도 상관없다. JOIN에 대해서는 직접 해보면서 실습을 통하여 감을 익히는 것이 중요한 것 같다. 아래에 원하는 영역에 대해서 Query문을 작성해주는 사이트를 첨부한다.

💡 SQL Joins Visualizer
사이트 주소: https://sql-joins.leopard.in.ua/

3. 회고

뭔가 비슷하듯 다른게 화가난다. MYSQL은 들여쓰기 안하고도 테이블을 잘 만들던데 sqlite는 왜 들여쓰기를 꼭 해야하는지 그것 때문에 시간 버렸다...사실 버렸다기 보다는 나의 안일함 때문이긴 하다. 그냥 당연히 똑같을 줄 알았다...내용 자체가 어렵다기 보다는 막 여기저기 테이블에서 합치고 가져오고 하는 것을 구상하는게 좀 힘든 것 같다.

뭔가 더 열심히 해야하는데라는 마음과 생각은 계속 드는데 몸은 점점 게을러져 가는게 느껴진다. 고쳐야하는데 참 이게 관성이 무서운 것 같다. 특히 프로젝트 끝나면 더 심한 거 같다. 프로젝트 끝나고 2일동안 너무 빡세게 놀았는지 다시 공부하는게 참 힘들다. 그래도 뭐 별 수 있겠나 싶은 생각. 빨리 자고 내일 일찍 일어나야겠다.

참고자료
1. Entity
2. JOIN

0개의 댓글