Verhnüpfen von Tabellen

[hate_sql]

Hallo, ich bin was Datenbanken und sql angeht noch absolut neu, also bitte um Nachsicht.

Ich habe eine Accesdatenbank, die ich in asp.net anspreche und auswerte. Einfache Sachen klappen ganz gut, aber hier einem komme ich nicht weiter. Ich versuche es mal allgemein zu klären.

Meine Haupttabelle heißt
tblMaterialien mit den Spalten
MaterialId. MaterialID ist ein Primärschlüssel (Typ Zahl)
Materialname asl Text

Eine Tabelle tblEigenschaften mit den Spalten
MaterialID als Primärschlüssel mit 1:1 Verknüpfung zu tblMaterialien.MaterialID
Eigenschaft (Typ Zahl), beinhalten den Wert
EigenschaftEinheit (Typ Zahl), verknüpft mit tblEinheiten.EinheitID, aber tblEinheiten. Einheit (Typ Text) wird angezeigt. Laut meinen Kenntnissen soll das so sein, damit die Daten nicht mehrfach vorgehalten werden. In Access kann der Text der Einheit schön über dasKombinationsfeld ausgewählt werden

EigenschaftMessmethode (Typ Zahl), verknüpft mit tblMessmethoden.MessmethodeID, aber tblMessmethoden. Messmethode(Typ Text) wird angezeigt, dito wie vorher.

Was brauche ich jetzt als SQL für asp.net? Eine Tabelle, die den Materialnamen enthält, die zu dem Materialnamen zugehörige Eigenschaft, die dazugehörige Einheit als Text und die dazugehörige Messmethode als Text.

Seit einigen Tagen plage ich mich damit herum. Mittlerweile ist das nur noch dumpfes rumgeeiere. Das sollte doch nicht so schwer sein oder?

Vielen Dank im voraus, so das sich mein nick bald in love_sql ändert.

[hate_sql]

Hallo,

noch nicht ganz was ist suche, aber immer hin funktioniert es mit 2 Tabellen,

SELECT tblMaterialien.Materialname, tblHärten.ShoreHärteA, tblEinheiten.Einheit, tblFertigungsverfahren.Fertigungsverfahren

FROM tblEinheiten, tblFertigungsverfahren
INNER JOIN (tblMaterialien INNER JOIN tblHärten ON tblMaterialien.MaterialID = tblHärten.MaterialID) ON tblFertigungsverfahren.FertigungsverfahrenID = tblMaterialien.Fertigungsverfahren

WHERE tblHärten.ShoreHärteAEinheit=tblEinheiten.EinheitI D;

Aber ehrlich gesagt verstehen tue ich den Teil ab Inner join überhaupt nicht. Kann mir wer das verständlich erklären. Zudem muss ich sagen das bei den Erklärungen im web zu Inner Join auch nicht wirklich durchgestiegen bin.

Mfg, Franz

[fanderlf]

Öhm mal generell: Wenn zwei Tabellen denselben Primärschlüssel haben stimmt zu 99% irgendwas nicht. Zum Beispiel hat eine Materialeigenschaft einen eigenen Primärschlüssel und benutzt die MaterialID als Sekundärschlüssel (oder auch Fremdschlüssel) um darauf zu referenzieren. Ansonsten könntest Du ja per Material nur eine Zeile mit Eigeschaften haben und diese könntest Du auch gleich in die Materialtabelle ziehen.

Sieht dann praktisch so aus:

Tabelle: Material
==================
MaterialId: int, PK
MaterialName: String

Tabelle: MaterialEigenschaft
==================
EigenschaftId: int, PK
MaterialId: int, FK auf Material
EigenschaftName: string
Wert: string
EinheitId: int, FK auf Einheit
MessmethodeId: int, FK auf Messmethode

Tabelle: Einheit
==================
EinheitId: int, PK
EinheitName: string
EinheitKuerzel: string

Tabelle: Messmethode
==================
MessmethodeId: int, PK
MessmethodeName: string
Beschreibung: string

Das entsprechende Kommando dazu würde so aussehen:

[highlight=sql]
SELECT *
FROM Material m
INNER JOIN MaterialEigenschaft me ON me.MaterialId = m.MaterialId
INNER JOIN Einheit e ON e.EinheitId = me.EinheitId
INNER JOIN MessmethodeId mm ON mm.MessmethodeId = me.MessmethodeId
[/highlight]

[hate_sql]

Hallo,

grundsätzlich könnte ich alles in eine Tabelle werfen.

Beispiel: Edelstahl, Baustahl, Warmarbeitsstahl, diese haben wieder viele Eigenschaften wie Zugfestigkeit, E-Modul, Korrosionsbeständigkeit, etc. Diese Eigenschaften haben eine Einheit, z.B. mm, N/mm², etc. und werden nach bestimmten Normen gemessen. Wobei eine Eigenschaft (zahl) unterschiedliche Einheiten (Text) haben kann (selten) und nach verschiedenen Mesmethoden (Normen) gemessen werden kann.

Beispiel hat der Werkstoff Edelstahl die Eigenschaft E-Modul mit der Einheit N/mm² = 210000 N/mm² gemessen nach Norm xyz

Wenn ich es richtig verstehe macht es Sinn Einheit und Messmethode in eine eigene Zabelle zu verlagern

Die Haubttabelle enthält eine MaterialID mit der Materialbezeichnung, z.B. Edelstahl xyz. Jetzt könnte man die dazugehörigen Eigenschaften in weiteren Felder anlegen.

Leider ist mann in Access begrenzt, was die Beziehungen angeht, ab einer bestimmten Anzahl erhält man die Meldung Anzahl der Indizes pro Tabelle überschritten, obwohl von Hand kein Feld indiziert ist. Nach meiner Kenntnis indiziert Access jedes Feld mit Beziehung.

Mann könnte die Felder Einheit und Messmezhode als reines Nachschlagefeld ausführen ohne Beziehung, aber dann stösst man an anderen Stellen auf Beschränkungen, weil eben keine Beziehung definiert ist.

Da relative wenige Zeilen, aber viele Felder, weiss ich nicht ob ich wirklich für jede Eigenschaft eine eigene Tabelle mit Primärschlüssel, Fremdschlüssel zu MaterialID, Einheit, Messmethode anlegen soll?

Folglich habe ich die eigendliche eine Tabelle in mehr Tabellen aufgeteilt und über eine 1:1 Beziehung verknüpft.

Bisher funktioniert das System, sowohl in Access (Dateneingabe durch verschiedene Leute), als auch Ausgabe in die Webpage.

Was mich so fuxt, ist die richtige Formulierung der SQL, damit ich weder Kreuztabelle bekomme oder richtigerweise die z.B. Einheit als Text und nicht die Zahl der EinheitID.

Bin für jeden Verbesserungsvorschlag dankbar, bzw wie der in der vorherigen Post dargestelle Join funktioniert.

Vielen Dank im voraus, Franz

[Martin R.]

Hallo,

warum willst du die Tabellen mehrfach indizieren

Normalisierung hat viele Vorteile.
Um nicht technisch zu werden mal ein bsp.

Tabelle Material
Mat Elastizitätsmodul
Stah1 210.000
Stahl2 250000

Select * where Elastizitätsmodul >200000

Ergebnis 250000
Das kann dir bei einem vernünftigen Design nicht passieren.

Mal abgesehen, wenn sich eine Prüfnorm ändert musst du es nicht bei jedem Material abänderen und und und.

Der Join zeigt dir alle Eigenschaften,Einheiten und Methoden die über die verschiedenen technischen IDs mit einem Material in Beziehung stehen.

[hate_sql]

Werd immer konfuser

Hallo Martin,

bevor ich ein endgültiger Anhänger von Konfuzius werde.

Ich dachte denau das mache ich. Normalisierung. Die sich wiederholenden Einheiten und Messmethoden in jeweils eigene Tabelle auslagern. Ich kann z.B. die Messmethoden (Text) ändern, da ja die Verknüpfung über die MessmethodeId (Pk dieser Tabelle) läüft.

In der Tabelle der Materialeigenschaften gibt es dann die Felder:
Eigenschaft1 als Zahl
Eigenschaft1Einheit über Kombinationsfeld als Fremdschlüssel auf die Tabelle Einheiten mit EinheitID (Primärschlüssel) und nicht Anzeige des schlüsselwerts sondern das dazugehörige Feld Einheit (Text).

Eigenschaft1Messmethode über Kombinationsfeld als Fremdschlüssel auf die Tabelle Messmethoden MessmethodeID (Primärschlüssel) und nicht Anzeige des Schlüsselwerts sondern das dazugehörige Feld Messmethode(Text).

Und soweiter. Für jede Eigenschaft 3 Felder: Wert, Einheit, Messmethode

Die Tabelle Material ist wiederum per 1:1 an die Tabelle Materialeigenschaft geknüpft. Warum das alles? Da Access für jeden Fremdschlüssel einen Index anlegt und die Anzahl auf 32 beschränkt ist. Ansonsten hätte ich nur 3 Tabellen. Material mit all seinen Eigenschaften (je 3 Felder für Eigenschafr, Einheit,. Messmethode), Tabelle mit den Einheiten, Tabelle mit den Mesmethoden.

Das der Join die Tabellen verknüpft, soweit bin ich schon, aber wie in den speziellen Fall das genau funktioniertt, ist mir noch unklar.

Sollte ich komplett auf dem Holzweg sein, bitte genauer beschreiben, wie meine Tabellen dann in Access aussehen müßten, da ich laut den Fehlermeldungen in meinem jetzigen Design weder auf die Beziehungen (und den damit verbunden unsichtbaren Indizes) verzichten kann, noch auf die Normalisierung.

Für alles dankbar, Franz

[hate_sql]

Hallo Fanderl,

jetzt glaube ich habe ich deinen Vorschlag kapiert. Statt vieler Felder mit den unterschiedlichen Eigenschaftsnamen, meine Tabelle kippen. Noch eine Tabelle zum normalisieren für die unterschiedlichen Eigenschaftsnamen machen. In sql nicht auf, wie bei mir auf das spezifische Eigenschaftsfeld einen select machen, sondern auf das allgemeine Eigenschaftfeld und mit Where nach der speezifischen Eigenschaft filtern. Richtig verstanden?

Mfg, Franz

Öhm mal generell: Wenn zwei Tabellen denselben Primärschlüssel haben stimmt zu 99% irgendwas nicht. Zum Beispiel hat eine Materialeigenschaft einen eigenen Primärschlüssel und benutzt die MaterialID als Sekundärschlüssel (oder auch Fremdschlüssel) um darauf zu referenzieren. Ansonsten könntest Du ja per Material nur eine Zeile mit Eigeschaften haben und diese könntest Du auch gleich in die Materialtabelle ziehen.

Sieht dann praktisch so aus:

Tabelle: Material
==================
MaterialId: int, PK
MaterialName: String

Tabelle: MaterialEigenschaft
==================
EigenschaftId: int, PK
MaterialId: int, FK auf Material
EigenschaftName: string
Wert: string
EinheitId: int, FK auf Einheit
MessmethodeId: int, FK auf Messmethode

Tabelle: Einheit
==================
EinheitId: int, PK
EinheitName: string
EinheitKuerzel: string

Tabelle: Messmethode
==================
MessmethodeId: int, PK
MessmethodeName: string
Beschreibung: string

Das entsprechende Kommando dazu würde so aussehen:

[highlight=sql]
SELECT *
FROM Material m
INNER JOIN MaterialEigenschaft me ON me.MaterialId = m.MaterialId
INNER JOIN Einheit e ON e.EinheitId = me.EinheitId
INNER JOIN MessmethodeId mm ON mm.MessmethodeId = me.MessmethodeId
[/highlight]

[fanderlf]

Also man könnte das durchaus auch anders modellieren je nachdem worauf es in Deinem Problem ankommt. Ich hab mir das so gedacht:

Der Kern des Problems ist dass man Materialien ablegen will, also eine Tabelle Material. Da jetzt eine Material mit Sicherheit mehrere Eigenschaften haben kann habe ich diese in eine extra Tabelle gepackt (1:n). Wenn gleiche Eigenschaften mehrere Materialen haben könnten, dann müsste man noch eine Tabelle dazwischen bauen (m:n).
Die Einheit und die Messmethode habe ich wieder in eine separate Tabelle gepackt, da man bestimmt die gleiche Messmethodik wieder für verschiedene Eigenschaften verwenden kann (z.B. wenn sich nur der Wert unterscheidet), genauso verhält es sich mit der Einheit.

Ich hoffe Du hast etwas verstanden was mein Ansatz ist. Frag ruhig nach wenn Du was nicht verstanden hast

Schau mal so mit Beispieldaten:

Material
1 Kabel
2 Widerstand

Eigenschaft
1 1 Widerstand 0.5 1 1
2 1 Laenge 0.5 2 2
3 2 Widerstand 300 1 1
4 2 Durchmesser 0.5 2 2

Einheit
1 Ohm OmegaZeichen
2 Meter m

Messmethode
1 Widerstandsmessgeraet anschließen
2 Mit Schieblehre messen

[hate_sql]

Hallo fanderl,

nach einigem überlegen bin ich derzeit bei dem Schluss, das ich es derzeit so lasse wie es ist, da die Datenbank schön älter und damit gefüllt ist. Ich habe dein erstes Beispiel in Access nochmals auf schnelle nachvollzogen.

1.ten Die Datenbank wäre sehr schnell um weitere Eigenschaften zu erweitern. Derzeit ist es deutlich aufwendiger neue Eigenschaften anzulegen. Das hat mich echt faziniert, wie sich etwas ändert, wenn man statt in "Spalten" in "Zeilen" denkt. Wie sich das anlegen neuer Eigenschaften extrem vereinfachen lässt.

2.ten. Kurze Zeit später ist mir aber aufgefallen (Dank Martin), das dieser Aufwand auf der anderen Seite aber einen wesentlichen Vorteil bietet. Weil jede Eigenschaft explizit als eigenes Feld angegeben ist, kann ich nätürlich für jedes Feld auch entsprechend die Eingabe beschränken, Eingabe fordern, etc. Z.B sind viele Eigenschaften Zahlenwerte, die sich in einem bestimmten Bereich tummeln, alles ausserhalb ist ein fehlerhafte Eingabe, oder andere Eigenschaften sind Text-Werte (z,b. Klassifizierung nach Ul94, und das lässt sich wieder normalisieren, wie jetzt auch schon). Zudem bietet Access mit automatsieren erzeugen von Eingabemasken eine sehr schnelle Möglichkeit Werte in die Datenbank einzugegeben, wenn für jede Eigenschaft eine eigene Eingabefeld zur Verfügung steht, was für den Bediener wesentlich leichter ist.

3.ten Wüsste ich nicht, wie ich auf die schnelle die Datenbank ändere.

Für ein eventuelles Redesign bedeutet das wohl nochmals genauer darüber nachzudenken, wie das für die Zukunft auszusehen hat. Was bleibt, wie ist dieser Join zu verstehen, damit ich nicht soviel Zeit auf der anderen Seite (einbinden in asp.net ) verschwende.

Waren das glückliche Zeiten, als ich micht nicht mit asp.net, silverlight und Datenbank beschäftigen musste , sondern schnöde Winforms.

Mfg, Franz

[fanderlf]

Na in WinForms hast Du aber dieselben Probleme. Das hat eigentlich nichts mit dem UI Framework zu tun.

[hate_sql]

Hallo fanderl,

nachdem ich vorher nicht mit access musste, auch keine Datenbanken allgemein, damit auch kein sql, und sql statements die in asp.net unterschiedlich zu dem sind wie sie in access sind (wäre auch zu einfach in access mittels Abfrage-Assistent die sql erstellen und per paste und copy übertragen), silverlight, wo vieles aufgrund von Beschränkungen nicht so geht und vieles, obwohl es so gehen sollte, einen workaround benötigt, dazu html, asp.net, javascript, php, css, etc.. So sind das doch deutlich mehr Technologien und vorallem Sprachkonsrukte, die man benötigt um halbweg was vernünftiges hinzukriegen. So gesehen war es mit Winforms, etc, deutlich einfacher und man konnte sich mehr auf die Entwicklung konzentrieren, als sich mit den diversen "Technologien" zu plagen. Nebenbei. Wenn ich vergleiche zwischen den alten Winforms und jetzt dem xaml, kann ich den wesentlichen Vorteil nicht erkennen. Ein with bla ... war mir tausendmal lieber als das jetzige xmal Klartext geschriebsel. Vieleicht habe ich auch zu viele schlechte Erfahrungen mit Blend und VS gemacht, wenn in einer umfangreichen GUI nur noch der lapidare Fehler kommt das er die erste Zeile nicht verarbeiten kann. Aber das ist jetzt wirklich extrem offtopic.

Vielen Dank für die Hilfe, Franz

[fanderlf]

Hm trotzdem hat die Oberflächentechnologie nichts mit Datenbankabfragen zu tun. Ausserdem gibt es auch für nahezu jede Datenbank einen Querydesigner. Ich würde davon allerdings erstmal abraten, weil man sonst gar nicht versteht was das Teil macht und teilweise auch unnötig aufwändige SQL Befehle generiert werden.

@Silverlight und XAML:
Der Unterschied zwischen Windows Forms und sämtlichen XAML-basierten Frontends ist, dass diese viel mehr Unterstützung für Architektur bieten (Stichwort: MVVM - Model-View-ViewModel). Ausserdem lassen diese sich durch die strikte Trennung von UI (XAML - View) und Logik (UI - Logik - ViewModel / BusinessLogik -Model) leichter testen. Im Umkehrschluss bedeutet das natürlich auch dass man sich mit WPF/Silverlight wesentlich mehr auseinandersetzen muss als mit Windows Forms. Natürlich kann man XAML UIs auch auf dem herkömlichen Weg über Event Handler programmieren (wie in Windows Forms auch), aber das ist eigentlich nicht der Weg wie man es machen sollte, wenn man es "richtig" machen will. Natürlich kommt es hier auch immer auf den Anwendungsfall an.

@ASP.NET:
Das ist natürlich eine ganz andere Welt als Windows Forms. Selbst wenn es so aussieht als könnte man damit wie mit Windows Forms arbeiten (das war der ursprüngliche Ansatz), so kann das natürlich im Endeffekt so auch gar nicht funktionieren, da eine Webseite einen ganz anderen Lebenszyklus hat als eine Windows Form.

Fazit:
Wenn Du das alles allein machen sollst, dann wirds ganz schön hart. Vor allem wenn hinten etwas rauskommen soll was Qualität hat. Das sind viele verschiedene Technologien und wenns dann schon an etwas SQL scheitert, dann würde ich mich vielleicht erstmal auf eine der obigen Technologien beschränken.