정적과 동적 — 모델링과 하네스 구조

개념구분

5~6강의 실선(연관관계)/점선(의존관계)과 같은 질문 — '이것 없이 저것이 존재할 수 있는가'입니다.

식별관계는 부모 없이 존재할 수 없는 자식(외래키가 기본키의 일부), 비식별관계는 부모 없이도 독립적으로 존재할 수 있는 자식입니다.

스스로 확인

DB 정규화는 중복을 줄이고 무결성을 지키는 테이블 구조 최적화이고, ML의 '정규화'(Feature Scaling)는 컬럼 간 숫자 범위를 맞추는 전처리로 완전히 다른 작업입니다.

스스로 확인

HAS-A에 대응합니다. 부모 PK가 자식의 PK 일부가 되는 실선 관계입니다.

스스로 확인

업무 의미가 없어 변경에 안정적이고, 복합키보다 조인이 단순하며, PK BLOAT(복합 PK 비대화)를 막을 수 있기 때문입니다.

스스로 확인

브라우저 번들에 키가 그대로 노출되기 때문입니다.

스스로 확인

Notation(표기법)입니다. 데이터를 기록하는 기본 규칙 자체이기 때문입니다. Annotation은 그 위에 덧붙이는 부가 정보입니다.

스스로 확인

아닙니다. JOIN이 늘어 조회 성능이 떨어질 수 있어 반정규화를 하기도 합니다.

스스로 확인

아닙니다. 3대·4대로 이어지면 PK BLOAT가 생겨, 현대 권장은 비식별관계 + 대리키입니다.

자주 하는 실수

DB 정규화인지 ML 피처 스케일링인지 도메인을 밝히지 않으면 완전히 다른 두 작업이 헷갈립니다.

자주 하는 실수

레벨 구분·출력 위치 제어가 안 됩니다. logger를 쓰는 것이 맞습니다.

자주 하는 실수

되돌릴 수 없고 팀과 어긋납니다. Alembic으로 버전 관리해야 합니다.

자주 하는 실수

브라우저 번들에 키가 그대로 노출됩니다. 절대 금지입니다.

자주 하는 실수

아닙니다. DNS 전파는 최대 1~2시간 걸릴 수 있습니다. 다시 만지면 더 늦어집니다.

자주 하는 실수

빌드 로그, 운영 API 주소, CORS, 배포 환경변수까지 확인해야 합니다.

자주 하는 실수

AI가 프로젝트를 읽는 1순위가 루트의 규칙 파일이기 때문입니다.

자주 하는 실수

모델 파일이 Alembic 설정에 import되어 있는지 확인해야 합니다.

자주 하는 실수

대개 자식의 복합키 구조·제약 조건이 엉킨 것입니다.

용어

개체와 관계를 그린 데이터 모델 설계도입니다.

용어

1NF는 원자값 위반, 2NF는 완전 함수 종속 위반, 3NF는 이행 종속, BCNF는 결정자=후보키가 아닌 경우를 제거합니다.

용어

Min-Max Scaling은 0~1 범위로 매핑하고(이상치에 민감), 표준화는 평균 0·표준편차 1로 변환합니다.

용어

식별 관계가 누적되어 복합 PK가 비대해지는 현상입니다.

용어

데이터·호출 통로를 규격화해 안전하게 통제하는 아키텍처 전략입니다.

용어

예측하려는 대상 값입니다.

용어

현실 대상의 핵심만 뽑아 구조(틀)를 짜는 과정입니다.

용어

레벨을 구분해 기록을 남기는 표준 출력 도구입니다.

용어

삽입·갱신·삭제 시 발생하는 데이터 모순입니다.

용어

두 개 이상의 컬럼으로 구성된 기본키입니다.

용어

기본키가 될 수 있는 자격을 갖춘 키입니다.

용어

여러 자율 에이전트를 병렬 오케스트레이션하는 개발 플랫폼입니다.

용어

정적은 처음 정해진 값을 고수하는 것이고, 동적은 실행 중 상태를 실시간으로 반영하는 것입니다.

용어

SQLAlchemy 전용 DB 스키마 마이그레이션 도구입니다.

용어

Attribute ↔ Property, 클래스변수 ↔ 인스턴스변수, 상수 ↔ 변수 세 쌍으로 반복됩니다.

용어

축 4(정적 ↔ 동적)입니다.

용어

10절, 식별관계 ↔ 비식별관계로 데이터베이스 쪽에서 회수됩니다.

용어

역정규화(Denormalization)입니다. 조회 성능을 위해 의도적으로 구조를 단순화합니다.

종합

이 축 하나로 함수·클래스·HTTP·리액트·클로저가 전부 한 줄에 꿰이기 때문입니다.