Post

[SQL] 제약조건 정규화

이번시간에는 테이블을 만들 때 제약조건과 정규화에 대해서 알아보겠습니다!

Desktop View

오늘도 어김없이 emp 테이블로 시작하겠습니다. 저기서 혹시 중복이 안 되는 값이 들어갈 수 있나요? 바로 사원번호입니다. 이름이나 직급 등등은 모두 중복이 될 수 있죠. 그런데 생각해봅시다. 반약 이름도 같고 직급도 같고 사수도 같고 다 같은 사람이 들어오면 어떡하죠? 만약 Drop으로 둘중 하나를 지워야 할 때 어떤 것으로 구분할까요? 만약 이름을 기준으로 하면 그 이름을 가진 모든 레코드들이 사라질 겁니다. 그래서 우리는 고유값을 가지는 필드를 하나 정하고 테이블을 만들 때부터 제약을 정합니다. 이제 제약조건(constraint condition)입니다.

제약조건(constraint condition)

Unique

유니크는 말 그대로 각각 한가지 값만 가질 수 있습니다. 따라서 같은 값을 insert하면 에러가 납니다. 제약조건은 테이블을 생성할 때만 적을 수 있으므로 신중하게 만들어야 합니다.

Desktop View

여기서 member_id 를 보시면 int 타입 뒤로 unique가 보입니다. 그럼이제 이 member_id는 각각 고유한 값만 올 수 있습니다.

그런데 문제가 있죠? 만약 이대로 테이블을 만들고 레코드를 insert하는데 member_id를 아예 안 넣을 수 도있잖아요? 그럼 NULL값이 될거고 만약 모든 값이 똑같은 레코드 2개가 들어왔다면 곤란해지겠죠? 따라서 우리한테 member_id를 강제로 값을 만들어야 하게 하는 제약조건이 있습니다.

Not NULL

Not NULL은 말 그대로 이 제약조건을 테이블을 생성할 때 넣으면 그 테이블에 레코드를 insert할 때 강제로 그 필드 값을 적어야 합니다.

그래서 보통 이 두개를 같이

Desktop View

이런식으로 만듭니다. 이제 member_id는 중복된 값이 올 수 도 없고, 강제로 값을 적어야합니다. 이러면 각각의 고유값이 무조건 생기겠죠?

PRIMARY KEY

이것은 위의 Unique와 Not NULL을 합친 것입니다. ㅋㅋ 그래서 보통 이 제약조건을 많이 쓰죠. 이제 더 할게 없을거같은데 또 문제가 생깁니다. 만약 레코드들을 보통 고유넘버를 지정하면서 1씩 차례대로 입력하는데 중간을 건너뛸 수도 있잖아요? 3까지 쓰고 다음엔 4를 써야하는데 5를 쓴다던가.. 하는 것을 방지하기 위해서 존재하는 제약조건이 있습니다.

Auto_increment

이것을 테이블을 생성할 때 어떤 필드에 지정하면 insert할 때 그 필드의 레코드 값을 적지 않습니다. 자동으로 1부터 쭉 값이 커지면서 대입이 되죠 ㅎㅎ 그래서 primary key auto_increment로 고유값이면서 빼먹지 않고 하나씩 자동으로 숫자가 만들어지죠.. 정말 편하죠?

정규화

Desktop View

이 두 테이블을 보면 어떤 생각을 할까요? 저기 보이는 부서번호를 주로 하는 테이블이 하나 더있죠? 만약 쇼핑몰 DB를 만든다고 합시다. 그럼 각각 상품마다 중복되는 레코드 값( 상의, 하의 등)을 다 적어야겠죠? 그럼 중복되는 값들이 엄청 많아지겠네요. 근데 우리가 코딩을 하고 프로그래밍 언어를 사용하는 이유가 무엇일까요? 바로 이런 중복을 최소화하고 효율적으로 관리를 하기 위함이죠. 따라서 이런 중복되는 카테고리들을 하나로 묶어서 다른 테이블로 만들어 주는것을 정규화라고 합니다! 이것은 어떤 기술이라기보다 개발자의 사고방식과 마인드라고 할 수 있죠.

이번 시간에는 여기까지 하겠습니다!

This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.