Office: (Office 2010) Tabellen abgleichen

Hallo,
habe folgende Situation:
Es gibt zwei Tabellen die miteinander abgeglichen werden sollen.
TabelleA: Feld „FzgA1“ (Textfeld, Inhalt z.B. A15, N20), Feld „FzgA2“, … Feld „FzgA15“.
TabelleB: Feld „FzgN1“ (Textfeld, Inhalt z.B. A15, N20), Feld „FzgN2“, … Feld „FzgA8“.
Frage: Welches „FzgA1“ … „FzgA15“ stimmt mit „FzgN1“ … „FzgN8“ am meisten überein.
Wie geht man da am einfachsten vor?

:)

 

In einer Datenbank üblicherweise (und wenig überraschend) mit einer Abfrage. Dazu sollten aber die Tabellenstrukturen auch datenbankgemäß sein.

Für Deine sichtbar Exceltabellen fragst Du am besten im Excelforum nach. Da ist es üblich, auch mit "freien" Strukturen zu arbeiten.

 

Moin,

Was bedeutet das genau?
maike

 

Hallo Eberhard,
der screenshot stammt aus Access und ich möchte die Aufgabe auch mit Access durchführen.
FzgA1 ... FzgA15 bedeutet FahrzeugAlt1 bis FahrzeugAlt15. In diesem Feld/Spalte sind alle AusstattungsCoden aufgeführt die das Fahrzeug enthält. FzgN1 ... FzgN8 sind neue Fahrzeuge, die z.Teil andere AusstattungsCoden enthalten. Es sollte nun ein Abgleich erfolgen, welches FahrzeugAlt mit welchem FahrzeugNeu die größte Übereinstimmung in den Ausstattungscoden hat.
Die Frage ist, wie stelle ich diesen Abgleich am einfachsten an? Eventuell auch mit einer Anpassung der Tabellen.

 

Hallo,
ein Anfang wäre ein korrektes Datenmodell. Für eine Datenbank ist die vorliegende Struktur ungeeignet. Du benötigst noch eine weitere Tabelle zur Zuordnung der Codes zum Fahrzeug, jeweils ein Datensatz.

 

Hallo Klaus,
meinst Du dies so?

 

Hallo,
genau so meine ich das, als klassische n:m Beziehung. Wobei für Fahrzeug und den Code nur die entsprechenden Schlüsselwerte (Zahl) gespeichert werden sollten.

 

Hallo Klaus,
wie sieht nun die Abfrage aus mit der ich so einen Vergleich durchführen kann?
Könntest Du mir eine Beispielabfrage in die beigefügte Datenbank einfügen?

 

Hallo,
ich habe keine Möglichkeit ACCDB's zu öffnen. Entweder nach Access2003 konvertieren, oder warten.

 

Hallo Klaus,
hier ein mdb-Version.

 

Hallo,
der Aufbau der Tabellen entspricht nicht meinem Vorschlag.

- Tabelle für die Fahrzeuge (je Fahrzeug ein Datensatz)
- Tabelle für die Codes (je ein DS)
- Tabelle zur Erfassung der Codes zum Fahrzeug (je ein DS)

Dein Beispiel enthält keine Primärschlüssel und keine Beziehungen. Eine solche DB ist unbrauchbar. Mit den Abstrahierten Bezeichnungen kann man nichts anfangen.

 

Ich habe die Datenbank optimiert. Könntest Du bitte mal schauen ob Du mir damit eine Vergleichsabfrage erstellen Kannst.
Danke

 

Hallo Klaus,
ist die Lösung doch etwas schwieriger?

 

Hallo Heinrich,

zunächst einmal solltest du die Tabellenbeziehungen (mit Ref. Integrität) einrichten.
Ist das nicht möglich, so handelt es sich um einen Fehler, der bereinigt werden muss.

Dann kannst du mit folgender Abfrage die Häufigkeit der Übereinstimmungen zwischen zwei Fahrzeugen feststellen. Code:

Bei entsprechender Sortierung und Einsatz von "Top x" kannst du die ersten x Treffer anzeigen lassen.

Hoffe, das hilft dir weiter.

 

Es erfüllt mich mit Traurigkeit und ein wenig mit Schrecken, was da als Datenbank mit Optimierung bezeichnet wird.

In der Anlage habe ich die hingeworfenen Tabellen zu einer m:n-Beziehung verarbeitet, was an sich kein großer Akt ist:

1) tb_Ausstattung und tb_Fzg: Ein Primärschlüssel auf ein Feld ist Index genug für dieses Feld. Ein weiterer eindeutiger Index hilft nicht, erhöht aber Verwaltungsaufwand, was u.a. zu langsameren Schreibaktionen führen wird.
Tipp: Man sollte nicht nur etwas zusammenklicken, sondern dabei auch einen Blick in das Indexfenster der Entwurfsansicht wagen. Manchmal führen auch (ungünstige) DB-Einstellungen zu solchen Dingen, was man aber erst durch Anschauen bemerken kann.
In manchen Fällen können die 32 möglichen Indizes pro Tabelle zu knapp sein. Da würden dann verschwendete Indizes zusätzlich schmerzen.

2) tb_Fahrzeugausstattung (Verknüpfungstabelle): Die Fremdschlüssel, über die Beziehungen erstellt werden, erhalten keinen eigenen Index. Dieser Index ist nämlich so wichtig, dass er bei Erstellung einer Beziehung mit referentieller Integrität automatisch (und schwer sichtbar) erstellt wird. Nachzulesen in dem Script, das in meiner Fußnote verlinkt ist.

Dafür vergibt man hier aber einen zusammengesetzten eindeutigen Index auf die beiden Fremdschlüsselfelder, weil eine Zuordnung doch besser eindeutig sein sollte.

3) Beziehungen als Scheinwesen und zum Besprechen taugen nichts. Man muss sie anlegen, damit sie auch wirken. Dabei ist die Einstellung referentieller Integrität unverzichtbar - zumindest habe ich noch keinen sinnvollen Fall einer Beziehung ohne RI gesehen.
Das Ganze wegen Punkt 2 (automatische Indizierung von FK), aber auch wegen der referentiellen Integrität als Funktionalität an sich. Dann kann es nicht mehr passieren, dass in der Verknüpfungstabelle eine Codeleiche BB9 auftritt, die es in der Primärtabelle nicht als PK gibt. Integrität von Daten ist nicht eine Worthülse, sondern in einer Datenbank ein hoher Wert.

Irgendwann, besser sofort, sollte man sich auch mal mit Grundlagen beschäftigen, und zwar in der Form, dass sie abrufbereit (als Reflex) vorliegen. Nur mit einem soliden Fundament kann man ein Hochhaus Datenbank errichten, das nicht sofort leidet und bröckelt und ... schneller als gedacht einstürzt.

Die Vergleichsabfrage ist dann auch dabei, und zwar in einer Form, die auch bei 100k Fahrzeugen mit 100k Ausstattungen flüssig laufen wird.