[졸업프로젝트] 프로젝트설계 - 데이터베이스 설계
What is Database?
- 작성된 목록으로써 여러 운용프로그램과 작성된 목록으로써 여러 응용 시스템들의 통합된 정보들을 저장하여 운영할 수 있는 공둉 데이터들의 묶음
대표적인 4가지 DB 종류
- 관계형 데이터베이스(RDB, Relational DataBase) :행과 열로 구성된 테이블을 갖는 구조, SQL을 통해 데이터에 접근 및 관리
- NoSQL :RDB에 비해 덜 제한적인 일관성 모델 사용, 키-값 pair형태로 저장, 키(key)값을 이용해 데이터에 접근 및 관리
- 계층형 데이터베이스 : 데이터를 트리 구조로 정의, 부모,자식형태를 갖는 구조, 데이터 중복의 문제발생
- 네트워크형 데이터베이스 : 레코드간의 다양한 관계를 그물처럼 갖는 구조, 구조가 복잡해서 유지보수가어려움
계층형 데이터베이스의 단점을 보완한것이 네트워크형 데이터베이스이고,
네트워크형 데이트베이스의 단점을 보완한것이 관계형 데이터베이스이기때문에
RDB와 NoSQL만 살펴보겠다.
Mainly Used Database
장점
안정적이다.
사용자는 데이터 저장의 물리적 구조로부터 자유롭다.
테이블의 데이터 중복이 없어 일관성이 있으며 구조가 명확하다.
단점
데이터 스키마가 사전에 계획되어 있어야 한다.
데이터 사이에 상호 관계는 Join을 통해 일어나는데, 성능 문제가 발생할 수 있다.
Join을 통해 매우 복잡한 쿼리가 만들어 질 수 있다.
빅 데이터를 스키마에 맞추어 넣을 때 많은 시간 소용.
제품 종류
Oracle, MySQL(Oracle)
MS-SQL(Microsoft)
DB2, Infomix(IBM)
Maria DB(Sun Microsystems)
Derby(Apache)
SQLite(Opensource)
출처 : https://lazyer.tistory.com/27
장점
관계형 데이터베이스보다 유연하고 데이터의 저장 및 검색을위해 특화됨
레코드, 필드에 한 개 이상의 데이터를 갖도록 허용.
정확한 데이터 구조를 알 수 없거나 변경 또는 확장될 수 있는 경우 유용하다.
관련 데이터를 동일한 컬렉션에 넣으며, 수평적 확장에 유리하다.
읽기(read)의 빈도 수가 변경(update)의 빈도 수 보다 많을 때 유용.
Key값에 따른 Sharding이 더 쉽다.
단점
릴레이션이 아니므로 고정된 스키마가 없다
Join이 힘들다.(Join을 한다기보단 Embedded Document하여 유사하게 동작하는 방식 사용)
MongoDB Join : 네이버 블로그 (naver.com)
https://m.blog.naver.com/theswice/221066958293
유연성으로 데이터 구조를 결정하지 못할 수 있음
데이터의 중복 가능 (수정의 어려움)
제품 종류
1) Document방식
- MongoDB(MongoDB Inc.), CouchDB(Apache) : Json, XML과 같은 Collection 데이터 모델 구조 사용
2) Key - Value 방식
- Redis, Memchached : 둘다 In-memory DB이기도 하며 Key와 Value의 데이터가 쌍으로 저장되는 가장 단순한 데이터 모델 구조 사용
3) Big Table DB
- HBase, Cassandra, Hypertable, ScyllaDB : Key-Value 형에서 발전된 형태인 Column Family 데이터 모델 구조 사용
출처 : https://lazyer.tistory.com/27
+ SQL Lite
지금까지 살펴본 DBMS들은 서버-클라이언트 구조에서 대규모 데이터베이스 관리를 위한 시스템이다.
그러나 sqlite는 이와 달리 로컬에서 사용하는 경량 데이터베이스.
원격 Connection이 발생하지 않기 때문에 데이터로의 접근이 매우 빠름.
아이폰이나 안드로이드 등의 모바일에서 많이 활용된다. (오픈소스)
출처: https://khanrc.tistory.com/entry/데이터베이스의-분류와-종류 [khanrc's blog]
DataBase By function
무작정 MariaDB를 사용해서 JDBC를 이용해 접근하겠다! 가 아닌
우리가 구현하려는 기능이 무엇인지 알고 그 기능에 필요한 데이터와 우리가 사용할 언어에 최적화된 DB를 찾아야했다.
내가 진행하는 프로젝트에서 데이터들을 저장해야하는 파트는 아래와 같다.
- 회원정보저장
- 회원의 버킷리스트
- 카테고리별 분류와 특성
- 장소
1. 회원정보저장
회원 ID, PW, 별명, 버킷리스트 등을 속성으로 두어 테이블로 작성해도 상관없을 듯하다.
이 파트는 MariaDB를 사용
혹은 iOS와 안드로이드에서 가볍고 빠르게 DB접근을 수행하기위해 사용되는 SQLlite를 사용 해보는것도 좋을듯 하다.
회원정보 DB 테이블 작성법
https://linuxism.ustd.ip.or.kr/428
SQLite를 사용해야 하는 이유 - ITWorld Korea
https://www.itworld.co.kr/news/117213
2. 회원의 버킷리스트
버킷리스트를 계속 업데이트해야하고
UserID, 대분류, 중분류, 소분류, BucketListID 등 구조가 명확하기때문에
MariaDB 혹은 SQLlite를 사용
3. 카테고리별 분류와 특성
추천시스템을 구현하기위해 분류별 특성이 다양하게 있을 것이므로
레코드에 한 개 이상의 데이터를 넣을 필요가있고, 분류별로 얼만큼의 특성이 있을지 불분명하다.
또한 카테고리를 업데이트하는 경우는
사용자가 기존 카테고리가 없는 활동을 버킷리스트에 넣으려고 할때이므로
데이터베이스에 대해 쓰기보다 읽기를 자주 할 것같아 NoSQL
그 중, RDBMS와 비슷해서 쉽게 적응할 수 있다는 MongoDB로 우선 선택하고
좀 더 찾아보고 적용 할 수 있을지 조사해보면 될 것 같다.
예를들어)
대분류가 음식점
중분류가 중식
소분류가 마라탕이라면
음식점 특성 - 먹는 것과 관련된 활동, 친구나 가족을 만날때 빈도수가 높은 활동
중식 특성 - 아시아의 음식, 중국의 음식, 기름짐, 느끼함
마라탕 특성 - 매움, 얼큰함, 최근에 유행
4. 장소
구글링해서 사람들이 실제로 구현해본 결과들을보면
MySQL을 이용해서 이미지파일을 바이너리형태로 넣고 위도,경도도 넣으므로
기존에 배웠던 MariaDB를 사용해도 될 것 같다