2023 Google Solution Challenge
2023.02.07, 09 / 19:00 ~ 21:30
우리 팀은 파이어베이스의 Realtime Database를 사용하기로 결정해서
오늘 DB설계를 실시했다.
맨날 Relational data model만 구상하다가 Key-Value로 매칭하려니 매우 어려웠다는..
우선 기존에 구상했던 UI에 맞춰서 필요한 데이터를 하나씩 적어보았다.
그리고, 해당하는 데이터를 구할 수 있는 방법을 생각해 보았다.
API가 많으면 좋았지만, 우린 정책 관련 내용이 필요했기에.. 대부분을 어쩔 수 없이 크롤링으로 처리하기로 했다.
파이어베이스는 NoSQL이라 Relational data model로 세울 필요는 없지만,
우리가 필요한 데이터의 타입이나 두 엔터티간의 관계를 파악하기 위해서 일부로 세웠다.
따라서 이후에 Key-Value로 전환해주었다.
모니터의 여러 기능을 써보던 참에
캡처한 화면 여러 개를 끌고 와서 붙일 수 있다는 것을 깨닫고
테이블과 테이블 사이의 관계를 정의해보기로 했다.
그래야 어떤 레코드끼리 관계가 있는지 알 수 있으니까!
오랜만에 1:N, M:1, M:N 구분하는데 엄청 머리아팠다.
전공 과목 중에 데이터베이스 들을 때 되게 잘했는데 벌써 다 까먹었나..
(사람은 영화를 여러 개 예매할 수 있고, 영화는 여러 사람이 예매할 수 있으니.. 하면서 문제 풀었던 기억이!)
그리고 이 모델을 설계하면서 어떤 문제가 생길 수 있나 고민해봤는데..
생각보다 많은 문제가 있었다.
예를 들자면 가져온 데이터들을 어떻게 분류를 나눠서 사용자에게 전달할 것인가? 등
주어진 뉴스 기사를 읽고 어느 파트로 넣어야 할 지 모르잖아!
그래서 그 부분을 프론트 분들과 의논했다.
UI의 어떤 부분을 수정하면 좋을지 내 생각을 말씀드리고, 서로 조율해 나갔다.
또한, DB부분은 백엔드끼리 회의해서 나온 것이다보니 이 구조를 말로 설명하기가 난감했다.
아이패드라는 좋은 도구를 이용한 결과
직접 그리면서 서로 의견을 나누니 설명하기 훨씬 수월했고, DB 구조도 조금 수정하여 완성했다.
역시 백문이 불여일견임을 느꼈다.
이제 데이터를 크롤링하고 전처리를 깔끔하게 하면
프로젝트를 완성할 수 있을 듯 한데..
계절학기 프로젝트 마감도 얼른 해야된다!
할 일이 많은 나 ㅜ