Basisprincipes van 4th Dimension Learning

Het 4D-platform — oorspronkelijk 4th Dimension, en nog steeds algemeen bekend onder zijn historische naam — slaat de gegevens van een volledige applicatie op in één enkel gestructureerd gegevensbestand. Inzicht in hoe tabellen in die architectuur passen, vormt de basis voor al het andere dat u gaat bouwen: velden, formulieren, waardelijsten en uiteindelijk de query’s en methoden die een echte zakelijke app aandrijven. In dit gedeelte wordt uitgelegd hoe u uw eerste tabel maakt, de eigenschappen ervan opent en deze de juiste naam geeft, terwijl de redenering achter elke stap wordt toegelicht, zodat u deze met vertrouwen op grotere ontwerpen kunt toepassen.

Belangrijkste punten

• In 4D bevinden alle tabellen zich in één gegevensbestand in plaats van in afzonderlijke bestanden, zoals in FileMaker Pro (FMP). Dit model met één bestand staat centraal in de manier waarop 4D omgaat met back-ups, implementatie en toegang voor meerdere gebruikers.
• Een 4D-database ondersteunt maximaal 256 tabellen, elk met maximaal 2 GB aan gegevens of ongeveer 16 miljoen records.
• U maakt tabellen vanuit het menu Structuur terwijl u zich in de Ontwerpmodus bevindt.
• Om de eigenschappen van een tabel te openen, moet u specifiek dubbelklikken op het tabelnaamgebied — klikken op een andere plek in het structuurvenster zal het eigenschappendialoogvenster niet openen.
• Het venster Tabeleigenschappen heeft drie tabbladen; de standaardwaarden zijn veilig voor een eerste project, en de tabelnaam kan op elk moment worden gewijzigd.
• Naamgevingsconventies zijn belangrijk: kies duidelijke, consistent enkelvoudige of meervoudige namen zoals “Klanten” voordat u er formulieren en relaties op bouwt.

Waarom tabellen belangrijk zijn in het 4D-gegevensmodel

Als u een FileMaker Pro-achtergrond heeft, is de mentale omslag belangrijk. In FMP leefde elke tabel historisch gezien in een eigen bestand en werden relaties tussen bestanden beheerd.

In 4D is de architectuur anders: alle tabellen worden opgeslagen in het enkele gegevensbestand. De structuur (uw ontwerp — tabellen, velden, formulieren, methoden) wordt gescheiden gehouden van de gegevens (de daadwerkelijke records die gebruikers invoeren), maar elke tabel die u definieert, bevindt zich in dat ene gegevensbestand.

Dit ontwerp heeft praktische consequenties die bepalen hoe u werkt:

• Back-ups zijn eenvoudiger. Omdat de gegevens gecentraliseerd zijn, maakt u een back-up van één gegevensbestand in plaats van dat u er meerdere moet bijhouden.
• Implementatie is overzichtelijker. U levert een structuur en een gegevensbestand, geen map vol onderling afhankelijke documenten.
• Toegang voor meerdere gebruikers is ingebouwd. 4D Server beheert gelijktijdige toegang tot dat ene gegevensbestand, zodat u zelf geen bestandsvergrendelingsschema’s hoeft te ontwerpen.

De tegenprestatie is dat het gegevensbestand het enige groeipunt wordt. Dat is precies de reden waarom 4D limieten per tabel oplegt: tot 256 tabellen, elk met een maximum van 2 GB of ongeveer 16 miljoen records.

Voor de meeste zakelijke apps voor kleine teams en afdelingen zijn deze plafonds genereus. Maar als u iets ontwerpt dat miljoenen transactierijen zal verzamelen, moet u al vroeg nadenken over de manier waarop u gegevens over tabellen verdeelt en of u oudere records moet archiveren.

Gerelateerd: Airtable — Een spreadsheet-eenvoudige interface bovenop een echte relationele database, met automatiseringen, weergaven en deelbare interfaces..

Stap voor stap een tabel maken

Voor deze walkthrough maken we slechts één tabel, waardoor de voorbeelddatabase gemakkelijk te volgen is. Dezelfde procedure is schaalbaar naar veel tabellen.

1. Ga naar de Ontwerpmodus. Het maken van tabellen is een structurele wijziging, dus u moet zich in de Ontwerpmodus bevinden. U kunt geen tabellen toevoegen terwijl de applicatie in de gebruikersmodus wordt uitgevoerd.
2. Open het menu Structuur. Selecteer in de menubalk het menu Structuur.
3. Kies “Nieuwe tabel”. Dit menu-item voegt een nieuwe, lege tabel toe aan uw structuur.
4. Zoek de nieuwe tabel in het structuurvenster. Het venster Structuur voor Voorbeelddatabase (Afbeelding 6 in de originele walkthrough) geeft uw tabellen weer. Een nieuw gemaakte tabel verschijnt als een naamloos item.
5. Dubbelklik op het tabelnaamgebied. Hierdoor wordt het venster Tabeleigenschappen geopend (Afbeelding 7).

Bij die laatste stap is een waarschuwing nodig die het waard is om te herhalen, omdat nieuwkomers hier vaak door in de war raken: u moet op het tabelnaamgebied klikken en niet ergens anders. Het structuurvenster bevat verschillende regio’s, en alleen het naamgebied reageert door het dialoogvenster Tabeleigenschappen te openen. Als er niets gebeurt wanneer u dubbelklikt, klikt u vrijwel zeker op de verkeerde plek — verplaats uw cursor rechtstreeks naar de naam van de tabel en probeer het opnieuw.

Het venster Tabeleigenschappen begrijpen

Wanneer het venster Tabeleigenschappen wordt geopend, ziet u drie tabbladen. De oorspronkelijke richtlijn is om ze voorlopig op de standaardwaarden te laten staan, en dat is een goed advies voor een eerste project — maar het helpt om te weten wat u uitstelt.

Als u aan het winkelen bent: Zoho Creator — Een low-code app-bouwer die aansluit op de bredere Zoho-suite en prijzen per gebruiker in plaats van per app..

• Het veld Tabelnaam blijft zichtbaar op elk tabblad. Dit is een bewuste ontwerpkeuze: welk tabblad u ook bekijkt, u kunt de naam van de tabel wijzigen. U kunt de naam op elk moment wijzigen, dus een naam is nooit permanent.
• De andere tabbladen bepalen het structurele gedrag — zaken zoals hoe de tabel deelneemt aan de bredere database en hoe de records worden beheerd. Voor een voorbeeld met één tabel hoeft geen van deze aanpassingen te worden gedaan.

De belangrijke gewoonte die hier moet worden opgebouwd, is terughoudendheid. Nieuwe ontwikkelaars openen vaak een eigenschappendialoogvenster en beginnen opties aan of uit te vinken voordat ze begrijpen wat elke optie doet. In 4D is, net als bij de meeste relationele databaseontwerpen, de veiligste weg om standaardinstellingen te accepteren, een werkende tabel te krijgen en geavanceerde instellingen pas opnieuw te bekijken wanneer een concrete vereiste u daartoe dwingt.

Een opmerking over naamgeving

Noem voor de Voorbeelddatabase de eerste tabel “Klanten”. Dit is een kleine beslissing met grote gevolgen voor het verdere proces:

• Wees consistent wat betreft het getal. Als u deze tabel “Klanten” noemt, noem dan de volgende “Bestellingen” en “Producten” — niet “Bestelling” en “Product”. Consistentie maakt relaties en code veel gemakkelijker te lezen.
• Vermijd spaties en speciale tekens waar mogelijk, aangezien tabelnamen vaak voorkomen in code en in gegenereerde query’s.
• Geef namen op basis van de entiteit, niet het scherm. “Klanten” beschrijft een ding; “CustomerEntryScreen” beschrijft een formulier. Houd die concepten gescheiden.

Nadat u de naam heeft getypt, klikt u op Toepassen en sluit u het venster met het vak linksboven of de knop Gereed. Uw tabel bestaat nu in de structuur en is klaar om velden te ontvangen.

Hoe tabellen passen bij de rest van de database

Een tabel is slechts de container. De rest van uw applicatie bouwt er in een duidelijke volgorde op voort, en het is de moeite waard om het hele plaatje te bekijken voordat u verdergaat:

• Gegevensvelden definiëren de kolommen — de feitelijke kenmerken die u opslaat, zoals de naam, het adres of het rekeningnummer van een klant.
• Formulieren zijn de gebruikersinterface: de schermen waarop mensen records bekijken en bewerken.
• Waardelijsten (keuzelijsten) beperken en versnellen de gegevensinvoer door vooraf gedefinieerde opties aan te bieden.
• Voorbeeldgegevens laten u formulieren en lijsten testen met realistische inhoud voordat u live gaat.

Elk van deze hangt af van het feit dat de tabel eerst bestaat. Dit is de reden waarom de ontwerpworkflow van 4D opzettelijk is geordend: structuur vóór interface, interface vóór gegevens. Als u probeert een formulier te bouwen voordat de onderliggende velden bestaan, heeft u simpelweg niets waaraan u zich kunt binden.

Het verklaart ook waarom het model met één gegevensbestand zo belangrijk is. Omdat elke tabel, elk veld en elk record zich in één gecoördineerde structuur bevindt, kan 4D relaties en referentiële integriteit in uw hele applicatie afdwingen zonder dat u externe bestanden hoeft te beheren.

Gerelateerd: Knack — Een databasebouwer zonder code, gericht op portals, directory's en interne tools, met vaste prijzen in plaats van kosten per gebruiker..

Dat is hetzelfde principe achter relationele databasebeheersystemen in het algemeen — het concept geformaliseerd in het relationele model van E. F. Codd en nu standaard in producten als Oracle Database, Microsoft SQL Server en PostgreSQL. 4D past dat relationele denken toe binnen een op zichzelf staand applicatiebestand, wat het toegankelijk maakt voor kleine teams en citizen developers.

Praktische richtlijnen voor schalen buiten één tabel

Het voorbeeld gebruikt voor de duidelijkheid één enkele tabel, maar echte apps stoppen daar zelden. Houd bij het toevoegen van tabellen rekening met deze criteria:

Overweging	Wat te controleren	Waarom het ertoe doet
Aantal tabellen	Blijf ruim onder de limiet van 256 tabellen	Laat ruimte over en houdt de structuur navigeerbaar
Grootte per tabel	Let op het plafond van 2 GB / ~16 miljoen records	Grote transactietabellen moeten mogelijk worden gearchiveerd of gesplitst
Naamgeving	Consistent, op entiteiten gebaseerd, geen verdwaalde tekens	Beïnvloedt de leesbaarheid van code en de duidelijkheid van relaties
Relaties	Definieer bewust koppelingen tussen tabellen	Voorkomt verweesde of dubbele gegevens
Groeiplan	Bepaal vroeg wat er wordt gearchiveerd	Beschermt de prestaties naarmate gegevens zich ophopen

Een handige vuistregel: modelleer één tabel per reële entiteit (klanten, bestellingen, producten, facturen) en verbind ze vervolgens met relaties in plaats van alles in één brede tabel te proppen. Dit weerspiegelt de normalisatieprincipes die in de meeste databasecurricula worden onderwezen en zorgt ervoor dat uw 4D-structuur onderhoudbaar blijft naarmate de app groeit.

Onze keuze: Claris FileMaker Pro — Het langlopende relationele databaseplatform voor teams die aangepaste apps nodig hebben op desktop, internet en mobiel vanuit één bestand..

Veelvoorkomende fouten om te vermijden

• Klikken op het verkeerde gebied in het structuurvenster. Alleen het gebied van de tabelnaam opent de Tabeleigenschappen. Dit is het meest voorkomende struikelblok in deze stap.
• Tabellen laat hernoemen zonder de afhankelijkheden te controleren. U kunt de naam op elk gewenst moment wijzigen, maar als formulieren, methoden of relaties al naar de oude naam verwijzen, moet u deze bijwerken.
• De groottelimieten negeren totdat het te laat is. De limiet van 2 GB / 16 miljoen records per tabel is genereus maar eindig. Plan archivering voor tabellen met een hoog volume.
• Formulieren bouwen vóór velden. De volgorde van de workflow bestaat om een reden — definieer eerst de structuur.
• Eigenschappen op de eerste dag te veel aanpassen. Standaardinstellingen zijn er om u op weg te helpen. Wijzig ze wanneer een vereiste dit vraagt, niet ervoor.

Veelgestelde vragen

Hoeveel tabellen kan een 4D-database bevatten?

Een 4D-database ondersteunt maximaal 256 tabellen. Elke tabel kan maximaal 2 GB aan gegevens bevatten, of ongeveer 16 miljoen records. Voor de meeste afdelings- en kleine teamtoepassingen zijn deze limieten meer dan voldoende, maar bij ontwerpen met een hoog volume moet er rekening worden gehouden met archivering.

Waarom kan ik het venster Tabeleigenschappen niet openen?

U klikt vrijwel zeker op het verkeerde gedeelte van het structuurvenster. Het dialoogvenster Tabeleigenschappen wordt alleen geopend als u rechtstreeks dubbelklikt op het gebied van de tabelnaam. Als u ergens anders in het venster klikt, gebeurt er niets; plaats uw cursor dus op de naam van de tabel en probeer het opnieuw.

Kan ik de naam van een tabel wijzigen nadat deze is gemaakt?

Ja. Het veld Tabelnaam blijft zichtbaar op alle drie de tabbladen van het venster Tabeleigenschappen, zodat u de naam op elk gewenst moment kunt wijzigen. Onthoud alleen dat als formulieren, methoden of relaties al naar de oude naam verwijzen, u die verwijzingen moet bijwerken.

Moet ik een van de tabbladen Tabeleigenschappen wijzigen?

Niet voor een eerste project. De oorspronkelijke walkthrough adviseert om de standaardinstellingen te laten staan, en dat is een goede gewoonte. De drie tabbladen beheren structureel gedrag dat u pas nodig zult hebben als een specifieke vereiste u dwingt om ze opnieuw te bekijken.

Waarin verschilt een 4D-tabel van een FileMaker Pro-bestand?

In FileMaker Pro stonden tabellen van oudsher in afzonderlijke bestanden. In 4D worden alle tabellen opgeslagen in één enkel gegevensbestand, wat de back-up, implementatie en toegang voor meerdere gebruikers centraliseert. Dit is het belangrijkste architectonische verschil om te internaliseren bij het overstappen tussen de twee platforms.

Hoe moet ik mijn eerste tabel noemen?

Voor de voorbeelddatabase noemt u deze “Customers”. Kies in het algemeen namen op basis van entiteiten, houd het meervoud consistent over de tabellen heen en vermijd spaties of speciale tekens, aangezien tabelnamen vaak voorkomen in code en gegenereerde query’s.

Hoe nu verder

Nu uw eerste tabel is gemaakt en benoemd, beschikt u over de container die uw applicatie nodig heeft. De volgende stap is het definiëren van gegevensvelden — de kolommen die de tabel zijn inhoud geven.

Van daaruit bouwt u formulieren voor de interface, koppelt u waardelijsten om de gegevensinvoer te versnellen, en tenslotte voert u voorbeeldgegevens in om alles van begin tot eind te testen. Elke fase bouwt rechtstreeks voort op de tabel die u zojuist hebt gemaakt, dus neem even de tijd om te controleren of deze correct wordt weergegeven in het structuurvenster voordat u verdergaat.