PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II

PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II

Contenu du Chapitre I Présentation du plan de cours
Informations utiles Source des notes de cours ftp://dmiftp.uqtr.ca/FMeunier/pro1024/ Local: 3081R No. de téléphone: ext. 3833

Contenu du Chapitre I Introduction aux bases de données Concepts
Normalisation Exemple d’application en industrie

Introduction aux bases de données (Concepts)
Définitions importantes Bases de données: ensemble de tables (tableaux) contenant de l’information pouvant être stockées localement sur un disque dure ou à distance sur des serveurs dédiés Table: Ensemble d’enregistrements (rangées dans un tableau) structurés de façon unique Enregistrement: Ensemble de champs (attributs, caractéristiques) liés entre eux par une ou plusieurs relations Champ: Plus petite unité d’information ne pouvant plus être décomposée en sous-unité

Les outils modernes de développement et de gestion des bases de données sont basés sur le modèle relationnel. Ces principes se retrouvent dans tous les outils de développement des bases de données (ex: ACCESS, SQLSERVER, ORACLE etc.). Pour bien concevoir une base de données il faut appliquer un ensembles de règles appelées: normalisation. Ces règles permettent d'éviter d'introduire des anomalies dans la structure de la base de données, pouvant facilement conduire à des erreurs durant les manipulations des données: entrée des données, mise-à-jour et destruction de données.

Un Système de Gestion de Base de Données relationnel n’est en fait qu’un logiciel comme un autre. Sa principale fonction est de stocker de l’information et de répondre à des requêtes d’information en établissant un dialogue avec une application cliente. Ce dialogue repose sur un langage, généralement SQL. Un SGBD possède trois caractéristiques fondamentales: Une ou plusieurs structures de données (des tableaux de données) qui vont contenir les données. Ces tableaux sont sauvegardés dans l'ordinateur. Un langage de manipulation et d'interrogation pour obtenir les informations à partir des structures de données, comme le langage SQL (Structured Query Language). Des utilitaires qui assurent l'intégrité des données ou leur validité durant les manipulations de ces données: ajouts, modifications et destructions.

Système de Gestion de Base de Données relationnel

Dans un modèle relationnel, les structures de données qui contiennent les données sont des tableaux composés de plusieurs colonnes (champs) et de plusieurs lignes (enregistrements). Un tableau contient toutes les données reliées à un certain type d'élément. Par exemple, voici un tableau qui contient les données reliées aux employés d'une entreprise:

"Employés" est le nom du tableau ou groupe de données. Ce tableau décrit les données de ce qu'on appelle "une relation". Le tableau décrit les données d'une relation. La relation est la structure logique qui permet de gérer, en plus des données, les opérations de manipulation et de contrôle d'intégrité des données. Dans le tableau Employés, il y a 9 enregistrements ou lignes. Notez qu'une ligne décrit une entité, un employé en particulier. On dit aussi qu'une ligne contient les données d'un employé particulier. Les titres en haut du tableau sont les attributs de la relation ou du tableau.

Chaque enregistrement (rangée) d'une relation doit décrire une entité particulière de façon unique. Pour cette raison, un tableau doit contenir une clé primaire qui est un attribut dont la valeur permet d'identifier la ligne de façon unique. Dans l'exemple précédent la clé primaire est le "No. employé". En effet, c'est le numéro de l'employé qui est utilisé pour identifier un employé de façon unique. Notez que les autres attributs ne peuvent pas identifier un employé de façon unique. Parfois, une combinaison de plusieurs attributs peut constituer la clé primaire (clé primaire composée). Dans le tableau "Employés", nous pourrions prendre comme clé primaire les attributs "Nom" et "Prénom". Ces attributs permettent d'identifier de façon unique un employé. Notez cependant que cela suppose que deux employés ne peuvent pas avoir le même nom-prénom, ce qui représente une contrainte additionnelle qu'il faudrait contrôler.

En plus de la clé primaire, nous pouvons avoir aussi une ou plusieurs clés externes. Voici une autre relation qui décrit les commandes:

Dans le tableau "Commandes", l’attribut "No. commande" est la clé primaire de la relation "Commandes". L'attribut "No. employé" qui décrit l’employé qui a préparé la commande, est une clé externe. En effet, les numéros d'employé qui sont valides doivent se trouver déjà dans la colonne "No. employé" de la relation "Employés", laquelle colonne est la clé primaire de cette dernière relation. Il y a donc un lien de dépendance entre les relations "Employés" et "Commandes": "No. employé" des commandes dépend de l'attribut "No. employé" de la relations "Employés".

Il pourrait aussi exister un lien de dépendance multiple (deux clés étrangères) entre les relations "Employés", "Clients", et "Commandes": "No. employé" des commandes dépend encore de l'attribut "No. employé" de la relation "Employés" et "Code Client" des commandes dépend de l’attribut "Code Client" de la relation "Clients".

Une base de données relationnelle est constituée de plusieurs relations qui ont des liens entre elles (via les clés externes), ainsi que des contraintes d'intégrité. Voici une liste de propriétés générales de base que ces relations doivent avoir: Chaque relation a un nom unique Une entrée dans une cellule d'une table doit contenir une donnée atomique (pas de valeur multiple comme un ensemble, une liste, un tableau, ...). Chaque ligne (enregistrement) d'un tableau est unique i.e. deux lignes d'un tableau ne sont jamais identiques Chaque attribut ou colonne dans un tableau a un nom unique dans le tableau La propriété 2 implique qu'on ne peut pas mettre plusieurs valeurs dans une cellule d'un tableau. À titre d'exemple, une commande typique va contenir une liste de produits commandés dans cette commande. Or, selon la propriété 2, on ne pas mettre une telle liste dans une cellule. Que faire alors? La solution consiste à créer une nouvelle relation (détails-commande) qui contient tous les produits commandés de toutes les commandes.

Voici comment on procède si nous ajoutons la liste des produits commandés à la relation "Commandes": nous créons la nouvelle relation "Détails-commandes".

Dans la relation "Détails-commandes" précédente, nous pouvons remarquer que la commande no contient trois produits commandés qui sont définis par leur numéro "Réf.-produit" (11, 42 et 72). Ces derniers numéros font référence à la relation "Produits" (non présentée dans le texte) qui définit chaque produit. Notez que la clé de la relation "Détails-commandes" est la clé composée "No. commande-Réf. produit". Les tableaux précédents ne contiennent pas tous les attributs qui sont réellement nécessaires: ce sont des exemples partiels, pour simplifier la présentation, nous dirons pour l’instant que cette base de données est non normalisée.

Introduction aux bases de données (Concepts: Contraintes d’intégrités)
Le modèle relationnel inclut plusieurs types de contraintes qui servent à faciliter le contrôle de la validité des données lors de mises-à-jour. Les types principaux de contraintes sont: contraintes de domaine: représentent les valeurs et leurs types qui sont admissibles dans une cellule intégrité des entités: avec la clé primaire (obligatoirement non nulle), on s'assure de l'unicité des entités intégrité référencielle: dans le cas de la relation "Commandes", l'attribut "No. employé" est une clé externe qui est définie dans la relation "Employés". Les clés externes représentent des liens entre les tableaux. Aussi, on ne peut entrer un numéro d'employé dans le tableau "Commandes" que si ce numéro est déjà défini dans le tableau "Employés". L'intégrité référentielle consiste à contrôler ce type de lien entre les relations. contraintes opératoires: dans chaque type d'entreprise on retrouve des règles de fonctionnement particulières (business rules). Par exemple, on peut obliger qu'un client ne puisse obtenir des billets de série éliminatoire qui si ce client a un billet de saison.

Introduction aux bases de données (Concepts: Liens entre relations)
La clé primaire d'une relation permet de lier le contenu d'une relation avec une autre relation. Par exemple, dans la relation "Commandes", le "No commande" permet d'identifier de façon unique chaque commande. L'attribut "No commande" dans la relation "Détails commandes" définit un lien de type 1 à plusieurs (1 à N ou 1:N) entre la relation "Commandes" et la relation "Détails commandes". En effet, un numéro de commande qui apparaît dans la relation "Détails commandes" doit d'abord être défini dans la relation "Commandes" et il n'y apparaît qu'une seule fois (1), car "No commande" est la clé de cette relation et doit donc être unique. Aussi, dans la relation "Détails commandes" un même numéro de commande peut apparaître plusieurs fois (à plusieurs).

Nous trouvons aussi des liens de type 1 à 1. Par exemple, lorqu'un fournisseur expédie des produits qui ont été commandés par un client, alors le fournisseur va préparer un bon de livraison qui est destiné au service d'approvisionnement du client et aussi une facture qui est destinée au service des finances du client. Ainsi, pour chaque bon de livraison il y a une et une seule facture. Si nous avons la relation "Bons de livraison" et la relation "Factures", alors il y a un lien "1 à 1" entre l'attribut "No bon livraison" de la relation "Bons de livraison" et l'attribut "No bon livraison" de la relation"Factures" puisque la facture doit correspondre à une et une seule livraison.

Dans un modèle relationnel, on distingue plusieurs types de liens entre les entités (relations). Lors du passage du modèle conceptuel (logique) au modèle physique ces liens seront représentés soit par l’insertion de clé étrangères dans certaines tables, soit par la création de nouvelles tables. Lien de type Un-à-Un Un lien Un-à-Un existe quand pour chaque clé primaire il y a zéro ou une valeur correspondante pour un autre champ ou un autre enregistrement. Lorsque la relation concerne des champs, ceux-ci sont généralement placés dans une même table, mais cela n’est pas obligatoire. Lorsque la relation concerne des entités (des enregistrements dans le modèle physique) elle peut s’étendre entre deux entités ou bien d’une entité vers elle-même. Ce dernier cas permet la représentation de hiérarchies 3 (par exemple l’entité "employé" peut avoir une relation vers une autre entité "employé" .

Lien de type Un-à-N Un lien Un-à-N (un à plusieurs) existe quand, pour chaque enregistrement dans une table il existe zéro ou plusieurs enregistrements liés dans une autre table (exemple : un client a plusieurs commandes). Lien de type N-à-Un Ce lien existe lorsque plusieurs enregistrements d’une même table font référence de façon non ambiguë à un seul enregistrement d’une autre table. On appelle parfois ce lien un lien « Lookup » ou table de référence car il représente une référence vers la clé primaire d’une autre table. Un lien N-à-Un impliquant des clés étrangères peut généralement être renversé (en Un-à-N), alors qu’un lien Un-à-N impliquant que des clés primaires (liens identifiants) ne peut pas être renversé en N-à-Un.

Lien de type N-à-N Un tel lien existe lorsque plusieurs enregistrements d’une même table sont liés à plusieurs autres enregistrements d’une autre table. Ce lien est réversible par essence. Un exemple classique est celui des commandes et des articles: plusieurs commandes peuvent faire références au même article, et plusieurs articles peut être utilisés dans une même commande.

Introduction aux bases de données (Normalisation: FORMES NORMALES)
La normalisation est un procédé formel qui permet de décider comment regrouper les attributs en relations et de vérifier la validité des relations (ces regroupements d'attributs). La normalisation a pour but de préserver la cohérence des données lors du stockage et de la mise à jour des informations. Ce procédé de normalisation est réalisé en étapes successives qu'on appelle "formes normales 1,2, 3, BCNF…".

Introduction aux bases de données (Normalisation: FORMES NORMALES)

Introduction aux bases de données (Normalisation: 1FN)
Une relation est en première forme normale si les cellules ne contiennent que des valeurs atomiques et non répétitives. La relation Employés suivante est dite en première forme normale (1FN). Par contre, si nous avions décidé de créer un seul attribut nom composé du nom et prénom (ex: Davolio Nancy), la relation ne serais pas en 1FN.

Nous avons déjà vu dans les diapositives précédentes comment représenter une liste de valeurs à l'aide d'une relation additionnelle (voir la relation "Détails-commandes"). Si nous voulions ajouter les champs article1, article2, article3, etc, à la relation Commandes, elle ne serait plus en 1FN.

Introduction aux bases de données (Normalisation: Dépendance fonctionnelle)
Une forme normale est une méthode de classification de table qui repose sur les dépendances fonctionnelles (DF) qu’elle comprend. Une dépendance fonctionnelle signifie que si nous connaissons la valeur d’un attribut on peut toujours déterminer la valeur d’un autre attribut. La notation utilisée dans la théorie relationnelle est une flèche entre les deux attributs, par exemple A->B s’énonce « A détermine B ». Par exemple, votre numéro de salarié dans votre entreprise permet de trouver votre nom. Le concept de dépendance fonctionnelle est identique au concept de fonction en mathématiques: si nous écrivons y=sin(x), alors y est fonctionnellement dépendant de x. Cela signifie que la valeur du sinus est déterminée uniquement par la valeur de l'angle x. On peut, par exemple, créer une relation "Sinus" dans laquelle il y aura 2 attributs: X et Y (Y=sinus(x)). Autrement dit, la valeur de X détermine (fonctionnellement) la valeur de Y. Nous écririons cette dépendance comme suit: X ---> Y

Un attribut peut aussi dépendre de plusieurs autres attributs simultanément. Par exemple, dans la relation "Détails-commandes", l'attribut "Quantité" est fonctionnellement dépendant des attributs "No. commande" et "Réf. produit". Nous écririons alors: "No. commande","Réf. produit" ---> "Quantité" Un autre exemple serait: la note d'un étudiant dépend du nom de l'étudiant et du numéro de cours. En effet, un étudiant peut être inscrit dans plusieurs cours, et donc, le nom de l'étudiant ne suffit pas à déterminer la note d'un étudiant.

Le ou les attributs à gauche de la flèche dans une dépendance fonctionnelle sont appelés "déterminant" de la dépendance. La dépendance de plusieurs valeurs (DPV) signifie que si nous connaissons la valeur d’un attribut nous pouvons toujours déterminer les valeurs d’un ensemble d’autres attributs. La notation retenue dans la théorie relationnelle est une flèche à double pointe entre les deux attributs, par exemple A<->B s’énonce « A détermine plusieurs B ». Par exemple, le nom d’un professeur permet de déterminer la liste de ses étudiants. La compréhension des DF et les DPV joue un rôle essentiel dans celle des formes normales.

Une clé-candidate est un ou plusieurs attributs qui identifient de façon unique une ligne dans une relation. En d'autres termes, ce sont les attributs ou groupe d'attributs qui peuvent constituer une clé primaire dans une relation. Une clé-candidate doit avoir les 2 propriétés suivantes: Identification unique: chaque ligne doit être identifiée de façon unique par la valeur de la clé. Cette propriété implique que chaque attribut qui ne fait pas parti de la clé est fonctionnellement dépendant de la clé. Non-redondance: aucun attribut dans la clé ne peut être éliminé sans détruire la propriété d'identification unique.

La notation utilisée permet de décrire une relation comme par exemple la relation "Employés" : Employés(No. employé, Nom, Prénom, Fonction, Ville, Tél. domicile) À gauche on place le nom de la relation. Entre parenthèses, on place la liste des attributs séparés par des virgules. Considérons la relations "Étudiants" qui donne la liste des étudiants dans un programme d'études: Étudiants(No. étudiant, Nom, Programme, Ville, Tél. domicile) Dans la relation "Étudiants", "No. étudiant" est la seule clé-candidate, puisque tous les autres attributs sont fonctionnellement dépendant de "No. étudiant". Aussi, "No. étudiant" est le déterminant pour toutes les dépendances fonctionnelles possibles.

En définitive, "No. étudiant" est la seule clé-candidate. On peut aussi écrire de façon graphique les dépendances fonctionnelles comme suit:

Considérons par exemple la relation "Étudiants-cours" définie par: Étudiants-cours(No. étudiant, Nom, Programme, Ville, Tél. domicile, Cours, Note) Nous avons alors le graphique des dépendances fonctionnelles suivant: Les attributs "No. étudiant" et "Cours" déterminent (ensemble) la note obtenue par un étudiant dans un certain cours.

Une relation est en deuxième forme normale si elle est en 1FN et si tout attribut qui ne fait pas partie de la clé primaire dépend fonctionnellement de la clé primaire. De plus, cet attribut (non dans la clé) ne dépend pas fonctionnellement d'un sous-ensemble des attributs de la clé. La relation "Étudiants" est en 2FN. La relations "Étudiants-cours" ne l'est pas: en effet, nous savons que l'attribut "Note" dépend des attributs "No. étudiant" et "Cours". L'attribut "Nom" dépend uniquement de l'attribut "No. étudiant". Dans ce cas on dit que "Note" a une dépendance fonctionnelle partielle sur "No. étudiant" dans la relation " Étudiants-cours".

Remarquez que cette dépendance partielle crée de la redondance (des répétitions) dans le tableau des données associées à la relation: en effet, on doit répéter, pour un étudiant, son nom, son programme, sa ville, son no. de téléphone, pour chaque cours où il est inscrit. Pour éliminer ces anomalies, on modifie simplement la relation "Étudiants-cours" comme suit: Étudiants-cours2 (No. étudiant, Cours, Note)

Une relation est en troisième forme normale si elle est en deuxième forme normale et si elle ne contient pas de dépendance fonctionnelle transitive. Une dépendance fonctionnelle transitive est une dépendance fonctionnelle entre un ou plusieurs attributs qui ne font pas partie de la clé primaire. Considérons la relation "Clients" définie par: Clients (No. client, Nom-client, Vendeur, Région-vendeur) où un vendeur est affecté à chaque client.

Nous avons alors les dépendances fonctionnelles suivantes: La relation "Clients" n'est donc pas en troisième forme normale, puisque l'attribut non-clé "Région-Vendeur" dépend fonctionnellement de l'attribut non-clé "Vendeur". Notez que la relation "Clients" n'est pas réellement complète puisqu'elle ne contient pas tous les détails comme l'adresse du client, etc.

Voici des anomalies de structure qu'on observent dans la relation "Clients": Anomalie d'insersion: on ne peut pas entrer un nouveau vendeur avant d'avoir un client qui est associé à ce vendeur. Il n’existe pas d'entité vendeur. Anomalie de destruction: si on détruit le seul client associé à un vendeur, on perd l'information sur ce vendeur. Anomalie de modification: si on change la région associée à un vendeur, on doit possiblement modifier plusieurs cellules dans plusieurs lignes, dans la relation "Clients".

Pour corriger ces anomalies, nous devons transformer les relations de façon qu'elles soient en troisième forme normale. Nous pouvons alors créer une nouvelle entité vendeur: Clients (No. client, Nom-client, Vendeur) Vendeurs ( Vendeur, Région-vendeur)

Voici un autre exemple de relation qui n'est pas en troisième forme normale, la relation "Expéditions" suivante: Expéditions ( No. Expé. , Origine, Destination, Distance )

Dans la relation "Expéditions", la distance dépend fonctionnellement des attributs non-clé "Origine" et "Destination". Pour corriger la situation, nous devons définir plutôt les relations suivantes "Expéditions2" et "Distances": Expéditions2 ( No. Expé. , Origine, Destination ) Distances ( Origine, Destination, Distance )

Introduction aux bases de données (Normalisation: BCNF)
La forme normale 3FN (3NF) souffre de certains problèmes quand une relation: Possède plusieurs clés candidates, qui sont, composées et dont, certaines clés candidates se chevauchent (ont au moins un attribut en commun) Dans le but de définir la BCNF, il faut ramener la notion de déterminant. Comme déjà mentionné un déterminant est un attribut sur lequel plusieurs autres attributs sont fonctionnellement dépendants. Une relation est BCNF si et seulement si ses déterminants sont des clés candidates.

La définition de la forme normale BCNF est conceptuellement plus simple que la 3NF puisqu’elle ne fait pas de référence explicite aux premières formes normales (1NF, 2NF, 3NF) ni même au concept de dépendance transitive. Observons la relation S (supplier) suivante: S ( S# , SNAME, STATUS, CITY)

Dans la relation S les attributs S# et SNAME sont des clés candidates (chaque fournisseur possède un numéro unique et aussi un nom unique). À partir du schéma des dépendances nous observons aussi que les attributs STATUS et CITY sont indépendants. S est BCNF puisque les déterminants sont des clés candidates

Observons la relation SSP suivante: SSP ( S# , SNAME, P#, QTE)

Les clés candidates de SSP sont (S#,P#) et (SNAME,P#) Ces clés candidates se chevauchent puisque l’attribut P# est commun aux deux clés. SSP possède deux déterminants S# et SNAME (S# <->SNAME) qui ne sont pas clés candidates SSP n’est donc pas BCNF. En observant la tabulation de SSP, on remarque des redondances qui peuvent causer des anomalies de UPDATE. Pour changer le nom d’un fournisseur il faut parcourir toute la BD.

Pour corriger ces anomalies, nous pourrions créer deux relations en remplacement de la relation SSP: SS(S#, SNAME) SP(S#,P#,QTY) Ou: SP(SNAME,P#,QTY)

Considérons la relation SJT avec comme attributs S (étudiant), J (cours), et T (professeur) qui correspond à un étudiant s à qui un professeur t enseigne le cours j. Cette relation doit suivre les contraintes: Pour chaque cours, chaque étudiant de ce cours reçoit l’enseignement d’un seul professeur. Chaque professeur enseigne un seul cours. Chaque cours peut être enseigné par plusieurs professeurs.

Observons un exemple de tabulation de la relation SJT De la première contrainte, découle une dépendance de T sur l’attribut composé (S,J) De la seconde contrainte, découle une dépendance de J sur T

Observons les dépendances fonctionnelles: Les clés candidates (S,J) et (S,T) se chevauchent La relation SJT est en 3NF mais pas en BCNF (T est un déterminant mais pas un clé candidate) Des anomalies de UPDATE peuvent survenir, par exemple si on efface l’information que Jones suit un cours de physique ceci entraînera la perte de l’information que le professeur Brown enseigne la physique

Pour corriger ces anomalies, nous pourrions créer deux relations en BCNF en remplacement de la relation SJT: ST(S, T) TJ(T,J)

Introduction aux bases de données (Normalisation: Autre exemple)
Schéma du processus opérationnel d’une entreprise

Introduction aux bases de données (Normalisation: 1NF)
Nous pourrions décider de créer une relation permettant de contenir l’information relative aux fournisseurs et aux livraisons FIRST ( S# , STATUS, CITY, P#, QTY)

Anomalies Insertion: Un fournisseur ne devient connu que si il distribue au moins une pièce Destruction: Si nous détruisons l’information d’une livraison (ex: S3) nous pourrions perdre l’information sur la ville du fournisseur Modification: La redondance (ex: CITY) fait que si un fournisseur déménage il faudra modifier plusieurs tuples de la relations FIRST

La solution aux problèmes cités auparavant pourrait être de créer deux relations. SECOND(S#, STATUS, CITY) SP(S#, P#, QTY)

Anomalies Insertion: Le statut d’une ville ne peut être connue que si un fournisseur de cette ville existe Destruction: Si nous détruisons l’information d’un fournisseur (ex: S5) nous perdons alors l’information sur la ville d’Athens Modification: La redondance existe encore (ex: CITY) fait que si un fournisseur déménage il faudra modifier plusieurs tuples de la relations SECOND

Pour corriger ces anomalies, nous pourrions créer deux relations en remplacement de la relation SECOND SC(S#, CITY) CS(CITY, STATUS)

Les relations FIRST et SECOND ne sont pas en BCNF (elles n’étaient même pas 3NF) FIRST contient trois déterminants (S#, CITY, (S#, P#)) dont seul (S#, P#) est une clé candidate SECOND contient un déterminant (CITY) qui n’est pas une clé candidate Les relations SP, SC et CS sont en BCNF puisque la clé primaire est le seul déterminant de la relation

Introduction aux bases de données (Normalisation: Intégration de vues)
Lorsqu'un projet de développement est analysé par plusieurs individus, on retrouve plusieurs relations. Des relations qui décrivent la même entité, comme un employé par exemple, doivent être fusionnées. Par exemple, si nous avons les relations: Employés1( No. employé, Nom, Adresse) Employés2( No. employé, Fonction, Ancienneté) Alors, on remplace les deux relations précédentes par la relation "Employés" qui décrit le contenu des relations précédentes: Employés( No. employé, Nom, Adresse, Fonction, Ancienneté)

Introduction aux bases de données (Normalisation: Synonymes)
Lors de la fusion de relations, il faut éviter certains problèmes comme par exemple, dans les relations suivantes, "No. employé" et "No. Ass. Sociale" servent à identifier de façon unique un employé et sont des synomymes. Alors, on peut choisir l'un ou l'autre ou les deux. Employés3( No. employé, Nom, Adresse) Employés4( No. Ass. Sociale, Fonction, Ancienneté) Si le numéro d'assurance social est considéré comme une donnée privée, nous devrions alors utiliser le "No. employé" comme clé et inclure dans un champ séparé le "No Ass. Sociale": Employés3Avec4( No. employé, Nom, Adresse, No. Ass. Sociale, Fonction, Ancienneté)

Introduction aux bases de données (Normalisation: Alias et Homonymes)
Si dans les relations précédentes, nous désirons conserver les deux attributs "No. employé" et "No. Ass. Sociale", alors ces attributs s'appellent des alias. En effet, l'un ou l'autre peut servir de clé primaire. En fait, "No. employé" est fonctionnellement dépendant de "No. Ass. Sociale" et vice-versa. Considérons les relations suivantes: Étudiants1 ( No. étudiant, Adresse, Cours) Étudiants2 ( No. étudiant, Adresse, Solde ) Dans la relation "Étudiant1", l'adresse peut être l'adresse de résidence d'un étudiant sur le campus, alors que dans la relation "Étudiant2", l'adresse peut désigner l'adresse permanente de l'étudiant. Dans ce cas, on parle d'homonymes. En fait, les adresses sont différentes et doivent être spécifiées de façon plus exacte.

Introduction aux bases de données (Normalisation: Relations de types différents)
Considérons les relations suivantes: Étudiants3 ( No. étudiant, Adresse, Superviseur) Étudiants4 ( No. étudiant, Date diplôme ) La relation "Étudiant3" désigne plutôt un étudiant qui est en train de suivre un programme de cours ou de stage, tandis que la relation "Étudiants4" désigne les étudiants qui ont terminés leurs programmes de cours avec succès. Ce sont deux relations différentes qui ne peuvent pas (normalement) être fusionnées. La discussion précédente montre que certaines anomalies peuvent survenir au moment de l'intégrations de plusieurs relations. En fait, il faut toujours s'assurer que les relations fusionnées conservent toujours la troisième forme normale (3FN).

Introduction aux bases de données (Étude de cas: Étapes à suivre)
Dans les sections précédentes nous avons exposés les principes de gestion d'une base de données relationnelle. Présentons maintenant une étude du cas d'un système de gestion des stocks. Pour modéliser cet exemple nous devons suivre les étapes suivantes: Définir les relations et leurs clés primaires Montrer les dépendances fonctionnelles Montrer les liens entre les relations S'assurer que ces relations sont en troisième forme normale Définir les contraintes d'entreprises (business rules) Définir les formulaires qui sont utilisés par le personnel

Introduction aux bases de données (Étude de cas: Informations sur le processus)
Voici des informations importantes sur la description du système de gestion des stocks: Les employés peuvent commander des produits à l'aide de réquisitions Chaque produit appartient à une catégorie de produits Il y a plusieurs fournisseurs, chaque fournisseur peut fournir plusieurs produits et un produit peut être fourni par plusieurs fournisseurs Les produits sont expédiés par les fournisseurs selon un transporteur désigné sur la réquisition et il y a plusieurs transporteurs À la réception des produits livrés, on crée un bon de livraison qui sert à gérer les stocks.

Introduction aux bases de données (Étude de cas: Informations sur le processus)
Les informations précédentes sont souvent tirées a priori des processus en place et par la circulation de formulaires papier. Elles permettent de mettre en relief certains comportements du système permettant aussi de mieux comprendre et de modéliser le système. Le nouveau modèle du système de gestion n’est pas nécessairement tenu de respecter l'ancien. Il peut toujours être amélioré afin d’éviter par exemple les duplications.

Introduction aux bases de données (Étude de cas: Entités principales)
La description précédente donne le comportement général du système. Souvent, tel que mentionné précédemment, des formulaires-papier existants peuvent être utilisés pour modéliser le nouveau système. Les principales entités définissent les relations principales suivantes: Employés Réquisitions Produits Catégories-produit Fournisseurs Transporteurs Bons-de-livraison

Introduction aux bases de données (Étude de cas: Attributs de chaque entités)
Complément d’information sur le fonctionnement du système actuel: Un employé complète une réquisition qui est transmise au fournisseur choisi À la livraison, un employé crée un bon de livraison qui sert à la mise-à-jour des produits en stock. Ensuite, nous définissons les attributs de chaque relation: Employés No-employé Nom-employé Poste-occupé Téléphone-employé Réquisitions No-Réquisition Description-Réquisition Date-Réquisition

Introduction aux bases de données (Étude de cas: Attributs de chaque entité)
Produits No produit Nom produit Description produit No catégorie Unités en stock Catégories-produit No-catégorie Nom-catégorie Fournisseurs No-fournisseur Nom-fournisseur Adresse-fournisseur Téléphone-fournisseur Transporteurs No-transporteur Nom-transporteur

Introduction aux bases de données (Étude de cas: Attributs de chaque entité)
Bons-de-livraison No-livraison Date-livraison No-Réquisition No-fournisseur Normalement, dans la description précédente, nous pourrions ajouter plus d'informations sur les entités, comme le numéro de fax pour un fournisseur, son etc.

Introduction aux bases de données (Étude de cas: Normalisation)
Pour être en 1FN, les valeurs des attributs doivent être atomiques et non répétitives (une seule valeur, et non des listes), donc les listes doivent être modélisées avec des relations additionnelles. Dans une Réquisition, nous pouvons retrouver possiblement, plusieurs produits commandés. Ainsi, on peut donc créé une nouvelle relation qui concerne les produits et les réquisitions: Produits-réquisitions No-Réquisition No-produit Quantité-commandée Pour une livraison, on peut retrouver plusieurs produits livrés. Items-livrés No-livraison Quantité-reçue

De plus, un fournisseur peut offrir plusieurs produits, i.e. on doit maintenir une liste des produits offerts par chaque fournisseur: Produits-d'un-fournisseur No-fournisseur No-produit Nous avons donc identifier les principales entités et leurs relations avec leurs attributs. Ces relations sont donc toutes en 1FN, parce que les valeurs des attributs sont toutes atomiques.

Pour avoir la deuxième forme normale, chaque relation doit avoir une clé primaire et les attributs non-clé doivent être fonctionnellement dépendant de la clé primaire. Dans chaque relation, on identifie la clé-primaire et on vérifie que les autres attributs dépendent fonctionnellement de la clé; finalement, on identifie les clés externes qui définissent des liens entre les relations (entités): Employés No-employé (clé) Nom-employé Poste-occupé Téléphone-employé Réquisitions No-Réquisition (clé) Description-Réquisition No-employé (clé externe de Employés) Date-Réquisition

Produits No-produit (clé) Nom-produit Description-produit No-catégorie (clé externe de Catégories-produits) Unités-en-stock Catégories-produit No-catégorie (clé) Nom-catégorie Fournisseurs No-fournisseur (clé) Nom-fournisseur Adresse-fournisseur Téléphone-fournisseur

Transporteurs No-transporteur (clé) Nom-transporteur Bons-de-livraison No-livraison (clé) Date-livraison No-Réquisition (clé externe de Réquisitions) No-fournisseur (clé externe de Fournisseurs) No-transporteur (clé externe de Transporteurs) Produits-réquisitions No-Réquisition (clé et clé externe de Réquisitions) No-produit (clé et clé externe de Produits) Quantité-commandée

Items-livrés No-livraison (clé et clé externe de Bons-de-livraison) No-produit (clé et clé externe de Produits) Quantité-reçue Produits-d'un-fournisseur No-fournisseur (clé et clé externe de Fournisseurs)

Introduction aux bases de données (Étude de cas: Formulaires)
La conception des formulaires permet de vérifier le fonctionnement et les possibilités du système de gestion. En général, il suffit de placer ensemble les relations et les listes qui définissent un formulaire La gestion des stocks requiert un formulaire qui décrit une réquisition ainsi que les produits commandés sur la réquisition: Formulaire-réquisition No-Réquisition (clé) Description-Réquisition No-employé (clé externe de Employés) Date-Réquisition Liste des produits commandés: No-produit (clé et clé externe de Produits) Quantité-commandée

Formulaire-bon-livraison No-livraison (clé) Date-livraison No-Réquisition (clé externe de Réquisitions) No-fournisseur (clé externe de Fournisseurs) Liste des items livrés No-produit (clé et clé externe de Produits) Quantité-reçue Le formulaire "Formulaire-bon-livraison" montre que le fournisseur peut expédier un certain nombre de produits (Quantité-reçue) et ce nombre n'est pas nécessairement égal au nombre commandé sur la réquisition. Cela implique que plusieurs bons de livraison peuvent correspondent à une même réquisition.

Pour faciliter la gestion des stocks, nous pourrions ajouter un attribut représentant la quantité de produits qui n'ont pas encore été livrés concernant une réquisition particulière. Nous constatons alors que ce nouvel attribut doit être ajouté comme suit: Produits-réquisitions No-Réquisition (clé et clé externe de Réquisitions) No-produit (clé et clé externe de Produits) Quantité-commandée Quantité-à-livrer Voir la remarque concernant l'attribut "Quantité-à-livrer" dans la conclusion

Introduction aux bases de données (Étude de cas: Contraintes d’entreprise)
La principale contrainte de conception découle du fait que les clés externes doivent indiquer que les clés primaires des entités correspondantes doivent d'abord être définie de façon unique. Les autres contraintes correspondent à des règles de gestion particulière qui assurent un bon fonctionnement du système. Voici quelques règles particulières: Dans une livraison, la quantité d'un produit livré doit être inférieure ou égale à la quantité de produit qui reste à livrer. Cela signifie que la valeur de l'attribut "Quantité-livrée", au moment d'une livraison d'un produit, doit être inférieure ou égale à la valeur courante de l'attribut "Quantité-à-livrer" dans la relation "Items-livrés". Sinon, nous devrions retourner au fournisseurs les produits livrés en trop. Nous devrions mettre-à-jour l'attribut "Unités-en-stock" de la relation "Produits" au moment d'une livraison d'un produit Si un produit commandé sur une réquisition existe déjà en stock (attribut "Unités-en-stock) de la relation "Produits"), alors commander uniquement la quantité de produit qui manque.

Introduction aux bases de données (Étude de cas: Conclusion)
Nous pouvons constater que la gestion des données d'une entreprise nécessite une analyse très détaillée. Les principes des bases de données relationnelles servent uniquement à identifier et à éliminer les problèmes de gestion des données. En général, nous devons éviter de stocker la même information à des endroits différents ou sous une forme différente (redondance). Nous devons aussi éviter de définir un attribut qui est en réalité calculable à l'aide d'informations existantes ailleurs dans la base (redondance). Par exemple, la valeur de l'attribut "Quantité-à-livrer" dans la relation "Produits-réquisitions" pourrait être éliminée puisque cette valeur est égale à la quantité commandée moins la somme des quantités reçues d'un produit dans les livraisons qui concernent une réquisition particulière. L'ajout de la variable "Quantité-à-livrer" est donc inutile.

Introduction aux bases de données (Étude de cas: Conclusion)
En somme, le plus important est de s'assurer que la base de données contient toutes les informations requisent et que ces informations sont consistantes i.e. qu'elles ne contiennent pas d'erreurs. Il est plus facile de s'assurer qu'on n'ajoute pas d'inconsistances que d'ajouter des inconsistances et de les rechercher ensuite. En fait, les tables (relations) servent à gérer les informations de la base de données. Les formulaires sont quant à eux destinés à entrer l'information dans les tables ou à extraire des informations contenues dans les tables. Ce sont des rôles distincts. Ainsi, dans une table on utilise toujours la clé pour représenter une entité, i.e. un numéro ou un code. Par contre, dans un formulaire, nous présentons à l'utilisateur, en plus de la clé, d'autres informations qui peuvent aider ce même utilisateur. Par exemple, si un formulaire contient un "No-fournisseur", alors nous devons souvent ajouter le nom du fournisseur.

PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II

Présentations similaires

Présentation au sujet: "PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II

Présentations similaires

Présentation au sujet: "PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back