데이터베이스 표준화 팁

Luke Chung

FMS, 사장

2002년 9월

적용 대상:

   Microsoft Access

요약 : 이 기사에서는 개발자들에게 Access 테이블을 설계할 때 위험을 피할 수 있도록 팁을 제공합니다. 이 기사는 Microsoft Access 데이터베이스(.mdb)와 Microsoft Access 프로젝트(.adp)에 적용됩니다.

목차

소개
데이터 이해
어떤 데이터가 필요한가 
데이터로 무엇을 할 것인가 
데이터가 서로 어떻게 연결되어 있는가 
데이터가 어떻게 변할 수 있는가 
쿼리 사용 방법 학습
데이터베이스 표준화 개념
한 곳에 고유한 정보 저장
레코드는 무료이지만 새 필드는 고가
데이터를 복제해야할 시기 파악
키 필드에 대해 의미없는 필드 사용
참조 무결성 사용
결론

소개

데이터베이스를 설계할 때 가장 중요한 단계중 하나는 데이터의 테이블에 데이터가 제대로 분배되었는지 확인하는 것입니다. 적당한 데이터 구조가 있으면 응용 프로그램의 나머지 부분(쿼리, 폼, 보고서, 코드 등)은 크게 간단해집니다. 올바른 테이블 디자인의 형식 이름은 "database normalization"입니다.

이 기사는 기본적인 데이터베이스 표준화 개념과 고려해야 할 몇 가지 일반적인 위험에 대한 개요입니다.

데이터 이해

테이블 디자인을 계속하기 전에 데이터로 무엇을 할지와 시간에 따라 데이터가 어떻게 변경되는지를 알고 있어야 합니다. 도출한 가정에 따라 이벤트 디자인에 영향을 미칩니다.

어떤 데이터가 필요한가 

응용 프로그램을 디자인할 때 필요한 모든 데이터가 있는지 확인하고 데이터의 소스를 알아야 최종 결과물을 예상할 수 있습니다. 예를 들어, 보고서 모양이 어떤지, 데이터 소스가 어디인지, 모든 데이터가 존재하는지 등입니다. 실현, 프로세스 지연, 중요한 보고서에 데이터가 누락 등이 프로젝트에 손상을 주는 요소들입니다.

필요한 데이터를 알고 있으면 데이터의 소스를 확인해야 합니다. 데이터를 다른 소스에서 가져옵니까  해당 데이터를 정리하거나 확인해야 합니까  사용자가 데이터를 입력합니까 

필요한 데이터와 데이터의 소스를 파악하는 것이 데이터베이스 디자인의 첫 번째 단계입니다.

데이터로 무엇을 할 것인가 

사용자가 데이터를 편집해야 합니까  그렇다면 사용자가 데이터를 이해하고 편집할 수 있도록 데이터를 어떻게 표시해야 할까요  유효성 검사 규칙 및 관련된 조회 테이블이 있습니까  편집 및 삭제의 백업을 보관해야 할 데이터 입력과 관련된 감사 문제가 있습니까  어떤 종류의 요약 정보를 사용자에게 표시해야 합니까  내보내기 파일을 생성해야 합니까  이 정보가 있으면 필드가 어떻게 서로 관련된지를 그려볼 수 있습니다.

데이터가 서로 어떻게 연결되어 있는가 

데이터를 관련된 필드(예: 고객 관련 정보, 송장 관련 정보 등)로 그룹화합니다. 필드의 각 그룹은 앞으로의 테이블을 나타냅니다. 그런 다음 필드를 어떻게 서로 연결할지를 고려해야 합니다.  예를 들어, 일대다 관계로 관련된 테이블은 무엇입니까(예: 한 고객이 여러 송장을 가질 수 있음)  일대다 관계로 관련된 테이블은 무엇입니까(하나의 테이블로 결합하기 위한 고려 사항) 

데이터가 어떻게 변할 수 있는가 

테이블을 디자인한 후 시간에 대한 영향은 주로 고려하지 않지만 나중에 큰 문제를 야기할 수 있습니다. 대부분의 테이블 디자인은 즉시 완벽하게 사용할 수 있습니다. 그러나 사용자가 데이터를 수정하고, 새 데이터가 추가됨에 따라 시간이 지나면서 대부분의 디자인이 망가집니다. 이러한 변경 사항을 수용하기 위해 테이블을 다시 만들어야 할 수도 있습니다. 테이블 구조가 변경되면 모든 종속 요소(쿼리, 폼, 보고서, 코드 등)도 업데이트해야 합니다. 시간에 따라 예상되는 변경 사항을 파악하고 있으면 더 나은 디자인을 구현하여 문제점을 최소화할 수 있습니다.

쿼리 사용 방법 학습

데이터를 분석 및 조작하는 방법을 알고 있는 것도 중요합니다. 쿼리 작업 방법, 쿼리를 사용하여 여러 테이블의 데이터를 연결하는 방법, 쿼리를 사용하여 데이터를 그룹화 및 요약하는 방법, 비표준화된 양식으로 데이터를 표시해야 할 경우 크로스탭을 사용하는 방법 등을 잘 알고 있어야 합니다.

결국 좋은 데이터 디자인의 목적은 시간에 따라 데이터를 효율적으로 저장해야 할 필요성과 데이터를 쉽게 검색 및 분석해야 할 필요성 간에 균형을 이루는 것입니다. 쿼리의 기능을 잘 알고 있으면 테이블을 제대로 디자인하는 데 크게 도움이 됩니다.

데이터베이스 표준화 개념

데이터베이스 표준화에 대한 이론적인 설명을 제공하는 대신 이 절에서는 데이터베이스 표준화에 관련된 기본적인 개념을 설명합니다. 사용자 상황에서 이를 적용하는 방법은 응용 프로그램 요구 사항에 따라 달라질 수 있습니다. 목표는 이 기본 개념을 이해하고, 이 개념을 적용하며, 기본 개념에서 파생한 문제점을 이해하는 것입니다.

한 곳에 고유한 정보 저장

대부분의 데이터베이스 개발자는 데이터 표준화의 기본 개념을 이해하고 있습니다. 이상적으로는 동일한 데이터를 한 장소에 저장하고 참조해야할 경우 ID를 사용하여 이를 참조하는 것이 가장 좋습니다. 이렇게 하면 일부 정보가 변경되면 한 장소에서 이를 변경할 수 있고 응용 프로그램 전체에서 정보가 변경됩니다.

예를 들어, 고객 테이블에는 이름, 주소, 전화 번호, 전자 메일 주소 및 기타 특징을 포함한 각 고객의 레코드를 저장할 수 있습니다. 고객 테이블에는 키 필드이자, 다른 테이블에서 고객을 참조하기 위해 사용하는 고유한 CustomerID 필드(대개 Autonumber 필드)가 있을 수 있습니다. 따라서 동일한 고객이 여러 송장을 갖을 수 있기 때문에 모든 고객 정보를 각각의 송장과 함께 저장하기 보다는 송장 테이블에서 고객 테이블의 고객 세부사항을 조회하는 데 사용할 수 있는 고객 ID 값을 간단하게 참조할 수 있습니다. Access에서는 콤보 상자와 하위 폼을 사용하는 강력한 폼을 통해 이를 매우 쉽게 할 수 있습니다. 새 전화 번호처럼 고객 정보를 변경해야 할 경우 고객 테이블에서 이를 변경할 수 있습니다. 그러면 해당 정보를 참조하는 응용 프로그램의 다른 부분이 자동으로 업데이트되는 것을 알 수 있습니다.

적절하게 표준화된 데이터베이스에서는 시간에 따른 데이터의 변경을 약간만 편집하면 쉽게 처리할 수 있습니다. 제대로 표준화되지 못한 데이터베이스에는 종종 여러 레코드나 테이블에서 변경해야 하는 프로그래밍이나 쿼리가 포함되어 있습니다. 그러면 구현해야 할 작업이 많아질 뿐만 아니라 코드나 쿼리가 제대로 실행되지 않으면 일치하지 않게 될 데이터의 변경 사항도 늘어납니다.

레코드는 무료이지만 새 필드는 고가

시간에 따라 새 레코드를 간단하게 추가할 수 있도록 데이터베이스를 디자인해야 합니다. 데이터베이스 테이블은 많은 레코드 수를 보유할 수 있도록 디자인됩니다. 그러나 다른 필드를 추가해야 할 경우 디자인 문제가 생길 수 있습니다.

스프레드시트 디자인에 익숙한 방법으로 데이터베이스를 디자인하는 스프레드시트 전문가에게 주로 이런 일이 발생합니다. 시간에 따라 변하는 필드(연도, 분기, 제품 및 영업 사원 등)를 디자인할 때는 앞으로 새 필드를 추가할 수 있도록 해야 합니다. 그러나 올바른 디자인이란 더 많은 레코드를 추가할 수 있도록 정보를 바꾸고 시간에 따라 변하는 데이터를 한 필드에 넣을 수 있게 하는 것입니다. 예를 들어, 각 연도에 대한 별도의 필드를 작성하는 대신 Year 필드를 만들고 각 레코드의 연도를 해당 필드에 입력합니다.

다른 필드 추가가 문제가 되는 이유는 테이블 구조 변경이 응용 프로그램의 다른 부분에 영향을 미치기 때문입니다. 테이블에 필드를 추가할 경우 테이블에 종속된 개체와 코드도 업데이트해야 합니다. 예를 들어, 쿼리에서도 추가 필드를 포함시켜야하고, 폼에서도 추가 필드를 표시해야 하며, 보고서에서도 추가 필드를 포함시켜야 하는 식입니다. 그러나 데이터가 표준화되어 있다면 기존 개체에서 자동으로 새 데이터를 검색하여 이를 제대로 계산하거나 표시합니다. 쿼리를 사용하면 테이블에 있는 연도에 상관없이 Year 필드에서 그룹화하여 연도별 요약을 표시할 수 있기 때문에 쿼리가 특히 강력합니다.

그러나 데이터 표준화를 시간에 따라 변하거나 시간에 종속적인 필드가 있는 데이터를 표시하거나 사용할 수 없다는 의미는 아닙니다. 크로스탭 쿼리를 사용하여 이러한 정보를 표시할 수 있습니다. 크로스탭 쿼리에 익숙하지 않으면 크로스탭 쿼리 사용 방법을 배워야 합니다. 특히 크로스탭 쿼리 결과는 편집할 수 없다는 점에서 테이블과는 다릅니다. 그러나 데이터시트(255개 필드까지)에 정보를 표시하는 데 크로스탭 쿼리를 사용할 수 있습니다. 보고서에서 크로스탭 쿼리를 사용하려면 보고서에 추가 필드 이름이나 변경되는 필드 이름이 포함되어야 하기 때문에 더 복잡해집니다. 이것이 바로 대부분의 보고서에서 별도의 열 대신 보고서 내 별도의 그룹핑으로 데이터를 표시하는 이유입니다. 선택의 여지가 없는 경우 시간을 들여 이를 지원하도록 해야 하지만 모두가 시간에 따라 추가 리소스가 필요할 수도 있다는 것을 인식하고 있습니다.

따라서 이것이 바로 추가 레코드는 무료이고(데이터베이스의 큰 장점) 추가 필드는 비용이 많이 들어가는 이유입니다. 데이터베이스를 제대로 디자인했다면 무척 많은 양의 변경을 수용할 수 있습니다.

데이터를 복제해야할 시기 파악

때로 시간에 따라 변경될 수 있는 정보를 보존하려면 데이터의 표준화를 해제해야 합니다.

간단한 예제와 같이 고객 ID 번호를 통해 고객 테이블에 연결된 송장은 작성하는 시점이 아니라 송장이 발행되는 시점에 고객 주소를 포함해야 합니다. 왜냐면 두 이벤트 사이에 고객 정보가 바뀔 수 있기 때문입니다. 송장을 발행할 때 주소를 포함시키지 않고 앞으로 고객 정보를 업데이트해야 할 경우 특정 송장이 전송되는 정확한 주소를 확인할 수 없습니다. 이것은 심각한 비즈니스 문제가 될 수 있습니다. 물론 고객 전화 번화 같은 일부 정보는 보존하지 않아도 됩니다. 따라서 복제해야 할 데이터를 선택적으로 결정해야 합니다.

데이터를 복제에 대한 다른 예로 송장의 라인 항목을 입력하는 경우를 들 수 있습니다. 주로 가격 목록을 사용하여 고객이 주문한 품목을 선택합니다. 간단히 가격 목록 ID만 저장하여 제품 설명, 가격 및 기타 세부사항과 함께 가격 목록을 게시할 수 있습니다. 그러나 제품 설명과 가격은 시간에 따라 변합니다. 데이터를 가격 목록에서 라인 항목 테이블로 복사하지 않으면, 앞으로 원본 송장을 정확하게 다시 인쇄하지 못할 수도 있습니다. 아직 대금을 지불하지 않았을 경우 이것은 큰 문제가 될 수 있습니다.

표준화가 동일한 데이터를 한 장소에 보관하고 편집을 단순화시키는 데는 좋지만 이런 편의를 원하지 않는 경우도 있습니다. 기록상 이유로 데이터의 스냅샷이 필요한 경우 시작할 때 이를 데이터베이스에 디자인해야 합니다. 그렇지 않으면 데이터를 덮어쓴 경우 다시 가져올 수 없습니다.

키 필드에 대해 의미없는 필드 사용

효율성을 위해 각 테이블에는 키 필드가 있어야 합니다. 키 필드는 테이블의 고유성을 정의하며, 다른 필드에 대해 인덱스로 사용되어 검색 성능을 개선시킵니다. 예를 들어, 고객 테이블에는 고객의 고유한 번호를 정의하는 CustomerID 필드가 있을 수 있습니다. 국가 목록처럼 필드는 많지만 간단한 단일 조회 테이블이 없는 테이블을 예를 들어 설명합니다.

일반적으로 키 필드에는 다음과 같은 특성이 있습니다.

• 하나의 필드여야 합니다.

  여러 필드를 테이블의 키 필드로 정의할 수는 있지만 단일 필드를 선호합니다. 첫째, 고유성을 정의하기 위해 여러 필드가 필요한 경우 키를 저장할 때 더 많은 공간을 차지합니다. 둘째, 테이블의 다른 인덱스에서도 키 필드 조합을 사용해야 합니다. 그러면 단일 필드일 때보다 더 많은 공간을 차지합니다. 셋째, 테이블의 레코드를 식별할 때 키 조합을 인식해야 합니다. 고객을 정의하기 위해 다른 필드 조합을 사용하는 것보다 CustomerID 필드를 사용하는 것이 더 낫습니다.  

• 숫자여야 합니다.

  Access에서는 키 필드에 적합한 Long Integer인 AutoNumber 필드 형식을 제공합니다. 이 값은 자동으로 모든 레코드마다 고유할 뿐만 아니라 복수 사용자 데이터 입력도 지원합니다.  

• 시간에 따라 바뀌지 말아야 합니다.

  키 필드는 시간에 따라 바뀌지 말아야 합니다. 주민 등록 번호 같이 한 번 결정된 필드는 변경할 수 없습니다. 변경되는 키 필드는 링크가 해제되기 때문에 기록 데이터를 사용하기가 매우 어렵습니다.  

• 의미가 없어야 합니다.

  키 필드가 시간에 따라 바뀌지 않도록 하려면 의미가 없어야 합니다. 의미없는 키 값은 다른 데이터가 불완전한 경우에도 도움이 됩니다. 예를 들어, 특정인의 전체 주소를 갖고 있지 않는 고객 번호를 지정할 수 있습니다. 응용 프로그램의 나머지 부분은 제대로 작동하므로 이 키 필드를 받았을 때 정보를 추가할 수 있습니다. 테이블에서 사용자가 갖고 있지 않는 국가나 다른 식별 필드를 키 일부로 사용할 경우 응용 프로그램을 사용할 수 없는 위험을 감수해야 합니다.

따라서 위에서 언급한 모든 이유 때문에 대부분 테이블의 키 필드로 AutoNumber 필드를 사용할 것을 권장합니다. 콤보 상자와 숨겨진 열을 사용하여 필드를 AutoNumber 필드로 바인딩하고 이를 사용자에게 숨길 수 있습니다.

참조 무결성 사용

테이블이 정의되고 테이블이 서로 관련된 방법을 파악했으면 참조 무결성을 추가하여 이 관계를 강화하십시오. 이렇게 하면 링크된 필드가 잘못 수정되거나 "고아" 레코드가 되는 것을 방지할 수 있습니다.  Microsoft Jet Database Engine에서는 계단식으로 업데이트와 삭제를 할 수 있게 해주는 복잡한 참조 무결성을 지원합니다. 일반적으로 ID 필드는 변경하지 말아야 합니다. 그러므로 계단식 업데이트는 중요하지 않지만 계단식 삭제는 매우 유용할 수도 있습니다.

예를 들어, 주문 테이블과 연관된 송장 테이블이 있는데 송장에는 주문(라인 항목)이 무제한 있을 수 있고 각 주문 레코드에 주문이 연결된 송장 번호가 있을 경우, 계단식 삭제를 사용하면 송장 레코드를 삭제한 다음 해당하는 모든 주문 레코드도 자동으로 삭제할 수 있습니다. 그러면 해당하는 송장 레코드가 없는 주문 레코드는 만들어지지 않습니다.

결론

이 데이터베이스 디자인 개념을 사용자 여러분의 응용 프로그램 디자인에 조기에 적용하여 많은 문제점과 디자인이 구현되지 않을 경우 필요한 대책을 최소화하시길 바랍니다.  여러분의 행운을 빕니다.  

Luke Chung은 Microsoft Access 사용자 및 개발자를 위한 타사 제품을 제공하는 선두 공급자인 FMS Inc.의 사장겸 창립자입니다.