UNIVERSITE “POLITEHNICA” DE BUCAREST FACULTE D’INGE NIERIE EN LANGUE S ETRANGERES MANAGEMENT, INNOVATION ET TECHNOLOGIE DES SYSTEMES COLLABORATIFS… [607250]

UNIVERSITE “POLITEHNICA” DE BUCAREST
FACULTE D’INGE NIERIE EN LANGUE S ETRANGERES
MANAGEMENT, INNOVATION ET
TECHNOLOGIE DES SYSTEMES
COLLABORATIFS

PROJET DE FIN D’ETUDE

Etudiant:
Elena – Loredana AVRAM
Coordinateur (Tuteur) :
Prof.dr.ing . George DRAGOI

UNIVERSITE “POLITEHNICA” DE BUCAREST
FACULTE D’INGENIERIE EN LANGUES
ETRANGERES
MANAGEMENT, INNOVATION ET
TECHNOLOGIE DES SYSTEMES
COLLABORATIFS

Architecture d’une application de gestion
pour une université

Coordinat eur (Tuteur): Etudiant:
Prof.dr.ing . George DRAGOI Elena – Loredana AVRAM

Bucarest
2017

UNIVERSITE “POLITEHNICA” DE BUCAREST
FACULTE D’INGENIERIE EN LANGUE S ETRANGERES
MANAGEMENT, INNOVATION ET TECHNOLOGIE
DES SYSTEMES COLLABORATIFS

Aprouvé
Directeur de départment:
Prof. dr. ing. George DRAGOI

SUJET DU PROJET DE F IN D’ETUDE POUR :
Elena – Loredana AVRAM

1. Titre du thème (du sujet):
Architecture d’une application de gestion pour une université

2. Données initiales de c onception:
Le besoin d’une application pour gérer les courses et horaires d’une faculté

3. Contribution de l’étudiant:
– Conception de la base de donnees
– Conception des diagrammes fonctionnelles
– Conception de l ’interface utilisateur

4. Matériel graphique obligatoire:
Schéma base de données , diagrammes fonctionnels , structure interface utilisateur

5. Le mémoire est basé sur les connaissances acquises au fil des études des suivants cours:
Management des systèmes informatiques, Technologies web et développement , Systèmes
adaptifs et collaboratifs , Interface homme -machine

6. L’environnement de développement de l’ouvrage :
SQL Developper, DBSchema

7. Ce projet serve à:
Projet final études master

8. Délai de l’ouvrage :
Septembre 2017

Coordinateur (Tuteur) du projet Etudiant :
Prof. dr. ing . George DRAGOI Elena -Loredana AVRAM

Academic Honesty Statement (Déclaration d’honnêteté académique)

Je, soussigné , Elena – Loredana AVRAM déclare que le proje t de fin d’étude ayant le titre
Architecture d’une application de gestion pour une université , qui est soutenu pub lique devant le
jury pour les PFE’s à l’Université “POLITEHNICA” de Bucarest, Faculté d’Ingénierie en Langues
Etrangères, en vue d'obtenir le grade d’ingénieur, est le résultat de mon propre travail, basé sur mes
travaux .
Le mémoire de la thèse, les simul ations, les expériences et les mesures qui sont présentés
est entièrement réalisé par moi-même sous la direction de mon tuteur sans l’implication d’autres
personnes qui ne sont pas cités par leur nom et leur contribution dans la partie Remerciements.
Tout es les sources et les ressources utilisées sont indiquées dans les références du mémoire de
thèse et mentionnées au fil du mémoire.
Le projet n’a jamais été présenté à un établissement d’enseignement supérieur ou institut
de recherche dans le pays ou à l ’étranger.
Toutes les informations utilisées, y compris les ressources d’Internet, sont obtenues à
partir des sources qui ont été cités et indiqués dans les notes et dans la bibliographie en
conformité avec les normes éthiques. Je comprends que le plagiat est une infraction et il est
punissable en vertu de la loi.
Les résultats des modélisations, des simulations, des expériences et des mesures sont
authentiques. Je comprends que la falsification des données et des résultats constitue une fraude
et est pun i conformément à la réglement ation et aux lois existantes.

Elena -Loredana AVRAM 12. 09. 2017

Sommaire

1 Introduction ………………………….. ………………………….. ………………………….. ……………………….. .
1.1. Motivation
1.2. Objectifs
1.3. Avantages
2 Présentation du domaine ………………………….. ………………………….. ………………………….. …….. .
2.1. Base de donnees – generalites
2.2. Roles dans l'environnement de base de donnees
2.3. Langage de base de donnees
2.4. Composants c onceptuels
2.5. Composants logiques/physiques
2.6. Etat de l'art
3 Architecturde l ’application ………………………….. ………………………….. ………………………….. ….. .
3.1. Description
3.2. Diagrammes
3.3. Schema d e la base de donnees
3.4. Arhitecture du systeme
3.5. Conception de l'interface
4. Conclusions ………………………….. ………………………….. ………………………….. ………………………. .
References ………………………….. ………………………….. ………………………….. ………………………….. .. .

1. Introduction

1.1. Motivation

La création d'une application comportant des bases de données présente des potentiels et
avantages dans tous les secteurs y compris également celui de la gestion d'une université.

L’Université Politehnica de Bucarest rencontre des soucis liés à la gestion de leurs
enseignants et les cours à dispenser.

Il leur faut beaucoup de temps pour saisir des énormes quantités de données en utilisant MS
Excel qui est si difficile à utiliser, où l'utilisateur doit mémoriser toutes les fonctionnalités de
l'outil et ce n'est pas facile et peut être les résultats de différentes erreurs ce qui occasionne des
retards dans leur travail.

Ce travail a été conçu afin de donner une solution qui peut résoud re des tels problèmes.

Pour réaliser ce travail de recherche, on a dû recourir au prototype modèle qui nous a permis
d'aborder les différentes étapes de la création d'un logiciel à savoir l'analyse, la conception, le
développement et la mise en oeuvre du logiciel.

A l'issue de cette recherche, on a proposé un logiciel qui permettra à l'université d'enregistrer
les informations, de gérer les enseignants ainsi que les cours à dispenser, de faire des rapports
périodiques à partir de ces informations et de gérer tout le système et faire les statistiques. Le
nouveau logiciel permettra un accès rapide aux informations.

1.2. Objectifs

Les principaux objectifs des systèmes de gestion sont les suivants:

Informatisation – Tous les détails concernant l'université, qu'ils soientt petite s ou
grande s, seront informatisés.
Pas de données redondantes – Comme ce système de gestion sera centralisé, les chances
que les données sont en double dans le système soient proches de nul.
Automation – La fonctionnalité d'automatisation de ce système de gestion atténuera la
tâche d'écriture des documents.
Interaction facile

1.3. Avantages

Par ce système de gestion, il sera plus facile pour un enseignant d'être en contact chaque jour.
En fait, il sera plus facile pour chaque personne qui est associée au système d'être en contact
selon les besoins.

Le système de gestion proposé présente plusieurs avantages:

 Communicat ion efficace entre enseignants et étudiants
 Automatisation complète de toutes les opérations
 Informations stockées centralem ent sans redondance nulle
 Interaction fréquente avec les enseignants
 Mise à jour fiable sur la participation de l'e tudiant , le rapport d'étape et le paiement des
frais.
 Suivi des de voirs assignés par l'enseignant
 Informations antérieures sur les événements universitaires et les vacances
 Participation automatisée aux étudiants
 Gestion informatisée des marques et des notes
 Travail de devoir aux étudiants et approbation
 Amélioration de l'interaction avec les enseignants
 Accès à la fréquentation, au calendrier, aux notes, aux grades et au calendrier des
examens
 Interface facile à utiliser
 Accès rapide à la base de données
 Plus de capacité de stockage
 Installation de Search

2. Presentation de domaine

2.1. Base de données – généralités

Une base de données est une collection organisée de données. C'est la collection de schémas,
de tables, de requêtes, de rapports, de vues et d'autres objets. Les données sont généralement
organisées pour modéliser les aspects de la réalité de manière à prendre en charge les processus
nécessitant des informations.
On considère qu'une base de données est une collection de données liées et un système de
gestion de base de données (SGBD) d’être le logiciel qui gère et contrôle l'accès à la base de
données. Une application de base de do nnées est simplement un programme qui interagit avec la
base de données à un moment donné de son exécution. On utilise également le système de base
de données à terme plus inclus comme une collection de programmes d'applic ation qui
interagissen t avec le SGBD et la base de données elle -même.
Un système de gestion de base de données (SGBD) est une application informatique qui
interagit avec l'utilisateur, d'autres applications et la base de données elle -même pour capturer et
analyser d es données. Un SGBD à usage général est conçu pour permettre la définition, la
création, l'interrogation, la mise à jour et l'administration de bases de données.
Le fait d'avoir un référentiel central pour toutes les données et les descriptions de données
permet au SGBD de fournir une facilité d'enquête générale à ces données, appelée langue de
requête. La fourniture d'un langage de requête atténue les problèmes liés aux systèmes basés sur
les fichiers où l'utilisateur doit travailler avec un ensemble fixe d e requêtes, ce qui entraîne des
problèmes importants de gestion de logiciels. Le langage de requête le plus courant est le langage
de requête structure (SQL – Structured Query Language ), qui est maintenant la langue formelle
et standard pour le SGBD relationnel.
Il fournit un accès contr ôlé à la base de données. Par exemple, il peut fournir:
– un système de sécurité qui empêche les utilisateurs non autorisés d ’accéder à la base de
données;
– un système d ’intégrité, qui maintient la recuperat ion des données stockées;
– un système de contrôle de la concurrence, qui permet l ’accès partagé de la base de données;
– un système de contrôle de recuperation , qui restaure la base de données suite à une panne
de logiciel;
– un catalogue accessible à l ’utilisateur, qui contient des descriptions des données dans la
base de données .

Les SGBD existants fournissent diverses fonctions qui permettent la gestion d ’une base de
données :

 Définition des données – Création, modification et suppression
 Mise à jour – Insertion, modification et suppression des données réelles.

 Récupération – Fournir des informations sous une forme dire ctement ou pour un
traitement ultérieur par d ’autres applications. Les données récupérées peuvent être mises
à disposition sous une forme essentiellement identique à celle stockée dans la base de
données ou sous une nouvelle forme obtenue en mod ifiant ou en combinant les données
existantes de la base de données.
 Administration – Enregistrement et suivi des utilisateurs, application de la sécurité des
données, suivi des performances, maintien de l ’intégrité des données, gestion du contrôle
de la concurrence et recuperation d’informations corrompues par un événement tel
qu’une défaillance inattendue du système.

Composants de l ’environnement SGBD

A. Equipement matériel

Le SGBD et les applications nécessitent un hardware pour s'exécuter. Ca peut all er d'un seul
ordinateur personnel à un seul ordinateur central ou un réseau d'ordinateurs. Il dépend des
exigences de l'organisation et du SGBD utilisé. Certains SGBD ne s'exécutent que sur un
hardware ou des systèmes d'exploitation particuliers, tandis qu e d'autres fonctionnent sur une
grande variété de systèmes matériels et d'exploitation. Un SGBD nécessite une quantité
minimale de mémoire principale et d'espace disque à exécuter, mais cette configuration minimale
peut ne pas donner nécessairement des per formances acceptables.

B. Logiciel

Le composant logiciel comprend le logiciel DBMS lui -même et les programmes
d'application, ainsi que le système d'exploitation, y compris le logiciel réseau si le SGBD est
utilisé sur un réseau. En règle générale, les prog rammes d'application sont écrits dans un langage
de programmation de troisième génération (3GL), comme C, C ++, C #, Java, Visual Basic,
COBOL, Fortran, Ada ou Pascal, ou une langue de quatrième génération (4GL), telle que comme
SQL, intégré dans une langu e de troisième génération. Le SGBD cible peut avoir ses propres
outils de quatrième génération qui permettent un développement rapide des applications grâce à
la fourniture de langages de requêtes non -procédés, des générateurs de rapports, des générateurs
de formulaires, des générateurs graphiques et des générateurs d'applications. L'utilisation d'outils
de quatrième génération peut améliorer considérablement la productivité et produire des
programmes plus faciles à entretenir.

C. Les données

Peut-être le co mposant le plus important de l'environnement SGBD – certainement du point
de vue des utilisateurs finaux – sont les données. Les données servent de pont entre les
composants de la machine et les composants humains. La base de données contient à la fois les

données opérationnelles et les métadonnées, les "données sur les données". La structure de la
base de données s'appelle le schéma, qui comprend des tableaux, chaque table comportant des
champs (attributs).

D. Procédures

Les procédures se rapportent aux ins tructions et aux règles qui régissent la conception et
l'utilisation de la base de données. Les utilisateurs du système et le personnel qui gèrent la base
de données nécessitent des procédures documentées sur la façon d'utiliser ou d'exécuter le
système. I l peut s'agir d'instructions sur la façon de:
• Connecter au SGBD.
• Utiliser un système de SGBD ou un programme d'app lication particulier.
• Démarrer et arrête le SGBD.
• Effectuer des copies de sauvegarde de la base de données.
• Défaillance du logi ciel. Cela peut inclure des procédures sur la façon d'identifier le composant
défectueux, comment réparer le composant défectueux (par exemple, téléphoner à l'ingénieur
matériel approprié) et, suite à la réparation du défaut, comment récupérer la base de d onnées.
• Modifier la structure d'une table, réorganisez la base de données sur plusieurs disques,
améliorez les performances ou archivez des données dans un stockage secondaire.

2.2. Rôles dans l'environnement de base de données

2.2.1. Administrateurs de données e t de base de données

L'administrateur de données (DA) est responsable de la gestion de la ressource de données, y
compris la planification de la base de données, élaboration et maintenance de normes, de
politiques et de procédures et la conception de la b ase de données conceptuelle / logique. La DA
consulte et conseille les cadres supérieurs, en veillant à ce que la direction du développement de
la base de données soit en fin de compte liée aux objectifs de l'entreprise.
L'administrateur de la base de données (DBA) est responsable de la réalisation physique de
la base de données, y compris la conception et la mise en œuvre de la base de données physique,
le contrôle de la sécurité et de l'intégrité, la maintenance du système opérationnel et une
perfo rmance satisfaisante des applications pour les utilisateurs. Le rôle du DBA est plus orienté
techniquement que le rôle de la DA, nécessitant une connaissance détaillée du SGBD cible et de
l'environnement système. Dans certaines organisations, il n'y a pas de distinction entre ces deux
rôles; dans d'autres, l'importance des ressources de l'entreprise se reflète dans la répartition des
équipes de personnel dédiées à chacun de ces rôles.

2.2.2. Concepteurs de bases de données

Le concepteur de base de données logiqu e s'occupe d'identifier les données (c'est -à-dire les
entités et les attributs), les relations entre les données et les contraintes sur les données qui
doivent être stockées dans la base de données. Le concepteur de base de données logique doit
avoir une c ompréhension complète et complète des données de l'organisation et des contraintes
sur ces données (les contraintes sont parfois appelées règles métier). Ces contraintes décrivent les
principales caractéristiques des données vues par l'organisation .
Le con cepteur de base de données physique décide de la réalisation physique de la
conception de la b ase de données logique. Cela implique:
• mapper la conception de la base de données logique dans un ensemble de tables et des
contraintes d'intégrité;
• sélectionn er des structures de stockage spécifiques et des méthodes d'accès pour les données
afin d'obtenir de bonnes performances;
• concevoir toutes les mesures de sécurité requises sur les données.

2.2.3. Développeurs d'applications

Une fois la base de données impléme ntée, les programmes d'application qui fournissent la
fonctionnalité requise pour les utilisateurs finaux doivent être mis en œuvre. C'est la
responsabilité des développeurs d'applications. En règle générale, les développeurs d'applications
travaillent à p artir d'une spécification produite par des analystes de systèmes. Chaque programme
contient des instructions qui demandent au SGBD d'effectuer une opération sur la base de
données, qui comprend la récupération des données, l'insertion, la mise à jour et la suppression
des données .

2.2.4. Les utilisateurs finaux

Les utilisateurs finaux sont les «clients» de la base de données, qui ont été conçus et mis en
œuvre et sont maintenus pour répondre à leurs besoins d'information. Les utilisateurs finaux
peuvent être cla ssés selon la manière dont ils utilisent le système:
 Les utilisateurs Naïves ignorent généralement le SGBD. Ils accèdent à la base de
données par des programmes d'application spécialement écrits qui tentent de rendre
les opérations aussi simples que possi ble. Ils invoquent les opérations de la base de
données en entrant des commandes simples ou en choisissant des options à partir d'un
menu. Cela signifie qu'ils n'ont besoin de rien savoir de la base de données ou du
SGBD. Par exemple, l'assistant de caisse au supermarché local utilise un lecteur de
code à barres pour connaître le prix de l'article. Cependant, il existe un programme
d'application présent qui lit le code à barres, recherche le prix de l'élément dans la
base de données, réduit le champ de la b ase de données contenant le nombre de ces
articles en stoc k et af fiche le prix .

 Utilisateurs sophistiqués. À l'autre extrémité du spectre, l'utilisateur final sophistiqué
connaît la structure de la base de données et les fonctionnalités offerte s par le SGBD.
Les utilisateurs finaux sophistiqués peuvent utiliser un langage de requête de haut
niveau tel que SQL pour effectuer les opérations requises. Certains utilisateurs finaux
sophistiqués peuvent même écrire des programmes d'application pour le ur propre
usage.

2.3. Langages de base de données

Langage de requête de données (DQL) : Déclarations qui interroge la base de données mais
ne modifient pas les données ou les objets de base de données. Cette catégorie contient
l'instruction SELECT.

Langage de définition de données (DDL) : Une langue qui permet au DBA ou à l'utilisateur
de décrire et de nommer les entités, les attributs et les relations requis pour l'application, ainsi
que toute contrainte d'intégrité et de sécurité associée .
Le schéma de la base de données est spécifié par un ensemble de définitions exprimées au
moyen d'une langue spéciale appelée Langue de définition de données. Le DDL est utilisé pour
définir un schéma ou pour modifier celui existant. Il ne peut pas être utilisé pour manip uler des
données. Les DDL sont des déclarations qui créent et modifient des objets de base de données.
Alors que DML et DQL fonctionnent avec les données dans les objets de la base de données,
DDL fonctionne avec les objets de la base de données eux -mêmes. En d'autres termes, DDL gère
les conteneurs de données tandis que DML gère les données à l'intérieur des conteneurs. Cette
catégorie comprend les instructions CREATE, ALTER et DROP.

Langage de manipulation des données (DML) : une langue qui fournit un ensemble
d'opérations pour prendre en charge les opérations de base de manipulation de données sur les
données contenues dans la base de donnée s. Déclarations qui modifient les données stockées
dans les objets de la base de données (c'est -à-dire les tab les). Cette catégorie contient les
instructions INSERT, UPDATE et DELETE.
Les opérations de manipulation de données comprennent habituellement les éléments
suivants:
 insertion de nouvelles données dans la base de données;
 modification des données stockées dans la base de données;
 récupération des données contenues dans la base de données;
 suppression des données de la base de données

Data Control Language (DCL) : Déclarations qui gèrent les privilèges que les utilisateurs de
la base de données ont co ncernant la base de données et les objets stockés dans celui -ci. Cette
catégorie comprend les déclarations GRANT et REVOKE.

2.4. Composants conceptuels dans la base de données

2.4.1. Entités

Une entité (ou une classe d'entité) est une personne, un lieu, une chose, un événement ou un
concept concernant les données collectées. En d'autres termes, les entités sont les choses réelles
dans lesquelles nous avons suffisamment d'intérêt pour capturer et stocker des données dans une
base de données. Une e ntité est représentée comme un rectangle dans le schéma . Pendant
l'exécution, chaque instance d'objet d'entité représente une ligne dans la table de base de données
et stocke ses données. Il n'y a qu'une seule instance par ligne et toutes les instances de la même
classe d'objet d'entité sont mises en cache ensemble.

2.4.2. Les attributs

Un attribut est un fait unitaire qui caractérise ou décrit une entité d'une manière ou d'une
autre. Ceux -ci sont représentés sur le diagramme de conception comme noms dans le rectangle
qui représente l'entité à laquelle ils appartiennent.
L'attribut ou les attributs qui apparaissent en haut du rectangle (au -dessus de la ligne horizontale)
forment l'identifiant unique pour l'entité. Un identifiant unique, comme son nom l'ind ique,
fournit une valeur unique pour chaque instance de l'entité. On dit que les attributs sont un fait

d'unité parce qu'ils doivent être atomiques, ce qui signifie qu'ils ne peuvent être divisés en unités
plus petites de manière significative. Un attribut est donc l'unité de données la plus petite
nommée qui apparaît dans un système de base de données.

2.4.3. Relations

Les relations sont les associations entre les entités. Étant donné que les bases de données
concernent le stockage de données connexes, l es relations deviennent la colle qui contient la base
de données ensemble. Les relations sont présentées sur le diagramme de conception en tant que
lignes reliant une ou plusieurs entités.
Elles sont de plusieurs types :

 Relation one -to-many
Une relation one-to-many est une association entre deux entités dans lesquelles toute
instance de la première entité peut être associée à une ou plusieurs instances de la seconde, et
toute instance de la seconde entité peut être associée à au plus une instance de la p remier.

 Relation one -to-one
Une relation one -to-one est une association dans laquelle une instance d'une entité peut être
associée à au plus une instance de l'autre entité et vice versa.

 Relation many -to-many
Une relation many -to-many est une associ ation entre deux entités dans lesquelles toute
instance de la première entité peut être associée à zéro, une ou plusieurs instances de la seconde
et vice versa.
Les relations many -to-many sont assez communes, et la plupart d'entre elles auront des
données d'intersection. La mauvaise nouvelle est que le modèle relationnel ne soutient pas
directement des relations multiples. Il n'y a aucun problème à avoir des relations many -to-many
dans un design conceptuel, car une telle conception est indépendante de toute technologie
particulière.
Toutefois, si la base de données va être relationnelle, des modifications doivent être
apportées lorsque vous mappez le modèle conceptuel au modèle logique correspondant. La
solution consiste à mapper les données d'intersection vers une table séparée (une table
d'intersection) et la relation many -to-many à deux relations individuelles avec la table
d'intersection au milieu et sur le côté "plusieurs" des deux relations.

2.4.4. Règles d'affaires

Une business rule est une politique, une procédure ou une norme adoptée par une
organisation. Les règles sont très importantes dans la conception de la base de données car elles
dictent les contrôles qui doivent être placés sur les données.
La plupart des règles peuvent être appliqué es par des procédures manuelles que les employés
doivent suivre ou la logique placée dans les programmes d'application. Cependant, chacun de ces
éléments peut être contourné: les employés peuvent oublier ou choisir de ne pas suivre une
procédure manuelle, et les bases de données peuvent être mises à jour directement par des
personnes autorisées, en contournant les contrôles inclus dans les programmes d'application. La
base de données peut servir très bien comme la dernière ligne de défense.
Les règles peuv ent être implémentées dans la base de données sous la forme de contraintes,
qui sont formellement définies des règles qui restreignent certaines données dans la base de
données .

2.5. Composants de conception logiques / physiques

Au cour s de la conception logique des bases de données, les propriétés physiques de stockage
(nom de fichier ou espace de table, emplacement de stockage et informations de
dimensionnement) peuvent être affectées à chaque objet de base de données car ils sont clas sés à
partir du modèle conceptuel, ou ils peuvent être omis d'abord et ajoutés plus tard dans un
document physique étape de conception qui suit la conception logique. Pour l'efficacité du
temps, la plupart des DBA effectuent les deux étapes de conception ( logiques et physiques) en
parallèle.

2.5.1. Tables

L'unité principale de stockage dans le modèle relationnel est la table, qui est une structure
bidimensionnelle composée de lignes et de colonnes. Chaque ligne correspond à une occurrence
de l'entité que représe nte la table et chaque colonne correspond à un attribut pour cette entité .

2.5.2. Colonnes et types de données

Chaque colonne dans une table relationnelle représente un attribut du modèle conceptuel. La
colonne est l'unité de données la plus petite nommée qui peut être référencée dans une base de
données relationnelle.
Chaque colonne doit recevoir un nom unique (dans la table) et un type de données. Un type
de données est une catégorie pour le format d'une colonne particulière.

Les types de données fournissent plusieurs avantages:

● Restriction des données dans la colonne aux caractères qui ont un sens pour le type de
données (par exemple, tous les chiffres ou uniquement les dates valides du calendrier).
● Fournir un ensemble de comportements utiles à l'uti lisateur de la base de données. Par
exemple, si vous soustrayez un numéro d'un autre numéro, vous obtenez un nombre en
conséquence; mais si vous soustrayez une date d'une autre date, vous obtenez un nombre
représentant les jours écoulés entre les deux date s en conséquence.
● Assistance au RDBMS pour stocker efficacement les données de la colonne. Par
exemple, les nombres peuvent souvent être stockés dans un format numérique interne qui permet
d'économiser de l'espace, par rapport au simple stockage des ch iffres comme une chaîne de
caractères.

2.5.3. Contraintes

Une contrainte est une règle placée sur un objet de base de données (généralement une table
ou une colonne) qui restreint d'une façon ou d'une autre les valeurs de données autorisées pour
cet objet de ba se de données. Ceux -ci sont les plus importants dans les bases de données
relationnelles dans la mesure où les contraintes sont la façon dont nous implémentons les
relations et les règles métier spécifiées dans la conception logique. Chaque contrainte reço it un
nom unique pour permettre son référencement dans les messages d'erreur et les commandes de
base de données subséquentes.
Les contraintes imposent des limites aux données ou au type de données pouvant être
insérées / mises à jour / supprimées d'une ta ble. Le but de toutes les contraintes est de maintenir
l'intégrité des données au cours d'une mise à jour / suppression / insertion dans une table.

Types :
o La contrainte NOT NULL s'assure qu'une colonne ne contient pas la valeur NULL.
Lorsqu’on ne fourn isse pas de valeur pour une colonne particulière lors de l'insertion d'un
enregistrement dans une table, la valeur NULL est par défaut. En spécifiant la contrainte NULL,
nous pouvons être sûrs qu'une colonne (s) particulière (s) ne peut pas avoir des valeu rs NULL.
o La contrainte UNIQUE oblige une colonne ou un ensemble de colonnes à avoir des
valeurs uniques. Si une colonne a une contrainte unique, cela signifie qu'une colonne particulière
ne peut pas avoir des valeurs en double dans une table.
o La contra inte DEFAULT fournit une valeur par défaut à une colonne lorsqu'il n'y a pas
de valeur fournie lors de l'insertion d'un enregistrement dans une table.
o La contrainte CHECK est utilisée pour spécifier une plage de valeurs pour une colonne
particulière d'un e table. Lorsque cette contrainte est définie sur une colonne, elle garantit que la
colonne spécifiée doit avoir la valeur dans la plage spécifiée.
o La contrainte de clé primaire identifie de manière unique chaque enregistrement dans
une table. Il doit av oir des valeurs uniques et ne peut pas contenir de nulls.

o Les clés étrangères sont les colonnes d'une table qui indique la clé principale d'une autre
table. Ils constituent un renvoi entre les tableaux.
o La contrainte INDEX est utilisée pour créer et ex traire des données de la base de données
très rapidement. Un index peut être créé en utilisant un seul ou un groupe de colonnes dans une
table.

2.5.4. Vues

Une vue est une requête de base de données stockée qui fournit à un utilisateur de base de
données un so us-ensemble personnalisé des données d'une ou plusieurs tables dans la base de
données. D'autre part, une vue est une table virtuelle, car elle ressemble à une table et, pour la
plupart, elle se comporte comme une table, mais elle ne stocke aucune donnée ( seule la requête
de définition est stockée).
Les vues servent un certain nombre de fonctions utiles:
● Cacher les colonnes que l'utilisateur n'a pas besoin de voir (ou ne devrait pas être autorisé à
voir)
● Cacher les lignes des tables qu'un utilisateur n'a pas besoin de voir (ou ne devrait pas être
autorisé à voir)
● Cacher les opérations de base de données complexes telles que les jointures de table
● Améliorer les performances des requêtes

2.6. Etat de l’art

Une méthode pour développer un système informatique est le cycle de vie de développement
de système (SDLC), qui divise le travail en phases, comme il suit :

Planification
La phase de planification se déroule sur une période de temps plus longue que n'importe quel
projet individuel, et le plan global d'information pour l'organisation con stitue la base de laquelle
les projets devraient être lancés pour atteindre les objectifs généraux.
Les activités de la base de données dans cette phase impliquent l'examination des options de
SGBD et la détermination de savoir si les technologies actuelle ment utilisées répondent aux
besoins globaux du projet .

Collecte des besoins
Au cours de la phase de collecte des exigences, l'accent doit être mis sur QUOI ? plutôt que
sur COMMENT. Le COMMENT ? est développé au cours des phases de conception suivantes. Il
est important pour les exigences d'inclure autant que possible sur les processus existants et
attendus, les business rules et les entités. Plus le travail est effectué dans les premiers stades d'un
projet, plus les étapes suivantes se déroulent plus fac ilement.

Design conceptuel
La phase de design conceptuel consiste à concevoir les éléments externes de l'application et
de la base de données. La mise en page des rapports, des écrans, des formulaires, des pages Web
et d'autres véhicules d'entrée et de pr ésentation de données sont finalisées au cours de cette
phase. En outre, le flux de l'application externe est documenté sous la forme d'un organigramme,
d'un storyboard ou d'un diagramme de flux d'écran. Cela aide à comprendre le flux logique du
système.

Conception logique
Pendant la conception logique, la plupart de la conception technique de l’application et bases
de données incluses dans le projet est effectuée. De nombreuses méthodologies appellent cette
phase de conception – interne, car elle implique la conception des internes du projet que les
utilisateurs ne verront jamais.

Conception physique
Au cours de la phase de conception physique, la conception logique est mappée ou convertie
au logiciel matériel et système réel qui sera utilisé pour impléme nter l'application. Du côté du
processus, peu ou rien doit être fait si les spécifications de l'application ont été rédigées d'une
manière qui peut être directement implémentée. Cependant, il faut beaucoup de travail pour
spécifier le matériel sur lequel l 'application sera installée, y compris les estimations de capacité
pour les processeurs, les périphériques de disque et la bande passante réseau sur laquelle le
système fonctionnera.
Du côté de la b ase de données, les relations qui ont été conçues dans la phase de conception
logique antérieure sont implémentées dans le SGBD à utiliser. En particulier, Data Definition
Language (DDL) est codé ou généré pour définir les objets de la base de données, y compris les

clauses SQL qui définissent le stockage physiq ue des tables et des index.

Construction
Pendant la phase de construction, les développeurs d'applications codent et testent les
différentes unités de programmation. Les unités de programme testées sont promues dans un
environnement de test système, où l' ensemble du système d'application et de base de données est
assemblé et testé de bout en bout.

Implémentation et déploiement
La mise en œuvre consiste à installer les composants du nouveau système d'application
(programmes d'application, formulaires ou pages Web, rapports, objets de base de données, etc.)
dans le système en direct et effectuer toutes les conversions de données requises. Le déploiement
consiste à placer les groupes d'utilisateurs professionnels sur la nouvelle application.

Support contin u
Une fois qu'un nouveau système d'application et une base de données ont été implémentés
dans un environnement de production, le support de l'application est souvent transmis à une
équipe de support de production. Cette équipe doit être prête à isoler et à répondre à tout
problème pouvant survenir, ce qui pourrait inclure des problèmes de performance, des résultats
anormaux ou inattendus, des pannes complètes ou des demandes inévitables d'amélioration.

2.6.1. Presentation de l’application

Ce projet de la base d e do nnées pour gérer l'université permet à l'administrateur
d'enregistrer les informations quotidiennes exigées des étudiants, des enseignants et
d'autres membres du personnel.
Le système de gestion organisera le travail à l'intérieur de l'école et le syst ème proposé fera
les tâches suivantes:

o insérer et modifier les informations de l'étudiant telles que le nom, le numéro, l'adresse,
etc.
o insérer et modifier les informations de l'employé telles que le nom de l'employé, le
numéro, l'adresse
o insérer et modif ier des informations sur des cours tels que la durée, le calendrier, la
classe, les points de crédit
o insérer et modifier des informations sur chaque faculté telles que le nom, le doyen, le
nombre d'étudiants, le calendrier des cours, les coordonnées
o créer horaire pour chaque enseignant
o créer le calendrier pour chaque année dans une faculté
o chercher un enseignant et ses classes
o la rech erche d'une faculté et des cours

L’application doit gérer les suivants points:

A. Configuration de l'organisation

– Configur ation organisationnelle et détails
– Facultés, départements
– Cours
– Disponibilité
– Semestres et sujets
– Configuration de la structure du cours en fonction du contingent

B. Gestion de l'affiliation

– Détails de l'université
– Suivre les cours enregistrés
– Configurer la prise en charge
– Surveiller l'admission des étudiants
– Approbations étudiantes et allocation d'identité étudiante

C. Gestion des étudiants

– Horaire des étudiants
– Présence
– Transfert / abandon scolaire
– Promotion étudiante

D. Gestion des examens

– Calendrier des examens et méthodologie de classement
– Préparer / publier un document d'interrogation
– Téléchargement / réception du document de questions
– Télécharger les notes d’un examen
– Marquage d'examen
– Génération de grade
– Publi er un rapport d'étape / Résultats

E. Gestion du contenu

– Télécharger / Rechercher / Récupérer des documents numérisés
– Télécharger / Rechercher / Récupérer des horaires
– Configuration des événements / calendrier

F. Gestion du personnel

– Gérer l’horaire
– Gérer le nombre des cours par semaine/semestre/année
– Affectation Désignation / Direction / Départements / Sujets

G. Gestion des congés

Ce module couvre les fonctions / fonctionnalités suivantes

– Accorder les conges
– Demande de congé
– Autorisation de congé

L'administrateur est celui qui contrôle le système de gestion de l'école, son personnel et
toute autre personne ou chose qui est associée à l’université.
Dans un autre terme, l'administrateur est l'entité la plus puissante du système.
Il y aura un administra teur dans le système.
Il a le pouvoir de créer, mettre à jour ou supprimer tout enregistrement du système.
Il ou elle pourra afficher le profil de tout autre utilisateur dans le système.
L'administrateur pourra voir tous les détails s'il est lié au personn el ou à l'examen.
Chaque fois qu'un étudiant est inscrit à une faculté, une classe et la section connexe seront
attribuées par l'administrateur à l'étudiant.
Assigner un horaire aux enseignants et les étudiants seront la responsabilité
de l'administrateur.
L'administrateur accordera la désignation au personnel de l'école, comme celui qui sera
le professeur, qui sera le professeur adjoint, etc.
Il ou elle aura le pouvoir de promouvoir tout personnel de l'école.
L'administrateur approuvera la demande d'autori sation des enseignants et des étudiants.
L’application sera disponible en roumain, anglais et français.

3. Arhitecture de l’application

3.1. Description

L’application est conçu e pour une meilleure interaction entre les étudiants, les enseignants et
la direction. Ce logiciel de gestion gère très gracieusement toutes les exigences pour une gestion
facile de l'universite.
Le système de gestion de l'universite étant basé sur le Web peut être consulté partout dans le
monde, ce qui permet aux étudiants, a ux enseignants et à la direction de s'entretenir en tout
temps.

Exigences matérielles
 Processeur
 RAM
 Disque dur
 Connexion Internet
 Exigences logicielles
 Système d'exploitation (Windows, Linux, Mac)
 Serveur de base de données
 Langue (html)
 Navigateur com patible

Exigences fonctionnelles
 Le système de gestion doit être une base de réseau.
 L'administrateur doit se connecter.
 L'administrateur doit ajouter un nouvel enseignant et une classe et les modifier.
 L'administrateur doit mettre à jour les nouvelles de l'universite .
 L'administrateur doit accéder à to utes les données relatives aux enseignants .
 L'administrateur doi t gérer l'activité universitaire .
 L'administrateur génère un calendrier.
 L'enseignant doit se connecter.
 L'enseignant doit com muniquer avec l 'administrateur
 L'enseignant doit assigner des tâches.
 L'enseignant doit marquer la présence en ligne.
 L'enseignant doit déclarer son résultat en ligne.

Exigences non fonctionnelles
 Le système devrait être facile à utiliser.
 Le système devrait être disp onible 24h / 24.
 Le système devrait répondre à l'heure
 Le système devrait fournir des informations spécifiques à un utilisateur spécifique.
 Le système ne doit pas échouer.
 Une bonne inf ormation est disponible pour l'enseignant au bon moment.

3.2. Diagramme s UML

UML ( Unified Modeling Language ) est généralement défini comme «une langue standard
pour spécifier, construire, visualiser et documenter les artefacts d'un système logiciel». Par
rapport à l'utilisation de plans architecturaux dans l'industr ie de la construction, l'UML fournit
une langue commune pour décrire les modèles logiciels. L'UML ne prescrit aucune
méthodologie particulière, mais est flexible et adaptable à n'importe quelle approche et peut être
utilisé en conjonction avec une large ga mme de cycles de vie de logiciel et de processus de
développement. Les principaux objectifs de la conception de l'UML étaient les suivants:

 Fournir aux utilisateurs un langage de modélisation visuelle express, prêt à l'emploi, afin
qu'ils puissent dévelop per et échanger des modèles significatifs.
 Fournir des mécanismes d'extensibilité et de spécialisation pour étendre les concepts de
base. Par exemple, l'UML fournit des stéréotypes, qui permettent de définir de nouveaux
éléments en étendant et en affinant la sémantique des éléments existants.
 Être indépendant des langages de programmation particuliers et des processus de
développement.
 Fournir une base formelle pour comprendre le langage de modélisation.
 Encourager la croissance du marché des outils orientés objet.
 Soutenir les concepts de développement de niveau supérieur tels que les collaborations,
les cadres, les modèles et les composants.
 Intégrer les meilleures pratiques.

UML dé finit un certain nombre de diagrammes, dont les principaux peuvent être divisés en
deux catégories suivantes:
 Diagrammes structurels, qui décrivent les relations statiques entre les composants.
– diagrammes de classe,
– diagrammes d'objets,
– diagrammes de composants ,
– diagrammes de déploiement.

 Diagrammes comportementaux, qui décrivent les relations d ynamiques entre les
composants.
– diagramme en cas de l'utilisation ,
– diagrammes de séquence,
– diagrammes de collaboration,
– diagramme s d'état,
– diagrammes d'activité.

3.2.1. Taxonomy

Un vocabulaire définit la sémantique des types d'entités et de leurs responsabilités, les
relations taxonomiques entre les types d'entités et les relations ontologiques entre les types
d'entités. L a sémantique n'est qu'un simple mot pour le sens: quand on définit la sémantique de
quelque chose, nous définissons sa signification.
Les taxonomies sont des classifications des types d'entités en hiérarchies. L'ontologie va au –
delà de la taxonomi e. Lorsque la taxonomie traite des hiérarchies de classification, l'ontologie
représentera et communiquera des connaissances sur un sujet ainsi qu'un ensemble de relations et
de propriétés qui tiennent pour les entités comprises dans ce sujet.
Le sc hema ci -dessous represent une taxonomy pour les personnes d’une universit é:

3.2.2. Diagrammes de composant et de déploiement

Les diagrammes de composants décrivent l'organisation et les dépendances entre les
composants matériels physiques, tels que l e code source, le code d'exécution (binaire) et les
exécutables. Par exemple, un diagramme de composants peut illustrer la dépendance entre les
fichiers source et les fichiers exécutables, similaire aux informations contenues dans makefiles,
qui décrivent les dépendances du code source et peuvent être utilisées pour compiler et lier une
application. Un composant est représenté par un rectangle avec deux onglets chevauchant le bord
gauche.
Les diagrammes de déploiement représentent la configuration du système d'exécution,
montrant les noeuds matériels, les composants qui s'exécutent sur ces noeuds et les connexions
entre les nœuds. Un noeud est représenté par un cube tridimensionnel. Les diagrammes de
composants et de déploiement peuvent être combinés, comme il suit :

3.2.3. Use case diagram

Le schéma de cas de l'utilisation est de capturer l'aspect dynamique d'un système.
Les diagrammes de cas d'utilisation sont utilisés pour rassembler les exigences d'un système
incluant des influen ces internes et externes. Ces exigences sont principalement des exigences de
conception. Par conséquent, lorsqu'un système est analysé pour rassembler ses fonctionnalités,
les cas d'utilisation sont préparés et les acteurs sont identifiés. Lorsque la tâche initiale est
terminée, les diagrammes de cas d'utilisation sont modélisés pour présenter la vue extérieure.

En bref, les objectifs des diagrammes de cas d'utilisation peuvent être considérés comme suit:
 Utilisé pour rassembler les exigences d'un système .
 Utilisé pour obtenir une v ue extérieure d'un système.
 Identifier les facteurs externes et internes qui influencent le système.
 Montrer que l'interaction entre les exigences sont des acteurs.
Ci-dessous, une diagramme en ca s d’utilisation pour une facult é:

3.2.4. Diagramme de s équence

Un schéma de séquence modélise les interactions entre les objets dans le temps, capturant le
comportement d'un cas d'utilisation individuel. Il montre les objets et les messages passés entre
ces objets dans le cas d'utilis ation. Dans un diagramme de séquence, les objets et les acteurs sont
représentés sous forme de colonnes, avec des lignes de vie verticales indiquant la durée de vie de
l'objet dans le temps.
Une activation / mise au point de contrôle, qui indique qua nd l'objet effectue une action, est
modélisée comme une boîte rectangulaire sur la ligne de vie; une ligne de vie est représentée par
une ligne pointillée verticale s'étendant à partir de l'objet. La destruction d'un objet est indiquée
par un X au point ap proprié de sa ligne de vie.
Ci-dessous, une diagramme de sequence pour une facult é:

3.2.5. Diagramme de classe

Avec la popularité croissante des langages de programmation orientation objet , le langage
unifié de modélisation (UML) est devenu plus populaire. UML est une langue de spécification
visuelle standa rdisée pour la modélisation d'objets qui comprend une notation graphique utilisée
pour créer un modèle abstrait d'un système, connu sous le nom de modèle UML.
UML possède 13 types de diagrammes qui peuvent être utilisés pour modéliser le
comportemen t et la structure du système. Cependant, celui qui intéresse les modélisateurs de

données est le schéma de classe. Bien que les différences de notation soient manifestement
évidentes, un individu spécialisé dans la lecture des diagrammes ER peut facilement s'adapter.
Voici quelques points clés concernant les entités de modélisation utilisan t des diagrammes de
classes UML :

 Chaque entité est représentée comme classe d'objet dans un rectangle. Le symbole <<
Entité >> est inclus avec le nom de la classe pour d ésigner le type de classe.
 Les identificateurs uniques (clés primaires) ne sont pas affichés dans les diagrammes de
classes; ils sont spécifi és ailleurs dans le modèle UML.
 Les clés étrangères ne sont pas affichées car elles ne sont pas utilisées dans des systèmes
orientés objet.
 Les attributs sont affichés avec un nom et un type (séparés par deux points
 Les relations sont présentées avec des lignes.
 La cardinalité et l'option sont affichées avec un symbole combiné près de la fin de la
ligne.
 Le symbole du diamant à la fin d'une ligne de relation indique ce que l'UML app elle une
agrégation. Une agrégation est une dépendance entre deux types d'entité requis pour
l'existence de l'entité dépendante. Si la dépendance est toujours une seule entité, le
diamant est présenté comme un diamant sol ide au lieu d'un élément creux.
 La généralisation et la spécialisation (super types et sous -types) sont indiquées en
utilisant une ligne entre les deux entités avec une flèche creuse orientée vers la classe
générale (le super type).
Ci-dessous, une diagramme de classe pour une facult é:

3.3. Schéma de la base de données – Entity Relationship Mo deling

La modélisation de l a relation d'entité est le processus de représentation visuelle des entités,
des attributs et des relations pour produire le ERD.
Le processus est de nature itérative, car les entités sont découvertes tout au long du processus
de conception. Le principal a vantage des ERD est qu'ils peuvent être compris par des personnes
non techniques tout en offrant une grande valeur aux techniciens. Fait correctement, les ERD
sont indépendants de la plate -forme et peuvent même être utilisés pour les bases de données non
relationnelles si désiré .
Voici les éléments communs à tous les formats ERD:

 Les entités sont représentées sous fo rme de rectangles ou de boîtes.
 Les relations sont représentées comme des lignes.
 La ligne se termine (ou les symboles à côté d'eux) indiquent la cardinalité maximale de la
relation ( c'est-à-dire une ou plusieurs).
 Les symboles proches de la ligne se terminent (dans la plupart des formats ERD)
indiquent la cardinalité minimale de la relation (c'est -à-dire si la participation à la relation
est ob ligatoire ou facultative).
 Les attributs peuvent éventuellement être inclus (le format d'affichage des attributs varie
assez) .

3.3.1. Schema de la base de donn ées

3.3.2. Création des tables

La première étape dans la conception de la base de données physique est de cartographier les
relations présentées dans la conception logique aux tables. L'importance de cette étape devrait
être évidente car les tableaux sont la principale unité de stockage dans les bases de données
relationnelles.
Cependant, si un travail adéquat a été mis dans la conception logique, la traduction à un
design physique est beaucoup plus facile.
En bref, le processus se déroule comme il suit:

 Chaq ue relation devient une table.
 Chaque attribut dans la relation devient une colonne dans la table correspondante.
La colonne est la plus petite division de données significatives dans la base de données,
de sorte que les colonnes ne doivent pas avoir de sous -composants qui ont un sens par elles –
mêmes. Pour chaque colonne, il f aut spécifier:
 Un nom de colonne unique dans le tableau.
 Un type de données et, pour certains types de données, une longueur et une précision.
 Si les valeurs des colonnes sont requises ou non. Cela prend la forme d'une clause NULL
ou NOT NULL pour chaque colonne.
 Vérifier les contraintes. Ceux -ci peuvent être ajoutés aux colonnes pour appliquer des
règles métier simples.

 L'identifiant unique de la relation est défini comme la clé primaire de la table.
Les colonnes participant à la clé primaire doivent être spécifiées comme NOT NULL et
dans la plupart des SGBDR, la définition d'une contrainte de c lé primaire provoque la définition
automatique d'un index unique sur la (les) colonne (s) de la clé primaire. Les colonnes de clé
étrangère doivent avoir une clause NOT NULL si la relation est obligatoire; sinon, ils peuvent
avoir une clause NULL.

 Tout autre ensemble de colonnes qui doit être unique dans le tableau peut avoir une
contrainte unique définie.
Comme pour les principales contraintes de clés, les contraintes uniques dans la plupart
des SGBDR provoquent une définition automatique d'un index u nique sur la (les) colonne (s)
unique (s). Cependant, contrairement aux contraintes de clés primaires, une table peut avoir
plusieurs contraintes uniques et les colonnes dans une contrainte unique peuvent contenir des
valeurs nulles (c'est -à-dire elles peu vent être spécifiées avec la clause NULL).

 Les relations entre les relations deviennent des contraintes référentielles dans la
conception physique .

Le modèle logique peut être pour un système de base de données complet, alors que le projet
actuel peu t être une implémentation d'un sous -ensemble de ce système entier. Lorsque cela se
produit, le concepteur de base de données physique sélectionnera et mettra en œuvre uniquement
le sous -ensemble de tables nécessaires pour répondre aux besoins actuels. Voic i la conception
logiqu e pour l ’application décrite dans ce projet :

CREATE SCHEMA school;

CREATE TABLE school.Discipline (
ID_Disciplina int NOT NULL ,
Titlu varchar(25 0) ,
[Puncte credit] int ,
[Tip disciplina] varchar(50) ,
CONSTRAINT Pk_Discipline PRIMARY KEY ( ID_Disciplina )
);

CREATE TABLE school.Domeniu (
Id_domeniu int NOT NULL IDENTITY,
Nume varchar(250) ,
Desc riere varchar(512) ,
CONSTRAINT Pk_Domeniu PRIMARY KEY ( Id_domeniu )
);

CREATE TABLE school.Facultate (
Id_facultate int NOT NULL IDENTITY,
Nume varchar(250) ,
Descriere varchar(250) ,
CONSTRAINT Pk_Facultate PRIMARY KEY ( Id_facultate )
);

CREATE TABLE school.Filiera (
Id_Filiera int NOT NULL IDENTITY,
[Nivel studii] varchar(250) ,
Id_facultate int ,
CONSTRAINT Pk_Filiera PRIMARY KEY ( Id_Filiera )
);

CREATE TABLE school.Orar (
ID_orar int NOT NULL IDENTITY,
Locatie varchar(250) ,
Ora timestamp ,
Durata float ,
CONSTRAINT Pk_Orar PRIMARY KEY ( ID_orar )
);

CREATE TABLE school.[Plan de invatamant] (
Id_plan int NOT NULL ,
An int ,
Semestru int ,
Id_Disciplina int ,
CONSTRAINT [Pk_Plan de invatama nt] PRIMARY KEY ( Id_plan ),
CONSTRAINT [idx_Plan de invatamant] UNIQUE ( Id_Disciplina )
);

CREATE TABLE school.Profesori (
Id_prof int NOT NULL ,
Nume varchar(250) ,
Prenume varchar(250) ,
Titlu varchar(250) ,
CONSTRAINT Pk_Profesori PRIMARY KEY ( Id_prof )
);

CREATE TABLE school.Specializare (
Id_Specializare int NOT NULL ,
Nume varchar(250) ,
Id_domeniu int ,
Id_Filiera int ,
CONSTRAI NT Pk_Specializare PRIMARY KEY ( Id_Specializare ),
CONSTRAINT idx_Specializare_0 UNIQUE ( Id_domeniu )
);

CREATE TABLE school.Studenti (
ID_Student int NOT NULL IDENT ITY,
Nr_Matricol int ,
Nume varchar(250) ,
Prenume varchar(250) ,
CONSTRAINT Pk_Studenti PRIMARY KEY ( ID_Student )
);

CREATE TABLE school.[Cursuri,seminarii si lab] (
Id_csl int NOT NULL IDENTITY,
Tip varchar(50) ,
[Nr. total ore] int ,
Id_orar int ,
ID_Disciplina int ,
CONSTRAINT [Pk_Cursuri,seminarii si lab] PRIMARY KEY ( Id_csl ),
CONSTRAINT [idx_Cursuri,seminarii si lab] UNIQUE ( Id_orar ) ,
CONSTRAINT [Pk_Cursuri,seminarii si lab_0] UNIQUE ( ID_Disciplina )
);

3.4. Architecture du système

Un système d'information sur les étudiants , un système de gestion des étudiants, un logiciel
d'administration scolaire ou un système d'administration des étudiants est un système
d'information de gestion pour les établisseme nts d'enseignement pour gérer les données des
étudiants. Les systèmes d'information permettent d'enregistrer les étudiants dans les cours, de
documenter le classement, les relevés de notes, les résultats des tests des élèves et d'autres notes
d'évaluation, de construire les horaires des é tudiants , de suivre la fréquentation des étudiants et
de gérer de nombreux autres besoins en matière de données relatives aux étudiants dans une
école.

Un SIS ne doit pas être confondu avec un système de gestion de l'apprenti ssage ou un
environnement d'apprentissage virtuel, où les documents de cours, les affectations et les tests
d'évaluation peuvent être publiés par voie électronique.

Ces systèmes varient en taille, en portée et en capacité, à partir de paquets implémentés dans
des organisations relativement petites pour couvrir les dossiers des étudiants, des solutions à
l'échelle de l'entreprise qui visent à couvrir la plupart des aspects de la gestion de grandes
organisations multi -campus et leurs écoles en ligne avec des sites locaux importants
responsabilité. De nombreux systèmes peuvent être mis à l'échelle à différents niveaux de
fonctionnalité et peuvent généralement être configurés par leurs établissements d'accueil pour
répondre aux besoins locaux:

Maintenance et reporting des données des étudiants
Traiter les demandes des futurs étudiants
Inscription à de nouveaux étudiants et activation de la planification en ligne
Création automatique d'agendas de cours et d'enseignants
Manipuler les enregistr ements des examens, des évaluations, des notes, des notes et
des progrès scolaires
Maintien des enregistrements des absences et de la présence
Maintien des dossiers de discipline
Fournir des rapports statistiques
Communiquer les détails des élèves aux parents ou à d'autres personnes autorisées
par l'élève, par l'intermédiaire d'un portail
Services d'éducation spéciale / plan d'éducation individuelle (PEI)
Services de comptabilité et de budgétisation
Traitement de la paie pour le personnel de l'école
Rapports réglementaires et rapports pour les organismes d'accréditation

3.5. Conception de l’interface
a. Page pour ajouter, éditer ou supprimer des cours

b. Page pour ajouter un cadr e pédagogique

c. Page pour ajouter, éditer ou supprimer un cadr e pédagogique

d. Page pour ajouter un étudiant

e. Page pour ajouter, éditer ou supprimer un étudiant

f. Page pour generation de l’h oraire pour les professeurs ou les etudiants

4. Conclusions