Dezember 07, 2021, 13:33:48

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


Neuling - Walkthrough zur Datenbankstruktur

Begonnen von Ineksi, November 04, 2021, 15:33:39

⏪ vorheriges - nächstes ⏩

Ineksi

Hallo!

Wie oben schon geschrieben bin ich relativ neu im Umgang mit Access, aber habe die glorreiche Aufgabe bekommen, eine Datenbank zu basteln. Ich lese mich nebenher ein, aber ich werde Fehler machen. Faire Warnung hiermit abgesetzt ;)

Bisher gibt es eine funktionierende Datenbank, allerdings null Dokumentation davon und 90% der Datenbank sind nicht allzu feinsinnige Lösungen (Auswahlfelder, die direkt ins Formular geschrieben wurden etc.). Die neue soll wesentlich mehr Daten verwalten (auf einem recht alten Rechner, daher auch optimiert) und weitestgehend für Nutzer ohne Ahnung bedienbar sein.
Ihr seht das Problem, denke ich ;)

Es geht um Artikel, die zur Verschrottung, oder zur Reparatur und Weiterverkauf bei uns ankommen. Das beinhaltet schon die erste Herausforderung, weil Geräte auch wieder zurückkommen können. Wie ich das lösen kann, weiß ich bisher nicht, außer einem Gerät einen doppelten Datensatz zu geben und eine Art Sondernummer zuzuweisen.

Jedes Gerät hat Daten:
eine eigene Nummer - die hab ich zunächst als Primärschlüssel meiner Haupttabelle hergenommen;
einen Hersteller - die haben eine eigene Tabelle bekommen, ID ist PK;
eine Modellbezeichnung - Haupttabelle (die variieren einfach zu stark);
einen Gerätetyp und Details - hat auch eine eigene Tabelle, dazu gleich mehr;
Eingangs- und Ausgangsdatum - Haupttabelle;
eine (zentrale) Stelle an die geliefert wird und Käufer - eigene Tabelle, auch gleich dazu mehr;
einen Entsorger;
Reparaturen, die eine gewisse Zeit dauern und Material brauchen - zunächst mit der Haupttabelle, aber ich überlege, das auch auszulagern;
ein Gewicht pro verschrotteter Maschine (theoretisch kann man aber jeder eins zuweisen);
Checklisten und ähnliches, die aber nur ein Ja/Nein Ding sind und damit in der Haupttabelle geblieben sind.

Hersteller sind letztlich einfach nur Namen, eine Spalte, eine ID.
Gerätetypen + Details sind eine Art zweiteilige Kategorie, zwei Spalten. Daher angelegt als zB. Waschmaschine / 1000 Umdrehungen/min, Waschmaschine / 850U/min, Trocker / Kondenser. Zusätzlich eine ID.
Die zentrale Stelle und den Empfänger hab ich jetzt aktuell auf 4 Spalten, Zentrale Stelle / Name / Straße / Ort, auch mit ID als PK.

Die Datenbank muss theoretisch alle Teile separat abrufen können - welche Maschinen wann an die zentralen Stellen gegangen sind. Welche Maschinen noch nicht repariert oder verschrottet wurden. Wie viel an Gewicht dafür anfiel. Ich vermute bisher, dass ich das über Abfragen lösen kann, aber so weit bin ich noch gar nicht ^^'

Frage eins ist ergo: Macht das so Sinn oder würdet ihr das anders strukturieren? Gibt's vielleicht Strukturen, die ich übersehen habe?

Ganz lieben Dank für eure Geduld!

Beaker s.a.

Hallo,
Zeig doch erstmal, was du hast. Will sagen, poste ein Bild des
Beziehungsfensters mit allen Tabellen und allen Feldern sichtbar,
oder eine Beispiel-DB mit ein paar Spieldaten.

gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

Ineksi

Hi!

Sorry, dass das so lange gedauert hat, aber hier ist das, was ich bisher gebastelt hatte. Spieldaten kann ich auch noch nachliefern, aber da die Haupttabelle so breit ist, bringt das evtl. nicht allzu viel.

MzKlMu

Hallo,
für die Reparaturen ist eine extra Tabelle notwendig, je Reparatur ein Datensatz. Gesamtstunden ist überflüssig, wird stets berechnet und im Formular bei Bedarf angezeigt. Ebenso ist für die Checkliste als solches eine Tabelle und dann eine Tabelle zur Zuordnung der Checklistenpunkte zum Gerät.

Beziehungen sind grundsätzlich mit referentieller Integrität einzurichten.
Gruß
Klaus

Beaker s.a.

Hallo,
Auch wenn sich's gerade überschnitten hat.

Zitataber da die Haupttabelle so breit ist, bringt das evtl. nicht allzu viel.
Das ist schon mal der erste Fehler. Die Reparaturen gehören in eine eigene Tabelle
mit einem Fremdschlüssel (FK) zum Gerät; - beliebig viele Reparaturen (0 - n).
Warum haben Tabellen das Prefix "Form"? Ich persönlich verwende für Tabellen schon
lange keinen Prefix mehr, achte aber darauf sie mit der Mehrzahlform zu benennen.

Dann die üblichen Hinweise
- vermeide Sonderzeichen in Objektnamen (z.B. Geraete)
- bennene alle IDs dem Tabellennamen entsprechend
- setze in den Beziehungen die "referentielle Intigrität"

Neben der o.a. Reparatur-Tabelle würde ich auch eine Tabelle "Empfaenger" anlegen.
Da die Hersteller ja wohl auch eine (oder mehrere) Adressen haben würde ich diesen
Teil ganz anders aufbauen. Alle "Personen" (Hersteller/Empfänger) kommen in eine
Tabelle mit einem Kennzeichen ihrer Rolle; - Adressen werden per FK angebunden
(s.o.; - beliebig viele Adressen). Sollten die Eigenschaften der einzelnen Personen-
gruppen sehr unterschiedlich sein, bietet sich eine 1:1-Tabelle/Gruppe an.

Vermutlich (kenne ja deine Realität nicht) müssen da auch noch andere Felder aus
der Geräte-Tabelle in andere/eigene Tabellen.

gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

Ineksi

Hi!

Okay, ich seh schon, ich muss da noch ein bisschen was dran tun :)

Zitat von: Beaker s.a. am November 09, 2021, 12:10:39
Zitat von: undefinedaber da die Haupttabelle so breit ist, bringt das evtl. nicht allzu viel.
Das ist schon mal der erste Fehler. Die Reparaturen gehören in eine eigene Tabelle
mit einem Fremdschlüssel (FK) zum Gerät; - beliebig viele Reparaturen (0 - n).
Hier maximal 5, das haben wir inzwischen durch Statistik festgestellt. Oberhalb der 5 Reparaturen liegen wir üblicherweise außerhalb des Rahmens der Rentabilität, deswegen nur 5 :) Rentiert sich das Auslagern eurer Meinung nach trotzdem? Auch im Hinblick auf zukünftige Formulare.

Zitat von: Beaker s.a. am November 09, 2021, 12:10:39Warum haben Tabellen das Prefix "Form"? Ich persönlich verwende für Tabellen schon
lange keinen Prefix mehr, achte aber darauf sie mit der Mehrzahlform zu benennen.
Guter Punkt, arbeite ich dran. Die Ursprungsidee war, diese Tabellen mehr oder minder nur für die Formulare zu verwenden (Auswahlfelder und so; auch weil es einen Fall in der "alten" Datenbank gab, der so lief). Im Nachhinein schien die Verknüpfung sinnvoller. Wie gesagt, Anfänger - ich lern dazu, versprochen! ;)

Zitat von: Beaker s.a. am November 09, 2021, 12:10:39Dann die üblichen Hinweise
- vermeide Sonderzeichen in Objektnamen (z.B. Geraete)
- bennene alle IDs dem Tabellennamen entsprechend
- setze in den Beziehungen die "referentielle Intigrität"
So gut wie erledigt.
Bzgl. referentiell habe ich das Problem, dass ich den Kollegen (vermutlich wird es weitere Bearbeiter geben) nicht die Chance geben will, meine Auswahlen versehentlich umzuschreiben. Von daher hatte ich das bisher nicht drin. Das möchte ich tendenziell durch eine Dokumentation abdecken.

Zitat von: Beaker s.a. am November 09, 2021, 12:10:39Neben der o.a. Reparatur-Tabelle würde ich auch eine Tabelle "Empfaenger" anlegen.
Woran denkst du dabei? Empfänger hatte ich bisher nur im Hinblick auf die "VerkaufAn", wobei sich da auf einen zweiten Gedanken anbietet, die Entsorger dort mit zu hinterlegen und eine allgemeine "Empfänger" Tabelle zu schaffen.

Zitat von: Beaker s.a. am November 09, 2021, 12:10:39Da die Hersteller ja wohl auch eine (oder mehrere) Adressen haben würde ich diesen
Teil ganz anders aufbauen. Alle "Personen" (Hersteller/Empfänger) kommen in eine
Tabelle mit einem Kennzeichen ihrer Rolle; - Adressen werden per FK angebunden
(s.o.; - beliebig viele Adressen). Sollten die Eigenschaften der einzelnen Personen-
gruppen sehr unterschiedlich sein, bietet sich eine 1:1-Tabelle/Gruppe an.
Hersteller sind hier (glücklicherweise?) nur ein Merkmal wie zB eine Farbgebung oder dergleichen; sie haben in der Folge mit uns nichts mehr zu tun.

Zitat von: MzKlMu am November 09, 2021, 12:04:47Gesamtstunden ist überflüssig, wird stets berechnet und im Formular bei Bedarf angezeigt.
Dumme Frage, aber kann ich mir die dann auch durch die Abfragen holen, wenn es ein berechneter Wert ist?

Zitat von: MzKlMu am November 09, 2021, 12:04:47Ebenso ist für die Checkliste als solches eine Tabelle und dann eine Tabelle zur Zuordnung der Checklistenpunkte zum Gerät.
Die Checkliste muss ich glücklicherweise (noch) nicht mit dokumentieren, nur ihr Vorhandensein (oder nicht Vorhandensein) feststellen. Geb ich dir völlig recht, wenn ich sie mit erfassen müsste.

Ganz lieben Dank für eure Zeit und Gedanken!

MzKlMu

November 09, 2021, 13:21:09 #6 Letzte Bearbeitung: November 09, 2021, 13:31:00 von MzKlMu
Hallo,
Zitat von: undefined.. nicht die Chance geben will, meine Auswahlen versehentlich umzuschreiben.
was hat das mit RI zu tun ?
Die Auswahlen können auch mit RI umgeschrieben werden.
Es ist unerlässlich RI einzustellen, da gibt es keinen Spielraum. Ohee RI hast Du einen unkontrollierten Datenhaufen, aber keine Datenbank.

Die Gesamtstunden braucht man nicht in einer Abfrage, Abfragen (und Tabellen) werden immer über Formulare (und Berichte) angezeigt und dort lässt sich die Gesamtsumme immer ermitteln und anzeigen.

Noch eine Anmerkung zu Mehrbenutzer:
Eine Datenbank für den Mehrbenutzerbtrieb ist für eine zuverlässige Betriebsweise in Backend (nur die Tabellen) und Frontend (der ganze Rest) aufzuteilen. Dabei liegt nur das Backend zentral auf einem Server das Frontend braucht jeder User auf seinem PC. Jeder User braucht somit auch Access, mindestens als (kostenlose) Runtime. Wobei es auch nicht so einfach ist, aus einer Datenbank ein mit der Runtime lauffähige Version zu erstellen.
Und wenn es um Sicherheit (nicht nur der Daten) geht, so ist Access als Backend eher ungeeignet, hier wäre ein SQL Server vorzuziehen, von denen es auch einige kostenlos gibt. Mit einem SQL server als Backend können auch Rechte vergeben werden, was mit Access ein ziemlicher Aufwand ist.

In einer Firmenumgebung muss das alle gründlich bedacht werden.

PS und OT:
Warum muss man hier einen englischen Begriff verwendet (Walkthrough) den ein normal Sterblicher erst mal nachschlagen muss ?
"Anleitung" hätte es doch auch gut getroffen, oder nicht ? Aber wie gesagt, nur nebenbei.
Gruß
Klaus

Ineksi

Zitat von: MzKlMu am November 09, 2021, 13:21:09Hallo,
Zitat.. nicht die Chance geben will, meine Auswahlen versehentlich umzuschreiben.
was hat das mit RI zu tun ?
Gerade wenn RI eingestellt ist, die Auswahlen können auch mit RI umgeschrieben werden.
Es ist unerlässlich RI einzustellen, da gibt es keinen Spielraum. Ohen RI hast Du einen unkontrollierten Datenhaufen, aber keine Datenbank.
Okay, da hab ich vermutlich was missverstanden in den Strukturen.

Zitat von: MzKlMu am November 09, 2021, 13:21:09Die Gesamtstunden brauch man nicht in einer Abfrage, Abfrage (und Tabellen) werden immer über Formulare (und Berichte) angezeigt und dort lässt sich die Gesamtsumme immer ermitteln und anzeigen.
Cool! Muss ich nur noch rausfinden wie. Danke dafür :D

Zitat von: MzKlMu am November 09, 2021, 13:21:09Noch eine Anmerkung zur Mehrbenutzer:
Eine Datenbank für den Mehrbenutzerbtrieb ist für eine zuverlässige Betriebsweise in Backend (nur die Tabellen) und Frontend (der ganze Rest) aufzuteilen. Dabei liegt nur das Backend zentral auf einem Server das Frontend brauch jeder User auf seinem PC.
Und wenn es um Sicherheit (nicht nur der Daten) geht, so ist als Backend Access eher ungeeignet, hier wäre ein SQL Server vorzuziehen, von denen es auch einige kostenlos gibt. Mit einem SQL server als Backend können auch Rechte vergeben werden, was mit Access ein ziemlicher Aufwand ist.

In einer Firmenumgebung muss das alle gründlich bedacht werden.
Völlig nachvollziehbar, in dem Falle hab ich aber den Luxus, dass wir alle an einem Rechner hocken, nur eben schichtweise. :) Backup werde ich vermutlich trotzdem einrichten müssen, und im Idealfall (- das ist die nächste Herausforderung -) kriegen die anderen Kollegen ohnehin nur die Formulare zu Gesicht. Klickibunti wird ihnen hoffentlich zeigen, wo sie Sachen reinschreiben dürfen. :)

Danke für die Hilfe, kann ich sehr gut brauchen!

Ineksi

Und Walkthrough:
Ich komme aus'm Spielebereich, das ist'n bisschen Berufskrankheit.
Sorry dafür :(

MzKlMu

Hallo,
Zitat von: undefinedBackup werde ich vermutlich trotzdem einrichten müssen
Backup ist etwas völlg anderes als Backend.
Backup ist eine Datensicherung und Backend ist die Auslagerung von Tabellen in eine eigene Datenbank.
Im Frontend sind kein Tabellen mehr diese sind im Frontend nur zum Backend verlinkt/verknüpft.
Gruß
Klaus

Beaker s.a.

Hallo,
ZitatRentiert sich das Auslagern eurer Meinung nach trotzdem? Auch im Hinblick auf zukünftige Formulare.
Auf jeden Fall. Zwar nicht im Hinblick auf Formulare sondern im Hinblick
auf Nachhaltigkeit und einfache Auswertungen (Abfragen) ->
Zitatdas haben wir inzwischen durch Statistik festgestellt
Genau das (max. Reparaturen, durchschnittl. Anzahl) bekommt man mit Auf-
zählungsfeldern schlecht bis gar nicht hin.
ZitatHersteller sind hier (glücklicherweise?) nur ein Merkmal wie zB eine Farbgebung
O.K., dann brauchst du nur deren Namen. Um da beim Gerät Schreibfehler zu
vermeiden und eine einfache Auswahl (Kombi) zu ermöglichen, würde ich sie
aber trotzdem in eine eigene Tabelle schreiben, und beim Gerät einen ent-
sprechenden FK hinterlegen.

gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.