CS 강의 5. DB 구조와 유형

출처 : 내일배움캠프

 

0. 컴퓨터와 데이터베이스

컴퓨터의 여러 구조 중, 보조 기억장치는 영구 저장소로써 파일과 데이터를 저장할 수 있다. 파일은 파일시스템에, 데이터는 데이터베이스에 저장된다

0 - 1. 파일시스템 vs 데이터베이스

ex) 카카오톡 실행 파일은 파일시스템에 저장되어 있고, 카톡의 메세지 목록 등의 데이터는 DB에 저장된다

1) 파일시스템

- 개별 파일을 보관하고 정리하는 시스템으로, 여러 폴더에 파일이 저장되고 사용자는 파일을 직접 관리해야 한다

~ 파일 정리, 처리 등에 사용자의 자원이 많이 사용된다

2) 데이터베이스

- 데이터를 구조화하고 연결하는 기능을 제공한다

- 테이블, 레코드, 필드 등의 개념을 사용해 데이터를 구성하고, 데이터를 효율적으로 관리하고 검색할 수 있다

- 데이터의 일관성, 무결성, 안전성을 유지하며 복잡한 데이터 조작을 간편하게 수행할 수 있다

1. 데이터베이스

1 - 1. 데이터베이스 개요

정보 vs 데이터

정보 : 여러 종류의 문서로 흩어져있어 조합하기 어려운 단위 ~ 파일시스템 : 카카오톡을 실행할 수 있는 정보

데이터 : 정보를 체계적으로 분류해 조합할 수 있는 단위 ~ 데이터베이스 : 카카오톡의 메세지를 채팅방에 출력할 수 있는 데이터

 

데이터베이스 : 조직체의 운영 데이터들이 통합된 데이터베이스의 구조는 어떤 데이터 모델을 사용하는지에 따라 다르다

 

특징

- 데이터의 대규모 저장소로서, 여러 사용자에 의해 동시 사용

- 모든 데이터가 중복을 최소화하며 통합

- 데이터베이스는 운영 데이터뿐 아니라 그 데이터에 관한 설명까지 포함 ~ 데이터베이스 스키마 또는 메타데이터

- 프로그램 메모리가 아닌 개별 저장공간에 저장되기 때문에 프로그램 과 데이터 간 독립성 제공

- 효율적으로 접근이 가능하고 질의(쿼리)를 할 수 있다

- 데이터베이스 관리 시스템(DBMS) : 데이터베이스를 정의하고, 질의어를 지원하고, 리포트를 생성하는 등 작업을 수행하는 소프트웨어

1 - 2. 데이터베이스 시스템 개요

데이터베이스 스키마

- 전체적인 데이터베이스 구조를 뜻하며 자주 변경되지 않음

- 데이터베이스의 모든 가능한 상태를 미리 정의

ex) 사람 데이터는 이름, 키, 몸무게, MBTI 필드를 가진다

 

데이터베이스 상태

- 특정 시점의 데이터베이스의 내용을 의미하며, 시간이 지남에 따라 계속해서 바뀜

- 데이터베이스에 수정이 일어날 때마다 상태는 바뀝니다

 

데이터베이스 시스템(DBS) : DB, DBMS, USER를 포함한 가장 큰 범위

 

데이터베이스

- 조직체의 응용 시스템들이 공유해 사용하는 운영 데이터들이 구조적으로 통합된 모임

- 시스템 카탈로그( 또는 데이터 사전, Data Directory)와 저장된 데이터베이스로 구분할 수 있음

- 시스템 카탈로그(system catalog)는 저장된 데이터베이스의 스키마 정보를 유지

DBMS의 기능

- 사용자가 새로운 데이터베이스를 생성

- 데이터베이스의 구조를 명시

- 사용자가 데이터를 효율적으로 질의하고 수정할 수 있도록 함

- 시스템의 고장이나 권한이 없는 사용자로부터 데이터를 안전하게 보호

- 동시에 여러 사용자가 데이터베이스를 접근하는 것을 제어

 

데이터베이스 언어라고 부르는 특별한 프로그래밍 언어를 한 개 이상 제공

 

SQL은 여러 DBMS에서 제공되는 사실상의 표준 데이터베이스 언어

 

하드웨어

- 데이터베이스는 디스크와 같은 보조 기억 장치에 저장되며, DBMS에서 원하는 정보를 찾기 위해

디스크 블록들을 주기억장치로 읽어들어야 합니다

- 계산이나 조합 및 비교 연산들을 수행하기 위해 중앙처리 장치가 사용

- DBMS 자체도 주기억장치에 적재되어 실행되어야 함

 

데이터베이스 시스템의 요구사항

• 데이터 독립성
• 효율적인 데이터 접근
• 데이터에 대한 동시 접근
• 백업과 회복
• 중복을 줄이거나 제어하며 일관성 유지
• 데이터 무결성
• 데이터 보완
• 쉬운 질의어
• 다양한 사용자 인터페이스

1 - 3. 파일시스템 vs DBMS

파일시스템을 사용한 기존의 데이터 관리

- 파일시스템은 DBMS 이전부터 사용되었다

- 파일 접근방식이 프로그램에 자세하게 표현되므로 데이터에 대한 응용 프로그램의 의존도가 높다

단점

- 데이터가 서로 다른 다수의 파일에 중복해서 저장된다

- 다수 사용자를 위한 동시성 제어가 제공되지 않는다

- 검색 데이터를 간편하게 해주는 쿼리가 제공되지 않는다

- 보안 조치가 미흡하다

- 회복 기능이 없다

- 프로그램, 데이터 독립성이 없으므로 유지보수 비용이 많이 소요된다

- 파일을 검색하거나 갱신하는 절차가 상대적으로 복잡해 생산성을 떨어뜨린다

 

DBMS의 장점

1. 스키마 정의를 통해

- 데이터의 중복과 불일치 감소

- 표준화 용이

- 조직체의 요구사항 식별 가능

2. 관리도구를 통해

- 개발 및 유지보수 비용 감소

- 보안, 무결성 향상

- 다양한 유형의 장애로부터 DB 복구 가능

- 데이터베이스의 공유와 동시에 접근이 가능

단점

- DBMS 및 하드웨어 추가 구입비용 발생, 교육비용 발생

- 프라이버시 노출 위험 증가

 

+ DBMS 적용하면 안되는 경우

- 초기 투자비용이 너무 클 때

- 오버헤드가 너무 클 때

- 응용이 단순하고 잘 정의되었으며 변경되지 않을 것으로 예상될 때

- 엄격한 실시간 처리 요구사항이 있을 때

- 데이터에 대한 다수 사용자의 접근이 필요하지 않을 때

1 - 3. DBMS 발전 과정

1) 계층 DBMS

- 1960년대 후반 등장, 트리 구조를 기반으로 한 계층 데이터 모델을 사용한 DBMS, 계층 데이터 모델

 

장점 : 특정 유형의 응용에 대해 빠른 속도와 높은 효율 제공

단점

- 어떻게 데이터를 접근하는 지 미리 응용프로그램에 정의해야 한다

- 데이터베이스가 생성될 때 각각의 관계를 명시적으로 정의해야 한다

- 레코드들이 링크로 연결되어 있으므로 레코드 구조를 변경하기 어렵다

 

2) 네트워크 DBMS 구조

- 레코드들이 노드로, 레코드들 사이의 관계가 간선으로 표현되는 그래프를 기반으로 하는 네트워크 데이터 모델을 사용

- 네트워크 DBMS에서도 레코드들이 링크로 연결되어 있으므로 레코드 구조를 변경하기 어렵다

 

3) 관계 DBMS(RDBMS) ~ MY SQL Server, Oracle, MySQL

장점

- 모델이 간단해 이해하기 쉽다

- 사용자는 자신이 원하는 것만 명시하고 데이터의 위치와 접근 방법은 DBMS가 결정한다

 

4) 객체 지향 DBMS

- 객체 지향 프로그래밍 패러다임을 기반으로 하는 데이터 모델

 

장점 : 데이터와 프로그램을 그룹화하고, 복잡한 객체들을 이해하기 쉬우며, 유지와 변경이 용이하다

ex) ONTOS, OpenODB, GemStone, ObjectStore, O2등

 

5) 객체 관계 DBMS

- DBMS에 객체 지향 대념을 통합한 객체 관계 데이터 모델이 제안됨

ex) 오라클, infomix, Universal Server등

1 - 4. DBMS 언어

1) 데이터 정의어 (DDL)

- 사용자는 데이터 정의어를 사용해 데이터베이스 스키마를 정의

- 데이터 정의어로 명시된 문장이 입력되면 DBMS는 사용자가 정의한 스키마에 대한 명세를 시스템 카탈로그 또는 데이터 사전에 저장

 

데이터 정의어의 기본적 기능

- 데이터 모델에서 지원하는 데이터 구조를 생성

- 데이터 구조의 변경

- 데이터 구조의 삭제

- 데이터 접근을 위해 특정 어트리뷰트 위에 인덱스를 정의

 

2) 데이터 조작어(DML)

- 사용자는 데이터 조작어를 사용해 데이터베이스 내 원하는 데이터를 검색, 수정, 삽입, 삭제

- 절차적 언어와 비절차적 언어

cf)

절차적 언어 : 프로그램을 순차적으로 실행하는 방식으로 동작, 명령어와 함수의 연속으로 이루어진 프로시저를 사용해 작업을 수행한다. C, Pascal, Fortan 등이 있다

- 관계 DBMS에서 사용되는 SQL은 대표적인 비절차적 언어

- 대부분 데이터 조작어는 SUM, COUNT, AVG와 같은 내장 함수를 담고 있다

- 데이터 조작어는 입출력을 통해 수행되거나 C, 코볼 등의 고급 프로그래밍 언어로 작성된 프로그램에 내포되어 사용된다

 

데이터 조작어의 기본 기능

- 데이터의 삽입

- 데이터의 검색

- 데이터의 수정

- 데이터의 삭제

 

3) 데이터 제어어(DCL) : 사용자는 데이터 제어어를 사용해 데이터베이스 트랜젝션을 명시하고 권한을 부여하거나 취소

1 - 5. DBMS 사용자

1) 응용 프로그래머

- DB에서 특정 응용을 구현하는 역할

- 프로그래밍 언어로 응용 프로그램을 개발하며 DB에 접근할 때는 제공된 데이터 조작어를 사용한다

- 프로그래머가 작성한 프로그램에 따라 데이터베이스에 최종 사용자들이 반복적으로 접근 및 프로그램이 수행되므로 프작성 트랜젝션 또는 프로그램이라고 한다

 

2) DBA

- 데이터베이스 관리자는 조직 여러 부분의 상이한 요구를 만족시키기 위해 일관성있는 데이터베이스 스키마를 생성하고 유지하는 사람(팀)

- 물리 DB의 변경을 수행

- 데이터베이스 스키마의 생성과 변경

~ 무결성 제약조건 명시

~ 사용자 권한을 허용하거나 취소, 사용자 역할 관리

~ 저장 구조와 접근 방법(물리적 스키마) 정의

~ 백업과 회복

~ 표준화 시행

 

3) 오퍼레이터(인프라팀)

- DBMS가 운영되고 있는 컴퓨터 시스템과 전산실을 관리하는 사람

 

4) 최종 사용자

- 질의하거나 갱신하거나 보고서를 생성하기 위해 데이터베이스를 사용하는 사람

- 최종 사용자는 다시 데이터베이스 쿼리문을 사용해 매번 다른 정보를 찾는 캐주얼 사용자와 기작성 트랜젝션을 주로 반복해 사용하는 초보 사용자로 구분된다

2. 데이터베이스

2 - 1. 관계형 데이터베이스(SQL)

- 동일한 구조(릴레이션)의 관점에서 모든 데이터를 논리적으로 구성

- 선언적 질의어를 통해 데이터 접근을 제공

- 응용 프로그램들은 데이터베이스 내 레코드들의 어떤 순서와도 무관하게 작성됨

- 사용자는 원하는 데이터만 명시하고, 어떻게 데이터를 찾을지 명시할 필요 없다

- 가장 단순한 개념의 데이터 모델

 

특징

- 바탕이 되는 데이터 구조로 간단한 테이블을 사용

- 중첩된 복잡한 구조가 없다

- 집합 위주로 데이터를 처리

- 숙련되지 않은 사용자도 쉽게 이해할 수 있다

- 표준 데이터베이스 응용에 대한 좋은 성능을 보인다

 

릴레이션 : 2차원의 테이블(스프레드 시트와 유사)

레코드 : 릴레이션의 각 행

튜플 : 레코드의 공식 용어 = 로우(ROW)

속성 : 릴레이션에서 이름을 가진 하나의 열 = 컬럼(COLUMN)

 

* 파일 시스템은 레코드만 있는 파일 형태로 데이터가 존재하지만, 관계형 데이터베이스는 속성, 튜플을 가진 릴레이션(테이블) 형태로 존재한다

 

도메인

- 한 속성에 나타날 수 있는 값들의 집합

- 각 속성의 도메인은 원자값

- 프로그래밍 언어의 데이터 타입과 유사하다

- 동일한 도메인이 여러 속성에서 사용될 수 있다

- 복잡 속성이나 다치 애트리뷰트(애트리뷰트 하나에 여러 값이 들어갈 수 있는 것 ex) 학과 사무실 전화번호)

 

차수와 카디널리티

- 차수 : 한 릴레이션에 들어있는 속성의 수(필드 수)

~ 유효 릴레이션의 최소 수는 1 : 속성이 1개 이상 있어야 릴레이션이 된다

~ 릴레이션의 차수는 자주 바뀌지 않는다 : 테이블 스키마를 변경할 경우 전체 로우에 반영되어야 하기 때문에 처리가 중단된다

- 카디널리티 : 릴레이션의 튜플(로우 수)

~ 유효한 릴레이션은 카디널리트 0을 가질 수 있다

~ 릴레이션의 카디널리티는 시간이 지남에 따라 계속 변한다

2 - 2. 비관계형 데이터베이스(NoSQL)

- 관계형 데이터베이스보다 더 융통성 있는 데이터 모델을 사용하며 데이터 저장 및 검색에 특화된 매커니즘을 제공한다

- NoSQL은 분산 환경에서의 데이터 처리를 더욱 빠르게 하기 위해 개발되었다

 

특징

- 거대한 Map으로 Key-Value 형식을 지원

- 컬럼간 관계를 정의하지 않는다(PK 등)

- 스키마에 대한 정의가 없다

 

종류

1) 문서형 데이터베이스

- 데이터를 테이블이 아닌 문서처럼 저장하는 데이터베이스

- JSON과 유사한 형식으로 데이터 문서화, 저장

- 각 문서는 하나의 속성에 대한 데이터를 갖고 있고, 컬렉션이라는 그룹으로 묶어 관리 ~ MongoDB

2) Key - Value 타입

- 속성을 Key - Value의 쌍으로 나타내는 데이터를 배열의 형태로 저장

- Key : 속성 Value : 속성에 연결된 데이터 값

- Redis, Dynamo 등

3) Wide - Column Store 데이터베이스

- 데이터베이스의 열에 대한 데이터를 집중적으로 관리하는 데이터베이스

- 각 열에는 Key - Value 형식으로 데이터가 저장되고, 컬럼 패밀리라고 하는 열의 집합체 단위로 데이터를 처리할 수 있다

- 하나의 행에 다수의 열을 포함할 수 있어 유연성이 높다

- 데이터 처리에 필요한 열을 유연하게 선택할 수 있어 규모가 큰 데이터 분석에 주로 사용된다

- Cassandra, HBase 등

4) 그래프 데이터베이스

- 자료구조의 그래프와 비슷한 형식으로 데이터 간 관계를 구성하는 데이터베이스

- 노드에 속성별 데이터 저장, 각 노드간 관계는 선으로 표현한다. Neo4J, InfiniteGraph 등

- 장점 : 대용량 데이터 처리 적합, 읽기보다 쓰기가 빠르고 RDB보다 읽기 쓰기가 모두 빠름, 데이터 모델링이 유연, 확장성이 좋아 검색에 유리, 최적화된 키 저장 기법을 사용해 응답속도나 처리효율 등에서 성능이 뛰어나다

- 단점 : 쿼리 처리시 데이터를 파싱 후 연산을 해야하므로 큰 크기의 document를 다룰 때 성능이 저하됨

2 - 3. SQL vs NoSQL

1) SQL 사용이 적합한 경우

1. 데이터베이스의 ACID 성질을 준수해야 하는 경우

- SQL을 사용할 때 DB와 상호작용 방식을 정확하게 규정할 수 있어, DB에서 데이터를 처리할 때 발생할 수 있는 예외 상황을 줄이고 데이터베이스의 무결성을 보호할 수 있다

- 전자 상거래를 포함, 모든 금융 서비스 목적의 SW 개발은 반드시 ACID가 준수되어야 하므로 SQL을 사용한다

 

2. 소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우

- 소프트웨어(프로젝트)의 규모가 많은 서버를 필요로 하지 않고 일관된 데이터를 사용하는 경우 RDB를 사용

- NoSQL은 다양한 데이터 타입과 높은 트래픽도 지원하도록 설계되어 있어 굳이 사용할 필요가 없다

 

2) NoSQL 사용이 적합한 경우

1. 데이터의 구조가 거의 또는 전혀 없는 대용량 데이터를 저장하는 경우

- 대부분의 NoSQL DB는 저장 데이터 유형의 제한이 없다

- SW 개발에 정형화되지 않은 대량의 데이터가 필요한 경우 NoSQL 적용이 보다 효율적

 

2. 클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우

- 클라우드 기반으로 데이터베이스 저장소를 구축하면, 저렴한 비용의 솔루션을 제공받을 수 있습니다

- 소프트웨어 데이터베이스의 확장성이 중요하다면, 번거롭지 않게 확장할 수 있는 NoSQL이 적합할 수 있다

 

3. 빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 업데이트하는 경우

- 스키마를 미리 준비할 필요가 없어 개발 속도가 빨라진다

- 다운타임(DB 서버를 내리고 오프라인에서 데이터 처리 진행하는 시간)없이 데이터 구조를 자주 업데이트해야 하는 경우, 스키마를 매번 수정해야 하는 RDB보다 NoSQL DB가 더 적합하다