Model jednostka-atrybut-wartość - Entity–attribute–value model

Model encja-atrybut-wartość ( EAV ) to model danych do kodowania w sposób efektywny przestrzennie encji, w którym liczba atrybutów (właściwości, parametrów), których można użyć do ich opisania, jest potencjalnie ogromna, ale liczba, która będzie faktycznie dotyczą danego podmiotu jest stosunkowo skromne. Takie byty odpowiadają matematycznemu pojęciu macierzy rzadkiej .

EAV jest również znany jako model obiektowo-atrybutowo-wartościowy , pionowy model bazy danych i otwarty schemat .

Struktura danych

Ta reprezentacja danych jest analogiczna do efektywnych przestrzennie metod przechowywania macierzy rzadkiej , w której przechowywane są tylko niepuste wartości. W modelu danych EAV każda para atrybut-wartość jest faktem opisującym jednostkę, a wiersz w tabeli EAV przechowuje pojedynczy fakt. Tabele EAV są często określane jako „długie i wąskie”: „długie” odnosi się do liczby wierszy, „chude” do kilku kolumn.

Dane zapisywane są w trzech kolumnach:

Podmiot : element jest opisany.
Atrybut lub parametr : zwykle realizowany jako klucz obcy do tabeli definicji atrybutów. Tabela definicji atrybutów może zawierać następujące kolumny: identyfikator atrybutu, nazwę atrybutu, opis, typ danych oraz kolumny wspomagające walidację danych wejściowych, np. maksymalna długość ciągu i wyrażenie regularne, zestaw dopuszczalnych wartości itp.
Wartość atrybutu.

Przykład

Zastanów się, jak można by próbować przedstawić zapis kliniczny ogólnego przeznaczenia w relacyjnej bazie danych. Jasne utworzenie tabeli (lub zestawu tabel) z tysiącami kolumn jest niewykonalne, ponieważ zdecydowana większość kolumn miałaby wartość null . Aby skomplikować sprawy, w długiej dokumentacji medycznej, która śledzi pacjenta w czasie, może występować wiele wartości tego samego parametru: na przykład wzrost i waga dziecka zmieniają się wraz z jego wzrostem. Wreszcie wszechświat odkryć klinicznych stale się powiększa: na przykład pojawiają się choroby i opracowywane są nowe testy laboratoryjne; wymagałoby to ciągłego dodawania kolumn i ciągłego poprawiania interfejsu użytkownika. (Sytuacja, w której lista atrybutów często się zmienia, nazywana jest w żargonie bazy danych „zmiennością atrybutów”).

Poniżej przedstawiono migawkę tabeli EAV z wynikami klinicznymi z wizyty u lekarza w związku z gorączką rano dnia 1.05.98. Wpisy pokazane w nawiasach ostrych są odniesieniami do wpisów w innych tabelach, pokazanych tutaj jako tekst, a nie jako zakodowane wartości klucza obcego dla ułatwienia zrozumienia. W tym przykładzie wszystkie wartości są wartościami dosłownymi, ale mogą to być również predefiniowane listy wartości. Te ostatnie są szczególnie przydatne, gdy wiadomo, że możliwe wartości są ograniczone (tj. enumerable ).

Podmiot . W przypadku ustaleń klinicznych jednostką jest zdarzenie dotyczące pacjenta : klucz obcy do tabeli, który zawiera co najmniej identyfikator pacjenta i jeden lub więcej znaczników czasu (np. data/godzina rozpoczęcia i zakończenia badania), które rejestrują, kiedy opisywane zdarzenie miało miejsce.
Atrybut lub parametr : klucz obcy do tabeli definicji atrybutów (w tym przykładzie, definicje objawów klinicznych). Co najmniej tabela definicji atrybutów zawierałaby następujące kolumny: identyfikator atrybutu, nazwa atrybutu, opis, typ danych , jednostki miary oraz kolumny wspomagające walidację danych wejściowych, np. maksymalna długość ciągu i wyrażenie regularne, maksymalne i minimalne dopuszczalne wartości, zbiór wartości dopuszczalnych itp.
Wartość atrybutu. Zależałoby to od typu danych i wkrótce omówimy sposób przechowywania wartości.

Poniższy przykład ilustruje objawy, które można zaobserwować u pacjenta z zapaleniem płuc .

(<patient XYZ, 1/5/98 9:30 AM>,  <Temperature in degrees Fahrenheit>,  "102" )
(<patient XYZ, 1/5/98 9:30 AM>,  <Presence of Cough>,  "True" )
(<patient XYZ, 1/5/98 9:30 AM>,  <Type of Cough>,  "With phlegm, yellowish, streaks of blood" )
(<patient XYZ, 1/5/98 9:30 AM>,  <Heart Rate in beats per minute>,  "98" )
...

Opisane powyżej dane EAV są porównywalne z zawartością paragonu sprzedaży supermarketu (co zostałoby odzwierciedlone w tabeli Pozycje sprzedaży w bazie danych). Pokwitowanie zawiera tylko szczegóły faktycznie zakupionych przedmiotów, zamiast wymieniać wszystkie produkty w sklepie, które klient mógł kupić, ale nie. Podobnie jak wyniki kliniczne dla danego pacjenta, kwit sprzedaży jest rzadki.

„Entity” to identyfikator sprzedaży/transakcji — klucz obcy do tabeli transakcji sprzedaży. Służy do wewnętrznego tagowania każdej pozycji, chociaż na paragonie informacja o Wyprzedaży pojawia się na górze (lokalizacja sklepu, data/godzina sprzedaży) i na dole (całkowita wartość sprzedaży).
„Atrybut” jest kluczem obcym do tabeli produktów, skąd można wyszukać opis, cenę jednostkową, rabaty i promocje itp. (Produkty są tak samo zmienne jak wyniki badań klinicznych, a może nawet bardziej: nowe produkty są wprowadzane co miesiąc , podczas gdy inne są usuwane z rynku, jeśli akceptacja konsumentów jest niska. Żaden kompetentny projektant baz danych nie zakodowałby na stałe poszczególnych produktów, takich jak Doritos lub Diet Coke, jako kolumny w tabeli).
„Wartości” to zakupiona ilość i łączna cena elementu zamówienia.

Modelowanie wierszy , w którym fakty dotyczące czegoś (w tym przypadku transakcji sprzedaży) są rejestrowane jako wiele wierszy, a nie wiele kolumn , jest standardową techniką modelowania danych. Różnice między modelowaniem wierszy a EAV (które można uznać za uogólnienie modelowania wierszy) to:

Tabela modelowana wierszami jest jednorodna pod względem faktów, które opisuje: tabela Elementy zamówienia opisuje tylko sprzedane produkty. Natomiast tabela EAV zawiera prawie każdy rodzaj faktów.
Typ danych kolumn wartości w tabeli modelowanej wierszowo jest wstępnie określony przez charakter rejestrowanych faktów. Natomiast w tabeli EAV pojęciowy typ danych wartości w określonym wierszu zależy od atrybutu w tym wierszu. Wynika z tego, że w systemach produkcyjnych umożliwienie bezpośredniego wprowadzania danych do tabeli EAV byłoby receptą na katastrofę, ponieważ sam silnik bazy danych nie byłby w stanie przeprowadzić solidnej walidacji danych wejściowych. Zobaczymy później, jak można zbudować ogólne frameworki, które wykonują większość zadań walidacji danych wejściowych, bez niekończącego się kodowania na zasadzie atrybut po atrybucie.

W repozytorium danych klinicznych modelowanie wierszy również znajduje wiele zastosowań; podschemat badań laboratoryjnych jest zazwyczaj modelowany w ten sposób, ponieważ wyniki badań laboratoryjnych są zazwyczaj numeryczne lub mogą być zakodowane numerycznie.

Okoliczności, w których należałoby wyjść poza standardowe modelowanie wierszy na rzecz EAV, wymieniono poniżej:

Typ danych poszczególnych atrybutów jest różny (jak widać w wynikach klinicznych).
Kategorie danych są liczne, rosnące lub zmienne, ale liczba wystąpień (rekordów/wierszy) w ramach każdej kategorii jest bardzo mała. Tutaj, przy tradycyjnym modelowaniu, diagram encji i relacji bazy danych może mieć setki tabel: tabele zawierające tysiące/miliony wierszy/instancji są wizualnie wyróżnione w takim samym stopniu, jak te z bardzo małą liczbą wierszy. Te ostatnie są kandydatami do konwersji na reprezentację EAV.

Taka sytuacja ma miejsce w środowiskach modelowania ontologicznego , gdzie kategorie ("klasy") często muszą być tworzone w locie, a niektóre klasy są często eliminowane w kolejnych cyklach prototypowania.

Pewne ("hybrydowe") klasy mają pewne atrybuty, które nie są rzadkie (obecne we wszystkich lub większości przypadków), podczas gdy inne atrybuty są wysoce zmienne i rzadkie. Te ostatnie nadają się do modelowania EAV. Na przykład opisy produktów wykonane przez korporację konglomeratową zależą od kategorii produktu, np. atrybuty niezbędne do opisania marki żarówki różnią się znacznie od tych wymaganych do opisania urządzenia do obrazowania medycznego, ale oba mają wspólne atrybuty, takie jak opakowanie koszt jednostkowy i jednostkowy.

Opis pojęć

Jednostka

W danych klinicznych jednostka jest zazwyczaj zdarzeniem klinicznym, jak opisano powyżej. W bardziej ogólnych ustawieniach encja jest kluczem obcym w tabeli „obiekty”, która rejestruje wspólne informacje o każdym „obiekcie” (rzeczy) w bazie danych – co najmniej preferowana nazwa i krótki opis, a także kategoria/klasa podmiotu, do którego należy. Każdemu rekordowi (obiektowi) w tej tabeli przypisywany jest wygenerowany maszynowo identyfikator obiektu.

Podejście „tabeli obiektów” zostało zapoczątkowane przez Toma Ślezaka i współpracowników z Lawrence Livermore Laboratories dla bazy danych Chromosome 19 i jest obecnie standardem w większości dużych bioinformatycznych baz danych. Użycie tabeli obiektów nie wymaga równoczesnego korzystania z projektu EAV: konwencjonalne tabele mogą być używane do przechowywania szczegółowych informacji dotyczących kategorii każdego obiektu.

Główną zaletą centralnej tabeli obiektów jest to, że dzięki pomocniczej tabeli synonimów obiektów i słów kluczowych można zapewnić standardowy mechanizm wyszukiwania podobny do Google w całym systemie, w którym użytkownik może znaleźć informacje o dowolnym obiekcie zainteresowania bez konieczności najpierw określ kategorię, do której należy. (Jest to ważne w systemach biologicznych, w których słowo kluczowe, takie jak „acetylocholina” może odnosić się do samej cząsteczki, która jest neuroprzekaźnikiem, lub do biologicznego receptora, z którym się wiąże.

Atrybut

W samej tabeli EAV jest to po prostu identyfikator atrybutu, klucz obcy w tabeli Definicje atrybutów, jak wspomniano powyżej. Jednak zazwyczaj istnieje wiele tabel metadanych, które zawierają informacje związane z atrybutami, które zostały krótko omówione.

Wartość

Konwertowanie wszystkich wartości na ciągi, jak w powyższym przykładzie danych EAV, daje w wyniku prostą, ale nieskalowalną strukturę: konwersje między typami danych stałych są wymagane, jeśli chce się coś zrobić z wartościami, oraz indeks wartości kolumna tabeli EAV jest zasadniczo bezużyteczna. Ponadto nie jest wygodne przechowywanie dużych danych binarnych, takich jak obrazy, w postaci zakodowanej w Base64 w tej samej tabeli, co małe liczby całkowite lub ciągi. Dlatego większe systemy używają oddzielnych tabel EAV dla każdego typu danych (w tym dużych obiektów binarnych „BLOBS”), przy czym metadane dla danego atrybutu identyfikują tabelę EAV, w której będą przechowywane jego dane. Takie podejście jest w rzeczywistości dość wydajne, ponieważ niewielka ilość metadanych atrybutów dla danej klasy lub formularza, z którymi użytkownik zdecyduje się pracować, może być łatwo buforowana w pamięci. Wymaga to jednak przeniesienia danych z jednej tabeli do drugiej w przypadku zmiany typu danych atrybutu.

Historia

EAV, jako uniwersalny środek reprezentacji wiedzy , wywodzi się z koncepcji „ list asocjacyjnych ” ( par atrybut-wartość ). Powszechnie używane dzisiaj, po raz pierwszy zostały wprowadzone w języku LISP . Pary atrybut-wartość są szeroko stosowane w różnych aplikacjach, takich jak pliki konfiguracyjne (przy użyciu prostej składni, takiej jak atrybut = wartość ). Przykładem niebazowego wykorzystania EAV jest UIMA (Unstructured Information Management Architecture), standard zarządzany obecnie przez Apache Foundation i wykorzystywany w takich obszarach, jak przetwarzanie języka naturalnego . Oprogramowanie, które analizuje tekst, zazwyczaj oznacza („dodaje adnotacje”) segment: przykład przedstawiony w samouczku UIMA to program, który wykonuje rozpoznawanie nazwanych jednostek (NER) w dokumencie, dodając adnotację do segmentu tekstu „President Bush” adnotacją- potrójna wartość atrybutu (osoba, imię i nazwisko, "George W. Bush") . Takie adnotacje mogą być przechowywane w tabeli bazy danych.

Chociaż EAV nie ma bezpośredniego połączenia z parami AV, wydaje się, że Stead i Hammond jako pierwsi wpadli na pomysł ich wykorzystania do trwałego przechowywania dowolnie złożonych danych. Pierwszymi systemami dokumentacji medycznej, w których zastosowano EAV były: elektroniczna dokumentacja medyczna Regenstrief (wysiłek kierowany przez Clementa MacDonalda), system TMR (The Medical Record) Williama Steada i Eda Hammonda oraz HELP Clinical Data Repository (CDR) stworzone przez grupę Homera Warnera przy Szpital LDS, Salt Lake City, Utah. (System Regenstrief faktycznie wykorzystywał projekt Pacjent-Atrybut-Znacznik-Wartość: użycie sygnatury czasowej wspierało wyszukiwanie wartości dla danego pacjenta/atrybutu w porządku chronologicznym.) Wszystkie te systemy, opracowane w latach 70., zostały wydane przed systemami komercyjnymi na podstawie EF Codd „s relacyjnej bazy danych modelu były dostępne, choć pomoc była znacznie później przeniesiony do relacyjnej architektury i skomercjalizowane przez korporację 3M. (Zauważ, że chociaż przełomowy artykuł Codda został opublikowany w 1970 r., jego mocno matematyczny ton spowodował niefortunny efekt zmniejszenia jego dostępności wśród typów niezwiązanych z informatyką, a w konsekwencji opóźnił akceptację modelu w kręgach IT i dostawców oprogramowania. Wartość późniejszego wkład Christophera J. Date , kolegi Codda w IBM, w przetłumaczeniu tych pomysłów na przystępny język, wraz z prostymi przykładami ilustrującymi ich siłę, jest nie do przecenienia.)

Grupa z Columbia-Presbyterian Medical Center jako pierwsza użyła relacyjnego silnika bazy danych jako podstawy systemu EAV.

System zarządzania danymi z badań klinicznych TrialDB o otwartym kodzie źródłowym autorstwa Nadkarni et al. jako pierwszy użył wielu tabel EAV, po jednej dla każdego typu danych DBMS .

Struktura EAV/CR, zaprojektowana głównie przez Luisa Marenco i Prakasha Nadkarniego, nałożyła zasady orientacji obiektowej na EAV; zbudowano go na podejściu Toma Ślęzaka do tablicy obiektów (opisanym wcześniej w sekcji "Entity"). SenseLab , publicznie dostępna baza danych neuronaukowych, jest zbudowana w oparciu o platformę EAV/CR.

Użyj w bazach danych

Termin „baza danych EAV” odnosi się do projektu bazy danych, w którym znaczna część danych jest modelowana jako EAV. Jednak nawet w bazie danych opisanej jako „oparta na EAV” niektóre tabele w systemie są tradycyjnymi tabelami relacyjnymi.

Jak wspomniano powyżej, modelowanie EAV ma sens w przypadku kategorii danych, takich jak wyniki kliniczne, w których atrybuty są liczne i rzadkie. Jeśli te warunki nie są spełnione, preferowane jest standardowe modelowanie relacyjne (tj. jedna kolumna na atrybut); korzystanie z EAV nie oznacza porzucenia zdrowego rozsądku lub zasad dobrego projektowania relacji. W systemach dokumentacji klinicznej podschematy dotyczące danych demograficznych pacjentów i rozliczeń są zazwyczaj modelowane w sposób konwencjonalny. (Chociaż większość schematów baz danych dostawców jest zastrzeżona, VistA , system używany w całym systemie medycznym Departamentu Spraw Weteranów Stanów Zjednoczonych (VA), znany jako Veterans Health Administration (VHA), jest oprogramowaniem typu open source, a jego schemat jest łatwy do sprawdzenia, chociaż wykorzystuje silnik bazy danych MUMPS , a nie relacyjną bazę danych).

Jak omówiono pokrótce, baza danych EAV jest zasadniczo niemożliwa do utrzymania bez licznych tabel pomocniczych, które zawierają pomocnicze metadane . Tabele metadanych, które zazwyczaj przewyższają liczbę tabel EAV o współczynnik co najmniej trzech lub więcej, są zazwyczaj standardowymi tabelami relacyjnymi. Przykładem tabeli metadanych jest wspomniana powyżej tabela Definicje Atrybutów.

EAV/CR: reprezentacja podstruktury za pomocą klas i relacji

W prostym projekcie EAV wartości atrybutu są prostymi lub prymitywnymi typami danych, jeśli chodzi o silnik bazy danych. Jednak w systemach EAV służących do reprezentacji bardzo zróżnicowanych danych istnieje możliwość, że dany obiekt (instancja klasy) może mieć podstrukturę: to znaczy niektóre jego atrybuty mogą reprezentować inne rodzaje obiektów, które z kolei mogą mieć podstrukturę, aby dowolny poziom złożoności. Na przykład samochód ma silnik, skrzynię biegów itp., a silnik ma takie elementy, jak cylindry. (Dozwolona podstruktura dla danej klasy jest zdefiniowana w metadanych atrybutu systemu, co omówiono później. Zatem na przykład atrybut „pamięć o dostępie swobodnym” może dotyczyć klasy „komputer”, ale nie klasy „silnik” .)

Aby przedstawić strukturę podrzędną, stosuje się specjalną tabelę EAV, w której kolumna wartości zawiera odniesienia do innych podmiotów w systemie (tj. wartości kluczy obcych w tabeli obiektów). Uzyskanie wszystkich informacji o danym obiekcie wymaga rekurencyjnego przechodzenia metadanych, po którym następuje rekurencyjne przechodzenie danych, które zatrzymuje się, gdy każdy pobrany atrybut jest prosty (atomowy). Przechodzenie rekurencyjne jest konieczne, niezależnie od tego, czy szczegóły poszczególnych klas są reprezentowane w formie konwencjonalnej lub EAV; takie przechodzenie jest wykonywane na przykład w standardowych systemach obiektowo-relacyjnych. W praktyce liczba poziomów rekurencji jest stosunkowo niewielka dla większości klas, więc kary za wydajność wynikające z rekurencji są niewielkie, zwłaszcza w przypadku indeksowania identyfikatorów obiektów.

EAV/CR (EAV z klasami i relacjami) odnosi się do struktury obsługującej złożoną podstrukturę. Jego nazwa jest nieco myląca: podczas gdy był wynikiem prac nad systemami EAV, w praktyce wiele lub nawet większość klas w takim systemie może być reprezentowana w standardowej formie relacyjnej, w zależności od tego, czy atrybuty są rzadkie, czy gęste . EAV/CR naprawdę charakteryzuje się bardzo szczegółowymi metadanymi, które są wystarczająco bogate, aby obsługiwać automatyczne generowanie interfejsów przeglądania do poszczególnych klas bez konieczności pisania kodu interfejsu użytkownika klasa po klasie. Podstawą takich interfejsów przeglądarki jest to, że możliwe jest wygenerowanie partii dynamicznych zapytań SQL, które są niezależne od klasy obiektu, najpierw sprawdzając jego metadane i wykorzystując informacje o metadanych do wygenerowania sekwencji zapytań względem tabel danych, oraz niektóre z tych zapytań mogą być dowolnie rekurencyjne. To podejście sprawdza się dobrze w przypadku zapytań typu obiekt-w-czasie, tak jak w interfejsach przeglądania opartych na sieci Web, gdzie kliknięcie nazwy obiektu powoduje wyświetlenie wszystkich szczegółów obiektu na osobnej stronie: metadane powiązane z klasą obiektu również ułatwiają przedstawienie szczegółów obiektu, ponieważ zawiera podpisy poszczególnych atrybutów, kolejność ich prezentacji oraz sposób ich grupowania.

Jednym z podejść do EAV/CR jest umożliwienie kolumnom przechowywania struktur JSON , które w ten sposób zapewniają niezbędną strukturę klas. Na przykład PostgreSQL od wersji 9.4 oferuje obsługę kolumn binarnych JSON (JSONB), umożliwiając odpytywanie, indeksowanie i łączenie atrybutów JSON.

Metadane

Według słów prof. dr. Daniela Masysa (dawniej przewodniczący Wydziału Informatyki Medycznej Uniwersytetu Vanderbilt), wyzwania związane z pracą z EAV wynikają z faktu, że w bazie danych EAV „schemat fizyczny” (sposób przechowywania danych) jest radykalnie odmienny od „schematu logicznego” – sposób, w jaki użytkownicy i wiele aplikacji, takich jak pakiety statystyk, traktuje go, tj. jako konwencjonalne wiersze i kolumny dla poszczególnych klas. (Ponieważ tabela EAV koncepcyjnie miesza jabłka, pomarańcze, grejpfruty i siekane suey, jeśli chcesz przeprowadzić jakąkolwiek analizę danych przy użyciu standardowego oprogramowania z półki, w większości przypadków musisz przekonwertować ich podzbiory do postaci kolumnowej. proces wykonywania tego, zwany obracaniem , jest na tyle ważny, że należy go omówić osobno).

Metadane pomagają wykonać sztuczkę, która pozwala użytkownikom na interakcję z systemem pod względem schematu logicznego, a nie fizycznego: oprogramowanie nieustannie sprawdza metadane w celu różnych operacji, takich jak prezentacja danych, interaktywna walidacja, zbiorcza ekstrakcja danych i zapytania ad hoc . Metadane można faktycznie wykorzystać do dostosowania zachowania systemu.

Systemy EAV rezygnują z prostoty fizycznej i logicznej struktury danych za złożoność ich metadanych, która między innymi odgrywa rolę, jaką w standardowych projektach baz danych odgrywają ograniczenia bazy danych i integralność referencyjna . Taki kompromis jest generalnie opłacalny, ponieważ w typowym mieszanym schemacie systemów produkcyjnych dane w konwencjonalnych tabelach relacyjnych mogą również korzystać z takich funkcji, jak automatyczne generowanie interfejsów. Struktura metadanych jest na tyle złożona, że zawiera własny podschemat w bazie danych: różne klucze obce w tabelach danych odnoszą się do tabel w ramach tego podschematu. Ten podschemat jest standardowo-relacyjny, z cechami takimi jak ograniczenia i integralność referencyjna, które są wykorzystywane do rękojeści.

Poprawność zawartości metadanych, z punktu widzenia zamierzonego zachowania systemu, ma kluczowe znaczenie, a zadanie zapewnienia poprawności oznacza, że podczas tworzenia systemu EAV należy włożyć znaczne wysiłki projektowe w budowanie interfejsów użytkownika do edycji metadanych, z których mogą korzystać ludzie w zespole, który zna problematyczną dziedzinę (np. medycyna kliniczna), ale niekoniecznie jest programistą. (Historycznie jednym z głównych powodów, dla których prerelacyjny system TMR nie został zaadoptowany w witrynach innych niż jego instytucja macierzysta, było to, że wszystkie metadane były przechowywane w jednym pliku o nieintuicyjnej strukturze. Dostosowywanie zachowania systemu poprzez zmianę zawartości tego pliku, bez powodowania awarii systemu, było tak delikatnym zadaniem, że autorzy systemu zaufali tylko sobie, że to zrobią.)

Tam, gdzie system EAV jest wdrażany przez RDF , do wyrażenia takich metadanych można wygodnie użyć języka schematu RDF . Ta informacja o schemacie może być następnie wykorzystana przez silnik bazy danych EAV do dynamicznej reorganizacji wewnętrznej struktury tabeli w celu uzyskania najlepszej wydajności.

Kilka końcowych zastrzeżeń dotyczących metadanych:

Ponieważ logika biznesowa znajduje się w metadanych, a nie jest jawna w schemacie bazy danych (tj. usunięty jeden poziom w porównaniu z tradycyjnie zaprojektowanymi systemami), dla osoby niezaznajomionej z systemem jest ona mniej oczywista. Narzędzia do przeglądania metadanych i raportowania metadanych są zatem ważne dla zapewnienia łatwości konserwacji systemu EAV. W typowym scenariuszu, w którym metadane są implementowane jako relacyjny podschemat, narzędzia te są niczym innym jak aplikacjami zbudowanymi przy użyciu gotowych narzędzi do raportowania lub zapytań, które działają na tabelach metadanych.
Niezorientowanemu użytkownikowi łatwo jest uszkodzić (tj. wprowadzić niespójności i błędy) metadane. W związku z tym dostęp do metadanych musi być ograniczony, a ścieżka audytu dostępu i zmian musi być wprowadzona w celu radzenia sobie z sytuacjami, w których wiele osób ma dostęp do metadanych. Korzystanie z RDBMS dla metadanych uprości proces utrzymywania spójności podczas tworzenia i edycji metadanych dzięki wykorzystaniu funkcji RDBMS, takich jak obsługa transakcji. Ponadto, jeśli metadane są częścią tej samej bazy danych, co same dane, zapewnia to tworzenie kopii zapasowej co najmniej tak często, jak same dane, dzięki czemu można je odzyskać do określonego momentu.
Jakość adnotacji i dokumentacji w metadanych (tj. opis/tekst objaśniający w kolumnach opisowych podschematu metadanych) musi być znacznie wyższa, aby ułatwić zrozumienie przez różnych członków zespołu programistów. Zapewnienie jakości metadanych (i utrzymywanie ich aktualności w miarę rozwoju systemu) ma bardzo wysoki priorytet w długoterminowym zarządzaniu i utrzymywaniu każdego projektu wykorzystującego komponent EAV. Słabo udokumentowane lub nieaktualne metadane mogą zagrozić długoterminowej żywotności systemu.

Informacje przechwycone w metadanych

Metadane atrybutów

Metadane walidacji obejmują typ danych, zakres dopuszczalnych wartości lub członkostwo w zbiorze wartości, dopasowanie wyrażenia regularnego, wartość domyślną oraz dopuszczalną wartość null. W systemach EAV reprezentujących klasy z podstrukturą metadane walidacyjne będą również rejestrować, do jakiej klasy, jeśli w ogóle, należy dany atrybut.
Metadane prezentacji : sposób wyświetlania atrybutu użytkownikowi (np. jako pole tekstowe lub obraz o określonych wymiarach, lista rozwijana lub zestaw przycisków radiowych). Gdy obiekt złożony składa się z wielu atrybutów, tak jak w projekcie EAV/CR, istnieją dodatkowe metadane dotyczące kolejności, w jakiej atrybuty powinny być prezentowane oraz jak te atrybuty powinny być opcjonalnie pogrupowane (w opisowych nagłówkach).
W przypadku atrybutów będących parametrami laboratoryjnymi rejestruje się zakresy wartości prawidłowych , które mogą różnić się w zależności od wieku, płci, stanu fizjologicznego i metody badania.
Metadane grupowania : atrybuty są zwykle przedstawiane jako część grupy wyższego rzędu, np. formularz specyficzny dla danej specjalności. Metadane grupowania zawierają informacje, takie jak kolejność, w jakiej prezentowane są atrybuty. Niektóre metadane prezentacji, takie jak czcionki/kolory i liczba atrybutów wyświetlanych w wierszu, dotyczą całej grupy.

Zaawansowane metadane walidacji

Metadane zależności : w wielu interfejsach użytkownika wymagane jest wprowadzenie określonych wartości do określonych pól/atrybutów, aby wyłączyć/ukryć niektóre inne pola lub włączyć/pokazać inne pola. (Na przykład, jeśli użytkownik wybierze odpowiedź „Nie” na pytanie logiczne „Czy pacjent ma cukrzycę?”, kolejne pytania dotyczące czasu trwania cukrzycy, leków na cukrzycę itp. muszą być wyłączone). ogólna struktura obejmuje przechowywanie zależności między atrybutami kontrolującymi i kontrolowanymi atrybutami.
Obliczenia i złożona walidacja : Podobnie jak w arkuszu kalkulacyjnym, wartość niektórych atrybutów może być obliczona i wyświetlona na podstawie wartości wprowadzonych do pól, które zostały przedstawione wcześniej w kolejności. (Na przykład powierzchnia ciała jest funkcją wysokości i szerokości). Podobnie mogą istnieć „ograniczenia”, które muszą być prawdziwe, aby dane były prawidłowe: na przykład w różnicowej liczbie białych krwinek suma zliczeń poszczególnych typów białych krwinek musi zawsze wynosić 100, ponieważ poszczególne zliczenia reprezentują procentach. Formuły obliczane i złożona walidacja są zazwyczaj realizowane przez przechowywanie wyrażeń w metadanych, które są zastępowane w makrach wartościami wprowadzonymi przez użytkownika i które mogą zostać ocenione. W przeglądarkach internetowych zarówno JavaScript , jak i VBScript mają funkcję Eval(), którą można wykorzystać do tego celu.

Walidacja, prezentacja i grupowanie metadanych umożliwiają tworzenie frameworków kodu, które wspierają automatyczne generowanie interfejsu użytkownika zarówno do przeglądania danych, jak i interaktywnej edycji. W systemie produkcyjnym, który jest dostarczany przez Internet, zadanie sprawdzania poprawności danych EAV jest zasadniczo przenoszone z warstwy zaplecza/bazy danych (która jest bezsilna w odniesieniu do tego zadania) do warstwy środkowej/serwera WWW. Podczas gdy walidacja zaplecza jest zawsze idealna, ponieważ nie można jej odwrócić, próbując bezpośrednio wprowadzić dane do tabeli, walidacja warstwy środkowej za pomocą ogólnej struktury jest całkiem wykonalna, chociaż znaczna część wysiłku związanego z projektowaniem oprogramowania musi najpierw zostać włożona w zbudowanie struktury . Dostępność struktur open source , które można badać i modyfikować pod kątem indywidualnych potrzeb, może znacznie pomóc w uniknięciu ponownego odkrywania koła.

Scenariusze użytkowania

(Pierwsza część tej sekcji jest A streszczanie wyrobu odniesienia Dinu / Nadkarni centralnej, do którego czytnika skierowana jest na więcej szczegółów).

Modelowanie EAV, pod alternatywnymi terminami „ modelowanie danych ogólnych ” lub „schemat otwarty”, od dawna jest standardowym narzędziem dla zaawansowanych modelarzy danych. Jak każda zaawansowana technika, może być obosieczna i powinna być używana rozważnie.

Ponadto zastosowanie EAV nie wyklucza zastosowania tradycyjnych podejść do modelowania relacyjnych baz danych w ramach tego samego schematu bazy danych. W EMR, które opierają się na RDBMS, takich jak Cerner , które wykorzystują podejście EAV do podschematu danych klinicznych, zdecydowana większość tabel w schemacie jest w rzeczywistości modelowana tradycyjnie, a atrybuty są reprezentowane jako pojedyncze kolumny, a nie jako wiersze.

Modelowanie podschematu metadanych systemu EAV w rzeczywistości bardzo dobrze pasuje do tradycyjnego modelowania ze względu na wzajemne powiązania między różnymi komponentami metadanych. Na przykład w systemie TrialDB liczba tabel metadanych w schemacie przewyższa liczbę tabel danych o około dziesięć do jednego. Ponieważ poprawność i spójność metadanych ma kluczowe znaczenie dla prawidłowego działania systemu EAV, projektant systemu chce w pełni wykorzystać wszystkie funkcje zapewniane przez RDBMS, takie jak integralność referencyjna i ograniczenia programowalne, zamiast konieczności ponownego wymyślania systemu RDBMS -koło silnika. W związku z tym liczne tabele metadanych, które obsługują projekty EAV, mają zazwyczaj postać relacyjną trzeciej normalnej.

Komercyjne systemy elektronicznej dokumentacji medycznej (EHR) wykorzystują modelowanie wierszy dla klas danych, takich jak diagnozy, przeprowadzane zabiegi chirurgiczne i wyniki badań laboratoryjnych, które są podzielone na osobne tabele. W każdej tabeli „jednostka” jest połączeniem identyfikatora pacjenta i daty/godziny postawienia diagnozy (lub wykonanej operacji lub testu laboratoryjnego); atrybut jest kluczem obcym do specjalnie wyznaczonej tabeli przeglądowej, która zawiera kontrolowane słownictwo - np. ICD-10 dla diagnoz, Current Procedural Terminology dla procedur chirurgicznych, z zestawem atrybutów wartości. (Np. w przypadku wyników badań laboratoryjnych można zapisać zmierzoną wartość, czy jest ona w normalnym, niskim lub wysokim zakresie, identyfikator osoby odpowiedzialnej za wykonanie badania, datę/godzinę wykonania badania itp. Jak wspomniano wcześniej, nie jest to pełne podejście EAV, ponieważ domena atrybutów dla danej tabeli jest ograniczona, tak jak domena identyfikatorów produktów w tabeli Sprzedaż w supermarkecie byłaby ograniczona do domeny Produkty w Tabela produktów.

Jednak w celu przechwytywania danych dotyczących parametrów, które nie zawsze są zdefiniowane w standardowych słownikach, EHR zapewniają również „czysty” mechanizm EAV, w którym specjalnie wyznaczeni użytkownicy zaawansowani mogą definiować nowe atrybuty, ich typ danych, maksymalne i minimalne dopuszczalne wartości (lub dopuszczalny zestaw wartości/kodów), a następnie zezwól innym na przechwytywanie danych na podstawie tych atrybutów. W Epic (TM) EHR mechanizm ten jest określany jako „Arkusze blokowe” i jest powszechnie używany do przechwytywania danych z obserwacji pielęgniarek hospitalizowanych.

Modelowanie rzadkich atrybutów

Typowym przypadkiem zastosowania modelu EAV są bardzo rzadkie, niejednorodne atrybuty, takie jak parametry kliniczne w elektronicznej dokumentacji medycznej (EMR), jak wspomniano powyżej. Jednak nawet w tym przypadku trafne jest stwierdzenie, że zasada modelowania EAV jest stosowana do podschematu bazy danych, a nie do całej jej zawartości. (Na przykład dane demograficzne pacjentów są najbardziej naturalnie modelowane w tradycyjnej strukturze relacyjnej z jedną kolumną na atrybut).

W związku z tym argumenty dotyczące EAV i projektowania „relacyjnego” odzwierciedlają niepełne zrozumienie problemu: projekt EAV powinien być stosowany tylko dla tego podschematu bazy danych, w którym należy modelować rzadkie atrybuty: nawet tutaj muszą być one obsługiwane przez trzecią tabelę metadanych postaci normalnej . Istnieje stosunkowo niewiele problemów związanych z projektowaniem baz danych, w których napotykane są rzadkie atrybuty: dlatego okoliczności, w których projekt EAV ma zastosowanie, są stosunkowo rzadkie. Nawet w przypadku ich napotkania zestaw tabel EAV nie jest jedynym sposobem na rozwiązanie problemu rzadkich danych: rozwiązanie oparte na XML (omówione poniżej) ma zastosowanie, gdy maksymalna liczba atrybutów na jednostkę jest stosunkowo niewielka, a całkowita ilość rzadkich dane są również skromne. Przykładem takiej sytuacji są problemy z uchwyceniem zmiennych atrybutów dla różnych typów produktów.

Rzadkie atrybuty mogą również występować w sytuacjach e-commerce, w których organizacja kupuje lub sprzedaje ogromny i bardzo zróżnicowany zestaw towarów, przy czym szczegóły dotyczące poszczególnych kategorii towarów są bardzo zmienne. Oprogramowanie Magento E-commerce wykorzystuje podejście EAV do rozwiązania tego problemu.

Modelowanie wielu klas z bardzo małą liczbą wystąpień na klasę: wysoce dynamiczne schematy

Innym zastosowaniem EAV jest modelowanie klas i atrybutów, które choć nie są rzadkie, są dynamiczne, ale gdzie liczba wierszy danych na klasę będzie stosunkowo niewielka – maksymalnie kilkaset wierszy, ale zwykle kilkadziesiąt – i system Programista jest również zobowiązany do zapewnienia interfejsu użytkownika końcowego opartego na sieci Web w bardzo krótkim czasie. „Dynamiczny” oznacza, że nowe klasy i atrybuty muszą być stale definiowane i zmieniane w celu reprezentowania ewoluującego modelu danych. Scenariusz ten może wystąpić w szybko rozwijających się dziedzinach nauki, a także w rozwoju ontologii, zwłaszcza w fazie prototypowania i iteracyjnego udoskonalania.

Podczas gdy tworzenie nowych tabel i kolumn reprezentujących nową kategorię danych nie jest szczególnie pracochłonne, programowanie interfejsów opartych na sieci Web, które obsługują przeglądanie lub podstawową edycję z walidacją opartą na typie i zakresie, jest takie. W takim przypadku łatwiejszym w utrzymaniu rozwiązaniem długoterminowym jest stworzenie struktury, w której definicje klas i atrybutów są przechowywane w metadanych, a oprogramowanie dynamicznie generuje podstawowy interfejs użytkownika na podstawie tych metadanych.

Wspomniana wcześniej struktura EAV/CR została stworzona w celu rozwiązania tej właśnie sytuacji. Zauważ, że model danych EAV nie jest tutaj niezbędny, ale projektant systemu może uznać go za akceptowalną alternatywę dla, powiedzmy, sześćdziesięciu lub więcej tabel zawierających w sumie nie więcej niż dwa tysiące wierszy. W tym przypadku, ponieważ liczba wierszy na klasę jest tak mała, względy dotyczące wydajności są mniej ważne; dzięki standardowemu indeksowaniu według identyfikatora klasy/identyfikatora atrybutu, optymalizatorzy DBMS mogą łatwo buforować dane dla małej klasy w pamięci podczas uruchamiania zapytania dotyczącego tej klasy lub atrybutu.

W scenariuszu atrybutów dynamicznych warto zauważyć, że Resource Description Framework (RDF) jest wykorzystywany jako podstawa pracy ontologicznej związanej z siecią semantyczną. RDF, który ma być ogólną metodą przedstawiania informacji, jest formą EAV: trójka RDF zawiera obiekt, właściwość i wartość.

Pod koniec książki Jon Bentley „Pisanie skutecznych programów”, autor ostrzega, że czyni kod bardziej wydajne zazwyczaj robi to również trudniejsze do zrozumienia i utrzymania, a więc nie ma pośpiechu w i kodu Tweak chyba jeden najpierw ustaliła, że tam jest problem z wydajnością, a środki, takie jak profilowanie kodu, wskazały dokładną lokalizację wąskiego gardła. Gdy to zrobisz, modyfikujesz tylko określony kod, który musi działać szybciej. Podobne względy dotyczą modelowania EAV: stosuje się je tylko do podsystemu, w którym tradycyjne modelowanie relacyjne jest znane a priori jako niewygodne (jak w dziedzinie danych klinicznych) lub okazuje się, że podczas ewolucji systemu stwarza poważne wyzwania konserwacyjne. Database Guru (a obecnie wiceprezes Core Technologies w Oracle Corporation) Tom Kyte, na przykład, słusznie wskazuje na wady stosowania EAV w tradycyjnych scenariuszach biznesowych i zwraca uwagę, że sama „elastyczność” nie jest wystarczającym kryterium EAV. (Jednak twierdzi, że EAV należy unikać we wszystkich okolicznościach, mimo że sam oddział Oracle Health Sciences wykorzystuje EAV do modelowania atrybutów danych klinicznych w swoich komercyjnych systemach ClinTrial i Oracle Clinical.)

Praca z danymi EAV

Piętą achillesową EAV jest trudność w pracy z dużymi ilościami danych EAV. Często konieczna jest przejściowa lub trwała konwersja między kolumnowymi i rzędowymi lub modelowanymi EAV reprezentacjami tych samych danych; może to być zarówno podatne na błędy, jeśli jest wykonywane ręcznie, jak i obciążające procesor. Struktury generyczne, które wykorzystują metadane atrybutów i grupowania atrybutów, odnoszą się do pierwszego, ale nie do drugiego ograniczenia; ich stosowanie jest mniej lub bardziej obowiązkowe w przypadku schematów mieszanych zawierających mieszankę danych konwencjonalno-relacyjnych i EAV, gdzie iloraz błędu może być bardzo istotny.

Operacja konwersji nazywana jest obracaniem . Obracanie nie jest wymagane tylko w przypadku danych EAV, ale także w przypadku dowolnych formularzy lub danych modelowanych wierszowo. (Na przykład implementacje algorytmu Apriori do analizy powiązań , szeroko stosowanego do przetwarzania danych o sprzedaży w supermarketach w celu zidentyfikowania innych produktów, które nabywcy danego produktu prawdopodobnie kupią, w pierwszym kroku przestawiają dane modelowane wierszowo). Wiele silników baz danych posiadają własne rozszerzenia SQL ułatwiające przestawianie, a pakiety takie jak Microsoft Excel również je obsługują. Okoliczności, w których obrót jest konieczny, omówiono poniżej.

Przeglądanie niewielkich ilości danych dla pojedynczej encji, po którym następuje opcjonalnie edycja danych na podstawie zależności między atrybutami. Operację tę ułatwia buforowanie niewielkich ilości wymaganych metadanych pomocniczych. Niektóre programy, takie jak TrialDB, uzyskują dostęp do metadanych w celu generowania półstatycznych stron sieci Web, które zawierają osadzony kod programistyczny, a także struktury danych zawierające metadane.
Ekstrakcja zbiorcza przekształca duże (ale przewidywalne) ilości danych (np. pełne dane z badania klinicznego) w zestaw tabel relacyjnych. Chociaż intensywnie wykorzystuje procesor, zadanie to jest rzadkie i nie musi być wykonywane w czasie rzeczywistym; tzn. użytkownik może czekać na zakończenie procesu wsadowego. Nie można przecenić znaczenia masowej ekstrakcji, zwłaszcza gdy dane mają być przetwarzane lub analizowane za pomocą standardowych narzędzi innych firm, które są całkowicie nieświadome struktury EAV. W tym przypadku nie jest wskazane, aby próbować ponownie wymyślać całe zestawy kół za pomocą ogólnej struktury, a najlepiej jest po prostu zbiorczo wyodrębnić dane EAV do tabel relacyjnych, a następnie pracować z nimi za pomocą standardowych narzędzi.
Interfejsy zapytań ad hoc do danych modelowanych wierszami lub modelami EAV, w przypadku zapytań z perspektywy poszczególnych atrybutów (np. „odzyskaj wszystkich pacjentów z chorobą wątroby, z objawami niewydolności wątroby i bez historii nadużywania alkoholu”) muszą zazwyczaj wyświetla wyniki zapytania z poszczególnymi atrybutami jako osobne kolumny. W przypadku większości scenariuszy baz danych EAV wydajność zapytań ad hoc musi być tolerowana, ale odpowiedzi w drugiej części nie są konieczne, ponieważ zapytania mają zwykle charakter eksploracyjny.

Podział relacyjny

Jednak struktura modelu danych EAV jest idealnym kandydatem do podziału relacyjnego, patrz algebra relacyjna . Przy dobrej strategii indeksowania możliwe jest uzyskanie czasu odpowiedzi w czasie krótszym niż kilkaset milisekund w tabeli EAV o miliardach wierszy. Microsoft SQL Server MVP Peter Larsson udowodnił to na laptopie i udostępnił rozwiązanie.

Optymalizacja wydajności obrotu

Jedną z możliwych optymalizacji jest użycie oddzielnego „ magazynu ” lub schematu z możliwością zapytań, którego zawartość jest odświeżana w trybie wsadowym ze schematu produkcyjnego (transakcji). Zobacz hurtownie danych . Tabele w magazynie są mocno indeksowane i optymalizowane za pomocą denormalizacji , która łączy wiele tabel w jedną, aby zminimalizować spadek wydajności związany z łączeniem tabel.
Niektóre dane EAV w hurtowni mogą być konwertowane na standardowe tabele przy użyciu „ widoków zmaterializowanych ” (patrz hurtownia danych ), ale jest to zazwyczaj ostateczność, z której należy korzystać ostrożnie, ponieważ liczba tego rodzaju widoków ma tendencję do nieliniowego wzrostu z liczbą atrybutów w systemie.
Struktury danych w pamięci : można używać tabel mieszających i dwuwymiarowych tablic w pamięci w połączeniu z metadanymi grupowania atrybutów do danych przestawnych, po jednej grupie na raz. Te dane są zapisywane na dysku jako plik rozdzielany płaskimi, z wewnętrznymi nazwami każdego atrybutu w pierwszym wierszu: ten format można łatwo zaimportować zbiorczo do tabeli relacyjnej. Ta technika "w pamięci" znacznie przewyższa alternatywne podejścia, utrzymując zapytania w tabelach EAV tak proste, jak to możliwe i minimalizując liczbę operacji we/wy. Każda instrukcja pobiera dużą ilość danych, a tablice mieszające pomagają przeprowadzić operację przestawiania, która polega na umieszczeniu wartości dla danej instancji atrybutu w odpowiednim wierszu i kolumnie. Pamięć o dostępie swobodnym (RAM) jest wystarczająco obfita i przystępna cenowo w nowoczesnym sprzęcie, aby pełny zestaw danych dla pojedynczej grupy atrybutów w nawet dużych zestawach danych zwykle mieścił się całkowicie w pamięci, chociaż algorytm można ulepszyć, pracując na wycinkach danych jeśli tak nie jest.

Oczywiście, bez względu na to, jakie podejście zastosujesz, odpytywanie EAV nie będzie tak szybkie, jak odpytywanie standardowych danych relacyjnych modelowanych kolumnowo dla niektórych typów zapytań, w podobny sposób, w jaki dostęp do elementów w macierzach rzadkich nie jest tak szybki, jak w przypadku innych -sparse macierze, jeśli te ostatnie mieszczą się całkowicie w pamięci głównej. (Macierze rzadkie, reprezentowane za pomocą struktur, takich jak połączone listy, wymagają przechodzenia przez listę w celu uzyskania dostępu do elementu na danej pozycji XY, podczas gdy dostęp do elementów w macierzach reprezentowanych jako tablice 2-D można uzyskać za pomocą szybkich operacji rejestrów procesora.) Jeśli jednak , prawidłowo wybrałeś podejście EAV do problemu, który próbowałeś rozwiązać, jest to cena, którą płacisz; pod tym względem modelowanie EAV jest przykładem kompromisu między przestrzenią (i utrzymaniem schematu) a czasem procesora.

Alternatywy

EAV a uniwersalny model danych

Pierwotnie postulowany przez Maiera, Ullmana i Vardiego „Universal Data Model” (UDM) ma na celu uproszczenie zapytań o złożony schemat relacyjny przez naiwnych użytkowników, tworząc iluzję, że wszystko jest przechowywane w jednej gigantycznej „uniwersalnej tabeli”. Odbywa się to poprzez wykorzystanie relacji między tabelami, dzięki czemu użytkownik nie musi martwić się o to, która tabela zawiera jaki atrybut. CJ Date zwrócił jednak uwagę, że w sytuacji, gdy jedna tabela jest wielokrotnie powiązana z inną (jak w genealogicznych bazach danych, gdzie ojciec i matka jednostki są również osobami fizycznymi, lub w niektórych biznesowych bazach danych, w których wszystkie adresy są przechowywane centralnie, a organizacja może mają różne adresy biura i adresy wysyłkowe), w schemacie bazy danych nie ma wystarczających metadanych, aby określić jednoznaczne sprzężenia. Gdy UDM został skomercjalizowany, tak jak w SAP BusinessObjects , to ograniczenie można obejść poprzez utworzenie „Wszechświatów”, które są widokami relacyjnymi z predefiniowanymi łączeniami między zestawami tabel: programista „Wszechświata” rozróżnia niejednoznaczne sprzężenia poprzez uwzględnienie tabela w widoku wiele razy przy użyciu różnych aliasów.

Poza sposobem, w jaki dane są modelowane w sposób jawny (UDM po prostu używa relacyjnych widoków do interweniowania między użytkownikiem a schematem bazy danych), EAV różni się od Universal Data Models tym, że ma również zastosowanie do systemów transakcyjnych, nie tylko zorientowanych na zapytania (tylko do odczytu ) systemy jak w UDM. Ponadto, gdy są używane jako podstawa dla systemów zapytań o dane kliniczne, implementacje EAV niekoniecznie chronią użytkownika przed koniecznością określenia klasy obiektu zainteresowania. Na przykład w bazie danych klinicznych i2b2 opartej na EAV, gdy użytkownik wyszukuje termin, ma możliwość określenia kategorii danych, którymi użytkownik jest zainteresowany. Na przykład wyrażenie „ lit ” może odnosić się do lek (stosowany w leczeniu choroby afektywnej dwubiegunowej ) lub test laboratoryjny na poziom litu we krwi pacjenta. (Poziom litu we krwi musi być uważnie monitorowany: zbyt duża ilość leku powoduje poważne skutki uboczne, a zbyt mała jest nieskuteczna).

XML i JSON

Implementacja Open Schema może używać kolumny XML w tabeli do przechwytywania zmiennych/informacji rozrzedzonych. Podobne pomysły można zastosować do baz danych, które obsługują kolumny o wartościach JSON : rzadkie, hierarchiczne dane mogą być reprezentowane jako JSON. Jeśli baza danych obsługuje JSON, taką jak PostgreSQL i (częściowo) SQL Server 2016 i nowsze, można odpytywać, indeksować i łączyć atrybuty. Może to zapewnić ponad 1000-krotną poprawę wydajności w porównaniu z naiwnymi implementacjami EAV, ale niekoniecznie zwiększa niezawodność całej aplikacji bazodanowej.

Zauważ, że istnieją dwa sposoby przechowywania danych XML lub JSON: jednym sposobem jest przechowywanie ich jako zwykłego ciągu, nieprzezroczystego dla serwera bazy danych; innym sposobem jest użycie serwera bazy danych, który może „zaglądać” w strukturę. Istnieją oczywiście poważne wady przechowywania nieprzezroczystych łańcuchów: nie można o nie zapytać bezpośrednio, nie można utworzyć indeksu na podstawie ich zawartości i niemożliwe jest wykonanie złączeń na podstawie zawartości.

Budowanie aplikacji, która ma zarządzać danymi, staje się niezwykle skomplikowane w przypadku korzystania z modeli EAV, ze względu na rozległość infrastruktury, którą trzeba opracować w zakresie tabel metadanych i kodu aplikacji-framework. Używanie XML rozwiązuje problem walidacji danych na serwerze (co musi być wykonane przez kod warstwy pośredniej i kod oparty na przeglądarce w frameworkach opartych na EAV), ale ma następujące wady:

To jest programistyczne. Schematy XML są niezwykle trudne do napisania ręcznie, zalecanym podejściem jest tworzenie ich poprzez definiowanie tabel relacyjnych, generowanie kodu schematu XML, a następnie usuwanie tych tabel. Jest to problematyczne w wielu operacjach produkcyjnych obejmujących dynamiczne schematy, gdzie nowe atrybuty muszą być zdefiniowane przez zaawansowanych użytkowników, którzy rozumieją określoną dziedzinę aplikacji (np. zarządzanie zapasami lub biomedycynę), ale niekoniecznie są programistami. Natomiast w systemach produkcyjnych, które używają EAV, tacy użytkownicy definiują nowe atrybuty (oraz powiązane z nimi kontrole typu danych i walidacji) za pomocą aplikacji GUI. Ponieważ metadane związane z walidacją muszą być przechowywane w wielu relacyjnych tabelach w znormalizowanym projekcie, aplikacja GUI, która łączy te tabele ze sobą i wymusza odpowiednie kontrole spójności metadanych, jest jedynym praktycznym sposobem umożliwienia wprowadzania informacji o atrybutach, nawet dla zaawansowani programiści - nawet jeśli końcowy wynik używa XML lub JSON zamiast oddzielnych tabel relacyjnych.
Diagnostyka oparta na serwerze, która skutkuje rozwiązaniem XML/JSON w przypadku próby wstawienia nieprawidłowych danych (np. sprawdzenie zakresu lub naruszenia wzorca wyrażeń regularnych) jest dla użytkownika końcowego niejasna: aby dokładnie przekazać błąd, można, przynajmniej trzeba powiązać szczegółową i przyjazną dla użytkownika diagnostykę błędów z każdym atrybutem.
Rozwiązanie nie rozwiązuje problemu generowania interfejsu użytkownika.

Wszystkie powyższe wady można naprawić, tworząc warstwę metadanych i kodu aplikacji, ale podczas tworzenia tego zniknęła pierwotna „zaleta” polegająca na tym, że nie trzeba tworzyć frameworka. Faktem jest, że solidne modelowanie rzadkich atrybutów danych jest trudnym problemem do projektowania aplikacji bazy danych, bez względu na to, które podejście do przechowywania danych jest używane. Praca Sarki udowadnia jednak zasadność wykorzystania pola XML zamiast relacyjnych tabel EAV specyficznych dla typu dla warstwy przechowywania danych oraz w sytuacjach, gdy liczba atrybutów przypadająca na jednostkę jest niewielka (np. zmienne atrybuty produktu dla różnych typów produktów ) rozwiązanie oparte na XML jest bardziej kompaktowe niż rozwiązanie oparte na tabeli EAV. (Sam XML może być traktowany jako sposób reprezentacji danych atrybut-wartość, chociaż jest oparty na tekście strukturalnym, a nie na tabelach relacyjnych).

Struktury drzewiaste i relacyjne bazy danych

Istnieje kilka innych podejść do reprezentacji danych o strukturze drzewa, czy to XML , JSON czy inne formaty, takie jak zagnieżdżony model zestawu w relacyjnej bazie danych. Z drugiej strony dostawcy baz danych zaczęli uwzględniać obsługę JSON i XML w swoich strukturach danych i funkcjach zapytań, tak jak w IBM DB2 , gdzie dane XML są przechowywane jako XML oddzielnie od tabel, używając zapytań XPath jako części instrukcji SQL lub w PostgreSQL , z typem danych JSON, który można indeksować i odpytywać. Te osiągnięcia uzupełniają, ulepszają lub zastępują podejście oparte na modelu EAV.

Zastosowania JSON i XML niekoniecznie są takie same, jak korzystanie z modelu EAV, chociaż mogą się pokrywać. XML jest lepszy niż EAV w przypadku arbitralnie hierarchicznych danych, które mają stosunkowo niewielką objętość dla pojedynczej jednostki: nie jest przeznaczony do skalowania do poziomu wielu gigabajtów w odniesieniu do wydajności manipulacji danymi. XML sam w sobie nie dotyczy problemu rzadkich atrybutów, a kiedy model danych leżący u podstaw reprezentowanych informacji można rozłożyć bezpośrednio na strukturę relacyjną, XML lepiej nadaje się jako środek wymiany danych niż jako podstawowy mechanizm przechowywania . EAV, jak wspomniano wcześniej, ma szczególne (i tylko) zastosowanie w przypadku scenariusza z rzadkimi atrybutami. Gdy taki scenariusz jest spełniony, użycie tabel atrybut-wartość specyficznych dla danego typu danych, które mogą być indeksowane według jednostki, według atrybutu i według wartości oraz manipulowane za pomocą prostych instrukcji SQL, jest znacznie bardziej skalowalne niż użycie struktury drzewa XML. Wspomniany powyżej silnik Google App Engine nie bez powodu korzysta z tabel z silnie typizowanymi wartościami.

Bazy grafów

Alternatywnym podejściem do zarządzania różnymi problemami napotykanymi w przypadku danych o strukturze EAV jest wykorzystanie grafowej bazy danych . Reprezentują one jednostki jako węzły wykresu lub hipergrafu , a atrybuty jako łącza lub krawędzie tego wykresu. Problem złączeń tabel rozwiązano, udostępniając specyficzne dla grafów języki zapytań, takie jak Apache TinkerPop lub dopasowanie wzorców przestrzeni atomowej OpenCog.

Inną alternatywą jest skorzystanie ze sklepu SPARQL .

Uwagi dotyczące oprogramowania serwerowego

PostgreSQL: kolumny JSONB

PostgreSQL w wersji 9.4 zawiera obsługę kolumn binarnych JSON (JSONB), które można odpytywać, indeksować i łączyć. Pozwala to na poprawę wydajności o tysiąc lub więcej razy w porównaniu z tradycyjnymi konstrukcjami stołów EAV.

Schemat bazy danych oparty na JSONB zawsze ma mniej tabel: można zagnieżdżać pary atrybut-wartość w polach typu JSONB tabeli Entity. Dzięki temu schemat bazy danych jest łatwy do zrozumienia, a zapytania SQL zwięzłe. Kod programistyczny do manipulowania obiektami bazy danych na warstwie abstrakcji okazuje się znacznie krótszy.

SQL Server 2008 i nowsze: rzadkie kolumny

Microsoft SQL Server 2008 oferuje (zastrzeżoną) alternatywę dla EAV. Kolumny z niepodzielnym typem danych (np. kolumny numeryczne, varchar lub datetime) mogą być oznaczone jako sparse, po prostu umieszczając słowo SPARSE w definicji kolumny instrukcji CREATE TABLE. Kolumny rzadkie optymalizują przechowywanie wartości NULL (które teraz nie zajmują w ogóle miejsca) i są przydatne, gdy większość rekordów w tabeli będzie miała dla tej kolumny wartości NULL. Optymalizowane są również indeksy w rzadkich kolumnach: indeksowane są tylko te wiersze z wartościami. Ponadto zawartość wszystkich rzadkich kolumn w określonym wierszu tabeli może być zbiorczo agregowana w pojedynczą kolumnę XML (zestaw kolumn), której zawartość ma postać. [<column-name>column contents </column-name>]*....W rzeczywistości, jeśli zestaw kolumn jest zdefiniowany dla tabeli jako część instrukcji CREATE TABLE, wszystkie później zdefiniowane kolumny rzadkie są zwykle do niej dodawane. Ma to interesującą konsekwencję, że instrukcja SQL SELECT * from <tablename>nie zwróci pojedynczych, rzadkich kolumn, ale połączy je wszystkie w pojedynczą kolumnę XML, której nazwa jest nazwą zestawu kolumn (który dlatego działa jako wirtualna kolumna obliczeniowa). Rzadkie kolumny są wygodne w przypadku aplikacji biznesowych, takich jak informacje o produkcie, gdzie odpowiednie atrybuty mogą być bardzo zmienne w zależności od typu produktu, ale gdzie łączna liczba zmiennych atrybutów na typ produktu jest stosunkowo niewielka.

Ograniczenia rzadkich atrybutów

Jednak to podejście do modelowania rzadkich atrybutów ma kilka ograniczeń: konkurencyjne DBMS-y nie zdecydowały się na pożyczanie tego pomysłu dla własnych silników. Ograniczenia obejmują:

Maksymalna liczba rzadkich kolumn w tabeli wynosi 10 000, co może być niewystarczające w przypadku niektórych implementacji, takich jak przechowywanie danych klinicznych, gdzie możliwa liczba atrybutów jest o jeden rząd wielkości większa. Dlatego nie jest to rozwiązanie do modelowania *wszystkich* możliwych atrybutów klinicznych pacjenta.
Dodanie nowych atrybutów – jeden z głównych powodów, dla których można poszukiwać modelu EAV – nadal wymaga DBA. Co więcej, nie rozwiązano problemu budowania interfejsu użytkownika w celu rozrzedzenia danych atrybutów: usprawniono jedynie mechanizm przechowywania. * Aplikacje mogą być napisane tak, aby dynamicznie dodawać i usuwać rzadkie kolumny z tabeli w czasie wykonywania: w przeciwieństwie do tego, próba wykonania takiej akcji w scenariuszu z wieloma użytkownikami, w którym inni użytkownicy/procesy nadal używają tabeli, byłaby zablokowana dla tabele bez rzadkich kolumn. Jednakże, chociaż ta zdolność zapewnia moc i elastyczność, zachęca do nadużyć i powinna być wykorzystywana rozważnie i rzadko.
- Może to spowodować znaczne obniżenie wydajności, po części dlatego, że wszystkie skompilowane plany zapytań, które używają tej tabeli, są automatycznie unieważniane.
- Dynamiczne dodawanie lub usuwanie kolumn to operacja, która powinna być kontrolowana, ponieważ usuwanie kolumn może spowodować utratę danych: zezwalanie aplikacji na modyfikowanie tabeli bez utrzymywania pewnego rodzaju śladu, w tym uzasadnienia działania, nie jest dobrą praktyką oprogramowania.
Ograniczenia SQL (np. sprawdzanie zakresu, sprawdzanie wyrażeń regularnych) nie mogą być stosowane do kolumn rozrzedzonych. Jedyne sprawdzanie, które jest stosowane, dotyczy prawidłowego typu danych. Ograniczenia musiałyby zostać zaimplementowane w tabelach metadanych i kodzie warstwy środkowej, tak jak ma to miejsce w produkcyjnych systemach EAV. (Ta uwaga dotyczy również aplikacji biznesowych).
SQL Server ma ograniczenia dotyczące rozmiaru wiersza podczas próby zmiany formatu przechowywania kolumny: całkowita zawartość wszystkich kolumn typu danych atomowych, rzadkich i nierozrzedzonych, w wierszu zawierającym dane nie może przekraczać 8016 bajtów, jeśli ta tabela zawiera rzadki kolumna danych, które mają zostać automatycznie skopiowane.
Rzadkie kolumny, które zawierają dane, mają narzut pamięci wynoszący 4 bajty na kolumnę, oprócz przechowywania samego typu danych (np. 4 bajty dla kolumn daty i godziny). Ma to wpływ na ilość danych o rzadkich kolumnach, które można powiązać z danym wierszem. To ograniczenie rozmiaru jest złagodzone dla typu danych varchar, co oznacza, że jeśli ktoś osiągnie limity rozmiaru wiersza w systemie produkcyjnym, trzeba to obejść, wyznaczając rzadkie kolumny jako varchar, nawet jeśli mogą mieć inny wewnętrzny typ danych. Niestety, to podejście obala sprawdzanie typu danych po stronie serwera.

Oferty przetwarzania w chmurze

Wielu dostawców chmury obliczeniowej oferuje magazyny danych oparte na modelu EAV, gdzie z daną jednostką można powiązać dowolną liczbę atrybutów. Roger Jennings zapewnia ich dogłębne porównanie. W ofercie Amazon, SimpleDB, typ danych jest ograniczony do łańcuchów, a dane, które z natury nie są łańcuchami, muszą być przekonwertowane na łańcuch (np. liczby muszą być uzupełnione zerami wiodącymi), jeśli chcesz wykonywać operacje takie jak sortowanie. Oferta firmy Microsoft, Windows Azure Table Storage, oferuje ograniczony zestaw typów danych: byte[], bool, DateTime, double, Guid, int, long i string [1] . Google App Engine [2] oferuje największą różnorodność typów danych: oprócz dzielenia danych liczbowych na int, long lub float, definiuje również niestandardowe typy danych, takie jak numer telefonu, adres e-mail, geokod i hiperłącze. Google, ale nie Amazon czy Microsoft, pozwala zdefiniować metadane, które uniemożliwiłyby powiązanie nieprawidłowych atrybutów z określoną klasą encji, umożliwiając utworzenie modelu metadanych.

Google pozwala operować na danych przy użyciu podzbioru SQL; Firma Microsoft oferuje składnię zapytań opartą na adresach URL, która jest abstrakcyjna za pośrednictwem dostawcy LINQ ; Amazon oferuje bardziej ograniczoną składnię. Niepokojące jest, że wbudowana obsługa łączenia różnych podmiotów za pomocą złączeń jest obecnie (kwiecień '10) nieistniejąca we wszystkich trzech silnikach. Takie operacje muszą być wykonywane przez kod aplikacji. Może to nie stanowić problemu, jeśli serwery aplikacji znajdują się w tej samej lokalizacji co serwery danych w centrum danych dostawcy, ale duży ruch sieciowy byłby generowany, gdyby oba te serwery były geograficznie rozdzielone.

Podejście EAV jest uzasadnione tylko wtedy, gdy modelowane atrybuty są liczne i rzadkie: jeśli przechwycone dane nie spełniają tego wymagania, domyślne podejście dostawców chmury do EAV jest często niedopasowaniem w przypadku aplikacji, które wymagają prawdziwej bazy danych zaplecza (w przeciwieństwie do zwykłego sposobu trwałego przechowywania danych). Modernizacja ogromnej większości istniejących aplikacji bazodanowych, które wykorzystują tradycyjne podejście do modelowania danych, w architekturę chmury typu EAV, wymagałaby poważnej operacji. Microsoft odkrył na przykład, że jego baza programistów aplikacji bazodanowych była w dużej mierze niechętna do inwestowania w taki wysiłek. Dlatego niedawno Microsoft udostępnił ofertę premium — dostępny w chmurze, pełnoprawny silnik relacyjny SQL Server Azure, który umożliwia przenoszenie istniejących aplikacji bazodanowych z niewielkimi zmianami.

Jednym z ograniczeń SQL Azure jest to, że fizyczne bazy danych są ograniczone do 500 GB od stycznia 2015 r. Firma Microsoft zaleca, aby większe zestawy danych były dzielone na wiele fizycznych baz danych i dostępne za pomocą zapytań równoległych.

Languages

In other projects