Dbm (discuter | contributions) (→SQLfast) |
Dbm (discuter | contributions) (→SQLfast) |
||
Ligne 203 : | Ligne 203 : | ||
:*<font color="black"><b>Case 1. Four hours to save the library</b>, draft version, <i>June 10, 2017.</i></font>[https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case01-Small-library.pdf [full text]] | :*<font color="black"><b>Case 1. Four hours to save the library</b>, draft version, <i>June 10, 2017.</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>Keywords</b>'': rapid application development, application prototyping, aplication architecture, GUI |
− | :*<b>Case 4. Schema-less databases | + | :*<b>Case 4. Schema-less databases - Part 1</b>, draft version, June 6, 2017. [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case04-Schemaless-DB(1).pdf [full text]] |
− | ::'' | + | ::''<b>Objective</b>'': This document is the first of a series of three case studies that explore alternative data models that organize the data in structures that provide more flexibility than standard relational tables. We observe that this flexibility makes it easier to dynamically modify the schema of the database but, as an unfortunate consequence, the schema is less expressive. In some of these data models, the schema is practically devoid of any information, hence the name schema-less. |
+ | ::In this study, we explore two extreme data models. In the Universal table model, according to which the data of all the source tables are stored in a single table comprising the union of the columns of the source tables. In the second model, called Column-oriented model, each column of the source tables is implemented in an independent table. | ||
+ | ::''<b>Keywords</b>'': non-relational data model, NoSQL, schema-less database, universal table model, universal relation, column-oriented data model, Cassandra, data migration, schema conversion | ||
− | :*<b>Case 5. Schema-less databases | + | :*<b>Case 5. Schema-less databases - Part 2</b>, draft version, July 7, 2017. [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case05-Schemaless-DB(2).pdf [full text]] |
− | ::'' | + | ::''<b>Objective</b>'': This document studies a third family of alternative data models, namely the Key-Value data structure. In these models, the information is represented by triples that each defines the value of an attribute of an entity. Several approaches are described, with increasing levels of genericity. |
+ | ::''<b>Keywords</b>'': non-relational data model, NoSQL, schema-less database, key-value model, triple, triplestore, RDF, SPARQL, description logic, A-BOX, OWL, Redis, Berkley DB, data migration, schema conversion | ||
− | :*<b>Case 6. Schema-less databases | + | :*<b>Case 6. Schema-less databases - Part 3</b>, draft version, July 25, 2017. [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case06-Schemaless-DB(3).pdf [full text]] |
− | ::'' | + | ::''<b>Objective</b>'': This document studies a fourth family of alternative data models, namely the object (or document) models. In these models, the information is represented by complex objects in which properties can be multivalued and composite. |
+ | ::''<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, July 25, 2017. [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 and event-based 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. | ||
+ | ::''<b>Keywords</b>'': temporal data type, temporal database, history, entity type, time point, time period, time interval, evolution, event, state, transaction time, valid time, system time, bitemporal data, document-oriented model, JSON, trigger | ||
:*<b>Case 14. The book of which you are the hero</b>, draft version, June 2, 2014. [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case14-Game-Books.pdf [full text]] | :*<b>Case 14. The book of which you are the hero</b>, draft version, June 2, 2014. [https://staff.info.unamur.be/dbm/Documents/Tutorials/SQLfast/SQLfast-Case14-Game-Books.pdf [full text]] | ||
Ligne 252 : | Ligne 261 : | ||
:*<b>Case 8. Active databases</b>, writing in progress. | :*<b>Case 8. Active databases</b>, writing in progress. | ||
− | + | :*<b>Case 10. Temporal databases - Part 2</b>, writing in progress. | |
− | + | ||
− | :*<b>Case 10. Temporal databases - Part 2 | + | |
:*<b>Case 11. Pivot tables: from columns to rows</b>, writing in progress. | :*<b>Case 11. Pivot tables: from columns to rows</b>, writing in progress. |
<Retour à la page d'accueil / Back>
Sommaire |
Case studies in preparation