Relaties en enums

Een tabel op zichzelf bewaart een lijst. Een applicatie heeft meer nodig: dat de contactpersonen weten bij welke account ze horen, dat de kansen weten van wie ze zijn, dat een veld status alleen de statussen aanvaardt die bestaan.

Dat zijn de twee stukken van deze pagina: de relaties, die entiteiten aan elkaar koppelen, en de enums, die de verzameling mogelijke waarden van een veld afsluiten.

#De relaties

In het modeldiagram is elke relatie een lijn tussen twee entiteiten, met een label dat de naam van het pad en de cardinaliteit noemt — in Klantenbeheer conta · 1:N tussen Contas en Contactos, en eenzelfde lijn tussen Contas en Oportunidades.

Een relatie heeft altijd twee kanten:

• De kant van het kind (child), die de verwijzing bewaart — de kolom conta_id van de tabel contactos.
• De kant van de ouder (parent), waarnaar verwezen wordt — de kolom id van de tabel contas.

#Een relatie aanmaken

Relaties tekent u in het diagram, door het ene veld met het andere te verbinden:

1. Ga met de muis over het veld aan de kant van het kind — de regel antwoordt met de tip Sleep naar een veld van een andere tabel om te koppelen.
2. Sleep van dat veld naar het veld aan de kant van de ouder (meestal de primaire sleutel van de andere entiteit) en laat los.
3. Het venster Nieuwe relatie gaat open, met de twee entiteiten en de twee kolommen al ingevuld — die komen uit het slepen en zijn daar niet te bewerken.
4. Vul de rest in (hierna) en bevestig met Relatie aanmaken.

#De cardinaliteit

Het eerste veld van het venster is de Cardinaliteit — hoeveel er aan elke kant staan:

Optie	Wanneer u die gebruikt
One-to-many (1:N)	Eén account heeft meerdere contactpersonen. Dit is het meest voorkomende geval.
Many-to-one (N:1)	Hetzelfde, van de andere kant bekeken.
One-to-one (1:1)	Eén record voor één record — een account en haar fiscale gegevens.
Many-to-many (N:N)	Velen op velen — labels op accounts, docenten op cursussen. Vereist een koppeltabel.

Afhankelijk van de keuze toont het venster Child (heeft de FK) en Parent (waarnaar verwezen wordt) — of, in het geval N:N, Entiteit A en Entiteit B.

#De navigators

De twee volgende velden zijn de navigators — het hart van de relatie, en wat haar buiten het diagram bruikbaar maakt.

Een navigator is een virtueel veld dat niet in de database bestaat: het dient om van het ene record naar de verwante records te springen en om de kolommen van de andere kant in de API's op te halen. Zij zorgen ervoor dat een zoekopdracht op contactpersonen bij elke contactpersoon ook de naam teruggeeft van de account waar hij bij hoort — zonder tweede zoekopdracht en zonder code.

• Navigator op Contactos → Contas — het pad van het kind naar de ouder. Een naam in het enkelvoud: conta.
• Navigator op Contas → [Contactos] — het pad van de ouder naar de kinderen. Een naam in het meervoud: contactos. De rechte haken in het label zeggen dat deze kant een lijst teruggeeft.

Een van de velden leeg laten is een legitieme beslissing: die kant wordt dan eenvoudigweg niet beschikbaar gesteld. Als niemand van een account naar haar contactpersonen hoeft te gaan, maakt u dat pad niet aan.

Op de kaart van de entiteit verschijnen de navigators in de sectie Navigatie, met de naam links en de bestemming rechts — tussen rechte haken wanneer het om een lijst gaat.

#Fysiek of virtueel

Het veld Type relatie bepaalt of de relatie ook in de database wordt geschreven:

Optie	Wat het doet
Virtueel — alleen in het model van het platform	De relatie bestaat voor het platform: navigators, API's, schermen. De database wordt niet aangeraakt.
Fysiek — maakt de FK aan in de database	Naast het model wordt de foreign key in de engine aangemaakt: het is dan de engine zelf die een conta_id weigert die niet bestaat.

De fysieke relatie is veiliger — de integriteit hangt niet langer af van wie schrijft. De virtuele is wat overblijft wanneer u niet aan het schema van de database kunt (of wilt) komen: databases van derden, tabellen die met andere systemen gedeeld worden, historische gegevens die de controle niet zouden doorstaan.

#Bij het verwijderen van de ouder

Bij het verwijderen van de parent (ON DELETE) zegt wat er met de kinderen gebeurt wanneer het ouderrecord verwijderd wordt:

Optie	Wat er gebeurt
Niets (blokkeert als er children zijn)	Het verwijderen mislukt zolang er kinderen zijn.
Restrict — blokkeert onmiddellijk	Hetzelfde, meteen gecontroleerd.
Cascade — verwijdert de children	De account verwijderen verwijdert haar contactpersonen en kansen.
Set NULL — maakt de children los	De kinderen blijven zonder ouder achter (de kolom wordt leeg). Vereist dat de kolom leeg mag zijn.

In een fysieke relatie wordt deze regel door de engine toegepast. In een virtuele relatie blijft zij in het model bewaard en gaat zij gelden als de relatie ooit gematerialiseerd wordt.

#Veel-op-veel

Met Many-to-many (N:N) vraagt het venster nog drie dingen, omdat zo'n relatie een tabel in het midden nodig heeft (de koppeltabel), met één verwijzing naar elke kant:

Veld	Wat het is
Koppeltabel	De tabel die de twee verbindt — bijvoorbeeld conta_etiqueta.
Kolom → A (child)	De kolom van de koppeltabel die naar de eerste entiteit wijst.
Kolom → B (parent)	De kolom van de koppeltabel die naar de tweede wijst.

De koppeltabel moet eerst bestaan: maak haar aan zoals elke andere (zie Tabellen en velden).

#Relaties die kant-en-klaar meekomen

Bij het importeren van een tabel in het model komen de foreign keys die al in de database bestaan er vanzelf bij als relaties, met navigators die op basis van de tabelnamen worden voorgesteld. Zo is Klantenbeheer met haar twee relaties geboren — u hoeft alleen te bevestigen of de namen van de navigators de namen zijn die u in de rest van de app wilt lezen.

#Een relatie verwijderen

Klik op de lijn van de relatie in het diagram en bevestig. De vraag is expliciet: Deze relatie uit het model verwijderen? — en het antwoord ook: de relatie gaat uit het model van het platform en een fysieke FK die al in de database is aangemaakt, wordt NIET verwijderd. Wilde u de foreign key in de engine echt ongedaan maken, dan doet u dat in de database.

#Waar ze daarna voor dienen

Eenmaal aangemaakt duikt de relatie overal op:

• In de API's, als geneste velden: een zoekopdracht op contactpersonen kan conta { nome, cidade } teruggeven.
• In de datastores van de schermen, om master-detail te bouwen — de tabel met contactpersonen gefilterd op de id van de geladen account (zie Datastores en gegevens).
• In de integriteit van de gegevens, wanneer de relatie fysiek is.

#De enums

Een enum is een gesloten verzameling waarden voor een veld: de estado van een account is Actief, Opgeschort of Verloren, en niets anders. In plaats van het veld vrije tekst te laten aanvaarden — en te eindigen met "actief", "Actief", "ACTIEF" en "aktief" in dezelfde kolom — declareert u de verzameling één keer.

#Een enum aanmaken

De enum ontstaat op de kolom, op het moment dat u haar het type geeft:

1. Selecteer de kolom in het venster Nieuwe tabel (of in Structuur bewerken).
2. Kies bij Type het type enum.
3. Het vak Items van de enum verschijnt. Klik op Item toevoegen voor elke waarde.
4. Vul de drie kolommen van elk item in:

Kolom	Wat het is
Waarde	De bewaarde waarde. Letters, cijfers en _, beginnend met een letter — bij conventie in hoofdletters: ACTIEF, IN_BEHANDELING.
Label	De tekst die mensen zien: Actief, In behandeling.
Kleur	Een optionele kleur, gebruikt door de widgets die statussen kleuren (het Kanban, de opmaakregels).

Elke enum-kolom heeft haar eigen enum, en de naam daarvan is afgeleid van de tabel en de kolom — de kolom tipo van de tabel actividades geeft de enum ActividadesTipo.

#Een enum wijzigen

Open Structuur bewerken opnieuw op de tabel, selecteer de kolom en werk aan de Items van de enum: toevoegen, het label wijzigen, de kleur wijzigen, verwijderen met de ×. Bevestig met Wijzigingen toepassen.

Het label of de kleur wijzigen is veilig — dat is alleen presentatie. Een waarde wijzigen of verwijderen is dat niet: de records die de oude waarde al hadden, blijven achter met een waarde die de enum niet meer kent.

#Waar de enums opduiken

Een enum-veld houdt in het hele platform op vrije tekst te zijn:

Waar	Wat er verandert
In het diagram	Het veld verschijnt cursief, met de naam van de enum in plaats van het type.
In de API's	Het veld krijgt een type met vaste waarden, en de API weigert elke waarde buiten de lijst.
In de widget Keuzelijst	Bij Bron van de opties kiest u Enum uit het model en daarna het Enum-veld — de opties en de labels komen uit het model, en er zijn geen lijsten die u op twee plekken moet bijhouden.
In het Kanban	Bij Bron van de kolommen maakt de optie Enum één kolom per enum-waarde aan, meteen met de kleuren.
In de opmaakregels	De voorwaarden vergelijken met de waarden van de enum.

#Waarom niet…?

• Waarom lukt het slepen van het ene veld naar het andere niet? Het slepen begint op de regel van het veld aan de kant van het kind en eindigt op de regel van het veld aan de kant van de ouder. Sleept u de hele kaart, dan verplaatst u die in het diagram — pak de regel van het veld.
• Waarom geeft de API de gegevens van de verwante tabel niet terug? De navigator van die kant ontbreekt. Een lege navigator is een kant die met opzet niet beschikbaar is gesteld — maak de relatie opnieuw aan met de naam ingevuld.
• Waarom is het aanmaken van de fysieke relatie mislukt? Een foreign key wordt alleen aanvaard als de bestaande gegevens haar respecteren. Wijzen er kinderen naar ouders die niet bestaan, dan weigert de engine — ruim eerst de wezen op, of maak de relatie als virtueel aan.
• Waarom zie ik de relatie nog steeds nadat ik haar verwijderd heb? U hebt haar uit het model verwijderd; de foreign key in de database staat er nog en is wat het opnieuw importeren weer meebrengt.
• Waarom toont mijn enum-veld de waarde in plaats van het label? De widget is niet aan de enum van het model gekoppeld — kies in plaats van een vaste lijst Enum uit het model en wijs het Enum-veld aan.