현서의 개발 일지📚

[ Database - Intermediate ] - 파티셔닝, 샤딩, 래플리케이션

Partitioning 파티셔닝은 말 그대로 테이블을 자르는 작업이라고 보면 됩니다. 이에 대한 종류로는 위와같이 vertical, horizontal partitioning이 있습니다. 우선 vertical partitioning 먼저 보겠습니다. vertical partitioning 이는 그리 어렵지 않습니다. 우리가 쭉 해오던 BCNF와 같은 normalization이 결국에는 column을 기준으로 table을 나눈 것이 되므로 vertical partitioning이 됩니다. 하지만 이는 정규화만 있는 것이 아닙니다. 우리는 위와같이 Article에 대한 예시를 들 수 있겠습니다. 해당 테이블로부터 위 쿼리문을 통해 게시물들을 조회해올 겁니다. 하지만 실제로는 content 값이 필요 없어서 ..

[ Database - Intermediate ] - Index

SELECT * FROM customer WHERE first_name = "Minsoo'; (인덱스가 걸려있지 않은 상황)이런식으로 Customer 테이블을 full scan(=table scan)을 통해 tuple을 찾으면 $O(N)$의 시간 복잡도가 걸릴 것입니다. 그리고 Customer 테이블의 로우 수가 많아지면 많아질 수록 이는 비효율적인 scan이 되겠죠. 이는 B-tree based index를 적용해서 table scan을 하게되면 $O(logN)$으로 로우를 찾을 수 있습니다. 즉 해당 쿼리문이 더 빠르게 처리될 수 있습니다. 이는 상황에 따라서 조건을 만족하는 튜플(들)을 빠르게 조회하거나 바르게 정렬, 그룹핑하기 위해 사용됩니다. MySQL에서 Indexing 해보기 만약 위와같은 ..

[ Database - Intermediate ] - DB 정규화 (1NF, 2NF, 3NF, BFNF, 역 정규화)

DB 정규화(normalization) db정규화란 이전에도 봤다싶이 데이터 중복과 insertion, update, deletion anomaly를 최소화하기 위해 일련의 normal forms(NF)에 따라 relational DB를 구성하는 과정이라고 할 수 있습니다. DB 정규화 과정은 위와같습니다. 이는 처음부터 순차적으로 진행되며 앞쪽 NF를 만족하지 못하면 만족하도록 테이블 구조를 조정해야 합니다. 그리고 1NF ~ BCNF까지는 FD와 key만으로 정의되는 normal forms입니다. 그래서 3NF까지 도달하면 정규화 됐다고 말하기도 합니다. 그래서 실무에서는 보통 3NF 혹은 BCNF까지만 진행합니다. 4NF~6NF는 학술적인 측면이 강합니다. 우리는 위 Employee_account를..

[ Database - Intermediate ] - Functional dependency

위와같이 empl_id(집합 X)가 같다면 그 empl_name ~ salary까지(집합 Y)가 같다는 즉 X에 의해 Y가 결정되고 Y는 X에 의존하는 것을 X -> Y로 표현하고 이것을 Functional dependency (FD)라고 부릅니다. 주의해야 할 점이 있는데, state만으로 FD를 판단해서는 안됩니다. 위와같이 {empl_name} -> {birth_date} 이렇게 하게되면 Jinho라는 동명이인이 들어왔을 떄 birth_date가 달라지기 때문이죠. 그리고 위와같이 dept_id를 이전에 FD에 포함하지 않았었는데, 이는 구축하려는 DB의 attribute가 관계적으로 어떤 의미(sementics)를 지닐지에 따라 달라집니다. 그 이유는 임직원이 여러개의 부서를 가질 수 있다면 X ..

[ Database - Basic ] - DB 테이블 설계를 잘못하면 발생할 수 있는 문제점

중복 데이터 문제 만약 위와같이 예전에 봤던 employee 데이터베이스 스키마와 department 데이터베이스 스키마를 한번에 합친 모습입니다. 이때는 Insertion anomalies가 발생하게 되는데, 위와같이 중복된 데이터가 삽입되게 됩니다. 이렇게 하게되면 저장공간 낭비일 뿐더러, 실수로 인한 데이터 불일치 가능성이 존재하게 됩니다. 실수로 dept_name을 DEV가 아닌 DEB이렇게 삽입하면 발생할 수 있는 문제점입니다. 그리고 만약 어떤 employee가 부서배치를 받기 전이라면 dept_id부터 dept_leader_id까지의 정보가 싹다 null이 될 것입니다. 뒤에서 볼거지만 이렇게 로우에 null을 난발하는 것은 좋지 못한 것입니다. 또다른 문제점이 있습니다. 만약 임직원의 정보..