Presentation is loading. Please wait.

Presentation is loading. Please wait.

DB Application Design (1) IS 240 – Database Management Lecture #16 – 2004-04-13 Prof. M. E. Kabay, PhD, CISSP Norwich University

Similar presentations


Presentation on theme: "DB Application Design (1) IS 240 – Database Management Lecture #16 – 2004-04-13 Prof. M. E. Kabay, PhD, CISSP Norwich University"— Presentation transcript:

1 DB Application Design (1) IS 240 – Database Management Lecture #16 – 2004-04-13 Prof. M. E. Kabay, PhD, CISSP Norwich University mkabay@norwich.edu

2 2 Copyright © 2004 M. E. Kabay. All rights reserved. Topics Functions of DB Application Views User Interface Design Homework

3 3 Copyright © 2004 M. E. Kabay. All rights reserved. Functions of DB Application OLAP: OnLine Analytical Processing – decision support SW OLAP cubes: multidimensional database like 3D (or nD) spreadsheet for seeing many different views of data

4 4 Copyright © 2004 M. E. Kabay. All rights reserved. CRUD Four basic functions common to all DB applications Create Read Update Delete Hence CRUD

5 5 Copyright © 2004 M. E. Kabay. All rights reserved. Format/Materialize Independent aspects of DB data Data content = view Appearance = materialization or format Materialize = to design appearance of DB application

6 6 Copyright © 2004 M. E. Kabay. All rights reserved. Enforce Constraints Structural constraints Domain specifications Uniqueness Relationship constraints E.g., no order detail without order header Business rules Non-structural, non-obvious; e.g., ___________________________________ {rule from a student DB} Think of an example here.

7 7 Copyright © 2004 M. E. Kabay. All rights reserved. Provide Control and Security Six fundamental goals of information security Confidentiality Control or possession Data integrity Authenticity Availability Utility Think of examples of each of these in a database application

8 8 Copyright © 2004 M. E. Kabay. All rights reserved. Execute Application Logic Applications execute business logic Actions in one part of a DB usually imply effects on other parts E.g., in hospital application Issuing prescription in hospital pharmacy implies modifying current inventory Reaching re-order point initiates order to supplier Order to supplier implies changes to current budget line-item

9 9 Copyright © 2004 M. E. Kabay. All rights reserved. Topics Functions of DB Application Views User Interface Design Homework

10 10 Copyright © 2004 M. E. Kabay. All rights reserved. Views Structured list of data attributes Projection or subset From complete list of available entities Or semantic objects Defined in data model Can be materialized or formatted as On-line form or Hard-copy report or Graphical representation Static Dynamic

11 11 Copyright © 2004 M. E. Kabay. All rights reserved. View: Structured List Customer view: Structured List of Attributes for an Art Gallery DB [Figure 10-4(a), p. 263] CUSTOMER.Name CUSTOMER.AreaCode CUSTOMER.LocalNumber TRANSACTION.PurchaseDate TRANSACTION.SalesPrice... WORK.ARTIST.Name WORK.Title WORK.Copy ARTIST.Name... What do the ellipses imply?

12 12 Copyright © 2004 M. E. Kabay. All rights reserved. Sample Data for Customer View Figure 10-4 (b), p. 263 What is all this?

13 13 Copyright © 2004 M. E. Kabay. All rights reserved. View Create Create INSERT INTO CUSTOMER (CUSTOMER.Name, CUSTOMER.City) VALUES (NewCust.CUSTOMER.Name, NewCust.CUSTOMER.City)

14 14 Copyright © 2004 M. E. Kabay. All rights reserved. View Read Read SELECT CUSTOMER.CustomerID, CUSTOMER.Name FROM CUSTOMER, WORK WHERE CUSTOMER.CustomerID = WORK.CustomerID

15 15 Copyright © 2004 M. E. Kabay. All rights reserved. View Update Update INSERT INTO CUSTOMER (CUSTOMER.Name, CUSTOMER.City) VALUES (NewCust.CUSTOMER.Name, NewCust.CUSTOMER.City)

16 16 Copyright © 2004 M. E. Kabay. All rights reserved. View Delete Cascading deletions depend on relationship cardinality ??

17 17 Copyright © 2004 M. E. Kabay. All rights reserved. Topics Functions of DB Application Views User Interface Design Homework

18 18 Copyright © 2004 M. E. Kabay. All rights reserved. User Interface Design Form Structure Follows View Structure & User Needs Structure Should Guide Actions Good Form Design Can Prevent Catastrophe Drop-Down Menus Restrict Choices and Reduce Errors Radio Buttons for Mutually Exclusive Options Cursor Movements Function Keys Context-specific HELP

19 19 Copyright © 2004 M. E. Kabay. All rights reserved. Form Structure (1) No absolute, unambiguous algorithm for determining where to place data Form structure follows View structure & User needs Vary among users Group form elements logically / ergonomically User should naturally see data as being related to each other Sequence should reflect natural usage patterns from user point of view Or among groups of users (functions)

20 20 Copyright © 2004 M. E. Kabay. All rights reserved. Form Structure (2) Consider hospital DB with PATIENT, DOCTOR and PATIENT-DOCTOR tables Discuss ways you could group information rationally on forms to help Doctors treating individual patients A head nurse responsible for managing an entire floor What are the issues you would have to think about when designing the forms?

21 21 Copyright © 2004 M. E. Kabay. All rights reserved. Form Structure (3) DOCTOR'S FORM Patient: NameXXXX Agexx Bedxx Status: Date/Time Heart Respiration Temp xxxx xx xx xx Treatment Schedule: xxxxxxxxxxxx xxxxx xxxxxxxxx Notes:

22 22 Copyright © 2004 M. E. Kabay. All rights reserved. Form Structure (4) Head Nurse Form Bed Patient Nurse Next med Current status T H R xxxxxxxx xxxx xxxxxx xxxxx xxxxx xxxx Nurse Beds Covered Xxxxx xxx xxx xxx xxx xxx xxx xxx Doctor Pager # Xxxx xxxx

23 23 Copyright © 2004 M. E. Kabay. All rights reserved. Structure Should Guide Actions (1) Design form so that it's easy to do the right thing and hard to make mistakes; e.g., Highlight fields for visibility where user is expected to enter data Gray out fields where user is forbidden to enter or change data Set field length to imply or limit acceptable input; e.g., "State" field can be 2 characters only If possible, use lists of allowed data See later – e.g., drop-down boxes, radio buttons....

24 24 Copyright © 2004 M. E. Kabay. All rights reserved. Structure Should Guide Actions (2) Can have different variations of forms for different functions; e.g., DISPLAY form such as the ones discussed for doctors and for head nurses may mostly show data but allows few changes Discuss which fields might change in the forms shown in these notes NEW PATIENT form specifies fields for all the data needed for registration to collect appropriate information

25 25 Copyright © 2004 M. E. Kabay. All rights reserved. Good Form Design Can Prevent Catastrophe Chemical plant in Netherlands Computer-controlled reaction vessels Operator entered numerical codes into form on screen to determine compounds entering vats 1992: data entry error Operator typed 634 instead of 632 in numerical code for tank # of 1 of 2 compounds Mixture of wrong chemicals caused massive explosion Plant destroyed; 3 firemen killed & 11 employees injured Discuss how better form design could have prevented accident

26 26 Copyright © 2004 M. E. Kabay. All rights reserved. Drop-Down Menus Restrict Choices and Reduce Errors In the example of the explosion, a good form design might have shown a choice of allowable combinations instead of allowing any combination including explosive pairs Drop-down menus are perfect for showing allowed choices; e.g., Enter compound #1Enter compound #2 A B C D 12345 A C E G 12354

27 27 Copyright © 2004 M. E. Kabay. All rights reserved. Radio Buttons for Mutually Exclusive Options Drop-down boxes are useful for data- dependent choices that can change When there are fixed choices that are mutually exclusive, radio buttons make it intuitively easy for the user to understand the restriction: Select one of the following meal plans: 21/week 14/week 7/week Per meal

28 28 Copyright © 2004 M. E. Kabay. All rights reserved. Cursor Movements Make the cursor move from field to field in a way that reflects what the user will be doing For example, if a doctor tends to fill in information in a particular way, make the ENTER and TAB keys move the cursor to the logically-next field; e.g., Let doctor enter next treatment ENTER moves cursor to next line in list TAB moves cursor to next field (e.g., Notes) Be consistent in use of these keys

29 29 Copyright © 2004 M. E. Kabay. All rights reserved. Function Keys All special functions that are assigned to function keys (e.g., ESC, F1 F2 F3... ) should be available in drop-down menus If you define function keys, be absolutely consistent; e.g., if F1 is HELP, it should be HELP in every form; If ESC moves to the previous (or higher) form, it should always do so throughout the application

30 30 Copyright © 2004 M. E. Kabay. All rights reserved. Context-specific HELP General help (e.g., from F1 key or pulldown menu) Provides overview of entire form May have hyperlinks for specific information Provides suggestions for additional topics Allows navigation to an index of help topics May provide find function Help-cursor Allows user to point to specific part of form Brings up pop-up help to explain meaning or choices for particular field or feature ? Pop-up Help

31 31 Copyright © 2004 M. E. Kabay. All rights reserved. Homework Reread Chapter 10, pp 257-274 using the full SURVEY-QUESTION-READ-RECITE-REVIEW phases of SQ3R Read ahead to complete the chapter for next Thursdays class REQUIRED: For Tuesday 20 April for 46 points Complete and hand in printed replies to Group 1 Questions 10.1 through 10.23 Remember to include the question itself in your answer sheets (makes them much more useful for review)

32 32 Copyright © 2004 M. E. Kabay. All rights reserved. DISCUSSION


Download ppt "DB Application Design (1) IS 240 – Database Management Lecture #16 – 2004-04-13 Prof. M. E. Kabay, PhD, CISSP Norwich University"

Similar presentations


Ads by Google