Relationer och enums

En ensam tabell sparar en lista. En applikation behöver mer: att kontakterna vet vilket konto de tillhör, att affärsmöjligheterna vet vems de är, att ett status-fält bara tar emot de statusar som finns.

Det är den här sidans två delar: relationerna, som kopplar entiteter till varandra, och enums, som stänger uppsättningen möjliga värden i ett fält.

#Relationerna

I modelldiagrammet är varje relation en linje mellan två entiteter, med en etikett som anger vägens namn och kardinaliteten — i Kundhantering, conta · 1:N mellan Contas och Contactos, och en likadan mellan Contas och Oportunidades.

En relation har alltid två sidor:

• Barnsidan (child), som håller referensen — kolumnen conta_id i tabellen contactos.
• Föräldersidan (parent), som refereras — kolumnen id i tabellen contas.

#Skapa en relation

Relationer ritas i diagrammet genom att koppla ett fält till ett annat:

1. Hovra över fältet på barnsidan — raden svarar med tipset Dra till ett fält i en annan tabell för att koppla.
2. Dra från det fältet till fältet på föräldersidan (vanligtvis den andra entitetens primärnyckel) och släpp.
3. Dialogen Ny relation öppnas, redan med de två entiteterna och de två kolumnerna ifyllda — de kom från dragningen och går inte att ändra där.
4. Fyll i resten (härnäst) och bekräfta med Skapa relation.

#Kardinaliteten

Dialogens första fält är Kardinalitet — hur många på varje sida:

Alternativ	När det används
One-to-many (1:N)	Ett konto har flera kontakter. Det vanligaste fallet.
Many-to-one (N:1)	Detsamma, sett från andra hållet.
One-to-one (1:1)	En post till en post — ett konto och dess skatteuppgifter.
Many-to-many (N:N)	Många till många — etiketter på konton, lärare på kurser. Kräver en kopplingstabell.

Beroende på valet visar dialogen Child (har FK:n) och Parent (refererad) — eller, i N:N-fallet, Entitet A och Entitet B.

#Navigatorerna

De två följande fälten är navigatorerna — relationens hjärta, och det som gör den användbar utanför diagrammet.

En navigator är ett virtuellt fält som inte finns i databasen: det tjänar till att hoppa från en post till de relaterade posterna och till att hämta den andra sidans kolumner i API:erna. Det är de som gör att en fråga på kontakter returnerar, tillsammans med varje kontakt, namnet på kontot den tillhör — utan en andra fråga och utan kod.

• Navigator på Contactos → Contas — vägen från barnet till föräldern. Ett namn i singular: conta.
• Navigator på Contas → [Contactos] — vägen från föräldern till barnen. Ett namn i plural: contactos. Hakparenteserna i etiketten säger att den här sidan returnerar en lista.

Att lämna ett av fälten tomt är ett giltigt beslut: den sidan exponeras helt enkelt inte. Om ingen behöver gå från ett konto till dess kontakter skapar du inte den vägen.

På entitetens kort dyker navigatorerna upp i avsnittet Navigering, med namnet till vänster och målet till höger — inom hakparenteser när det är en lista.

#Fysisk eller virtuell

Fältet Typ av relation avgör om relationen också skrivs in i databasen:

Alternativ	Vad det gör
Virtuell — bara i plattformens modell	Relationen finns för plattformen: navigatorer, API:er, skärmar. Databasen rörs inte.
Fysisk — skapar FK:n i databasen	Utöver modellen skapas främmande nyckeln i motorn: det blir motorn själv som vägrar ett conta_id som inte finns.

Den fysiska relationen är säkrare — integriteten slutar bero på den som skriver. Den virtuella är det som återstår när man inte kan (eller inte vill) röra databasens schema: tredjepartsdatabaser, tabeller som delas med andra system, historiska data som inte skulle klara kontrollen.

#När föräldern tas bort

När föräldern tas bort (ON DELETE) säger vad som händer med barnen när föräldraposten raderas:

Alternativ	Vad som händer
Ingenting (blockerar om det finns barn)	Borttagningen misslyckas så länge det finns barn.
Restrict — blockerar direkt	Detsamma, kontrollerat med en gång.
Cascade — tar bort barnen	Att radera kontot raderar dess kontakter och affärsmöjligheter.
Set NULL — släpper barnen	Barnen blir utan förälder (kolumnen blir tom). Kräver att kolumnen tar emot tomt värde.

I en fysisk relation tillämpas den här regeln av motorn. I en virtuell relation sparas den i modellen och börjar gälla om relationen en dag materialiseras.

#Många-till-många

Med Many-to-many (N:N) ber dialogen om tre saker till, eftersom en sådan relation behöver en tabell emellan (kopplingstabellen), med en referens till varje sida:

Fält	Vad det är
Kopplingstabell	Tabellen som kopplar ihop de två — till exempel conta_etiqueta.
Kolumn → A (child)	Kolumnen i kopplingen som pekar på den första entiteten.
Kolumn → B (parent)	Kolumnen i kopplingen som pekar på den andra.

Kopplingstabellen måste finnas innan: skapa den som vilken annan som helst (se Tabeller och fält).

#Relationer som redan är gjorda

När du importerar en tabell till modellen kommer de främmande nycklar som redan finns i databasen in av sig själva som relationer, med navigatorer föreslagna utifrån tabellernas namn. Det var så Kundhantering föddes med sina två relationer — du behöver bara kontrollera om navigatorernas namn är de du vill läsa i resten av appen.

#Ta bort en relation

Klicka på relationens linje i diagrammet och bekräfta. Frågan är tydlig: Ta bort den här relationen från modellen? — och svaret också: relationen försvinner ur plattformens modell och en fysisk FK som redan skapats i databasen tas INTE bort. Om du verkligen ville göra den främmande nyckeln ogjord i motorn gör du det i databasen.

#Vad de sedan används till

När relationen är gjord dyker den upp överallt:

• I API:erna, som nästlade fält: en fråga på kontakter kan returnera conta { nome, cidade }.
• I skärmarnas datastorer, för att bygga master–detalj — kontakttabellen filtrerad på id för det laddade kontot (se Datastorer och data).
• I dataintegriteten, när relationen är fysisk.

#Enums

En enum är en sluten uppsättning värden för ett fält: ett kontos estado är Aktivt, Vilande eller Förlorat, och inget annat. I stället för att låta fältet ta emot fri text — och sluta med ”aktivt”, ”Aktivt”, ”AKTIVT” och ”aktiv” i samma kolumn — deklarerar du uppsättningen en gång.

#Skapa en enum

Enumen föds i kolumnen, i samma stund som du ger den typen:

1. Välj kolumnen i dialogen Ny tabell (eller i Redigera struktur).
2. Välj enum under Typ.
3. Rutan Enum-alternativ dyker upp. Klicka på Lägg till post för varje värde.
4. Fyll i varje posts tre kolumner:

Kolumn	Vad det är
Värde	Värdet som sparas. Bokstäver, siffror och _, med en bokstav först — som konvention i versaler: ATIVO, EM_ANALISE.
Etikett	Texten som människor ser: Aktivt, Under granskning.
Färg	En valfri färg, som används av de widgetar som färglägger statusar (Kanban, formateringsreglerna).

Varje enum-kolumn har sin egen enum, och dess namn härleds från tabellen och kolumnen — kolumnen tipo i tabellen actividades ger enumen ActividadesTipo.

#Ändra en enum

Öppna Redigera struktur på tabellen igen, välj kolumnen och pilla på Enum-alternativ: lägga till, byta etikett, byta färg, ta bort med ×. Bekräfta med Tillämpa ändringar.

Att ändra etikett eller färg är riskfritt — det är bara presentation. Att ändra eller ta bort ett värde är det inte: posterna som redan hade det gamla värdet blir kvar med ett värde som enumen inte längre känner till.

#Var enums dyker upp

Ett enum-fält slutar vara fri text i hela plattformen:

Var	Vad som ändras
I diagrammet	Fältet visas i kursiv stil, med enumens namn i stället för typen.
I API:erna	Fältet får en typ med fasta värden, och API:et vägrar alla värden utanför listan.
I widgeten Listruta	Under Alternativens källa väljer du Enum från modellen och sedan Enum-fält — alternativen och etiketterna kommer från modellen, och det finns inga listor att underhålla på två ställen.
I Kanban	Under Kolumnernas källa skapar alternativet Enum en kolumn per enum-värde, färgerna inkluderade.
I formateringsreglerna	Villkoren jämför med enumens värden.

#Varför inte…?

• Varför går det inte att dra från ett fält till ett annat? Dragningen börjar på raden för fältet på barnsidan och slutar på raden för fältet på föräldersidan. Om du drar hela kortet flyttar du det i diagrammet — ta tag i fältets rad.
• Varför returnerar API:et inte data från den relaterade tabellen? Navigatorn på den sidan saknas. En tom navigator är en sida som med flit inte har exponerats — skapa relationen på nytt med namnet ifyllt.
• Varför misslyckades skapandet av den fysiska relationen? En främmande nyckel accepteras bara om befintliga data respekterar den. Om det finns barn som pekar på föräldrar som inte finns vägrar motorn — städa bort de föräldralösa först, eller skapa relationen som virtuell.
• Varför ser jag relationen kvar efter att jag tagit bort den? Du tog bort den ur modellen; den främmande nyckeln i databasen ligger kvar, och det är den som en ny import tar med sig tillbaka.
• Varför visar mitt enum-fält värdet i stället för etiketten? Widgeten är inte kopplad till modellens enum — välj Enum från modellen i stället för en fast lista och peka ut Enum-fält.