Planera en relaterad databas

Innan du skapar en relaterad databas med relationsdiagrammet designar du din databas på papper eller på skärmen. I databastermer kallas planen som du utvecklar för ett enhetssambandsdiagram.

Information om allmänna steg för att designa en anpassad app i FileMaker Pro finns i Skapa en anpassad app.

Så här planerar du en relaterad databas:

  1. Bestäm vilka kategorier av information som den relaterade databasen kommer att behöva. De här kategorierna kommer att vara tabeller i FileMaker Pro.

    Till exempel kan en försäljningsdatabas omfatta de här tabellerna: Kunder som innehåller kundinformation, Fakturor som innehåller orderinformation samt Produkter som innehåller produktinformation.

  2.  

    Tabellerna Kunder, Fakturor och Produkter

  3. Bestäm hur tabellerna är relaterade till varandra. Det kan du göra genom att skriva enkla meningar som beskriver hur kategorierna samverkar, exempelvis "kunder beställer produkter" och "fakturor spårar kunders beställningar".
  4. Anslut en tabell till en annan för att indikera en relation mellan dem. Till exempel kan kunder ha fakturor och fakturor kan ha produkter.

    Om en tabell inte har någon relation till en annan tabell är den förmodligen överflödig. I det här exemplet passar tabellen Personal inte in i relationsdatabasen.

  5.  

    Tre tabeller med relationer till varandra där tabellen Personal har utelämnats

  6. Indikera typen av relation mellan tabeller genom att ansluta dem med en representerande symbol.
    • I en relation av typen en-till-en matchas en post i Tabell A med en post i Tabell B.
    • I en relation av typen en-till-många matchas en post i Tabell A med många poster i Tabell B.
    • I en relation av typen många-till-många matchas många poster i Tabell A med många poster i Tabell B.

    Mer information finns i Om relationer.

  7.  

    Tre tabeller med relationer till varandra

    Detta exempel visar att:

    • en kund kan ha flera fakturor
    • en produkt kan visas på många fakturor
    • en faktura kan ha många produkter
  8. Obs! Det finns en relation av typen många-till-många mellan Fakturor och Produkter. Du kan inte skapa en relation av typen många-till-många direkt mellan två tabeller.

    Relaterade databaser hanterar relationer av typerna en-till-en och en-till-många direkt. Du måste lösa relationen av typen många-till-många genom att använda en mellanliggande tabell som bryter upp relationen av typen många-till-många i två relationer av typen en-till-många. För att lösa problemet i det här exemplet lägger du till den mellanliggande tabellen Radposter för att lagra information om sålda produkter.

  9.  

    Justerade relationer med tabellen Radposter som kopplingstabell

    När relationen av typen många-till-många har lösts visar det här exemplet att:

    • en kund kan ha flera fakturor
    • en faktura kan ha många radobjekt
    • en produkt kan visas på många radobjekt
  10. Bestäm vilka fält som respektive tabell behöver.

    Varje tabell har bara ett ämne och alla fält i en tabell beskriver bara det ämnet. I fälten i en post i tabellen Kunder lagras t.ex. all information om en kund.

    Av samma skäl bör du tilldela varje kund ett unikt identifieringsnummer. I din databas är det här en primärnyckel. Du lägger endast till ett kundidentifieringsnummer i tabellen om en ny kund ska läggas till och ett KundID är därför avgörande för att en post ska existera. Kundtabellen kan även ha fält för kundens namn, adress och telefonnummer.

    En produkttabell kan ha fält för ett produktidentifieringsnummer, styckepris för varje produkt samt antal enheter på lager. En radposttabell kan ha fält för produkt- och fakturaidentifieringsnummer samt namn, styckepris, antal och totalpris för varje såld produkt. En fakturatabell kan ha fält för fakturaidentifieringsnummer, orderdatum och säljare.

  11.  

    Fält som anges i varje tabell

  12. Bestäm primärnyckelfältet (eller flera fält för en relation med flera villkor) för varje tabell och indikera samtliga i din plan. Indikera sedan det främmande nyckelfältet/de främmande nyckelfälten i varje tabell.

    I detta exempel:

    • primärnycklarna är Kunder::KundID, Fakturor::FakturaID, Produkter::ProduktID, samt Radposter::ObjektID
    • de främmande nycklarna är Fakturor::KundID och Radposter::ProduktID
  13. Om du vill visa kunddata i tabellen Fakturor måste du ha ett gemensamt fält i de två tabellerna för att skapa en relation. KundID är det gemensamma fältet. I tabellen Kunder är det primärnyckeln, och i tabellen Fakturor är det den främmande nyckeln.

    I tabellen Radposter är ProduktID det gemensamma fältet mellan tabellerna Radposter och Produkter. I tabellen Produkter är det här fältet primärnyckeln, och i tabellen Radposter är det den främmande nyckeln.

    De här nyckelfälten är en typ av matchande fält. Mer information finns i Om relationer.

     

    Nyckelfält har ringats in i varje tabell

  14. För varje tabell bestämmer du vilka fält som ska lagra data och vilka fält som ska användas från andra (relaterade) tabeller.

    Med utgångspunkt i ämnet för en tabell kan du se var det är logiskt att lagra information och var du ska använda data från en relaterad tabell. Med undantag för nyckelfält ska alla fält bara förekomma en gång i databasen. Ta bort fält som inte är relevanta för tabellens ämne.

  15.  

    Onödiga fält har strukits i tabellerna

  16. Anslut varje primärnyckel till dess motsvarande främmande nyckel i den relaterade tabellen.

    Det som upprättar en relation mellan tabeller är att deras nyckelfält innehåller data som matchar relationens villkor.

  17.  

    Relationer mellan nyckelfält i tabellerna

    Denna plan indikerar nu att:

    • en kund kan ha många olika fakturor, men en enskild faktura kan endast ha en kund
    • en faktura kan ha många radobjekt, men ett enskilt radobjekt visas på en faktura
    • en produkt kan visas på många olika radobjekt, men ett enskilt radobjekt har bara en produkt