1. 1.NET Web Forms Business Forms © 2002 by Jerry Post

2. 2 Common Features  Forms originated on paper but today we often mean electronic forms.  Forms have common features.  The forms determine how the database will be designed.  Once you know how to create the standard forms, you can quickly build many business applications. Customer ID Last Name First Name Phone Main form/single row Products IDDescriptionColorSizeQOH 227Dog collarRedLarge15 293Dog leash, nylonBlack6 foot10 492Cat bedGraySmall4 596Bird cageGoldMedium2 602Aquarium, squareBlack25 gallon3 Listing/tabular Order Main/Sub or Parent/Child Order ID Customer Order Date ItemPriceQtyValue 2274.951 3590.89108.90

3. 3 Main Form  Main forms are relatively easy to understand.  As long as all of the elements on the form refer to a single entity.  Example: Customer form contains only data about one customer.  Example that presents problems: Order form contains data about the order (date), and about the customer (name).  Database systems work best if all of the data on a form relate to one entity.  You could use sections on one large form (Oracle approach).  Often better to use separate forms  Absolutely best for the Web.  But then you need to link them.  Example: Order form, choose customer from a list, or click a link to add a customer or edit the underlying data.

4. 4 Compound Forms are Confusing  Main order form that includes customer data.  Does the “New” button mean new orders or new customers?  If the Order fails, what do we do about the customer data?  Does the clerk have to enter customer data for every order?  Does the clerk or customer have to create an Order to change the customer data? If not, we need another Customer form anyway, so why put everything on the Order form?  Remember that Web forms often are filled out by customers, who have no training and possibly minimal computer skills. Order Order ID Order Date Last Name First Name Address City State ZIP New Order Order ID Order Date Customer New ProblemsBetter Customer Customer ID Last Name First Name Address City State ZIP New Edit Select

5. 5 Tabular Forms  Are similar to the way data is stored in the database.  If the table will be edited, all data should refer to only one entity.  Useful for employees to quickly edit related data.  Generally avoid using them with customers, except in special circumstances, and then only with limited editing and highly limited filters so they never see more than a few rows.  Problems arise when the list is too long.  Horizontally, too many columns take time to scroll on browsers.  Vertically, bigger problems with retrieving and handling the data. Need some type of paging and search or filter systems. Products IDDescriptionColorSizeQOH 227Dog collarRedLarge15 293Dog leash, nylonBlack6 foot10 492Cat bedGraySmall4 596Bird cageGoldMedium2 602Aquarium, squareBlack25 gallon3 Listing/tabular

6. 6 Main and Sub Forms  Are a special compound form.  The main form displays simple data from one row.  The sub form displays repeating data related to the main form.  Typical example from in-house systems: Order form  Main form shows data for a specific order (Date, Customer)  Sub form shows items being purchased.  These are rarely used on the Web when dealing directly with customers. It is less confusing to use separate pages.  The main form follows other main rules.  The subform is a tabular listing.  Restricted to match some main form ID.  Generally limited to a few rows. Order Order ID Customer Order Date ItemPriceQtyValue 2274.951 3590.89108.90

7. 7 Menu or Switchboard Forms  Most business applications use some type of initial form to handle login and direct users to various other forms.  The approach is easy to implement as Web forms with hyperlinks. You can use Target=“_blank” to keep the main menu and open other forms in new windows.  The hard parts are  Customizing the form for specific users.  Deciding what links belong on the form.  Organizing them to be logical and easy to use.  Sometimes you need multiple levels of menu forms, but then you have to make it easy to get back to the top, and to find each task. Start Form Username Password Customers Orders Inventory

8. 8 Advance Warning  If you can create these four types of forms as Web pages, you can fairly quickly build most business database-driven websites.  So, you would think that Microsoft.NET would have technologies to make it easy to create these standards.  But you would be wrong. At least for now. We can still hope.  Many of the Microsoft books include a note that, yes, you can sort of build some of these forms, but Microsoft designers believe that Web forms are usually read only, so there was no point to including details to actually collect and save data.

9. 9 From Forms to DB Design  Business forms contain much of the information you need to design the database for the application.  Modern databases must be designed carefully to avoid problems and to make them flexible enough to handle changes later.  You begin the process by collecting (or drawing) the forms and reports you will need.  In the process, ask lots of questions:  How many of these are there? (e.g., How many customers)  What identifies each item? (e.g., Do we give unique ID numbers to customers? Where do they come from?)  What type of data is that? (e.g., Are customer IDs numbers or do they include alphabetic characters?)  Who gets access to this data? (e.g., Which employees are authorized to edit customer data?)  Do you want fries with that? (Just practicing.)  The main goal is to create independent but interrelated database tables to hold the data for the application.

10. 10 Keys  Primary key  Every table (object) must have a primary key  Uniquely identifies a row (one-to-one)  Concatenated (or composite) key  Multiple columns needed for primary key  Identify repeating relationships (1 : M or M : N)  Key columns are underlined  First step  Collect user documents  Identify possible keys: unique or repeating relationships

11. 11 Surrogate Keys  Real world keys sometimes cause problems in a database.  Example: Customer  Avoid phone numbers: people may not notify you when numbers change.  Avoid SSN (privacy and most businesses are not authorized to ask for verification, so you could end up with duplicate values)  Often best to let the DBMS generate unique values  Access: AutoNumber  SQL Server: Identity  Oracle: Sequences (but require additional programming)  Drawback: Numbers are not related to any business data, so the application needs to hide them and provide other look up mechanisms.

12. 12 Problems with Keys  Key columns provide the link between tables and forms.  Customer(CustomerID, LastName, FirstName, …)(primary key)  Order(OrderID, OrderDate, CustomerID)(foreign key)  How do you generate a new key value?  With Access (AutoNumber) and SQL Server (Identity), the value is generated when you insert a new row into the table. BUT, there is no easy way to retrieve the generated value!  Oracle (Sequences) provides a separate method to generate numbers that works well.  If you need transportability, it is best to create a separate GenKey routine that works somewhat like Oracle Sequences and generates keys as needed. But you have to write code that gets a key value whenever you need one.  People cannot memorize key values, so forms need a method to let users select from a list. (For example, choosing the customer for an order.) These lists can cause data transfer problems.