Eine komplexe Ähnlichkeitsgrupierung in Access SQL ohne VBA möglich?

[Kloso]

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:

Hund		9
Mueller		6
Tipp		5

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

[DF6GL]

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..

[Kloso]

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.

[Josef P.]

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

[Kloso]

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).

[Josef P.]

"like" wirst du weiterhin benötigen, falls du die Begriff innerhalb eines Textes suchen musst.

Prinzip:

Code [Auswählen] Erweitern

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

[crystal]

Hallo Kloso,

du schreibst:

In 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

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.

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

[Beaker s.a.]

Hallo,

Das Maximum liegt bei mehreren Hundert...

255, um genau zu sein.

refHaupt, 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

[crystal]

Hi Ekkehard,

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.

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

[ebs17]

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.

[crystal]

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.

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.

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.

[ebs17]

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.

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.

Da 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.

hatte 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.

[crystal]

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.

@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

[Beaker s.a.]

Hallo crystal,

Die 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

[crystal]

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