데이터베이스 시작

디자인의 중점을 유지하기 위해 데이터베이스의 용도를 요약하고 자주 요약을 참조합니다. 예를 들어 홈 기반 비즈니스를 위한 소규모 데이터베이스를 원하는 경우 "고객 데이터베이스는 우편물 및 보고서 생성을 위해 고객 정보 목록을 유지합니다."와 같이 작성할 수 있습니다. 기업 데이터베이스의 경우 각기 다른 역할의 사용자가 데이터베이스 및 해당 데이터를 언제, 어떻게 사용할지를 설명하는 여러 단락이 필요할 수 있습니다. 전체 디자인 프로세스에서 참조할 구체적이고 자세한 세부 임무를 만듭니다.

기존 정보 및 추적 메서드로 시작합니다. 예를 들어 현재 구매 주문을 원장에 기록하거나 종이 양식에 고객 정보를 보관할 수 있습니다. 이러한 원본을 사용하여 현재 캡처하는 정보(예: 양식의 모든 상자)를 나열합니다. 현재 중요한 정보를 캡처하지 않는 경우 필요한 개별 정보를 생각해 보세요. 각 개별 데이터 형식은 데이터베이스의 필드가 됩니다.

첫 번째 목록을 완벽하게 만드는 것에 대해 걱정하지 마세요. 시간이 지남에 따라 미세 조정할 수 있습니다. 그러나이 정보를 사용하는 모든 사람들을 고려하고 자신의 아이디어를 요청하십시오.

데이터베이스에서 원하는 내용과 생성할 보고서 또는 우편물의 유형을 생각해 보세요. 그런 다음 해당 목표를 충족하는 데 필요한 정보를 캡처하고 있는지 확인합니다. 예를 들어 지역별 매출을 보여 주는 보고서를 원한다면 지역 수준에서 판매 데이터를 캡처해야 합니다. 실제 정보가 포함된 보고서를 원하는 디자인으로 스케치합니다. 그런 다음 보고서를 만드는 데 필요한 데이터를 나열합니다. 우편물이나 데이터베이스에서 원하는 다른 출력에 대해 동일한 작업을 수행합니다.

예제

정기 전자 메일 업데이트를 옵트 인 또는 옵트 아웃할 기회를 고객에게 제공하고 옵트 인한 고객 목록을 인쇄하려 한다고 가정합니다. 고객 테이블에 예 및 아니요 값이 허용되는 전자 메일 보내기 열이 필요합니다.

전자 메일 수신에 동의한 고객의 경우 전자 메일 주소가 필요하므로 해당 필드도 있어야 합니다. 적절한 인사말(예: Mr., Mrs. 또는 Ms.)을 포함하려면 인사말 필드를 포함합니다. 전자 메일에서 이름으로 고객 주소를 지정하려면 이름 필드를 추가합니다.

필요한 정보 목록을 작성한 후 데이터를 구성하는 데 필요한 주요 엔터티(또는 주제)를 결정합니다. 엔터티 간에 데이터가 중복되지 않도록 합니다. 예를 들어 제품 판매 데이터베이스의 예비 목록은 다음과 같을 수 있습니다.

주요 엔터티는 고객, 공급업체, 제품 및 주문입니다. 따라서 고객 팩트 테이블, 공급업체 팩트 테이블 등 4개의 테이블로 시작합니다. 최종 디자인이 아닐 수도 있지만 좋은 시작점이 됩니다.

테이블이 많을수록 더 좋은 이유를 이해하려면 아래 표시된 테이블을 고려해 보세요.

각 행에 제품과 공급업체 둘 다의 정보가 포함되어 있습니다. 동일한 공급업체의 여러 제품을 사용할 수 있으므로 공급업체 이름과 주소 정보를 여러 번 반복해야 합니다. 이 경우 디스크 공간이 낭비됩니다. 대신, 공급업체 정보를 별도의 공급업체 테이블에 한 번만 기록하고 해당 테이블을 제품 테이블에 연결합니다.

이 디자인의 두 번째 문제는 공급업체에 대한 정보를 수정해야 하는 경우에 명확하게 나타납니다. 공급업체 주소를 변경해야 한다고 가정합니다. 주소는 여러 위치에 나타나므로 실수로 한 곳에서만 주소를 변경하고 다른 곳에서는 변경하지 않을 수 있습니다. 한 곳에만 공급업체 주소를 기록하면 이 문제가 해결됩니다.

마지막으로, 세기 무역에서 공급하는 제품이 하나뿐인데 해당 제품을 삭제하되 공급업체 이름과 주소 정보를 유지하려 한다고 가정합니다. 이 디자인에서 어떻게 하면 공급업체 정보 손실 없이 제품 레코드를 삭제할 수 있을까요? 불가능합니다. 각 레코드에 공급업체 팩트뿐 아니라 제품 팩트가 포함되어 있으므로 하나만 삭제하고 다른 하나를 유지하는 것은 불가능합니다. 이러한 팩트를 별도로 유지하려면 이 테이블을 제품 정보 테이블과 공급업체 정보 테이블로 분할합니다. 그런 다음 제품 레코드를 삭제하면 제품 팩트만 삭제되고 공급업체 팩트는 삭제되지 않습니다.

데이터베이스 테이블의 주제를 선택한 후 해당 테이블의 열에는 단일 주제에 대한 팩트만 저장되어야 합니다. 예를 들어 제품 테이블에는 제품 팩트만 저장되어야 하고 공급업체 팩트는 저장되면 안 됩니다.

테이블에서 추적할 정보를 결정하려면 앞서 만든 목록을 사용합니다. 예를 들어 고객 테이블에는 이름, 성, 주소, 전자 메일 보내기, 인사말, 전자 메일 주소 등이 포함될 수 있습니다. 테이블의 각 레코드(고객)에 동일한 열 집합이 있으므로 고객마다 정확히 동일한 정보를 저장합니다.

첫 번째 목록을 만든 후 검토하고 구체화합니다. 정보를 가능한 최소 필드로 나누어야 합니다. 예를 들어 초기 목록에 주소가 필드로 포함되어 있으면 주소, 구/군/시, 시/도, 우편 번호로 나누거나, 고객이 전 세계에 걸쳐 있는 경우 더 많은 필드로 나눕니다. 그러면 예를 들어 적절한 형식으로 우편물을 보내거나 시/도별로 주문을 보고할 수 있습니다.

각 테이블의 데이터 열을 구체화했으면 각 테이블의 기본 키를 선택할 준비가 되었습니다.

각 테이블의 행을 고유하게 식별하는 방법이 필요합니다. 두 고객의 이름이 같았던 앞의 예제를 떠올려 보세요. 두 고객이 이름을 공유하기 때문에 각 고객을 개별적으로 식별하는 방법이 필요합니다.

따라서 모든 테이블에 각 행을 고유하게 식별하는 열(또는 열 집합)을 포함해야 합니다. 이를 기본 키라고 하며 직원 ID 번호, 일련 번호 등의 고유 번호인 경우가 많습니다. Access는 기본 키를 사용하여 여러 테이블의 데이터를 신속하게 연결하고 데이터를 통합합니다.

때로는 기본 키가 둘 이상의 필드로 이루어져 있습니다. 예를 들어 주문의 개별 항목을 저장하는 주문 세부 정보 테이블은 주문 ID와 제품 ID의 두 열을 기본 키에 사용할 수 있습니다. 기본 키가 둘 이상의 열을 사용하는 경우 복합 키라고도 합니다.

카탈로그에서 각 제품을 고유하게 식별하는 제품 번호와 같이 테이블의 정보에 대한 고유 식별자가 이미 있는 경우 해당 식별자를 사용하되, 이러한 값이 기본 키에 대한 다음 규칙을 충족해야 합니다.

• 각 레코드의 식별자가 항상 다릅니다. 기본 키에 중복 값은 허용되지 않습니다.

• 항목의 값이 항상 있습니다. 테이블의 모든 레코드에 기본 키가 있어야 합니다. 여러 열을 사용하여 키를 만드는 경우(예: 부품 패밀리 및 부품 번호), 두 값이 항상 있어야 합니다.

• 기본 키는 변경되지 않는 값입니다. 키가 다른 테이블에서 참조되기 때문에 한 테이블에서 기본 키를 변경할 경우 해당 키를 참조하는 모든 테이블에서 변경되어야 합니다. 자주 변경할 경우 오류가 발생할 가능성이 커집니다.

명확한 식별자가 없는 경우 임의의 고유 번호를 기본 키로 사용합니다. 예를 들어 주문을 식별하는 목적으로만 각 주문에 고유한 주문 번호를 할당할 수 있습니다.