jaka jest różnica pomiędzy wyzwalaczami, twierdzeniami i sprawdzeniami (w bazie danych)

W standardzie SQL zarówno twierdzenia, jak i ograniczenia sprawdzania są tym, co teoria relacyjna nazywa "ograniczeniami": regułami, z którymi dane faktycznie zawarte w bazie danych muszą być zgodne.

Różnica między nimi polega na tym, że ograniczenia kontroli są w pewnym sensie znacznie "prostsze" : są to reguły odnoszące się tylko do jednego wiersza, podczas gdy twierdzenia mogą dotyczyć dowolnej liczby innych tabel lub dowolnej liczby innych wierszy w tej samej tabeli. To oczywiście sprawia, że (dużo !) bardziej złożone dla konstruktorzy DBMS, aby go wspierać, i to jest z kolei powód, dlaczego tego nie robią : po prostu nie wiedzą, jak to zrobić.

Wyzwalacze to fragmenty kodu wykonywalnego, z których można zadeklarować DBMS, że powinny one być wykonywane za każdym razem, gdy pewna operacja aktualizacji (insert/delete / update) zostanie wykonana w określonej tabeli. Ponieważ wyzwalacze mogą wywoływać wyjątki, są one środkiem do implementacji tego samego twierdzenia. Jednak z wyzwalaczami, to wciąż programista, który musi zrobić kodowanie i nie popełnić żadnego błędu.

EDIT

Onedaywhen ' s comments re. ASSERTION / CHECK cnstr. są poprawne. Różnica jest o wiele bardziej subtelna (i myląca). Standard rzeczywiście pozwala zapytań podrzędnych w ograniczeniach kontroli. (Większość produktów go nie obsługuje, więc moje "odnoszą się do jednego wiersza" jest prawdziwe dla większości produktów SQL, ale nie dla standardu. Czy jest jeszcze jakaś różnica ? Tak, wciąż jest. Więcej niż jeden.

Pierwszy przypadek: TABLE MEN (ID: INTEGER) oraz TABLE WOMEN (ID:INTEGER). Teraz wyobraź sobie zasadę, że "żadna wartość ID nie może pojawić się zarówno w tabeli mężczyzn, jak i kobiet". To jedna zasada. Celem twierdzenia jest właśnie to, że projektant bazy danych określi tę pojedynczą regułę [i będzie z nią zrobiony], a DBMS będzie wiedział, jak sobie z tym poradzić [oczywiście efektywnie] i jak wyegzekwować tę regułę, bez względu na to, jaka konkretna aktualizacja zostanie wykonana w bazie danych. W przykładzie DBMS wiedziałby, że musi sprawdź tę regułę po wstawieniu do mężczyzn i po wstawieniu do kobiet, ale nie po usunięciu z mężczyzn/kobiet, lub wstaw do .

Ale DBMS nie są wystarczająco inteligentne, aby to wszystko zrobić. Co zatem należy zrobić ? Projektant bazy danych musi dodać dwa ograniczenia wyboru do swojej bazy danych, jeden do tabeli mężczyzn (sprawdzanie nowo wstawionych identyfikatorów mężczyzn względem tabeli kobiet) i jeden do tabeli kobiet (sprawdzanie odwrotnie). Jest twoja pierwsza różnica : jedna zasada, jedna Twierdzenie, dwa sprawdzanie ograniczeń. Ograniczenia kontroli są niższym poziomem abstrakcji niż twierdzenia, ponieważ wymagają od projektanta większego myślenia o (A) wszystkich rodzajach aktualizacji, które potencjalnie mogą spowodować naruszenie jego twierdzenia, oraz (b) jakie szczególne kontrole powinny być przeprowadzane dla każdego z konkretnych "rodzajów aktualizacji", które znalazł w (a). (Chociaż nie lubię robić" absolutnych "stwierdzeń o tym, co wciąż jest "czym", a co "jak", podsumowałbym ograniczenia te wymagają więcej myślenia" jak "(proceduralnego) przez projektanta baz danych, podczas gdy twierdzenia pozwalają projektantowi baz danych skupić się wyłącznie na" co " (deklaratywnym).)

Drugi przypadek ( choć nie jestem tego do końca pewien - więc weź z przymrużeniem oka): po prostu twoja Przeciętna zasada RI. Oczywiście są używane do określenia tego za pomocą klauzuli reference. Ale wyobraź sobie, że klauzula odniesienia nie była dostępna. Zasada " każde zamówienie musi być złożone przez znanego klienta" jest to tak naprawdę tylko reguła , a więc jedno twierdzenie. Jednak wszyscy wiemy, że taka zasada zawsze może zostać naruszona na dwa sposoby: wstawianie zamówienia (w tym przykładzie) i usuwanie klienta. Teraz, zgodnie z powyższym przykładem Mężczyzna / Kobieta, gdybyśmy chcieli zaimplementować tę pojedynczą regułę / twierdzenie za pomocą ograniczeń sprawdzania, musielibyśmy napisać ograniczenie sprawdzania, które sprawdza istnienie klienta po wstawieniu do porządku, ale jakie ograniczenie sprawdzania możemy napisać, które robi to, co jest potrzebne po usunięciu od klienta ? Po prostu nie są zaprojektowane do tego celu, o ile mogę powiedzieć. Jest druga różnica : ograniczenia wyboru są związane wyłącznie z wstawianiem, twierdzenia mogą definiować reguły, które będą również sprawdzane przy usuwaniu.

Trzeci przypadek: Imagine a table COMPOS (componentID:... procent: liczba całkowita), a zasada mówiąca, że "suma wszystkich procentów musi być zawsze równa 100". To jedna reguła, a twierdzenie jest zdolne do / align = "left" / Ale spróbuj i wyobraź sobie, jak można przejść o egzekwowanie takiej zasady z ograniczeń kontroli ... Jeśli masz poprawną tabelę z, powiedzmy, trzema niezerowymi wierszami, które sumują się do stu, jak zastosujesz jakąkolwiek zmianę do tej tabeli, która mogłaby przetrwać ograniczenie czeku ? Nie można usunąć ani zaktualizować(zmniejszyć) żadnego wiersza bez konieczności dodawania innych zastępujących wierszy lub aktualizacji pozostałych wierszy, które sumują się do tego samego procentu. Podobnie dla insert lub update (increase). Potrzebowałbyś odroczenia przynajmniej sprawdzanie ograniczeń, a potem co zamierzasz sprawdzić ? Jest trzecia różnica : ograniczenia sprawdzania są ukierunkowane na poszczególne wiersze, podczas gdy twierdzenia mogą również definiować / wyrażać reguły, które "obejmują" kilka wierszy (np. reguły dotyczące agregacji wierszy).

Twierdzenia nie modyfikują danych, sprawdzają tylko określone warunki

Wyzwalacze są potężniejsze, ponieważ mogą sprawdzać warunki, a także modyfikować dane

--------------------------------------------------------------------------------

Twierdzenia nie są powiązane z konkretnymi tabelami w bazie danych i nie są powiązane z konkretnymi zdarzeniami

Wyzwalacze są powiązane z konkretnymi tabelami i konkretnymi zdarzeniami

Ograniczenie bazy danych obejmuje warunek, który musi być spełniony, gdy baza danych jest aktualizowana. W SQL, jeśli warunek ograniczenia zostanie obliczony na false, to aktualizacja nie powiedzie się, dane pozostaną niezmienione, a DBMS wygeneruje błąd.

Zarówno CHECK jak i {[2] } są ograniczeniami baz danych zdefiniowanymi przez standardy SQL. Ważną różnicą jest to, że CHECK jest stosowana do określonej tabeli bazowej, podczas gdy {[2] } jest stosowana do całej bazy danych. Rozważmy ograniczenie, które ogranicza połączone wiersze w tabelach T1 i T2 W sumie 10 wierszy, np.

CHECK (10 >= (
              SELECT COUNT(*)
                FROM (
                      SELECT *
                        FROM T1
                      UNION
                      SELECT * 
                        FROM T2
                     ) AS Tn
             ))

Załóżmy, że tabele są puste. Jeśli zostanie to zastosowane tylko jako ASSERTION i użytkownik spróbuje wstawić 11 wierszy do T1, wtedy aktualizacja nie powiedzie się. To samo miałoby zastosowanie, gdyby ograniczenie było stosowane jako ograniczenie CHECK Tylko do T1. Jednak, jeśli ograniczenie zostanie zastosowane jako CHECK ograniczenie do T2 tylko ograniczenie powiedzie się, ponieważ polecenie targeting T1 nie powoduje ograniczeń stosowane do T1 do badania.

Zarówno an ASSERTION, jak i a CHECK mogą zostać odroczone (jeśli zadeklarowane jako DEFERRABLE), co pozwala na czasowe naruszenie warunku ograniczenia, ale tylko w ramach transakcji.

ASSERTION i CHECK ograniczenia związane z zapytaniami podrzędnymi są funkcjami poza podstawowym standardem SQL i żaden z głównych produktów SQL nie obsługuje tych funkcji. MS Access (niezupełnie przemysłowy produkt) obsługuje CHECK ograniczenia dotyczące zapytań podrzędnych, ale nie można ich odroczyć ograniczenia Plus testowanie ograniczeń jest zawsze wykonywane wiersz po wierszu, a praktyczne konsekwencje są takie, że funkcjonalność jest bardzo ograniczona.

W połączeniu z ograniczeniami CHECK, wyzwalacz jest stosowany do określonej tabeli. Dlatego wyzwalacz może być użyty do implementacji tej samej logiki co ograniczenie CHECK, ale nie ASSERTION. Wyzwalacz jest kodem proceduralnym i w przeciwieństwie do ograniczeń, użytkownik musi wziąć znacznie większą odpowiedzialność za problemy, takie jak wydajność i obsługa błędów. Najbardziej komercyjne produkty SQL obsługują wyzwalacze (wspomniany MS Access nie).

Wyrażenie powinno być prawdziwe dla trigger to fire, ale check będzie obliczany wszędzie tam, gdzie wyrażenie jest fałszywe.