Miesiąc: maj 2022

Zasady opisane do tej pory dotyczyły zachowania poszczególnych słów lub statystycznego związku między słowami, ale bez próby ich gramatycznego powiązania. Nieco bardziej ambitnym podejściem jest wykorzystanie podstawowej właściwości języka: posiadania gramatyki. NLP to wielki tytuł, który można zastosować do dość prostych procesów operujących na wolnym tekście, wykorzystującym podstawowe zasady. Ogólnie rzecz biorąc, oczekujemy, że silnik NLP będzie składał się z dwóch części: leksykonu, który zawiera listę słów, ich „znaczenie” w pewnym sensie oraz ich część wartości mowy (rzeczownik, czasownik itp.) razem ze składnią, zestawem reguł operujących na elementach leksykonu w celu wygenerowania „poprawnych gramatycznie” i „znaczących” fraz i zdań. Aby podać bardzo prosty przykład, leksykon może zawierać:

a regułą może być liczba mnoga ,x. ¼ ,x. 1 „s”. W praktyce prawdziwa gramatyka byłaby bardziej złożona. (Mógłby na przykład poradzić sobie z faktem, że liczba mnoga od „owce” nadal brzmiała „owce”, a nie „owce”, jak sugeruje nasz przykład). Niemniej jednak nawet ten prosty przykład ma pewną moc. Zauważ, że dla części mowy psa podane są trzy możliwości: „dobry pies” (rzeczownik), „dogonić czyjeś ślady” (czasownik), „róża psa” (przymiotnik) i prawdopodobieństwa ich wystąpienia są podane w nawiasach, w oparciu o pomiary w dużej liczbie tekstów, których części mowy zostały oznaczone przez ludzi. Można również gromadzić inne statystyki dotyczące słów i klas słów, na przykład części mowy, i umieszczać je w regułach statystycznych. Na przykład bardzo rzadko słowo „to” pojawia się bezpośrednio przed rzeczownikiem, ale bardzo często przed czasownikiem. Tak więc, ponieważ „pies” dość często występuje jako czasownik (15%), bardzo prawdopodobne jest, że będzie to słowo „piesić czyjeś ślady”.

Porównywalnie proste gramatyki NLP tego typu zostały użyte do analizy danych biznesowych, aby umożliwić bardzo dokładne wyodrębnienie nazw firm, lokalizacji itp. oraz analizę wiadomości e-mail w celu ustalenia, czy są to skargi. Dość inną aplikacją jest parsowanie zapytań wprowadzanych do wyszukiwarki, która odpytuje bazę danych. W tym przypadku parser wykorzystuje techniki NPL, aby poprawić wszelkie błędy popełnione przez osobę tworzącą zapytanie. Parser wykorzystuje gramatykę, która pozwala mu sprawdzić, czy zapytania mają poprawną strukturę i słownictwo, a także może posiadać wiedzę semantyczną o bazie danych, która umożliwia dalszą interpretację. Jednym z przykładów podanych przez jednego sprzedawcę jest parsowanie „6 Pak 12oz Diet Cola”, gdzie twierdzi się, że wiedza semantyczna jest wymagana do oddzielenia rozmiaru butelki od opakowania.

Punktem wyjścia dla większości praktycznych systemów jest próba wyodrębnienia tematu ze źródeł danych. Proces ekstrakcji z konieczności polega na wzięciu dłuższego tekstu i skróceniu go do krótszego. Odbywa się to częściowo w celu poprawy wydajności przetwarzania na kolejnych etapach, ale także dlatego, że ekstrakcja w pewnym sensie dociera do „istoty” dokumentu. Jedna z najprostszych metod polega na sporządzeniu listy poszczególnych słów użytych w tekście. Użytkownicy, którzy proszą o informacje dotyczące tego słowa, mogą otrzymać wszystkie dokumenty, które zawierają to słowo na swoich listach. Proces można ulepszyć, jeśli chodzi o przywoływanie, poprzez sedno: chociaż użytkownicy proszą o informacje na temat „psa”, proces ma bazę danych, która rozszerza termin na „psy”, „psy dwuosobowe”, „pies myśliwski” itp. Prosty doprecyzowanie może polegać na indeksowaniu dokumentów, aby dowiedzieć się, ile razy każde słowo występuje jako ułamek całkowitej długości tekstu. Zwykle wyklucza się wszystkie bardzo popularne słowa, takie jak „the”, „and”, „is” itp., umieszczając je na liście stop, która jest używana przez program indeksujący. Tak więc, biorąc pod uwagę prośbę użytkownika o teksty z „gazem” (powiedzmy), teksty mogą być wymienione w kolejności malejącej częstotliwości, co sprzyja precyzji. Można jednak zrobić więcej, stosując tę ​​prostą strategię uwzględniania liczby słów: możliwe jest opisanie tekstu w kategoriach porównania całej listy z listami wygenerowanymi dla innych dokumentów (rysunek 2.18). Dokument po lewej stronie rysunku to taki, który zainteresował użytkownika. Pokazana jest część jego indeksu słów, w szczególności słowa „lpg”, „oktan”, „gaz”, „auto” wraz z miarą ich częstotliwości występowania. Po prawej stronie znajdują się statystyki dla tych słów uśrednione w całej bazie danych.

Teraz, nawet nie wiedząc, że nastąpiło indeksowanie, użytkownik mógł powiedzieć: „Znajdź więcej dokumentów na ten sam temat”. Wyszukiwarka przeszukuje bazę danych, porównując indeks interesującego dokumentu ze wszystkimi innymi. Rozważmy dwa przypadki takiego porównania, z dokumentami X i Y. Bez uciekania się do skomplikowanej matematyki, możemy zobaczyć, że dokument Y jest „znacznie bardziej podobny” do dokumentu będącego przedmiotem zainteresowania niż średnia lub dokument X. W szczególności zauważamy częste występowanie ‘gas’ ORAZ ‘auto’ zarówno w Y, jak iw interesującym dokumencie. Prawdopodobnie oznacza to, że łączy ich wspólne zainteresowanie „gazem” w kontekście jego amerykańskiego wykorzystania jako „benzyny”. Używając łącznych prawdopodobieństw słów, możemy zacząć definiować dla nich podstawowe „znaczenia” indywidualnie: „gaz” = „benzyna” kontra „gaz” = „gaz ziemny”, ponieważ ten pierwszy ma tendencję do kojarzenia się z takimi rzeczami, jak „samochody”. (= ‘samochody’) zamiast ‘lpg’ = ‘gaz ziemny’. Gdybyśmy przyjrzeli się dokładniej, jak zrobiliśmy to intuicyjnie, odkrylibyśmy, że zasadniczo mierzyliśmy dla każdego dokumentu, jak zmienia się stosunek (częstotliwość w dokumencie)/(średnia częstotliwość we wszystkich dokumentach) dla każdego terminu. Stosunek znacznie większy lub mniejszy niż jeden dla tego terminu oznacza, że ​​jest wysoce nietypowy. Dokumenty, które mają wiele nietypowych cech, prawdopodobnie dotyczą tego samego tematu. Stosunek częstotliwości terminów w dokumencie do średniej częstotliwości jest znany jako miara TF-IDF (Term Frequency Inverse Document Frequency) i jest powszechnie używany do lokalizowania „podobnych” dokumentów. W tym przykładzie dla uproszczenia założyliśmy, że użytkownik prosi wprost o podobne dokumenty i robi to jako pojedyncze zapytanie. W rzeczywistości silniki zarządzania wiedzą zwykle eliminują potrzebę zgłaszania tego żądania przez użytkowników. Wiele z nich jest zaprojektowanych do działania w proaktywnym trybie push: stopniowo tworzą listy preferowanych słów w ramach pozyskiwania profili użytkowników. Listy te są modyfikowane przez sposób użytkowania i okresowe proszenie użytkowników o wyrażenie preferencji. Po uzyskaniu zestawu profili dla każdego użytkownika, system może następnie, bez monitowania, wysyłać użytkownikom wiadomości informujące o nadejściu dokumentów pasujących do profilu.

Przeniesienie interfejsu z klientami z call-center do centrum obsługi poczty e-mail może obniżyć koszty, ale jedynie przenosi ból związany z zarządzaniem z jednej operacji na drugą. Wciąż musi być jakiś sposób na oddzielenie zapytań o informacje od skarg klientów; wciąż musi być sposób, aby na podstawie tych danych zauważyć, że występują problemy z konkretnymi produktami i powiadomić o tym projektantów. Istnieje wiele innych obszarów, w których zwiększona ilość informacji, zarówno w organizacji, jak i w jej obrębie, musi zostać przeanalizowana i zrozumiana, najlepiej przez maszynę. Specjalistyczne firmy w dziedzinie oprogramowania do zarządzania wiedzą zaczynają oferować rozwiązania, które „inteligentnie” analizują dane korporacyjne i kierują je na właściwy obszar do rozwiązania. Mówi się, że możemy decydować o tym, czy informacja jest ważna, jeśli najpierw wiemy, czego ona dotyczy. Pojęcie „około” może wydawać się bardzo abstrakcyjne i trudne do zdefiniowania w formalny sposób, ale coraz częściej firmy konstruują narzędzia do ekstrakcji wiedzy, które mogą tworzyć operacyjnie zadowalające wyjaśnienia dotyczące „około”. Dość dokładnym sposobem myślenia o organizowaniu wiedzy jest rozważenie, że jest ona poddawana wielu zapytaniom, które można sformułować w terminach języka naturalnego, takich jak „Kto jest zaangażowany?”, „O czym to jest?”, „Dlaczego zostało to zrobione?” wyprodukował?”, „Kiedy coś się wydarzyło?”, „Gdzie?”, „Jak (w ramach którego procesu) powstało”, „Ile (lub jakie są liczby)?” Nie jest to szczególnie trudne wymienić kilka sposobów, w jakie można opisać znaczenie elementu danych elektronicznych:

† Według tytułu.

† Przez fragment metainformacji, której definicja została opublikowana.

† Przez kto to napisał.

† Do kiedy zostało napisane.

† Według jego zawartości.

† Poprzez linki do iz niego przez inne elementy.

† Po wyglądzie (kolorowa broszura, arkusz kalkulacyjny itp.).

i są inne. Można zauważyć, że dokumenty nie istnieją tylko w izolacji, ale istnieją w wielu kontekstach, które obejmują ludzi, którzy z nimi pracują i procesy biznesowe, które wspierają i zmieniają się z czasem, a nie są skamieniałościami, które się nie zmieniają. Rysunek wyjaśnia to dokładniej

Na rysunku dokument jest reprezentowany na dwa sposoby. Po pierwsze, przez jego „treść”, która składa się z rdzenia, tematu i wszelkich dodatkowych metainformacji dodanych do niego przez ludzkich lub maszynowych interpretatorów. Po drugie, poprzez swoją historię – w jaki proces był zaangażowany, kto ją przeczytał, umieścił ją w swoim osobistym profilu jako typowy przykład rzeczy, o których chciała usłyszeć i tak dalej. Jest oczywiste, że niektóre z tych informacji są jawnie, nawet świadomie, stosowane w danych: większość raportów w dzisiejszych czasach jest pisana przy użyciu standardowych „stylów” dla różnych poziomów nagłówków itp. większość ma arkusze treści; arkusze kalkulacyjne i bazy danych mają nagłówki kolumn, które w pewien sposób odnoszą się do korporacyjnych modeli danych i słowników; czasami autorzy lub tłumacze stosują słowa kluczowe do dokumentu, w HTML lub XML ,meta. definicja; czasami silniki baz danych automatycznie indeksują dowolny tekst dokumentu, wyodrębniając słowa i ich częstotliwość, które mają działać jako przeszukiwalne maszynowo podsumowanie dokumentu. Jednak wiele informacji o użyciu dokumentu jest tworzonych w ukryciu (choć nie w zamierzonym sensie). Jeśli to ma być użyte jako część dowodu na temat około, to również musi być wpisane do metaopisu i aktualizowane tak często, jak to konieczne. Zatem podstawowym zadaniem rozwiązań do zarządzania wiedzą jest integracja szeregu zbiorów danych generowanych przez procesy poprzez oznaczanie ich etykietami indeksowymi i informacjami źródłowymi, a następnie obserwowanie późniejszej historii danych i ciągłe aktualizowanie tego rekordu wraz z wykorzystaniem silniki wnioskowania, wyposażone w szczątkową inteligencję, które próbują osiągnąć prostą parę celów:

1 Dostarcz wszystkim właściwym osobom wszystkie dane ważne i istotne dla ich obszaru pracy (wymóg wycofania).

2 Bez dostarczania niczego, co nie jest konieczne (precyzja wymogu).

Ogólnie rzecz biorąc, istnieje wzajemna zależność między precyzją a wydajnością procesu wyszukiwania informacji

Zauważ, że może to utrudnić porównywanie systemów wyszukiwania wiedzy. Niektórzy mogą błędnie dawać za dużo, inni wolą dawać mniej, z szansą na utratę czegoś ważnego. Ponownie wybór nie jest absolutny; będzie to zależeć od aktualnych wymagań obecnej populacji użytkowników, biorąc pod uwagę dzisiejszy zestaw danych.

Coraz częściej dostawcy oferują rozwiązania, w których część rozpoznawania istotnych wzorców jest realizowana przez komputer. Zamiast po prostu odpowiadać na zestawy zapytań generowanych przez użytkowników i opartych na hipotezach użytkownika, bardziej zaawansowane systemy mogą same przeprowadzać eksploracyjną analizę danych, tworząc same hipotezy i grupując dane w znaczące lub przynajmniej przydatne wzorce. Tym wzorom zazwyczaj przypisuje pewien statystyczny poziom dokładności. Na przykład sprzedawca detaliczny może chcieć znaleźć „odpowiednie” wzorce cech klientów w danym obszarze kodu pocztowego. Następnie zażądają od inteligentnego oprogramowania „znalezienia wzorców związanych z obszarem pocztowym X”. System może odpowiedzieć, obliczając statystyczne współzachowanie szeregu parametrów dla tego obszaru i zwracać regułę, która mówi: „w obszarze X istnieje 83% szans, że osoby powyżej 45 roku życia, które wykupiły od Ciebie ubezpieczenie na życie, pytałem również o ubezpieczenie zdrowotne”. Oczywiście parametry „kod pocztowy”, „wiek”, „ubezpieczenie na życie” (lub ich proste pochodne) muszą być jednostkami lub atrybutami w bazowym modelu danych. Istnieje również możliwość, że oprogramowanie może wygenerować zbyt wiele statystycznych „reguł” tego typu, jeśli po prostu zostanie zaprogramowane na tych liniach. Bardziej satysfakcjonujące jest poproszenie go o opracowanie reguł opisujących nietypowe zachowanie, w naszym przykładzie, być może informujących nas o obszarach z kodem pocztowym, w których zapytania w wieku 45 lat i osób były niezwykle wysokie. Zauważ, że reguły wymienione powyżej są zasadniczo sposobami kompresji dużej liczby zbiorów danych w znacznie bardziej zwartą i wydajną metodę przetwarzania, a ponadto taką, która jest łatwiejsza do zrozumienia dla człowieka. Rozumowanie oparte na regułach ma również tę zaletę, że można je wyrazić formalnie, w kategoriach logicznych, co prowadzi do łatwości programowania. Jak wszystkie systemy, które tworzą ogólne widoki konkretnych danych, jest to jednak przybliżenie i z czasem może wymagać udoskonalenia. (Być może trzeba będzie nawet zrezygnować, jeśli zmienią się okoliczności). Zaawansowane systemy OLAP przeprowadzają powtarzające się kontrole tego typu reguł. Niektóre schematy wręcz „eksperymentują” z regułami, modyfikując ich parametry poprzez dodanie małego elementu losowego (symulowane wyżarzanie) lub łącząc części reguł w sposób analogiczny do rozmnażania płciowego (algorytmy genetyczne). Reguły są „wyraźne”: o ile rozumiemy nazewnictwo języka logicznego, w którym reguła jest napisana, możemy przynajmniej w zasadzie (w praktyce reguła może być dość złożona) zrozumieć jej wyprowadzenie. Istnieją inne potężne techniki, które można wykorzystać do kierowania naszą strategią, które nie pozwalają nam tak łatwo zrozumieć, dlaczego one pracują. To nie jest magia, choć czasami prawie jako taka się sprzedaje. Jednym z przykładów jest sieć neuronowa, która składa się z bardzo dużej liczby prostych, połączonych ze sobą jednostek, które mogą wykonywać funkcje logiczne. Zdolność tych sieci do wykonywania swoich zadań wynika z wysokiego stopnia łączności między nimi, co daje początek innej nazwie tej klasy technik: koneksjonizmowi. Zazwyczaj pojedynczy element w sieci neuronowej zachowuje się w sposób opisany na rysunku

Do elementu neuronowego wprowadza się szereg wyjść innych elementów neuronowych, każdy poprzez element ważący, który zmienia siłę jego działania. Każdy element może mieć inną wagę. Następnie element neuronowy sumuje wszystkie te ważone dane wejściowe i daje wynik, który nie jest ich prostą sumą. W rzeczywistości ma kształt podobny do kształtu „S” pokazanego na rysunku. Ten kształt, który jest zbliżony do sposobu, w jaki zachowuje się neuron biologiczny w mózgu, bardzo słabo reaguje na małe sygnały wejściowe i ma tendencję do nasycania się dużymi. Oznacza to, że w procesach koneksjonistycznych, które tworzą sieć, bardzo małe jest ignorowane, a bardzo duże nie może nadmiernie dominować. Charakter połączenia pokazano na rysunku

Neurony są ułożone w trzech warstwach: warstwa wejściowa, która otrzymuje dane do analizy, warstwa wyjściowa, która daje odpowiedź, na przykład rozpoznanie jednego obiektu wśród wielu, oraz warstwa ukryta. W typowym przykładzie OLAP moglibyśmy chcieć podzielić naszą bazę klientów na tych, którym warto zarządzać kontem, tych, do których należy po prostu wysłać wiadomość e-mail i tych, do których w ogóle nie warto się kontaktować. Mamy szereg przykładowych danych dla każdego z tych typów klientów. Nazywamy to „zestawem treningowym”. Tabela danych może być dość złożona: kod pocztowy, wiek, zawód itp. Każdy z tych wymiarów w tabeli danych jest arbitralnie przypisany do jednego z elementów wejściowych sieci. Nasz przykład będzie miał trzy neurony wyjściowe, nazwane następująco: 1 = „zarządzaj”, 2 = „poczta”, 3 = „ignoruj”. Zaczynamy od przypisania losowych wartości do wag sieci i wprowadzamy wartości pierwszego rekordu ze zbioru uczącego do warstwy wejściowej. Jest bardzo mało prawdopodobne, że spowoduje to, że tylko jeden węzeł wyjściowy będzie miał dużą wartość. Możliwe jest jednak zastosowanie prostego algorytmu, który po stwierdzeniu, że dane wejściowe odpowiadają typowi klienta, powiedzmy „1”, zmienia wagi w taki sposób, aby pierwsza wartość wyjściowa była większa, a pozostałe dwa mniejsze. wartości. Drugi przykład tej samej klasy obiektów jest stosowany do danych wejściowych i ponownie przeprowadzany jest proces dopasowywania wag. Ostatecznie wagi zbliżają się do stałej wartości, która w pewnym sensie jest zbiorową „pamięcią” typu 1. Możemy przechowywać wagi jako wzorzec rozpoznawania dla typu 1, a następnie powtórzyć proces z przykładami typu 2, a następnie dla typu 3.  Tak więc, kiedy otrzymujemy dane o nowym kliencie, możemy to przetestować na trzech wzorcach i oczekiwać wysokiej wartości wyjściowej od tego, który najlepiej przewiduje preferencje zarządzania klienta. W przytoczonym przykładzie marketingowym sieć została przeszkolona na podstawie dostosowania wag według klasy, do której należał obiekt. W niektórych przypadkach możliwe jest nawet przeprowadzenie „treningu nienadzorowanego”: sieć spontanicznie zaczyna wyodrębniać różne grupy danych odpowiadające różnym klasom obiektów. Brzmi to dość magicznie, ale tak nie jest. Opiera się na tym, że dane z różnych klas obiektów mają właściwości dające się oddzielić. Różnice te mogą być bardzo trudne do dostrzeżenia dla ludzkich obserwatorów lub klasycznych metod statystycznych, ale muszą istnieć. W rzeczywistości jest to jeden z problemów z sieciami neuronowymi: wykrywają one różnice między różnymi klasami obiektów, ale nie zawsze można zobaczyć, dlaczego. Oznacza to, że generalnie nie można użyć sieci neuronowej do wyodrębnienia „cech”, które mogłyby być użyte za pomocą prostszych lub szybszych technik klasyfikacji; oznacza to również, że trudno jest przewidzieć, jak sieć, która poradziła sobie z jedną klasą problemów, poradzi sobie z inną. Sieci neuronowe zostały przyjęte entuzjastycznie po początkowym okresie sceptycyzmu; część (choć nie całość) tego sceptycyzmu powróciła w ostatnich latach.

Biorąc pod uwagę nasze różne bazy danych skonstruowane w sposób, który pozwala nam wykorzystać ich zawartość do pomocy w planowaniu biznesowym, nadal potrzebujemy sposobu na interakcję z nimi w celu uzyskania tych wskazówek. Istnieje wiele sposobów, na które możemy to zrobić, a robiąc to, na różne sposoby możemy podzielić każde „inteligentne” zachowanie między użytkownika-człowieka a maszynę. Najwcześniejsze systemy po prostu wspierały ludzki osąd, umożliwiając tworzenie zapytań i agregacji zgodnie z intuicją użytkownika dotyczącą tego, co było istotne, lub prezentując dane w sposób, który ułatwiał ich interpretację, na przykład poprzez tworzenie wykresów lub wykresy. Jest to nadal bardzo potężna pomoc w ustaleniu, co jest lub nie jest istotne w danych. Proste pakiety, które mogą, na przykład, łączyć monitor aktywności w witrynie sieci Web z arkuszem kalkulacyjnym Excell, mogą być niezwykle skuteczne w identyfikowaniu osób, które regularnie odwiedzają witrynę. Rozszerzeniem tego jest wizualizacja danych, która wykorzystuje zdolność ludzkiego mózgu do wykrywania znaczenia w dwu- lub trójwymiarowych wzorcach. Sukces wizualizacji danych był w ostatnich latach w dużej mierze wynikiem zwiększonej mocy obliczeniowej. Szybsze maszyny oznaczają, że możliwe jest oglądanie dynamicznie zmienionych renderów danych: zmiana i kompresja skal, obracanie trójwymiarowych wykresów danych, lepsza rozdzielczość kolorów i tak dalej. Oznaczało to również, że rozwój narzędzi został uwolniony od wielu ograniczeń wydajnościowych. Oprócz możliwości konstruowania bardziej przyjaznych interfejsów użytkownika oznacza to również, że wiele operacji wizualizacji może być łatwiej potokowych, dzięki czemu operację skalowania można łatwo połączyć na przykład z procedurą kreślenia 3D, a następnie postrzegane w inny sposób. Stratedzy mogą korzystać z tych narzędzi, aby prezentować w czasie rzeczywistym rozgrywanie scenariuszy decydentom w sali konferencyjnej (którzy, nawiasem mówiąc, sami rzadko

Sama czynność projektowania hurtowni danych może być korzystna sama w sobie: znacznie wyraźniej przybliża prawdziwą naturę kluczowych procesów biznesowych organizacji. Ale magazynowanie ma na celu coś więcej. Mając w pełni zapełniony i w miarę dokładny magazyn, firmy miałyby nadzieję, że będą w stanie wydobyć informacje, które pomogłyby im w lepszym prowadzeniu i/lub przeprojektowywaniu procesów biznesowych. Istnieje co najmniej jedna podstawowa różnica między bazą danych zbudowaną w celu napędzania procesu biznesowego, taką jak obsługa zamówień, a bazą danych wspierającą podejmowanie decyzji, z której wyodrębniane są informacje przeznaczone do prowadzenia strategii, na przykład ocena wyników sprzedaży regionalnej i planowanie kampanii marketingowej: operacyjne bazy danych to zazwyczaj odczyt lub zapis jednej pozycji danych na raz, np. złożenie zamówienia na konkretny produkt, dla konkretnego klienta. Jest to jeden z powodów, dla których standardową praktyką przemysłową stało się korzystanie z relacyjnych baz danych, których indywidualne rekordy można w ten sposób uzyskać dostęp i aktualizować. Z drugiej strony bazy danych do wspomagania decyzji zasadniczo agregują i uśredniają informacje w próbce rekordów danych. („Podaj średnią sprzedaż na klienta w Regionie Północnym, Regionie Południowym, Regionie Wschodnim” itp.) Ze względu na dobre praktyki utrzymywania danych, takie jak normalizacja, wyszukiwanie tych informacji może obejmować odczytywanie wielu różnych tabel. Nawet jeśli tak nie jest, dostęp do każdego pojedynczego rekordu, który spełnia kryteria, może być bardzo powolnym procesem w przypadku dużych baz danych. Za pomocą tej metody może nie być możliwe zapewnienie przetwarzania analitycznego on-line (OLAP), nazwy nadanej usługom wspomagania decyzji, które są dostępne, a ich dostarczenie nie zajmuje godzin lub dni. Rozwiązanie tego problemu jest w zasadzie proste i można je budować na istniejących bazach danych. Wystarczy z góry zdecydować, jakimi kategoriami (lub „wymiarami”) danych chcesz zarządzać — sprzedażą, regionami, grupami demograficznymi klientów itp. — a następnie okresowo wstępnie obliczyć agregaty dla każdego z tych wymiarów. aktualizacja w miarę pojawiania się nowych transakcji. Użyliśmy terminu wymiar dla każdego z elementów zarządzania. Jest to zwykłe określenie, które dało początek innej koncepcji szeroko stosowanej w OLAP – Datacube. Załóżmy dla uproszczenia, że ​​rozważamy tylko trzy wymiary: produkt, region, marża zysku. Następnie możemy przedstawić nasze agregaty danych jako umieszczone w „kostce”

Osie sześcianu to kolumny lub pola w modelu danych operacyjnych, a wartość, marża zysku ze sprzedaży produktu 3 w Regionie Wschodnim, znajduje się w odpowiednim zestawie trzech współrzędnych (trójka) w tym obszarze. Nie ma matematycznego powodu, dla którego musimy trzymać się trzech wymiarów. Wszystkie reguły przetwarzania danych będą działać dla „hiperkostek” o dowolnie wielu wymiarach, ale znacznie ułatwia to wizualizację przez człowieka i wydajność przetwarzania, jeśli ograniczymy liczbę wymiarów do małej wartości. Oczywiście możemy obliczyć kostki, których osie są różne: wiek klienta, grupa społeczno-ekonomiczna, kod pocztowy, kwartały w ciągu roku itd., a dane zarządzania zwykle definiuje się jako serię tych kostek, które zasilają wielowymiarowy system wspomagania decyzji

Istnieją pewne ograniczenia liczby kostek i całkowitej liczby wymiarów, które może obsłużyć OLAP, zarówno pod względem czasu przetwarzania, jak i przechowywania. Aby jak najlepiej wykorzystać te systemy, należy najpierw zastanowić się nad wyborem wymiarów, które w najbardziej zwięzły sposób reprezentują kluczowe zmienne organizacji. Dostawcy magazynów i DSS czasami argumentują, że najlepiej jest wybierać je w dużej mierze na podstawie danych zorientowanych na klienta, ponieważ najprawdopodobniej ujawnią one trendy, które można wykorzystać do zwiększenia rentowności. Problemem jest również architektura bazy danych OLAP. Chociaż koncepcja jest kostką logiczną, baza danych, która jest jego podstawą, może być zaprojektowana na wiele sposobów. Najbardziej radykalne jest odwzorowywanie logicznego sześcianu przez kostkę pamięci, a właściwie zbiór tablic, które razem tworzą zredukowaną wersję kostki, z pominięciem pustych punktów danych. Inne podejścia modyfikują lub rozszerzają tradycyjną bazę danych relacji. Aby uzyskać więcej informacji na ten temat, a także argument, że rzadkie macierze prawdopodobnie zostaną przyjęte w przypadku małych/średnich rozwiązań

Poza tym możesz uwierzyć, że dane, które trafiają do hurtowni, są teraz tak bliskie doskonałości, jak to tylko możliwe. Jest to prawdopodobnie prawda w momencie zapisywania go do bazy danych, ale może się to wydawać zaskakujące, ale może to nie być wystarczający warunek. Do tej pory omówiliśmy tylko problemy związane z wieloma punktami wejściowymi, tj. problem zasadniczo przestrzenny. Bazy danych również cierpią z powodu problemów czasowych: baza danych może pozostać niezmieniona, ale okoliczności jej wypełnienia mogą nie. Przede wszystkim kwestia integralności referencyjnej: jeśli np. element danych Y dziedziczy wartości, właściwości, metody itp. z elementu danych X, to uzasadnienie dalszego istnienia Y w modelu danych zależy od dalsze istnienie X. Firma zależna może istnieć jako taka tylko wtedy, gdy firma macierzysta nadal istnieje, podając jeden prosty przykład. Nie oznacza to, że spółka zależna zaprzestaje prowadzenia działalności, może nadal to robić, nawet pod tą samą nazwą, ale ważne jest, aby baza danych miała jakiś sposób na rozróżnienie zmiany okoliczności. W przypadku takich relacji często dobrym pomysłem jest rozszerzenie struktury danych o informacje o znacznikach czasu, które mogą być okresowo aktualizowane, co określa daty rozpoczęcia i zakończenia, dla których informacje są uważane za ważne. Możliwe jest uruchomienie inteligentnego oprogramowania w hurtowni danych w celu testowania takich kwestii, na przykład sprawdzenie wszystkich wpisów w spółkach macierzystych i zależnych pod kątem istotnych zmian w zachowaniu (np. zmiana adresu do faktury, pociągająca za sobą reorganizację lub rozpuszczenie).

Zawsze były problemy z integralnością danych, ale w eBiznesie będzie to jeszcze większy problem, z co najmniej trzech powodów: po pierwsze, wzrośnie sama ilość danych, a więc proporcjonalnie wzrośnie potencjał błędu. Po drugie, łączenie istniejących organizacji w tymczasowe, rozszerzone przedsiębiorstwa doprowadzi do niezgodności między systemami i być może niechęci do przyjęcia odpowiedzialności za naprawienie rzeczy, zwłaszcza za wspieranie tego, co jest postrzegane jako przejściowe relacje. Po trzecie, utrata kontroli nad wprowadzaniem danych. Zamiast stosunkowo niewielu, dobrze wyszkolonych i nadzorowanych pracowników wprowadzania danych, środowisko internetowe przewiduje, że znaczny procent danych wprowadzanych jest przez klientów i dostawców, którzy mają niewielką wiedzę lub chęć dbania o system, który nie jest ich własnym. Będzie też rosnąca ilość danych pochodzących ze stosunkowo niedokładnych kodów kreskowych i innych czytników. Ogólnie rzecz biorąc, dane będą pochodzić ze źródeł o znacznie mniejszej liczbie wbudowanych funkcji sprawdzania jakości. Problemem do rozwiązania jest to, jak poprawić te dane po ich zebraniu, a przynajmniej jak zminimalizować ewentualne szkody. Wcześniej w tym rozdziale opisaliśmy trzy koncepcyjne etapy tworzenia baz danych i hurtowni e-biznesu. Integralność danych można poprawić, przetwarzając je w trzech głównych punktach cyklu.

Pierwszym miejscem, w którym możemy zweryfikować dane i wykluczyć błędy, jest konkretna aplikacja, np. formularz zamówienia. Oczywiście bardzo ważne jest zapewnienie przeprowadzenia jak największej liczby kontroli przed zaakceptowaniem danych. Należy egzekwować i być może ponownie egzekwować standardowe praktyki tworzenia sum kontrolnych danych. (Sumy kontrolne są wczesną formą podpisu cyfrowego, zwykle stosowaną do produktu lub mechanizmu płatności: wyobraź sobie przypadek, w którym produktom firmy są przypisywane kody numeryczne w prostej kolejności całkowitej. Na tym kodzie wykonywana jest operacja matematyczna, która powoduje wygenerowanie dodatkowe cyfry, które są dołączane do oryginalnego kodu w celu utworzenia pełnego kodu dla produktu. Operacja cyfry kontrolnej jest wykonywana przez dowolny system, który otrzymuje kod produktu. To odwraca działanie matematyczne i sprawdza, czy cyfry kontrolne i podstawowe kod są kompatybilne na przykład bardzo prostym podejściem może być dodanie „1” do wszystkich nieparzystych kodów produktów i „0” do wszystkich parzystych. W obu przypadkach zsumowanie cyfr dałoby liczbę parzystą, chyba że dane zostały po drodze uszkodzone. Jest to bardzo szczątkowe i niezbyt dokładne lub wydajne rozwiązanie, ale demonstruje zasadę.) O ile to możliwe, granice wartości danych należy sprawdzić przy najbliższej okazji. Formularze internetowe można sprawdzić na kliencie, zanim zostaną wysłane na serwer, za pomocą apletu Java przesłanego z formularzem. Dzięki temu można upewnić się, że pole kodu pocztowego zostało wypełnione, sprawdzić datę urodzenia, aby sprawdzić, czy mieści się ona w dopuszczalnych granicach i tak dalej. Jednak nie zawsze jest możliwe przeprowadzenie tych kontroli w tym momencie. Klienci mogą nie być w stanie zaakceptować apletów lub nie chcą ich akceptować. Aplikacja może być zbyt stara, aby można ją było skutecznie przepisać z uwzględnieniem kontroli integralności. Może się zdarzyć, że z wielu innych powodów nie jest możliwe przeprowadzenie wszystkich kontroli na etapie wejściowym. W każdym razie przejdą niektóre błędy. Istnieje również problem z semantyką danych lokalnych i korporacyjnych. Znaczenie terminu dotyczącego danych w jednym wniosku może nie odpowiadać dokładnie znaczeniu terminu o podobnej nazwie w innym: typowym przykładem może być termin „lokalizacja”. Dla jednej aplikacji lub jednej firmy w przedsiębiorstwie może to oznaczać dzielnicę kodów pocztowych, inną konkretną zatokę magazynową. Istnieje potrzeba pogodzenia tych różnych punktów widzenia, które nie są błędami, ale nadal mogą zepsuć procesy biznesowe. Temu problemowi uzgadniania zwykle nadaje się znacznie bardziej pozytywną nazwę: integracja i transformacja danych. Tutaj potrzebujemy mieszanki oprogramowania, które w pierwszej kolejności potrafi odwzorować niskopoziomową strukturę danych – m.in. relacyjne i płaskie bazy danych – do wspólnego formatu do przetwarzania, a następnie przeanalizuj je, aby sprawdzić, czy nie zawiera anomalii. Bardzo prostym przykładem może być odkrycie, że firma, która najwyraźniej zawsze znajduje się pod jednym adresem w jednej aplikacji, zawsze znajdowała się pod innym w innej aplikacji. Jeszcze bardziej podstawowe kwestie, takie jak bazy danych, które obcinają dane wejściowe przy różnych długościach, muszą zostać podjęte. Oczywiście tego typu problemy nie mogły zostać wykryte na etapie pojedynczej aplikacji. Etap integracji i transformacji dodaje zatem wartość do poszczególnych strumieni danych aplikacji, porównując je z korporacyjnymi modelami danych używanymi przez hurtownię danych i operacyjne bazy danych, oznaczając niespójności, a następnie dodając deskryptory metadanych, zanim dane zostaną dopuszczone do wejść do magazynu lub kierować procesem operacyjnym.

Jednym z kilku wyzwań koncepcyjnych, jakie World WideWeb stawia społeczności baz danych, jest kwestia logiki zapytań. Zdecydowanie dominującym paradygmatem w dzisiejszej architekturze baz danych jest relacyjna baza danych z jej dobrze znanym modelem tabelarycznym, podmiotami i relacjami. Przyjęcie tego frameworka w naturalny sposób dało początek specyficznemu podejściu do przeprowadzania zapytań o dane, w szczególności rozwinięciu Simple Query Language (SQL). SQL jest zależny od danych znajdujących się, przynajmniej koncepcyjnie, w wierszach i kolumnach w jednej lub kilku tabelach. Zapytania są tworzone w odniesieniu do nich: „znajdź wszystkich klientów w Indiach zamawiających zapasy o wartości przekraczającej 1 milion USD”, można łatwo przedstawić w ten sposób. Jednak wiele danych on-lineWeb nie jest zestawionych w formie tabel. Zapytania są zwykle oparte na ciągach, wyszukując na przykład „Indie”, być może wzbogacone o operatory logiczne: w ten sposób „Indie” ORAZ „komputer”. Jest to prosty, brudny i dość skuteczny sposób na zebranie obszernego ładunku informacji, ale także odzyskanie wielu, które nie są szczególnie istotne. Próbując zintegrować „czyste” bazy danych z „brudnymi” danymi sieciowymi, musimy żądać kompromisu z obu stron. To już się dzieje. W przypadku baz danych rośnie świadomość, że indeksowanie zawartości jest ważne: streszczenia zawartości tworzone są automatycznie i można je przeszukiwać za pomocą łańcuchów logicznych. Po stronie internetowej coraz częściej praktykowane jest pojawianie się stosunkowo znormalizowanych metadanych opisujących zawartość stron internetowych. Omówimy te aspekty dalej, gdy przyjrzymy się ekstrakcji wiedzy. Wcześniej w tym rozdziale omówiliśmy XML jako sposób mapowania między dokumentami handlowymi współpracujących organizacji. W szczególności zwróciliśmy uwagę, że organizacje często mają różne poglądy na temat niezbędnych pól na fakturach, formularzach zamówień itp. Nie jest to charakterystyczne dla handlu internetowego; jest to również problem w przypadku łączenia baz danych zaprojektowanych przez różne zespoły. Ogólnie rzecz biorąc, ten problem z danymi jest bardziej złożony niż przypadek handlowy. Metadane przechowywane w bazach są często określane jako służące dwóm celom: administracyjnym i biznesowym. Metadane administracyjne dotyczą sposobu zarządzania danymi: kiedy zostały/ma być, zaktualizowane, czy zostały oczyszczone, ich źródło i tak dalej. Metadane biznesowe opisują, czym są dane: ich związek z pewnym procesem biznesowym, zasady, według których są uzyskiwane z innych pozycji („zysk” ¼ „dochód” – „koszt”) i tak dalej. Przy tworzeniu systemu wymiany danych konieczne jest uwzględnienie zarówno rodzajów informacji metadanych, jak i reguł konwersji między metadanymi dla różnych baz danych. Należy zapewnić narzędzia umożliwiające osobom niebędącym ekspertami tworzenie tych mapowań.

Chociaż w najlepszym z możliwych światów projektowanie systemów informatycznych dla przedsiębiorstw powinno zaczynać się od odgórnego określenia, czym chcemy zarządzać, a następnie integracji śrub i nakrętek, które to zapewnią, prawie nigdy nie zaczynamy od tak korzystnego punkt widzenia: dziedzictwo i liczne inicjatywy w ramach zainteresowanych organizacji zwykle to uniemożliwiają. W związku z tym należy wykonać dość dużo pracy, po prostu łącząc to, co już istnieje. Zazwyczaj zasoby danych organizacji znajdują się w wielu miejscach, w różnych formatach

Pozycja pokazana na rysunku przedstawia realia wielu organizacji. Często stanowią one pole bitwy między zintegrowaną, ale być może nie reagującą lub biurokratyczną kontrolą sprawowaną przez dział IS firmy, a nowszymi, fragmentarycznymi inicjatywami podejmowanymi przez poszczególne jednostki funkcjonalne, które szybciej tworzyły własne data marty. W tę i tak już zagmatwaną scenę został wrzucony korporacyjny Intranet, który ma zapewnić każdemu w organizacji bezpośredni dostęp online do wiedzy korporacyjnej. W takich sytuacjach oczekiwania tych osób są czasami bardzo zawiedzione, gdy powiedziano im, że jedynym sposobem, w jaki można uzyskać dostęp do plików z jednego systemu przez inny, jest fizyczny transport taśm lub dysków z danymi. To nie wszystko, często dane muszą być następnie uruchamiane przez programy konwertujące w trybie off-line, których opracowanie zajmuje trochę czasu i może zapewnić tylko bardzo ograniczone okna na dane, ze względu na różnice w modelach danych. Nawet jeśli fizyczny transport można zastąpić często drogi i wciąż raczej powolny, masowy transfer plików drogą elektroniczną (rysunek 2.9), przy użyciu takich metod, jak Internet File Transfer Protocol (FTP), integracja aplikacji nie jest łatwa do uzyskania na różnych platformach. Ponadto dane nie są statyczne.

Zmienia się, a zmiany te muszą być zsynchronizowane we wszystkich aplikacjach składających się na proces biznesowy. Transfer plików między procesami nie musiałby zatem odbywać się tylko raz, ale za każdym razem, gdy odpowiednie dane uległyby zmianie. To szybko staje się niemożliwe do opanowania. Zamiast tego dane powinny być utrzymywane tylko na platformie hosta i tylko odpowiednie ich części są pobierane przez zależne procesy znajdujące się w innych systemach, gdy jest to wymagane. Aby to osiągnąć, jednym podejściem jest zastosowanie zasad komponentów, jak opisano we wcześniejszej dyskusji o architekturze

Komponenty, które są interfejsem między dwoma systemami, muszą być zdolne do utrzymania niezawodnej komunikacji poprzez interfejs, być może z pełną integralnością przetwarzania transakcji, zaangażowaniem i wycofaniem. W praktyce zarządzanie tym może odbywać się za pomocą oddzielnego pakietu oprogramowania uruchomionego na osobnym serwerze. Podstawowym wymogiem jest to, że struktura danych jednej bazy danych musi być odwzorowana na strukturę drugiej: typowym przykładem tego jest konwersja wartości jednostkowych – wagi funtów na kilogramy, dolarów amerykańskich na franki francuskie itp. – które mogą wystąpić w przypadku budowania przedsiębiorstw wielonarodowych. Innym powszechnym przykładem są tabele danych relacyjnych baz danych: niektóre mogą używać jednej kolumny zawierającej adres i kod pocztowy, podczas gdy inne, które przyjęły marketing kodu pocztowego, mogą podzielić adres i kod na dwie oddzielne kolumny. Oczywiście zaletą jest tworzenie rozwiązania (komponentowego lub innego), które dostarcza programistom zestaw narzędzi, które w prosty sposób pozwalają na konstruowanie reguł przeprowadzania takich konwersji. Obecnie istnieje szereg rozwiązań komercyjnych. Zobacz na przykład Hummingbird’s Genio Suite. Oczywiście pojawiają się problemy z wydajnością, gdy uruchamiamy aplikacje, które mogą wymagać nie tylko złożonych zapytań o dane, ale nawet bardziej złożonych i czasochłonnych procesów pośredniczących, które mogą być uruchamiane na danych. Jednym z rozwiązań jest zapewnienie hierarchicznego zestawu procesów, z prostymi wywoływanymi do prostych zadań i delegowanie jak największej ilości pracy do istniejących silników baz danych, które są zoptymalizowane pod kątem własnych danych. W przypadku bardziej złożonej wymiany danych wymiana może być prowadzona przez program zarządzający, działający na osobnym serwerze. Ponadto, gdy bazy danych znajdują się na tym samym serwerze lub są bezpośrednio połączone przez bramę komunikacyjną, czasami możliwe jest umożliwienie im bezpośredniej komunikacji, zmniejszając w ten sposób potrzebę „puzonowania” strumienia danych od źródła do serwera zarządzającego do miejsca docelowego.