Zrób Sobie Firmę

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.

Dobre organizacje gromadzą dane w celu prowadzenia działalności, ale także do przyszłych analiz, aby kierować ich strategią. Logiczna (nie fizyczna) integracja tych danych w pojedynczą, zarządzalną przestrzeń informacyjną, zwłaszcza tam, gdzie ma to na celu wspieranie podejmowania decyzji zarządczych, nazywana jest hurtownią danych. Hurtownia danych to podejście koncepcyjne, a nie rzecz fizyczna, której celem jest integracja wielu rzeczywistych baz danych, które mogą być montowane na heterogenicznym zbiorze platform sprzętowych i programowych, zwykle rozproszonych. W poprzednim rozdziale omówiliśmy ogólny przypadek technicznej integracji takich systemów, odnosząc się do architektur komponentów i potrzeby interpretacji między bazami danych, od niskopoziomowych formatów danych po wysokopoziomową semantykę danych. Omówimy tutaj głównie technologie oparte na aplikacjach, które leżą na nich. Projektując hurtownię danych, należy podjąć decyzję, czy ma ona być zorientowana na dane, czy na aplikacje. W pierwszym przypadku model danych dla hurtowni jest zaprojektowany (w miarę możliwości) tak, aby był niezależny od poszczególnych aplikacji. Raczej stara się być wystarczająco wszechstronna, aby objąć istniejące i prawdopodobne przyszłe zastosowania. Dostosowanie do potrzeb dowolnej konkretnej aplikacji lub użytkownika jest zapewniane przez oprogramowanie do obsługi zapytań i prezentacji

Na rysunku jest to dolna warstwa danych, która jest pierwsza, z z niego generowane są widoki zorientowane na aplikację. To holistyczne podejście jest często niewykonalne dla organizacji, które rozwinęły obsługę danych w sposób zdecentralizowany. Częściej rozwiązanie będzie zorientowane na aplikację (lub kilka rozwiązań zorientowanych na aplikacje). Rozwiązanie magazynowe opiera się wówczas na integracji wielu baz danych, które obsługują jedną jednostkę funkcjonalną, na przykład marketing. Jak pokazano na rysunku

dane często występują w postaci tabel w relacyjnych bazach danych. Ze względów historycznych są to często różne roczniki i wzornictwo. Hurtownia aplikacji rozwiązuje skromniejszy problem integracji tych danych w coś, co można przeszukiwać w jednorodny sposób, bez przeprojektowywania podstawowego modelu danych. Nomenklatura jest dość nieprecyzyjnie zdefiniowana, ale hurtownie aplikacji są zwykle większymi i bardziej ambitnymi przykładami data martów, które powstają z nowych lub istniejących baz danych i są przeznaczone do obsługi stosunkowo zwartych procesów biznesowych, takich jak zarządzanie klientami. Bardzo realne niebezpieczeństwo pojawia się, gdy składnice danych nakładają się na dane, które zawierają. Utrzymanie i integralność stają się poważnym problemem i wiele czasu może zająć rozwiązywanie sporów między działami finansowymi i marketingowymi, na przykład, jeśli każdy ma dostęp do innego zestawu danych dotyczących sprzedaży i algorytmów obliczania marży. Niemniej jednak wiele organizacji wybiera tę drogę ze względu na trudności i opóźnienia związane z uzyskaniem zgody kierownictwa na rozwiązanie globalne [64]. Chociaż celem projektowania hurtowni może być stworzenie ogólnego rozwiązania, które jest niezależne od poszczególnych aplikacji, główną cechą takiego systemu musi być to, że jest on zorientowany na biznes, a nie po prostu ogromne repozytorium danych. W szczególności powinien być dostosowany do modelu procesu, a nie tradycyjnego modelu danych [65]. Jednym z powodów, dla których jest to ważne, jest wydajność. Zapytania dotyczące tradycyjnej, jednoprzedmiotowej bazy danych, używanej do obsługi pojedynczej operacji, mogą stosunkowo łatwo przeniknąć dane w sposób optymalizujący wydajność – modelarz danych wie, które są dominującymi jednostkami i atrybutami, i może odpowiednio zaprojektować bazę danych. Jednak tam, gdzie hurtownia ma obsługiwać kilku „masterów”, ich zapytania trafią do bazy z kierunków, których niekoniecznie można było przewidzieć. W związku z tym zwyczaj i praktyka bazy danych mogą wymagać modyfikacji. Na przykład normalizacja, zasada projektowa, zgodnie z którą wpisy nie powinny pojawiać się częściej niż to konieczne, często musi być zaniechana w interesie szybkości [66]. Ponadto, chociaż warto zachować centralną, ogólną koncepcję magazynu, może być konieczne tworzenie podzbiorów danych na lokalnych serwerach, dostosowanych do potrzeb konkretnych jednostek biznesowych. Oprogramowanie magazynowe będzie w tym przypadku zawierało mechanizmy synchronizacji tych lokalnych baz danych z systemem nadrzędnym, z regularną aktualizacją i oznaczaniem danych ze szczegółami ostatniej aktualizacji.

Przypuśćmy, że jesteśmy w stanie zdefiniować, uchwycić i przeanalizować pokaźny zbiór dokładnej „wiedzy korporacyjnej”. Co z tym zrobimy? W szczególności, kto powinien mieć do niego dostęp, być może nawet z możliwością interakcji w celu opisania go lub zmiany? Tradycyjny model dostępu do danych korporacyjnych był dość restrykcyjny: działy finansowe miały dostęp do danych finansowych, działy marketingu do danych marketingowych i tak dalej. Częściowo powodem było to, że bazy danych były oddzielne i skonfigurowane tylko do obsługi procesów jednostki funkcjonalnej, która je ustawiała; część tego stanowiła trudność w zapewnieniu wygodnego i bezpiecznego dostępu do nich z odległych miejsc. Wielowymiarowa prezentacja danych i możliwości transmisyjne firmowych intranetów zmieniły to wszystko. Teoretycznie każdy, kto ma prawa dostępu do danych, powinien mieć możliwość ich przeglądania, być może nawet dostosowanego do ich modelu biznesowego, a nie do modelu biznesowego. Czasami te prawa dostępu mogą zostać rozszerzone poza samą firmę, na partnerów, dostawców, a nawet klientów. Niektóre firmy, ostrożnie lub w inny sposób, eksperymentują obecnie z takim podejściem do uwalniania wiedzy w postaci portalu korporacyjnego. Zasadniczo chodzi o kierowanie wieloma procesami skoncentrowanymi na wiedzy w firmie, które bezpośrednio lub pośrednio wchodzą w interakcję z ludźmi za pośrednictwem zestawu interfejsów internetowych, z których każdy ma zestaw praw dostępu do jednego, spójnego zbioru danych przedsiębiorstwa. Jeśli jest to możliwe, można uzyskać pewne wyraźne korzyści, w tym:

† Zarówno publiczne, jak i prywatne aspekty firmy opierają się na tym samym modelu informacyjnym. Poglądy klientów i wewnątrz przedsiębiorstwa nie są zatem niespójne, a jeśli różnią się szczegółami i wiedzą, istnieje jasne wyjaśnienie, dlaczego tak się dzieje.

† Dane klienta i wewnętrzne dane procesu są takie same. Gdy klient śledzi niedostarczenie zamówienia, agent pomocy i dyspozytor, którego pytają, będą pracować z tą samą ścieżką audytu. Wszystkie będą działać z tymi samymi nagłówkami cen i szczegółów dotyczących zamawiania zapasów (chociaż oczywiście mogą istnieć dane „warunków specjalnych” połączone z pełną integralnością referencyjną i widoczne tylko dla przedstawicieli firmy).

† Działy marketingu i projektowania będą miały dostęp do komentarzy klientów na temat produktów firmy. Wady produktów, sugestie nowych funkcjonalności, porównania z innymi produktami można pracować wspólnie, dzieląc się wspólną wiedzą i postrzeganiem.

† Jednostki funkcjonalne i zespoły ds. planowania wykonawczego będą miały wspólny pogląd semantyczny dotyczący możliwych do zarządzania elementów organizacji: „region” sprzedaży lub geograficzny będzie konsekwentnie definiowany, a dyskusje na temat wyników i targetowania mogą być prowadzone sprawnie i bez nieporozumień.

Zwróć uwagę, jak klient stał się częścią zespołu wiedzy. Jednym z kluczowych elementów budowania e-biznesu będzie zdolność do czerpania korzyści z danych klientów on-line. Sieć daje znacznie większą moc gromadzenia wzorców zachowań on-line, które demonstrują upodobania i awersje do produktów. Należy rozważyć, jak najlepiej zintegrować te informacje z dowolnym firmowym magazynem danych. Oczywiście należy unikać opierania tego głównie na wprowadzaniu wiadomości e-mail, ponieważ jest to trudne do przekonwertowania na automatyczne wprowadzanie. Możliwe są ankiety on-line, wiele informacji można też uzyskać, projektując formularze, które można wypełnić przez callcenter agentów i przenoszone do dostępnej bazy danych.

Niezależnie od tempa pełnej standaryzacji pionowej XML zdarzają się DTD (niezależnie od tego, czy na przykład wszyscy zgadzają się co do standardowego sposobu opisu produktu), bez wątpienia przed technologią w zakresie ogólnej obsługi transakcji handlowych, szczególnie w połączeniu z językami programowania, takimi jak Java, czeka bardzo pozytywna przyszłość. Formularze zamówień on-line to prosty przykład: najprostszym sposobem zaprogramowania formularza zamówienia on-line jest stworzenie formularza HTML, który umożliwia klientowi wpisanie danych i przesłanie ich na serwer WWW. Niestety, jak zauważyliśmy w innym miejscu, podczas wprowadzania danych do systemu generowany jest wysoki stopień błędu, który może sięgać nawet 20% w przypadku formularza wielowierszowego. Nie ma łatwego i niedrogiego sposobu na naprawienie tego, co prowadzi do niezadowolenia klientów i utraty interesów. Zamiast tego coraz częściej rozwiązaniem jest wysyłanie formularza do terminala klienta z osadzonym fragmentem kodu wykonywalnego do sprawdzania formularzy (np. aplet Java), który działa na komputerze klienta i sprawdza wprowadzone dane z szablonem. XML zapewnia doskonały sposób kodowania tego szablonu. Jest w języku, który jest stosunkowo łatwy do zrozumienia; może być generowany niezależnie od kodu Java i udostępniany kodowi i koderowi, gdy jest to wymagane; może być rozwijany wokół procesu biznesowego, a nie aplikacji sprawdzającej formularz klienta; można go zsynchronizować ze zmianami w procesie biznesowym, zapewniając integralność. Ponadto jest to sposób na szerokie publikowanie w Internecie zasad handlowych organizacji. Te procesy handlowe XML mogą być łatwo dostępne przez zdalnych inteligentnych agentów, aby umożliwić w pełni zautomatyzowane przetargi, współpracę itp., jak opisano wcześniej. Nawet tam, gdzie różne organizacje stosują różne opisy XML swoich reguł handlowych, ustrukturyzowana i jasno zdefiniowana dyscyplina kodowania procesu może w wielu przypadkach umożliwić tworzenie mapowań między nimi, umożliwiając w ten sposób handel.

Zwykłym sposobem przesyłania danych internetowych między hostami online jest obecnie HTML. Problem z HTML polega na tym, że chodzi głównie o wygląd informacji, a nie o to, co one „oznaczają”. Możemy używać terminów „tytuł”, „autor”, „data publikacji”, „kod ISNB” itp., ale nie mają one specjalnego znaczenia w HTML. Dlatego nie można ich łatwo wybrać automatycznie w większym tekście; nie można też sprawdzić poprawności ciągu, który one reprezentują. Nie możemy na przykład łatwo sprawdzić, czy podana wartość ISBN (np. 0-471-98794-8) składa się z zestawu pól zawierających tylko liczby, oddzielonych myślnikami. Ten brak HTML został w dużej mierze naprawiony w rozwoju Extensible Mark-up Language (XML). XML nadal zapewnia mechanizm układu i wyglądu tekstu, podobnie jak HTML, ale jest znacznie silniejszy w swojej zdolności do nadawania jakiejś formy „znaczenia” wybranym terminom w tekście, a wybór ten jest w dużej mierze w gestii autora . Weźmy przykład z naszej dyskusji o tym, jak opisać konkretną książkę (Networked Futures): chcemy określić, że ma tytuł, autora, wydawcę, identyfikator ISBN, datę i opis. Następnie uproszczony opis XML jest pokazany poniżej

<items> w nawiasach to są tagi. W przedstawionych przykładach każdy z nich reprezentuje typ danych. Informacje istotne dla konkretnego typu tagu to te zawarte między parą <items> i </items> (Użytkownicy HTML będą dobrze zaznajomieni z tą notacją.) W przykładzie widzimy, że istnieje globalny element o nazwie <book> w którym zagnieżdżonych jest wiele innych tagów: <title>, <author>, itd. Pokazaliśmy tylko jedną warstwę zagnieżdżania, ale XML pozwala nam to rozszerzyć w dowolnym stopniu. Na przykład możemy sobie wyobrazić, że tytuł. składał się z dwóch części:

i tak dalej. Korzyść z automatycznego przetwarzania powinna być jasna: ponieważ znaczniki są zdefiniowane i zawierają ciągi danych, programowi znacznie łatwiej jest „zrozumieć”, że „Networked Futures” jest tytułem, a nie autorem lub fragmentem wolnego -opis tekstowy, oczywiście pod warunkiem, że jest świadomy sposobu, w jaki definiujemy książkę i terminów związanych z tą definicją. Jak osiąga się ten ostatni warunek? Musimy upublicznić naszą definicję „książki”. Możemy to zrobić w XML na wiele sposobów, z których jednym jest nagłówek naszego przykładu powyżej z odniesieniem do definicji typu dokumentu (DTD). To kolejny dokument, który zawiera ogólny szablon „książki” i opcjonalnie dodatkowe zasady ułatwiające sprawdzenie poprawności danych. DTD można zlokalizować poprzez jego adres URL. Zakłada się, że strony handlowe, a nawet organizacje międzynarodowe, takie jak organizacje handlowe, mogłyby umieścić swoje DTD i inne dokumenty XML w Internecie, aby handel mógł odbywać się bez dwuznaczności i błędów. W rzeczywistości XML to znacznie więcej, niż przed chwilą omówiliśmy. W szczególności wiele działań dotyczy definiowania, w jaki sposób XML powinien reprezentować prezentację danych w dokumentach elektronicznych, co oczywiście jest przedmiotem zainteresowania projektantów stron internetowych w eCommerce. Jednak to, co omówiliśmy, jest prawdopodobnie najbardziej znaczącym wpływem, jaki XML wywrze na rozwój elektronicznego biznesu: jego potencjał umożliwiający tworzenie standardowych modeli biznesowych dla transakcji automatycznych. Jak dotąd jest to tylko potencjał; siła napędowa musi pochodzić od modelu do technologii, a modele muszą być tworzone w drodze porozumienia. Jak to się stanie, nie jest jeszcze jasne: czy będzie pochodzić od stowarzyszeń branżowych, współpracy opartej na technologii, takiej jak World Wide Web Consortium, czy od dominujących dostawców oprogramowania? Czy zostanie to osiągnięte w sektorach wertykalnych (np. EPICS i ONIX współpracują nad mapowaniem między ich modelem a XML), czy za pomocą międzysektorowych ogólnych definicji handlowych („faktura”, „odwołanie” itp.)? Rzeczywiście, może się zdarzyć, że niektóre wiodące na rynku przedsiębiorstwa podążą za wczesnym modelem EDI i opracują własne modele handlowe. Chociaż w pewnym sensie może to być szkoda, nie będzie to miało tak wyniszczającego efektu, jak to samo podejście dwadzieścia lat temu. Zastrzeżony EDI tworzył blokadę we wszystkich warstwach procesu, od poziomu bajtów w górę. Tworzenie strategii migracji z własnych definicji XML do wspólnego standardu powinno być łatwiejsze. Ale to nie będzie trywialne. Jeszcze przez jakiś czas przedsiębiorstwa będą musiały ostrożnie stąpać po tym obszarze.

Pomimo ostrzeżeń podanych powyżej, nie ma wątpliwości, że internetowy handel EDI szybko stanie się wszechobecny w całej społeczności handlowej. Jak już powiedzieliśmy, usługi TCP/IP i Internet zapewnią znacznie łatwiejsze środowisko transmisji dla transakcji międzyfirmowych. Widzieliśmy, jak oprogramowanie pośredniczące oparte na komponentach pozwala nam łączyć klientów i serwery w wielowarstwowe architektury dowolnie złożonych procesów. Interoperacyjność baz danych w Internecie stała się rzeczywistością. Co z jednostkami danych i modelami biznesowymi, które je napędzają? Co musimy zrobić, aby znacznie łatwiej osiągnąć interoperacyjność międzybranżową? Na rysunku podajemy bardzo stylizowaną i uproszczoną fakturę, która może przechodzić między dwiema firmami.

Aby mógł on zostać przetworzony automatycznie, należy stworzyć i narzucić pewne specyfikacje i ograniczenia. Po pierwsze, dokładnie tak jak w przykładzie księgowym, musimy zdefiniować różne elementy składające się na tę transakcję. Musimy zarezerwować zestaw nazw odpowiadający różnym częściom formularza: „faktura”, „od” (który prawdopodobnie jest obiektem zwanym „dostawca”) itp. Muszą one zostać umieszczone w internetowej bibliotece dozwolonych terminów i terminologii. Prawdopodobnie musimy zdefiniować i rozgraniczyć cały zestaw elementów, które są wymagane do wystawienia prawidłowo sformułowanej faktury – w podanym przykładzie można się spierać, że nie ma wątpliwości, czy cena odnosi się do kosztu jednostkowego lub koszt dwóch sztuk. Musimy również ustawić ograniczenia dotyczące używanych zestawów znaków, dozwolonej liczby znaków, być może symboli specjalnych, takich jak £ lub $ i tak dalej. Jeszcze jedno: faktura jest podpisana podpisem cyfrowym, który prawdopodobnie zawiera dane uwierzytelniające firmy wystawiającej oraz funkcję skrót, która zapewnia, że ​​dane nie zostały naruszone. Oprócz określenia wszystkich wcześniej wspomnianych ograniczeń, musi istnieć jakiś sposób na opisanie, w jaki sposób ta sygnatura ma być wyprowadzona i sprawdzona. Podsumowując, nasz proces EDI musi:

† Jeżeli transakcja dotyczy ludzi, upewnij się, że można ją zaprezentować na wszystkich prawdopodobnych platformach prezentacyjnych.

† W przestrzeni wspólnej dla wszystkich zaangażowanych stron zdefiniuj terminologię transakcji.

† Ustaw limity wartości, które może mieć każdy z terminów.

† Prawdopodobnie sprawdź ich zgodność, on-line, w czasie rzeczywistym i uruchom procedurę obsługi wyjątków, aby rozwiązać wszelkie problemy.

† Zdefiniuj i wykonaj procedury w celu zakończenia innych aspektów transakcji.

Musimy więc przesyłać dane między stronami zaangażowanymi w transakcję, wraz ze standardowymi szablonami, które kontrolują jej integralność, prezentację i które mogą aktywować wymagane procesy.