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