Architektura systemu bazodanowego odnosi się do struktury i organizacji systemu, w tym sposobu, w jaki dane są przechowywane, przetwarzane i zarządzane. Architektura systemu bazodanowego może obejmować różne komponenty, takie jak silnik bazy danych, interfejs użytkownika, mechanizmy zabezpieczeń i inne elementy, które współpracują ze sobą w celu zapewnienia wydajności, skalowalności i niezawodności systemu. Architektura systemu bazodanowego jest kluczowym czynnikiem wpływającym na jego wydajność i zdolność do obsługi dużych ilości danych.
Zobacz wszystkie tagiMercury DB (HgDB) 3.0 to implementacja serwera usług obiektowej bazy danych opartej o relacyjny model SQL (dane zachowywane są w relacyjnych strukturach). To pozwala na wykorzystanie wszelkich rozwiązań związanych z wszechobecną we współczesnych systemach obiektowością oraz tradycyjnych systemów BI (Business Intelligence) opartych o silnik relacyjny.
Podstawą wyszukiwania w systemie Mercury DB jest Indeks Lucene. W niniejszy artykule przedstawione zostaną zasady tworzenia nazewnictwa pól, które są podstawą do realizacji zapytań wyszukiwania. Zaprezentowany zostanie również podział pól ze względu na ich rodzaj, kategorię (podział ze względu na pochodzenie pola) oraz sposób wyszukiwania (podział ze względu na typ pola).
Mercury to repozytorium metadanych o obiektach wraz z definicjami kontrolek GUI umożliwiającymi generowanie formularzy GUI. Metadane to ustrukturyzowany informacje stosowane do opisu obiektów (spraw) - opisują logiczny i fizyczny związek pomiędzy częściami złożonego obiektu (zobacz Opisywanie obiektów cyfrowych, 21 października 2016 [dostęp 2020-07-01]). Mercury DB w swoich strukturach umożliwia również przechowywanie niezbędnych danych pozwalających na generowanie formularzy edycji oraz stron prezentacji składowanych obiektów. Metadane składowane są w relacyjnej bazie danych (SQL). Synonimem definicji metadanych spraw jest typ sprawy. Poniżej opis encji.
Podczas aktualizacji obiektów spraw automatycznie tworzona jest historia zmiany. Jednak gdy dochodzi do zmiany typu sprawy, co jest niejednokrotnie częstym zjawiskiem w systemach szybko rozwijających się, zmieniających model przechowywania danych, powstaje nowa wersja sprawy. Akcja zachodzi automatycznie, gdy (korzystając z usług warstwy biznesowej) wykonamy zapis sprawy (istniejącej) i gdy zostanie wykryta zmiana typu tj. zostanie dodane nowe pole, zostanie wykryta zmiana typu pola. Od wersji 3.0.1.0.2 akcję zmiany wersji można wykonać "manualnie" wywołując odpowiednią sekwencję zapisów, o czym powiemy sobie na końcu artykułu.