DBMS의 무결성에 대해 알아보았다.

기르기르·2022년 9월 30일

DB 기초

목록 보기

2/6

DataBase 무결성

DataBase의 무결성

데이터 무결성은 데이터의 정확성, 일관성, 유효성을 의미한다.
정확성이란 중복이나 누락이 없는 상태를 말하고, 일관성은 원인과 결과의 의미가 연속적으로 보장되어 변하지 않는 상태를 말한다.
주로 데이터에 적용되는 연산에 제한을 두어 데이터의 무결성을 유지한다.

무결성이 필요한 이유가 뭘까?

데이터베이스에서 데이터 무결성 설계를 하지 않는다면 테이블에 중복된 데이터 존재, 부모와 자식 데이터 간의 논리적 관계 깨짐, 잦은 에러와 재개발 비용 발생 등과 같은 문제가 발생할 수 있기 때문이다.

데이터 무결성 제약조건?

데이터베이스의 무결성(정확성, 일관성, 유효성) 보장을 위해 저장, 삭제, 수정 등을 제약할 수 있는 조건이다.
제약조건 또한 장점과 단점이 존재한다.

장점
응용 프로그램들은 일관성 조건을 검사할 필요가 없다.
스키마를 정의할 때 일관성 조건을 오직 한 번만 명시하고, 데이터베이스가 갱신될 때 DBMS가 자동적으로 일관성 조건을 검사한다.

단점
(1) 프로그래밍 작업이 훨씬 복잡해진다.
(2) 무결성 제약조건을 반복해서 구현해야 한다.
(3) 무결성 제약조건들 간에 서로 충돌이 발생할 수 있다.

무결성 제약조건의 종류🧾

1. 개체 무결성(Entity integrity)
① 기본 키 제약이라고도 한다.
② 기본 키는 테이블 내에 오직 하나의 값만 존재해야 한다.
     -기본 키는 튜플들을 고유하게 식별하고, 효율적으로 빠르게 접근하는 데 사용되며 두
     개 이상의 튜플이 동일한 기본 키 값을 갖을 수 없다.
③ 릴레이션의 기본 키를 구성하는 어떤 애트리뷰트도 널값을 가질 수 없다
     - 기본 키를 구성하는 애트리뷰트가 Null값을 가지면 튜플들을 고유하게 식별할 수
     없게 되기 때문.

2. 참조 무결성 (Referential integrity)
① 외래 키 제약이라고도 한다.
② 참조 관계에 있는 두 테이블의 데이터가 항상 일관된 값을 갖도록 유지되는 것을 말한다.
③ 외래 키 속성 값이 상위 테이블의 인스턴스에 반드시 존재하거나 Null이어야 한다.

3. 도메인 무결성(Domain integrity)
① 테이블에 존재하는 필드의 무결성을 보장하기 위한 것이다.
② 데이터 형식을 통해 값들의 유형(정수형, 실수형, 문자형 등)을 제한하고 애트리뷰트에 저장되는 값들의 범위를 제한할 수 있다.

4. 키(Key) 무결성
① 각 테이블에는 최소 하나의 키가 존재해야 한다.

5. Null무결성(Null integrity)
① 테이블의 특정 속성 값을 Null이 될 수 없도록 제한했다면 해당 속성에 Null 값을 지정할 수 없다.

데이터 보안, 무결성, 정합성의 차이

데이터 보안이란? 권한이 없는 사용자가 데이터베이스를 접근하여 검색하거나 갱신하지 못하도록 데이터베이스를 보호하는 것이다.

데이터 무결성이란? 권한을 가진 사용자로부터 데이터베이스의 정확성을 지키는 것이다.

데이터 정합성이란? 정합성은 데이터가 서로 모순 없이 일관되게 일치해야 함을 의미하며, 어떤 데이터들의 값이 서로 일치하는 것을 정합성이 맞다 라고 말한다. 비정규형을 사용해 아노말리(Anomaly : 이상현상)가 발생하면 정합성이 깨진다.

현업에서 FK를 사용하는가요?🤦‍

강의를 배울 때에는 열심히 ERD를 보며 PK 주고 FK 주고 만들었는데 우연히도 현업에서 FK를 제한적이게 사용한다는 이야기를 접했다. 찾아 본 결과 현업 DBA들은 대부분 FK의 사용을 반대하고 또 실제로 FK의 사용을 딱히 달가워 하지 않는 개발자들은 FK를 사용함에서 오는 이득보다 실이 크다고 말한다. 사실 이 부분은 나처럼 아직 배우고 있는 입장에서 미리 알아두면 좋지 않을까? 싶은 정보이다. 그래서 내가 찾아 본 것을 내용으로 써보고자 한다.

대표적으로 제기되는 몇 가지 문제

① 성능 저하
    외래키를 사용하면 테이블의 생성과 수정 등의 명령을 수행할 때 항시 무결성 검사를 시행하기 때문에 느려진다.
② 업무로직으로인한 구조 변경 시 어려움
    테이블의 수가 적으면 상관 없지만 규모가 큰 곳에서는 테이블의 수가 100만개가 넘는 대량의 데이터가 존재할 수 있기 때문에 구조를 변경할 때 FK의 제약조건으로 인해 발목 잡히는 경우가 있다고 한다.(부모 테이블의 구조가 바뀌면 자식 테이블에 Full Lock이 걸린다.) 그렇게 되면 시간 대비 비용 처리에 문제가 생기기도 한다.
③ 테스트 데이터 설계
    FK가 걸려있으면, 자식 테이블 테스트 데이터를 생성하면서 부모 테스트 데이터도 생성해야 하기때문에 간단한 테스트도 복잡해진다.
④ FK의 대처 방안 존재
     우회방법을 통한 테스트 데이터를 만들기, FK를 쓰는 대신 JOIN을 사용하는 등 굳이 FK를 쓰지 않더라도 정합성을 맞추고 무결성은 프로그램으로 대신하는 방식이 존재한다.

하지만 사실 다른 이유잖아!

현업의 DBA들과 실제 대기업 프로젝트에서 FK를 잘 사용하지 않는 것과 다르게 위의 문제들이 사실 오해에 비롯된 것이라는 반박도 있어 그 또한 기술하고자 한다!

① 성능저하? 별 차이도 없어
자식이 많은 부모테이블에서 대량 DELETE가 발생하는 특수한 작업에 한해서 영향이 있다.
필요한 DML을 바로 실행하고 DBMS가 반환하는 에러를 핸들링하는것이 오히려 성능 향상에 도움이 된다.
불필요하게 사전에 SELECT를 하는게 많아질 경우 오히려 동시성 문제와 성능저하가 일어난다.
② 애초에 구조를 잘 짜면 되는거 아냐?
애초에 잘못 짜여진 구조라는 얘기가 있는데.. 설계가 잘못된 경우, 작업 목표가 없는 경우이기때문에 문제가 발생하는 거라고 한다. 이거는 사실 실무에 나가서도 공감할 수 없을 것 같다.
③ FK를 대처하기 보다 그냥 쓰는게 나은데
아무리 잘 짜여진 프로그램이라도 무결성을 완벽히 보장할 수 없다. 애초에 무결성 등을 위해서 사용하라고 권장된 FK인데 성능저하 같은 미신과 그냥 불편하다는 이유로 배제하기에는 FK를 쓰는게 더 효과적이다.

개인적으로는 말이지..

솔직하게 말해서는 FK를 대부분의 회사에서 쓰지 않는데에는 이유가 있다고 생각한다. 가장 큰 원인은 업무량이 늘어나는게 아닐까. 기한 안에 맞춰 손실 줄이기, 인건비 줄이기 등은 생각보다 회사의 손익에 큰 영향을 미친다. 득실이 미비하고 방안이 있다면 그걸 선택하는게 비지니스 적인 측면에서 더 당연한 일이 아닐까? 실제로 현업에 들어가서는 시키는 대로 하는게 나의 일이겠지만 내가 어떻게어떻게하다가 DBA가 되고나서 PM이 되고나서 나 또한 그 방향을 제시해야 하는 사람이 될테니 이런건 머릿속에 담아두는게 이득인 것 같다. 그나저나 IT는 진짜 실시간으로 발전하는 분야답게 트렌드가 있다는게 조금 두렵다. 당장에도 다 머릿속에 넣기에 이렇게 방대한 자료들이 있는데 나이 먹어서 더 따라갈 수 있을까? 개인적인 바람으로 IT업계에서 오랜 시간을 보낸 사람들 다 세련 되었으면 좋겠다. 나도 그럴거라는 기대를 품을 수 있게 ㅋㅋㅋ 뭐 사실 이거는 내 하기 나름이겠지.