Software Engineering for Internet Applications - Student Community

);274-- ordering within a form, lower number = higher on-- pageform_sort_key integer,-- if there are N forms, starting with 0, to define-- this object, on which does this go? (relevant for-- very complex objects where-- you need more than one page to submit)form_number integer,-- for full text indexinclude_in_ctx_index_p char(1)check (include_in_ctx_index_p in ('t','f')),-- add forms should be prefilled with the default-- valuedefault_value varchar(200),check ((abstract_data_type not in ('user')and oracle_data_type is not null)or(abstract_data_type in ('user'))),unique(table_name,column_name)15.5 Exercise 3: Write a Program to Generate DDLStatementsBegin an admin interface to your km module, starting with a pagewhose URL ends in "ddl-generate". This should be a script that willgenerate CREATE TABLE (data definition language) statements fromthe metadata tables. You'll want to have a look at the SQL beforefeeding it to the RDBMS and therefore you may wish to write yourscript so that it simply outputs the DDL statements to the Webbrowser with a MIME type of text/plain. You can save this to yourlocal file system as km-generated.sql and feed it to your SQLclient when you're satisfied.In addition to the housekeeping elements that you've defined for yourapplication, each object table should have an object_id column. Thevalue of this column should be unique across all of the tables in thekm module, which is easy to do in Oracle if you use a singlesequence to generate all the keys. Given unique object IDs acrosstypes, if you were to add a km_object_registry table you'd beable to publish cleaner URLs that pass around only object IDs ratherthan object IDs and types.country_code char(2) referencescountry_codes(iso),postal_code varchar(80),home_phone varchar(100),work_phone varchar(100),mobile_phone varchar(100),pagervarchar(100),fax varchar(100),aim_screen_namevarchar(50),icq_number varchar(50));The table just keeps getting fatter. As the table gets fatter, more andmore columns are likely to be NULL for any given user. With Oracle9i you're unlikely to run up against the hard database limit of 1000columns per table. Nor is there an storage efficiency problem. Nearlyevery database management system is able to record a NULL valuewith a single bit, even if the column is defined char(500) or whatever.Still, something seems unclean about having to add more and morecolumns to deal with the possibility of a user having more and morephone numbers.Medical informaticians have dealt with this problem for many years.The example above is referred to as a "fat data model." In thehospital world you'll very likely find something like this for storingpatient demographic and insurance coverage data. But for laboratorytests the fat approach begins to get ugly. There are thousands ofpossible tests that a hospital could perform on a patient. New testsare done every day that a patient is in the hospital. Some hospitalshave experimented with a "skinny" data model for lab tests. The tablelooks something like the following:create table labs (lab_idinteger primary key,patient_id integer not null referencespatients,test_date timestamp(0),test_name varchar(100) not null,test_units varchar(100) not null,test_value number not null,note varchar(4000));-- make it fast to query for-- "all labs for patient #4527"-- or "all labs for patient #4527,75