DB 수업 중에 함수적 의존성에 관해 교수님께서 혼신의 힘을 다하여 설명해주셨지만, 내 머리가 부족한 탓에 100% 내것으로 만들지 못했다... (교수님 죄송합니다 😭) 함수적 의존성에 관해 추가적으로 정리하고 싶어 관련 레퍼런스들을 찾아보다, 단번에 이해할 수 있도록 기가 막히게 잘 정리해놓은 두 레퍼런스가 있어 다시 한번 글을 쓰면서 정리해보고자 한다. 함수적 의존성(Functional Dependency) 함수적 의존성(Functional Dependency, FD)이란 DB 정규화 작업에 필요한 개념으로 두 attributes 집합 사이의 의존성을 나타내는 개념을 의미한다. 예를 들어 아래와 같은 테이블이 있다고 가정하자.emp_idemp_namebirth_datepositionsalary 위..
대학교 Database 시간에 하루도 빠짐없이 강조받는 말은 DB를 설계할 때부터 각 테이블에 대해 정확히 정의해야 한다는 말이다. 즉, 무작정 DB를 설계하는 것이 아니라 Table간의 관계를 고려하여 필요한 테이블만 효율적으로 만들도록 해야한다는 의미이다. 교수님께서 DB 설계에 대해 이야기하며 데이터 무결성이라는 말을 잠깐 언급하셨는데, 깊게 설명하지 않으셨지만 DB 설계 시 데이터 무결성 제약조건에 대해 깊이 생각해볼 필요가 있을 것 같아 따로 정리해보고자 한다. 데이터 무결성, 그리고 제약 조건 데이터 무결성 제약조건이란 무엇일까? 보통 데이터 무결성과 제약조건이라는 단어는 함께 쓰이는 용어이다. 이번엔 이 둘을 나누어 구분해보고자 한다. 데이터 무결성이란, DB 내에 있는 데이터의 정확성을 유..
모든 기술은 하나가 좋아지면, 반드시 하나가 나빠지기 마련이다. 서로 오르내리는 여러 지표들, 그 사이에서 절충안을 찾아내는 Trade-Off를 고려한 의사결정이 필요하다. 특히 머신러닝 엔지니어들은 각자 상황에 맞게 정확도를 택할 것인지, 속도를 높일 것인지에 대한 고민을 가지고 그 절충안을 찾기 위한 노력이 필요하다. 특히 머신러닝에서 편향(Bias)와 분산(Variance)의 Trade-Off는 지도학습(Supervised Learning)의 Error를 생각할 때 중요하게 생각해야하는 요소다. 아래는 Bias-Variance Trade-Off로 잘 알려진 사진 자료이다. 앞서 편향(Bias)과 분산(Variance) Trade-Off를 정리하기 이전에, 편향과 분산에 대해 간단하게 정의해보자. 편..
ML 수업과 논문에 Data Representation이라는 단어가 꽤 많이 등장한다. Data Representation, 직역하면 데이터 표현이라는 뜻으로 해석이 된다. '데이터 표현'이라는 해석만 가지고는 어느정도 유추가 가능한데, 본격적인 논문 파훼 이전에 정확히 머릿속에 정의해놓아야 할 필요성을 느껴 이번 기회에 정리해보고자 한다. Data Representation Data Representation은 모델링 이전에 데이터를 어떻게 표현해야하는지에 대한 고찰이라고 할 수 있다. 컴퓨터는 사진과 영상, 그리고 자연어에 대한 의미를 파악하지 못하며 숫자만을 계산할 수 있다. 때문에 이미지 처리의 경우 사진의 특징을 잘 살리기 위해 어떻게 픽셀 데이터를 표현해야할지, 자연어처리의 경우에는 각 단어들..
ML 프로젝트를 하며, 항상 github에 프로젝트 소스를 올릴 때 폴더 구조화에 대해 고민을 했던 경험이 있다. 부끄럽지만, 지금까지는 프로젝트 폴더에 대해 다른 사람 github project를 뒤져가며 프로젝트 구조화를 얼렁뚱땅 흉내냈다. 때마침, 조만간 몇몇 프로젝트도 진행해볼 예정이라 프로젝트 구조화에 대해 확실하게 정리하고 넘어가고 싶어져 간단한 글을 남긴다. 모든 프로젝트에 있어 정답인 프로젝트 구조화 방식은 없다. 때문에, 각자 프로젝트 특징에 맞춰 진행하면 될 것 같다. 여기서는 ML 초심자의 관점으로 프로젝트 구조화에 대해 설명해보고자 한다. (Pytorch 프로젝트 구조는 따로 정리해보도록 하겠다)References ML 프로젝트시 폴더 구조화 하는 방법 관련 글실제로 프로젝트를 하다..
2024. 02. 14 (수) tistory를 시작하다. 기술 블로그를 노션에 운영해오면서 남들에게 공유하기 위해선 매 페이지마다 publish 해야하는 단점에 대해서 개인적으로 불만을 가지고 있었다. 그리고 결국.. 기술 블로그 플랫폼을 옮기기로 결정했다! 처음에 velog, notion, github.io 이렇게 총 세가지 플랫폼을 두고 나의 거취를 결정했다. velog는 개인적으로 개발인들에게 너무나도 유용한 플랫폼이라고 잘 알고 있었다. 그러나 모든 사람들이 똑같은 템플릿을 쓰는 것이 개성이 없다고 느껴졌고 (남들이 좋다고 하는건 다 따라하면서도 뭔가 나만의 개성을 잘 나타낼 수 있는 플랫폼이면 했다.) Google에 찾고 싶은 내용을 검색하면 검색 카테고리가 항상 후순위로 밀려나있는 느낌이 들었..