2011-12-14, 04:26 AM
I found a way to cheat at the problem, it's quite frustrating that I still can't come up with anything decent, though.
1/ find all pizzerias that serve at least one of the pizzas we want (Person \join_{age>"30"} Eats \join Serves), project the pizzeria-pizza relations
2/ self-join with new schemas (pizzeria, pizza1) and (pizzeria, pizza2) with condition (pizza1 != pizza2). As a result, get the relations of pizzerias that serve MORE THAN ONE pizza
* This way, we rule out the pizzerias that serve only one type of pizza, because its pizza1 will coincide with pizza2, inevitably
For this particular database, we only have 2 types of pizzas that people over 30 years old eat, so this works out (whatever passes the filter serves 2 types of pizza and thus "every" type). For other databases, we can easily find the number of pizzas that people over 30 years old eat, and keep recursing step 2 until we rule out all the ones that don't serve EVERY one of them.
Realistically, it works, it's just not a one-size-fits-all solution.
1/ find all pizzerias that serve at least one of the pizzas we want (Person \join_{age>"30"} Eats \join Serves), project the pizzeria-pizza relations
2/ self-join with new schemas (pizzeria, pizza1) and (pizzeria, pizza2) with condition (pizza1 != pizza2). As a result, get the relations of pizzerias that serve MORE THAN ONE pizza
* This way, we rule out the pizzerias that serve only one type of pizza, because its pizza1 will coincide with pizza2, inevitably
For this particular database, we only have 2 types of pizzas that people over 30 years old eat, so this works out (whatever passes the filter serves 2 types of pizza and thus "every" type). For other databases, we can easily find the number of pizzas that people over 30 years old eat, and keep recursing step 2 until we rule out all the ones that don't serve EVERY one of them.
Realistically, it works, it's just not a one-size-fits-all solution.