예전에 공부했었던 데이터베이스 정규화와 관련해서 제 나름대로 정리해본 내용입니다.

• 제1정규형

  • 정의: 한 레코드의 각 칼럼들에 담긴 값은 원자값들만 담긴다.

  • 맥락

    • 이 부분이 정확히 왜 제시되었는지 아직도 적확하게 결론짓지는 못했습니다.

    • 하지만 제 나름대로 관련해서 이해한 방식은 "모든 칼럼들의 집합은 슈퍼키이다" 입니다.

      • 따라서 제1정규형을 만족한다면 슈퍼키의 존재성을 가정해도 되어서, 다른 정규형들을 설명할 때의 논리적인 기반이 되는 것 같습니다.

• 제3정규형 (수정: 논리적으로 잘못 이해한 부분이 있어 수정하였습니다. 정리 안 했으면 지나칠 뻔 했습니다.)

  • 정의: 다음 조건을 만족하면 제3정규형 위반

    • 이행적 종속성 A -> B -> C가 발생하는데,

    • A -> B가 일대일 대응이 아니여서 칼럼 C의 값이 중복해서 들어가고,

    • 원래 테이블 ABC를 AB와 BC로 분리했을 때 후보키가 바뀌는 일이 일어나지 않는다.

      • C가 후보 키의 일부인 경우 분리를 못하는 경우가 있습니다. (예: AC -> B, B -> C)

      • 이 부분을 설명하기 위해 prime attribute이라는 개념을 사용하는 것 같습니다.

  • 맥락

    • 정리하고 보니 핵심적인 부분이 바로 칼럼 간의 의존관계인 것 같습니다.

    • 데이터 모델링을 할 때, 각 칼럼이 어떤 칼럼들에 의존하는지 파악하는 연습을 하기로 생각했습니다.

• 제2정규형

  • 정의: 제3정규형 조건에서 B가 후보키의 일부일 때가 제2정규형의 조건이 됩니다.

    • 즉, 앞의 A -> B가 일대일 대응이 아닌 경우입니다.

사용한 용어들입니다.

• 슈퍼키: 레코드를 유일하게 결정지을 수 있는 칼럼들의 집합

• 후보 키: minimal 슈퍼키. 후보 키 자체는 슈퍼키인데, 후보 키에서 칼럼을 하나라도 제외하면 레코드를 유일하게 결정지을 수 없다.

• 기본 키 (PK): 후보키 중 사람이 DBMS 관리를 위해 고른 것

   

2024-11-10

• 수정: 인프런 데이터베이스 강의 소개 영상을 보는데 실무에서의 RDBMS 설계는 이론과 괴리가 있다는 사실이 약간 충격이었습니다.

• 최근에 어떤 블로그 글을 보는데 비즈니스 로직이 실제로 블로그에 나오는 식의 명세로 작성되고, 데이터베이스 스키마로 옮겨진다는 것을 확인하였습니다. (그리고 DDD라는 개념이 무엇인지 궁금해졌습니다.)

  • 업데이트: 다시 읽어보는데, 엔티티 관계 다이어그램으로 일차적으로 옮겨지고 그 다음 데이터 모델링이 진행되는 것으로 해석하였습니다.

  • 수정: 데이터베이스 강의 소개 영상을 보니 실무에서는 기획에서 나온 화면의 데이터를 바탕으로 진행하는 경우가 더 많다는 것을 알았습니다.

     

• 간단한 프로젝트를 천천히 진행해보면서 여기의 내용과 유사하게 진행해보아야겠습니다.

  • 수정: 천천히 진행해보려 했는데, 간단한 프로젝트의 데이터베이스 스키마의 복잡도가 실제 포트폴리오의 스키마에 미치지 못할 수 있겠다는 생각이 들었습니다. 그 경우를 대비해서 최대한 빠르게 스키마 설계를 해보고 잘 되는지 확인해보아야겠습니다.

  • 업데이트: 일단은 다음 방법이 저에게 효과가 있는 것 같습니다. 더 복잡한 테이블 설계에서도 적용 가능한지 확인해보아야겠습니다.

    • 비즈니스 로직에 대한 명세를 만든다. (상황에 따라 테이블 설계하면서 동시적으로 진행)

    • 제일 개념들이 많이 들어가는 구체적인 명세들을 먼저 고른다.

    • 명세들을 잘 표현하는 테이블 구조를 설계한다.

    • 제3정규형을 지키도록 ~~리팩토링~~데이터 모델링을 한다.