도당탕탕

여기 흔히 떠도는 말로 대부분의 애플리케이션은 제 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..

관계형 모델은 각 테이블의 로우를 구분할 수 있는 한개 이상의 기본키가 있습니다. 그리고 해당 기본키는 다음과 같이 속성을 가지고 있습니다. 로우마다 유일 해야 한다. 널 값을 가질 수 없다. 여기서 궁금한점! 만약 기본키가 없으면 어떻게 될까요? 기본키를 만들지 말고 테이블을 구성하면 안될까요? 결론적부터 말씀드리면 관계형 모델링에서 할 수는 있지만 해서는 안됩니다. 그 이유는 다음과 같이 문제가 발생합니다. 데이터를 걸러 낼 때 일치하는 로우가 없거나 딱 한 개인 조건은 보장할 수 없다. 로우마다 유일하다고 해서 데이터베이스 엔진이 컬럼 한 개나 일련의 컬럼을 항상 효율적으로 사용할 수 있는 것은 아니다. 기본키가 없는 테이블 간의 관계를 모델링하는 것은 일반적으로 불가능하다. 반복적이고 일관성 없는..