VL 1.4 E-CommerceDataManagement Flashcards
Warum ist Schema-Evolution nicht optimal?
Keine gute Idee, denn nachträgliche Hinzunahme von Attributen ist beispielsweise bei Standardimplementierung von Relationalen Datenbanken extrem aufwändig!
- Schema-Evolution ist möglichst zu vermeiden –> praktisch wichtig
- –> Umsetzung aufwendig Z.b Darstellung/Anordnung im Speicher
–> Tupel müssen versetzt werden bzw “neuer Speicherplatz für neues Atribut eingefügt werden” (informell)
Was ist Sparsity?
Relation ist “dünn besetzt”, d.h. viele NULL-Werte
Was tritt häufig bei E-Commerce-Daten auf?
Schema-Evolution in Verbindung mit Sparsity
Zum Beispiel Produktdaten bei Elektronikbauteilen 2000 Produktkategorien,
- insgesamt > 5000 Attribute über alle Kategorien
- –> ständig neue Teile - mit neuen Attributen –> manche Hersteller haben Attribute als “Alleinstellungsmerkmal”. Andere haben dieses A. nicht, daher haben sie dort NULL-Werte ==
⇒ diese Schema-Evolution ist aufwändig und Sparsity ist störend (vergeudeter Speicherplatz)
Welche Lösung gibt es für Sparsity?
**Alternative Möglichkeiten der physischen Repräsentation**
- (1)Vertikale Repräsentation // Tupel der Vertikalen Repräsentation sind schlank -> NULL_werte nicht dabei –> Einem Datenobjekt == ggf. mehrere Tupel der Relation Tupel (Vertikal) = (Objekt_id, Key(=Attribut(Bezeichnung)), VAL(Attribut-wert)) Vertikale Darstellung trifft man häufig im Web Kontext an
- (2)Binär
Was kann das Problem der alternativen Repräsentation sein (Vertikal oder Binär) ?
Anwender erwartet weiterhin horizontale Repräsentation// ihm wird auch weiterhin die horizontale Sicht angezeigt, obwohl die physische Darstellung möglicherweise vertikal ist - SQL Abfrage machen Probleme.
⇒ D.h. Anfragen müssen in der Art umgestaltet werden, dass sie auf vertikaler Repräsentation arbeiten!
Was ist der pathologische Fall bei Sparsity?
Ein Tupel hat außer der ID nur NULL-Werte (zb Oid=5, A1=NULL, A2=NULL etc)
wie sieht die vertikale Darstellung aus? Möglichkeiten des Umgangs
- (1) Wir lassen die Null-Werte in der Vertikalen Darstellung zu (nochmal checken)
- (2) Darstellung in separater Relation, die nur für die pathologische Fälle dient
Von welchem Attribut-Typ ist das “Val”-Attribut der vertikalen Repräsentation? Wie kann man mit verschiedenen Typen umgehen?
Das generischste, dass wir im “Keller” haben
⇒ Also, das was am meisten zulässt! Dieser Typ muss alles umfassen Randnotiz:
Möglichkeit –>
- Pro Datentyp eine vertikale Relation –> dann kein “Kampf der Datentypen” –> auch besser zur Suche / Indices für Typ integer und Typ String beispielsweise
Unterschied logischer Entwurf und Physischer Entwurf
- LE = Wir überlegen uns: Was haben wir für Relationen und welche Attribute haben wir –> Logischer Entwurf hat bereits bei der Horizontalen Darstellung stattgefunden
- PE = Welche Indizes und Sichten haben wir –> Physischer Entwurf wie kann ich den effizienten Betrieb meiner Datenbank sicherstellen, wie werden die Daten letztendlich im Speicher abgelegt
Erläutern Sie kurz den in der LV vorgestellten Ansatz zur Speicherung von E-Commerce Daten (ohne Details zur Implementierung der einzelnen Operatoren).
Vertikale Darstellung und Binäre Darstellung
(Zur Erlangung einer guten bis sehr guten Note:) Erläutern Sie die Implementierung der diversen der LV besprochenen Algebra-Operatoren.
Gebe auch die Formeln an!
Mit v2h und h2v –> zuhilfenahme von Join-Operatoren insbesondere Left-Outer-Join wg. hinzunhame der NULL-Werte
Was ist Higher-Order View? Enablement Layer? Query Processing
Atribute plötzlich teil des Inhalts. –> D.h. Schema plötzlich teil des Inhalts beim Übergang von horizontaler zu vertikaler Darstellung Führt zu neuen Erfordernissen bezüglich der Anfragesprache
Wie ist das Verhältnis von Schema der horizontalen Darstellung zum Inhalt der vertikalen Darstellung?
Das was auf der im horizontalen Fall auf der Schema-Ebene auftaucht (bsp. Attribute) ist im vertikalen Fall Inhalt der Relation
Was ist ein Column-Store?
Binär –> für jede Spalte aus horizontal eine eigene Relation vertikal Weitere Bedingung: Null-Werte beibehalten und alle Tupel stets die gleiche Reihenfolge haben –> dann hat man die Repräsentationsform “Column-Store” Idee: Abspeicherung der Atrtributwerte spaltenweise –> Abfrage bei bestimmten Informationsbedürfnissen deutlich schneller als mit der herkömmlichen horzontaler Darstellung
Wie werden Anfragen bezüglich vertikaler und horizontaler Repräsentation gehandhabt?
Umtransponierung
Wo knirscht es beim konvertieren von h2v bzw. v2h? hier v2h!!!!
(1) k muss auch generiert werden (wieviele Attribute gibt es überhaupt) –> Also Möglichkeit die Anzahl der Attribute abzufragen (2)Attributbezeichnung muss erst konstruiert werden (A1,A2,A3,Ai) indem man –> i in String konvertieren und an (Groß) A anhängen Aber: Möglichkeit der String-Manipulation nicht Bestandteil der relationalen Algebra (3) Attributbezeichnungen müssen stets unterschiedlich sein es würden doppelte im Zuge des Joins erzeugt werden (oid, val, val) siehe Folie Outerjoin Schritte (Folie 15) Spalten heißen alle ‘Val’. Es gibt Operator für Umbenennung in relationaler Algebra (Beta). Jedoch nicht mit Datenbank-Inhalt als Argument. –>–> Herkömmliche Systeme unterstützen das ganze nicht (1)(2)(3) –> erweiterungen erforderlich für Überführung
