네, 반갑습니다. 오늘 이 영상을 보신 후엔 DBS 스키마 설계를 잘못했을 때 어떤 문제가 발생할 수 있는지 알게

됩니다. 자, 그러면 오늘도 고고싱! 자, 먼저 첫 번째로 중복 데이터 문제가 발생할 수 있습니다. 예를 들어서 설명해 볼게요.

어떤 IT 회사의 데이터베이스를 구축하려고 하는데요. 다음과 같이 테이블을 만들었다고 가정해 보겠습니다. 어떻게 테이블을

설계를 했냐면 이런 식으로 테이블을 설계를 한 거예요. 보시면은 IT 회사의 임직원 정보와 부서

정보를 이렇게 하나의 테이블에 저장할 수 있도록 설계를 한 겁니다. 그래서 그 임직원의 아이디가 프라이머리 키가

되고요. 그리고 그 임직원의 이름, 생일, 직군, 연봉 그리고 그 임직원이 속한 부서의 아이디와 부서의 이름 그리고

부서의 리더 아이디까지 이렇게 한 번에 저장할 수 있도록 테이블을 설계를 한 거죠. 자, 그러면 이 테이블에 데이터를 **입력**하게 되면

그러니까 여기서 **입력**이라는 것은 **삽입**을 하거나 업데이트를 하거나 삭제를 하게 되면 어떤 문제가 발생할 수 있을까요?

이거를 이제 살펴보도록 하겠습니다. 먼저 데이터를 추가할 때, 그러니까 **삽입**을 할 때 발생할 수 있는 이상 현상을 살펴볼게요. 이거를

**삽입 이상 현상**이라고 하는데요. 자, 여기 이렇게 테이블이 있죠. 이 테이블에 데이터를 하나 추가를 해보겠습니다. 그래서 이렇게

메시라는 이름의 임직원 정보를 추가를 했어요. 그러면 이 메시의 **사원** 아이디는 1이 됐고 그 다음에 생일 정보, 직군, 연봉 정보를 다 추가를

했고 그 다음에 이 메시는 개발팀 소속이었거든요. 그래서 그 부서 아이디는 1001이 되고요. 그 부서의 이름은 데브라는 이름이고 그 부서의

리더 아이디는 이제 J 메시의 아이디, 그러니까 메시가 이 부서의 리더가 되는 거예요. 그래서 이 메시 아이디까지

이렇게 넣어줬습니다. 그러면 여기까지는 일단 문제가 없어요. 그런데 여기에 이제 추가로 또 다른 임직원의 정보를 입력해 보도록

하겠습니다. 그러면 이번에는 진호라는 이름의 임직원 정보를 입력을 했어요. 이분의 인플루언서 아이디는 2가 되고요. 그

다음에 이런 정보들을 입력하고 진호라는 분도 개발팀 소속이기 때문에 이렇게 개발팀의 아이디와 개발팀의

1은 그리고 리더의 아이디를 이렇게 적어줬습니다. 자, 그러면 이 부분을 한번 유심히 볼게요. 얘는 지금 중복된 데이터입니다.

그러니까 둘 다 개발팀 소속이 되면서 개발팀, 개발팀의 이름 그리고 개발팀의 리더 아이디까지 모두 중복으로 이렇게

데이터가 입력이 되는 거죠 그러면 이렇게 중복 데이터가 발생하게 되면 일단 저장 공간을 낭비를 하게 돼요 왜냐하면 중복된 데이터가 계속 쌓이는

거니깐요 그 다음에 만약에 실수로 데이터를 잘못 입력을 하게 되면 데이터 불일치가 발생할 수도 있습니다 예를 들어서 여기에 대표라고 입력을

해야 되는데 데브가 아니라 오타가 나가지고 deb라고 입력을 할 수도 있는 거고 이렇게 잘못 입력을 하게 되면 분명히

같은 개발팀 소속인데 신호의 개발팀 이름은 deb가 되고 메시의 개발팀 이름은 dev가 되는 거죠 그래서 이렇게 실수로 인해서

같은 데이터임에도 불구하고 잘못된 데이터 불일치가 발생할 수 있는 가능성도 항상 존재를 하는 겁니다 그래서 가능하다면 중복된 데이터는

최대한 줄여 주는게 좋은 건데 지금 테이블 설계를 이렇게 하나로 묶어서 했다 보니까 이런 중복된 데이터가

발생할 수 있게 돼 버린 거죠 자 어쨌든 그러면 이런 상황에서 데이터를 추가로 또 입력을 해 볼 건데요 이번에는 아직 부서 배치를

받지 못한 임직원을 추 살펴보도록 하겠습니다 자 그러면 얘는 어떻게 입력을 해줘야 될까요 여기 이렇게

젠이라는 이름의 임직원 정보를 추가를 할 거예요 그래서 이렇게 인플로이 아이디와 생일 직군 연봉 정보를 다

입력을 해줬습니다 그런데 얘는 지금 아직 부서 배치를 받지 못한 거잖아요 그러면 지금 이렇게 부서와 관련된 애트리뷰트가 있는데

여기에는 어떤 값들이 들어가야 될까 이게 이제 고민스러운 겁니다 그래서 이런 경우에는 그냥 일단 널 값으로

이렇게 입력을 하게 되는데요 이렇게 널 값을 많이 쓰는게 좋은 것은 아닙니다 왜 그런지는 뒤에서 조금 더

자세히 설명을 하고요 그래서 가급적이면 할 수 있는 한 null 값은 적게 쓰는 게 좋아요 그런데 지금은 이런 테이블에 스키마 상황에서는 아직

부서를 배정받지 못한 임직원의 정보를 입력을 하려면 이렇게 null 값으로 입력해 줄 수밖에 없는 거죠 그래서

이렇게 null 값을 많이 쓰게 된다는 이런 문제점이 있고요 그다음에 또 다른 데이터를 하나 추가를 해보겠습니다 그런데 이번에는 어떤

데이터를 추가를 할 거냐면 임직원이 한 명도 없는 부서 정보를 입력을 하고 싶은 거예요 그러면 지금 ES 스키마에서는 어떻게 입력을 해줘야

될까요 예를 들어서 지금 QA 그러니까 우리 회사의 프로덕트의 품질을 검증하는 부서를 입력을 하고 싶은 거예요 그래서 이렇게 QA 팀의

이름과 그 QA 팀의 아이디와 그리고 아직 이 부서에는 소속된 임직원이 아무도 없기 때문에 그 부서의 리더

아이디는 널로 이렇게 입력을 해줬습니다. 그런데 문제는 지금 이 테이블은 임직원 정보도 한 번에 표현을 하기 때문에 이 임직원 정보에는

어떤 데이터를 넣어 줘야 되냐 이게 또 이슈가 되는 거죠. 그러면 아까처럼 그렇게 널로 또 넣어 줘야 될 거예요.

그래서 이렇게 널로 넣어 줬다고 해보겠습니다. 그런데 여기만 왜 널이 아니냐면 얘는 프라이머리 키기 때문에

프라이머리 키는 널 값을 가질 수 없거든요. 그래서 얘는 임시로 이렇게 인플로이 아이디 자리에 4라는 값을

넣어주게 된 겁니다. 그래서 이렇게 아직 부서원이 존재하지 않는 QA 부서를 이 테이블에 입력을 하고 싶으면 결국 QA 부서 저장용 로우를 하나

만들어 줘야 되는데 그렇게 억지로 넣어 주려고 하다 보니까 임직원과 관련된 애트리뷰트에는 모두

이렇게 null로 넣어주게 되고 심지어 인플루의 아이디를 프라이머리 키로 쓰는 이 부분은 null이 될 수 없기

때문에 임시로 4라는 값을 보여주게 되면서 얘가 뭔가 매끄럽지도 않고 또 넣을 값도 많이 쓰게 되는 이런 형태로

부서 정보를 추가하게 되는 거죠. 자, 그런데 만약에 이 상황에서 이 QA 부서의 첫 임직원이 들어왔다고 해볼게요. 만약에 그 임직원의 이름이

유진이라고 한다면 그 유진이라는 임직원 정보를 이렇게 새로운 튜플로 새로운 로우로 입력을 해주게 됩니다.

그러면 그 유진이 속한 부서 아이디는 1000이가 되고 그 부서의 이름은 QA가 되고 유진이 그 부서의 리더가 됐기 때문에 유진의 아이디를 이렇게

리더 아이디에 적어주게 됩니다. 자, 그러면 이렇게 QA 부서에 처음으로 새로운 부서원이 한 명 들어오게 되면서 부서 정보를 저장하기 위해서

임시로 넣어뒀던 이 정보는 이제는 필요 없게 되는 거잖아요. 그래서 이제 이 정보는 이렇게 삭제를 해줘야 됩니다.

그러면 이렇게 부서 정보 하나 관리하는 게 처음에 부서용으로 하나 저장해 놨다가 그 부서에 새로운 임직원이 최초로 들어오면 이 튜플은 또

삭제를 해줘야 되고 이런 번거로움이 있는 거죠. 이것 또한 이 테이블에 스키마를 이런 식으로 만들어 버리니까

불편한 점이 생기는 겁니다. 그래서 지금까지 인서션 오노물리스를 살펴봤고요, 테이블 설계가 잘못되면

데이터를 추가할 때 어떤 문제들이 생길 수 있는지를 설명을 드린 겁니다. 자, 그러면 이런 현상이 왜 발생했는가 지금 보시는 이

테이블의 스키마를 잘 살펴보면 두 개의 관심사가 한 테이블에 있다라는 것을 알 수 있습니다. 우선 이 테이블은

임직원의 정보를 저장하고 있고요 또한 이 테이블은 부서의 정보도 저장을 하고 있습니다 그러니까 무슨 말이냐면 서로 다른

별개의 관심사가 한 테이블에 있는 거예요 이 임직원 정보와 부서 정보가 한 테이블 안에 있는 겁니다 그래서 사실 테이블을 설계할 때 관련있는

하나의 관심사만 묶어서 테이블로 설계하는 게 더 바람직하고요 그래서 이 각각에 대한 것을 따로따로 테이블로

만들어 주게 되면 이제 이런 식으로 설계를 할 수 있습니다 임직원 테이블이 하나가 생기고 부서 테이블이 또 하나 생기는 거죠

그러면 이 임직원 테이블에는 employee ID가 프라이머리 키가 되는 거고 부서 테이블에는 이 부서 ID가

프라이머리 키가 되는 겁니다 그리고 이 임직원 테이블에 있는 department ID는 department 테이블에 이 프라이머리

키이 프라이머리 키를 레퍼런스하는 foreign 키가 되는 거예요 그래서 이런 식으로 설계를 하게 되면 예를

들어서 이제 새로운 임직원을 추가를 한다고 해볼게요 그러면 이렇게 사이먼이라는 이름의 새로운 임직원을

추가를 했을 때 이 인플루이 테이블에 추가를 해주면 되는 겁니다 그러면 이때 디플로이먼트 아이디만 잘

챙겨주면 되는 거거든요 그래서 만약에 이 사이먼이라는 임직원이 아직 부서를 배정받지 못했다 그러면 이

임직원의 디폴트 아이디를 얘만 널로 이렇게 입력을 해주면 되는 거예요 그게 아니라이 사이먼이라는

임직원이 개발팀 소속이다 그러면 사이먼이라는 정보를 이렇게 입력할 때 여기에 이렇게 개발팀 아이디를

적어주면 되는 겁니다 그래서 훨씬 더 간결하고 널 값도 적게 쓰게 되고 디폴트먼트 테이블 쪽은 수정할 필요가

없게 되는 겁니다 자 그런데 그게 아니라 만약에 새로운 부서 정보를 입력을 해야 된다 아직 소속된 임직원은 없는 새로운 부서 정보를

입력해야 된다면 그렇다면 이때는 디폴트먼트 테이블에만 추가를 해주면 되겠죠 예를 들어서 디자인 부서를

새로 입력을 한다 그러면은 이 디폴트먼트 테이블에만 부서 아이디와 부서의 이름과 그리고 아직 그 부서에는 아무도 소속된 임직원이 없기

때문에 그 부서의 리더 아이디는 널로 이렇게 입력을 해주면 되는 겁니다 그래서 이렇게 테이블을 잘 설계를

하게 되면 중복된 데이터도 많이 만들 수 있고 훨씬 더 깔끔하고 안전하게 데이터들을 관리할 수가 있게 되는

거죠 자 그러면 지금까지는 insertion anomaly에 대해서 살펴봤는데요 이번에는 deletion anomaly에 대해서 살펴보도록

하겠습니다 그러니까 테이블이 이렇게 합쳐서 설계되어 있다면 그러면 데이터를 삭제를 할 때 어떤 문제점이

발생할 수 있는지 살펴보도록 할게요 자 아까 예제와 동일합니다 이렇게 하나로 합쳐진 테이블 스키마가 있고

이렇게 데이터가 있어요 그러면 이제 이 테이블에서 유진 정보를 삭제를 하면 어떻게 될까요 그러니까 이 튜플을

삭제를 하면 어떻게 될까요 지금 유진은 qa 팀에 남아있는 최후의 1인이었거든요 그런데 이렇게

유진 정보를 삭제하게 되면서 이 qa 부서에 대한 정보 자체도 데이터베이스에서 사라지게 되는 겁니다 그러니까 나는 유진 정보만 삭제했을

뿐인데 애꿎은 부서 정보까지도 사라지게 돼 버린 거예요. 유진이 QA 팀에서 최후의 1인이었기 때문에 이런 현상이

발생하게 되는 거죠. 그러면 이 문제를 해결하기 위해서 유진 정보를 담고 있던 이 튜플을 아예 삭제하는 것이

아니라 이렇게 유진과 관련된 정보만 null로 바꿔 줄 수도 있을 겁니다. 그러면 일단은 이 QA 부 대한 정보는 데이터베이스에서 살아남게 되겠죠.

하지만 지금 이런 식으로 저장하는 것이 매끄럽지도 않아요. 왜냐하면 지금 보세요. 인플루언서 아이디가 뭐로

지정되어 있는데 그러니까 임직원의 아이디가 원하는 건데 사실 얘는 임직원의 정보를 저장하려고 남겨둔 게 아니라 QA 부서

때문에 이렇게 남겨둔 거라서 뭔가 이렇게 논리적으로 매끄럽게 저장되어 있는 것도 아니고요. 이렇게 보시는

것처럼 널 값도 많이 쓰게 돼서 그렇게 좋은 게 아닌 거죠. 그런데 만약에 이렇게 관심사별로 테이블을

따로따로 분리해서 설계를 했다면, 그렇다면 이때 이렇게 유진 정보를 삭제를 해주게 되면 인플루엔서

테이블에서만 튜플이 사라지게 되고 디폴트먼트 테이블에서는 리더의 아이디만 롤러로 바꿔주면 되는 형태로

처리를 해주면 돼서 결국 이 Q의 부서의 정보는 여전히 데이터베이스에 존재하면서도 깔끔하게 이 유진에 관련된

정보를 삭제할 수 있게 되는 겁니다. 그래서 테이블 설계가 중요하다는 것을 이 딜리셔 언어 몰리스를 통해서

살펴봤고요. 그러면 이번에는 업데이트 온오 몰리스를 살펴보도록 할게요. 자 같은 예제입니다. 임직원 정보와 부서 정보를 이렇게

하나로 합쳐서 스키마를 설계했을 때 그때 업데이트를 할 때도 어떤 문제가 발생할 수 있는지를 살펴보도록 할게요

자 보시는 것처럼 이런 상황에서 최근에 개발팀에 부서 이름이 원래는 대부였는데 대부일로 변경이 됐다고

해볼게요 그러면 이 둘 다를 업데이트를 해줘야 되는데 어떤 이유에서 진호라는 튜플에 대해서만이 개발팀의

이름이 업데이트 됐다고 가정을 해볼게요 그러면 그 말은 지금 진호만 이렇게 개발팀의 이름이 대부 1로

업데이트 됐다라는 얘기인데 지금 이 현상은 보시면 부서의 불일치가 발생을 한 거예요 둘 다 사실은 같은 부서

소속인데 메시의 튜플에서는 개발팀 이름이 대부로 되어 있고 진호의 튜플에서는 개발 부서의 이름이 대부일로 되어 있는 겁니다 그래서

이렇게 일부만 업데이트를 해주게 되면 데이터에 불일치가 발생할 수 있습니다. 하지만 만약에 이렇게 테이블이 따로따로 설계되어 있다면

그러면은 예를 들어서 개발팀의 이름을 바꿔주고 싶을 때 여기만 바꿔주면 되는 거잖아요. 그래서 얘를 이렇게

대부분으로 바꿔주면 되는 거라서 데이터 불일치가 발생할 여지가 사라지는 거죠. 그래서 지금까지 3가지

이종 데이터를 살펴봤습니다. Insertion Anomaly, Deletion Anomaly, Update Anomaly 이렇게 세 가지 문제점

BJ.47 DB 테이블 설계 잘못하면 어떤 문제가 생길 수 있을까요?

8년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요

알기 쉽게 설명합니다

함께 성장했으면 좋겠어요 :)


#컴공맛집 #백엔드전문채널
