Diskussion:Relationale Datenbank

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Relationale Datenbank“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit oder --~~~~.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Einführung

Die Einführung ist leider gar nicht gelungen und erklärt einen Fachbegriff mit dem selben Fachbegriff: „Eine relationale Datenbank dient zur elektronischen Datenverwaltung in Computersystemen und beruht auf dem relationalen Datenbankmodell.“ (nicht signierter Beitrag von Anfahrer (Diskussion | Beiträge) 16:18, 22. Sep. 2011 (CEST))

Vorschlag für diesen Teil der Einleitung:

"Eine relationale Datenbank zeichnet sich durch ihre eindeutigen Bezeihungen zwischen unterschiedlichen Datenmengen aus. Diese Beziehungen weden durch Schlüssel gekennzeichnet. Die Datenbank Engine ist in der Lage diese Schlüssel und den dadurch beschriebenen Verbindunegn zu folgen und diese aufzulösen."

Tabellarische Organisation der Daten ist eine Konvention die sich bis heute gehalten hat, jedoch kein Muss für Relationalität. Daher habe ich, und würde ich, in der Einleitung auf diesen Begriff verzichten. (nicht signierter Beitrag von OliverMX (Diskussion | Beiträge) 20:30, 6. Dez. 2015 (CET))

Grundlegende Konzepte

Folgender Satz macht hier keinen Sinn: "Als Schlüssel nimmt man hier die Attributmenge (Nutzernummer, Buchnummer)." Das würde ja bedeuten, dass jedes Buch an jeden Nutzer zur gleichen Zeit ein mal verliehen werden kann ... ?! Mein Vorschlag: "Als Schlüssel nimmt man hier das Attribut Buchnummer." Das heißt dann, dass jedes Buch zur gleichen Zeit nur ein mal ausgeliehen werden kann. Jeder Nutzer kann alle Bücher ausleihen, die gerade nicht an einen anderen Nutzer verliehen sind (was in einer Bücherei mit Printmedien ja durchaus sinn macht). Grüße, Ralf

Transitive Huelle

Zunächst einmal Lob für die Überarbeitung! Die Mühe hat sich sehr gelohnt. Als kleinen Beitrag habe ich noch den Nachteil "keine transitive Hülle berechenbar" rausgenommen. Natürlich lässt sich die transitive Hülle, z.B. eines Mitarbeiters berechnen. Wäre das nicht möglich, würden z.B. ERP-Systeme nicht mit RDBMS arbeiten - es gäbe u.a. keine Stücklisten. Gruß --EFR 09:13, 26. Jan. 2007 (CET)

Hallo Frank,

Ich bin mir nicht sicher, ob das Problem mit der transitiven Huelle nicht doch besteht. Rekursive Anfragen sind durch SQL 95 oder frueher nicht moeglich. Ich meine mich zu entsinnen, dass sie auch durch die Relationale Algebra nicht abgedeckt werden.

Traditionel wird das Problem in der Applikation geloest.

Wenn, dann laesst sich das die Huelle nur mit neueren SQL Standards berechnen, mit dieser grauenhaften rekursiv Anfrage. Ausnahmen sind natuerlich noch proprietaere Erweiterungen, wie sie Oracle bietet.

Also meiner Ansicht nach sollte der Absatz wieder in den Text, oder habe ich da irgendwas falsch verstanden? Gruss -- sparti 10:20, 27. Jan. 2007 (CET)

Hallo Sparti,

Du hast völlig Recht, die transitive Hülle lässt sich nicht mit reationaler Algebra bzw. Standard-SQL bestimmen. Unrichtig ist, dass dies ein Nachteil relationaler DBMS ist. Die Nutzung funktionaler bzw. prozeduraler Sprachen ist für RDBMS ja nicht verboten, wie wir wissen ;). Der Absatz gehört also (wenn überhaupt?) in das Lemma Relationale Algebra und nicht unter den Absatz Kritik am relationalen Datenbankmodell. Das Beispiel Vorgesetzte ist ja dann auch das Beispiel für die Modellierung transitiver Beziehungen bei der Datenmodellierung - nach dem Motto: So geht's. Gruß --EFR 14:15, 28. Jan. 2007 (CET)

Naja, ich denke schon, dass es ein Nachteil der Relationalen Datenbank ist. Bei Wahl eines anderen Datenbankmodelles - das nicht auf der Relationalen Algebra basiert - habe ich das Problem nicht!?

Und natuerlich, einen Workaround findet man fast immer, aber der ist in diesem Fall nicht nur etwas umstaendlicher, sondern auch weniger Effizient, da ich mehere Anfragen benoetige.

Also wir sollten diesen Umstand zumindest erwaehnen. Ich schlage vor, ein Unterkaptiel "Beschraenkungen der Relationalen Algebra" in die Theorie relationaler Datenbanken einfzufuegen.

Waere das fuer Dich ok? -- sparti 15:50, 28. Jan. 2007 (CET)

Ich bin wirklich neugierig, wie sich transitive Beziehungen und deren Abfragen besser in hierarchischen oder netzwerkartigen DB-Modellen modellieren oder abfragen lassen (Methode in OODB gilt nicht, wenn sie imperativ definiert werden muss, dass wäre ja auch ein "Workaround"). Die Effizienz kann tatsächlich bei der Hüllenbestimmung über viele transitive Abhängigkeiten in einer großen Grundmenge ein Problem sein - wäre es das nicht aber auch bei anderen DBMS? Zumindest von hierarchischen DB her kann ich das aus eigener Erfahrung bejahen (große Stücklisten bei ERP-Auswertungen).

Wenn der theoretischen Informatik mit dem vorgeschlagenen Unterkapitel genüge getan wird, ist das absolut i.O. für mich. Als Kritik an RDBMS ist es mMn gegenüber den anderen Punkten halt ein eher theoretisches Argument. Freundlicher Gruß --EFR 09:34, 29. Jan. 2007 (CET)

Naja, als ich meinte, dass es Datenbankmodelle gibt, die es besser machen, hatte ich kein konkretes Modell im Auge. Aber theoretisch waere man ja in der Lage eines zu definieren, das diesen Nachteil vermeidet.

Hmm, im Grunde genommen verstehe ich auch nicht, warum man die Berechnung der Transitiven Huelle nicht als Operation der Relationalen Algebra aufgenommen hat. Seit SQL-99 gibt es ja nun die Moeglichkeit deklarativ rekursive Anfragen zu stellen. Wie vereinbart sich das mit der Relationalen Algebra, wurde die hierfuer erweitert? Oder handelt es sich dabei eben nur um einen "Workaround", der aber im DBMS stattfindet? Gruss -- sparti 10:00, 29. Jan. 2007 (CET)

Wie man rekursive Abfragen in SQL2 mit der relationalen Algebra vereinbart? Gar nicht - hat man auch nicht nötig. ;) Denk doch z.B. mal an ein GROUP BY - immerhin von Anfang an im Standard. Da gibt es auch keine Entsprechung in der relationalen Algebra, und keinen stört's. Die relationale Algebra gab ja auch nur den Anstoß für RDMS, ist aber nicht deren Dogma. Aber ich schweife ab. Wie gesagt würde es mich nicht stören, wenn Du unsere Diskussionspunkte in ein Unterkapitel "Beschränkungen der relationalen Algebra" einbringen würdest. Ich selbst würde dies aber eher im Lemma Relationale Algebra abhandeln. Gruß --EFR 10:30, 29. Jan. 2007 (CET)

Ok, Danke. Ich hab nur Interesse halber gefragt :) Ich werd bei Gelegenheit was dazu schreiben. Viele Gruesse -- sparti 13:35, 29. Jan. 2007 (CET)

Übersicht über die verschiedenen am Markt verfügbaren relationalen Datenbanken

Ich finde, auf diese Seite gehört auch eine kurze Bewertung der verschiedenen am Markt verfügbaren relationalen Datenbanken, deren Stärken und Schwächen, Einsatzgebiete, Lizenskosten, Marktanteile. Ich habe dazu einige Infos, die ich gerne im Wiki eintragen würde. Oder gibt es das schon an einer anderen Stelle? 16. Feb. 2007

Ich finde die Idee nachvollziehbar und lobenswert, fürchte aber, dass das ein frustrierendes und undurchführbares Unterfangen wird. Zum einen werden erfahrungsgemäß Edit-Kriege toben, weil der Vergleich unzählige Personen veranlassen wird, ihr Lieblingsprodukt immer wieder ins beste Licht zu rücken. Zum anderen wird es nicht möglich sein, die Informationen vollständig ohne Rechteverletzung zusammenzutragen. Lizenzkosten bei Oracle sind z.B. vertraulich (diese Vereinbarung gehört zum Distributionsvertrag) und aktuelle Markanteile aus objektiven (bezahlten) Quellen dürfen meiner Kenntnis nach nicht einfach in Wikipedia eingetragen werden.

Aber der entscheidende Punkt wird wohl die Bewertung sein. Es gibt eine Liste der Datenbankmanagementsysteme und Versuche, dort Bewertungen einzutragen werden regelmäßig gelöscht. --EFR 17:21, 16. Feb. 2007 (CET)

Danke für den Hinweis. Diese Seite hatte ich noch gar nicht entdeckt. Warum trägst du diese Seite nicht als Link hier ein oder als Link unter "Siehe auch"? 17. Feb. 2007

Eine "Bewertung" der verschiedenen DBMS würde ich nicht machen. Das ist zu subjektiv. Es reicht IMO, wenn in den einzelnen DBMS-Artikeln die Eigenschaften genannt werden. --Kurt Seebauer 22:58, 18. Feb. 2007 (CET)

Lemma

Sollte man den Artikel nicht in Relationales Datenbankmodell umbenennen, um den Namen an die der anderen Artikel anzugleichen?

Diese Artikel habe ich gefunden, die auf "-datenbankmodell" enden:

• Datenbankmodell
• Hierarchisches Datenbankmodell
• Netzwerkdatenbankmodell
• Objektorientiertes Datenbankmodell

--L'ottimo 20:36, 16. Apr. 2007 (CEST)

Nein, der Artikel behandelt tatsaechlich Relationale Datenbanksysteme als Hauptlemma. Dazu gehoert mehr als die Beschreibung des Datenbankmodelles, wie zB das Datenbankmanagementsystem, die Schema Erzeugung oder auch nur Transaktionen, Anfrageoptimierung, etc. Das Problem bei den anderen Datenbankmodellen ist doch, dass es heute kaum noch oder noch keine entsprechenden Datenbanksysteme mit messbarer Bedeutung gibt. -- sparti 20:56, 16. Apr. 2007 (CEST)

Relationenschema

In der Grafik taucht der Begriff "Relationenschema" auf. Er wird jedoch nirgendwo anders benutzt und es fehlt auch der Link zum entsprechenden Artikel Relationenschema.

Habs hinzugefuegt. -- sparti 21:28, 22. Mai 2007 (CEST)

Einleitungssatz

Eine relationale Datenbank ist eine Datenbank, die auf dem relationalen Datenbankmodell basiert.

Dieser Einleitungssatz ist doch ein Witz, oder? --Jazzman KuKa 01:25, 20. Jun. 2007 (CEST)

Nein absolut nicht. Warum solte es einer sein? -- sparti 08:10, 20. Jun. 2007 (CEST)

Dieser Satz ist eine Redundanz. Genausogut könnte man als Einleitungssatz von Kampf um Gaza schreiben: "Der Kampf um Gaza ist der Kampf, der um die Stadt Gaza stattfindet.". Beides ist im Grunde keine erklärende Information sondern eine Umformulierung. Gerade etwas für Laien so unverständliches wie eine Datenbankarchitektur sollte meiner Meinung nach im Einleitungssatz anschaulich beschrieben werden. --Jazzman KuKa 11:00, 20. Jun. 2007 (CEST)

Also es gibt eine Menge anschaulicher Informationen weiter unten. Oben sollte aber eine möglichst korrekte Defintion sein.

Redundant ist das übrigens keines Wegs. Dein Beispiel hinkt nämlich. Ein Kampf ist nämlich immer gleich, egal ob er in Gaza oder in Timbuktu stattfindet. Der wichtige Unterschied ist allenfalls, wer dort gegen wen gekämpft hat. Eine Datenbank nach dem Relationalen Modell ist aber deutlich von einer mit Netzwerkmodell verschieden. Dein Beispiel müßte also heißen ein "Häuserkampf ist ein Kampf der in Städten ausgetragen wird". Das ist aber in meinen Augen eine sinnvolle Information.

Redudanz gibt es übrigens nur, wenn man in diesem Artikel erneut erklärt was eine Datenbank ist. Dazu müsste ich nur den Datenbank Artikel hierher kopieren. Wem ist damit gedient? Doch nur dem der keinen Link klicken kann.

Trotzdem verstehe ich Dein Anliegen. Ich werde mir überlegen, wie man den Unterschied oben deutlicher hervorhebt. -- sparti 11:27, 20. Jun. 2007 (CEST)

Objektorientierte Datenbanken

Die einfachere Verwaltung komplexerer Objekte bringt aber auch einen Performance-Verlust mit sich. 

Stimmt dieser Satz? Mir kommt es so vor als wäre die Verwaltung nicht einfacher sondern schwieriger. -- 81.7.200.82 11:33, 18. Jul. 2007 (CEST)

Es ist tatsächlich viel leichter Objekte mit einer objektorientierter Datenbank persistent zu halten (sofern man denn auch objektorientiert programmiert *g*). Was ich mich frage ist, warum hier die Behauptung aufgestellt wird das dies einen Performance-Verlust bedeuten würde? Eher umgekehrt wird ein Schuh draus - schließlich fällt das ganze OR-Mapping weg und dadurch hat man sogar noch einen Performancegewinn. Mir fällt kein Beispiel ein in dem das anders wäre.

Florian Sening 13:42, 18. Jul. 2007 (CEST)

Also der Performance Nachteil bezieht sich natürlich nur auf die Datenbank und kann im Einzelfall erheblich sein. Man Beachte, daß ein Aufändiges OR-Mapping nicht immer nötig sein muß.

Man bedenke aber die Probleme die eine OODB zu lösen hat: Objekt Größe kann stark variieren -> Speichermangement. Die Daten zu einem Objekt liegen jetzt örtlich verteilt. Statt viele Datenobjekte mit einem IO Zugriff lesen zu können müssen jetzt sogar mehere IO Zugriff für ein Objekte durchgeführt werden. Weiterhin, muss die Datenbank komplexe Objektbeziehungen auflösen. Ein Thema dabei ist auch Vererbung die von der Datenbank erkannt und bei einer Anfrage aufgelöst werden -> Daten haben noch geringerer Lokalität. -- sparti 14:17, 18. Jul. 2007 (CEST)

Hmm. Vielleicht sollte man den Satz umformulieren - ich finde das extrem unverständlich. Was das I/O angeht - ist denke das ist kein Problem, klar gibts da einige Sachen auf die man achten muss, aber durch den fehlenden OR-Overhead geht das doch locker. Das mit den vielen Datenobjekten auf einmal lesen ... ich weiß nicht ganz worauf du hinaus willst, das macht die relationale DB doch auch nicht anders?

Florian Sening 16:38, 18. Jul. 2007 (CEST)

Bei Datenbank Implementierung ist die CPU oft nicht das Bottleneck, sondern die IO, daher ist IO ein Schlüsselindikator für eine gute Datenbankperformance. Was eine darüberliegende Applikation tut, ist dafür zunächst mal unerheblich, da nicht alle Applikationen ein OR-Mapping brauchen. Und ob der OR-Overhead da größer ist, ist eine sehr gewagte Behauptung: Eine IO Operation führt zu meheren 100.000 Takten Wartezeit bei der CPU. In der Zeit kann man schnell mal ein bischen Mappen. -- sparti 17:33, 18. Jul. 2007 (CEST)

Dann bedeutet der Satz also, dass die Verwaltung komplexerer Objekte für den Benutzer einfacher wird, diese bedeuten aber für die Datenbank mehr Aufwand und dadurch entsteht dann der Performance-Verlust. Oder? Zuerst hatte ich es nämlich so verstanden, dass die einfachere Verwaltung die Datenbank betrifft. -- 81.7.200.82 11:45, 19. Jul. 2007 (CEST)

Ich habe es etwas angepasst. Ist es besser so? -- sparti 12:54, 19. Jul. 2007 (CEST)

Der vereinfachte Zugriff auf komplexe Objekte bringt aber einen Performance-Verlust, durch eine schlechtere Lokalität der Daten, mit sich.

Also - mit dem eingeschobenen Zwischensatz finde ich das Ganze sogar noch unverständlicher. Vielleicht kann mir kurz jemand erklären was mit dem Satz eigentlich ausgedrückt werden soll? Und was ist das Problem mit der Lokalität? Ich hab schon oben nicht verstanden wo da das Problem sein soll.

Warum kann die Objektgröße stark variieren? Meinst du damit Objekte des gleichen Typs oder was? Gemappt in ein RDBMS sieht das doch mit der Größe auch nicht anders aus? Ob ich die Daten jetzt hier oder da halte hat doch auf mein Speichermanagement keinen Einfluß, oder?

Was meinst du damit das die Daten jetzt "örtlich" verteilt liegen? Wie liegen sie denn in einem RDBMS? Anders? Warum man nicht mehr mehrere "Objekte" auf eine Rutsch lesen kann ist mir auch nicht klar. Es sind mehr I/O-Zugriffe notwending? Warum denn?

Und warum muss die Datenbank komplexe Objektbeziehungen auflösen? Warum komplex? Und was hat die DB damit zu schaffen?

-- Florian Sening 13:13, 24. Jul. 2007 (CEST)

Hmm, ich habe jetzt versucht nochmal die Quelle für meine Behauptungen zu finden. Leider ist unter dem vielen (zum Teil sicherlich berechtigtem) Lob schwierig kritische Stimmen zu finden. Einzige Quelle, die auf Performance Probleme hindeutet ist diese hier: http://www.aifb.uni-karlsruhe.de/Lehrangebot/Winter2001-02/IWM/download/folien/folien054in1.pdf. Dort gibt es einen Hinweis auf Probleme mit großen Datenmengen. Und allein darum geht es ja, wenn die IO zum Bottleneck wird.

Ich gebe Dir aber auch recht, daß man beim Speichern komplexer Objekthierarchien ähnliche Effekte bei einer Relationalen Datenbank feststellen wird. Also daß zumindest einige Probleme weniger an der Technik sondern eher in der Struktur der Daten zu suchen ist.

Bis ich eine bessere Quelle gefunden habe, werde ich meine Behauptung im Text auf große Datenmengen reduzieren. -- sparti 09:23, 25. Jul. 2007 (CEST)

Ja. So ist das schon viel verständlicher. Super! Was die vorherigen Versionen dieses Satzes ausdrücken sollten ist mir aber nach wie vor unklar. ;)

Die Quelle ist nicht schlecht, allerdings habe ich das Gefühl das Objekte völlig falsch verstanden werden (vielleicht auch von mir).

Viele Dienste relationaler DBMS (Sichtenbildung, Schemaevolution, deklarative Anfragesprachen, Konsistenzbedingungen, Rechte, Tuning) nicht oder nur ansatzweise gegeben

Ein Objekt kapselt Daten und Zugriff. So etwas darf es demnach gar nicht geben.

Enge Verknüpfung von DB-Schema und Anwendung führt oft zu Inflexibilität

Den verstehe ich auch nicht. Es gibt kein Schema. Es gibt nur Objekte. Also, worum geht's?

Mangels entsprechender polymorpher Operatoren keine flexible Neuverbindung der Daten (z.B. durch Join) möglich, Verknüpfung nur entlang der im Schema festgelegten Beziehungen

Wie bei den anderen Punkten auch. Es handelt sich nicht um ein relationales System aus dem Aussagen abgeleitet werden - man arbeitet mit den Objekten wie sie existieren.

Mal die Frage in den Raum gestellt - ganz besonders auch an dich, sparti ... Kann es sein das hier versucht wird OODBMS wie RDBMS zu verwenden? So kommt es mir zumindest vor.

--Florian Sening 17:46, 25. Jul. 2007 (CEST)

Einleitung

Benutzer Sparti hat den von mir umformulierten Einleitungsabsatz wieder revertiert, mit der Begründung: "Defintion so zu ungenau." Also dann schauen wir mal auf die ursprüngliche (und jetzige) Fassung:

• Eine relationale Datenbank ist eine Datenbank, die auf dem relationalen Datenbankmodell basiert. Das Datenbankmodell wurde von Edgar F. Codd 1970 erstmals vorgeschlagen und ist heute, trotz einiger Kritikpunkte, ein etablierter Standard zum Speichern von Daten.

Meine Fassung:

• Eine relationale Datenbank dient zur elektronischen Datenverwaltung in Computersystemen und beruht auf dem relationalen Datenbankmodell. Dieses wurde 1970 von Edgar F. Codd erstmals vorgeschlagen und ist bis heute, trotz einiger Kritikpunkte, ein etablierter Standard zum Speichern von Daten.

Was bitte sei an meiner Fassung "ungenau"? - Die Definition unterscheidet sich inhaltlich überhaupt nicht und benutzt nur eine flüssigere Sprache. "Elektronische Datenverwaltung" ist genau das, was in Datenbank als deren Zweck angegeben ist. Auch der zusätzliche Verweis auf Computersysteme ergibt Sinn für jene Leser, die nicht schon IT-Spezialisten sind (Stichwort Oma-Test). --Edoe 15:18, 1. Jan. 2008 (CET)

Hallo Edoe, Deine Definition überspringt schlicht, dass eine Relationale Datenbank eine Datenbank ist. Der Hinweis auf EDV und und Computersystem mag einem Laien zwar einen Hinweis gegen, wozu eine Datenbank verwendet wird, dient aber nicht der Definition und ist strenggenommen sogar falsch. Auch ein Karteikasten kann eine Datenbank sein. Der Begriff Datenbank wird im juristischen Sprachgebrauch sogar so verwendet.

Was genau eine Datenbank ist sollte aber im Artikel Datenbank erlaeutert werden, da ein Relationale Datenbank eine spezielle Art der Datenbank ist. Doch auch dort sollten OMA Erläuterungen mit der noetigen Vorsicht eingebracht werden. Erläuterungen für Laien gehören meiner Ansicht nach direkt hinter die Lemma Defintion, aber nicht dort hinein. -- sparti 16:37, 1. Jan. 2008 (CET)

Meine Definition "überspringt" das gleich zwei mal _nicht_: Erstens heisst das Lemma "relationale Datenbank", zweitens verweise ich mit "elektronische Datenverwaltung" genau auf das Lemma Datenbank - und das ist auch genau die dort genannte Definition. Also habe ich schlicht die Wiederholungen heraus gekürzt. Und was "genau" eine Datenbank ist, ist ja dann auch am rechten Platz erklärt. - Der Satz "Eine relationale Datenbank ist eine Datenbank, die auf dem relationalen Datenbankmodell basiert." ist einfach sprachlich daneben. --Edoe 01:16, 3. Jan. 2008 (CET)

Es ist nicht erlaubt Lemmatas mit sich selbst zu definiert und EDV ist keineswegs mit Datenbank gleichsetzbar. Die Wiederholung war bewusst dort platziert und ist wichtig, um klar zustellen, dass eine relationale Datenbank zwar eine Datenbank, aber eben keine gewöhnliche Datenbank ist. Die Definition ist also fachlich und sprachlich korrekt. Siehe dazu auch hier: en:Relational database Und falls dir meine nicht gefällt, dann schau dir doch mal diese hier an [1] :)

Vielleicht finden wir ja einen Kompromiss, in dem wir die Definition einer Relation weiter nach oben ziehen, also das relationale Datenbankmodell etwas früher erläutern? -- sparti 02:43, 3. Jan. 2008 (CET)

Hae? Du kritisierst _meine_ Definition als selbstbezüglich? Und was hat EDV damit zu tun? Datenbank redirected nach Datenbanksystem - und da steht als erster Satz: "Ein Datenbanksystem (DBS) ist ein System zur elektronischen Datenverwaltung." Vielleicht malst du dir einfach mal ein Diagramm, wo a) deine und b) meine Verweise dargestellt sind, zeigst das deinen Kindern/Neffen/Omas/Frauen usw. und fragst sie, welches einfacher ist. ... Klar, "Kompromisse" sind immer möglich, mach mal einen Vorschlag. --Edoe 14:42, 3. Jan. 2008 (CET)

Oje, irgendwie hab ich da Datenverwaltung mit Datenverarbeitung verwechselt. Wenn Du die beiden Begriffe in Deiner Definition austauscht, wirst Du meine Kritik verstehen.

Das ändert aber nichts daran, dass Datenbank Teil der Definition bleiben muss. Wie bereits gesagt ist es nicht ausreichend, dass das Lemma den Hinweis selbst enthält. Genauso wenig ist es sinnvoll die Definitionen von Datenbank hier zu wiederholen.

Die Definition muss aber klar stellen, dass eine relationale Datenbank, die Eigenschaften von Datenbank erbt, jedoch ein spezielles Datenbankmodell verwendet. Von meiner Oma - sofern sie keine IT Expertin ist - erwarte ich übrigens nur, dass sie versteht, dass es um Datenbanken geht.

Als Kompromiss schlage ich vor, analog zu vielen anderen Quellen, Relationale Datenbank als Menge von einfachen Tabellen zu definieren. Nachteil ist, dass diese Definition deutlich schwammiger ist. -- sparti 21:02, 3. Jan. 2008 (CET)

Erstmal ist es keinesfalls Aufgabe eines Lexikons, Begriffe (im möglichst mathematischen Sinne) zu _definieren_, sondern zu _erklären_. Und zwar möglichst gut. Dass eine "relationale Datenbank" auch eine "Datenbank" ist, das ergibt sich aus dem Begriff ganz trivial. Dann _habe_ ja bereits den Verweis auf Datenbank bei mir drin, nur eben mit der dort zu findenden Erklärung, dass es eben ein "System zur elektronischen Datenverwaltung" ist; im übrigen in Computern - beides ist nicht trivial. --Edoe 15:14, 4. Jan. 2008 (CET)

Ok, Du gibst dem Kind einen anderen Namen damit es verständlicher wird - gleichzeitig sagst Du aber es ist intuitiv klar, dass eine Relationale Datenbank eine Datenbank sei - ähnlich wie ein Hubkolbenmotor ein Motor ist. Dort scheint die Wiederholung aber niemanden zu stören. Ich bin der Meinung, dass die meissten Leute beide Datenbankbegriffe synonym verwenden und nur deswegen kommt ihnen die Definition komisch vor. Aber dass eine Relationale Datenbank eine Datenbank ist, ist nicht trivial, auch wenn es trivial klingt. Unser Anliegen sollte es sein, genau diesen Punkt klar rauszuarbeiten. --

Hmm, und den Verweis auf "Datenbank" mit "elektronische Datenverwaltung" zu benennen, das reicht dir nicht? - Dann mach doch mal bitte einen Vorschlag, damit das wenigstens nicht direkt hintereinander steht, so klingt das einfach billig. Vielleicht in einem zweiten Satz "Wie jede Datenbank ...". Und dass es mit Computersystemen und der Speicherung von Daten zu tun hat, darf auch dabei stehen. --Edoe 19:52, 6. Jan. 2008 (CET)

Also ich persönlich kann nicht verstehen warum hier etwas billig sein soll, das woanders akzeptiert ist. Aber wenn es dir so wichtig ist, dann ändere es. Meine Hauptkritik bezog sich auf die EDV und das hat sich ja geklärt. Gruss -- sparti 14:38, 7. Jan. 2008 (CET)

Ok, habe mal versucht, unsere Diskussion umzusetzen. - Zu deinem Edit noch eine Frage: Warum ist "am meisten genutzte Standard" ein POV? Es ist eine Faktenbehauptung, die entweder stimmt oder nicht. Meinst du sie stimmt nicht? --Edoe 23:12, 11. Jan. 2008 (CET)

Ich stimme dir persönlich zu, dass es stimmt. Aber der Superlativ muss eigentlich immer durch externe Quellen belegt werden. Man könnte z.B. leicht argumentieren, dass Objektrelationale Datenbanken dabei sind diesen Standard abzulösen. Dann kommt aber schnell auf eine sehr dünne Faktenlage. Daher sollten wir extreme Behauptungen einfach vermeiden, dann sind wir auf der sicheren Seite und haben keinen Aerger mit Quellen. Etwas anders läge der Fall, wenn Du eine zuverlässige Quelle zu deiner Behauptung zitieren könntest. Ich vermute aber mal, dass du (genauso wie ich) keinen Beleg dafür hast. -- sparti 23:32, 11. Jan. 2008 (CET)

Gut, lassen wir mal den Superlativ. Das "objekt-relational" ist im übrigen IMHO eine reine Marketingformel, während diese Funktionen von 99,5% der Anwender nicht benutzt werden. --Edoe 14:56, 13. Jan. 2008 (CET)

Leicht OT: Artikel zur gerne verwendeten falschen Bezeichnung "rationale Datenbank"

Hallo!

Ich überlege, ob es Sinn macht der "rationalen Datenbank" einen eigenen Artikel zu widmen, der sagt, dass das "relationale Datenbank" heißt. Hintergrund ist die Tatsache, dass sehr häufig der falsche Begriff verwendet wird. (Ich habe z.B. inzwischen 3 Stellennanzeigen gesehen, in denen es falsch stand). Eine kurze Suche auf einer bekannten Suchmaschine fördert ebenfalls erschreckendes zu Tage (z.B. Fachartikel in denen von "rationalen Datenbanken" die Rede ist). Ein solcher Wikipedia-Artikel weit oben in den Suchergebnissen könnte einige vielleicht auf ihren Fehler aufmerksam machen.

Was haltet ihr davon?

rstevens

Das widerspricht leider dem Konzept einer Enzyklopädie. Wenn dann gehört das als Hinweis in den Artikel Relationale Datenbank hinhein. Mir stellt sich dabei aber spontan die Frage, woher du die Gewissheit nimmst, dass "Relationalen Datenbank" immer falsch ist. Ist das nicht nicht legitime Verwendung im Genitiv und Plural? -- sparti 01:25, 3. Mai 2008 (CEST)

Ich meinte "rationale Datenbank" nicht "relationale Datenbank"! Aber, wenn das nicht zum Konzept passt, dann wäre ggf. ja ein Hinweis ok, oder? -- rstevens

Ups, hab gestern Abend nicht mehr so genau hingesehen. Ich hab "Rationale Datenbank" noch nie gehört. Ja, ggf ein Hinweis. -- sparti 20:30, 3. Mai 2008 (CEST)

Gibt es ja auch nicht, aber gib es mal bei Google ein, da staunt man wie viele das falsch machen! -- rstevens 20:00, 11. Mai 2008 (CEST)

Das Verhältnis falsch/richtig ist 290/46300. Also eine ziemlich unbedeutende Falschschreibungen, wie ich finde. Gruß -- Talaris 21:52, 11. Mai 2008 (CEST)

Beziehungen zwischen Tabellen / Relationen

zu Hier sollte Relation nur im mathematischen Sinne benutzt werden

hi sparti, dann sollte man noch irgendwie erklären, warum die tabellen "relationen" heißen. bzw. was "relational" bedeutet. ich finde so ein artikel sollte auch für nichtinformatiker einen informationswert haben, was zur zeit nichtgegeben ist, denn das lemma wird im grunde nicht erklärt. um es gleich vorweg zu nehmen: bitte nicht fachchinesisch mit fachchinesisch erklären... equa 18:35, 26. Aug. 2008 (CEST)

Hallo Equa,

in der Einleitung wird der Zusammenhang zwischen Tabelle und Relation bereits erklaert und wie ich finde recht verstaendlich. Ich glaube uebrigens, dass man es nicht allen recht machen kann. Vorallem ist eine bessere Verstaendlichkeit kein Grund fuer Ungenauigkeiten. Es gibt bereits heute zuviele Fachleute, die nicht erklaeren koennen, woher der Begriff Relationale Datenbank kommt, dem muessen wir nicht noch vorschub leisten. -- sparti 23:41, 26. Aug. 2008 (CEST)

Verlinkung

Suchfunktion : "RDM" diese Seite verlinken! (Abkürzung) (nicht signierter Beitrag von Dionysos85 (Diskussion | Beiträge) 17:08, 18. Mai 2009 (CEST))

Einleitung

Es ist falsch, dass Codd an der Entwicklung von SQL mitgearbeitet hat. Er ist im Gegenteil ein starker Gegner von SQL. Möglicherweise ist dieses ein Folgefehler des Wikipedia-Artikels zu SQL: "Die Bezeichnung leitet sich von dem Vorgänger SEQUEL ([ˈsiːkwəl], Structured English Query Language) ab, der von IBM in den 1970er Jahren auf der Grundlage des Artikels „A Relational Model of Data for Large Shared Data Banks“ (1970) von Edgar F. Codd entworfen wurde." In diesem Satz bezieht sich "von Edgar F. Codd entworfen wurde" auf den Artikel "A Relational ..." und nicht auf "SEQUEL". Mein Vorschlag: Streichung des Nebensatzes.

Günter Matthiessen --84.128.208.248 17:35, 18. Sep. 2009 (CEST)

WP:SM. Gruß --Euku:^⇄ 19:18, 18. Sep. 2009 (CEST)

Artikel erklärt nicht was relationale Datenbanken sind!

Es ist nötig diesen Artikel zu überarbeiten. Relationale Datenbanken zu erklären in dem man schreibt:"Relationale Datenbanken sind relationale Datenbanken", macht keinen Sinn. Ihr solltet mal jemanden von der Straße holen der nichts mit der Sache zu tun hat und wenn Ihr dem diese Sache mit diesem Artikel erklären könnt, habt Ihr das Ziel dieses Angebots erreicht.

MFG Jan Girke 12:14, 27. Jan. 2010 (CET) (ohne Benutzername signierter Beitrag von 79.193.165.106 (Diskussion | Beiträge) )

WP:Sei mutig, weil "ihr" inkludiert auch dich. --Sebastian.Dietrich 21:50, 27. Jan. 2010 (CET)

Das steht dort auch nicht. Wer lesen kann ist klar im Vorteil. -- 84.160.238.151 01:03, 20. Mär. 2010 (CET)

Ist das wirklich so schwer zu erklären?

Eine relationale Datenbank ist eine Form der Datenverwaltung bei der die Informationen auf mehrere Tabellen (Relationen genannt) verteilt werden, um redundante Daten in eigene Tabellen auslagern zu können. Als Beispiel kann man sich eine Adressliste vorstellen, individuelle Angaben wie der Namen oder die Straße mit Hausnummer stehen zusammen in einer Tabelle, gemeinsame Merkmale mehrerer Einträge, wie etwa der Wohnort, in einer anderen Tabelle (man nennt das Normalisation). Jeder Eintrag in einer Tabelle hat einen Primärschlüssel, mit dem ein Eintrag eindeutig identifiziert wird. Bei der Verknüpfung von zwei Tabellen (ebenfalls Relation genannt) wird der Primärschlüssel der einen Tabelle als Fremdschlüssel in der anderen Tabelle verwendet. Auf die Adressliste bezogen heisst das, in der Tabelle mit den Namen wird nicht der Wohnort gespeichert sondern der Primärschlüssel aus der Tabelle mit den Wohnorten (in der Tabelle mit den Namen wird er aber zum Fremdschlüssel). Diese Vorgehensweise vermeidet z. Bsp. Unklarheiten durch unterschiedliche Schreibweisen, da in der Tabelle mit den Wohnorten jeder Ort mit nur einem Eintrag vertreten ist, es kann dann nicht passieren, dass in einer Adressliste unterschiedliche Angaben auftauchen, wie z. Bsp. "Frankfurt", "Frankfurt am Main", "Frankfurt a. M.", "Frankfurt/Main" oder "Ffm". Das Datenbankdesign hilft auch beim Abfragen von Einträgen, statt eine Tabelle mit 100.000 Namen zu durchsuchen, um festzustellen, wer in einem bestimmten Ort wohnt, kann man auch erst einmal überprüfen, ob in der Tabelle mit 1.000 Orten der gesuchte Ort überhaupt enthalten ist. (nicht signierter Beitrag von 46.114.156.237 (Diskussion) 11:41, 9. Apr. 2014 (CEST))

Danke, das hat mir viel Zeit gespart! So wird auch diese Einleitung verständlicher. H. de Groot (Diskussion) 17:39, 18. Mär. 2018 (CET)

"Gegenüberstellung von Grundbegriffen"

Aus meiner Sicht stimmen diese Begriffe so nicht überein bzw. nur sehr entfernt oder mit Einschränkungen.

Beispiele:

- Generell fragwürdig ist die kommentarlose Gegenüberstellung der relationalen und objektorientierten Welt.

- Wo soll der Unterschied sein zwischen "Spalte" und "Spaltenüberschrift"?

-In dieser Zeile:

Spaltenüberschrift(en)	Fremdschlüssel	funktionale Beziehung (Relationship)	Assoziation

Eine Spaltenüberschrift muss nicht notwendigerweise ein Fremdschlüssel (FS) sein. Und für Nicht-FS-Attribute gilt, dass diese im normalisierten Zustand eben keine funktionale Beziehung haben dürfen.

- Die Kopfzeile eine DB-Tabelle ist allenfalls eine Untermenge einer OO-Klasse, da letztere ebenso Methoden beschreibt. Außerdem definiert die Klasse auch Datentypen, Wertebereiche etc., während die Kopfzeile lediglich ein Resultat aus der Tabellendefinition ist, welche ihrerseits die Attribute spezifiziert.

- Bei Beziehungen zwischen Objekten/Entitäten/Relationen ist die OO-Sichtweise eine andere als die relationale. Praktisch heißt dies: Das Objekt kennt seine Kindsobjekte, während die Kindstabelle angibt, auf welche Haupttabelle sie referenziert.

Für Einsteiger in die Thematik ist diese Gegenüberstellung eine ziemliche Fehlanleitung.

Eine Gegenüberstellung mag sinnvoll sein, sollte jedoch etwas ausführlicher und korrekter ausfallen.