W relacyjnej bazie danych tabele są często połączone zależnościami klucza obcego (FOREIGN KEY). Klucz obcy wymusza integralność referencyjną, czyli to, że wartości w kolumnie odwołującej się muszą wskazywać na istniejący wiersz w tabeli nadrzędnej.
Dlatego przed usunięciem tabeli należy ustalić, czy jest ona tabelą nadrzędną dla innych tabel (czyli czy inne tabele mają do niej FK). Jeśli tak, operacja usunięcia może:
- zostać odrzucona przez system bazy danych z powodu istniejących ograniczeń,
- albo (w zależności od konfiguracji) wymagać wcześniejszego usunięcia/zmiany constraintów lub danych,
- spowodować awarie logiki aplikacji, która zakłada istnienie tej tabeli i jej relacji.
Odpowiedź "Sprawdzić, czy tabela jest używana jako klucz obcy w innych tabelach, a następnie usunąć." jest poprawna, bo opisuje właściwą kolejność: najpierw analiza zależności, potem dopiero zmiana schematu.
Opcja "Usunąć tabelę bez sprawdzania." jest ryzykowna: w praktyce często kończy się błędem wykonania (DROP TABLE nie przejdzie) albo problemami z integralnością i działaniem aplikacji.
Opcja "Usunąć wszystkie tabele, a następnie odtworzyć je bez tej tabeli." jest nieadekwatna: to działanie skrajne, grozi utratą danych i nie jest standardową praktyką administracyjną.
Opcja "Zmienić strukturę tabeli, aby nie była używana jako klucz obcy." jest myląca: to nie tabela nadrzędna "jest używana jako FK", tylko inne tabele mają klucze obce wskazujące na nią. Aby rozwiązać problem, zwykle modyfikuje się constrainty w tabelach zależnych lub plan migracji, a nie "ukrywa" tabelę zmianą jej struktury.
Wskazówka egzaminacyjna: przy pytaniach o usuwanie obiektów w bazie szukaj odpowiedzi, która uwzględnia zależności (FK) i integralność, a nie najszybszą operację.
