auswertung statistik bezugsdatensätze

[hgef]

hallo,
ich habe ein problem, das vielleicht gar nicht so schwer ist, ich mir jedoch den kopf dran zerbreche.

folgende struktur:

in einem haus sollen verschiedene dinge installiert werden. es gibt ein budget, in dem einige dieser items drin sind, andere nicht.
die datensätze fürs haus werden über die zimmer bestimmt, daneben gibt es eine art katalogtabelle, die die verfügbaren produkte enthält. zudem sollen, wenn die items installiert werden, die barcodes der realen produkte eingelesen werden (wobei ich noch nicht weiß, wo ich die hinschreiben soll, vielleicht in wiederholfelder).
ich habe also zwei tabellen:

tab1 haus
tab2 items

ds könnten so aussehen

tab1
raum item anzahl budget

wohnzimmer lampe 3 included
wohnzimmer schrank 5 additional
schlafzimmer lampe 5 additional
schlafzimmer steckdose 10 included
schlafzimmer steckdose 5 additional
schlafzimmer lampe 2 additonal
flur lampe 1 inlcuded

tab2

id produkt
1 lampe
2 schrank
3 steckdose

die tabellen sind über die itemID miteinander verbunden.

wenn die externe bestellung aufgegeben wird, soll natürlich nur dastehen, 10 lampen, 15 steckdosen etc.
für die interne budgetplanung muss dann natürlich unterschieden werden: 3 lampen included, 7 lampen additional, 10 steckdosen incl, 5 steckdosen add. etc.

ich habe es nicht hinbekommen, auszuwerten wieviel gesamt, wieviel im budget, wieviel nicht usw. weder als statistikfeld, noch als bericht noch als ausschnitt mit filterfunktion. da nach zimmer und budet gerechnet wird, gibts natürlich

ich habe mit dann mit einem formelfeld in der item-tabelle geholfen, in der ich noch 3 zusätzliche quantitätsfelder hinzugefügt habe.

also

quantität_all: wenn ( itemID_haus=itemID_items ) summe (haus::quantität))
quantität_included: wenn ( itemID_haus=itemID_items UND budget_haus = inluded ) summe (haus::quantität))
quantität_additional ( itemID_haus=itemID_items UND budget_haus = additional ) summe (haus::quantität))

das funktioniert auch ganz gut. allerdings bekomme ich es nicht hin, dass, wenn lampen sowohl included sind als auch additional, unterschieden wird.
irgendwie bleibt ein quantitätsfeld immer leer. und ich weiß nicht, warum.

sieht dann so aus

item quant_all quant_incl quant_add
lampe 10 ... 10
steckdose 15 15 ...

verrechnet sich irgendwie...
hat jemand schon mal ein prblem wie dieses gehabt?

danke, hgef

 

[micki-mac]

So wie du es geschildert hast, würde ich, wenn die Mengen nicht allzu groß werden, empfehlen, für jedes Produkt einen Datensatz anzulegen, d.h. 10 Steckdosen = 10 Datensätze. Dann sollte die Auswertung kein Problem sein. Dann ist auch das Problem mit dem Barcode gelöst, der kommt in ein Feld des Produkts. Ansonsten müsstest du für jeden neuen Barcode einen neuen Datensatz anlegen.

 

[hgef]

ja, darauf wird es wohl hinauslaufen, obwohl ich das vermeiden wollte, bläht die datenbank nur unnötig auf.
zudem wird ein nachträgliches ändern der quantität problematisch. es müsste dann ja ein script auf dem scipttrigger des quantitätsfelds liegen, dass jedesmal die anzahl der datensätze vergleicht, und notfalls löscht oder neue erstellt.
mit den barcodes, das stimmt schon. ich habe es zwar noch nicht ausprobiert, aber ich dachte mir, wenn ich die barcodes mit filemaker go erfasse, dass ich sie per script auch in ein wiederholfeld schreiben kann, das dann halt so oft wiederholt beschrieben wird, wie die anzahl der quantität ist. das wäre dann aber er die nächste problembearbeitung gewesen, hat aber schon vorher gehakt.
jedenfalls danke für deine antwort.

 

[micki-mac]

zudem wird ein nachträgliches ändern der quantität problematisch. es müsste dann ja ein script auf dem scipttrigger des quantitätsfelds liegen, dass jedesmal die anzahl der datensätze vergleicht, und notfalls löscht oder neue erstellt.

Hmm. Diesen Satz verstehe ich nicht: was heisst "nachträglich"? Nach was? Und was ist problematisch daran, eine Steckdose hinzuzufügen, also dafür einen neuen Datensatz anzulegen? Und warum muss die Anzahl der Datensätze verglichen werden? Verglichen mit was?

mit den barcodes, das stimmt schon. ich habe es zwar noch nicht ausprobiert, aber ich dachte mir, wenn ich die barcodes mit filemaker go erfasse, dass ich sie per script auch in ein wiederholfeld schreiben kann, das dann halt so oft wiederholt beschrieben wird, wie die anzahl der quantität ist. das wäre dann aber er die nächste problembearbeitung gewesen, hat aber schon vorher gehakt.

Ich glaube, du hast das Problem mit den Barcodes noch nicht wirklich gesehen: Wenn du für alle Steckdosen einen Datensatz hast, aber mehrere Barcodes für die Menge der Steckdosen, kannst du die unterschiedlichen Barcodes zwar in ein Wiederholfeld schreiben, aber woher soll Filemaker (wir reden hier doch von Filemaker, oder?) wissen, welche Steckdose welchen Barcode hat?

Dein Grundproblem, scheint mir, hat mit dem Thema "Datenmodell" zu tun. Das ist der erste Schritt, wenn man eine Datenbank erstellen will: Man muss sich darüber klar sein, welche Daten in welche Tabelle gehören.

 

[hgef]

Hmm. Diesen Satz verstehe ich nicht: was heisst "nachträglich"? Nach was? Und was ist problematisch daran, eine Steckdose hinzuzufügen, also dafür einen neuen Datensatz anzulegen? Und warum muss die Anzahl der Datensätze verglichen werden? Verglichen mit was?

die struktur, dass die menge der items den zimmern zugeordnet werden, und dies in einem datensatz über die quantität will ich noch nicht aufgeben.
das hieße dann aber, dass ich mir eine neue tabelle erstelle, in der alle items, wie lampen, steckdosen etc je einen einzelnen datensatz bekommen. das würde dann bspw so aussehen, dass ich in den location ds reinschreibe: flur: 10 lampen und in dem moment, wo ich die quantität festlege, werden in der location_items-tabelle 10 bezugsdatensätze erzeugt, die mit sowohl der location-tabelle über die locationID verbunden sind als auch mit der produkttabelle über die itemID. hier könnte man dann die barcodes in jeden datensatz einlesen, das stimmt schon. was bei diesem modell ungünstig ist, wenn ich mich bspw etwas später entscheide, die quantität herabzusetzen oder zu erhöhen. dann müsste ich per scripttrigger die anzahl datensätze in der bezugstabelle vergleichen und ggfalls abgleichen. das meinte ich.

einen einzelnen datensatz sofort zu erstellen, ist bsp wenn ein zimmer 1000 verschieden items benötigt, manuell zu aufwendig, deshalb mein festhalten an der struktur.

Ich glaube, du hast das Problem mit den Barcodes noch nicht wirklich gesehen: Wenn du für alle Steckdosen einen Datensatz hast, aber mehrere Barcodes für die Menge der Steckdosen, kannst du die unterschiedlichen Barcodes zwar in ein Wiederholfeld schreiben, aber woher soll Filemaker (wir reden hier doch von Filemaker, oder?) wissen, welche Steckdose welchen Barcode hat?

das kann in der datenbank mit dieser datenstruktur logischerweise nicht zugeordnet werden, aber es geht ja grundsätzlich darum, welche items verbaut werden. wichtig ist, zu identifizieren, was im haus ist, wobei es dann erstmal egal ist, ob die steckdose rechts neben der eingangstür ist oder am fenster.

 

[hgef]

achso, filemaker go deshalb, weil man über iphone und ipad mit einer app, bspw. cns-barcode die barcodes gleich fotografieren und in die db schreiben kann. der rest natürlich über fm pro 12 in meinem fall.

 

[micki-mac]

das würde dann bspw so aussehen, dass ich in den location ds reinschreibe: flur: 10 lampen und in dem moment, wo ich die quantität festlege, werden in der location_items-tabelle 10 bezugsdatensätze erzeugt, die mit sowohl der location-tabelle über die locationID verbunden sind als auch mit der produkttabelle über die itemID.

Also 3 Tabellen? Wo kommt jetzt die dritte Tabelle her? Bisher hast du von 2 Tabellen gesprochen: Location und Item. Nun sind es plötzlich 3. So ist es schwierig, dir einen Rat zu geben. Ich wiederhole daher: Mach dir erst einen Plan.

hier könnte man dann die barcodes in jeden datensatz einlesen, das stimmt schon.

"Hier" heisst in welche der 3 Tabellen?
Ich will nicht pingelig sein, aber für mich ist wirklich nicht klar, was in diesem Zusammenhang "hier" heisst.

was bei diesem modell ungünstig ist, wenn ich mich bspw etwas später entscheide, die quantität herabzusetzen oder zu erhöhen. dann müsste ich per scripttrigger die anzahl datensätze in der bezugstabelle vergleichen und ggfalls abgleichen. das meinte ich.

Ja, dann musst die per Script Bezugsdatensätze löschen.

 

[hgef]

Also 3 Tabellen? Wo kommt jetzt die dritte Tabelle her? Bisher hast du von 2 Tabellen gesprochen: Location und Item. Nun sind es plötzlich 3.

die dritte tabelle käme dann, wenn ich, wie du es auch vorgeschlagen hast, die items per location einzeln erzeugen würde, im falle, dass ich die location tabelle beibehalte, denn dort ist der raum als einzelner datensatz entscheidend und die anzahl der items wird im feld quantität bestimmt und nicht über die anzahl der datensätze.

in dem fall wäre die tabellen dann:

1. items (produktkatalog)
2. location (je zimmer ein datensatz mit quanität der zu verwendeten items)
3. location_items (je gekauftem item ein datensatz)

ich finde diese lösung jedoch sehr unelegant. deshalb wäre mir lieber, wie ich mit den zwei ersten tabellen und vielleicht ein zwei extra-statistik- oder formelfeldern die anzahl der items je nach budget und location anzeigen kann.

 

[micki-mac]

Ich habe keine 3 Tabellen vorgeschlagen. Das muss ein Missverständnis sein. Datenbanktechnisch würde ich eine 1:n Relation umsetzen: Ein Item (Steckdose, Lichtschalter, ...) kann immer nur an einem Ort sein, ein Ort kann aber mehrere Items beinhalten, also eine klassische 1:n Relation.

Daraus folgt, dass man 2 Tabellen hat: (1) Location, (2) Item.

Die Tabelle Item bekommt folgende Felder:
ID
Angelegt (Zeitstempel)
Geändert (Zeitstempel)
Bezeichnung ("Steckdose", ...)
Barcode
Fremdschlüssel (d.h. ID der Location)

Zusätzlich könnte man überlegen, Felder für Kategorie ("Steckdose", ...) und Subkategorie ("Unter Putz", ...) anzulegen und Wertelisten dafür einzurichten.

Von der Location ausgehend kannst du dann 10 neue Datensätze in Items anlegen. Das geht per Script. Dabei wird die ID der Location gleich in die Item-Datensätze eingetragen. Die Auswertung ist dabei sehr einfach zu bewerkstelligen.

 

[hgef]

Ich habe keine 3 Tabellen vorgeschlagen. Das muss ein Missverständnis sein. Datenbanktechnisch würde ich eine 1:n Relation umsetzen: Ein Item (Steckdose, Lichtschalter, ...) kann immer nur an einem Ort sein, ein Ort kann aber mehrere Items beinhalten, also eine klassische 1:n Relation.

ja, das ist mir schon klar.
die dritte tabelle ist die der konkreten produkte, die eingekauft werden. also der produktkatalog, aus dem die steckdose von firma AB oder eben BC gewählt wird.
sprich: ich gehe auf location, wähle 10 item und bekomme den katalog angezeigt, und sage, die von fischer oder was weiß ich möchte ich bestellen. dadurch wird dann auch gleich eine bestellliste generiert, in der die artikelnummern und preise drin sind. könnte man auch über eine externe db machen, da aber nur ein begrenztes sortiment benutzt werden soll, finde ich die tabellenlösung naheliegender.

das mit der datensatz-generierung per script wollte ich ja eigentlich nicht machen, aber es wird wohl darauf hinauslaufen. die generierung ist ja einfach, aber der abgleich, falls die quantität geändert wird, könnte ein wenig behäbig sein. vor unmittelbarem einlesen der barcodes muss die feldeingabe quantität dann sowieso gesperrt werden. alles andere würde ohnehin keinen sinn mach und wäre auch unlogisch.

danke jedenfalls nochmal für die hilfe.
gru0, hgef

 

[micki-mac]

die generierung ist ja einfach, aber der abgleich, falls die quantität geändert wird, könnte ein wenig behäbig sein.

Warum sollte das behäbig sein?

vor unmittelbarem einlesen der barcodes muss die feldeingabe quantität dann sowieso gesperrt werden. alles andere würde ohnehin keinen sinn mach und wäre auch unlogisch.

Das ist mal wieder ein Satz, den ich nicht verstehe.

 

[hgef]

Warum sollte das behäbig sein?

weil nach jedem nachträglichen ändern der quantität, alle bezugsdatensätze immer wieder abgeglichen werden müssen, sprich: ich suche nach den items, die für eine bestimmte location erstellt wurden und frage nach, ob die anzahl der ds noch mit der quantität übereinstimmt. tut sie das nicht, erstelle ich neue oder lösche vorhandene. letzteres muss über eine schleife passieren, was ich behäbig finde, im sinne von: die performance beeinträchtigend. wenn die db auf einem server liegt, kann das ein paar sekunden dauern.

Das ist mal wieder ein Satz, den ich nicht verstehe.

diese möglichkeit des abgleichs kann (oder besser: sollte) ich natürlich nicht mehr haben, nachdem die bestellung rausgegangen ist. dh. wenn ich anfange, die barcodes der schon gekauften items einzulesen, muss ich das quantitätsfeld in der location-tabelle blockieren, damit man dann nicht mehr nachträglich einen abgleich machen kann. das würde sonst intern zu einer fehlerhaften buchhaltung führen (weniger oder mehr items in der db als tatsächlich gekauft). und u.u. ds löschen, bei denen der barcode schon eingelesen war, im fall ich frage vorher nicht ab, ob das barcode-feld schon beschrieben ist.

aber wie dem auch sei, ich habe mich jetzt für diese lösung entschieden, und bin auch gerade dabei, die entsprechenden scripte zu programmieren. im testlauf werden ich ja dann sehen, welche auswirkung das auf die performance der db hat.

 

[micki-mac]

weil nach jedem nachträglichen ändern der quantität, alle bezugsdatensätze immer wieder abgeglichen werden müssen, sprich: ich suche nach den items, die für eine bestimmte location erstellt wurden und frage nach, ob die anzahl der ds noch mit der quantität übereinstimmt. tut sie das nicht, erstelle ich neue oder lösche vorhandene. letzteres muss über eine schleife passieren, was ich behäbig finde, im sinne von: die performance beeinträchtigend. wenn die db auf einem server liegt, kann das ein paar sekunden dauern.

In der Tabelle Locations wird dir angezeigt, wie viele Bezugsdatensätze es gibt. Und da gibt es ein Feld, wo du die Veränderung der Anzahl eintragen kannst. Und je nachdem werden entweder neue Datensätze angelegt oder vorhandene werden gelöscht. Da braucht es keine Schleife.

Damit löst sich wohl auch dein anderes Problem, das ich immer noch nicht richtig verstanden habe.

 

[hgef]

In der Tabelle Locations wird dir angezeigt, wie viele Bezugsdatensätze es gibt. Und da gibt es ein Feld, wo du die Veränderung der Anzahl eintragen kannst. Und je nachdem werden entweder neue Datensätze angelegt oder vorhandene werden gelöscht.

also diese funktion kenne ich nicht. was soll das sein?

 

[micki-mac]

Du schreibst einfach ein entsprechendes Script und ruft es mit einem Scripttrigger auf, wenn der Feldinhalt gesichert wird.