Dbm (discuter | contributions) (→SQLfast) |
Dbm (discuter | contributions) (→SQLfast) |
||
Ligne 201 : | Ligne 201 : | ||
:*<b>Chapter 23. Aid to SQLfast development</b>, writing in progress. | :*<b>Chapter 23. Aid to SQLfast development</b>, writing in progress. | ||
+ | ::''Chapter contents'': Introduction. Two SQLast language levels. Examining the contents of variables and parameters. Enabling/disabling script output display. Tracing script execution. Tracing selected code sections. Tracing trigger execution. Analyzing and processing traces. | ||
:*<b>Chapter 24. Storing transient data - The SQLfast lists</b> | :*<b>Chapter 24. Storing transient data - The SQLfast lists</b> | ||
Ligne 207 : | Ligne 208 : | ||
:*<b>Chapter 25. Dynamic columns and schema-less tables</b> | :*<b>Chapter 25. Dynamic columns and schema-less tables</b> | ||
::''Chapter contents'': Introduction. Dynamic columns. Practical syntax. Metadata of dynamic columns. Technical note. Performance: static vs dynamic columns. Dynamic columns in DBMS (MariaDB)). Summary. | ::''Chapter contents'': Introduction. Dynamic columns. Practical syntax. Metadata of dynamic columns. Technical note. Performance: static vs dynamic columns. Dynamic columns in DBMS (MariaDB)). Summary. | ||
+ | |||
+ | :*<b>Chapter 26. Developing a tutorial</b> | ||
+ | ::''Chapter contents'': Introduction. Opening a tutorial. A tutorial is a formatted text. Adding images. Navigating within and between tutorials. Code snippets. Embedded scripts. Embedded script variants. Embedded scripts as a programming system. Inserting video and audio messages. Embedded wrappers. What is the role of a tutorial, after all?. Summary. Technical complement: about wrappers. | ||
:*<b>Appendix. A basket of examples</b>, writing in progress. | :*<b>Appendix. A basket of examples</b>, writing in progress. | ||
Ligne 219 : | Ligne 223 : | ||
<br> | <br> | ||
− | :*<font color="black"><b>Case 1. Four hours to save the library</b>, draft version, <i> | + | :*<font color="black"><b>Case 1. Four hours to save the library</b>, draft version, <i>November 2020.</i></font>[https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case01-Small-library.pdf [full text]] |
::''<b>Objective</b>'': This case study describes the emergency writing of a small application that was to implement the core functions of the management of a small library. The challenge was to replace the current software, lost in a recent crash of the server. All that was left after the accident was the last backup of the database, unfortunately in an unknown format. | ::''<b>Objective</b>'': This case study describes the emergency writing of a small application that was to implement the core functions of the management of a small library. The challenge was to replace the current software, lost in a recent crash of the server. All that was left after the accident was the last backup of the database, unfortunately in an unknown format. | ||
::''<b>Keywords</b>'': rapid application development, application prototyping, application architecture, GUI | ::''<b>Keywords</b>'': rapid application development, application prototyping, application architecture, GUI | ||
Ligne 242 : | Ligne 246 : | ||
::''<b>Keywords</b>'': non-relational data model, key-value model, object model, NoSQL, schema-less database, multivalued property, composite property, document-oriented DBMS, MongoDB, CouchDB, Azure, Datastore Oracle, metadata, index, data migration, schema conversion | ::''<b>Keywords</b>'': non-relational data model, key-value model, object model, NoSQL, schema-less database, multivalued property, composite property, document-oriented DBMS, MongoDB, CouchDB, Azure, Datastore Oracle, metadata, index, data migration, schema conversion | ||
− | :*<b>Case 9. Temporal databases - Part 1</b>, draft version, <i> | + | :*<b>Case 8. Active databases</b>, draft version, <i>September 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case08-Active-DB.pdf [full text]] |
+ | ::''<b>Objective</b>'': This study shows how advanced data structures of SQL can be used to built smarter databases, in particular active databases, that are able to react to external stimuli. It starts with a short reminder of the SQL data structures, including some of these advanced constructs, namely check constraints, views, generated columns and triggers. Then, it presents some usual applications of active databases, such as integrity control, redundancy management, updatableviews, data modification logging, alerters, type-subtype implementation, repair rules, temporal databases and access control. Finally, it explores, through a simple but representative business application, the power of active databases as compared with traditional application development. In this application, we observe the impact of moving the control of business rules from the programs to the database. This unusual application architecture requires special static and dynamic validation techniques. In its conclusion, this study briefly sketches the history of the trigger concept and evaluates the benefits and disadvantages of its use in application development. | ||
+ | ::''<b>Keywords</b>'': ECA rules, trigger, business rules, active database, DAG, finding circuits, advanced SQL, data structure, check predicate, updatable view, derived data, inventory management, 2-tier architecture, 3-tier architecture | ||
+ | |||
+ | :*<b>Case 9. Temporal databases - Part 1</b>, draft version, <i>November 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case09-Temporal-DB(1).pdf [full text]] | ||
::''<b>Objective</b>'': In this study we examine various ways to organize the data describing the evolution of a population of entities. The basic model consists in storing the successive states of each entity, completed by the time period during which the state was observable. We distinguish between the transaction time, that refers to the data modification time in the database and the valid time, referring to modification events of entities in the real world. This study particularly develops entity-based, attribute-based, event-based and document-oriented temporal database models. In these models, data management is ensured by triggers that automate as far as possible entity creation, modification and deletion operations. | ::''<b>Objective</b>'': In this study we examine various ways to organize the data describing the evolution of a population of entities. The basic model consists in storing the successive states of each entity, completed by the time period during which the state was observable. We distinguish between the transaction time, that refers to the data modification time in the database and the valid time, referring to modification events of entities in the real world. This study particularly develops entity-based, attribute-based, event-based and document-oriented temporal database models. In these models, data management is ensured by triggers that automate as far as possible entity creation, modification and deletion operations. | ||
::The next study will be devoted to temporal database querying and transformation. | ::The next study will be devoted to temporal database querying and transformation. | ||
Ligne 259 : | Ligne 267 : | ||
::''<b>Keywords</b>'': genealogy, tree, cyclic data structure, transitive closure, transitive reduction, tree projection, recursive CTE, recursive query, tree drawing, tree traversal, depth-first traversal, breadth-first traversal, SQLdraw. | ::''<b>Keywords</b>'': genealogy, tree, cyclic data structure, transitive closure, transitive reduction, tree projection, recursive CTE, recursive query, tree drawing, tree traversal, depth-first traversal, breadth-first traversal, SQLdraw. | ||
− | :*<b>Case 14. The book of which you are the hero</b>, draft version, <i> | + | :*<b>Case 14. The book of which you are the hero</b>, draft version, <i>November 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case14-Game-Books.pdf [full text]] |
::''<b>Objective</b>'': Game books are traditional text-based adventure games made up of a collection of pages (episodes) connected by references (branches). An episode comprises a text that describes a situation or an action and one or several branches that allow the gamer to jump to other episodes. Many of them are now available as pdf or html documents. In this study, we implement a simple game engine that automates such game books. This engine is based on a game database that can also be used to automatically generate stories. | ::''<b>Objective</b>'': Game books are traditional text-based adventure games made up of a collection of pages (episodes) connected by references (branches). An episode comprises a text that describes a situation or an action and one or several branches that allow the gamer to jump to other episodes. Many of them are now available as pdf or html documents. In this study, we implement a simple game engine that automates such game books. This engine is based on a game database that can also be used to automatically generate stories. | ||
::Actually, this project is a nice opportunity to examine in some detail the concept of graph (a game book basically is a set of nodes and a set of edges) and to develop exploration and transformation algorithms. In particular, we study the structure of a game graph, we identify its abnomalies, we extract its circuits, we build and count the different possible runs from the starting episode to an exit episode, we search for unreachable episodes and dead-end branches and we identify episodes that can be merged. | ::Actually, this project is a nice opportunity to examine in some detail the concept of graph (a game book basically is a set of nodes and a set of edges) and to develop exploration and transformation algorithms. In particular, we study the structure of a game graph, we identify its abnomalies, we extract its circuits, we build and count the different possible runs from the starting episode to an exit episode, we search for unreachable episodes and dead-end branches and we identify episodes that can be merged. | ||
Ligne 265 : | Ligne 273 : | ||
::''<b>Keywords</b>'': computer game, game engine, story generation, graph, cyclic graph, acyclic graph, graph transformation, Marimont algorithm, reachability, circuit, elementary circuit, transitive closure, cyclic kernel, set comparison. | ::''<b>Keywords</b>'': computer game, game engine, story generation, graph, cyclic graph, acyclic graph, graph transformation, Marimont algorithm, reachability, circuit, elementary circuit, transitive closure, cyclic kernel, set comparison. | ||
− | :*<font color="black"><b>Case 15. Directory management</b>, draft version. <i> | + | :*<font color="black"><b>Case 15. Directory management</b>, draft version. <i>November 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case15-Directory-Management.pdf [full text]]</font>. |
::''<b>Objective</b>'': The contents of storage media, such as hard disks and flash disks, both internal and external, are organized into a hierarchical structure made up of directories and files. | ::''<b>Objective</b>'': The contents of storage media, such as hard disks and flash disks, both internal and external, are organized into a hierarchical structure made up of directories and files. | ||
::This chapter shows that, when such structures are stored in a database, processes can be designed easily to examine directories, to analyze their contents, to describe their evolution and to discover potential problems. In particular, small applications will be developed to extract statistics, to display the structure and contents of a directory, do identify and describe potentially duplicate files and directories within a root directory or between two directories. | ::This chapter shows that, when such structures are stored in a database, processes can be designed easily to examine directories, to analyze their contents, to describe their evolution and to discover potential problems. In particular, small applications will be developed to extract statistics, to display the structure and contents of a directory, do identify and describe potentially duplicate files and directories within a root directory or between two directories. | ||
Ligne 271 : | Ligne 279 : | ||
::''<b>Keywords</b>'': directory structure, tree modeling, tree analysis, statistics, tree evolution, duplicate files, clone detection, secure hashing, SHA256, database performance, CTE, recursive queries. | ::''<b>Keywords</b>'': directory structure, tree modeling, tree analysis, statistics, tree evolution, duplicate files, clone detection, secure hashing, SHA256, database performance, CTE, recursive queries. | ||
− | :*<b>Case 21. Test Database Generation</b>, obsolete version, <i> | + | :*<b>Case 21. Test Database Generation</b>, obsolete version, <i>November 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case21-Test-databases.pdf [full text]] |
::''Chapter contents'': Database performance evaluation. Generating high volume of synthetic data. Integrating heterogeneous data sources. Data cleaning. Data anonymization. Random data extraction. Executing very large scripts. Query performance. | ::''Chapter contents'': Database performance evaluation. Generating high volume of synthetic data. Integrating heterogeneous data sources. Data cleaning. Data anonymization. Random data extraction. Executing very large scripts. Query performance. | ||
− | :*<b>Case 27. Conway's Game of Life</b>, draft version, <i> | + | :*<b>Case 27. Conway's Game of Life</b>, draft version, <i>November 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case27-Life-Game.pdf [full text]] |
::''<b>Objective</b>'': This study is about games, worlds, life and death, borderline SQL applications and dramatic database optimization. The goal of the project is to implement the graphical animation of Conway’s cellular automata, aka Game of Life. A game of life is made up of an infinite array of cells in which live a population of small animals, each of them occupying one cell. The transition of one state of the population to the next one is specified by a set of simple computing rules. The goal of the game is to observe and study the evolution of the population. A game of life is implemented as a table in a database in which each row contains the coordinates and the content of a cell. The algorithms developed in this study load the initial state of a population then compute the next states thanks to the evolution rules. Finally, they visualize this evolution as an animated cartoon. The contribution of this study is twofold. It stresses the importance of database and algorithm optimization (the last version is 1,400 times faster than the first one) and it shows that relational databases and SQL may be quite efficient to develop matrix manipulation procedures (the SQL version is nearly 7 times faster than the equivalent Python program). | ::''<b>Objective</b>'': This study is about games, worlds, life and death, borderline SQL applications and dramatic database optimization. The goal of the project is to implement the graphical animation of Conway’s cellular automata, aka Game of Life. A game of life is made up of an infinite array of cells in which live a population of small animals, each of them occupying one cell. The transition of one state of the population to the next one is specified by a set of simple computing rules. The goal of the game is to observe and study the evolution of the population. A game of life is implemented as a table in a database in which each row contains the coordinates and the content of a cell. The algorithms developed in this study load the initial state of a population then compute the next states thanks to the evolution rules. Finally, they visualize this evolution as an animated cartoon. The contribution of this study is twofold. It stresses the importance of database and algorithm optimization (the last version is 1,400 times faster than the first one) and it shows that relational databases and SQL may be quite efficient to develop matrix manipulation procedures (the SQL version is nearly 7 times faster than the equivalent Python program). | ||
::This study is also a tribute to E. F. Codd, the inventor of the relational model of databases, who first studied self-replicating cellular automata. | ::This study is also a tribute to E. F. Codd, the inventor of the relational model of databases, who first studied self-replicating cellular automata. | ||
::''<b>Keywords</b>'': cellular automata, replicating system, Conway, glider, Codd, matrix manipulation, algorithm optimization, database optimization, declarative algorithm, table indexing, in-memory database, CTE, recursive query, vector graphics, SQLdraw, animated simulation, Python. | ::''<b>Keywords</b>'': cellular automata, replicating system, Conway, glider, Codd, matrix manipulation, algorithm optimization, database optimization, declarative algorithm, table indexing, in-memory database, CTE, recursive query, vector graphics, SQLdraw, animated simulation, Python. | ||
− | :*<font color="black"><b>Case 28. From data bulk loading to database book writing</b>, draft version, <i> | + | :*<font color="black"><b>Case 28. From data bulk loading to database book writing</b>, draft version, <i>November 2020.</i></font> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case28-Topo-sort.pdf [full text]] |
::''<b>Objective</b>'': When data have to be loaded in a database from an external source, the order in which tables are filled is important as far as referential integrity is concerned. This order is determined by the directed graph formed by tables and foreign keys. From this graph one have to derive a linear ordering that represent one of the valid order in which table data are loaded. This derivation is called topological sorting, for which this chapter discusses and implements a simple algorithm. However, things are a bit more complex when the graph is not acyclic, as is often the case for database loading. Therefore, the chapter studies ways to transform a graph that includes circuits into a purely acyclic graph. These techniques are also applied to the ordering of topics when planning the writing of a book. | ::''<b>Objective</b>'': When data have to be loaded in a database from an external source, the order in which tables are filled is important as far as referential integrity is concerned. This order is determined by the directed graph formed by tables and foreign keys. From this graph one have to derive a linear ordering that represent one of the valid order in which table data are loaded. This derivation is called topological sorting, for which this chapter discusses and implements a simple algorithm. However, things are a bit more complex when the graph is not acyclic, as is often the case for database loading. Therefore, the chapter studies ways to transform a graph that includes circuits into a purely acyclic graph. These techniques are also applied to the ordering of topics when planning the writing of a book. | ||
::''<b>Keywords</b>'': data loading, database schema, (non) acyclic graph, topological sorting, strongly connected components, graph contraction, condensation of a graph, transaction management. | ::''<b>Keywords</b>'': data loading, database schema, (non) acyclic graph, topological sorting, strongly connected components, graph contraction, condensation of a graph, transaction management. | ||
− | :*<font color="black"><b>Case 31. Path finders, rovers and Ariadne's thread</b>, draft version. <i> | + | :*<font color="black"><b>Case 31. Path finders, rovers and Ariadne's thread</b>, draft version. <i>November 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case31-Shortest-path.pdf [full text]]</font>. |
::''<b>Objective</b>'': This chapter tackles a widespread optimization problem: computing the shortest path between two cities. The solving technique is based on Dijkstra’s algorithm. It also is applied to two similar applications domains, namely maze solving and controlling a rover on a hostile planet. A general purpose, application independent, solving tool is developed. | ::''<b>Objective</b>'': This chapter tackles a widespread optimization problem: computing the shortest path between two cities. The solving technique is based on Dijkstra’s algorithm. It also is applied to two similar applications domains, namely maze solving and controlling a rover on a hostile planet. A general purpose, application independent, solving tool is developed. | ||
::''<b>Keywords</b>'': optimization, shortest path, Dijkstra’s algorithm, maze solving, rover control. | ::''<b>Keywords</b>'': optimization, shortest path, Dijkstra’s algorithm, maze solving, rover control. | ||
− | :*<font color="black"><b>Case 34. Blockchains</b>, draft version. <i> | + | :*<font color="black"><b>Case 34. Blockchains</b>, draft version. <i>November 2020.</i> [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case34-Blockchains.pdf [full text]]</font>. |
::''<b>Objective</b>'': In this study, we examine some fundamental aspects of blockchains, particularly the security of data and the way(s) it is achieved through cryptographic transformations. Basically, a blockchain is a historical database in which the description of operations, generally called transactions, are stored in chronological order. Once recorded, the data of a transaction can never be deleted nor modified. | ::''<b>Objective</b>'': In this study, we examine some fundamental aspects of blockchains, particularly the security of data and the way(s) it is achieved through cryptographic transformations. Basically, a blockchain is a historical database in which the description of operations, generally called transactions, are stored in chronological order. Once recorded, the data of a transaction can never be deleted nor modified. | ||
::The document first introduces the elements of cryptography necessary to build a blockchain, notably secure hashing, and symmetric and asymmetric key encryption. Then, it describes the distinctive aspects of blockchains independently of its application domain and applies them to cryptocurrencies. Finally an experimental toolbox, comprising a collection of functions designed to manage and explore blockchains, is built step by step. | ::The document first introduces the elements of cryptography necessary to build a blockchain, notably secure hashing, and symmetric and asymmetric key encryption. Then, it describes the distinctive aspects of blockchains independently of its application domain and applies them to cryptocurrencies. Finally an experimental toolbox, comprising a collection of functions designed to manage and explore blockchains, is built step by step. | ||
Ligne 301 : | Ligne 309 : | ||
:*<b>Case 7. Schema-driven code generation</b>, writing in progress. | :*<b>Case 7. Schema-driven code generation</b>, writing in progress. | ||
− | |||
− | |||
− | |||
− | |||
:*<b>Case 13. Bis repetita non (always) placent (Detecting and controlling redundancies)</b>, writing in progress. | :*<b>Case 13. Bis repetita non (always) placent (Detecting and controlling redundancies)</b>, writing in progress. |
<Retour à la page d'accueil / Back>
Sommaire |
Case studies in preparation