데이터베이스 디자인의 기초

제대로 디자인된 데이터베이스는 최신의 정확한 정보에 대한 액세스를 제공합니다. 데이터베이스 작업에서 목표를 달성하기 위해 올바른 디자인이 필수적이기 때문에 좋은 디자인 원칙을 배우는 데 필요한 시간을 투자하는 것이 좋습니다. 결국, 요구 사항을 충족하고 변경을 쉽게 수용할 수 있는 데이터베이스로 끝날 가능성이 훨씬 더 많을 것입니다.

이 문서에서는 데스크톱 데이터베이스를 계획하기 위한 지침을 제공합니다. 필요한 정보, 해당 정보를 적절한 테이블 및 열로 나누는 방법 및 해당 테이블이 서로 관련되는 방법을 결정하는 방법을 배워야 합니다. 첫 번째 데스크톱 데이터베이스를 만들기 전에 이 문서를 읽어야 합니다.

중요:  Access 데이터베이스 애플리케이션을 만들 수 있는 디자인 환경을 제공합니다. 웹을 디자인할 때 많은 디자인 고려 사항이 다릅니다. 이 문서에서는 웹 데이터베이스 애플리케이션 디자인에 대해 설명하지 않습니다. 자세한 내용은 웹에서 공유할 데이터베이스 빌드 문서를 참조하세요.

이 문서의 내용


알아야 할 일부 데이터베이스 용어

Access 테이블로 정보를 구성합니다.회계사 패드 또는 스프레드시트를 연상하는 행 및 열 목록입니다. 간단한 데이터베이스에는 테이블이 하나만 있을 수 있습니다. 대부분의 데이터베이스의 경우 두 개 이상의 데이터베이스가 필요합니다. 예를 들어 제품에 대한 정보를 저장하는 테이블, 주문에 대한 정보를 저장하는 다른 테이블 및 고객에 대한 정보가 있는 다른 테이블이 있을 수 있습니다.

세 테이블을 데이터시트로 보여 주는 이미지

각 행을 레코드 각 열, 필드라고 합니다. 레코드는 무언가에 대한 정보를 결합하는 의미 있고 일관된 방법입니다. 필드는 정보의 단일 항목입니다. 모든 레코드에 나타나는 항목 유형입니다. 예를 들어 제품 테이블의 각 행이나 레코드에는 한 제품에 대한 정보가 포함됩니다. 각 열이나 필드에는 이름, 가격 등 해당 제품에 대한 일부 유형의 정보가 포함됩니다.

맨 위로 이동

올바른 데이터베이스 디자인은 무엇인가요?

특정 원칙은 데이터베이스 디자인 프로세스를 안내합니다. 첫 번째 원칙은 중복 정보(중복 데이터라고도 하는)가 잘못되어 공간을 낭비하고 오류 및 불일치의 가능성을 증가하기 때문에 잘못된 것입니다. 두 번째 원칙은 정보의 정확성 및 완전성도 중요합니다. 데이터베이스에 잘못된 정보가 포함되어 있는 경우 데이터베이스에서 정보를 끌어오는 보고서에도 잘못된 정보가 포함되어 있습니다. 결과적으로 해당 보고서를 기반으로 하는 모든 의사 결정은 잘못된 것으로 오인됩니다.

따라서 좋은 데이터베이스 디자인은 다음을 사용합니다.

  • 정보를 주체 기반 테이블로 분할하여 중복 데이터를 줄입니다.

  • 필요한 경우 테이블의 정보를 함께 조인하는 데 필요한 정보를 Access에 제공합니다.

  • 정보의 정확성과 무결성을 지원하고 보장하는 데 도움이 됩니다.

  • 데이터 처리 및 보고 요구 사항을 수용합니다.

맨 위로 이동

디자인 프로세스

디자인 프로세스는 다음 단계로 구성됩니다.

  • 데이터베이스의 용도 결정    

    이렇게 하면 나머지 단계를 준비하는 데 도움이 됩니다.

  • 필요한 정보 찾기 및 구성     

    데이터베이스에서 기록할 모든 유형의 정보(예: 제품 이름 및 주문 번호)를 수집합니다.

  • 정보를 테이블로 나누기    

    정보 항목을 주요 엔터티 또는 주체(예: 제품 또는 주문)로 분할합니다. 그런 다음 각 주체가 표가 됩니다.

  • 정보 항목을 열로 전환    

    각 테이블에 저장할 정보를 결정합니다. 각 항목은 필드가 되고 표의 열로 표시됩니다. 예를 들어 Employees 테이블에 성 및 고용 날짜와 같은 필드가 포함되어 있을 수 있습니다.

  • 기본 키 지정    

    각 테이블의 기본 키를 선택합니다. 기본 키는 각 행을 고유하게 식별하는 데 사용되는 열입니다. 예제는 제품 ID 또는 주문 ID일 수 있습니다.

  • 테이블 관계 설정    

    각 테이블을 살펴보고 한 테이블의 데이터가 다른 테이블의 데이터와 어떻게 관련이 있는지 결정합니다. 필요한 경우 테이블에 필드를 추가하거나 새 테이블을 만들어 관계를 명확히 합니다.

  • 디자인 구체화    

    디자인을 오류로 분석합니다. 테이블을 만들고 샘플 데이터의 몇 가지 레코드를 추가합니다. 테이블에서 원하는 결과를 얻을 수 있는지 를 참조합니다. 필요한 경우 디자인을 조정합니다.

  • 정규화 규칙 적용    

    테이블이 올바르게 구성되는지 확인하려면 데이터 정규화 규칙을 적용합니다. 필요한 경우 테이블을 조정합니다.

맨 위로 이동

데이터베이스의 목적 결정

데이터베이스의 목적, 용도, 사용 방법, 누가 사용할지 등 데이터베이스의 용도를 적어 두는 것이 좋습니다. 가정 기반 비즈니스용 작은 데이터베이스의 경우 예를 들어 "고객 데이터베이스는 메일 및 보고서를 생성하기 위해 고객 정보 목록을 보관합니다." 같은 간단한 정보를 작성할 수 있습니다. 데이터베이스가 더 복잡하거나 많은 사용자가 사용하는 경우 회사 설정에서 자주 발생하는 경우 목적이 단락 이상일 수 있으며 각 사용자가 데이터베이스를 사용할 때와 방법을 포함해야 합니다. 아이디어는 디자인 프로세스 전반에 걸쳐 참조할 수 있는 잘 개발된 사명을 가지는 것입니다. 이러한 문을 사용하면 결정을 내릴 때 목표에 집중할 수 있습니다.

맨 위로 이동

필요한 정보 찾기 및 구성

필요한 정보를 찾고 구성하려면 기존 정보로 시작하세요. 예를 들어 원장에 구매 주문을 기록하거나 파일 캐비닛에 종이 양식에 고객 정보를 보관할 수 있습니다. 이러한 문서를 수집하고 표시된 각 유형의 정보(예: 양식에 입력한 각 상자)를 나열합니다. 기존 폼이 없는 경우 고객 정보를 기록하기 위해 폼을 디자인해야 한다고 생각하세요. 양식에 어떤 정보를 넣을까요? 어떤 채우기 상자를 만들까요? 이러한 각 항목을 식별하고 나열합니다. 예를 들어 현재 인덱스 카드에 고객 목록을 유지했다고 가정합니다. 이러한 카드를 검사하면 각 카드에 고객 이름, 주소, 도시, 주, 우편 번호 및 전화 번호가 들어 있는 것으로 표시될 수 있습니다. 이러한 각 항목은 테이블의 잠재적 열을 나타내고 있습니다.

이 목록을 준비할 때 처음에는 완벽해지기 걱정하지 마세요. 대신, 마음에 품는 각 항목을 나열합니다. 다른 사용자가 데이터베이스를 사용할 경우 아이디어를 요청합니다. 나중에 목록을 미세 조정할 수 있습니다.

다음으로 데이터베이스에서 생성하려는 보고서 또는 메일 유형을 고려합니다. 예를 들어 제품 판매 보고서가 지역별로 판매를 표시하거나 제품 재고 수준을 표시하는 인벤토리 요약 보고서를 표시해야 할 수 있습니다. 또한 판매 이벤트를 발표하거나 프리미엄을 제공하는 고객에게 보낼 양식 편지를 생성할 수도 있습니다. 보고서를 마음으로 디자인하고 어떻게 될지 상상해 봐야 합니다. 보고서에 어떤 정보를 제공하나요? 각 항목을 나열합니다. 양식 문자와 만들 예상되는 다른 보고서에 대해 동일한 작업을 합니다.

제품 재고 보고서를 구상하고 있는 사람

만들 수 있는 보고서 및 메일에 대해 생각하면 데이터베이스에 필요한 항목을 식별하는 데 도움이 됩니다. 예를 들어 고객에게 주기적인 전자 메일 업데이트를 옵트인(또는 옵트아웃)할 수 있는 기회를 제공하고 옵트인한 사용자 목록을 인쇄하려는 경우를 가정해 보겠습니다. 해당 정보를 기록하기 위해 고객 테이블에 "전자 메일 보내기" 열을 추가합니다. 각 고객에 대해 필드를 예 또는 아니요로 설정할 수 있습니다.

고객에게 전자 메일 메시지를 보내야 하는 요구 사항은 기록할 다른 항목을 제안합니다. 고객이 전자 메일 메시지를 수신하려는 것을 알고 나면 보낼 전자 메일 주소를 알아야 합니다. 따라서 각 고객에 대한 전자 메일 주소를 기록해야 합니다.

각 보고서 또는 출력 목록의 프로토타입을 구성하고 보고서를 생성하는 데 필요한 항목을 고려하는 것이 좋습니다. 예를 들어 양식 편지를 검사할 때 몇 가지가 염두에 두어 있을 수 있습니다. 인사말을 시작하는 "Mr.", "Mrs." 또는 "Ms." 문자열과 같은 적절한 인사말을 포함하려는 경우 인사 항목을 만들어야 합니다. 또한 일반적으로 "친애하는 미스터 스미스"가 아닌 "친애하는 편지"로 편지를 시작할 수 있습니다. Mr. Sylvester Smith". 일반적으로 성은 이름과 별개로 저장하려는 것을 시사합니다.

중요한 점은 각 정보를 가장 작은 유용한 부분으로 끊어야 한다는 것입니다. 이름의 경우 성을 쉽게 사용할 수 있도록 만들면 이름과 성의 두 부분으로 나타났습니다. 예를 들어 보고서를 성별로 정렬하기 위해 고객의 성은 별도로 저장하는 데 도움이 됩니다. 일반적으로 정보 항목에 따라 정렬, 검색, 계산 또는 보고서를 사용하려는 경우 해당 항목을 자체 필드에 넣어야 합니다.

데이터베이스가 응답할 질문에 대해 생각해 던지기 바랍니다. 예를 들어 지난 달에 추천 제품의 판매량이 얼마나 많습니까? 최고의 고객은 어디에 거주하나요? 베스트셀러 제품의 공급업체는 누구인가요? 이러한 질문을 예상하면 기록할 추가 항목을 0으로 설정하는 데 도움이 됩니다.

이 정보를 수집한 후 다음 단계를 준비합니다.

맨 위로 이동

정보를 테이블로 나분할 수 있습니다.

정보를 테이블로 나누기 위해 주 엔터티 또는 주체를 선택하세요. 예를 들어 제품 판매 데이터베이스에 대한 정보를 검색하고 구성한 후 예비 목록은 다음과 같을 수 있습니다.

주제별로 그룹화된 필기 정보 항목

여기에 표시된 주요 엔터티는 제품, 공급자, 고객 및 주문입니다. 따라서 제품에 대한 사실, 공급업체에 대한 사실, 고객에 대한 사실, 주문에 대한 사실 등 4개의 테이블로 시작하는 것이 좋습니다. 목록을 완료하지는 못하겠지만 좋은 출발점입니다. 디자인이 잘 작동할 때까지 이 목록을 계속 구체화할 수 있습니다.

항목의 예비 목록을 처음 검토할 때 앞의 그림에 표시된 4개 대신 모든 항목을 단일 테이블에 두는 것이 좋습니다. 이게 왜 나쁜 생각인지 여기에서 알 수 있습니다. 여기에 표시된 표를 잠시 고려합니다.

제품과 공급업체가 모두 포함된 테이블을 보여 주는 이미지

이 경우 각 행에는 제품 및 해당 공급자에 대한 정보가 포함되어 있습니다. 동일한 공급 업체에서 많은 제품을 사용할 수 있기 때문에 공급자 이름 및 주소 정보를 여러 번 반복해야 합니다. 이 경우 디스크 공간이 낭비됩니다. 공급업체 정보를 별도의 공급 업체 테이블에 한 번만 기록한 다음 해당 테이블을 제품 테이블에 연결하는 것이 훨씬 더 나은 솔루션입니다.

이 디자인의 두 번째 문제는 공급자에 대한 정보를 수정해야 할 때 발생합니다. 예를 들어 공급자의 주소를 변경해야 라고 가정합니다. 주소는 여러 위치에 나타나므로 실수로 한 곳에서만 주소를 변경하고 다른 곳에서는 변경하지 않을 수 있습니다. 공급자의 주소를 한 곳만 기록하면 문제가 해결됩니다.

데이터베이스를 디자인할 때 항상 한 번만 각 팩트 기록을 시도합니다. 특정 공급자의 주소와 같은 여러 장소에서 동일한 정보를 반복하는 경우 해당 정보를 별도의 테이블에 를 두세요.

마지막으로 Coho Winery에서 제공하는 제품이 하나만 있으며 제품을 삭제하지만 공급자 이름 및 주소 정보를 유지하려는 경우를 가정합니다. 공급업체 정보를 잃지 않고 제품 레코드를 삭제하려면 어떻게 하나요? 불가능합니다. 각 레코드에는 제품에 대한 사실과 공급업체에 대한 팩트가 포함되어 있기 때문에 다른 레코드를 삭제하지 않고 삭제할 수 없습니다. 이러한 사실을 구분하려면 한 테이블을 제품 정보에 대한 테이블 하나와 공급업체 정보에 대한 다른 테이블로 분할해야 합니다. 제품 레코드를 삭제하면 공급업체에 대한 사실이 아닌 제품에 대한 팩트만 삭제해야 합니다.

표로 표시되는 제목을 선택한 후 해당 테이블의 열에는 제목에 대한 팩트만 저장해야 합니다. 예를 들어 제품 테이블은 제품에 대한 팩트만 저장해야 합니다. 공급업체 주소는 공급업체에 대한 사실이지 제품에 대한 사실이 아니기 때문에 공급업체 테이블에 속합니다.

맨 위로 이동

정보 항목을 열로 전환

표의 열을 확인하려면 표에 기록된 주제에 대해 추적해야 하는 정보를 결정해야 합니다. 예를 들어 고객 테이블의 경우 이름, 주소, City-State-Zip, 전자 메일 보내기, 안도 및 전자 메일 주소는 좋은 열 목록으로 구성됩니다. 표의 각 레코드에는 동일한 열 집합이 포함되어 있으므로 각 레코드에 대한 이름, 주소, 도시-상태-Zip, 전자 메일 보내기, 안도 및 전자 메일 주소 정보를 저장할 수 있습니다. 예를 들어 주소 열에는 고객의 주소가 포함되어 있습니다. 각 레코드에는 한 고객에 대한 데이터가 포함되어 있으며 주소 필드에는 해당 고객의 주소가 포함되어 있습니다.

각 테이블에 대한 초기 열 집합을 결정한 후 열을 더 구체화할 수 있습니다. 예를 들어 고객 이름을 이름과 성의 두 개의 별도 열로 저장하여 해당 열만 정렬, 검색 및 인덱싱할 수 있습니다. 마찬가지로 주소는 실제로 주소, 도시, 주, 우편 번호 및 국가/지역 5개 구성 요소로 구성됩니다. 또한 별도의 열에 저장하는 것이 타당합니다. 예를 들어 상태별로 검색, 필터링 또는 정렬 작업을 수행하려면 별도의 열에 저장된 상태 정보가 필요합니다.

데이터베이스가 국내에서만 제공된 정보를 보유할지 아니면 국제적인 정보도 보유할지 여부를 고려해야 합니다. 예를 들어 국제 주소를 저장하는 경우 해당 열이 국내 주 및 다른 국가/지역의 지역을 모두 수용할 수 있기 때문에 주가 아닌 지역 열을 두는 것이 좋습니다. 마찬가지로 국제 주소를 저장하는 경우 우편 번호는 우편 번호보다 더 의미가 있습니다.

다음 목록에는 열을 결정하는 몇 가지 팁이 표시됩니다.

  • 계산된 데이터를 포함하지 않습니다.    

    대부분의 경우 계산 결과를 테이블에 저장하면 안 됩니다. 대신 결과를 표시하려는 경우 Access에서 계산을 수행할 수 있습니다. 예를 들어 데이터베이스의 각 제품 범주에 대한 순서대로 단위의 하위 구성을 표시하는 제품 주문 보고서가 있는 경우를 가정해 보겠습니다. 그러나 테이블에는 단위 On Order 하위 열이 없습니다. 대신 제품 테이블에는 각 제품의 순서대로 단위를 저장하는 단위 주문 열이 포함됩니다. 이 데이터를 사용하여 Access는 보고서를 인쇄할 때마다 하위 값을 계산합니다. 하위 하위 자체는 테이블에 저장되어 있지 않습니다.

  • 가장 작은 논리적 부분에 정보 저장    

    전체 이름에 대한 단일 필드 또는 제품 설명과 함께 제품 이름을 입력해야 하는 유혹이 있을 수 있습니다. 필드에서 두 가지 이상의 정보를 결합하는 경우 나중에 개별 사실을 검색하기가 어렵습니다. 정보를 논리적 부분으로 분석하려고 합니다. 예를 들어 이름 및 성 또는 제품 이름, 범주 및 설명에 대해 별도의 필드를 만들 수 있습니다.

디자인하는 동안의 정보 항목을 보여 주는 이미지

각 테이블의 데이터 열을 구체화하면 각 테이블의 기본 키를 선택할 준비가 됩니다.

맨 위로 이동

기본 키 지정

각 테이블에는 테이블에 저장된 각 행을 고유하게 식별하는 열 또는 열 집합이 포함되어야 합니다. 이는 종종 직원 ID 번호 또는 일련 번호와 같은 고유한 식별 번호입니다. 데이터베이스 용어에서 이 정보를 테이블의 기본 키라고 합니다. Access는 기본 키 필드를 사용하여 여러 테이블의 데이터를 빠르게 연결하고 데이터를 함께 가져올 수 있습니다.

카탈로그의 각 제품을 고유하게 식별하는 제품 번호와 같은 테이블에 대한 고유 식별자가 이미 있는 경우 해당 식별자를 테이블의 기본 키로 사용할 수 있지만 이 열의 값은 항상 각 레코드마다 다를 수 있습니다. 기본 키에는 중복 값을 사용할 수 없습니다. 예를 들어 이름이 고유하지 않은 경우 기본 키로 사용자 이름을 사용하지 않습니다. 동일한 테이블에 이름이 같은 두 사람이 쉽게 있을 수 있습니다.

기본 키에는 항상 값이 있어야 합니다. 열의 값이 어느 시점에서 부호가 되거나 알 수 없는 값(누락된 값)이 될 수 있는 경우 주 키의 구성 요소로 사용할 수 없습니다.

항상 값이 변경되지 않는 기본 키를 선택해야 합니다. 두 개 이상의 테이블을 사용하는 데이터베이스에서 테이블의 기본 키를 다른 테이블의 참조로 사용할 수 있습니다. 기본 키가 변경되는 경우 키가 참조되는 모든 곳에서도 변경 내용을 적용해야 합니다. 변경되지 않는 기본 키를 사용하면 기본 키가 참조하는 다른 테이블과 동기화되지 않을 수 있습니다.

종종 임의의 고유 번호가 기본 키로 사용됩니다. 예를 들어 각 주문에 고유한 주문 번호를 할당할 수 있습니다. 주문 번호의 유일한 목적은 주문을 식별하는 것입니다. 할당된 후 변경되지 않습니다.

좋은 기본 키를 만들 수 있는 열 또는 열 집합을 염두에 두지 않는 경우 AutoNumber 데이터 형식이 있는 열을 사용하는 것이 좋습니다. AutoNumber 데이터 형식을 사용하면 Access에서 자동으로 값을 할당합니다. 이러한 식별자는 사실이 없습니다. 나타내는 행을 설명하는 사실 정보가 없습니다. 사실이 아닌 식별자는 변경되지 때문에 기본 키로 사용하기에 이상적입니다. 행에 대한 팩트(예: 전화 번호 또는 고객 이름)를 포함하는 기본 키는 사실 정보 자체가 변경될 수 있기 때문에 변경될 가능성이 더 높습니다.

기본 키 필드가 있는 제품 테이블을 보여 주는 이미지

1. AutoNumber 데이터 유형으로 설정된 열은 종종 좋은 기본 키를 만드는 경우가 있습니다. 두 제품 아이디가 동일하지 않습니다.

경우에 따라 테이블의 기본 키를 함께 제공하는 두 개 이상의 필드를 사용할 수 있습니다. 예를 들어 주문에 대한 줄 항목을 저장하는 주문 세부 정보 테이블은 기본 키인 주문 ID 및 제품 ID의 두 열을 사용하게 됩니다. 기본 키가 둘 이상의 열을 사용하는 경우 복합 키라고도 합니다.

제품 판매 데이터베이스의 경우 제품 테이블용 ProductID, 주문 테이블에 대한 OrderID, CustomerID for the Customers table 및 SuppliersID의 기본 키로 사용할 각 테이블에 대해 AutoNumber 열을 만들 수 있습니다.

디자인하는 동안의 정보 항목을 보여 주는 이미지


맨 위로 이동

테이블 관계 만들기

이제 정보를 테이블로 나눠서 의미 있는 방법으로 정보를 다시 가져올 수 있는 방법이 필요합니다. 예를 들어 다음 양식에는 여러 테이블의 정보가 포함됩니다.

주문 폼 이미지

1. 이 폼의 정보를 가져오는 위치는 고객 테이블...

2. ... Employees 테이블...

3. ... 주문 테이블...

4. ... 제품 테이블...

5. ... 및 주문 세부 정보 테이블입니다.

Access는 관계적 데이터베이스 관리 시스템입니다. 관계형 데이터베이스에서 정보를 별도의 주체 기반 테이블로 분할합니다. 그런 다음 테이블 관계를 사용하여 필요한 경우 정보를 함께 가져올 수 있습니다.

맨 위로 이동

일대다 관계 만들기

이 예제를 고려합니다. 제품 주문 데이터베이스의 공급 업체 및 제품 테이블입니다. 공급자는 수에 관계 없이 제품을 공급할 수 있습니다. 공급업체 테이블에 표현된 모든 공급업체의 경우 제품 테이블에 여러 제품이 표현될 수 있습니다. 따라서 공급업체 테이블과 제품 테이블 간의 관계는 일대다 관계입니다.

일대다 개념

데이터베이스 디자인에서 일대다 관계를 나타내기 위해 관계의 "일" 쪽의 기본 키를 취하고 관계의 "다" 쪽의 테이블에 추가 열 또는 열로 추가합니다. 이 경우 공급자 테이블에서 제품 테이블에 공급자 ID 열을 추가합니다. 그러면 Access는 제품 테이블의 공급업체 ID 번호를 사용하여 각 제품에 대한 올바른 공급자를 찾을 수 있습니다.

제품 테이블의 공급자 ID 열을 외계 키라고 합니다. 외계 키는 다른 테이블의 기본 키입니다. 제품 테이블의 공급자 ID 열은 공급업체 테이블의 기본 키이기 때문에 외계 키입니다.

디자인하는 동안의 정보 항목을 보여 주는 이미지

기본 키 및 외계 키의 페어링을 설정하여 관련 테이블을 조인할 수 있는 기반을 제공합니다. 공통 열을 공유할 테이블이 확실하지 않은 경우 일대다 관계를 식별하면 관련 두 테이블에 공유 열이 필요하게 됩니다.

맨 위로 이동

다대다 관계 만들기

제품 테이블과 주문 테이블 간의 관계를 고려합니다.

단일 주문은 두 개 이상의 제품을 포함할 수 있습니다. 반면, 단일 제품은 여러 주문에 나타날 수 있습니다. 따라서 주문 테이블의 각 레코드에 대해 제품 테이블에는 많은 레코드가 존재할 수 있습니다. 또한 제품 테이블의 각 레코드에 대해 Orders 테이블에 많은 레코드가 있을 수 있습니다. 이러한 유형의 관계는 모든 제품의 경우 많은 주문이 있을 수 있기 때문에 다대다 관계라고 합니다. 모든 주문에 대해 많은 제품이 있을 수 있습니다. 테이블 간의 다대다 관계를 감지하기 위해 관계의 양쪽을 모두 고려하는 것이 중요합니다.

주문 및 제품인 두 테이블의 주체는 다대다 관계가 있습니다. 이 경우 문제가 있습니다. 문제를 이해하려면 제품 ID 필드를 Orders 테이블에 추가하여 두 테이블 간의 관계를 만들려고 시도한 경우 어떻게 될지 상상해 본다. 주문당 두 개 이상의 제품을 사용하려면 주문당 주문 테이블에 두 개 이상의 레코드가 필요합니다. 단일 순서와 관련된 각 행에 대한 순서 정보를 반복하면 부정확한 데이터가 발생할 수 있는 비효율적인 디자인이 생성됩니다. 제품 테이블에 주문 ID 필드를 두면 동일한 문제가 발생하게 됩니다. 각 제품의 제품 테이블에 두 개 이상의 레코드가 있습니다. 이 문제를 어떻게 해결하나요?

대답은 다대다 관계를 두 개의 일대다 관계로 나타 내는 정션 테이블이라고도 하는 세 번째 테이블을 만드는 것입니다. 그런 다음 다대다 관계를 형성하는 두 테이블의 기본 키를 이 세 번째 테이블에 삽입합니다. 결과적으로 세 번째 테이블은 관계의 각 발생 또는 인스턴스를 기록합니다.

다대다 관계의 개념

주문 세부 정보 테이블의 각 레코드는 주문의 한 줄 항목을 나타내고 있습니다. 주문 세부 정보 테이블의 기본 키는 주문 및 제품 테이블의 외계 키인 두 필드로 구성됩니다. 주문 ID 필드를 사용하는 것만으로는 한 주문에 많은 줄 항목이 존재할 수 있기 때문에 이 테이블의 기본 키로 작동하지 않습니다. 주문 ID는 주문의 각 행 항목에 대해 반복됩니다. 따라서 필드에 고유한 값이 포함되지 않습니다. 제품 ID 필드를 사용하는 것만으로는 여러 주문에 한 제품이 표시될 수 있기 때문에 작동하지 않습니다. 그러나 두 필드가 함께 각 레코드에 대해 항상 고유한 값을 생성합니다.

제품 판매 데이터베이스에서 Orders 테이블 및 제품 테이블은 서로 직접 관련이 없습니다. 대신 주문 세부 정보 테이블을 통해 간접적으로 관련됩니다. 주문과 제품 간의 다대다 관계는 2개의 일대다 관계를 사용하여 데이터베이스에서 표현됩니다.

  • 주문 테이블 및 주문 세부 정보 테이블에는 일대다 관계가 있습니다. 각 주문에는 두 개 이상의 줄 항목이 있지만 각 행 항목은 하나의 순서에만 연결됩니다.

  • 제품 테이블 및 주문 세부 정보 테이블에는 일대다 관계가 있습니다. 각 제품에는 여러 줄 항목이 관련될 수 있지만 각 줄 항목은 하나의 제품만 참조합니다.

주문 세부 정보 테이블에서 특정 순서로 모든 제품을 확인할 수 있습니다. 특정 제품에 대한 모든 주문을 확인할 수도 있습니다.

주문 세부 정보 테이블을 통합한 후 테이블 및 필드 목록은 다음과 같이 표시될 수 있습니다.

디자인하는 동안의 정보 항목을 보여 주는 이미지


맨 위로 이동

일대일 관계 만들기

또 다른 유형의 관계는 일대일 관계입니다. 예를 들어 드물게 필요하거나 일부 제품에만 적용되는 몇 가지 특별 보조 제품 정보를 기록해야 라고 가정합니다. 정보가 자주 필요하지 않습니다. 제품 테이블에 정보를 저장하면 해당 정보가 적용되지 않는 모든 제품에 대한 빈 공간이 제공될 수 있기 때문에 별도의 테이블에 저장합니다. 제품 테이블과 마찬가지로 ProductID를 기본 키로 사용할 수 있습니다. 이 보조 테이블과 제품 테이블 간의 관계는 일대일 관계입니다. 제품 테이블의 각 레코드에 대해 보조 테이블에 단일 일치 레코드가 있습니다. 이러한 관계를 식별할 때 두 테이블은 공통 필드를 공유하고 있어야 합니다.

데이터베이스에서 일대일 관계의 필요성을 감지할 때 두 테이블의 정보를 한 테이블에 함께 넣을 수 있는지 여부를 고려합니다. 어떤 이유로 이러한 작업을 원하지 않는 경우 빈 공간이 많을 수 있기 때문에 다음 목록에서는 디자인에서 관계를 나타내는 방법을 보여줍니다.

  • 두 테이블에 동일한 제목이 있는 경우 두 테이블에서 동일한 기본 키를 사용하여 관계를 설정할 수 있습니다.

  • 두 테이블에 기본 키가 서로 다른 주체가 있는 경우 테이블 중 하나를 선택하고 다른 테이블에 기본 키를 외계 키로 삽입합니다.

테이블 간의 관계를 결정하는 것은 올바른 테이블과 열을 확보하는 데 도움이 됩니다. 일대일 관계 또는 일대다 관계가 있는 경우 관련된 테이블은 공통 열 또는 열을 공유해야 합니다. 다대다 관계가 있는 경우 관계를 나타내는 데 세 번째 테이블이 필요합니다.

맨 위로 이동

디자인 구체화

필요한 테이블, 필드 및 관계가 있는 경우 테이블을 만들고 샘플 데이터로 채우고, 쿼리 만들기, 새 레코드 추가 등 정보를 사용하여 작업해 보아야 합니다. 이렇게 하면 잠재적인 문제를 강조하는 데 도움이 됩니다. 예를 들어 디자인 단계에서 삽입하지 못하게 한 열을 추가해야 할 수도 있습니다. 또는 중복을 제거하기 위해 두 테이블로 분할해야 하는 테이블이 있을 수 있습니다.

데이터베이스를 사용하여 원하는 답변을 얻을 수 있는지 를 참조합니다. 폼 및 보고서의 대략적인 초안을 만들고 예상되는 데이터를 표시하는지 를 참조합니다. 불필요한 데이터 복제를 찾아서 찾을 때 디자인을 변경하여 제거합니다.

초기 데이터베이스를 사용해보면 개선할 수 있는 여지가 발견될 것입니다. 다음은 확인해야 할 몇 가지 사항입니다.

  • 열을 잊어버렸다면? 그렇다면 정보가 기존 테이블에 속하나요? 다른 테이블에 대한 정보인 경우 다른 테이블을 만들어야 할 수 있습니다. 추적해야 하는 모든 정보 항목에 대한 열을 생성합니다. 다른 열에서 정보를 계산할 수 없는 경우 새 열이 필요할 수 있습니다.

  • 기존 필드에서 계산할 수 있기 때문에 열이 필요하지 않은가요? 다른 기존 열(예: 소매 가격에서 계산된 할인 가격)에서 정보 항목을 계산할 수 있는 경우 일반적으로 이러한 항목만 계산하고 새 열을 만드는 것이 좋습니다.

  • 테이블 중 하나에 중복 정보를 반복적으로 입력하고 있나요? 그렇다면 테이블을 일대다 관계가 있는 두 개의 테이블로 분할해야 합니다.

  • 필드가 많고 레코드 수가 제한되어 있으며, 개별 레코드에 빈 필드가 많은 테이블이 있나요? 그렇다면 더 적은 필드와 더 많은 레코드가 있도록 테이블을 다시 디자인하는 것이 더 까다로우면 됩니다.

  • 각 정보 항목이 가장 작은 유용한 부분으로 나타 졌나요? 정보 항목에 대한 보고, 정렬, 검색 또는 계산이 필요한 경우 해당 항목을 자체 열에 넣습니다.

  • 각 열에 표의 제목에 대한 팩트가 포함되어 있나요? 열에 표의 제목에 대한 정보가 포함되어 있지 않은 경우 다른 테이블에 속합니다.

  • 테이블 간의 모든 관계는 공통 필드 또는 세 번째 테이블로 표현하나요? 일대일 및 일대일 관계에는 일반적인 열이 필요하게 됩니다. 다대다 관계에는 세 번째 테이블이 필요하게 됩니다.

제품 테이블 구체화

제품 판매 데이터베이스의 각 제품은 음료, 조미료 또는 해산물과 같은 일반 범주에 속합니다. 제품 테이블에는 각 제품의 범주를 보여주는 필드가 포함되어 있을 수 있습니다.

데이터베이스 디자인을 검사하고 구체화한 후 범주에 대한 설명을 이름과 함께 저장하기로 결정했다고 가정합니다. 제품 테이블에 범주 설명 필드를 추가하는 경우 범주에 속하는 각 제품에 대한 각 범주 설명을 반복해야 합니다. 이 방법은 좋지 않습니다.

더 나은 솔루션은 범주를 자체 테이블 및 자체 기본 키로 추적할 데이터베이스의 새 주체로 만드는 것입니다. 그런 다음 범주 테이블의 기본 키를 제품 테이블에 외계 키로 추가할 수 있습니다.

범주 및 제품 테이블에는 일대다 관계가 있습니다. 범주에는 두 개 이상의 제품이 포함할 수 있지만 제품은 하나의 범주에 속할 수 있습니다.

테이블 구조를 검토할 때 반복 그룹을 찾아야 합니다. 예를 들어 다음 열이 포함된 표를 고려합니다.

  • 제품 ID

  • Name(이름)

  • 제품 ID1

  • Name1

  • 제품 ID2

  • Name2

  • 제품 ID3

  • Name3

여기서 각 제품은 열 이름의 끝에 숫자를 추가하여 다른 열과 다른 열의 반복 그룹입니다. 이렇게 번호 매기기 열이 표시되는 경우 디자인을 다시 참조해야 합니다.

이러한 디자인에는 몇 가지 결함이 있습니다. 먼저 제품 수에 대한 상한을 설정해야 합니다. 이 제한을 초과하는 즉시 주요 관리 작업인 테이블 구조체에 새 열 그룹을 추가해야 합니다.

또 다른 문제는 최대 제품 수보다 적은 공급업체가 추가 열이 비어 있을 것이기 때문에 공간을 낭비할 수 있습니다. 이러한 디자인의 가장 심각한 결함은 제품 ID 또는 이름으로 테이블을 정렬하거나 인덱싱하는 등의 많은 작업을 수행하기가 어렵다는 것입니다.

반복 그룹이 표시될 때마다 테이블을 두 개로 분할하는 것을 주시하여 디자인을 면밀히 검토합니다. 위의 예제에서는 공급자 ID로 연결된 공급업체 및 제품에 대해 두 개의 테이블을 사용하는 것이 좋습니다.

맨 위로 이동

정규화 규칙 적용

디자인의 다음 단계로 데이터 정규화 규칙(정규화 규칙이라고도 하는 경우)을 적용할 수 있습니다. 이러한 규칙을 사용하여 테이블이 올바르게 구성되는지 확인합니다. 데이터베이스 디자인에 규칙을 적용하는 프로세스를 데이터베이스 정규화 또는 정규화라고 합니다.

정규화는 모든 정보 항목을 나타내고 예비 디자인에 도착한 후에 가장 유용합니다. 이 아이디어는 정보 항목을 적절한 테이블로 분할하는 데 도움이 되도록 하는 것입니다. 정규화에서 할 수 없는 것은 시작할 모든 올바른 데이터 항목이 되도록 하는 것입니다.

각 단계에서 규칙을 연속적으로 적용하여 디자인이 "일반 양식"이라는 중 하나에 도착하도록 합니다. 다섯 가지 일반 양식이 널리 허용됩니다. 다섯 번째 일반 폼을 통해 첫 번째 일반 양식입니다. 이 문서는 대부분의 데이터베이스 디자인에 필요한 모든 것이기 때문에 처음 3개에서 확장됩니다.

첫 번째 일반 양식

첫 번째 일반 폼은 테이블의 모든 행 및 열 교차에 단일 값이 존재하며 값 목록이 없는 상태입니다. 예를 들어 가격이라는 필드가 두 개 이상 있는 가격을 사용할 수 없습니다. 행과 열의 각 교차를 셀로 생각하면 각 셀은 하나의 값만 보유할 수 있습니다.

두 번째 일반 양식

두 번째 일반 형식에서는 각 비키어 열이 키의 일부가 아닌 전체 기본 키에 완전히 종속되어야 합니다. 이 규칙은 두 개 이상의 열로 구성된 기본 키가 있는 경우 적용됩니다. 예를 들어 주문 ID 및 제품 ID가 기본 키를 형성하는 다음 열이 포함된 표가 있는 경우를 가정해 보겠습니다.

  • 주문 ID(기본 키)

  • 제품 ID(기본 키)

  • 제품 이름

제품 이름은 제품 ID에 종속되지만 주문 ID는 아니기 때문에 이 디자인은 두 번째 일반 양식을 위반합니다. 따라서 전체 주 키에 종속되지 않습니다. 테이블에서 제품 이름을 제거해야 합니다. 다른 테이블(제품)에 속합니다.

세 번째 일반 양식

세 번째 일반 형식에서는 모든 비키어 열이 전체 기본 키에 종속될 뿐만 아니라 키가 아닌 열은 서로 독립적이지 않습니다.

이를 말하는 또 다른 방법은 각 비키어 열이 기본 키에 종속되어야 하며 기본 키만이 아니라는 것입니다. 예를 들어 다음 열을 포함하는 표가 있는 경우를 가정해 보겠습니다.

  • ProductID(기본 키)

  • Name(이름)

  • SRP

  • discount

할인은 제안된 소매 가격(SRP)에 따라 달라 지는 것으로 가정합니다. 이 표는 키가 아닌 열인 할인은 다른 비키키 열인 SRP에 따라 달라지기 때문에 세 번째 일반 형식을 위반합니다. 열 독립성은 다른 열에 영향을 주지 않고 키가 아닌 열을 변경할 수 있습니다. SRP 필드에서 값을 변경하면 할인이 그에 따라 변경됩니다. 따라서 해당 규칙을 위반합니다. 이 경우 할인은 SRP에서 키가 있는 다른 테이블로 이동해야 합니다.

맨 위로 이동

추가 도움이 필요하신가요?

기술 향상
교육 살펴보기
새로운 기능 우선 가져오기
Microsoft Office 참가자 참가

이 정보가 유용한가요?

언어 품질에 얼마나 만족하시나요?
사용 경험에 어떠한 영향을 주었나요?

의견 주셔서 감사합니다!

×