관계형 데이터베이스 및 PostgreSQL

https://holix.com/course/development-data/UX25

나의 첫 코딩 수업 - AI를 이용한 개발 완벽 가이드 | 홀릭스(HOLIX)

 

데이터베이스의 필요성

- 구조적이고 형식에 맞는 저장을 하고, 새로 생긴 데이터를 잘 저장을 하면,

1. 데이터의 정합성을 관리하기 더 쉬움, 정합성이라는 건, 데이터가 서로 모순이 없는 상태

2. 쓰고 읽는 속도를 최적화할 수 있음. 저장,불러오기, 쿼리 등등

3. 표준을 만들어 타 프레임워크와 호환성을 높일 수 있음

4. 백업과 복원이 쉬움

5. 이벤트(transaction)를 완성도 있게 처리할 수 있음 --> ACID

 

Transaction 트랜잭션의 주요 특징 ACID : 트랜잭션은 데이터베이스의 상태를 변하게 하는 하나의 작업 단위. 일련의 작업들을 하나의 논리적인 작업으로 묶는 것을 말함.

- Atomicity (원자성) - 트랜잭션의 모든 작업이 완전히 실행되거나, 전혀 실행되지 않도록 보장. 중간에 오류가 발생하면 모든 작업이 취소되도록 처리.

- Consistency (일관성) - 트랜잭션이 완료되면 데이터베이스가 일관된 상태를 유지해야 함. 트랜잭션 실행 전후로 디비의 상태는 정의된 규칙에 따라 유효해야 함.

- Isolation (격리성) - 여러 트랜잭션이 동시에 실행될 때, 각각의 트랜잭션이 독립적으로 처리되어야 함. 다른 트랜잭션에 영향을 주지 않도록 하는 것이 중요

- Durability (지속성) - 트랜잭션이 성공적으로 완료되면, 그 결과가 디비에 영구적으로 저장되어야 함.

 

예를 들어, 은행 계좌에서 A 계좌에서 B 계좌로 돈을 이체하는 트랜잭션이 있을 때, A 계좌에서 돈이 빠져나가고 B 계좌에 입금이 완료되지 않으면 안 되겠죠? 이런 과정을 통해 데이터의 일관성을 유지하고, 문제가 생기면 원래 상태로 되돌릴 수 있도록 도와주는 것이 트랜잭션 Transaction 임!

---

DBMS - database management system - 데이터를 효율적으로 저장하고 관리하며, 사용자들이 데이터를 쉽게 검색하고 수정할 수 있도록 도와주는 소프트웨어

1. 데이터 저장과 관리 : 데이터를 구조적으로 저장하고 필요한 경우 데이터를 빠르게 찾아줌

2. 데이터 보안 : 데이터를 보호하고, 접근 권한을 관리해서 허가된 사용자만이 데이터를 조회하거나 수정할 수 있게 함.

3. 데이터 무결성 유지 : 데이터의 정확성과 일관성을 보장하기 위해 데이터에 적용할 규칙을 설정

4. 동시성 제어 : 여러 사용자가 동시에 데이터에 접근할 때 충돌이나 데이터 손상이 없도록 제어함

5. 백업과 복구 : 데이터의 손실이나 오류에 대비해 백업 기능과 복구 기능을 제공함.

예시로 많이 쓰는 DBMS가 MySQL, PostgreSQL, Oracle, Microsoft SQL 등이 있음.

DBMS 는 데이터를 체계적으로 저장하고 관리하여 필요한 정보에 빠르게 접근하고 수정할 수 있도록 해주는 프로그램.

 

대학교 3학년 때, DB 수업을 들었다. 그 때는 MySQL을 썼던 거 같은데, Oracle 이라는 단어도 봤던 걸로 봐서는 2 가지 DBMS를 다 썼던 게 아닐까 싶다. 학점은 A0 이었던 거 같은데, 역시나 다시 공부해야하지 않을까 싶다. 그래도 기억이 좀 나니까 도움이 되긴 하네.

---

관계형 DB - Schema

 

1. 데이터 타입을 하나의 표로 나타내고

2. 타입들 간의 관계로 데이터를 쓰고 읽음.

출판사를 예로 들면,

출판등록번호	사명	창사일	소개	출판 수
123456	황금	1945	~~~~	1111
000001	가지	2000	어쩌구 저쩌구	2222
......	......	......	......	......

 

이렇게되면, 첫째 행이 데이터의 모양 Model, Schema를 결정하는 것.

Type, Class 와도 연결된 개념이다.

 

저 중에서 어떤 건 primary key가 되고, 다른 DB 테이블이랑 연결지을 수도 있고 했던 걸로 기억한다.

대학 때 DB는, 나에게 이해가 되게 잘 되는 분야였던 거 같다. 굿굿.

 

즉, Schema 라는 건, 저렇게 DB 테이블을 하나 만드는 거라고 생각하면 쉬움.

 

---

관계형 DB - Record

새로운 DB 테이블이 있다.

책 출판과 관련된 테이블이 있다고 해보자.

ISBN	책 제목	출판사명	작가명	책 내용	출판 일수

위의 테이블에서, 새로운 책이 생기게 되어서, 목록에 추가하게 되는 순간이 있을 것이다.

그래서 새로운 책이 생기면, Schema에 맞게 데이터를 입력해서 추가할 수 있다.

기록한다는 의미에서 Record. 한 줄 추가하는 걸 Record.

이거는 새로운 Object, Instance가 생겼다라고 생각할 수 있기 때문에 Object, Instance와 동일한 개념처럼 보면 된다.

---

관계형 DB - Relation

여기서, 출판사랑 책 정보랑 연결시켜서, 어떤 출판사가 어떤 책을 출판했는지를 나타낼 수 있다.

출판사 하나는 여러 책을 출판했을 수 있다. 그리고 책 하나는 무조건 출판사 하나와 연결이 된다.

출판사, 책의 관계는

One to Many (1:N) 의 관계

그럴 때, 출판사의 출판 번호가 두 테이블에 다 있으면, 그것으로 연결될 수 있다고 생각함.

그래서, 1번 표의 고유 번호, Primary Key (PK) 는 출판 번호가 된다.

2번 표의 고유 번호는, PK는 ISBN 이 된다.

그리고 2번 표에서 1번 표의 고유 번호인 출판 번호를 가지고 와서 기록하게 되면, 그 2번 표에서의 출판 번호가 있는 해당 열의 경우에는 Foreign Key (FK) 라고 해서, 다른 표의 누군가를 특정할 수 있는 열을 의미하게 된다.

그래서 2번 표의 입장에서 보면, 1번 표의 PK를 가지고 온 것이다. 외부의 정보, 그래서 Foreign 이라고 함.

 

 

졸업한 지 오래되었지만, 그래도 기억이 잘 나긴 나는구나ㅋㅋㅋㅋㅋ 신기. 이게 뭐라고 이렇게 기분이 좋을까 싶네.

---

N:N Relation

이라고 하면, 1번 표에 2번 표의 PK를, 2번 표에 1번 표의 PK를 가지고 와서, 서로가 서로의 PK를 가지고 와서 FK 를 만들어놓으면 해결가능한 것이라고 생각함.

사람 --- 채팅방

의 관계를 생각해보면, 사람 1명이 많은 채팅방에 참여하고 있다.

그리고 채팅방 1개에 여러명의 사람들이 참여되어 있다.

N 이라는 건, 추가될 수도 있고 삭제될 수도 있다는 의미이다.

그러니까, 사람 1명이 채팅방에 참여하고 있는데, 추가로 채팅방이 생길 수도 있고 기존 채팅방에서 나올 수도 있다.

그리고 채팅방도 마찬가지다. 사람이 추가로 들어올 수도 있고, 사람이 나갈 수도 있다.

N 이라는 의미는, 고정된 숫자가 아니라 변동될 수 있다는 의미이기도 하다는 것.

암튼, N:N 의 관계는, 서로가 서로를 참조하면 된다고 생각함.

 

1:N의 경우에는, N 쪽에서 1의 PK 를 FK 로 참조하면 된다.

근데, N:N 의 경우에는 단순히 서로가 서로를 참조하는 방법으로는 안 된다.

 

그래서, 아예 그 관계성을 테이블로 만드는 것. 그러니까 사람과 채팅방의 연결선을 표현하는 테이블을 작성해둔다.

그걸 Junction Table, Linking Table 이라 한다.

N:N 관계인데 연결에 의미가 불명확하면 두 테이블명을 붙여서 이름을 짓는다.

그러니까,

연결번호 / 참여한 사람 / 참여한 채팅방

이런 식으로 테이블을 만들어서 관리를 할 수가 있음.

질문. 근데 왜 서로 참조를 하면 될 거 같은데 왜 안 될까?

 

관계에서는 단순히 서로가 서로의 기본 키(PK)를 참조하는 방식으로는 해결이 안 되는 이유는 데이터의 중복성과 유연성 문제 때문이에요.

예를 들어, 사람과 채팅방 관계를 생각해 볼게요. 사람 1명이 여러 채팅방에 참여할 수 있고, 하나의 채팅방에 여러 사람이 들어갈 수 있습니다. 만약 각 테이블에 상대방의 PK를 외래 키(FK)로만 추가하면, 여러 관계를 효율적으로 표현하기 어려워져요. 아래 두 가지 문제점이 생깁니다:

1. 데이터 중복:
   • 예를 들어 채팅방 테이블에 여러 사람을 기록하고자 할 때, 채팅방마다 사람이 여러 명 참여하는 경우를 일일이 기록하려면 같은 채팅방 ID가 여러 번 등장해야 합니다. 이러면 테이블에 데이터 중복이 생기고 관리가 어려워집니다.
   • 반대로 사람 테이블에도 참여하는 채팅방을 모두 기록하려면 같은 사람 ID가 반복적으로 등장하게 되죠.
2. 유연성 부족:
   • 사용자가 새로운 채팅방에 참여하거나 기존 채팅방에서 나가거나, 새로운 사람이 채팅방에 들어오고 나가는 등의 관계 변화가 생길 때마다 기존 테이블을 자주 수정해야 합니다.
   • 만약 단순히 PK-FK 참조 방식으로만 구현하면 유연하게 관계를 표현하기 어렵고, 테이블 자체가 점점 비효율적으로 변합니다.

이 문제를 해결하기 위해 Junction Table 또는 Linking Table이라는 중간 테이블을 사용합니다. 이 테이블은 각 관계의 연결을 표현하는 새로운 테이블로, 각 행이 사람과 채팅방의 참여 관계를 나타냅니다.

예: 사람_채팅방 Junction Table

연결 번호사람 ID채팅방 ID

1	100	1
2	101	1
3	100	2

이렇게 중간 테이블을 사용하면 각 사람이 여러 채팅방에 유연하게 참여할 수 있고, 채팅방이 다양한 사람을 포함할 수 있어요.

중간에 추가로 테이블을 만드는 일이 늘어나지만, 데이터의 중복을 줄이고 관계를 유연하게 관리할 수 있어 장기적으로 훨씬 효율적이죠. 이 방식의 장점들을 조금 더 구체적으로 살펴보면 다음과 같습니다:

1. 데이터 중복 감소:
   • N관계에서는 각 테이블에 상대방의 데이터를 넣으려면 중복이 발생하지만, Junction Table을 사용하면 데이터가 중복 없이 필요한 정보만 저장됩니다.
2. 유연한 관계 관리:
   • Junction Table을 통해 언제든지 사람과 채팅방의 관계를 추가하거나 삭제할 수 있어요. 사람이 채팅방에 새로 들어가거나 나가는 것처럼 관계가 자주 변동될 때, 각각의 테이블에 직접적으로 데이터를 수정하지 않고 중간 테이블에만 기록하면 됩니다.
3. 확장성:
   • Junction Table을 사용하면 각 관계에 추가적인 정보를 저장할 수도 있어요. 예를 들어, 사람이 채팅방에 참여한 시간을 기록하거나, 채팅방 내에서의 역할을 구분하는 정보도 추가할 수 있습니다.

비록 테이블이 하나 추가되긴 하지만, N

관계에서는 이 방식이 데이터베이스 관리와 유지보수 측면에서 훨씬 더 안정적이고 확장성 있는 구조를 만들어줘요.

---

사람, 채팅방, 메세지의 관계를 생각해보면 어떨까?