Description

L'objectif de l'UV est de d'amener les étudiants à maîtriser la conception de bases de données relationnelles, relationnelles-objets et non-relationnelles. Cette maîtrise reposera sur des compétences méthodologiques de modélisation conceptuelle et logique, ainsi que sur des compétences technologiques de mise en œuvre au sein de SGBD typiques (tels que PostgreSQL, Oracle, MongoDB ou Neo4J). Les étudiants mèneront un projet qui servira de cadre d'application en situation des concepts préalablement étudiés et expérimentés.

Pré-requis : introduction aux bases de données relationnelles

  • Le cours est conseillé pour les étudiants de l'UTC en Génie Informatique, dès leur premier semestre, à condition qu'ils aient déjà validé un cours d'initiation aux bases de données relationnelles (par exemple NF92 à l'UTC, l'Api Bases de données, ou un cours en IUT d'informatique).

  • Une connaissance de base de l'utilisation d'un système Linux est nécessaire.

Pré-requis : maîtrise de la langue française

Il est indispensable pour suivre une UV en autonomie d'avoir une très bonne maîtrise de la langue française, permettant la lecture des supports fournis et la communication écrite via les dispositifs mis à disposition.

Objectifs pédagogiques

Savoir concevoir une base de données

  • Savoir mener un projet de réalisation de base de données

  • Savoir réaliser et interpréter un modèle conceptuel de données en UML ou E-A.

  • Savoir réaliser un modèle logique de données relationnel normalisé en 3NF, notamment à partir d'un modèle conceptuel de données

  • Savoir écrire des requêtes en algèbre relationnelle

  • Savoir exprimer des contraintes complexes

Savoir implémenter une base de données relationnelle

  • Savoir utiliser le langage SQL pour créer et interroger une base de données

  • Savoir mobiliser la gestion des transactions en SQL

  • Savoir exploiter les techniques d'optimisation des bases de données

Savoir implémenter une base de données non-relationnelle

  • Savoir réaliser un modèle logique de données relationnel-objet ou non-relationnel en mobilisant les concepts d'imbrication et d'identification

  • Connaître les syntaxes JSON et XML

  • Savoir utiliser les extensions SQL sous Oracle dédiées au relationnel-objet et au relationnel-XML

  • Savoir utiliser les extensions JSON sous Postgres dédiées au relationnel-JSON

Connaître les principes de réalisation d'une application de base de données

  • Connaître les principes de l'accès à une base de données avec un langage de programmation

  • Savoir accéder à une base de données à partir d'un langage de programmation

Objectifs transversaux

  • Savoir réaliser un projet modeste du début à la fin en petit groupe (clarification, analyse, développement, clôture)

  • Savoir réaliser et interpréter une analyse et une modélisation de problème

  • Savoir mobiliser un esprit critique face aux technologies (veille, évaluation, choix)

Objectifs transversaux (autonomie)

  • Savoir s'organiser et mobiliser des ressources matérielles et humaines pour mener une tâche en autonomie

  • Savoir utiliser les moyens de communication numériques en contexte profesionnel

Autonomie

Version en autonomie

NA17, NA18 et AA23 sont des versions de NF17, NF18 et AI23 en autonomie, c'est à dire que les cours et TD ne sont pas encadrés, mais travaillés de façon autonome par les étudiants, sur la base des supports pédagogiques de l'UV.

Les étudiants en autonomie réalisent un projet, participent à des activités pair-à-pair en groupe et passent les mêmes examens que les autres étudiants.

Activités pédagogiques obligatoires

  • Réalisation et auto-correction de devoirs

  • Réalisation d'exercices pairs-à-pairs

  • Réalisation d'un projet en groupe

  • Réalisation de tests individuels

  • Examens médian et final

Activités pédagogiques optionnelles

  • Travail en autonomie des modules (cours et exercices corrigés)

  • Participation à des séances de travail avec un enseignant

  • Échanges via un outil de support à distance entre pairs et avec un enseignant

Être autonome ne signifie pas faire ce que l'on veut, mais savoir s'organiser pour remplir un objectif, et en particulier savoir gérer son temps.

Être autonome ne signifie pas faire seul, mais savoir trouver les ressources pour faire, et en particulier savoir faire appel aux autres.

Conseils

Il est fortement conseillé de :

  • travailler en binôme ou en groupe

  • se fixer un créneau de travail régulier

  • noter scrupuleusement le planning des rendus dans son agenda

  • poser des questions régulièrement et lire les questions posées par les autres

Les versions en autonomie sont déconseillées aux étudiants étrangers, en particulier si c'est leur premier semestre à l'UTC ou s'ils ont des difficultés avec le français (ils suivront de préférence les versions classiques).

Qui peut faire une UV en autonomie ?

Les formations en autonomie permettent de développer ou consolider des compétences transverses :

  • savoir s'organiser,

  • savoir se faire travailler.

Suivre en formation en autonomie demande donc soit :

  • de maîtriser ces compétences transverses, la formation en autonomie est alors un espace pour travailler différemment en profitant de ces compétences déjà acquises.

  • de vouloir acquérir ces compétences transverses, la formation en autonomie aura alors un double objectif : maîtriser les contenus de la formation et maîtriser les compétences transverses. La formation en autonomie est alors plus difficile qu'une formation classique (mais plus riche).

Exemples :

  • Les étudiants adaptés à une formation en autonomie sont typiquement les étudiants de TC02+, les ex TC ayant eu un parcours sans heurt.

  • Les GX02+ ayant bien réussi leur(s) premier(s) semestre(s).

Contre-exemples :

  • Les TC01 ou GX01 ne connaissant pas encore le contexte de l'UTC,

  • Les étudiant étrangers en échange pour un semestre,

  • Les étudiant maîtrisant mal la langue française.

Remarque : Avoir des antécédents dans la discipline peut être un léger avantage, car cela permet de se concentrer sur l'acquisition des compétences transverses, mais l'expérience montre c'est une arme à double tranchant, les étudiants ayant plus de mal à apprécier la différence entre ce qu'ils connaissent déjà et ce qu'ils doivent apprendre de nouveau que dans un cadre classique.

P2P : l'exercice dont vous êtes le héros

L'exercice pair-à-pair (P2P) consiste à faire faire par les apprenants des exercices originaux qui seront résolus par d'autres apprenants. C'est une mise en situation d'enseignant pour les apprenants. Une consigne précise guide la création de l'exercice par les apprenants (ce n'est pas un exercice libre).

L'exercice P2P se déroule de la façon suivante :

  1. Exercice : Chacun propose un exercice à destination des autres étudiants (pairs)

  2. Résolution : Chacun se voit affecté la résolution de l'exercice d'un pair

  3. Correction : Chacun corrige la réponse de son pair et propose un corrigé type

Chacun est évalué sur l'exercice proposé, sur la résolution réalisée et sur ses corrections.

Mini-projet

Les projets consistent à réaliser une base de données, éventuellement accompagnée d'une petite partie applicative afin d'élaborer une solution à un problème posé. Les projets doivent être réalisés dans le temps prévu, en ajustant le périmètre fonctionnel si nécessaire.

Le projet sont réalisés sur les serveurs Linux de l'UTC et sont livrés sous la forme d'un commit Git poussé sur le serveur Gitlab de l'UTC.

Objectif

  • Donner un cadre d'application aux étudiants pour motiver la mise en pratique de ce qui est vu en cours

  • Découvrir ou approfondir des technologies

  • Être en situation d'ingénierie (presque) réelle

  • Faire réfléchir sur le métier d'ingénieur (implications, verrous...)

Évaluation

  1. Examen Final : 50%

  2. Examen Médian : 25%

  3. Applications : 25%

Conditions de validation de l'UV

  • Moyenne générale pondérée supérieure à 10

  • Note supérieure à 10 au médian ou au final

  • Note éliminatoire : 0 à l'une des épreuves

Examens

Les examens médian et final seront composés d'exercices similaires à ceux travaillés en TD.

La partie applications comprend des exercices, des projets et des test sur papier et sur machine.

Consignes pour les examens

  • Tous les documents papier sont autorisés.

  • Aucun appareil électronique n'est autorisé (ordinateur, téléphone, traducteur...).

  • Les réponses peuvent être données en anglais pour les étudiants étrangers (le préciser sur la copie). Les étudiants non francophones peuvent demander de l'aide pour la compréhension de certains mots si le dictionnaire ne suffit pas à les comprendre.

  • Présentez une pièce d'identité (de préférence votre carte d'étudiant).

  • Chacun des exercices est à rendre sur une copie séparée.

  • Le nom doit être écrit lisiblement sur chaque copie.

  • Il ne sera répondu à aucune question sur le contenu. Si un énoncé ne vous paraît pas suffisamment clair, énoncez vos hypothèses.

  • Les correcteurs se réservent le droit d'appliquer des malus hors barème (points négatifs) pour toute réponse absurde ou tout contre-sens grossier.

Évaluation des rendus (projet, tests...) sur une échelle de 0 à 3

De nombreux rendus dans le cadre de la formation seront évalués sur l'échelle décrite ci-après.

  • 3 : Livrable attendu, sans erreur

  • 2 : Livrable attendu, avec une ou deux erreurs ou insuffisances mineures

  • 1 : Livrable insuffisant ou comportant plusieurs erreurs mineures ou une erreur importante (qui rend la solution inadaptée)

  • 0 : Livrable non rendu, hors sujet, non acceptable (erreurs nombreuses et/ou plusieurs erreurs importantes)

Professionnalisme

Un livrable rendu dans le cadre de la formation sera évalué sur les mêmes critère qu'un livrable professionnel, en particulier :

  • Un document est lisible, correctement présenté et correctement écrit en français. Ceci est d'autant plus vrai pour les travaux de groupe qui peuvent faire l'objet de relectures croisées (pour les étudiants étrangers maîtrisant mal la langue française et effectuant un rendu seul, cela sera précisé sur le livrable).

  • Un code informatique s'exécute. Il a été testé sur l'environnement prévu et ne comporte pas d'erreur empêchant son exécution. Un code qui ne s'exécute pas n'a même pas été testé au niveau technique, et ne mérite pas l'attention du destinataire, il est rejeté (et vaut 0).

  • Un code informatique est livré avec des données de test réalistes. Un code est livré avec un jeu de données qui permet d'en tester les fonctionnalités. Ces données ont réalistes par rapport au sujet traité. Elles montrent que le code a été correctement testé au niveau fonctionnel.

  • Un code informatique est livré avec une documentation. Celle-ci est synthétique et permet a minima de définir les modalités d'exécution et de test du code qui ne sont pas évidentes.

À propos du plagiat...

  • Plagier : « Emprunter à un ouvrage original, et par métonymie à son auteur, des éléments, des fragments dont on s'attribue abusivement la paternité en les reproduisant, avec plus ou moins de fidélité, dans une œuvre que l'on présente comme personnelle. ( TLFi) »

    Le plagiat est interdit.

  • Paraphrase : « Souvent avec une connotation péjorative. Développement explicatif d'un texte, souvent verbeux et diffus, qui ne fait qu'en délayer le contenu sans que rien ne soit ajouté au sens ou à la valeur. ( TLFi) »

    La paraphrase est inutile.

  • Citation : « Action de citer un passage d'auteur, de reproduire exactement ce qu'il a dit ou écrit, oralement ou dans un texte ( TLFi) »

    • Les citations doivent êtres produites dans une mise en forme permettant de les identifier sans doute possible, a minima entre guillemets français : « ».

    • Les citations doivent être courtes (quelques mots à quelques lignes)

    • Les citations doivent être exactes, on peut utiliser la syntaxe [...] si on souhaite les raccourcir (sans que cela en travestisse le sens).

    • Il est nécessaire de conserver les numéros de pages où elles apparaissent, ou les URL en cas de site avec des sous-pages (ou tout autre procédé permettant de les situer rapidement au sein du texte).

    • Il est nécessaire d'ajouter des explications et/ou une reformulation et/ou un positionnement (accord, désaccord) et/ou des liens (autres articles...) relatifs à la citation ; a minima une phrase permettant de comprendre pourquoi la citation est mobilisée.

Volume horaire

Un crédit ECTS correspond à 25 à 30h de travail étudiant.

Les UVs Nx1718 correspondent à 6 crédits ECTS, soit environ 150h de travail étudiant.

Les UVs Ax23 correspondent à 5 crédits ECTS, soit environ 125h de travail étudiant.

Logiciels

L'ensemble de la formation se déroule sous Linux.

Les projets seront menés en utilisant Git et le serveur Gitlab de l'UTC.

Côté client (Linux)

La salle machine sera équipée de PC sous Linux, avec les logiciels suivants :

Côté serveur (Linux)

Les étudiants auront aussi un accès à un serveur sous Linux avec :

  • Apache avec module PHP

  • PosgreSQL

  • Oracle