[G_PRO] Databanken
  • Welkom
  • Inleiding
    • Benodigdheden
    • Nuttige extra's
    • Mee helpen?
  • Semester 1: databanken intro
    • Installatie van alle software
    • Databanken
      • Inleiding
      • Voorbeeld
      • Wat is een relationele databank
      • Basisstructuren van een relationele databank
      • Diagramnotatie
    • (My)SQL
      • DDL
        • Datatypes
          • Enum
        • CREATE
        • ALTER
        • DROP
        • Sleutels voor identificatie
        • Primaire sleutel toevoegen/verwijderen
        • Primaire sleutel in een nieuwe tabel
        • Vreemde sleutels
        • Relaties-voorstellen
        • Labo
      • DML
        • INSERT
        • UPDATE
        • DELETE
        • LIKE
        • Logische operatoren
        • Vergelijkingen
        • SELECT sorteren
        • Functies
        • Labo
      • SELECT
        • SELECT met clausules
        • SELECT met WHERE
      • Groeperen en samenvatten
        • Aggregaatfuncties
        • SELECT met GROUP BY
        • SELECT met HAVING
        • IN
        • BETWEEN
        • SELECT DISTINCT
        • Labo
      • JOINS
        • JOINs bij simpele relaties
        • JOINs via tussenliggende tabel
        • UPDATE van JOIN
      • apTunes project
  • PRO (GEEN LEERSTOF EN/OF IN OPBOUW)
    • PRO
      • Waarom een databank?
      • Een databank ontwerpen
      • ERM
        • Basisbegrippen
        • Constraints (voorwaarden, beperkingen)
        • Keys (Sleutels)
        • Discussiepunten bij ontwerp in ERM
        • Aanvullende begrippen
        • Herleiden van ERD's tot tabellen
        • Voorbeeld
        • Bibliografie
        • Labo oefeningen
      • NoSQL
      • Blockchain
  • SEMESTER 2: DATABANKEN
    • Join
      • INNER JOIN
      • LEFT JOIN
      • COALESCE
      • RIGHT JOIN
      • LEFT EXCLUDING JOIN
      • RIGHT EXCLUDING JOIN
      • OUTER JOIN
      • OUTER EXCLUDING JOIN
      • Samenvattende flowchart
      • Labo oefeningen
    • Views
      • CREATE
      • ALTER
      • DROP
      • UPDATE
      • RENAME
      • BESLUIT
      • Labo oefeningen
    • Subqueries
      • Een onafhankelijke subquery
      • Subqueries met tijdelijke opslag
      • Labo oefeningen
    • Indexeren
      • mogelijkheden
      • CREATE
      • DROP
      • UNIQUE
      • trage queries opvolgen
    • ERD
      • Referentiële beperkingen
      • Overzicht
      • Labo oefeningen
    • Stored programs
      • Stored procedures
      • CREATE
      • DROP
      • DELIMITER
      • Variabelen
      • Parameters
      • Gerelateerde data invoegen
      • IF -THEN-ELSE-ELSEIF
      • LOOP
      • WHILE
      • REPEAT
      • SIGNAL
      • Error handling
      • RESIGNAL
      • Stored functies
      • Triggers
      • Cursors
      • Transacties en rollbacks
      • Object access control
      • Oefeningen basisgebruik stored procedures
      • Oefeningen control flow
      • Oefeningen stored functions
      • Oefeningen triggers
      • Oefeningen error handling
      • Oefeningen transacties en access control
Powered by GitBook
On this page
  • Specialisatie en generalisatie; overerving van attributen
  • Design constraints
  • Aggregatie

Was this helpful?

Export as PDF
  1. PRO (GEEN LEERSTOF EN/OF IN OPBOUW)
  2. PRO
  3. ERM

Aanvullende begrippen

PreviousDiscussiepunten bij ontwerp in ERMNextHerleiden van ERD's tot tabellen

Last updated 5 years ago

Was this helpful?

Specialisatie en generalisatie; overerving van attributen

  • Voorbeeld: zichtrekening en spaarrekening. Deze hebben de gemeenschappelijke attributen van elke rekening (rekeningnummer, saldo, datum laatste verrichting) maar ook een specifiek attribuut: krediet en interestvoet. Dit noemen we "specialisatie". Het omgekeerde proces is generalisatie.

  • De entity sets zichtrekening en spaarrekening "erven" de attributen van de entity set rekeningen.

Voorlopig moet je specialisatie en generalisatie enkel op het conceptuele niveau kennen. Dat wil zeggen dat je deze zaken in een ERD moet kunnen noteren, maar je moet ze niet kunnen voorstellen in een tabelstructuur. In het algemeen spring je ook best spaarzaam om met overerving.

Design constraints

  • attribuut-bepaald: een entity kan tot een specialisatie behoren op basis van een attribuut in de veralgemeende entity set, bv. het attribuut "rekeningstype", dat de waarde "zicht" of "spaar" kan hebben.

  • user-bepaald: de gebruiker kan zelf een entity indelen in de specialisatie naar keuze.

  • gescheiden of overlappend: het kan zijn dat een entiteit slechts tot één gespecialiseerde entity set mag behoren, of tot meerdere tegelijk. Het is bijvoorbeeld niet mogelijk dat een rekening tegelijkertijd een spaarrekening én een zichtrekening is, maar dat wil niet zeggen dat dit voor andere entiteittypes ook altijd zo is.

  • totaal of partieel: het kan zijn dat een entiteit moet behoren tot een gespecialiseerde set, maar het kan ook zijn dat dit niet hoeft.

Aggregatie

Aggregatie in een ERM houdt in dat een relatie tussen twee entiteittypes wordt behandeld als een entiteit op zich. Aggregatie wordt oa. gebruikt om relaties tussen relaties te leggen.

Dit is een n op n relatie, het attribuut filiaal hoort dus bij de relationship set, en kan niet verplaatst worden naar een van de entity sets.

Door aggregatie kunnen we het attribuut filiaal verzelfstandigen tot entity set.

In deze laatste afbeelding is er een associatieve entiteit Lening aanwezig.