Relasjoner og enums

En tabell alene lagrer en liste. En applikasjon trenger mer: at kontaktene vet hvilken konto de hører til, at salgsmulighetene vet hvem de tilhører, at et estado-felt bare godtar de statusene som finnes.

Det er de to delene på denne siden: relasjonene, som kobler entiteter til hverandre, og enumene, som lukker settet med mulige verdier for et felt.

#Relasjonene

I modelldiagrammet er hver relasjon en linje mellom to entiteter, med en etikett som sier navnet på veien og kardinaliteten — i Kundehåndtering, conta · 1:N mellom Contas og Contactos, og en tilsvarende mellom Contas og Oportunidades.

En relasjon har alltid to sider:

• Barne-siden (child), som holder referansen — kolonnen conta_id i tabellen contactos.
• Forelder-siden (parent), som det refereres til — kolonnen id i tabellen contas.

#Opprette en relasjon

Relasjonene tegnes i diagrammet, ved å koble et felt til et annet:

1. Hold musen over feltet på barnesiden — linjen svarer med hintet Dra til et felt i en annen tabell for å koble.
2. Dra fra det feltet til feltet på foreldersiden (typisk primærnøkkelen i den andre entiteten) og slipp.
3. Dialogen Ny relasjon åpnes, allerede med de to entitetene og de to kolonnene fylt ut — de kom fra dragingen og kan ikke redigeres der.
4. Fyll ut resten (se nedenfor) og bekreft med Opprett relasjon.

#Kardinaliteten

Det første feltet i dialogen er Kardinalitet — hvor mange på hver side:

Alternativ	Når det brukes
Én-til-mange (1:N)	En konto har flere kontakter. Det vanligste tilfellet.
Mange-til-én (N:1)	Det samme, sett fra den andre siden.
Én-til-én (1:1)	En post for en post — en konto og skattekortet dens.
Mange-til-mange (N:N)	Mange til mange — etiketter på kontoer, kursholdere på kurs. Krever en koblingstabell.

Alt etter hva du velger, viser dialogen Barn (har FK-en) og Forelder (det refereres til) — eller, i N:N-tilfellet, Entitet A og Entitet B.

#Navigatorene

De to neste feltene er navigatorene — hjertet i relasjonen, og det som gjør den nyttig utenfor diagrammet.

En navigator er et virtuelt felt som ikke finnes i databasen: den brukes til å hoppe fra en post til de relaterte postene og til å hente kolonnene fra den andre siden i API-ene. Det er de som gjør at en spørring på kontakter returnerer, sammen med hver kontakt, navnet på kontoen den hører til — uten en ekstra spørring og uten kode.

• Navigator på Contactos → Contas — veien fra barnet til forelderen. Et navn i entall: conta.
• Navigator på Contas → [Contactos] — veien fra forelderen til barna. Et navn i flertall: contactos. Hakeparentesene i etiketten sier at denne siden returnerer en liste.

Å la ett av feltene stå tomt er en legitim beslutning: den siden eksponeres rett og slett ikke. Trenger ingen å gå fra en konto til kontaktene dens, oppretter du ikke veien.

På kortet til entiteten dukker navigatorene opp i seksjonen Navigasjon, med navnet til venstre og målet til høyre — i hakeparenteser når det er en liste.

#Fysisk eller virtuell

Feltet Relasjonstype avgjør om relasjonen også skrives inn i databasen:

Alternativ	Hva den gjør
Virtuell — bare i plattformens modell	Relasjonen finnes for plattformen: navigatorer, API-er, skjermer. Databasen røres ikke.
Fysisk — oppretter FK-en i databasen	I tillegg til modellen opprettes fremmednøkkelen i motoren: det blir motoren selv som nekter en conta_id som ikke finnes.

Den fysiske relasjonen er sikrere — integriteten slutter å avhenge av hvem som skriver. Den virtuelle er det som er igjen når du ikke kan (eller ikke vil) røre skjemaet i databasen: tredjeparts databaser, tabeller som deles med andre systemer, historiske data som ikke ville bestått kontrollen.

#Når forelderen slettes

Når forelderen slettes (ON DELETE) sier hva som skjer med barna når forelderposten slettes:

Alternativ	Hva som skjer
Ingenting (blokkerer hvis det finnes barn)	Slettingen feiler så lenge det finnes barn.
Restrict — blokkerer umiddelbart	Det samme, kontrollert med én gang.
Cascade — sletter barna	Å slette kontoen sletter kontaktene og salgsmulighetene dens.
Set NULL — løsner barna	Barna blir stående uten forelder (kolonnen blir tom). Krever at kolonnen godtar tomt.

I en fysisk relasjon håndheves denne regelen av motoren. I en virtuell relasjon lagres den i modellen og begynner å gjelde hvis relasjonen en dag materialiseres.

#Mange-til-mange

Med Mange-til-mange (N:N) ber dialogen om tre ting til, fordi en slik relasjon trenger en tabell imellom (koblingstabellen), med en referanse til hver side:

Felt	Hva det er
Koblingstabell	Tabellen som knytter de to sammen — for eksempel conta_etiqueta.
Kolonne → A (barn)	Kolonnen i koblingstabellen som peker på den første entiteten.
Kolonne → B (forelder)	Kolonnen i koblingstabellen som peker på den andre.

Koblingstabellen må finnes fra før: opprett den som en hvilken som helst annen (se Tabeller og felt).

#Relasjoner som allerede er ferdige

Når du importerer en tabell inn i modellen, kommer fremmednøklene som allerede finnes i databasen inn av seg selv som relasjoner, med navigatorer foreslått ut fra navnene på tabellene. Det var slik Kundehåndtering ble født med sine to relasjoner — det eneste du må gjøre er å bekrefte om navnene på navigatorene er de du vil lese i resten av appen.

#Fjerne en relasjon

Klikk på relasjonslinjen i diagrammet og bekreft. Spørsmålet er tydelig: Fjerne denne relasjonen fra modellen? — og svaret er det også: relasjonen går ut av plattformens modell, og en fysisk FK som allerede er opprettet i databasen fjernes IKKE. Ville du virkelig fjerne fremmednøkkelen i motoren, gjøres det i databasen.

#Hva de er til for, etterpå

Når relasjonen er laget, dukker den opp overalt:

• I API-ene, som nøstede felt: en spørring på kontakter kan returnere conta { nome, cidade }.
• I datastorene på skjermene, for å bygge master-detalj — kontakttabellen filtrert på id til kontoen som er lastet inn (se Datastorer og data).
• I integriteten i dataene, når relasjonen er fysisk.

#Enumene

En enum er et lukket sett med verdier for et felt: estado på en konto er Aktiv, Suspendert eller Tapt, og ingenting annet. I stedet for å la feltet godta fritekst — og ende opp med «aktiv», «Aktiv», «AKTIV» og «aktivt» i samme kolonne — deklarerer du settet én gang.

#Opprette en enum

Enumen blir til i kolonnen, i det øyeblikket du gir den typen:

1. I dialogen Ny tabell (eller i Rediger struktur) velger du kolonnen.
2. Under Type velger du enum.
3. Feltet Enum-elementer dukker opp. Klikk på Legg til element for hver verdi.
4. Fyll ut de tre kolonnene for hvert element:

Kolonne	Hva det er
Verdi	Verdien som lagres. Bokstaver, sifre og _, med bokstav først — etter konvensjon med store bokstaver: ATIVO, EM_ANALISE.
Etikett	Teksten folk ser: Aktiv, Til vurdering.
Farge	En valgfri farge, brukt av widgetene som fargelegger statuser (Kanban, formateringsreglene).

Hver enum-kolonne har sin egen enum, og navnet på den utledes fra tabellen og kolonnen — kolonnen tipo i tabellen actividades gir enumen ActividadesTipo.

#Endre en enum

Åpne Rediger struktur på tabellen igjen, velg kolonnen og endre Enum-elementer: legge til, endre etiketten, endre fargen, fjerne med ×. Bekreft med Bruk endringene.

Å endre etiketten eller fargen er trygt — det er bare presentasjon. Å endre eller fjerne en verdi er det ikke: postene som allerede hadde den gamle verdien blir stående med en verdi enumen ikke lenger kjenner.

#Hvor enumene dukker opp

Et enum-felt slutter å være fritekst i hele plattformen:

Hvor	Hva som endrer seg
I diagrammet	Feltet vises i kursiv, med navnet på enumen i stedet for typen.
I API-ene	Feltet får en type med faste verdier, og API-et nekter enhver verdi utenfor listen.
I widgeten Nedtrekksliste	Under Kilde for alternativene velger du Enum fra modellen og deretter Enum-felt — alternativene og etikettene kommer fra modellen, og det finnes ingen lister å vedlikeholde to steder.
I Kanban	Under Kilde for kolonnene lager alternativet Enum én kolonne per enum-verdi, med fargene på plass.
I formateringsreglene	Betingelsene sammenlignes med verdiene i enumen.

#Hvorfor ikke…?

• Hvorfor får jeg ikke dratt fra det ene feltet til det andre? Dragingen starter på linjen til feltet på barne-siden og slutter på linjen til feltet på forelder-siden. Drar du hele kortet, flytter du det i diagrammet — ta tak i linjen til feltet.
• Hvorfor returnerer ikke API-et dataene fra den relaterte tabellen? Navigatoren på den siden mangler. En tom navigator er en side som med vilje ikke er eksponert — opprett relasjonen på nytt med navnet fylt ut.
• Hvorfor feilet opprettelsen av den fysiske relasjonen? En fremmednøkkel godtas bare hvis dataene som allerede finnes respekterer den. Finnes det barn som peker på foreldre som ikke finnes, nekter motoren — rydd bort de foreldreløse først, eller opprett relasjonen som virtuell.
• Hvorfor ser jeg fortsatt relasjonen etter at jeg fjernet den? Du fjernet den fra modellen; fremmednøkkelen i databasen ligger der fortsatt, og det er den som kommer tilbake ved ny import.
• Hvorfor viser enum-feltet mitt verdien i stedet for etiketten? Widgeten er ikke koblet til enumen i modellen — i stedet for en fast liste velger du Enum fra modellen og peker på Enum-felt.