RDBMS의 관계에 대해 공부하고있었습니다. 매핑 관계를 배후에있는 기본 개념을 이해 했습니다만, 나는 그들을 발견 할 수 없습니다.RDBMS에서 관계를 발견하는 방법은 무엇입니까?
세 가지 가능성 : 많은 (가장 일반적인)에
프로젝트를 시작할 때 처음 두 조건을 구분할 수 없으며 머리가 깨끗하지 않습니다. 짧은 시간 동안 도움을 받으면 연습 할 때 이러한 원리를 적용해야 할 때가 아닙니다.
이곳은 대부분의 초심자가 흔들리는 곳입니다. 어떻게 이러한 관계를 발견 할 수 있습니까? 더 간단한 방법이 있습니까?
기술적 관점에서 관계를 보지 마십시오. 머리 속에 관계를 구상하려고 할 때 유추 및 실례를 사용하십시오.
예를 들어 라이브러리 데이터베이스가 있다고 가정 해 봅시다. 도서관에는 도서이 있어야합니다.
각 Book
Authors 의해 기록되었을 각
Author 여러
Books 쓸 수도있다. 따라서
many-to-many 관계가 데이터베이스의 3 개 테이블에 반영됩니다.
각 Book도 Publisher이 있어야하지만, Book은 하나의 Publisher있을 수 있으며 Publisher가 Books 많은 게시 할 수 있습니다. 따라서 일대 다 관계이며 Books 테이블에서 참조되는 PublisherId으로 나타납니다.
이 간단한 비유는 핵심과의 관계를 설명합니다. 기술 렌즈를 통해 사진을 보려고하면 더 힘들게됩니다.실제로 어려운 점은 데이터베이스를 구축 할 때 실제 데이터 시나리오를 적용하는 것입니다.
두 개의 테이블 A와 B가 있다고 가정 해보십시오. A로부터의 엔트리를 고려해 볼 때 B에서 몇 개의 엔트리가 많아야 관련 될 수 있다고 생각하십니까? 하나 이상입니까? 그런 다음 B에서 항목을 고려하고 A와 관련된 항목 수를 생각하십시오.
몇 가지 예 :
표 A : 어머니, 표 B : 아이들. 각 어린이는 어머니가 한 명이지만 어머니는 한 명 이상의 자녀를 가질 수 있습니다. 어머니와 자녀는 일대 다 관계입니다.
표 A : 의사, 표 B : 환자. 각 환자는 하나 이상의 의사를 방문 할 수 있으며 각 의사는 하나 이상의 환자를 치료합니다. 그래서 그들은 many-to-many 관계를가집니다.
예를 들어, 1 대 1의 예 : LicencePlate to Vehicle. 하나의 번호판은 하나의 차량에 속하고 하나의 차량에는 하나의 번호판이 있습니다.
내가 원하는 답변을 얻지 못하는 이유는 질문을 제출하는 방식 때문이라고 생각합니다. "실체 간의 올바른 관계 유형을 어떻게 발견 할 수 있습니까?"라고 묻는 대신 "기능적 요구가 구현할 관계를 어떻게 결정합니까"에 대해 생각하십시오. 데이터베이스 디자인은 기능을 수행하지 않습니다. 구현해야 할 관계를 이끌어가는 것은 기능상의 필요입니다.
데이터베이스 구조를 설계 할 때 모든 엔티티를 식별해야합니다. 엔티티는 책 제목, 청구서, 국가, 개 종 등의 목록을 저장하려는 모든 사실입니다. 그런 다음 관계를 식별하려면 데이터베이스에 질문 할 질문 유형을 고려해야합니다. 때로는 앞으로의 생각이 약간 걸립니다 ... 아무도 질문을하지 않고서도 이이되지 않을 수도 있습니다. 그러므로 결정적인 답이 없기 때문에 우주에 "사실 목록들 사이의 관계는 무엇입니까?"라고 물어볼 수는 없습니다. 당신은 우주를 정의합니다 ... 나는 단지 이런 종류의 질문에 대한 답을 알고 싶습니다. 그러므로 나는 이런 유형의 관계를 사용할 필요가있다.
두 개의 공통 엔티티 인 고객 테이블과 상점 위치 테이블 간의 관계를 살펴 보겠습니다. 먼저 이들에 대해 알아야 할 것을 정의하지 않고 이러한 엔티티를 관련시키는 "올바른"방법은 없습니다. 소매 업체에서 일하고 고객에게 기본 상점 지정을 제공하여 해당 지역 상점에 재고가있는 웹 사이트의 제품을 볼 수 있다고 가정 해 보겠습니다. 이는 상점과 고객간에 일대 다 관계가 필요합니다. 이 방식으로 관계를 설계하면 한 상점이 많은 고객을 기본값으로 가질 수 있고 각 고객은 하나의 기본 상점 만 가질 수 있습니다. 이 관계를 구현하려면 Customer 테이블에 테이블의 기본 키에 링크하는 외래 키로 DefaultStore 필드를 추가하는 것만 큼 쉽습니다.
위의 동일한 두 엔티티는 다른 컨텍스트에서 관계 정의에 대한 대체 요구 사항을 가질 수 있습니다. 좋아하는 상점 목록을 선택하여 한 번에 모든 상점에 대한 주식 정보를 쿼리 할 수있는 기회를 고객에게 제공 할 수 있어야한다고 가정 해 보겠습니다. 한 고객이 많은 상점과 관련 될 수 있고 각 상점이 많은 고객과 관련 될 수 있기를 원하면 다 대다 관계가 필요합니다. 관계 연결을 정의하기 위해 별도의 테이블을 만들어야하기 때문에 다 대다 관계를 구현하려면 약간의 오버 헤드가 필요하지만이 추가 기능을 얻을 수 있습니다. 관계 테이블을 CustomerStoreFavorites과 같은 것으로 부를 수 있으며 각 엔티티의 결합 된 기본 키는 기본 키로 사용됩니다 : (CustomerID, StoreID). 관계에 특성을 추가 할 수도 있습니다 (예 : LastOrderDate 필드). 고객이 특정 상점에서 주문한 마지막 날짜를 지정할 수 있습니다.
기술적으로 동일한 두 엔티티에 대해 두 가지 유형의 관계를 정의 할 수 있습니다. 예를 들어 고객에게 기본 상점을 선택할 수있는 옵션을 제공해야 할 수도 있지만 고객이 특정 상점에서 주문한 마지막 날짜를 기록 할 수 있어야합니다. DefaultStore 필드를 Store 테이블 에 대한 외래 키와 함께 Customer 테이블에 구현하고도 고객이 주문한 모든 상점을 추적하는 관계 테이블을 생성 할 수 있습니다.
모든 고객이 자체 상점을 보유하고있는 별난 상황이 있다면 고객 및 상점의 모든 속성을 하나의 테이블에 저장할 수 있기 때문에 엔터티에 대해 두 개의 테이블을 작성할 필요조차 없습니다.
즉, 구현할 관계 유형을 결정하는 방법은 데이터베이스에 질문 할 때 필요한 질문을 스스로에게 묻는 것입니다. 설계 방법에 따라 수집 할 수있는 관계형 데이터와 요청할 수있는 쿼리가 제한됩니다. 상점에서 고객까지 일대 다 관계를 디자인하면 다른 관계를 통해 해당 정보를 얻을 수 없다면 각 고객이 주문한 모든 상점에 대해 질문 할 수 없습니다. 예를 들어, 고객 및 상점과 일대 다 관계가있는 "구매"라는 엔티티를 만들 수 있습니다. 각 구매가 한 고객 및 한 상점과 관련이 있다고 정의 된 경우, 이제 "이 고객이 주문한 상점이 무엇입니까?"라는 질문을 할 수 있습니다. 사실이 구조로 모든 정보에 대한 훨씬 더 풍부한 정보 소스를 수집하고보고 할 수 있습니다. 어떤 상점에서든 고객의 구매. 따라서 데이터베이스의 다른 모든 관계의 컨텍스트를 고려하여 두 특정 엔터티간에 구현할 관계를 결정해야합니다.
마법의 공식이 없으므로 연습, 경험 및 창의력이 필요합니다. 응급실 다이어그램은 설계를 분석하고 올바른 유형의 질문을 얻을 수 있도록 설계를 머리에서 종이로 가져 오는 훌륭한 방법입니다. 데이터베이스 아키텍처에 대해 배우기위한 많은 책과 자료가 있습니다. 제가 많이 배운 좋은 책 중 하나는 Abraham Silberschatz와 Henry Korth의 "Database System Concepts"였습니다.
무슨 뜻인지 예를 들려 줄 수 있습니까? – Enumy
사용할 수있는 옵션이 너무 명확하므로 왜 그 문제를 발견 할 수 없는지 이해할 수 없습니다. 당신을 미치게 만드는 예를 보여주십시오. – JotaBe
매우 일반적인 질문입니다. 실례지만 드릴 수는 없지만 질문에 대해 자세히 설명해 드릴 수 있습니다. 프로젝트 작업을 시작할 때 여러 테이블을 만듭니다.이 테이블은 어떤 식 으로든 관련되어 있지만, 나는 발견 할 수 없습니다 . 나는 매우 일반적인 대답을 찾고있다. 그래서 나는 내 모든 관계를 최소한의 종이 한장에 줄 수있다. 일반적인 생각은 괜찮다. –