Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
absoluter neuling mit kleinem problem wegen beziehungen
zurück: Problem bei komplexer Abfrage weiter: Problem bei Abfragen aus 2 Tabellen Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Antwort Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
Franz86
Neuling


Verfasst am:
29. Okt 2009, 23:36
Rufname:

absoluter neuling mit kleinem problem wegen beziehungen - absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

hallo,
ich versuche 2 tabellen für rechnungen zu erstellen.
die erste tabelle soll folgende spalten besitzen:
R-Nr (autowert)
Kundenname
Adresse
Datum
Versandart
Versandkosten
etc...

die zweite tabelle soll für die jeweils bestellten posten und preise als untertabelle dienen. die rechnungsnummer der ersten tabelle ist hierbei referentiell mit n:1 bezogen, da ja mehrere posten dann die selbe rechnungsnummer in der tabelle haben müssen.

jedoch scheitert das ganze nun bei dem ausfüllen des 2. postens mit folgender fehlermeldung: "Der Datensatz kann nicht hinzugefügt oder geendert werden, da ein Datensatz Tabelle "Bestellung" mit diesem Datensatz in Beziehung stehen muss.

würde mich freuen, wenn mir jemand meinen fehler verdeutlichen könnte.

eine abfrage, formular, bericht, krieg ich noch alleine hin, es scheitert einfach nur an diesem fehler.

beilegt habe ich euch einen screenshot und die access-datei im 2002/2003-format
http://www9.picfront.org/picture/K9uAcLkzhwP/img/access.jpg
http://www.file-upload.net/download-1978118/_Neu.mdb.html

vielen dank für eure hilfe
KlausMz
Moderator Access


Verfasst am:
29. Okt 2009, 23:51
Rufname:
Wohnort: Irgendwo in der Pfalz


AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

Hallo,
Du brauchst noch weitere Tabellen für die Kunden und die Artikel.
Zwischen der Rechungstabelle und der Postentabelle sowie der Artikel und der Postentabelle ist eine n:m Beziehung erforderlich. Die R-Nr in der Postentabelle darf kein Autowert sein, sondern eine Zahl LongInteger.
Verzichte auf Sonderzeichen in Feldnamen.
Zur Datenmodellierung/Datenbankstruktur findest Du hier weitere Infos:
Dokumente zur Datenmodellierung
Umgang mit m:n-Beziehungen
Datenmodell entwickeln: Welche Tabellen und Beziehungen?

_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.


Zuletzt bearbeitet von KlausMz am 29. Okt 2009, 23:52, insgesamt einmal bearbeitet
Franz86
Neuling


Verfasst am:
30. Okt 2009, 00:03
Rufname:

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

vielen dank!
jetzt hab ich den rest auch endlich verstanden ^^

das mit einer zusätzlichen kundentabelle wollte ich zwecks übersichtlichkeit zunächst weglassen.
tk6
SAP-Consultant


Verfasst am:
30. Okt 2009, 00:08
Rufname:

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

Ich habe mal das nötigste verändert.

Im Einzelnen:

1. Ich habe zuerst mal als Anfang die Tabelle mit den Kunden und Belegkopfdaten gespalten, denn du schreibst ja öfter auch dem gleichen Kunden eine Rechnung, also wären diese Daten in der Tabelle redundant gespeichert. Der Kunde steht zur Rechnung/Bestellung in einer 1:n-Beziehung, d.h. eine Rechnung richtet sich exakt an einen Kunden, aber ein Kunde kann mehrere Rechnungen haben.

2. Über die Primärschlüssel-Fremdschlüsselbeziehungen KundenID - KundenID_FK und R-Nr - R-Nr stehen die Daten im Zusammenhang und können, wie in der Abfrage1, die ich erstellt habe, zusammengeführt werden.

3. Die von KlausMz erwähnt Korrektur des Fremdschlüssels habe ich gemacht.

Mehr habe ich erstmal nicht gemacht, mach bitte mit dieser DB weiter und laß deine eigene erstmal liegen, da ist nicht viel mit anzufangen.

Was Klaus schreibt, solltest du unbedingt beachten.

Allerdings irrt er in einem Punkt: Zwischen den Pos. und dem Belegkopf besteht eine 1:n-Beziehung, da ist keine weitere Tabelle dazwischen erforderlich.

Allerdings ist unbedingt eine Artikel-Tabelle notwendig.

Einige wertvolle Anregungen findest du sicher auch in diesem Thema:

http://www.office-loesung.de/ftopic335132_45_0_asc.php

_________________
Beste Grüße

tk



a_230700.zip
 Beschreibung:

Download
 Dateiname:  a_230700.zip
 Dateigröße:  24.35 KB
 Heruntergeladen:  80 mal



Zuletzt bearbeitet von tk6 am 30. Okt 2009, 00:13, insgesamt einmal bearbeitet
astern
Datenmodell-Missionar


Verfasst am:
30. Okt 2009, 00:11
Rufname: Andreas
Wohnort: Rastede


Re: AW: absoluter neuling mit kleinem problem wegen beziehun - Re: AW: absoluter neuling mit kleinem problem wegen beziehun

Nach oben
       Version: Office 2007

Franz86 - 29. Okt 2009, 23:03 hat folgendes geschrieben:
das mit einer zusätzlichen kundentabelle wollte ich zwecks übersichtlichkeit zunächst weglassen.


Das geht nicht! Das ist so, als wenn Du als Fahranfänger sagst: "Die Bremse wollte ich zwecks Übersichtlichkeit zunächst nicht benutzen." Dann kannst Du zwar auch fahren, aber knallst bald gegen den nächsten Baum. So wird es Dir mit der DB auch ergehen, wenn Du etwas, was sein muss, einfach weglässt!

MfG
A*

_________________
1. Access-Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Access-Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!
tk6
SAP-Consultant


Verfasst am:
30. Okt 2009, 00:36
Rufname:

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

Habe nochmal ein paar Korrekturen gemacht. Für die Weiterarbeit muß ich dich auf Klaus und Astern verweisen, aus Zeitgründen.
_________________
Beste Grüße

tk



a_233500.zip
 Beschreibung:

Download
 Dateiname:  a_233500.zip
 Dateigröße:  19.03 KB
 Heruntergeladen:  43 mal

astern
Datenmodell-Missionar


Verfasst am:
30. Okt 2009, 01:00
Rufname: Andreas
Wohnort: Rastede

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

Aye, Aye,
ich übernehme ! Wink Anbei das Datenmodell!

MfG
A*

_________________
1. Access-Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Access-Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!



rechnungsDB_v05.jpg
 Beschreibung:
Datenmodell
 Dateigröße:  67.17 KB
 Angeschaut:  1289 mal

rechnungsDB_v05.jpg



rechnungsDB_v05.zip
 Beschreibung:
.mdb-Datei (2003er Format)

Download
 Dateiname:  rechnungsDB_v05.zip
 Dateigröße:  16.11 KB
 Heruntergeladen:  60 mal

KlausMz
Moderator Access


Verfasst am:
30. Okt 2009, 08:56
Rufname:
Wohnort: Irgendwo in der Pfalz

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

Hallo,
@Tk6
Zitat:
Allerdings irrt er in einem Punkt: Zwischen den Pos. und dem Belegkopf besteht eine 1:n-Beziehung, da ist keine weitere Tabelle dazwischen erforderlich.
Nein, da irre ich nicht, da sind wir eigentlich auch einer Meinung. Mit Postentabelle meine ich die Tabelle mit den Positionen. Und in dieser Tabelle wird eine n:1 Beziehung zum Belegkopf und eine n:1 Beziehung zum Artikel gebraucht. So wie es A* realisiert hat. Und in Deinem Beispiel ist es ja auch so.

@A*
Den Preis würde ich auch redundant in die Tabelle "tbl_bestellposition" übernehmen, sonst muss auch eine Preisliste mit Gültigkeitsdatum geführt werden. Denn Preise können sich ja ändern, die älteren Rechnungen aber nicht.

Und bei der Gelegenheit:
Ich würde in Feld und Objektnamen immer einen Großbuchstaben verwenden.
Z.B. "tbl_Bestellposition", "Art_id_f". Wenn man jetzt in VBA einen solchen namen verwendet, wird aus einem geschriebenen Kleinbuchstaben ein Großbuchstabe. Wenn nicht hat man einen Tipfehler. Meiner Meinung nach ist das recht hilfreich.
Aber das hat natürlich nichts mit der Funktionalität der DB zu tun.

_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
astern
Datenmodell-Missionar


Verfasst am:
30. Okt 2009, 11:58
Rufname: Andreas
Wohnort: Rastede

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

Hallo!
Hier kommt die Version 6. Ich habe die Hinweise von KlausMz eingearbeitet - und gleich noch etwas mehr (Rabatt, Skonto, usw.). Bin aber kein Buchhalter - vielleicht gibt's noch mehr...
Mit der Schreibweise der Namen hat Klaus auch recht. Ich hatte jetzt aber keine Lust, das nochmal alles zu ändern. Nächstes mal!

MfG
A*

_________________
1. Access-Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Access-Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!



rechnungsDB_v06.jpg
 Beschreibung:
Datenmodell
 Dateigröße:  93.55 KB
 Angeschaut:  1264 mal

rechnungsDB_v06.jpg



rechnungsDB_v06.zip
 Beschreibung:
.mdb-Datei (2003er Version)

Download
 Dateiname:  rechnungsDB_v06.zip
 Dateigröße:  17.26 KB
 Heruntergeladen:  91 mal

tk6
SAP-Consultant


Verfasst am:
30. Okt 2009, 13:32
Rufname:

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

... und zum Vergleich das Datenmodell "vom Buchhalter". Beim Vergleich bieten sich natürlich die Begriffe "zweckmäßig/weniger zweckmäßig für..." eher an als das Begriffspaar "richtig/falsch"... Wink

Edit:
Bei Abfragen, die die Ermittlung des jeweils gültigen MWSt-Satzes haben, ist hier darauf zu achten, daß die Abfrage neben den Joins, die den Beziehungen entsprechen eine Bedingung beinhaltet, die den gültigen Mehrwertsteuersatz in Abhängigkeit vom Rechnungsdatum ermittelt. Also etwa in dieser Art:
Code:
... WHERE (((tbl_MwSTSaetze.von)<=[tbl_Rechnungskopf].[RechDatum]) AND ((tbl_MwSTSaetze.bis)>=[tbl_Rechnungskopf].[RechDatum]))...



shot_rech_korr.JPG
 Beschreibung:
 Dateigröße:  52.99 KB
 Angeschaut:  1251 mal

shot_rech_korr.JPG


KlausMz
Moderator Access


Verfasst am:
30. Okt 2009, 14:20
Rufname:
Wohnort: Irgendwo in der Pfalz

AW: absoluter neuling mit kleinem problem wegen beziehungen - AW: absoluter neuling mit kleinem problem wegen beziehungen

Nach oben
       Version: Office 2007

Hallo,
@Tk6
und wie machst Du das mit dem Verkaufspreis? Bei Deinem Modell wird auch noch eine Preisliste gebraucht, die ähnlich wie bei der Mwst den zum Rechnungsdatum gültigen Preis ermittelt.

_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
tk6
SAP-Consultant


Verfasst am:
30. Okt 2009, 15:12
Rufname:


Re: AW: absoluter neuling mit kleinem problem wegen beziehun - Re: AW: absoluter neuling mit kleinem problem wegen beziehun

Nach oben
       Version: Office 2007

KlausMz - 30. Okt 2009, 13:20 hat folgendes geschrieben:
...und wie machst Du das mit dem Verkaufspreis?...
Das habe ich bewußt herausgelassen (d.h. für den Screenshot einige Tabellen und Felder aus der DB gelöscht), weil hier verschiedene "zweckmäßige" Modelle denkbar sind. Vorher sollte man aber die Voraussetzungen und die Erfordernisse abklären:

1. Sind die Preise auf ewig die gleichen? Bei dem abgebildeten Datenmodell müsste das so sein. Da es in der Realität (leider) nicht so ist, ist mein Modell also unvollständig.
2. Sollen die letztlich in Rechnung gestellten Preise in der Tabelle tbl_Rechnungsposition "redundant" gespeichert werden?
usw.

Allein mit der Frage 2. würde man aber hier im Forum wieder eine Riesen-Fachdebatte lostreten, die wollte ich umgehen. Im vorliegenden Datenmodell (aus dem Thema http://www.office-loesung.de/ftopic335132_45_0_asc.php ) war es so, daß der Preis aus dem Artikelstamm gezogen wurde und, wenn der Benutzer nicht eingriff, in die Tabelle tbl_Rechnungsposition geschrieben wurde. Zusätzlich gab es die Möglichkeit, selbst den Preis festzulegen oder einen prozentualen Rabatt zu wählen.

Die so produzierten Daten gaben sowohl für die Rechnungsgestaltung (Ausweis des letztlich berechneten Preises und getrennter Ausweis der Höhe des via Rabatt gutgeschriebenen Betrages versus Ausweis des "Originalpreises" in Re.-Pos., Berechnungsstaffel in der Rechnungsaufstellung und Ausweis der Rabattbeträge ebenfalls in der Berechnungsstaffel zum Endrechnungsbetrag) wie auch für die Buchung nach unterschiedlichen Buchungsmethoden alles her, was man braucht.

Außerdem konnte auf eine immer wieder zu aktualisierende Preislistentabelle (ohne die "alten Preise" zu löschen, also mal wieder eine der hier so beliebten "n:m-Zwischentabellen" mit > 1 Datensätzen zum selben Artikel) verzichtet werden.

Aus Sicht eines "Datenbankpapstes" vermutlich ein Sakrileg. Hier: Off-topic.

Edit:
Vgl. Abbildung unten
Erläuterung:
1. (rot) Situation nach dem Klick auf die Schaltfläche "Einzelpreis manuell ändern" (Pfeil)
2. Situation nach manueller Änderung des Einzelpreises; blauer Pfeil: durch drücken der Schaltfläche "Einzelpreis zurücksetzen" wird wiederum der Preis aus dem Artikelstamm ermittelt

_________________
Beste Grüße

tk



rechnungseingabe.JPG
 Beschreibung:
Erläuterung s. Text oben
 Dateigröße:  101.5 KB
 Angeschaut:  1220 mal

rechnungseingabe.JPG


Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: Neuling: Abfragen in Kontaktdatenbank 3 Tinker 703 11. Jan 2007, 16:28
Willi Wipp Neuling: Abfragen in Kontaktdatenbank
Keine neuen Beiträge Access Tabellen & Abfragen: Hilfe bei Thema Beziehungen 8 heino 592 26. Dez 2006, 13:19
heino Hilfe bei Thema Beziehungen
Keine neuen Beiträge Access Tabellen & Abfragen: Problem mit Beziehungen 1 rodes 487 23. Nov 2006, 08:30
stpimi Problem mit Beziehungen
Keine neuen Beiträge Access Tabellen & Abfragen: Beziehungen ja oder nein? 2 toc 596 20. Okt 2006, 14:44
toc Beziehungen ja oder nein?
Keine neuen Beiträge Access Tabellen & Abfragen: Probleme bei Erstellen von Beziehungen 1 Twister-3101 581 06. Sep 2006, 12:11
Gastuser Probleme bei Erstellen von Beziehungen
Keine neuen Beiträge Access Tabellen & Abfragen: Beziehungen (nein, keine Partneranzeige) 1 mädibo 596 28. Jan 2006, 08:40
blicki Beziehungen (nein, keine Partneranzeige)
Keine neuen Beiträge Access Tabellen & Abfragen: tabelle nverknüpfen Beziehungen 6 Gast 591 27. Sep 2005, 23:44
Gast tabelle nverknüpfen Beziehungen
Keine neuen Beiträge Access Tabellen & Abfragen: Importierte Tabelle mit vielen m:n Beziehungen aufteilen 6 joerg70 1001 12. Aug 2005, 19:23
joerg70 Importierte Tabelle mit vielen m:n Beziehungen aufteilen
Keine neuen Beiträge Access Tabellen & Abfragen: M:N Beziehungen um alle Datensätze zu sehen? 3 zuperwoman 686 04. Jul 2005, 10:46
stpimi M:N Beziehungen um alle Datensätze zu sehen?
Keine neuen Beiträge Access Tabellen & Abfragen: Tabellen in A2k, Beziehungen 1 Domainhunter 476 21. Jun 2005, 11:44
rita2008 Tabellen in A2k, Beziehungen
Keine neuen Beiträge Access Tabellen & Abfragen: Wer kann mir helfen? mehrere Tabellen mit Beziehungen 3 Markus N 604 20. März 2005, 15:40
MJ_Lan Wer kann mir helfen? mehrere Tabellen mit Beziehungen
Keine neuen Beiträge Access Tabellen & Abfragen: access xp - 2 beziehungen 1 ma81 476 21. Feb 2005, 21:01
blicki access xp - 2 beziehungen
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Microsoft Project