collapse

* Benutzer Info

 
 
Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?

* Wer ist Online

  • Punkt Gäste: 138
  • Punkt Versteckte: 1
  • Punkt Mitglieder: 1

Es sind keine Mitglieder online.

* Forenstatistik

  • stats Mitglieder insgesamt: 14260
  • stats Beiträge insgesamt: 69842
  • stats Themen insgesamt: 9396
  • stats Kategorien insgesamt: 5
  • stats Boards insgesamt: 17
  • stats Am meisten online: 415

Autor Thema: Relations-Tabelle sinnvoll?  (Gelesen 9685 mal)

Offline Fredda

  • Newbie
  • Beiträge: 11
Relations-Tabelle sinnvoll?
« am: Mai 10, 2010, 06:24:48 »
Hallo liebe Access-Freunde!

Ich fange gerade erst an, mich mit diesem Programm zu beschäftigen, soll aber möglichts bald den ersten (schriftlichen) Entwurf für eine Datenbank fertig haben. Habe mich nun schon durch ein paar Tutorials bemüht und kenne einige der Grundsachen.
Was mir eher Probleme bereitet: Wenn ich Relationen erstelle, wie macht sich das nachher im Formular bemerkbar?

Im Moment habe ich meine Datenfelder auf 7 Tabellen verteilt und weiß nicht so genau, wie ich diese nun verbinden soll. Daher hatte ich überlegt, quasi eine zusätliche Tabelle zu erstellen, mit der ich all die anderen Tabellen verknüpfe? Denn ich muss bei einer neuen Dateneingabe ja alle 7 Tabellen benutzen und wenn ich Abfragen starte, brauche ich meistens auch Daten aus fast allen Tabellen.

Mir ist auch noch nicht so ganz klar, wie es nachher aussieht, wenn ich bspw. die Besitzer_ID aus der Besitzer_Tabelle mit der "Mutter"_Tabelle (also die Relationstabelle) verknüpfe. Was genau sehe ich dann im Formular? Und wo gebe ich die BesitzerDaten ein und wie weiß ich, welche ID ich in die Mutter_Tabelle eingeben muss?

Ich hoffe, es ist nicht zu unverständlich...
Ich würde mich sehr über ein paar aufklärende Antworten freuen!

Bis dahin,
Fredda
 

database

  • Gast
Re: Relations-Tabelle sinnvoll?
« Antwort #1 am: Mai 10, 2010, 07:46:39 »
Schönen guten Morgen,

Zitat
Ich hoffe, es ist nicht zu unverständlich...
Nein, es sind typische Fragen, die zu Anfang IMMER wieder auftauchen. Es gibt auf www.dbwiki.de relativ einfache Erklärungen zu Datenmodellierung und Datenbankplanung allgemein.

Im Prinzip ist es das Thema, um welches sich die Datenbank dreht der bestimmende Faktor, welche Informationen in welchen Tabellen abgelegt werden. Wobei dann die Zusammensetzung der Daten in den einzelnen Tabellen ganz bestimmten Regeln unterliegen. Diese Regeln werden als die Normalformen bezeichnet.
Grundsätzlich solltest du immer davon ausgehen, dass JEDE Tabelle einen ID Wert besitzt. Dieser ID-Wert ist in seiner Form MEIST eine Zahl und wird beim Erstellen eines Datensatzes AUTOMATISCH angelegt (Autowert).
Diese ID stellt den Primärschlüssel dar, also ein UNIQUE-Wert, der einen Datensatz EINDEUTIG kennzeichnet. Gibt es zu einer Tabelle eine weitere Tabelle mit Informationen zum gleichen Thema spricht man von einer Mastertabelle und ihrer Detailtabelle.
Zum leichetern Verständnis sei eine Einkaufsrechnung angeführt. Die Mastertabelle (z.B. tblRechnung) würde demnach die Kopfdaten der Rechnung enthalten, also zuerst mal eine RechnungsID, Informationen zum Kunden, das Rechnungsdatum, die Rechnungsnummer, etc. Die zugehörige Detailtabelle (z.B. tblRechnungsdetails) die dazu gespeicherten Rechnungsdetails, also Informationen zum verkauften Artikel, die Anzahl, den Einzelpreis - und GANZ WICHTIG den Fremdschlüssel zuir Rechnungstabelle also die RechnungsID um festlegen zu können zu welcher Rechnung die Details gehören.
Nun befindet sich in der Detailtabelle eine Information zum verkauften Artikel also auch in diesem Fall wiederum dessen ArtikelID welche ihrerseits mit dem Primärschlüssel der Tabelle tblArtikel in verbindung steht sowie in der Rechnungstabelle die Information zum Kunden, welche ebenfalls eine Primär- Fremdschlüssel- Beziehung zur Tabelle tblKunden zeigt.

Zitat
Im Moment habe ich meine Datenfelder auf 7 Tabellen verteilt und weiß nicht so genau, wie ich diese nun verbinden soll
Nach welchem Überlegungsschema hast du die geplant? Hast du die Daten willkürlich zusammengewürfelt?
Zitat
Wenn ich Relationen erstelle, wie macht sich das nachher im Formular bemerkbar
Hoffentlich positiv - wenn das Datenmodell stimmt, wirds auch so sein. Ein Formular ist nur eine Hilfestellung für den Benutzer um Daten in eine Tablle einzugeben, man verhindert dadurch, dass Benutzer direkt in die Tabllen 'reinhämmern' :)
Zitat
welche ID ich in die Mutter_Tabelle eingeben muss?
Das, beispeilsweise braucht dich gar nicht zu interessieren, das erledigt die Datenbank für dich wenn du daten in die Tabellen felder eingibst (wenn die ID als Autowert erstellt wird)

Erkläre doch nmal ein wenig genauer worum es bei deiner DB geht, ich bin mir sicher, dass du einige wichtige Tipps zum Datenmodell hier bekommen wirst.

LG

Peter


 

Offline Fredda

  • Newbie
  • Beiträge: 11
Re: Relations-Tabelle sinnvoll?
« Antwort #2 am: Mai 10, 2010, 23:30:36 »
Vielen Dank, lieber Peter, für deine Antwort!

Zitat
Nein, es sind typische Fragen, die zu Anfang IMMER wieder auftauchen.
Oh je, das hab ich mir ja fast schon gedacht.
Ein wenig klarer ist mir das mit der ID nun schon!

Zitat
Nach welchem Überlegungsschema hast du die geplant? Hast du die Daten willkürlich zusammengewürfelt?

Ich habe schon versucht, die Daten soweit wie möglich zu "normalisieren", aber es kann gut sein, dass ich da den ein oder anderen Fehler gemacht habe.
In der Datenbank geht es um ausgelieferte Maschinen. Hauptsächlich soll die Datenbank dazu genutzt werden, um Wartungsdaten und Garantieablauf zu bestimmen. Und dann natürlich, um was für eine Maschine es sich handelt, wo sie sich befindet, wem sie gehört, wer sie installiert hat etc.

Hier sind meine jetztigen Tabellenüberschriften:
Besitzer
MaschinenDetails (evtl. Wartungs- und Garantiedaten in eine eigene Tabelle?)
Ort
Installateur
Elektriker
Klempner
Kunde

Kunde kann auch ein Händler sein, der von uns gekauft hat und dann an den Besitzer weiterverkauft hat.

Da ich bei einer Abfrage ja prinzipiell alle Daten haben muss (Wenn ich z.B. abfrage, welche Maschinen im Mai 2010 gewartet werden müssen) fällt es mir schwer, die Beziehungen zu erstellen, da ich das Gefühl hab, ich muss alle Tabellen miteinander verbinden, damit ich bei einer Abfrage auch alle Daten bekomme. Bzw. bei einer Eingabe im Formular muss ich auch alle Daten eingeben. Oder ist das über die ID dann nicht mehr notwendig?

Wenn ich dann z.B. in der tblBesitzer auch die MaschinenDetails sehen will, was muss ich dann bei der Beziehung eingeben? Den MaschinenDetailsID in die tblBesitzer einfügen? Was ist dann meine "Verwandte Tabelle/Abfrage"? Alle Details oder reicht bspw. der MaschinenName?

Vielen Dank nochmal und sonnige Grüße,
Fredda
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23580
Re: Relations-Tabelle sinnvoll?
« Antwort #3 am: Mai 11, 2010, 09:49:02 »
Hallo,

vermutlich denkst Du viel zu kompliziert, bzw. auf zu "hohem Level"…



Überleg Dir zunächst nur, welche Daten sinngemäß für sich zusammengehören. Mindestens sind dies:

Maschinen  (alle Daten, Werte, die eine Maschine eindeutig beschreiben)
Besitzer   (alle Daten, die einen Besitzer eindeutig beschreiben)
Hersteller (alles, was einen Hersteller beschreibt)

Diese Daten(blöcke) kann man "Stammdaten" nennen. Für jeden "Block" ist infolge eine Tabelle zu erstellen.


In jeder Tabelle sollte (muß!) ein Primärschlüssel zur eindeutigen Identifizierung eines/r bestimmten Maschine, Besitzers, Herstellers eingebaut sein. 

Will man nun einer Maschine einen Hersteller zuordnen, muß in der Maschinen-Tabelle ein sogenanntes Fremdschlüsselfeld enthalten sein, das den Primärschlüsselwert des entspr. Herstellers aus der Hersteller-Tabelle aufnimmt. Das ergibt die Verbindung beider Tabellen und kann als Beziehung im Beziehungsfenster definiert werden (eigentlich aber dort nur notwendig, wenn man auch die referenzielle Integrität (als Funktionalität der Jet-Engine, dem Access-DB-System) nutzen will.)

Zusätzlich wird nun aber noch eine Tabelle gebraucht, die die "Verlaufsdaten" speichern kann/soll.

Verlaufdaten sind solche, die im Laufe der Zeit an Arbeitstätigkeiten an den Maschinen auftreten.  Das wären hier eben die "Wartungen". Auch hier ist zu überlegen, welche Daten nun zu einer solchen Wartung gehören, und es werden vermutlich weitere "Stammdaten" hinzukommen. :


z. B.:


tblWartung:

WID  (PK, Autowert)

W_MaschineID    (Fremdschlüsselfeld, enthält den Primärschlüsselwert einer Maschine)
W_Datum           (enthält das Datum der durchgeführten Wartung)
W_PersID              (Person(ID), die die Wartung durchführt.  Für "Personal" ist dann eine weitere Stammdatentabelle nötig)
W_ErsatzteilID   (verbrauchtes Ersatzteil, für "Ersatzteil"  ist ebenfalls eine weitere Tabelle nötig. Es ist aber zu überlegen, ob bestimmte Ersatzteile immer wieder benötigt werden, dann ist eine "Stammdatentabelle" sinnvoll, oder ob es praktisch immer andere Ersatzteile sind, dann bräuchte es hier nur ein normales Textfeld für die Ersatzteilbeschreibung.

W_Kommentar   (möglichst als Memo ausführen, damit die Warungsperson such genügend Platz hat, um den "Wartungsbericht"  zu schreiben.


.
.
.


(erhebt keinen Anspruch auf Vollständigkeit   ;)  )

Offline Fredda

  • Newbie
  • Beiträge: 11
Re: Relations-Tabelle sinnvoll?
« Antwort #4 am: Mai 11, 2010, 23:18:07 »
Hallo Franz!

Danke für deine Beschreibung! Das mit der Verlaufstabelle klingt sehr sinnvoll und ich habe es in meine Skizze eingebaut.

Allerdings habe ich leider irgendwie immer noch ein Problem damit zu verstehen, wie sich diese Beziehungen nachher auswirken.
Ich habe nun jeder Taballe einen Primärschlüssel zugeordnet und auch schon versucht, einige Fremdschlüssel (also Beziehungen) aufzubauen.
Bspw. habe ich der TblMaschinen die Primärschlüssel der tblInstallateur, tblKlempner und tblElektriker als Fremschlüssel zugeordnet.
Wie aber sieht das nachher in meiner Eingabe aus?
Wenn ich z.B. als erstes meine tblMaschinen ausfülle, bleiben die Fremdschlüssel dann ersteinmal leer? Und wie kann ich meiner Maschine dann den passenden Elektriker zuordnen? Ich habe ja auch manchmal denselben Elektriker für verschiedene Maschinen.
Oder muss ich zwingend erst die tblElektriker ausfüllen um meiner Maschinen denselbigen zuordnen zu können? Und muss ich dann von jedem meiner Elektriker den Fremdschlüssel (also die ID) wissen?

Edit: Nach ein wenig Rumprobiererei: Die meisten meiner vorherigen Fragen haben sich erübrigt, falls ich es richtig verstanden habe. So muss ich also tatsächlich ersteinmal meine tblElektriker ausfüllen und kann dann nachher bei der Eingabe tblMaschinen einen der Elektriker aussuchen. Meine letzte Frage steht allerdings noch, wie erkenne ich meinen passenden Elektriker?
Ich würde gerne bei der Eingabe in tblMaschinen nicht die Elektriker_ID als Auswahl bekommen, sondern z.B. Vor- und Nachname, ist so etwas möglich? Also, das ich quasi aus einer Beziehung zwei Auswahlfelder bekomme? (Beziehung Elektriker:Maschinen 1:n)

Edit2: Und doch noch eine Frage: Ich hatte eigentlich vor, ein paar Nachschlagefelder zu benutzen, habe aber nun schon des öfteren gelesen, das davon abzuraten ist. Ist es dann sinnvoll, weitere Tabellen zu erstellen und diese per Beziehungsfunktion zu nutzen?
Bspw. wollte ich ein Status Nachschlagefeld mit "Auf Lager", "Ausgeliefert" und "Installiert" erstellen. Sollte ich dafür nun besser eine neue Tabelle tblStatus erstellen und diese mit meiner tblMaschinen in 1:n Relation setzen?

Puh, viele Fragen... :)

Ich danke euch für eure ausführlichen und schnellen Antworten!

Fredda
« Letzte Änderung: Mai 12, 2010, 05:42:28 von Fredda »
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23580
Re: Relations-Tabelle sinnvoll?
« Antwort #5 am: Mai 12, 2010, 08:37:00 »
HAllo,



1) zu Edit2: KEINE Nachschlagefelder (---> in Tabellen) benutzen. NUR "tblStatus" (mit StatusID als PK und Bezeichnung) in Relation setzen (d. h. eigentlich in Formularen per Kombi auswählen und nur die entspr. ID speichern.)
2) Dateneingabe/-ausgabe/-änderung  NUR mittels Formularen (bzw. Berichten für (Druck-)Ausgabe)
3) Auswahl von Stammdatenwerten mittels Kombis (dabei das Kombi so einstellen, dass die gebundene Spalte das Primärschlüsselfeld enthält, diese Spalte aber nicht sichtbar ist (Spaltenbreite=0) . Sichbar können dann "lesbare" Saplten sein, z. B. Vorname, Zuname, etc. z. B. bei den Elektrikern). Das "Füllen" der Kombilisten passiert über passend (Kriterien!)  aufgebaute Abfragen, die auch dynamisch der Datensatzherkunft eines Komnis zugeordnet werden können.
3) Warum verschiedene Tabellen für Installateure, Klempner, Elektriker?  Das sind alles "Personen" und gehören in EINE Tabelle. Zur Unterscheidung des Einsatzbereiches oder Berufes wird lediglich ein Feld "EinsatzbereichID" als Fremdschlüssel (weitere Tabelle "tblEinsatzbereiche" erstellen!) in Tabelle "tblPersonen" mitgeführt.
4) ZUERST müssen die Stammdaten gepflegt sein, bevor sie ausgewählt werden können. ;-)
5) 1:n verbundene Daten (Tabellen) stellt man am Besten mittels Hauptform (gebunden an die 1-Tabelle) und einem darin eingebauten UFO-Steuerelement (zeigt (Endlos)-Form an, das an die n-Tabelle gebunden ist) an.
Z. B. :  Hauptform: frmMaschine,  UFO:  frmWartung
6) n:1 verbundene Daten am Besten mit Kombi auswählen (seltener Listenfeld oder UFO)



Grundlegend:   KEINE Datenmanipulationen in Tabellen selber. NUR Formulare dafür benutzen. Tabellen so weit bzw. sinnvoll  wie möglich, (und das ist oft sehr weit möglich ;-)  ) normalisieren. 



Offline Fredda

  • Newbie
  • Beiträge: 11
Re: Relations-Tabelle sinnvoll?
« Antwort #6 am: Mai 13, 2010, 05:57:08 »
Hey,

vielen Dank für deine Hilfestellungen!!

Zu 1.) bedeutet das, ich muss keine Relation setzen um Kombifelder zu erstellen? Irgendwie erschließt sich mir der Sinn der Beziehung dann immer noch nicht :( Und ich verstehe auch noch nicht, woher Access weiß, welcher Fremdschlüssel der richtige ist... Wähle ich das aus??

2.) merke ich mir! :)

3.) Da komme ich gerade nicht ganz hinterher... Ich dachte, das "Füllen" geschieht über Formulare?
Habe jetzt für die tblMaschinen eine tblStatus erstellt und eine Kombiliste erstellt in dem ich in der Entwurfsansicht "Nachschlagen" für das Statusfeld wie auf dem Bild "kombi" zu sehen ausgefüllt habe. Ist das so korrekt?
Leider bekomme ich es aber nicht hin, das ich mir aus der tblKunde Vor- UND Nachnamen anzeigen lassen kann.
Inwiefern helfen mir denn die Abfragen beim Füllen?

zu dem zweiten 3.) Hehe, das hab ich sogar schon vorher umgeändert :)

4.) Danke!

5.) Endlosform bedeutet, das ich bspw. nicht nur eine Person für meine Maschine auswählen kann sondern "unendlich" viele? Ist das so korrekt?
Wie sieht das denn nachher in meinen Tabellen/Abfragen aus? Habe ich dann dort meine Maschine mit all ihren Daten doppelt stehen, nur die Person ist anders?
Bspw so:
Maschine         Seriennr          Status            Person
xo                    1234               inst                 xy
xo                    1234               inst                 ab
?

6.) Also erstelle ich dann in meiner 1 Tabelle ein Kombifeld (wie bei 3.) beschrieben?


Vielen vielen Dank!


[Anhang gelöscht durch Administrator]
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23580
Re: Relations-Tabelle sinnvoll?
« Antwort #7 am: Mai 13, 2010, 09:08:05 »
Hallo,

wir verlieren uns hier in einem Grundkurs   ;)

1) Relationen sind logisch gesehen in einer (vernünftig aufgebauten, d. h. normalisierten ) DB immer vorhanden. Ob die Relationen für Access auch im Beziehungsfenster praktisch definiert werden, ist nicht zwingend erforderlich.  Nur wenn die interne Funktionalität der Referenziellen Integrität des Access-DB-Systems genutzt werden soll, müssen die Relationen und deren Typ im Beziehungsfenster klargelegt werden.  Trotzdem ist es sinnvoll, die Beziehungen zu definieren, allein um sich selbst den Überblick zu verschaffen.

2) na, glaube ich nicht, weil:  "  jetzt für die tblMaschinen eine tblStatus erstellt und eine Kombiliste erstellt …   "  ---> das sind Tabellen und keine Formulare   ;)


3)  Habe geschrieben:  "Das "Füllen" der Kombilisten passiert …"   
Weiterhin ist das Nachschlagefeld in der Tabelle NICHT  korrekt.
"Inwiefern helfen mir denn die Abfragen beim Füllen? "  ---->  Es wird die KombiLISTE gefüllt mit den Daten aus einer "Stammtabelle", damit ein Datensatz ausgewählt werden kann und der PK(!) daraus in der dem Form zugrundeliegenden Tabelle (z. B.: "tblWartung") als FK abgelegt wird. Das erfordert aber auch die "Bindung" des Kombifeldes an das entspr. Tabellenfeld (-->Steuerelementinhalt des Kombifeldes  besitzt den Tabellenfeldnamen)

5) Mit einem Endlosform wählst Du keine Personen für eine Maschine aus (warum überhaupt "für eine Maschine"??, Personen führen Wartungen durch...) . Personen werden über ein Kombi bei einer bestimmten Wartung ausgewählt.



6)  nein. Du sollst Formulare verwenden... ----> 2.)

database

  • Gast
Re: Relations-Tabelle sinnvoll?
« Antwort #8 am: Mai 14, 2010, 19:48:04 »
Hallo,
Zitat
wir verlieren uns hier in einem Grundkurs  
..aber wenn wir diesen schon führen dann ...
...darf ich dazwischen noch was einfügen :)

zu 1)  Ich persönlich kann vom Verzicht auf referenzielle Integrität nur warnen! Ausser dem Wunsch Daten systemlos kreuz und quer in die Tabellen zu schreiben fällt mir kein vernünftiger Grund ein, die referenzielle Integrität zu vernachlässigen. Erklärung zur RI hier: http://www.dbwiki.de/wiki.php?title=Referentielle_Integrit%E4t

Vielleicht hilft (auch) die Erklärung mit der Einkaufsrechnung aus meiner ersten Antwort um den Sinn von Beziehungen in einer Datenbank zu verstehen.
Vielleicht fällt es dir aber auch leichter mit folgendem Beispiel:

Ein Geschäft sperrt um 8:00 Uhr früh auf und du bist die erste Kunde an diesem Tag, krallst dir einen Einkaufswagen und betrittst den Laden.
Damit dich die Kassierin identifizieren kann, verpasst man dir am Eingang einen Primärschlüssel - du bist Kundschaft Nr1. und damit du deinen Wagen wiederfindest, wenn du ihn in einer Regalreihe stehenlässt um andere Artikel für deinen Einkauf zu holen, verpasst man dem Einkaufswagen einen Fremdschlüssel nämlich deinen Primärschlüssel.
Somit bist du mit deinem Einkaufswagen logisch verbunden, dein Einkaufswagen steht mit dir in Beziehung.
Immer wenn du einen Artikel in den Einkaufswagen legst, bekommt der ein kleines Schild aufgeklebt - den Fremdschlüssel den ForeignKey die Nummer 1 also deinen Primärschlüssel, dem PrimaryKey. Praktisch wie in einer Detailtabelle jeder Datensatz den Primäschlüssel seiner Mastertabelle mitgeliefert bekommt.
Ganz deutlich wirds dann bei der Kassa, da weiß dann die Kassierin ganz genau, dass die Artikel aus dem Wagen mit dem Fremdschlüssel 1 zu dir gehören auch wenn verschiedene Artikel aus verschiedenen Einkaufswagen auf dem Kassenband liegen. Würde das nicht so sein, könnte es passieren, dass du oder andere den Einkauf zu zahlen hätten, den sie nicht getätigt haben.
Die Geschichte mit der referenziellen Integrität passt natürlich auch in dieses Beispiel - sie verhindert nämlich, dass Waren auf dem Band liegen, die keiner in seinem Wagen hatte, oder Waren am Band liegen bleiben, obwohl der Kunde das Geschäft verlassen hat. Das heißt, Waren mit einem bestimmten Fremdschlüssel-Aufkleber müssen auf einen Kunden referenzieren, sonst verliert der gesamte Einkauf seine Integrität, seine Gültigkeit.
Schau dir zu diesem Thema bitte auch diesen Artikel und die Weiterführenden Verlinkungen an: http://www.dbwiki.de/wiki.php?title=Tabelle

Für den Punkt 3:
Nachgschlagefelder sind so ziemlich das Grauslichste, das einem in einer Datenbank über den Weg laufen kann. Nachschlagefelder haben so ziemlich gar nichts in einer Tabelle zu suchen, die verwirren nur und verfälschen ganz besonders für Anfänger die Zusammenhänge der Daten. Siehe dazu auch: http://www.dbwiki.de/wiki.php?title=Access_Anf%E4nger:_Die_Nachteile_von_Nachschlagefeldern!
Kombilisten hingegen werden auf Formularebene benutzt um in einen Datensatz den Primärschlüssel einer verknüpften Tabelle als Fremdschlüssel einzufügen.
Komilisten sollen daher auch zumindest 2 Felder enthalten - den Primärschlüssel der Herkunftstabelle und ein Feld, welches eine beschreibende Eigenschaft besitzt. Für den von dir angesprochenen Status KÖNNTE das bedeuten, dass die Kombiliste etwa so aufgebaut ist:

1   In Betrieb
2   Wartung
3   Instandhaltung
4   Verschrottet

Dabei werden in die Maschinentabelle die Zahlen geschrieben (die Fremdschlüssel zur Tabelle Status) die Texte werden beim Aufklappen der Listen sichtbar - als Vereinfachung, damit man sich nicht die Zahlen merken muss! ;D

zu 5 darf ich dann vielleicht noch hinzufügen:
Zitat
Endlosform bedeutet, das ich bspw. nicht nur eine Person für meine Maschine auswählen kann sondern "unendlich" viele?
Zuerst bitte klarerweise die Erklärung von DF6GL - und dann, Endlos- in bezug auf Endlosformular bezeichnet NICHT die Mögliche Anzahl von dargestellten Datensätzen!
Endlosformulare sind ein spezielle Form von Formularen, die in ihrer Darstellung dem Aussehen einer Tabelle sehr nahe kommen, aber den Vorteil bieten, dass neben mehreren anderen Sachen die einzelnen Felder formatiert werden können, dass mehr Gestaltungsmöglichkeiten bestehen um das Aussehen und somit die Lesbarkeit der dargestellten Daten zu verbssern.
Endlosformulare nehem daher auch KEINE wie auch immer gearteten Einfluß auf die Art und Weise der Datenspeicherung in einer Tabelle oder Tabellen.

Gruß
Peter
 

Offline Fredda

  • Newbie
  • Beiträge: 11
Re: Relations-Tabelle sinnvoll?
« Antwort #9 am: Mai 16, 2010, 23:42:49 »
Hallo Franz und Peter!

Puh, erstmal vielen Dank für eure Mühe, mir das ganze so ausführlich zu erklären!
Habe mir jetzt am Wochenende die Links zu DBwiki und aus der Signatur von Franz etwas genauer angeschaut und ein paar Access Bücher gewälzt..
Trotzdem habe ich manchmal das Gefühl, den Wald vor lauter Bäumen nicht zu sehen!

Ich habe nun schon mal ein Formular erstellt und Kombifelder eingefügt. Nach ein paar Probedurchläufen in einer Kopie meiner Datenbank "scheint" das auch ganz gut zu funktionieren.
Habe in einem der Links oder Bücher (ich weiß es grad nicht mehr genau) gelesen, dass Formulare "normalerweise" auf Abfragen basieren und nicht auf Tabellen. Kann man das so allgemein sagen? Ich habe momentan nicht das Gefühl, erst eine Abfrage erstellen zu müssen um meine Daten einzutragen.

Dann sitze ich auch gerade an einem Problem zwischen einer m:n Beziehung. Diese habe ich über eine Verbundstabelle in zwei 1:n Beziehungen aufgelöst und möchte dies nun über ein Listenfeld mit Mehrfachauswahl abspeichern.
Benötige ich dafür einen Code?

Vielen vielen Dank nochmals!

 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23580
Re: Relations-Tabelle sinnvoll?
« Antwort #10 am: Mai 17, 2010, 08:39:52 »
Hallo,

"..dass Formulare "normalerweise" auf Abfragen basieren und nicht auf Tabellen.."


Tabellen und Abfragen kann man aus dieser Sicht gleichstellen.   Bei Abfragen allerdings ergibt sich, falls man darin mehrere Tabellen verknüpft, das Risiko zu einer "nicht aktualisierbaren Abfrage", was dann zu nicht editierbaren Daten im Formular führt (in der Abfrage selber ist das dann auch schon so).  Abfragen sind (u. a.) sinnvoll, wenn nur vorbestimmte Daten aus einer Tabelle angezeigt/bearbeitet werden sollen, oder auch die Daten schon im Vorhinein sortiert werden müssen.


"über eine Verbundstabelle in zwei 1:n Beziehungen aufgelöst "  --->  Verbundtabelle ==>  n:m-Tabelle

"..dies nun über ein Listenfeld mit Mehrfachauswahl abspeichern."   ??  Was meinst Du genau damit?
"Benötige ich dafür einen Code?"  wenn das so stimmt, wie Du es beschreibst:  Ja



Offline Fredda

  • Newbie
  • Beiträge: 11
Re: Relations-Tabelle sinnvoll?
« Antwort #11 am: Mai 17, 2010, 10:19:24 »
Hallo Franz!

Danke zu deiner Aufklärung bzgl Abfrage. :)

Ja, meine Verbundtabelle ist damit eine n:m Tabelle. Ich hatte das allerdings so auf einer der Seiten gefunden, das man eine m:n Beziehung eben über eine solche Tabelle "auflösen" sollte.
Ich möchte nun meinen Personen (Klempner, Elektriker etc) Maschinen zuweisen. Es können aber mehr als eine Person an einer Maschine arbeiten und jede Person installiert meistens mehr als eine Maschine.
Dazu habe ich die tblPersonenMaschine erstellt und möchte im frmMaschinen nun ein Listenfeld mit Mehrfachauswahl erstellen. Die dort ausgewählten Personen sollen dann über ihre Primärschlüssel den Primärschlüsseln der Maschine in der Verbundtabelle zugeordnet werden.

Ich hatte mir dazu unten angehängte Beispieldatenbank heruntergeladen. Dort wird das Problem einmal mit UFo und einmal mit der Mehrfachauswahl gelöst. Habe mir den zugehörigen Code aus der Datenbank zwar angesehen, aber bei mir funktioniert es so nicht. ich vermute, das es an dem zusätzlichen Code für das UFo liegt? Den kann ich aber leider nicht rauserkennen, mangels Erfahrung mit SQL.

 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23580
Re: Relations-Tabelle sinnvoll?
« Antwort #12 am: Mai 17, 2010, 11:00:40 »
Hallo,

wir drehen uns im Kreise..


Überleg nochmal, wie die Daten zusammenhängen. Erstell dazu die Tabellen (wegen mir auch auf Papier) gemäß den Normalisierungsregeln.

Überleg, aus welchem Blickwinkel die Daten zu bearbeiten sind ( was die DB überhaupt leisten soll: Maschinen(wartung)-Verwaltung, oder Verwaltung von Personen, die Maschine warten sollen...)


Für Maschinen(wartung):

Haupt-Formular auf Basis "tblMaschinen" , darin UFO mit Endlosform auf Basis von "tblWartungen", wiederum darin Auswahl der akt. Personen über Kombifeld, das seine Listendaten aus "tblPersonen" bezieht.



Für Personen:
Haupt-Formular auf Basis "tblPersonen" , darin UFO mit Endlosform auf Basis von "tblWartungen", wiederum darin Auswahl der akt. Maschine über Kombifeld, das seine Listendaten aus "tblMaschinen" bezieht.

Offline Fredda

  • Newbie
  • Beiträge: 11
Re: Relations-Tabelle sinnvoll?
« Antwort #13 am: Juni 01, 2010, 23:53:43 »
Ich möchte mich hier nochmal herzlich für die Geduld und Erklärungen von euch bedanken!