Diskussion:Relationale Algebra

Das hier würde ich vielleicht etwas ausführlicher machen. So in dem Stil: Es gibt folgende bla bla bla: dann zählst Du die nachfolgenden Abschnitte nochmal kurz in einer Übersicht auf und dann gehts im Einzelnen los...

sieht man doch im Inhaltsverzeichnis DWay 10:11, 9. Sep 2004 (CEST)

Quellen fehlen

Dieser Artikel bedarf einer gründlichen überarbeitung:

• Quellen fehlen fast vollständig

• Er ist unvollständig (Zum Beispiel fehlt der Full-Outer-Join)

• Er ist fehlerhaft (Der Semijoin ist allgemeiner definiert)

--kowa (Diskussion) 17:07, 12. Aug. 2018 (CEST)

Redundanz

Dieser Artikel sehr lang in Anbetracht der Tatsache, dass nicht viel neues darin steht, wenn man Mengen kennt. Da diese in den ausführlichen Definitionen dann doch verwendet werden, hielte ich es für besser und lesbarer, wenn man einfach sagte, dass die fraglichen Definitionen analog (bis auf die Verwendung von Typen sind sie sogar gleich) zu denjenigen der Mengenlehre erfolgen und dann auf die eigentlichen Besonderheiten einginge.

Auch der Textblock in der Einleitung ist zu lang und nicht hinreichend strukturiert.Stephan Spahn 12:58, 12. Mai 2011 (CEST)

Vereinigung

So steht es im Artikel drin: Bei der Vereinigung R ∪ S werden alle Tupel der Relation R mit allen Tupeln der Relation S zu einer einzigen Relation vereint. Voraussetzung dafür ist, dass R und S das gleiche Relationenschema haben. Das heißt, sie haben gleiche Attribute und Attributtypen. Duplikate werden bei der Vereinigung gelöscht.

ABER !!! Bei dem Beispiel sind die Duplikate noch drin. D.h. das Beispiel ist falsch. In dem Endergebnis der Vereinigung von den Relationen r und s, müsste der Datensatz 456 raus!

Duplikate werden nicht gelöscht sondern nur einmal angeführt, soll heißen in der Ergebnisrelation werden Duplikate gelöscht.

Kreuzprodukt

Gemeint ist hier sicher das kartesische Produkt, oder? Ich habe den Begriff aus einer Überschrift gelöscht, aber weiter unten taucht er nochmal auf. --Head 16:37, 10. Feb 2005 (CET)

Laut meinem 'Datenbanksysteme' von Kemper/Eickler wird die Operation tatsächlich als Kreuzprodukt bezeichnet. Man kann aber auch kartesisches Proukt sagen. --Sprezz 17:52, 10. Feb 2005 (CET)

Division

Ist jemand in der Lage die Division um eine Definition zu bereichern und überhaupt irgendwie verständlich hinzuschreiben? Scheint ein komplizierter Sachverhalt zu sein, aber richtig durchschaubar wird er hier auch nicht... --Elwood j blues 22:43, 14. Feb 2005 (CET)

Habe mich an einer umgangssprachlichen Definition versucht, schau mal? Fragment 02:16, 8. Aug 2005 (CEST)

Join

In dem ersten Beispiel von Join müsste es meiner Meinung nach heißen, dass das Ergebnis die Menge aller Datensätze ist, die in beiden Tabellen vorkommt. Vergleicht dazu mal den Artikel in der englischen Wikipedia. --Dash 16:08, 28. Mai 2005 (CEST)

Beim Natural Join ist das Beispiel irgendwie sinnfrei, oder? Es findet doch gar keine Projektion statt! (nicht signierter Beitrag von 84.61.83.226 (Diskussion) )

Da Join auf diese Seite umgelenkt ist, sollten m. E. auch die im Datenbank-Jargon üblichen Begriffe „outer join“ und „inner join“ definiert werden. Könnte das jemand tun, der sich damit besser auskennt, als ich? --jpp ?! 14:09, 24. Mär 2006 (CET)

Ach wäre das schön, wenn mir jemand diesen Wunsch erfüllte… --jpp ?! 15:31, 5. Jan. 2007 (CET)

Schau mal, ob dir das Ergebnis gefällt--Af8 21:40, 12. Jun. 2007 (CEST)

Ist die Definition des Joins über den Vereinigungsoperator an der Stelle nicht etwas unpräzise formuliert?

$R\bowtie _{\mathrm {Ausdruck} }S:=\{r\cup s|r\in R\land s\in S\land \mathrm {Ausdruck} \}$

Der Vereinigungsoperator wurde doch schon anders belegt (Relationenalgebra). R und S sind ggf. nicht Vereinigugnsverträglich. Das Kreuzprodukt ist definiert als

$A\times B:=\{(a_{1},\dots ,a_{m},b_{1},\dots ,b_{k})|(a_{1},\dots ,a_{m})\in A\wedge (b_{1},\dots ,b_{k})\in B\}$

wäre das nicht passender an dieser Stelle? (nicht signierter Beitrag von 130.83.161.65 (Diskussion) 15:26, 6. Sep. 2010 (CEST))

Joinverfälschung keine textuele Erläuterung - Ein Mangel der beseitigt werden sollte. Aus dem Beispiel selber läst sich nur schwerlich die Regel herleiten. Ich hab den ganzen kram in SQL-Vorlsung gehört und ich steh auf dem schlauch... für ein paar erhelende Sätze wäre ich dankbar. Gruß CB -- 00:16, 18. Nov. 2010 (CET) (ohne Benutzername signierter Beitrag von 141.35.40.136 (Diskussion) )

Wäre gut wenn erläutert wird (im Beispiel) das <> ungleich Operator ist (ist er das?). War mir nicht sofort klar. (nicht signierter Beitrag von 130.83.199.121 (Diskussion) 11:34, 12. Apr. 2012 (CEST))

Der Semi-Join kann auf beide Eingaberelationen beschränkt werden, nicht nur auf die linke. (nicht signierter Beitrag von 95.90.210.140 (Diskussion) 18:43, 15. Dez. 2014 (CET))

Mengenoperationen

Die Aussage "der Wertebereich der Attribute von R und S identisch ist" muss man relativieren, denn - leider - sind die Wertevorräte zweier CHAR-Felder unterschiedlicher Längen, die mit identischen INSERTs gefüllt wurden, i.a. nicht identisch, so dass JOINs mit diesen Feldern (hier: person.id und anschrift.id könnten unterschiedliche Feldlängen haben!) eine leere Ergebnismenge erzeugen. Gänzlich problematisch wird es in SELEKTIONEN, wenn feste Zeichenketten (hier: Selektion von anschrift.ort="Marburg") verwendet werden!

---

Das Komplement fehlt.

Relationale Algebra – aber Deklarative Sprache

Den Satz aus der Einleitung „Eine praktische Umsetzung findet die Relationenalgebra als Basis der Sprache SQL.“ finde ich missverständlich. Ich würde noch folgendes hinzufügen:
SQL ist eine deklarative Sprache und verwendet die Elemente der relationalen Algebra. SQL ist allerdings nicht gleichmächtig mit der Relationalen Algebra.
Auch, wenn das hier nicht der SQL-Artikel ist, finde ich die Abgrenzung wichtig. Wie seht Ihr das? --Dunkeltron 15:26, 7. Sep 2005 (CEST)

Was tun? Weiß ich auch nicht, aber

1. Laut dem englischen SQL-Artikel basiert SQL sowieso auf dem Tupelkalkül. In meiner Bibel (Heuer, Saake) steht: "Die Sprache SQL besitzt einen Kern, der auf dem Kalkül basiert, jedoch mit algebraischen Erweiterungen" (S.337). Für die einzelnen Teile von SQL-Statements wird später außerdem erläutert, wie sie in den Tupelkalkül umzusetzen sind.
2. Aktuelle SQL-Dialekte sind streng relational vollständig, d.h. jedes Statement der RA kann in genau einem Statement der Sprache ausgedrückt werden - SQL-92 war das noch nicht, dafür ist die orthogonale Verwendbarkeit von SFW-Blöcken, speziell Mengenoperationen (UNION war nur auf oberster Ebene anwendbar), notwendig. Einige SQL-Dialekte unterstützen außerdem keine "Unterabfragen". Aggregatfunktionen sind auf der anderen Seite so aber nicht in die reine RA abzubilden, die Multimengensemantik auch nicht, vgl. die Erweiterungen. Letztlich sind also beide irgendwie weniger mächtig als das jeweils andere. (EDIT: streng relational vollständig natürlich! Fragment 19:51, 9. Sep 2005 (CEST))
3. Einen Bezug zu SQL sollte man aber durchaus darstellen, vielleicht, indem man die Mächtigkeit des SQL-Kerns mit Hilfe der RA bewertet oder einige Grundoperationen umsetzt.

Grüße, Fragment 21:31, 8. Sep 2005 (CEST)

Quatsch: SQL auf Relationale Algebra abbilden

Der eigentliche Weg muss lauten rel. Algebra --> SQL. Das kommt im Artikel nicht rüber, aber SQL ist nunmal nur eine mögliche Abfragesprache für rel. Datenbanken und keineswegs die Wurzel aller anderen.

Ich verstehe Dich nicht. Wieso sollte man SQL nicht in die RA abbilden können? Oder das nicht tun wollen? Die RA ist keine praktische Abfragesprache, sondern eine Sprache für die theoretische Betrachtung anderer Abfragesprachen. Selbstverständlich ist es sinnvoll, SQL in die RA abzubilden, z.B. zur Semantikfestlegung. Die Aussage Deines 2. Satzes ist korrekt, aber ich weiß nicht, warum Du ihn hierher geschrieben hast? Fragment 15:26, 28. Sep 2005 (CEST)

Im übrigen enthält Deine Änderung sachliche Fehler, falsche Begrifflichkeiten und abschnittsfremde Informationen (der Abschnitt heißt "Erweiterungen der RA"). Bist Du zum diskutieren da oder mache ich den REV einfach so? Fragment 15:35, 28. Sep 2005 (CEST)

Revert-Begründung

1. sachliche Fehler: a) Die RA ist nicht die formale (nicht "mathematische") Grundlage aller Anfragesprachen, sondern vielmehr die Kalküle (Tupelkalkül/Bereichskalkül). b) Im weiteren lässt sich nicht jede Abfragesprache auf die RA zurückführen, nicht sichere Kalkülausdrücke z.B. nicht. c) Es gehen nicht nur "proprietäre Erweiterungen" von SQL über die Mächtigkeit der RA hinaus, sondern bereits der SQL-Kern. d) Die bisher definierte RA war nicht minimal. Daher werden die minimalen Operationen in einem eigenen Abschnitt aufgelistet.

2. falsche Begrifflichkeit: a) relationale Datenbestände -> relationales Datenmodell, b) "proprietär" ist anscheinend nur wg. seines negatives Bedeutungszusammenhanges verwendet ohne Kenntnis der Wortbedeutung

3. abschnittsfremde Informationen: Der Einleitungssatz gehört in die Einleitung, nicht in die Diskussion von Erweiterungen.

Gruß, Fragment 21:45, 28. Sep 2005 (CEST)

---

Ok, dann versuche ich mal an Deinem(?) Text darzulegen, was ich hier mind. missverständlich finde:

1. Um andere Abfragesprachen, speziell SQL, vollständig in die relationale Algebra abbilden zu können, ist die relationale Algebra nicht mächtig genug.

SQL wurde auf BASIS der relationalen Algebra entwickelt. Die logische Abbildungsrichtung lautet also relationale Algebra --> SQL. Damit handelt es sich nicht um Erweiterungen der Algebra sondern um Konstrukte in SQL die über die rel. Algebra hinaus gehen.

2. Es gibt z. B. keine Möglichkeit, die SQL-Operatoren GROUP BY/HAVING, Aggregatfunktionen

Dabei handelt es sich nur um Darstellungsoptionen, was haben die die in einer (mengenorientierten) Algebra zu suchen?

3.und Nullwerte in die relationale Algebra zu übersetzen.

Für Nullwerte ist tatsächlich eine Erweiterung der Domäne nötig.

4. Wir betrachten hier einige Erweiterungen (die teilweise ähnliches bewirken), die eine vollständige Abbildung in die relationale Algebra, und damit eine vollständige theoretische Betrachtung dieser Abfragesprachen, ermöglichen.

siehe 1. Punkt

Vielleicht waren meine Änderungen nicht ausreichend - einen Abschnitt "Erweiterungen... " so wie er aktuell da steht halte ich allerdings für falsch.

---

Ahoi, fein, dass Du noch da bist,

Ad 1) Belege mal bitte? Quelle? Ich habe nur Aussagen gefunden, dass SQL auf dem Tupelkalkül basiert, nicht auf der RA, und habe dafür länger gesucht. Es würde mich wirklich interessieren, ob es überhaupt irgendwelche Sprachen gibt, die ausdrücklich auf der RA basieren, sowas gehört dann nämlich in die Einleitung. "Alle" wie Du geschrieben hast, gilt in keinem Fall (Gegenbeispiele: QBE, QUEL, so weit ich gesehen habe: SQL).

Ich wiederhole nochmals, es gibt keine "logische Abbildungsrichtung" solcher Sprachen; sie sind wenigstens teilweise (die Kerne) ineinander abbildbar, sonst würden die formalen Sprachen ja auch gar keinen Sinn machen (sie wären nutzlos). Die RA ist hier ja nicht umsonst mittels quasi-Kalkülausdrücken definiert.

Ad 2) Dass "ORDER BY" eine Darstellungsfunktion ist, hätte ich Dir abgenommen, für Aggregatfunktionen gilt das wohl kaum (Beispiel: Alle Verkäufer, deren Gesamtsumme an Verkäufen > 1.000.000 ist). Aber egal, im Heuer&Saake sind die als Erweiterungen der RA aufgeführt (daher kommt ja auch der Gruppierungsoperator γ) - wenn das für die gut genug ist, soll es für mich auch reichen.

Deine Änderungen waren nicht nur "nicht ausreichend", sonst hätte ich ja keinen Revert gemacht, sondern erweitert, s.o.

Außerdem, m.E.: Die "große" Leistung der RA ist die Definition des Begriffes "relationale Vollständigkeit" mit einer Sprache sehr beschränkter Mächtigkeit (das ist nämlich so gewollt), und nicht die formale Definition.

Grüße, Fragment 14:29, 29. Sep 2005 (CEST)

A.Kemper, A.Eickler, Datenbanksysteme, 5. Auflage:

• „Es gibt zwei formale Sprachen, die für die Anfrageformulierung in relationalen Datenbanken konzipiert wurden. Es handelt sich hierbei um 1. die relationale Algebra (...) un 2. den Relationenkalkül.“ (S. 82)
• „Die relationale Algebra und der Relationenkalkül bilden die theoretische Grundlage für die Anfragesprache SQL.“ (S. 105)
• „Nach der Einführung des relationalen Modells Anfang der 70er Jahre wurde von IBM ein DBMS-Prototyp namens "System R" entwickelt. Die Anfragesprache, die System R bereitstellte, wurde "SEQUEL" genannt (...) und später in SQL umbenannt“ (S. 105)

Danach ist die relationale Algebra ebenso ein Teil des relationalen Modells wie das Tupelkalkül (= Relationenkalkül) und existierte bereits vor SQL; was wiederum den Schluss nahe legt, dass SQL zumindest teilweise auf der Relationenalgebra basiert. --Thetawave 14:36, 3. Okt 2005 (CEST)

Super!! Das würde erklären, warum ich nur nicht-wirklich-Behauptungen finde, dass der TK Basis für SQL ist und nur Erwähnungen der RA "in der Nähe von" SQL finde. Und jetzt? Fragment 14:56, 3. Okt 2005 (CEST)

Keine Ahnung, ich wollte nur die Zitate einbringen ;-D. Aber mal sehen... --Thetawave 17:04, 3. Okt 2005 (CEST)

Ich habe die Originalarbeit von E. F. Codd - dem „Urvater“ des Relationalen Datenmodells - an erster Position in die Literaturliste aufgenommen, inklusive Links auf legale Online-Quellen (der veröffentlichende Zeitschriftenverlag stellt den Artikel freundlicherweise kostenfrei zur Verfügung). Vielleicht kann man anhand dieses Dokuments ermitteln, wie die historische Entwicklung vor sich ging und so die weitere Vorgehensweise festmachen?! Ich habe leider gerade keine Zeit, den Artikel zu lesen. --Thetawave 17:25, 3. Okt 2005 (CEST)

Lese ich später :-) Das ganze scheint eine SEHR SEHR lange Geschichte zu sein, ich habe gerade das hier gefunden: http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html , was erstmal die Aussage, dass TK und RA zusammen entwickelt wurden, stützt. Danach ist furchtbar viel passiert zwischen Forschern bei IBM und in Berkeley, und dann kam SQL, oder so ähnlich. Ich bin fast geneigt, meine Finger vom Thema zu lassen. Fragment 01:04, 4. Okt 2005 (CEST)

(Symmetrische) Differenz

Ich hab die symmetrische Differenz als Dreieck gelernt und die normale als \

Ich kenn die normale als \ oder -, die symmetrische kannte ich gar nicht :-) Schreib die alternativen Notationen halt mit dazu, als Alternative gekennzeichnet. Wir müssen bloß innerhalb des Wikis konsistent bleiben. Grüße, Fragment 12:48, 31. Okt 2005 (CET)

Beispielaufgaben

Tachle, ich vermisse hier Beispiele in der relationalen Algebra mit Anfragen wie: "Wir haben eine Relation vorliegen, mit MHz Geschindigkeiten von Computern. Welcher ist von diesen Computern der schnellste?"... Oder ähnliche Fragen wie: "Welche Computer werden von allen registrierten Kunden gekauft?". "Welche werden nicht von allen Kunden gekauft?" Oder Aggregatzustände wie: Meisten? Wenigsten? o.ä.. Kann das jemand büdde ergänzen? Ich lerne gerade für eine mündliche Prüfung und würde hier womöglich Fehlinformationen preisgeben. Tolga Cerci 13:20, 19. Nov 2005 (CET)

---

Habe im Abschnitt "Beispiele" folgenden Text gefunden:

"--> wieso muss die Bezeichnung nicht mit σ_{Ware.Bezeichnung='Gemüse'} sowie _{Lieferant.Ort='Bremen'} angegeben werden. Es wird ja :auf eine zweite Tabelle zugegriffen, nämlich Ware. Bitte kurzes Feedback und dann wieder den Text hier löschen. Vielen Dank!"

Meine Antwort dazu: Der Tablellennamen müssen hier nicht angegeben werden, weil die Spaltennamen im Relationenschema eindeutig sind. Es gibt bei "Bezeichnung" z.B. nur in "Ware" --Miwi 01:40, 6. Nov. 2006 (CET)

Kreuzprodukt

"Wenn alle Merkmale (Spalten) verschieden sind, so umfasst die Resultatstabelle die Summe der Merkmale der Ausgangstabellen."

Ist meiner Meinung nach ein irreführender Satz. Beim kartesischen Produkt sollte doch die Anzahl Spalten des Resultats auf jeden Fall der addierten Spaltenanzahl der beiden Tabellen entsprechen. Jedenfalls ist das in SQL der Fall und aus mathematischer Sicht eigentlich auch anzunehmen. Andererseits meint die englische Ausgabe, dass das kartesische Produkt auf Sätze mit gleichen Attributen gar nicht erst anwendbar sei.

Transitive Huelle

Hallo allerseits,

seit SQL 99 ist es moeglich rekursive Anfragen zu stellen. Ich konnte aber nicht herausfinden, wie die Relationale Algebra erweitert wurde, um diese Anfragen zu ermoeglichen. Die plausibelste Quelle schien mir von R. Agrawal zu kommen: Alpha: An Extension of Relational Algebra to Express a Class of Recursive Queries, Found in: IEEE, Transactions on Software Engineering, By R. Agrawal. Ist dies eine geeignete Quelle zum Thema?

Vielleicht kann auch jemand den Artikel entsprechend erweitern? Danke -- sparti 20:25, 29. Jan. 2007 (CET)

Quotienten from outer Space

Hallo !

|<------------------------------- soooon Hals hab ich ! ---------------------------------------->|

Wo zum Geier sind die volkstümlichen Minuszeichen in der RA definiert, wie sie in der Definition (Grafik) der Division (und auch der Umbenennung) stehen? Sollte das vielleicht der oben definierte Backslash "\" sein ? Wenn ich mal ein Link auf unseren Sportverein in Wikipedia setz, dann ist der nach spätestens 5 Minuten wieder rausgekickt, aber son Schrott überdauert hier die Jahrzehnte! Querlesen geht beim Kloheftchen, nicht in mathematischen Abhandlungen! --Racksatte 11:25, 7. Mär. 2008 (CET)

Was ist denn das für ein beleidigender und unqualifizierter Beitrag?

"Minus" also: - oder "Slash" bzw. mathematisches "ohne" also: \ bedeuten ein und das selbe. Oft schreibt man in der relationalen Algebra "-" anstatt "\" für die Mengendifferenz. Aber eigentlich ist in der Mathematik UND Informatik für die Mengendifferenz nur das "ohne"-Zeichen "\" üblich. Eine Mengendifferenz ist nicht ganz kanonisch mit einem Minus erklärbar. (nicht signierter Beitrag von 138.246.2.135 (Diskussion) 14:48, 3. Dez. 2011 (CET))

Duplikatelemination in Projektion

Hallo,

ich bereite mich gerade auf die Klausur in DBS1 an der LMU München (Fachrichtung: Diplom-Informatik) vor. Mir ist aufgefallen, dass unserer Skript und auch Bücher wie z.B. Datenbanksysteme - Eine Einführung A.Kemper/A.Eickler bei der Projektion eine Duplikatelemination definieren. Im Artikel wird keine definiert. Wird diese Elimination aus einem bestimmten Grund erwähnt/nicht erwähnt?

Viele Grüße Christoph

Komisches Latex

Warum wird hier beim Join überall dierser Kram: \triangleright\!\!\triangleleft anstatt \bowtie verwendet?

mfg

Komischer Artikel

Sehr schwer verständlich geschrieben. Vllt. sollte man mal jemanden ranlassen, der kein Mathe-Freak ist. (nicht signierter Beitrag von 193.174.83.97 (Diskussion | Beiträge) 15:46, 5. Jun. 2009 (CEST))

Outer Join nicht teil der Relationalen Algebra

Ein Outer Join ist doch nicht durch die relationale Algebra abbildbar? Laut dem Buch Elmasri - "Grundlagen von Datenbanksystemen" (2002) Seite 256ff sind Aggregatsfunktionen, Gruppierungen, Rekursive Abschlussoperationen, Outer-Joins und Outer-Unions nicht teil der relationalen Algebra. Dies sollte man zumindest erwähnen. -- Borlander 09:57, 8. Sep. 2009 (CEST)

Gruppierungsoperator und Aggregatfunktionen

Ein praktisches Beispiel dazu wäre sehr hilfreich, sonst versteht das ja kein Mensch. --BuZZdEE.BuzZ 11:58, 18. Mai 2010 (CEST)

Beispiel zur Umbenennung

Ich hätte mir gewünscht der Artikel wäre in sich etwas konsistenter. Beispielsweise wird der Umbenennung die lineare Schreibweise

linear R[alt→neu]

eingeführt, dann im Beispiel direkt darunter werden neu und alt vertauscht und der Pfeil umgedreht. Das sind Kleinigkeiten, jedoch sieht der Artikel dadurch etwas inkonsistent aus und kann Leser (wie mich) verwirren. (nicht signierter Beitrag von 130.83.161.65 (Diskussion) 16:00, 6. Sep. 2010 (CEST))

Zeichen fehlen

wie bspw. ⋊ ⋉ ⋊ ⋈ sollten zumindest kurz erläutert werden.--77.4.83.96 17:53, 29. Dez. 2011 (CET)

Literatur

Ich glaube nicht, dass dieser Andreas Heuer "Datenbanken: Konzepte und Sprachen" geschrieben hat. Sondern es handelt sich um Prof. Andreas Heuer von der Universität Rostock https://dbis.informatik.uni-rostock.de/mitarbeiter/heuer/. Der Link muss demnach entfernt werden.