Sitter och knåpar med en ResursbokningsDB. Behöver hjälp på hur jag ska designa den. Användare kan boka en eller flera resurser. Resurserna kan vara av olika typ (ex skrivare eller ett rum). Bokningar kan ske mån-fre 07:00 - 20:00 och man kan boka en resurs en halvtimme och längre. Vad jag tänkt är att visa en stapel på varje bokad resurs, där stapeln växer ju mer tid den är bokad. Sen ska bara vissa användare kunna boka vissa resurser, men det kanske inte har med DB:n att göra. Inloggning ska ske mot ett AD.

Förslag till DB design någon?

MVH E

rent spontant

1. tabell person, innehåller personinformation
2. tabell bokning, innehåller specifik info om bokningen och har många till en relation till person(1)
2. tabell resurs, innehåller information om resursen, kopplad till bokning
3. tabell resurstyp, kopplad till resurs och specar vilken typ det är
4. tabell säkerhet, kopplad till resurs och person, innehåller användarid & resursid så att man specificera vem som får se vad


Så, då har du en struktur för att kunna boka koppla resurs till en bokning. Vill du kunna boka flera resuser på samma bokning lägger du till en kopplingstabell mellan bokning och resurs. Vill du underlätta säkerhetshantering (vissa användare kan bara boka vissa saker) kanske du bör funder på att införa användargrupper(dvs istället för att ge varje person tillgång till varje specifik resurs så kopplar du användare till en eller flera grupper som har åtkomst till vissa resurser). Någonting i användare skall kopplas mot befintlig användare i ditt AD så att man löser användaridentifiering (dvs slippa logga in mm).

När bokningar skall kunna ske i tiden tas ej upp i databasdesigenen som sådan, det löser du antingen i ett businesslager eller på andra sätt (tex med hjälp av triggers). Att vissa staplar mm gör man inte heller i en databasdesign, det ligger på presentationslagernivå.

Tack för svaret Marcus. Ditt förslag var ganska likt det jag gjorde. Eftersom en användare skall kunna boka flera resurser som har jag (som du även skrev) en tabell som heter bokningsrad. Dessutom har jag tre till tabeller, tid (id, tid = halvtimmes intervall), vecka (id, veckonummer = 1-52) samt dag (id, veckodagarna).

Jag förstår att "visa staplarna" hör till presentationslagret.. men.. för att göra detta måste man ju veta hur länge (tex 07:00 - 09:30) en resurs är bokad och när den är det. Och för att veta detta måste ju det lagras. Eller?

Förstår inte ditt förslag om triggers och businesslager, men du kanske kan förtydliga?

MVH Erik

OBS, med slutdatum och startdatum menar jag egentligen något av datatypen Datetime som lagrar både datum OCH tid. Nedanstående är skrivet utifrån ett perspektiv med SQL server som databas och något modernt utveklingsspråk, men samma tänk kan användas på de flesta databaser och språk.

Förstår inte riktigt ditt tänk med de tre tabellerna tid, vecka och dag, det verkar uppriktigt sagt helt uppåt väggarna. I de flesta databaser finns det datatyper för lagring och hantering av datum och tider (tex datetime i sql server). Mitt förslag är att du tar bort de tabellerna och lägger till ett startdatum och ett slutdatum i antingen bokningstabellen eller bokningsrad. Det gör att du får en mycket bättre databasstruktur som stämmer överens med ungefär hur 100% av motsvarande bokningssystem fungerar.

Var du lägger det beror på hur du vill jobba. Vill du kunna boka upp resurserna samtidigt som en övergripande bokning eller vill du kunna boka upp en resurs under en del av en överhängande bokning? Tex att man gör en överhängande bokning som är en hel dag, till den knyter man en resurs (tex konferrensrum) som gäller för hela bokningen och en annan resurs (tex projektor) som man bara behöver en del av dagen. Detta möjliggör tex för andra att kunna boka resursen under den del av dagen som du inte har behov av den.

För att hantera när en resurs är bokad så används olika metoder beroende på databas och utvecklingsspråk. Använder du tex SQL server som db och VB, .Net eller ASP(i någon form) så kan jag rekommendera en närmare studie av DATEDIFF-funktionen. Denna funktion finns dock inte i Oracle där datum hanteras lite anorlunda.

<b>Jag förstår att "visa staplarna" hör till presentationslagret.. men.. för att göra detta måste man ju veta hur länge (tex 07:00 - 09:30) en resurs är bokad och när den är det. Och för att veta detta måste ju det lagras. Eller?</b>

Självklart måste det lagras och det är ju en del av bokningen (bokning eller bokningsrad beroende på hur man vill ha det enligt resonemanget ovan), inte något som skall sparas i egna tabeller. Jag tog det för uppenbart att det skall ligga i bokningen eller bokningsraden så jag skrev inte något om det.


<b>Förstår inte ditt förslag om triggers och businesslager, men du kanske kan förtydliga?</b>

Businesslager = något som håller i de affärsregler som gäller och gör kontroller. Vissa lägger mycket i databasen i stored procedures eller triggers, andra gör det i programkod. Tex att du i programmet som skall hantera det klickar på knappen ”Spara”, det första man gör är inte att spara resursbokningen utan man gör en sökning i databasen efter en annan bokning. Hittar man en annan bokning infomerar man användaren om det och låter den gör något val, i annat fall sparar man ner bokningen.

Grovt förenklat kan man dela upp ett program i olika lager(skikt) där databasen inte ingår. Man kan ange tre olika lager: databaslager, businesslager och presentationslager.
Databaslagrets enda uppgift är att hämta data och spara data till databsen.
Presentationslagrets enda uppgift är att visa data för användaren och låt den påverka data.
Businesslagret är då det egentliga hjärtat som styr enligt vilka regler data skall behandlas, det är t ex detta lagret som skall se till att resurser inte kan bokas samtidigt. I en perfekt värld skall man även kunna byta ut t ex databaslager om man bestämmer sig för att använda en annan databas (dvs man byter ut detta lager om man vill byta från Oracle till SQL server). Detta är ju inte något som påverkar affärsreglerna och bör då inte heller påverka businesslagret. OBS, detta är grovt förenklat och det finns många variationer.

Trigger = Något i databasen som utlöses av en händelse. T ex vid insert av en bokningsrad. Finns det en Trigger då så ”triggas” (utlöses) den och en kontroll kan göras om tiden man vill boka resursen på allaredan är upptagen och isåfall kan trigger svara med ett medelande om det och i annat fall spara ner posten. Grovt generaliserat och förenklat, men i stort sett så...

Så för att avsluta
Tabell, kolumner (*= primär nyckel, + = främmande nyckel, *+ = både och)
1. Person, *Personid
2. Bokning, *Bokningsid +Personid startdatum slutdatum
3. Resurs, *ResursId
4. Bokningsrad, *+Bokningsid *+Resursid startdatum slutdatum
5. Behörighet, *+PersonId *+Resursid
Resten av kolumnerna som kan tänkas ingå i tabellerna skriver jag inte ut utan endast de som behövs som primär/främmande nycklar samt vad som behövs för att boka en resurs i tiden.

Dett ger dig möjlighet att:
• Skapa en bokning och till den knyta inga eller ett flertal resurser (logik för att styra så att en bokning utan resurser inte kan skapas hör inte hemma i databasmodellen )
• Ange ett datum som gäller övergripande för bokningen, men även ange att vissa resurser som ingår i bokningen bara är bokade en viss tid. (t ex bokning av konrefensrum en hel dag där en projekt kanske bara behövs under eftermiddagen, dumt att boka även projektorn en hel dag)
• Enkelt kontrollera när en resurs är bokad, tex med Datediff metoden (som det står massor av i hjälpen beroende på vad du utvecklar i)

Som vanligt så hänvisas till en författre som heter Date som har skrivit en mycket bra bok om databaser, kommer dock inte ihåg vad den heter, där du kan lära dig om normalisering mm.


Hoppas att du förstår ungefär hur jag menar, hör gärna av dig annars.

Tack för svaret Marcus. Slog helt slint i min hjärna när jag gjorde databasen. Så fort jag läste meningen om datetime i sql server klickade det, he he he så kan det bli ibland då man är trött. Tror jag kommer att göra så att man knyter resursen till bokningen så att användare kan ta del av den under den tid den inte är uppbokad (som du nämnde). Jag skall definitivt kolla upp DATEDIFF-funktionen den verkar vara bra för mitt ändamål.

Det du skrev om de olika lagrena/skiktena var otroligt givande (du kanske skall skriva en artikel om detta för sådana som mig :) och den uppskattades.

MVH ERIK