도당탕탕

정규화된 테이블은 비정규화된 테이블보다 컬럼의 개수가 적고 저장 공간도 많이 차지하지 않기 때문에 성능이 좋아집니다. 또한 단일 공간으로 이루어진 데이터이기 때문에 갱신과 삽입이 빠르게 수행되고 중복이 없어 DISTINCT나 GROUP BY 사용을 현저하게 줄여줍니다. 데이터 웨어하우스에서 역정규화? 하지만 데이터 웨어하우스에서는 왜 역정규화를 사용해야 할까요? 아니 그보다 데이터 웨어하우스는 무엇일까요? 위키에서는 이렇게 말합니다. 데이터 웨어하우스(data warehouse)란 사용자의 의사 결정에 도움을 주기 위하여, 기간 시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스를 말한다. 즉 쉽게 말하면 데이터들을 수집하고 분석하는 즉 일종의 다차원 분석을 제공해주는 ..

여기 흔히 떠도는 말로 대부분의 애플리케이션은 제 3정규화만 해도 충분하다.가 있습니다. 많은 실무자, 현업자들은 일단 최대한 정규화한 후 애플리케이션이 제대로 돌아갈 때까지 역정규화하라고 말을 합니다. 사실 이 말들은 맞습니다. 대부분의 데이터 모델에서 이미 제 3정규화를 거친 엔티티는 더 높은 수준의 정규화를 만족할 가능성이 크기 때문입니다. 실제로 현재 많은 데이터베이스에서 이미 5정규화 6정규화 까지 도달해 있는데도 사람들은 이를 제 3정규화라고 칭합니다. 그렇다면? 우리는 어떻게 해야 할까요? 드물기는 하지만 제 3정규화를 만족하는 것처럼 보이더라도 데이터 이상 현상을 일으키는 설계 실수를 찾아야 합니다. 특히 제 3정규화로 설계했지만, 한 테이블이 다른 테이블 두 개 이상과 관계를 맺는다면 더..

이론적으로는 관련 컬럼의 데이터 타입이 같으면 테이블 간에 어떤 관계든 맺을 수 있습니다. 하지만 뭔가 할 수 있다는 이유만으로 반드시 해야 하는 것은 아닙니다. 대표적으로 비슷한 컬럼을 가진 테이블들의 컬럼 분리입니다. 예를 들어보죠. Customer, Employee, Vendor 테이블 구조 | Customer | | Employee | | Vendor | --------------------- --------------------- --------------------- | customer_id | | employee_id | | vendor_id | | cust_first_name | | empl_first_name | | vend_first_name | | cust_last_name | | e..

좋은 데이터베이스 스키마를 설계하려면 연관된 테이블의 기본키 값을 가지고 있도록 테이블의 외래키를 정의하는 것이 좋습니다. 예를 들어 Orders 테이블은 Customers 테이블의 기본키를 가리키는 customer_id나 customer_sequence 컬럼을 정의해 주문 고객 정보를 식별할 수 있게 해야 합니다. 다음은 카페와 메뉴간의 관계도를 다이어그램으로 간단하게 보여주는 그림입니다. Menus - Cafes 관계 다이어그램 위 그림에서 노란색 키는 기본키, 파란색 키는 외래키를 나타내며 화살표 방향을 통해 부자 관계를 알 수 있습니다. ( 다이어그램 사진의 일부분이라 테이블이 몇 개 없습니다. 참고해주세요!) 관계를 설명하면 다음과 같습니다. 카페 : 카테고리 -> 1 : 다 카테고리 : 메뉴 ..

개발자들은 가격 계산, 인원수 계산, 수량 계산 등 이런 계산 데이터들을 컬럼에 저장하고 싶은 유혹에 빠질 수 있습니다. 한번 다음 예를 들어보죠. Orders Table query CREATE TABLE Orders { order_id int(5) NOT_NULL, order_date date NULL, customer_id int(5) NOT_NULL, product_id varchar(20) NOT_NULL, order_total decimal(10,2) NULL, } 이렇게 왜 계산 데이터를 저장하면 안 좋은지 살펴봤습니다. 다음에는 참조 무결성을 보호하려면 외래키를 정의 하자에 대해 공부해 보겠습니다. 비결정적 함수를 사용하기 때문에 인덱스를 만들 수 없습니다. 즉 DB2, 오라클 등 인덱스를 ..

데이터베이스의 관계는 오직 하나의 토픽 혹은 액션만 선정해서 기술해야 합니다. 컬럼은 관계로 정의된 주제를 기술하는 유일한 특성과 관련된 데이터를 포함해야 합니다. 또 속성은 다른 관계의 속성을 포함하는 외래키가 될 수도 있고, 이 속성은 다른 관계의 있는 일부 튜플과 연관성을 제공하기도 합니다. 유일한 특성을 가져야 하는 컬럼 만약 단일 컬럼에 특성값을 두 개 이상 저장하면 어떨까요? 제가 생각하기엔 별로 좋지 못한 생각인 것 같습니다. 그 이유는 다음과 같습니다. 검색하거나 값을 집계할 때 특성값을 분리하기가 어렵습니다. 때문에 중요한 개별 특성은 자체 컬럼에 넣는 것을 고려해야 합니다. 예를 들어보죠. 다음은 User라는 테이블입니다. User 테이블 | user_id | user_name | us..

스프레드 시트에서는 비슷한 데이터가 반복적으로 그룹을 이루는 것을 흔히 볼 수 있습니다. 또한 이런 반복적인 데이터들을 정규화를 시키지 않고 새 데이터베이스에 밀어 넣는 일도 빈번히 일어난다고 합니다. 여기 Home 테이블의 예를 들어보죠. Home |id| delivery_task1 | delivery_task2 | delivery_task3 | delivery_task4 | delivery_task5 | name | ------------------------------------------------------------------------------------------------- |1 | LQ25432 | LQ12345 | LA90584 | LS39473 | LQ06958 | Home1 | ..

데이터를 중복으로 저장하면 일관되지 않은 데이터, 비정상적인 삽입, 갱신, 삭제 처리, 디스크 공간 낭비 등 많은 문제를 일으킵니다. 그렇기 때문에 정규화릍 통해 해당 문제점을 해결하려고 합니다. 정규화란? 정규화는 중복 데이터를 저장하면서 일으키는 문제점을 없애려고 정보를 주제별로 분할하는 프로세스를 의미합니다. 여기서 말하는 중복은 한 테이블의 기본키 값을 다른 테이블의 외래키로 중복으로 사용하는 것이 아니라 사용자가 같은 데이터를 한 군데 이상 사용하는 것을 말합니다. 정규화의 목표 정규화의 한 가지 목표는 한 데이터베이스에서 동일한 테이블이든 다른 테이블이든 반복되는 데이터를 최소화하는 것입니다. 다음 CustomerSales 테이블의 예를 들어보죠 |sale_id|cust_first_name|c..