Although you always wanted to be an artist, you ended up being an expert

on databases because you love to cook data and you somehow confused

database with data baste. Your old love is still there, however, so you set up

a database company, ArtBase that builds a product for art galleries. The core of

this product is a database with a schema that captures all the information that

galleries need to maintain. Galleries keep information about artists, their names

(which are unique), birthplaces, age, and style of art. For each piece of artwork,

the artist, the year it was made, its unique title, its type of art (e.g., painting,

lithograph, sculpture, photograph), and its price must be stored. Pieces of

artwork are also classified into groups of various kinds, for example, portraits,

still-lifes, works by Picasso, or works of the 19th century; a given piece may

belong to more than one group. Each group is identified by a name (like

those just given) that describes the group. Finally, galleries keep information

about customers. For each customer, galleries keep that persons unique name,

address, total amount of dollars spent in gallery (very important!), and the artists

and groups of art that the customer tends to like.

The ER model your DB engineer designed was lost, and he has resigned. So

you need to step in:

Draw an ER diagram for this database. Make sure to indicate primary

keys, cardinality constraints, weak entities (if any) and participation

constraints. List any assumptions you make in the process.

Translate the ER diagram into relational database tables (i.e. give the

SQL DDL statements). Make sure that the translation captures key

constraints (primary keys and foreign keys if applicable) and participation

constraints in the ER diagram. Identify constraints, if any, that you are not

able to capture.