Romodin
Mikhail
Ulyanovsk
State Technical Universtitet
Empirical development of databases using the language pseudocode
prototyping
Introduction
In the
development of automated systems, including databases, their conceptual design
is carried out consistently, experimenting with design decisions. Database to
basic conceptual decisions usually attributed relational structure and
connectivity, specifications attributes and selection of primary keys. Of
course, the variability of these decisions to a large extent depends on the
database application, that is, from queries to its content, which, in the early
stages of conceptual design, can be estimated with a high degree of fragmented
uncertainty [1].
To
provide the necessary consistency potential queries and sketch solutions for
database designers responsible for the conceptual design of the database, it is
advisable to provide an opportunity to experiment with design solutions. In
other words, designers need tools that allow you to create queries to implement
the model imitations of fragments of the future database.
The
paper presents such tools which are based on the pseudo-code programming
databases and their fragments, taking into account programmatic access to the
test content, embedded in the programmed model. Developed by means of
experimenting with programmed conceptual solutions are implemented as a
specialized extension of the instrumental question-answering environment WIQA
(Working In Questions and Answers), serving the conceptual design of AC [2]
Environment pseudocode programming
Instrumental
environment WIQA developed as an automated system architecture, which
integrates a number of interpretations WIQA, one of which is the understanding
and use of the complex as a "workbench pseudo-code programming"
design problems [3]. Generalized representation of this interpretation is given
in Figure 1.
Figure 1. WIQA as the environment pseudocode
programming
On the
generalized scheme reflected that the solution to every problem programmable Z
of wood project tasks documented in the question-answer form (Question-Answer
protocol, QA-protocol), which is a refined version of the pseudo-code program
(QA-program). Tree project tasks with their programs and organizational model
of collective, fulfilling project is loaded into memory question-answer
(QA-memory) tools WIQA just as the program is loaded into memory. Designer,
playing the role of "intelligent processor" (Scheme I j and
Ik-processors), to cause it needs QA-program memory and executes it in
interpreted mode with the help of "Interpreter", built in workbench.
Specificity
and presentation of pseudo-code programs and their execution environment
defines the memory whose cells are designed for storage of interactive objects
oriented registration "questions" and "answers" (a special
case of the problem issues). Each cell has a rich attributes (for example, its
unique index name, type, time of last modification, a pointer to the person who
created the object instance, and other system attributes of the cell). [2]
Moreover, the designer, zaregistrirovavshschy protocol (used in the program) a
particular object has the right and the possibility to attribute this property
ellichestvo any useful attributes to him, using the mechanisms of object-relational
mapping [3]. Marked specificity apply to data (QA-data) and operators
(QA-operators) pseudo-code programs, which is why they are called
"question-answer program" and the designation of QA-programs.
Language of pseudocode
programming
Language
of pseudo-code programming project tasks built into the question-response
modeling environment WIQA and is focused on its QA-memory [4], which is why in
the following text, it will be designated LWIQA.
Language-specific
LWIQA define the following
features:
1. Language of LWIQA especially close to natural language in its
algorithmic Used serving human interaction with the available experience in the
business. For this reason, the language is aimed at solving problems for which
there are precedents for the project and connected together.
2. The text of the
original pseudocode program in LWIQA built from the
representations of its structural units (sentence by sentence, the operator of
the operator) with the help of QA-data in the form of QA-model of this problem,
which opens up possibilities for the designer QA-modeling in his work with the
pseudocode problem, if there is a need in this.
3. Language of LWIQA - object-oriented programming support tasks with
databases and programming tasks in workflow management team.
4. If the work is
programmed in a language LWIQA, can be
"transferred" computer, the corresponding QA-program is compiled into
code executable by a computer processor (K-processor).
In
other words, one class of QA-programs can be executed as an I-processor and to
the processor. In working with the program in its class to open the following
features:
1. Programs, the
execution of which is entrusted to the K-processor, the designer created a
language LWIQA in interpreted mode and
debugged using the role of I-processor. Debugged program is compiled
automatically into executable code.
2. In the operation of
QA-programs in interpreted mode, its automatic execution is improved to a state
of automatic execution. This process of "skill" as used in the
solution process, into a "skill."
3. Programming a
certain work of the designers, it can be assembled from the programs, some of
which are executed I-processor, and the other marks the K-processor.
4. Parts of the same
program can be distributed between the processor and the I-K-processor to improve
the effectiveness of its coordinated execution.
5. Language of LWIQA developed as open to the inclusion in the structure
of additional types of data and QA-operators. The existing structure of the
language is shown in Figure 2.
The figure shows the
individual groups:
·
"Data Structures", backed by the emulation of any traditional
data types (scalars, arrays, records, sets, stacks, queues, ....) by means of
QA-data;
·
Data model "used for the specification of table structures and
their populations, as well as hierarchical structures;
·
"Basic operations" of the traditional pseudo-code programming
languages (Appoint, Input, Output, If, GOTO, etc.);
·
Operators databases "that emulate the basic SQL-operators;
·
Operators work flow "that emulate the basic operators of simulation
languages;
·
Operators visualization ", which are currently being developed for
on-demand viewing of designers cells QA-memory scenarios, pre-programmed or
quickly.
The details of the
structure of language LWIQA represent tabulated (Table 1), revealing the basic
operators and their syntax:
|
Îïåðàòîð |
Îïèñàíèå |
|
Command
on naturally-professional language |
Text
operator interpreted person executing the program |
|
IF…THEN |
Abridged
conditional statement "IF..THEN" |
|
IF..THEN..ELSE |
The
conditional operator « IF..THEN..ELSE..» |
|
&var&
:= val |
Assignment to a variable & var & value val. Operator Appoint. |
|
CALL &èìÿ_ïðîöåäóðû& |
EXECUTE |
|
GOTO &label& |
Unconditional
jump to label &label& |
|
FINISH |
END |
|
SET
&var1&, val1; &var2&, val2; … ; &varn&, valn |
Setting
of the set of variables |
|
INTERRUPT |
Interrupting
the program. Pressing the person executing the program button
"Abort" |
|
TEST [E,
NE, L, G, LE, GE], &var&, val &label& |
Conditional
jump to tag & label & in the case of [equality, inequality, less
than, greater than, less than or equal to, greater than or equal to] value of
the variable & var & value val. |
|
INPUT
&var& |
By simply
entering the person executing the keyboard values of var simple
type |
|
OUTPUT &var& |
Simple
derivation of the person executing the screen values of var
simple type |
Analogs of
operators given in Table 1 are used in the traditional pseudo-programming
codes. The differences are due to the fact that the QA-operator:
·
executed by a I-processor, which, if necessary, analyze existing
conditions (preconditions) and / or checks the result of execution, using
useful tools for such action simulation environment WIQA;
·
Inherits the attributes of "cell» QA-memory, in which the operator
is recorded, allowing the use of the attributes in the analysis of the
preconditions and verification result.
In the actions on the
analysis of the preconditions and control results QA-operator is interpreted as
"data» (QA-data), including not only the basic attributes, but more that
I-processor has the right to correct (or before execution of the statement, or
after). These properties and performance capabilities of the operators of the
traditional pseudo-code programming available.
Let's move on to
the operators, extending the basic set for use in programming tasks involving
access to databases.
Situations in which the model
is useful to access the database when it is not present, confronting designers:
·
In the process of the conceptual design of the database speakers;
·
In tasks of prototyping design solutions, including interaction with the
database:
·
In the service tasks of the design process, when designers have to be
useful or quickly create temporary table storage structure.
For the pseudocode
programming language features selected LWIQA was expanded set
of pseudocode operators, shown in Table 2.
|
Îïåðàòîð |
Îïèñàíèå |
|
CREATE
DATABASE |
Creating
a database. Method encoded as QA-program |
|
CREATE TABLE |
Create a
table. Executed by a dedicated QA-master data. |
|
DROP TABLE |
Deleting a table |
|
SELECT |
Selecting
data from a table |
|
DELETE FROM |
Deleting
data from a table |
|
INSERT
INTO |
Adding
data to a table |
|
UPDATE |
Modify
existing data in the table |
According to the
purpose of expansion operators are similar to the related operators of SQL.
Differences, as well as for the basic operators in the performance and
attributes, inherited from the QA-memory.
Formalization of LWIQA
For the language LWIQA developed his model formalized in the basis BNF -
notations [5]. Detail of the section of the language presented in the works of
the database is as follows:
<CREATE TABLE> ::= CREATE TABLE table_name ( { < column_definition > | < table_constraint > }
[ ,...n])
< column_definition > ::={ column_name data_type
}
< table_constraint > ::=[ CONSTRAINT
constraint_name ]
{ [PRIMARY KEY{ ( column [ ,...n ] ) }]| FOREIGN KEY(
column [ ,...n ] )
REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]}
<SELECT>
::= SELEC T (*|(column [ ,...n ]))
[ FROM { <table_source> } ]
[ WHERE <search_condition> ]
[ ORDER BY { column_name [ ASC | DESC ] }
<INSERT>
::= INSERT [INTO <table_name>
(column [ ,...n ])]
[VALUES (value, [,…n])]
<value> ::= ("string"|int|float|Boolean|datetime)
LIST OF REFERENCES
1.
C.J. Date Introduction to Database
Systems - 8th ed. - M .: "Williams", 2006 – 1328 p.
2.
Sosnin, P.I. Programming human-computer
activities /P.I.Sosnin. - Saarbruken: Lambert Academic Publishing, 2012. - 343 p.
3. Sosnin P. Question-Answer Shell for Personal Expert System //
Chapter in the book “Expert Systems for Human, Materials and Automation.”
Published by Intech, (2011), pp. 51-74.
4. Sosnin P. Question-Answer Approach to Human-Computer Interaction
in Collaborative Designing. Chapter in the book “Cognitively Informed
Intelligent Interfaces: Systems Design and Development” Published IGI Global, (2012),
pp. 157-176.