데이터를 테이블(관계) 형태로 조직화하여 관리하는 데이터베이스 관리 시스템 각 테이블은 행과 열로 구성되며, 데이터 간의 관계는 기본키와 외래키를 통해 정의
포트폴리오 매칭 시스템의 특성과 RDBMS 적용 이유
사용자 정보, 스킬 등 정형화된 데이터를 다룰 가능성이 높음
사용자와 포트폴리오 간의 다대다 관계를 처리해야 할 가능성이 있음
NoSQL 부적합 이유
NoSQL은 테이블 간의 관계를 직접적으로 지원하지 않으므로, 사용자와 포트폴리오 간의 복잡한 매칭 로직을 구현하기 어렵다.
데이터 무결성과 일관성이 중요한 시스템에서 NoSQL은 추가적인 애플리케이션 로직을 필요로 하며, 복잡성이 증가한다.
시스템 초기 설계가 명확하고, 데이터 구조가 자주 변경되지 않는 경우에는 RDBMS의 고정된 스키마가 더 적합하기에..
VARCHAR, CHAR
VARCHAR
저장된 데이터의 길이만큼만 공간을 차지, 추가적으로 문자열 길이를 저장하기 위해 1~2바이트 더 사용
데이터 길이가 가변적인 경우 적합
CHAR
char(50)이면 저장된 데이터가 50글자보다 짧으면, 나머지 공간은 공백으로 채워짐
데이터 길이가 고정되어 있어 데이터 검색이나 비교 작업에서 속도가 더 빠름
여기서 드는 의문은 항상 varchar을 사용하는 것이 합리적이지 않나..? 왜 나누어진거지
varchar은 저장하는 데이터의 길이를 추적해야하기 때문에, 각 데이터 항목에 추가적인 1~2바이트가 필요하고, char는 고정 길이이므로 길이를 추적할 필요가 없고, 데이터가 항상 같으 크기로 정렬되어 저장된다.
char은 고정된 길이 덕분에 검색과 비교가 더빠를 수 있고, 고정된 길이의 데이터가 많으면 디스크 I/O 작업에서 이점이 있을 수 있다고 함
varchar은 데이터 길이가 다를 경우, 데이터 정렬과 검색 작업 시 추가적인 계산이 필요할 수 있음
내가 varchar로 사용한 이유는 데이터 길이가 가변적이고, 짧은 데이터 이기에 ( 이름, 이메일 주소, 게시글 제목...)
ENUM?
소셜 로그인 제공자를 ENUM으로 한 이유
ENUM은 열거형 데이터 타입, 데이터베이스에서 특정 열에 대해 미리 정의된 값들 중 하나만 저장할 수 있도록 제한하는 데 사용
ENUM은 미리 정의된 값만 저장할 수 있고, ( 위에 내가 설정한 google, github로 설정하면 이 값만 ) 내부적으로 ENUM값은 정수로 저장된다고함 (값은 정의 된 순서에 따라 저장)
=> 메모리를 절약할 수 있고, 비교 속도가 더 빠르다는 장점, 허용된 값 외의 데이터터는 삽입되지 않아서 데이터가 잘못 저장될 가능성이 줄어든다.
근데 다른 권한 레벨이나, 연차별 직책과 같은 것을 tinyint로 지정한건 확장성 때문에
그리고 enum을 사용하는 다른 이유는 데이터가 별도로 매핑 값을 확인안해도 됨
=> 이러한 생각으로 설정하였지만, 다른 분들하고 상의 해야할 듯..?
좋아요 테이블을 분리해야하는 이유는 좋아요 기능이 확장되지 않을까..? 좋아요 수에 기반해서 포트폴리오 랭킹 시스템 구현 가능할 것 같고, 사용자가 좋아요를 누른 포트폴리오를내가 좋아요한 포트폴리오목록으로 별도로 조회 가능 -> 아 이건 따로 저장 버튼 만들기로 했던 것 같기도 , 좋아요 데이터를 분석해서 개인화 추천 시스템에 활용할 수 있지 않을까..? -> 유사한 기술 스택을 가진 포트폴리오 추천???
초기 ERD 작업
확인✔️
회원 관리
소셜로그인(google, github)과 로컬 로그인 모두 지원하도록 설계?
회원의 공통 정보를 부모 테이블로 분리하고, 일반 회원/사업자 정보를 자식 테이블로 관리?
와 같이 디자이너들을 위한 포트폴리오를 모아둔 페이지는 있지만 개발자는 없기에, 참고하면서 저건 개발자가 과연 구현시킬 수 있을까 라는 생각도 많이 들었기에, 실제 개발자들이나 취준생들 구현시킨 포트폴리오 사이트를 모아둔다면 취준생들에게 도움이 되지 않을까 싶어서 ( 물론 나에게도 ㅎㅎㅎ )
이런 주제를 말했더니 딱 나온 이야기는 여기에 인사담당자까지 연결하여 실제 취업까지? 라는 의견도 나옴
여기에 살을 계속 붙이면 그럴듯한 사이트가 될 것같다.
작업분담은 프론트(최은서), 백엔드(한영신), 풀스택(이윤정, 나)로 진행하기로 함
프로젝트 생성 후 브랜치 전략(feature 브랜치)를 도입, feature-ssa 브랜치 생성하였다.
YesY Team결성🎉
일단 이번주 나의 할일은 ERD (초기 스키마) 작성하고, 주기능을 보조해줄 수 있는 편의성 기능 생각해서 정리 -> 이건 빨리 정리해서 전달해주어야 할 것 같다.
분명히 env 파일 만들고, 경로까지 다 지정을 해놨는데, 인식이 되지 않아 지도나 사진이 보이지 않음.. 직접 키를 yaml에 입력해주니 생성되는걸 확인했는데 그러면 경로의 문제는 아니고.. 근데 폴더에는 env 파일이 보이는데 sts에 env가 보이지 않음을 발견... 발견하기 전에 env를 지웠다가 리셋시켰다가.. 난리난리를
conf_thres는 탐지된 객체의 신뢰도를 나타낸 conf 값이 conf_thres 보다 작으면 해당탐지를 무시
conf_thres를 낮추면 더 많은 객체를 탐지하지만, 오탐지가 증가할 수 있다.
conf_thres를 높이면 더 높은 신뢰도로 탐지된 객체만 남는다.
iou_thres
iou_thres를 낮추면 더 많은 탐지를 허용하며, 강아지 클래스의 추가적인 탐지가 가능해질 수 있다 .
iou_thres를 높이면 중복된 탐지를 더 강하게 제거한다.
결론적으로def detect_and_crop(image_path, model, output_folder, conf_thres=0.25, iou_thres=0.2):로 진행
탐지 결과가 없거나 다른 클래스만 탐지될 경우, 해당 클래스는 무시하도록 함.
여기서 탐지 정확도를 높이기 위해서는 conf_thres를 낮추거나 모델 가중치를 변경해서 시도해보자...
이미지의 해상도, 밝기, 대조 등을 조정하여 강아지 탐지 가능성을 높이고, OpenCV의 cv2.equalizeHist 또는 cv2.resize 등을 활용해 데이터 품질을 개선
==> 다시 생각 아니 클래스를 무시하면 안되지!!!!!!! 영상 프레임 별 감지를 하는건데 무시하면 오차가 생기고 그만큼 모델 행동 분류하는데 오차가 생길거 아니냐고... 객체 감지를 하면 크롭하여 저장한 뒤 넣어두고, 객체감지 오류가 발생한경우 크롭되지 않은 원본의 데이터를 가지고 데이터 처리를 하자
크롭 완료!✨ . . .
오차는 존재....;;;
코드 흐름
labeling_dir에서 JSON 파일을 읽고, JSON 파일의 annotations에서 frame_number를 추출
frame_dir 에서 해당 frame_number에 해당하는 이미지를 읽어오고, detect_and_crop 함수를 호출하여 강아지 객체를 탐지하고 크롭된 이미지를 저장한다.
탐지된 강아지 객체의 정보를 annotations.csv 파일에 기록
csv 파일안에는 frame_number 탐지된 강아지가 포함된 프레임 번호, cropped_frame_path 크록된 강아지 이미지 경로가 들어간다. 크롭된 이미지에는 강아지 객체가 탐지된 후, 해당 영역을 크롭하여 cropped_output 디렉터리에 저장한다.