Mercury powstał z potrzeby efektywnej rejestracji, wyszukiwania, porównywania i audytowania danych jakie są wykorzystywane w trakcie działania aplikacji procesowych w przedsiębiorstwie.

Mercury może pełnić funkcje repozytorium danych, dla aplikacji procesowych (w szczególności IBM Business Process Manager), repozytorium niezależnego od istniejących w organizacji systemów, zunifikowanego repozytorium danych dla aplikacji wewnętrznie tworzonych w organizacji (np. kiedy chcemy zarządzać dowolnymi danymi, nie posiadamy dedykowanego systemu i tworzymy rozwiązanie wewnątrz organizacji, a chcemy aby dane były bezpieczne i przechowywane w sposób jednolity dla każdej aplikacji).

Mercury ma zastosowanie wszędzie tam, gdzie w wyniku rozwoju aplikacji, model danych ulega dynamicznym zmianom. Zapewnia on stały dostęp do danych we wszystkich zaimplementowanych modelach. Nie wymaga migracji danych do nowych wersji struktur przechowywania danych. Silnik identyfikacji typów przechowywanych obiektów realizuje zadanie budowania ontologii, tworzy ich nowe wersje oraz powiązania pomiędzy nimi. Możliwość definiowania alternatywnego nazewnictwa pól pozwala na tworzenie uniwersalnych relacji pomiędzy danymi pochodzącymi z różnych systemów.

W repozytorium danych Mercury przechowywane są metadane dotyczące typów obiektów jak i również sposobu ich prezentacji na formularzach WWW, aplikacjach mobilnych. W związku z tym jest on idealnym rozwiązaniem dla implementacji mechanizmów ich automatycznej generacji, dynamicznej prezentacji danych użytkownikowi końcowemu.

Firmy które wykorzystują Mercury DB (HgDB) w swoich projektach:

Korzyści z zastosowania Mercury DB

1. Niezależność od producenta silnika RDBMS (serwera relacyjnej bazy danych). Mercury wspiera następujące implementacje serwerów: MySQL, PostgreSQL, Oracle, DB2 oraz MS SQL.

2. Implementacja Mercury wykorzystuje jednolitą architekturę relacyjnej bazy danych, dla dowolnych obiektów, zoptymalizowaną pod kątem pracy z dużym wolumenem danych i obsługą dużej ilości transakcji.

3. Implementacja Mercury zawiera:
   1. Wsparcie szybkiego wyszukiwania pełno tekstowego w odrębnych strukturach noSQL (Apache Lucene).
   2. Wykorzystanie pamięci podręcznej (cache) na różnego rodzaju poziomach w celu optymalizacji zapytań do relacyjnej bazy danych oraz optymalizacji akcji modyfikacji danych.
   3. Dostęp do danych jest możliwy z wielu systemów. W architekturze SOA realizując strategię "omnichannel e-commerce" pozwala na wykorzystanie Mercury do celów MDM (Mobile Device Management), centralnego repozytorium wszelkich danych dla wszystkich systemów w przedsiębiorstwie..
4. Wersjonowanie definicji encji (typu obiektu). Aktualizacja/modyfikacja definicji pojedynczej encji w Mercury powoduje powstanie jej nowej wersji i automatycznie aktualizuje powiązania pomiędzy innymi encjami modelu. Nie jest wymagane tworzenie nowych powiązań, tak jak w tradycyjnym modelu SQL.
5. Nie ma obawy, że będziemy chcieli zapisać/odczytać obiekt o nieaktualnej strukturze (sprawa, której struktura została zmieniona, a my tego nie zweryfikowaliśmy). Jednocześnie mamy cały czas dostęp do danych przechowywanych w poprzednich wersjach.
6. Zaawansowane metody wyszukiwania pozwalają na przetwarzanie danych pochodzących z różnych wersji modeli encji oraz ich prezentacji na jednej liście wyników wyszukiwania.
7. Obsługa zewnętrznych źródeł danych słownikowych. Systemy wymagają danych słownikowych, które w tradycyjnych rozwiązaniach przechowywane są w tablicach, do których kopiowane są dane z różnych systemów i pojawia się problem ich aktualności (synchronizacja danych pomiędzy systemami). System Mercury pozwala na integrację różnych systemów i dostarczanie danych słownikowych „on-line”. Obsługuje komunikację z zewnętrznymi źródłami danych przy wykorzystaniu sterowników JDBC oraz autorskiej implementacji klienta HTTP/HTTPS.
8. Możemy zdefiniować różne źródła pobierania danych dla klientów serwera Mercury:
   1. Jako źródło danych SQL
   2. Jako źródło usług SOAP.
   3. Jako źródło usług REST.
   4. System Mercury posiada prostą, własną definicję API do pobierania danych po protokole HTTP/HTTPS, więc jeżeli system zewnętrzny nie posiada typowych implementacji API SOAP, REST, można tworzyć własne integracje po stronie systemu klienckiego.

Cechy rozwiązania Mercury DB

1. Architektura klient-serwer – Aplikacja jest zbudowana w języku JAVA i działa w oparciu o serwer aplikacji Apache Tomcat®.
2. Szybkość i skalowalność – Mercury przetwarza dane wielowątkowo co pozwala na łatwe skalowanie pionowe (liczba CPU, optymalne wykorzystanie mocy serwerów) jak i poziome (klastry serwerów aplikacji).
3. Możliwość użycia w dowolnej aplikacji – Dostępne API SOAP, REST oraz klient JAVA. Wszelkie operacje na danych (zapis, odczyt, wyszukiwanie, wersjonowanie, …) można wykonywać za pomocą API dostępnego jako metody SOAP, REST lub biblioteki JAVA, którą można wykorzystać we własnych aplikacjach.
4. Uniwersalne API – Pozwala na wykorzystanie tego samego zestawu metod bez względu na strukturę danych. W rozwiązaniu Mercury wykorzystujemy nazwy klas obiektów oraz zbiory ich atrybutów do identyfikacji struktur zapisywanych i odczytywanych obiektów.
5. Wyszukiwanie danych za pomocą składni zapytań Apache Lucene – Indeksowanie danych i wyszukiwanie opiera się o bardzo efektywny silnik Lucene co pozwala na znaczenie szybszy dostęp do danych (potrzebny przede wszystkim w dynamicznych aplikacjach WWW używających wywoływania AJAX, itp.
6. Rejestracja historii zmian danych – Możliwa jest rejestracja historii zmian w danych. Rozwiązanie pozwala na śledzenie zmian w danych na potrzeby audytów przy niewielkim zwiększeniu obciążenia aplikacji oraz serwera. Przechowywane są dwie formy historii zmian:
   1. migawka zmiany – rejestr przechowujący odwzorowanie pełnego obiektu z wartościami pól sprzed zmiany
   2. strumień zmian – rejestr zmian wartości dla poszczególnych pól obiektu. Zawiera dane związane z nazwą pola, jego starą wartością oraz nową wartością
7. Struktura fizyczna danych oparta o bazę SQL – dane przechowywane są w bazie SQL (MySQL, PostgreSQL, Oracle, IBM) co pozwala na wykorzystanie danych w celu raportowania za pomocą narzędzi zewnętrznych. W relacyjnej bazie danych tworzone są widoki reprezentujące zdefiniowane typy obiektów.
8. Wersjonowane zmiany struktur obiektów – Każda modyfikacja obiektów zapisywana jest jako nowa wersja obiektu co pozwala na odczyt danych w odpowiedniej wersji.
9. Możliwość hierarchizacji obiektów – Mercury umożliwia odwzorowywania zależności między obiektami i budowy hierarchii obiektów co przydaje się do budowy złożonych obiektów biznesowych i odwzorowywania dowolnych modeli danych jakie używamy w systemach.
10. Wsparcie dla OAuth 2.0 w usługach REST – Jest możliwość zabezpieczenia dostępu do danych za pośrednictwem mechanizmów autoryzacji opartych o token w standardzie OAuth 2.0.
11. Zabezpieczenie danych chronionych - istnieje oznaczenia poszczególnych pól obiektów/spraw jako pola chronione ("protected"). Dzięki temu nie są one przechowywane w indeksie Lucene.
12. Obsługa transakcji ACID (Atomicity, Consistency, Isolation, Durability) - Jako, że system Mercury składuje dane obiektów w relacyjnej bazie danych, podczas operacji ich modyfikacji, wykorzystuje on mechanizmy transakcyjności dostarczone wraz z silnikiem RDBMS.