올바르게 설계된 데이터베이스를 사용하면 최신의 정확한 정보에 액세스할 수 있습니다. 올바른 디자인은 데이터베이스 작업에서 목표를 달성하는 데 필수적이므로 좋은 디자인의 원칙을 배우는 데 필요한 시간을 투자하는 것이 좋습니다. 결국 요구 사항을 충족하고 변화를 쉽게 수용할 수 있는 데이터베이스로 끝날 가능성이 훨씬 더 높습니다.
이 문서에서는 데스크톱 데이터베이스를 계획하기 위한 지침을 제공합니다. 필요한 정보를 결정하는 방법, 해당 정보를 적절한 테이블 및 열로 나누는 방법 및 해당 테이블이 서로 어떻게 관련되는지를 알아봅니다. 첫 번째 데스크톱 데이터베이스를 만들기 전에 이 문서를 읽어야 합니다.
이 문서의 내용
알아야 할 일부 데이터베이스 용어
Access 정보를 테이블로 구성합니다. 회계사의 패드 또는 스프레드시트를 연상시키는 행 및 열 목록입니다. 간단한 데이터베이스에는 테이블이 하나만 있을 수 있습니다. 대부분의 데이터베이스에는 둘 이상의 데이터베이스가 필요합니다. 예를 들어 제품에 대한 정보를 저장하는 테이블, 주문에 대한 정보를 저장하는 다른 테이블 및 고객에 대한 정보가 포함된 다른 테이블이 있을 수 있습니다.
각 행을 레코드, 각 열, 필드라고 더 정확하게 호출합니다. 레코드는 무언가에 대한 정보를 결합하는 의미 있고 일관된 방법입니다. 필드는 정보의 단일 항목으로, 모든 레코드에 표시되는 항목 유형입니다. 예를 들어 제품 테이블의 각 행이나 레코드에는 한 제품에 대한 정보가 포함됩니다. 각 열이나 필드에는 이름, 가격 등 해당 제품에 대한 일부 유형의 정보가 포함됩니다.
올바른 데이터베이스 디자인은 무엇인가요?
특정 원칙은 데이터베이스 디자인 프로세스를 안내합니다. 첫 번째 원칙은 중복 정보(중복 데이터라고도 함)가 나쁜 이유는 공간을 낭비하고 오류와 불일치의 가능성을 증가하기 때문입니다. 두 번째 원칙은 정보의 정확성과 완전성이 중요하다는 것입니다. 데이터베이스에 잘못된 정보가 포함된 경우 데이터베이스에서 정보를 가져오는 모든 보고서에는 잘못된 정보도 포함됩니다. 따라서 해당 보고서를 기반으로 하는 모든 결정은 잘못된 정보를 받게 됩니다.
따라서 좋은 데이터베이스 디자인은 다음과 같습니다.
-
중복 데이터를 줄이기 위해 정보를 주체 기반 테이블로 나눕니다.
-
필요에 따라 테이블의 정보를 함께 조인하는 데 필요한 정보를 Access에 제공합니다.
-
정보의 정확성과 무결성을 지원하고 보장하는 데 도움이 됩니다.
-
데이터 처리 및 보고 요구 사항을 수용합니다.
디자인 프로세스
디자인 프로세스는 다음 단계로 구성됩니다.
-
데이터베이스의 용도 결정
이렇게 하면 나머지 단계를 준비하는 데 도움이 됩니다.
-
필요한 정보 찾기 및 구성
데이터베이스에 기록할 수 있는 모든 유형의 정보(예: 제품 이름 및 주문 번호)를 수집합니다.
-
정보를 테이블로 나누기
정보 항목을 제품 또는 주문과 같은 주요 엔터티 또는 주체로 나눕니다. 그러면 각 주제가 테이블이 됩니다.
-
정보 항목을 열로 변환
각 테이블에 저장할 정보를 결정합니다. 각 항목은 필드가 되고 테이블에 열로 표시됩니다. 예를 들어 Employees 테이블에는 성 및 고용 날짜와 같은 필드가 포함될 수 있습니다.
-
기본 키 지정
각 테이블의 기본 키를 선택합니다. 기본 키는 각 행을 고유하게 식별하는 데 사용되는 열입니다. 제품 ID 또는 주문 ID를 예로 들면 다음과 같습니다.
-
테이블 관계 설정
각 테이블을 살펴보고 한 테이블의 데이터가 다른 테이블의 데이터와 어떻게 관련되는지 결정합니다. 필요에 따라 테이블에 필드를 추가하거나 새 테이블을 만들어 관계를 명확히 합니다.
-
디자인 구체화
디자인을 분석하여 오류를 분석합니다. 테이블을 만들고 샘플 데이터의 몇 가지 레코드를 추가합니다. 테이블에서 원하는 결과를 가져올 수 있는지 확인합니다. 필요에 따라 디자인을 조정합니다.
-
정규화 규칙 적용
데이터 정규화 규칙을 적용하여 테이블이 올바르게 구조화되었는지 확인합니다. 필요에 따라 테이블을 조정합니다.
데이터베이스의 목적 확인
데이터베이스의 목적, 사용 방법, 데이터베이스를 사용할 사용자 등 데이터베이스의 용도를 종이에 적어 두는 것이 좋습니다. 예를 들어 가정 기반 비즈니스용 소규모 데이터베이스의 경우 "고객 데이터베이스는 메일 및 보고서를 생성하기 위해 고객 정보 목록을 유지합니다."와 같은 간단한 항목을 작성할 수 있습니다. 데이터베이스가 더 복잡하거나 많은 사용자가 사용하는 경우 회사 설정에서 자주 발생하는 것처럼 용도는 단락 이상이 될 수 있으며 각 사용자가 데이터베이스를 사용하는 시기와 방법을 포함해야 합니다. 이 아이디어는 디자인 프로세스 전반에 걸쳐 참조할 수 있는 잘 개발된 임무 성명서를 갖기 위한 것입니다. 그러한 진술을 하면 결정을 내릴 때 목표에 집중하는 데 도움이 됩니다.
필요한 정보 찾기 및 구성
필요한 정보를 찾고 구성하려면 기존 정보부터 시작합니다. 예를 들어 구매 주문을 원장에 기록하거나 파일 캐비닛의 종이 양식에 고객 정보를 보관할 수 있습니다. 이러한 문서를 수집하고 표시된 각 유형의 정보를 나열합니다(예: 양식에 입력하는 각 상자). 기존 양식이 없는 경우 고객 정보를 기록하기 위해 양식을 디자인해야 한다고 가정합니다. 양식에 어떤 정보를 입력하시겠습니까? 어떤 채우기 상자를 만들겠습니까? 이러한 각 항목을 식별하고 나열합니다. 예를 들어 현재 인덱스 카드에 고객 목록을 유지한다고 가정해 보겠습니다. 이러한 카드를 검사하면 각 카드 고객 이름, 주소, 도시, 주, 우편 번호 및 전화 번호를 보유하고 있음을 알 수 있습니다. 이러한 각 항목은 테이블의 잠재적 열을 나타냅니다.
이 목록을 준비할 때 처음에는 완벽해지는 것에 대해 걱정하지 마세요. 대신 마음에 오는 각 항목을 나열합니다. 다른 사람이 데이터베이스를 사용하는 경우 자신의 아이디어도 요청합니다. 나중에 목록을 미세 조정할 수 있습니다.
다음으로, 데이터베이스에서 생성하려는 보고서 또는 메일링 유형을 고려합니다. instance 경우 제품 판매 보고서가 지역별 매출을 표시하거나 제품 재고 수준을 보여 주는 인벤토리 요약 보고서를 표시할 수 있습니다. 판매 이벤트를 알리거나 프리미엄을 제공하는 고객에게 보낼 양식 편지를 생성할 수도 있습니다. 마음에 보고서를 디자인하고 어떻게 생겼는지 상상해 보세요. 보고서에 어떤 정보를 배치하시겠습니까? 각 항목을 나열합니다. 양식 편지 및 만들 것으로 예상되는 다른 보고서에 대해 동일한 작업을 수행합니다.
만들려는 보고서 및 메일에 대한 생각을 제공하면 데이터베이스에 필요한 항목을 식별하는 데 도움이 됩니다. 예를 들어 고객에게 정기적인 전자 메일 업데이트를 옵트인(또는 옵트아웃)할 수 있는 기회를 제공하고 옵트인한 사람들의 목록을 인쇄하려고 합니다. 해당 정보를 기록하려면 고객 테이블에 "전자 메일 보내기" 열을 추가합니다. 각 고객에 대해 필드를 예 또는 아니요로 설정할 수 있습니다.
고객에게 전자 메일 메시지를 보내는 요구 사항은 기록할 다른 항목을 제안합니다. 고객이 전자 메일 메시지를 받기를 원한다는 것을 알게 되면 전자 메일 메시지를 보낼 전자 메일 주소도 알아야 합니다. 따라서 각 고객의 전자 메일 주소를 기록해야 합니다.
각 보고서 또는 출력 목록의 프로토타입을 생성하고 보고서를 생성하는 데 필요한 항목을 고려하는 것이 좋습니다. instance 경우 양식 편지를 검사할 때 몇 가지 사항이 떠오를 수 있습니다. 인사말을 시작하는 "Mr.", "Mrs." 또는 "Ms." 문자열과 같이 적절한 인사말을 포함하려면 인사말 항목을 만들어야 합니다. 또한 일반적으로 "Dear Mr. Smith"가 아닌 "Dear Mr. Smith"로 편지를 시작할 수 있습니다. 실베스터 스미스 씨"라고 말했습니다. 이는 일반적으로 성을 이름과 별도로 저장하려는 것일 수 있습니다.
기억해야 할 핵심은 각 정보를 가장 작은 유용한 부분으로 분할해야 한다는 것입니다. 이름의 경우 성을 쉽게 사용할 수 있도록 이름을 이름 및 성의 두 부분으로 구분합니다. 예를 들어 성을 기준으로 보고서를 정렬하려면 고객의 성을 별도로 저장하는 것이 도움이 됩니다. 일반적으로 정보 항목을 기준으로 정렬, 검색, 계산 또는 보고하려면 해당 항목을 자체 필드에 배치해야 합니다.
데이터베이스에서 답변할 수 있는 질문에 대해 생각해 보세요. instance 지난 달에 닫은 추천 제품의 판매량은 몇 개입니까? 최고의 고객은 어디에 거주합니까? 베스트셀러 제품의 공급업체는 누구인가요? 이러한 질문을 예상하면 기록할 추가 항목을 0으로 설정할 수 있습니다.
이 정보를 수집한 후에는 다음 단계를 수행할 준비가 됩니다.
정보를 테이블로 나누기
정보를 테이블로 나누려면 주 엔터티 또는 주체를 선택합니다. 예를 들어 제품 판매 데이터베이스에 대한 정보를 찾고 구성한 후에는 예비 목록이 다음과 같이 표시될 수 있습니다.
여기에 표시된 주요 엔터티는 제품, 공급업체, 고객 및 주문입니다. 따라서 제품에 대한 팩트, 공급업체에 대한 팩트, 고객에 대한 팩트, 주문에 대한 팩트 등 네 개의 테이블로 시작하는 것이 좋습니다. 목록을 완료하지는 않지만 좋은 시작점입니다. 잘 작동하는 디자인이 있을 때까지 이 목록을 계속 구체화할 수 있습니다.
항목의 예비 목록을 처음 검토할 때 앞의 그림에 표시된 4개 대신 모든 항목을 단일 테이블에 배치하려는 유혹이 있을 수 있습니다. 왜 그것이 나쁜 생각인지 여기에서 배우게 될 것입니다. 잠시 생각해 보십시오. 표는 다음과 같습니다.
이 경우 각 행에는 제품 및 해당 공급자에 대한 정보가 모두 포함됩니다. 동일한 공급업체의 많은 제품을 사용할 수 있으므로 공급업체 이름과 주소 정보를 여러 번 반복해야 합니다. 이 경우 디스크 공간이 낭비됩니다. 공급자 정보를 별도의 Suppliers 테이블에 한 번만 기록한 다음 해당 테이블을 Products 테이블에 연결하는 것이 훨씬 더 나은 솔루션입니다.
이 디자인의 두 번째 문제는 공급자에 대한 정보를 수정해야 할 때 발생합니다. 예를 들어 공급자의 주소를 변경해야 한다고 가정합니다. 주소는 여러 위치에 나타나므로 실수로 한 곳에서만 주소를 변경하고 다른 곳에서는 변경하지 않을 수 있습니다. 한 곳에서만 공급자의 주소를 기록하면 문제가 해결됩니다.
데이터베이스를 디자인할 때는 항상 각 사실을 한 번만 기록해 보세요. 특정 공급자의 주소와 같이 둘 이상의 위치에서 동일한 정보를 반복하는 경우 해당 정보를 별도의 테이블에 배치합니다.
마지막으로, Coho Winery에서 제공하는 제품이 하나만 있다고 가정하고 제품을 삭제하고 공급자 이름과 주소 정보를 유지하려고 합니다. 공급업체 정보를 잃지 않고 제품 레코드를 삭제하려면 어떻게 할까요? 불가능합니다. 각 레코드에는 제품에 대한 팩트 및 공급업체에 대한 팩트를 포함하므로 다른 레코드를 삭제하지 않고는 삭제할 수 없습니다. 이러한 사실을 별도로 유지하려면 한 테이블을 제품 정보에 대한 테이블과 공급업체 정보에 대한 테이블의 두 테이블로 분할해야 합니다. 제품 레코드를 삭제하는 것은 공급업체에 대한 사실이 아니라 제품에 대한 사실만 삭제해야 합니다.
테이블로 표현되는 주제를 선택한 후에는 해당 테이블의 열에 주제에 대한 팩트만 저장해야 합니다. instance 경우 제품 테이블은 제품에 대한 팩트만 저장해야 합니다. 공급 업체 주소는 공급 업체에 대한 사실이지 제품에 대한 사실이 아니기 때문에 공급 업체 테이블에 속합니다.
정보 항목을 열로 변환
테이블의 열을 확인하려면 테이블에 기록된 주제에 대해 추적해야 하는 정보를 결정합니다. 예를 들어 Customers 테이블의 경우 이름, 주소, City-State-Zip, 전자 메일 보내기, 인사말 및 전자 메일 주소는 열의 좋은 시작 목록으로 구성됩니다. 테이블의 각 레코드에는 동일한 열 집합이 포함되어 있으므로 각 레코드에 대한 이름, 주소, City-State-Zip, 전자 메일 보내기, 인사말 및 전자 메일 주소 정보를 저장할 수 있습니다. 예를 들어 주소 열에는 고객의 주소가 포함됩니다. 각 레코드에는 한 고객에 대한 데이터가 포함되며 주소 필드에는 해당 고객의 주소가 포함됩니다.
각 테이블에 대한 초기 열 집합을 결정했으면 열을 더 구체화할 수 있습니다. 예를 들어 고객 이름을 이름 및 성이라는 두 개의 개별 열로 저장하여 해당 열에서만 정렬, 검색 및 인덱싱할 수 있습니다. 마찬가지로 주소는 실제로 5개의 개별 구성 요소, 주소, 도시, 주, 우편 번호 및 국가/지역으로 구성되며 별도의 열에 저장하는 것도 합리적입니다. 예를 들어 상태별로 검색, 필터링 또는 정렬 작업을 수행하려면 별도의 열에 저장된 상태 정보가 필요합니다.
또한 데이터베이스에 국내 출처의 정보만 보유할지, 아니면 국제 정보도 보유할지 고려해야 합니다. instance 경우 국제 주소를 저장하려는 경우 해당 열이 국내 주와 다른 국가/지역의 지역을 모두 수용할 수 있으므로 국가 대신 지역 열을 사용하는 것이 좋습니다. 마찬가지로 우편 번호는 국제 주소를 저장하려는 경우 우편 번호보다 더 합리적입니다.
다음 목록에서는 열을 결정하기 위한 몇 가지 팁을 보여 줍니다.
-
계산된 데이터를 포함하지 않음
대부분의 경우 계산 결과를 테이블에 저장해서는 안 됩니다. 대신 결과를 확인하려는 경우 Access에서 계산을 수행하도록 할 수 있습니다. 예를 들어 데이터베이스의 각 제품 범주에 대한 순서에 따라 단위의 부분합을 표시하는 Products On Order 보고서가 있다고 가정해 보겠습니다. 그러나 테이블에는 주문 시 단위 부분합 열이 없습니다. 대신 Products 테이블에는 각 제품에 대한 주문 단위를 저장하는 주문 단위 열이 포함되어 있습니다. Access는 해당 데이터를 사용하여 보고서를 인쇄할 때마다 부분합을 계산합니다. 부분합 자체는 테이블에 저장해서는 안 됩니다.
-
가장 작은 논리 파트에 정보 저장
전체 이름 또는 제품 설명과 함께 제품 이름에 대한 단일 필드가 있는 것이 좋을 수 있습니다. 필드에 여러 종류의 정보를 결합하면 나중에 개별 사실을 검색하기가 어렵습니다. 정보를 논리적 부분으로 분해해 보세요. 예를 들어 이름과 성 또는 제품 이름, 범주 및 설명에 대해 별도의 필드를 만듭니다.
각 테이블의 데이터 열을 구체화하면 각 테이블의 기본 키를 선택할 준비가 된 것입니다.
기본 키 지정
각 테이블에는 테이블에 저장된 각 행을 고유하게 식별하는 열 또는 열 집합이 포함되어야 합니다. 직원 ID 번호 또는 일련 번호와 같은 고유 ID 번호인 경우가 많습니다. 데이터베이스 용어에서 이 정보를 테이블의 기본 키 라고 합니다. Access는 기본 키 필드를 사용하여 여러 테이블의 데이터를 신속하게 연결하고 데이터를 함께 가져옵니다.
카탈로그의 각 제품을 고유하게 식별하는 제품 번호와 같은 테이블에 대한 고유 식별자가 이미 있는 경우 해당 식별자를 테이블의 기본 키로 사용할 수 있지만 이 열의 값이 각 레코드에 대해 항상 다른 경우에만 사용할 수 있습니다. 기본 키에는 중복 값이 있을 수 없습니다. 예를 들어 이름은 고유하지 않으므로 사용자의 이름을 기본 키로 사용하지 마세요. 같은 테이블에 같은 이름을 가진 두 사람이 쉽게 있을 수 있습니다.
기본 키에는 항상 값이 있어야 합니다. 열 값이 할당되지 않거나 알 수 없는(누락된 값)될 수 있는 경우 기본 키의 구성 요소로 사용할 수 없습니다.
항상 값이 변경되지 않는 기본 키를 선택해야 합니다. 둘 이상의 테이블을 사용하는 데이터베이스에서 테이블의 기본 키를 다른 테이블에서 참조로 사용할 수 있습니다. 기본 키가 변경되는 경우 키가 참조되는 모든 곳에서 변경 내용도 적용해야 합니다. 변경되지 않는 기본 키를 사용하면 기본 키가 이를 참조하는 다른 테이블과 동기화되지 않을 가능성이 줄어듭니다.
종종 임의의 고유 번호가 기본 키로 사용됩니다. 예를 들어 각 주문에 고유한 주문 번호를 할당할 수 있습니다. 주문 번호의 유일한 목적은 주문을 식별하는 것입니다. 할당된 후에는 변경되지 않습니다.
올바른 기본 키를 만들 수 있는 열 또는 열 집합을 염두에 두지 않는 경우 AutoNumber 데이터 형식이 있는 열을 사용하는 것이 좋습니다. AutoNumber 데이터 형식을 사용하면 Access에서 자동으로 값을 할당합니다. 이러한 식별자는 사실상 없습니다. 나타내는 행을 설명하는 팩트 정보가 포함되지 않습니다. 팩트리스 식별자는 변경되지 않으므로 기본 키로 사용하기에 적합합니다. 행에 대한 팩트(예: 전화 번호 또는 고객 이름)를 포함하는 기본 키는 사실 정보 자체가 변경될 수 있으므로 변경될 가능성이 높습니다.
1. AutoNumber 데이터 형식으로 설정된 열은 종종 좋은 기본 키를 만듭니다. 두 제품 ID가 동일하지 않습니다.
경우에 따라 테이블의 기본 키를 함께 제공하는 두 개 이상의 필드를 사용할 수 있습니다. 예를 들어 주문에 대한 품목을 저장하는 주문 세부 정보 테이블은 기본 키인 주문 ID 및 제품 ID에 두 개의 열을 사용합니다. 기본 키가 둘 이상의 열을 사용하는 경우 복합 키라고도 합니다.
제품 판매 데이터베이스의 경우 각 테이블에 대한 AutoNumber 열을 기본 키로 사용할 수 있습니다. Products 테이블의 경우 ProductID, Orders 테이블의 OrderID, Customers 테이블의 CustomerID 및 Suppliers 테이블의 SupplierID입니다.
테이블 관계 만들기
이제 정보를 테이블로 분할했으므로 의미 있는 방식으로 정보를 다시 모을 수 있는 방법이 필요합니다. 예를 들어 다음 양식에는 여러 테이블의 정보가 포함됩니다.
1. 이 폼의 정보를 가져오는 위치는 고객 테이블...
2. ... Employees 테이블...
3. ... Orders 테이블...
4. ... Products 테이블...
5. ... 및 주문 세부 정보 테이블.
액세스는 관계형 데이터베이스 관리 시스템입니다. 관계형 데이터베이스에서 정보를 별도의 주체 기반 테이블로 나눕니다. 그런 다음 테이블 관계를 사용하여 필요에 따라 정보를 함께 가져옵니다.
일대다 관계 만들기
제품 주문 데이터베이스의 공급자 및 제품 테이블 예제를 고려합니다. 공급자는 모든 수의 제품을 제공할 수 있습니다. 다음은 Suppliers 테이블에 표시되는 공급업체의 경우 Products 테이블에 표시되는 많은 제품이 있을 수 있습니다. 따라서 Suppliers 테이블과 Products 테이블 간의 관계는 일대다 관계입니다.
데이터베이스 디자인에서 일대다 관계를 나타내려면 관계의 "일" 쪽에서 기본 키를 가져와 관계의 "다" 쪽 테이블에 추가 열 또는 열로 추가합니다. 예를 들어 이 경우 Suppliers 테이블의 Supplier ID 열을 Products 테이블에 추가합니다. 그런 다음, Access는 Products 테이블의 공급업체 ID 번호를 사용하여 각 제품에 대한 올바른 공급자를 찾을 수 있습니다.
Products 테이블의 Supplier ID 열을 외래 키라고 합니다. 외래 키는 다른 테이블의 기본 키입니다. Products 테이블의 Supplier ID 열은 Suppliers 테이블의 기본 키이기도 하므로 외래 키입니다.
기본 키와 외신 키의 페어링을 설정하여 관련 테이블을 조인하기 위한 기초를 제공합니다. 공통 열을 공유해야 하는 테이블을 잘 모르는 경우 일대다 관계를 식별하면 관련된 두 테이블에 실제로 공유 열이 필요합니다.
다대다 관계 만들기
Products 테이블과 Orders 테이블 간의 관계를 고려합니다.
단일 주문은 두 개 이상의 제품을 포함할 수 있습니다. 반면, 단일 제품은 여러 주문에 나타날 수 있습니다. 따라서 주문 테이블의 각 레코드에 대해 제품 테이블에는 많은 레코드가 존재할 수 있습니다. 또한 Products 테이블의 각 레코드에 대해 Orders 테이블에 많은 레코드가 있을 수 있습니다. 이러한 유형의 관계를 다 대 다 관계라고 하는 이유는 제품의 경우 주문이 많을 수 있기 때문입니다. 모든 주문에 대해 많은 제품이 있을 수 있습니다. 테이블 간의 다 대 다 관계를 검색하려면 관계의 양쪽을 고려하는 것이 중요합니다.
주문과 제품이라는 두 테이블의 주체는 다대다 관계를 맺습니다. 이 경우 문제가 발생합니다. 문제를 이해하려면 제품 ID 필드를 Orders 테이블에 추가하여 두 테이블 간의 관계를 만들려고 하면 어떤 일이 발생할지 상상해 보십시오. 주문당 둘 이상의 제품을 사용하려면 주문당 Orders 테이블에 둘 이상의 레코드가 필요합니다. 단일 순서와 관련된 각 행에 대해 주문 정보를 반복하면 데이터가 부정확해질 수 있는 비효율적인 디자인이 발생합니다. Products 테이블에 주문 ID 필드를 배치하면 동일한 문제가 발생합니다. 각 제품에 대한 Products 테이블에 레코드가 두 개 이상 있습니다. 이 문제를 해결하려면 어떻게 해야 할까요?
대답은 다대다 관계를 두 개의 일대다 관계로 나누는 접합 테이블이라고도 하는 세 번째 테이블을 만드는 것입니다. 그런 다음 다대다 관계를 형성하는 두 테이블의 기본 키를 이 세 번째 테이블에 삽입합니다. 따라서 세 번째 테이블은 관계의 각 발생 또는 instance 기록합니다.
Order Details 테이블의 각 레코드는 주문의 한 줄 항목을 나타냅니다. 주문 세부 정보 테이블의 기본 키는 Orders 및 Products 테이블의 외래 키라는 두 개의 필드로 구성됩니다. 주문 ID 필드만 사용하면 한 주문에 많은 품목이 있을 수 있으므로 이 테이블의 기본 키로 작동하지 않습니다. 주문 ID는 주문의 각 품목에 대해 반복되므로 필드에 고유한 값이 포함되지 않습니다. 하나의 제품이 여러 주문에 표시할 수 있으므로 제품 ID 필드만 사용하면 작동하지 않습니다. 그러나 두 필드는 항상 각 레코드에 대해 고유한 값을 생성합니다.
제품 판매 데이터베이스에서 Orders 테이블과 Products 테이블은 서로 직접 관련이 없습니다. 대신 Order Details 테이블을 통해 간접적으로 관련됩니다. 주문과 제품 간의 다대다 관계는 두 개의 일대다 관계를 사용하여 데이터베이스에 표시됩니다.
-
Orders 테이블과 Order Details 테이블에는 일대다 관계가 있습니다. 각 주문에는 둘 이상의 품목이 있을 수 있지만 각 품목은 하나의 주문에만 연결됩니다.
-
Products 테이블 및 주문 세부 정보 테이블에는 일대다 관계가 있습니다. 각 제품에는 여러 품목이 연결되어 있을 수 있지만 각 품목은 하나의 제품만을 참조합니다.
주문 세부 정보 테이블에서 특정 주문의 모든 제품을 확인할 수 있습니다. 특정 제품에 대한 모든 주문을 확인할 수도 있습니다.
Order Details 테이블을 통합한 후 테이블 및 필드 목록은 다음과 같이 표시될 수 있습니다.
일대일 관계 만들기
또 다른 유형의 관계는 일대일 관계입니다. instance 경우 드물게 필요하거나 몇 가지 제품에만 적용되는 몇 가지 특별한 추가 제품 정보를 기록해야 한다고 가정합니다. 정보가 자주 필요하지 않으며 Products 테이블에 정보를 저장하면 적용되지 않는 모든 제품에 대한 빈 공간이 발생하므로 별도의 테이블에 배치합니다. Products 테이블과 마찬가지로 ProductID를 기본 키로 사용합니다. 이 추가 테이블과 Product 테이블 간의 관계는 일대일 관계입니다. Product 테이블의 각 레코드에 대해 보조 테이블에 일치하는 단일 레코드가 있습니다. 이러한 관계를 식별할 때 두 테이블은 공통 필드를 공유하고 있어야 합니다.
데이터베이스에서 일대일 관계의 필요성이 감지되면 두 테이블의 정보를 한 테이블에 함께 넣을 수 있는지 여부를 고려합니다. 어떤 이유로 이 작업을 수행하지 않으려는 경우 빈 공간이 많을 수 있으므로 다음 목록에서는 디자인에서 관계를 나타내는 방법을 보여 줍니다.
-
두 테이블에 동일한 제목이 있는 경우 두 테이블에서 동일한 기본 키를 사용하여 관계를 설정할 수 있습니다.
-
두 테이블에 서로 다른 기본 키가 있는 다른 주체가 있는 경우 테이블 중 하나(둘 중 하나)를 선택하고 다른 테이블에 기본 키를 외래 키로 삽입합니다.
테이블 간의 관계를 확인하면 올바른 테이블과 열이 있는지 확인할 수 있습니다. 일 대 일 또는 일 대 다 관계가 있는 경우 관련된 테이블은 공통 열 또는 열을 공유해야 합니다. 다 대 다 관계가 있는 경우 관계를 나타내려면 세 번째 테이블이 필요합니다.
디자인 구체화
필요한 테이블, 필드 및 관계가 있으면 테이블을 만들고 샘플 데이터로 채우고 쿼리 만들기, 새 레코드 추가 등의 정보를 사용해 보아야 합니다. 이렇게 하면 잠재적인 문제를 강조 표시할 수 있습니다. 예를 들어 디자인 단계에서 삽입하지 않은 열을 추가해야 하거나 중복을 제거하기 위해 두 테이블로 분할해야 하는 테이블이 있을 수 있습니다.
데이터베이스를 사용하여 원하는 답변을 얻을 수 있는지 확인합니다. 양식 및 보고서의 대략적인 초안을 만들고 예상되는 데이터가 표시되는지 확인합니다. 불필요한 데이터 중복을 찾고, 데이터가 발견되면 디자인을 변경하여 제거합니다.
초기 데이터베이스를 사용해 볼 때 개선의 여지가 있을 것입니다. 다음은 검사 몇 가지 사항입니다.
-
열을 잊어 버렸나요? 그렇다면 정보가 기존 테이블에 속하나요? 다른 항목에 대한 정보인 경우 다른 테이블을 만들어야 할 수 있습니다. 추적해야 하는 모든 정보 항목에 대한 열을 만듭니다. 정보를 다른 열에서 계산할 수 없는 경우 새 열이 필요할 수 있습니다.
-
기존 필드에서 계산할 수 있으므로 열이 필요하지 않은가요? 정보 항목을 다른 기존 열(예: 소매 가격에서 계산된 할인 가격)에서 계산할 수 있는 경우 일반적으로 이 작업을 수행하고 새 열을 만들지 않는 것이 좋습니다.
-
테이블 중 하나에 중복 정보를 반복적으로 입력하고 있나요? 그렇다면 테이블을 일대다 관계가 있는 두 테이블로 나누어야 할 수 있습니다.
-
개별 레코드에 많은 필드, 제한된 수의 레코드 및 많은 빈 필드가 있는 테이블이 있나요? 그렇다면 필드가 적고 레코드가 더 많도록 테이블을 다시 디자인하는 것을 생각해 보세요.
-
각 정보 항목이 가장 작은 유용한 부분으로 나뉘어져 있나요? 정보 항목을 보고, 정렬, 검색 또는 계산해야 하는 경우 해당 항목을 자체 열에 넣습니다.
-
각 열에 테이블 제목에 대한 팩트가 포함되어 있나요? 열에 테이블의 제목에 대한 정보가 포함되어 있지 않으면 다른 테이블에 속합니다.
-
테이블 간의 모든 관계가 공통 필드 또는 세 번째 테이블로 표현되는가? 일대일 및 일대다 관계에는 공통 열이 필요합니다. 다대다 관계에는 세 번째 테이블이 필요합니다.
Products 테이블 구체화
제품 판매 데이터베이스의 각 제품이 음료, 양념 또는 해산물과 같은 일반 범주에 속한다고 가정합니다. Products 테이블에는 각 제품의 범주를 보여 주는 필드가 포함될 수 있습니다.
데이터베이스 디자인을 검사하고 구체화한 후 해당 이름과 함께 범주에 대한 설명을 저장하기로 결정한다고 가정해 보겠습니다. Products 테이블에 범주 설명 필드를 추가하는 경우 범주에 속하는 각 제품에 대해 각 범주 설명을 반복해야 합니다. 이는 좋은 솔루션이 아닙니다.
더 나은 해결 방법은 고유한 테이블과 자체 기본 키를 사용하여 데이터베이스가 추적할 수 있는 새로운 주체로 범주를 만드는 것입니다. 그런 다음 Categories 테이블의 기본 키를 외래 키로 Products 테이블에 추가할 수 있습니다.
범주 및 제품 테이블에는 일대다 관계가 있습니다. 범주에는 둘 이상의 제품이 포함될 수 있지만 제품은 하나의 범주에만 속할 수 있습니다.
테이블 구조를 검토할 때 반복 그룹에 대한 경계를 찾습니다. 예를 들어 다음 열이 포함된 테이블을 고려해 보세요.
-
제품 ID
-
Name(이름)
-
제품 ID1
-
Name1
-
제품 ID2
-
Name2
-
제품 ID3
-
Name3
여기서 각 제품은 열 이름의 끝에 숫자를 추가하여 다른 열과 다른 열의 반복 그룹입니다. 이러한 방식으로 번호가 매겨진 열이 표시되면 디자인을 다시 방문해야 합니다.
이러한 디자인에는 몇 가지 결함이 있습니다. 우선 제품 수에 상한을 적용해야 합니다. 해당 제한을 초과하는 즉시 테이블 구조에 새 열 그룹을 추가해야 합니다. 이는 주요 관리 작업입니다.
또 다른 문제는 추가 열이 비어 있기 때문에 최대 제품 수보다 적은 공급 업체가 약간의 공간을 낭비한다는 것입니다. 이러한 디자인의 가장 심각한 결함은 제품 ID 또는 이름으로 테이블을 정렬하거나 인덱싱하는 등 많은 작업을 수행하기 어렵게 만든다는 것입니다.
반복 그룹이 표시되면 테이블을 두 개로 분할하는 것을 주시하여 디자인을 면밀히 검토합니다. 위의 예제에서는 두 개의 테이블을 사용하는 것이 좋습니다. 하나는 공급자용이고 다른 하나는 공급업체 ID로 연결된 제품용입니다.
정규화 규칙 적용
데이터 정규화 규칙(정규화 규칙이라고도 함)을 디자인의 다음 단계로 적용할 수 있습니다. 이러한 규칙을 사용하여 테이블이 올바르게 구조화되었는지 확인합니다. 데이터베이스 디자인에 규칙을 적용하는 프로세스를 데이터베이스 정규화 또는 정규화라고 합니다.
정규화는 모든 정보 항목을 나타내고 예비 설계에 도착한 후에 가장 유용합니다. 이 아이디어는 정보 항목을 적절한 테이블로 나누는 데 도움이 되는 것입니다. 정규화에서 수행할 수 없는 작업은 시작할 모든 올바른 데이터 항목이 있는지 확인하는 것입니다.
각 단계에서 규칙을 연속적으로 적용하여 디자인이 "일반 양식" 중 하나에 도달하도록 합니다. 5개의 일반 양식이 널리 허용됩니다. 즉, 다섯 번째 정규 형식을 통한 첫 번째 정규 형식입니다. 이 문서는 대부분의 데이터베이스 디자인에 필요한 모든 항목이므로 처음 3개에 대해 확장됩니다.
첫 번째 정규 형식
첫 번째 일반 양식은 테이블의 모든 행과 열 교집합에서 단일 값이 존재하며 값 목록이 없음을 나타냅니다. 예를 들어 둘 이상의 가격을 배치하는 Price라는 필드가 있을 수 없습니다. 행과 열의 각 교집합을 셀로 생각하면 각 셀은 하나의 값만 보유할 수 있습니다.
두 번째 정규 형식
두 번째 일반 형식을 사용하려면 키가 아닌 각 열이 키의 일부가 아니라 전체 기본 키에 완전히 의존해야 합니다. 이 규칙은 둘 이상의 열로 구성된 기본 키가 있는 경우에 적용됩니다. 예를 들어 주문 ID 및 제품 ID가 기본 키를 형성하는 다음 열이 포함된 테이블이 있다고 가정합니다.
-
주문 ID(기본 키)
-
제품 ID(기본 키)
-
제품 이름
제품 이름은 제품 ID에 따라 달라지지만 주문 ID에는 의존하지 않으므로 전체 기본 키에 종속되지 않으므로 이 디자인은 두 번째 일반 형식을 위반합니다. 테이블에서 제품 이름을 제거해야 합니다. 다른 테이블(제품)에 속합니다.
세 번째 정규 형식
세 번째 일반 형식을 사용하려면 키가 아닌 모든 열이 전체 기본 키에 종속될 뿐만 아니라 키가 아닌 열은 서로 독립적이어야 합니다.
이를 말하는 또 다른 방법은 키가 아닌 각 열이 기본 키와 기본 키에만 의존해야 한다는 것입니다. 예를 들어 다음 열이 포함된 테이블이 있다고 가정합니다.
-
ProductID(기본 키)
-
이름
-
SRP
-
discount
할인은 제안된 SRP(소매 가격)에 따라 달라지는 것으로 가정합니다. 이 테이블은 키가 아닌 열인 Discount이 키가 아닌 다른 열인 SRP에 따라 달라지므로 세 번째 일반 형식을 위반합니다. 열 독립성 은 다른 열에 영향을 주지 않고 키가 아닌 열을 변경할 수 있어야 임을 의미합니다. SRP 필드에서 값을 변경하면 할인이 그에 따라 변경되므로 해당 규칙을 위반합니다. 이 경우 SRP에 키가 지정된 다른 테이블로 할인을 이동해야 합니다.
