Document Database Analysis - Assignment Example

?Task a) and b) The ER-Diagram consists of five main entities, ly VISIT, BOOKING, OWNER, DOG, and INVOICE. The relationships can be explained in detail considering their cardinalities, participations and constraints according to the given scenario. CLASS/VISIT and BOOKING A CLASS/VISIT can have several BOOKINGs and a one BOOKING have a single corresponding CLASS/VISIT. Hence a one to many relationship exits between these entities (Marked with 1 and M near the respective entity). A CLASS/VISIT may or may not have booking at a time and it is considered a BOOKING is optional for a CLASS/VISIT and CLASS/VISIT is mandatory for a booking (marked with a circle on BOOKING as the optional side). A class can either have no bookings as minimum or 10 bookings as maximum (cardinality marked as (0, 10) near CLASS/VISIT entity). A booking must always have a class related to it and one class is the maximum (cardinality marked as (1, 1) near BOOKING entity). BOOKING and OWNER An OWNER can have several BOOKINGs and a one BOOKING have a single corresponding OWNER. Hence, one to many relationship exits between these entities (Marked with 1 and M near the respective entity). An OWNER may always have a booking and a booking should always have owner. It is considered a BOOKING and OWNER are mandatory for each other. An OWNER at least has one booking in minimum or many bookings (cardinality marked as (1, M) near OWNER entity). A booking must always have a owner related to it and one owner is the maximum (cardinality marked as (1, 1) near BOOKING entity). OWNER and DOG An OWNER can have several DOGs and a DOG have a single OWNER. Hence a one to many relationship exits between these entities (Marked with 1 and M near the respective entity). An owner may always have at least a dog and a dog should always have owner. Hence it is considered a BOOKING and OWNER are mandatory for each other. An owner at least has one dog or many dogs (cardinality marked as (1, M) near OWNER entity). A dog must always have an owner and one owner as the maximum (cardinality marked as (1, 1) near DOG entity). CLASS/VISIT and DOG A CLASS/VISIT can have several DOGs attending and a DOG can attend to several CLASS/VISITs. Hence, many to many relationship exits between these entities. A composite entity ‘attend’ was introduced as the linking entity (marked as 1:M on either side of the composite entity). A class may always have a many dogs attending or no dogs attending a class (marked with a circle on the composite entity). A dog should always attend a class. Hence it is considered a DOG is optional for a CLASS/VIST. A class can either have no dogs attending or 10 dogs as maximum (cardinality marked as (0, 10) near CLASS/VISIT entity). A dog must always have at least a class related to it and one class is the maximum (cardinality marked as (1, 1) near BOKING entity). BOOKING and INVOICE An INVOICE can be related only for a one BOOKING and a one BOOKING have a single corresponding INVOICE. Hence a one to one relationship exits between these entities (marked with 1 and 1 near the respective entity). An invoice always has a booking and a booking should always have an invoice. It is considered a BOOKING and INVOICE are mandatory for each other. An INVOICE always has one booking or many bookings as minimum and maximum (cardinality marked as (1, 1) near INVOICE entity). A booking must always have an invoice related to it and one invoice is the maximum (cardinality marked as (1, 1) near BOOKING entity). The primary and foreign key relevant to each entity is presented in their entity definition table as PK and FK respectively. Entity DEFINITION Entity Name: CLASS/VISIT   Entity Description: The details of the Classes and Visits are recorded here Attribute Name Data Type Field Length Required Y/N Validation Rule Primary Key / Foreign Key class_id text 50 Y Not Null PK class_name text 100 Y     class_day text 15 Y     class_max capacity integer 2 Y     class_start_date date 20 Y     Entity DEFINITION Entity Name: BOOKING   Entity Description: All the bookings relevant to classes and visits are recorded here Attribute Name Data Type Field Length Required Y/N Validation Rule Primary Key / Foreign Key bk_id text 50 Y Not Null PK class_id text 50 Y Not Null  PK and FK ow_id text 20 Y Not Null PK and FK bk_date date 20 Y     Entity DEFINITION Entity Name: INVOICE   Entity Description: Invoice details relevant for each booking is recorded in this relation Attribute Name Data Type Field Length Required Y/N Validation Rule Primary Key / Foreign Key invoice_id text 50 Y Not Null PK bk_id text 50 Y Not Null  FK invoice_tot amount float 15 Y     Entity DEFINITION Entity Name: OWNER   Entity Description: The details of the Classes and Visits are recorded here Attribute Name Data Type Field Length Required Y/N Validation Rule Primary Key / Foreign Key ow_id text 20 Y Not Null PK ow_name text 100 Y     ow_address text 150 Y     ow_tele text 20 Y     ow_no_of_dogs interger 10 Y ow_email text 50 Y     Entity DEFINITION Entity Name: DOG   Entity Description: The details relevant to dogs which attend the classes and visits Attribute Name Data Type Field Length Required Y/N Validation Rule Primary Key / Foreign Key rec_id text 50 Y Not Null PK dog_name text 100 Y     dog_breed text 50 Y     dog_age integer 2 Y     vacc_date date 20 Y     Entity DEFINITION Entity Name: attend   Entity Description: this entity acts as a linking entity between CLASS and Dog entities Attribute Name Data Type Field Length Required Y/N Validation Rule Primary Key / Foreign Key class_id text 50 Y Not Null PK rec_id text 50 Y Not Null PK c) Form A Form B The booking for a Jenny Jones Dog Education Class can be completed with two easy steps according to the Form illustrated above. Form A is the first step where the user is given the option to select the owner or register a new owner. The Class can also be selected from the existing set of classes. A calendar option is given to select the date accurately. After entering the correct information user can check availability of the place in that particular class and the message will be displayed within the same page after checking. Depending on the availability user can either cancel the booking or move into the second step represented in Form B. In this form the Customer ID, Booking ID, Invoice ID and Date will automatically appear in this form where user have to enter the charged amount and confirm by taking a printout of the invoice. Appropriate validation checks for each form value will also be guide the user as well. References Hoffer, Jeffrey. George, Joey. Valacich, Joseph. Modern Systems Analysis and Design, Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc, 1998. Print. Read More