Kriterien für Access Abfrage
Ich habe eine Datenbank aus der ich 3 Kriterien abfragen will. Ich gebe als Kriterium: "nicht NAME" ein. In einer Spalte führt Access dieses Kriterium durch, sobald ich dies für die zweite Spalte eingebe, wird in der ersten Spalte wieder ein paar Zeilen mit dem eigentlich gelöschten Namen eingefügt die vorher entfernt wurden.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 19724
Url: https://administrator.de/contentid/19724
Ausgedruckt am: 08.11.2024 um 13:11 Uhr
26 Kommentare
Neuester Kommentar
Gibst Du diese nebeneinander oder schräg untereinander (gleichbedeutend jeweils mit Und / Oder)?
Vielleicht liegt es daran?
mfg icon99
Vielleicht liegt es daran?
mfg icon99
Eine Idee hät ich noch;
schon mal über diesen Aufbauassistent (oder wie er auch immer sich nennt) versucht?!
ansonsten meine mail - adresse
icon99@web.de
mfg icon99
schon mal über diesen Aufbauassistent (oder wie er auch immer sich nennt) versucht?!
ansonsten meine mail - adresse
icon99@web.de
mfg icon99
ich dachte eher mir den Kram mal mitzunehmen, um in ruhe darüber rum zu denken, mal sehe wie das hinkriege, melde mich auf jeden Fall noch mal.
mfg icon99
mfg icon99
Weil das von MS nicht gewollt und keiner mehr ihren SQL - Server kaufen würde.
Soweit wie ich das in Erinnerung habe ist hinter Access auch kein richtiges SQL.
mfg icon99
Soweit wie ich das in Erinnerung habe ist hinter Access auch kein richtiges SQL.
mfg icon99
Vielleicht die Trickkiste namens VBA, hat mir einigen Fällen auch schon weiter geholfen.
mfg icon99
mfg icon99
@KH-AP
Das mit dem Komma hab ich auch nicht verstanden - NATÜRLICH gehört da eigentlich ein Semikolon hin. Das wiederum hat Access 2002 SP3 bei mir angemeckert!
Ich habe bei einer Test-MDB, die neulich hier im Forum im Thread Abfrage mehrerer Tabellen mittels SQL-Query gepostet wurde, als gültiges SQL-Statement eingeben können:
SELECT Lieferer.*, Lieferer.Firmenname
FROM Lieferer
WHERE [Lieferer].[Firmenname] not IN ( "Computerwelt", "Pelikan")
In der Entwurfsansicht wird der WHERE-Part dargerstellt als
"Nicht In ("Computerwelt";"Pelikan")" ...mit Semikolon in der IN (...,..)-Liste.
Strange, dieses Access. Hat echt nichts mit SQL zu tun. Oder ich stell mich zu blöd an.
Das mit dem Komma hab ich auch nicht verstanden - NATÜRLICH gehört da eigentlich ein Semikolon hin. Das wiederum hat Access 2002 SP3 bei mir angemeckert!
Ich habe bei einer Test-MDB, die neulich hier im Forum im Thread Abfrage mehrerer Tabellen mittels SQL-Query gepostet wurde, als gültiges SQL-Statement eingeben können:
SELECT Lieferer.*, Lieferer.Firmenname
FROM Lieferer
WHERE [Lieferer].[Firmenname] not IN ( "Computerwelt", "Pelikan")
In der Entwurfsansicht wird der WHERE-Part dargerstellt als
"Nicht In ("Computerwelt";"Pelikan")" ...mit Semikolon in der IN (...,..)-Liste.
Strange, dieses Access. Hat echt nichts mit SQL zu tun. Oder ich stell mich zu blöd an.
@KH-AP
Hi,
deine select-Anweisung:
SELECT Kraftwerke.Nummer, Kraftwerke.Kraftwerk, Kraftwerke.Elektr_Leistung_in_MW, Kraftwerke.Ort, Kraftwerke.PLZ, Kraftwerke.Straße, Kraftwerke.Betreiber1, Kraftwerke.Betreiber2, Kraftwerke.Betreiber3, Kraftwerke.Typ, Kraftwerke.[Link Kraftwerksseiten], Kraftwerke.[Link Allgemein], Kraftwerke.[Link Anschrift Anfahrt], Kraftwerke.Betriebsleiter, Kraftwerke.Leittechniker, Kraftwerke.Geschäftsführer, Kraftwerke.[Anderer Ansprechpartner], Kraftwerke.Bemerkungen
FROM Kraftwerke
WHERE (((Kraftwerke.Betreiber1)<>"E.ON") AND ((Kraftwerke.Betreiber2)<>"E.ON"));
Anweisung Ende
Wenn ich deine Tabellenstruktur sehe, behaupte ich mal, so kann das NIE funktionieren.
Betrachten wir nur mal die Felder, die du filtern willst.
<table border="1">
<tr>
<th> Betreiber1</th><th> Betreiber2</th><th> Betreiber3</th>
</tr>
<tr>
<td>E.ON</td><td>ZDF</td><td>WDR</td>
</tr>
<tr>
<td>ZDF</td><td>ARD</td><td>E.ON</td>
</tr>
<tr>
<td>NDR</td><td>SWR</td><td>ARTE</td>
</tr>
<tr>
<td>SAT1</td><td>E.ON</td><td>PRO7</td>
</tr>
</table>
In deiner select-Anweisung willst du dir alle 3 Betreiber-Spalten anzeigen lassen.
Dazu jetzt mal deine where-Klausel:
WHERE (((Kraftwerke.Betreiber1)<>"E.ON") AND ((Kraftwerke.Betreiber2)<>"E.ON"));
Teil 1 der where-Klausel: Alle Betreiber1, außer E.ON
Teil 2 der where-Klausel: Alle Betreiber2, außer E.ON
Teil 1 funkt. soweit, alle Betreiber aus deiner select-Anweisung werden angezeigt,
außer E.ON in Spalte Betreiber1.
Jetzt sollen im 2. Teil der where-Klausel auch die E.ON-Einträge der Spalte Betreiber2
verschwinden.
Da aber Datensätze nun mal in Reihen angelegt werden, erscheinen natürlich die
vorher gefilterten Einträge aus dem 1. Teil der where-Klausel wieder in der Ausgabe,
aufgrund dessen, da du ja in der select-Anweisung alle 3 Betreiber auswählst.
Wenn du dir die Tabelle anschaust, dann siehst du es auch selber.
Teil 1 würde die Reihen 2 ?4 ausgeben, Teil 2 die Reihen 1 ?3, womit der Eintrag
E.ON aus der Spalte Betreiber1 wieder angezeigt wird.
Um dieses Problem zu lösen, brauchst du also mind. 2 Tabellen:
Tabelle1 ? Betreiber
betreiberid --> eindeutige Kennung/darf nur EINMAL vorkommen
betreiber --> Name des Betreibers
und weitere Felder, die zum Betreiber gehören, wie Firmensitz, Kontaktperson etc.
Tabelle2 ? Kraftwerke
betreiberid --> hier gehört die Kennung aus Tabelle1 rein, darf jetzt MEHRMALS vorkommen, da ein Betreiber ja mehrere Kraftwerke betreibt, wenn ich das richtig verstehe.
kraftwerktyp --> erklärt sich selber
standort --> erklärt sich selber
leistung --> erklärt sich selber
und weitere Felder, die zum Kraftwerk gehören.
Daten, die in einer Tabelle wiederholt vorkommen, sind redundant und werden
normalerweise in einer eigenen Tabelle untergebracht. Die Tabellen werden dann
über Schlüsselfelder(im Beispiel ist es "betreiberid") verknüpft.
Eine entsprechende select-Anweisung könnte nun lauten:
select betreiber, kraftwerktyp, standort, leistung from betreiber, kraftwerke
where betreiber.betreiberid=kraftwerke.betreiberid and betreiber <> "E.ON"
Ich denke mal, dass es so geht.
Gruß
Günni
PS:
An alle Access-Feinde: SQL ist ein Standard, der von Access über MySQL bis hin zu Oracle gleich ist.
Mal abgesehen von einigen Funktionen, die der ein oder andere implementiert.
Diese Funktionen beeinträchtigen aber keinesfalls die Arbeitsweise von SQL.
Nur mal nebenbei.
Hi,
deine select-Anweisung:
SELECT Kraftwerke.Nummer, Kraftwerke.Kraftwerk, Kraftwerke.Elektr_Leistung_in_MW, Kraftwerke.Ort, Kraftwerke.PLZ, Kraftwerke.Straße, Kraftwerke.Betreiber1, Kraftwerke.Betreiber2, Kraftwerke.Betreiber3, Kraftwerke.Typ, Kraftwerke.[Link Kraftwerksseiten], Kraftwerke.[Link Allgemein], Kraftwerke.[Link Anschrift Anfahrt], Kraftwerke.Betriebsleiter, Kraftwerke.Leittechniker, Kraftwerke.Geschäftsführer, Kraftwerke.[Anderer Ansprechpartner], Kraftwerke.Bemerkungen
FROM Kraftwerke
WHERE (((Kraftwerke.Betreiber1)<>"E.ON") AND ((Kraftwerke.Betreiber2)<>"E.ON"));
Anweisung Ende
Wenn ich deine Tabellenstruktur sehe, behaupte ich mal, so kann das NIE funktionieren.
Betrachten wir nur mal die Felder, die du filtern willst.
<table border="1">
<tr>
<th> Betreiber1</th><th> Betreiber2</th><th> Betreiber3</th>
</tr>
<tr>
<td>E.ON</td><td>ZDF</td><td>WDR</td>
</tr>
<tr>
<td>ZDF</td><td>ARD</td><td>E.ON</td>
</tr>
<tr>
<td>NDR</td><td>SWR</td><td>ARTE</td>
</tr>
<tr>
<td>SAT1</td><td>E.ON</td><td>PRO7</td>
</tr>
</table>
In deiner select-Anweisung willst du dir alle 3 Betreiber-Spalten anzeigen lassen.
Dazu jetzt mal deine where-Klausel:
WHERE (((Kraftwerke.Betreiber1)<>"E.ON") AND ((Kraftwerke.Betreiber2)<>"E.ON"));
Teil 1 der where-Klausel: Alle Betreiber1, außer E.ON
Teil 2 der where-Klausel: Alle Betreiber2, außer E.ON
Teil 1 funkt. soweit, alle Betreiber aus deiner select-Anweisung werden angezeigt,
außer E.ON in Spalte Betreiber1.
Jetzt sollen im 2. Teil der where-Klausel auch die E.ON-Einträge der Spalte Betreiber2
verschwinden.
Da aber Datensätze nun mal in Reihen angelegt werden, erscheinen natürlich die
vorher gefilterten Einträge aus dem 1. Teil der where-Klausel wieder in der Ausgabe,
aufgrund dessen, da du ja in der select-Anweisung alle 3 Betreiber auswählst.
Wenn du dir die Tabelle anschaust, dann siehst du es auch selber.
Teil 1 würde die Reihen 2 ?4 ausgeben, Teil 2 die Reihen 1 ?3, womit der Eintrag
E.ON aus der Spalte Betreiber1 wieder angezeigt wird.
Um dieses Problem zu lösen, brauchst du also mind. 2 Tabellen:
Tabelle1 ? Betreiber
betreiberid --> eindeutige Kennung/darf nur EINMAL vorkommen
betreiber --> Name des Betreibers
und weitere Felder, die zum Betreiber gehören, wie Firmensitz, Kontaktperson etc.
Tabelle2 ? Kraftwerke
betreiberid --> hier gehört die Kennung aus Tabelle1 rein, darf jetzt MEHRMALS vorkommen, da ein Betreiber ja mehrere Kraftwerke betreibt, wenn ich das richtig verstehe.
kraftwerktyp --> erklärt sich selber
standort --> erklärt sich selber
leistung --> erklärt sich selber
und weitere Felder, die zum Kraftwerk gehören.
Daten, die in einer Tabelle wiederholt vorkommen, sind redundant und werden
normalerweise in einer eigenen Tabelle untergebracht. Die Tabellen werden dann
über Schlüsselfelder(im Beispiel ist es "betreiberid") verknüpft.
Eine entsprechende select-Anweisung könnte nun lauten:
select betreiber, kraftwerktyp, standort, leistung from betreiber, kraftwerke
where betreiber.betreiberid=kraftwerke.betreiberid and betreiber <> "E.ON"
Ich denke mal, dass es so geht.
Gruß
Günni
PS:
An alle Access-Feinde: SQL ist ein Standard, der von Access über MySQL bis hin zu Oracle gleich ist.
Mal abgesehen von einigen Funktionen, die der ein oder andere implementiert.
Diese Funktionen beeinträchtigen aber keinesfalls die Arbeitsweise von SQL.
Nur mal nebenbei.
Ich glaub den kenn ich, dass mit den mehreren Tabellen hat er mir nicht nur einmal um die Ohren geschlagen.
mfg icon99
mfg icon99
@KH-AP
Hi,
Klingt keineswegs komisch. Als Beispiel der Datenbestand eines Immobilienhändlers:
Ein Kunde hat Interesse an mehreren Objekten, ein Objekt kann mehrere Interessenten
haben.
Oder Datenbestand eines Krankenhauses:
Ein Arzt hat viele Patienten, ein Patient kann von mehreren Ärzten behandelt werden.
Solche etwas nennt man m:m (mehrfach-zu-mehrfach) Beziehung, und kann in einer
relationalen Datenbank nicht abgebildet werden.
Dazu bedarf es dann einer weiteren Tabelle, in der die Beziehungen dargelegt werden.
<table border="1">
<tr>
<th>betreiber-id</th><th>kraftwerk-id</th>
</tr>
<tr>
<td>1</td><td>1</td>
</tr>
<tr>
<td>1</td><td>2</td>
</tr>
<tr>
<td>2</td><td>1</td>
</tr>
<tr>
<td>2</td><td>2</td>
</tr>
</table>
Was jetzt komisch klingt, ist, dass ich heute operiert worden bin und deshalb
nicht stundenlang vor'm PC sitzen kann.
Wenn's in 2 -3 Tagen geht, mache ich mir mal Gedanken darüber und poste dir
meine Ergüsse. So ein Modell habe ich selber auch noch nie entworfen.
Falls du deinerseits eine Lösung gefunden hast, wäre es nett, wenn du sie ebenfalls
bekanntgibst.
Gruß
Günni
Hi,
Das Grundlegende Problem war / ist ja, das
für ein Kraftwerk wieder mehree
Betreiber in Frage kommen. Klingt komisch,
ist aber so ;)
für ein Kraftwerk wieder mehree
Betreiber in Frage kommen. Klingt komisch,
ist aber so ;)
Klingt keineswegs komisch. Als Beispiel der Datenbestand eines Immobilienhändlers:
Ein Kunde hat Interesse an mehreren Objekten, ein Objekt kann mehrere Interessenten
haben.
Oder Datenbestand eines Krankenhauses:
Ein Arzt hat viele Patienten, ein Patient kann von mehreren Ärzten behandelt werden.
Solche etwas nennt man m:m (mehrfach-zu-mehrfach) Beziehung, und kann in einer
relationalen Datenbank nicht abgebildet werden.
Dazu bedarf es dann einer weiteren Tabelle, in der die Beziehungen dargelegt werden.
<table border="1">
<tr>
<th>betreiber-id</th><th>kraftwerk-id</th>
</tr>
<tr>
<td>1</td><td>1</td>
</tr>
<tr>
<td>1</td><td>2</td>
</tr>
<tr>
<td>2</td><td>1</td>
</tr>
<tr>
<td>2</td><td>2</td>
</tr>
</table>
Was jetzt komisch klingt, ist, dass ich heute operiert worden bin und deshalb
nicht stundenlang vor'm PC sitzen kann.
Wenn's in 2 -3 Tagen geht, mache ich mir mal Gedanken darüber und poste dir
meine Ergüsse. So ein Modell habe ich selber auch noch nie entworfen.
Falls du deinerseits eine Lösung gefunden hast, wäre es nett, wenn du sie ebenfalls
bekanntgibst.
Gruß
Günni
Moin alle, insbesondere Günni,
obwohl sich die eigentliche Thread-Frage nun erledigt hat: Günnis Behauptungen haben mir ja keine Ruhe gelassen.
Ich habe eben nochmal den Fall unter MS-Access 2000 (statt 2003) nachgestellt. Mit einer kleinen Tabelle nach obigem Muster.
Und mal meine damaligen WHERE-Vorschläge gegen Günnis Beispieldaten abgefeuert.
select * from kraftwerk
1 E.ON ZDF WDR
2 ZDF ARD E.ON
3 NDR SWR ARTE
4 SAT1 E.ON PRO7
~~~~ (Beliebiger Freeware Sql-Client mit Access-Treiber
select * from kraftwerk
WHERE 'E.ON' NOT IN (Betreiber1, Betreiber2, Betreiber3)
3 NDR SWR ARTE
~~~~
select * from kraftwerk
WHERE NOT (Betreiber1='E.ON' Or Betreiber2='E.ON' Or Betreiber3='E.ON');
3 NDR SWR ARTE
~~~~
Access 2000 - Abfrage in der SQL-Ansicht:
select * from kraftwerk
WHERE 'E.ON' NOT IN (Betreiber1, Betreiber2, Betreiber3)
Nummer Betreiber1 Betreiber2 Betreiber3
3 NDR SWR ARTE
~~~~
select * from kraftwerk
WHERE 'E.ON' NOT IN (Betreiber1, Betreiber2, Betreiber3)
Nummer Betreiber1 Betreiber2 Betreiber3
3 NDR SWR ARTE
-----> Funktioniert also klaglos unter Access2000, aber nicht unter Access2002 SP3,
sowohl bei KH-AP als auch bei mir.
Meine Frage: Ist dieses Phänomen bekannt?
Muss bei Access2002 eventuell irgendeine *.DLL von Hand nachregistriert werden?
Nicht, dass ich nun auf meine alten Tage plötzlich mit Access Datenbanken abfragen wollte, aber das ist ja ein Problem, das alle Access2002-Anwender haben müssten.
Ratlos
Biber
obwohl sich die eigentliche Thread-Frage nun erledigt hat: Günnis Behauptungen haben mir ja keine Ruhe gelassen.
Wenn ich deine Tabellenstruktur sehe, behaupte ich mal, so kann das NIE funktionieren.
Um dieses Problem zu lösen, brauchst du also mind. 2 Tabellen:
Um dieses Problem zu lösen, brauchst du also mind. 2 Tabellen:
An alle Access-Feinde: SQL ist ein Standard, der von Access über MySQL bis hin zu Oracle gleich ist.
Mal abgesehen von einigen Funktionen, die der ein oder andere implementiert.
Diese Funktionen beeinträchtigen aber keinesfalls die Arbeitsweise von SQL.
Das wollte ich eigentlich nicht so stehen lassen (auch wenn ich bekennender MS-Access-Feind bin).Mal abgesehen von einigen Funktionen, die der ein oder andere implementiert.
Diese Funktionen beeinträchtigen aber keinesfalls die Arbeitsweise von SQL.
Ich habe eben nochmal den Fall unter MS-Access 2000 (statt 2003) nachgestellt. Mit einer kleinen Tabelle nach obigem Muster.
Und mal meine damaligen WHERE-Vorschläge gegen Günnis Beispieldaten abgefeuert.
select * from kraftwerk
1 E.ON ZDF WDR
2 ZDF ARD E.ON
3 NDR SWR ARTE
4 SAT1 E.ON PRO7
~~~~ (Beliebiger Freeware Sql-Client mit Access-Treiber
select * from kraftwerk
WHERE 'E.ON' NOT IN (Betreiber1, Betreiber2, Betreiber3)
3 NDR SWR ARTE
~~~~
select * from kraftwerk
WHERE NOT (Betreiber1='E.ON' Or Betreiber2='E.ON' Or Betreiber3='E.ON');
3 NDR SWR ARTE
~~~~
Access 2000 - Abfrage in der SQL-Ansicht:
select * from kraftwerk
WHERE 'E.ON' NOT IN (Betreiber1, Betreiber2, Betreiber3)
Nummer Betreiber1 Betreiber2 Betreiber3
3 NDR SWR ARTE
~~~~
select * from kraftwerk
WHERE 'E.ON' NOT IN (Betreiber1, Betreiber2, Betreiber3)
Nummer Betreiber1 Betreiber2 Betreiber3
3 NDR SWR ARTE
-----> Funktioniert also klaglos unter Access2000, aber nicht unter Access2002 SP3,
sowohl bei KH-AP als auch bei mir.
Meine Frage: Ist dieses Phänomen bekannt?
Muss bei Access2002 eventuell irgendeine *.DLL von Hand nachregistriert werden?
Nicht, dass ich nun auf meine alten Tage plötzlich mit Access Datenbanken abfragen wollte, aber das ist ja ein Problem, das alle Access2002-Anwender haben müssten.
Ratlos
Biber
@Biber
Hi,
es funkt. eben NICHT!, glaub's mir. Oder hast du andersrum mal versucht, dir
alle eon-Einträge anzeigen zu lassen? Indem du das "not" einfach weglässt?
select * from kraftwerk
WHERE 'E.ON' IN (Betreiber1, Betreiber2, Betreiber3)
Ergebnis:
Wie man sieht, fördert diese Abfrage auch die Betreiber zutage, die vorher bei deiner
Abfrage unterschlagen wurden, obwohl da ja nur die eon's rausgefiltert werden sollten.
Um diese Beziehung darzustellen, braucht man sogar 3 Tabellen.
Tabelle Betreiber:
id --> eindeutige Kennung/darf nur einmal vorkommen
betreiber --> Betreibername
und weitere, betreiberspezifische Felder
Tabelle Kraftwerke
id --> eindeutige Kennung/darf nur einmal vorkommen
kraftwerk --> Kraftwerkname
und weitere, kraftwerkspezifische Felder
Tabelle bez(iehungen)
betreiberid --> ID's der Betreiber
kraftwerkid --> ID's der Kraftwerke
Diese Tabellen stehen in folg. Beziehung zueinander:
Betreiber----bez-----Kraftwerke
1-------------n--n--------------1
Verknüpft werden die Tabellen dann:
SELECT Kraftwerk, Betreiber, Leistung
FROM betreiber, kraftwerke, bez
WHERE bez.betreiberid=betreiber.id And bez.kraftwerkid=kraftwerke.id;
Ergebnis:
Da unsere, kleine Beispieltabelle vier Zeilen hat(vier Kraftwerke) mit je drei Betreibern,
fördert die Abfrage folgerichtig 12 Ergebnisse zutage.
Lasse ich mir jetzt nur die eon's anzeigen:
SELECT Kraftwerk, Betreiber, Leistung
FROM betreiber, kraftwerke, bez
WHERE bez.betreiberid=betreiber.id And bez.kraftwerkid=kraftwerke.id
and betreiber='eon';
Ergebnis:
Sieht schon anders aus, oder?
Noch ein letztes Beispiel, um dich zu überzeugen:
Du hast einen Versandhandel, dort stehen Kunden, Artikel und Aufträge in der gleichen
Beziehung, also auch wieder 3 Tabellen.
Wenn du diesen Versandhandel verwalten würdest, wie die Kraftwerke in unserer
Ausgangstabelle in einer einzigen, so müßte für jeden Auftrag eine neue Spalte
eingefügt werden.
Szenario jeden Monat:
Einige Kunden bestellen 5-10mal, andere 10-20mal, wieder andere über 30mal.
Ergebnis:
Eine endlos breite Tabelle, gespickt mit unzähligen, leeren Feldern.
Und dann versuch daraus mal, mittels Abfrage vernünftige Erkenntnisse draus zu gewinnen,
z.B. Umsätze pro Kunde.
Gruß
Günni
Hi,
es funkt. eben NICHT!, glaub's mir. Oder hast du andersrum mal versucht, dir
alle eon-Einträge anzeigen zu lassen? Indem du das "not" einfach weglässt?
select * from kraftwerk
WHERE 'E.ON' IN (Betreiber1, Betreiber2, Betreiber3)
Ergebnis:
Wie man sieht, fördert diese Abfrage auch die Betreiber zutage, die vorher bei deiner
Abfrage unterschlagen wurden, obwohl da ja nur die eon's rausgefiltert werden sollten.
Um diese Beziehung darzustellen, braucht man sogar 3 Tabellen.
Tabelle Betreiber:
id --> eindeutige Kennung/darf nur einmal vorkommen
betreiber --> Betreibername
und weitere, betreiberspezifische Felder
Tabelle Kraftwerke
id --> eindeutige Kennung/darf nur einmal vorkommen
kraftwerk --> Kraftwerkname
und weitere, kraftwerkspezifische Felder
Tabelle bez(iehungen)
betreiberid --> ID's der Betreiber
kraftwerkid --> ID's der Kraftwerke
Diese Tabellen stehen in folg. Beziehung zueinander:
Betreiber----bez-----Kraftwerke
1-------------n--n--------------1
Verknüpft werden die Tabellen dann:
SELECT Kraftwerk, Betreiber, Leistung
FROM betreiber, kraftwerke, bez
WHERE bez.betreiberid=betreiber.id And bez.kraftwerkid=kraftwerke.id;
Ergebnis:
Da unsere, kleine Beispieltabelle vier Zeilen hat(vier Kraftwerke) mit je drei Betreibern,
fördert die Abfrage folgerichtig 12 Ergebnisse zutage.
Lasse ich mir jetzt nur die eon's anzeigen:
SELECT Kraftwerk, Betreiber, Leistung
FROM betreiber, kraftwerke, bez
WHERE bez.betreiberid=betreiber.id And bez.kraftwerkid=kraftwerke.id
and betreiber='eon';
Ergebnis:
Sieht schon anders aus, oder?
Noch ein letztes Beispiel, um dich zu überzeugen:
Du hast einen Versandhandel, dort stehen Kunden, Artikel und Aufträge in der gleichen
Beziehung, also auch wieder 3 Tabellen.
Wenn du diesen Versandhandel verwalten würdest, wie die Kraftwerke in unserer
Ausgangstabelle in einer einzigen, so müßte für jeden Auftrag eine neue Spalte
eingefügt werden.
Szenario jeden Monat:
Einige Kunden bestellen 5-10mal, andere 10-20mal, wieder andere über 30mal.
Ergebnis:
Eine endlos breite Tabelle, gespickt mit unzähligen, leeren Feldern.
Und dann versuch daraus mal, mittels Abfrage vernünftige Erkenntnisse draus zu gewinnen,
z.B. Umsätze pro Kunde.
Gruß
Günni
@günni
nööö, nöö, nööö, seh ich noch nicht ein (aber ich lass mich gern überzeugen).
Auf Deine 3 Tabellen komme ich durch ein billiges Union mit meiner einen Tabelle:
select k1.id, k1.Betreiber1 as Betreiber, k1.Leistung as Leistung from kraftwerke k1
union
select k2.id, k2.Betreiber2 as Betreiber, k2.Leistung as Leistung from kraftwerke k2
union
select id, Betreiber3 as Betreiber, Leistung from kraftwerke
WHERE 'E.ON' IN (Betreiber1, Betreiber2, Betreiber3)
also alle Kraftwerke, an denen E.ON "Mitbetreiber" ist. Inclusive aller Partner.
id Betreiber Leistung
1 E.ON 30
1 WDR 30
1 ZDF 30
2 ARD 50
2 E.ON 50
2 ZDF 50
3 NDR 29
3 SWR 29
4 E.ON 25
4 PRO7 25
4 SAT1 25
>> und was soll die Tabelle inhaltlich sagen?? Das Feld "Leistung" lässt sich doch wohl kaum summieren??
~~~~~~~~~~~~~~~
select k1.id, k1.Betreiber1 as Betreiber, k1.Leistung as Leistung from kraftwerke k1 where betreiber1="E.ON"
union
select k2.id, k2.Betreiber2 as Betreiber, k2.Leistung as Leistung from kraftwerke k2 where betreiber2="E.ON"
union
select id, Betreiber3 as Betreiber, Leistung from kraftwerke where betreiber3="E.ON"
id Betreiber Leistung
1 E.ON 30
2 E.ON 50
4 E.ON 25
---> Gesamtleistung aller Kraftwerke, bei denen E.ON die Finger im Spiel hat.
Und? Welchen Informationsverlust habe ich zu beklagen?
Muss für heute den Computer verlassen - ich antworte morgen gerne mehr.
Grüße Biber
Moin, Günni,
so, nochmal kurz meine Antwort von gestern ergänzen, damit Du das nicht in den falschen Hals bekommst.
Meine Beispiele bezogen sich nur auf die Behauptungen
usw., was ich nach wie vor für nicht richtig halte.
Grundsätzlich hast Du natürlich recht mit Deiner Normalisierung der Tabellen und das Beispiel Kunden-Aufträge-Artikel verdeutlicht das auch. Keine Frage, kein Einwand.
Aber der obige Tabellenaufbau wie von KH-AP skizziert signalisiert für mich, dass an den Feldern "Betreiber1", "Betreiber2", "Betreiber3" keine weiteren Attribute hängen - es sind max. drei Prosa-Felder wie es in Adresstabellen die Felder "TelNr1", "TelNr2", "TelNr3" oder in Kontakttabellen die Felder "AnsprechPartner1", "AnsprechPartner2", "AnsprechPartner3" sind.
Also (nach menschlichlichem Ermessen) maximal 3 Felder, die reine Prosa und keinerlei Schlüsselfelder sind.
So habe ich die ursprüngliche Fragestellung verstanden und so waren meine ersten Antworten gemeint.
Grüße Biber
so, nochmal kurz meine Antwort von gestern ergänzen, damit Du das nicht in den falschen Hals bekommst.
Meine Beispiele bezogen sich nur auf die Behauptungen
Da aber Datensätze nun mal in Reihen angelegt werden, erscheinen natürlich die
vorher gefilterten Einträge aus dem 1. Teil der where-Klausel wieder in der Ausgabe,
aufgrund dessen, da du ja in der select-Anweisung alle 3 Betreiber auswählst.
vorher gefilterten Einträge aus dem 1. Teil der where-Klausel wieder in der Ausgabe,
aufgrund dessen, da du ja in der select-Anweisung alle 3 Betreiber auswählst.
Grundsätzlich hast Du natürlich recht mit Deiner Normalisierung der Tabellen und das Beispiel Kunden-Aufträge-Artikel verdeutlicht das auch. Keine Frage, kein Einwand.
Aber der obige Tabellenaufbau wie von KH-AP skizziert signalisiert für mich, dass an den Feldern "Betreiber1", "Betreiber2", "Betreiber3" keine weiteren Attribute hängen - es sind max. drei Prosa-Felder wie es in Adresstabellen die Felder "TelNr1", "TelNr2", "TelNr3" oder in Kontakttabellen die Felder "AnsprechPartner1", "AnsprechPartner2", "AnsprechPartner3" sind.
Also (nach menschlichlichem Ermessen) maximal 3 Felder, die reine Prosa und keinerlei Schlüsselfelder sind.
So habe ich die ursprüngliche Fragestellung verstanden und so waren meine ersten Antworten gemeint.
Grüße Biber