Architectures, modèles et langages de données

Dimension: px
Commencer à balayer dès la page:

Download "Architectures, modèles et langages de données"

Transcription

1 Architectures, modèles et langages de données Ingénierie des bases de données Hypercube c,d OLAP Fascicule 2 Modèle relationnel, algèbre relationnelle et transposition du conceptuel au relationnel André Gamache 2005

2

3 Architectures, Modèles et Langages de Données Volume 1 Fascicule 1 1- Introduction 1 2- Architecture fonctionnelle du SGBD Modèle conceptuel des données 79 - Index Fascicule 2 4- Modèle relationnel : théorie et contraintes d intégrité 1 5- Algèbre relationnelle Transposition du MCD au MRD Index Volume 2 Fascicule 3 7- Langage de données SQL 1 8- Indexation, vue relationnelle et base réactive Index Fascicule 4 9- Langage de programmation et SQL Théorie de la normalisation relationnelle : les formes normales FN1 à FN Optimisation des requêtes relationnelles 117 Annexes : A- SQLoader B- Projet ALU-Nord : Script de chargement des données - Index

4 Chapitre 4 Modèle relationnel et normalisation 3

5 Chapitre 4 Modèle relationnel et normalisation 4 Chapitre 4 Modèle relationnel: théorie et contraintes d intégrité Dans ce chapitre, nous allons étudier le modèle relationnel (MRD) en abordant les bases théoriques. Afin d éviter une démarche trop désincarnée, nous introduirons les éléments d implémentation et le langage SQL-DDL pour illustrer leur utilisation dans la création d une base de données. Nous étudierons aussi plusieurs implémentations des mécanismes de validité et de cohérence pour les données inhérentes à ce modèle, débordant les technologies à la mode de l heure. Il s agit en premier d une étude du MRD et non une étude exhaustive du système Oracle. Vous y trouverez donc des notions théoriques implémentées et définies différemment selon le SGBD auquel font référence les exemples. Le SGBD Oracle est en trame de fond dans de nombreux exemples et illustrations des concepts sous-jacents au modèle relationnel. 4.1 Modèle relationnel Le modèle relationnel proposé par l article phare de Codd ( 1 ) est une représentation logique et tabulaire des données stockées et cela dans une perspective propre aux usagers. En d autres mots, les utilisateurs voient les données sous forme tabulaire sans connaître les détails de leur implémentation physique. L exploitation des données fait appel à la même vision externe des données. Les tables qui sont appelées relations dans la théorie relationnelle sont obtenues par la transformation du modèle relationnel MCD vers le modèle relationnel (MRD) selon un ensemble de règles de transposition appliquées à chaque classe et à chaque association du MCD. Une relation est implémentée par une table logique. Cette dernière est nommée dans le langage SQL par un libellé unique qui est inscrit dans le dictionnaire. L'en-tête de la table est composé des attributs de la relation. Les lignes de la table sont les tuples qui correspondent aux instances de la classe d entités représentée par la table. Il ne peut pas y avoir deux tuples identiques dans l extension d une même relation. Chaque table correspond à une sémantique précise qui peut être explicitée par une interprétation d un tuple en langage naturel. Le passage du modèle conceptuel au logique est fait selon des règles précises appliquées à chaque élément du modèle : attribut, classe, association et spécialisation. A ce stade de notre étude, le passage sera illustré par quelques modèles conceptuels simples qui permettront de justifier la structure des tables utilisées et dʹétudier les propriétés particulières au modèle relationnel. Les autres règles de passage seront étudiées dans un prochain chapitre. Exemple : Gestion des comptes bancaires individuels modélisée par le diagramme des classes UML du MCD suivant : Client nom* rue ville 1 EstProprio 1..* Compte nocompte* nomsucc solde

6 Chapitre 4 Modèle relationnel et normalisation 5 Ce MCD est capable de représenter (modéliser) les instances suivantes : Instances de Client Bérubé, des-roses, Québec Cousin, des-lilas, Lévis Vézina, des-saules, Montréal Instances de Compte c-100, Montcalm, c-200,desjardins, c-300, Plateau, c-400, Laurier, Figure 4.1 Le ou les attributs de la clé primaire de chaque classe sont identifiés par un astérisque dans le MCD. En appliquant les règles de transposition du MCD de la figure 4.1, nous obtenons le modèle relationnel (MRD) composé des deux tables ci-dessous : Client (nom*, rue, ville) Compte (nocompte*, nomsucc, solde, nom) N.B. Dans une clause SQL, le trait d'union utilisé dans le libellé d'un mot sera remplacé par le souligné puisque le premier n'est pas admissible dans la plupart des langages de définition des tables (SQL-DDL). De même, un libellé d attribut pu de classe ne peut pas avoir d accent. La règle de transposition de ce MCD simple ayant une association de type 1 à plusieurs vers le modèle relationnel ci-dessus consiste à représenter chaque classe qui participe à l'association par une table de même nom et dotée des mêmes attributs. L'association de un à plusieurs n'est pas représentée, mais plutôt simulée par l'ajout, dans la table correspondant à la classe située du côté 1..n, des attributs spécifiques à l'association et ceux de la clé primaire de la classe située du côté de la multiplicité 1. Au niveau des instances, chaque entité devient un tuple formé de valeurs scalaires. À noter que le modèle de cet exemple simple a des limites évidentes de représentation. Par exemple, la clé étant le nom du client, on ne peut pas représenter des clients ayant le même patronyme! En effet, le nom doit identifier les clients et les distinguer les uns des autres! Pour contourner cette difficulté, il faudrait choisir une autre clé, le nas par exemple, et l'ajouter aux attributs de la classe Client. Dans le modèle ci-dessus, le nom est donc présumé être la clé de la relation. La clé de la deuxième relation présume aussi que le numéro de compte bancaire est global pour une même banque, car autrement le numéro de compte ne serait pas nécessairement unique parmi les comptes des différentes succursales. Avec un MCD légèrement plus complexe doté d une association de plusieurs à plusieurs, le passage se fait selon une règle quelque peu différente. Par exemple, lorsque les contraintes de multiplicité de part et d'autre d'une association sont de plusieurs à plusieurs, chaque classe et chaque association sont respectivement transformées en une table pour chaque élément. Au total, le MRD comprend alors 3 tables. Client (nom*, rue, ville) Compte (nocompte*, nosucc, solde) EstProprio (nom*, nocompte*, dates)

7 Chapitre 4 Modèle relationnel et normalisation 6 Client nom* rue ville 1..* EstProprio dates 1..* Compte nocompte* nomsucc solde Diagramme UML de classes avec une classe d association Figure 4.1c L attribut dates représente la date de validité de la signature d un client pour le compte bancaire partagé entre plusieurs personnes. Le schéma logique de la table EstProprio qui modélise l'association comprend la clé primaire de chaque classe UML participante et les attributs propres à l'association, c est-à-dire ceux de la classe d association. Il existe aussi des règles de transformation pour les autres structures utilisées dans les MCD. Elles seront étudiées avec plus de détails dans un chapitre subséquent. Interprétation du modèle Le modèle relationnel représente parfois de façon approximative une certaine réalité organisationnelle. La sémantique du MRD est souvent précisée par une phrase qui interprète chaque association et chaque table. Par exemple la table Client dérivée du MCD de la figure 4.1 a une sémantique particulière : Un client nommé Jacques habite sur la rue des Lilas à Québec. Un client peut avoir plusieurs comptes dans une succursale bancaire et au moins un, peu importe la succursale. Un compte doit être la propriété d une seule personne. Dans ce modèle très simple, le client est présumé être identifié sans équivoque par son nom, lequel joue le rôle de clé! Il est bien sûr possible de représenter une réalité plus complexe en changeant la définition des classes et des contraintes des associations du MCD et en multipliant les tables. Conventions dʹécriture pour la relation et son extension Nous conviendrons d'une notation particulière pour désigner une relation du MRD et une autre pour référer à son extension, c est-à-dire à son contenu : a) Lorsqu il y a référence à une relation (ou table), le nom commence par une majuscule ou est entièrement en majuscules. Si la référence est faite à son extension, le nom de celle-ci commence par une minuscule ou est entièrement en lettres minuscules. De façon générale, l'extension de la relation R est notée par r(r), tandis que son schéma relationnel est noté R. On peut en pratique utiliser indifféremment dans les expressions soit le schéma Client, soit son extension client. Dans les deux cas, le système réfère aux données de la table. b) Les attributs de la clé primaire sont marqués par un astérisque ou soulignés. Les attributs de la clé primaire sont regroupés de préférence au début de la table. c) Le type des attributs - exemples : numérique, chaîne de caractères et date - n'est pas obligatoirement précisé dans le modèle relationnel (logique). Il devra l être cependant lors de la création de chaque relation. Il est parfois utile d ajouter le domaine de chaque attribut dans le MRD.

8 Chapitre 4 Modèle relationnel et normalisation 7 Par exemple, le MCD de la figure 4.1 est implémenté par les deux tables ci-dessous dans lesquelles les clés sont respectivement nom et nocompte. Voici deux extensions relationnelles valides de ce modèle : Client : Compte : nom* rue ville nocompte* nomsucc solde nom Bérubé des-roses Québec c-100 Montcalm Bérubé Cousin des-lilas Lévis c-200 Desjardins Cousin Vézina des-saules Montréal c-300 Plateau Vézina c-400 Laurier Vézina Figure 4.2 L extension de Compte (pouvant être notée compte) regroupe dans cet exemple quatre tuples valides de la table. L extension d une table est dynamique et varie donc dans le temps selon les mises à jour effectuées par les différentes applications autorisées à exploiter la base de données. L en-tête de la table est le schéma de la relation et est défini par le nom de la table et les attributs. Les tuples constituent son extension dont le nom débute par une lettre minuscule. Relation unique pour un MRD Pourquoi alors ne pas représenter toute l'information sur les clients et les comptes bancaires par une seule table au lieu de deux comme cela est préposé par les règles de transposition? Une telle approche éviterait une multiplication des tables et partant, allégerait le calcul de certaines réponses qui exigent la consultation de deux ou de plusieurs tables. Par exemple, à la figure 4.3, on a l'extension de la relation CompteClient qui contient toute l'information des deux tables précédentes. La réponse à une question du genre trouver le nom et le solde d'un client est alors obtenue par la consultation d'une seule table, soit CompteClient. CompteClient : nom* rue ville nocompte* solde nomsucc Bérubé des-roses Québec c Montcalm Cousin des-lilas Lévis c Desjardins --> Vézina des-saules Montréal c Plateau --> Vézina des-saules Montréal c Laurier Figure 4.3 Par contre, avec cette relation, le fait que la cliente Vézina ait deux comptes bancaires à des succursales différentes est représenté par deux tuples. Du même coup, il y a redondance pour les valeurs des attributs non primaires, rue et ville du client. Cette redondance peut devenir importante avec la croissance du schéma de la table et/ou l'augmentation de la taille de l'extension. Elle est une source d'erreurs en cas d'une mise à jour incomplète. En effet, la mise à jour d'une table est précédée par une recherche dont le prédicat peut être formulé de manière à ne pas retrouver tous les tuples correspondant aux comptes de Vézina. Ainsi, lorsque la propriétaire du compte c300 change d adresse et que cette modification n est enregistrée par l'application que pour ce compte, il en résulte que Vézina aura deux adresses différentes dans la base, et cela même si ce n est pas le cas dans la réalité. La base est donc devenue incohérente. Par exemple, l'application ci-dessous effectue une telle mise à jour partielle de la table CompteClient pour modifier l adresse de Vézina propriétaire du compte bancaire c300 : {Ouvrir CompteClient; nocompte = 'c300';

9 Chapitre 4 Modèle relationnel et normalisation 8 nom = ' Vézina'; -- recherche par la clé 'Vézina + c300' Lire un tuple t dans CompteClient ; Tant que ( t.nom!= 'Vézina' et t.nocompte!= 'c300') Lire un tuple t dans l extension de CompteClient; fin ; t.adresse = 'Berry'; -- mise à jour d un tuple fin } Pour éviter une mise à jour partielle de la table, et pour simplifier la programmation des applications, il suffit d'avoir deux relations plutôt qu une seule. Ainsi, l'adresse de chaque client n apparaîtra que dans un seul tuple qui sera celui maintenu à jour par l'application. En poussant le raisonnement à sa limite, nous pourrions demander pourquoi ne pas avoir que des relations binaires? Par exemple, chaque attribut de Client faisant l'objet d'une relation : ClientRue (nom*, rue)... ClientVille (nom*, ville) De toute évidence, la modélisation relationnelle avec seulement des relations binaires multiplie le nombre de relations à consulter dans le calcul d'une réponse. Par exemple, pour obtenir toute l information sur un client, il faudra consulter autant de tables qu il y a d attributs le caractérisant. Cette multiplication des lectures aura donc un effet négatif sur la performance du logiciel SGBD et sur la complexité de l application. D autre part, il suffit d imaginer une base opérationnelle ayant par exemple une table nommée Assurance définie par 20 attributs. Il est inconcevable de faire près de 20 relations lorsque quelques unes suffisent pour représenter correctement le contrat d assurance de chaque client. Certaines relations sont donc préférables (ce sont les formes dites normales) à d autres parce qu elles ont une structure qui bloque certaines anomalies potentielles pouvant apparaître en cours d'exploitation et mettre en péril l'intégrité de la base. Ces relations dites normales constituent le schéma optimal de la base. Nous verrons dans une autre section sur les formes normales comment vérifier qu une table est en forme normale et comment la transformer au besoin. Dans certains cas, la recherche des formes normales aboutit à une multiplication des relations qui alourdit le traitement subséquent. Dans la conception d une base, il faudra faire la part des choses entre la cohérence et l efficacité. Nous discuterons de cet aspect plus loin dans ce chapitre en abordant la question de la dénormalisation. Domaines des attributs : sémantique et syntaxique Chaque attribut d une relation peut avoir un domaine sémantique propre, défini comme l ensemble des valeurs atomiques (i.e. scalaires) admissibles pour valuer cet attribut (to value an attribute signifie lui assigner une valeur). Deux attributs ayant des libellés différents peuvent cependant partager le même domaine sémantique. Ils sont alors considérés compatibles. Par exemple, le schéma de la table Menage ci-dessous est défini avec deux attributs, le premier est le nas du conjoint et l'autre celui de la conjointe. Les deux attributs partagent le même domaine, soit d-nas. Le schéma peut être formulé ainsi : Menage (conjoint*:d_nas, conjointe*:d_nas)

10 Chapitre 4 Modèle relationnel et normalisation 9 Les deux attributs primaires de cette table Menage partagent le même domaine, d-nas quelle que soit la définition explicite que l on puisse donner à ce domaine. Les valeurs d un domaine partageront un même type. Par contre, il peut arriver dans certains schémas que deux attributs de même libellé aient un domaine sémantique différent. Cette situation peut engendrer des problèmes d ambiguïté qu il faudra savoir résoudre au moment de l exploitation. L extension r d une relation R sera toujours un sous-ensemble du produit cartésien du domaine des attributs : r d1 x d2 x d3 x... di Le domaine exclut la valeur nulle qui représente l absence d une valeur. Celle-ci, qui est une réalité lors de l implantation, devra être traitée de façon particulière et systématique par le SGBD. Comme un attribut ne peut pas être comparé à une valeur nulle (qui est hors domaine), il faudra représenter cette valeur particulière (le null) par un code interne nommé indicateur d absence de valeur. Ce dernier ne pourra être testé que par un prédicat spécial, le IS NULL. Souvent par abus de langage, cet indicateur est aussi appelé une valeur nulle ou null! Cette dernière est hors du domaine. Domaine syntaxique Lorsque le domaine sémantique ne peut pas être spécifié par un ensemble de valeurs (ex. les noms de client n étant pas tous connus à priori), il est remplacé par le domaine syntaxique qui correspond aux valeurs autorisées par le type des données du domaine. Ex. nom est une chaîne de caractères de type VARCHAR2(50). Toute chaîne de caractères dont la longueur est égale ou inférieure à 50 sera considérée comme une valeur du domaine nom, même s il est peu réaliste. Par exemple, la chaîne ABCDEF est une valeur autorisée! Le domaine syntaxique d un attribut est formalisé au moment de la création du schéma d une relation : Create table Client ( nas Number (8,0), nom VARCHAR2(50); <--toute chaîne de 50 car.ou moins est valide) Cette commande SQL-DDL Create table lance la création d une structure de table qui servira par la suite pour ranger des données. Les métadonnées (le schéma) qui définissent cette structure sont logées dans le dictionnaire du SGBD. Au plan logique, la table Client est composée de deux colonnes libellées respectivement nas et nom. Les données qui peuvent être rangées dans chaque colonne sont assujetties éventuellement aux contraintes imposées par le domaine de chaque attribut. Par exemple, il n est pas possible de ranger un nom dépassant les 50 caractères ou d y ranger un nas qui est une chaîne de caractères. Plusieurs attributs peuvent partager le même domaine et ses contraintes. Pour faciliter l écriture de ces domaines, il est possible de créer un domaine nommé. La commande SQL-92 CREATE DOMAIN permet de définir à la fois les domaines syntaxique et sémantique : - domaine syntaxique : CREATE DOMAIN d_nom Varchar2(50); --d_nom est le nom du domaine syntaxique - domaine sémantique (numérique dans cet exemple) : CREATE DOMAIN d_solde Number(8,2) CHECK (solde >0 and solde < = );

11 Chapitre 4 Modèle relationnel et normalisation 10 Le domaine d un attribut est alors spécifié en faisant référence au nom d un domaine prédéfini. Create table Client ( nas number (8,0), nom varchar(45) not null, solde d_solde) ; <- référence au domaine nommé d_solde L obligation pour un attribut de respecter son domaine est une contrainte d attribut spécifiée au niveau du schéma. Dans le cas d'une contrainte impliquant plusieurs attributs d une même relation, elle est formulée de préférence par une clause de contrainte de table. Dans certains cas, elle peut être renforcée par une procédure lancée automatiquement par le serveur SGBD à chaque fois qu'un des attributs est modifié (vérification par trigger). La définition du domaine sémantique est aussi possible au niveau du schéma. Par exemple, l attribut solde précise que la valeur du solde bancaire d un client doit toujours être positif : Create table Client ( nas number (8,0), nom VARCHAR2(50), solde Number(8,2)CONSTRAINT c_compte CHECK(solde > 0)); Une contrainte un peu plus complexe peut être formulée au niveau de la table, exigeant que tout ajout ou toute modification du solde d un client puisse devenir négatif avec une marge de seulement pour les clients de la succursale Montcalm. Dans les autres cas, le solde doit être positif. Create table nosucc Number(5), nomsucc Varchar2(45) not null, solde Number(8,2) not null, CONSTRAINT c_soldecompte CHECK(solde>= 0 OR (solde>= and nomsucc = Montcalm )); Cette contrainte a un caractère sémantique, puisque les valeurs admissibles définies par le prédicat fixent le niveau plancher du solde d un compte pour les succursales bancaires tout en permettant par le OR logique que le solde soit déficitaire de pour la succursale Montcalm. Avec SQL-92, la contrainte d attribut peut être formulée avec un CHECK() faisant référence aux attributs d une autre table de la base. Cette nouvelle fonctionnalité du langage de définition des tables ajoute de la souplesse, mais alourdit aussi le travail à effectuer par le moteur SGBD qui doit accéder à plusieurs autres tables pour vérifier la contrainte d attribut à chaque fois qu une modification est réalisée sur la table. Métafonctions spéciales Pour faciliter la description et l'étude du modèle relationnel, deux métafonctions sont définies : a) une métafonction dom() pour fournir les valeurs du domaine. Par exemple, on aura : dom(d 2 ) = {v1, v2, v3,...}, c est-à-dire les valeurs du domaine d2;

12 Chapitre 4 Modèle relationnel et normalisation 11 b) une métafonction [ ], appelée projection de tuple. Elle fournit la valeur de l'argument pour un tuple courant désigné par la variable tuple t. Il est possible de parcourir l'extension d'une table en variant le tuple désigné par t. La métafonction pourrait être notée ainsi : [ ] (t, attributi). En pratique, on adopte la convention d écriture suivante pour désigner la valeur de l'attribut i du tuple courant t : t [attributi] = valeurj dom(attributi) Par exemple, la valeur de l attribut ville du tuple courant t est donnée par l'expression suivante: 'Québec' = t [ville] et non par 'Québec' = [ ] (t, ville). Souvent, la valeur obtenue de la fonction sera comparée à une constante par l expression t [ville] = 'Québec' Cette métafonction sera utile dans l'étude des opérateurs relationnels. En résumé, t[a] est une fonction qui retourne la valeur de A pour le tuple courant désigné par la variable de tuple t. Schéma logique d une relation Le schéma logique de la relation Rk est l ensemble sk formé des attributs de la relation Rk dans laquelle chaque attribut est associé à un domaine, de préférence sémantique. Très souvent cependant le SGBD permet une référence au seul domaine syntaxique et la vérification de l appartenance d une valeur au domaine sémantique d un attribut est effectuée par le biais du typage ou par une procédure spéciale appelée déclencheur (trigger), laquelle est programmée par l'administrateur de la base. Modèle logique de la base de données Un modèle logique est formé de l ensemble S des schémas relationnels sk : S = {s1, s2,... sk}. Par exemple, la base de données Dotation est définie par l ensemble des schémas logiques des relations qui composent cette base. Souvent dans la théorie, le domaine n est pas explicitement associé à l attribut pour alléger la représentation. Dans un tel cas, deux attributs avec le même libellé sont présumés avoir le même domaine sémantique. Par exemple les deux formulations cidessous de la même relation Job sont équivalentes. La base Dotation : Employe(matricule*, nas, nom, metier, noatelier) Job(numero*, rubriquejob) Assignation(matricule*, numero*, datea) Deux formulations avec et sans le type des attributs : Job(numero*, rubriquejob) Job(numero* Number(4,0), rubriquejob varchar(50)) Relation de base Chaque relation du MRD est une relation de base, car elle est implémentée sur disque au moyen d une structure physique et ses caractéristiques sont inscrites dans le dictionnaire. La clé des relations Employe et Job est monoattribut, tandis que celle de Assignation est composée de deux attributs. Ce MRD correspond aussi à un diagramme de classes que vous pouvez facilement établir en notant que la relation Assignation correspond à une classe d association dans un diagramme de classe.

13 Chapitre 4 Modèle relationnel et normalisation Dépendance fonctionnelle ( >) Pour vérifier si le schéma d une relation est acceptable dans une base, il faut avoir recours à la notion de forme normale qui est définie au moyen de la notion de dépendance fonctionnelle. Une dépendance fonctionnelle (notée DF) est définie entre un ou plusieurs attributs d'une même relation pour imposer une contrainte aux valeurs qui peuvent entrer dans la construction des tuples de l'extension. Il existe une dépendance entre l attribut A et C dans R si à chaque fois que la valeur a1 pour A apparaît dans un tuple, on y retrouve aussi la valeur c5 pour C. On dit alors que l attribut A détermine l attribut C. Cette contrainte de dépendance est notée A --> C. Une clé dans une extension identifie un seul tuple de l'extension, de sorte qu une valeur donnée de son domaine apparaît que dans un seul tuple de l extension. On dit aussi que la clé détermine tous les attributs de la relation. Par exemple, l analyse informatique a permis de formuler le schéma de la table Employe et des DF ci-dessous : Employe (matricule*, nas, nom, age, metier, noatelier) L ensemble des dépendances fonctionnelles F valides est le suivant : {matricule --> nas, nom, age, metier, noatelier ; -- La définition de la clée sous-tend la DF suivante : nas --> matricule, nom, age, noatelier; noatelier --> metier }. L'ensemble F regroupe toutes les DF valides dans la relation Employe. La première DF se lit ainsi : le matricule détermine les attributs nas, nom, metier, noatelier, i.e. tous les attributs du schéma de la relation. En d'autres mots, lorsqu'une valeur du matricule apparaît dans l'extension, la valeur des autres attributs composant la partie droite de la DF est aussi fixée pour toute l'extension, peu importe le temps et le tuple. Il faut aussi noter qu'une DF peut être formulée avec des attributs non primaires, c est-à-dire qui n entrent pas dans la composition de la clé primaire ou d une clé candidate. Si une DF existe entre deux attributs non primaires (noatelier --> metier), elle représente la contrainte suivante : dans un atelier donné, il y a que des ouvriers pratiquant un seul et même métier. Cette dépendance fonctionnelle est donc l'expression d'une contrainte sur l'extension de la relation qui est bien sûr justifiée par la réalité à modéliser. Dans la relation formelle R(A*, B, C ), la clé est définie comme étant l'attribut A. Elle définit de ce fait la DF A --> B, C. La réalité pourrait aussi imposer une DF entre B et C dans R, comme celle-ci : B --> C. Cette dernière DF est vérifiée si pour toute paire de tuples ti et tj de r, c est-àdire les tuples de rang i et celui de rang j, la proposition suivante est vraie : si ti[b] = tj[b], alors ti[c] = tj[c] -- définition de la DF avec les indices variables i et j Par exemple, cette DF est vérifiée dans l'extension ci-dessous. Les tuples 1 et 4 vérifient la DF formulée entre B et C et de plus, aucun tuple de l'extension ne doit contredire cette DF. Qu en est-il pour les tuples de rang 1 et 2? La DF est aussi vérifiée, car la partie gauche étant fausse, la proposition qui définit la DF est vraie quelle soit la valeur de vérité de la partie droite. F = { A--> B, C; B--> C}

14 Chapitre 4 Modèle relationnel et normalisation 13 r : A B C rang du tuple --> 1 a1 b2 c3 ** 2 a2 b5 c3 3 a5 b4 c4 4 a1 b2 c3 ** Dans cette extension, lorsque deux valeurs des attributs du déterminant (partie gauche de la DF) coïncident dans deux tuples différents (**), les valeurs déterminées (partie droite) coïncident obligatoirement. Dans l exemple ci-dessus, un des deux tuple est redondant puisqu il a les mêmes valeurs. La DF est similaire à une implication logique; elle n'est cependant pas une équivalence logique. On ne peut pas déduire d'une DF valide que son inverse est aussi valide. Elle peut être invalidée dans une extension; elle est alors notée C -/-> B. Déterminant, déterminé et dépendance fonctionnelle élémentaire Les attributs de la partie gauche d'une DF forment le déterminant, tandis que ceux de la partie droite constituent le déterminé. Dans la relation Employe, la DF matricule --> metier est une DF formée du déterminant matricule et du déterminé metier. Lorsque le déterminé (membre droit) est composé d un seul attribut, la DF est dite élémentaire; elle est notée df. Toute DF peut être transformée en un ensemble équivalent de dépendances élémentaires. Dépendance fonctionnelle et analyse informatique En termes d'analyse, la dépendance fonctionnelle traduit une partie de la sémantique des données du système d'information qui est formalisé par l'analyste. La DF n'est pas suffisante cependant pour représenter toute la sémantique des données. Par exemple, si l'analyste remarque qu'une assignation de travail dans la relation Assignation est complètement identifiée par la combinaison des valeurs (matricule, numéro), cela signifie aussi qu'une assignation particulière sera faite à une seule date. Cette information sur les données est formulée par la DF suivante qui est valide dans la relation Assignation : matricule, numero -> date De même, si le système d'information exclut la représentation d'un employé qui a deux métiers, l'analyste formulera cette contrainte par la DF suivante : matricule --> metier. Cependant, le fait qu'un employé ne puisse pas être assigné à plus de trois jobs n'est pas spécifié par une DF. Il faudra implémenter une contrainte de multiplicité (cardinalité) au niveau de la relation pour renforcer cette limite dans la BD. Une DF est valide dans une table dans la mesure où tous les attributs de celle-ci, déterminant et déterminé sont dans son schéma. Si un attribut est absent, la DF n est pas valide dans la table, mais demeure valide dans la base. Dépendance fonctionnelle triviale Une dépendance fonctionnelle dont le déterminé (partie droite) est inclus dans le déterminant (partie gauche) est dite une dépendance fonctionnelle triviale. Dépendance fonctionnelle totale ( =>) Il y a une dépendance fonctionnelle totale (DFT) entre les ensembles d'attributs X et Y de la relation R, notée X=>Y, s'il n'existe pas un sous-ensemble propre de X qui détermine Y. Formellement, si un attribut quelconque de X est enlevé, la dépendance fonctionnelle résiduelle avec Y n'est plus vérifiée : X - {A} -/->Y. La négation d'une DFT se formule ainsi : X =/=> Y. Par exemple, la clé d'une relation détermine totalement tous les attributs de la relation. En effet, en supprimant un attribut de la clé composée d'une relation, l'ensemble obtenu ne détermine plus tous les autres attributs du schéma.

15 Chapitre 4 Modèle relationnel et normalisation 14 Exemple: ProduitLivre(noMateriau*, nofournisseur*, prix, categorie) Un fournisseur peut livrer différents matériaux à divers prix et un matériau peut être fourni par divers fournisseurs et à divers prix. Cependant un fournisseur ne peut livrer un même matériau qu'à un seul prix, peu importe la catégorie. Il en découle que la clé doit être composée des attributs (nomateriau et nofournisseur). Dans ce cas, les attributs déterminent totalement tous les attributs de la relation ProduitLivre. C'est la clé au sens du relationnel. (nomateriau, nofournisseur) => prix, categorie Cette dernière DF peut être formulée d'une façon équivalente en divisant le déterminé de la DF pour former autant de DF élémentaires qu'il y a d'attributs dans le déterminé : nomateriau, nofournisseur ==> prix et nomateriau, nofournisseur ==> categorie DFT :{nomateriau, nofournisseur} ==> {prix, categorie } Ces dépendances peuvent être notées avec la notation utilisée dans les livres de C. Date : nomateriau, nofournisseur prix, categorie Figure 4.4a Les dépendances fonctionnelles élémentaires obtenues sont équivalentes à la DF ayant un déterminé composé. En effet, il n'y a pas de sous-ensemble de la clé qui détermine prix et catégorie, il faut en conclure que les DFT ci-dessus sont vérifiées. En effet, si l'attribut nofournisseur est enlevé du déterminant, on n a alors plus que nomateriau -/-> prix. Finalement, toute DFT est une DF, mais l'inverse n'est pas vrai. Si une partie de la clé, soit le nomateriau, soit le nofournisseur, déterminait tous les attributs non primaires de la relation ProduitLivre, la DFT ne serait pas vérifiée. 4.3 Clé de relation Chaque relation de base du modèle relationnel a obligatoirement une clé et parfois plusieurs. Une clé est définie pour avoir certaines propriétés particulières décrites ci-dessous. La clé garantit que chaque tuple de l extension est unique à tout moment. En d'autres mots, elle assure qu'un même fait ou objet n'est représenté qu'une seule fois dans la relation. Il peut y avoir d'autres attributs ou ensembles d'attributs qui vérifient les mêmes propriétés de clé, mais un seul de ces ensembles sera choisi comme la clé dite primaire ou principale. Les autres seront dites des clés candidates. Les attributs qui composent une clé primaire ou candidate sont dits primaires. Propriétés dʹune clé de relation La clé d une table doit avoir trois propriétés essentielles : a) L ensemble des attributs de la clé détermine tous les attributs du schéma de la relation. Cette propriété est notée ainsi : clé -> tuple de R, i.e. tous les attributs de R sont déterminés par la clé.

16 Chapitre 4 Modèle relationnel et normalisation 15 b) La deuxième propriété stipule qu'il n existe pas un sous-ensemble quelconque de la clé capable d identifier de façon unique chaque tuple de la relation. La clé est donc minimale et correspond à une DFT entre la clé et tous les attributs du schéma. En d autres mots, la DF suivante est fausse : (clé) -/-> {tous les attributs de R} où (clé) signifie un sous-ensemble de l ensemble des attributs de la clé. La négation signifie qu un sous-ensemble de la clé ne détermine pas tous les attributs. S'il y a lieu, une clé est choisie parmi les clés candidates. Cette dernière sera appelée à jouer un rôle particulier tout en gardant son statut de clé candidate. Cette clé choisie devient alors la clé primaire ou principale de la relation. Sa définition dans une table permet d'implémenter la notion de clé étrangère dans une autre table qui y réfère. Sans la clé primaire, il ne peut pas y avoir une autre clé dite clé étrangère dans une autre relation. Comme nous le verrons plus loin cette clé étrangère permet de définir une contrainte d intégrité référentielle entre deux relations. c) La clé d une relation de base doit avoir une valeur pour chaque tuple de la relation. Aucun indicateur de l absence d une valeur (le null) n est acceptable pour un attribut de la clé, c'est-àdire un attribut primaire. Cette particularité ne s applique pas obligatoirement aux relations intermédiaires et temporaires obtenues lors du calcul d'une réponse à une requête. Superclé dʹune relation de base Une superclé d une relation de base est un ensemble d attributs (pas nécessairement minimal) qui vérifie la première propriété de la clé. Soit R le schéma d une relation dont l extension est r, alors K R est une superclé si, pour deux tuples quelconques de l'extension r, soit ti et tj, on a que ti[k] tj[k]. Une clé est un cas particulier de la superclé puisqu elle correspond à la plus petite superclé. En dépit du terme, toute superclé n'est pas une clé au sens propre parce qu elle n a pas toutes les propriétés d une clé. La notion de superclé est utilisée dans les algorithmes de synthèse relationnelle, notamment dans celui bien connu de Bernstein. Exemple : Employe (matricule*, nas, nom, age, metier, noatelier) Dans cet exemple, la clé primaire est composée du seul attribut matricule. Les ensembles {matricule, nom}, {matricule, metier} et {matricule, nom, metier} sont parmi d'autres, trois superclés de la relation Employe. Clé candidate Une clé candidate est aussi une clé de relation, et à ce titre admissible comme clé primaire. Par exemple, les attributs nas et matricule dans la relation Employe sont deux clés candidates. Une d'entre elles sera choisie afin de jouer un rôle supplémentaire à savoir celui de la clé primaire (on dit aussi clé principale). Les deux demeurent cependant des clés candidates. Il y a une équivalence logique entre les clés candidates : nas <--> matricule. On peut aussi écrire : nas -> matricule et matricule -> nas. Les attributs d une clé candidate sont aussi des attributs primaires (Codd, 1970). Clé étrangère dans une relation Généralement, une clé étrangère est un ensemble d attributs d'une relation lesquels forment obligatoirement une clé primaire ou candidate déclarée dans une autre relation de la même base de données. La relation qui renferme la clé primaire est dite parent, tandis que celle qui a la clé étrangère est qualifiée de relation enfant. La clé étrangère implémente en quelque sorte l'association entre deux classes du modèle conceptuel. C'est par ces attributs que deux tables

17 Chapitre 4 Modèle relationnel et normalisation 16 peuvent être jointes afin d'avoir accès aux données via leur association. Pour trouver les employés d un département, il faut pouvoir explorer la table Employe et retenir ceux qui travaillent dans ce département. La clé étrangère permet d effectuer rapidement cette recherche. C est aussi par ce moyen qu une contrainte dite référentielle est imposée aux tuples des tables parent et enfant. Un tuple enfant ne peut pas être ajouté dans une table si sa clé étrangère ne correspond pas à un tuple dans la table parent. Par exemple, dans le MRD suivant composé de deux relations : Employe(nas*, nom, ville, no) Departement(no*, site) L'attribut no de la relation Employe est une clé étrangère dans cette relation, puisque ce même attribut est une clé primaire déclarée dans la relation parent Departement. Employe nas* nom ville no Departement no* site Contrainte référentielle déclarée Plus formellement, un ensemble d attributs {C, E} d une relation R2 est une clé étrangère si l'ensemble {C, E} satisfait aux deux critères intemporels suivants : a) Chaque attribut de la clé étrangère {C, E} peut avoir valué par l indicateur de null, sinon chacun a une valeur provenant de son domaine respectif; b) Il existe une relation de base R1 avec une clé primaire ou une clé candidate déclarée {A, B} dans laquelle chaque valeur non nulle de la clé étrangère {C, E} correspond à une valeur de la clé primaire de R1. Les attributs doivent partager respectivement le même domaine, même s'ils n'ont pas le même libellé dans le modèle logique. Exemple : Soit les relations R1 (C*, E*, G, H) et R2( J*, C, E ) avec {C, E} comme clé étrangère appariée avec la clé primaire {C, E} de la relation R1. Cette association est faite sur la base de l identité des libellés pour les attributs des clés primaire et étrangère, C et E. Le fait d avoir le même libellé implique qu ils ont le même domaine. Toutefois, deux attributs, un de la clé étrangère et l autre de la clé primaire pourraient avoir des libellés différents et le même domaine. La validation de la contrainte référentielle entre deux relations peut être techniquement réalisée de plusieurs façons selon le SGBD. Spécification en SQL DDL du modèle relationnel Le modèle relationnel (logique) est défini comme un ensemble de relations (ou de tables) dont les extensions de la BD sont composées de tuples vérifiant les types et les contraintes spécifiées dans le schéma. Chaque extension de table est un sous-ensemble du produit cartésien du domaine des attributs de son schéma. La spécification du MRD par un langage de définition de données (DDL) particulier est appelée le schéma relationnel de la base. Ce schéma revêt des formes différentes d un SGBD à l autre, mais il est généralement une transposition formelle du modèle de données relationnel. Selon le système, le domaine sémantique peut être implémenté ou remplacé par le

18 Chapitre 4 Modèle relationnel et normalisation 17 domaine syntaxique. On trouve ci-dessous un schéma relationnel du système MRDS spécifié avec son propre langage DDL différent du SQL-DDL courant. Déjà lors de cette implémentation par Honeywell-Bull, la notion de domaine était disponible au moyen du CHECK_Proc. A titre d'exemple, voici un schéma relationnel MRDS de la 1ère génération (1985) qui n'a rien à voir cependant avec les schémas relationnels plus récents spécifiés avec le SQL-DDL. Dans cet exemple, tous les schémas et les index sont définis dans un seul fichier et la notion de domaine syntaxique partageable est implémentée. En outre, une procédure peut être lancée pour vérifier le domaine sémantique, une contrainte d'attribut, voire même une contrainte logique complexe formulée avec plusieurs attributs d'une relation. Schéma relationnel du SGBD MRDS du système DPS/Multics /*schéma du modèle CodeRoute MRDS (multics/unix CERT-Toulouse) */ /* Avec les domaines */ Domain : d_nom char(30) varying, d_code char(5) CHECK_proc >uud>317700>gamache>val_codes, /*pour valider la contrainte ref. sur code_infraction*/ d_vignette char(8), d_annee fixed dec (4,0), d_permis char(12), d_modele char(10), d_prix fixed dec (8,2), d_descrip char(100) varying, date char(6); /* Attributs et leur domaine respectif */ Attribute : nomp d_nom, codeinfract d_codes,-- notez la définition du domaine dateinfract d_annee, novignette d_vignette, fabricant d_nom, annee d_annee, nopermis d_permis, description d_descrip /* Relations du modele */ Relation : infraction (nomp* codeinfract* dateinfract*), proprio (nomp* nopermis), descinfract (codeinfract* description), auto (novignette* fabricant annee modele nomp), prixv (fabricant* annee* modele*); /* Index sur les attributs non primaires */ index: proprio (nopermis), auto (fabricant modele); -- index avec une entrée composée /* fin du schéma */

19 Chapitre 4 Modèle relationnel et normalisation 18 Le schéma ci-dessus utilise une procédure en langage PL/1. Cette procédure est exécutée à chaque mise à jour d un attribut dont le domaine est d_codes. Ce mécanisme est une des premières implémentations des contraintes logiques, puisqu elle permettait de consulter un fichier externe au SGBD pour valider la valeur d un attribut en fonction de son domaine, ou encore de faire un calcul de validation complexe qui ne pouvait pas être formulée au niveau de la spécification de l attribut du schéma. Propriétés des relations de base Une relation de base est une relation définie et implémentée physiquement dans la base de données, tandis que toute autre relation intermédiaire générée par des opérations sur la table de base est dite temporaire. Toute relation de base a les propriétés suivantes : a) Chaque relation de base a obligatoirement une superclé formée, dans le pire des cas, avec tous les attributs du schéma. Une clé primaire est choisie parmi les clés candidates et, si elle est monoattribut, joue alors le rôle d'un identifiant. En théorie, il n'y a pas de doublets dans une extension de relation dotée d'une clé primaire déclarée et activée. b) Chaque attribut d'une clé primaire d une relation de base doit être valué 1 (i.e. instancié) et ne peut pas être sans valeur. Dans le reste du texte, lorsqu'on mentionne le mot relation seulement, cela fait référence à une relation de base. Les relations intermédiaires n ont pas nécessairement une clé. c) Les attributs d'une relation de base sont associés à un domaine atomique (condition pour avoir la première forme normale). Cela veut dire que pour chaque ligne ou tuple, il y a seulement une valeur dans chaque colonne. Le domaine de chaque attribut est spécifié dans le dictionnaire de façon implicite ou explicite. Par exemple, spécifier que l'attribut nom est une chaîne de 25 caractères, définit implicitement le domaine syntaxique comme étant formé par toutes les chaînes, significatives ou non, d'au plus 25 caractères. d) L ordre des tuples dans une extension n est pas significatif et varie dans le temps. Cependant, l'ordre des valeurs dans un tuple est fixé selon l ordre des attributs du schéma. Lors de l'ajout d'un tuple, les valeurs fournies devront respecter l'ordre imposé aux attributs dans la définition du schéma. Au niveau physique, les valeurs qui forment un tuple à ajouter sont aussi ordonnées conformément à l'ordre fixé par le schéma de la relation et chacune peut être référencée par son rang. Les tuples sont rangés dans une page physique et pas nécessairement de façon contiguë. e) Chaque tuple a une adresse interne unique connue sous le nom de ROWID (ROw IDentifier). Ce dernier constitue en principe un jeton identificateur unique dont la durée de vie est celle de la BD. Dans certains systèmes, par exemple le relationnel Oracle, le ROWID peut être modifié par le système lorsque dans une réorganisation, il y a déplacement d'un tuple vers la zone de débordement ou lorsque les tuples sont compactés à l intérieur de la même page. Dans ce cas, le ROWID est une adresse logique rarement utilisée par les applications. Il ne peut donc pas être assimilé à un identificateur d objet comme l'oid (Object Identifier) qui ne change pas de valeur au cours de son cycle de vie. 4.4 Contraintes dʹintégrité du modèle relationnel 1 Le mot valuation est un calque de l anglais to value an attribute or a predicate. Il pourrait être vu comme un néologisme signifiant donner une valeur à un attribut ou instancier un attribut.

20 Chapitre 4 Modèle relationnel et normalisation 19 Le modèle relationnel a plusieurs contraintes d intégrité inhérentes. Rappelons qu une contrainte d intégrité est une assertion toujours vérifiée pour chaque attribut, chaque tuple, chaque table ou pour la base de données entière. Les principales contraintes inhérentes sont celles de la clé primaire et référentielle. La nature de l assertion est fixée au préalable et est valide pour toute table pour laquelle elle est définie. Il y aussi les contraintes explicites définies sur les attributs, les tuples et les tables. Leur nature varie selon la formulation de l assertion. Par exemple, une contrainte d'attribut associé à un domaine peut énoncer que le salaire annuel d'un employé a un type numérique et ne peut pas dépasser $. Les contraintes permettent de déplacer certains contrôles de validation des applications vers le SGBD qui gère la BD. Cette migration du contrôle des données garantit une meilleure uniformité dans la vérification des contraintes. Il en découle une meilleure qualité pour les données de la base. Le moment du renforcement des contraintes peut varier; une contrainte peut être vérifiée immédiatement après l'exécution d'une clause d'insertion SQL-DML ou être reportée à la fin du traitement portant sur une ou plusieurs relations. Contrainte de clé (unicité des tuples) Toute valeur d'une clé candidate identifie un et un seul tuple dans une extension de relation. La contrainte donne alors naissance à une dépendance de clé toujours vérifiée dans la relation. La clé peut être monoattribut ou composée de plusieurs attributs. Comme cela a été vu antérieurement, une clé définit une dépendance fonctionnelle sur tous les attributs de la relation. L implémentation de la contrainte de clé varie d un SGBD à l autre. Elle peut être réalisée par une procédure interne au SGBD appelée déclencheur (trigger) qui vérifie l'unicité de la valeur de clé lors de toute modification apportée à l'extension d'une relation. Elle est généralement vérifiée par la création d'un index système qui exclut les doublets et les valeurs nulles pour les attributs primaires. Cette implémentation est automatique dès lors que la clé est formellement spécifiée dans le schéma (Oracle). Contrainte d entité (obligation d avoir une valeur pour les attributs primaires) En règle générale, la clé primaire ou un de ses attributs ne peut pas être nul. Par conséquent, un tuple avec un indicateur NULL pour un attribut primaire ne peut pas être ajouté dans une extension d une relation de base. C'est la contrainte d'entité. Par contre, une clé candidate peut être totalement ou partiellement valuée par l indicateur NULL. Contrainte d unicité et de clé candidate La contrainte d unicité définie sur un ensemble d attributs interdit à deux tuples de l extension d avoir les mêmes valeurs pour ces attributs. L unicité de l attribut sited est vérifiée par les six premiers tuples de la table Departement. La contrainte de clé candidate spécifie qu il n existe pas deux tuples de l extension de R qui ont les mêmes valeurs du domaine pour les attributs de la clé candidate en excluant aussi tout indicateur d absence de valeur, le NULL considéré non inclus dans le domaine. Un attribut déclaré UNIQUE peut être alors considéré comme une clé candidate si le NOT NULL est aussi spécifié. departement : nod * nomd sited 23 vente Lévis 34 R/D Québec 12 pub Montréal 11 finances null 14 siège-soc null + 9 distribution Lévis rejet du tuple

21 Chapitre 4 Modèle relationnel et normalisation 20 Figure 4.5 Dans l'exemple de la figure 4.5, les six premiers tuples respectent la contrainte d unicité définie pour l attribut sited de Departement, et cela en dépit de la présence des indicateurs null (indicateur de l absence d une valeur). L ajout du tuple (9, distribution, Lévis) est cependant impossible, car cette action viole la contrainte d unicité définie pour l attribut sited. Toutefois, l ajout du tuple (9, distribution, null) est possible, car ce nouveau tuple est réputé différent de ceux déjà dans la table. Cependant, toute mise à jour de ce tuple n est pas acceptable. Par exemple, il est impossible de représenter le fait que le nouveau département de distribution soit localisé à Québec! La contrainte d'unicité définie par UNIQUE sur l'attribut sited exclut un deuxième tuple avec le sited à Québec. Voici comment sont formulées la table Departement et toutes les contraintes au moyen du langage SQL-DDL : Create table Departement ( nod integer NOT NULL, nomd varchar2(35) NOT NULL, sited varchar(10) NULL UNIQUE Check(site_d IN ( Québec, Lévis, Montréal )), CONSTRAINT cp_departement Primary Key (no_d)); N.B. Chaque contrainte est identifiée par un nom de sorte qu en cas d erreur, le système fera une référence à ce nom de contrainte impliquée. Dans l exemple ci-dessus, toute violation à la contrainte de l unicité de la clé nod activera une erreur qui fera référence à la contrainte cp_departement. La mise au point des clauses SQL-DDL est ainsi rendue plus facile. Écriture différente des contraintes : niveau table La contrainte peut être aussi formulée au niveau de la table après celle des attributs puisqu elle comprend le nom de l attribut qu elle contraint. Create table Departement ( nod integer NOT NULL, nomd varchar2(35) NOT NULL, sited varchar(10) NULL UNIQUE, CONSTRAINT C_siteD Check(siteD IN ( Québec, Lévis, Montréal )); Toutefois, si la contrainte d unicité était définie différemment dans le schéma de la table pour inclure dorénavant les deux attributs, nomd et sited, serait-il alors possible d ajouter le tuple (9, distribution, Lévis)? Le tuple pourrait être ajouté car la combinaison de valeurs (distribution, Lévis) est unique et vérifie la contrainte UNIQUE formulée différemment au niveau de la table et non plus au niveau de l'attribut. Create table Departement ( nod number(4,0) NOT NULL, nomd varchar2(35) NOT NULL, sited varchar(10) NULL, Constraint u_nom_site UNIQUE(nomD,siteD), Constraint cp_departement (nod) primary key));

CONCEPTION Support de cours n 3 DE BASES DE DONNEES

CONCEPTION Support de cours n 3 DE BASES DE DONNEES CONCEPTION Support de cours n 3 DE BASES DE DONNEES Auteur: Raymonde RICHARD PRCE UBO PARTIE III. - LA DESCRIPTION LOGIQUE ET PHYSIQUE DES DONNEES... 2 A. Les concepts du modèle relationnel de données...

Plus en détail

Bases de Données. Plan

Bases de Données. Plan Université Mohammed V- Agdal Ecole Mohammadia d'ingénieurs Rabat Bases de Données Mr N.EL FADDOULI 2014-2015 Plan Généralités: Définition de Bases de Données Le modèle relationnel Algèbre relationnelle

Plus en détail

Bases de Données relationnelles et leurs systèmes de Gestion

Bases de Données relationnelles et leurs systèmes de Gestion III.1- Définition de schémas Bases de Données relationnelles et leurs systèmes de Gestion RAPPELS Contraintes d intégrité sous Oracle Notion de vue Typage des attributs Contrainte d intégrité Intra-relation

Plus en détail

Chapitre 3 LE MODELE RELATIONNEL ET SQL (DDL)

Chapitre 3 LE MODELE RELATIONNEL ET SQL (DDL) Chapitre 3 LE MODELE RELATIONNEL ET SQL (DDL) Un modèle de données définit un mode de représentation de l information selon trois composantes : 1. Des structures de données. 2. Des contraintes qui permettent

Plus en détail

Bases de Données Relationnelles. Le Modèle Relationnel

Bases de Données Relationnelles. Le Modèle Relationnel Bases de Données Relationnelles Le Modèle Relationnel Le modèle relationnel modèle de niveau logique modèle simple : deux concepts relation (table) attribut (colonne) défini par Ted Codd en 1970 ; prix

Plus en détail

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

Modélisation de bases de données : Le modèle relationnel

Modélisation de bases de données : Le modèle relationnel Modélisation de bases de données : Le modèle relationnel Rappel chapitre 1 C est quoi un modèle? Type de modèle : Modèle hiérarchique Modèle réseau Modèle objet Modèle relationnel Cours BD Dr REZEG K 1

Plus en détail

Introduction aux Bases de Données

Introduction aux Bases de Données Licence 3 Géographie Aménagement NHUC5548 Introduction aux Bases de Données Le cas des BD relationnelles Concepts, méthodes et applications JP ANTONI / Y FLETY 1 Logistique et autres fonctionnements Cours

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

Rappel sur les bases de données

Rappel sur les bases de données Rappel sur les bases de données 1) Généralités 1.1 Base de données et système de gestion de base de donnés: définitions Une base de données est un ensemble de données stockées de manière structurée permettant

Plus en détail

UML et les Bases de Données

UML et les Bases de Données CNAM UML et les Bases de Données UML et les Bases de Données. Diagramme de classes / diagramme d objets (UML)...2.. Premier niveau de modélisation des données d une application...2.2. Les éléments de modélisation...2.2..

Plus en détail

Bases de Données. Le cas des BD relationnelles ouverture sur les BD relationnelles spatiales Séance 2 : Mise en oeuvre

Bases de Données. Le cas des BD relationnelles ouverture sur les BD relationnelles spatiales Séance 2 : Mise en oeuvre Bases de Données Le cas des BD relationnelles ouverture sur les BD relationnelles spatiales Séance 2 : Mise en oeuvre Synthèse : conception de BD langage de modélisation famille de SGBD SGBD Analyse du

Plus en détail

1 Introduction et installation

1 Introduction et installation TP d introduction aux bases de données 1 TP d introduction aux bases de données Le but de ce TP est d apprendre à manipuler des bases de données. Dans le cadre du programme d informatique pour tous, on

Plus en détail

Langage SQL : créer et interroger une base

Langage SQL : créer et interroger une base Langage SQL : créer et interroger une base Dans ce chapitre, nous revenons sur les principales requêtes de création de table et d accès aux données. Nous verrons aussi quelques fonctions d agrégation (MAX,

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

Chapitre 5 LE MODELE ENTITE - ASSOCIATION

Chapitre 5 LE MODELE ENTITE - ASSOCIATION Chapitre 5 LE MODELE ENTITE - ASSOCIATION 1 Introduction Conception d une base de données Domaine d application complexe : description abstraite des concepts indépendamment de leur implémentation sous

Plus en détail

Langage propre à Oracle basé sur ADA. Offre une extension procédurale à SQL

Langage propre à Oracle basé sur ADA. Offre une extension procédurale à SQL Cours PL/SQL Langage propre à Oracle basé sur ADA Offre une extension procédurale à SQL PL/SQL permet d utiliser un sous-ensemble du langage SQL des variables, des boucles, des alternatives, des gestions

Plus en détail

Chapitre 10. Architectures des systèmes de gestion de bases de données

Chapitre 10. Architectures des systèmes de gestion de bases de données Chapitre 10 Architectures des systèmes de gestion de bases de données Introduction Les technologies des dernières années ont amené la notion d environnement distribué (dispersions des données). Pour reliér

Plus en détail

Conception des bases de données : Modèle Entité-Association

Conception des bases de données : Modèle Entité-Association Conception des bases de données : Modèle Entité-Association La modélisation d un problème, c est-à-dire le passage du monde réel à sa représentation informatique, se définit en plusieurs étapes pour parvenir

Plus en détail

NF26 Data warehouse et Outils Décisionnels Printemps 2010

NF26 Data warehouse et Outils Décisionnels Printemps 2010 NF26 Data warehouse et Outils Décisionnels Printemps 2010 Rapport Modélisation Datamart VU Xuan Truong LAURENS Francis Analyse des données Avant de proposer un modèle dimensionnel, une analyse exhaustive

Plus en détail

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml OCL Object Constraint Language Le langage de contraintes d'uml Plan 1. Introduction 2. Les principaux concepts d'ocl Object Constraint Language 1 Object Constraint Language 2 Exemple: une application bancaire

Plus en détail

A QUOI SERVENT LES BASES DE DONNÉES?

A QUOI SERVENT LES BASES DE DONNÉES? BASE DE DONNÉES OBJET Virginie Sans virginie.sans@irisa.fr A QUOI SERVENT LES BASES DE DONNÉES? Stockage des informations : sur un support informatique pendant une longue période de taille importante accès

Plus en détail

1. Qu'est-ce que SQL?... 2. 2. La maintenance des bases de données... 2. 3. Les manipulations des bases de données... 5

1. Qu'est-ce que SQL?... 2. 2. La maintenance des bases de données... 2. 3. Les manipulations des bases de données... 5 1. Qu'est-ce que SQL?... 2 2. La maintenance des bases de données... 2 2.1 La commande CREATE TABLE... 3 2.2 La commande ALTER TABLE... 4 2.3 La commande CREATE INDEX... 4 3. Les manipulations des bases

Plus en détail

Cours Base de données relationnelles. M. Boughanem, IUP STRI

Cours Base de données relationnelles. M. Boughanem, IUP STRI Cours Base de données relationnelles 1 Plan 1. Notions de base 2. Modèle relationnel 3. SQL 2 Notions de base (1) Définition intuitive : une base de données est un ensemble d informations, (fichiers),

Plus en détail

Bases de données relationnelles

Bases de données relationnelles Bases de données relationnelles Système de Gestion de Bases de Données Une base de données est un ensemble de données mémorisé par un ordinateur, organisé selon un modèle et accessible à de nombreuses

Plus en détail

Bases de Données Avancées

Bases de Données Avancées 1/62 Bases de Données Avancées Introduction & Rappel Conception et Modélisation Thierry Hamon Bureau H202 - Institut Galilée Tél. : 33 1.48.38.35.53 Bureau 150 LIM&BIO EA 3969 Université Paris 13 - UFR

Plus en détail

TP Contraintes - Triggers

TP Contraintes - Triggers TP Contraintes - Triggers 1. Préambule Oracle est accessible sur le serveur Venus et vous êtes autorisés à accéder à une instance licence. Vous utiliserez l interface d accés SQL*Plus qui permet l exécution

Plus en détail

Architectures, modèles et langages de données

Architectures, modèles et langages de données Architectures, modèles et langages de données OLAP Hypercube Ingénierie des bases de données Fascicule 3 c,d Volume I Langage SQL, indexation et vue relationnelle André Gamache 2005 Architectures, Modèles

Plus en détail

I4 : Bases de Données

I4 : Bases de Données I4 : Bases de Données Passage de UML au modèle relationnel Georges LOUIS Département Réseaux et Télécommunications Université de La Rochelle Module I4 2008-2009 1 G.Louis Sommaire 1 Des classes aux tables

Plus en détail

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information

Plus en détail

Bases de données. Chapitre 1. Introduction

Bases de données. Chapitre 1. Introduction Références : Bases de données Pierre Wolper Email : pw@montefiore.ulg.ac.be URL : http : //www.montefiore.ulg.ac.be/~pw/ http : //www.montefiore.ulg.ac.be/ ~pw/cours/bd.html Henry F. Korth, Abraham Silberschatz,

Plus en détail

Chapitre 1 Généralités sur les bases de données

Chapitre 1 Généralités sur les bases de données Chapitre 1 Généralités sur les bases de données I. Définition d un SGBD Une base de données, généralement appelée BD est un ensemble structuré et organisé permettant le stockage de grandes quantités d'informations

Plus en détail

Les bases de données Page 1 / 8

Les bases de données Page 1 / 8 Les bases de données Page 1 / 8 Sommaire 1 Définitions... 1 2 Historique... 2 2.1 L'organisation en fichier... 2 2.2 L'apparition des SGBD... 2 2.3 Les SGBD relationnels... 3 2.4 Les bases de données objet...

Plus en détail

Entrepôt de données 1. Introduction

Entrepôt de données 1. Introduction Entrepôt de données 1 (data warehouse) Introduction 1 Présentation Le concept d entrepôt de données a été formalisé pour la première fois en 1990 par Bill Inmon. Il s agissait de constituer une base de

Plus en détail

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication Statut du Committee Working Draft document Titre XACML Language Proposal, version 0.8 (XACML : XML Access Control Markup Language) Langage de balisage du contrôle d'accès Mot clé Attestation et sécurité

Plus en détail

Intégrité des données

Intégrité des données . Contraintes d intégrité : Définition et objectif Intégrité des données Définition des contraintes Vérification des contraintes Contrainte d'intégrité : propriété sémantique que doivent respecter les

Plus en détail

Intégrité sémantique dans les bases de données relationnelles

Intégrité sémantique dans les bases de données relationnelles Intégrité sémantique dans les bases de données relationnelles 1 - Intégrité sémantique Bernard ESPINASSE Professeur à Aix-Marseille Université (AMU Ecole Polytechnique Universitaire de Marseille Fev. 2013

Plus en détail

Modélisation des données

Modélisation des données Modélisation des données Le modèle Entité/Association Le MCD ou modèle Entité/Association est un modèle chargé de représenter sous forme graphique les informations manipulées par le système (l entreprise)

Plus en détail

Le Langage De Description De Données(LDD)

Le Langage De Description De Données(LDD) Base de données Le Langage De Description De Données(LDD) Créer des tables Décrire les différents types de données utilisables pour les définitions de colonne Modifier la définition des tables Supprimer,

Plus en détail

Introduction aux bases de données. Généralités sur les bases de données. Fonctions d'un SGBD. Définitions. Indépendance par rapport aux traitements

Introduction aux bases de données. Généralités sur les bases de données. Fonctions d'un SGBD. Définitions. Indépendance par rapport aux traitements Introduction aux bases de données Université de Nice Sophia-Antipolis Version 2.1-5/12/2000 Richard Grin Généralités sur les bases de données R. Grin SGBD 2 Définitions Une base de données est un ensemble

Plus en détail

Créer le schéma relationnel d une base de données ACCESS

Créer le schéma relationnel d une base de données ACCESS Utilisation du SGBD ACCESS Polycopié réalisé par Chihab Hanachi et Jean-Marc Thévenin Créer le schéma relationnel d une base de données ACCESS GENERALITES SUR ACCESS... 1 A PROPOS DE L UTILISATION D ACCESS...

Plus en détail

Compte-rendu de projet de Système de gestion de base de données

Compte-rendu de projet de Système de gestion de base de données Compte-rendu de projet de Système de gestion de base de données Création et utilisation d'un index de jointure LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Thierry Grison

Plus en détail

BASES DE DONNÉES. CNAM Centre associé de Clermont-Ferrand Cycle A Année 1997-98. J. Darmont I. INTRODUCTION II. LES SYSTÈMES HIÉRARCHIQUES

BASES DE DONNÉES. CNAM Centre associé de Clermont-Ferrand Cycle A Année 1997-98. J. Darmont I. INTRODUCTION II. LES SYSTÈMES HIÉRARCHIQUES BASES DE DONNÉES CNAM Centre associé de Clermont-Ferrand Cycle A Année 1997-98 J. Darmont I. INTRODUCTION II. LES SYSTÈMES HIÉRARCHIQUES III. LES SYSTÈMES RÉSEAU IV. LES SYSTÈMES RELATIONNELS V. LE LANGAGE

Plus en détail

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile Dans ce TP, vous apprendrez à définir le type abstrait Pile, à le programmer en Java à l aide d une interface

Plus en détail

1/ Présentation de SQL Server :

1/ Présentation de SQL Server : Chapitre II I Vue d ensemble de Microsoft SQL Server Chapitre I : Vue d ensemble de Microsoft SQL Server Module: SQL server Semestre 3 Année: 2010/2011 Sommaire 1/ Présentation de SQL Server 2/ Architerture

Plus en détail

16H Cours / 18H TD / 20H TP

16H Cours / 18H TD / 20H TP INTRODUCTION AUX BASES DE DONNEES 16H Cours / 18H TD / 20H TP 1. INTRODUCTION Des Fichiers aux Bases de Données 2. SYSTEME DE GESTION DE BASE DE DONNEES 2.1. INTRODUCTION AUX SYSTEMES DE GESTION DE BASES

Plus en détail

Introduction au Système de Gestion de Base de Données et aux Base de Données

Introduction au Système de Gestion de Base de Données et aux Base de Données Introduction au Système de Gestion de Base de Données et aux Base de Données Formation «Gestion des données scientifiques : stockage et consultation en utilisant des bases de données» 24 au 27 /06/08 Dernière

Plus en détail

INTRODUCTION : Données structurées et accès simplifié

INTRODUCTION : Données structurées et accès simplifié INTRODUCTION : Données structurées et accès simplifié À l'origine de l'informatique, le stockage d'information se faisait sur cartes perforées. Ces supports pauvres ne permettaient pas de définir la structuration

Plus en détail

Le langage SQL pour Oracle - partie 1 : SQL comme LDD

Le langage SQL pour Oracle - partie 1 : SQL comme LDD Le langage SQL pour Oracle - partie 1 : SQL comme LDD 1 SQL : Introduction SQL : Structured Query Langage langage de gestion de bases de donn ees relationnelles pour Définir les données (LDD) interroger

Plus en détail

SGBDR. Systèmes de Gestion de Bases de Données (Relationnelles)

SGBDR. Systèmes de Gestion de Bases de Données (Relationnelles) SGBDR Systèmes de Gestion de Bases de Données (Relationnelles) Plan Approches Les tâches du SGBD Les transactions Approche 1 Systèmes traditionnels basés sur des fichiers Application 1 Gestion clients

Plus en détail

A QUOI SERVENT LES BASES DE DONNÉES?

A QUOI SERVENT LES BASES DE DONNÉES? BASE DE DONNÉES OBJET Virginie Sans virginie.sans@irisa.fr A QUOI SERVENT LES BASES DE DONNÉES? Stockage des informations : sur un support informatique pendant une longue période de taille importante accès

Plus en détail

Chapitre 07 Le modèle relationnel des données

Chapitre 07 Le modèle relationnel des données Chapitre 07 Le modèle relationnel des données Introduction Ce chapitre est un prolongement de l'étude du modèle relationnel vu en classe de première. L'idée principale est de faire comprendre aux élèves

Plus en détail

Création et Gestion des tables

Création et Gestion des tables Création et Gestion des tables Version 1.0 Z Grégory CASANOVA 2 Sommaire 1 Introduction... 3 2 Pré-requis... 4 3 Les tables... 5 3.1 Les types de données... 5 3.1.1 Les types de données Sql Server... 5

Plus en détail

ECR_DESCRIPTION CHAR(80), ECR_MONTANT NUMBER(10,2) NOT NULL, ECR_SENS CHAR(1) NOT NULL) ;

ECR_DESCRIPTION CHAR(80), ECR_MONTANT NUMBER(10,2) NOT NULL, ECR_SENS CHAR(1) NOT NULL) ; RÈGLES A SUIVRE POUR OPTIMISER LES REQUÊTES SQL Le but de ce rapport est d énumérer quelques règles pratiques à appliquer dans l élaboration des requêtes. Il permettra de comprendre pourquoi certaines

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude

Plus en détail

Bases de données relationnelles & SQL

Bases de données relationnelles & SQL Bases de données relationnelles & SQL Objectifs Appréhender les concepts du modèle relationnel. Etre capable de concevoir un schéma relationnel. Etre capable de créer une base de données relationnelle

Plus en détail

1 Modélisation d une base de données pour une société de bourse

1 Modélisation d une base de données pour une société de bourse IN306 : Corrigé SID Christophe Garion 18 octobre 2010 Ce document est un corrigé succinct de l examen du module IN306. 1 Modélisation d une base de données pour une société de bourse Une

Plus en détail

et les Systèmes Multidimensionnels

et les Systèmes Multidimensionnels Le Data Warehouse et les Systèmes Multidimensionnels 1 1. Définition d un Datawarehouse (DW) Le Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées

Plus en détail

Les bases de données

Les bases de données Les bases de données Introduction aux fonctions de tableur et logiciels ou langages spécialisés (MS-Access, Base, SQL ) Yves Roggeman Boulevard du Triomphe CP 212 B-1050 Bruxelles (Belgium) Idée intuitive

Plus en détail

AGRÉGATION «ÉCONOMIE ET GESTION»

AGRÉGATION «ÉCONOMIE ET GESTION» AGRÉGATION «ÉCONOMIE ET GESTION» CONCOURS INTERNE SESSION 2002 ÉPREUVE SUR LES TECHNIQUES DE GESTION ET COMPORTANT DES ASPECTS PÉDAGOGIQUES DOMAINE : économie et gestion informatique Durée de préparation

Plus en détail

CHAPITRE 1. Introduction aux bases de données

CHAPITRE 1. Introduction aux bases de données CHAPITRE 1 Contenu du chapitre 1 Pourquoi utiliser une bases de? Définitions et objectifs d'un SGBD Niveaux d'abstraction des Méthodes de modélisation d une BD Modèles de structuration des Structure globale

Plus en détail

Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère

Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère L'héritage et le polymorphisme en Java Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère En java, toutes les classes sont dérivée de la

Plus en détail

A. Définition et formalisme

A. Définition et formalisme Les cardinalités et les différents types d'associations I. Les cardinalités A. Définition et formalisme Les cardinalités sont des couples de valeur que l'on trouve entre chaque entité et ses associations

Plus en détail

Olivier Mondet http://unidentified-one.net

Olivier Mondet http://unidentified-one.net T-GSI Ch.4 Le Langage SQL LDD, LCD Cet exercice guidé reprend le plan suivis lors de l intervention de formation faite pour l académie de Versailles. L objectif principal visait en la présentation du langage

Plus en détail

Comprendre Merise et la modélisation des données

Comprendre Merise et la modélisation des données Comprendre Merise et la modélisation des données Tables des matières Avant-propos 1- Introduction 1-1 Principes fondateurs 1-2 Bases conceptuelles 1-3 Place de Merise dans le cycle de développement informatique

Plus en détail

Exemple accessible via une interface Web. Bases de données et systèmes de gestion de bases de données. Généralités. Définitions

Exemple accessible via une interface Web. Bases de données et systèmes de gestion de bases de données. Généralités. Définitions Exemple accessible via une interface Web Une base de données consultable en ligne : Bases de données et systèmes de gestion de bases de données The Trans-atlantic slave trade database: http://www.slavevoyages.org/tast/index.faces

Plus en détail

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN Les contenues de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas

Plus en détail

Présentation du module Base de données spatio-temporelles

Présentation du module Base de données spatio-temporelles Présentation du module Base de données spatio-temporelles S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Partie 1 : Notion de bases de données (12,5h ) Enjeux et principes

Plus en détail

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation Base de données S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Présentation du module Contenu général Notion de bases de données Fondements / Conception Utilisation :

Plus en détail

BTS S.I.O. 2012-2013 PHP OBJET. Module SLAM4. Nom du fichier : PHPRévisionObjetV2.odt Auteur : Pierre Barais

BTS S.I.O. 2012-2013 PHP OBJET. Module SLAM4. Nom du fichier : PHPRévisionObjetV2.odt Auteur : Pierre Barais BTS S.I.O. 2012-2013 PHP OBJET Module SLAM4 Nom du fichier : PHPRévisionObjetV2.odt Auteur : Pierre Barais Table des matières 1 But... 3 2 Les bases :... 3 3 Utilisation d'une classe : Instanciation...3

Plus en détail

1.2 Genèse. 1.3 Version de Designer utilisée

1.2 Genèse. 1.3 Version de Designer utilisée Designer et l ingénierie du logiciel Notions élémentaires P.-A. Sunier, ISNet Neuchâtel avec le concours de C. Kohler et P. Ferrara 1 Propos liminaires... 1 1.1 Objectifs de publication... 1 1.2 Genèse...

Plus en détail

LES TYPES DE DONNÉES DU LANGAGE PASCAL

LES TYPES DE DONNÉES DU LANGAGE PASCAL LES TYPES DE DONNÉES DU LANGAGE PASCAL 75 LES TYPES DE DONNÉES DU LANGAGE PASCAL CHAPITRE 4 OBJECTIFS PRÉSENTER LES NOTIONS D ÉTIQUETTE, DE CONS- TANTE ET DE IABLE DANS LE CONTEXTE DU LAN- GAGE PASCAL.

Plus en détail

Patrice BOURSIER. Professeur, Univ. de La Rochelle. patrice.boursier@univ-lr.fr. Bases de Données. Notes de cours

Patrice BOURSIER. Professeur, Univ. de La Rochelle. patrice.boursier@univ-lr.fr. Bases de Données. Notes de cours Patrice BOURSIER Professeur, Univ. de La Rochelle patrice.boursier@univ-lr.fr Bases de Données Notes de cours SOMMAIRE Chapitre 1 : Introduction Chapitre 2 : Modèle conceptuel Chapitre 3 : Modèle relationnel

Plus en détail

Bases de données - Modèle relationnel

Bases de données - Modèle relationnel Bases de données - Modèle relationnel Introduction SITE :http://www.univ-orleans.fr/lifo/members/mirian.halfeld/ BD - Mírian Halfeld-Ferrari p. 1 Les bases de données - Bibliographie Ullman and Widom,

Plus en détail

Modèle conceptuel : diagramme entité-association

Modèle conceptuel : diagramme entité-association Modèle conceptuel : diagramme entité-association Raison d'être de ce cours «La conception et l'utilisation de bases de données relationnelles sur micro-ordinateurs n'est pas un domaine réservé aux informaticiens.»

Plus en détail

OCL - Object Constraint Language

OCL - Object Constraint Language OCL - Object Constraint Language Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon SIMA - OCL - Object

Plus en détail

CREATION WEB DYNAMIQUE

CREATION WEB DYNAMIQUE CREATION WEB DYNAMIQUE IV ) MySQL IV-1 ) Introduction MYSQL dérive directement de SQL (Structured Query Language) qui est un langage de requêtes vers les bases de données relationnelles. Le serveur de

Plus en détail

Importation des données dans Open Office Base

Importation des données dans Open Office Base Importation des données dans Open Office Base Il est aujourd'hui assez rare dans les bureaux de créer un environnement de base de données de toutes pièces. Les données sont manipulées depuis longtemps

Plus en détail

Introduction aux SGBDR

Introduction aux SGBDR 1 Introduction aux SGBDR Pour optimiser une base Oracle, il est important d avoir une idée de la manière dont elle fonctionne. La connaissance des éléments sous-jacents à son fonctionnement permet de mieux

Plus en détail

IFT3030 Base de données. Chapitre 2 Architecture d une base de données

IFT3030 Base de données. Chapitre 2 Architecture d une base de données IFT3030 Base de données Chapitre 2 Architecture d une base de données Plan du cours Introduction Architecture Modèles de données Modèle relationnel Algèbre relationnelle SQL Conception Fonctions avancées

Plus en détail

INTEGRITE ET BD ACTIVES

INTEGRITE ET BD ACTIVES INTEGRITE ET BD ACTIVES 1. INTRODUCTION Un SGBD doit garantir la cohérence des données lors des mises à jour de la base. En effet, les données d'une base ne sont pas indépendantes, mais obéissent à des

Plus en détail

Pourquoi l apprentissage?

Pourquoi l apprentissage? Pourquoi l apprentissage? Les SE sont basés sur la possibilité d extraire la connaissance d un expert sous forme de règles. Dépend fortement de la capacité à extraire et formaliser ces connaissances. Apprentissage

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

UEO11 COURS/TD 1. nombres entiers et réels codés en mémoire centrale. Caractères alphabétiques et caractères spéciaux.

UEO11 COURS/TD 1. nombres entiers et réels codés en mémoire centrale. Caractères alphabétiques et caractères spéciaux. UEO11 COURS/TD 1 Contenu du semestre Cours et TDs sont intégrés L objectif de ce cours équivalent a 6h de cours, 10h de TD et 8h de TP est le suivant : - initiation à l algorithmique - notions de bases

Plus en détail

Table des matières. Avant-propos

Table des matières. Avant-propos Table des matières Avant-propos v Table des matières xi 1 Introduction aux systèmes de gestion de bases de données 1 1.1 Donnée et type de données 2 1.2 Donnée et information 2 1.3 Donnée simple et complexe

Plus en détail

CRÉER UNE BASE DE DONNÉES AVEC OPEN OFFICE BASE

CRÉER UNE BASE DE DONNÉES AVEC OPEN OFFICE BASE CRÉER UNE BASE DE DONNÉES AVEC OPEN OFFICE BASE 2 ème partie : REQUÊTES Sommaire 1. Les REQUÊTES...2 1.1 Créer une requête simple...2 1.1.1 Requête de création de listage ouvrages...2 1.1.2 Procédure de

Plus en détail

Cours 420-KEG-LG, Gestion de réseaux et support technique. Atelier No2 :

Cours 420-KEG-LG, Gestion de réseaux et support technique. Atelier No2 : Atelier No2 : Installation d Active Directory Installation du service DNS Installation du Service WINS Création d'un compte d'ordinateur Jonction d'un ordinateur à un domaine Création d usagers. Étape

Plus en détail

Mise en place Active Directory, DNS Mise en place Active directory, DNS sous Windows Serveur 2008 R2

Mise en place Active Directory, DNS Mise en place Active directory, DNS sous Windows Serveur 2008 R2 BTS SIO Mise en place Active Directory, DNS Mise en place Active directory, DNS sous Windows Serveur 2008 R2 Frédéric Talbourdet Centre de formation Morlaix - GRETA BTS SIO CAHIER D ES CHARGES - Projet

Plus en détail

Charte de nommage du «.tn»

Charte de nommage du «.tn» République Tunisienne Instance Nationale des Télécommunications ---------------------------------- ------------------------------------ Charte de nommage du «.tn» Version 1.0 Table des matières Article

Plus en détail

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Contenu de ce cours : 1. Stockage de données. Supports, fonctionnement d un disque, technologie RAID 2. Organisation

Plus en détail

1 Position du problème

1 Position du problème Licence Science et Technologies - INF245 Examen session 1 - mai 2012 Durée : 2 heures Documents non autorisés Le barème est donné à titre indicatif 1 Position du problème Le Club Universitaire de Vélo

Plus en détail

Faculté des sciences de gestion et sciences économiques BASE DE DONNEES

Faculté des sciences de gestion et sciences économiques BASE DE DONNEES BASE DE DONNEES La plupart des entreprises possèdent des bases de données informatiques contenant des informations essentielles à leur fonctionnement. Ces informations concernent ses clients, ses produits,

Plus en détail

Le Langage SQL version Oracle

Le Langage SQL version Oracle Université de Manouba École Supérieure d Économie Numérique Département des Technologies des Systèmes d Information Le Langage SQL version Oracle Document version 1.1 Mohamed Anis BACH TOBJI anis.bach@isg.rnu.tn

Plus en détail

Le modèle de données

Le modèle de données Le modèle de données Introduction : Une fois que l étude des besoins est complétée, deux points importants sont à retenir : Les données du système étudié Les traitements effectués par le système documentaire.

Plus en détail

Encryptions, compression et partitionnement des données

Encryptions, compression et partitionnement des données Encryptions, compression et partitionnement des données Version 1.0 Grégory CASANOVA 2 Compression, encryption et partitionnement des données Sommaire 1 Introduction... 3 2 Encryption transparente des

Plus en détail

PROJET 1 : BASE DE DONNÉES REPARTIES

PROJET 1 : BASE DE DONNÉES REPARTIES PROJET 1 : BASE DE DONNÉES REPARTIES GESTION D UNE BANQUE Elèves : David Bréchet Frédéric Jacot Charles Secrétan DONNÉES DU PROJET SSC - Bases de Données II Laboratoire de Bases de Données BD réparties

Plus en détail

Débuter avec OOo Base

Débuter avec OOo Base Open Office.org Cyril Beaussier Débuter avec OOo Base Version 1.0.7 Novembre 2005 COPYRIGHT ET DROIT DE REPRODUCTION Ce support est libre de droit pour une utilisation dans un cadre privé ou non commercial.

Plus en détail

Chapitre 2. Classes et objets

Chapitre 2. Classes et objets Chapitre 2: Classes et Objets 1/10 Chapitre 2 Classes et objets Chapitre 2: Classes et Objets 2/10 Approche Orientée Objet Idée de base de A.O.O. repose sur l'observation de la façon dont nous procédons

Plus en détail