Welcome Guest Search | Active Topics | Members | Log In

Kontrola słownikowa danych Options · View
subieta
Posted: Friday, April 22, 2005 11:12:31 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Kontrola słownikowa danych była stosowana we wszystkich projektach, w których uczestniczylem. Jest bardzo ważna, pozwala na usunięcie literówek, synonimów, homonimów i wszelkiego rodzaju błędów, które mogą byc popełnione przez użytkowników w trakcie zapełniania bazy danych. Systemy relacyjne nie przewidują systemowego wsparcia dla kontroli słownikowej, w odróżnieniu od innych systemów, np. Lotusa. W systemach relacyjnych słownik jest normalną tabelą, która jest wykorzystywana dla kontroli wprowadzania danych, ale dzieje się to po stronie aplikacji. To oznacza, ze:
(1) brak wsparcia systemowego powoduje, że taką kontrolę wprowadza się nie na etapie projektu, ale na etapie zmian, czyli dopiero po uświadomieniu sobie zagrożeń wynikających z zaśmiecenia bazy danych przypadkowymi błędami. Zmiana na tym etapie kosztuje o wiele więcej niż w trakcie projektu, gdyż oznacza nie tylko wprowadzenie słowników, ale również wyczyszczenie zaśmieconej bazy danych i poprawienie wszystkich aplikacji, które na niej działają.
(2) Jeżeli programista danej aplikacji zapomni lub zlekceważy kontrolę slownikową, to nic nie wskaże, że jest coś niewłaściwego. Wyjdzie to dopiero potem, kiedy stwierdzi się zaśmiecenie bazy danych.
(3) Kontrola słownikowa dodatkowo obciążą kod aplikacji po stronie klienta.

Reasumując, kontrolę słownikową warto wprowadzić jako systemowe rozwiazanie po stronie serwera w taki sposób, aby programiści aplikacyjni nie mogli jej pominąć ani też nie musieli w swoim kodzie robić czegokolwiek extra, co byłoby związane z kontrolą słownikową.

Zwrócę uwagę, że kontrola słownikowa przypomina typ enumeration znany z róznych propozycji języków schematów, np. IDL lub ODL. Zasadnicza różnica polega na tym, że typu enumeration nie można aktualizować podczas działania bazy danych. Przykładowo, jeżeli słownik dotyczyłby wszystkich rezyserów filmów, to nie można sobie wyobrazić, że daloby się to zalatwić przez enumeration - nowy reżyser musi być wprowadzony normalnie jako element bazy danych, a nie metabazy. Z tego wzgledu słowniki tworzą nowy typ powiązania pomiędzy danymi, który jest nieobecny w UML i w modelu relacyjnym, mianowicie, powiązanie pomiędzy opisem pewnej danej w metabazie, a normalną strukturą danych występującą w samej bazie danych. Implementacja tego związku np. w SQL wymaga przejścia na SQL dynamiczny (refleksję), zdania SQL stają się bardzo muliste, ich wydajność pozostawia wiele do życzenia (zgodnie z moimi doświadczeniami z projektu sklepu EMPiK, gdzie problem był rozwiązywany).

Systemowe wsparcie dla tego rodzaju opcji polegałoby na tym, aby już projektanci na etapie UML mogli określać powiązanie pomiędzy definicją pewnej danej, a słownikiem. Następnie, system zarządzania bazą danych posiadałby środki, aby to powiązanie prosto zaimplementować (poprzez prostą klauzulę w schemacie), a następnie egzekwowałby to w postaci generycznej nie dopuszczając do wprowadzenia danych niezgodnych ze słownikami. Programista aplikacyjny miałby do czynienia tylko ze standardowym wyjątkiem, jeżeli kontrola słownikowa wykryłaby błąd.

Takie systemowe wsparcie dla słowników prowadzi do następnych opcji. Jedną z nich jest możliwość automatycznej korekty wprowadzanych danych na podstawie slownika. Jest na to sporo algorytmów, jeden z nich (mój) był zaimplementowany w systemach Linda i Netul i spotkał sie wręcz z entuzjastyczną reakcją wsród uzytkowników.

Kolejną opcją jest możliwość pracy z synonimami. Użytkownik np. za cholerę nie wie, czy w bazie danych miało być "traktor" czy "ciągnik", próbuje tak, system mu wywala, próbuje inaczej, system znowu mu wywala, itd. Przykładem jest portal PKP Hoga, gdzie jest kontrola słownikowa, tylko kto zgadnie, że Warszawa Centralna powinna sie zapisac jako Warszwa Centr., inaczej dostanie sie po łapach. Synonimy pozwalają uniknąć także problemów z częstymi literówkami, błędami ortograficznymi, pomijaniem polskich ogonków, itd. Słownik z synonimami byłby tabelą dwukolumnową, gdzie w drugiej kolumnie byłyby kody synonimów ("traktor" i "ciągnik" miałyby ten sam kod) albo słowo znormalizowane (np. traktor). W bazie danych przechowywane byłyby tylko kody lub słowa znormalizowane. Dla raportowania normalizacja jest znacznie lepsza, dla wyszukiwania (porownywanie synonimow) lesze są kody.

Trzecia opcja może dotyczyć danych złożonych. W tym przypadku kontrola słownikowa oznaczałaby również oszczędność miejsca i czasu. Same dane nie zawierałyby danej złożonej będącej w słowniku, lecz referencję do pozycji słownika. To mogłoby również przynieść znaczny zysk np. przy porównaniach. Z punktu widzenia SBQL-a takie referencje byłyby przezroczyste, tj. programista dostawałby się bezpośrednio do elementow danej zlożonej, bez uzywania explicite nazwy danej pointerowej.
subieta
Posted: Monday, May 12, 2008 10:15:03 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Przypominam o tej ważnej własności, bo temat nie został podjęty, a szkoda.
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.053 seconds.