Attribute 후보에 대한 예외 경우

데이터 모델링을 할 때, 비즈니스 룰에서 Attribute를 찾아내는 과정이 있습니다.
일반적으로 "하나의 값으로 표현할 수 있는 명사"는 Attribute 후보로 봅니다.

하지만, 이 규칙에는 예외가 있습니다.
바로 하나의 값으로 표현할 수 있는 명사라도, Entity로 만들어야 하는 경우입니다.

---

1. Attribute가 아닌 Entity로 만들어야 하는 경우

조건: 동일한 속성을 한 Entity 안에서 여러 개 저장해야 할 때

예를 들어,

"유저는 여러 개의 주소를 가질 수 있다."

라고 가정해봅시다.

이 상황에서 주소를 단순히 User 테이블의 Attribute로 넣으면 어떤 문제가 생길까요?

---

2. 잘못된 모델링이 초래하는 문제점

문제 1. Null 값 증가

• 유저가 주소를 여러 개 가질 수 있다면, 주소를 address_1, address_2, address_3 … 이런 식으로 컬럼을 만들어야 합니다.
• 하지만 대부분의 유저가 주소를 하나만 갖고 있다면 나머지 컬럼들은 Null로 채워지게 됩니다.
• Null은 DB 공간을 낭비하고, 데이터 해석을 애매하게 만들어 부정적입니다.

---

문제 2. 컬럼 수 확장 문제

• 유저가 주소를 3개만 가질 거라 가정하고 컬럼을 3개 만든다고 해도,
  만약 어떤 유저가 4개를 등록하고 싶다면 DB 구조 자체를 변경해야 합니다.
• 이렇게 되면 테이블 구조가 불필요하게 자주 바뀌고, 확장성이 떨어집니다.

---

문제 3. 조회(Query) 복잡성

• 특정 유저의 주소를 조회하거나, 모든 유저의 주소를 검색하려고 하면 SQL이 복잡해집니다.
• 특히 특정 주소만 조건으로 검색할 때 WHERE 절이 난잡해집니다.

---

3. 올바른 모델링 방법

주소를 User 테이블에 직접 넣지 말고, Address라는 별도의 Entity로 분리합니다.

user 테이블	Address 테이블
user_id (PK)	address_id (PK)
name	user_id (FK)
email	address_detail
...	...

• Address 테이블은 user_id를 Foreign Key로 갖습니다.
• 이렇게 하면 유저가 주소를 여러 개 등록해도 Address 테이블에 행(Row)만 추가하면 되므로 확장성이 뛰어납니다.

💡 장점

1. Null 값 최소화
2. 테이블 구조 변경 불필요
3. SQL 조회 간단화

하나의 값으로 표현할 수 있는 명사는 attribute 후보이다. 단 여러값을 가질 수 있다면 entity후보다.