OfficeTutor 365

정확한 자료의 입력..

 

 컴퓨터를 사용하는 것은 자료의 정확성을 높이기 위함이다. 일 예로 은행에서 공(0)이 하나 더 붙으면 백만원이 천만원이 된다. 아마 필자에게 공이 두어 개 붙은 통장이 생긴다면 ‘돈을 갖고 튀어라’라는 영화의 주인공처럼 바로 날라 버리고 말 것이다. 인생역전 로또 보다 나을 것이다.(ㅋㅋ 한번 이런 일이 안 생기나..).

하지만 컴퓨터로 봐서는 단순히 2바이트의 오류에 해당한다. 수십 기가(Giga)의 하드용량으로 봐서는 정말 무시해도 될 듯하지만 이런 일은 여러 사람 밥줄이 끊길 일이다. 몇 일 전에 모 은행의 전산담당자가 전산장애(?)로 기자회견까지 하면서 쩔쩔매는 화면을 보면서 ‘쯔쯔쯔 안됐군..ㅡ.ㅡ’한 기억이 새롭다. (사실 유출만 안될 뿐 모든 전산시스템에서 이런 일은 비일비재하게 일어난다 다만 밖으로 새어나가지 않았을 뿐이지…)

 

그렇다면 프로그램을 하고 있고 자료를 관리하는 여러분들은 어떻게 정확한 자료를 컨트롤 할 것인가

 

아래의 자료는 국립중앙도서관의 도서입력정보 중에서 나타난 오류의 유형을 분석한 한 부분의 자료이다.

오류항목	입력오류 유형	예	처리사항
다양한단위	c	$c12 c%	모두 cm 로 수정
	c,	$c12 c,
	cn	$c12 cn
	c,m	$c12 c,m
	cnm	$c12 cnm
	CM	$c12 CM
	Cm	$c12 Cm
	m	$c12 m
	.m	$c12 .m
	mm	$c12 mm
	dm	$c12 dm
	xm	$c12 xm
	vcm	$c12 vcm
	p.	$c12 p.
	장	$c12 장
	츠	$c12 츠
5	영문+숫자	$cB18

 

 

단순히 12cm으로 표기하면 되는 간단해 보이는 입력에 수없이 많은 유형의 오류가 나타난다. 어떤 바보가 저렇게 입력을 했냐고 따져 물을 것인가? 당연 입력한 사람이 있을 테지만 ‘사람’이 한 일이다. 돈에 공이 더 붙은 사건처럼 치명적이진 않아도 자료의 정확성이라는 면에서는 이미 치명적인 오류 상황인 것이다.

 

 

 

오늘은 자료의 정확성을 어떻게 확보할 지에 대해서 얘기해 보자.

 

- 정확성은 테이블 설계단계에서 부터….

자료형 : 숫자의 경우 tinyint(0~255 1byte), smallint(-32768~32767 2byte), int(약 -21억~21억 4byte), decimal, numeric, real, float (필요한 설명은 F1을 뒤지거나 검색으로 확인길..)등을 사용한다. 내용에서 알 수 있듯이 이미 데이터 형에 따라 사용할 수 있는 정확도는 이미 결정이 되어있다. 또 숫자형으로 정의 할 경우 이미 숫자 이외의 문자형 등의 입력은 차단된다. (가끔은 문자형을 사용해서 형 변환을 해야 하는 예외적인 경우도 발생한다. ) 사용하게 될 자료형을 신중하게 고르는 것에서부터 자료의 정확성은 시작된다. 참고로 문자형의 선택 시 일정한 길이의 데이터가 아니라면 CHAR형의 사용보다는 VARCHAR형을 사용하는 것이 옳다. MDB에서의 ‘텍스트’형은 VARCHAR형에 해당한다. CHAR형의 경우 남은 공간에 공백문자가  채워짐으로 추후에 프로그램에서 이 공백을 제거하느라 수없이 TRIM을 호출하게 되는데 그래도 꼭 빼먹는 실수가 애먹인다 ㅋㅋ.

 

NULL값허용 : 설계단계에 꼭 지켜야 하는 사항은 더 있다. NULL값의 허용 여부는 자료 정확성에 빼놓을 수 없는 사항이다. 널 값은 꼭 필요한 개념이긴 하지만 입력, 계산, 통계등에서 많은 오류와 혼란을 야기함으로 주의를 기울여야 한다.  특히 키 값이나 키 값처럼 사용될 소지가 있다면 반드시 NOT NULL이다.

 

기본 값 : 설계시의 주의 사항 또 하나는 기본 값의 지정이다. 기본값의 지정은 사용자의 입력오류와 데이터의 신뢰성을 높인다. 숫자형이라면 꼭 비워두어야 할 경우가 아니라면 0를 기본값으로 넣어 두자.

 

이와 같이 입력되는 자료에 따라서 자료형을 선택하고 자료의 크기를 선택하는 설계작업은 자료 정확성의 시작이다.

 

다음으로 자료의 정확성을 확보하는 것은 입력 단계이다. 여기서는 입력 폼을 구성할 때 사용 가능한 기능들을 살펴보자.

- 마스크를 사용해서 자료의 정확성을 높이자.

예로 입력되는 숫자가 년도 4자리라면 ‘0000’  - 4자리의 숫자를 꼭 넣어라. 안 넣으면 에러메시지 표시한다’ 라는 의미이다. 마스크의 기능은 설명서를 참조하거나 게시판에서 검색해 보고 꼭 익혀두어야 할 기능이다.

 

- 다음은 입력란의 형식을 사용해라.
입력란의 속성에는 ‘형식’이라는 속성이 있다. 날짜의 경우 년/월/일/요일/시를 원하는 형식에서 선택하거나, yyyy-mm-dd hh:nn처럼 결정할 수 있으며, 숫자의 경우 통화, 고정소숫점, 백분율 등을 선택해서 표기할 수 있다. 100000000보다는 100,000,000(쉼표 구분)이 가독성도 높고 입력오류를 더 줄일 수 있다.

 

- 기본값
입력란에 기본값을 설정함으로써 실수로 값을 입력하지 않을 경우를 대비 할 수 있다.

 

- 유효성 검사 규칙 / 유효성 검사 메시지
예로 1980년에 만들어진 회사의 입사년도를 입력할 경우 그 범위는 1980~2004년까지이다. 실수로 1980년 이전 이나 2004년 이후의 값이 입력된다는 것은 숫자이므로 에러는 없지만 범위를 벗어남으로 오류가 된다. 이럴 경우 범위 밖으로 벗어날 경우 오류메시지를 표시하는 기능이 유효성 검사 규칙 속성이고, ‘1980년 이전엔 회사없었으니 확인해ㅡ.ㅡ+’ 라고 경고메시지를 표시하는 것이 유효성 검사 메시지 이니 필요에 따라서 잘 활용하시면 된다.

 

- 입력시스템 모드
입력시스템 모드는 해당 입력란의 입력되는 문자의 언어를 선택하도록 하는 기능이다. 영문이름 이라는 필드라면 당근 영어를 선택해 놓으면 한영키를 누르는 번거로움이나 한글로 입력하다 지우고 다시 입력하는 수고로움도 없을 것이다.

 

- 자동 고침 사용
한글과 영어가 혼재 되었을 때, 추천단어나 표준어가 잘못 쓰였을 때 자동으로 수정해 주는 기능으로 요긴하다. 도구의 ‘자동고침…’대화상자의 내용이 적용된다.
하지만… 가끔은 성가시게 할 때도 있다. 특정단어를 입력했는데 자꾸 영어로 바뀐다거나 꼭 입력하려고 하는데 자동으로 표준어로 바꿔준다거나… 상황에 맞게 쓰시라.

 

- 검사루틴
위의 기능들을 모두 검토해도 해결이 안 되는 것들이 있다. 예로 주민번호의 규칙체크를 해야 한다면 어떻게 입력 오류를 줄일 것인가. 당연 이때는 루틴(함수)을 만들어서 입력시나 수정 시에 검사하도록 해야 한다.

- 트리거검사/스토어드 프로시져
트리거/스토어드 프로시져는 검사루틴으로 사용할 수도 있지만 연관성 있는 자료의 수정이 있을 때는 유용하다.(예로 금액이 수정될 때 마다 누가 수정했는지 정보를 다른 테이블에 기록해야 한다면 트리거가 유용할 것이다) 또 함수와 달리 서버에서 실행이 됨으로 훨씬 빠르게 동작하며, 프로젝트 내의 프로그램 변경 없이 서버 사이드의 변경으로 적용이 됨으로 이점이 많다. 필요에 따라서 자료의 유효성을 검사하는 루틴을 제작 검증하는데 이용된다.

- 육안검사
입력이 왠만큼 이뤄진 후라면 꼭 육안 검사를 해보자. 어떻게? 10만 건이 입력되었는데 하나씩 불러서 검증해야 하는 것은 작업자의 업무고, 액세스에서 테이블을 열어서 각 필드 별로 오름차순 내림차순으로 정렬해 보는 것만으로도 수많은 오류를 찾아 낼 수 있다. 프로그래머는 자신이 구현한 작업방법과 순서대로만 작업하므로 사용자들의 패턴을 알 수 없다. 사용자들은 한 마디로 어디로 튈지 모르는 럭비공과 같다. 육안검사를 할 때 마다 느끼는 거지만 참 기상천외하게도 내가 만들어 놓은 로직을 벗어나는 오류상황연출로 놀라지만 어쩌랴 내가 완벽한 인간이 못되고 사용자도 완벽한 인간이 아닌 것을……

…………………………….

사족

자료 입력의 정확성을 높이는 일은 아주 중요한 일이지만 또 반면 강하면 부러진다. 상황에 따라서는 유연한 입력구조가 필요한 경우가 더 많다. 필수, 키 값, 코드 값 이외의 경우 데이터의 특성을 살펴서 사용자의 편의가 더 우선시 되는 경우의 고려도 잊지 마시라…

 

 

~~EASY IS POWERFUL SIMPLE IS BEAUTIFUL~~~