ER-diagram

Ett ER-diagram (Entity-Relationship) är en ritning av databasen. Det visar vilka entiteter som ska lagras, vilka attribut de har, och hur de hänger ihop — och framför allt hur många som hör ihop med hur många. Den vanligaste notationen är kråkfot (crow’s foot), uppkallad efter symbolen för “många” som ser ut som en fågelfot.

När du läst detta ska du kunna

• Känna igen och namnge delarna i ett ER-diagram: entitet, attribut, PK, FK, relation och kardinalitet
• Läsa och rita de fyra kråkfotssymbolerna: exakt ett, noll eller ett, ett eller många, noll eller många
• Avgöra på vilken sida av en relation den främmande nyckeln hamnar
• Översätta ett ER-diagram till entitetsklasser i C# med EF Core

Vad används det till?

• Designa databasen innan du skriver en enda CREATE TABLE eller entitetsklass
• Hitta fel tidigt — ska en order verkligen kunna sakna kund? Det syns direkt i kardinaliteten
• Prata med andra — kunden, läraren eller teamet kan granska datamodellen utan att läsa kod
• Dokumentera en befintlig databas, så att nästa person förstår hur tabellerna hänger ihop

ER-diagrammet beskriver data, inte beteende. Det finns inga metoder här — bara vad som ska sparas och hur det kopplas ihop. Mer om databasen i sig hittar du i SQL-sektionen och på sidan om ER-diagram i SQL.

Delarna och vad de heter

Läs relationen åt båda håll, och läs alltid symbolen vid den bortre entiteten: “En kund lägger noll eller många ordrar” (symbolen vid Order). “En order läggs av exakt en kund” (symbolen vid Kund).

De fyra kråkfotssymbolerna

Varje ände består av två tecken. Det inre tecknet (närmast entiteten) är max, det yttre är min. En ring betyder noll, ett streck betyder ett och kråkfoten betyder många.

Var hamnar FK? Alltid på många-sidan. En kund har många ordrar, så det är Order som får kolumnen KundId — inte tvärtom. En kund kan ju inte ha en kolumn per order.

Exempel — webbshop: Kund, Order, OrderRad och Produkt

En kund lägger ordrar. En order består av en eller flera orderrader, och varje orderrad gäller en produkt. OrderRad är kopplingsentiteten som löser många-till-många mellan Order och Produkt — och den bär egen data: antal och styckpris vid köptillfället.

Läs det högt, så märker du om något är fel:

• En kund lägger noll eller många ordrar. En order läggs av exakt en kund.
• En order innehåller en eller många orderrader. En orderrad hör till exakt en order.
• En produkt finns på noll eller många orderrader. En orderrad gäller exakt en produkt.

Styckpris ligger på OrderRad och inte bara på Produkt — annars skulle gamla ordrar plötsligt ändra pris när du höjer priset på produkten.

Samma modell som EF Core-entiteter

Varje entitet blir en klass, varje attribut en property, och varje relation blir en FK-property plus en navigation property. Många-sidan får en lista. (Läs mer i Entity Framework, särskilt Entiteter och Relationer.)

public class Kund
{
    public int KundId { get; set; }                     // PK — EF hittar "<Klass>Id" själv
    public string Namn { get; set; } = "";
    public string Epost { get; set; } = "";
    public string? Telefon { get; set; }                // nullable = får saknas

    public List<Order> Ordrar { get; set; } = new();    // noll eller många
}

public class Order
{
    public int OrderId { get; set; }                    // PK
    public DateTime Datum { get; set; }
    public string Status { get; set; } = "Ny";

    public int KundId { get; set; }                     // FK → Kund
    public Kund Kund { get; set; } = null!;             // exakt en

    public List<OrderRad> Rader { get; set; } = new();  // en eller många (kontrolleras i koden)
}

public class OrderRad
{
    public int OrderRadId { get; set; }                 // PK
    public int Antal { get; set; }
    [Precision(10, 2)]
    public decimal Styckpris { get; set; }

    public int OrderId { get; set; }                    // FK → Order
    public Order Order { get; set; } = null!;

    public int ProduktId { get; set; }                  // FK → Produkt
    public Produkt Produkt { get; set; } = null!;
}

public class Produkt
{
    public int ProduktId { get; set; }                  // PK
    public string Namn { get; set; } = "";
    [Precision(10, 2)]
    public decimal Pris { get; set; }
    public int Lagersaldo { get; set; }

    public List<OrderRad> OrderRader { get; set; } = new();  // noll eller många
}

public class ShopContext : DbContext
{
    public DbSet<Kund> Kunder => Set<Kund>();
    public DbSet<Order> Ordrar => Set<Order>();
    public DbSet<OrderRad> OrderRader => Set<OrderRad>();
    public DbSet<Produkt> Produkter => Set<Produkt>();
}

Lägg märke till skillnaden mellan “noll” och “ett” som minimum:

• Exakt ett (int KundId, inte int?) → kolumnen blir NOT NULL i databasen. En order kan inte sparas utan kund.
• Noll eller ett skulle bli int? KundId → kolumnen tillåter NULL.
• Ett eller många kan databasen inte tvinga fram — det finns ingen constraint för “minst en rad i en annan tabell”. Det kontrollerar du i koden innan du sparar, t.ex. if (order.Rader.Count == 0) throw ....

ER-diagram eller UML-klassdiagram?

De ser lika ut — rutor med namn och fält, linjer emellan — men de svarar på olika frågor.

Tumregel: rita ER-diagram när du designar databasen, och klassdiagram när du designar koden. Med EF Core ligger de nära varandra, men klassdiagrammet har metoder och arv som databasen aldrig ser, och ER-diagrammet har FK-kolumner som du i koden mest använder via navigation properties.

När ska du välja ett ER-diagram?

Vanliga misstag

• FK på fel sida. Den främmande nyckeln ligger på många-sidan. Kund ska inte ha OrderId.
• Många-till-många utan kopplingsentitet. En relationsdatabas kan inte lagra N:M direkt. Rita ut OrderRad (eller motsvarande) — det är ändå där intressant data som antal och pris ofta bor.
• Symbolen läses vid fel entitet. “En kund lägger många ordrar” läses vid Order-änden. Säg meningen högt åt båda håll.
• Glömt minimum. Att bara rita kråkfot (“många”) säger inget om noll är tillåtet. Bestäm om det ska vara ring eller streck — det avgör NOT NULL.
• Metoder i ER-diagrammet. BeräknaTotal() hör hemma i klassdiagrammet, inte här.

Övning

Rita ett ER-diagram för ett bibliotek med entiteterna Låntagare, Lån, Exemplar och Bok:

1. En låntagare kan ha noll eller många lån. Ett lån tillhör exakt en låntagare.
2. Ett lån gäller exakt ett exemplar. Ett exemplar kan ha lånats noll eller många gånger.
3. En bok har ett eller många exemplar. Ett exemplar är av exakt en bok.

Markera PK och FK i varje entitet. Skriv sedan entitetsklasserna i C# och fundera: vilken av relationerna kan databasen inte tvinga fram, och var i koden skulle du kontrollera den?

TL;DR