Understanding Database - SQL 기초 총정리

SQL vs NoSQL

SQL은 테이블 형식, NoSQL은 정형화되지 않은 데이터베이스 형식. 

SQL의 기본 개념인 테이블, 관계의 개념을 NoSQL에서는 콜렉션, 그리고 참조 혹은 내장형의 개념 정도로 생각할 수 있겠다. 

SQL은 정형화되어 있어서 머릿속에 사실 구도를 그리는 것이 상대적으로 편하다. 반면, NoSQL은 구조가 정형화되어 있지 않아서 머릿속에 구조를 명확하게 그리기가 처음에 쉽지 않다. 하지만 그로 인한 장점은 확장성에 있다고 할 수 있겠다. 

예를 들어 SQL에서는 데이터를 정해진 테이블의 형태 안에 넣어야만 하지만 NoSQL에서는 그런 부분을 제약조건으로 추가하거나 혹은 제약 조건 없이 다양한 형태의 데이터를 하나의 콜렉션(SQL로 치면 하나의 테이블)에 몽땅그리 저장할 수 있다는 장점이 있다. 

하나의 컬렉션에 몽땅 그리 집어넣어서 좋은 점은 내가 원하는 데이터를 한 번에 한 군데서 다 찾아 볼 수 있다는 것. 

무슨 말이냐면 나중에 원하는 걸 찾을 때 SQL의 경우 테이블 조인이라는 것을 해서 다른 테이블에 있는 걸 찾아 찾아 가야하는 반면, NoSQL은 보부상 가방처럼 원하는 거 관련된 게 한 가방안에 다 있으니 한번의 쿼리로 찾아낼 수 있다는 것이 강점이라고 할 수 있다. 

 

Figure 1. 대충 그린 SQL 과 NoSQL 형식의 차이

---

Data Base, 데이터 베이스란 의미있는 데이터들을 구조화된 모음이다. (Collection) 

 

데이터 베이스의 역사 

1960-70 년대: 회사들의 사내의 어플리케이션

- SQL, COBOL 같은 것들이 각 회사 마다 사용되었으며 정형화된 기준 같은 것이 따로 없었다. 그 당시 데이터의 저장 매체는 컴퓨터의 테이프 형태에 저장되었기에 데이터 접근 속도가 느렸으면 순차적 인덱스나 간단한 인덱스가 주로 사용되었다. 

1980-2000 년대에 들어 이 어플리케이션들이 더 넓게 상용되기 시작했다. SQL 표준(1986), MS Access, 관계형 모델들의 발전되기 시작헀고 상업용이나 미디어를 위한 데이터베이스들이 사용되기 시작했다. (NoSQL) 

2000년대 이후로 소셜 미디어가 성장하면서 온라인 뱅킹, 이커머스, 문자, 사진, 음악, 비디오 뿐만 아니라 소셜미디어에 사용되는 코멘트, 좋아요, 공유, 메세지 등 실시간으로 스트리밍되는 다양한 데이터들이 그 대상이 되어 다양한 분야의 데이터 자원으로 이용되기 시작했다. 

 

도처에 깔린 모든 자료나 정보들 중 의미있는 정보들을 '데이터'라고 칭한다. 데이터 베이스 관리시스템(Database Management System (DBMS))은 실제로 데이터베이스를 만들고 유지관리 하는 소프트 웨어를 의미한다. 그리고 이 데이터 베이스 관리 시스템과 데이터 자체 거기에 실제로 사용자가 사용하는 인터페이스 어플리케이션을 통합하여 데이터베이스 시스템이라고 한다. 아래 Figure 2에서 확인할 수 있다. 

 

Figure 2. Database System structure

 

DBMS의 주요 기능은 4가지가 있다. 데이터베이스를 정의하는 것(데이터 유형, 관계, 제약조건), 데이터베이스 조작하는 것(데이터를 추가, 수정, 읽어내기 등), 데이터 베이스를 설계하는 것( 물리적 저장 장치나 분리 방법 같은 것들) 그리고 데이터 베이스를 공유한는 것이다. 

 

SQL은 Structured Query Language 의 준말로써, 관계형 데이터 베이스에 사용되는 ANSI/ISO 표준 언어이다. 어떤 사람들은 SEQUEL이라고 부르기도 한다. 여기서 관계형 데이터 베이스란 말은 데이터 베이스는 종류별로 모아진 모음(collection - table) 들의 모음이고 이런 각 콜렉션들의 관계, 그 안의 값들의 관계에 따라서 디지인을 설계한다는 의미이다. 다시 말해 테이블 안에 값과 또 거기에 연결된 다른 테이블의 값들 간에 키(외래키와 주요키) 관계들로 인해서 서로 다른 테이블의 정보를 연결하여 새로운 의미와 결과를 도출해내는 형태로 모델링되는 데이터베이스의 형식을 의미한다. 

 

이런 테이블간의 관계와 데이터의 형태는 구조화된 형태로 저장될 수 있고 이는 스키마를 통해 나타낼 수 있다. 여기서 스키마는 실제 데이터는 아니고 그냥 해당 테이블의 구조와 정의를 설명해주는 것으로 생각할 수 있다. 스키마는 데이터 열 이름과 데이터 타입으로 구성된다. 

열이름 ------->	학생 번호	이름	나이
데이터 타입 --->	integer	text	integer

테이블은 테이블 이름, 열(attribute, column, field)과 행(row, tuple), 헤더( 열 이름들 ), 바디 (데이터 값이 있는 부분) , 도메인 ( 데이터 타입의 속성) 으로 구성된다. 

 

'키'는 PK(pramary key), candidate key, Foreign Key(FK) 가 있다.

 

프라이머리 키는 테이블의 각 행을 독립적으로 인지할 수 있도록 해주는 값이다. 예를 들어 테이블에 학생 번호, 이름, 나이가 존재할 때 학생번호가 프라이머리 키로 사용될 수 있다. 왜냐하면 학생이름과 나이는 여러 행에 중복된 값이 있을 수 있어서 이름과 나이만 봣을 땐 각 행을 개별로 인지하기가 어렵다. 설령 같은 나이에 동명이인이라고 할지라도 말이다. 그래서 PK의 경우는 주민등록번호나 자동차 등록 번호와 같이 각 행의 데이터를 개별로 인지할 수 있도록 해주는 열쇠와 같은 것이라고 볼 수 있다. 그렇기에 절대로 빈값이(Null)이 될 수 없고 유니크한 값이어야 하며 되도록 간단할 수록 좋다. 간혹 이름+나이와 같이 두개를 묶어서 쓸 수도 있지만 되도록이면 간단하게 단독으로 스이는 것이 빠르고 좋다. 또 되도록이면 한번 설정 후 수정하지 않는 것을 추천한다. 왜냐하면 나중에 테이블 간의 관계를 설정할 때 이 PK를 가지고 연결하는 작업을 하기 때문에 관계를 다 만들어둔 상태에서 또 PK를 변경하면 다른 연결된 것들도 모두 손봐야 하는 상황이 온다...

 

후보키(Candidate key)는 독립적으로 쓰이며 행을 인지할 수 있는 역할을 할 수 있는 후보군을 의미한다. 주민번호처럼 하나를 쓸수도 있도 주민번호 + 이름 과 같은 조합으로 쓸 수도 있다. 테이블에 여러개의 후보군이 있을 수 있지만, 이 중 간단하고 가장 대표적인 것을 PK로 선택하는 것이 좋다. 

 

외래(FK)키는 두개의 테이블을 연결해줄 때 쓴다. Parent 테이블과 child 테이블이라고 칭한다. (관계가 있는 두개의 테이블) Parent 테이블에 외래키를 하나 지정하고 그 외래키를 Child 테이블의 PK와 연결해줄 수 있다. 즉, FK는 연결된 테이블에서는 PK로 쓰인다. 아래 그림에서와 같이 프로젝트 테이블의 PK는 project_id 그리고 FK는 school_id 일 때, 이 FK 를 활용하여 school 테이블과 연결할 수 있고 그로 인해 각 프로젝트가 어느 학교의 것인 지 알 수 있다. 이 두 개의 정보를 하나의 테이블에 다 담지 않고 두 개의 테이블로 나눠서 저장하는 것에 대해서는 추후에 설명된다. (Normalization) 

Figure 3. PK and FK

키를 설정하였다면 그에 따른 제약 조건들도 설정해 줄 수 있다. 먼저 PK의 경우 앞서 이미 언급했듯이 NOT NULL(빈 값을 포함할 수 없다), UNIQUE(중복값을 가질 수 없다) 등과 같은 제약 조건이 있을 수 있고 FK의 경우엔 Child 테이블의 PK에 없는 값은 가질 수 없다. (두 테이블이 연결되어 있기 때문에 Child 테이블에 없는 값이 FK에 있을 경우 참조 오류가 발생한다.) 

 

E.F. Codd 라는 사람이 관계형 데이터 베이스를 도입한 사람이다. 관계형데이터의 목적은 데이터를 분리하여 중복된 데이터를 줄임으로 인해 데이터 저장비용을 효과적으로 줄이는 것에 있다. 

 

RDBMS 는 관계형 데이터 베이스 관리 시스템을 의미한다. 데이터의 값들은 원자성을 가지고 있어야 하며(더이상 분해 x), 열과 행의 순서는 의미가 없으며, 데이터의 저장은 수직으로 확장 가능하고 (행을 추가 가능), 무결성 제한 조건들은 데이터 들간에 있어 데이터를 일관성 있게 저장 및 유지할 수 있도록 해준다. 

 

이런 RDBMS의 한계로는 데이터 베이스의 확장하려면 여러 규모의 확장이 필요하다는 것이다. 사용자가 다루기 어려운 가격이 비싼 서버에서 확장이 진행될 수 있으며, 데이터 베이스가 테이블에 맞지 않느 경우 복잡한 구조로 테이블을 늘이던지 다시 나누던지 등등의 방법으로 데이터베이스 모델링 재설계가 필요하다. 

 

그럼에도 불구하고 RDBMS를 사용하는 이유로는 ACID compliance 를 이유로 들 수 있다. Atomicity, Consistency, Isolation, Durabiility을 준수하면서 데이터를 구조화하고 일관성있게 유지해주는 장점 때문이다. 

 

SQL

Structured Query Langauge, Manipulating relational databases, International standard since 1986(ANSI, ISO)
SQL is language, and MySQL is DBMS. Web interfaces( e.g., phpMyAdmin) 

 

SQL은 다양하게 활용되는 데 LAMP는 하나의 예시로 수업에서 다뤄진 것이다. 여러개의 소프트웨어를 하나의 세트로 묶어서 이렇게 부르기도 하는 데 그 중 하나인 LAMP는 Linux + Apache + MySQL + PHP 의 결합이다. 이것을 쌓아서 쓴다고 하여 LAMP Stack 이라고 부른다. 

 

SQL에서는 text 데이터 타입을 설정할 때 다른 언어(String)에서와 다르게 VARCHAR 이라는 것을 사용하고 여기에 개수까지 지정한다. 예를 들면 VARHCAR(20)와 같이 쓰인다. 이렇게 그 크기를 제한함으로써 불필요하게 메모리가 낭비되는 것을 막아준다. 

 

스키마라는 것에 대해서 앞에 언급했었는 데 이를 쿼리로 나타낼 때는 테이블을 생성할 때 쓰인다고 보면 된다. 테이블 생성 시 스키마 디자인에서 설정한 데이터 이름, 타입, 제약조건들을 지정할 수 있다. 테이블은 생성되고 수정될 수 있지만 한 번 삭제(drop)하는 경우 다시 살려낼 수는 없다. 

Figure 4. SQL query -- create table example

Figure 4는 내가 짠 쿼리 중에 하나인데, ID는 자동으로 증가하도록 설정, PK, FK 설정과 제약조건, 테이블 관계도 모두 설정되어 있다. 

 

쿼리를 짤 때 reserved words(시스템에 저장된 키워드들 - CREATE TABLE , IF, PRIMARY KEY 등과 같이 초록색으로 표시된 것 Figure 4) 들은 되도록 대문자로 쓰는 것를 추천한다. 그리고 테이블 이름은 대문자, 소문자를 구별해서 사용해야 하고 열이름 같은 경우는 대소문자 상관없이 사용이 가능하다. 다시 말해 테이블 이름은 대소문자가 틀리면 인지를 못한다는 말이고 열이름은 대소문자가 틀려도 인지할 수 있다는 말이다. 

 

테이블 안에 데이터를 수정하는 데 사용되는 대표적인 쿼리들은 insert, delete, update 가 있다. 그리고 데이터를 추출해내는 (원하는 데이터를 찾아서 출력해내는) 쿼리는 select가 쓰인다. 

이 때 여러가지 방법으로 데이터를 찾을 수 있는 데 DISTICT, ORDER BY, GROUP BY , WHERE 절을 사용하여 조건에 맞는 데이터를 추려낼 수 있다. 위에 예시에서는 3개의 테이블을 조인하여서 사용하였고 각 테이블은 전체 이름을 그대로 사용하는 대신 a, p, 그리고 ㅣ을 상용함으로써 전체 쿼리를 더 단순화 하였다. 

 

DBMS는 테이블관계에 있어서 혼란이 올 수 있는 유효하지 않은 작업을 막아낸다. 예를 들어 PK나 FK를 제거하려 한다거나 데이터 타입이 잘못된 데이터를 삽입하려 하거나 중복된 PK를 입력하거나 혹은 다른 테이블과 관계가 형성된 테이블을 제거하려고 하는 작업들은 저지된다. 

 

NULL 값에 대해서 언급을 하자면 앞서서 비어있는 값이라고 말한 적이 있다. NULL은 값이라기 보다는 '상태'로 해석될 수 있다. 예를들어 알수 없는 상태, 이용이 불가능한 상태, 보류된 상태, 해당되지않는 상태 등을 NULL이라고 한다. 예를 들어 학생과 학교 정보가 담긴 테이블이 있다고 했을 때 학생의 주민번호는 NULL이 될 수 없지만 학교 이름은 NULL이 될 수 있다.( 학교 다니지 않는 학생이거나 아직 어려서 학교 미취학 아동일 경우) NULL 이 가능할 경우는 IS NULL, 가능하지 않는 경우 NOT NULL을 사용한다. 

 

쿼리를 짜다 보면 논리적인 관계에 대해서 정의해야 할 때가 있다. ( and , or, but ) AND를 사용ㅇ하는경우 FALSE가 가장 쎄다. 다시 말해서 하나 이상이 FALSE이면 FALSE 이다. 그리고 만약 OR를 사용하는경우 TRUE가 제일 강하다. 하나라도 TRUE면 모두 TRUE가 된다. 

Figure 5. Three Valued Logic

테이블 조인은 테이블 간 관계를 형성하여 다른 테이블의 내용을 자유자재로 가져다 쓸 수 있도록 해주는 역할을 해준다. 조인에 종류로는 다양한 종류가 있다. 두 그룹의 교집합 형태를 생각하며 이해하면 쉽다.

Inner join result will include only the colored part.

Inner 조인은 말 그대로 안쪽의 데이터(공통된 부분만) 출력해준다. Outer는 바깥 쪽 (해당되는 방향에 있는 데이터)를 출력해주고 Full outer는 양쪽 데이터를 모두 출력, Cross 는 하나씩 다 연결지어서 (신발 끈 묶 듯) 다 출력해주는 것을 의미한다. 

다음 이미지는 타 사이트에 잘 설명된 내용과 그림이 있어서 첨부한다.  

https://cloud.google.com/blog/topics/developers-practitioners/bigquery-explained-working-joins-nested-repeated-data?hl=en 

 

관계대수

관계돼수는 쿼리 작업을 형식화하고 관계에 사용하고 또 효과적으로 쿼리를 생성하고 사용할 수 있도록 해준다.  

 

단항연산

SELECT	σ<cond> (r)	σ salary>10000 (Employee)	σ salary>1000 (  σ age>30 (Employee) )   σ salary>1000 ^ age >30 (Employee)
PROJECT	∏ <A1, A2,...> (r)	∏ ID, Salary (Employee)	∏ id ( σ salary>10000 (Employee) )
Assignment	←	test ← σ age<30 (Employee)	test(number, name, pay) ←  ∏  ID, the_name, salary (Employee)
Rename	ρ	ρ test (Employee)	ρ test(name, number, payment,...) (Employee) : change table name from Employee to test, and its fields name as well.

이항연산

Union [ ⋃ ]	양쪽 테이블에서 전부 출력 ( 열 개수, 위치, 데이터 유형 등이 모두 같아야 한다)
Intersect [⋂]	교집한 부부만 출력( 중복 제거 )
Minus[ - ]	R1 - R2: R1에서 R2에 해당되는 부분 제외
Cross-product(Cartesian product) [ X ]	R1에 있는 각 행을 R2의 각 행과 하나씩 짝짓기
Conditional join [ R1⋈ age <30 R2 ]	조건이 맞는 부분관 합친다. (Cross랑 같은 데 조건이 있는 것 뿐)
Equi Join [R1 ⋈ age R2 ]	R1이랑 R2의 각 행의 값이 같은 것만 출력(여기서는 두 테이블에 나이 값 같은 것만 매칭해서 출력 )

 

ER Diagram (Entity Relationship Diagram) 

ER diaram을 그리는 순서는 다음과 같다. 1) 분석 요구사항이 무엇인가? 를 파악한다. 2) 논리적 디자인을 설계한다. 예를 들어 어떤 테이블들이 필요하고 어떤 관계로 참조를 할지 등을 고려해여 논리적 디자인 설계가 필요하다. 3) 정규화: 논리적으로 설계된 디자인에 대해 명확히 하며 체계화된 단순화가 필요하다. 4) 설계된 디자인을 고려하여 DBMS에서 물리적 디자인을 구현한다. 

 

ER diagram의 구성요소들은 다음과 같다. Entity 는 테이블이름이라고 생각하면 되겠다. Attribute는 그 안의 구성 요소들이다. 각 행이 하나의  attribute를 구성한다. Relationship은 관계이고 instance는 테이블에 있는 Attribute의 종류라고 보면 되겠다. 관계를 표현하기 위해서 동사를 써서 보통 표현하기도 하는 데 Entity(테이블 이름)이 주어로 쓰인다. 아래 그림에서 "캐릭터는 시티에 산다"라는 관계가 정의 가능하다. 

PK, FK 나 그 밖에 제약들은 쿼리과정에서 설정되기는 하지만 보통은 모델 설계 단계에서부터 고려를 해야 한다. 그래야 그에 맞게 디자인이 가능하기 때문이다. 

 

카디널리티 제약 (한국어로는 뭐라고 표현해야 간단하게 표현할 수 있을 지 모르겠다) 

카디널리티는 얼마나 많은 인스턴스의 엔티티 종류들이 관계에 영향을 미치는 지를 정의하는 것을 말한다. 다시 말해서  엔티티에는 다양한 인스턴스들이 있는 데 이 인스턴스가 다른 테이블과 몇개나 연관이 있느냐는 것이다. 예를 들어, 캐릭터와 도시의 엔티티를 생각해보자. 

캐릭터 엔티티에는 캐릭터 수만큼의 인스턴스가 있다. 배트맨, 슈퍼맨, 스파이더맨이 있다고 했을 때 3개의 인스턴스가 존재한다. 반대로 전세계에는 오직 런던, 맨체스터, 울산 3개의 도시가 있다고 했을 때 이 둘의 관계를 정의해보자. 

엔티티 캐릭터의 각 각의 인스턴스 (3개)는 하나의 도시에만 살 수 있다. 한 번에 여러 곳에 살 수는 없으니, 그렇다면 캐릭터는 적어도 하나의 도시에 살고 있어야 하고 최대로 살 수 있는 도시도 하나 뿐이다. (바로 one and only one 관계) 다음은 도시의 입장에서 보면 각 도시에는 한 명도 안 살고 있을 수도 있고 혹은 3명 모두 한 도시에 살 수 있을 수도 있다. (바로 zeo or Many) 이렇게 두 엔티티의 관계가 정의될 수 있다.

Crow's foot Diagram: 까마귀 발 모양 같다고 해서 붙여진 이름

관계들을 정리한 내용

그렇다면, 만약 ? 다대다의 관계가 발생하면 어떻게 해야할까? 다대다의 관계는 원자성을 가져야 한다는 (값은 반드시 하나의 값으로만 이루어져야 한다)를 위반하는 상황을 초래하게 된다. 그래서 이럴 때 해결책은 중간 다리를 놓아서 해결해줄 수 있다. 이 중간 다리 역할을 하는 테이블을 "브리징 엔티티(joining(bridging /intersection/junction) entity)"이라고 한다.

 아래 테이블을 보면 이해하기 쉽다.  오더 테이블의 프로덕트는 FK 이고 이는 Product 테이블을 참조할 수 있도록 해준다. 그리고 반대로 Product의 오더는 FK로, 오더의 PK를 참조하도록 되어있다. 문제는 FK들이 모두 여러개의 값을 보유하고 있다는 점이다. 원자성에 위반되는 사항이다. 이럴 때 우리는 OrderedProduct라는 중간 브리지 엔티티를 도입한다. 이 브리지 테이블은 두 개의 compound key 를 PK로 가지게 된다. (이런 이유로 테이블이 늘어난다!)  이로 인한 이득은 원자성을 위배하지 않아도 된다는 점과 불필요한 NULL 값을 홀딩하지 않아도 된다는 점이다. 

 이렇게 관계를 따지다 보면 간혹 weak entity라는 것에 대해 접하게 된다. 이는 어떤 엔티티가 완전히 다른 특정 엔티티가 없이는 존재할 수 없는 상황일 때를 의미한다. 예를 들어, 호텔방이라는 엔티티가 있다고 하자, 호텔방이라는 엔티티는 호텔이라는 엔티티 없이 단독으로 존재할 수 있는 가? 대답은 NO. 그렇다면 호텔방은 weak entity 가 된다. 이런 엔티티는 PK키가 별도로 없고 부분 키라는 것을 가지게 된다. 부분 키로는 각 데이터를 인지할 수 없지만 호텔이라는 엔티티의 PK와 호텔방 엔티티의 룸넘버가 composite key로써 하나의 인지자로 역할하게 된다. 

 strong entity의 경우, PK, FK 등이 있으며, default 값 같은 것들도 설정되는 일반적인 entity들이 모두 여기 해당된다. 

Stored Procedure, Trigger and View

쿼리를 만들면서 조금 어려웠던 것이 모든 작업을 자동으로 발생할 수 있도록 하는 것이었다. 예를 들어 하나의 입력이 발생했을 때 모든 조건들을 검토하여 관련 데이터 들이 모두 일관성을 유지하며 업데이트 되도록 하는 것이 하나의 챌린지였다. 그 가장 큰 역할을 해준 것이 바로 Stored Procedure과 Trigger 이다. 

 

Stored Procedure는 말 그대로 다양한 과정을 하나의 쿼리에 저장해두었다가 호출이 되면 해당 쿼리를 실행하는 역할을 한다. Call 를 이용해서 호출할 수 있으며 안에 다양한 쿼리를 담을 수 있다. 예를 들어 조건 문 IF - ELSE 라던지 CASE - WHEN - 같은 것들을 쓸 수 있고 다른 Stored procedure를 호출할 수도 있다. 또 하나의 특별한 점은 값을 반환할 수 있다는 점이다. 그래서 메세지를 출력하거나 혹은 찾아낸 값을 반환할 수도 있다. 

Trigger의 경우는 단어 그대로 어떤 일이 발생했을 때 트리거처럼 이어서 작동되는 역할을 한다. 예를 들어 학생 테이블에 학생 입학금 데이터를 입력했을 때 (insert를 써서 입력 가능), 학교의 총 입학금이 업데이트 되도록 하고 싶다(update)는 상황이 있다고 하자. 

그러면 CREATE TRIGGER triggername AFTER INSERT ON 학생테이블 ~~~ 과 같이 시작할수 있다. 아래 예시에서 트리거는 bankbalance에 업데이트가 발생하였을 때 만약 새로운 금액이 입력되면 값을 업데이트하는 것으로 설정하였다. 

다음으로 VIEW 는 가상 테이블과 같다고 생각할 수 있다. 쿼리로 미리 정의된 결과를 보여주는 테이블이며 우리가 원할 때 언제든 테이블을 부르듯 부를 수 있다. 테이블의 경우 원하는 결과를 얻기 위해 매번 쿼리를 다 써서 불러야 하는 한 편, 뷰를 사용하면 자주 호출해야하는 결과들을 한번의 select 쿼리로 출력할 수 있어 효율적이다. 

CREATE VIEW visitor_log AS
	SELECT name, date, hotel, city
    FROM Hotel_Visitor_History
    WHERE city='SEOUL'; 

SELECT * FROM visitor_log;

데이터 베이스 정규화 

스키마의 체계적 분석은 1)중복을 제거하고 2)데이터 수정 문제를 제거하고 3)데이터 베이스 쿼리를 단순화 하고 4)가능한 효율성을 향상시키는 데서 온다. 새로운 데이터를 입력할 때 발생할 수 있는 문제점으로 만약 특정 데이터가 존재하지 않는 경우 NULL값이라도 넣어야 하는 상황이 생긴다는 것이고 이것은 메모리를 낭비하여 비효율적이라고 볼 수 있다. 또 데이터를 업데이트(수정) 하는 경우, 관련 데이터가 다른 테이블에도 있는 경우 여러번 업데이트를 해야 하고 만약 추가 정보를 같이 업데이트하려고 하면 전체 테이블을 수정해야 하므로 테이블의 구성과 심하면 관계도를 다시 설계해야하는 상황이 올 수 있다. 뿐만 아니라 데이터를 삭제하는 경우 하나의 항목만 삭제되는 것이 아니라 해당 내용이 포함된 전체 행이 삭제되기 때문에 자칫 필요한 데이터가 삭제되는 경우도 발생할 수 있다. 

이러한 여러 문제들이 발생할 수 있기 때문에 이를 방어하기 위해서 정규화는 전통적 데이터베이스 설계에서 굉장히 중요한 과정이라고 볼 수 있다. 

 

일반적으로 1차 - 3.5차 정규화를 거치면 대부분의 테이블들은 쪼개질 수 있는 최대로 쪼개어진 것으로 보지만 3차 이후의 정규화들도 사용되는 경우들이 있다. 여기에서는 6차까지만 언급할 것이다. 정규화가 완료되었다고 생각된다면 스키마의 체계적 분석 요건 4가지를 모두 충족하는 지 확인해 봄으로써 설계를 확인 할 수 있겠다.

 

Stage	Condition
1st Normal form - 1NF	각 행이 전부 PK로 독립적이고 유니크하게 분류될 수 있다.(각 열에 중복이 없다) 각 열이 모두 원자성을 가진다.(하나의 셀은 단, 하나의 값만 보유) 중복되는 행이 없다.
2nd Normal form - 2NF	1차 정규화를 만족할 때,  Composite key(2개 이상이 세트) 가 PK 일때 모든 열들이 PK 세트에 의존하는 경우 Full dependency라고 하고 하나의 키에만 의존하는 경우 Partial dependecy 라고 한다. Partial dependency 모두 제거!  만약 필요하면 브리지 테이블을 도입할 수 있다.
3rd Normal form - 3NF	1차, 2차 정규화 모두 만족 시,  각 열은 모두 PK에 따라서만 달라질 수 있다. (만약 다른 값에도 영향을 받는 다면 쪼개야 한다!!)
Beyond 3rd Normal form (Boyce-Codd Normal form, 3.5NF)	만약 3차까지 만족한다면,  테이블은 단 한개의 후보키를 가질 수 있다.
4NF	BCNF(3.5 정규화)까지 만족시,  열은 하나 이상의 중복값을 가질 수 없다.
5NF	4 정규화 까지 만족시,  데이터 손실 없이 더이상 테이블 쪼갤 수 없는 상태이다
6NF	5 정규화까지 만족시, 각 테이블에는 하나의 열만 가지고 있다.