Letzte Seiten:

Generalisierung bzw. Spezialisierung

ERM


RM

Allgemein:

  • Kann auf disjunkte, nicht-disjunkte, totale und partielle Generalisierung bzw. Spezialisierung angewandt werden
  • 1 Relation für Supertyp und je 1 Relation pro Subtyp
  • Subtypen erben (nur) Schlüsselattribut(e) des Supertyps
  • Beziehungstyp 1:1



Disjunkte und partielle Generalisierung bzw. Spezialisierung

CDM




PDM



SQL
[Code]
CREATE TABLE Fahrzeug
( FNr  CHAR(5)  NOT NULL  PRIMARY KEY );

CREATE TABLE Auto_sub
( FNr  CHAR(5)  NOT NULL  PRIMARY KEY,
  FOREIGN KEY (FNr) REFERENCES Fahrzeug (FNr)
                    ON DELETE CASCADE
);

CREATE TABLE Fahrrad_sub
( FNr  CHAR(5)  NOT NULL  PRIMARY KEY,
  FOREIGN KEY (FNr) REFERENCES Fahrzeug (FNr)
                    ON DELETE CASCADE
);

CREATE VIEW Auto
AS SELECT FNr
   FROM Auto_sub
   WHERE FNr NOT IN (SELECT FNr FROM Fahrrad_sub)
   WITH CHECK OPTION;

CREATE VIEW Fahrrad
AS SELECT FNr
   FROM Fahrrad_sub
   WHERE FNr NOT IN (SELECT FNr FROM Auto_sub)
   WITH CHECK OPTION;

Mittels Views wird die Disjunktheit garantiert. Auf Datenbankebene muss daher bei Datenmanipulationen mit den Views anstelle der Basistabellen gearbeitet werden.

Disjunkte und totale Generalisierung bzw. Spezialisierung

ERM
  • Disjunkt: Eine Person kann in max. einem Subtyp Mitglied sein
  • Total: Jede Person muss Mitglied in einem Subtyp sein



CDM






RM

Der Supertyp entfällt, da alle Entitäten durch Subtypen beschrieben werden. Das ergibt je 1 Relation pro Subtyp. Die Subtypen erben alle Attribute des Supertyps. Das betrifft auch Fremdschlüssel, die sich ggf. aus Beziehungen des Supertypen ergeben.

PDM



SQL
[Code]
CREATE TABLE Mann_sub
( PNr   CHAR(3)      NOT NULL  PRIMARY KEY,
  Name  VARCHAR(20)
);

CREATE TABLE Frau_sub
( PNr   CHAR(3)      NOT NULL  PRIMARY KEY,
  Name  VARCHAR(20)
);

CREATE VIEW Mann
AS SELECT PNr, Name
   FROM Mann_sub
   WHERE PNr NOT IN (SELECT PNr FROM Frau_sub)
   WITH CHECK OPTION;

CREATE VIEW Frau
AS SELECT PNr, Name
   FROM Frau_sub
   WHERE PNr NOT IN (SELECT PNr FROM Mann_sub)
   WITH CHECK OPTION;

Mittels Views wird die Disjunktheit garantiert. Auf Datenbankebene muss daher bei Datenmanipulationen mit den Views anstelle der Basistabellen gearbeitet werden.

Sofern das DBMS materialisierte Views unterstützt, kann die Disjunktheit auch wie folgt garantiert werden.

[Code]
CREATE TABLE Mann
( PNr   CHAR(3)      NOT NULL  PRIMARY KEY,
  Name  VARCHAR(20)
);

CREATE TABLE Frau
( PNr   CHAR(3)      NOT NULL  PRIMARY KEY,
  Name  VARCHAR(20)
);

CREATE MATERIALIZED VIEW Mann_oder_Frau
AS SELECT PNr FROM Mann
   INTERSECT
   SELECT PNr FROM Frau;

ALTER TABLE Mann_oder_Frau
ADD CONSTRAINT MannDisjunktFrau CHECK (PNr IS NULL);



Auflösung der Subtypen

RM

Disjunkte Generalisierung bzw. Spezialisierung:

  • 1 Relation; enthält alle Attribute von Supertyp und Subtypen
  • Zusätzliches Typ-Attribut zum Speichern der disjunkten Werte



Nicht-disjunkte Generalisierung bzw. Spezialisierung:

  • 1 Relation; enthält alle Attribute von Supertyp und Subtypen
  • Zusätzliches (boolesches) Typ-Attribut für jeden Subtypen



Hinweis: Obige Auflösungen sind nicht zu empfehlen, wenn viele spezifische Attribute für die Subtypen definiert werden.

CDM




PDM



SQL

Disjunkte Generalisierung bzw. Spezialisierung:

[Code]
CREATE TABLE Spieler
( SNr         CHAR(3)      NOT NULL  PRIMARY KEY,
  Spielertyp  VARCHAR(10)  NOT NULL 
                           CHECK (Spielertyp IN ('Fußball', 'Tennis'))
);



Nicht-disjunkte Generalisierung bzw. Spezialisierung:

[Code]
CREATE TABLE Spieler
( SNr      CHAR(3)  NOT NULL  PRIMARY KEY,
  Fußball  BOOLEAN  NOT NULL,
  Tennis   BOOLEAN  NOT NULL
);