데이터 정합성이 깨지기 쉬운 테이블 설계

데이터 정합성[참고 1]이 깨지기 쉬운 테이블 설계

이철우

관계형 데이터베이스에서 사번이 주열쇠인 인재 테이블, 사번과 발령 날짜가 주열쇠인 발령 테이블은 다음과 같을 것이다.

인재 테이블
-
사번 이름 출생날짜
1 홍길동 1990-01-01
2 서경덕 1995-05-05
3 황진이 2000-06-06
...
발령 테이블
-
사번 발령날짜 발령내용 
1 2010-01-01 입사사원
2 2014-01-01 입사사원
1 2015-01-01 승진대리
3 2023-07-01 입사사원
...

이렇게 두 테이블을 구성하면 데이터 정합성이 잘 지켜질 것이다. 그런데 현업의 요구(?)에 따라 발령 테이블에 이름을 넣었다고 하자. 그러면 발령 테이블은 다음과 같이 될 것이다.

바뀐 발령 테이블
-
사번 이름 발령날짜 발령내용 
1 홍길동 2010-01-01 입사사원
2 서경덕 2014-01-01 입사사원
1 홍길동 2015-01-01 승진대리
3 황진이 2023-07-01 입사사원
...

이제 홍길동 사원이 이름을 '홍건적’으로 바꾸었다고 하자. 당연히 인재 테이블 사번 1의 이름을 바꾸어야 한다. 발령 테이블은 고칠 것이 없고 '바뀐 발령 테이블’은 인재 테이블처럼 사번 1의 이름을 바꾸어야 한다.

만약 이를 놓쳤다면, 사번 1의 이름이 테이블마다 다르게 되고 이것을 '데이터 정합성이 깨졌다’라고 한다. 電算 데이터는 현업의 신뢰를 잃게 될 것이다. 데이터 ‘이름’ 重複에 따라 유지/보수가 어려워진 것이다.

사실 '바뀐 발령 테이블’은 관계형 데이터베이스가 나오기 전, 파일 시스템 시대에 설계하던 방식이다. '발령 파일’에 이름이 없을 경우, 사번 1의 이름을 알려면 '인재 파일’을 또 읽어야 하는 문제가 있었다. 그러나 관계형 데이터베이스에서는 두 테이블을 결합(Join)해서 이 문제를 간단히 해결한다.

2017년 L사 G시스템을 유지/보수하며 위에 같은 데이터 '중복’을 접했다. 또한 2023년 H증권 API를 분석하며 파일 시스템의 잔재를 보았다. 관계형 데이터베이스를 파일 시스템처럼 쓰며 유지/보수 비용을 과다하게 지출해야만 하는 현장들이다. A사 버전 n 데이터베이스를 B사 버전 n+로 바꾸는 것이 '高度化’가 아니고 데이터 정합성과 무결성이 지켜지기 쉽게 테이블을 설계하는 것이 고도화가 아닐까? 이런 것을 아는 인재가 경영者가 되어야 한다.

[참고 1]무결성과 정합성이란 무엇인가?

4 Likes

사상누각

현업에서 사람 손을 많이 거친 테이블들을 보면 정말 단순한 Join 조차도 안하려 하더군요.

3 Likes

저비용 고효율을 쫓아
'처음’엔 '개발비 절감’이란 이득을 ‘한 때’ 얻었는데,
그 뒤 '지속’적인 유지/보수 비용 지출이라는 '손해’를 감수하는
저렴한 경영입니다.

1 Like

사실 이 정도는 대학교 과제에서도 흔히 다루는 수준인데
하청의 하청 국비 경력 뻥튀기로 오는 경우가 많아서…

2 Likes

저는 이 책을 봤습니다.

An Introduction to Database Systems, 저자 C. J. Date, 아마도 6판이나 7판을 본 듯 합니다.
저자는 최초의 관계형 데이터베이스 IBM DB2 를 만든 사람입니다.

아래 링크는 8판 입니다.

https://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844

3 Likes