DB 모델링을 어떻게 해야될지 질문입니다. 0 6 1,981

by 신짱 [DB 모델링/설계] [2019.10.10 14:54:18]


안녕하세요.

DB 모델링을 해야되는데 최선의 방법(?)이 무엇일지 계속 고민을 해보다가 질문남깁니다.

서비스 이용시에 부가적으로 입력을 해야 되는 데이터들인데.. 

하나의 테이블로 관리를 해야될지 테이블을 쪼개서 관리를 해야될지.. 애매한 상황입니다.

일단 필요한 데이터는 아래와 같습니다.

 

# 국내개인

1. 이름(한글/영문)

2. 주민등록번호

3. 이메일

4. 휴대전화/유선전화

5. 주소

 

# 국내법인

1. 법인명(한글/영문)

2. 법인등록번호

3. 사업자등록번호

4. 대표자명

5. 대표자 주민등록번호

6. 대표자 이메일

7. 대표자 휴대전화/유선전화

8. 법인 주소

 

# 외국개인

1. 이름(한글/영문)

2. 국적

3. 외국인 등록증 여부

4. 외국인 등록번호

5. 이메일

6. 휴대전화

7. 외국인 등록증상 주소

 

# 외국법인

1. 법인명(한글/영문)

2. 국적

3. 대표자명(영문)

4. 대표자 이메일

5. 법인주소

 

# 국가기관

1. 국가기관명(한글/영문)

2. 기관번호(사업자등록번호)

3. 기관 대표 이메일

4. 기관 대표 유선전화

5. 기관 주소

 

총 5개의 유형으로 나눠져 있습니다.

이를 최대한 공통 데이터를 뽑고 나머지는 유형별로 서브테이블을 만들어야 할지.. (이 경우에 데이터를 나눌때도 애매하네요.. 같은 이메일이나 연락처라도 성격이 서로 달라서)

조언 부탁드립니다!!

by jkson [2019.10.10 16:13:25]

답변은 아니고요. 관계형데이터모델링 공부했는데 공부할 때는 아.. 하던 게 지금은 하나도 생각 안 나네요. ㅋㅋ 슈퍼타입, 서브타입.. 역시 실습이나 경험이 있어야 모델링에 대한 이해가 깊어지나봅니다.

그냥 저라면 고객 유형별로 단독으로 쿼리되는 케이스가 많다면

공통속성을 하나의 테이블로 하고 고객유형컬럼(국내개인, 국내법인, 외국개인, 외국법인, 국가기관) 하나 만든 다음에

각각의 유형마다 독립적으로 존재하는 컬럼을 모아서 테이블 하나씩 만들 거 같네요.

반대로 유형별로 단독 쿼리되는 경우보다는 전체데이터 조회가 많고 유형은 단지 구분하기 위한 용도라면

그냥 하나의 테이블에 모든 속성 컬럼 다 넣고 만들 것 같고요.

그냥 의견일 뿐 저 사람은 저렇게 생각하는구나 정도로만.. ㅎㅎ


by 생각 [2019.10.10 17:21:07]

저는 보통 공통코드를 잘 활용합니다.

짧은 지식이지만,,, 해당 내용은 비슷한 데이터가 많아 굳이 각각 테이블을 분리할 필요는 없을 것 같습니다.

1) 개인/법인 (내/외국인), 국가기관
2) 공통코드 (개인 내/외국인 10,20 | 법인 내/외국인 30,40 | 국가기관 50) 식으로 구분짓고 이를 1번 테이블과 매칭할 거 같네요. 
   좀더 컬럼이 추가된다면 공통코드를 세분화하는 것도 괜찮을 거 같구요.

 

 


by 부쉬맨 [2019.10.11 10:15:08]

공통코드냐...

목록코드냐...

집합코드냐...

계층코드냐...

반정규화해서 하나의 테이블에 코드값|코드명|주소||이메일|전화|etc1|etc2|etc3|etc4|etc5

형태로 가져가서 사용하는 방법도있고요.

코드테이블와 코드값의 테이블을 구분을 지어서 만드셔도 무방할꺼 같습니다.

해당 모델 생성시 관점은 새로운 컬럼이 생겼을때의 대처임으로 임의의 컬럼들을 몇개 생성해서 부가정보를 입력받는 형태로 진행하시면될듯

코드테이블과 코드값명의 테이블을 나누면 장점은 코드테이블에서 만료여부를 날짜나 플래그로 두어서 해당 코드값명의 정보와 조인시 사용하지않게 하면 부분적인 데이터를 만들지 않아도 되고요.

코드값명들기준으로 하나의 테이블을 만든다면 생각해야되는 부분이 많이질 여지가 있습니다. 하지만 개발자입장에서는 1안보다는 2안(반정규화 테이블)을 원할수 있으니 고민해보시면될듯 합니다.

 

 


by 꼬랑지 [2019.10.11 10:40:30]

우선 각각의 엔터티 후보들의 PK가 무엇이냐를 고려해 봐야 할 것이고

두번째로는 어떤 칼럼들이 암호화 되어야 하는지를 판단하시는게 좋을듯 합니다.

공통데이타로 판정되어 통합했는데 어떤 번호는 암호화 대상이고 어떤 번호는 암호화 대상이 아니면 골치 아플 수 있습니다.

그리고 흔히 모델링은 정답이 없다라고 말하는데 정답이 있을 수 있습니다. 그 데이타를 어떻게 사용하는지에 대한 업무 프로세스입니다.

하나의 고객이 복수개의 전화번호를 가지는데 고객-고객전화번호 두개의 엔터티로 나누지 않고 [고객번호,고객명,전화번호1,전화번호2] 이렇게 설계했다고 해서 오류인가?

엄밀히 따지면 제1정규형 위배지만 만일, 전화번호는 최대 2개만 허용되고 고객정보 조회시 항상 전화번호가 보여야 한다면 하나의 엔터티로 가는 것이 더 효율적일 수 있습니다.

모델링은 업무-데이타의 사용방법에 충실한 것이 제일 좋습니다.


by smileHaHa [2019.10.11 16:17:47]

부족하지만 데이터 아키텍쳐를 공부하고 있습니다.  

정규화를 시킨다면 테이블을 분리해서 관리하는것이 맞겠으나, 

시스템 내에서 각 유형이 같은 레벨로 관리가 된다면 테이블을 하나로 통합해서 관리하는것이 사용하기에 편할 것 같습니다.. 

아래와 같이 하나로 관리하는게 어떨지요 ? 

#고객

1. 고객ID -- ex) 고객구분코드 + 일련번호

2. 고객구분코드--ex) II : 국내개인(Internal Individual)  / IC : 국내법인(Internal cprporation) / FI : 외국개인(Foreign Individual) / FC : 외국법인(Foreign cprporation) / NA: 국가기관(National Agency)  

3. 고객명_한글

4. 고객명_영문

5. 고객식별번호 -- 고객구분이 국내개인일 경우 주민등록번호, 국가법인일경우 법인등록번호, 외국개인일경우 외국인등록번호, 외국법인일 경우 null, 국가기관일 경우 기관번호

6. 국적

7. 이메일

8. 전화번호

9. 국내_주소

10. 외국인 등록중 여부 -- 외국개인일 경우에만 존재

11. 대표자명 --법인일경우에만 존재

12. 대표자 주민등록번호 --국내법인일경우에만 존재

13. 대표자 이메일 -- 법인, 국가기관일경우에만 존재

14. 대표 전화번호 --국내법인, 국가기관일경우에만 존재

15. 사업장주소 --법인, 국가기관일경우에만 존재


by 신짱 [2019.10.24 13:35:18]

다들 답변 감사합니다! 많은 도움이 되었습니다ㅎㅎ 

하나의 테이블로 관리하기로 결정했습니다.

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입