Diskussion:B-Baum

message: -- Sparti 00:59, 26. Jan 2005 (CET)
thread_title:  Indexstrukturen 

message: Bei einem externen Suchbaum werden die Daten nur in den Blättern gespeichert.
Die inneren Knoten beinhalten nur Verwaltungsinformationen.
Ich habe vor kurzem bei uns im Informatiokuntericht etwas von Brüder-Bäumen erfahren.
Irgendwie gleicht die Definition von B-Bäumen der von Brüder-Bäumen.
Kann es sich da um die selbe Datenstruktur handeln?
--unbekannt
Nein, kurze Recherche () ergibt, dass Bruder-Baeume binaer sind. B-Baume haben aber sehr zahlreiche Kinder.
Gruss -- Sparti 17:33, 13. Jun 2005 (CEST)
thread_title:  Bruder-Baum 

message: Hallo allerseits,
der Artikel hat enorm zugelegt. Ich halte ihn fuer einen Kandidaten für exzellente Artikel. Ich schlage vor, den Artikel vorab noch eine Zeit lang zum Review zu belassen und Ihn dann als Kandidat anzumelden. Gibt es jemanden, der anderer Ansicht ist oder den Artikel noch weiter verbessern moechte? Viele Gruesse -- sparti 14:38, 2. Aug 2005 (CEST)
replies: text: Nee, das ist noch zu früh. Ich würde die Autoren lieber noch etwas weiterschreiben lassen. Ich glaube die können noch eine Menge mehr liefern. Und bevor man ihn dann auf den Kandidaten verheizt gehört der Artikel auch erstmal in den Review. Dann bekommt man die Probleme, die der Artikel sicher noch hat, mit, bevor er durch haufenweise Contra-Stimmen keine Chance mehr hat. --Coma 14:48, 2. Aug 2005 (CEST)
replies: text:  Die Idee war auch nicht, sofort einen Eintrag dort zu tun, sondern auf den Artikel aufmerksam zu machen. Ich denke der Artikel kann noch einen Absatz fuer Laien gebrauchen, wo beschrieben wird, was das ganze eigentlich soll. @Hauix, willst Du etwas in der Richtung schreiben? Sonst wuerde ich mich mal ransetzen. Gruss -- sparti 13:17, 3. Aug 2005 (CEST)
thread_title:  Kandidaten für exzellente Artikel 

message: Hallo, der Artikel ist bereits sehr gut, ein Lob an die Autoren. Meiner Ansicht nach würde der Artikel viel gewinnen, wenn das Grundprinzip in einem einleitenden Abschnitt Übersicht in 10 bis 15 verständlichen Sätzen zusammengefasst würde. Derzeit ist der Leser gezwungen, die Defininitionen und Operationen einzeln durchzuarbeiten, um sich über die Funktionsweise zu informieren. --84.168.216.64 15:56, 21. Aug 2005 (CEST)
thread_title: Übersichtsabschnitt wäre schön

message: Benutzer:84.168.216.64 hat alle Verweise der Bauart #Links innerhalb der Seite in Links innerhalb der Seite geändert. Ist das Wikipedia-Konvention? Ich finde das nicht schick, da ich schon gerne vor dem Klick auf den Link wüsste, dass es ein Sprung innerhalb der Seite ist. Die jetzige Link-Schreibweise ist unnötig kompliziert. Wenn einem "global" das "#" nicht gefällt, könnte man das in der Wikimedia-Software entsprechend anpassen...
--Hauix15:41, 3. Sep 2005 (CEST)
replies: text: Mir ist keine solche Konvention bekannt und halte das fuer eine persoenliche Praeferenz des Autors. Mir selbst waere es egal, wobei ich mir nie mehr Muehe als notwendig machen wuerde. -- Gruss sparti 21:20, 3. Sep 2005 (CEST)

text: Vielleicht geht es ihm um die Darstellung für Ausdrucke? Ich würde die Version ohne # für lesbarer halten. -- Fleasoft 12:25, 5. Sep 2005 (CEST)
thread_title:  Links innerhalb der Seite 

message: Im Artikel steht, dass beim Einfügen volle Knoten "vorsorglich" geteilt werden, bevor man weiter zu den Kindknoten absteigt. Soweit ich Herrn Bayer verstanden habe, ist das aber falsch und die Knoten werden von unten nach oben aufgeteilt und zwar wirklich erst, wenn sie "übervoll" sind, also geteilt werden müssen.
Durch eine vorsorgliche Teilung kann man sich zwar das Rückwärts-Arbeiten sparen, erhält dadurch allerdings Bäume, die unnötig oft geteilt werden und hat damit etwas anderes als den von Rudolph Bayer beschriebenen B-Baum.
-- Oimel 14:23, 30. Sep 2005 (CEST)
thread_title:  Einfügen falsch beschrieben? 

message: Ein B-Baum ist in der Informatik eine Daten- oder Indexstruktur, die häufig in Datenbanken und Dateisystemen eingesetzt wird. Ein B-Baum ist ein vollständig balancierter Baum, der Daten sortiert nach Schlüsseln speichert. Das Einfügen, Suchen und Löschen von Daten in B-Bäumen ist in amortisiert logarithmischer Zeit möglich. B-Bäume wachsen anders als die meisten Suchbäume von den Blättern hin zur Wurzel.
* Ein runder Artikel. Ausreichend bebildert, umfangreich und interessant zu lesen norro 20:27, 2. Dez 2005 (CET)
thread_title: Lesenswert-Diskussion

message: Da ein vollständiger Baum mit Verzweigungsgrad t und Höhe h gerade t^{(h + 1)} - 1 Schlüssel speichert, können bei einem entsprechend groß gewählten t (z. B. t = 1024) bei einer Höhe von h = 4 bereits 1024^{4} - 1 = (2^{10})^{4} - 1 = 2^{40} - 1 Schlüssel gespeichert werden.
1. Widerspricht sich das schon mal selbst, da t^{(h + 1)} - 1 bei h = 4 sicherlich 1024^{4+1} - 1 ist, nicht 1024^{4} - 1.
2. Macht das aber eh keinen Sinn. Denn wenn jeder Knoten bis 2t-1 Schlüssel hat und bis zu 2t Nachfolgeknoten, dann haben wir z.B. bei einem Baum der Höhe 2 und t=2 bereits 3+4*3=15 Knoten, gegenüber den t^{(h + 1)} - 1 = 2^{3}-1 = 7 Knoten ist das doch ein deutlicher Unterschied. --OmEgA 15:44, 2. Jun. 2007 (CEST)
thread_title:  maximale Schlüsselanzahl? 

message: "oder die minimal erlaubte Anzahl von Kindknoten - in diesem Fall wäre die maximal erlaubte Anzahl an Schlüsseln 2t-1." 
siehe #REDIRECT B-Baum#Idee_und_.C3.9Cbersicht
Wieso ist das so? --BuZZdEE.BuzZ 12:57, 29. Okt. 2010 (CEST)
thread_title:  maximale Anzahl von Schlüsseln bei minimalem Verzweigungsgrad t 

message: Bei den Formeln hab ich mich gefragt, ob x.k_{j-1} \leq k Sinn macht, also das Gleichzeichen stört mich irgendwie, damit hätte Eltern- und Kindknoten den gleichen Schlüssel, was prinzipiell nicht stört, aber die eindeutige Suche kann man damit vergessen.
Vor allem würde x.k_{j-1} \leq k \leq x.k_j bedeuten, dass ein Index sowohl links als auch rechts vom Elternknoten eingefügt werden könnte.
--Cyber1000 16:42, 15. Aug. 2007 (CEST)
thread_title:  Definition Kindknoten 

message: Folgende Aussage habe ich nicht verstanden - und denke daher, dass sie entweder berichtigt oder besser erklärt werden sollte ;) Falls es nur an mir liegt bin ich auch mit einer einfachen Antwort zufrieden:
Zitat: "Die Suche bricht nicht in einem inneren Knoten ab, wenn dort der Schlüssel k bereits gefunden wird. Es findet immer ein Abstieg zu einem Blattknoten statt."
Problem 1: Sollte dies wirklich der Fall sein, in welchen Unterbaum steigt man dann ab - den vor dem gefundenen (gleichen) Schlüssel oder den danach?
Problem 2: Ist ein B-Baum nicht inkonsistent, wenn sich der gleiche Schlüssel an zwei verschiedenen Stellen im Baum wiederfindet?
--Thekryz 18:02, 2. Apr. 2008 (CEST)
replies: text: Ich habe das mal so ergänzt. --Thekryz 16:36, 26. Jun. 2008 (CEST)
thread_title:  Suche beim Einfügen 

message: Beschreibt nicht, was passiert, wenn Schlüssel in Kindknoten (symmetrischer Nachfolger / Vorgänger) Kinder hat. Wohin werden diese Verschoben, zusammengeführt ...? Wäre eine Erkläreung wert. Ich nehme mal an, dass man das ganze rekursiv machen kann (also beim Löschen im inneren Knoten wieder Löschen im inneren Knoten (mit Kindschlüssel) durchführen). --Thekryz 12:27, 1. Jul. 2008 (CEST)
thread_title:  Löschen aus inneren Knoten 

message: "Ein Knoten des Binärbaumes kann dann als ein Block gelesen bzw. gespeichert werden." - Muss das hier nicht B-Baum oder einfach nur Baum heißen? LG, Flo --129.187.41.12 12:24, 24. Aug. 2009 (CEST)
replies: text: ja, so war es wohl gemeint - danke für die Änderung Flo. Grüsse -- hroest Disk 10:29, 31. Aug. 2009 (CEST)
thread_title:  Binärbaum vs. B-Baum: Typo? 

message: besser x.c nehmen, sonst kommt man mit dem gesuchten k durcheinander (nicht signierter Beitrag von 134.91.90.5 (Diskussion) 19:56, 21. Jun. 2010 (CEST)
thread_title:  Im Abschnitt Suche wird mal x.k mal x.c verwendet.  

message: Folgenden Satz habe ich gerade aus dem Abschnitt „Geschichte und Namensgebung“ entfernt:
: Eine andere Interpretation entsteht durch Betrachtung der Banyan-Feige, einer Pflanzenart, die durch Wurzelteilung wächst.
Mir scheint das Theoriefindung (siehe Wikipedia:Keine Theoriefindung). Wenn jemand eine Quelle dafür findet, darf er's gern wieder einbauen. -- Levin 03:26, 12. Aug. 2010 (CEST)
thread_title:  Banyan-Feige 

message: in der Grafik gilt k1 < k2 (da im ersten Kindknoten geordnet), aber auch k2 < k1 (da k1 in der Wurzel steht und somit die Teilbäume trennt).
Das kann nicht sein. Besser: die Grafik aus der engl. Wikipedia verwenden. (nicht signierter Beitrag von Teddy87 (Diskussion | Beiträge) 19:08, 14. Aug. 2011 (CEST)
thread_title:  Grafik fehlerhaft 

message: Die Konstante dieser Abschätzung ist aber deutlich geringer als bei (balancierten) binären Suchbäumen mit Höhe \log_2(n):
 {\log_2(n) \over {\log_t({n+1 \over 2})}} \approx \log_2(t)
:::Das is vollkommer Schwachsinn was da steht, denn ein balancierter binärer Suchbaum hat Höhe log2 ((n+1)/2) (nicht signierter Beitrag von 79.229.173.103 (Diskussion) 22:25, 5. Okt. 2011 (CEST)
thread_title:  Fehler 

message: Ich bin der Meinung, dass die Angabe "t=3" bei den Graphiken zu den Operationen (Abbildungen 3-6) falsch ist. Richtig müsste es meiner Ansicht nach "t=2" heißen. 80.110.19.234 11:01, 17. Apr. 2015 (CEST)
thread_title:  Fehler in Graphiken bei den Operationen? 

message: Der C++ Code im Abschnitt "Programmierung" enthält m.E. einen Bug und eine Unschönheit. Der Bug ist in der Funktion BTreeNode::splitChild. Die Zuweisung "node->n = t - 1;" kommt in dieser Funktion zweimal vor. Beim zweiten Mal muss es jedoch "_node->n = t - 1;" heißen, sonst bleibt die Anzahl der Keys im Knoten _node auf einem falschen Wert. Es ist m.E. ungeschickt, zwei Variablen "node" und "_node" zu benennen. In der verlinkten Quelle zum Beispielcode ist der Bug nicht enthalten, und die Variablen sind besser unterscheidbar benannt.
Die Unschönheit ist, dass die Funktion BTreeNode::insert  im Beispiel redundant ist, nicht aufgerufen wird und gelöscht werden kann. Identischer Code befindet sich auch in der Klasse BTree, in Funktion BTree::insert. --2003:E3:739:C00:81D3:5491:BECF:96F5 16:30, 14. Dez. 2023 (CET)
thread_title:  Beispielcode fehlerhaft