Office: (Office 2013) Kundennummer in allen Tabellen übernehmen

So, habe das mit den Beziehungen alles mittlerweile verstanden. Nun habe ich ein Baum aus Beziehungen.





Wie verfahre ich weiter, wenn ich alles automatisch machen möchte ? Ziel ist es, wenn ich ein Kunde anlege, dass alle weiteren Tabellen auch ein weiteren Eintrag bekommt.

Ich will nachher dann per Excel mit Sql query einzelene Datensätze ansprechen usw.

 

Hallo Zidinjo,

... gestatte mir, daß ich Dir widerspreche, daß Du das mit den Beziehungen alles verstanden hast.
Anfangen möchte ich mit der Tabelle für Kunden. Hier gehören der Ort und die Hausnummer mit Sicherheit nicht zusammen. Es fehlt die Straße.
Nach der Darstellung ist es zwar möglich, daß ein Kunde mehrere Häuser sich bauen läßt aber diese dürfen nicht in der gleichen Gemeinde oder Stadt sein. Es gib nämlich keine Straßennamen in dieser Tabelle.
Sinnvollerweise ist zunächst zu erstellen eine Tabelle mit den Daten für den Bauherren (tbl_Kunden) und dann eine Tabelle für die Bauprojekte (tbl_Hausbau)
tbl_Kunde 1--->n tbl_Hausbau
Nach Deiner Aufteilung kann für ein Haus nur eine Kalkulation erfasst werden. Es gibt nicht die Möglichkeit eines Nachtrages, oder einer Änderung, oder wenn etwas zusätzlich gemacht werden soll, was ich mir bei einem Bauprojekt nur schwer vorstellen kann.
Die Tabelle für Mehrarbeiten ist ebenfalls nur auf eine Mehrarbeit begrenzt
Sollte eine zweite Kalkulation erforderlich sein, mußt du das ganze Bauprojekt nochmals anlegen was unweigerlich zu Duplikaten und zur Unübersichtlichkeit führt.

Verwirrend ist auch, daß das Bauobjekt mit drei Außenmaßen versehen ist. Ich vermute mal daß es sich hierbei um Länge, Breite und Höhe handelt.
Die Felder sollten sinnvollerweise dann auch so benannt werden.
Demnach werden nur rechteckige, oder quadatische Gebäude erstellt, bzw. kaluliert. Wie trägst Du dann einen L-Bungalow ein??

In der Tabelle Kalkulation gibt es Verbindungen zu Mehrleistung und Minderleistung. Nach der vorliegend Struktur ist hier auch nur eine Mehr- oder Minderleistung möglich und nötig. Dies geht nach meinem Verständnis and der Realität vorbei. Denn wie wird Die Mehr- oder Minderleistung definiert?
Ich kann mir nicht vorstellen, daß ein Teilprozess eines Arbeitsprozesses nicht durchgeführt wird.

Was verstehst Du unter "alles"

Wird er nicht, da ein Eintrag in der Kundentabelle nicht automatisch einen Eintrag in den Tabellen auslöst welche in Beziehung mit den Kundendaten stehen. Selbst wenn dies per Anweisung ausgeführt werden würde, was soll dann erfasst werden?

Da Dein Ansinnen, wie mir scheint, schwerpunktmäßig auf dem Abruf von Daten aus Access nach Excel zu liegen scheint, so denke ich wäre ein Export der Excel daten in eine Textdatei einfacher um sie von dort wieder einzulesen.
Denn selbst wenn Du, in Excel, nach Kundennummern bislang gesucht hast, wie willst Du bei Abfragen der Kundennummer oder der ID alle gefundenen Daten --- hier Häuser mit Kalkulation, darstellen, bzw einlesen? Da brauch nur ein Kunde zwei Häuser gebaut zu haben ....

Es wird ein Schuh daraus, wenn die Datenbank die Betriebsabläufe bzw den Geschäftsablauf wiederspiegelt. z.B. Der Kunde wird in der DB angelegt, alle relevanten Daten für die Kalkulation eingetragen und dann an eine Excel Vorlage weitergegeben um dort berechnet bzw. ausgewertet zu werden. Die Exceldatei wird dann gespeichert und der Speicherort in der DB in eine Tabelle geschrieben damit man sie findet und aufrufen kann. So kann man auch die Änderungen oder Nachkalukulationen verfolgen.

Schau Dir doch mal das beigefügte Beispiel an. Vieleicht verstehst Du dann das eine oder andere besser bzw. was ich meine. Suche auch mal nach Andreas Stern - Datenmodelle -- sehr lehr- und hilfreich.

 

Hallo,
die Tabellen mit den einzelnen ID sind auch ziemlich sinnfrei.

 

Hallo Knut, warum dieser Eiertanz mit Excel und Access? Mein Tipp wäre alles in Access zu machen. Falls es um schon größere in Excel vorhandene Daten geht, die kann man auch importieren.

 

Hallo Zidinjo,

möchte nicht über dein Datenbank-Modell ein Urteil fällen, steht mir ja nicht zu.
Aber, Ich möchte dir eine Beispiel-DB zu Verfügung stellen, die ich eben erstellt habe.
Hat nicht lange gedauert und ist aus diesem Grund auch noch nicht fertig gedacht
(soll ja nur eine Anregung für ein ordentliches DB-Modell sein und nicht mehr)
denke aber, dass sie jetzt schon wesentlich besser funktionieren würde als deine DB die du hier gezeigt hast.
Einige Daten habe ich dir eingefügt, zum besseren Verständnis.
Mein Tipp ist... viel Nachdenken bevor du dein Datenbank-Modell erstellst.

Excel und Access... würde ich auch fragen... warum, gibt es da einen besonderen Grund dafür?

PS: für verschiedene Haus-Typen könnte auch schon so manches vorgegeben werden!
Das habe ich aber nicht eingefügt, da ich deine Vorgangs- und Arbeitsweise mit der DB nicht kenne.

 

Das Problem ist, dass ich zurzeit alles in Excel programmiert habe und auch alles klappt. Das Programmieren sollte eig keine Probleme darstellen. Ich muss das mit der Datenbank erstmal alles verstehen. Wie es ausschaut ist dies ein ziemlich großes Thema und so eine flache Datenbank, die ich in Excel habe, soll und darf man nicht in Access realisieren.

Ich werde die Tage weiterhin lernen und es kommt bald ein update über mein Beziehungsbaum.

Edit* Kurze Frage ist das möglich, dass eine Tabelle nur aus FK und Primärkeys besteht ? Wenn ja, werden solche Tabellen benutzt ? Weil meistens ist dies doch unnötig, da keine weitere Information in die Tabelle hinzugefügt wird.

z.b Tabelle Bauhaben hat Elemente : Kunde, Haus und Finanzen, die 3 Elemente sind Fk.

 

Servus Zidinjo,
google mal: Datenmodell entwickeln: Welche Tabellen und Beziehungen?

 

Woraus ziehst Du diesen Schluss? Aus der Lehre, den Vorgaben Deines Chefs oder Deiner eigenen Meinung?

 

\@Zidinjo:

Hier liegt womöglich noch eine Wissenslücke vor.
Es gibt ausser den Tabellen mit 1:n Beziehungen auch Tabellen, in welchen über m:n Beziehungen nur Schlüsselfelder aus vielen Tabellen gespeichert und verwaltet werden.
Dann gibt es da auch durchaus Tabellen (Zwischentabellen genannt), deren Inhalt anzuschauen sinnlos ist, denn es sind nur noch Zahlen; Zahlen, welche aus einer PK-Spalte und beliebig vielen (bis zu 254) FK-Spalten stammen können.
Wenn man nun weiss, dass ein Datensatz bis zu 255 Felder haben kann und
dass der Inhalt von 254 Felder nur durch Angabe des PK zu jederzeit abgebildet werden kann und in rel. Datenbanken auch abgebildet wird, indem
man schon vorhandene Daten einfach blitzschnell auslist und anzeigt und dadurch keine doppelte Daten vorkommen können.....usw.
Siehe das Prinzip von relationalen Datenbanken.
A. Kelz: Relationale Datenbanken

Wie kann man nun eine solche m:n Tabelle wieder für den Anwender in
brauchbare und lesbare Ergebnisse umwandeln?
Man benutzt die Möglichkeit der Abfragen, in welchen man Daten wieder zusammenführen und lesbar machen kann.
Diese Abfragen speichern keine Daten, sondern klauben blitzschnell schon vorhandene Daten zusammen und zeigen sie an.
Diese Abfragen können im Gegensatz zu Tabellen zusätzlich Berechnungen durchführen, sortieren, filtern und noch vieles mehr.
Diese Abfragen arbeiten auch im ungeöffneten Zustand automatisch und absolut zuverlässig.
Diese Abfragen können statt der Tabellen auch als Datensatzquellen von Formularen und Berichten benutzt werden.
usw...usw.

 

\@Zidinjo:
Ich hab mal ein Beispiel erstellt.
Darin gibt es Stammdatentabellen für alle möglichen Filmkünstler, welche beliebig erweiterbar sind. Dafür gibts auch schon Formulare.
Diese Tabellen sind nur in der Tabelle für die Regie etwas ausführlicher als Beispiel. (bis zu 255 Felder möglich)
Es gibt natürlich auch eine Tabelle mit Filmtiteln.
Ich will in der DB mir eine persönliche ideale Besetzung in verschiedenen Filmen erstellen. Das Beziehungsmodell zeigt Dir meine Intuition.
Nachdem man in den Stammdatentabellen über die zugehörigen Formulare
die entsprechenden Daten eingegeben hat, kann man im ENTSCHEIDENDEN
FORMULAR 'frm_IdealCrew' sich nun alles zusammenstellen.
Ich hab Dir die Beispiele für alle Kombis in der Entwurfsansicht ausgearbeitet.
Absichtlich musst Du in den rot gefärbten Kombis das noch nachbauen wegen des Lerneffektes.
Du musst jetzt noch herausbringen, warum in den Kombis "human" lesbare Werte stehen statt nur Zahlen, wie sie in 'tbl_IdealCrew' zu sehen sind.

 

Hallo ohrkester

ich finde es ja toll, dass du so auf die Schnelle eine Beispiel-DB machst. Ich frage mich allerdings, ob das in diesem Fall sinnvoll ist, jemandem der von DB-Design keine Ahung hat, mit einem Beispiel aus einem komplett anderen Gebiet (mit zudem noch etwas speziellem Gedanken dahinter) helfen zu wollen. Bzw. die Datenmodellierung klar zu machen.

@Zidinjo
Auch der neueste Wurf ist jenseits ... die Kommentare zeigen es. Tabellen mit nur einem Primärschlüssel und keinem einzigen Feld machen jetzt NULL Sinn!
Vergiss einfach mal das Ganze, was du in Excel gemacht hast.
Entweder du bist Willens, eine richtige Access Anwendung zu erstellen und was zu lernen - oder dann bleib bei Excel. Eine Kombination mit Eingabe in Excel und Daten in Access oder umgekehrt ist Schwachsinn! Jedes der beiden Tools hat seine Berechtigung:
Excel ist für komplexe Berechnungen mit relativ einfachen Daten, Grafiken rasch und einfach erstellen, Diagramme, Kreuztabellen etc. Am meisten wird ja Excel von Controllern verwendet.
Access hingegen ist ein in sich funktionierendes Datenbanksystem, welches mit Formularen und Berichten genügend Möglichkeiten bietet, eine für den Endbenutzer komfortable Oberfläche (GUI) zu erstellen und die Eingabe-Möglichkeiten benutzerfreundlich zu gestalten, sowie Auswertungen zu gestalten.

Access legt aber NIE automatisch in anderen Tabellen Datensätze an. Dies erreicht man dadurch, dass man entsprechende Formulare erstellt, welche Tabellen und/oder Abfragen als Datenquelle haben. Dazu ist es aber unerlässlich, dass man VORHER ein sauberes Datenmodell aufbaut.
Um dies machen zu können, muss man zuerst mal die Aufgabenstellung klar definieren:
WAS will ich speichern und aus dem Businessprozess abbilden können? In welcher Beziehung stehen die einzelnen Objekte die ich brauche. In deinem Fall
Kunde - Haus/Häuser - Kalkulation (auch mehrere pro Haus, wie erwähnt)
Habe ich in einer Tabelle ein Feld, das in mehreren Datensätzen identisch vorkommen kann, dann ist das ein Kandidat für eine 1:N Tabelle.
Klassiker: Kunden - Ortschaften. Man legt die PLZ und den Namen des Ortes NIE direkt in der Kundentabelle ab, sondern erstellt eine Tabelle tbl_Ort in der jeder Ort eben nur einmal vorkommt. Jeder Eintrag hat einen Primärschlüssel, das ist mit Vorteil ein Autowert. In der Kundentabelle ist EIN Feld als numerischer Fremdschlüssel in das dann der Primärschlüssel des betreffenden Ortes kommt.
Ob man die Strasse auch noch als separate Tabelle ablegt, ist Geschmacksache, bei wenigen Datensätzen eher nicht, bei einer Kundendatenbank wie z.b. Zalando sicher.
(Die Strassen sind dann auch noch mit dem Ort verknüpft um plausibel zu sein, eine Züricherstrasse gibt es in Basel nicht, aber eine Zürcherstrasse, aber so weit gehen wir mal nicht ...)

Deine Kundentabelle ist also schon mal falsch ...
Welche Felder in die tbl_Haus müssen, das musst du selbst wissen (Hinweise, dass es da "Mängel" gibt, wurden gemacht). Der Primärschlüssel muss eindeutig benamst werden, ID ist sicher ungenügen, also Haus_ID (wie du es ja bei Kunden_ID richtig gemacht hast)
tbl_Kalkulation gehört sicher nicht in eine 1:1 Beziehung - auch das wurde gesagt.
Eine Kalkulation besteht aus diversen Elementen, in tbl_Kalkulation muss dann die Haus_ID als Fremdschlüssel.
Dann muss man in der Kalkulation nicht jeden Bestandteil aufführen, sondern einen Fremdschlüssel auf eine Tabelle tbl_Kalkulations_Komponente.
Darin werden sämtliche möglichen Komponenten erfasst, da bin ich ja eben nicht der Fachmann, ich leite mal aus deinen Feldern ab:
1 = Interne Kalkulation
2 = Ausbaugewerke
3 = Geschlossener Rohbau
4 = Mehrleistung
5 = Minderleistung

Was du mit "Buttonspeicherung" und "ColorCells" meinst, erschliesst sich mir überhaupt nicht, sieht aber nicht gerade nach etwas im Zusammenhang mit Hausbau aus ...

In der tbl_Kalkulation gibt es dann einen Fremdschlüssel auf tbl_Kalkulations_Komponente und wohl noch Felder für Masse/Einheiten und auch einen Betrag !
Wie willst du sonst kalkulieren ?

du hast dann eine "Auflistung" von Komponenten, mal einfach dargestellt:

Code:

Bau das mal so auf und komm dann wieder!

 

\@jmc:

Ich beweise mit meinem Beispiel, welches absichtlich nichts mit der gestellten Problematik zu tun hat, dass es Tabellen (m:n) geben wird, welche nur aus
Zahlen (Long integer Schlüsselfeldwerten) bestehen und absolut sinnvoll sind.
Mir ist bewusst, dass es viele Menschen gibt, welche anhand von Beispielen etwas besser begreifen als anhand von theoretischen Ausführungen der Beispiele.
Excelfreunde können damit anfangs nichts anfangen und auch Accessfreunde sollten maximal während der DB-Entwicklung darauf direkt schauen.
Ich habe auch absichtlich rote Felder eingefügt, anhand welcher man durch "Nachkauen" Verständnis und Verstehen aufbauen kann.
Ansonsten verweise ich doch ziemlich klar auf ein paar notwendige Links, um relationale Datenbanken zu verstehen.

UND: Du überforderst mit Deiner kompletten und komplexen theoretischen Ausführung den Anwender.
Step by Step ist richtiger meines Erachtens.
Allerdings auch aufwendiger für den Lehrenden bzw. besser gesagt den Beratenden.