Zum Inhalt springen

karl-heinz

Mitglieder
  • Gesamte Inhalte

    12
  • Benutzer seit

  • Letzter Besuch

  1. Alle AUTO_INCREMENT entfernen! Die Fremdschlüssel-Beschränkung hattest du schon gepostet...
  2. DROP DATABASE Beispiel; CREATE DATABASE Beispiel; USE Beispiel; CREATE TABLE Dokument(D_ID [B]INT[/B] NOT NULL AUTO_INCREMENT PRIMARY KEY , Nickname VARCHAR(25) NOT NULL); CREATE TABLE Link (L_ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY , Nickname VARCHAR(25) NOT NULL, D_ID [B]INT[/B] NOT NULL); INSERT INTO Dokument (Nickname) VALUES ("Foo"), ("Bar"); INSERT INTO Link (Nickname, Link.D_ID) VALUES ("Foolink", [B]1[/B]); Naja der Datentyp von Primär- und zugehörigen Fremdschlüsseln muss gleich sein, weil du sonst bei jedem Suchvorgang, Vergleich etc. einen der Werte umwandeln müsstest. Daher erzwingt auch eine FOREIGN KEY CONSTRAINT, dass die Datentypen identisch sind. Also, wat macht ein AUTO_INCREMENT? Es erzeugt quasi automatisch einen Schlüsselwert der eindeutig ist. Sollte dir aber sofort auffallen, wenn du ein SELECT * FROM Dokument machst! Schließlich enthält dein INSERT auf Dokument keine Angabe zu D_ID! Aber diesen Wert brauchst du ja, wenn du dann einen INSERT auf Link machst der auf ein Dokument zeigen soll! Fehler mit dem Datentyp war also doch noch drin . Naja mach doch noch mal eine FOREIGN KEY CONSTRAINT dazu und entferne erstmal diese AUTO_INCREMENT-Geschichte, und dann kannste den Krams auf deine eigentliche Aufgabe münzen...
  3. Doch fast, aber du hast nicht denselben Datentypen für den Fremdschlüssel verwendet, und dat ist weshalb problematisch?
  4. Ja! Und zwar in der Link-Tabelle (z.B. Link.D_ID oder Link.Dokument als int). D.h. also, du 'nimmst' dir den Primärschlüssel der betreffenden Tabelle (hier Dokument.D_ID) und 'verwendest' ihn in der anderen Tabelle (Link) als Fremdschlüssel, indem du ihn dort als Spalte anlegst (beide Datentypen müssen übereinstimmen!). Und dann kannst du noch eine CONSTRAINT für Link definieren, die sicherstellt, dass wenn du einen Wert in Link.D_ID reinschreibst, dieser auch in Dokument.D_ID existiert. Aber du kannst kein AUTO_INCREMENT für den Fremdschlüssel verwenden! Und wenn du jut bist, sachste mir noch kurz warum ...
  5. Hm okay... Wie bekomm ich folgendes hin: "Foolink"->"Foo"? Anders gesagt wie bekomme ich es hin, dass wenn ich "Foolink" kenne, dass ich auch "Foo" kenne? Nach deinen Inserts sollte ja ungefähr Folgendes in der DB stehen: Dokument: (1,'Foo') (2,'Bar') Link: (1,'Foolink') Du musst jetzt nur noch Link ändern, so das folgendes in der DB wäre: (1,'Foolink',1)
  6. Sehr Gut! Einzig der Attributname 'Nickname' stört mich ein wenig, aber mit Ausnahme, der letzten Forderung hast du allet richtig gemacht . Zu der Frage ob ich IDs möchte: Jep ich wollte welche (künstlicher Primärschlüssel). Ob man dis auch anders machen könnte? Ja, angenommen der Name eines Dokumentes muss eindeutig sein, so könntest du stattdessen auch 'Name' verwenden (natürlicher Primärschlüssel) und 'D_ID' weglassen, da es ja dann nicht mehr gebraucht werden würde. Was hab' ich nun mit 'zeigt auf' gemeint? Wat hat denn ein Html-Link für ein Attribut? Richtig 'href'. Und wat steht drin? Na die Adresse der Webseite auf die 'verlinkt' wird. Was wäre also die Dokumentadresse in deinem Fall? Gruß
  7. Unabhängig von deiner letzten Frage, poste bitte noch mal die korrigierte Version :cool:.
  8. Na dann mach jetzt erstmal ein Beispiel (SQL) mit zwei Tabellen Dokument und Link. Beide haben einen Namen, und bei Link wird zusätzlich angeben, auf welches Dokument er 'zeigt'. Für beide sollst du einen künstlichen Primärschlüssel verwenden. Und am Ende bitte noch drei Inserts: Ein Dokument 'Foo' und 'Bar' und ein Link 'Foolink', der auf 'Foo' zeigt. Los geht's und vergiss die Kommentare nicht . Gruß
  9. Na das ist doch schon was! Allerdings vergibst du auch in der Tabelle Zugriff, die Werte für N_ID automatisch. Macht das Sinn? Was tut den deine Foreign Key Constraint? Sie stellt doch sicher, dass der Fremdschlüssel auch als Primärschlüssel bereits existiert. Wie kommt ein solcher Fremdschlüssel also zustande? Da er auch als Primärschlüssel existieren muss, kann er erst danach manuell angelegt werden, oder? Kleiner Tipp, geh' hier doch mal etwas strukturierter vor, und dokumentiere das auch für uns: Erzeuge z.B. ein kleines Datenbeispiel, welche Attribute sind Primärschlüssel und welche sind Fremdschlüssel oder schreib' auf was du darunter bis jetzt verstehst. Gruß
  10. Schreib' dir doch schnell 'nen kleines Skript, welches passende reguläre Ausdrücke verwendet. Sollte eigentlich in weniger als 15 min. gelöst sein. Z.B. machste am Anfang jeder Zeile 'nen 'INSERT INTO ... (...) VALUES (' zuvor gegebenenfalls Trennzeichen ersetzten, analog dazu das Format von Zeichenketten, Datumswerte etc. berücksichtigen und an das Ende jeder Zeile 'nen ');'. Gruß
  11. Sorry falls das schon gesagt wurde, aber dein relationales Modell ist keine korrekte Umsetzung des ERM: Stichworte: Fremdschlüssel, zusammengesetzter Primärschlüssel, schwache Entität bzw. n:m-Beziehung... Bei der Argumentation, ob es sich um die 3.NF handelt würd' ich auch grummeln . Die Bedingungen der entsprechenden Normalformen sind auf der Wikipedia zu finden, und müssen im jeweiligen Fall auch angewendet werden. Doch bevor du das tust, würde ich mich erstmal um 'ne korrekte Abbildung deines ERD kümmern. Gruß
  12. Hallo, mit folgender Aufgabenstellung habe ich erhebliche Schwierigkeiten: Anmerkung: Das entsprechende Relationenschema ist R = (System, Größe, Material) - in der Aufgabenstellung als Relation in Tabellenform. Die zugehörigen Tupel sind: (Stehsammler, A4, Acryl), (Stehsammler, A5, Holz), (Ordner, A4, Kunststoff), (Hängemappe, A4, Karton) und (Ordner, A5, Kunststoff). Lösungsansatz a) F = {{Material} -> {System}, {Größe, Material} -> {System}} P = {{System, Größe}, {Material, Größe}} Die Tabelle bzw. Relation ist in der 3. Normalform, jedoch nicht in der BCNF, da Material (Determinante von System) kein Superschlüssel ist. c) R_1 = (Material, System) R_2 = (Material, Größe) Die entsprechenden Tupel hab' ich jetzt mal ausgeblendet. Fragen Ist mein Lösungsansatz korrekt? Gibt es noch andere Möglichkeiten? Ist in Aufgabe a mit 'Schlüssel' 'Schlüsselkandidaten der gegebenen Relation' gemeint? Wie würde ich in Aufgabe b sinnvoll - sofern ich richtig liege - für die 2.NF und 3.NF argumentieren? Habt ihr ein paar Tipps zu einer sicheren Vorgehensweise - ich bin hier recht intuitiv vorgegangen? Vielen Dank Karl-Heinz

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...