Office: (Office 2003) Datenbank aufbauen Teil-1

Guten morgen Josef, @alle

irgendwie komme ich noch nicht ganz klar damit, Bspw. wofür steht eigentlich fiVerteiler, fiLieferant usw. ist das = ID und müssen die so heißen?

schau dir bitte mal meinen Anhang an. *rolleyes.gif*
mit den Beziehungstypen habe ich doch noch ein Verständnisproblem denke ich. Mir brumbt der Schädel, aber ich möchte es doch durchziehen. Weil ich das halt für meine tägliche Arbeit brauche *frown.gif*

mfg
Erich *wink.gif*

 

Das Präfix "fi" benutze ich als Kennung für einen Fremdschlüssel. Du kannst das Feld aber benennen wie du willst.

Den Anhang sah ich mir an, ich entdeckte aber nichts neues, was nicht zuvor bereits in diesem Thread stand.
Und wie schon einmal erwähnt: du hoffst vergeblich, wenn du glaubst, ich bau dir dein Modell als "Forum-Supportleistung" komplett zusammen.
Ich bin gerne bereit, dich bei der Lösung von kniffligen Tabellenbeziehungen zu unterstützen, aber ich werde dir die Denkarbeit nicht abnehmen.

Wie viel Eigeninitiative hast du schon ergriffen, um das Verständnisproblem zu verkleinern?
Das Access-Tutorial erwähnte ich bereits. Dort sind u.a. Besipiele für 1:1, 1:n und n:m-Beziehungen gezeigt.
Im AEK-Downloadbereich von www.donkarl.com gibt es eine Skript zum Thema Normalsisierung von Michael Zimmermann.
Und per Suchmaschine gibt es ungefähr 100.000 Treffer zum Begriff Datenmodellierung.
Ich verstehe durchaus, dass das am Anfang vielleicht etwas kompliziert ist. Ich hoffe aber auch, dass du versteht, dass mich das "Vorkauen" von Grundlagen nicht besonders interessiert, wenn es diese x-fach zum Nachlesen gibt.

mfg
Josef

 

Hallo Josef,

wie würdest du dieses bewerten?

mfg
Erich

 

Du solltest im DBDesigner nicht die 1:n-Beziehungen verwenden, die im PK landen. Meist benötigst du "1:n (non identifying)"
(Das ist genau der Grund, warum man erst Hilfswerkzeuge verwenden sollte, wenn man weiß, was die machen sollen, sonst kommen Ergebnisse, die man nicht haben will. *wink.gif*)

Bezüglich Notizen:
Soll es mehrere Notizen je Beanstandung geben?
Derzeit steht bei dir: "Eine Notiz hat mehrere Beanstandungen"

 

Hallo Josef,

Ja es können mehrere Notizen je Beanstandung sein

hast wiedermal recht lassen wir das Hilfswerkzeug weg, mich da rein zu versetzen ist sicherlich Zeitverschwendung. Ich habe aber doch noch einen Klemmer 1:n Beziehung heißt ja links kann es nur 1x vorkommen rechts unendlich Bsp. 1:n 1 Lieferant viele Beanstandungen je Lieferant.

Nach dem Chema habe ich versucht die doc Datei mal abzudenken, mein derzeitiges Ergebnis im Anhang. beim Artikelstamm habe ich noch zweifel wie das aussehen müsste, sowie mit der Kennung aus deinem Beispiel. Würdest du wenigstens im doc ggf. Bemerkungen einbringen? Dann würde ich die Struktur mal in Access herstellen, um sie dir noch mal zwecks drüberschauen hier hochladen.

Danke, Danke!

mfg
Erich

 

Ich finde, dass das so passt. *Smilie

Symbolisch wird das gerne so dargestellt:
Erfasser (1) ---> (n) Beanstandung

auch das sieht gut aus.

Noch ein Tipp:
bevor du die Tabellen mit Access erstellst, male dir die "Tabellen" auf ein großes Blatt Papier (nur Tabellenname und Schlüsselfelder) und zeichne Pfeile (= Beziehungen) zw. den Schlüsselfeldern ein.
Damit erhälst du eine relativ gute Übersicht über den Zusammenhang des Gesamtsystems.

Ist vielleicht etwas unglücklich formuliert, da daraus nicht hervorgeht, ob es zu einem Artikel mehrere Beanstandungen geben kann.

 

Hallo Josef,

ja würde ich so machen und mir das anschauen, bzw. lade ich dir das hier noch mal hoch.

Schau dir aber bitte noch mal die doc Datei an, liege ich noch richtig
ist Bspw. das Verbindungsfeld: Lieferantenkennung = (fiLieferant ?) oder ist das Verbindungsfeld: Lieferantenkennung das ID Feld aus Lieferant

wünsche dir einen schönen 01.Mai *wink.gif* *Smilie

mfg
Erich

 

Und ein Lieferant liefert nie mehrere Artikel?
Ich vermute hier eher eine n:m-Beziehung.

Im Prinzip kann man das so berschreiben: in der Fremschlüsseltabelle werden die Werte aus dem Primärschlüssel der der Primärschlüsseltabelle eingetragen.

Beispiel:
Lieferant (1) ---> (n) Beanstandung
PK in der Lieferantentabelle wäre z.B.: idLieferant
FK der Beanstandungstabelle, der den Wert aus idLieferant aufnehmen soll, könnte z.B. mittels fiLieferant bezeichnet werden.
id ... kennzeichnet dann immer den Pk und damit die "Primärschlüsselseite"
fi wäre dann der Präfix für Fremdschlüsselfelder.
Du kannst aber auch die Felder in beiden Tabellen mit LieferantID oder sonst wie benennen. (grundsätzlich ist alles erlaubt, es sollte meiner Ansicht nach nur einheitlich sein.)

 

Hallo Ihr!

Anmerkend zu Josef will ich kurz die m:n Beziehung näher erläutern:

tbl_Lieferanten
LieferantID (PK)
...usw

tbl_Artikel
ArtikelID (PK)
...usw

tbl_ArtikelLieferanten
LieferantID (FK)
ArtikelID (FK)

Somit kannst Du zu jedem Artikel X Lieferanten erfassen und zu jedem Lieferant X Artikel. Und wenn s ganz fein werden soll, dann bildest Du den Primary Key in der Tabelle tbl_ArtikelLieferanten aus

LieferantID (FK) & ArtikelID (FK) = Primary Key

Dann ist sichergestellt, dass keine Kombination aus Artikel und Lieferant doppelt erfasst wird.

 

Hallo Erich,

hatte mir mal Dein .doc angeschaut. Zu Thema Beanstandungen:

Dein Aufbau besagt, das ein Lieferant beanstandet werden kann und auch ein Artikel.

Wird nicht der Artikel beanstandet der von einem Lieferanten kommt?

 

Hallo Sascha,

einen schönen 01.Mai wünsche ich dir, ja auch heute läßt mich die DB nicht in Ruhe!
ja es wird der Artikel beanstandet, das ist richtig

Nun bin ich der Meinung ich bin fertig? und kann die Tabellen wie im Anhang beschrieben erstellen, oder gibt es noch weitere Anmerkungen.
Es wäre nun sehr hilfreich da (ich als Anfänger Stufe 1) mir denke ich sehr große Mühe gemacht habe aber so wie ich das sehe habt ihr noch die eine oder andere Idee (Anmerkung) würdet ihr mir mein Dokument doc korriegieren
so das ich die tab erstellen kann?

mfg
Erich *wink.gif* *Smilie

 

Moin Erich.

Auch für Dich einen schönen 1.Mai. Und an an Josef auch..*Smilie

Magst Du mir kurz erläutern, was HKArtikel und Artikelstamm gemein haben. Du schreibst dazu:

Dein Zitat bedeutet für mich: Ein Artikel im Artikelstamm, kann entweder ein Hausteil oder ein zugekauftes Teil sein. Richtig?

 

Hallo Sascha,

ja, ein Artikel erhält den Kennbuchstaben "H" für Hausteil oder "K" für Kaufteil
dh. der Artikel kann ein Hausteil (eigene Artikel) oder ein Zukaufteil sein
damit kann ich nachher unterscheiden bzw. möchte das Auswerten zwischen Hausteilfehler und Kaufteilfehler
mfg
Erich

 

Huhu Erich,

und was schreibst Du in die Tabelle HKArtikel? Alle ArtikelID die Hausteil sind oder befinden sich in dieser Tabelle nur die Kennzeichen "H" oder "K"?

Alternativ könnte auch gehen:

Richte einfach einen Lieferanten ein, der sich meinethalben -Hausteil- mit Eurer Anschrift nennt. Somit hättest Du auch sichergestellt, dass es, zukünftig möglich wäre ein Teil zu zukaufen oder aus eigener Produktion kommt. Verstehst? Das Auswerten klappt auch dann genauer....

 

nur H-K würde in der tab stehen