Dbm (discuter | contributions) m |
Dbm (discuter | contributions) m |
||
| Ligne 15 : | Ligne 15 : | ||
:*<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>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>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>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>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>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 language T-SQL</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>Temporal language T-SQL</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>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. | :*<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>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>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]. | ||
| Ligne 33 : | Ligne 38 : | ||
:*<b>Co-transformation</b> (''language processing''). [P04-03][P06-04] [P06-06] | :*<b>Co-transformation</b> (''language processing''). [P04-03][P06-04] [P06-06] | ||
| − | :*<b>Program understanding</b> (''language processing''). Database reverse engineering requires the elicitation of implicit (i.e., not explicitly declared in the DDL code) data structures and constraints. This process relies on various techniques such as data analysis, schema analysis and program source code analysis. Code analysis is a complex matter but it provides essential information on the data structures. For instance, implicit foreign keys can be detected through the examination of the data validation sections that precede the insert statements in application programs. Identification of programming clichés, dependency graph and program slicing are some techniques that have been studied and implemented in DB-MAIN [P96-01] [P98-01] [P98-02] [PHD03]. Recently, we applied dynamic program analysis techniques to the detection of dynamic SQL statements, which are increasingly used in web applications (through JDBC for instance). [P08-02] [PHD09] | + | |
| + | :*<b>Program understanding</b> (''language processing''). Database reverse engineering requires the elicitation of implicit (i.e., not explicitly declared in the DDL code) data structures and constraints. This process relies on various techniques such as data analysis, schema analysis and program source code analysis. Code analysis is a complex matter but it provides essential information on the data structures. For instance, implicit foreign keys can be detected through the examination of the data validation sections that precede the insert statements in application programs. Identification of programming ''clichés'', dependency graph and program slicing are some techniques that have been studied and implemented in DB-MAIN [P96-01] [P98-01] [P98-02] [PHD03]. Recently, we applied dynamic program analysis techniques to the detection of dynamic SQL statements, which are increasingly used in web applications (through JDBC for instance). [P08-02] [PHD09] | ||
*'''Keywords''' | *'''Keywords''' | ||
<Back to Themes & Resources page>