Co to jest koncepcja Key Preserved Table?

Przeczytałem w Dokumentacji Oracle o tabeli z kluczem w sekcji Aktualizacja widoków dołączania.

Nie znalazłem jednak żadnego prostego sposobu, aby to zrozumieć.

Mam nadzieję, że otrzymam kilka prostych szczegółów koncepcyjnych innych niż oficjalna Dokumentacja Oracle.

Zachowany klucz oznacza, że ​​1 wartość klucza trafia do 1 tabeli. Podanie przykładów może pomóc lepiej zrozumieć tę koncepcję.

Przykład 1:

Twój widok zawiera agregację. Załóżmy, że masz następującą strukturę widoku.

GroupID, AverageSalary
1 , 10000
2, 12000
3, 14000

W tym przykładzie: twoje wartości pochodzą z więcej niż jednego wiersza. Jeśli spróbujesz zaktualizować AverageSalary w tym widoku, baza danych nie będzie mogła znaleźć TYCH wierszy do zaktualizowania.

Przykład 2: Twój widok pokazuje wartości z więcej niż jednej tabeli. Twój widok pokazuje wartości z tabeli PERSON i PERSON_CONTACT_DETAILS (ID, PersonID, ContactType, ContactValue).

Przykładowe wiersze:

 1,1,email,ddd@example.com
 1,1,phone,898-98-99

Dołączasz do tabeli 2 i wyświetlasz bardziej przyjazne dla biznesu informacje.

PersonId, Name, LastName, Phone1, Email1

Tutaj chcesz zaktualizować Phone1 i Email1. Ale twój personID odwzorowuje na dwa różne wiersze, w tym przykładzie może być więcej wierszy. W tym widoku ponownie baza danych nie ma możliwości znalezienia KTÓRYCH wierszy do zaktualizowania.

Uwaga: jeśli ograniczysz widok sql i jasno określisz, które wiersze do aktualizacji mogą działać.

Ten dwa przykłady to pierwsze przykłady, które przychodzą mi na myśl. Można je zwiększyć. Ale koncepcja jest jasna. Baza danych musi odwzorować 1 wartość klucza na 1 tabelę. Na przykład masz tabele PERSON jeden do jednego, PERSON_DETAILS. Tutaj widok i aktualizacja będą działać, ponieważ są one jeden do jednego.

Dokumentacja już czytać mówi całkiem dobrze. Aby wyjaśnić dalej:

Koncepcja tabeli z kluczem jest kluczowa dla zrozumienia ograniczeń dotyczących modyfikowania widoków łączenia.

Zwykle updatedziała na jednym stole. Aby uniknąć krętych podkwerend w filtrze, Oracle pozwala na updatewidok (lub podkwerendę), o ile nadal jest w stanie łatwo zmapować dokonane zmiany na rzeczywistych wierszach tabeli. Jest to możliwe, jeśli setklauzula modyfikuje tylko kolumny w tabeli „z zachowaniem klucza”:

Tabela jest zachowywana w kluczu, jeśli każdy klucz w tabeli może być również kluczem wyniku połączenia. Tak więc tabela z kluczami ma swoje klucze zachowane przez złączenie.

Na przykład:

create table foo( foo_id integer primary key, foo_val integer not null );
create table bar( bar_id integer primary key, bar_val integer not null, 
                  foo_id integer not null references foo );

update (select * from foo join bar using(foo_id)) set foo_val=1;
ORA-01779: cannot modify a column which maps to a non key-preserved table

update (select * from foo join bar using(foo_id)) set bar_val=1;
0 rows updated.

Pierwsza aktualizacja nie powiedzie się, ponieważ Oracle nie ma możliwości mapowanie 1: 1 foo_valw zapytaniu do foo_valw foo- odwrotnie druga zmiana powiedzie, ponieważ Oracle może 1: 1 map każdy bar_valdo bar_valw bar. Ważną rzeczą jest to, że foo_idjest unikalny w foo- więc dla każdego wiersza w barmoże być tylko jeden odpowiadający wiersz foo(właściwie dokładnie 1 w tym przykładzie, ale to samo dotyczy dopuszczalnego klucza obcego - chodzi o to, że nigdy nie ma więcej niż jeden rząd).

Najpierw dam przykład i wyjaśnię go później. Rozważ 2 tabele Studenci (t_students) i Kurs (t_course).

• Tabela uczniów (stundentid, name, courseid) ma klucz podstawowy na legitymacji studenckiej.
• Tabela kursów (courseid, coursename) ma klucz podstawowy na ID kursu.

Po połączeniu tych dwóch tabel ->

select * from t_students S, t_course C where S.courseid=C.courseid; 

Wynikowe dane będą miały dokładnie taką samą liczbę wierszy jak tabela Studentów. W zestawie wyników nie będzie zduplikowanych wartości studentid (studentid zostanie zachowany). Jednak, chociaż Courseid jest unikalny w tabeli kursów, będzie powtarzany wiele razy w zestawie wyników, ponieważ wielu studentów mogło zdecydować się na ten sam kurs (innymi słowy, Courseid nie jest zachowany).

Na podstawie tego przykładu możesz dojść do wniosku, że:

• Każdy klucz w tabeli podstawowej działa jako klucz do danych wynikowych po dołączeniu (studentid)
• Wiersze z wiersza podstawowego pojawiają się w wynikowym atmost danych tylko raz. (Bez duplikatów wierszy)

Jest to koncepcja kluczowych konserwowanych tabel.

Aby wiedzieć, czy kolumny widoku można aktualizować,

select * from all_updatable_columns where table_name='V_VIEW_NAME';

PS: podaj nazwę tabeli / widoku dużymi literami.