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

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

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

Transcription

1 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 afin d'en faciliter l'exploitation (ajout, mise à jour, recherche de données) et accessibles de façon sélective par plusieurs utilisateurs. La gestion et l'accès à une base de données sont assurés par un ensemble de programmes qui constituent le Système de gestion de base de données (SGBD). Un SGBD héberge généralement plusieurs bases de données, qui sont destinées à des logiciels différents ou des thématiques différentes. II. Fonctions d un SGBD D'une manière générale, un SGBD doit avoir les caractéristiques suivantes : - Indépendance physique : Le niveau physique peut être modifié indépendamment du niveau conceptuel. Cela signifie que tous les aspects matériels de la base de données n'apparaissent pas pour l'utilisateur, il s'agit simplement d'une structure transparente de représentation des informations. - Indépendance logique : le niveau conceptuel doit pouvoir être modifié sans remettre en cause le niveau physique, c'est-à-dire que l'administrateur de la base doit pouvoir la faire évoluer sans que cela gêne les utilisateurs. - Manipulabilité : des personnes ne connaissant pas la base de données doivent être capables de décrire leurs requêtes sans faire référence à des éléments techniques de la base de données. Ceci peut se faire à travers un dictionnaire de données ou un catalogue système. - Rapidité des accès : le système doit pouvoir fournir les réponses aux requêtes (recherches d informations à partir d une ou plusieurs bases de données) le plus rapidement possible, cela implique des algorithmes de recherche rapides. - Différents langage d accès : le SGBD doit au moins supporter un langage adressant les concepts du modèle (par exemple, dans le cas du modèle relationnelle, ce langage est SQL). Néanmoins, ce type de langage ne permet pas tous les types de manipulation. Pra conséquent, soit les SGBD proposent un langage plus complet avec la possibilité de définir des accès à la base de données, soit ils proposent un couplage d un langage de type SQL avec un langage de programmation conventionnel. - Administration centralisée : le SGBD doit permettre à l'administrateur de pouvoir manipuler les données, insérer des éléments, vérifier son intégrité de façon centralisée. - Limitation de la redondance : le SGBD doit pouvoir éviter dans la mesure du possible des informations redondantes, afin d'éviter d'une part un gaspillage d'espace mémoire mais aussi des erreurs. - Vérification de l'intégrité : les données doivent être cohérentes entre elles, de plus lorsque des éléments font références à d'autres, ces derniers doivent être présents. - Partage des données : le SGBD doit permettre à plusieurs utilisateurs d accéder à la base de données de manière simultanée et transparente. - Sécurité des données : le SGBD doit permettre de spécifier qui a le droit d accéder ou de modifier tout ou une partie d une base de données. Il faut donc présenter des mécanismes permettant de gérer les droits d'accès aux données selon les utilisateurs afin de se prémunir contre les manipulations illicites intentionnelles ou accidentelles. - Résistance aux pannes : le SGBD doit garantir la cohérence de l information et des traitements en cas de panne. Les opérations sur les bases de données pouvant être très longues, il faut fournir un mécanisme de reprise en cas de panne matérielle ou logicielle, intentionnelle ou fortuite.

2 Base de données 2 - Capacité de stockage élevée : le SGBD doit permettre de gérer des données très volumineuses, pouvant atteindre plusieurs milliards d octets. Les unités de stockage sont passées du mégaoctet Mo (10 6 octets) au gigaoctet Go (10 9 ), puis au téraoctet To (10 12 ), puis petaoctet Po (10 16 ), voir même au exaoctet Eo (10 18 ) et zettaoctet Zo (10 21 ). III. Avantages de l utilisation des SGBD Avant l arrivée des bases de données (et encore dans beaucoup de cas aujourd hui), chaque application écrite pour un organisme travaillait avec ses propres fichiers. Une même information (l adresse d un client par exemple) peut alors être enregistrée dans plusieurs fichiers disjoints. Ceci occasionne des délais de mise à jour et peut amener les différentes applications à travailler sur des données contradictoires. Quand la gestion se fait avec une base de données centralisée (centralisée «logiquement» mais pas nécessairement physiquement si la base de données est répartie sur plusieurs sites), chaque donnée n est enregistrée qu en un seul endroit de la base et il ne peut y avoir ce genre de problèmes. Cette centralisation facilite donc le maintien de l intégrité des données. Les facilités offertes par les SGBD pour contrôler l accès des utilisateurs aux données de la base et les reprises automatisées après incident accroissent la sécurité dans le traitement des données. Les SGBD offrent aussi des instructions très puissantes pour le traitement des données : un seul ordre SELECT du langage SQL peut correspondre à des dizaines de lignes de programmation dans un langage de troisième génération comme le langage C. La productivité des programmeurs est ainsi fortement augmentée. En plus de l indépendance des programmes vis-à-vis de l implantation physique des données, d autres avantages importants sont apportés par l utilisation des SGBD évolués des dernières générations (en particulier par les SGBD relationnels). Ces SGBD offrent : - L indépendance des programmes vis-à-vis de la structure logique des données (stratégie d accès aux données, manière de regrouper les données, ) - L interrogation directe de la base par les utilisateurs dans un langage non procédural. Ces différents points facilitent grandement la maintenance des applications et permettent plus de souplesse pour le traitement des données enregistrées. IV. Niveaux de description des bases de données Trois niveaux de description des données ont été définis par la norme ANSI/SPARC. - Niveau interne : description du stockage des données au niveau des unités de stockage, des fichiers,... On appelle cette description le schéma interne. - Niveau conceptuel : description de la structure de toutes les données qui existent dans la base, description de leurs propriétés (relations qui existent entre elles) c'est-à-dire de leur sémantique inhérente, sans soucis d'implémentation physique ni de la façon dont chaque groupe de travail voudra s'en servir. On appelle cette description le schéma conceptuel. - Niveau externe : description pour chaque utilisateur de sa perception des données. On appelle cette description le schéma externe ou vue. Ce cours abordera plus particulièrement le niveau conceptuel. V. Type d utilisateurs d une base de données L administrateur de la base est chargé du contrôle de la base de données. Il est chargé de permettre l accès aux données aux applications ou individus qui y ont droit et de conserver de bonnes performances d accès à ces données. Il est aussi chargé des sauvegardes et des procédures de reprise après panne.

3 Base de données 3 Le programmeur d applications utilise la base de données pour construire ses applications. Il a droit de créer de nouvelles tables et les structures associées (vue, index, cluster, ). Il définit avec l administrateur de la base les droits qui seront accordés aux utilisateurs des applications qu il développe. L utilisateur final n a accès qu aux données qui lui sont utiles. L administrateur de la base peut lui accorder certains droits : consultation, modification, suppression des données. En général, il n a pas le droit de créer de nouvelles tables ni d ajouter ou d enlever des index. VI. Les différents types de SGBD Le type d'un SGBD est caractérisé par le type du modèle de données qu'il implémente. Il existe ainsi cinq types de modèles de données : - Le modèle hiérarchique : les données sont stockées hiérarchiquement, selon une arborescence descendante. Ce modèle s apparente à l organisation des répertoires d un ordinateur. Ce type de SGBD est particulièrement adapté à la modélisation de nomenclatures. Si le principe de relation «1 vers N» n est pas respecté, alors la hiérarchie doit être transformée en un réseau. Les structures de données hiérarchiques ont été très utilisées dans les premiers SGBD car très simple d implémentation. Directeur Directeur commercial Directeur technique Directeur des ressources humaines Assistant Directeur technique adjoint Responsable du personnel Responsable logistique Responsable fabrication - Le modèle réseau : ce modèle est une extension du modèle précédent, il est alors possible d établir des relation «1 vers N» en définissant des associations entre tous les types d enregistrements. Cependant, pour retrouver une donnée dans une telle modélisation, il faut connaitre le chemin d accès, ce qui rend les programmes encore dépendants de la structure de données. Famille Père Nom : Gérard Age : 35 ans Fils Nom : Tom Age : 10 ans Fils Nom : Jean Age : 7 ans Fils Nom : Eric Age : 2 ans - Le modèle déductif : les données sont modélisées dans des tables, mais leur manipulation se fait par calcul de prédicats. C'est le modèle le moins courant. - Le modèle objet (SGBDOO, Système de Gestion de Bases de Données Orienté Objet) : les données sont stockées sous forme d'objets, c'est-à-dire de structures appelées classes présentant des données membres qui les décrivent et représentent leur état. Les objets contiennent aussi la logique qui permet des les utiliser et des les modifier. Tous ces objets sont classés hiérarchiquement dans une base de données à objets. - Le modèle relationnel (SGBDR, Système de Gestion de Bases de Données Relationnelles) : les données sont modélisées dans des tables ou relations. La manipulation de ces données se fait selon la théorie mathématique des relations. PERSONNE VILLE ID Nom Prénom DateNaiss VilleNaiss ID Nom Polulation Superficie Région 1 Dupont Bob 01/01/ Paris km² 2 2 Durand Gérard 29/04/ Lyon km² 3 3 Marchand Daniel 26/12/ Marseille km² 4

4 Base de données 4 La souplesse apportée par cette représentation et les études théoriques appuyés sur la théorie mathématique des relations ont permis le développement de langages puissants non procéduraux. Dans ces langages, l utilisateur ou le programmeur indique quelles informations il veut obtenir e c est le SGBD qui trouve la manière d arriver au résultat. Le programme ou l utilisateur n a plus à navigue dans la base pour retrouver ses données. Ces langages peuvent être utilisés par des non-informaticiens et permettent l écriture de programmes indépendants de la structure logique et physique des données. Le langage SQL est un standard parmi tous ces langages. L inventeur du modèle relationnel est Codd qui travaillait dans les laboratoires d IBM. Il a énoncé douze règles que doivent vérifier les SGBD pour être relationnels. En fait, aucun SGBD ne respecte actuellement toutes ces règles. Certains cependant s approchent de cette «perfection» relationnelle. Voici ces douze règles (certaines notions seront développées plus tard dans ce cours) : Règle 1 : toutes les informations sur les données sont représentées au niveau logique et non physique (pas besoin d informations sur la façon dont sont enregistrées physiquement les données). Règle 2 : les données sont accessibles uniquement par la combinaison du nom de la table, de la clé primaire et du nom de la colonne (pas de chemin à donner). Règle 3 : une valeur spéciale doit représenter l absence de valeur (valeur NULL). Règle 4 : la description de la base de données doit être accessible comme les données ordinaires (un dictionnaire des données est enregistré dans la base). Règle 5 : un langage doit permettre de définir les données, définir des vues (visions particulières de la base, enregistrées comme des relations), manipuler les données, définir les contraintes d intégrité, des autorisations et gérer des transactions. Règle 6 : on peut faire des mises à jour par les vues lorsque c est logiquement possible. Règle 7 : le langage doit comporter des ordres effectuant l insertion, la mise à jour et la suppression de données (un seul ordre pour effectuer chacune des fonctions). Règle 8 : indépendance des programmes vis-à-vis de l implantation physique des données. Règle 9 : indépendance des programmes vis-à-vis de l implantation logique des données (si les informations manipulées par les programmes n ont pas été modifiées ou supprimées). Règle 10 : les contraintes d intégrité doivent pouvoir être définies dans le langage relationnel et enregistrées dans le dictionnaire des données. Règle 11 : indépendance vis-à-vis de la répartition des données sur divers sites. Règle 12 : on ne peut jamais contourner les contraintes (d intégrité ou de sécurité) imposées par le langage du SGBD en utilisant un langage de plus bas niveau (par exemple le langage C). A la fin des années 90 les bases relationnelles sont les bases de données les plus répandues (environ trois quarts des bases de données).

5 Chapitre 2 Modèle Conceptuel de données I. Introduction Le modèle conceptuel de données MCD (ou modèle entité-association MEA, ou Entity-RelationShip Model en anglais) a été introduit dans les années 70 comme une amélioration du modèle relationnel introduit par Codd en 1970: le MCD est plus facile à lire pour la construction de bases de données. Il devient le modèle le plus utilisé pour représenter dans un premier temps la structure de données. Actuellement, il n y a pas de standard Entité-Association, il existe une large variété de notations et de concepts. Deux utilisations des schémas EA : Concevoir le schéma de la base de données avant que la moindre donnée ne soit stockée : c est la conception conceptuelle. A partir d un tel schéma, il est plus clair de raisonner sur les concepts à stocker, les attributs dont on a besoin, les relations entre les concepts Une fois terminée, un tel schéma est traduit selon des règles précises en son schéma relationnel correspondant. La construction du schéma entité-association ainsi que son passage au modèle relationnel seront vus dans les chapitres 3 et 4. Faire de la réingénierie : à partir d une base existante complexe, dont la documentation est inexistante, on peut créer un schéma EA pour avoir une première vue synthétique de la situation et prendre des décisions comme restructurer la base, la normaliser, en créer une nouvelle plus large permettant de stocker les données de l ancienne, II. Concepts de base 1. Modèle entité-association (EA) Le modèle EA propose une description sur la base des trois concepts de base qui sont l identifications des objets, des liens entre ces objets et des propriétés de ces objets : - objet entité - lien association - propriété attribut 2. Définitions a. Entités Une entité est un objet concret ou abstrait du monde réel à propos duquel on veut enregistrer des informations. ex : M. Dupont, Mme Dupont, un crayon, l atelier de distribution, le bureau du directeur Un type d entité (TE) est un ensemble d entités qui possèdent les mêmes caractéristiques. ex : Personne (représentation de l ensemble des personnes telles que les entités M. Dupont et Mme Dupont), Employé (représentation de l ensemble des employés), Article (représentation de l ensemble des articles tels que les crayons et les livres) Un attribut d une entité est une propriété associée à un TE. L ensemble des attributs d un TE représente l ensemble des informations inhérentes que l on souhaite conserver sur les entités du TE. ex : (nom, prénom, salaire) sont des attributs du TE Employé

6 Base de données 6 Une entité munie de ses attributs sera modélisée de la manière suivante : Employé nom prénom salaire nom de l entité attributs de l entité (ou propriétés) On distingue deux types d entités : Entité forte = entité qui n a pas besoin d une autre entité pour exister. Entité faible = entité qui a besoin d une autre entité pour pouvoir être définie. Elles sont notées avec un double rectangle. On distingue deux cas : o 1 er cas : Employé est une entité faible car l ensemble des numéros de sécurité sociale des élèves est contenu dans l ensemble des numéros de sécurité sociale des personnes. On dit qu il y a un lien d héritage entre les deux entités. o 2 nd cas : Appartement est une entité faible car sa clé (on définira cette notion par la suite) est composée de l attribut clé de Bâtiment (N Bâtiment) et d un autre attribut (N Appart.). On dit qu il y a un lien d identification entre les deux entités. Personne N SécuritéSoc Nom Prénom DateNaissance LieuNaissance Bâtiment N Bâtiment NombreApp. DateConstr. Employé N SécuritéSoc Nom Prénom DateNaissance LieuNaissance Appartement N Bâtiment N Appart. Taille Etage b. Associations Une association (ou une relation) est un lien entre plusieurs entités, où chaque entité liée joue un rôle déterminé ; si l association lie des entités du même type, elle est dite cyclique ou réflexive et, dans ce cas, la spécification des rôles est indispensable. ex : lien de travail entre l employée M. Durant et le service de gestion, lien de mariage entre M. X et Mme Y. Un type d association (TA) est un ensemble d associations qui possèdent les mêmes caractéristiques (liant des entités de mêmes types avec mêmes rôles et mêmes propriétés, respectifs) ex : le TA «fabrique» lie le TE «Atelier de fabrication» au TE «Article», le TA «travaille» lie «Employé» à «Service», le TA «est-marié-avec» lie «Personne» à lui-même. Un attribut d une association est une propriété associée à un TA. L ensemble des attributs d un TA représente l ensemble des informations inhérentes que l on souhaite conserver sur les associations du TA. ex : (quantité-en-fabrication) est un attribut du TA fabrique

7 Base de données 7 Une association sera modélisée de la manière suivante : Association binaire : C est une association qui relie deux entités. Rayon nomr étage VENTE quantité Article noma type Association n-aire (ici, avec n = 3) : C est une association qui relie n entités différentes. Rayon nomr étage LIVRAISON quantité Fournisseur nomf adresse Article noma type Association réflexive : C est une association qui agit sur la même entité, mais avec des rôles différents. subalterne Employé nom CHEF salaire supérieur Le nom des associations peut-être (entre autres) : Un verbe (plutôt pour une association binaire ou réflexive) pour décrire des rôles réciproques entre deux entités ; Un nom (plutôt pour les associations n-aires) pour représenter une entité complexe définie à partir d autres entités. Les associations peuvent avoir des significations différentes : Composition : Le sens de l association est de définir l entité Vélo comme composé d autres entités (Roue et Cadre). Ce type d association est à utiliser avec précaution car on peut modéliser, dire tout et n importe quoi avec ce lien de composition. Vélo Type Poids COMP. DE Roue type épaisseur Cadre matériau forme Héritage : Pour représenter ce lien d héritage, on peut utiliser les deux notations ci-contre. Quelle que soit la notation, la clé Employé N Employé de Pilote est sont attribut N Employé. Même si celui-ci n est pas noté, il fait quand même partie de la liste des attributs de Pilote. EST UN Employé N Employé Pilote Nom Prénom Pilote Nom Prénom

8 Base de données 8 Identification : Pour représenter ce lien d identification, on utiliser la notation ci-contre. La clé de Episode est son couple d attributs (Nom, Numéro). Même si l attribut Nom n est pas noté, il fait quand même partie de la liste des attributs de Episode. Série Nom Producteur ID Episode Numéro Muni d attributs : On peut ajouter des attributs propres à une association, ils dépendent de toutes les entités reliées par cette association. Prix est un attribut propre à l association Catalogue : le Prix dépend à la fois du Fournisseur et du Produit. Fournisseur Numéro Nom CATALOGUE Prix Produit NumProduit Type Associations considérées comme entités : Certaines associations peuvent être vues comme des entités, pour notamment pouvoir construire des associations d associations. Exemple : Supposons que l on ait à représenter un ensemble de départements universitaires avec leurs serveurs et les logiciels qui y sont installés. On veut représenter le fait qu un département qui a acheté un logiciel l a forcément installé sur un serveur. Avec une association ternaire (3- aire), ou pourrait représenter les choses ainsi de la manière. Malheureusement, les cardinalités ne nous permettent pas de spécifier que pour un couple (logiciel, département), il existe obligatoirement au moins 1 serveur. Pour cela, il convient de créer une association supplémentaire que l on utilisera comme entité. Logiciel ACHAT INSTALL Serveur Département Logiciel ACHAT INSTALL Serveur Département

9 Base de données 9 c. Occurrence et population On appelle occurrence d un TE (TA) toute entité (association) appartenant à l ensemble décrit par le TE (TA). Une occurrence de TE est un ensemble de valeurs (éventuellement vide) pour chaque attribut du TE. Une occurrence de TA est un ensemble de valeurs (éventuellement vide) pour chaque attribut du TA et chaque occurrence de Tes qui joue un rôle dans le TA. On appelle population d un TE (TA) l ensemble des occurrences du TE (TA). III. Diagrammes Entité-Association 1. Diagramme Le modèle entité-association permet une représentation graphique assez lisible du schéma d une BD, appelée diagramme entité-association (diagramme EA) Les TE sont représentés par des rectangles, les TA par des hexagones ou autres symboles similaires (ovale, losange, ), les attributs sont soit rattachés au TE (TA) par des traits, et représentés par des ovales, soit listés à l intérieur du rectangle (hexagone), au dessous du nom du TE (TA) et séparés de celui-ci par une barre. 2. Contraintes de cardinalité Les cardinalités d un lien entre un TE et un TA sont le minimum (min) et le maximum (max) de fois qu une entité peut intervenir dans une association de ce type. Formellement : si un TA A lie n TEs (E 1, E 2,, E n ) et si (a i,b i ) représente les cardinalités du lien entre E i et A, alors a i et b i décrivent respectivement le nombre minimum et le nombre maximum de (n 1)-uplets de E 1 E i 1 E i + 1 E n auxquels une instance quelconque de E i est reliée. Remarque : - La cardinalité maximum b i est toujours 1. - Si une cardinalité est connue et vaut k > 1, on considère parfois qu elle est indéterminée N, de telle sorte qu on ne puisse avoir que des cardinalités 0, 1 ou N. - Il est impossible d avoir un couple de cardinalités (a,b) avec a > b. Propriétés : - min = 0 : toute entité peut exister tout en étant impliquée dans aucune association ; on parle de participation partielle du TE au TA. - min = 1 : aucune entité ne peut exister sans être impliquée dans au moins une association ; on parle de participation totale du TE au TA. - min = N : aucune entité ne peut exister sans être impliquée dans plusieurs associations (cas rare et complexe). - max = 0 : toute entité ne peut pas être impliquée dans une association (cas à éviter) - max = 1 : toute entité peut être impliquée dans au plus une association. - max = N : toute entité peut être impliquée dans plusieurs associations. Classification Classification d une association binaire A selon les cardinalités maximums des entités participantes E et F : - A est 1:1 si maxcard(e,a) = 1 et maxcard(f,a) = 1 - A est 1:N si maxcard(e,a) = 1 et maxcard(f,a) = N (ou vice-versa) - A est M:N si maxcard(e,a) = N et maxcard(f,a) = N

10 Base de données 10 Exemple : Employé nom salaire <0,N> <0,1> CHEF EMPLOI <0,N> <0,1> <0,N> LIVRAISON quantité <0,N> <0,N> Fournisseur nomf adresse Rayon nomr étage <0,N> VENTE quantité <0,N> Article noma type Dans l exemple ci-dessus, expliquons les contraintes de cardinalité qui entoure l association : - EMPLOI : EMPLOI Employé Rayon Commentaires e 1 e 1 r 1 r 2 e 1 e 2 - LIVRAISON : r 1 r 1 r 1 Fournisseur Rayon Article f 1 r 1 a 1 f 1 r 1 a 2 f 1 r 2 a 2 f 1 r 2 a 1 f 1 f 1 f 1 f 2 f 2 f 1 f 1 f 2 r 1 r 1 r 1 r 1 r 1 r 1 r 2 r 1 Un employé e 1 peut être employé dans aucun rayon (minimum = 0) et peut travailler dans un seul rayon r 1 au maximum (maximum = 1), ce qui explique la contrainte de cardinalité <0,1> entre Employé et EMPLOI. Dans un rayon, on peut avoir aucun employé qui y travaille (minimum = 0) mais on peut en avoir autant que l on veut (maximum = N), ce qui explique la contrainte de cardinalité <0,N> entre Rayon et EMPLOI. a 1 a 2 a 2 a 1 a 1 a 1 a 1 a 1 LIVRAISON Commentaires Un fournisseur f 1 peut être faire l objet de la livraison d aucun article dans aucun rayon (minimum = 0). De plus, un fournisseur f 1 peut fournir plusieurs articles (a 1, a 2, ) dans plusieurs rayons (r 1, r 2, ) différents (maximum = N), ce qui explique la contrainte de cardinalité <0,N> entre Fournisseur et LIVRAISON. Un rayon r 1 peut être faire l objet de la livraison par aucun fournisseur ou d aucun article (minimum = 0). De plus, un rayon r 1 peut être rempli grâce à plusieurs articles (a 1, a 2, ) et par plusieurs fournisseurs (f 1, f 2, ) différents (maximum = N), ce qui explique la contrainte de cardinalité <0,N> entre rayon et LIVRAISON. Un article a 1 peut être faire l objet de la livraison par aucun fournisseur ou dans aucun rayon (minimum = 0). De plus, un article a 1 peut être fourni par un seul fournisseur f1 mais dans plusieurs rayons (r 1, r 2, ) différents (maximum = N), ce qui explique la contrainte de cardinalité <0,N> entre article et LIVRAISON. 3. Cardinalités d un attribut Les cardinalités d un attribut spécifient le nombre de valeurs de cet attribut qui sont autorisées (au minimum, au maximum) dans : - une occurrence du TE (TA), si l attribut est directement rattaché à un TE (TA). - une valeur de l attribut dont il est composant, sinon. Un attribut est dit : - simple s il n est pas décomposé en d autres attributs : ses valeurs sont atomiques; un domaine lui est associé ; - complexe s il est décomposé en d autres attributs; ses valeurs sont composées ;

11 Base de données 11 - monovalué s il ne peut prendre qu une seule valeur par occurrence (maxcard = 1) ; - multivalué s il peut prendre plusieurs valeurs par occurrence (maxcard > 1) ; - obligatoire s il doit prendre une valeur au moins par occurrence (mincard = 1) ; - facultatif s il peut ne pas prendre de valeur dans une occurrence (mincard = 0). 4. Identifiants des TE et TA Un identifiant d un TE (TA) est constitué par un ou plusieurs attributs qui doivent avoir une valeur unique pour chaque entité (association) de ce type Les attributs appartenant à un identifiant doivent être de cardinalité (1,1). Un TE (TA) peut avoir aucun ou plusieurs identifiants : ex : n employé et (nom+prénoms) sont deux identifiants du TE Employé, si dans cette entreprise il n y a jamais deux employés ayant les mêmes nom et prénoms, ou le même numéro Les identifiants (ou clés primaires) peuvent être représentés sur le diagramme en les soulignant. Pour éviter des surcharges, les identifiants des TA peuvent être précisés textuellement en commentaire du diagramme. Règles : - si le TA a des cardinalités (1,1) pour un des TE liés, alors tout identifiant de ce TE est identifiant du TA. - si plusieurs occurrences du TA lient les mêmes occurrences des TE, alors chaque identifiant du TA contient au moins un attribut du TA. TE faible : Un TE E est dit faible si aucun sous-ensemble de ses attributs ne constitue un identifiant et qu un identifiant peut être défini en intégrant un identifiant d un autre TE qui lui est lié par un TA binaire (d identification) de cardinalité (1,1) pour E. L identifiant d un TE faible (qui est le même que celui du TA d id.) est constitué de l identifiant du TE dont il dépend et d un (ou plusieurs) attributs du TE faible IV. Contraintes d intégrité 1. Définition Une contrainte d intégrité (CI) est un ensemble de règles de contrôle de cohérence des valeurs prises par les différentes entités et associations d une BD et qui ne peut pas être décrite avec les concepts du modèle. ex : Si une personne participe à l association Mariage, alors la valeur de son attribut «état civil» doit être «mariée» : x,y Personne, <x,y> Mariage x.état-civil = marié ex : Seuls les hommes peuvent participer à l association mariage dans le rôle «époux» x,y Personne, <époux:x,y> Mariage x.sexe = M 2. Contraintes d intégrité sur les attributs Les CI les plus fréquentes limitent les valeurs d un attribut à certaines valeurs du domaine sous-jacent. ex : Age [0, 130]. Les limites peuvent être définies en fonction du contexte (valeur d un autre attribut, participation à une association, ) ex : Si mois {4,6,9,11} alors jour [1:30], sinon si mois = 2 alors jour [1:29] sinon jours [1:31]. ex : Si une personne participe à l association Mariage, alors la valeur de son état civil doit être «marié».

12 Chapitre 3 Construction d un schéma EA I. Introduction Afin de pouvoir construire le schéma entité-association répondant aux besoins d une entreprise, le concepteur étudie les différents modèles existants, les dsifférents besoins et supports de l entreprise en recensant les divers documents Afin de pouvoir réunir les différentes connaissances de l entreprise et lui permettre de gérer au mieux les employés et les différents services, le concepteur procède à différentes taches : Etablir la liste des entités ; Lister leurs attributs et déterminer les identifiants ; Identifier les différentes associations reliant ces entités en établissant les différentes cardinalités ; Lister leurs attributs ; Établir les règles d intégrité ; Vérifier la cohérence et la pertinence du schéma obtenu. Exemple : Dans une agence bancaire, le directeur explique : «Nous gérons des comptes bancaires, mais aussi nous permettons aux clients d établir une épargne et d avoir une assurance. Les comptes bancaires, épargnes et assurances possèdent un numéro d identification et d une date de création. Le client possède lui aussi un numéro d identification. Nous permettons à un client de réaliser diverses opérations sur ses comptes bancaires et épargne, et nous luis envoyons une fois par mois, à une date précise, le relevé de ses comptes.» De l exposé précédent on peut extraire les informations suivantes : quatre TE : Client, Compte, Opération, Relevé. N d identification du client : attribut du TE Client N d identification, Type et Date de création du compte : attributs du TE Compte un TA : Ouvrir entre Client et Compte ; cette association a pour cardinalité (0,N) pour le TE Compte Les choix de représentation dépendent du point de vue du concepteur. C est donc seulement en examinant l utilisation des données qu il est possible de déterminer la représentation adéquate. II. Règles de modélisation Règle de représentation par un type d entité Tout ensemble d objets similaires utiles pour l application est représenté par une entité. Règle de représentation par un type d association Tout ensemble de liens similaires et de même sémantique, utiles pour qualifier l application, entre deux ou plusieurs objets représentés par des entités est représenté par une association. Règle de représentation par un attribut Toute information utile et descriptive d un objet ou d un lien, ne faisant l objet d aucun traitement en dehors de cet objet ou de ce lien est représentée par un attribut. Remarque importante : Par rapport à la réalité, un schéma est une représentation : incomplète : il ne représente que les informations qui sont jugées utiles pour l application ; partiale : il représente le point de vue du concepteur ; infidèle : il ne représente pas la réalité telle qu elle est, mais telle qu elle intéresse le concepteur.

13 Base de données 13 III. Vérification du diagramme EA Une fois le diagramme EA établi, plusieurs types de vérifications sont effectués : vérification syntaxique : il s agit de vérifier que les règles du modèle EA sont respectées ; par jeu d essai : vérifier grâce à une mini BD que le diagramme permet effectivement de stocker les informations nécessaires à l entreprise ; complétude par rapport aux traitements : vérifier que le diagramme contient tous les types d informations nécessaires à l exécution des traitements prévus ; par les utilisateurs : présenter le diagramme accompagné des définitions aux futurs utilisateurs et vérifier que les informations contenues correspondent bien aux besoins. Chaque oubli, erreur, modification,, détecté lors des vérifications entraîne une mise à jour du diagramme et relance les différentes phases de vérification. IV. Notion de dépendance Pour un TE (ou un TA) donné, on dit qu il y a dépendance d un attribut, ou un ensemble d attributs, A vers un attribut, ou un ensemble d attributs, B, si toutes les occurrences qui ont même valeur pour A ont toujours même valeur pour B : on note cette dépendance A B, et on dit que B dépend de A ou que A détermine B. Par définition, l identifiant d un TE (TA) détermine tous les autres attributs du TE (TA). Formellement, quelles que soient deux occurrences du TE (TA) de valeurs (a,b) et (a,b ) pour (A,B) : a = a b = b Soient E 1 et E 2 deux entités liées par une association A. On dit qu il y a dépendance de E 1 vers E 2 (notée E 1 E 2 ), si pour chaque occurrence de E 1, l association A lui associe toujours la même occurrence de E 2. V. Règles de validation d un diagramme EA L élaboration d un schéma EA se fait en plusieurs étapes : une de celles-ci est celle qui consiste à vérifier le schéma en utilisant un certain nombre de règles dites de vérification et de normalisation. Ces règles permettent d obtenir un schéma dans lequel les erreurs de mises à jour, d insertion et de suppression, ainsi que les redondances logiques, sont les plus limitées possibles. 1. Règles concernant les entités Règle n 1 : Existence d un identifiant pour chaque entité. Cette règle permet d aider le concepteur quand celui-ci hésite entre modéliser un concept par une entité ou par une association. Exemple : On représente une situation où des clients commandent des produits. Si le concept commande inclut un numéro de commande unique pour chaque commande, alors il faut modéliser le concept commande par une entité cf. solution 1. Sinon, on peut le modéliser par une association : la clé sera alors le couple clé (Client,Produit) cf solution 2. Client N Client Nom Prénom Solution 1 Commande N Commande PASSER Produit Code Client N Client Nom Prénom Solution 2 COMMANDE Produit Code

14 Base de données 14 Règle n 2 : Tous les attributs autres que l identifiant doivent être en dépendance fonctionnelle complète et directe de l identifiant. La notion de dépendance fonctionnelle est celle du paragraphe précédent : quelle que soit l instance de l entité considérée, la valeur de la clé est unique (deux instances différentes ne peuvent pas avoir la même valeur de clé) et pour tous les attributs non clé, il n existe qu une seule valeur (les attributs sont monovalués : la valeur d un attribut est une valeur simple et non un ensemble de valeurs). Ceci correspond à la première forme normale qui sera vue dans le chapitre 8 (1NF). La notion de dépendance complète stipule que les valeurs des attributs non clé dépendent de la valeur de toute la clé et non d une partie seulement. Exemple : L entité Episode, sur la figure ci-contre, a pour clé le couple d attributs (Nom_Série,Numéro). Si on fait l hypothèse que toute série n a qu un producteur, alors il y a une dépendance fonctionnelle Nom_Série Producteur. Donc Episode ne suit pas la règle 2. Pour suivre la règle 2, il faut transformer Episode grâce à la méthode suivante. On crée une nouvelle entité formée des attributs qui constituent la DF, et on enlève de Episode la partie droite de la DF (c est à dire l attribut Producteur). Comme, alors, il reste Nom_Série et Numéro dans Episode, et que Nom_Série est clé primaire de Production, Episode devient une entité faible, reliée à Production par une association d identification. Cette notion de dépendance complète Episode Numéro Exemple : correspond à la deuxième forme normale qui sera vue dans le chapitre 8 (2NF). La notion de dépendance directe stipule que tout attribut dépend directement de la clé, c est à dire qu il n y a pas de DF avec une partie gauche différente de la clé. Dans l entité Voiture sont présents les attributs Marque et Modèle. Or quand on connaît la valeur de Modèle, on connaît forcément la Marque. Il y a donc une DF Modèle Marque avec comme partie gauche Modèle qui n est pas la clé. Donc voiture ne suit pas la règle numéro 2. Voiture Immatriculation Couleur Modèle ID Production Nom_Série Producteur Modèle Modèle Marque Comme précédemment, on résout le problème en construisant une Episode Nom_Série Numéro Producteur Voiture Immatriculation Couleur Marque Modèle nouvelle entité dont les attributs sont les attributs de la DF et en ôtant la partie droite de la DF de l entité d origine. On obtient les deux entités à gauche. Cette notion de dépendance directe correspond à la troisième forme normale qui sera vue dans le chapitre 8 (3NF). En résumé, appliquer la règle 2 revient à mettre le schéma EA en troisième forme normale. 2. Règle concernant les associations : Règle n 3 : Tous les attributs d une association doivent dépendre complètement de la clé de cette association, c'est-à-dire de l ensemble des clés de toutes les entités associées. Chaque attribut doit dépendre de toute la clé et non d une partie de la clé seulement. Exemple : L association Achat du premier schéma relie 3 entités : Client, Produit et Fournisseur. La clé de Achat est donc (N Client, Code, N Fournisseur). Deux attributs supplémentaires figurent dans Achat : Date d achat et Prix. Il est clair que la date d achat dépend à la fois du client qui achète, du produit acheté et du fournisseur. Par contre, le prix ne dépend que du fournisseur et du produit (on suppose que le client ne peut pas marchander). On a donc la dépendance fonctionnelle (Code,N Fournisseur) Prix. Ici, la partie gauche n est pas toute la clé de Achat, mais seulement une partie. Donc Achat ne suit pas la règle 3. Pour résoudre le problème, on crée une nouvelle association à partir des attributs de la dépendance fonctionnelle et on enlève la partie droite de la dépendance fonctionnelle de l association d origine.

15 Base de données 15 On obtient le deuxième schéma. Client N Client Nom Prénom <1,N> ACHAT Date d achat Prix <0,N> Produit Code Description <0,N> Fournisseur N Fournisseur Nom Adresse Client N Client Nom Prénom <1,N> ACHAT Date d achat <0,N> <0,N> Produit Code Description <1,N> Fournisseur N Fournisseur Nom Adresse <1,N> PRIX Montant Remarque : On a stocké ici la date d achat comme attribut de Achat. Cela signifie que pour un achat, c est-à-dire pour un triplet (client,produit,fournisseur), il n y a qu une seule date correspondante. Autrement dit on ne peut pas stocker plusieurs achats identiques à deux dates différentes. Si on voulait le faire, il faudrait faire une entité spéciale pour Date et relier cette entité à l association Achat qui serait alors 4- aire. 3. Validation d un TA (arité) Règle 4 : Soit un TA bien construit, liant les TE E 1,,E n ; s il y a une dépendance (E 1,,E i ) E i + 1, alors il y a la dépendance (E 1,,E i ) (E i + 1,,E n ). Donc si un TA comporte l une de ces dépendances sans les autres, il faut décomposer le TA, afin de matérialiser cette dépendance par un nouveau TA de cardinalité maximum 1 pour le rôle source de la dépendance. <0,N> <0,N> Chercheur TRAVAILLE Laboratoire <1,N> Projet Dans l exemple ci-dessus, cette dépendance traduit la règle d entreprise : chaque projet est réalisé dans un et un seul laboratoire. Le diagramme précédent n est pas correct. La dépendance doit être décrite par un TA binaire reliant les deux TE Projet et Labo, le TE restant sera lié par un TA binaire au TE source de la dépendance.

16 Base de données 16 La correction du diagramme est donnée ci-après. <0,1> Chercheur TRAVAILLE <1,N> Projet <1,1> AFFECTE <0,N> Laboratoire 4. Elimination des types d association (TA) redondants Un TA est redondant si les associations correspondantes peuvent être établies sans ambiguïté par composition des associations d autres TA <1,N> <1,N> <1,N> Etudiant INSCRIT Cours ASSURE <1,N> Enseignant <1,N> EST ELEVE DE <1,N> Si pour l application on veut conserver un TA redondant, il faut alors déclarer par une contrainte d intégrité que ce TA est dérivé d autres. 5. Transformation des attributs référence Si l on trouve dans un TE E 1 un attribut dont la valeur est égale à celle de l identifiant d un TE E 2, cet attribut exprime un lien entre E 1 et E 2. Ce lien doit être explicitement décrit comme une association entre les deux TE et l attribut supprimé de E 1. Employé N Employé Nom Prénom #N Service Service N Service Etage Nom Employé N Employé Nom Prénom <1,1> <1,N> Service TRAVAILLE N Service Etage Nom 6. TE ou attribut complexe? Si un TE retenu a priori se révèle ne présenter d intérêt pour aucun traitement de l application mais qu il faut néanmoins conserver l information correspondante, il convient de rattacher celle-ci, sous forme d un attribut, au TE (TA) où elle est pertinente.

17 Base de données 17 Employé N Employé Nom Prénom Service N Service Etage Nom Employé N Employé Nom Prénom Service N Service Etage Nom Un TE qui n a qu un seul attribut doit être transformé en attribut des TE auxquels il est relié. Cours N Cours Intitulé Horaire <1,1> <0,1> ALIEU Salle N Salle Cours N Cours Intitulé Horaire N Salle Si un TE possède un attribut complexe qui fait l objet de traitements indépendamment du TE en question, il faut le remplacer par un TE, plus un TA qui conserve le lien avec le TE d origine. Etudiant N Etudiant Nom Prénom Cours Intitulé Salle Horaire Etudiant N Etudiant Nom Prénom <0,N> <0,N> Cours INSCRIT Intitulé Salle Horaire

18 Base de données 18 VI. Description d un schéma EA 1. Entités : Une entité est décrite par : le nom du type d entité ; une définition précisant la population exacte de l entité ; la description des attributs de l entité ; la composition des identifiants de l entité, s il en existe. Exemple (TE Employé de la BD hypermarché) : nom : Employé définition : «toute personne employée de l entreprise en ce moment» attributs : nom, salaire (avec leur description) identifiant : nom Remarque : Deux TE différents peuvent avoir le même nom. La définition libre est une partie importante de la description du TE et permet de définir exactement, de façon non ambiguë, la population du TE. 2. Associations : Une association est décrite par : le nom du type d association ; une définition précisant la population exacte du TA ; les noms des entités participant à l association, avec le nom du rôle si nécessaire ; pour chaque rôle, ses cardinalités : min 0, max 1 ; la description des attributs du TA, s il en existe ; la composition des identifiants du TA, s il en existe. Exemple (TA Emploi de la BD hypermarché) : nom : Emploi définition : «lie un employé au rayon dans lequel celui-là travaille aujourd hui» TE participants : Employé, Rayon cardinalités : Employé: 0:1 Rayon: 0:n identifiants : (Employé.nom + Rayon.nomR) 3. Attributs : Un attribut est décrit par les spécifications suivantes : le nom de l attribut ; une définition (libellé clair) ; la cardinalités ; le domaine de valeurs si l attribut n est pas composé d autres, la description des attributs composants sinon. Exemple (attribut «date de naissance» d un TE Personne) : nom : date de naissance définition : «date de naissance de la personne» cardinalités : min = 1, max = 1 composition : nom : jour ; définition : «jour de naissance de la personne» ; cardinalités : min = 1, max = 1 ; domaine : l intervalle entier [1,31] nom : mois ; définition : «mois de naissance de la personne» ; cardinalités : min = 1, max = 1 ; domaine : l intervalle entier [1,12] nom : année ; définition : «année de naissance de la personne» ; cardinalités : min = 1, max = 1 ; domaine : l intervalle entier [1870,2004]

19 Chapitre 4 Modèle Relationnel I. Introduction Le modèle relationnel est un modèle d informations structurées un tableau de valeurs. Les relations sont des tables avec des restrictions : l ordre des lignes (tuples) n est pas significatif ; l ordre de colonnes (attributs) n est pas significatif ; pas de duplication de lignes. II. Concepts de base : 1. Domaine Un domaine est un ensemble de valeurs que peut prendre un attribut : Dnom : chaine de caractères de longueur maximale 30 ; Djour : {lundi, mardi, mercredi, jeudi, vendredi, samedi, dimanche} ; Dmois : {janvier, février, mars, avril,, octobre, novembre, décembre} ; Dcouleur : {rouge, vert, bleu, jaune,..., violet} ; Dâge : [0,125] ; Dsalaire : R Relation Une relation est définie par son schéma de relation et ses valeurs. Schéma d une relation : R(A 1 :D 1,,A n :D n ) R : nom de la relation A 1,,A n : attributs, tous distincts D 1,,D n : domaines des attributs, non nécessairement tous distincts (A 1 :D 1,,A n :D n ) : structure (type de tuple) Tuple : {A 1 :d 1,,A n :d n } un ensemble de couples <attribut,valeur> Valeur d une relation : sous-ensemble de tuples de l ensemble : {{ A 1 :d 1,,A n :d n } d i D i } Exemple Schéma de la relation Etudiant : Etudiant ( N étud:dnum, Nom:Dnom, Prénom:Dnom, Age:Dâge ) Une valeur de la relation Etudiant : Age Prénom Nom N étud 21 Marc Rochat André Duval Annie Aubry Jean Rochat 136 III. Base de données relationnelle 1. Introduction Un schéma d une BD relationnelle est un ensemble de schémas de relations auquel on ajout les contraintes d intégrité.. Une base de données relationnelle est un ensemble de relations. Une valeur d une BD est un ensemble de valeurs de relations.

20 Base de données Clés d une relation a. Définitions Les clés d une relation sont des ensembles d attributs qui déterminent tous les autres attributs de la relation. Ainsi, les clés d une relation ont la propriété d identification unique de tuples lorsque deux tuples n ont jamais la même valeur pour cet ensemble d attributs. Formellement, quelles que soient tuples de la relation R de valeurs (a,b) et (a,b ) pour (A,B) : a est un clé de la relation R si : a = a b = b Une super-clé est un ensemble d attributs qui identifie de manière unique un tuple de la relation Une clé est une super-clé minimale, c'est-à-dire une superclé dont on ne peut enlever aucun attribut sans lui faire perdre son statut de superclé; en général, une relation a plusieurs clés (on parle de clés candidates). La définition des clés est une information intentionnelle (appartient au schéma), donc valide pour toutes les extensions possibles de la relation b. Clé primaire Une clé primaire est une clé privilégiée choisie parmi les clés candidates. Ses valeurs doivent toujours être connues (sans valeur NULL). Son choix est arbitraire, peut se faire par des heuristiques (e.g. plus simple), mais elle peut être inventée pendant la phase de conception de la BD. Dans le schéma de relation, la clé primaire sera soulignée. Exemple Etudiant (Code_per, Nom, Prenom, Adresse, Date_nais, Lieu_nais, NASS) Quelles sont les clés candidates? Code_per, NASS, (Nom,Prenom,Adresse) Quelle clé primaire choisir? Code_per c. Clé étrangère Soit R 2 une relation, un sous-ensemble d attributs FK dans R 2 est dit clé étrangère lorsque : il existe une relation R 1 de clé primaire PK (R 1 peut être R 2 ) à tout instant, chaque valeur de FK dans R 2 est identique à une valeur de PK dans R 1 On fera précéder les clés étrangères du caractère dièse (#). Exemple Etudiant(N étud, nom, prénom, âge) Cours(NomC, horaire, prof) Suit(#N étud, #NomC) Propriétés Il n est pas nécessaire d avoir pour toute valeur de PK dans R 1 une valeur identique de FK dans R 2 ; Un attribut d une clé étrangère peut faire partie d une clé candidate de sa relation ; Chaque attribut d une clé étrangère doit être défini sur le même domaine que son équivalent dans la clé primaire correspondante. 3. Contraintes d intégrité a. Définition : Contrainte : c est une assertion vérifiée par les données de la base à tout moment sans être définie au niveau de la structure. Les contraintes relationnelles comprennent : Les contraintes structurelles : liées au modèle relationnel, à l unicité des valeurs de clés, Les contraintes comportementales : liées aux applications Les contraintes intra-relationnelles : mettant en jeu une seule relation sur la non nullité d un attribut Les contraintes inter-relationnelles : mettant en jeu plusieurs relations sur l intégrité référentielle (existence des clés étrangères)

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

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

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

Modélisation Conceptuelle. Partie 2: Le modèle Entité-Association

Modélisation Conceptuelle. Partie 2: Le modèle Entité-Association Modélisation Conceptuelle Partie 2: Le modèle Entité-Association Modèle de type conceptuel But: permettre la description conceptuelle des structures de données d'une application Les concepts de base (correspondent

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

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

Introduction aux Bases de Données

Introduction aux Bases de Données Introduction aux Bases de Données I. Bases de données I. Bases de données Les besoins Qu est ce qu un SGBD, une BD Architecture d un SGBD Cycle de vie Plan du cours Exemples classiques d'applications BD

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

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

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

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

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

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

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

Chap. 3: Le modèle de données entité-association (E.A.)

Chap. 3: Le modèle de données entité-association (E.A.) Chap. 3: Le modèle de données entité-association (E.A.) En anglais: Entity-Relationship (ER) Origines: C.Bachman (1969), P.Chen (1976). Modèle de données > décrire la réalité perçue à travers les données

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

UML (Diagramme de classes) Unified Modeling Language

UML (Diagramme de classes) Unified Modeling Language UML (Diagramme de classes) Unified Modeling Language Sommaire Introduction Objectifs Diagramme de classes Classe (Nom, attribut, opération) Visibilité et portée des constituants d une classe Association

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

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2 éducalgo Manuel d utilisation 26 juin 2011 Table des matières 1 Tâche à effectuer : écrire un algorithme 2 2 Comment écrire un algorithme? 3 2.1 Avec quoi écrit-on? Avec les boutons d écriture........

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. 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

Systèmes d information et bases de données (niveau 1)

Systèmes d information et bases de données (niveau 1) Systèmes d information et bases de données (niveau 1) Cours N 1 Violaine Prince Plan du cours 1. Bibliographie 2. Introduction aux bases de données 3. Les modèles 1. Hiérarchique 2. Réseau 3. Relationnel

Plus en détail

II. Modèle conceptuel le modèle entité-association

II. Modèle conceptuel le modèle entité-association II. Modèle conceptuel le modèle entité-association Personne Voiture Schéma conceptuel Monde réel υ Concepteur υ Personne conduit Voiture ϖ ϖ Schéma logique utilisateurs ω LMD BD Personne Dupont Durant

Plus en détail

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

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

Modèle Entité/Association

Modèle Entité/Association Base de données Modèle Entité/Association L3 Informatique Antoine Spicher antoine.spicher@u-pec.fr Contexte du cours Organisation du cours 1 ère partie (C. D.) Modèle et algèbre relationnel Langage SQL

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

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

Bases de données Cours 1 : Généralités sur les bases de données

Bases de données Cours 1 : Généralités sur les bases de données Cours 1 : Généralités sur les bases de données POLYTECH Université d Aix-Marseille odile.papini@univ-amu.fr http://odile.papini.perso.esil.univmed.fr/sources/bd.html Plan du cours 1 1 Qu est ce qu une

Plus en détail

Formation à l utilisation des Systèmes de Gestion de Bases de Données Relationnelles. organisée avec la collaboration du

Formation à l utilisation des Systèmes de Gestion de Bases de Données Relationnelles. organisée avec la collaboration du Proyecto FAO COPEMED Universidad de Alicante Ramón y Cajal, 4 03001 - Alicante, España GCP/REM/057/SPA Web : www.fao.org/fi/copemed Tel : +34 96 514 59 79 Fax : +34 96 514 59 78 Email : copemed@ua.es Formation

Plus en détail

Introduction aux bases de données Cours 1 : Généralités sur les bases de données

Introduction aux bases de données Cours 1 : Généralités sur les bases de données Cours 1 : Généralités sur les bases de données ESIL Université de la méditerranée Odile.Papini@esil.univmed.fr http://odile.papini.perso.esil.univmed.fr/sources/bdmat.html Plan du cours 1 1 Qu est ce qu

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

Cours Bases de données

Cours Bases de données Informations sur le cours Cours Bases de données 9 (10) séances de 3h Polycopié (Cours + TD/TP) 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine antoine.cornuejols@agroparistech.fr Transparents Disponibles

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

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

Chapitre VIII. Les bases de données. Orientées Objet. Motivation

Chapitre VIII. Les bases de données. Orientées Objet. Motivation Chapitre VIII Motivation Le modèle relationnel connaît un très grand succès et s avère très adéquat pour les applications traditionnelles des bases de données (gestion) Les bases de données Orientées Objet

Plus en détail

Dossier I Découverte de Base d Open Office

Dossier I Découverte de Base d Open Office ETUDE D UN SYSTEME DE GESTION DE BASE DE DONNEES RELATIONNELLES Définition : Un SGBD est un logiciel de gestion des données fournissant des méthodes d accès aux informations. Un SGBDR permet de décrire

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

Base de Données et Langage SQL

Base de Données et Langage SQL Base de Données et Langage SQL (IUT, département informatique, 1 re année) Laurent AUDIBERT Institut Universitaire de Technologie de Villetaneuse Département Informatique Avenue Jean-Baptiste Clément 93430

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

Modélisation conceptuelle des données Responsable: Dominique Schneuwly, Regis Caloz

Modélisation conceptuelle des données Responsable: Dominique Schneuwly, Regis Caloz Geographic Information Technology Training Alliance (GITTA) presents: Modélisation conceptuelle des données Responsable: Dominique Schneuwly, Regis Caloz Table des matières 1. Modélisation conceptuelle

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

Langage SQL (1) 4 septembre 2007. IUT Orléans. Introduction Le langage SQL : données Le langage SQL : requêtes

Langage SQL (1) 4 septembre 2007. IUT Orléans. Introduction Le langage SQL : données Le langage SQL : requêtes Langage SQL (1) Sébastien Limet Denys Duchier IUT Orléans 4 septembre 2007 Notions de base qu est-ce qu une base de données? SGBD différents type de bases de données quelques systèmes existants Définition

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

Conception d une base de données

Conception d une base de données Conception d une base de données Cyril Gruau 17 octobre 2005 (corrigé le 13 juillet 2006) Résumé Ce support de cours regroupe quelques notions concernant le modélisation conceptuelle de système d information

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

INFO 364 : Bases de Données Projet Professeur : Esteban Zimányi Assistants : Pierre Stadnik et Mohammed Minout Année Académique : 2004-2005

INFO 364 : Bases de Données Projet Professeur : Esteban Zimányi Assistants : Pierre Stadnik et Mohammed Minout Année Académique : 2004-2005 Université Libre de Bruxelles Faculté des Sciences Appliquées & Faculté des Sciences INFO 364 : Bases de Données Projet Professeur : Esteban Zimányi Assistants : Pierre Stadnik et Mohammed Minout Année

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

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

IT203 : Systèmes de gestion de bases de données. A. Zemmari zemmari@labri.fr

IT203 : Systèmes de gestion de bases de données. A. Zemmari zemmari@labri.fr IT203 : Systèmes de gestion de bases de données A. Zemmari zemmari@labri.fr 1 Informations pratiques Intervenants : Cours : (A. Zemmari zemmari@labri.fr) TDs, TPs : S. Lombardy et A. Zemmari Organisation

Plus en détail

OBJECTIFS ET ARCHITECTURE DES SGBD

OBJECTIFS ET ARCHITECTURE DES SGBD OBJECTIFS ET ARCHITECTURE DES SGBD 1. INTRODUCTION Même si vous n avez jamais utilisé de système de gestion de bases de données (SGBD), vous avez certainement une idée de ce qu est une base de données

Plus en détail

LE MODELE CONCEPTUEL DE DONNEES

LE MODELE CONCEPTUEL DE DONNEES LE MODELE CONCEPTUEL DE DONNEES Principe : A partir d'un cahier des charges, concevoir de manière visuelle les différents liens qui existent entre les différentes données. Les différentes étapes de réalisation.

Plus en détail

Modèle Entité-Association. C est un modèle important pour la conception des bases de données relationnelles. Il

Modèle Entité-Association. C est un modèle important pour la conception des bases de données relationnelles. Il Le modèle Entité-Association C est un modèle important pour la conception des bases de données relationnelles. Il est très répandu, très documenté. Il aide à concevoir une base de données sans redondance,

Plus en détail

Initiation aux bases de données (SGBD) Walter RUDAMETKIN

Initiation aux bases de données (SGBD) Walter RUDAMETKIN Initiation aux bases de données (SGBD) Walter RUDAMETKIN Bureau F011 Walter.Rudametkin@polytech-lille.fr Moi Je suis étranger J'ai un accent Je me trompe beaucoup en français (et en info, et en math, et...)

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

Bases de données avancées Introduction

Bases de données avancées Introduction Bases de données avancées Introduction Dan VODISLAV Université de Cergy-Pontoise Master Informatique M1 Cours BDA Plan Objectifs et contenu du cours Rappels BD relationnelles Bibliographie Cours BDA (UCP/M1)

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

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

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

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

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

Méthode d analyse Merise

Méthode d analyse Merise Méthode d analyse Merise - Frédéric Julliard Université de Bretagne Sud UFR SSI - IUP Vannes - année 2001-2002 Approche ancienne : 1978 Très répandue en France Origine française : développée par : CTI

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

MERISE. Modélisation de Systèmes d Information. Pierre Gérard. DUT Informatique 2ème année 2004/2005. IUT de Villetaneuse - Université de Paris 13

MERISE. Modélisation de Systèmes d Information. Pierre Gérard. DUT Informatique 2ème année 2004/2005. IUT de Villetaneuse - Université de Paris 13 Modélisation de Systèmes d Information IUT de Villetaneuse - Université de Paris 13 DUT Informatique 2ème année 2004/2005 LATEX Cycle de vie Introduction Processus de développement d un logiciel La méthode

Plus en détail

1. LA GESTION DES BASES DE DONNEES RELATIONNELLES

1. LA GESTION DES BASES DE DONNEES RELATIONNELLES Dossier G11 - Interroger une base de données La base de données Facturation contient tout un ensemble d'informations concernant la facturation de la SAFPB (société anonyme de fabrication de produits de

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

CESI Bases de données

CESI Bases de données CESI Bases de données Introduction septembre 2006 Bertrand LIAUDET EPF - BASE DE DONNÉES - septembre 2005 - page 1 PRÉSENTATION GÉNÉRALE 1. Objectifs généraux L objectif de ce document est de faire comprendre

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

Concevoir un modèle de données Gestion des clients et des visites

Concevoir un modèle de données Gestion des clients et des visites page 1 MCD Concevoir un modèle de données Gestion des clients et des visites La gestion des informations d une organisation est un élément essentiel de son efficacité. L obligation de les trouver et de

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

Bases de données cours 1

Bases de données cours 1 Bases de données cours 1 Introduction Catalin Dima Objectifs du cours Modèle relationnel et logique des bases de données. Langage SQL. Conception de bases de données. SQL et PHP. Cours essentiel pour votre

Plus en détail

Le langage SQL Rappels

Le langage SQL Rappels Le langage SQL Rappels Description du thème : Présentation des principales notions nécessaires pour réaliser des requêtes SQL Mots-clés : Niveau : Bases de données relationnelles, Open Office, champs,

Plus en détail

Introduction aux Bases de Données Relationnelles Conclusion - 1

Introduction aux Bases de Données Relationnelles Conclusion - 1 Pratique d un : MySQL Objectifs des bases de données Où en sommes nous? Finalement, qu est-ce qu un? Modèle relationnel Algèbre relationnelle Conclusion SQL Conception et rétro-conception Protection de

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

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

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

INTRODUCTION AUX BASES de DONNEES

INTRODUCTION AUX BASES de DONNEES INTRODUCTION AUX BASES de DONNEES Équipe Bases de Données LRI-Université Paris XI, Orsay Université Paris Sud Année 2003 2004 1 SGBD : Fonctionnalités et Principes Qu est qu une base de données? Un Système

Plus en détail

Du 10 Fév. au 14 Mars 2014

Du 10 Fév. au 14 Mars 2014 Interconnexion des Sites - Design et Implémentation des Réseaux informatiques - Sécurité et Audit des systèmes - IT CATALOGUE DE FORMATION SIS 2014 1 FORMATION ORACLE 10G 11G 10 FEV 2014 DOUALA CAMEROUN

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

Bases de Données. Stella MARC-ZWECKER. stella@unistra.u-strasbg.fr. Maître de conférences Dpt. Informatique - UdS

Bases de Données. Stella MARC-ZWECKER. stella@unistra.u-strasbg.fr. Maître de conférences Dpt. Informatique - UdS Bases de Données Stella MARC-ZWECKER Maître de conférences Dpt. Informatique - UdS stella@unistra.u-strasbg.fr 1 Plan du cours 1. Introduction aux BD et aux SGBD Objectifs, fonctionnalités et évolutions

Plus en détail

Cours d introduction à l informatique. Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions

Cours d introduction à l informatique. Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions Cours d introduction à l informatique Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions Qu est-ce qu un Une recette de cuisine algorithme? Protocole expérimental

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

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

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

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

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Conception, architecture et urbanisation des systèmes d information

Conception, architecture et urbanisation des systèmes d information Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction

Plus en détail

COURS de BASES de DONNEES

COURS de BASES de DONNEES COURS de BASES de DONNEES Céline Robardet INSA-Lyon Point de départ Une base de données est une collection de données ayant une origine commune Un Système de Gestion de Base de Données (SGBD) est un logiciel

Plus en détail

... /5. Bases de Données I (J. Wijsen) 23 janvier 2009 NOM + PRENOM : Orientation + Année : Cet examen contient 11 questions.

... /5. Bases de Données I (J. Wijsen) 23 janvier 2009 NOM + PRENOM : Orientation + Année : Cet examen contient 11 questions. Bases de Données I (J. Wijsen) 23 janvier 2009 NOM + PRENOM : Orientation + Année : Cet examen contient 11 questions. Question 1 Donnez la traduction en modèle relationnel du schéma Entité-Association

Plus en détail

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed 6, bd maréchal Juin F-14050 Caen cedex 4 Spécialité Informatique 2 e année Rapport de projet Gestion du parc informatique matériel et logiciel de l Ensicaen SAKHI Taoufik SIFAOUI Mohammed Suivi ENSICAEN

Plus en détail

Sage 100 CRM Guide de l Import Plus avec Talend Version 8. Mise à jour : 2015 version 8

Sage 100 CRM Guide de l Import Plus avec Talend Version 8. Mise à jour : 2015 version 8 Sage 100 CRM Guide de l Import Plus avec Talend Version 8 Mise à jour : 2015 version 8 Composition du progiciel Votre progiciel est composé d un boîtier de rangement comprenant : le cédérom sur lequel

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

Diagramme de classes

Diagramme de classes Diagramme de classes Un diagramme de classes décrit les classes et leurs relations (associations, généralisation/spécialisation, ). classe association méthodes attributs héritage Diagramme de classes :

Plus en détail

Ecole des Hautes Etudes Commerciales HEC Alger. par Amina GACEM. Module Informatique 1ière Année Master Sciences Commerciales

Ecole des Hautes Etudes Commerciales HEC Alger. par Amina GACEM. Module Informatique 1ière Année Master Sciences Commerciales Ecole des Hautes Etudes Commerciales HEC Alger Évolution des SGBDs par Amina GACEM Module Informatique 1ière Année Master Sciences Commerciales Evolution des SGBDs Pour toute remarque, question, commentaire

Plus en détail

Vincent Augusto 2010-2011

Vincent Augusto 2010-2011 le des Systèmes Vincent Augusto École Nationale Supérieure des Mines de Saint-Étienne 2010-2011 Un 1/73 le des Un 2/73 1 2 3 4 le 5 6 7 8 Un le des Un 3/73 Contenu du cours : Techniques pour l analyse

Plus en détail

Bases de données réparties: Fragmentation et allocation

Bases de données réparties: Fragmentation et allocation Pourquoi une base de données distribuée? Bibliographie Patrick Valduriez, S. Ceri, Guiseppe Delagatti Bases de données réparties: Fragmentation et allocation 1 - Introduction inventés à la fin des années

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

clef primaire ; clef étrangère ; projection ; restriction ; jointure ; SQL ; SELECT ; FROM ; WHERE

clef primaire ; clef étrangère ; projection ; restriction ; jointure ; SQL ; SELECT ; FROM ; WHERE Cas Neptune hôtel Base de données et langage SQL Propriété Intitulé long Formation concernée Matière Notions Transversalité Présentation Description Neptune Hôtel. L interrogation d une base de données

Plus en détail

Utiliser Access ou Excel pour gérer vos données

Utiliser Access ou Excel pour gérer vos données Page 1 of 5 Microsoft Office Access Utiliser Access ou Excel pour gérer vos données S'applique à : Microsoft Office Access 2007 Masquer tout Les programmes de feuilles de calcul automatisées, tels que

Plus en détail

Cours 1 : introduction

Cours 1 : introduction Cours 1 : introduction Modèle entité-association Exemple : Deux entités (produit et dépôt) sont mises en relation (stock). Une entité doit être constituée d un identifiant et peut être complétée par des

Plus en détail