RJLRef: $PH/06f522/asgnt3/asgnt3DraftDueOct12.txt ----------------------------------- [NOTE: There is no class Oct. 12 - it's on a Monday schedule.] Hello class. This is a DRAFT of your next assignment, which is really a mini-project. It will probably last beyond Oct. 12, with some deliverables by that date. It's an extension of asgnt2 on Candidate Keys, to include several implementation considerations. Asgnt3 will implement and test an application of gencpp or chgen. This application operates on the metadata in a schema.msdat file and in metaschenma.sch, including [meta-]data for the candidate key binary association of asgnt2. As a test application, we will use schooldb,sch from [TBD], augmented by metaschema.sch, as the schema.msdat file. (For this data model we have the domain knowledge to define the composite candidate keys.) One starting point is $PH/06f522/asgnt3/TBUpdatedSchooldb.sch.txt. Chgen or gencpp will generate load and access code for this data model. and you will implement several methods in C or C++. To implement chgen and gencpp alternatives, I would like two 2-student teams - one to use chgen's pr_load.c and pr_accessors.c and another to use gencpp's equivalent load and access methods. (pr_parse() in pr_load.c can parse ASCII-coded field value sequences.) Each team should implement the SAME methods and interfaces (TBD). For ease of comparison, both teams should use the SAME candidate key data model extensions [TBD from asgnt2] and the same schooldb.dat test database for ease of reference. The fifth student should volunteer to create this database and the main test driver and test cases to test it. Some records will be pre-loaded and others will become data inputs for the test cases. Hint: pr_load( uses pr_parse() to parse ASCII-coded field value sequences for schema tables. The test driver can also use pr_parse on schema-defined tables. The application requires writing a private method called keyExists which checks if a given candidate key value already exists in the pre-loaded schooldb.dat. Candidate keys including composite keys for schooldb.sch are TBD. Assumptions (mandatory to simplify code comparison and re-use): Assume that the key field value list is a white-space-separated text string, for ease of test data generation. Assume that the candidate key spec is a white-space-separated list of field names (some are fkeys named XYid for table XY). These must match some TA field spec via the relation CA. Assume the Candidate Key spec table has ttabrev CK and pkey CKid. Assume the key-to-attribute association table CA has pkey CAid. Assume that a candidate key structure for table XX is identified by the ttabbrev XX plus this candidate's CKid value and a list of ASCIIi-coded field values for its component fields. [Hint: from XXid we can locate its set of CKid's and its CA components. Each CAid child has a TAid fkey to access its field name and datatype.] The 'core' application requirement is to write a method called ckeyExists which checks if a given candidate key value already exists among the pre-loaded schooldb.dat records. Remember that pkeys and fkeys are encoded as unsigned integers by pr_load(). Two public client methods must also be implemented. Both of these use the keyExists() check method: (1) Add a new record for which EACH pre-defined candidate key value must be NEW (i.e., does not already exist in the DB). (2) Retrieve a record whose selection criterion is a particular candidate key (its id and specified values for each key component. For transaction (1), duplicates are not allowed(), so [keyExists()==FALSE for EACH candidate key] is a pre-condition for accepting the record (to avoid future violations of referential integrity). For transaction (2), the record must exist, so [keyExists()==TRUE for THIS candidate key] is a pre-condition for correctly reporting success or failure in retrieving the record (3) A third type of method might be useful in cases where an incomplete set of key-component values or pairs is supplied for a candidate key in (1), or for a set of data fields in (2), which does not cover any single candidate key. Call this private method keyIsComplete(). Its signature might be (); This method would make sure that the given list of data field names with non-NULL values spans at least one candidate key. [One can imagine several ways to use this kind of analysis such as completion hints to the user.] You needn't implement this transaction type, but I invite proposals with pseudo-code on how to implement it. E.g., one possibility is to supply an entire record with all undefined or missing field values replaced by a reserved string "?". [Note that keyIsComplete() depends ONLY on metadata, not on the record instances in the database.] Pre-requisites for this asgnt3 (TBDiscussed this Tues 9/26): (1) a complete metaschema.sch including candidate key tables. (2) a complete schooldb.sch for the data records. (3) an actual candidate key component list for at least some entity types. [Is this data or meta-data?] (4) agreed-upon interface specifications for the methods to be implemented (including how to identify each candidate key and its component fields). (5) paths to chgen/genv13 and gencpp executables using saturn's gencpcp if gencpp is not buildable on linux)