Hallo, habe folgende Schwierigkeit. Bsp:
Hund | | 4 |
Hunde | | 2 |
Hunde welpen | | 3 |
Müller springt | | 2 |
Müller tanzt | | 4 |
Tipp | | 2 |
Tipps | | 3 |
Nun möchte ich die ähnlichen Felder
gruppieren, und dann das ,,
ähnliche Wort" mit der
addierten zahl stehen haben. So:
Wäre so etwas möglich? Habe schon nach allen möglichen ,,
ähnlichkeitssuchen" gesucht, aber alles basiert nicht auf eine Spalte und ist mega komplex mit
.DLLs, VBA und
Modulen. Ich habe überlegt ob es nicht einfach mit
Group by zusammen mit
LIKE und
Count irgendwie gehen sollte?
Vielen Dank
Hallo,
nun, ganz so einfach ist das nicht, schon gar nicht nur mit like und Gruppierung... Es wird also "mega komplex".
Wodran machst Du denn "Ähnlichkeiten" fest?
Ist Müller und Müllerin das Gleiche
Oder "Hunde" und Hundert"
Vermutlich ist es zunächst nötig, am Konzept der Datenhaltung nach zu arbeiten..
Hallo DF6GL,
danke für die Antwort. Es ist so, dass Hund ein Produkt ist und Hunde, Hunds, Hundinen... Synonyme sind. Die sachen sind in einer Excel tabelle so abgelegt: In der ersten Spalte liegen die Hauptbezeichnungen: Hund, Katze, Maus. Und in der zeile folgen dann jeweils die synonyme.
Da ich es alles analysieren wollte und access ja nur auf eine spalte zugreifen kann, hatte ich die gesamte excel tabelle mit vba in eine große Spalte umgewandelt und die dann mit sql in access analysiert.
Nun sind ja die Hauptbezeichnungen und Synonyme zu denen untereinander, die möchte ich halt zu der Grundbezeichnung wieder zusammengruppieren.
Es hört sich mega kompliziert an. Denke das ist schon tiefe IT.
Idealer zustand wäre. Ich habe suchanfragen in meiner Datenbank, Query soll Abfragen analysieren in dem er es mit der Excel-Tabelle vergleicht und auch auf die Synonyme zugeht und mir dann sagt Hund wurde x mal gesucht, mit der Berücksichtigung der synonyme. Aber ich denke sowas ist unmöglich.
Hallo!
Bei Synonymen wird es einfacher, wenn du diese kennst. Dann kannst du sie in einer Tabelle (aber in 1:n-Struktur und nicht wie in Excel) ablegen und mit dieser Hilfstabelle suchen.
mfg
Josef
Hallo, ja genau, das ist in meinem Fall so, dass es nur um die Synonyme geht die ich auch in der Excel Tabelle hinterlegt habe. Zuerst hatte ich es nicht angesprochen weil ich dachte dass man es mit "like".. etc. viellecht leichter lösen könnte.
Danke dir für den Tipp. Ich habe ihn zwar leider nicht ganz verstanden. Aber bevor ich hier jetzt 100 fragen stelle versuche ich soweit wie möglich selber voranzukommen, (deine Antwort zu analysieren).
"like" wirst du weiterhin benötigen, falls du die Begriff innerhalb eines Textes suchen musst.
Prinzip:
select
S.Hauptbegriff, Count(*) as AnzahlTreffer
from
Quelltabelle Q
inner join
Suchbegrifftabelle S
On Q.zuDurchsuchenderText like '*' & S.Suchbegriff & '*'
Group By
S.Hauptbegriff
Die Tabelle "Suchbegrifftabelle" enthält beispielsweise
Suchbegriff | Hauptbegriff (=Synonym-Gruppe)
Hund | Hund
Hunde | Hund
Rüde | Hund
Dackel | Hund
Wenn nun im Text Hunde vorkommt würde das 2 Treffer für den Hauptbegriff "Hund" ergeben - 1x mit "*Hund*" und einmal mit "*Hunde*".
=> je nach Daten und Vorhaben nur ganze Wörter suchen oder die SQL-Anweisung so umbauen, dass immer nur 1 Treffer aus eine Gruppe gezählt wird.
mfg
Josef
Hallo Kloso,
du schreibst:
ZitatIn der ersten Spalte liegen die Hauptbezeichnungen: Hund, Katze, Maus. Und in der zeile folgen dann jeweils die synonyme.
Das ist doch schon "die halbe Miete".
Leider hast du dann
ZitatDa ich es alles analysieren wollte und access ja nur auf eine spalte zugreifen kann, hatte ich die gesamte excel tabelle mit vba in eine große Spalte umgewandelt und die dann mit sql in access analysiert.
Damit hast du die Synonyma-Information zerstört. Und wieso sollte Access nur auf eine Spalte zugreifen? Das Maximum liegt bei mehreren Hundert...
Folgende Idee, bezogen auf die Original-Excel-Datei:
1. Importiere die erste Spalte in eine Access-Tabelle tblHaupt. Primärschlüssel kann dabei direkt der Haupt-Begriff sein, oder spendiere der Tabelle ggf. noch einen Autowert als Primärschlüssel.
2. Importiere die gesamte Excel-Tabelle in eine zweite Access-Tabelle tblSynWork. Diese Tabelle benötigt Felder refHaupt, synonym1, synomyn2, usw. bis zur maximalen Anzal Synonyma in der Excel-Tabelle.
3. Erstelle eine dritte Access-Tabelle tblSynAlle mit den Feldern SynKey, RefHaupt und synWert.
4. Im Beziehungsfenster verknüpfe die Tabellen wie folgt:
tblHaupt.Hauptwert -- tblSynWork.refHaupt
tblHaupt.Hauptwert -- tblSynAlle.refHaupt.
5. Erstelle eine Anfüge-Abfrage. Dazu doppelklickst du alle drei Tabellen, so dass sie im Abfrage-Fenster erscheinen.
6. Dann Doppelklick (DK) auf tblHaupt.Hauptwert. Unten dann Anfügen an tblSynAlle.RefHaupt.
7. DK auf tblSynWork.synonym1. Unten anfügen an tblSynAlle.synWert. Kriterien: <> ""
8. Ausführen!
8a. Access sollte nun alle Synonyma, die in der zweiten Excel-Spalte standen, in die tblSynAll eintragen, jeweils mit Referenz auf den Hauptwert.
9. Wiederhole Schritte 7 und 8 für alle weiteren Synomyna-Spalten 2 bis x). Dabei aber keinen DK auf synonymx mehr machen, sondern unten synonymx in Kombifeld auswählen.
10.) Letztlich erhälst du in der Tabelle alle Synonyma mit jeweiligem Bezug auf den Hauptwert.
11.) Die Tabelle tblSynWork kannst du dann löschen (zuvor im Beziehungsfenster die Beziehung zu tblHaupt löschen).
12.) Wenn du jetzt eine Abfrage (über beide Tabellen) erstellst mit den Feldern tblHaupt.Hauptwert und tblSynAll.SynWert erhälst du
Hund Hunde
Hund Hündin
Hund Hunderasse
...
Leider fehlt ein Eintrag,
Hund Hund
aber den kann man mit Schritt 7 und 8 auch erzeugen (refHaupt statt synonymx auswählen).
Wenn du nun auf deine eigentliche Tabelle zugreifen willst, musst du formulieren:
select <alles mögliche> from tblEigentlich where <Kriterien> and tblEigentlich.Typ in (select synWert from tblSynAlle where tblSynAlle.RefHaupt = <selektionskriterium>)
<selektionkriterium> wäre z.B. "Hund"
So würdest du ohne Join mit der tblEigentlich auskommen, die ja vielleicht extern ist.
Zu kompliziert? OK, gebe ich zu. Man muss zuerst etwas mit den Original-Exceldaten jonglieren. Aber so oder so ähnlich könnte es klappen. Es macht natürlich nur dann Sinn, wenn die Excel-Datei mit den Bezeichnungen und Synonyma relativ selten geändert wird...
Ansonsten würde es sich anbieten, statt nach synonymen Begriffen für
ein Produkt zu suchen bzw. zu gruppieren, eine Produkt-Kennung (P-Nummer, P-ID) zu benutzen, die ja hoffentlich eindeutig bleibt, egal wie das Produkt benannt wird. Wenn ein Produkt einen neuen, zusätzlichen Namen erhält, sollte sich das in der Produkt-Kennung wiederspiegeln, also z.B.
P-Kennung | P-Bezeichnung | P-Intern
123456 | Weizenmehl Typ 405 | 123456
123456-1 | Sonnenmehl Typ 405 | 123456
123456-2 | Weizenmehl Typ 405 Aldi Süd | 123456
123456-3 | Weizenmehl Typ 405 Aldi Nord | 123456
Aber das nur nebenbei...
LG
crystal
Hallo,
ZitatDas Maximum liegt bei mehreren Hundert...
255, um genau zu sein.
ZitatrefHaupt, synonym1, synomyn2, usw. bis zur maximalen Anzal Synonyma in der Excel-Tabelle.
Hast du es immer noch nicht verstanden?
Aufzählungsfelder gehören als Datensätze in eine Tabelle; - in diesem Falle dann 1:n,
so wie Josef es bereits skizziert hatte.
gruss ekkehard
Hi Ekkehard,
ZitatHast du es immer noch nicht verstanden?
Aufzählungsfelder gehören als Datensätze in eine Tabelle; - in diesem Falle dann 1:n,
so wie Josef es bereits skizziert hatte.
Nur die Ruhe, aber in diesem Fall dient meine Tabelle tblSynWork ja nur als
temporäre Tabelle, die nur und genau dazu dient, die "Aufzählungsfelder" zu eleminieren und dadurch den Excel-Datenbestand zu normalisieren.
Und wie ich geschrieben habe, gehe ich von einem einmaligen Vorgang aus.
lg
crystal
Um Josef's Hinweise stark gekürzt zu wiederholen und auf die Frage im Thementitel einzugehen: Mit einer ordentlichen Datenstruktur (inklusive notwendiger Tabellen) kann man mit einfachen (also nichtkomplexen) SQL-Anweisungen ohne alles VBA und temporärem Zwischenzeugs recht oft zu einem guten Ergebnis kommen, und das einfach und i.d.R. performant.
Hallo,
leider kennen wir die Datenstrukturen nicht.
Ich bin davon ausgegangen, dass die Excel-Tabelle mit den Synonyma eher nur einmal in Access importiert werden müsste (freilich normalisiert).
Dies wäre mit meinem skizzierten Schema relativ einfach möglich, ohne VBA bemühen zu müssen und als Resultat hätte man eine Tabelle, in der ALLE Synonyma mit Bezug auf den Hauptbegriff gespeichert sind.
Ein solcher einmaliger "manueller" Vorgang würde also die Daten bereitstellen, die man für weitere Selektionen benötigt.
ZitatMit einer ordentlichen Datenstruktur (inklusive notwendiger Tabellen) kann man mit einfachen (also nichtkomplexen) SQL-Anweisungen ohne alles VBA und temporärem Zwischenzeugs recht oft zu einem guten Ergebnis kommen, und das einfach und i.d.R. performant.
Solche allgemeinen Lehrbuch-Statements nützen absolut nichts. Werde doch mal konkret, lieber ebs17 und lade ein Beispiel hoch, dass deine These anschaulich erklärt.
Warum sollte man die Einträge mit Like-Anweisungen selektieren (die ja durchaus auch falsche DS zurückliefern könnten), wenn man statt dessen die vorhandenen Beziehungen (aus der Excel-Datei) adäquat umgesetzt benutzen kann?
Angenommen wir hätten für Hund die Synonyma Hündin, Hunde, Wolfshund und Welpe. Wie würdest du diese Synonyma in einer Abfrage "treffen" können? Bei diesem einfachen Beispiel noch machbar, aber für die allgemein gültige Abfrage geht es nur mit einer Referenztabelle und einer In-Bedingung.
Oder beweise, dass es auch anders geht.
lg
crystal
PS: ebenso einfach wäre es möglich, ein einfaches Formular zu bauen, in dem man
1. alle Synonyma eines Hauptbegriffs sieht und
2. ein neues Synonym hinzufügen kann.
Zitat von: KlosoDie sachen sind in einer Excel tabelle so abgelegt: In der ersten Spalte liegen die Hauptbezeichnungen: Hund, Katze, Maus. Und in der zeile folgen dann jeweils die synonyme.
Damit ist die Struktur doch klar, also bekannt: 1. Spalte Hauptbezeichnung, dann Aufzählungsfelder für Synonyme. Das man solche Aufzählungsfelder besser in Datensätze einer zusätzlichen Tabelle auflöst, sollte wohl nicht extra diskutiert werden.
Das nicht deshalb, um irgendeiner Prinzipienreiterei zu genügen, sondern weil solche Strukturen erst die unmittelbare und einfache Anwendung von SQL ermöglichen. Der Rennwagen SQL benötigt entsprechende (Schnell-)Straßen, um seine Stärken richtig zur Geltung zu bringen. Zum Hoppeln durch Wald und über Wiese sind andere Gefährte nicht nur eine Alternative, sondern schnell eine bessere.
Wer jetzt ein hochgeladenes Beispiel für eine normale 1:n-Beziehung benötigt, sollte sich vielleicht vorher in ein Selbststudium mit einem guten Grundlagenbuch zurückziehen.
Eine Abfrage auf eine solche 1:n-Beziehung hat Josef bereits gezeigt. Ich weiß jetzt nicht, was da eine Wiederholung bringt. Zu einer Wiederholung kann man auch kommen, wenn man Beiträge mehrfach liest, um sich dann doch Sinn und Inhalt des Geschriebenen zu nähern.
Zitat von: KlosoDa ich es alles analysieren wollte und access ja nur auf eine spalte zugreifen kann ...
Richtig ist, dass für SQL gleiche Informationen in genau einer Spalte vorkommen sollen. Dies aber wie gerade angesprochen über die Datenumformung von Aufzählungsfeldern in Datensätze einer weiteren Tabelle.
Zitat von: Klosohatte ich die gesamte excel tabelle mit vba in eine große Spalte umgewandelt
Für zusammenpepappte Informationen hat SQL wenig bis gar keine brauchbare Verarbeitungsmethoden, da sollte man dann Textverarbeitung bemühen.
Indexnutzung als wirksames Mittel zur Verarbeitungsperformance auch bei größeren Datenmengen (denn warum sind wir in einer Datenbank) fiele dann total flach.
Wenn die Synonymtabelle so gestaltet und die Datenlage derart ist, dass man auf eine
Ähnlichkeitsprüfung verzichten kann zugunsten einer Prüfung auf
Gleichheit, um so besser. Atomare Informationen unmittelbar vergleichen kann SQL besonders gut.
Aber man kann auch auf die eigentliche Fragestellung (Erstbeitrag: Ähnlichkeit) eingehen, irgendwo gibt es da ja Gründe für die ursprüngliche Formulierung.
@crystal: Dich zu überzeugen bei Deinen Meinungen habe ich längst beiseite gelegt, das ist mir zu anstrengend, zumal Du meine Sprache wie bekundet eh nicht verstehst. Meine Hinweise sollen eher Dritten dienen.
Hallo Gemeinde,
wer genau nachliest wird feststellen, dass mein Beitrag ein Rezept dafür darstellt, die Daten der Excel-Tabelle in zwei Access-Tabellen zu überführen, die eine - man staune - 1:n-Beziehung haben, ja.
Die Struktur der Excel-Tabelle ist freilich klar, nicht aber die der Access-Anwendung, lieber ebs17.
Es geht ja wohl eher darum, anhand der Synonyma eines Hauptbegriffs auf weitere Datenbestände innerhalb der Access-Anwendung, evtl. auch auf Daten einer Server-Datenbank zuzugreifen, oder? Wobei es wohl so ist, dass in diesen Datenbeständen der Hauptbegriff nicht vorhanden ist, so dass man dort nur über die Synonyma suchen kann.
Zitat@crystal: Dich zu überzeugen bei Deinen Meinungen habe ich längst beiseite gelegt, das ist mir zu anstrengend, zumal Du meine Sprache wie bekundet eh nicht verstehst. Meine Hinweise sollen eher Dritten dienen.
Kann ich nur wiederholen, an dich gerichtet, ebs17.
Genug OT; ich würde mich freuen, wenn du, Kloso, mal kurz schreiben würdest, wie die von mir angesprochenen weiteren Daten aussehen und ob ich mit meiner hier geäußerten Vermutung in etwa richtig liege.
Danke,
crystal
Hallo crystal,
ZitatDie Struktur der Excel-Tabelle ist freilich klar, nicht aber die der Access-Anwendung
Was soll man dazu sagen? Eberhard würde sicher ein passender Spruch einfallen ;)
Das (also die Struktur in Access) ist doch erste, was ich mache bevor/während
ich über den Ablauf eines Imports nachdenke.
gruss ekehard
Hallo Ekkehard,
ich meinte doch nur, dass die Struktur der Access-Anwendung des Thread-Starters nicht bekannt ist, so dass anhand seiner Angaben nicht ersichtlich ist, wie er die Information der Excel-Datei prinzipiell in der Access-Anwendung einsetzen will. Was ist daran seltsam?
lg
crystal
Hallo crystal,
Zitatdass die Struktur der Access-Anwendung des Thread-Starters nicht bekannt ist,
O.K., so hatte ich es nicht verstanden. Trifft aber trotzdem nicht, denn die Struktur
haben Josef und Eberhard ja schon gleich zu Beginn aufgezeigt.
Sie ist ja auch grundlegend für den Import und (vor allem wohl) die Weiterverarbeitung,
wozu Josef auch schon einen Ansatz gepostet hat. War somit eigentlich das einzige
Thema im Thread, zum Status quo also
bekannt.
gruss ekkehard
Hallo an alle, ich bedanke mich sehr für die solch große Beiträge zu meinem Problem.
Crystal:ZitatZu kompliziert? OK, gebe ich zu. Man muss zuerst etwas mit den Original-Exceldaten jonglieren. Aber so oder so ähnlich könnte es klappen. Es macht natürlich nur dann Sinn, wenn die Excel-Datei mit den Bezeichnungen und Synonyma relativ selten geändert wird...
Ja, die Synonyme Tabelle wird oft geändert und aktualisiert, da kommen auch neue Begriffe dazu. Darum wäre dein Vorschlag zwar möglich, aber zu umständlich zum aktualisieren.
Beaker:Zitat255, um genau zu sein
Da würde dann wieder dieses Problem, was ich schon mal hatte auftauchen: http://www.access-o-mania.de/forum/index.php?topic=21835.msg125463#msg125463 (http://www.access-o-mania.de/forum/index.php?topic=21835.msg125463#msg125463), dass ich WHERE, und JOIN IN nicht auf alle Spalten (Tabelle.*) beziehen kann sondern nur auf eine und bei mehreren SynonymeSpalten wäre es sehr umfangreich sie alle (im Code) aufzuzählen.
ebs17:ZitatMit einer ordentlichen Datenstruktur
Ja. Das habe ich nun verstanden, dass es der Kernpunkt ist. Versuche das nun zu analysieren. Ob das in meinem Fall möglich ist.
ZitatAber man kann auch auf die eigentliche Fragestellung (Erstbeitrag: Ähnlichkeit) eingehen, irgendwo gibt es da ja Gründe für die ursprüngliche Formulierung.
Weil ich ursprünglich schon den Query fertig hatte (siehe mein erster Beitrag), jedoch waren dann synonyme wie hund = 1 und hundE = 3 in einer spalte untereinander und da habe ich halt zuerst den Gedanken gehabt, dies mit hilfe von
(z.Bsp 75%tiger ähnlichkeit zu gruppieren) und Hund = 4 bekommen könnte, was aber nun völliger quatsch sei
(unmöglich).
JosefP.:ZitatDie Tabelle "Suchbegrifftabelle" enthält beispielsweise
Suchbegriff | Hauptbegriff (=Synonym-Gruppe)
Hund | Hund
Hunde | Hund
Rüde | Hund
Dackel | Hund
Das ist nun mein Anhaltspunkt an dem ich sage, dass sieht nun für mich realistisch aus. Jedoch muss ich dann meine Excel-Tabell komplett umstrukturieren und in zwei spalten dann machen Spalte1: Begriff Spalte2: Synonyme. Dann könnte man es ordentlich gruppieren und alle synonyme wären auf Spalte1, sprich, den Begriff grupiert.
crystal:ZitatEs geht ja wohl eher darum, anhand der Synonyma eines Hauptbegriffs auf weitere Datenbestände innerhalb der Access-Anwendung, evtl. auch auf Daten einer Server-Datenbank zuzugreifen, oder? Wobei es wohl so ist, dass in diesen Datenbeständen der Hauptbegriff nicht vorhanden ist, so dass man dort nur über die Synonyma suchen kann.
Genau so sieht es aus. Ich habe eine ServerDatenbank die ich analysiere. Da tauchen in einer Spalte dann die begriffe auf die meist "anders" geschrieben werden(also wie synonyme). Mein Ziel ist es einfach die Häufigkeit dieses Begriffes
(inkl. seine Synonyme) zu analysieren.
Da bleibt mir im Endeffekt nur die Variante von
JosepfP klar.
Versuche nun mein Glück, schaue wie weit ich mit meinen
schwachen Kenntnissen voran komme.
Bedanke mich aber wirklich für so viel Mühe!!!
Hallo Kloso,
danke für deine ausführliche Antwort.
Bitte prüfe doch, ob es in der Server-Datenbank nicht doch ein Feld gibt, das eindeutig ist, egal welcher neuer Begriff (Synonym) eingegeben wird. Denn die Excel-Datei wird ja auch "irgendwie" aus den Daten der Server-DB erstellt, deshalb wird es die erforderliche Beziehung Hauptbegriff->Synonym dort vermutlich auch geben.
Ggf. könntest du die "Server-Datenbank-Administratoren" bitten, dir einen VIEW auf die Daten zu erstellen, in dem sowohl Hauptbegriff als auch Synonym enthalten ist. Das würde deinen Aufwand dann erheblich reduzieren...
Viel Erfolg anyway,
crystal
PS: Ich gehe mal davon aus, dass du nur beschränkten Zugriff auf die Server-Datenbank hast - alles andere wäre aus Sicht der Admins fahrlässig. Die Admins haben dir also einen oder mehrere Views auf die Server-Datenbank bereitgestellt (readonly), damit du damit werkeln kannst.
Da wäre es doch ein leichtes, diese Views so zu erweitern, dass du dein Vorhaben - schwups - umsetzen kannst, selbst wenn es sich um SAP handeln sollte...
Hallo crystal,
ZitatDenn die Excel-Datei wird ja auch "irgendwie" aus den Daten der Server-DB erstellt,
Leider nein, die Excel Datei ist von einer entstanden, der genau weiß nach was in der DB gesucht werden kann(was in der Server-DB dann als Eintrag auftaucht), und sich dann ungefähr die Frage gestellt hat-> welche synonyme könnte man haben, welche Tippfehler kann der User mal machen, und hat es in der Excel Tabelle hinterlegt, damit man dann eine etwas genauere Analyse auf bestimmte (Such)Begriffe machen kann.
Hallo Kloso,
also das ist ja schon irgendwie seltsam.
Das Server-System MUSS doch mit irgendwie eindeutigen Daten arbeiten (z.B. Produkt-Nummer), wenn dort ein neuer Datensatz angelegt wird. Oder können dort Datensätze "im Nebel" erstellt werden?
Wie werden denn Datensätze im Server-System zusammengeführt, in denen mal Hündin und mal Dackel steht, wobei sich beide auf denselben Hauptbegriff Hund beziehen?
Bitte frag doch mal genau bei den Admins nach.
Deine Aussage im letzten Posting würde bedeuten, dass die Server-DB letztlich unbrauchbar wäre, was ich mir allerdings nicht vorstellen kann. Nochmal: Wenn es dort möglich ist, Bezeichnungen frei einzugeben, wird es trotzdem ein Feld geben, in dem die "eigentliche" Referenz gespeichert ist oder anders gesagt ein Feld, anhand dessen es möglich ist, Datensätze mit unterschiedlichen Bezeichnungen als "zusammengehörend" zu identifizieren.
Vielleicht ist nur die Eingabe-Maske schlecht gebaut, so dass man das Feld "Hauptbegriff" nicht sieht, sondern nur das Freitext-Feld (Synonym). Dann würde es mich nicht wundern, dass ein "genervter" Mitarbeiter eine solche Excel-Tabelle händisch erstellt.
Bitte prüf das und lass uns wissen, wie es aussieht.
Grüße
crystal
Hallo crystal,
also ich habe gehofft ich schaffe es ohne ins Detail zu gehen :)
du musst es dir so vorstellen. Du gibts in google was ein - google listet dir das gesuchte auf. Ich bekomme in meiner Server datenbank zu sehen, was gesucht worden ist und zu welcher Zeit und wie viele Treffer es gibt. So eine Datenbank ist das. Darum jedes mal wenn jemand etwas in unserer Suche was sucht, bekomme ich es in meiner Datenbank.
Ich analysiere das. Ich analysiere sehr viel daraus, wie viele suchen es gibt, wie viele suchen nur ein Wort wie viele einen Satz und so weiter.
Es gibt aber bestimmte Sachen die gesucht werden. Eins davon ist genau das was ich am Beispiel mit den Hunden gemacht habe. Sagen wir mal es werden Tiere gesucht. Jemand gibt "Hund" ein und sucht in der von der Suchmaschine hinterlegten Servern nach dem Inhalt. Parallel ist da irgendwo im Kern der Suchmaschine ein Tool hinterlegt der mit Synonymen arbeitet. Dieser Tool braucht eine bestimmte Form einer Excel Tabelle mit synonymen die dann in das für das Tool formatierte Format konvertiert wird.
Ich greife mir einfach die für das Tool erstellte Excel Tabelle und versuche mit ihrer Hilfe die Suchen zu analysieren.
Habe schon alles was nur möglich ist erfolgreich analysiert. Nur bleibt mir halt nur noch dieser einfacher (in Gedanken aber nicht im Prozess) weg die Suchbegriffe in abhängigkeit von excel zu analysieren.
Ich habe eigentlich schon folgendes gemacht. Vielleicht wird es dann einfacher:
- Ich habe schon mit einem tollen
Query für den Monat xx ein
gutes Ergebnis, der mir folgendes Liefert:
Ergebnis (mit dem Query) in Access:
Suchbegriff | | Anzahl |
Hund | | 3 |
Hunde | | 2 |
Hund welpen | | 1 |
Die original (excel)Synonym Tabelle:
Begriff | | Synonyme | | Synonyme | | Synonyme |
Hund | | Hunde welpen | | Dogs | | Hunde | |
Katze | | Katzen | | Cats | | Cat | |
Maus | | Mäuse | | Mause | | Mouse | |
Es wäre ja in etwa wie folgt:
Prüfe Spalte "Suchbegriff" mit der Tabelle
Synonyme, achte auf die Spalten "Synonyme" und gib sie dann bei Spalte "Begriff" in der
Ergebnisstabelle dazu. Schlielich gruppiere die Begriffe und zähle die Spalte "Anzahl" zusammen.
Suchbegriff | | Anzahl | Begriff | |
Hund | | 3 | Hund | |
Hunde | | 2 | Hund | |
Hund welpen | | 1 | Hund | |
Nun ist mein Ziel eigentlich einfach (egal ob in Acces oder exportiert in Excel):
Das wäre so das was ich mir vorstellen würde. Was sagt ihr, reicht da der Ansatz von JosefP?
Liebe Grüße
Hallo,
natürlich passt der Vorschlag von JosefP...
Du musst nur die Excel-Liste in eine (normalisiere) Access-Tabelle umsetzen (Wurde auch schon gezeigt):
ZitatBegriff Synonym
----------------------
Hund Hund
Hund Hunde
Hund Welpen
Hund Dogs
Katze Katze
Katze Katzen
Katze Cats
Katze Cat
Maus Maus
Maus Mäuse
Maus Mice
Maus Mouse
und die Abfrage an die Namen anpassen.
Gebe es eine einfachere möglichkeit diese excel tabelle wie davor beschrieben zu normalisieren ohne es per hand abzutippen?
ZitatDie original (excel)Synonym Tabelle:
Begriff | | Synonyme | | Synonyme | | Synonyme |
Hund | | Hunde welpen | | Dogs | | Hunde | |
Katze | | Katzen | | Cats | | Cat | |
Maus | | Mäuse | | Mause | | Mouse | |
Wahrscheinlich VBA mäßig, oder? Oder hat excel so eine Funktion?
Hallo,
es läuft ein ähnlich gelagerter Thread:
http://www.access-o-mania.de/forum/index.php?topic=21877.0
Hallo,
ZitatIch greife mir einfach die für das Tool erstellte Excel Tabelle
Wenn da irgendwo eine Excel-Tabelle generiert wird, ist es da nicht möglich noch
eine zweite, für dich geeignete ("normalisierte") Excel-Tabelle zu generieren?
gruss ekkehard
Hallo Beaker s.a.,
leider nein, das hatte ich auch schon probiert.
Aber ::)
Ich habe es nun super hinbekommen. Funktioniert genau wie es haben möchte. Super Super Super! Nur noch eine kleine optische Korrektur bekomme ich nicht hin. (bisschen weg von meinem Thema sondern nur auf SQL Sprache bezogen:)
Bei folgendem SQL Code:
SELECT [Tabelle1].[SpalteA], [Tabelle2].[Spalte1]
FROM [Tabelle1], [Tabelle2]
WHERE ([Tabelle1].[SpalteA] = [Tabelle2].[Spalte1])
UNION ALL
SELECT [Tabelle1].[SpalteA], [Tabelle2].[Spalte1]
FROM [Tabelle1], [Tabelle2]
WHERE ([Tabelle1].[SpalteA] = [Tabelle2].[Spalte2])
UNION ALL
SELECT [Tabelle1].[SpalteA], [Tabelle2].[Spalte1]
FROM [Tabelle1], [Tabelle2]
WHERE ([Tabelle1].[SpalteA] = [Tabelle2].[Spalte3]);
UNION ALL
...
Union All geht bis SpalteX.
Nun ist die Frage ob man es schöner kombinieren könnte. Es ändern sich ja hauptsächlich nur die "Spalte1,Spalte2,Spalte3..SpalteX". Ob man das Union umgehen könnte und stattdessen es irgendwie mit Komma oder And lösen könnte?
Viele Grüße
Nein, anders kannst Du die UNION-Abfrage nicht schreiben. Entweder Du bist bei vielen Synonym-Spalten tippfleißig, oder aber Du setzt Dir in einer VBA-Schleife die gewünschte Anweisung zusammen.
Persönlich würde ich aber auf die UNION-Abfrage verzichten und eine neue Tabelle erstellen, da allerdings die Exceltabelle umformen:
Public Function PivotToList(ByVal NamePivotTable As String, _
ByVal NameListTable As String, _
ByVal NumberFirstMatrixField As Byte, _
ByVal NameTitleField As String, _
ByVal NameValueField As String, _
ByVal TypeValuefield As DataTypeEnum, _
Optional ByVal UseNullValues As Boolean = False, _
Optional ByVal IntoNewTable As Boolean = False) As Boolean
On Error GoTo ErrHandler
Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Dim sSQL As String
Dim sConstantFields As String
Dim bExistsTable As Boolean
Dim i As Long
Set dbs = CurrentDb
bExistsTable = TableExistsDAO(dbs, NameListTable)
If IntoNewTable Then
If bExistsTable Then dbs.TableDefs.Delete NameListTable
End If
Set rst = dbs.OpenRecordset(NamePivotTable, dbOpenSnapshot)
With rst
If Not bExistsTable Or IntoNewTable Then
' Listtabelle neu erstellen
Set tdf = dbs.CreateTableDef(NameListTable)
For i = 0 To NumberFirstMatrixField - 2
Set fld = tdf.CreateField(.Fields(i).Name, .Fields(i).Type)
tdf.Fields.Append fld
sConstantFields = sConstantFields & "[" & .Fields(i).Name & "], "
Next
Set fld = tdf.CreateField(NameTitleField, dbText)
tdf.Fields.Append fld
Set fld = tdf.CreateField(NameValueField, TypeValuefield)
tdf.Fields.Append fld
dbs.TableDefs.Append tdf
RefreshDatabaseWindow
End If
' Inhalte übertragen
For i = NumberFirstMatrixField To .Fields.Count - 1
sSQL = "INSERT INTO " & NameListTable & " (" & sConstantFields & "[" & _
NameTitleField & "], [" & NameValueField & "])" & _
" SELECT " & sConstantFields & "'" & .Fields(i).Name & "', [" & _
.Fields(i).Name & "] FROM " & NamePivotTable
If Not UseNullValues Then
sSQL = sSQL & " WHERE [" & .Fields(i).Name & "] IS NOT NULL"
End If
dbs.Execute sSQL, dbFailOnError
Next
.Close
End With
' ' Beispiel für ein Setzen eines zusammengesetzten Index
' sSQL = "CREATE INDEX NachnameVorname ON Listtabelle(Nachname, Vorname)"
' dbs.Execute sSQL, dbFailOnError
Set rst = Nothing
Set dbs = Nothing
PivotToList = True
Exit_Function:
Exit Function
ErrHandler:
MsgBox "Fehler: " & vTab & Err.Number & vbCrLf & Err.Description
Resume Exit_Function
End Function
Public Function TableExistsDAO(pDb As DAO.Database, _
ByVal psName As String) As Boolean
Dim s As String
On Error Resume Next
s = pDb.TableDefs(psName).Name
TableExistsDAO = (Err.Number = 0)
End Function
Die Tabelle wird wegen "Fertigkeit" in der folgenden Berechnung schneller sein, außerdem lassen sich Felder indizieren, was der Performance einen zusätzlichen Schub geben kann.
Hallo nochmal,
wie wäre denn folgender Vorschlag:
1. du verknüpfst die Excel-Datei mit Access
2. dadurch kannst du auf die verknüpfte Tabelle so zugreifen, als wäre sie eine Access-Tabelle
3. sagen wir die Excel-Tabelle heißt etab mit den Feldern haupt, syn1, syn2...synx
4. jetzt könntest du eine Union-Abfrage erstellen (Name uquery):
select haupt, syn1 as syn from etab
union
select haupt, syn2 as syn from etab where syn2 <> ""
union
select haupt, syn3 as syn from etab where syn3 <> ""
...
union
select haupt, synx as syn from etab where synx <> "";
5. diese Abfrage uquery kannst du dann in deiner eigentlichen Suche angeben (Bsp.: du suchst nach Hund):
select uquery.haupt, uquery.syn, <irgendwas> from uquery, <irgendwo>
where <suchfeld>
in (select haupt, syn from equery where haupt="Hund")
group by syn;
Damit bleibt die externe Excel-Datei unangetastet (sie ändert sich ja) und sie braucht nicht in Access kopiert zu werden. Sie hat dann leider keinen Index, aber das ist vielleicht zu verschmerzen - je nach Größe der Datei.
uquery ist dann eine virtuelle Tabelle, die nur so lange existiert, wie die eigentliche Abfrage läuft. Deine Excel-Datei braucht nicht umstrukturiert werden, so dass du immer auf die aktuelle Version zugreifst.
Die Performance wird eher etwas schlecht sein; schlecht performant ist aber nur der Teil, der die IN-Tabelle zusammenbaut.
Möge ein Spezialist sich das anschauen und kommentieren, bevor du es probierst.
lg
crystal
ZitatDamit bleibt die externe Excel-Datei unangetastet (sie ändert sich ja)
Wenn zu den x Synonym-Spalten weitere hinzukommen, erfährt es die UNION-Abfrage nicht, und die nachfolgende Verarbeitung auch nicht. Ist das beabsichtigt?
Strukturprobleme löst man besser grundlegend, statt dass da ein Programmierer alle Entwicklungen im Auge behalten und nachprogrammieren muss, es sei denn, der Programmierer muss mangels richtiger Aufgaben beschäftigt werden.
ZitatDatei unangetastet
Eier werden von Natur aus mit Kalkschale und vom Menschen mit Pappe-Umverpackung geliefert. Was passiert, wenn man Rühreier machen will?
Sorry liebe Mods,
ich muss doch kurz auf den unsinnigen Post von Eberhard antworten.
1. Es gibt keine fertigen Programe oder Anwendungen. Man muss immer irgendwo nachbesern oder erweitern.
2. Wenn Kloso bei Umsetzung meiner Idee x ausreichend groß wählt, wird das schon eine Weile funktionieren. Ansonsten muss er dann nur einen oder mehrere Unions hinzufügen. Einfache Sache.
3. Deine Beispiele aus der "realen Welt" sind eigentlich fast immer skurril, unpassend und unverständlich. Lass es doch und kommentiere einfach nur sachlich und fachlich fundiert.
lg
crystal
Im Übrigen habe ich meine Idee ja nicht als die Lösung per se dargestellt, sondern allenfalls als Alternative, die von Kloso - weil ohne VBA - vielleicht einfacher nachvollzogen werden kann...
ZitatWenn Kloso bei Umsetzung meiner Idee x ausreichend groß wählt, wird das schon eine Weile funktionieren.
Wenn die Abfrage nicht vorhandene Felder der unangetasteten Tabelle verwendet, wird sie gleich in einen Fehler laufen.
Ist das jetzt Logik oder Unsachlichkeit?
@ebs17
Weder noch. Es ist einfach nur nicht richtig überlegt.
ha s1 s2 s3 s4 s5 s6 s7 s8 s9 (Feldnamen der Excel-Tabelle)
---------------------------------
aa a1 a2 a3 a4 a5
bb b1 b2 b3 b4
cc c1
dd d1 d2 d3
Läuft hier die Abfrage
...
union select ha, s6 as sy ... where s6 <> ""
union select ha, s7 as sy ... where s7 <> ""
...
in einen Fehler?
Ich bitte dich einfach nur, dich sachlich mit meiner Idee zu beschäftigen und eine simple Frage zu beantworten: wäre sowas grundsätzlich möglich (ohne Rücksicht auf Performance und "Tabus")?
Ich finde meine Idee nämlich grundsätzlich ganz cool - und sie kommt ohne VBA aus (vgl. Thread-Thema). Auch würde mich interessieren, was DF6GL, Josef P., Beaker s.a. und andere davon halten...
lg
crystal
Hallo crystal,
Na, wenn du mich so direkt fragst, kann ich Eberhard nur zustimmen.
Sch... auf "ohne VBA", wenn's flexibler ist und nicht weiter angepasst
zu werden braucht, wenn Daten dazu kommen, dann in Gottes Namen
"warum nicht?".
Und wenn Eberhard sagt "mach' dies besser mit VBA", dann kannst du
ihm schon glauben, dass alles andere nur suboptimal ist, - bestenfalls.
gruss ekkehard
P.S. (OT):
Eberhards
ZitatBeispiele aus der "realen Welt"
sind eigentlich immer sehr passend. Obwohl beim letzten habe ich auch
eine Minute länger gebraucht ;)
Zitatwäre sowas grundsätzlich möglich
Wenn Du unterstellen kannst, dass es in der Exceltabelle für nicht vorhandene Inhalte bereits Spaltenüberschriften gibt: Ja.
Die unangetastete Exceltabelle nimmst Du da aber selber nicht ernst, und die Erstellerin wird wohl kaum von folgenden Sorgen ahnen und da Spaltenüberschriften vortragen für eine Weile.
Zitatohne Rücksicht auf Performance
Nun, es gibt Abfragen, die funktionieren. Kommen aber ein paar Daten mehr dazu, dauert das Funktionieren so lange, dass der User an einen Absturz glaubt. Welcher Nutzer wünscht sich das?
Datenbanklösungen zu bauen, die mengenuntauglich/unperformant sind, ist diskutabel. Das bewusst zu tun, obwohl man mit vergleichbarem Aufwand anderes machen könnte, ist zumindest Verschwendung von Zeit des Nutzers und am Ende auch des Entwicklers, der in die Pflicht des Optimierens genommen wird. Man wird sich wünschen, dass der Verursacher-Entwickler in die Pflicht genommen wird und nicht andere hinterher aufräumen müssen.
Zum Querlesen: Es war einmal eine kleine Exceltabelle ... (http://www.ms-office-forum.net/forum/showthread.php?t=289614)
Hat sich denn schon jemand für die vorhandenen / potentiellen Datenmengen in der Suchmaschine interessiert? Die Notwendigkeit dafür nimmt ab, wenn man sich gleich am möglichen Optimum für mögliche Performance orientiert.
ZitatIch finde meine Idee nämlich grundsätzlich ganz cool
Das darfst Du. Zur Auswahl zwischen Varianten müssen einem erst mal Varianten einfallen. Sowie dann auch: Das üblich Beste kann sich auch als schlecht erweisen, wenn spezielle Bedingungen eintreten. Man ist also mit anhaltender Restkritik zu allem sowie dem Wissen um Varianten gut beraten.
Du darfst aber davon ausgehen, dass hier die meisten Teilnehmer Vorschläge gemäß Best practice (https://de.wikipedia.org/wiki/Best_practice) ihrer Möglichkeiten und Erfahrungen geben. Der geplagte Fragesteller wird das auch irgendwie erwarten.
Wenn man eine ungünstige Datenstruktur (die Exceltabelle) vorfindet, kann man die Umformungen
laufend und immer wieder während jeder der Suchabfragen machen, oder man macht die Umformung einmalig und konsequent (mit Zugabe Indexunterstützung), z.B. bei Beginn der Sitzung zu den Suchabfragen. Die Exceltabelle wird kaum eine Aktualisierungsfrequenz von Sekunden haben.
Es ist bekannt, dass die ellenlange und nach eigener Einschätzung mit Performanceproblemen behaftete UNION-Abfrage mit jeder Suche neu ausgeführt wird?
Zeit und Aufwand schätzen und bewerten, das darf jeder für sich. Meine Wahl ist nachlesbar.
Man sollte zusätzlich auch nicht aus den Augen verlieren, woher die Wunsch auf Verzicht auf VBA stammt:
Zitat von: KlosoHabe schon nach allen möglichen ,,ähnlichkeitssuchen" gesucht, aber alles basiert nicht auf eine Spalte und ist mega komplex mit .DLLs, VBA und Modulen.
Das ist auf die Suche gemünzt, zumindest in meiner Wahrnehmung.
Wenn aber Kloso irgendein Access-Frontend in Verwendung hat, gibt es da automatisch jede Menge Ereignisse (Form_Open), die man zu einer kleinen Prozedur zur Aufbereitung der Exceltabelle nutzen kann. Da ist der Schritt der Datenumformung bereits nachhaltig erledigt, ehe der Suchvorgang beginnt. Die Lebensdauer der umgeformten Exceltabellenkopie kann man dann selber festlegen, hier dann sicher entsprechend der Dauer der Sitzung zur Synonymsuche, maximal Zeit des geöffneten Frontends.
Der Suchvorgang selber ist dann astreines SQL, nachdem der Nutzer seine Suchparameter hinzugefügt hat.
So würde ich es für mich machen, und daher kann ich es auch anderen nahelegen.
//OT - Beispiele aus der "realen Welt":
Ich war mal im Verkauf tätig, bei ganz normalen Menschen.
Axel J. Bertling sagte: Es beschwert sich niemand, wenn man sofort versteht. Damit man verstanden wird, rede mit jedem wie mit einem vierzehnjährigen Mädchen. Na, auch da gibt es Ausnahmen.
Danke für deinen Kommentar, Ekkehard.
Um es nochmal klarzustellen:
Ich habe eine Idee gepostet, die m.E. funktionieren würde.
Die Zahl der Synonyma in der Excel-Datei ist ja irgendwie endlich und wird nicht plötzlich explodieren. Das hat ja auch Kloso mit seiner eigenen Lösung (mit viel zu komplizierten Selects) schon angedeutet, indem er "x" eingeführt hat.
Meine pragmatische Idee zeigt doch nur:
1. es wäre möglich, x Attribute per Union so umzugestalten, dass sie per where...in abgerufen werden können
2. meine Idee kommt ohne VBA aus
3. freilich hat meine Idee den Nachteil, dass "x" irgendwann vielleicht zu klein ist
4. wie oft wird 3. vorkommen?
5. prinzipiell ist meine Idee doch cool, einmal abgesehen von 3.
Im übrigen glaube ich solchen Sätzen
ZitatUnd wenn Eberhard sagt "mach' dies besser mit VBA", dann kannst du
ihm schon glauben, dass alles andere nur suboptimal ist, - bestenfalls.
prinzipiell nicht, denn niemand besitzt die absolute Wahrheit und es ist immer besser, Meinungen und Aussagen zu hinterfragen, als sie unreflektiert zu akzeptieren. Wenn sich tausend Fische in engem Schwarm bewegen, wird am Ende nur der dem Netz entgehen, der etwas abseits geschwommen ist (um auch mal ein blumiges Beispiel zu bringen).
Während ich dies schreibe, hat ebs17 eine neue Antwort eingestellt und ich bin positiv überrascht: hier lese ich zum ersten Mal Argumente, die sogar ich (!) nachvollziehen kann (einmal abgesehen von einigen Details und dem Nachsatz).
Ich kann es nur wiederholen: dies ist ein Diskussions-Forum und so sollten Ideen auch einfach nur diskutiert werden, um letztlich den Fragesteller sowie Mitleser etwas weiter zu bringen UND zu zeigen, dass es mehrere Wege zur Lösung seines Problems geben kann.
Niemand hat die Wahrheit gepachtet und niemand ist unfehlbar. Meine Einwürfe und Ideen sollen daran erinnern und die nicht seltene - ich nenne es einmal so - Arroganz hinter mancher Antwort aufzeigen.
OK, Mods, damit habe ich wieder teilweise OT geschrieben. Es steht euch frei, mich dafür "mundtod" zu machen.
Ansonsten lg
crystal