Web/DataBase

[ 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을 난발하는 것은 좋지 못한 것입니다. 또다른 문제점이 있습니다. 만약 임직원의 정보..

[ Database - Advance ] - MVCC

먼저 MVCC가 무엇인지 알아보기 위해 위는 간단한 예시입니다. write(x=50)은 write_lock을 잡고 write하는 일련의 과정을 나타낸 것입니다. 앞으로 생략하겠습니다. 또한, commit하고 그 뒤에 unlock(x) 즉 write-lock을 해제해주는 과정을 진행해 주어야 하는데, 그 이유는 recoverability를 위해 commit 시점 뒤에 해준다고 이전에 설명했었습니다. 위 그림 시점 이후에 또 tx1 에서 tx2 unlock이후에 x를 읽는다면 어떻게 될까요?? 10일까요 아니면 50일까요?? 이는 당연히 DBMS의 isolation level에 따라 다르겠지요. 만약 read committed는 read하는 시간을 기준으로 그 전에 commit된 데이터를 읽기 때문에, tx..