Filtracja Danych: Bazy Danych vs. Serwer
- Szczegóły
Wymagania określane w WHERE, są również drugim miejscem, w którym możemy dokonywać selekcji wierszy. Stosowanie WHERE jest intuicyjne.
Operatory Porównania w Filtracji Danych
Najczęściej używana filtracja, czy też wyszukiwanie określonych rekordów, bazuje na podstawowych, znakowych operatorach porównania (=, >, <, <>, >=, <=). Czasem stosuje się ich aliasy np. symbol „różny od” != oraz <> są synonimami, podobnie jak !> i <= (nie większy niż i mniejszy lub równy). Rzadziej stosowanymi są operatory negacji ~, czy bitowe & AND, | OR oraz ^ XOR.
Każdy z nich, musi stanowić logicznie spójną, niezależną strukturę porównywania wartości w określony sposób. Tworzenie ciągu logicznych warunków, może wymagać stosowania nawiasów.
Należy jednak pamiętać, że operacje porównania, muszą być spójne w zakresie kompatybilności typów danych. Logicznym jest, że nie ma za bardzo sensu porównywanie np.
Warunki filtracji, mogą być budowane za pomocą wyrażeń, jak również, możemy tu stosować dowolne funkcje skalarne. Należy jednak pamiętać, że stosowanie ich, może znacząco wpłynąć na wydajność wykonywanych zapytań.
Przeczytaj także: Definicja i pomiar filtracji kłębuszkowej
Filtrowanie Wartości Tekstowych
Oprócz typowej selekcji rekordów, których kolumny zawierają wartości tekstowe bazującej na operatorze równości (=), możemy stosować również operatory porównania - ><, > lub <.
Maskę dopasowania, tworzymy za pomocą prostych konstrukcji. Określenie zakresu znaków na wskazanej pozycji w nawiasach kwadratowych []. Zakres może być ciągły [a-z] lub stanowić listę możliwych znaków [adg]. Może też określać, wykluczenie konkretnych znaków - stosujemy wtedy symbol ^.
Określanie zakresu może być wykonane dla kilku znaków. Porównywanie wartości tekstowych odbywa się zawsze w określony sposób - zgodny z regułami określonego alfabetu. Ponieważ istnieje wiele reguł (języków), mamy możliwość wyboru konkretnej z nich.
Filtrowanie Wartości Liczbowych i Dat
Przeszukiwania wartości liczbowych czy dat, wykonywane jest często w ramach zakresów. Operator „BETWEEN AND” określa przedział obustronnie domknięty dla którego chcemy akceptować wiersze w zbiorze wynikowym.
Elementy listy, mogą być podane jawnie, tak jak powyżej, lub mogą być wektorem zwracanym przez podzapytanie. W tym przykładzie, użyłem dodatkowo funkcji LEN(), która zwracająca długość ciągu tekstowego. Filtruję tu wszystkie imiona krótsze niż 7 znaków, zaczynające się od ‘Joa’ lub ‘Joh’.
Przeczytaj także: Webber AP8400 - wymiana filtrów
Distinct, usuwa ze zbioru wynikowego wszystkie duplikaty.Co istotne, operator IN tłumaczony jest tylko i wyłącznie na operator ‘=’ równości. Żeby skorzystać z innych (np. > lub <) należy użyć operatora ANY (ewentualnie jego synonimu SOME - który działa dokładnie tak samo).
Ostatnim z operatorów działających na listach, jest ALL, który tłumaczony jest na szereg warunków AND. Zatem porównanie w filtrze z uzyciem ALL, zakłada, że dana wartość jest np.
Podzapytania w Klauzuli WHERE
Jak już zdążyłeś pewnie zauważyć, możliwe jest stosowanie podzapytań w klauzuli WHERE. Jest to generalna zasada elastyczności języka SQL.
Jeśli zadbamy aby w określonym miejscu, pojawiły się wartości określonego (oczekiwanego) typu np. wartości skalarne to wszystko będzie zgodne z jego strukturą. Mamy do czynienia z porównaniem wartości skalarnej, przechowywanych w określonej kolumnie z inną wartością skalarną. Zaznaczam, że nie musi to być wartość stała. Może to być zmienna (np.
Etap filtrowania rekordów, operuje na elementach tabeli wirtualnej, powstałej w pierwszym kroku przetwarzania zapytania czyli po klauzuli FROM. Jeśli łączymy wewnętrznie (INNER JOIN) np. dwie tabele, Klienci i Zamówienia, dostępne będą tutaj tylko te rekordy z tabel źródłowych, dla których wynik operacji złączenia zostanie spełniony - będzie równy TRUE.
Przeczytaj także: Optymalne rozcieńczenie bimbru
Wyszukiwanie wśród rekordów „odsianych” w kroku łączenia tabel (np. Klientów bez zamówień) w tej sytuacji nie powiedzie się. Tworząc warunki filtracji, mamy do dyspozycji szeroki zakres możliwości oferowanych przez język SQL.
Możemy odwoływać się tu do wszystkich kolumn, tabel źródłowych, wyszczególnionych we FROM. Na wartościach które zawierają, dokonywać dowolnych przekształceń i tak otrzymane dane, porównywać z innymi kolumnami lub wyrażeniami. Do przekształceń danych, posłużyć nam mogą wbudowane lub własne funkcje skalarne.
Filtrowanie Danych Według Daty
Filtrowanie według dat pomaga wybierać dane, analizować je w określonych okresach, dokonywać porównań i śledzić trendy. Czasami przy tworzeniu raportów mogą wystąpić błędy: na wykresie nie uwzględniono niezbędnych danych lub wręcz przeciwnie, pojawiły się niepotrzebne dane.
Jeśli zestaw danych zawiera pole daty i godziny, można go użyć do filtrowania. Na przykład deale można filtrować według następujących pól: date_create, date_modify, begindate i closdate.
W przypadku błędów lub braku pola określonego do filtrowania kreator automatycznie wybiera w zestawie danych pierwsze pole typu data i godzina. Aby filtrować dane według daty i godziny należy zawsze ustawiać odpowiednie pole w bloku Filters.
Aby filtrować dane z zestawu wirtualnego, dodaj pole do filtrowania. Edytuj zestaw danych zawierający deale, pola niestandardowe i produkty. du.UF_CRM_1645431691305 - wybiera określone pole niestandardowe z crm_deal_uf. Następnie edytuj zapytanie i zastąp parametr WHERE.
Bezpieczeństwo Danych Podczas Filtracji
W rozdziale przedstawione zostały wybrane zagrożenia związane z bezpieczeństwem funkcjonowania serwisów WWW opartych na bazach SQLowych. Jednym z problemów występujących podczas tworzenia serwisów komputerowych jest konieczność zabezpieczenia ich przed atakami włamywaczy komputerowych.
Włamywacze często wykorzystują to, że programiści, przyzwyczajeni do pisania aplikacji jednowarstwowych, nie zabezpieczają się przed atakami polegającymi na manipulowaniu danymi znajdującymi się po stronie przeglądarki internetowej. niepoprawną obsługę ciasteczek (ang.
Problem zagrożenia atakami typu SQL inject jest szeroko poruszany w czasopismach informatycznych. i użytkownik mógłby się zalogować do systemu nie znając hasła.
Wszystkie parametry dostarczane przez użytkownika serwisu powinny być filtrowane. Idealnie byłoby, gdyby każdy z parametrów był sprawdzany pod kątem dopuszczalnego zbioru wartości, które powinien przyjmować.
Istnieją na rynku programy, zwane firewallami aplikacyjnymi, które pozwalają na automatyzację procesu sprawdzania poprawności przekazywanych serwisowi parametrów. Niektóre z rozwiązań pozwalają na automatyczne ustalanie zestawu reguł przy użyciu technik z zakresu sztucznej inteligencji, inne natomiast wymagają wprowadzenia zestawu reguł.
Dostęp do bazy danych może być zorganizowany za pomocą oddzielnej warstwy np. przy użyciu biblioteki dostępu do bazy danych. Najprostszą ze stosowanych metod zabezpieczania aplikacji webowych przed nieautoryzowanym dostępem do danych jest używanie uprawnień bazodanowych.
Część z języków służących do tworzenia serwisów WWW wspiera automatyczne formatowanie zapytań przekazywanych do bazy danych. Do rozwiązań systemowych można zaliczyć np. stosowany w PHP mechanizm magic_quotes.
Proponujemy stworzenie dodatkowej warstwy dostępu do danych, która będzie z jednej strony śledzić, które strony i z jakimi parametrami użytkownik przegląda i na tej podstawie będzie przydzielać temu użytkownikowi uprawnienia, a z drugiej strony będzie filtrować zapytania SQL, które są przekazywane z serwera WWW do bazy danych. Rozwiązanie takie można zaadaptować do dowolnego serwera WWW i języka programowania.
Rozwiązanie opiera się na pomyśle aby przed zadaniem zapytania bazie danych, zmodyfikować je w taki sposób, żeby nie mogły one zwracać danych, do których użytkownik nie ma dostępu. System jest oparty o architekturę pośrednika (ang.
Aby uzyskać większą efektywność wdrażania systemu, może on pracować w dwóch trybach. W trybie logowania bazie danych zadawane są dwa zapytania. Jedno przefiltrowane, a drugie w postaci oryginalnej. Jeśli zapytania te zwrócą różne wyniki, to informacja o tym jest umieszczana w dzienniku aplikacji, jako przypadek potencjalnie błędnego zaprogramowania systemu.
Aby jeszcze bardziej ułatwić wdrażanie systemu, SQLshield został zaprojektowany w taki sposób, że projektant aplikacji w każdej chwili może sprawdzić do jakich danych ma dostęp program generujący stronę.
Pierwsza sekcja programu w SQLshield zawiera informacje o tym, do jakich tabel i na których stronach dostęp powinien być filtrowany. Służą do tego instrukcje page oraz protect. Po słowie kluczowym page podaje się listę stron, na których dostęp do bazy danych ma być filtrowany (zazwyczaj nie są to wszystkie strony, gdyż do filtrowania dostępu do części ze stron używa się innych mechanizmów systemowych, np. ograniczania dostępu na podstawie logowania do systemu operacyjnego lub ograniczania dostępu tylko z pewnej podsieci fizycznej).
W liście tej można używać wyrażeń regularnych. Następnie podaje się, jakie są możliwe do uzyskania uprawnienia, kiedy się je uzyskuje, a kiedy traci. Niektóre z uprawnień mogą być uzyskiwane na określony czas. Do specyfikowania uprawnień służą słowa kluczowe gain i revoke.
Każda z transakcji ma przypisaną osobę, która jej dokonała. Osoba powinna widzieć swoje i tylko swoje transakcje oraz rozliczenia. Załóżmy, że w programie SQLshield znajduje się tylko jedna linia ograniczająca dostęp do danych (access table users when Logged($user) and user in $user).
Jeśli serwis WWW przekazuje do bazy pytanie zawierające tabelę users, to jest ono automatycznie uzupełniane o warunek users.user=$user. Ponieważ HTTP jest protokołem bezstanowym, więc nie można wiązać nabytych uprawnień z połączeniem, ale konieczne jest wiązanie ich z innym obiektem.
Największym z występujących problemów technicznych, na który napotkaliśmy podczas implementacji systemu, była konieczność powiązania identyfikatora sesji z zapytaniem zadawanym bazie danych.
W trakcie przeprowadzonych eksperymentów nie zauważyliśmy wprowadzania przez nasz system opóźnień. Co więcej, w niektórych przypadkach wydajność wzrosła! Działo się to wtedy, kiedy programiści niepotrzebnie pobierali za dużo danych z bazy, np.
Przedstawiliśmy język opisu polityk bezpiecznego dostępu do danych SQLshield oraz aplikację korzystającą z opisów stworzonych w tym języku. Pokazaliśmy, że możliwe jest zabezpieczenie się przed kilkoma często występującymi problemami związanymi z bezpieczeństwem serwisów WWW w sposób automatyczny.
Filtracja Danych po Stronie Klienta
Z rozsądkiem i też patrząć na to, żeby użytkownik był zadowolony. Jeśli użytkownik wyszukał jakieś produkty, pobrałeś dane o tych produktach, wyświetliłeś je w liście. Użytkownik zawęził wyszukiwanie np. bluza i np. strona się wczytuje z 3 sekundy i pokazuje tylko produkty do 100zł. Wtedy mógłbyś przefiltrować dane, które już masz, bo już je pobrałeś, więc po co je pobierać?
Zresztą przefiltrować po stronie frontendu możesz w ułamek sekundy, bo nie musisz walić zapytania do serwera, które trwałoby np. (Ale to tylko połowa prawdy, bo np. załóżmy, że pobrałeś tylko pierwszą stronę - załóżmy, że masz takie stronicowanie, że jedna strona to 10 wyników - użytkownik kliknął filtruj i zostały tylko 4 produkty. I w rezultacie i tak musisz pobrać brakujące produkty (żeby dorównać do 10 wyników), więc i tak musisz się połączyć z bazą. Ale ogólnie o ile czasem faktycznie można wykorzystać frontend do zmniejszenia obciążenia bazy (albo do polepszenia doświadczeń użytkownika), to mam wrażenie, że to jeszcze nie ten etap.
tags: #filtracja #danych #na #bazie #danych #a
