Forum / Aufbaumodule / Industrielle Informationssysteme [UE]

Mir ist nicht ganz klar was ich als Primärschlüssel verwenden soll, bzw wie ich die IDs wählen soll? ) Als Primärschlüssel numerische Werte verwenden. Nimm eine fortlaufende id.

Aber wenn jeder einzelne Eintrag in der 1. NF eine einzelne ID kriegt, hab ich dann ja automatisch die 2. NF oder? dann hätten aber auch mehrere Personen mehrere IDs, vielleicht kannst du noch ein bisschen genauer erklären wie du die ID einführen würdest?

Aber wenn jeder einzelne Eintrag in der 1. NF eine einzelne ID kriegt, hab ich dann ja automatisch die 2. NF oder? dann hätten aber auch mehrere Personen mehrere IDs, vielleicht kannst du noch ein bisschen genauer erklären wie du die ID einführen würdest? Wieso meinst du, dass es dann die 2. NF ist? Die logische Abhängigkeit verschwindet ja nicht wegen dem einführen einer id. Ja, darum würde es sich empfehlen die Personen in eine eigene Tabelle auszulagern.

Hi, bei der 2 HUE, ich hänge beim 1.BSP. Die 1NF ist ok alles wird gesplittet. Jetzt fängt das Problem an, bei der 2NF wenn ich ID einfüge darf es sein das ich dann 2 Gleiche ID_Nr haben? Zb ID: 1 , Tomas Test ...... Führerschein B und dann nächste zeile ID1 THomas test ..... FÜhrerschein C ?? weil wie splitte ich die adresse und Führerschein auf, kann ja keine Strasse ID einbauen..

Ich bekomme 2c) überhaupt nicht auf die reihe! könnte mir da bitte jemand helfen? :)

Du kannst die Verknüpfung von Person und Führerschein in eine eigene Tabelle auslagern. Der Führerschein ist ja nicht von der Adresse und schon gar nicht von der Abteilung abhängig.

[QUOTE=ameliedemmler;22073]Ich bekomme 2c) überhaupt nicht auf die reihe! könnte mir da bitte jemand helfen? :) Woran hängt es?

@Clemens , wie hast du beim 2. Bsp , z.B.: die Tabelle Auftraggeber erstellt , weil bekomme immer ein Fehler bzw wie hast du das eingefügt mit dem "vererben" könntest du nur die eine Tabelle posten und davon ein INSERT INTO . bitte

CREATE TABLE "Auftraggeber" ( A_ID INTEGER PRIMARY KEY NOT NULL, Auftraggeber VARCHAR(50) NULL, Telefon VARCHAR(50) NULL, B_ID INTEGER NULL, FOREIGN KEY(B_ID) REFERENCES Bauprojekt(B_ID) );

INSERT INTO .....('1', Baufix, '00225..),, kommt ein fehler das ich 4 values aber definiert habe, aber B_ID ist tabelle bauvorhaben

@Clemens , wie hast du beim 2. Bsp , z.B.: die Tabelle Auftraggeber erstellt , weil bekomme immer ein Fehler bzw wie hast du das eingefügt mit dem "vererben" könntest du nur die eine Tabelle posten und davon ein INSERT INTO . bitte Meinst du mit Vererben einfach einen FOREIGN KEY?

edit: Der Fehler sagt, dass du noch etwas einfügen musst für den FOREIGN KEY. Die Tabellen kannst du später nicht so einfach Joinen ohne die "Verknüpfung"

INSERT INTO .....('1', Baufix, '00225', '1')\n~~~
Wobei der 2. einser deine id von deiner Bauvorhaben Tabelle ist z.B. Wohnpark XZ.

Aufgabe 3: da heißt es "Artikel werden auf einem oder MEHREREN Platzplätzen abgelegt" Was ist denn der Unterschied zu nur einem Lagerplatz? Wie habt ihr das realisiert?

ich denke das heisst nur dass ein Artikel auf mehreren Lagerplätzen gelagert werden kann. Also Artikel A liegt 10mal auf Platz 1 und 2 mal auf Platz2. es gibt also 12. wie macht ihr die Umlagerung? einfach als eine Funktion oder als Teil der Buchungen? also 3 Arten Zugang, Abgang, Umbuchen

habt ihr das so gemacht ? ER diagramm , die tabellen habe ich so CREATE TABLE "Artikel" ( Artikelnr INTEGER PRIMARY KEY , Artikelname VARCHAR(50)NULL, Einkaufspreis double );

CREATE TABLE "Buchung" ( ID INTEGER PRIMARY KEY , Buchungsdatum DATE Verkaufspreis double Menge integer Buchungsart char (20) Artikelnr FOREIGN KEY Buchungskennzeichen );

CREATE TABLE "Lagerplatz" ( LagerID PRIMARY KEY , Lagersektor FOREIGN KEY );

CREATE TABLE "Lagersektor" ( SektorID PRIMARY KEY , Lagersektor FOREIGN KEY );

und wegen der umlagerung ... meint damit einfach einen code mit 'UPDATE' ?

habt ihr das so gemacht ? ER diagramm , die tabellen habe ich so

Die Aufteilung von Einkaufspreis bei Artikel und Verkaufspreis bei Buchung ist mMn nicht optimal. Ob es ein Einkaufs/Verkaufspreis ist ergibt sich aus der Art der Buchung (Zu- oder Abbbuchung).

Wenn du für einen Artikel mehrere Einkaufspreise hast müsstest du bei der jetzigen Tabellenstruktur redundant speichern, was man vermeiden sollte.

ja das bei Artikel habe ich weggelassen, nur bei Buchung wie du es schon sagst habe ich das problem mit der Redundanz.... nur das bedeutet ich müsste bei tabelle buchung die sachen noch irgendwie aufsplitten oder? ich mein komme selber schon durcheinander weil die ganzen ID immer gleich sind mit der matrnr.