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/25 15:14] sebi |
pl:dydaktyka:ztb:2010:projekty:z_impetem:start [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 203: | Linia 203: | ||
| ==== Diagram struktury bazodanowej ==== | ==== Diagram struktury bazodanowej ==== | ||
| - | {{:pl:dydaktyka:ztb:2010:projekty:z_impetem:baza.png|}} | + | {{:pl:dydaktyka:ztb:2010:projekty:z_impetem:bazaNowa.jpeg|}} |
| Linia 345: | Linia 345: | ||
| ==== Koszta utrzymania ==== | ==== Koszta utrzymania ==== | ||
| - | Roczny koszt utrzymania hostingu i domeny będzie wynosił ok. 300zł. Na początek jest możliwość wykupienia w promocji serwera za 100zł na pół roku i w razie powodzenia projektu możliwość przedłużenia współpracy. | + | Roczny koszt utrzymania hostingu i domeny będzie wynosił ok. 300zł. Na początek jest możliwość wykupienia w promocji serwera za 100zł na pół roku i w razie powodzenia projektu możliwość przedłużenia współpracy. |
| + | |||
| + | ==== Postacie normalne ==== | ||
| + | |||
| + | **Pierwsza postać normalna** | ||
| + | Baza danych spełniająca pierwszą postać normalną musi składać się z tabel, które zawierają dane wzajemnie powiązane, musi zawierać unikalne powiązanie pewnych grup danych oraz muszą byc wskazane klucze główne poszczególnych tabel. Nasza baza danych spełnia pierwszą postać normalną ponieważ wszystkie tabele posiadają ściśle ze sobą powiązane dane np. tabela user_table posiada informacje na temat użytkownika takie jak jego imie, nazwisko, adres, adres e-mail. Wszystkie dane w tej tabeli są ze sobą ścisle powiązanie, nie ma niepotrzebnych lub powielających się elementów. Po rozdzieleniu danych pomiędzy tabele należało je powiązać ze sobą za pomocą unikalnych wartości zwanych identyfikatorami, dlatego każda tabela w naszej bazie posiada klucz główny, np. tabela abstractuser_table posiada identyfikator o nazwie id. Należy pamiętać, że stosowanie dodatkowych identyfikatorów jest korzystne ze względu na wyższą efektywność przeszukiwania danych. | ||
| + | |||
| + | **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. | ||
| + | |||
| + | **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 ==== | ||
| + | |||
| **pom.xml** | **pom.xml** | ||
| Linia 388: | Linia 405: | ||
| **hibernate.cfg.xml** | **hibernate.cfg.xml** | ||
| - | <code> | + | <code xml> |
| <?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | ||
| <!DOCTYPE hibernate-configuration PUBLIC | <!DOCTYPE hibernate-configuration PUBLIC | ||
| Linia 427: | Linia 444: | ||
| **user.hbm.xml** | **user.hbm.xml** | ||
| - | <code> | + | <code xml> |
| <?xml version="1.0"?> | <?xml version="1.0"?> | ||
| Linia 466: | Linia 483: | ||
| **user.java** | **user.java** | ||
| - | <code> | + | <code java> |
| package org.lukasz.gra.model; | package org.lukasz.gra.model; | ||
| Linia 547: | Linia 564: | ||
| **Dao.java** | **Dao.java** | ||
| - | <code> | + | <code java> |
| package org.lukasz.gra.persistence; | package org.lukasz.gra.persistence; | ||
| import java.util.logging.Level; | import java.util.logging.Level; | ||
| Linia 609: | Linia 626: | ||
| **userDao.java** | **userDao.java** | ||
| - | <code> | + | <code java> |
| package org.lukasz.gra.persistence; | package org.lukasz.gra.persistence; | ||
