Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:dydaktyka:ztb:2010:projekty:z_impetem:start [2010/06/28 08:56] ztb2010 |
pl:dydaktyka:ztb:2010:projekty:z_impetem:start [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 354: | Linia 354: | ||
| **Druga postać normalna** | **Druga postać normalna** | ||
| Pierwsza postać normalna wymagała wskazania klucza głównego w każdej z tabel bazy danych. Klucz główny może się składać z jednej lub wielu kolumn. Pełni on funkcję unikalnego identyfikatora rekordu. Zgodnie z drugą postacią normalną nie mogą istnieć żadne nawet częściowe zależności pomiędzy jakimikolwiek kolumnami wchodzącymi w skład klucza głównego. Nasza baza danych spełnia drugą postać normalną ponieważ w żadnej tabeli nie wystepuje pola, które by zależały od innego pola tej tabeli. Przykładowo druga postać normalna by nie była spełniona jeżeli np. posiadalibyśmy tabelę w której mielibyśmy dwa klucze główne idUser oraz idWorld. Najlepszym sposobem na rozwiązanie tego problemu byloby rozdzielenie danych na dwie tabele oraz utworzenie trzeciej, która będzie zawierała identyfikatory użytkownika oraz świata. | Pierwsza postać normalna wymagała wskazania klucza głównego w każdej z tabel bazy danych. Klucz główny może się składać z jednej lub wielu kolumn. Pełni on funkcję unikalnego identyfikatora rekordu. Zgodnie z drugą postacią normalną nie mogą istnieć żadne nawet częściowe zależności pomiędzy jakimikolwiek kolumnami wchodzącymi w skład klucza głównego. Nasza baza danych spełnia drugą postać normalną ponieważ w żadnej tabeli nie wystepuje pola, które by zależały od innego pola tej tabeli. Przykładowo druga postać normalna by nie była spełniona jeżeli np. posiadalibyśmy tabelę w której mielibyśmy dwa klucze główne idUser oraz idWorld. Najlepszym sposobem na rozwiązanie tego problemu byloby rozdzielenie danych na dwie tabele oraz utworzenie trzeciej, która będzie zawierała identyfikatory użytkownika oraz świata. | ||
| + | |||
| + | **Trzecia postać normalna** | ||
| + | Trzecia postać normalna ma charakter opcjonalny a jej stosowanie w znacznej mierze jest uzależnione od okoliczności. Tabele znajdują się w trzeciej postaci normalnej tylko wtedy, gdy spełniają następujące warunki: tablele znajdują się w drugiej postaci normalnej oraz wszystkie pola, które nie należa do klucza głównego są od niego zależne. Zależność pól spoza klucza głównego dotyczy oczywiście zawartych w nim danych. Nasza baza danych spełnia trzecia postać normalna ponieważ tabela address_user zawiera pola takie jak ulica, numer domu, miasto, państwo i idPostcode, który jest identyfikatorem tabeli postcode_table zawierającej kody pocztowe miejscowości. Widać tutaj, że dane dotyczące adresu śa ścisle związane z kodem pocztowym. Kiedy wysyła sie list to nazwa ulicy, numer domu, miejscowość i wlaśnie kod pocztowy wystarczą do odnalezienia własciwego adresu. Zaletą trzeciej postaci normalnej jest spójność danych. Wydobywanie odpowiednich danych z bazy danych zgodnej z trzecia postacią normalną trwa dlużej. W przypadku małych baz różnice są minimalne, jednak z punktu widzenia użytkowników baz danych z tysiącami lub milionami rekordów takaie spowolnienie może mieć olbrzymie znaczenie. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| ==== Implementacja ==== | ==== Implementacja ==== | ||
