MS Access 2010에서 프로젝트를 구축하고 있습니다. Oracle에 대한 이전 경험이 있습니다. 나는 MS Access에 대해 읽고 테이블 관계에 대한 참조를 계속보고있다. 이는 평균적인 사람이 데이터 입력 및 유효성 검사 및 쿼리 작성을 돕는 편리한 방법 인 것처럼 보이지만 SQL 모드에서만 쿼리를 작성하고 자체 유효성 검사 규칙이있는 폼을 사용하여 데이터 입력을 시행합니다.데이터베이스에서 관계를 지정하면 무엇을 얻을 수 있습니까?
관계를 강화하는 것이 실제로 필요한가요? 그것은 나에게 진보 된 수준의 것을 얻은 것처럼 보이지는 않습니다. 실제로 저나 다른 사람에게 문제를 야기 할 수도 있습니다. 나는 그 (것)들을 결코 전에 사용하지 않으며 나는 지금 시작하는 이득을 진짜로보고 있지 않다. 누구든지 그것에 대해 밝힐 수 있습니까?
오라클에 대한 이전의 경험이 있다고하셨습니다. 오라클에서 외래 키 제약 조건을 정의하지 않았습니까? 그렇게했다면 Access에서 관계를 정의 할 때 수행중인 작업입니다. 참조 무결성 (하위 레코드가 존재하는 경우 상위 레코드를 삭제할 수 없음)을 적용하거나 cascade delete 옵션을 사용하는 경우 부모 레코드를 삭제할 경우 하위 레코드를 자동으로 삭제하는 데 사용할 수 있습니다. 관계 (FK)가 정의되지 않은 경우 고아가 될 가능성이있는 하위 레코드를 잊어 버렸을 수도있는 코딩 오류를 처리하는 것은 유용한 백업입니다.
사용 요구 사항이 아니라면 반드시 사용해야 할 필요는 없습니다. 이것이 "필수"일 수있는 유스 케이스는 주문 기반 시나리오에 있습니다.
주문을 생성하고 추적하는 데이터베이스가 있다고 가정 해 보겠습니다. 각 주문은 동일한 주문에 묶여있는 여러 줄을 가질 수 있습니다. 그러나 표준화를 위해 대부분의 사람들은이를 두 개의 개별 테이블로 분리합니다. OrderHead 및 OrderDetail. 부모 Order에 다시 연결하지 않는 OrderDetail에 하위 레코드가 없다는 것을 확인하기 위해 여기에 참조 무결성을 적용하고자 할 것입니다.
나는 당신이 그것 없이는 그런 것들을 막을 수 있다고 확신하지만, 주로 그것을 강요합니다.
관계는 데이터 무결성을 유지하는 데 도움이되며 사용자가 액세스 양식을 입력하면 무결성으로 인한 오류 확률이 적음에 동의합니다. 그러나 앞으로 사용자가 MS Access에서 순수 RDBMS로 이동한다면이 관계가 도움이 될 것입니다.
관계의 목적은 나중의 특정 시점에서의 마이그레이션을위한 것이 아니지만 귀하의 경우에 대해 생각할 수있는 유효한 이유 중 하나입니다.
그 외의 경우 자체 양식 관계가있는 MS Access의 경우 특정 값을 추가하지 못할 수 있습니다.
쿼리를 SQL 모드로 작성하는 경우 관계를 정의해도 아무런 차이가 없습니다. 유용 할 수있는 유일한 방법은 무언가를 만든 다음 몇 달 동안 다시 보지 않았다면 관계를 개념적으로 재빨리 다시 이해할 수 있다는 것입니다.
액세스 쿼리 작성기를 사용하는 사용자는 관계를 정의하면 테이블을 쿼리에 빠르게 추가 할 수 있으며 Access는 쿼리 JOIN에 대해 적절한 (GIGO) 관계를 자동으로 작성합니다. 다시 말하지만, 만약 당신이 SQL로 작성한다면 아마도 이미 그렇게 할 것이므로 질의 작성에 도움이되지 않을 것입니다.
결론 - 다른 사람이 이미 언급 한 것처럼 테이블을 "실제"RDBMS로 내보낼 때까지 쿼리 프로세스를 간소화하는 그래픽 도구에 가깝습니다.
그래서 MySQL 또는 PostgreSQL 또는 Oracle과 같은 다른 테이블에 Access에서 테이블을 내보내려고하면 관계가 정의되지 않습니다. – SandPiper
RDBMS에서 설정해야합니다. 한 번 해본 다음 외래 키의 일부를 다시 작성했습니다. 심각한 것은 아니며 데이터가 손실되지 않습니다. 당신이 이미 그것을 기대한다면 그것은 큰 문제가 아닙니다. 않는 한, 당신은 많은 관계 및/또는 테이블을 가졌다 고 생각합니다. –
단지 데이터를 쿼리하는 사람으로부터 관계가 중요하지 않습니다. 그러나 응용 관점에서 볼 때 매우 중요하지 않은 경우 매우 유용합니다.
예를 들어, 고객의 테이블을 가지고 주문 테이블을 말할 수 있습니다. 비즈니스 규칙은 고객이 처음 있지 않는 한 주문을 작성할 수 없다는 것입니다. 따라서 고객없이 SQL을 자유롭게 작성하여 업데이트/삽입 쿼리가 작동하지 않습니다. 그리고 고객을 삭제해야 할 경우 복잡한 삭제 SQL 문을 작성하지 않고 해당 고객의 모든 주문을 자동으로 삭제할 수 있습니다. 예를 들어 5 년 또는 10 년 이상 된 모든 고객을 삭제할 수 있습니다 (따라서 비활성 상태 임). 고객을 삭제하면 모든 주문도 삭제됩니다. (각 고객에 대한 하위 레코드를 삭제해야하는 경우 작성하는 것이 매우 어려운 쿼리입니다. 강제 적용을 사용하면 모든 하위 레코드가 자동 삭제됩니다 (강제 캐스케이드 삭제).
또한보고 관점에서 중요합니다. 이번 달에 모든 고객과 청구액 합계를 표시하는 쿼리를 작성하면 총 결과가 하나가됩니다. 그러나 고객을 표시하거나 포함하고 싶지 않다면 주문 테이블을 치고 총액을 얻을 수 있습니다. 문제는 RI가 없기 때문에 (우연히 또는 주문 양식을 실행하는 일부 사용자 만) 주문 정보 (총 금액 포함)를 입력했지만 고객이 없을 수도 있습니다.
이제 두 개의 다른 보고서/쿼리를 실행하면 총계가 다르다는 것을 알 수 있습니다. "왜"두 가지 보고서가 서로 다른지에 대한 복잡한 적용에서 매월 판매량에 대한 두 보고서가 서로 동의하지 않는 이유를 파악하기 위해 며칠이 걸릴 수도 있고 많은 데이터가 일주일에 걸릴 수도 있습니다. 고객이 없어도 시스템에 주문을 입력 할 수 없다는 비즈니스 규칙을 시행하면보고에서 그러한 오류를 제거 할 수 있습니다. 당신은 SQL을 완벽하게 사용하지만 많은 코드와 많은 데이터 입력 폼을 가지고 있다고 말할 수 있습니다. 어떻게하면 고객없이 주문을 입력하지 않아도 될까요? 데이터 입력 중 사용자는 해당 주문 양식으로 고객을 입력하는 것을 잊을 수 있습니다. 그리고 고객이 반드시 선택되어야한다는 것을 보증하기 위해 해당 주문 양식으로 코드를 작성하더라도 어쩌면 실수로 SQL을 작성하는 중에 고객없이 주문 레코드를 시스템에 삽입 할 수 있습니다. 그러나 귀하의 월간 고객 총 보고서 쿼리는 합계 주문 데이터에 가입 한 고객 레코드가 있다고 가정합니다.
그러나 일부 보고서는 주문 데이터에서만 실행되어야합니다 (월간 요약 총계는 고객을 포함 할 필요가 없습니다). 문제는 이제 고객이없는 총 데이터가있는 주문 레코드가있는 시스템 어딘가에 있습니다. 결과는 서로 다른 보고서이며 판매 총계는 이제 동의하지 않습니다. 이것은 명백한 악몽이다.
그래서 응용 프로그램 코드의 일부 버그 또는 오류가 발생하여 "고아"레코드가있는 관계형 데이터로 간주되는 내용이 발생할 수 있습니다. 비즈니스 규칙에 따라 고객이 지정되지 않은 상태에서 주문을 입력 할 수는 있지만 매월 판매 보고서에 해당 사실이 표시되거나 주문 테이블을 조회하고 고객을 포함하지 않는 쿼리는 해당 사실을 "확인"해야합니다 고객 레코드가 아직 종료되지 않았다고 쿼리합니다.
위의 내용은 GAZILLION 문제의 표면을 긁는 것일뿐입니다. 따라서 데이터에 단순한 quires를 작성하는 동안, 문제점은 시스템에서 올바르게 연관된 데이터입니까? 쓰레기가 나오는 쓰레기에 관한 오래된 말은 사실입니다.
SQL quires에서 다중 테이블로 데이터를 가져 오는 날이 끝나면 데이터와 관련 무결성 (RI)에 대한 가정을해야합니다. 따라서 고객 및 해당 주문 총계를 표시하기 위해 해당 쿼리를 작성하면 customers 테이블에서 ASSUME 및 drop 한 다음 orders 테이블에서 관계형 조인을 수행합니다. 그러나 고객 레코드가없는 주문이 있으면 쿼리가 올바른 값을 생성하지 않습니다.그리고 주문 테이블을 치는 보고서가 이제는 다른 결과를 만들어 낼 것입니다.
아무리 RI를 강요하면 우연히 주문을 할 수 없으며, 고객 기록을 작성하지 않은 상태에서 주문을 할 수 없습니다. 그러한 규칙을 시행하지 않으면 데이터에서 잘못된 결과가 발생합니다.
일반적인 복잡한 응용 프로그램에는 40 개 또는 70 개의 관련 테이블이 있습니다. 그리고 그 테이블들 중 어느 하나라도 부모 (또는 자녀) 레코드가 귀하의 사업 가정에 따라 올바르게 작성되었다고 가정하는 것으로 가정합니다.
여행 예약 시스템이있을 수 있습니다. 고객이 전화를 걸어 예금을 거절 할 수는 있지만 특정 투어에 예약하지는 못할 수도 있습니다. 이 설정을 허용하면 이번 달의 고객에 대한 쿼리와 예약 된 둘러보기에서이를 고려해야합니다. 그러나 비즈니스 규칙은 돈을 버는 시스템의 모든 고객이 반드시 투어에 예약되어야한다는 것입니다. 따라서 해당 정보를 얻기 위해 쿼리를 작성하면이 규칙이 고려됩니다.
항상 작성한 모든 쿼리가 둘 이상의 테이블의 데이터를 포함하는 것이 아니라면 관계형 데이터 적용으로 많은 이점을 얻지 못할 수 있습니다. 그러나 여러 테이블로 쿼리를 묶는 순간부터 쿼리를 작성하기 전에 해당 데이터에 대한 가정을 알아야합니다. 투어 예약없이 시스템에 입금 된 고객을 허용합니까? 이 규칙은 해당 쿼리를 작성하는 방법을 결정합니다. RI가 시행되면 고객 "예약"에 대해 쿼리 할 수 있으며 투어 이벤트에 첨부된다는 것을 알 수 있습니다. 예약 + 보증금에 예약이 필요하지 않은 경우에도 마찬가지입니다.하지만 해당 데이터에 대한 가정을 알고 있어야합니다.
데이터에 대한 가정을 기반으로 한 가정을 기반으로 데이터를 가져 오는 쿼리를 만드는 유일한 방법이 있습니다. 그리고 RI를 강요하는 경우, 최소한 데이터가 관련성이 있고 그 가정에 따라 설정되어야한다는 것을 알고 있어야합니다.
하루가 끝날 때까지? RI를 강요하지 않으면 서 비즈니스 응용 프로그램과 규칙을 모델링하는 데이터베이스를 만드는 사람은 누구나 방향없이 나침반없이 배를 만들 수 있습니다.
그리고 각 테이블의 데이터를 내보내는 데는 문제가 없습니다. 그러나 해당 데이터가 엉망이고 고아 레코드가있는 경우 잘못된 데이터 모델을 다른 데이터베이스로 내보내고 모든 문제점과 문제점이 남아 있습니다.
몇 가지 사항에 따라 다릅니다. 고급 사용자의 경우 자동 참조 무결성을 제외하고는 실제로 많은 것을 얻지 못할 것입니다. 코드를 효율적으로 처리 할 수는 없습니다. –
관련 (그러나 ODBC 용) : http://stackoverflow.com/q/38468546/3820271 – Andre