Normalizacja bazy
jh - 13-03-2006 11:27
Normalizacja bazy
Jeszcze na kartce - projektuję bazę, w miarę uporządkowałem pola, relacje.
Jedna z tabel ma około 30 pól. Jest to tabela, wg na której najczęściej bedą
odbywały się odpytywania przez użytkowników. Wiele pól z tej bazy odwołuje
się do tabel pomocnicznych. Moje pytanie: kiedy i czy w ogóle powinnienem
podzielić taką tabelę na dwie - na np. tabelę główą i tabelę szczegółową
(1:1)? Czy taki podział znacząco poprawia wydajność bazy, jeżeli w głównym
widoku programu korzystającego z bazy będę pokazywał dane z tej tabeli
głównej, a po otworzeniu właściwości elementu dopiero dane z tej
szczegółowej tabeli?
Jacek
Artur Muszynski - 13-03-2006 11:27
"jh" <jh@radio.kielce.com.pl> wrote in message news:dv3hdc$4qg$1@nemesis.news.tpi.pl...
> Jeszcze na kartce - projektuję bazę, w miarę uporządkowałem pola, relacje.
> Jedna z tabel ma około 30 pól. Jest to tabela, wg na której najczęściej bedą
> odbywały się odpytywania przez użytkowników. Wiele pól z tej bazy odwołuje
> się do tabel pomocnicznych. Moje pytanie: kiedy i czy w ogóle powinnienem
> podzielić taką tabelę na dwie - na np. tabelę główą i tabelę szczegółową
> (1:1)? Czy taki podział znacząco poprawia wydajność bazy, jeżeli w głównym
> widoku programu korzystającego z bazy będę pokazywał dane z tej tabeli
> głównej, a po otworzeniu właściwości elementu dopiero dane z tej
> szczegółowej tabeli?
Jeśli celem ma być wyłącznie "optymalizacja", to nie dziel. Możesz tylko pogorszyć (ze względu na złączenia).
artur
>
> Jacek
>
>
Kazek Kurz - 15-03-2006 10:39
jh wrote:
> Jeszcze na kartce - projektuję bazę, w miarę uporządkowałem pola, relacje.
> Jedna z tabel ma około 30 pól. Jest to tabela, wg na której najczęściej bedą
> odbywały się odpytywania przez użytkowników. Wiele pól z tej bazy odwołuje
> się do tabel pomocnicznych. Moje pytanie: kiedy i czy w ogóle powinnienem
> podzielić taką tabelę na dwie - na np. tabelę główą i tabelę szczegółową
> (1:1)? Czy taki podział znacząco poprawia wydajność bazy, jeżeli w głównym
> widoku programu korzystającego z bazy będę pokazywał dane z tej tabeli
> głównej, a po otworzeniu właściwości elementu dopiero dane z tej
> szczegółowej tabeli?
Co sie stanei jak usuniesz krotke?
Czy usowajac z takiej tabeli krotke stracisz cos istotnego czy nie?
kazek
--
O ktorym Wojtek Wierba napisal:
Kiedyś mówiło się "cogito ergo sum".
No Kazek chyba powiedzialby jednak:
"cogito ergo zum" co tlumaczy sie jako
"... jezdem"
jh - 15-03-2006 10:39
Użytkownik "Kazek Kurz" <kakaz@tlendwuczasteczkowy.pl> napisał w wiadomości
news:dv4eej$meu$2@news.mm.pl...
> Co sie stanei jak usuniesz krotke?
> Czy usowajac z takiej tabeli krotke stracisz cos istotnego czy nie?
Nie bardzo rozumiem Twoje pytanie... Usuwając rekord z głównej tabeli, muszę
usunąć rekord z tabeli szczegółowej. A czy stracę istotne dane? One są tak
samo ważne jak każde inne....
Jacek
Kazek Kurz - 15-03-2006 10:40
jh wrote:
> Użytkownik "Kazek Kurz" <kakaz@tlendwuczasteczkowy.pl> napisał w
> wiadomości news:dv4eej$meu$2@news.mm.pl...
>> Co sie stanei jak usuniesz krotke?
>> Czy usowajac z takiej tabeli krotke stracisz cos istotnego czy nie?
> Nie bardzo rozumiem Twoje pytanie... Usuwając rekord z głównej tabeli,
> muszę usunąć rekord z tabeli szczegółowej. A czy stracę istotne dane?
> One są tak samo ważne jak każde inne....
Klasyczny przyklad: tabela lekarz-pacjent-choroba-adres-lek
usowajac z takiej tabeli pacjenta ( bo wyzdrowial) stracisz informacje
zarowno o leczonej chorobie, jak i o zaordynowanych lekach. Podczas gdy
nazwisko pacjenta ktory wyzdrowial moze byc niewazne, liczba
przepisanych lekow lub leczonych chorob moze byc potrzebna np. w celach
statystycznych.
jesli zatem takie sa wymogi, zeby te informacje trzymac, nie moga byc
one trzymane w jednej tabeli, bo pacjentow zdrowych nie chcemy trzymac w
bazie, a chorzy musieliby zostac usunieci razem z choroba.
takie rozumowanie jest wyjsciem do II postaci normalnej a sa i wyzsze.
generalnie jesli zaczniesz projektowac baze w metodologii obiektowej (
pacjent, lekarz, lek, choroba) jeden do jednego/jeden do wielu w ww
obiektach, kazdy obiekt to tabela, doataniesz wlasnie baze w II postaci
normalnej, jest wiec to relatywnie proste.
Szczegoly-> ksiazka o projektowaniu baz danych
kazek
--
O ktorym Wojtek Wierba napisal:
Kiedyś mówiło się "cogito ergo sum".
No Kazek chyba powiedzialby jednak:
"cogito ergo zum" co tlumaczy sie jako
"... jezdem"
jh - 15-03-2006 10:40
Użytkownik "Kazek Kurz" <kakaz@tlendwuczasteczkowy.pl> napisał w wiadomości
news:dv6tu5$30ko$1@news.mm.pl...
> Klasyczny przyklad: tabela lekarz-pacjent-choroba-adres-lek
> usowajac z takiej tabeli pacjenta ( bo wyzdrowial) stracisz informacje
> zarowno o leczonej chorobie, jak i o zaordynowanych lekach. Podczas gdy
> nazwisko pacjenta ktory wyzdrowial moze byc niewazne, liczba przepisanych
> lekow lub leczonych chorob moze byc potrzebna np. w celach statystycznych.
> jesli zatem takie sa wymogi, zeby te informacje trzymac, nie moga byc one
> trzymane w jednej tabeli, bo pacjentow zdrowych nie chcemy trzymac w
> bazie, a chorzy musieliby zostac usunieci razem z choroba.
>
> takie rozumowanie jest wyjsciem do II postaci normalnej a sa i wyzsze.
> generalnie jesli zaczniesz projektowac baze w metodologii obiektowej (
> pacjent, lekarz, lek, choroba) jeden do jednego/jeden do wielu w ww
> obiektach, kazdy obiekt to tabela, doataniesz wlasnie baze w II postaci
> normalnej, jest wiec to relatywnie proste.
> Szczegoly-> ksiazka o projektowaniu baz danych
A, nie zrozumiałem Twojego pytania. Chodziło mi o to, że mam dane w pewnym
sensie niepowtarzalne jako pola tabeli, a zarazem stanowiące logiczną
całość - już po normalizacji. Nie przez analogię do ilości pół, a samych
danych - to jak Imię i Nazwisko w jednej tabeli. Teoretycznie to samo imię
może być użyte z wieloma nazwiskami, ale w moim przypadku podział na umowną
ilość danych (pól) "Imię" i "Nazwisko" ma marne szanse na powtórzenie na
tyle, żeby tabele były podzielone ze względów nie powtarzania tych samych
informacji i powiązane relacją. Namierzyłem gdzieś (nie mam źródła pod
ręką), że czasem jednak taki podział ma sens - na owo "Imię" i "Nazwisko" ze
względów wydajnościowych. No i tego nie jestem pewien, bo uzasadnienia nie
tam znalazłem.
Pozdrawiam,
Jacek
Kazek Kurz - 15-03-2006 10:40
jh wrote:
> Użytkownik "Kazek Kurz" <kakaz@tlendwuczasteczkowy.pl> napisał w wiadomości
> news:dv6tu5$30ko$1@news.mm.pl...
[ciach]
>>takie rozumowanie jest wyjsciem do II postaci normalnej a sa i wyzsze.
mialo byc III postaci normalnej.
> A, nie zrozumiałem Twojego pytania. Chodziło mi o to, że mam dane w pewnym
> sensie niepowtarzalne jako pola tabeli, a zarazem stanowiące logiczną
> całość - już po normalizacji.
Rozumiem. Ok.
No wiesz; to chyba dosyc istotnie zalezy zarowno od ilosci danych jak i
od struktury tabel.
Np. strategie odczytu/blokowania krotek: zaluzmy ze masz wybrana
strategie blokowania rekordow: nie ma problemu. Ale jesli blokujesz nie
rekordy a strony albo wrcz tabele cala, to wowczas ktos czytajacy jedna
krotke blokuje ci wszytskoi albo jakis niemaly kawalek.
generalnie rzecz biorac w wiekszosci systemow ktore widzialem taki
podzial ( zgrubne/szcegolowe) byl dokonany.
Przyklad:
zamowienie + szczegoly zamowienia.
tabela zamowienie zawiera informacje o calkowitekj sumie zamowienia,
numerze zamowienia, numerze faktury, datach, kliencie, osobie ktora
przyjela zamowienie, dane o realizacji zamowienia jako calosci.
tabela szczegoly zawiera kolejne linie zamowienia ( ktore pojawia sie na
faktorze), zastosowane upusty, jakies parametry opcjonalne wazne dla
realizacji pozycji zamowienia zwiazane z pozycka zamowienia.
Strata: niektore dane sie powtarzaja (choc oczywicie nie musza),
dodatkowo relacja zamowienie-szczegoly komplikuje wiele rzeczy.
Zalety: przeszukiwanie zamowien nie grzebie po olbrzymiej tabeli
szczegolow zamowienia: mozesz miec 1000 zamowien miesiecznie ale kazde
moze zawierac 100 linii i tabela szczegolow zamowien z roku jest
olbrzymia mimo ze zamowiennjest tylko 12 tysiecy np.
Ponadto wycena zamowienia i generacja fry nie angazuje glownj krotki
zamowienia do zapisu, operuje wylacznie na krotkach z szczegolow,
podobnie niektore inne operacje na szczegolach zamowienia.
tak wiec w niektorych wypadkach ma to sens.
POnadto indeksy sa mniejsze bo dotycza bardziej konkretnych rzeczy.
Pamietaj tez ze logiczny model bazy relacyjnej jest dobry ale w pewnym
momencie mussz tez zaczac analizowac fizyczna implementacje. Podzial
tabeli na mniejsze mzoe miec sens jesli dzieki temu np. kawalki systemu
beda na roznych dyskach/stripach lepiej ulozone.
Oczywiscie te ostatnie zreczy to juz moga byc bardzo rozne w roznych bazach.
kazek
>
> Pozdrawiam,
> Jacek
>
>
--
O ktorym Wojtek Wierba napisal:
Kiedyś mówiło się "cogito ergo sum".
No Kazek chyba powiedzialby jednak:
"cogito ergo zum" co tlumaczy sie jako
"... jezdem"
jh - 15-03-2006 10:40
Dziękuję Ci bardzo, już wiem więcej ;-)
Pozdrawiam,
Jacek
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
=?iso-8859-2?Q?=5BMySQL=5D_Wy=B6wietlenie_wszystkich_rekordow _zawierajacy?==?iso-8859-2?Q?ch_duplikat_a__moze_inna_struktura_bazy_danych ?=
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
=?iso-8859-2?Q?=5BSQL_Server_2000=5D_uprawnienienia_do_u=BFyw ania_widoku_?==?iso-8859-2?Q?opartego_na_tabeli_z_innej_bazy?=
Dwie bazy czy dwie tabele?
[PHP i MySQL] Wstawianie =?ISO-8859-2?Q?rekord=F3w_do_bazy_?==?ISO-8859-2?Q?a_z=B3e_kodowanie?=
=?ISO-8859-2?Q?=5Bmysql=5D_synchronizacja_struktury_bazy_?==? ISO-8859-2?Q?lokalnej_ze_zdaln=B1?=
[Oracle] Co do tworzenia aplikacji dla bazy Oracle
narzedzie do transferu bazy mysql - mysql
narzedzie do transferu bazy odbc - odbc
Połączenie bazy danych z wykonaniem polaczenia telefonicznego
zanotowane.pldoc.pisz.plpdf.pisz.ploefg.opx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
