...
Verksamhetslager
TBD
Persistenslager
TBDDetta lager är baserat på JPA 2.0 samt Spring Data och Hibernate. För lokala tester används en HSQL in-memory databas och för externa tester används MySQL.
Persistenslagret kan konfigureras för att använda andra databaser som MS SQL Server, IBM D2 eller Oracle, men har endast verifierats med MySQL.
Mappning till tabell
Databasstrukturen är enkel med en enda huvudtabell där nästan hela posten är en primärnyckel och den information som uppdateras är endast två datumfält.
Tabellen ser ut enligt:
engagement_index_table
| Kolumnnamn | Null | Primär- nyckel | Del av logisk- nyckel | Typ och Längd |
|---|---|---|---|---|
| id | Nej | X | Varchar(64) | |
registered_resident_id | Nej | X | Varchar(32) | |
service_domain | Nej | X | Varchar(255) | |
categorization | Nej | X | Varchar(255) | |
logical_address | Nej | X | Varchar(64) | |
business_object_instance_id | Nej | X | Varchar(128) | |
source_system | Nej | X | Varchar(64) | |
data_controller | Nej | X | Varchar(64) | |
owner | Nej | X | Varchar(64) | |
clinical_process_interest_id | Nej | X | Varchar(128) | |
creation_time | Nej | Timestamp | ||
update_time | Ja | Timestamp | ||
most_recent_content | Ja | Timestamp |
Förutom primärnyckeln som är id så finns ett sökindex med namnet engagement_search_index.
Primärnyckel
I enlighet med specifikationen är den unika verksamhetsnyckeln ganska komplex och är just nu (RC8) baserad på nio fält, och för att underlätta databashanteringen har en teknisk primärnyckel valts där den denna härleds utifrån verksamhetsnyckeln. Den valda algoritmen för att skapa denna unika nyckel är SHA-2 eller mer exakt SHA-256, och resultatet är en 32 bytes array som sedan konverteras till en 64 teckens sträng på hexadecimalt format. I teorin kan duplikat uppstå, men i praktiken har ingen funnit några duplikat vid användning av denna algoritm, se även http://en.wikipedia.org/wiki/SHA-2.
Observera att användningen av en teknisk primärnyckel inte förändrar det faktum att man inte under några omständigheter kan ändra på någon del av verksamhetsnyckeln, dvs. utifrån detta perspektiv är det exakt samma hantering som om verksamhetsnyckeln hade används som primärnyckel. Därför har varje fält som ingår i verksamhetsnyckeln markerats med en JPA indikator om att fältet ifråga inte ska uppdateras.
Sökningar
För sökningar används springs JPA repository interface, där sökningar definieras antingen med namnkonvention eller med SQL (JPQL) satser.
Portering databaser
Nuvarande implementation har endast verifierats med MySQL 5 databas och det finns ett antal punkter som man bör reflektera över när det gäller portering till andra databaser:
- Vid sökning av flera poster med hjälp av primärnyckeln används en "IN" sats och vissa databaser kan kan ha begränsningar med avseende på batch-storleken för denna typ av anrop