Hilfe beim Aufbau von Tabellen

[Björn P]

Hallo zusammen,

als Access Neuling stehe ich vor einem Haufen Arbeit zur Erstellung einer Datenbank zur Protokollierung von Störung an Windenergieanlagen in verschiedenen Windparks...
Dazu habe ich ein paar Fragen um ein vernünftiges Fundament zu haben.

Ich habe geplant mit 4 Tabellen zu arbeiten, bin mir aber nicht ganz sicher ob ich dabei die Normalform einhalte...

tblWindpark - enthält IDWindpark (Primärschlüssel) und die Namen der Windparks
tblWEA - enthält IDWea (Primärschlüssel) und die Seriennummern der Windenergieanlagen (WEA)
tblLink - verbindet die Windparks mit den WEA, hier würde ich dann nur die jeweiligen ID reinnehmen und eine Extra ID als Primärschlüssel

Da ist jetzt die erste Frage, ob so ein Aufbau überhaupt sinnvoll ist. Man könnte ja auch die tblLink nehmen und dort direkt alle Informationen reinschreiben...

Die 4. Tabelle tblLogbuch enthält: Datum, Uhrzeit, Windpark, WEA, Bemerkung
Über ein Formular sollen dann neue Datensätze in der tblLogbuch erstellt werden können.

Was haltet ihr von so einem Aufbau? Bzw. welche Variante ist zu bevorzugen?

Vielen Dank für eure Hilfe

Gruß Björn

[DF6GL]

Hallo,

der Aufbau wäre so schon richtig... keinesfalls aber: "Man könnte ja auch die tblLink nehmen und dort direkt alle Informationen reinschreiben". Genau damit würdest Du ja die Normalform(en)  verletzen.

In tblLogbuch ist "Windpark" ( "IDWindpark" ?)  falsch und überflüssig.  Diese ID ist schon über die Verknüpfung zu tblWEA bekannt.

Fraglich ist aber, ob die Felder in tblLogbuch ausreichend sind. Gibt es neben der "Bemerkung" keine weiteren Klassifizierung eines Protokolls?  (zudem würde ich "tblLogbuch" in "tblProtokolle" umbenennen)

[Björn P]

Danke erstmal für die schnelle Antwort.

Ich dachte in tblLogbuch (tblProtokolle) sollte auch Windpark (nicht die ID, sondern der Name) mit rein, damit man später im Formular den Windpark auswählen kann per DropDown Liste...

Ein Feld sollte noch dazu kommen. Und zwar eine Checkbox um anzugeben ob die WEA "ok" ist oder einen Fehler hat...
Ich würde auf lange Sicht auch gerne noch mehr Informationen aufnehmen, aber fürs erste Projekt wollte ich mir nicht zuviel vornehmen...

[DF6GL]

Hallo, 

wenn eine WEA ausgewählt wird, wird "automatisch" auch deren Windpark definiert. Das bestimmen die Datenbeziehungen.

" ob die WEA "ok" ist oder einen Fehler hat..."

Was heißt das denn? Wann (bei welcher Situation) ist eine WEA ok oder nicht ok?

[Björn P]

Die WEA ist z.B. "OK" wenn eine Wartung durchgeführt wird, oder wenn aufgrund von Netzengpässen die WEA vorübergehend abgeschaltet werden muss.
Diese Zustände müssen natürlich dokumentiert werden, definieren aber keinen Fehler...

Habe jetzt übrigens die tblLink weggelassen, denn der Primärschlüssel dieser Tabelle hatte dieselben Werte wie die IDWea...
Daher habe ich die Verknüpfung der WEA zum Windpark direkt in der tblWEA vorgenommen.
Das Formular dazu funktioniert super.

Nun kann's also weitergehen mit mehr Funktionen, dazu hab ich direkt wieder eine Frage: :-)
Kann man auf Knopfdruck ein Haufen neue Datensätze erzeugen (50 Stck)?
Folgender Hintergrund:
2 mal am Tag werden alle WEA "überprüft" und der Status dokumentiert (dafür auch die Checkbox "Anlage OK").
Wir haben bisher ein ausgedrucktes Excel Blatt mit allen WEA wo wir unsere Haken und evtl. Bemerkungen machen.
Ich würde nun gerne dieses Blatt mehr oder weniger 1 zu 1 übernehmen.
Am Ende müsste man dann einmal auf "Speichern" drücken und 50 Datensätze mit demselben Datum/Uhrzeit aber unterschiedlichen IDWea würden angelegt...

Vielen Dank im vorraus!

ps: Ist es eigentlich okay mehrere Fragen im selben Thread zu stellen? Habe in den Regeln keine Aussage dazu gefunden.

Gruß Björn

[DF6GL]

Hallo,

"die tblLink weggelassen, denn der Primärschlüssel dieser Tabelle hatte dieselben Werte wie die IDWea..."


d. h. eine Wea findet sich nur in einem bestimmten Windpark.. ?  zeig nochmal einen Screenshot den Beziehungsfensters...


"Kann man auf Knopfdruck ein Haufen neue Datensätze erzeugen (50 Stck)?"

könnte man, aber wozu? Es ergäbe keine Eingabeaufwands-Ersparnis.

Einen solche ergäbe sich, wenn man nur die "Ausnahmen" erfassen würde, also solche Ereignisse, die seltener vorkommen als die "normalen"  (falls ein solcher Gedankengang bei Deiner Datensituation auftreten kann.


Vergiss Excel und solche Scherze bei einer DB...


Die (neuen) Fragen sind hier soweit  schon ok, derweil sie sich auf den selben Betreff beziehen. Nur wenn der Thread sich zu lang (über mehrere Seiten) erstreckt, sollte man einen neuen Thread mit konkreter Fragestellung eröffnen, ansonsten hat keiner Lust, das gesamte Vorgeplänkel und die Einzelheiten dazu sich einzuverleiben.

[Björn P]

Der Grund für die mehrfachen Datensätze ist vielleicht nicht so leicht zu erklären aber ich probier's mal:

In meinem ersten Formular lässt sich ein Windpark und eine WEA auswählen und dazu ein neuer Logbuch-Eintrag erstellen.
Das ist soweit auch super, wenn man über Tag für eine bestimme WEA etwas dokumentieren muss...

Da wir aber morgens und abends für alle WEA ein Eintrag brauchen, der manchmal auch nur aus einem Haken bei "Anlage OK" besteht, wäre es "lästig" wenn man jede einzelne WEA auswählen muss...
Schöner wäre es wenn man alle WEA in einer Liste sieht und dann entsprechende Haken setzt (und teilweise Bemerkungen dazu schreibt).
Ein weiterer Grund für diesen Aufbau wäre die Gewohnheit der Anwender: wenn die Liste quasi so aussieht wie vorher auf Papier, fällt es den Leuten denke ich leichter, mit dem neuen System zu arbeiten. :-)

Ein Screenshot von den Beziehungen habe ich angehängt.

[DF6GL]

Hallo,

ich verstehe wohl genau, was Du meinst...

Der Argumentation kann ich aber nicht beipflichten.

Ich hoffe, Du hast nicht wirklich den Fremdschlüsselfeldern den Datentyp "Byte" verpasst, was aufgrund des Prefixes ("byt") zu vermuten ist. Wenn so, dann ändere den umgehend auf "Long".  Weiterhin lösche (vorher) die Beziehungen im Beziehungsfenster und setze die nach der Änderung neu, damit sich jeweils eine 1:n-Beziehung ergibt.

Was bedeutet "morgens"?  ist das die Uhrzeit zwischen 6:00 und 12:00 Uhr und Nachmittags von 12:00 bis 18:00 , oder wie soll man sich das vorstellen?  Das Feld "datUhrzeit" ist überflüssig, die Uhrzeit kann im Feld "datDatum" mitgeführt werden, so man denn eine genaue Uhrzeit-Angabe überhaupt braucht.  Wenn es lediglich eine (binäre) Unterscheidung zwischen morgens und abends braucht, wäre ein einzelnes Ja/Nein-Feld ausreichend, das mit einem Optionsrahmen und darin 2 Optionsfeldern ("morgens" und "abends") dargestellt wird.


Lad mal die DB mit ein paar Spieldaten hier hoch (repariert/komprimiert und gezippt) ...

[MzKlMu]

Hallo,
und überhaupt ist es nur scheinbar eine gute Idee vor die Feldnamen ein Prefix zu hängen. Das bringt nichts und macht nur ein Haufen Arbeit wenn man es konsequent machen will.
Wenn Du irgendwann merkst (beim 4 Formular z.B.) dass der Datentyp nicht passt, (so wie mit den Byte) musst Du alles ändern, was bisher dieses Feld verwendet hat. Und auch noch suchen, wo überall.
Lasse es lieber sein, es bringt nichts.

[Björn P]

So, komme erst jetzt zum Antworten.
An dieser Stelle mal ein großes Dankeschön für die tolle Hilfe!

Hallo,
und überhaupt ist es nur scheinbar eine gute Idee vor die Feldnamen ein Prefix zu hängen. Das bringt nichts und macht nur ein Haufen Arbeit wenn man es konsequent machen will.
Wenn Du irgendwann merkst (beim 4 Formular z.B.) dass der Datentyp nicht passt, (so wie mit den Byte) musst Du alles ändern, was bisher dieses Feld verwendet hat. Und auch noch suchen, wo überall.
Lasse es lieber sein, es bringt nichts.

Ich habe mich nach besten Wissen und Gewissen an die Namenskonventionen von
http://www.access-tutorial.de/namenskonventionen.htm gehalten... :-)
Aber dein Argument ist verständlich, werde das dann nochmal umbennenen.

Ich hoffe, Du hast nicht wirklich den Fremdschlüsselfeldern den Datentyp "Byte" verpasst, was aufgrund des Prefixes ("byt") zu vermuten ist. Wenn so, dann ändere den umgehend auf "Long".  Weiterhin lösche (vorher) die Beziehungen im Beziehungsfenster und setze die nach der Änderung neu, damit sich jeweils eine 1:n-Beziehung ergibt.

Der Gedanke dahinter war, dass nicht mehr als 255 Windpark in der Liste auftauchen werden...

Was bedeutet "morgens"?  ist das die Uhrzeit zwischen 6:00 und 12:00 Uhr und Nachmittags von 12:00 bis 18:00 , oder wie soll man sich das vorstellen?  Das Feld "datUhrzeit" ist überflüssig, die Uhrzeit kann im Feld "datDatum" mitgeführt werden, so man denn eine genaue Uhrzeit-Angabe überhaupt braucht.  Wenn es lediglich eine (binäre) Unterscheidung zwischen morgens und abends braucht, wäre ein einzelnes Ja/Nein-Feld ausreichend, das mit einem Optionsrahmen und darin 2 Optionsfeldern ("morgens" und "abends") dargestellt wird.

Also es gibt fixe Zeiten für die "Überwachung" - morgens um 7:00 und abend um 16:00
Habe jetzt überlegt dass man dafür dann x Datensätze erzeugt, alle mit dem Status "Anlage OK", und dann gezielt, falls eine Anlage eine Fehler hat, diese auswählen und kommentieren kann...

Lad mal die DB mit ein paar Spieldaten hier hoch (repariert/komprimiert und gezippt) ...

Werde ich heute über Tag machen, so wie es zeitlich passt...

[DF6GL]

Hallo,

Namensgebung:  Der Vorschlag zu den Tabellennamen ist eher fragwürdig.  Besser ist bei Tabellenfeldern, denen einen Prefix in Form der Abkürzung des Tabellennamens voranzustellen, z. B. bei Tabelle tbl_Mitarbeiter  das Feld für den Nachname als "MA_Nachname" zu benennen.
Wenn man Wert auf einen Hinweis (im Namen) zum Datentyp legt, kann man das Ding auch  "MA_txtNachname" nennen. Das bleibt einem selber überlassen, wie man das handelt, es sollte nur durchgängig und eindeutig sein (was der Tabellenprefix ja impliziert.)

Wichtig und nicht zu vernachlässigen ist die Vermeidung von Leer- und Sonderzeichen im Namen, sowie keine reservierten Wörter zu verwenden, was nach o. g. Benamsung eher wenig wahrscheinlich ist.


Der Gedankengang mit "Byte" ist zu verwerfen. Zum Einen ist NIE sichergestellt, dass es nicht doch mehr Einträge geben könnte, zum Zweiten benutzt Access bei 32-Bit-Versionen für den Autowert grundsätzlich einen Long-Datentyp. Ein Autowert selber ist nur (voraussichtlich) bei Einstellung als Inkrementaler Autowert ab 1 fortlaufend aufsteigend.  Ist der Autowert auf "zufällig"  eingestellt, wird die gesamte "Bandbreite"  (Wertebereich) eines Long-Zahlentyps ausgenutzt, auch negative Zahlenwerte in nicht vorhersehbarer Reihenfolge.
Zudem sollte JEDES Ganzzahlfeld in Tabellen mit LONG deklariert werden, das Gleiche gilt für VBA-Ganzzahl-Variablen.


Wenn es nur zwei feste Zeitpunkte am Tag ergibt, dürfte der Vorschlag über ein Ja/Nein-Feld am effizientesten sein.


"..man dafür dann x Datensätze erzeugt, alle mit dem Status "Anlage OK", und dann gezielt, falls eine Anlage eine Fehler hat, diese auswählen und kommentieren kann..."

ist halt "Excel-Like" .. Man kann es auch so interpretieren, dass, wenn kein Datensatz vorhanden ist, eine WEA "ok" ist. D. H.man geht grundsätzlich davon aus, dass alles Ok ist und erfasst nur Fehlsituationen, bzw. erforderliche Kommentare.