collapse

* Benutzer Info

 
 
Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?

* Wer ist Online

  • Punkt Gäste: 76
  • Punkt Versteckte: 1
  • Punkt Mitglieder: 3
  • Punkt Benutzer Online:

* Forenstatistik

  • stats Mitglieder insgesamt: 13917
  • stats Beiträge insgesamt: 65841
  • stats Themen insgesamt: 8885
  • stats Kategorien insgesamt: 5
  • stats Boards insgesamt: 17
  • stats Am meisten online: 415

Autor Thema: 6 Mio Datensätze bei Abfrage  (Gelesen 8158 mal)

Offline Johanna

  • Newbie
  • Beiträge: 5
6 Mio Datensätze bei Abfrage
« am: Mai 17, 2010, 10:54:53 »
Hallo,

hier eine vereinfachte Problembeschreibung:
Ich habe zwei Tabellen. Diese sind über eine Vatertabelle verknüpft (1 zu 1 Beziehung).
Es sind ziemlich große Tabellen (mit über 60000 Datensätzen), wobei zu beachten ist, dass man die Tabellen nicht konsistent nebeneinander schreiben könnte; in beiden gibt es zwar die gleichen Suchbegriffe, allerdings gibt es unterschiedlich viele Datensätze zu einem Key. In Tabelle 1 gibt es zum Suchbegriff A 162 Datensätze, in Tabelle 2 gibt es zu Suchbegriff A 275 Datensätze.

In der MS Access Abfrage oder über die MATLAB Toolbox Database tritt bei mir das selbe Problem auf, wenn ich Daten zu einem beliebigen Suchbegriff abfrage:
MS Access Abfrageentwurf:
Ich ziehe die Vatertabelle in die Abfragefelder und gebe als Kriterium ="A" an. Daneben ziehe ich Spalten aus Tabellen 1 und 2 in die Abfragefelder. In der SQL-Syntax erfolgt die Abfrage also über INNER und LEFT JOINS.
Bei der Ausgabe habe ich nun 44550 Datensätze da stehen (was im Übrigen der Multiplikation der Anzahl der Datensätze zu A aus Tabelle 1 und 2 entspricht: 44550 = 162*275).

Also für mich müssten in der Ausgabe erstmal maximal 275 Datensätze vorliegen.
Danach wollte ich dann nach einer Möglichkeit suchen die Daten noch mal geordnet nebeneinander auszugeben.
Der Key ist ein String (z.B. A). Weitere Kriterien sind z.B. Jahreszahlen. Könnte man die Ausgabe nach Jahreszahlen ordnen und die Daten zu selben Jahreszahlen hintereinanderschreiben? Ist es überhaupt möglich Felder zwischendrin leer zu lassen, falls in einer Tabelle keine Daten zu einem Jahr vorliegen, in der anderen aber schon?

Danke für die Hilfe!
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23270
Re: 6 Mio Datensätze bei Abfrage
« Antwort #1 am: Mai 17, 2010, 11:36:17 »
Hallo,

befürchte da leichtes Datenchaos...   ;)


"Ich habe zwei Tabellen. Diese sind über eine Vatertabelle verknüpft (1 zu 1 Beziehung)."

was ist das denn?

Den weiteren Text durchblicke ich gar nicht... (bzgl. dessen, was Du denn überhaupt machen willst....)

Beschreibe mal
--alle Tabellen mit all ihren Feldern,  
--die Felder, mit denen die  Tabellen in Beziehung (welcher Typ) gesetzt werden,
--das, was Du von diesen Daten geliefert haben möchtest.


(die Anzahl der Datensätze ist unerheblich)


Offline Johanna

  • Newbie
  • Beiträge: 5
Re: 6 Mio Datensätze bei Abfrage
« Antwort #2 am: Mai 17, 2010, 12:00:58 »
Mit Vatertabelle meine ich das, was mir hier schonmal im Forum empfohlen wurde.
Im Tutorial stehts auch:
http://www.access-tutorial.de/tabellen/1zu1beziehung.htm
http://www.access-tutorial.de/tabellen/beziehungen.htm

Meine "Vatertabelle" enthält Ländernamen. In den andern Tabellen gibt es Infos über diese Länder.
Bei der Abfrage brauche ich nun nur noch in der Vatertabelle "CountryID" nach einem Land (z.B. Afghanistan) zu suchen und er spuckt mir aus allen anderen Tabellen Daten dazu aus.
Also die Spalte "Country" aus "CountryID" ist mit den Spalten "Country" aus den Tochtertabellen verknüpft (1:1).


In den Tochtertabellen stehen z.B. jede Menge Daten über die installierte Transformatorkapazität (wo noch zwischen verschiedenen Kraftwerkstypen und Verbrauchern unterschieden wird und verschiedenen Jahreszahlen, an denen die Datenerhebung stattfand). In einer anderen Tabelle steht zum Beispiel nur die Fläche eines Landes. Dort gibts keine weiteren Suchkriterien, also nur ein Datensatz pro Land. Wie soll man sowas sinnvoll nebeneinanderschreiben, wenn man alle Daten zu einem Land ausgeben will?

Mir scheint es so, als wolle Access die Daten zwar nebeneinanderschreiben, aber durchläuft dabei alles mehrfach, bis alles in jeder Kombination mal dastand.
In der Spalte mit der Flächenangabe eines Landes steht der Wert z.B. 44550 mal untereinander da. Dabei würde doch einmal reichen.
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23270
Re: 6 Mio Datensätze bei Abfrage
« Antwort #3 am: Mai 17, 2010, 12:23:53 »
Hallo,


von Vater- (Mutter-, Haupt-, 1-) Tabellen lese ich nichts bei einer 1:1-Beziehung...eher bei 1:n-Beziehungen.

1:1-Beziehungen sind mit Vorsicht zu geniesen und bringen in den meisten Fällen nur Verdruß. Nur weil solche Beziehungen möglich sind, müssen sie nicht sinnvoll sein.


Wenn wir denn schon bei Beziehungen sind, wäre es hier anzuraten, die Tabellen (Daten) erst mal gemäß dieser Richtlinien umzubauen:

http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/

und dann vernünftig (keine 1:1-Beziehungen!) zu verknüpfen.


Leider hast Du den Tabellenaufbau nicht genau (genug) beschrieben.



"Wie soll man sowas sinnvoll nebeneinanderschreiben, wenn man alle Daten zu einem Land ausgeben will?"

Wenn die Tabellen richtig verknüpft sind, klappt das auch. Dabei aber die Frage: WO und WOZU "nebeneinander" ?


"..wolle Access die Daten zwar nebeneinanderschreiben, aber durchläuft dabei alles mehrfach, bis alles in jeder Kombination mal dastand."


Ja, das ist so, wenn die Tabellen in der Abfrage nicht verknüpft (Inner-, Left-, oder Right-Join) sind. Diesen Effekt nennt man Kreuzprodukt.




Offline oma

  • Moderator
  • Access Guru
  • *****
  • Beiträge: 4020
Re: 6 Mio Datensätze bei Abfrage
« Antwort #4 am: Mai 17, 2010, 13:53:11 »
Hallo Johanna,

am besten ist du folgst den Vorschlag in #1 und stellst uns dein Tabellenentwurf einmal dar, da aus den Beschreibungen vieles "im Dunklen" bleibt ;D

Mach das nach folgemndem Sytem:

tblTabelle1: Tabelle1_ID, Feld1, Feld2, Feld3....
tblTabelle2: Tabelle2_ID, Feld1, Feld2, Feld3....
tblTabelle3: Tabelle3_ID, Tabelle1_ID, Tabelle2_ID, Feld1, Feld2, Feld3....
...

so dass alle Primärschlüssel und Fremdschlüssel erkennbar sind. Wenn die Bedeutung der Felder nicht mit Feldnamen erklärt sind, mache eine kurze Erläuterung zu diesen Feldern.

Nach den Tabellenerläuterung schreibe kurz u. prägnante die Auswertungziele aus diesen Tabellen.

Dann wird dir sicherlich geholfen ;)

Gruß Oma
nichts ist fertig!
 

Offline Johanna

  • Newbie
  • Beiträge: 5
Re: 6 Mio Datensätze bei Abfrage
« Antwort #5 am: Mai 17, 2010, 14:41:02 »
Ok, am besten füge ich mal ein Screenshot von meinen Beziehungen ein. Es sind inzwischen 1:n-Beziehungen.



Zur Erklärung: In CountryID gibt es drei Spalten. Dort stehen verschiedene Länderbezeichnungen für ein und das selbe Land nebeneinander (z.B. Deutschland, Germany, DE).
In den Tabellen sind aus Aktualisierungsgründen verschiedene Länderbezeichnungen zu finden. Durch die Beziehungen können aber nun alle Tabellen mit ein und der selben Bezeichnung angesprochen werden. Das war aber ein altes Problem und wurde schon in einem andern thread beantwortet.

Wenn ich die Daten so abfragen will, entsteht bei mir, wie DF6GL ja schon richtig erkannt hat ein ungewolltes Kreuzprodukt.

« Letzte Änderung: Mai 17, 2010, 14:44:25 von Johanna »
 

Offline Wurliwurm

  • Access-Profi
  • **
  • Beiträge: 376
Re: 6 Mio Datensätze bei Abfrage
« Antwort #6 am: Mai 17, 2010, 16:20:57 »
Hallo Johanna,

es wurde ja schon angesprochen, aber ich möchte es nochmal betonen: Die Modellierung ist unglücklich, um nicht zu sagen, dilettantisch. Alle Attribute, die vom Land und nur vom Land abhängen, gehören in eine einzige Tabelle mit Primärschlüssel Land. (Der Kunstschlüssel ID ist m. E. auch unglücklich, aber da hatten wir schonmal eine Diskussion hier, irgendwie scheint das so üblich zu sein im Access-Bereich  ;D )

Trotzdem: Mach doch mach im Abfragefenster eine Abfrage, wo Du CountryID.CountryUNDATA mit GeneratedEnergy.Country und dann GeneratedEnergy.Country mit Installed.Capacity.Country verknüpfst. Also Das also quasi ein waagrechter Strich sichtbar ist und der Pfeil weg von CountryID.CountryUNDATA  sich nicht aufspaltet.

Grüße
Johannes
 

Offline database

  • Moderator
  • Access Guru
  • *****
  • Beiträge: 4178
Re: 6 Mio Datensätze bei Abfrage
« Antwort #7 am: Mai 17, 2010, 17:28:48 »
Hallo,
ich werf mich hier nur gaaanz kurz in die Diskussion.
Zitat
Es sind inzwischen 1:n-Beziehungen.
1:n Beziehungen kann ich so eigentlich keine erkennen.
Um eine Beziehung mit dieser Wertigkeit zu erzeugen MUSS ein Primärschlüssel mit seinem Fremdschlüssel in Beziehung gesetzt werden, was hier aber offensichtlich nicht der Fall ist.
Weiter fällt mir auf, dass etliche Felder mit Schlüsselwörtern benannt wurden - auch nicht das Gelbe vom Ei.
Weiter ist es nicht vorteilhaft, wenn in mehreren Tabellen - im aktuellen Beispiel in ALLEN Tabellen die Primärschlüsselfelder gleich heissen (ID), wobei in den Tabellen 'Installed_Capacity' und 'Generated_Energy' die ID-Felder keine PrimaryKeys sind.
Dann möchte ich darauf hinweisen, dass es nicht nötig ist die Tabellenbeziehungen als Left- oder Right-Joins auszubilden, im Datenmodell gibt es diese Ausprägung praktisch nicht sondern diese wird beim Design einer Abfrage interessant.
Und abschließend darf ich noch den gesamten Aufbau des Datenmodells in Frage stellen.

@wurliwurm
Zitat
Kunstschlüssel ID
...was ist bitte ein Kunstschlüssel?

Gruß
Peter
Viele Grüße
Peter

Tipps und Links:
---------------------------------------------------------
1. http://www.donkarl.com
2. http://www.access-entwicklerbuch.de/2007/index.php?page=buch
3. http://www.xlam.ch/pos/rules.htm
3.a Reservierte Worte
4. http://www.functionx.com/vbaccess/index.htm
5. http://www.dbwiki.net

Nicht vergessen: Jede(r) hat mal klein angefangen!
Bitte keine Fragen per PN senden - Fragen gehören ins Forum!
 

Offline Wurliwurm

  • Access-Profi
  • **
  • Beiträge: 376
Re: 6 Mio Datensätze bei Abfrage
« Antwort #8 am: Mai 18, 2010, 10:10:06 »
Hallo Peter,

mit Kunstschlüssel meine ich "surrogate keys". Da hatte ich mal mit Oma eine Diskussion, ob die zweckmäßig sind. Ohne das Thema wieder aufgreifen zu wollen, finde ich es nicht nicht so toll, wenn der Access-Anfänger zwar schön brav und immer (fast immer, d.h. wenn er es nicht vergisst)  einen ID-Wert als Autowert setzt, aber gar nicht versteht, was ein Schlüssel überhaupt ist.

Grüße
Johannes
 

Offline database

  • Moderator
  • Access Guru
  • *****
  • Beiträge: 4178
Re: 6 Mio Datensätze bei Abfrage
« Antwort #9 am: Mai 18, 2010, 22:14:00 »
Hallo, guten Abend,

leicht im Fieberwahn - ich hab mir eine tolle Bronchitis mitsamt gippalem Infekt eingefangen - musste ich aus Neugier noch mal hier nachschauen...
Also mir persönlich reißt's da ausser Husten jetzt nichts raus.
Zitat
Da hatte ich mal mit Oma eine Diskussion
Jojo, die kenn' ich...

Zitat
finde ich es nicht nicht so toll, wenn der Access-Anfänger zwar schön brav und immer (fast immer, d.h. wenn er es nicht vergisst)  einen ID-Wert als Autowert setzt, aber gar nicht versteht, was ein Schlüssel überhaupt ist
Ich denke es ist besser einem Anfänger zu erklären wozu PK und FK benötigt werden, welche Vorteile dadurch entstehen und wie ein Datenmodell dabei richtig konzipiert wird als dem Selbigen gegenüber die Sinnhaftigkeit von Schlüsseln in Frage zu stellen.
Richtig: Diskussionen hinsichtlich primärschlüsselloser Tabellen hat's in der Vergangenheit jede Menge gegeben und die hören auch in der Gegenwart nicht auf, genauso wenig wie Diskussionen darüber ob im Datenmodell die referenzielle Integrität erzwungen werden soll oder nicht oder ob es überhaupt Sinn macht Tabellen im Datenmodel in Beziehung zu setzen - in meinen Augen alles vergeudete Diskussionszeit, welche die "ohne geht's genauso (irgendwie) und wenn's gebraucht wird, dann basteln wir's halt hinterher noch irgendwie rein" - Verfechter besser anders nützen sollten, da die selbigen dann meistens auch gleich in einem Aufwaschen die Normalisierung in Frage stellen. :)
Übrigens kein speziell auf Access zurückzuführendes Phänomen - das kommt kreuz und quer durch den Datenbankgarten vor - und gehört m.E. in die Rubrik Quacksaberei
Sicher kann es vorkommen, dass ein verwursteltes DB-Modell die Grundlage einer Applikation bildet und genau dieses im Zuge einer Erweiterung oder Veränderung dann Mittelpunkt einer Grundsatzdiskussion wird.
Nur eine App mit 50 Tabellen und etlichen tausend Datensätzen schmeißt man nicht einfach weg um dann ein toll normalisiertes Relationenmodell zu besitzen.
Da würde ich viel mehr darauf pochen für die kommende Systemumstellung die Erneuerung UND dabei Richtigstellung des Bemängelten ins Auge zu fassen.

So und damit bin ich auch schon wieder raus hier :)

Schöne Grüße

Peter 
Viele Grüße
Peter

Tipps und Links:
---------------------------------------------------------
1. http://www.donkarl.com
2. http://www.access-entwicklerbuch.de/2007/index.php?page=buch
3. http://www.xlam.ch/pos/rules.htm
3.a Reservierte Worte
4. http://www.functionx.com/vbaccess/index.htm
5. http://www.dbwiki.net

Nicht vergessen: Jede(r) hat mal klein angefangen!
Bitte keine Fragen per PN senden - Fragen gehören ins Forum!
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 23270
Re: 6 Mio Datensätze bei Abfrage
« Antwort #10 am: Mai 19, 2010, 09:32:35 »
Hallo,

@database:  na sowas, gute Besserung dann …


@Thema

Ich dachte, ich hätte Johanna schon mal einen Vorschlag gemacht, die Tabellen passend umzubauen (eigentlich nur alle Tabellen außer "CountryID" um jeweils ein Fremdschlüsselfeld "LandID" zu erweitern).


Dann weiter mit der einmaligen Ausführung von max. 3 Aktualisierungsabfragen "on the fly" zum Einstellen von "LandID" entspr. den Landesnamen und anschließender Auswahlabfrage, die über die "LandID" der einzelnen Tabellen  und über "ID" aus Tabelle "CountryID" verknüpft.


Offline Wurliwurm

  • Access-Profi
  • **
  • Beiträge: 376
Re: 6 Mio Datensätze bei Abfrage
« Antwort #11 am: Mai 19, 2010, 12:29:47 »
Ich denke es ist besser einem Anfänger zu erklären wozu PK und FK benötigt werden, welche Vorteile dadurch entstehen und wie ein Datenmodell dabei richtig konzipiert wird als dem Selbigen gegenüber die Sinnhaftigkeit von Schlüsseln in Frage zu stellen.

Genau das meinte ich eigentlich: Grundlagen wie ein Datenmodell richtig konzipiert wird. Damit wird vermieden, daß später Kreativität for Workarounds um die verwurschtelte Struktur vergeudet wird.

Deshalb habe ich die surrogate keys eben ein bißchen dick. Sie mögen ein paar Vorteile haben, aber wenn das als quasi-Standard vermittelt wird, bekommt man vom Access-Neuling auf die Frage "Hat die Tabelle einen Schlüssel, und wenn ja welchen?" die Antwort "Selbstverständlich hat die Tabelle einen, er heißt ID, ich bestätige nämlich immer mit "ja", wenn ein Primärschlüssel beim Anlegen von Tabellen verlangt wird.

Natürlich klappen die meisten Access-Anwendungen irgendwie, schließlich ist Access geduldig und für Laien und kleine Desktopanwendungen gemacht. Und besser als diese schaurigen Exceltapeten ist es allemal.

Gute Besserung
Johannes