Race database met twee tabellen lineitems

[martindes]

Ik wil graag een database in elkaar zetten waarbij ik de mogelijkheid heb om in een aparte tabel coureurs toe te voegen inclusief het team waarvoor ze beschikbaar zijn in een bepaalde seizoen.

 

Er zijn twee zaken die van belang zijn.

 

1. Het totale aantal coureurs bedraagt al 940 personen. Het zou dus erg mooi zijn wanneer ik per seizoen alleen de coureurs kan toevoegen in aparte tabel om de lijst overzichtelijker en minder foutgevoelig te maken.

 

2. In eén seizoen kan een coureur meerdere auto's gebruiken. Ik kan dus in mijn voorbeeld er niet voor kiezen dat ik automatisch een auto koppel aan een coureur. In 1952 zou dat voor Graham Hill wel kunnen maar niet voor Tony Brooks omdat die in mijn voorbeeld twee auto's heeft gebruikt.

 

Ik heb in mijn huidige oplossing twee tabellen lineitems gemaakt.

 

Een Seizoen_Lineitems tabel waarin alleen de coureurs staan die actief zijn in het seizoen van het record.

Een Races_Lineitems tabel voor de races waarin de coureurs worden toegevoegd vanuit de Seizoen_Lineitems tabel inclusief het team waarvoor ze in die éne specifieke race gereden hebben.

 

Het is de bedoeling dat ik in de lay-out van Races de races aan kan maken in een portaal.

 

Mijn problemen met deze oplossing.

 

1. In de Seizoen_Lineitems is de Primary Key uiteraard niet altijd hetzelfde als de PK van de coureur uit de tabel coureur. Ik heb dus die PK_Coureur nodig om die te verwerken in andere relaties om een totaal overzicht te krijgen.

 

2. Bij het maken van een nieuw record in de lay-out Races krijg ik de __PK_Races niet in het portaal record van Races_Lineitems.

 

Volgens mij is het maken van records in portalen het beste te doen met een script knop maar dat lukt me niet.

 

Heeft iemand suggesties en een oplossing zodat ik beter leer te begrijpen hoe deze materie in elkaar zit?

 

Ik heb het bestand bijgevoegd.

 

Bij voorbaat hartelijk dank voor de antwoorden.

Ploegenschema.fmp12 2.zip

[menno]

Ik heb jouw voorbeeldje even bekeken en je bent volgens mij in de goede richting bezig, maar ik zou het nog wat verder uitwerken voordat je begint met van alles aan elkaar te knopen. Als ik het voor mezelf op een rijtje zie, dan kom ik tot de volgende basis:

 

• 5 hoofdtabellen:
  
• Coureurs De persoon (Naam en andere persoonskenmerken)
  
• Teams Is een apart team of bij gebrek aan een team de individuele coureur
  
• Seizoenen Het seizoen (periode etc)
  
• Autos Merk, Type, VIN en overige kenmerken
  
• Races Races zonder data bijv. GP Monaco.

• 2 tussentabellen
  
• Races_Seizoenen De individuele race in een specifiek seizoen
  
• Autos_Teams_Coureurs De combinatie zoals deze deelneemt aan een race

• 1 resultaattabel
  
• Deelnames Races_Seizoenen + Autos_Teams_Coureurs

 

De focus ligt hier dus op de coureurs die met een bepaalde auto van een bepaald team deelnemen aan individuele races. Vanaf hier kan je vervolgens gemakkelijk weergaven maken van welke coureurs in bepaalde seizoenen hebben deelgenomen. Of welke auto's door welke coureurs zijn bestuurd etc. etc.

Is het niet belangrijk voor je om precies te weten welke auto's er zijn gebruikt en volstaat het merk/type, dan geef je dat aan bij de combinatie Teams_Coureurs. Die zijn dan mogelijk niet meer uniek, dus mijn keuze zou zijn de auto's wél als aparte entiteit te behandelen.

 

Ik zie alleen niet uit je verhaal komen wat je precies wilt bereiken. Een goede opzet bereik je door ofwel heel duidelijk je doel voor ogen te hebben óf door alles zoveel mogelijk uit splitsen door te normaliseren (zie o.a. https://nl.wikipedia.org/wiki/Databasenormalisatie)

 

Normalisatie kan extreem ver gaan en is voor FileMaker lang niet altijd handig, maar door het op zijn minst te overwegen, ga je wel heel intensief je datamodel bekijken en soms ook wel aanpassen. Vanwege deze normalisatie zou ik dus die auto's als aparte entiteiten behandelen in jouw DB, maar dat is jouw beslissing en is afhankelijk van je precies van jouw DB verwacht.

 

Om bij die auto te blijven, die zou je verder uiteen kunnen laten vallen door weer aparte tabellen te maken voor "Merk" en "Model" en Model zou weer uiteen kunnen halen in "Type" en "Versie" oid. Dat gaat voor jouw toepassing hoogstwaarschijnlijk weel te ver en dus zou je kunnen volstaan met een tabel "Auto" waarin bijvoorbeeld "VIN" het belangrijkste kenmerk is, maar dat zou ook het "Racenummer" kunnen zijn.

 

Niet direct antwoord op jouw vraag vrees ik, meer een pointer in een bepaalde richting, maar ik hoop dat je er iets mee kan aanvangen.

 

Succes in China trouwens, ik neem aan dat je er aan het werk bent?

[martindes]

Dank voor je reactie. Ik zal het morgen even goed doorlezen. Is al laat hier. Ik ben inderdaad in China aan het werk en wil me verder bekwamen in Filemaker. Ik ben trouwens wel wat verder gekomen met een aantal probleempjes maar ik weet dat de opzet van de database in beginsel goed moet zijn en dat is, zeker bij deze database, erg belangrijk. Daarom heb ik hier ook voor gekozen omdat er meer dan voldoende puzzelstukjes in zitten. Wat dacht je bijvoorbeeld van de teams. Ferrari's hebben onder de vlag van Scuderia Ferrari gereden maar zijn ook in het verleden gebruikt door privé coureurs. Of dat coureurs tijdens een race van auto wisselden en de punten deelden met degene die de auto vrij maakte. Vandaar dat ik voor deze oplossing heb gekozen om wat beter bekwaam te worden in Filemaker.

[martindes]

Ik zou graag een standaard script willen hebben om via een portaal een nieuw record aan te maken. Dat blijft nl. ook nog steeds problemen geven in mijn database.

[menno]

Hieronder de code van hoe je zo'n record zou kunnen aanmaken in de portaal op de layout "Seizoen" van jouw eigen voorbeeld:

If [ Get ( LayoutTableName ) ≠ "Seizoen" ]
# Zorg dat je op een layout met de context "Seizoen" staat
Exit Script [ ]

Else If [ Get ( WindowMode ) ≠ 0 ]
# Zorg dat je blader-modus actief is
Exit Script [ ]

End If 

# Venster vastzetten, anders beweegt er van alles en de procedure is langzamer
Freeze Window

# Sla de PK van het huidige record op in een variabele
Set Variable [ $pk ; Value:Seizoen::__PK_Seizoen ]

# Ga naar een layout waarvan de basistabel dezelfde is als van de portaal waar een record moet worden aangemaakt
Go to Layout [ "Seizoen_Lineitems" ]

# Maak hier een nieuw record aan
New Record/Request

# Vul de juiste FK met de zojuist in een variabele opgeslagen PK
Set Field [ Seizoen_Lineitems::_FK_Seizoen[ ] ; $pk ]

# Vastleggen record. Heel belangrijk!!!!
Commit Records/Requests [ Skip data entry validation ]

# Weer terug naar de originele layout
Go to Layout [ original layout ]

# Einde script
#

Als je het goed overneemt moet er op jouw scherm helemaal niets flikkeren oid.

 

Je zou ook kunnen starten met een nieuw venster maken en dan aan het einde ipv terug naar de originele layout dat venster weer kunnen sluiten ... net wat je zelf leuker/handiger vind

[martindes]

Dank je wel. Dit werkt prima voor mij.

 

Ik heb inderdaad normalisatie toegepast op de database. Dat had ik al zo goed mogelijk in kaart proberen te brengen voordat ik de database op ben gaan zetten.

 

Ik heb nog een andere vraag op het forum gepost i.v.m. met de fonts in de PDF's. Die zien er moddervet uit en ik heb op di moment geen goede PDF printer in mijn MacOsX EL Capitan systeem.

[andries]

he Menno

 

wat is de rede van je commit [ skip validation ] script step?

[menno]

wat is de rede van je commit [ skip validation ] script step?

Ik heb meerdere keren ervaren dat wanneer je géén commit doet, het record nog niet is weggeschreven en je er niet op kan queriën of een relatie naartoe kan leggen/gebruiken.

 

Je kan op de lay-out instellen dat records automatisch moeten worden ge-commit zodra je die lay-out verlaat. Vergeet je dat of laat je om wat voor reden dan ook het venster met die lay-out open dan krijg je niet altijd het antwoord van de database dat je verwacht als bijvoorbeeld een pk opvraagt en daarmee een relatie wilt leggen. Door standaard te commiten voorkom je dat probleem

[andries]

inderdaad zo gewend om met standaard commit te werken op layouts dat ik dat puntje vergeten was. merci