use test

/*
	Warenkorb-Analyse
	=================
	
	Bei youtube fand ich ein Science-Slam-Video zu Wirtschafts-Informatik,
	bei dem das Stichwort "Warenkorbanalyse" fiel. Interessante Sache 
	das, also habe ich das Beispiel aus dem Video in MySQL nachgebaut.
*/

create table einkauf
(
	e_id int,
	prod_id int
);

create table produkt
(
	prod_id int,
	name varchar (255)
);

insert into produkt ( prod_id, name ) values ( 1 , 'Cola');
insert into produkt ( prod_id, name ) values ( 2 , 'Milch');
insert into produkt ( prod_id, name ) values ( 3 , 'Bier');
insert into produkt ( prod_id, name ) values ( 4 , 'Pizza');
insert into produkt ( prod_id, name ) values ( 5 , 'Pampers');

insert into einkauf ( e_id, prod_id ) values ( 1, 1 );
insert into einkauf ( e_id, prod_id ) values ( 1, 2 );
insert into einkauf ( e_id, prod_id ) values ( 1, 4 );
insert into einkauf ( e_id, prod_id ) values ( 2, 2 );
insert into einkauf ( e_id, prod_id ) values ( 2, 5 );
insert into einkauf ( e_id, prod_id ) values ( 3, 1 );
insert into einkauf ( e_id, prod_id ) values ( 3, 4 );
insert into einkauf ( e_id, prod_id ) values ( 4, 2 );
insert into einkauf ( e_id, prod_id ) values ( 4, 3 );
insert into einkauf ( e_id, prod_id ) values ( 5, 1 );
insert into einkauf ( e_id, prod_id ) values ( 5, 3 );

SELECT * FROM produkt;
SELECT * FROM einkauf;

/*
	Alle Produkt-Paare aus den Einkäufen herausfinden, d.h.
	für jeden Einkauf jedes Produkt mit allen anderen
	Produkten dieses Einkaufs kombinieren.
	NB: Wenn ein Produkt innerhalb eines Einkaufs mehrfach
	vorkommt, dann muss das vorher gruppiert werden. Ich gehe
	hier oBdA davon aus, dass jedes Produkt nur einmal in jedem
	Einkauf vorkommt.
*/

SELECT ek1.e_id, ek1.prod_id, ek2.prod_id
FROM einkauf ek1, einkauf ek2
where ek1.e_id = ek2.e_id;

/*
	An dieser Stelle spielt die Einkaufsnummer keine Rolle.
	Hauptsache, ich kenne alle Paarungen.
	Das sind die Paarungen, die vorkommen.
	Was ist mit denen, die nicht vorkommen?
*/

SELECT ek1.prod_id, ek2.prod_id
FROM einkauf ek1, einkauf ek2
where ek1.e_id = ek2.e_id;

/*
	So gruppieren, dass ich sehe, welches Paar wie oft
	vorkommt.
	Die Zeilen, bei denen ek1.prod_id = ek2.prod_id ist,
	geben an, wie oft das Produkt mit der ek1.prod_id
	insgesamt gekauft wurde. 
*/

SELECT ekl.prod_id as prodA, ekr.prod_id as prodB, count(ekl.prod_id) as anzahl
FROM einkauf ekl, einkauf ekr
where ekl.e_id = ekr.e_id
group by prodA, prodB;

/*
	Welche Kombinationen fehlen für das jeweilige Produkt?
	Nun, vergleiche die obige Tabelle mit dem kartesischen Produkt
	der Waren.
*/

SELECT * 
FROM (
	SELECT ekl.prod_id as prodA, ekr.prod_id as prodB, count(ekl.prod_id) as anzahl
	FROM einkauf ekl, einkauf ekr
	where ekl.e_id = ekr.e_id
	group by prodA, prodB
) tupels 
right outer join 
(
	select prl.prod_id as prodR, prr.prod_id as prodL
	from produkt prl, produkt prr
) alleWarenTupel
on tupels.prodA = alleWarenTupel.prodR
and tupels.prodB = alleWarenTupel.prodL;

/*
	Von obiger Tabelle zeige ich prodA und prodB nicht an,
	denn prodR und prodL sind bedeutungsgleich. Wichtig ist,
	dass ich für die jeweilige Paarung die Anzahl kenne.
*/

SELECT alleWarenTupel.prodL, alleWarenTupel.prodR, tupels.anzahl
FROM (
	SELECT ekl.prod_id as prodA, ekr.prod_id as prodB, count(ekl.prod_id) as anzahl
	FROM einkauf ekl, einkauf ekr
	where ekl.e_id = ekr.e_id
	group by prodA, prodB
) tupels 
right outer join 
(
	select prl.prod_id as prodR, prr.prod_id as prodL
	from produkt prl, produkt prr
) alleWarenTupel
on tupels.prodA = alleWarenTupel.prodR
and tupels.prodB = alleWarenTupel.prodL;

/*
	Wie bekomme ich eine hübsche Tabelle?
	Ich hätte gerne die Spalte "anzahl" in Fünfer-Pakete aufgeteilt, so
	dass die ersten fünf Werte hintereinander stehen, in der zweiten
	Zeile die zweiten fünf Werte usw.
	Für MSSQL scheint es unkompliziert, siehe
	http://www.brighthub.com/internet/web-development/articles/91895.aspx
	Für MySQL ist es umständlich(er)
	http://www.onlamp.com/pub/a/onlamp/2003/12/04/crosstabs.html

	Schließlich ein Dank an
	http://en.wikibooks.org/wiki/MySQL/Pivot_table

	Wermutstropfen: Die Spaltennamen sind "hardcodiert". Bei großem
	Produktumfang wird das eine Qual :/, also doch besser in eine 
	Tabellenkalkulation bringen.
*/

select prodL, ProdName,
sum(anzahl*(1-abs(sign(prodR-1)))) as 'Cola',
sum(anzahl*(1-abs(sign(prodR-2)))) as 'Milch',
sum(anzahl*(1-abs(sign(prodR-3)))) as 'Bier',
sum(anzahl*(1-abs(sign(prodR-4)))) as 'Pizza',
sum(anzahl*(1-abs(sign(prodR-5)))) as 'Pampers'
from (
	SELECT alleWarenTupel.prodL, alleWarenTupel.ProdName, alleWarenTupel.prodR, tupels.anzahl
		FROM (
		SELECT ekl.prod_id as prodA, ekr.prod_id as prodB, count(ekl.prod_id) as anzahl
		FROM einkauf ekl, einkauf ekr
		where ekl.e_id = ekr.e_id
		group by prodA, prodB
	) tupels 
	right outer join 
	(
		select prl.prod_id as prodR, prr.prod_id as prodL, prr.name as ProdName
		from produkt prl, produkt prr
	) alleWarenTupel
	on tupels.prodA = alleWarenTupel.prodR
	and tupels.prodB = alleWarenTupel.prodL
) pivot
group by prodL, ProdName;

select ProdName, Cola, Milch, Bier, Pizza, Pampers
from 
(
	select prodL, ProdName,
	sum(anzahl*(1-abs(sign(prodR-1)))) as 'Cola',
	sum(anzahl*(1-abs(sign(prodR-2)))) as 'Milch',
	sum(anzahl*(1-abs(sign(prodR-3)))) as 'Bier',
	sum(anzahl*(1-abs(sign(prodR-4)))) as 'Pizza',
	sum(anzahl*(1-abs(sign(prodR-5)))) as 'Pampers'
	from (
		SELECT alleWarenTupel.prodL, alleWarenTupel.ProdName, alleWarenTupel.prodR, tupels.anzahl
			FROM (
			SELECT ekl.prod_id as prodA, ekr.prod_id as prodB, count(ekl.prod_id) as anzahl
			FROM einkauf ekl, einkauf ekr
			where ekl.e_id = ekr.e_id
			group by prodA, prodB
		) tupels 
		right outer join 
		(
			select prl.prod_id as prodR, prr.prod_id as prodL, prr.name as ProdName
			from produkt prl, produkt prr
		) alleWarenTupel
		on tupels.prodA = alleWarenTupel.prodR
		and tupels.prodB = alleWarenTupel.prodL
	) pivot
	group by prodL, ProdName
) nice;

-- Aufräumen;
--
drop table einkauf;
drop table produkt;

-- Ende.

/*
	Nummeriere die Datensätze
	*************************

	Gegeben sei eine Tabelle aysx mit einem Primary Key. 
        Die Werte für den PK müssen nicht fortlaufend sein. 

        Aufgabe: Nummeriere die Datensätze 
	vom kleinsten bis zum größsten PK-Wert.

	Das folgende MySQL-Script zeigt exemplarisch, wie 
        das machbar ist. Bedenke, dass die Bestimmung des 
        Rangs (gidf) nicht auf eine "echte" Tabelle beschränkt 
        ist, sondern auch mit einem View und dem Ergebnis
	einer Abfrage durchgeführt werden kann.

	Beispieltext: aysx Matthias Kopp 2013
*/

create table aysx ( 
	id int PRIMARY KEY, 
	remark varchar ( 64 ));

/*
	Tabelle mit Beispieldaten füllen.
*/

insert into aysx ( id, remark ) values ( 1,	'Eins' );
insert into aysx ( id, remark ) values ( 512,	'FiveOneTwo' );
insert into aysx ( id, remark ) values ( 21,	'Antv' );
insert into aysx ( id, remark ) values ( 42,	'Antwort' );
insert into aysx ( id, remark ) values ( 23,	'whatever' );

/*
	Wesentlich ist der self-join. Der PK-Constraint garantiert,
	dass jede aysx.id nur einmal vorkommt. Eine id ist immer
	gleich ihrer selbst und alle anderen sind entweder größer
	oder kleiner. Die where-Bedingung sucht diejenigen Datensätze
	zusammen, die kleiner-gleich einer id sind - und das für
	alle ids. Schließlich wird für jede id eine Gruppe gebildet
	und die Anzahl der Elemente in der Gruppe ist eben der Rang.
*/

select count(*) as rang, t2.id
from aysx t1, aysx t2
where t1.id <= t2.id
group by t2.id;

/*
	Ohne Gruppierung und Zählen - die "expandierte" Form.
	Hier kann man nachvollziehen, welche Elemente vorhanden sind.
	Zähle und gruppiere selbst!
*/

select t1.id, t2.id
from aysx t1, aysx t2
where t1.id <= t2.id
order by t2.id

/* Auräumen. */
drop table aysx;

Natürlich ist das obige Beispiel so in der Praxis nicht vorgekommen. Das Beispiel zeigt eine nützliche Struktur. Im Laufe der Zeit kam immer wieder die Anforderung der Durchnummerierung. Man braucht dazu keinen PK-Constraint, aber wenigstens irgendein Tupel, das unique ist – und das findet sich. Jedenfalls konnte ich immer irgendwo eins auftreiben :)

Das Script oben habe ich mit Copy&Paste aus SQuirreL SQL übernommen, während ich mit einer MySQL-Datenbank verbunden war. Kann sein, dass andere RDBMS eine leicht abweichende Syntax haben. Aber im Prinzip sollte dieses Script auf gängigen SQL-Systemen lauffähig sein.

Ich kenne aus der Praxis ein Szenario, bei dem FK-Constraints ausgeschaltet wurden, um den Import von Daten zu ermöglichen. Die Daten lagen in unterschiedlichen Tabellen, verknüpft durch Foreign Keys. Man kriegt die einen Daten nicht ‘rein, wenn die anderen Daten nicht vorhanden sind. Bei einem System mit vielen Tabellen und Verbindungen wird das schnell zu einer “Plage”, weil man sich über die Reihenfolge bei Export und Import Gedanken machen muss. Vielleicht sind in dem exportierten System bestimmte Datenstrukturen gar nicht vorhanden, weil das einen anderen Versionsstand hat als das System, in das hinein importiert wird. Es ist verlockend einfach, die Contraints auszuschalten, die Daten reinzupumpen und zu hoffen, dass alles gut geht. RDBMS mit einer strikten Vorgehensweise, Beispiel Oracle, erlauben es nicht, Constraints einzuschalten, solange inkonsistente Daten vorliegen. Und dann hat man zwei Probleme, nämlich inkonsistente Daten und fehlende Contraints, die wiederum zu weiteren Inkonsistenzen führen können. Wohl dem Kunden, der einen Supportvertrag hat :(

Foreign-Key-Contraints auszuschalten heisst, schnell und dreckig zu arbeiten. Manchmal wird einen der Arbeitsdruck dazu verleiten – es muss ein Weg gefunden werden und zwar flott. Ich kenne das. Und ich weiss, dass das Aufräumen inkonsistenter Daten mächtig viel Zeit in Anspruch nehmen kann. Foreign-Key-Contraints-ausschalten als Notnagel: Ja. Als Dauerlösung im Code: Nein!