[KB IT's Your Life 7기] 13주차 후기 - MYSQL과 DBMS

 

 

안녕하세요!

알고리즘 특강까지 다 끝나고, 이제 DBMS로 들어갑니다!

디비 커리큘럼이 생각보다 길어서 놀랐지만 ~

JDBMS까지 상세하게 배우는 것 같아서 좋네요!!

 

이거 다 끝나면 Spring배우고 프로젝트..

벌써 3개월이나 지났다는게 넘 신기하네요 :)

배운 내용 정리해보겠습니다!

 

 

---

 

1. DBMS 개요

 

1. 데이터베이스란?

 

데이터베이스를 한 마디로 정의하자면

'데이터의 집합' 입니다

 

여러 명의 사용자나 응용프로그램이 공유하고,

동시에 접근 가능해야 하는 데이터의 저장 공간 자체를 의미합니다

그리고 DBMS는 이 데이터베이스를 관리하고 운영하는 역할을 합니다

MySQL, Oracle, SQL Server 같은 것들이 전부 여기에 해당하죠

 

 

2. DB/DBMS의 특징

 

DBMS를 쓰는 이유가 뭘까요?

그냥 엑셀에 저장하면 안 되나? 라고 생각할 수도 있는데

DBMS에는 엑셀에는 없는 핵심 특징들이 있습니다

 

첫 번째는 데이터의 무결성(Integrity)입니다

데이터베이스 안의 데이터는 오류가 없어야 하고,

이를 위해 제약 조건(Constraint)이라는 특성을 가집니다

 

두 번째는 데이터의 독립성입니다

데이터베이스 크기를 변경하거나 저장소를 바꿔도

기존에 작성된 응용프로그램은 전혀 영향을 받지 않아야 합니다

 

세 번째는 보안입니다

데이터를 소유한 사람이나 접근이 허가된 사람만 접근할 수 있어야 하고,

사용자의 계정에 따라서 다른 권한을 가집니다

 

이 외에도 데이터 중복의 최소화, 응용프로그램 제작 및 수정이 쉬워짐,

데이터의 안전성 향상 등의 특징이 있습니다

 

 

3. DBMS 분류

 

DBMS는 시대에 따라 발전해온 역사가 있습니다

가장 먼저 나온 건 계층형 DBMS로, 1960년대에 시작됐습니다

 

각 계층은 트리(Tree) 형태의 1:N 관계로 구성되는데,

처음 구축한 이후 구조를 변경하기가 상당히 까다롭고

접근 유연성이 부족해서 임의의 검색에는 어려움이 있었습니다

 

이 문제를 개선하기 위해 1970년대에 망형 DBMS가 등장했습니다

1:1, 1:N, N:M(다대다) 관계를 지원해서 효과적이고 빠른 데이터 추출이 가능해졌지만,

복잡한 내부 포인터 때문에 프로그래머가 모든 구조를 이해해야만

프로그램 작성이 가능하다는 단점이 있었습니다

 

그리고 현재 가장 많이 사용되는 관계형 DBMS(Relational DBMS)가 있습니다

1969년 E.F.Codd라는 학자가 수학 모델에 근거해 고안했고,

데이터베이스를 테이블(Table)이라 불리는 최소 단위로 구성합니다

 

관계형 DBMS의 장점은

업무가 변화될 경우 쉽게 적응 가능하고,

대용량 데이터 관리와 데이터 무결성 보장이 된다는 점입니다

 

단점으로는 시스템 자원을 많이 차지해서

전반적으로 느려지는 문제가 있었는데,

하드웨어가 발전하면서 현재는 사실상 해결된 상태입니다

 

4. SQL 개요

 

관계형 DBMS에서 사용되는 언어가 바로 SQL입니다

'에스큐엘' 또는 '시퀄'이라고 읽습니다

 

SQL의 특징은

DBMS 제작 회사와 독립적이고, 다른 시스템으로 이식성이 좋다는 점입니다

 

Oracle에서는 PL/SQL, SQL Server에서는 T-SQL처럼

각 회사마다 표준 SQL을 기반으로 한 자체 언어가 있지만

핵심 문법은 동일하게 적용됩니다

 

---

 

2. 데이터베이스 모델링

 

1. 데이터베이스 모델링이란?

 

데이터베이스 모델링은

현실 세계에서 사용되는 작업이나 사물들을 DBMS의 데이터베이스 개체로 옮기기 위한 과정입니다

 

쇼핑몰을 예로 들면,

현실에서는 고객이 물건을 사는 행위가 있죠

이걸 데이터베이스로 표현하면

고객 테이블, 직원 테이블, 구매 테이블, 물품 테이블 이런 식으로 변환되는 겁니다

 

모델링의 단계는 크게 세 가지로 나뉩니다

개념적 모델링은 업무 분석 단계에 포함되고,

논리적 모델링은 업무 분석의 후반부와 시스템 설계의 전반부에 걸쳐 진행되며,

물리적 모델링은 시스템 설계의 후반부에 주로 진행됩니다

 

 

2. 쇼핑몰 데이터 예제로 이해하기

 

처음에는 고객 방문 기록과 구매 내역이 하나의 테이블에 섞여 있습니다

여기서 물건을 구매하지 않은 고객은 구매 관련 컬럼이 전부 비어있는 L자형 테이블이 됩니다

이렇게 되면 낭비되는 공간이 엄청 생기죠

 

그래서 빈칸이 있는 곳과 없는 곳을 분류해

고객 테이블(userTBL)과 구매 테이블(buyTBL)로 나눕니다

이렇게 하면 공간도 절약되고, 관리도 훨씬 쉬워집니다

 

이 과정에서 핵심 개념이 등장합니다

 

 

기본 키(PK, Primary Key)는

각 행을 구분하는 유일한 값으로, 중복되지 않고 비어있지 않아야 합니다

고객 테이블에서는 고객 이름이 PK 역할을 합니다

 

외래 키(FK, Foreign Key)는

외래 키로 부모 테이블에서 유일하게 하나의 정보를 얻을 수 있습니다

구매 테이블의 고객 이름 컬럼이 고객 테이블의 PK를 참조하는 FK가 되는 거죠

테이블 간의 관계에서는 주(Master)가 되는 쪽이 부모 테이블이 됩니다

고객이 물건을 소유하는 거지, 물건이 고객을 소유하는 건 아니니까

고객 테이블이 부모, 구매 테이블이 자식이 되는 1:N 모델입니다

 

제약 조건도 중요합니다

새로운 데이터가 들어갈 때는 부모 테이블에 먼저 넣어야 하고,

데이터 삭제 시에는 자식 테이블에서도 함께 지워야 합니다

 

 

3. Workbench로 다이어그램 만들기

 

이론으로만 배운 내용을 MySQL Workbench를 활용해서

실제로 ER 다이어그램으로 시각화하는 실습도 진행했습니다

 

모델 다이어그램을 작성한 뒤 Forward Engineer 기능을 이용하면

다이어그램이 자동으로 SQL문으로 변환되어 실제 데이터베이스에 적용됩니다

 

반대로 이미 존재하는 데이터베이스를 Reverse Engineer로 불러와서

다이어그램으로 변환하는 것도 가능합니다

 

---

 

테이블을 분리하고 PK/FK로 관계를 맺는 과정이

처음에는 당연한 것처럼 써왔는데,

이번에 왜 이렇게 설계하는지 그 배경을 제대로 이해하게 됐습니다

 

L자형 테이블에서 시작해서 정규화된 형태로 변환하는 과정이

굉장히 직관적으로 설명되어 있어서 이해하기 좋았습니다

 

앞으로 SQL 문법이나 실제 쿼리 작성 파트가 기대됩니다

아무튼, 이번 주도 무사히 수료!!!!

 

---