Purpose of this project Analyze, design, implement, and document a database system applicaion. You will use the methodology for database development learned in class. The system must be implemented on a DBMS with any language as a host-language for the application (use of Java and accessing the database using JDBC is one possibility.) The system must be menu-driven and include the basic functionality described below THE PHOTO SHOP The following specifications are intended as a guide; they are not the complete specifications. These are intended to be a basis for you to get started in the right direction in designing your system. You as the designer must analyze and decide what other details or features should be specified for your system. Thus, individual group implementations will differ in terms of design and implementation styles. Every group has to mention clearly in its report what other specifications are assumed Data and Functional Requirements We are hired to build a database for a photographic shop. The shop sells photos that can be bought over the internet. More precisely, the shop sells the rights to use a photo. In this sense, a photo can be sold only once. We need to model two very distinct parts: on one hand the information and activities that support the catalog of photos, models, and photographers and on the other hand the information and activities to support the transactions and customers We store some technical information for every photo, like the type (color or black and white), type of film, shutter speed, f-stop, price, resolution, the photographer etc. A photo can be made by a single photographer. If the photographer of a photo is known, we record the date of the shooting. The photos are grouped into several broad categories: landscapes, portraits and abstracts (everything that is not a landscape or a portrait). We are told that a photo cannot be a landscape and a portrait at the same time We store some biographical information of the photographers. We also store some information about the models (in the case of portraits) and information about the location rd their name, date of about other the photo was taken in (for landscapes). For photographers, we reco birth, short bio, address, and nationality. We also store information photographer(s) that influenced their work. We might need to record information about photo graphers, even if they have not made any of the photos we sell or sold at the store. is to provide the customers with a database of photographers. For every tion we need to record the place, the country and a short description Th e reason landscape photo of the area. Multiple landscape photos may have been taken at the same location. For a portrait model, we need to record his/her name, date of birth, sex and a short bio. A photo may picture several models. For every participation of a model in a portrait photo, we record the agency that provided the model (if available). For abstract photos we might store a comment. Although the customers can browse the catalog without registering, in order to buy one or more photos they need to have an account/profile and they need to register with a user name and password so the user name can be used as a key for Customers. For a customer, we record her user name, password, name, type, address and billing address. In the same transaction (or shopping cart) a customer can buy several photos. The attribute TotalAmount can be calculated from the individual price of every photo. Although this may, apparently, introduce some redundancy it gives us the flexibility to adapt the total price based on the type of customer or promotions or any other business rules (not to be included in our schema). For every transaction, we record the date and the credit card information of the buyer. Attributes like Name and Address need to be represented with their various component attributes First Name, Last Name, Street Address, State, Zip Code and the like. Other key attributes might need to be introduced. Your task is to design the database and application programs that will help manage the inventory and the day-to-day processing. Note that many functions are left out in order to reduce the size and the complexity of the project There are a number of processes that are relevant: Querying, Updating, Reporting. her assumptions but: (a) they should not be in contradiction with the You can make furt assumptions described above, and (b) they have to be clearly stated in your report Requirements Deliverable 1 must contain an analysis of the intended database system, and a conceptual schema. It must describe the problems encountered in this phase and justify the solutions. What is expected: 2. Analyze the entire application for the Photo Shop and come up with an extended ER diagram. Use notation for E/R concepts and for specialization/generalization Show entity types, relationship types (including class/subclass relationship types). valued/multi-valued, stored/derived) if needed. Show roles on recursive hierarchies from your textbook. and attributes. Show different types of attributes (simple/composite, single relationship types. Show key attributes - Include structural constraints (cardinalities ratio and participation constraints). Use both notations as an exercise--the traditional one and the (min, max) notation. Use some diagram editor to draw a clean diagram. 3. Mention any assumptions you made in doing the above that go beyond what is given in the project description. In particular, mention all such assumptions that led you in determining structural constraints. 4. Make a list of constraints that apply over and above what you can show in the diagram. In particular make a list of additional keys for entity types (if there are any) NOTE: The above specification will drive your subsequent phases. As in any actual design and implementation, you will be revising what you do here as you proceed through the phases. Please be explicit and detailed when writing your deliverable. This will help you in the long run