데이터베이스
여러 응용 시스템들의 통합한 정보들을 체계를 갖춰 구조화 해놓은 집합체이다.
데이터베이스는 여러 정보들은 각각의 파일로 통합해 관리되고, 각 시스템이 접근하여 정보처리를 한다.
즉, 동일한 데이터가 목적에 따라 다르게 응용하여 사용될 수 있다는 것이다.
왜 필요한 가? DB의 특징
데이터 저장은 파일에 데이터를 저장하거나, 인메모리 형태로 임시 저장하는 방법이 있음에도 굳이 데이터베이스를 사용하는 이유가 무엇일까?
- In-Memory 방식은 데이터가 프로그램의 실행에 의존한다.
이는 예기치 못한 상황으로부터 데이터를 보호할 수 없다. - File I/O 방식은 데이터량이 많아질 수록, 파일의 크기가 커질수록 비효율적이다.
엑셀이나 CSV 파일 형태는 데이터를 다루는데 적절해보이나 한계가 존재한다.
데이터가 필요할 시 매번 전체 파일을 읽어야하므로 크기가 커질수록 작업이 버거워진다.
복잡하게 얽힌 데이터량이 많아질수록 작업이 힘들어진다.
(중복, 비일관성, 유지보수, 보안성, 저장공간 등..)
실시간 접근성, 데이터 접근 용이함
데이터베이스를 이용하면 적시적소에 데이터를 부를 수 있다.
관계형 데이터베이스에서는 엑셀이나 CSV 파일같은 파일을 한개의 테이블로 저장하고
한번에 여러 테이블을 가질 수 있기 때문에 SQL로 데이터를 불러오기 수월하다.
혹 대용량의 데이터를 저장하고 빠르게 불러오는 것이 목적이라면 NoSQL이 적절하다.
데이터베이스와 스프레드 시트의 차이점
데이터베이스와 스프레드 시트(예: Microsoft Excel) 모두 정보를 편리하게 저장할 수 있지만 차이점이 있다.
- 데이터 저장 및 조작방법
- 데이터에 엑세스 할 수 있는 사람
- 저장할 수 있는 데이터량
데이터 공유 가능
스프레드 시트는 한명의 사용자를 위해 설계되었기 때문에
’복잡한 데이터 조작이 필요없는’ 단일 사용자나 적은 수의 사용자에게 적합하다.
반면에 데이터베이스는 엄청난 규모의 조직화된 정보 모음을 보유가능하도록 설계되었기 때문에
여러 사용자가 동시에 데이터에 빠르고 안전하게 액세스 및 쿼리할 수 있다.
데이터베이스의 진화
데이터베이스는 1960년대 초에 첫 등장한 이후로 계속해서 발전하고 있다.
계층적 데이터베이스(1:N 관계 트리 형태)와 네트워크 데이터베이스같은
탐색 데이터베이스가 데이터 저장 및 조작에 사용된 초기 시스템이었으나 유연성이 부족했다.
1980년대에 관계형 데이터베이스가 지배했고, 1990년대에는 객체 지향 데이터베이스가 등장했다.
인터넷 성장으로 비정형 데이터의 속도 및 처리를 위한 대응책으로 NoSQL 데이터베이스가 등장한다.
오늘날에는 클라우드 데이터베이스와 자율 운영 데이터베이스가 데이터 수집, 저장, 관리 및 활용 방법에 있어 새로운 지평을 열고있다.
데이터베이스의 트렌젝션
Transaction ; 처리 과정
하나 이상의 쿼리를 모아놓은 하나의 작업 단위
데이터베이스 트랜잭션은 ACID라는 특성을 가진다.
1. Atomicity - 원자성
모든 작업이 전부 성공하거나 전부 실패해서 결과를 예측할 수 있어야 한다.
성공 또는 실패 라는 두 개의 결과만 존재하는 트랜잭션은, 중단으로 미완료된 작업이 없어야 한다.
2. Consistency - 일관성
트렌젝션이 실행된 후에도 데이터베이스의 상태는 언제나 일관되어야 한다.
3. Isolation - 고립성
모든 트랜잭션은 다른 트랜잭션으로부터 독립되어야 한다.
격리성을 지키는 각 트랜젝션은 철저히 독립적이기 때문에, 다른 트랜젝션의 작업 내용을 알 수 없다.
4. Durability - 지속성
트랜잭션이 성공적으로 수행되었다면, 해당 트랜잭션에 대한 로그가 남아야 한다.
만약 런타임 오류나 시스템 오류가 발생하더라도, 해당 기록은 영구적이어야 한다.
관계형 데이터베이스
데이터 사용방식에 따라 수많은 데이터베이스 유형이 만들어지고 있다.
이 중 관계형 데이터베이스는 열과 행이 있는 테이블 집합으로 구성되며 정형 정보에 액세스하는 가장 효율적이고 유연한 방법을 제공한다.
구조화된 데이터는 하나의 테이블로 표현할 수 있다.
테이블을 사용하는 데이터베이스를 관계형 데이터베이스(Relational database)라고 한다.
키워드
- 데이터(data): 각 항목에 저장되는 값
- 테이블(table; 또는 relation) : 미리 정의된 열의 데이터 타입에 따라 작성된 데이터가 행에 축적된다.
- 칼럼(column; 또는 field) : 테이블의 한 열(세로)
- 레코드(record; 또는 tuple) : 테이블의 한 행(가로)에 저장된 데이터
- 키(key) : 테이블의 각 레코드를 구분할 수 있는 고유한 값으로 각 레코드마다 키(PK)를 가진다.
고유 키를 통해 해당 레코드를 찾거나 참조(reference)한다.
데이터베이스 설계
Schema
스키마는 "개요, 도면, 도식화"로
데이터가 구성되는 방식과 서로 다른 엔티티(entities)(테이블)과의 관계에 대한 구조를 틀에 맞춰 구상하는 것을 말한다.
테이블 간 관계 종류
각각의 테이블은 서로 상호관련성을 가지고 연결될 수 있다.
Foreign Key (외부키, 외래키, FK)라는 개념을 사용하여 서로 연결한다.
1:1
테이블 A의 레코드와 테이블 B의 레코드가 정확히 일대일 매칭이 되는 관계를 one to one 관계라고 한다.
이 관계는 자주 사용하지 않는다. 1:1로 나타낼 수 있는 관계라면 연결이 아니라 직접 칼럼을 만든다.
1:N
하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우를 one to many 관계라고 한다.
이 일대다 관계는 관계형 데이터베이스에서 가장 많이 사용한다.
각 고객은 여러 제품을 구매할 수 있지만 구매된 제품의 주인은 오직 한 고객 뿐이다 - one to many
한 이용자가 전화번호를 여러개 가질 수 있지만 그 전화번호의 주인은 오직 한 명이다 - one to many
N:N
여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우
N:N(다대다) 관계를 위해 스키마를 디자인할 때에는, Join 테이블을 만들어 관리한다.
한 고객은 여러 여행 상품을 구매할 수 있고, 한 여행 상품은 여러 고객이 구매할 수 있다. - Many to Many
N:N 관계를 위한 테이블 "조인 테이블"
두 개의 테이블과 1:N 관계를 형성하는 새로운 테이블로 N:N 관계를 나타낼 수 있다.
customer_package 테이블은 customer_id와 package_id를 묶어주는 역할이다.
이 테이블을 통해 어떤 고객이 몇 개의 여행 상품을 구매했는지, 어떤 여행 상품이 몇 명의 고객을 가지고 있는지 등을 확인할 수 있다.
조인 테이블 역시 기본키(여기서는 cp_id)가 반드시 있어야 한다.
💡만약 외래키를 리스트 형식으로 관리하는 필드가 있다면, 어떤 문제가 발생할 수 있을까?
자기참조 관계(Self Referencing Relationship)
때로는 테이블 내에서도 관계가 필요하다.
예를 들어 추천인이 누구인지 파악하기 위해 사용할 수 있다.
한 명의 유저는 한 명의 추천인를 가질 수 있으나 여러 명이 한 명의 유저를 추천인으로 등록할 수 있다. - Self
1:N 관계와 유사하지만, 일반적으로 일대다 관계는 서로 다른 테이블의 관계를 나타낼 때 표현하는 방법이다.
