Office: (Office 2013) Datenbank Felder Zuordnen

Dieses Excel-Denken musst Du bei Access völlig über Bord werfen.
VBA kann Dir später mal helfen, wenn es um das Designen von Formularen und Berichten geht.
Erst einmal geht es nur um Bleistift und Papier, um ein möglichst optimales
Tabellenmodell zu erstellen.
Der GPSWanderer hatte da zwar schon mal eins erstellt. Aber Du hast das halt noch nicht kapiert gehabt. Das kannst Du Dir auch immer wieder mal ansehen,
während Du weiter arbeitest.

Relationale Datenbanken (Access gehört dazu) sind so aufgebaut, dass es möglichst keine unnötigen doppelten (redundanten) Datensätze geben kann.
Daher bekommt jeder Datensatz einen eindeutigen Zahlenwert im PK von Access zugeteilt.
Jeder Datensatz in einer Tabelle kann in bis max. 255 Feldern Daten aller Art
zu diesem Datensatz aufnehmen.
Um nun an diese 255 Inhalte zu kommen, reicht nun einfach die Kenntnis des PK-Wertes und Access spuckt diese Inhalte auf Wunsch aus.

Und nun studiere mal den Link weiter.

 

Besser perID (PK) und perID_f (FK)
Der FK sollte den PK möglichst deutlich widerspiegeln, da es später komplexe
SQL-Codes geben wird, in denen man möglichst übersichtlich die Namen erkenn soll.

 

Stimmt, ist tatsaechlich besser und deutlicher.

Ja, mache ich der Link ist ein Hammer für mich.

Leser leihen Bücher.
Bücher sind von Verlagen.
Bücher stehen in Regalen.

Ein Tolles beispiel.

Ganz Herzlichen Dank nochmals, melde mich spaeter noch mal.
Bin noch am lesen! *wink.gif*

 

da es in diesem "gesperrten" Office-Forum Link keine Möglichkeiten gibt,
sich die dort abgelegten Beispiele herunter zu laden,
geb ich Dir noch diesen Link
A. Stern: Keine Angst vor Microsoft Access! - ADaMo

 

Hallo,

hier würde man 3 Tabellen verwenden.

- Personen
- Kontaktart (Telefon mobil, Festnetz, Fax usw. je ein Datensatz)
- KomEinträge (je Eintrag ein DS mit FS zur Person und FS zur Kontaktart).

Kunden und Lieferanten gehören in eine Tabelle.

 

Vielen Dank für den neuen Link.

Leider gibt es von Adamo keine 64bit version und ich benutze 64bit.

Nun werde ich in meiner VirtualBox Windows7 die 32bit Access instalieren.

Bin gespannt auf Adamo *Smilie Danke nochmals

 

Jetzt bin ich aber verwirrt Klaus. Kunden und Lieferanten haben doch sehr verschiedene Daten, wie sollen sie den in eine Tabelle gepackt werden?

 

Welche denn? Beide haben Namen, Adresse, Ort, ... Mir fällt da jetzt grad nix Verschiedenes ein, was nicht sowieso in eine andere Tabelle als die Stammdatentabelle gehört (Leistungen, Rabatte, Sonderkonditionen, Ansprechpartner ...).
maike

 

hmm... also soweit ich weiss ist der Lieferant, der dir die Ware ins Haus bringt...
(Verkaeufer)

und Kunde, der dir die Ware abkauft (Kaeufer). Oder nicht? *confused.gif*

Bitte korrigiert mich!

 

Die Frage ist, ob in der Tabelle die gleichen Informationen/Daten dazu gespeichert werden, wie ich schon sagte, Name, Adresse etc.
Kunde/Lieferant kann meinethalben noch durch ein zusätzliches Feld (eine 1 für Kunde, eine 2 für Lieferant) zur Erleichterung des Filterns gekennzeichnet werden - aber unterschiedliche Daten sehe ich da keine.
maike

 

Das ist mir jetzt sehr Verstaendlich. Hurraaa, und Herzlichen Dank.

Also alle Felder erstellen (İnformationen und Kontakte) und zusaetzlich ein Feld, wo man sehen kann, ob dieses ein Lieferant oder Kunde ist.

wau,,, nun bin ich jetzt um eine Erfahrung reicher. *Smilie

 

Hallo!

... das könnte aber auch der Zusteller sein. (SCNR *wink.gif*)


.. manchmal ist ein Lieferant auch ein Kunde oder umgekehrt. *wink.gif*


Ob man eine oder mehrere Tabellen verwendet, hängt vom Bedarf ab.
Eine allgemein gültige und einzig richtige Struktur gibt es meiner Meinung nach nicht.

Ich behaupte einfach einmal, dass allgemein folgendes gelten kann:
Kunden und Lieferanten haben viele ähnliche Datenbereiche: Firmenname, Adressen, Ansprechpartner u. ä.

Sie haben aber auch spezielle Daten: Kunden-/Lieferantenummer
Kunde: Rechnungsadresse, Lieferadresse usw.
Lieferant: ...

Wie man das in einem Datenmodell darstellt, hängt von den benötigten Daten und deren Einsatz ab.


Ich stelle das gerne in meinen Anwendungen (meist B2B-Daten) so dar:

* Eine Tabelle mit den Firmendaten (Kunden, Lieferanten, Zusteller oder auch nur Firmenkontakte in nur einer Tabelle => Datenstamm muss nicht mehrfach gewartet werden.)
* Eine Tabelle für die Adressen (1 Unternehmen kann mehrere Adressen haben)
* Eine Tabelle für Personendaten (.. später für AP benötigt)
* Eine Tabelle für die Ansprechpartner (n:m zw. Firmen und Personen)
* ...

* spezielle Tabellen für die Lieferanten, in denen nur die Daten abgelegt werden, die nur ein Lieferant hat. (1:1, 1:n oder n:m-Beziehung - je nach Bedarf)
* genauso für Kunden-spezifische Daten


Layout für die Anwender:
Es gibt eine Hauptmaske - je nachdem, ob die Firma/Person ein Kunden und/oder Lieferant ist, werden in einem Registerblatt Seiten aktiviert, die die Kunden/Lieferantendaten in Unterformularen zeigen.

Über eine Liste kann man die Kunden und Lieferanten filtern und auswählen.
Wenn der Anwender einen Adresse für eine Bestellung auswählen will, wird standardmäßig die Firmen-Auswahl auf Lieferanten vorgefiltert.


... das bedeutet aber nicht, dass dieser Aufbau für jede Anwendung passt.

mfg
Josef

 

Hallo Josef, Danke für deine Ausführliche Information.

Dann schreibe mir doch bitte mal, was ich benötige?

Beispiel:
Ich bin eine Firma und stelle Büro Möbel her.

Ich kaufe Waren (Roh)
Ich stelle Möbel her
Ich Verkaufe Möbel

dazu noch:
Ich kaufe fertige Möbel und Verkaufe sie weiter mit eigene Möbel.

Das heisst:
Den Bürotisch baue ich selber, abe die Stühle kaufe ich von X-Firma

Die kombination Tisch und Stühle Vekaufe ich an X-Firmen.

Danke im Voraus.

 

Das spart mir den ganzen Sermo, da es sehr differenziert erklärt wurde.

@Accessbeginner: Diese Denksportaufgabe ist eher Dein Bier und Du solltest
Deine Überlegungen dann zeigen, anstatt sie Dir vorkauen zu lassen.
Gehe stur nach den Tutorials vor. Da ist all das berücksichtigt (soweit ichs noch im Kopf hab).

 

Ich werde dein Rat folgen, Danke

Erforsche grad Adamo