WebMaster

데이터베이스 설계에서 "정규화(Normalization)"는 가장 중요한 개념 중 하나다. 정규화는 데이터의 중복을 최소화하고, 데이터 일관성을 보장하며, 데이터 모델을 더 유연하게 만들기 위한 과정이다. 한마디로, 잘 설계된 데이터베이스를 만들기 위한 체계적인 절차라고 할 수 있다. 우리는 앞에서 이미 잘 설계된 member, product, orders, order_item 테이블을 만들었다. 하지만 왜 테이블을 그렇게 여러 개로 나누어야만 했을까? 모든 데이터를 그냥 하나의 큰 테이블에 저장하면 더 편하지 않을까? 이 질문에 답하기 위해, 일부러 잘못 설계된 테이블에서부터 시작해서 점차적으로 개선해 나가는 과정을 밟아볼 것이다. 이 과정을 통해 정규화의 필요성을 몸소 체감하게 될 것이다. 정규화정규..

최종 논리적 ERD한글과 영문 표기 시점개념적 모델링 단계는 모든 이해관계자가 쉽게 이해할 수 있는 용어를 사용하는 것이 좋다. 따라서 한글을 사용하는 것이 좋다.물리적 모델링 단계는 실제 데이터베이스 테이블로 만들어야 하기 때문에 반드시 영문으로 표기해야 한다. 그 중간에 있는 논리적 모델링 단계는 한글을 사용하거나 또는 한글과 영문을 병기해서 함께 표기하기도 한다. 논리적 모델링 단계에서도 한글을 사용하는 이유는 실무에서는 물리적 모델링과 논리적 모델링을 함께 진행하는 경우가 많은데, 이 경우 기획자를 포함한 이해관계자들이 모델을 쉽게 읽을 수 있어야 하기 때문이다. 1단계: 핵심 엔티티 테이블 설계가장 기본이 되는 회원(member)과 상품(product) 테이블부터 설계한다. 이들은 다른 테이블의..

쇼핑몰 MVP 개념적 모델엔티티: 회원, 상품, 주문, 결제, 배송, 주문 항목관계: 회원-주문(1:N), 주문-결제(1:1), 주문-배송(1:1), 주문-상품(M:N)은 주문 항목을 통해 1:N 관계로 해소논리적 모델링은 이 개념적 모델을 관계형 데이터베이스의 언어(테이블, 컬럼, 키)로 번역하는 과정이다. 이 단계는 단순히 "1:1"로 번역하는 것에 그치지 않는다. 우리가 논리적 모델링 단계에서 학습한 수많은 트레이드오프들을 고민하면서 제품의 현실적인 제약과 개발 효율성, 성능까지 고려하여 모델을 다듬고 최적화하는 실용적인 판단이 필요하다. 개념에서 논리로(변환의 법칙)1) 엔티티(Entity)는 테이블(Table)로 변환된다.개념적 모델에서 정의한 데이터의 묶음, 즉 엔티티는 논리적 모델에서 데이터..

현대적인 애플리케이션 개발과 데이터베이스 설계에서는 비식별 관계를 사용하는 것이 사실상 표준이다. 과거: 식별 관계가 선호되었던 이유과거에는 식별 관계를 선호하는 경향이 있었다.논리적 명확성: "부모 없이는 자식이 존재할 수 없다"는 논리적 관계를 데이터 구조에 직접적으로 표현할 수 있다는 점을 높이 평가했다.저장 공간 절약: 지금과 달리 저장 공간이 비쌌던 시절에는 "AUTO_INCREMENT"를 위한 별도의 ID 컬럼을 만드는 것을 낭비라고 생각하는 경향이 있었다.쿼리 최적화: 특정 시나리오(예: 부모와 자식을 항상 함께 조회)에서 별도의 인덱스 없이도 PK 인덱스를 바로 활용할 수 있다는 점이 장점으로 여겨졌다.하지만 이러한 장점들은 소프트웨어의 복잡성이 기하급수적으로 증가하고, 변화의 속도가 빨라..

주문(orders)과 상품(product)의 다대다 관계를 해결하는 order_item 테이블을 예로 들어보자. 비즈니스 규칙"하나의 주문에는 동일한 상품이 중복으로 들어가면 안 된다"는 아주 일반적인 비즈니스 규칙이 있다고 생각해보자. 예를 들어, "주문번호 100번(order_id)"에 "청바지(product_id)" 상품이 두 번 기록되면 안 된다. 데이터가 중복으로 쌓이면 나중에 통계를 낼 때나 재고를 계산할 때 심각한 오류를 유발할 수 있다. 식별 관계 (Identifying)DROP TABLE IF EXISTS order_item_identifying;DROP TABLE IF EXISTS product_identifying;DROP TABLE IF EXISTS orders_identifying..

비식별 관계 (Non-identifying) DROP TABLE IF EXISTS member_detail_non_identifying;DROP TABLE IF EXISTS member_non_identifying;CREATE TABLE member_non_identifying ( member_id BIGINT NOT NULL AUTO_INCREMENT, name VARCHAR(50) NOT NULL, PRIMARY KEY (member_id));CREATE TABLE member_detail_non_identifying ( member_detail_id BIGINT NOT NULL AUTO_INCREMENT, -- 독립적인 PK member_id BIGINT NOT NULL, -- 일반 컬럼 + FK ..

단순 SQL 쿼리요구사항: 특정 댓글 하나의 내용을 조회하라 비식별 관계 쿼리-- comment_id가 500번인 댓글 조회SELECT content FROM comment_non_identifying WHERE comment_id = 500;댓글의 고유 ID 하나만 알면 되므로 매우 단순하고 직관적이다.식별 관계 쿼리-- 10번 게시글의 3번째 댓글 조회SELECT content FROM comment_identifying WHERE board_id = 10 AND comment_no = 3;댓글을 찾기 위해 부모 ID와 자식 번호를 모두 알아야 한다. 애플리케이션에서 관리해야 할 값이 더 많아진다. SQL 조인과 조회식별 관계는 손자 테이블을 조회할 때 조인 없이 데이터를 찾을 수 있다.요구사항: "..

식별 관계는 부모의 식별자를 자식이 물려받는다는 점에서 논리적으로 명확해 보일 수 있다. "게시글 없는 댓글은 없다"와 같은 비즈니스 규칙을 데이터 구조에 직접적으로 표현하는 것처럼 느껴지기 때문이다. 하지만 이런 강한 결합(Tight Coupling)은 실무적인 관점에서 여러 심각한 문제점을 만드는데, 이는 애플리케이션의 유연성과 확장성을 크게 저해하는 원인이 된다. 식별 관계의 핵심적인 문제점은 다음과 같다.유연성 부족 부모와 자식이 PK로 강하게 묶여 있기 때문에, 한번 맺어진 관계를 변경하는 것이 매우 어렵다.예를 들어 댓글을 다른 게시글로 옮기는 등의 비즈니스 요구사항 변경에 유연하게 대처할 수 없다.기본 키(PK) 컬럼의 전파와 복잡성 증가관계의 깊이가 깊어질수록(자식, 손자 테이블로 내려갈수..

게시글(BOARD)과 댓글(COMMENT)의 관계를 예로 들어보자. 하나의 게시글에는 여러 댓글이 달릴 수 있다. (1:N) 이 관계를 식별 관계, 비식별 관계로 각각 모델링 해보면서 장단점을 알아보자. 비식별 관계이 방식은 자식 테이블인 COMMENT가 자신만의 고유한 기본 키(comment_id)를 가지는 구조다.ERD에서 비식별 관계는 점선으로 표시된다. 식별 관계는 실선으로 표시된다.DROP TABLE IF EXISTS comment_non_identifying;DROP TABLE IF EXISTS board_non_identifying;CREATE TABLE board_non_identifying ( board_id BIGINT NOT NULL AUTO_INCREMENT, title VARCHA..

외래 키를 어떻게 사용하느냐에 따라 관계는 크게 다음 두 종류로 나뉜다.식별 관계(Identifying Relationship)비식별 관계(Non-identifying Relationship)이 둘을 구분하는 기준은 단 하나다. "부모 테이블의 기본 키를 물려받아 자식 테이블의 "기본 키(PK)의 일부"로 사용하는가(식별 관계), 아니면 부모 테이블의 기본 키를 단순히 "일반 컬럼"으로만 사용하느냐?(비식별 관계)"물론 두 경우 모두 부모의 기본 키를 알고 있으므로 받아온 부모의 키는 외래 키(FK)가 된다. 이 선택은 데이터베이스 모델의 구조, 유연성, 확장성에 큰 영향을 미치므로, 두 방식의 차이점과 장단점을 명확히 이해해야 한다. 식별 관계, 비식별 관계 예시1) 아파트와 호수: 식별 관계의 예시 ..