Datenbank für Cpk-Werte

daniel bischoff

Neuer Benutzer
Beiträge
4
Hallo zusammen

Ich muss eine Datenbank erstellen, welche ich nach den Cpk-Werten (Fähigkeitszahl in der Fertigung) filtern kann, bzw. in einem Bericht filtern.
Der Cpk-Wert muss unter filgenden Bedingungen gefiltert werden können:
  • von welcher Abteilung wurde es gemessen
  • Werte unter 1.33
  • Werte über 1.33
  • wie viele Aufträge wurden gemessen pro Jahr
  • wie viele Merkmale wurden gemessen pro Jahr
  • auf welcher Station wurde gemessen pro Jahr
  • wurde über diesen Cpk-Wert schon mal gesprochen
  • Zeitspanne
  • Kunde
  • Anzahl Messwerte

Folgendes habe ich zur Verfügung:
  • Artikelnummer (etwa 300 Stück)
  • Merkmal pro Artikel (von 1 bis 30, je nach Artikel)
  • Fertigungsauftrag, mit welchem der Artikel produziert wurde
  • Station wo es gemessen wurde
  • von welcher Abteilung
  • Datum
  • Kunde
  • Anzahl Messwerte
Ich habe nun folgende Tabellen gemacht:
  • Kunde
  • Station
  • Abteilung
  • Artikel
    • Kunde
    • Datum
    • Station
    • Abteilung
    • Merkmal 1 bis 30
    • Anzahl Messwerte
    • Bemerkung
Habe alles schon im Excel gemacht und funktioniert tadellos, da ich aber über 100 Register habe (pro Artikel 1 Register) und vieles Verknüpft inklusive Bilder, stürzt es oft ab und macht so keinen Spass mehr. Somit dachte ich, wäre das Access eine gute Idee.
Momentan scheitere ich, wenn ich einen Filter setzen will über die Merkmale 1 bis 30, dass nur die die Zeilen kommen, welche unter 1.33 ist.

Kann mir da jemand helfen?
Habe ich den Aufbau, bis dahin gut gemacht, oder gibt es da Anregungen?

lg
Daniel Bischoff
 
Werbung:
Kann mir da jemand helfen?
Was Du geschrieben hast klingt fast alles ok.
Bei den Merkmalen ist unklar, wie Du sie ablegen willst. Als einzelne Spalten? Als eigene Tabelle? Spalten wäre schlecht.

Tja und dann Access. Ich kann die Motivation verstehen, aber es ist m.E. nicht empfehlenswert. Es gibt hier einige, die von Excel weg wollen und nach Access schwenken. Und die nächste Stufe ist dann von Access weg.

Meine Empfehlung:
nimm einen echten DB Server, konkret Postgres
bau damit ein gutes* DB Modell und fundamentalen Code, um die Daten in die DB zu schaufeln
(an der Stelle ist anhand Deiner Beschreibung vollkommen offen, wie das erfolgt. Online, Import wöchentlich oder so)
Probier das alles aus, von vorne bis hinten und optimiere wo es klemmt oder kompliziert wird**
überleg Dir, wie die Sache sich perspektivisch entwickelt
was kommt nach Excel Umstellung
wer könnte, müsste zukünftig alles mit dem System arbeiten
auch: welche Prozesse brauchen Daten aus diesem System
überleg Dir, warum Du Access nehmen wolltest und was für Alternativen in Frage kommen
(mglw das Opensource Pendant LibreOffice oder andere)

bau ein gutes Frontend, mit dem Du alles gut überwachen und reporten kannst.
mindestens das, was Du jetzt schon kannst

* Es wird nie 100% perfekt :)
** Deine Frage zeigt ja, dass Du nicht einfach drauf los machen willst. Trotzdem kalkuliere ein, dass ein erster (Ent-)Wurf nicht optimal sein wird. Also ausgehend vom Datenmodell alles durchspielen (mit echten Daten, zu Fuß), hier nachfragen, wenn es irgendwo hakt, nachjustieren, wegwerfen, umbauen... Wenn Du eine minimale, brauchbare, funktionale V1 hast und die eine Weile läuft, wird es ganz von allein Änderungs- und Erweiterngswünsche geben. Dann geht der Prozess weiter / von vorne los.
 
Hallo Dabadpdu

Danke für deine Nachricht.
Leider bin ich ein bisschen limitiert, mit dem wissen und welche Programme ich anwenden darf.
Da die Informatik um neuer Software immer einen riesen Bogen macht, da man so oder so schon viel zu viele hat (wir haben momentan über 1300 Stück), werde ich da nicht durchkommen mit dem Postgres
Die Daten wären alle auf einem SQL-Server, leider ist die Datenbank, welche das Programm MeasurLink von Mitutoyo generiert, so unübersichtlich und so viele "Register" das man die Zusammenhänge nicht sieht und es einfacher ist, die Daten welche man benötigt abzutippen und das ausgeben was man möchte.

Die Merkmale werden pro Zeile ausgegeben, somit muss ich vorab immer den Kunden, Artikelnummer, Fertigungsnummer usw. eingeben, danach kommen die Merkmale. Es werden nur die Merkmale mit der Geschäftsleitung besprochen, welche unter 1.33 sind. Da ich aber bis anhin nicht herausgefunden habe, wie ich pro Zeile den tiefsten Wert herausfiltern kann, komme ich mit meiner Tabelle, welche ich zu Testzwecken mit 3 Aufträgen versehen habe, jeweils von 3 Kunden nicht weiter. Habe auch gegooglet, wie ich eventuell mit Makros das lösen kann, leider habe ich nichts gefunden.
Wenn ich bis ende Juli nicht weiterkomme, werde ich versuchen meine bestehende Excel-Liste zu optimieren, damit diese nicht mehr abstürzt und darin noch ein dynamische Tabelle generieren, welche momentan noch starr ist und ich jedes Mal noch anpassen muss.

Liebe Grüsse
Daniel
 
Tabellenkalkulation ist auch einfach keine Datenbank, Excel und Access und richtige DBMS Systeme auf SQL Basis sind eben alle grundverschieden. Für mich ließt sich das nicht durchdacht.

Wie kommen die Daten in die DB? Das ist ein ziemlich wichtiger Punkt. Offensichtlich ist hier schon ein Programm und damit verbunden vermutlich eine Datenbank im Spiel. Dazu eine IT die überfordert / Überlastet ist, aus welchen Gründen auch immer. Der richtige Weg wäre die Daten aus dieser Datenbank auszulesen und am besten in der Form, in der man sie braucht. Alternativ ein Auswertungssystem aufzubauen, es gibt viele Möglichkeiten. Nur die Daten abzutippen in eine andere Anwendung ist das ineffizenteste, was man tun kann. Hier liegen die größten Stärken einer DB, in der Automatisierung und Auswertung.

Ein DBMS liefert i.d.R. keine GUI, aus deiner Sicht ist das vermutlich der Schwachpunkt. Für deinen "manuellen" Ansatz sind daher Excel (oder auch Access) eher geeignet. Man könnte auch mit Excel die Daten aus der produktiven Datenbank abrufen und damit auch gleich filtern, aber ohne die Mitwirkung der IT geht da gar nichts.
 
Nagut, also eine Datenbank ist da. Postgres wäre die Empfehlung. MSSQL darf es auch sein. Und wenn Du mit Access darauf zugreifst, ist die Hälfte der Probleme von Access weg. Mir ist anhand Deiner Beschreibung nicht klar, ob der MS SQL Server nur die Daten Quelle ist, oder auch das Ziel Deines neuen Systems.
Die Merkmale werden pro Zeile ausgegeben, somit muss ich vorab immer den Kunden, Artikelnummer, Fertigungsnummer usw. eingeben, danach kommen die Merkmale. Es werden nur die Merkmale mit der Geschäftsleitung besprochen, welche unter 1.33 sind.
Das hört sich mies an.
Ich hab es so verstanden, Du hast 30 Merkmale, die jeweils gemeinsam in einer Datensatzzeile angegeben sind. Ihr Wert gibt den cpk an (was auch immer), der Schwellwert für die Filterung ist 1.33. Oder ist der CPK Wert nicht unter Merkmal 1-30 eingetragen?

Das ist ein "Datenmodell", das sehr ungünstig für SQL ist. Eigentlich ein super Beispiel, warum man normalisiern soll.
Nach Meinem Verständnis lautet ein Abfrage mit Standard SQL dazu ungefähr so:
select * from artikel
where merkmal01 <1.33 or merkmal02<1.33 or merkmal03<1.33or merkmal04<1.33or merkmal05<1.33
or merkmal06<1.33 ..
..
or merkmal21<1.33 or merkmal22<1.33..
or merkmal26<1.33.. or merkmal30<1.33

Jede Abfrage, also die Reportkriterien die Du oben aufgeführt hast, müsste einem solchen Schema aufgebaut werden. Das ist uncool.

(elegante) Umwege:
Ich weiß nicht, was MSSQL alles kann, aber eine Möglichkeit wäre, die Messwerte in einem Array oder JSON Array zusammenzufassen und die Such- / Filteroperationen dann mit Array Operationen zu vereinfachen.
Normalisierung: Bei Messwerten ist das so eine Sache. Ich finde, man kann da auch den Standpunkt vertreten, dass eine Messwertgruppe eine Informationseinheit bildet, muss nicht normalisiert werden. Man legt das so als Block (Zeile) ab und es wird ja dann auch nie wieder verändert (sind ja Messwerte). Das gilt besonders dann, wenn die Werte alle die gleiche Einheit / Information darstellen. Selbst wenn es verschiedene Informationen sind, könnte man es immer noch so machen.
Das ändert leider nichts an dem Problem, dass SQL für Spaltenweise Operationen bzw. Kriterienprüfungen nicht so gut geeignet ist.
 
Ich lese da im wesentlichen drei Dinge raus:

1) Die Daten liegen in einer Anwendung mit einem DBMS, auf die der OP allerdings kein Zugriff hat und die IT des OP keinen Zugriff geben will und / oder kann. Der OP tippt die Daten aus einer Anwendung ab (eventuell Copy-Paste) und nutzt sie dann in Excel, bisher.

2) In der Anwendung muss ein Filter gesetzt werden um die Daten auszulesen und es müssen immer mehrere Werte vorgegeben werden um die Werte dann in einer EAV-Darstellung anzeigen zu lassen. Die Attribute zum Datensatz stehen untereinander, eventuell betrifft das auch die Datenhaltung (was nicht zwingend schlecht ist).

3) Die Datenanalyse mit Excel funktioniert soweit und liefert das gewünschte Ergebnis. Es gibt aber wohl einige Baustellen in der Logik, es ist aufwendig, und es kann zu Abstürzen kommen.

Unabhängig davon mit welcher Datenbank man arbeitet (ob es bei Excel bleibt oder etwas anderes wird), ist für mich 1) das größte No-go. Niemand sollte ein System bauen, das auf eine manuelle Überführung der Daten Datum für Datum beruht, oder auch nur dem parsen von Ergebnislisten aus einer GUI. Wenn es schon eine Datenbank gibt, in der die Daten liegen, dann würde ich erstmal versuchen da (lesend) ran zu kommen. Oder zumindest gezielt einen Datenbestand zu exportieren.

Wenn das geht, spare ich mir viel Arbeit und ich muss mich nur um die Auswertung und die Anzeige der Daten kümmern. Wenn das überhaupt nicht geht, dann muss ich mich zusätzlich auch noch um die Eingabe der Daten in mein Auswertungssystem kümmern. Dann muss mein Auswertungssystem oder mein Prozess ganz anders aussehen, als wenn ich nur eine Ausgabe habe.
 
@bdittmar
Das ist exakt das Programm MeasurLink 9 von Mitutoyo, unterdessen gibt es eine 10.
Was die Power-BI Anbindung heissen soll, weiss ich nicht.
Ich habe den Hersteller Mitutoyo selber angefragt, ich sei der einzige, welcher diese Anforderungen hat.
Der Hersteller Q-DAS könnte dies "bauen".
Wenn man von Mitutoyo weg würde und zu Q-DAS wechseln würde, wären pro Jahr Lizenzkosten von 12'000 Franken fällig, da man das Programm nur mieten kann und nicht kaufen. Zudem wären alle Daten, welche bisher angehäuft wurden, mit einem grossen Aufwand implementierbar.

Liebe Grüsse
Daniel
 
Was die Power-BI Anbindung heissen soll, weiss ich nicht.
Das ist BI Tool von Microsoft. Also ein zweites Programm, was auf die Messwerte im MeasureLink Server zugreift.

Ist jetzt nicht überraschend, dass andere Programme das können. Aber es ist einfach ein offizieler Hinweis dazu.

Dieser Direktzugriff auf die Messwerte ist das, was @ukulele fordert. Nicht für andere, sondern für Dein Problem.
Ich hatte es im zweiten Anlauf so verstanden, dass es kein Problem ist, das scheint aber entweder nicht zu stimmen oder es ist Dir einfach nicht bekannt, dass es ginge.
Wenn der Hersteller sagt, dass sie es selbst nicht bieten und sogar auf andere Produkte verweist, dann ist das entweder
- Unwissen des Ansprechpartners
- Marketing Blödsinn
- Überambitionierter Protektionismus der eigenen Software oder
- Angst vor dem eigenen Produkt

Ich hatte das Tool (Infos) auch angeschaut und so tolle Aussagen gefunden wie ~"wir haben auf DB Ebene keine referentielle Integrität". Das ist nicht gut, und es führt fast zwangsläufig dazu, dass sie niemand anders an die Daten ran lassen. Nicht mal den Produzenten der Daten, also ihren Besitzer, Deine Firma also. Andererseits wäre ein lesender Zugriff -der ausreichen würde- dennoch vollkommen unproblematisch. (Siehe Power BI)

Ich würde eine Software nicht einsetzen, die mir keinen Vollzugriff auf meine Daten gewährt.
Aber ich bin mir nicht sicher, dass das wirklich so ist. An der Stelle würde ich weiter bohren.
 
Werbung:
@bdittmar
Ich habe den Hersteller Mitutoyo selber angefragt, ich sei der einzige, welcher diese Anforderungen hat.
Der Hersteller Q-DAS könnte dies "bauen".
Das ist, freundlich formuliert, gequirlte Scheiße. Entweder wollen sie dir ein Coustomizing verkaufen oder sie haben keine Lust auf unbequeme Arbeit oder einfach keine Ahnung.

Ja, es gibt Hersteller die dem Kunden keinen Datenbank Zugriff geben wollen. Die DATEV ist so ein Fall aber selbst die machen das mit der passenden Unterschrift und gegen Geld. Die meisten Hersteller wollen das vielleicht nicht, machen es aber auf gezielte Nachfrage. Häufig ist es auch gar nicht so schwer weil bei der Einrichtung der Software irgendwo die Datenbank aufgesetzt und Benutzer und Passwörter mit angelegt werden. Das hängt immer ganz vom Prozess ab, wer hat das bei euch installiert? Ihr selbst, ein Systemhaus, oder der Hersteller?

Sag dem Support, du benötigst einen lesenden Benutzer auf deine SQL Datenbank, oder die dokumentierten Passwörter aus dem Installationsvorgang. Da bist du ganz bestimmt nicht der Erste und vermutlich ist das auch nicht so wild. (Die DATEV z.B. hat das tatsächlich technisch sehr stark abgesichert, da braucht man ein Support-Token um SQL-Befehle absetzen zu können.)

Der Hersteller möchte aus verständlichen Gründen nicht, das du selbst in die Datenbank schreibst. Davon kann man auch nur abraten. Aber lesend darauf Zugriff zu nehmen ist kein Hexenwerk, du hast nur eventuell nach einem Update ein Problem wenn sie die Datenbank-Struktur verändern (was viele aber nur sehr selten tun). Wenn du dann so einen lesenden Zugang hast, kannst du mit Excel, oder PowerBI, oder Access oder sonstwas für Werkzeugen die Daten auslesen und entsprechend auswerten. Das ist einmalig viel Arbeit weil du die Datenstruktur verstehen musst und erstmal nachvollziehen musst, was die Anwendung genau tut in der Datenbank. Wenn das dann aber funktioniert ist das genau ein Abruf der Daten und dein Bericht steht.
 
Zurück
Oben