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 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! 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 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