Dbm (discuter | contributions) m |
Dbm (discuter | contributions) m |
||
Ligne 4 : | Ligne 4 : | ||
[[LIBD:Themes|<''Back to Themes & Resources page''>]] | [[LIBD:Themes|<''Back to Themes & Resources page''>]] | ||
− | *'''Description''': Interacting with databases requires languages and protocols, be they for database building, exploitation or administration. The level of language depends on its goal and on the skill of its target user. We present and discuss some of the languages and API’s we have developed as well as some contributions to language processing. | + | *'''Description''' |
− | :*<b>SPHINX | + | :Interacting with databases requires languages and protocols, be they for database building, exploitation or administration. The level of language depends on its goal and on the skill of its target user. We present and discuss some of the languages and API’s we have developed as well as some contributions to language processing. They can be classified into five categories: |
− | :*<b>NUL</b>. The Navigational User Language (NUL) was designed to allow end-users to query databases through an Entity-relationship view of data. A query was incrementally built by defining simple objects derived from the conceptual schema and from already defined objects. An interactive interpreter was developed on top of the SPHINX DBMS. NUL is described in paper [P76-01] and in system manuals [R78-01] to [R78-05]. | + | ::*''abstract language for information system design'': ADL |
− | :*<b>IDML</b>. Based on the experience of system SPHINX, we experimented wrapper technology to interface application programs with CODASYL databases through a high-level neutral data manipulation language based on a binary data model (1978-1981). This language will be reused later under the name ADL. A prototype wrapper generator was developed [P78-02] [P81-01]. | + | ::*''DBMS languages'': SPHINX DDL and DML, NUL, IDML, T-SQL, NDBS, SQL-Script |
− | :*<b>Wrappers</b>. A wrapper is a software component attached to a data source (such as a file and a database) and that provides its users (typically application programs) with a data model that is different from that of the data source. Practically, a wrapper is notably defined by its API. The wrapper technology and architecture have been extensively studied, experimented and used since 1981 in various contexts. | + | ::*''API'': wrappers, T-ODBC, conceptual API |
+ | ::*''languages for CASE tools'': Voyager 2, Grasyla | ||
+ | ::*''language processing'': co-transformation, program analysis | ||
+ | |||
+ | :*<b>Data Access Description Language (ADL)</b> (''abstract language''). The ADL language, borrowed from the IDML interface, has been used as an abstract data manipulation language to describe database algorithms. Formely a companion language of the GAM (notably to study performance of database programs [P76-02] [P77-01]), it has been extended recently to complement the GER in A. Cleves’s thesis [PHD09]. In book [B86], ADL was used to describe abstract database programs in a logical database design process. The latter book also describes ADL transformations following data structure transformations (what will be called later co-transformations). This framework allows programs to be described at the conceptual level, then to be automatically transformed into algorithms compliant with logical database schemas. | ||
+ | |||
+ | :*<b>SPHINX DDL and DML</b> (''DBMS languages''). One of results of the project Large Administrative Databases (1971-1977) was a DBMS based on a Entity-relationship model. It included a data definition language and a data manipulation language for COBOL programs [P78-01] [P78-03]. A detailed specification of these languages can be found in the final report of the project ([R78-01] to [R79-05]). | ||
+ | :*<b>NUL</b> (''DBMS language''). The Navigational User Language (NUL) was designed to allow end-users to query databases through an Entity-relationship view of data. A query was incrementally built by defining simple objects derived from the conceptual schema and from already defined objects. An interactive interpreter was developed on top of the SPHINX DBMS. NUL is described in paper [P76-01] and in system manuals [R78-01] to [R78-05]. | ||
+ | :*<b>IDML</b> (''DBMS languages''). Based on the experience of system SPHINX, we experimented wrapper technology to interface application programs with CODASYL databases through a high-level neutral data manipulation language based on a binary data model (1978-1981). This language will be reused later under the name ADL. A prototype wrapper generator was developed [P78-02] [P81-01]. | ||
+ | :*<b>Temporal languages TSQL / T-ODBC</b> (''DBMS language and API''). One of the result of project TimeStamp is a variant of SQL extended with bi-temporal dimensions. This variant was named T-SQL (a subset of TSQL2). The API with the database (an active DB implemented in Oracle 9) was an extension of ODBC called T-ODBC) [P01-02]. | ||
+ | :*<b>NDBS</b> (''DBMS languages''). NDBS (Network Database System, 1986-1996) is an educational database management environment allowing Turbo-Pascal programs to manage and use complex data in an efficient, though very intuitive, way. NDBS comprised a runtime library (database handler), a DDL compiler, a 4GL Query Language, a data dictionary, a report generator, a SQL/NDBS converter, an import/export tool, etc. The last version (under the name Pyramid) was developed by D. Rossi, then Master student in the University of Namur. Two original aspects: (1) the data model was a variant of the ER model, (2) the physical engine was a fairly strict implementation of the principles developed in the course of Database Technology I gave in the 80's. [NDBS-86] | ||
+ | :*<b>Temporal languages TSQL</b> (''DBMS language''). One of the result of project TimeStamp is a variant of SQL extended with bi-temporal dimensions. This variant was named T-SQL (a subset of TSQL2). [P01-02]. | ||
+ | :*<b>Scripting Language for SQL</b> (''DBMS language''). MS Access provides two ways to execute SQL statements: as Access queries (simple but single queries only) and embedded in VB programs (powerful but complex). We have designed a scripting language (SQL-Script) through which one can write simple SQL programs. A SQL-Script program is made up of a sequence of SQL statements, but also of variables, macros, loops, alternatives and interaction with users. An interpreter for SQL-Script has been developed in MS Access. [SQL-Script] | ||
+ | |||
+ | :*<b>Wrappers</b> (''API''). A wrapper is a software component attached to a data source (such as a file and a database) and that provides its users (typically application programs) with a data model that is different from that of the data source. Practically, a wrapper is notably defined by its API. The wrapper technology and architecture have been extensively studied, experimented and used since 1981 in various contexts. | ||
:**Database access code generation [B86]. | :**Database access code generation [B86]. | ||
:**Legacy database interoperability [P99-01] [P01-03] [P04-08] [P05-03] [P06-08]. | :**Legacy database interoperability [P99-01] [P01-03] [P04-08] [P05-03] [P06-08]. | ||
:**Information system evolution and migration [P03-03] [P04-04] [P06-04] [P08-05] [PHD09]. | :**Information system evolution and migration [P03-03] [P04-04] [P06-04] [P08-05] [PHD09]. | ||
:**High-level database programming through conceptual object classes to support fast system evolution [P10-05]. | :**High-level database programming through conceptual object classes to support fast system evolution [P10-05]. | ||
+ | :*<b>Temporal API T-ODBC</b> (''API''). The T-SQL language interacts with the database through the temporal API T-ODBC which is an extension of ODBC [P01-02]. The temporal database is an active DB implemented in Oracle 9. | ||
+ | :*<b>Conceptual API for system evolution</b> (''API''). The fast evolution of applications systems forces developers to adopt defensive programing techniques to facilitate system adaptation. We have developed a Java API that offers data manipulation at the conceptual level (according to a variant of the Entity-relationship model). The API is automatically generated by the DB-MAIN CASE tool according to rules that minimize the impact of changes on the database, on the data and on the application programs [P10-05]. | ||
+ | |||
:*<b>Languages for CASE tools</b>. [DB-MAIN] [P99-03] [P99-06] [PHD00] | :*<b>Languages for CASE tools</b>. [DB-MAIN] [P99-03] [P99-06] [PHD00] | ||
− | + | ||
− | :*<b>Co-transformation</b>. [P04-03][P06-04] [P06-06] | + | :*<b>Co-transformation</b> (''language processing''). [P04-03][P06-04] [P06-06] |
− | :*<b>Program understanding</b>. [P96-01] [P98-01] [P98-02] [P08-02 | + | :*<b>Program understanding</b> (''language processing''). [P96-01] [P98-01] [P98-02] [P08-02] |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
*'''Keywords''' | *'''Keywords''' |
<Back to Themes & Resources page>