by May 1, 1999 0 comments

The end-user today looks for simplification of tasks
and ease-of-use. So we’ve graduated from endless DOS commands to Windows’
clickable interface, and from complex programming languages to fairly easy front-end
tools. Databases had remained aloof to this transition for quite sometime, till SQL Server
7 came in and boasted of easier administering and wizard-based tasks. Along with
administrative tasks, it has also made querying the database for information easier
through English Query, a feature other databases are yet to catch up with.

SQL Server 7’s English Query makes querying the
database as simple as talking to it. It uses a set of entities and relationships that have
to be defined, so that the question asked by the user can be converted to a SQL statement
to query the database. So keying in a query is as simple as "List employees with
income less than 10,000" or "Which employee has maximum salary" and
you’ve your results. And, in case you use a word that’s not defined in the app,
it gives you hints. For example, if you type US and it’s not defined in the English
Query application, you don’t get an error like "item not defined" instead
you’ll get a message like this "I don’t understand the term US". In
case a question has not been phrased properly, it’ll give plenty of hints, or ask
questions to give you the results of a query. This makes not only querying the database on
a local system easy, but makes querying straight from the Net simple too since English
Query lets other apps use its objects.

Building an English Query application is not complex but
you do need to put your thinking cap on for a good system. The prerequisites are: your
database needs to be in place and set up in system DSN (data source name) in the ODBC data
source administrator. For the app, you need to build an English Query domain that is a
collection of information in the database.

The way your English Query application works depends on how
well you’ve defined the entities and relationships. Entities and relationships are
defined so that the English Query application can "read and understand" your
query. An entity is an object that’s contained in your database, like name, place,
thing, etc. While defining an entity, you can also give a number of synonyms for it for a
more foolproof application, so that the query still works if a user uses another word for
a particular entity, like client for customer, or novel or publication for book. While
defining an entity, you’ll also define the table it’s associated with and the
fields that it points to, and also if it’s a person, thing, location, timer, physical
object.

Once you’ve your entities in place, you’ll need
to define the relationships between different entities so that the application knows how
these objects are related to one another. For example, you can use, "some customers
have credit cards" to relate the entity "credit cards" with entity
"customer", to answer a query like "Which customers have credit
cards." You need to be cautious while defining relationships, since a wrong
relationship can give an entirely different result for the same query.

Once the relationships have been defined, the application
just needs to be compiled. The built application gets saved as EQD file and you can either
use it to query the database through Microsoft English Query itself, or extend this easier
querying feature to other application like searches on the Web.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<