Softpicks.Net Deutsch

[Michael Zimmermann]

Hallo!

stefan hoffmann:
> Michael Zimmermann schrieb:
> > Michael, ich mein's doch nur gut
> Ach was, du willst doch nur spielen .)

Nein, spielen tu ich nur mit Dir. ;-)

Gruß aus Mainz
Michael

.

[Michael Zimmermann]

Hallo!

Guido Altmann:
> > Nein. Objekte werden in Relationalen DBen als Instanzen
> > (Datensätze, Zeilen) in Tabellen repräsentiert und nicht
> > als Werte in Feldern.
>
> Objekte sind in dem Fall Immobilienobjekte!!!

Puh! Nochmal gutgegangen. ;-)

> > > tblObjekteDetails
> > > ObjekteDetailsID
> > > ObjekteID
> > > FeldArtID
> > > FeldArtTopID
> > > EingabeWert
> > > ...
> >
> > Domänen werden in RDBMS als Felddefinitionen
> > repräsentiert und nicht als Werte in Feldern.
>
> Ich habe das angesprochen Grid gefüllt, es funktioniert
> 100 % und sehr schnell!

Also nochmal zum Verständnis:

Wenn Du aus z. B.

id Haarfarbe Gewicht GebDat
25 braun 78 03.05.1912
17 blond 07.02.1980

id FeldTyp FeldWert
25 Haarfarbe braun
25 Gewicht 78
25 GebDat 03.05.1912
17 Haarfarbe blond
17 Gewicht
17 GebDat 07.02.1980

machst, was ich immer noch unterstelle, dann ist das
genau die Katastrophe, die ich meine.

Das ist nicht relational und Du siehst schon an den
Inhalten des Feldes "Feldwert" - ein solches ist es nämlich
in Access -, daß z. B. keine sinnvollen Datentypen und
Constraints für Haarfarbe, Gewicht, GebDat mehr möglich
sind.


Daß sich mit einigen Beispieldaten damit ein Grid füllen
läßt, ändert nichts daran, daß dieses Vorgehen mit RDBMS
unpraktikabel ist.

> Ich glaube immer noch ein wenig, dass Du nicht genau
> verstanden hast, was ich eigentlich meine, oder?

Mal sehen - falls Du es so meinst, wie in meinem Beispiel
oben, dann baust Du gerade an einem relationalen Unding.

Aber erst mal sehen, ob es das ist, was Du machst, bevor
ich weiter wettere. ;-)

> Ich freue mich schon auf Januar!

Okay, war ich also nicht zu streng zu Dir? ;-)

Gruß aus Mainz
Michael

.

[Karl Donaubauer]

Bernd Fegert wrote:
> wie kann ich durch eine Abfrage alle Datensätze einer Tabelle anzeigen,
> die das Kriterium auf ein Datenfeld beziehen und zwar sollen alle
> Datensätze angezeigt werden die den Wert 2 unterschreiten. Das Problem:
> die Werte im Datenfeld sind 6-stellig und 000002 wird nicht als
> Kriterium angenommen es steht dann dort immer 2 und es wird mir dann
> nichts angezeigt.

Welchen Datentyp hat das Feld in der Tabelle?

Oder handelt es sich um ein berechnetes Feld in der Abfrage?
Wie sieht dann die Berechnung aus bzw. poste dann den
SQL-Text der Abfrage.

--
HTH
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com

.

[Michael Zimmermann]

Hallo!

Herbert Clemens:
> Ich habe eine Tabelle mit einer Zutatenliste. Der Aufbau
> ist
>
> Produktnr Produktname Zutat1 Zutat2 ...bis Zutat25
>
> Also 27 Spalten. Manche Produkte haben nur 4 Zutaten,
> andere aber 25. So dass bei manchen Datensätzen nur 6
> Spalten belegt, und die anderen frei sind.

Dieser Aufbau ist völlig falsch.

Du brauchst eine Tabelle mit Produkten und eine weitere
mit Zutaten. Beide bekommen je eine eindeutige
Schlüsselnummer. Eine dritte Tabelle enthält über die
Schlüsselnummern die Produkt-Zutat-Zuordnung.

Man bezeichnet das in der DB-Theorie als m:n-Beziehung.

> Das Ganze ist also wie ein Rezept mit verschiedenen
> Zutaten. Ich benötige nun alle Produkte, die bestimmte
> Zutaten nicht enthalten. Beim Rezept wären das z.B. alle
> Rezepte ohne Mehl(Weizen-, Roggenmehl etc)

Diese Abfrage ist mit theoriekonformen Tabellen -die Du
aber erstmal erstellen mußt - kein Problem.

> Erschwerend kommt hinzu, das manche Produkte wiederum
> Bestandteil weiterer Produkte sind.
>
> Bei den Rezepten wäre das z.B. Pizza. Sie hat als
> Bestandteil den Grundteig, der wiederum Mehl enthält.

Das entspricht einer reflexiven m:n-Beziehung. Hier wäre
es angezeigt, die Unterscheidung Produkt/Zutat aufzuheben
und als eine Entität anzusehen.

Die oben erwähnte m:n-Beziehung wäre dann als reflexive
Beziehung der Produkte/Zutaten auf sich selbst anzulegen.

> Wie bekomme ich also alle Rezepte (=Produkte) ohne Mehle?.

Dann nicht mehr so einfach, da Du eine rekursive Funktion
brauchst, um die theoretisch beliebige Schachtelungstiefe
von Zutatenbeziehungen (Mehl in Teig, Teig in Pizza, Pizza
in Pizza-Kuchen, Pizza-Kuchen in mit Pizza-Kuchen gefülltem
Wildschwein => mit Pizza-Kuchen gefülltes Wildschwein
enthält Mehl) aufzulösen. Das ist in reinem SQL (Abfrage)
so nicht möglich und braucht eine entsprechend programmierte
Hilfsfunktion.

Bei sehr hoher zu erwartender Schachtelungstiefe, die aber
bei Rezepten nicht vorliegen dürfte, kann auch das Prinzip
der Nested Sets hilfreich sein.

Alles in allem hast Du Dir eine Aufgabestellung ausgesucht,
die für einen DB-Anfänger ein ziemlicher Brocken ist.

Gruß aus Mainz
Michael

.

[Herbert Clemens]

Hallo Michael, Hallo Steve

> Das ist eigentlich vom Datenbankdesign her falsch.
Leider musste ich die Tabelle so übernehmen.
Es hängen auch noch einige Eingabeberichte dran.

Morgen werde ich mir Eure Antworten konzentrierter ansehen.
Vielleicht werde ich die Tabelle doch noch umstricken müssen. (Wenn ich mal
die Zeit finde)

Vielen Dank für die Antworten

Herbert


.

[Michael Zimmermann]

Hallo!

Steven Prohaska:
> Michael Zimmermann wrote:
> >
> > Das entspricht einer reflexiven m:n-Beziehung. Hier wäre
> > es angezeigt, die Unterscheidung Produkt/Zutat
> > aufzuheben und als eine Entität anzusehen.
> >
> > Die oben erwähnte m:n-Beziehung wäre dann als reflexive
> > Beziehung der Produkte/Zutaten auf sich selbst
> > anzulegen.
> >
> Puuh - ich glaube das Kochen / Backen selber ist
> einfacher ;-)

Das hat die Natur weise eingerichtet. Würden die Vögel das
Gravitationsgesetz kennen, könnten sie nicht fliegen. ;-)

> Hab ehrlich gesagt keine Ahnung was Du uns hier sagen
> möchtest, aber ...

So schlimm?

> ... ich hätte wie auch schon geschrieben eventuell eine
> dritte Tabelle für die Grundrezepte gemacht und dann das
> Menü praktisch à la Stückliste zusammengestellt.

Stückliste ist aber reflexive m:n-Beziehung, wenn Du es
richtig machst.

Ein beliebiges Stück ist ja i. d. R. ebensosehr Bauteil
wie Produkt, das aus weiteren Bauteilen besteht.

Eine Lichtschranke z. B. ist möglicherweise Bestandteil
eines Produktes "Bewegungsmelder" oder auch selbst
Verkaufsprodukt mit Bestandteilen Emitter, Detektor, Kabel
etc.

Wenn Du Produkte und Bauteile als getrennte Entitäten
ansiehst, taucht dieselbe Lichtschranke in zwei Tabellen
auf: Pfui Redundanz.

Daher würde man normalerweise eine Tabelle tdatTeile
anlegen und m:n zu sich selbst in Beziehung setzen.

tdatTeil trefBauplan tdatTeil
idTeil _____fiProd _idTeil
.... fiBetandteil_/ ...

Grundbestandteile (die keinen Bauplan aufweisen) und
Endprodukte (die nicht verbaut werden) erkennt man einfach
am Fehlen entsprechender Einträge in der Bauplantabelle.

> Also tblMenuName "Mit Pizzatasche gefülltes Wildschwein",
> holt sich aus tblZutaten die Komponenten Wildschwein und
> Tomaten und weisnicht- wasallesnoch und aus
> tblGrundrezepte Pizzagrundteig. tblGrundrezepte kann sich
> wiederum aus tblZutaten bedienen.
> Die Tiefe der Verschachtelung ist dann eben hier
> beschränkt.

Das ist genau das Problem eines solchen Ansatzes. Eine
echte Stückliste muß prinzipiell beliebig schachtelbar
sein, was bei der reflexiven Beziehung der Fall ist.
Das ist in etwa analog zu einer Ordnerhierarchie.

Geschachtelte Zutaten wie in meinem Beispiel, zu dem mich
ein Rezept aus irgendeinem Asterix-Band angeregt hatte -
Bär gefüllt mit Wildschwein gefüllt mit Truthahn gefüllt
mit Hase oder so - ergeben einen Pfad

Bär |
|-Wildschwein |
|-Truthahn |
|-Hase

=> Bär/Wildschwein/Truthahn/Hase

was mit z. B.

Bär |
|-Wildschwein
|-Truthahn
|-Hase

=> Bär/Wildschwein
Bär/Truthahn
Bär/Hase

nicht identisch ist - das ist ein anderes Rezept.

Im ersten Bsp. ist Hase ein "Enkel" von Wildschwein, im
zweiten ein "Bruder".

Da Du nicht weißt, wieviel Zutaten ineinandergestopft werden
können, ist eine Beschränkung der Verschachtelungstiefe
nicht wünschenswert.

> Da ließe sich doch imho Querymäßig was draus basteln?

Wenn Du die Schachtelungstiefe beschränkst,
selbstverständlich. Wenn nicht, dann nicht.

Bißchen anders sieht die Sache auf dem SQL-Server aus,
da das T-SQL dort prozedurale Fähigkeiten hat (ibs. die
Schleifenbildung), die für rekursive resp. iterative
Strukturen nun mal erforderlich ist.

Gruß aus Mainz
Michael

.

Hallo, Henry,

Henry Habermacher [MVP Access]:


>> Vielleicht werde ich die Tabelle doch noch umstricken müssen. (Wenn
>> ich mal die Zeit finde)

> Falls nicht, empfehle ich Dir dafür Excel zu verwenden!

Ich finde beide Aussagen nicht so gut. Deine zielt darauf ab, dass er
dann in einer anderen NG fragt? Seine finde ich viel schlimmer.
Warum fragt er denn, wenn er nicht bereit ist, selber Zeit zu
investieren. Unsere Zeit, seine Frage zu lesen und zu beantworten, ist
doch auch etwas wert, oder?

Gruss - Mark
.

[Michael Zimmermann]

Hallo!

Steven Prohaska:
> Dank Deiner sehr plastischen Beschreibung ist nun die
> Welt für mich wieder in Ordnung. Also löse ich das Rätsel
> nun neu auf wie folgt:
>
> [Produkte]![PK_PrID]
> 1
> >
> n
> [Rezepte]![PrID]
> [Rezepte]![ZuID]
> n
> >
> 1
> [Zutaten]![PK_ZuID]
>
> In Rezepte kann ja nun ein "Rezept" oder auch ein
> "Grundrezept" stehen, die jeweils zugeordnet werden
> können.

Ich weise noch einmal darauf hin, daß ein solcher Ansatz
für Rezepte und Baupläne /falsch/ ist.

Rührteig ist ebensosehr ein Produkt wie eine Zutat.
Als Produkt wird es aus Mehl, Butter Eiern etc. erzeugt,
als Zutat findet es zusammen mit Haselnüssen, gemahlen;
Schokalade, geraspelt; Vanillearoma, künstlich und
kakaohaltiger Fettglasur Verwendung bei der Erzeugung
des Produktes Marmorkuchen.

Das gibt Dein Modell nicht her.

Dein Vorschlag ist dann und nur dann sachgerecht, wenn

- es nur einstufige Baupläne/Rezepte gibt
- es eine abgeschlossene Menge atomarer Zutaten/Teile
gibt
- Produkte nicht selbst als Zutaten höherstufiger
Produkte auftreten können

Dein Modell erlaubt also nur "Mischungen", aber keinen
strukturierten (geschachtelten) Aufbau von Produkten.

Gruß aus Mainz
Michael

.

[Michael Zimmermann]

Hallo!

Mark Doerbandt:
> Henry Habermacher [MVP Access]:
> > > Vielleicht werde ich die Tabelle doch noch umstricken
> > > müssen. (Wenn ich mal die Zeit finde)
>
> > Falls nicht, empfehle ich Dir dafür Excel zu verwenden!
>
> Ich finde beide Aussagen nicht so gut. ... Seine
> finde ich viel schlimmer.

Dann ist der Verweis auf Excel ja eine angemessene
Bestrafung. ;-)

Gruß aus Mainz
Michael

.

Hallo, Steven,

Steven Prohaska:

> Ich glaube verstanden zu haben, daß Du meinst und es
> hier richtig wäre, wie folgt aufzubauen:

> Wie kann man aber diese quasi unendlich mögliche
> Tiefe der Verschachtelung in den Griff bekommen ?

Michael will eigentlich nur auf eine Selbstreferenz hinaus, die z.B.
in Stuecklisten unbedingt erforderlich ist. Du hast dann nur eine
Tabelle mit den Bauteilen und jedes Bauteil kann einen Elter haben.
Damit kannst Du beliebige Schachtelungen aufbauen.

Gruss - Mark

--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm

Bitte keine eMails auf Newsgroup-Beiträge senden.
.

[Michael Zimmermann]

Hallo!

Steven Prohaska:
> Michael Zimmermann wrote:
> >
> > Ich weise noch einmal darauf hin, daß ein solcher Ansatz
> > für Rezepte und Baupläne /falsch/ ist.
> >
> Es entwickelt sich zu einer - zumindest für mich -
> interessanten Diskussion.
> Ich glaube verstanden zu haben, daß Du meinst und es
> hier richtig wäre, wie folgt aufzubauen:
>
> [Produkte]![PK_PrZuID]
> 1
> >
> n
> [Rezepte]![PrID]
> [Rezepte]![ZuID]
> n
> >
> 1
> [Produkte]![PK_PrZuID]

Was hat solange gedauert? Wenn ich mich ausnahmsweise
einmal selbst zitieren darf:

| Daher würde man normalerweise eine Tabelle tdatTeile
| anlegen und m:n zu sich selbst in Beziehung setzen.
|
| tdatTeil trefBauplan tdatTeil
| idTeil _____fiProd _idTeil
| ... fiBestandteil_/ ...
|
| Grundbestandteile (die keinen Bauplan aufweisen) und
| Endprodukte (die nicht verbaut werden) erkennt man
| einfach am Fehlen entsprechender Einträge in der
| Bauplantabelle.

> Allerdings schiebe ich keinen Blassen, wie man nun an die
> Sache auswertetechnisch - also z.B. alle Produkte ohne
> Mehl - rangehen könnte (Du schreibst ja auch, daß es SQL
> so nicht hergibt). Wie kann man aber diese quasi
> unendlich mögliche Tiefe der Verschachtelung in den
> Griff bekommen ?

Nur prozedural. In der Bauplan- (oder Rezept-) Tabelle
findest zu Produkt Nummer 5 alle seinen Bestandteile:

fiPrd fiTeil
5 3
5 7
5 12
5 17
5 24
5 38
5 42

Basisteile tauchen mit ihrer Id nicht im Feld fiPrd auf.

Der Algorithmus auf Zucker (z. B. 3) kommt schnell zum Ende,
da 3 im fiTeil-Feld mit der WHERE-Bedingung fiPrd=5
vorkommt.

Die Prüfung auf Mehl (nehmen wir mal an 15) würde erfordern,
nach dem Durchlauf der ersten Ebene, die gefundenen
fiTeil-Nummern, aus denen 5 besteht, als fiPrd zu suchen.
Z. B. könnten wir 24 (Teig) auch in der linken Spalte
finden:

fiPrd fiTeil
.... ...
5 24
.... ...
.... ...
24 15
24 18
24 22

Also: 5 (Kuchen) enthält 3 (Zucker) und 24 (Teig), wobei
24 als Produkt selbst wieder 15 (Mehl) enthält.

Als Pfad:
Kuchen/Zucker
Kuchen/Teig/Mehl

Teile, die selbst nicht weiter zusammengesetzt sind, also
einen Pfad auf jeden Fall terminieren, heißen in der
Informatik (Stichwörter hierzu: Graphentheorie, Baum,
Binärbaum) Blätter (Leaves). Endprodukte, die nicht
als Bauteile in weiteren Produkten vorkommen, heißen
Wurzeln (Roots), alle anderen sind gewöhnliche Knoten
(Nodes).

Du mußt also den Produktbaum rekursiv auflösen, bis alle
Pfade in Blättern enden, um alle Grundbestandteile
herauszubekommen. Wenn auf keiner Ebene je 15 vorkommt,
kann ein Mehlallergiker das sorglos essen.

Gruß aus Mainz
Michael

.

[Michael Zimmermann]

Hallo!

Mark Doerbandt:
> Michael will eigentlich nur...

Sei mir gegrüßt, oh Du mein Interpretator. ;-)

> ...auf eine Selbstreferenz hinaus, die z.B. in
> Stuecklisten unbedingt erforderlich ist.

Ja, darauf will er hinaus. Deshalb hat er das auch im ersten
Posting schon ausdrücklich gesagt. ;-)

Gruß aus Mainz
Michael

.

[Michael Zimmermann]

Hallo!

Henry Habermacher [MVP Access]:
> Womit wir dann bei der Stücklisten Problematik wären, ...

Genau.

> ...die schon manchen Kopfzerbrechen gemacht hat, weil ein
> Produkt wieder Ausgangszutat für ein anderes Produkt sein
> kann.

Ja. Aber das Problem ist doch bereits allgemeingültig
gelöst. Es muß das also niemand mehr selbsttätig erfinden.

> In diesem Fall denke ich, dass der vorgeschlagene
> Ansatz genügend ist.

Der richtige Ansatz ist auch nicht schwieriger. Er muß
die Tabelle ja nur auf sich selbst verknüpfen. Die
Stücklistenproblematik wurde im OP zwar nicht buchstäblich,
aber inhaltlich explizit angesprochen und war Bestandteil
der Frage.

Gruß aus Mainz
Michael

.

Hallo, Michael,

Michael Zimmermann:

> Sei mir gegrüßt, oh Du mein Interpretator. ;-)

Was fuer ein Glueck, dass Du mich hast! ;-P

> Ja, darauf will er hinaus. Deshalb hat er das auch im ersten
> Posting schon ausdrücklich gesagt. ;-)

In der Tat! Du weisst ja, das Empfaenger-Prinzip. Ich wollte nur
einfach auch mal was schreiben und manchmal nutzt es ja, das
Wesentliche noch mal kurz zusammen zu fassen! ;-)

Gruss - Mark
.

[Michael Zimmermann]

Hallo!

Gerald Aichholzer:
> Michael Zimmermann wrote:
> > Nur prozedural. In der Bauplan- (oder Rezept-) Tabelle
> > findest zu Produkt Nummer 5 alle seinen Bestandteile:
>
> Wenn man die Stückliste nicht in Form einer
> Adjazenzliste...

Reschbegd, Herr Doktor! ;-)

> sondern im Nested Set Modell darstellt, dann sollte sich
> diese Frage auch mit reinem SQL beantworten lassen (sogar
> einem relativ einfachen SQL-Statement).

Sic. Daher habe ich in meiner ersten Antwort auch darauf
hingewiesen:

| Bei sehr hoher zu erwartender Schachtelungstiefe, die
| aber bei Rezepten nicht vorliegen dürfte, kann auch das
| Prinzip der Nested Sets hilfreich sein.

> Nachteil dieses Modells ist, dass es beim Einfügen bzw.
> Löschen von Datensätzen reorganisiert werden muss ...

.... und daher eigentlich erst sinnvoll ist, wenn zu tiefe
Hierarchien die Abfrageperformance der klassischen Lösung
mit ihrer rekursiven externen Prozedur zu sehr in den Keller
gehen lassen.

Von diesem Manko abgesehen ist die normale reflexive
Beziehung ja in Ordnung. Ich kenne Nested Sets eigentlich
in erster Linie als Lösung von derartigen
Geschwindigkeitsproblemen.

Gruß aus Mainz
Michael

.