Databasdesign närvaro

Hej,

Jag försöker skapa en databas till ett program som kommer att användas för att registrera närvaro för ett antal grupper och dess medlemmar. Jag har lite svårt att greppa hur jag ska lägga upp tabellerna för att det ska bli optimalt.

En medlem kan gå med i en eller flera grupper. Dom här grupperna har sedan flera träffar där närvaro för varje medlem i gruppen ska registreras för den instansen av träffen.

Vilka värden ska sparas i närvaro-tabellen? Varje medlemsID för just den träffen, eller grupp-id? Jag tänker mig närvaro som en bool, men hur utformar man det här smartast?

Jag tänker mig tabellerna såhär

Medlem--
MedlemsID
Namn

Grupp--
Gruppid
Namn

Träff--
Träffid
Startdatum
Stopdatum
Gruppid(FK)

Närvaro--
Träffid(FK)
MedlemsID(FK)
Närvarande(bool)

All hjälp uppskattad!

Jag hade kanske inte löst det hela riktigt som du har gjort, men nästan :-)

Om man börjar bena i problemet finns det tre entiteter att hålla reda på, Medlem, Grupp och Träff och de har du ju identifierat.

Sedan kan man göra på lite olika sätt, men jag tolkar ditt "En medlem kan gå med i en eller flera grupper", som att det är information i sig som behöver sparas ner. Dvs någonting i den här stilen:

MedlemGrupp--
MedlemGruppID (PK)
MedlemsID
GruppID

Skulle också lägga till ett par datumkolumner för att hålla reda på när medlemmen tillhör en viss grupp (start och slutdatum).

Eftersom varje medlems närvaro ska registreras på respektive gruppträff kan man i Närvaro-tabellen använda en FK till MedlemGruppID. På så sätt kan inte en medlem vara med på en träff i en grupp han eller hon inte tillhör.

Närvaro--
Träffid(FK)
MedlemGruppID (FK)
Närvarande(bool)

Själv skulle jag inte ha kolumnen "Närvarande", för är personen närvarande, finns det en post i tabellen, annars inte. Varför lagra onödig information, som dessutom riskerar att bli inkonsekvent? Ska du lägga till "ej närvarande" på alla gamla träffar då du lägger till en ny medlemmar i en grupp?


Det här är nåt i stil med "tredje normalformen", dvs lagra information på bara ett enda ställe. Lite beroende på användningsområde och hur många träffar och användare du kommer ha i databasen, så kan man få dubbellagra information, för att få upp farten/användbarheten, men det är överkurs just nu tror jag.

Tack för ditt svar, många nyttiga tips!

Det om att bara lagra närvarande medlemmar tar jag med mig direkt, det låter ju väldigt logiskt. :-)

Jag antar att jag då kan göra en selection i närvaro-tabellen, t ex: "CASE WHEN medlem_id IS NULL THEN 'Frånvarande' ELSE 'Närvarande'". Borde ju vara bra mycket mer effektivare än att spara 1/0 för varje.

Ska också lägga till fler datumkolumner. Undrade dock lite över denna:


Om jag sparar enbart träffid och FK från MedlemGruppID i "Närvaro"-tabellen, kommer jag då kunna söka på liknande sätt som ovan. Kanske bara är att joina in MedlemGrupp-tabellen i queryn?

Närvaro--
Träffid(FK)
MedlemGruppID (FK)
Datum

Du måste joina in MedlemGrupp-tabellen för att få namn på gruppen och om medlemmen är med där.

Nu har jag labbat lite med det här och en fråga dök upp. Ser du någon fördel med att använda MedlemGruppID i närvaro-tabellen istället för att bara skriva in medlem_id, och alltså länka en medlem till en närvaro istället för som nedan?

MedlemGrupp--
MedlemGruppID (PK)
MedlemsID
GruppID

Tittar jag i lite exempel-databaser så verkar standard i M:N-tabeller vara att PK är kombinationen av t ex MedlemsID och GruppID. Går detta då att referera till på något sätt eller måste man ha en extra nyckel för detta som i tabellen ovan?

Jag tänker mig alltså närvarotabellen som nedan. Gör det någon egentlig skillnad? Jag får då joina in grupp_medlem för att ta reda på vilken grupp studenten tillhör.

Närvaro--
Träffid(PK)
MedlemID (PK)
datum

Personliga småsaker:

1. brukar markera upp rena relationstabeller specifikt, skönt kunna ha dom markerade i schemat. T.ex. relmembergroup.

2. Närvarande -true/false på den skulle ju kunna markera explicit frånvaro, i den mån man vill hålla koll på det. Man kan ju vara medlem i gruppen, men frånvarande på träffen.

Gör en konceptuell modell (den har du ju redan nästan klar) och sen översätt den till en logisk datamodell (nu kommer alla gafflar åt bägge hållen att lösas) och sen en fysisk.

Kika lite på http://dbwebb.se/kunskap/kokbok-for-databasmodellering för ideér, men tänk åxå på "över tid" dvs det går att konstruera en databas så man inte kan göra en sak igen pga att man redan gjort det. Tex hyra en lägenhet/hotellrum, har du inte med ett start och slutdatum så blir det marigt att hyra lägenheten igen om tex pnr (pass eller personnummer) används som enda nyckel.

Att sitta och labba, utan att tänkt igenom designen är ju lite tidsödande. Men tja har man tid så går det väl åxå.