Transact SQL - Fehler beim FOREIGN KEY

[rejoice]

Hallo

Ich habe ein Problem beim Fremdschlüssel anlegen. Das System ist ein Microsoft SQL Server 2008R2. Es können immer nur zwei Fremdschlüssel angelegt werden - der 3. klappt nie -dabei ist es egal in welcher Reihenfolge ich die Fremdschlüssel anlege. Die Fehlermeldung:

Das Einführen der FOREIGN KEY-Einschränkung 'fk_Seminarsprecher' für die Seminar-Tabelle kann Schleifen oder mehrere Kaskadepfade verursachen.

ich verstehe es nur nicht.... Wo entsteht da eine schleife?
In MySql klappt das wunderbar....

USE Datenbank;
 GO
 CREATE TABLE Studenten
 (
 StudentenID int CONSTRAINT pk_Studenten PRIMARY KEY,
 Vorname varchar(80) NOT NULL,
 Nachname varchar(80) NOT NULL
 );
 
CREATE TABLE Seminar
 (
 SeminarID int CONSTRAINT pk_Seminar PRIMARY KEY,
 Name varchar(80) NOT NULL,
 Seminarsprecher int NULL
 );
 
CREATE TABLE Zugehörigkeit
 (
 StudentenID int NOT NULL,
 SeminarID int NOT NULL
 )
 
ALTER TABLE Zugehörigkeit ADD CONSTRAINT fk_StudentenID FOREIGN KEY (StudentenID)
 REFERENCES Studenten ON UPDATE CASCADE ON DELETE CASCADE;
 
ALTER TABLE Zugehörigkeit ADD CONSTRAINT fk_SeminarID FOREIGN KEY (SeminarID)
 REFERENCES Seminar ON UPDATE CASCADE ON DELETE CASCADE;
 
ALTER TABLE Seminar ADD CONSTRAINT fk_Seminarsprecher FOREIGN KEY (Seminarsprecher)
 REFERENCES Studenten ON UPDATE CASCADE ON DELETE SET NULL;

[Thomas Henkel]

Probier mal bei der letzten Anweisung die Angabe der zu referenzierenden Spalte:

ALTER TABLE Seminar ADD CONSTRAINT fk_Seminarsprecher FOREIGN KEY (Seminarsprecher)
 REFERENCES Studenten (StudentenID) ON UPDATE CASCADE ON DELETE SET NULL;

Evtl. kommt er durcheinander, wenn die Spalten nicht die gleichen Namen haben.

Thomas

[Ralf Jansen]

Ist scheinbar normal im SQL Server zumindest dieser Blog stolpert über das gleiche Verhalten.

Die Frage nach dem warum kann ich nicht beantworten. Zur Lösung würde ich ein anderes DB Design vorschlagen das ich eh für besser halten würden.
Der Seminarsprecher ist natürlich auch Zugehörig zum Seminar. Sprecher ist also eine Rolle der Zugehörigkeit und sollte entsprechend in der Zugehörigkeit Tabelle dargestellt werden. Im einfachsten Fall als bit/bool Spalte.
Im jetzigen Design ist nicht sichergestellt das der Sprecher auch zum Seminar zugehörig ist. Eine Abfrage über die Zugehörigkeit würde also nicht zwingend eine vollständige Liste der Seminarteilnehmer liefern was nicht wirklich Erwartungskonform ist.

[rejoice]

Probier mal bei der letzten Anweisung die Angabe der zu referenzierenden Spalte:

ALTER TABLE Seminar ADD CONSTRAINT fk_Seminarsprecher FOREIGN KEY (Seminarsprecher)
 REFERENCES Studenten (StudentenID) ON UPDATE CASCADE ON DELETE SET NULL;

Evtl. kommt er durcheinander, wenn die Spalten nicht die gleichen Namen haben.

Thomas

Danke für den Tipp. Das hat leider auch nichts gebracht.

es scheint wohl wie Ralf Jansen erwähnt hat wohl ein Fehler im SQL Server zu sein.

Weiß jemand ob der Fehler im SQL Server 2012 auch noch da ist?

Zur Not werde ich mir den nachher mal in einer Virtuellen Maschine installieren.

@Ralf Jansen:
Deine Idee des anderen Datenbankdesign ist super.
In dem Fall war es eine Klausuraufgabe weswegen die Tabellen vorgegeben waren


Folgendes funktioniert ist aber nicht sinn der Sache

ALTER TABLE Seminar ADD CONSTRAINT fk_Seminarsprecher FOREIGN KEY (Seminarsprecher)
REFERENCES Studenten (StudentenID) ON UPDATE NO ACTION ON DELETE NO ACTION;

[Ralf Jansen]

Weiß jemand ob der Fehler im SQL Server 2012 auch noch da ist?

Verhält sich genauso.

[rejoice]

Nur komisch das es in MySQL geht.... Da hab ich nur bei dem Fremdschlüssel noch nen index hinzugefügt:

-- phpMyAdmin SQL Dump
-- version 3.5.2.1
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Erstellungszeit: 20. Sep 2012 um 15:30
-- Server Version: 5.1.63-0+squeeze1
-- PHP-Version: 5.3.3-7+squeeze14

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

--
-- Datenbank: `usr_web246_4`
--

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `seminar`
--

CREATE TABLE IF NOT EXISTS `seminar` (
`seminarid` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(100) CHARACTER SET latin1 NOT NULL,
`seminarsprecher` int(11) DEFAULT NULL,
PRIMARY KEY (`seminarid`),
KEY `seminarsprecher` (`seminarsprecher`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `student`
--

CREATE TABLE IF NOT EXISTS `student` (
`studentid` int(11) NOT NULL AUTO_INCREMENT,
`vorname` varchar(100) CHARACTER SET latin1 NOT NULL,
`nachname` varchar(100) CHARACTER SET latin1 NOT NULL,
PRIMARY KEY (`studentid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `zugehörigkeit`
--

CREATE TABLE IF NOT EXISTS `zugehörigkeit` (
`studentid` int(11) NOT NULL,
`seminarid` int(11) NOT NULL,
KEY `studentid` (`studentid`,`seminarid`),
KEY `seminarid` (`seminarid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci;

--
-- Constraints der exportierten Tabellen
--

--
-- Constraints der Tabelle `seminar`
--
ALTER TABLE `seminar`
ADD CONSTRAINT `seminar_ibfk_1` FOREIGN KEY (`seminarsprecher`) REFERENCES `student` (`studentid`) ON DELETE CASCADE ON UPDATE SET NULL;

--
-- Constraints der Tabelle `zugehörigkeit`
--
ALTER TABLE `zugehörigkeit`
ADD CONSTRAINT `zugeh@1irigkeit_ibfk_2` FOREIGN KEY (`seminarid`) REFERENCES `seminar` (`seminarid`) ON DELETE CASCADE ON UPDATE CASCADE,
ADD CONSTRAINT `zugeh@1irigkeit_ibfk_1` FOREIGN KEY (`studentid`) REFERENCES `student` (`studentid`) ON DELETE CASCADE ON UPDATE CASCADE;

[Ralf Jansen]

Was ist daran merkwürdig das sich unterschiedliche Datenbanken unterschiedlich Verhalten? Das würde ich eher als normal bezeichnen. ANSI SQL ist eher ein gutgemeinter Vorschlag als ein Gesetz.

[rejoice]

du hast ja recht.... es ist nur eben doof :-P Danke für deine Hilfe :-)