Kwerenda usuwająca - usuwa całe rekordy. Działanie to może się odnosić do tabeli lub tabel powiązanych relacją jeden do jednego a także do tabel powiązanych relacją jeden do wielu, uwzględniając tabelę po stronie jeden lub obie tabele w tej relacji. Kwerenda ta usuwa również rekordy w tabeli nie powiązanej relacjami. W przypadku usuwania rekordów w tabeli z relacją jeden do wielu po stronie jeden przy wymuszonych więzach integralności i zaznaczonym usuwaniu kaskadowym, usunięty zostanie również rekord po stronie wiele.
Tworzenie kwerendy usuwającej widok projekt - po otworzeniu wybranej tabeli lub tabel, zmieniamy typ kwerendy na usuwającą. Dla tabeli, z której chcemy usunąć rekordy przenosimy gwiazdkę (*) z listy pól tabeli do tabeli poniżej. W tabeli projektu kwerendy usuwającej jest pole usuwanie. W przypadku przeniesienia (*) w tym polu pokazuje się napis skąd (zdj.1). W celu określenia, dla którego pola ma nastąpić usunięcie, wybierz dane pole z listy pól tabeli. W polu usuwanie pokaże się słowo gdzie, czyli wg. danego pola ustalimy kryterium usuwania. A kryterium to może być dowolne, np. moim polem do kryterium jest IDzamówienia, czyli kryterium będzie się odnosiło do numeru zamówienia. Powiedzmy że usunę stare zamówienia, moje kryterium to <35 (zdj.2).
Opis normalizacji
Normalizacja to proces organizacji danych w bazie danych. Polega on na tworzeniu tabel i ustanawianiu pomiędzy nimi powiązań według reguł obowiązujących zarówno przy ochronie danych, jak i uelastycznianiu bazy danych przez eliminowanie powtarzających się i niespójnych zależności.
Powtarzające się dane niepotrzebnie zajmują miejsce na dysku i są przyczyną powstawania problemów z obsługą. Jeśli konieczna jest zmiana danych istniejących w więcej niż jednej lokalizacji, musi być ona przeprowadzona we wszystkich lokalizacjach w ten sam sposób. Implementacja zmiany adresu klienta jest o wiele łatwiejsza, jeśli dane są przechowywane tylko w tabeli Klienci i w żadnym innym miejscu bazy danych.
Co to jest „niespójna zależność”? O ile przeglądanie tabeli Klienci w poszukiwaniu adresu konkretnego klienta można nazwać zachowaniem intuicyjnym, to poszukiwanie w tej tabeli pensji pracownika obsługującego tego klienta nie ma żadnego sensu. Pensja pracownika jest związana z pracownikiem lub zależy od pracownika i dlatego powinna być przeniesiona do tabeli Pracownicy. Niespójne zależności mogą utrudniać dostęp do danych, ponieważ ścieżka ich odnajdywania może zostać utracona lub uszkodzona.
Istnieje kilka reguł normalizacji baz danych. Każda reguła nosi nazwę „postać normalna”. Jeśli przestrzegana jest pierwsza reguła, o postaci bazy danych mówi się, że jest „pierwszą postacią normalną”. Jeśli przestrzegane są pierwsze trzy reguły, postać bazy danych przyjmuje się za „trzecią postać normalną”. Chociaż możliwe są inne poziomy normalizacji, trzecia postać normalna uważana jest za najwyższy poziom wymagany przez większość aplikacji.
Jak to bywa z wieloma formalnymi regułami i specyfikacjami, rzeczywistość nie zawsze pozwala na ich dokładne odwzorowanie. Ogólnie rzecz biorąc, normalizacja wymaga dodatkowych tabel i dla niektórych osób jest to uciążliwe. Przed podjęciem decyzji o złamaniu jednej z pierwszych trzech reguł normalizacji należy upewnić się, że projekt aplikacji przewiduje występowanie problemów, takich jak powtarzające się dane lub niespójne zależności.
Do poniższych opisów dodane zostały przykłady.
Pierwsza postać normalna
• |
W poszczególnych tabelach wyeliminuj powtarzające się grupy. |
• |
Dla każdego zestawu danych pokrewnych utwórz oddzielną tabelę. |
• |
Dla każdego zestawu danych pokrewnych określ klucz podstawowy. |
Do przechowywania podobnych danych w jednej tabeli nie należy używać wielu pól. Na przykład rekord służący do śledzenia pozycji magazynowej, która może pochodzić z dwóch różnych źródeł, może zawierać pola Kod sprzedawcy 1 oraz Kod sprzedawcy 2.
Co się zdarzy po dodaniu trzeciego sprzedawcy? Dodanie pola nie jest rozwiązaniem. Wymaga to modyfikacji programu i tabel oraz nie umożliwia obsługi zmieniającej się dynamicznie liczby sprzedawców. Zamiast tego należy umieścić wszystkie informacje o sprzedawcach w oddzielnej tabeli o nazwie Sprzedawcy, a następnie połączyć magazyn ze sprzedawcami za pomocą klucza z numerem pozycji, albo sprzedawców z magazynem za pomocą klucza z kodem sprzedawcy.
Druga postać normalna
• |
Utwórz oddzielne tabele dla zestawów wartości, odnoszących się do wielu rekordów. |
• |
Ustal powiązania tabel za pomocą klucza obcego. |
Rekordy nie powinny zależeć od niczego innego tylko od klucza podstawowego tabeli (w razie potrzeby może to być klucz złożony). Rozważmy na przykład adres klienta w systemie księgowym. Obecność adresu konieczna jest w tabeli Klienci, ale również w tabelach Zamówienia, Wysyłka, Faktury, Należności i Inkaso. Zamiast przechowywać adres w postaci wpisu w każdej tabeli, przechowuje się go w jednym miejscu: albo w tabeli Klienci, albo w oddzielnej tabeli Adresy.
Trzecia postać normalna
• |
Wyeliminuj pola, które nie zależą od klucza. |
Wartości rekordu, które nie są częścią jego klucza, nie należą do tabeli. Zazwyczaj, jeśli zawartość grupy pól odnosi się do więcej niż jednego rekordu tabeli, należy rozważyć umieszczenie tych pól w oddzielnej tabeli.
Na przykład w tabeli Rekrutacja pracowników może znajdować się nazwa i adres uczelni, którą ukończył kandydat. Do korespondencji seryjnej potrzebna jest jednak kompletna lista uczelni. Jeśli informacje o uczelniach przechowywane są w tabeli Kandydaci, nie ma możliwości wyświetlenia listy uczelni bez aktualnych kandydatów. Utwórz oddzielną tabelę Uczelnie i połącz ją z tabelą Kandydaci za pomocą klucza z kodem uczelni.
WYJĄTEK: Stosowanie reguł trzeciej postaci normalnej, chociaż teoretycznie wskazane, nie zawsze jest praktyczne. Chcąc wyeliminować wszystkie możliwe wewnętrzne zależności pomiędzy polami tabeli Klienci, należałoby utworzyć oddzielne tabele dla miast, kodów pocztowych, przedstawicieli handlowych, klas klienta i innych czynników, które mogą być zduplikowane w wielu rekordach. Normalizacja oznacza teoretycznie poprawę wydajności. Jednak wiele mniejszych tabel może spowodować spadek wydajności lub brak możliwości otwarcia pliku i przekroczenie pojemności pamięci.
Bardziej realne może okazać się zastosowanie trzeciej postaci normalnej tylko do często zmienianych danych. Pozostawiając niektóre pola zależne, zmień projekt aplikacji tak, aby po zmianie dowolnego pola wymagała od użytkownika sprawdzenia wszystkich pól pokrewnych.
Inne postacie normalizacji
Istnieje czwarta postać normalna, zwana również postacią normalną Boyce'a-Codda (BCNF) oraz piąta postać normalna, ale są one rzadko wykorzystywane w praktyce. Zlekceważenie tych reguł może skutkować mniej doskonałym projektem bazy danych, ale nie powinno ono wpływać na funkcjonalność.
Normalizowanie tabeli przykładowej
W poniższych krokach przedstawiono proces normalizacji fikcyjnej tabeli studentów.
1. |
Tabela nieznormalizowana: |
||||||||||||||
|
|
NrStudenta |
Doradca |
Pok-Dor |
Klasa1 |
Klasa2 |
Klasa3 |
|
|||||||
|
|
1022 |
Nowak |
412 |
101-07 |
143-01 |
159-02 |
|
|||||||
|
|
4123 |
Kowalski |
216 |
201-01 |
211-02 |
214-01 |
|
|||||||
|
|
||||||||||||||
2. |
Pierwsza postać normalna: brak powtarzających się grup |
||||||||||||||
|
|
NrStudenta |
Doradca |
Pok-Dor |
NrKlasy |
|
|||||||||
|
|
1022 |
Nowak |
412 |
101-07 |
|
|||||||||
|
|
1022 |
Nowak |
412 |
143-01 |
|
|||||||||
|
|
1022 |
Nowak |
412 |
159-02 |
|
|||||||||
|
|
4123 |
Kowalski |
216 |
201-01 |
|
|||||||||
|
|
4123 |
Kowalski |
216 |
211-02 |
|
|||||||||
|
|
4123 |
Kowalski |
216 |
214-01 |
|
|||||||||
|
|
||||||||||||||
3. |
Druga postać normalna: eliminowanie powtarzających się danych |
||||||||||||||
|
|
NrStudenta |
Doradca |
Pok-Dor |
|
||||||||||
|
|
1022 |
Nowak |
412 |
|
||||||||||
|
|
4123 |
Kowalski |
216 |
|
||||||||||
|
|
||||||||||||||
|
|
NrStudenta |
NrKlasy |
|
|||||||||||
|
|
1022 |
101-07 |
|
|||||||||||
|
|
1022 |
143-01 |
|
|||||||||||
|
|
1022 |
159-02 |
|
|||||||||||
|
|
4123 |
201-01 |
|
|||||||||||
|
|
4123 |
211-02 |
|
|||||||||||
|
|
4123 |
214-01 |
|
|||||||||||
|
|
||||||||||||||
4. |
Trzecia postać normalna: eliminowanie danych, które nie zależą od klucza |
||||||||||||||
|
|
NrStudenta |
Doradca |
|
|||||||||||
|
|
1022 |
Nowak |
|
|||||||||||
|
|
4123 |
Kowalski |
|
|||||||||||
|
|
||||||||||||||
|
|
Nazwa |
Pokój |
Wydział |
|
||||||||||
|
|
Nowak |
412 |
42 |
|
||||||||||
|
|
Kowalski |
216 |
42 |
|
||||||||||
|
|