Pierwsza postać normalna a efektywność zapytań wybierających

Pełen tekst

(1)Zeszyty Naukowe nr 764. 2007. Uniwersytetu Ekonomicznego w Krakowie. Dariusz Put Katedra Informatyki. Pierwsza postaç normalna a efektywnoÊç zapytaƒ wybierajàcych Streszczenie: Informacje pochodzące z organizacji i jej otoczenia są rejestrowane w bazach danych. Z kolei bazy danych służą do generowania informacji na potrzeby szczebli kierowniczych organizacji. Im większa jest baza danych oraz im większa liczba użytkowników z niej korzysta, tym istotniejsze jest, aby SZBD działał efektywnie, do czego przyczyniają się m.in. wszelkie działania wpływające na zmniejszenie jego obciążenia. W procesie normalizacji dąży się do tego, aby doprowadzić bazę danych do najwyższej możliwej postaci normalnej, co pozwoli uniknąć różnych anomalii podczas jej eksploatacji. Proces normalizacji może jednak wpłynąć na szybkość działania kwerend wybierających. W artykule zaprezentowano wynik doświadczenia przeprowadzonego przy wykorzystaniu dwóch SZBD, którego celem było porównanie szybkości działania zapytań wybierających w bazach danych spełniających funkcjonalnie tę samą rolę, lecz różniących się stopniem normalizacji. Słowa kluczowe: baza danych, efektywność bazy danych, normalizacja, postać normalna, kwerenda wybierająca, optymalizacja zapytań.. 1. Baza danych w systemie informacyjnym Baza danych stanowi jeden z elementów systemu informacyjnego – przechowuje dane będące odzwierciedleniem obiektów i zdarzeń zaistniałych w świecie rzeczywistym oraz stanowi podstawę dla procesu zdobywania informacji i odkrywania istniejących prawidłowości. Projektując system informacyjny należy postępować według opracowanych i sprawdzonych metod, co pozwoli stworzyć projekt dobrze odzwierciedlający sposób działania organizacji, a to z kolei przyczyni się do poprawy wydajności zarządzania. Proces projektowania bazy danych także powinien być prowadzony według określonych reguł. Ich przestrzeganie doprowadzi do utworzenia bazy danych, która umożliwi efektywne rejestrowanie.

(2) Dariusz Put. 116. obiektów i zdarzeń, zapewni zachowanie integralności danych oraz zminimalizuje redundancję. Dobry projekt bazy danych uwzględnia konieczność skutecznej manipulacji danymi, pozwala na zachowanie spójności i jednoznaczności przechowywanych w niej danych. 2. Normalizacja bazy danych W teorii projektowania relacyjnych baz danych wyróżnia się kilka postaci normalnych. Proces projektowania powinien zmierzać do tego, aby w każdym następnym stadium projektu baza danych była zgodna z kolejną postacią normalną. Pierwsza postać normalna (1NF) mówi, że w bazie danych występują wyłącznie wielkości skalarne. Zapewnienie tej zasady ułatwia manipulację danymi, a przede wszystkim ich wyszukiwanie i modyfikację. Występowanie pól wielowartościowych, zawierających wiele wartości tego samego rodzaju bądź segmentowych, w których występuje więcej niż jeden rodzaj wartości, utrudnia zapewnienie jednoznaczności podczas wprowadzania i modyfikacji danych, a wyszukiwanie czyni mało efektywnym lub wręcz – w niektórych przypadkach – niemożliwym. Relacja jest w drugiej postaci normalnej (2NF), gdy jest w pierwszej postaci normalnej oraz każdy niekluczowy atrybut jest nieredukowalnie zależny od klucza podstawowego. Relacja jest w trzeciej postaci normalnej (3NF), gdy wszystkie jej niekluczowe atrybuty są wzajemnie niezależne oraz nieredukowalnie zależne od klucza podstawowego. Relacja znajduje się w postaci normalnej Boyce’a/Codda (BCNF), gdy jedynymi elementami determinującymi są klucze podstawowe1. C.J. Date [2000, s. 334] uważa, że celem projektanta bazy danych jest doprowadzenie występujących w niej relacji do możliwie najwyższej postaci normalnej. Twierdzi jednak, że „niekiedy mogą wystąpić uzasadnione powody, by ominąć zasady normalizacji. Jedynym sztywnym wymaganiem jest to, aby relacje były w pierwszej postaci normalnej”. Pozostawienie bazy danych w 1NF i rezygnacja z dalszego procesu normalizacji prowadzi do występowania redundancji, a to z kolei stwarza rozmaite problemy podczas eksploatacji bazy danych. Wśród nich należy wymienić: – problemy aktualizacji – operacja aktualizacji danych musi być niekiedy przeprowadzana na wielu krotkach równocześnie. Dokonanie zmiany atrybutu w jednej z krotek, a pozostawienie niezmienionej wartości tego atrybutu w innych, związanych z nią krotkach, może doprowadzić do tego, iż w bazie danych będą błędne dane; – problemy wstawiania – operacja dopisywania danych do bazy danych może wymagać wielokrotnego wpisywania tych samych danych w wielu krotkach; 1. W teorii baz danych wyróżnia się jeszcze czwartą i piątą postać normalną..

(3) Pierwsza postać normalna a efektywność…. 117. – problemy usuwania – usunięcie krotki pociąga za sobą niekiedy konieczność usunięcia innych, związanych z nią krotek i występujących w tej samej relacji. Powstaje pytanie, jaki może być powód pozostawienia bazy danych, bądź jej fragmentu, w pierwszej postaci normalnej i rezygnacja z dalszych etapów normalizacji? W procesie normalizacji wykorzystywane jest rzutowanie. Przejście do kolejnych postaci normalnych wymaga wykonania bezstratnej operacji rzutowania relacji wejściowej, co prowadzi do powstania większej liczby połączonych ze sobą relacji. Wzrost liczby relacji może powodować zmniejszenie efektywności systemu w zakresie wykonywania zapytań służących do przedstawiania danych: wybierających i krzyżowych. Jeśli baza danych ma być intensywnie wykorzystywana przez wielu użytkowników, a występujące w niej relacje zawierają setki tysięcy bądź nawet miliony rekordów, należy rozważyć, czy podstawowym kryterium nie powinno być zapewnienie szybkości działania zapytań wybierających, kosztem występowania opisanych powyżej anomalii. 3. Proces wykonywania zapytaƒ wybierajàcych W rozproszonych systemach baz danych można wskazać kilka wąskich gardeł decydujących o szybkości działania systemu. Klient aplikacji bazodanowej uruchamia zapytanie, w którym odwołuje się do danych zapisanych w kilku węzłach sieci. Na szybkość uzyskania odpowiedzi lub wykonania kwerendy funkcjonalnej mają wpływ m.in.: – przepustowość sieci, – moc obliczeniowa komputera-serwera, – szybkość wykonywania zapytań wybierających, na którą wpływają: skuteczność optymalizatora zapytań będącego częścią SZBD, budowa kwerendy, fizyczny projekt bazy danych. Przepustowość sieci oraz problemy sprzętowe nie są bezpośrednio przedmiotem zainteresowania projektanta bazy danych. Optymalizator zapytań jest integralną częścią SZBD, na jego działanie projektant nie ma wpływu2. Z punktu widzenia projektanta wzrost efektywności (szybkości działania) zapytań wybierających można uzyskać tworząc odpowiedni projekt bazy danych. Podczas wykonywania zapytań wybierających najwięcej czasu zajmuje optymalizatorowi operacja złączenia. Powstaje więc pytanie, czy zmniejszenie liczby złączeń spowoduje na tyle duży wzrost wydajności bazy danych w zakresie wykonywania kwerend wybierających, że zrekompensuje to niedogodności związane 2 Mówimy tu o wpływie na etapie projektowania bazy danych. Odpowiednio zbudowana kwerenda może nakazać optymalizatorowi działanie w ściśle określony sposób i tym samym przyspieszyć operację wyszukiwania..

(4) 118. Dariusz Put. z pozostawieniem bazy danych w 1NF? Poszukiwanie odpowiedzi na tak postawione pytanie ma sens tylko w przypadku, gdy baza danych w 1NF, pomimo występowania w niej opisanych wyżej anomalii, nadal będzie w pełni funkcjonalna. Zapewnienie funkcjonalności, oznaczające brak błędów i niespójności w danych, można osiągnąć stosując mechanizmy transakcji oraz tworząc odpowiednie procedury. Wymaga to większych nakładów pracy w procesie tworzenia aplikacji, ale najczęściej baza danych w 1NF może być równie funkcjonalna, jak odpowiadająca jej postać w BCNF, a znajdujące się w niej dane wolne od błędów i nieścisłości. Szybkość działania kwerend wybierających jest zależna m.in. od skuteczności optymalizatora zapytań. Gdyby podczas wykonywania kwerend zawierających złączenia optymalizator musiał tworzyć iloczyn kartezjański, nie byłoby wątpliwości – zapytanie działałoby tym szybciej, im mniej złączeń. W praktyce tak nie jest. Istnieją dwie klasy optymalizatorów używanych we współczesnych SZBD – regułowe i kosztowe. Wykonywanie zapytań może się odbywać z wykorzystaniem statystyki bazy danych, indeksów oraz różnych metod sprzężenia: sortująco-scalającego, zagnieżdżonych pętli lub mieszającego. 4. Test efektywnoÊci bazy danych w BCNF i 1NF Rozważmy fragment bazy danych w dwóch wersjach. W pierwszej baza danych znajduje się w BCNF, w drugiej – w 1NF. Obydwie funkcjonalnie służą temu samemu celowi – umożliwiają zapisywanie jednego rodzaju obiektów oraz jednego rodzaju zdarzeń. Pierwsza składa się z trzech połączonych tabel, druga z dwóch. Choć przedstawiony problem może uchodzić za uniwersalny, dla przejrzystości rozważań skupimy się na jednej sytuacji – klientów i składanych przez nich zamówień na produkty. Definicja tabel występujących w tym fragmencie bazy danych jest następująca: 1. BD1 – projekt fizyczny wersji bazy danych w BCNF: Create Table Klienci1 ( Id_Klienta Auto_Increment Primary Key, Nazwa_Klienta Varchar(30), Telefon Varchar(15)); Create Table Zamowienia1 ( Id_Zamowienia Auto_Increment Primary Key, Id_Klienta Int4, Data_Zamowienia Date, Data_Realizacji Date, Id_Pracownika Int4 Constraint C1 Foreign Key (Id_Klienta) References Klienci1);.

(5) Pierwsza postać normalna a efektywność…. 119. Create Table Szczegoly_Zamowien ( Id_Zamowienia Int4, Id_Produktu Int4, Liczba_Produktow Int2, Cena Float2, Constraint K1 Primary Key (Id_Zamowienia, Id_Produktu), Constraint C2 Foreign Key (Id_Zamowienia) References Zamowienia1); 2. BD2 – projekt fizyczny wersji bazy danych w 1NF: Create Table Klienci2 ( Id_Klienta Auto_Increment Primary Key, Nazwa_Klienta Varchar(30), Telefon Varchar(15)); Create Table Zamowienia2 ( Id_Zamowienia Int4, Id_Klienta Int4, Data_Zamowienia Date, Data_Realizacji Date, Id_Pracownika Int4 Id_Produktu Int4, Liczba_Produktow Int2, Cena Float2, Constraint K1 Primary Key (Id_Zamowienia, Id_Produktu), Constraint C1 Foreign Key (Id_Klienta) References Klienci2); W obydwu bazach danych przechowywane są dane o klientach (odpowiednio w tabelach Klienci1 i Klienci2) oraz składanych przez nich zamówieniach. Wykonywanie operacji dotyczących klientów (dopisywanie, usuwanie, modyfikacja danych) w obydwu bazach danych odbywa się w ten sam sposób. Inaczej jest w przypadku zamówień. W każdym zamówieniu może występować jedna bądź więcej pozycji (Id_Produktu). Sposób rejestracji zamówień przedstawia się następująco: 1. W bazie danych w BCNF (BD1) zamówienie jest rejestrowane w tabeli Zamowienia1 i Szczegoly_Zamowien. Do tabeli Zamowienia1 zapisywany jest jeden rekord zawierający wszyst kie atrybuty zamówienia, do tabeli Szczegoly_ Zamowien zapisywanych jest tyle rekordów, ile produktów (Id_Produktu) jest przedmiotem zamówienia. Wszystkie te rekordy mają taki sam Id_Zamowienia, co jednoznacznie wskazuje, którego zamówienia dotyczą. 2. W bazie danych w 1NF (BD2) zamówienie jest rejestrowane w całości w tabeli Zamowienia2. W tabeli tej wpisywanych jest tyle rekordów, ile produktów (Id_Produktu) jest przedmiotem za mówienia. Atrybuty występujące w tabeli Zamówienia2 można podzielić na dwie kategorie: te, które dotyczą samego.

(6) 120. Dariusz Put. zamówienia (Id_Zamowienia, Id_Klienta, Data_Zamowienia, Data_Realizacji, Id_Pracownika), oraz te, które dotyczą zamawianych produktów (Id_Produktu, Liczba_Produktów, Cena). Rekordy dotyczące tego samego zamówienia zawierają identyczne, zwielokrotnione dane w zakresie dotyczącym zamówienia oraz różne dane o zamawianych produktach. Baza danych BD1 znajdująca się w BCNF nie zawiera żadnych anomalii. Operacje aktualizacji, dopisywania, usuwania nie stwarzają problemów, możliwość wystąpienia danych niespójnych bądź błędnych jest minimalna, szczególnie przy odpowiednim ustawieniu więzów integralności oraz budowie transakcji. Baza danych BD2 zawierająca dane zwielokrotnione może powodować następujące problemy: – aktualizacja jednego z atrybutów zamówienia (np. daty realizacji) wymaga dokonania identycznej zmiany we wszystkich rekordach w tabeli Zamówienia2 dotyczących tego zamówienia, – usunięcie danych o zamówieniu wymaga skasowania wszystkich rekordów dotyczących tego zamówienia w tabeli Zamówienia2, – rejestracja zamówienia dotyczącego wielu produktów wymaga wielokrotnego wpisania danych dotyczących daty zamówienia, daty rea lizacji, identyfikatora pracownika przyjmującego zamówienie, identyfikatora klienta, który składa zamówienie. Opisane problemy z BD2 nie uniemożliwiają korzystania z bazy danych. W projekcie muszą być jednak stworzone odpowiednie mechanizmy, które zapobiegną możliwym niejednoznacznościom w bazie danych. Ponadto, co jest oczywiste, dane znajdujące się w BD2 będą zajmowały większą przestrzeń dyskową niż dane wpisane do BD1. W bazie danych BD1 znajdują się trzy tabele, w bazie BD2 – dwie. Jeśli w obydwu będą przechowywane te same dane, to w tabelach Klienci1 i Klienci2 wpisana zostanie taka sama liczba rekordów. Różnica w liczbie rekordów znajdujących się w poszczególnych bazach danych pojawi się, gdy rejestrowane będą zamówienia. Jeśli w bazie danych zapisane będą dane o n klientach i każdy z nich złoży x zamówień, a każde zamówienie będzie dotyczyło y produktów3, to w bazie danych BD1 znajdzie się łącznie n + x + x*y rekordów, natomiast w bazie BD2 będzie n + x*y rekordów. Wynika stąd, że różnica w liczbie rekordów w BD1 i BD2 jest równa liczbie złożonych zamówień.. 3. Liczba zamówień złożonych przez poszczególnych klientów, jak i liczba produktów będących przedmiotem poszczególnych zamówień może być różna. Dla uproszczenia przyjmujemy, że wszyscy klienci złożyli tę samą liczbę zamówień oraz każde zamówienie dotyczy tej samej liczby produktów. Efekt będzie taki sam, jeśli dane te potraktujemy jako wartości średnie (średnia liczba zamówień, średnia liczba produktów przypadających na jedno zamówienie)..

(7) Pierwsza postać normalna a efektywność…. 121. Z punktu widzenia efektywności zapytań wybierających istotniejsze jest porównanie liczby rekordów, które pojawią się w tabeli będącej wynikiem iloczynu kartezjańskiego danych występujących we wszystkich tabelach bazy danych. W przypadku BD1 będzie to n * x * x * y rekordów, a dla BD2 n * x * y rekordów. Wynika stąd, że różnica jest równa: nxxy – nxy = nxy(x – 1) czyli w tabeli będącej wynikiem iloczynu kartezjańskiego BD1 będzie o nxy(x – 1) rekordów więcej niż w BD2. Przyjęcie rozwiązania problemu rejestracji zamówień w oparciu o trzy tabele zaprezentowane w BD1 ma tę wadę, że w bazie danych występuje większa liczba rekordów, a co za tym idzie iloczyn kartezjański tabel składa się z większej liczby rekordów. Z kolei w BD2 liczba rekordów jest mniejsza, ale problemem staje się istniejąca redundancja. Oprócz tego, że w BD1 znajdzie się więcej rekordów niż w BD2, kwerendy wybierające, w których wymagane będzie wykorzystanie danych znajdujących się we wszystkich tabelach będą musiały wykonać jedno złączenie więcej w BD1 niż w BD2. Może stąd wynikać wniosek, że kwerendy takie będą działały szybciej w BD2 niż w BD1. W celu dokonania analizy szybkości uzyskania odpowiedzi na zapytania wybierające przeprowadzono badanie empiryczne. Wykorzystano dwa SZBD: Access 2000 (działający w SO Windows 2000) i PostgreSQL (w SO Linux). Aby zmini ma li zować wpływ czynników trzecich, podczas wykonywania zapytań zablokowano możliwość uruchamiania innych procesów w komputerach, w tym także możliwość korzystania z analizowanych baz danych. Przeprowadzone doświadczenie miało na celu znalezienie średniego czasu trwania kwerendy wybierającej, którą zbudowano tak, aby konieczna była analiza wszystkich danych występujących w bazie danych oraz dodatkowo umieszczono w niej funkcję agregującą. Była to kwerenda wybierająca nazwy wszystkich klientów wraz z liczbą produktów, które w sumie zamówili. 1. Postać kwerendy dla BD1: SELECT Klienci1.Nazwa_Klienta, Sum(Szczegoly_Zamowien.Liczba_Produktow) AS Liczba_Produktow FROM (Klienci1 INNER JOIN Zamowienia1 ON Klienci1.Id_Klienta = Zamowienia1.Id_Klienta) INNER JOIN Szczegoly_Zamowien ON Zamowienia1. Id_Zamowienia = Szczegoly_Zamowien.Id_Zamowienia GROUP BY Klienci1.Nazwa_Klienta, Klienci1.Id_Klienta; 2. Postać kwerendy dla BD2: SELECT Klienci2.Nazwa_Klienta, Sum(Zamowienia2.Liczba_Produktow) AS Liczba_Produktow.

(8) Dariusz Put. 122. FROM Klienci2 INNER JOIN Zamowienia2 ON Klienci2.Id_Klienta = Zamowienia2.Id_Klienta GROUP BY Klienci2.Nazwa_Klienta, Klienci2.Id_Klienta; Kwerendy były uruchamiane na przemian, 100 razy w przypadku każdej bazy danych, przez co starano się wyeliminować wartości przypadkowe. Następnie obliczono średni czas wykonywania każdej kwerendy. Aby możliwe było przemienne wykonywanie kwerend, szczególnie w systemie Access 2000, wszystkie tabele tworzące BD1 jak i BD2 umieszczono w jednym pliku (katalogu) bazodanowym. Ponadto pomiar przeprowadzono pięciokrotnie, w każdym przypadku dla takiej samej liczby klientów (100 tysięcy) oraz dla różnej liczby zamówień i zamówionych produktów. Zestawienie liczby danych wybranych do poszczególnych baz danych w każdej próbie zawiera tabela 1. W tabeli 2 zestawiono średni czas trwania kwerendy wybierającej w każdym z przypadków poddanych badaniu. Tabela 1. Liczba rekordów w poszczególnych tabelach. W każdym przypadku w bazach danych znajdowały się dane o 100 tys. klientów, w tabelach Klienci1 i Klienci2 było więc po 100 tys. rekordów Liczba rekordów w poszczególnych tabelach Wyszczególnienie. BD1. BD2. zamówienia1. szczegoly_zamowien. zamowienia2. Połowa klientów złożyła zamówienie na 1 produkt. 50 000. 50 000. 50 000. Każdy klient złożył zamówienie na 1 produkt. 100 000. 100 000. 100 000. Każdy klient złożył zamówienie na 5 produktów. 100 000. 500 000. 500 000. Każdy klient złożył 2 zamówienia, każde na 5 produktów. 200 000. 1 000 000. 1 000 000. Każdy klient złożył 3 zamówienia, każde na 5 produktów. 300 000. 1 500 000. 1 500 000. Źródło: opracowanie własne.. Tabela 2. Średni czas trwania kwerendy (w sek.) Wyszczególnienie. Access 2000. PostgreSQL. BD1. BD2. BD1. BD2. Połowa klientów złożyła zamówienie na 1 produkt. 5,54. 4,65. 5,61. 3,42. Każdy klient złożył zamówienie na 1 produkt. 11,11. 7,53. 12,46. 8,05.

(9) Pierwsza postać normalna a efektywność…. 123. cd. tabeli 2 Wyszczególnienie. Access 2000. PostgreSQL. BD1. BD2. BD1. BD2. Każdy klient złożył zamówienie na 5 produktów. 25,20. 22,58. 36,78. 33,14. Każdy klient złożył 2 zamówienia, każde na 5 produktów. 41,91. 29,58. 73,24. 62,29. Każdy klient złożył 3 zamówienia, każde na 5 produktów. 70,72. 16,56. 111,54. 93,64. Źródło: opracowanie własne.. Przeprowadzone badanie wykazało, że baza danych w 1NF zwraca dane szybciej niż baza danych znormalizowana do postaci BCNF. Analizy dokonano dla różnej liczby rekordów, wykorzystując jeden rodzaj kwerendy agregującej, absorbującej wszystkie dane występujące w bazie danych. I choć analiza ta nie jest pełna, dowodzi, że w procesie projektowania bazy danych należy wziąć pod uwagę problem efektywności zapytań wybierających. Pozostawienie bazy danych lub jej fragmentu w 1NF nie musi powodować, iż baza danych będzie zawierać dane niespójne lub błędne. Wymagać to jednak będzie większego nakładu pracy na etapie tworzenia aplikacji oraz zbudowania odpowiednich transakcji i procedur. Może natomiast skutkować szybszym wykonywaniem kwerend wybierających. 5. Zakoƒczenie Proces projektowania bazy danych powinien m.in. prowadzić do eliminacji, a przynajmniej minimalizacji redundancji rejestrowanych w niej danych podczas eksploatacji. Niemniej ważnym czynnikiem, szczególnie w odniesieniu do dużych, współużytkowanych (np. bazy internetowe) czy rozproszonych baz danych, jest szybkość działania optymalizatora zapytań. Szybkość ta ma tym większe znaczenie, im większa jest baza danych i im więcej użytkowników ma z niej korzystać. Eliminacja redundancji prowadzi zwykle do wzrostu liczby relacji w bazie danych. To z kolei prowadzi do zwiększenia liczby złączeń wykonywanych w procesie wybierania danych w odpowiedzi na kwerendę wybierającą przesłaną do systemu. Wzrost liczby złączeń pociąga za sobą zwiększenie czasu wykonywania kwerendy. W procesie projektowania bazy danych problem redundancji należy rozważać z łącznie z koniecznością zapewnienia odpowiedniej efektywności przejawiającej się m.in. w szybkości działania zapytań wybierających..

(10) 124. Dariusz Put. Literatura Chi R., Shin J. K., Siegel J.G. [1999], Technologia informacyjna, Biblioteka Praktyków Zarządzania, Dom Wydawniczy ABC, Warszawa. Date C.J. [2000], Wprowadzenie do systemów baz danych, WNT, Warszawa. Ladanyi H. [2000], SQL. Księga eksperta, Helion, Gliwice. Olesiński J. [2003], Ekonomika informacji. Metody, PWE Warszawa. Scheer A.W. [1996], Wstęp do informatyki gospodarczej. Podstawy efektywnego zarządzania informacją, Wydawnictwo Uniwersytetu Warszawskiego. Trueblood R.P., Lovet J.N. Jr. [2002], Zastosowanie języka SQL do analizy statystycznej i eksploracji danych, Mikom, Warszawa. First Normal Form and Selective Queries Effectiveness Information that comes from an organization and its environment is stored in databases. Next, databases are utilised for generating the information intended for organization managers. The larger is database and the greater is the number of its users the more important is that the database management system operates effectively. This effectiveness is the result of (among others) all factors that influence lower system load. In the normalization process a database should be transformed to the highest possible normal form, which enables avoiding various anomalies during database exploitation. The normalization process can, however, affect the speed of queries performance. The paper demonstrates the result of an experiment that was carried out with utilisation of two database management systems. The goal of the research concerned the comparison of performance speed of selective queries in databases that functionally are equivalent, but differ in the normalization level. Key words: database, database effectiveness, normalization, standard form, selective query, query optimization..

(11)