Diskussion:Relationale Datenbank

aus Wikipedia, der freien Enzyklopädie

Inhaltsverzeichnis 1 Diverses 2 Modellierung ER-Modell, echt jetzt?? 3 Definition ungenau 4 Schlüssel 5 Auflistung nebst Definition von Begriffen 6 überarbeiten 7 Neue Gestalltung 8 Gliederungsvorschlag für den Datenbankbereich in der Wikipedia

[Bearbeiten] Diverses

--

Objektorientierte Datenbanken haben sich bis heute quasi nicht durchgesetzt. Ich bin dafür, diesen Abschnitt zu überarbeiten. Aktuell sind XML-basierte Datenbanken auf dem Vormarsch (und sind dabei schon weiter als es die OOP-DBs je waren) und sollten erwähnt werden. Macht das jemand?

--

Warum soll relationale Datenbank denn dann etwas besonderes sein? Relationen gibt es doch in jedem Datenbanksystem, sonst wäre ja diese Datenkbanken total unsortiert.

Danke, --Abdull 11:02, 17. Feb 2005 (CET)

Relationale Datenbanken heissen deswegen "Relationale Datenbanken" (mit einem grossen R!), weil sie auf dem sog. Relationalen Datenbankmodell beruhen, das von Edgar F. Codd 1970 erstmals vorgeschlagen wurde; darin ist *Relation* ein im streng mathematischen Sinn wohldefinierter Begriff (terminus technicus), der im wesentlichen ein mathematisches Modell für eine *Tabelle* beschreibt. Mit irgendwelchen "Relationen" d.h. Beziehungen in einem umgangssprachlichen und also unscharfen Sinn hat das rein gar nichts zu tun. Codd kommt das Verdienst zu, als Erster ein wenig mathematische Ordnung in das kreuz und quer verlinkte Chaos der vor-relationalen Tabellen gebracht zu haben. -- Nol Aders 18. Mai 2005

-- Dass das oben besprochene Missverständnis überhaupt auftreten konnte, kommt daher, dass im Artikel steht: "Relational bedeutet etwa: In Verbindung stehend mit etwas." Das ist streng genommen falsch, jedenfalls -- wie exemplum zeigt -- irreführend und missverständlich. Ich werde das wohl korrigieren. -- Nol Aders 18. Mai 2005

---

Als negativer Punkt ist aufgeführt:

* künstliche Schlüsselattribute Zur eindeutigen Identifizierung von Tupeln müssen in manchen Fällen künstliche Schlüssel eingesetzt werden. Diese Schlüsselattribute müssen relationsweit eindeutig sein.

Was ist daran negativ? Autoincrement-Keys sind in fast jedem Fall besser als irgendwelche existierenden Seriennummern. Diese könnten, durch ein neues Nummerierungssystem o.ä. sinnlos werden, müssten also (in allen nötigen Relationen) umgeschrieben werden, während automatische IDs immer klar eindeutig sind. --dVrVm 22:02, 20. Apr 2005 (CEST)

Der ganze Abschnitt "Schwachpunkte der relationalen Modellierung" scheint mir nicht besonders glücklich abgefasst zu sein. Die meisten IT-Leute, die eine Relationale DB einsetzen, wollen gar keine Objekte abspeichern (oder wenn, dann müssen sie nur entscheiden können, welchen Player sie für ihr MP3-BLOB anwerfen sollen, was man ohne weiteres mit einem entsprechenden Attribut in der betreffenden Relation erledigen kann). Also ist aus Sicht der Relationalen Datenbanken, die dieser Artikel ja behandeln soll, Object-to-Relational Mapping kein vordringliches Thema, oder? -- Ich finde: weglassen! -- Nol Aders 18. Mai 2005

Haste schon gemacht, oder? Das Thema ist "persistente Objekte", d.h. Objekte, die nach der Beendigung des Programmes noch da sind. Mit RDBMS muss jedes Objekt eine eigene Methode "store_in_database()" bekommen, die umständlichst das Objekt abspeichert. Deswegen wollen alle weg vom relationalen Modell (vgl. Standardisierungsbemühungen), und deswegen wäre das Thema eine kurze Erwähnung wohl wert. Fragment 14:16, 6. Aug 2005 (CEST)

Etwas anderes ist die Diskussion um die "künstlichen" Schlüssel. Was sind das?? Und warum müssen diese Schlüsselattribute "relationsweit eindeutig" sein? Jeder (Super)Schlüssel, d.h. alle Attribute, die dazugehören, zusammen kombiniert, müssen per definitionem eindeutig sein über die Relation; aber die einzelnen Schlüsselattribute? Falls der Schlüssel aus mehreren Attributen besteht, wird das im Allgemeinen eben gerade nicht so sein, warum wird der Schlüssel sonst aus mehreren Attributen zusammengesetzt?? -- Nol Aders 18. Mai 2005

Nochmals etwas anderes sind Autoincrement-Schlüssel; das ist ein typisches Leistungsmerkmal von Low End Applikationen, Office-Applikationen mit DB-ähnlichen Eigenschaften (MS-Access) u.dgl. -- im professionellen Kontext wird das nicht so gemacht, u.a. wegen der möglichen Probleme bei Restore-from-Backup und anschliessendem Recovery-Restart. -- Nol Aders 18. Mai 2005

--

Künstliche Schlüsselattribute haben per se nichts mit dem relationalen Modell oder gar relationalen Datenbanken zu tun. Man kann sie erwähnen, er handelt sich aber weder um einen Vor- noch einen Nachteil des Konzeptes. Nebenbei gesagt, Object Orientierte DB haben immer künstliche Schlüssel (ich weiß, die Aussage ist etwas vereinfacht) und in diesem Fall stellten sie in der Tat ein Problem dar.

Sollte man nicht neben den Schwachpunkte der relationalen Modellierung auch deren Stärken erwähnen (Einfachheit, Kalküle) ? Andreas75 19:54, 26. Mai 2005 (CEST)

[Bearbeiten] Modellierung ER-Modell, echt jetzt??

Text: "Zur Modellierung von relationalen Datenbanken wird meist das Entity-Relationship-Modell oder Varianten davon verwendet."

Hat schon mal jemand im Ernst das ER-Modell dafür verwendet? Ich verwende eine UML-artige ad-hoc-Notation und habe gleiches bei Leuten gesehen, die damit ihr Geld verdienen. Die Notation kann man zwar als Sonderfall von ER sehen, aber ich würde von mir nicht sagen, dass ich ER benutzt hätte.

Grüße, Fragment 21:34, 8. Okt 2005 (CEST)

Ja, schon. Zum einen ist UML nicht wirklich geeignet zum Abbilden von Datenbankmodellen, da UML z.B. keine Schluessel kennt. Aber insbesondere kenne ich kein Tool, das mir aus UML ein Datenmodell physisch instanziert oder aus einer Datenbank ein UML Modell erzeugt. Und ich verdiene auch mein Geld damit.

Gruss -- sparti 21:56, 8. Okt 2005 (CEST)

Ich finde das Beste auf diesem Gebiet das, was sein Verfasser Hanswalter Buff, Zürich, seinen "ER-Dialekt für Relationale Datenbanken" nennt (Hanswalter Buff: Entity Relationship for Relational Databases). Das ist eine Präzisierung von Chen's ER-Modell derart, dass das grafische Schema direkt Relationen (im Sinne des Relationalen DB-Modells) darstellt. Alle 'Striche' zwischen den Kästchen (Entitätstypen) und Rhomben (Beziehungstypen) sind Pfeile und bedeuten Schlüssel-Fremdschlüssel-Beziehungen. So etwas wie "ER-to-Relational Mapping" wird völlig überflüssig, das ER-Schema ist selbst das Relationale DB-Schema. Wenn man sich an die sechs Regeln (es sind Produktionsregeln) von Buff hält, ist das Ergebnis ein DB-Schema in IDNF (= Inclusion Dependency Normal Form), das ist eine Normalform, die stärker ist als BCNF (= Boyce-Codd Normal Form). So etwas wie Normalisierung wird auch völlig überflüssig, das DB-Schema ist normalisiert 'by design'. (Literatur: Hanswalter Buff: Datenbanktheorie ISBN 3-0344-0201-5) — Nol Aders 02:38, 19. Dez 2005 (CET)

Ich bin in dieses Thema ja nur mäßig involviert, aber mir scheint auch ein ER-Modell (oder ähnliches) die sinnvollste Darstellungsvariante. UML basiert meines Erachtens doch auf Objekten, die, wie im Artikel erwähnt, nicht (zwingend) in Relationen (Datentabellen) abgebildet werden. Somit kann mit der UML auch nicht in jedem Fall ein Modell der Relationen angefertigt werden. Oder hab ich da was nicht verstanden? Wenn man natürlich die Relationen streng als Klassen anlegt würde das wiederum funktionieren. Aber wird das immer getan? 84.188.113.139 12:39, 4. Jan 2006 (CET)

Nun, eigentlich ist es doch egal, womit man die Datenbank spezifiziert. Es gibt formale Wege, Klassendiagamme ins ER-Modell zu überführen und daraus dann den relationalen Entwurf zu generieren, um eine Rel-DB zu erstellen. Wichtig finde ich, daß die gewählte Form der Spezifikation korrekt, vernünftig und nachvollziehbar angewandt wird. Ich verdiene mein Geld mit SW-Verifikation und ich kann sagen, daß es manchmal grausig ist, was man mit formalen Beschreibungssprachen wie UML, ER-M und SA/SD alles anstellen kann, um es anderen unmöglich zu machen, das nachzuvollziehen, was man sich im Schweiße seines Angesichts erdacht hat. Und, was nutzt einem dann noch die beste Spezifikation, wenn die Implementation davon abweicht. --134.169.255.227 15:55, 13. Jan 2006 (CET)

Das hier im Lemma ausführlich über Datenmodellierung diskutiert wird während der Artikel Datenmodellierung und seine Artverwandten noch meiner Meinung nach im Argen liegen zeigt, dass wir im Umfeld Datenbanken wirklich noch viel offen haben. Die obige Diskussion war und ist gut und wichtig, aber für relationale Datenbanksysteme eher uninteressant: die gibt es normalisiert und aus guten Gründen(!) denormalisiert, mit vorheriger Modellierung und oft auch ohne. Und für all diese Themen gibt es im Wiki bereits dutzende von Artikeln, auf die man von hier aus verweisen kann, aber die eben auch von Grund auf aufeinander aufbauen müssen. Da funktioniert es eben schlecht, wenn man - überspitzt ausgedrückt - im Datenmodellierungs-Artikel SQL erklärt und hier die Datenmodellierung. Siehe unten. Gruß --EFR 17:49, 17. Aug 2006 (CEST)

[Bearbeiten] Definition ungenau

In der Defintion steht heute: Eine relationale Datenbank ist eine Datenbank, die auf dem relationalen Datenbankmodell basiert.

Ein Datenbankmodell ist aber die Grundlage fuer ein Datenbanksystem und nicht fuer die Datenbank. Eine Relationale Datenbank enthaelt also nur die Datenstrukturen, fuer ein Relationales Datenbanksystem, das auf dem Relationalen Datenbankmodell basiert.

Sollten nicht die Artikel RDBMS, Relationales Datenbankmodell, Relationale Datenbank unter dem Lemma Relationales Datenbanksystem subsumiert werden?

-- Gruss sparti 14:03, 12. Nov 2005 (CET)

Ich finde, das Haupt-Lemma sollte "Relationale Datenbank" sein. Darin sollte sicher das Relationale DB-Modell beschrieben sein — Leitlinie: SQL-Standard (aber welcher?!). Dann stellt sich die Frage, was hierher und was in den Artikel "SQL" gehört. Weiter stellt sich die Frage, ob es ein weiteres Lemma "Relationales Datenbanksystem" braucht, ich finde nicht. — Nol Aders 02:38, 19. Dez 2005 (CET)

[Bearbeiten] Schlüssel

Es ist ein Attribut zur eindeutigen Identifikation von Entitäten einer oder mehrerer Relationen.

Nach meinem Verständnis ist ein Schlüssel eine Menge von Attributen, die ein Tupel eindeutig bestimmt. Dass die Menge auf ein Element beschränkt sein kann, ist natürlich möglich. --172.177.37.150 14:14, 7. Jun 2006 (CEST)

[Bearbeiten] Auflistung nebst Definition von Begriffen

Ich frage an, ob eine derartige Aufstellung von Begriffen nebst Definitionen wie im vorliegenden Artikel sinnvoll ist, da es zu den meisten Begriffen eigene Artikel gibt. Ich schlage vor, dass der vorliegende Artikel diesbezüglich aufgeräumt wird oder zumindest mit Verweisen auf die anderen Artikel versehen wird. tzeh 09:09, 8. Jun 2006 (CEST)

[Bearbeiten] überarbeiten

Der Artikel ist kaum strukturiert, ausschweifend und gleichzeitig ungenau, statt erklärungen stehen lange definitionslisten. igel+- 00:26, 18. Jun 2006 (CEST)

[Bearbeiten] Neue Gestalltung

Ich habe das Aussehen von "Wichtige Begriffe relationaler Datenbanken" geändert und mit Links auf die Hauptartikel zu den einzelnen Begriffen ergänzt. Spätestens jetzt ist erkennbar, dass der Artikel inhaltlich völlig daneben ist. Ich würde vorschlagen, dass wir uns auf dieser Diskussionsseite auf eine neue Strukturierung des Inhaltes festlegen. Mein Vorschlag:

1. Definition
2. Regeln zur Bildung von Relationen
3. Vorteile und Nachteile der relationalen Modellierung
4. Das übliche (weblinks, Siehe auch, Literatur)

--Kotik 20:28, 10. Aug 2006 (CEST)

[Bearbeiten] Gliederungsvorschlag für den Datenbankbereich in der Wikipedia

Hallo Leute,

da im DB-Bereich in der WP viel Wildwuchs und Redundanz herrscht, habe ich unter Diskussion:Datenbanksystem#Gliederungsvorschlag_f.C3.BCr_den_Datenbankbereich_in_der_Wikipedia mal einen Gliederungsvorschlag gemacht. Ich würde mich über Diskussionsbeiträge, Ermunterung und ein bisschen Hilfe freuen. ;-) Evtl. können wir auch ein Wikiprojekt gründen, um die Zusammenarbeit im DB-Bereich besser zu koordinieren. Wer würde ggf. mitmachen und sich einen Artikel schnappen? Viele Grüße, Kurt seebauer 09:18, 15. Aug 2006 (CEST)

Der Gliederungsvorschlag dort trifft nicht ganz das Grundproblem, das man unter anderem in diesem Artikel sieht: Rund um die Datenbank-Thematik gibt es Themenschichten, die innerhalb der Wikipedia immer wieder durcheinandergewürfelt werden, insbesondere die Schichten:

• Datenbank-Grundlagen allgemein (z.B. Was ist eine DB? Was ist ein DBMS? Was ist eine Abfragesprache? Was ist eine Datenbanksprache? etc. pp.)
• Methoden wie die Datenmodellierung (konzeptionell/fachlich und technisch)
• Techniken in diesem Umfeld
  • relationale Datenbanksysteme
  • ER-Modelle
  • ...

Das wurde und wird nicht sauber getrennt und deshalb gibt es leider sehr viele Fehler ("SQL ist eine Abfragesprache") und Redundanzen (Datenmodellierung für relationale Tabellen wird zig mal behandelt, mal fundiert, mal oberflächlich) und Inkonsistenzen (mal ist ein ER-Modell eine Methode, mal ist es eine Modell, mal ist es ein Diagramm) sowie Wildwuchs da in jedem Artikel (fast) alles behandelt wird. Meine Meinung: Weniger wäre an vielen Stellen mehr.

So z.B. auch in diesem Artikel. Ein Hinweis auf "Eine saubere Strukturierung der Daten ist Aufgabe der sogenannten Datenmodellierung." würde z.B. mMn völlig genügen - die Thesen von Codd und die Liste von Fachbegriffen ist ja fast schon für den Informatiker zu viel - war da nicht die OMA-Anforderung für Wikipedia-Artikel?

Ich tummle mich zur Zeit und noch weiter in den Grundlagen (erster Punkt) und helfe dort wo ich kann. Bei Punkt zwei habe ich angefangen und da gibt es viele viele Artikel, die man sich meiner Meinung nach näher anschauen müsste. Grüße --EFR 17:53, 15. Aug 2006 (CEST)