Father-food database

A father wants to keep track of who in his family likes which foods. Each family member has a first name, last name, and age, and each food has a brand name and a product name. The following SQL statements create tables to meet the father's specifications: CREATE TABLE People ( FirstName varchar(30) NOT NULL, LastName varchar(30) NOT NULL, Age int NOT NULL, PersonID int NOT NULL, primary key(PersonID) ); CREATE TABLE Food ( Brand varchar(30) NOT NULL, Product varchar(30) NOT NULL, FoodID int NOT NULL, primary key(FoodID) ); CREATE TABLE PeopleFood ( PersonID int NOT NULL, FoodID int NOT NULL, primary key(PersonID,FoodID) ); Since the father is not very comfortable with SQL, he wants a usable interface into the database, and has decided to hire you to build it. Since his database is already in place, you MUST use exactly the database structure that is specified by the above CREATE TABLE statements. Here is what the interface is supposed to do: * It should allow for easy adding, modifying, and deleting of people and foods, and should allow for easy adding and deleting of relations between people and foods. * For a given person, it should list all the foods that person likes, and for a given food, it should list all the people who like that food. * The user should be able to search for a specific person, a specific food, or list all people/all foods. * The user should be able to specify a person P and get a list of all other people who have at least k foods in common with person P, where k is a user-settable parameter. (An analogous function should exist for listing all foods that have at least k people in common with some food F.) * The user should be able to specify two people and the system will list all the foods that they both like. (An analogous function should exist for listing all people who like each of a pair of foods.) * All of the information should be displayed so it is easy to use. * The level of detail (e.g. whether a person's age is displayed or whether a brand name is displayed) should be specified (and dynamically changed) by the user. When you are finished, write a 1-3 page description of the hows and whys of your design. Include how you partitioned the code into files and classes and why, where you put various things (like SQL statements, FORMS, HTML code, style setting, etc.) and why, how you designed and implemented the interface and why, etc.