2. 데이터베이스와 사용자 데이터 관리
2-1 사용자 데이터 모델링 : 사용자 정보의 데이터베이스 구조 설계
데이터 모델링의 세가지 관점:
1. 데이터 관점 : 업무와 데이터, 데이터간의 관계성
2. 프로세스 관점 : 업무가 실제로, 무엇을 하는지
3. 데이터와 프로세스의 상관관점 : 처리하는 일의 방법에 따라 데이터가 어떤 영향을 받고 있는지
여기서 모델링을 하는것은 데이터 관점이다.
-
데이터 모델링의 중요성 및 유의점
: 잘못된 데이터 모델링으로 인한 변경 작업으로 전체 시스템에 큰 영향을 미칠 수 있다는 것
복합한 정보 요구사항의 간결한 표현
: 간결한 데이터 모델링은 사용자들이 파악하기 쉽고 빠르다.
데이터 품질
: 데이터 보관 기간 ↑ 가치 ↑ ( 활용을 많이 하게 되기 때문) -
데이터 모델링의 3단계 진행
추상화 수준에 따라 개념적, 논리적, 물리적 데이터 모델링
개념적 데이터 모델링
추상화 수준이 높고 업무 중심적이며 포괄적인 수준의 모델링.
조직, 사용자의 요구사항 분석 -> 핵심 엔티티와 관계성을 반결 -> 엔티티 관계 다이어그램 생성.
시스템 기능에 대해 논의할 수 있는 기반을 형성하며 데이터 요구사항을 발견하는 것을 지원하는 단계.
논리적 데이터 모델링
업무의 구체적인 모습과 흐름에 따른 구체화된 업무 중심의 데이터 모델링.
key, 속성, 관계 등을 정확하게 표현하며 재사용성↑
비즈니스 정보와 논리적인 구조와 규칙을 명확하게 표현
비즈니스 데이터에 존재하는 사실들을 인식, 기록함
신뢰성있는 데이터 구조를 얻기 위해 일관성을 확보, 중복 제거, 엔티티 속성 적절함을 고려한다.
식별자 확정, 정규화, m:m 관계 해소, 참조 무결성 규칙 정의 등으로 모델을 상세화 한다.
물리적 데이터 모델링
실제 DB의 저장구조에 따른 테이블 스페이스, 성능 등 물리적인 성격을 고려하여 설계.
물리적 스키마 : 데이터가 컴퓨터에 저장되는 방법 정의
테이블, 칼럼 등 물리적 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 사용.
참고 자료
링크텍스트
2-2 SQL vs NoSQL : 데이터베이스 선택 기준
관계형 데이터베이스 :
관계형 데이터베이스 관리 시스템 (Relational Database Management System, RDBMS)
관계형 데이터베이스 관리 시스템을 따로 RDBMS라고 부른다.
MySQL
Oracle
SQLite
MariaDB
PostgresSQL
SQL
관계형 데이터베이스 관리 시스템(RDBMS)의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이다.
관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었다.
관계형 데이터베이스에서는 모두 초창기 관계 데이터베이스 시스템을 위해 만들어진 SQL이라는 언어를 사용 하므로(문법이 조금씩 다른 부분도 있다.) 관계형 데이터베이스를 SQL이라고 부르는 것이다. 즉, SQL은 관계형 데이터베이스 전용 프로그래밍 언어이다.
장점
- 명확하게 정의된 스키마, 데이터 무결성 보장
- 관계는 각 데이터를 중복없이 한번만 저장
단점
- 덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듬)
- 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
- 대체로 수직적 확장만 가능함
비관계형 데이터베이스 :
비관계형 데이터베이스란 관계형 데이터베이스를 뺀 나머지 유형을 총칭하는 뜻이다. 마치 한국어 외에는 다 외국어인 것 처럼 관계형 데이터베이스가 아닌 모든 곳에서는 NoSQL인 것이다.
주의할 점은 NoSQL 데이터베이스 또는 비관계형 데이터베이스로도 관계 데이터를 저장할 수 있다. 유연한 스키마를 제공하며, 대량의 데이터와 높은 사용자 부하에서도 손쉽게 확장이 가능하다.
관계형 데이터베이스에서는 데이터를 입력할 때 스키마에 맞게 입력해야 하는 반면, NoSQL에서는 데이터를 읽어올 때 스키마에 따라 데이터를 읽어 온다. 이런 방식을 ‘schema on read’라고도 한다.
읽어올 때에만 데이터 스키마가 사용된다고 하여, 데이터를 쓸 때 정해진 방식이 없다는 의미는 아니다.
데이터를 입력하는 방식에 따라, 데이터를 읽어올 때 영향을 미친다.
장점
- 스키마가 없어서 유연함.언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
- 데이터는 애플리케이션이 필요로 하는 형식으로 저장됨.
- 데이터 읽어오는 속도 빨라짐
- 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능
단점
- 유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
- 데이터 중복을 계속 업데이트 해야 함
- 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 함 (SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)
NoSQL 데이터베이스 유형
Key-Value 타입
- 속성을 Key-Value의 쌍으로 나타내는 데이터를 배열 형태로 저장한다.
- Key는 속성 이름을 뜻하고, Value는 속성에 연결된 데이터 값을 의미한다.
- 대표적인 Key-Value 형식에 데이터베이스에는 Redis, Amazon DynamoDB 등이 있다.
문서형(Document) 데이터베이스
- 데이터를 테이블이 아닌 문서처럼 저장하는 데이터베이스를 의미한다.
- 많은 문서형 데이터베이스에서 JSON과 유사한 형식의 데이터를 문서화하여 저장한다.
- 각각의 문서는 하나의 속성에 대한 데이터를 가지고 있고, 컬렉션이라는 그룹으로 묶어 관리한다.
- 대표적인 문서형 데이터베이스에는 MongoDB 등이 있다.
Wide-Column Store 데이터베이스
- 데이터베이스의 열(column)에 대한 데이터를 집중적으로 관리하는 데이터베이스이다.
- 각 열에는 key-value 형식으로 데이터가 저장되고, 컬럼 패밀리(column families)라고 하는 열의 집합체 단위로 데이터를 처리할 수 있다.
- 하나의 행에 많은 열을 포함할 수 있어서 유연성을 높다.
- 데이터 처리에 필요한 열을 유연하게 선택할 수 있다는 점에서 규모가 큰 데이터 분석에 주로 사용되는 데이터베이스 형식이다.
- 대표적인 Wide-Column 데이터베이스에는 Apache Cassandra, Apache HBase 등이 있다.
그래프(Graph) 데이터베이스
- 자료구조의 그래프와 비슷한 형식으로 데이터 간의 관계를 구성하는 데이터베이스이다.
- 노드(nodes)에 속성별(entities)로 데이터를 저장한다.
- 각 노드간 관계는 선(edge)으로 표현한다.
- 대표적인 그래프 데이터베이스에는 Neo4J, InfiniteGraph 등이 있다.
SQL과 NoSQL 비교
스키마 (Schema)
SQL
고정된 형식의 스키마가 필요하다. 다시 말해, 처리하려는 데이터 속성별로 열(column)에 대한 정보를 미리 정해두어야 한다.
스키마는 나중에 변경할 수 있지만, 이 경우 데이터베이스 전체를 수정하거나 오프라인(down-time)으로 전환할 필요가 있다. 즉, 수정이 힘들다.
NoSQL
관계형 데이터베이스보다 동적으로 스키마의 형태를 관리할 수 있다.
행을 추가할 때 즉시 새로운 열을 추가할 수 있고, 개별 속성에 대해서 모든 열에 대한 데이터를 반드시 입력하지 않아도 된다.
SQL과 NoSQL 선택 기준
NoSQL 기반의 비관계형 데이터베이스가 확장성이나 속도면에서 더 뛰어나다.
그러나 고차원으로 구조화된 SQL 기반의 데이터베이스가 더 좋은 성능을 보여주는 서비스도 있다.
SQL 기반의 관계형 데이터베이스를 사용하기 좋은 경우
1.데이터베이스의 ACID 성질을 준수해야 하는 경우
- SQL을 사용하면 데이터베이스와 상호 작용하는 방식을 정확하게 규정할 수 있기 때문에 데이터베이스에서 데이터를 처리할 때 발생할 수 있는 예외적인 상황을 줄이고, 데이터베이스의 무결성을 보호할 수 있다.
- 전자 상거래를 비롯한 모든 금융 서비스를 위한 소프트웨어 개발 에서는 반드시 데이터베이스의 ACID 성질을 준수해야 한다.
- 그래서 이런 경우에는 일반적으로 SQL을 이용한 관계형 데이터베이스를 사용한다.
ACID란
- Atomicity(원자성)
- Consistency(일관성)
- Isolation(격리성)
- Durability(지속성)
2.소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우
- 소프트웨어(프로젝트)의 규모가 많은 서버를 필요로 하지 않고 일관된 데이터를 사용하는 경우, 관계형 데이터베이스를 사용하는 경우가 많다.
- 다양한 데이터 유형과 높은 트래픽을 지원하도록 설계된 NoSQL 데이터베이스를 사용해야만 하는 이유가 없기 때문이다.
3.관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우 - NoSQL에서는 여러 컬렉션을 모두 수정해야 하기 때문에 비효율적이다.
NoSQL 기반의 비관계형 데이터베이스를 사용하기 좋은 경우
1.정형화되지 않은 대용량의 데이터를 저장하는 경우
- 대부분의 NoSQL 데이터베이스는 저장할 수 있는 데이터의 유형에 제한이 없다. 즉, 필요에 따라, 언제든지 데이터의 새 유형을 추가할 수 있다.
- 소프트웨어 개발에 정형화 되지 않은 많은 양의 데이터가 필요한 경우, NoSQL을 적용하는 것이 더 효율적일 수 있다.
2.클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우
- 클라우드 기반으로 데이터베이스 저장소를 구축하면, 저렴한 비용의 솔루션을 제공받을 수 있다.
- 소프트웨어에 데이터베이스의 확장성이 중요하다면, 별다른 번거로움 없이 확장할 수 있는 NoSQL 데이터베이스를 사용하는 것이 좋다.
3.빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 업데이트 하는 경우
- 스키마를 미리 준비할 필요가 없기 때문에 빠르게 개발하는 과정에 매우 유리하다.
- 시장에 빠르게 프로토타입을 출시해야 하는 경우가 이에 해당한다.
- 소프트웨어 버전별로 많은 다운타임(데이터베이스 서버를 오프라인으로 전환하여 데이터 처리를 진행하는 작업 시간) 없이 데이터 구조를 자주 업데이트 해야하는 경우, 스키마를 매번 수정해야 하는 관계형 데이터베이스 보다 NoSQL 기반의 비관계형 데이터베이스를 사용하는 게 더 적합하다.
4.읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
- 성능과 비용적인 측면에서 이득을 얻을 수 있다.
