Microsoft English Query interprets English questions (for example, “Who is the oldest patient?”) and commands (for example, “Show the salespeople”) as commands to display a set of data. In some applications, you may wish to enhance English Query to understand other types of commands. Command phrasings are used to define these new domain-specific commands.
For example, imagine an English Query application used as a front-end for a CD jukebox, in conjunction with a database containing information about the CDs. A user might wish to say, “Play the Beatles album that has Get Back on it.”.This command would be translated into two commands to be executed by the application. The first would be an SQL command, which would fetch information about CDs by the Beatles that contain the track titled “Get Back.”.The second command would instruct the client to play the CD identified by the first command.
To enable domain commands, you create domain knowledge about CDs, authors, and tracks, and a relationship containing a command phrasing. The command phrasing in this example has the verb “play” and the direct object “CD.”
Command phrasings require a command ID. This is the ID that is handed back to the application through the object model, indicating which domain command it is. Each entity used in a command phrasing requires a parameterID. This is the ID that is handed back to the client application through the object model to indicate which SQL command corresponds to which command parameter.
A relationship that contains a command phrasing is a command relationship. Command relationships do not use join tables or SQL conditions, so the Database tab of the relationship is unavailable. Similarly, entities used in command relationships do not use join paths or “how many” and “how much” properties.
Some command phrasings use entities that are not represented by database objects. These non-database entities might simply be a static part of the phrasing (for example, “the recycle bin” in the command “Move <file> into the recycle bin.”) Or, these non-database entities might correspond to command arguments that are obtained from the user’s question rather than from the database. For example, in the command, “Raise the temperature of vat 6 by 12 degrees.” The command phrasing used would be “Raise the_temperature of vats by temperature_increase_amounts.” The entity “the_temperature” is not represented by a database object and does not correspond to a command argument. So, you’d specify this by selecting “None” as the parameter type. The entity “temperature_increase_amounts” (also not represented by a database object) does correspond to an parameter of the command. As a result, you’d need to indicate the data type of the parameter using the Parameter Type property.
Parameters that correspond to non-database entities are sent to the client application through the object model as data commands, rather than as SQL commands. In the previous example, “12 degrees” would be sent as the answer “12” with the qualifier property set to “degrees.”