Wertelisten

Auswahlfelder

• Liste mit einer festgelegten Menge von Werten
• Z.B. für Drop-Down-Menü

Implementierung durch Check-Constrains

CREATE TABLE Modul (
  MID INTEGER NOT NULL PRIMARY KEY,
  Bez VARCHAR(100) NOT NULL,
  Regelsemester INTEGER NOT NULL,
  Modulart VARCHAR(20) NOT NULL, 
  CHECK (Modulart IN ('Pflicht', 'Wahlpflicht', 'Wahl'))
); 

• Liste der Werte nicht explizit in den Daten repräsentiert
• Änderung an Werteliste erfordert Änderung des Datenmodells
• Änderung am Code, d.h. Entwicklungstätigkeit

Wertelisten im ER-Modell

• Änderung an Werteliste erfordert neuen Eintrag in der Tabelle
• Keine Änderung am Code, lediglich Dateningabe
• Verbund erforderlich
• IsValid: Ausblenden von nicht mehr nutzbaren Werten
• SortOrder: Sortierreihenfolge bei der Ausgabe

CREATE TABLE Modul (
  MID INTEGER NOT NULL,
  Bez TEXT NOT NULL,
  ModulartID INTEGER NOT NULL,
  PRIMARY KEY (MID)
);
CREATE TABLE Modulart (
  ID INTEGER NOT NULL,
  Description TEXT NOT NULL,
  IsValid INTEGER NOT NULL,
  SortOrder INTEGER NOT NULL,
  PRIMARY KEY (ID)
);
ALTER TABLE Modul
  ADD CONSTRAINT fk_Modul_Modulart FOREIGN KEY (ModulartID) REFERENCES Modulart (ID);

INSERT INTO Modulart (ID, Description, IsValid, SortOrder) VALUES (1, 'Pflicht', 1, 1);
INSERT INTO Modulart (ID, Description, IsValid, SortOrder) VALUES (2, 'Wahlpflicht', 1, 2);
INSERT INTO Modulart (ID, Description, IsValid, SortOrder) VALUES (3, 'Wahl', 1, 3);

Problem: Lokale Schlüssel

Konsistenzproblem

INSERT INTO Note 
  VALUES (1, 2.3, 1, 1);
INSERT INTO Note 
  VALUES (2, 3.7, 1, 1);

Problem: Transferierbarkeit

Konsistenzproblem

UPDATE Raum 
  set GID=99
WHERE RID=1;

• Raum wird in ein anderes Gebäude transferiert
• Das ist inhaltlich inkonsistent
• Fremdschüssel auf Raum-Datensatz mit RID=1 ggfs. nicht mehr gültig im neuen Gebäude

Problem: Mehrstellige Beziehungstypen

• Personen können mehrere Adressen haben
• Einer Adresse können mehrere Personen zugeordnet werden
• Personen können mehrere Adressarten haben
• Einer Adressart können mehrere Personen zugeordnet sein
• Eine Adresse kann mehrere Adressarten haben
• Einer Adressart können mehrere Adressen zugeordnet sein

Nicht möglich festzustellen, welche Adresse von Özdem privat oder geschäftlich ist

Assoziationstypen

• Personenadresse hat Doppelnatur
• Wird daher Assoziationstyp genannt
• Ist Entitätstyp
• Ist aber auch Beziehungstyp: verbindet Entitätstypen
• Dreistelliger Beziehungstyp
• Globale Schlüssel

Nun möglich festzustellen, welche Adresse von Özdem privat oder geschäftlich ist

Globale Schlüssel

Kein Konsistenzproblem

INSERT INTO Note 
  VALUES (2.3, 1, 1);

Nicht möglich

INSERT INTO Note 
  VALUES (3.7, 1, 1);

• Primärschlüsselbestandteil wird erzeugt
• SID UND MID bilden einen zusammengesetzte Primärschlüssel

Nichttransferierbarkeit

Zusammengesetzter Primärschlüssel

UPDATE Raum 
  set befindet_sich_inID=99
WHERE RID=1;

• Raum erhält neue Identität - ist somit ein neuer Raum
• Update nur möglich, wenn kein Fremdschüssel auf Raum mit RID=1 zeigt
• Fremdschüssel auf Raum mit RID=1 müssen vorher gelöscht werden

Existenzabhängigkeit

DELETE FROM Gebaeude 
WHERE GID=1;

• Raum kann nicht verschoben werden (Nichttransferierbarkeit)
• D.h., Raum muss gelöscht werden, damit Gebäude gelöscht werden kann
• D.h., Räume hängen von der Existenz von Gebäuden ab

Note mit Werteliste

Beispiel Handelsunternehmen

Assoziationstypen in HVS