Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Mehrere Datenbänke "zusammenführen"

Begonnen von H_Stadler, September 09, 2015, 08:47:56

⏪ vorheriges - nächstes ⏩

H_Stadler

Guten Morgen zusammen!

Nachdem ich nun, mit eurer Hilfe (Vielen Dank nochmal!), meine erste Datenbank recht gut fertiggestellt habe besteht der Wunsch diese Datenbank noch zu erweitern. Die Datenbank wird momentan zur Werkzeug-Verwaltung genutzt. Zunächst geht es hier nur um Messmittel. Es sollen jedoch auch verschiedene andere Werkzeuge, Equipment etc. in der gleichen Datei & Oberfläche verwaltet werden können. Viele dieser Daten hätten keinerlei Beziehungen zu der bisher bestehenden Datenbank, sollen aber unbedingt in der gleichen Datei zur Verfügung stehen, sodass es eine Zentrale Datenbank für sämtliche Geräte und Equipment Verwaltung gibt.
Wie würde man das clever lösen? Baue ich dazu einfach die zusätzlichen Datenbanken (wahrscheinlich 4 Stück) mit in die Datei ein, oder löst man das am besten mit mehreren Backends? Oder ist das sogar das absolut schlimmste was man machen könnte und solche Datenbanken sind strikt zu trennen?

Bin gespannt was ihr denkt!
LG,
Hubert

datekk

#1
Zitat von: Der_Praktikant am September 09, 2015, 08:47:56
Viele dieser Daten hätten keinerlei Beziehungen zu der bisher bestehenden Datenbank

Wie meinst Du das Genau? Benötigen die anderen Werkzeuge andere Felder? Und warum möchtest Du die Daten vereinen? Möchtest Du diese gemeinsam auswerten z.B. den Preis?

Ansonsten baue doch in deine Werkzeugtabelle alle benötigten Spalten ein und fülle dann die, die Du dafür benötigst. So hast Du alle Werkzeuge in einer Tabelle und damit auch in einer Datenbank.

Du kannst ja auch für unterschiedliche Werkzeuggruppen andere Formulare verwenden. Die passt Du dann einfach an Deinen Sachverhalt an.

Access 2016 mit SQL Server Backend. Bereits umgesetzt: Access mit MS SQL Backend,  ADODB Formularbindung, Streamen von Dateien zum SQL Server und zurück (Filestream), Drag&Drop Dateiupload zum Server, CTI / TAPI Integrierung in Access Anwendung - Nutzung auch über Remote Desktop, selbst aktualisierendes Access Frontend auf entfernten Rechnern (Upgrade). Berichte / Kreuztabellen mit SQL Server Backend, Mail Tagging, Outlook Steuerung über Access und umgekehrt // Grundwissen in .Net Core & Blazor Apps

H_Stadler

Guten Morgen Datek,

Ja eigentlich hast du das schon richtig verstanden. Andere Werkzeuge, die auch einen anderen Prüfintervall/Prüfweise haben sollen in einer "Baugleichen" Datenbank geführt werden können. Ich habe mittlerweile allerdings schon angefangen diese jetzt doch in zusätzliche Dateien zu setzen. Ich wollte nicht dass die eigentliche bzw. die "Hauptdatenbank" zu unübersichtlich wird. Schließlich muss die weiter gepflegt werden, wenn mein Praktikum rum ist.

Danke für deine Antwort, beim nächsten mal weiß ich dann wie ich am besten damit umgehe ;)

LG
LG,
Hubert

datekk

#3
Gut, ich kenne jetzt die DB nicht im Detail, dennoch denke ich, dass es übersichtlicher wäre, wenn Du alles nicht nur in einer DB sondern alle Werkzeuge in einer Tabelle führst. Diese Vorgehensweise kommt dann auch künftigen Praktikaten zugute die dann nicht überlegen müssen, warum ihr Vorgänger die Daten auf verschiedene DB verteilt.  ::)

Leg es doch so an:

tbl_Werkzeuge:

ID | Name              | Int_Nummer | Prüfintervall | Eigenschaft_1 | Eigenschaft_2 | Prüfdatum
1   | Hammer          | H-01            | 1                | hämmern       |                     | 01.09.2015
2   | Bohrmaschine   | B-01            | 2                | bohren          | Strom            | 01.07.2015


tbl_Prüfintervall

ID | Bezeichnung | Intervall
1   | Intervall 1    | 12
2   | Intervall 2    | 3

Dann machst du eine Abfrage der beiden Tabellen und eine Verknüpfung. Dabei verknüfpst Du das Feld Intervall aus tbl_Prüfintervall mit dem Feld Prüfintervall aus tbl_Werkzeuge. Z.B. abfr_Abfrage1

Die Abfrage nimmst Du dann als Datengrundlage für ein Formular oder einen Bericht.

Die Intervalle sind hier z.B. einfach Monatsangaben. Diese werden dem Datum der letzten Prüfung aus tbl_Werkzeuge z.B. in einem Bericht oder Formular zugerechnet.. Daraus entsteht dann das Datum der nächsten Prüfung. Hieraus kann man dann wieder weiter ableiten z.B. ob es im Vergleich zum heutigen Datum bereits abgelaufen ist usw.

Wenn Du genauer wissen willst wie das geht dann schreib nochmal oder lade mal eine abgespeckte Version Deiner Datenbank hier hoch.

LG
Access 2016 mit SQL Server Backend. Bereits umgesetzt: Access mit MS SQL Backend,  ADODB Formularbindung, Streamen von Dateien zum SQL Server und zurück (Filestream), Drag&Drop Dateiupload zum Server, CTI / TAPI Integrierung in Access Anwendung - Nutzung auch über Remote Desktop, selbst aktualisierendes Access Frontend auf entfernten Rechnern (Upgrade). Berichte / Kreuztabellen mit SQL Server Backend, Mail Tagging, Outlook Steuerung über Access und umgekehrt // Grundwissen in .Net Core & Blazor Apps

MzKlMu

Hallo,
ich würde die Tabelle auf keinen Fall wie vorgeschlagen aufbauen. Das ist nicht normalisiert. Aufzählungsfelder (mit einer Zahl hinten ..._1, ..._2 ...) verstoßen bereits gegen die 1. Normalform. Die Beziehung zwischen Werkzeug und Eigenschaft ist eine n:m Beziehung zu der 3 Tabellen erforderlich sind. Die Tabelle tbl_Prüfintervall ist in der Form nicht notwendig. Das Prüfintervall in Monaten kann man gleich in die Werkzeugtabelle aufnehmen ist ja auch nur eine Zahl. Das Prüfdatum hat in der Werkzeugtabelle nicht zu suchen, das muss auch in eine extra Tabelle mit einer n:1 Beziehung zum Werkzeug.

Ich sehe hier mindestens 4 Tabellen:

- Werkzeug
- Eigenschaften
- WerkzeugEigenschaft (Fremdschlüssel (FS) zu Werkzeug und FS zur Eigenschaft, je ein Datensatz)
- Prüfungen (FS zu Werkzeug).
Gruß Klaus

datekk

Darüber kann man sich sinnlos tot spekulieren, solang der tatsächliche Anwendungsfall nicht bekannt ist. Wenn das Gerät eine (von der Hochschule) vorgegebene Gerätenummer hat, so kann diese durchaus genau so in die Spalte Int_Nummer eingegeben werden. Es war ja gar nicht der Sachverhalt dies zu prüfen. Auch die Eigenschaften kennen wir nicht und daher wissen wir auch gar nicht, ob dafür eine Tabelle notwendig ist.

Die Tabelle für die Prüfintervalle kann sehr wohl interessant sein, da es nach den Schilderungen des TE so aussieht, als ob die Prüfintervalle die entsprechenden Werkzeugkategorien vorgeben. Somit kann ich bei der Erfassung über ein Formular via Kombifeld aus einem von vielen vorgegebenen Intervallen wählen, die Intervalle verwalten, ihnen Namen oder Bezeichnungen geben usw. Wenn dies nicht erforderlich ist, reicht freilich eine Eingabe einer Tages, Monats, Jahreszahl in der Spalte Prüfintervall der tbl_Werkzeuge.
Access 2016 mit SQL Server Backend. Bereits umgesetzt: Access mit MS SQL Backend,  ADODB Formularbindung, Streamen von Dateien zum SQL Server und zurück (Filestream), Drag&Drop Dateiupload zum Server, CTI / TAPI Integrierung in Access Anwendung - Nutzung auch über Remote Desktop, selbst aktualisierendes Access Frontend auf entfernten Rechnern (Upgrade). Berichte / Kreuztabellen mit SQL Server Backend, Mail Tagging, Outlook Steuerung über Access und umgekehrt // Grundwissen in .Net Core & Blazor Apps

MzKlMu

Hallo,
ZitatWenn das Gerät eine (von der Hochschule) vorgegebene Gerätenummer hat, so kann diese durchaus genau so in die Spalte Int_Nummer eingegeben werden.
das habe ich ja gar nicht angezweifelt (wo siehst Du das ?), selbstverständlich gehört die Gerätenummer in die Gerätetabelle. Mit den Aufzählungsfeldern meinte ich die Eigenschaft_1, Eigenschaft_2 usw. Diese Aufzählungsfelder sind unbedingt zu vermeiden, egal wie die Tabelle später aussieht. Eigenschaften sind Attribute eines Gerätes. Für die Prüfungen (und das Prüfdatum) ist eine extra Tabelle erforderlich. Da gibt kein Spekulationsspielraum. Und wenn Du das Intervall zur Auswahl über ein Kombi haben willst, genügt in der Tabelle ein Feld mit dem Intervall, das Feld kann auch als Primärschlüssel dienen, es ist ja eine Zahl.
Gruß Klaus

H_Stadler

Hallo ihr zwei,

Hier jetzt nochmal den Sinn, Aufbau und Zusammenhang aller DBs zu erklären ist recht komplex. Deshalb lasse ich das jetzt ganz frech aus, da ich das auch alles recht gut und voll funktionsfähig umgesetzt habe.
Datekk hat natürlich insofern Recht, dass es sinnvoll wäre alles in einer Datei abzuarbeiten, aber wegen Bedenken bezüglich Normalisierung habe ich das aufgeteilt.

Noch zusätzlich: Für das Prüfintervall habe ich tatsächlich eine extra Tabelle angelegt. Ich habe das nicht nur gemacht, damit das Prüfintervall in einer Kombibox ausgewählt werden kann, sondern auch damit ich ein Formular erstellen konnte wo "neue" Prüfintervalle hinzugefügt werden können. Da die DB von Leuten benutzt werden die sich noch nie mit Access beschäftigt haben fand ich das so etwas besser. Ob die zusätzliche Prüfintervall Tabelle dazu notwendig war sei dahingestellt...
LG,
Hubert

datekk

Zitat von: MzKlMu am September 22, 2015, 11:35:21
Hallo,
Mit den Aufzählungsfeldern meinte ich die Eigenschaft_1, Eigenschaft_2 usw. Diese Aufzählungsfelder sind unbedingt zu vermeiden

Da hast Du natürlich recht... Das war auch vielleicht ein bisschen unglücklich ausgedrückt... Ich wollte damit doch nur sagen, dass dann halt Werkzeugspezifische Spalten folgen wie z.B. Preis, Größe, Gewicht.. was weiß ich :) . Da ich ja nicht weiß was das für Spezifikationen sind habe ich Eigenschaft_1, Eigenschaft_2 geschrieben. Das soll so natürlich nicht als reelle Spaltenüberschrift gelten.
Access 2016 mit SQL Server Backend. Bereits umgesetzt: Access mit MS SQL Backend,  ADODB Formularbindung, Streamen von Dateien zum SQL Server und zurück (Filestream), Drag&Drop Dateiupload zum Server, CTI / TAPI Integrierung in Access Anwendung - Nutzung auch über Remote Desktop, selbst aktualisierendes Access Frontend auf entfernten Rechnern (Upgrade). Berichte / Kreuztabellen mit SQL Server Backend, Mail Tagging, Outlook Steuerung über Access und umgekehrt // Grundwissen in .Net Core & Blazor Apps