[Conny Westh]

För att uppnå en hyfsat flexibel modell bör du göra ungefär så här:

Du har en tabell för USER och en för GROUP och en tabell för RESOURCE.


För att koppla ihop USER och GROUP så att du får en många-till-många-relation behöver du ha en "länktabell" mellan de två låt oss kalla den USERGROUP.

Tabellen USER har en PK som vi kallas USERPK och GROUP har en PK som vi kan kalla GROUPPK.

Tabellen USERGROUP behöver då ha två kolumner som vi kan kalla för USERFK och GROUPFK (eftersom de är främmande nycklar ii USERGROUP som pekar på PK i USER respektive GROUP:

USER:
- USERPK (PK1)

GROUP:
- GROUPPK (PK1)

USERGROUP:
- USERFK (PK1)(FK1) -> USER.USERPK
- GROUPFK (PK2)(FK2) -> GROUP.GROUPPK

RESOURCETYPE:
- RESOURCETYPEPK (PK1)



RESOURCE:
- RESOURCEPK (PK1)
- RESOURCETYPEFK (FK1) -> RESOURCETYPE.RESOURCETYPEPK


USERGROUPRESOURCE:
- USERFK (PK1)(FK1) -> USERGROUP.USERFK
- GROUPFK (PK2)(FK2) -> USERGROUP.GROUPFK
- RESOURCEFK (PK3)(FK3) -> RESOURCE.RESOURCEPK


Sen behöver du komplettera med eventuella databärande kolumner, jag har bara lagt upp de som är primärnycklar och främmande nycklar.

RESOURCETYPE skulle då kunna vara Dokument eller Formulär som rena tupler, men här går det ju att variera sig en del, om man vill ha hårdare styrning av egenskaper så kanske egna tabeller för Dokument respektive Formulär är på sin plats.

Men väljer man att lägga till Dokument och Formulär i stället för RESOURCETYPE så bör de peka på RESOURCE, annars får man en massa duplicerad funktionalitet i databasen.

Om Dokument och Fformulärhar egna unika egenskaper som behöver lagras så kan det vara att föredra att skapa egna tabeller för dem.

Men det här är bara idéer och uppslag då jag inte vet exakt hur du ska använda systemet och då finns det flera avvägningar man får göra innan man hittar en optimal struktur.