BABIL_DB스키마

큰일난것 같다. DB를 너무 쉽게 생각한 모양이다. 왜 그러는지는 명세를 작성하며 정리해보자.

 

 먼저 모듈 얘기 부터 하자. 우리는 바빌키를 판매한다. 판매한 바빌키는 구매한 소비자에게 넘어갈 것이고, 소비자는 앱을 이용하여 어떤 인증과정을 통해 해당 바빌키를 활성화 시킨다. 활성화 과정 중, 유저는 자신의 바이크 정보를 앱에 기입한다. 우리 쪽에서는 이제, 어떤 사람이 (가입해야지만 활성화가 가능하니까 결국 활성화 한 사람이 누군지 알 수 있는것), 또 어떤 바이크에 장착하여, 어떤 바빌키를 이용하는지 알 수 있게된다! 유저가 바빌키를 이용하던 도중 문제가 발생할 수 있다. 그렇다면, 우리는 바빌키 장착 후 얼마만큼 시간이 지나서 문제가 발생했는지 (장착해야지만 모듈이 가동될테니까), 어떤 모델에 장착했을 때 문제가 발생했는지, 또 as가 필요하다면 그 모듈이 진짜 우리 제품이 맞는지 등을 확인 가능해야 한다.

 

1. 바빌키를 판매

 판매라... 판매라면, 판매 여부를 알 수 있어야 겠네? 또 언제 판매 됐는지도 알아야하나? 근데 적다보니까 생각나는게, 이런 부분을 우리가 알필요가 있냐 라는것. 일단 몰라도 되는걸로.

2. 인증과정을 통해

 인증이라는 것은, 상품을 받은 소비자가, 뭐 거기 붙어있는 QR 코드를 찍던지 아니면 일련번호를 입력하던지 해서 실제로 이게 우리쪽 서버에 등록되어 있는 정품이 맞나, 하고 확인하는 과정이다.

-상품ID

-블루투스 uid

-블루투스 name

3. 바빌키를 활성화

 인증 완료 후, BLE 스캔으로 해당 바빌키가 주변에 있는지 확인해서 찾고, 애칭까지 지어서 서버에 내가 이 바빌키를 사용중이올시다, 하고 등록까지 완료하는것이 활성화 과정이다.

-모듈 닉네임

-활성화 타임스탬프

-활성화 한 유저의 uid

-활성화 여부 (bool)

-장착된 바이크 브랜드

-장착된 바이크 모델명

-장착된 바이크 차대번호

 

 지금 보면 크게 주체가 세가지 정도가 보인다. 첫째는 "이용자" 이고, 둘째는 "바빌 모듈" 이며, 마지막으로는 "바이크" 이다. 먼저 큰 주체 별로 구조를 만들어보고, 그에 따라 관계형 모델을 구상해봤다.

 

논리 모델

 

물리 모델

 

 가모델로, 가벼운 마음으로 최대한 아는 선에서 만들었다. 위 구조를 참고하여 firebase에서 권장하는대로 최대한 비구조화+평면화로 json 구조를 짜볼 예정이다. Product, Vehicles는 만들어둔 데이터를 올려놓을 것이고, user는 uid 하위 디렉토리에 정보들을 생성할 것이다. 그 중 vehicles는 babil key 의 id를 참조할 것이니 기억해두자.

 

 너무 귀찮아서 부연설명을 덧붙이기가 힘든데, 실제 앱과 파이어베이스에 적용하면서 좀 더 자세히 서술해 두도록 하겠다.