[ Pobierz całość w formacie PDF ]
.Jeśli jedynym środkiem poprawy wydajności ma być w tym przypadkumodyfikacja projektu bazy danych, to należałoby rozważyć przechowywanie datyważności razem z każdym dowodem transakcji.Oczywiście prowadzi to dowystąpienia w bazie nadmiarowości danych.Jest to jednak nadmiarowośćkontrolowana, będąca wynikiem przemyślanej decyzji projektanta.Powyższyprzykład ilustruje możliwe do zaakceptowania odstępstwo od ścisłych reguł 182 Część Iprojektowania relacyjnych baz danych, a także wpływ wymagań operacyjnychaplikacji na projekt.Decydując się na wprowadzenie kontrolowanej nadmiarowości należy kierowaćsię jedną, podstawową zasadą: najpierw całkowicie znormalizować bazę danych,a dopiero potem wprowadzać nadmiarowość, jeśli występuje taka potrzeba.Niewolno ulegać pokusie naruszania reguł normalizacji już w pierwszej wersjiprojektu.Ponadto względy wydajności nie mogą stanowić wymówki dlanieprawidłowo sporządzonego projektu bazy danych.Odstępstwa od normalizacjirzadko znajdują uzasadnienie - wyjątek stanowią systemy przetwarzającerzeczywiście bardzo duże zbiory danych.Weryfikacja i uzupełnienie modelu E-RModel jest formalnie znormalizowany, wymaga jednak jeszcze wielu uzupełnień.Przede wszystkim nie zdefiniowano w nim identyfikatorów encji (kluczygłównych).Ponadto nie zweryfikowano poprawności informacji o asocjacjach,wygenerowanych automatycznie przez eksperta normalizacji.Weryfikacja asocjacjiDalszą pracę nad projektem rozpoczniemy od sprawdzenia, czy ekspertnormalizacji prawidłowo określił warunki asocjacji encji.Aby dokonać takiejweryfikacji, należy:1.Wybra� opcj� menu Expert\Verify Connectivities.Na ekranie pojawi się oknodialogowe Verify Connectivities.Należy wybrać opcję all connectivitiesi upewnić się, czy opcja for selected relationships pozostaje nieaktywna, poczym kliknąć przycisk Verify.2.Program zada teraz szereg pytań, dzięki którym ekspert normalizacji uzyskadodatkowe informacje o związkach, zachodzących między encjami.Poniższalista zawiera odpowiedzi, których należy udzielić na kolejno zadawane pytania:In general, is it necessary for a CALL to have a PROPERTY to exist?(Czy z każdym zgłoszeniem telefonicznym musi być skojarzonanieruchomość?) - odpowiedz No (Nie).general, can one CALL have many PROPERTY ? (Czy z jednymInzgłoszeniem telefonicznym może być skojarzona więcej niż jednanieruchomość?) - odpowiedz No (Nie).In general, is it necessary for a PROPERTY to have a CALL to exist?(Czy z każdą nieruchomością musi być skojarzone zgłoszenie telefoniczne?)- odpowiedz No (Nie). Projektowanie baz danych w modelu klient/serwer 183general, can one PROPERTY have many CALL ? (Czy jednejInnieruchomości może dotyczyć wiele zgłoszeń telefonicznych?) - odpowiedzYes (Tak).In general, is it necessary for a LEASE to have a PROPERTY to exist?(Czy z każdą umową najmu musi być skojarzona nieruchomość?) -odpowiedz Yes (Tak).general, can one LEASE have many PROPERTY ? (Czy jednaInumowa najmu może dotyczyć wielu nieruchomości?) - odpowiedz No (Nie).In general, is it necessary for a PROPERTY to have a LEASE to exist?(Czy każda nieruchomość musi mieć umowę najmu?) - odpowiedz No (Nie).general, can one PROPERTY have many LEASE ? (Czy jednejInnieruchomości może dotyczyć wiele umów najmu?) - odpowiedz Yes (Tak).general, is it necessary for a LEASE to have a TENANT to exist?In(Czy z każdą umową najmu musi być skojarzony najemca?) - odpowiedzYes (Tak).In general, can one LEASE have many TENANT ? (Czy jedna umowanajmu może dotyczyć wielu najemców?) - odpowiedz No (Nie).general, is it necessary for a TENANT to have a LEASE to exist?In(Czy z każdym najemcą musi być skojarzona umowa najmu?) - odpowiedzNo (Nie).In general, can one TENANT have many LEASE ? (Czy jeden najemcamoże mieć wiele umów najmu?) - odpowiedz Yes (Tak).Ekspert normalizacji programu ERX zmodyfikuje teraz model, zgodniez uzyskanymi odpowiedziami.W prezentowanym przykładzie tylko jednoz założeń, przyjętych pierwotnie przez eksperta, okazało się błędne.Na rysunku6.18 przedstawiono zmodyfikowany, prawidłowy model.Porównanie tego rysunkuz rysunkiem 6.17 wykaże, że zmianie uległ związek pomiędzy encjami CALLi PROPERTY. 184 Część IRysunek 6.18.Model pozweryfikowaniuasocjacji.Określenie licznościPo uruchomieniu eksperta normalizacji, asocjacja encji CALL i PROPERTYzmieniła się z 1,1 na 0,1.Jak należy interpretować liczby na diagramie?Oznaczają one minimalną i maksymalną liczność encji, wchodzących w związek.Liczność 1,1 między encjami CALL i PROPERTY oznacza, że dla każdegowystąpienia encji CALL musi istnieć przynajmniej jedno wystąpienie encjiPROPERTY.W kategoriach bazy danych można ten warunek interpretowaćnastępująco: w każdym wierszu tabeli CALL musi znajdować się poprawny numernieruchomości (kolumna PropertyNo), pochodzący z tabeli PROPERTY; kolumnaPropertyNo nie może pozostać pusta.Odpowiedz, udzielona na pytanie ekspertanormalizacji, zmieniła ten warunek - stwierdzała bowiem, że nieprawdą jest, iżz każdym zgłoszeniem telefonicznym musi być skojarzona nieruchomość (zob.pierwsze pytanie).Dlatego ekspert normalizacji zredukował minimalną liczność dozera.Zerowa liczność umożliwia w tym przypadku rejestrowanie telefonów, którenie dotyczą konkretnych nieruchomości, np.zapytań potencjalnych najemców -pozwala na niewpisywanie wartości do kolumny PropertyNo.Z kolei maksymalna liczność równa 1 oznacza, że z każdym wystąpieniem encjiCALL może być skojarzone najwyżej jedno wystąpienie encji PROPERTY.A zatem jeden wiersz w tabeli CALL może zawierać odnośnik do jednej tylkonieruchomości - nie może być skojarzony z wieloma nieruchomościami
[ Pobierz całość w formacie PDF ]
W trosce o komfort korzystania z naszego serwisu chcemy dostarczaĂ⥠Ci coraz lepsze usÄšâugi. By mÄĹc to robiĂ⥠prosimy, abyÄšâş wyraziÄšâ zgodĂ⢠na dopasowanie treÄšâşci marketingowych do Twoich zachowaÄšâ w serwisie. Zgoda ta pozwoli nam czĂâ˘Äšâşciowo finansowaĂ⥠rozwÄĹj Äšâşwiadczonych usÄšâug.
PamiĂâ˘taj, ĚĽe dbamy o TwojĂ⌠prywatnoÄšâşĂâĄ. Nie zwiĂâ˘kszamy zakresu naszych uprawnieÄšâ bez Twojej zgody. Zadbamy rÄĹwnieĚĽ o bezpieczeÄšâstwo Twoich danych. WyraĚĽonĂ⌠zgodĂ⢠moĚĽesz cofnĂâŚĂ⥠w kaĚĽdej chwili.