| 
B A S E D E D O N N E E S R E L A T I O N N E L L E BASE DE DONNEES BASEE SUR LA THEORIE DES ENSEMBLES. TERMINOLOGIE: --------------- DOMAINE: Ensemble de valeurs (toutes les valeurs pouvant être prises par une information) Domaine d'une info numérique : (0,1,2,3,4,5,6,.....) Domaine d'une info booléenne : (0,1) Domaine d'une info représentant une agence par ex. : (PARIS,TOULOUSE,NANTES) |
|
PRODUIT CARTESIEN :ensemble de toutes les possibilité de combinaisons entre une liste de domaine ex: Produit cartésien du domaine boleen et du domaine agence ................... : 0 : PARIS : : 1 : PARIS : : 0 : TOULOUSE : : 1 : TOULOUSE : : 0 : NANTES : : 1 : NANTES : :......:..........: RELATION : sous ensemble d'un produit cartesien une relation est en général caractérisée par un nom ............................. : AGENCE : 1 : PARIS : :.........: 0 : TOULOUSE : : 1 : NANTES : :......:..........: |
|
ATTRIBUT: Le domaine d'une information ne suffisant pas à son identification on nomme les informations ........................... : AGENCE : TEST : VILLE : :.........:......:........: : 1 : BLEU : : 0 : BLANC : : 1 : BLANC : :......:........: TUPLE : Une ligne d'une relation. REMARQUES IMPORTANTES: Dans une relation l'ordre des colonnes n'importe pas l'ordre des lignes n'importe pas |
|
Ce sont des concepts bien réels sur un ordinateur: Domaine: Variable, champs.(information élémentaire) Relation: Fichier,Table. Attribut: Définition et caractéristiques d'un champs. Ensemble de relations: Base de données. |
|
EXEMPLE: RELATION CLIENTS !-- ATTRIBUTS (noms de zone) v ........................................................... : NUMCLI : NOM : PRENOM : AGENCE : COD : DATE : :........:.............:..........:........:.....:........: : 101 : DUBOIS : Eric : 01 : 07 : 930405 : : 107 : ERNST : Patrick : 01 : 12 : 891215 : I-> : 110 : DUPONT : Alain : 02 : 14 : 890405 : I : 102 : MERCIER : Anne : 03 : 18 : 910302 : I : 104 : BOZUFFI : Ricardo : 03 : 12 : 900302 : I : 121 : GARDEL : Sophie : 01 : 17 : 921215 : I : 130 : FLAVARD : Cecile : 02 : 09 : 920405 : I : 132 : GOUDE : Jean : 02 : 13 : 890405 : I : 103 : FORTRAN : Yves : 03 : 17 : 900302 : I : 105 : DUBROVNIK : Marie : 01 : 16 : 931215 : I :........:.............:..........:........:.....:........: I !<--DOMAINE-->! I (Colonne) I TUPLE (enregistrement) |
|
RELATION AGENCES .......................... : AGENCE : LIBAGE : <--ATTRIBUTS :........:...............: TUPLE ------>: 01 : PARIS : : 02 : TOULOUSE : : 03 : LYON : :........:...............: I I----DOMAINE |
|
ACCES AUX DONNEES ------------------- SELECTION Restriction de lignes PROJECTION Restriction/reorganisation des colonnes UNION Regroupement de deux relations (l'une apres l'autre) JONCTION Restriction sur le produit cartésien de X relations SELECTION (clients de l'agence 01) .................................................. : NUMCLI : NOM : PRENOM : AGENCE : :........:..................:...........:........: : 101 : DUBOIS : Eric : 01 : : 107 : ERNST : Patrick : 01 : : 121 : GARDEL : Sophie : 01 : :........:..................:...........:........: |
|
PROJECTION (nom,agence) ............................. : NOM : AGENCE : :...........................: : DUBOIS : 01 : : ERNST : 01 : : DUPONT : 02 : : MERCIER : 03 : : BOZUFFI : 03 : : GARDEL : 01 : : FLAVARD : 02 : : GOUDE : 02 : : FORTRAN : 03 : : DUBROVNIK : 02 : :..................:........: |
|
JONCTION (sur agence) ......................................................... : NUMCLI : NOM : PRENOM : AGENCE : LIBAGE : :........:............:..........:........:.............: : 101 : DUBOIS : Eric : 01 : PARIS : : 107 : ERNST : Patrick : 01 : PARIS : : 110 : DUPONT : Alain : 02 : NANTES : : 102 : MERCIER : Anne : 03 : LYON : : 104 : BOZUFFI : Ricardo : 03 : LYON : : 121 : GARDEL : Sophie : 01 : PARIS : : 130 : FLAVARD : Cecile : 02 : NANTES : : 132 : GOUDE : Jean : 02 : NANTES : : 103 : FORTRAN : Yves : 03 : LYON : : 105 : DUBROVNIK : Marie : 01 : PARIS : :........:............:..........:........:.............: |
|
TYPES DE BASE DE DONNEES ------------------------- 1/ SGDB semi-relationnel (38 avant V7) Structure des données (SDD) Sélection et projection (fichiers logiques) 2/ SGDB relationnel minimal (38 depuis V7) semi-relationnel + Jonction (logiques joints) 3/ SGDB relationnel complet relationnel minimal + langage relationnel (SQL/400) (OPNQRYF sur 38 depuis V8 bien que n'etant pas vraiment "relationnel") |
|
TYPES DE BASE DE DONNEES ------------------------- 4/ SGDB relationnel total relationnel complet + integrite -l'integrite des données est assurée par OS/400. (en autre fonction journal) -l'intégrité référentielle est assurée depuis la V3R10 : il est impossible de supprimer une entete de commande s'il reste des lignes dans le fichier détail. - Avec la V4R20, DB2/400 supporte les contraintes de domaines (rpix doit être > 0 et datliv > datcde) |
|
NORMALISATION --------------- Tout d'abord RECENSEMENT DES DONNEES aux différents échelons: + postes de travail + responsables/direction. Ce travail a pour but d'aboutir à la rédaction d'un "dictionnaire" où les données seront identifiées par : + un NOM + une DEFINITION (en clair) + une STRUCTURE (alpha,num..) + un TYPE (calcul ,saisie,...) + une QUANTIFICATION (nb de valeurs possibles) + des EXEMPLES(relevés sur les documents) + des COMMENTAIRES |
|
puis SYNTHESE DES DONNEES afin d'établir un dictionnaire définitif ce travail a pour but d'éliminer + les SYNONYMES: deux termes différents recouvrant la même réalité "article" et "produit" + les POLYSEMES: un seul terme recouvrant deux réalités "prix article" utilisé pour prix de vente et prix d'achat. |
|
Et enfin Organisation logique des données: 1/ A PARTIR DES REGLES DE GESTION TROUVER LES RELATIONS ENTRE LES DONNEES "UN pour UN" ------ ------ ! !-<--->-! ! ------ ------ "UN pour PLUSIEURS" ------ ------ ! !-<-->>-! ! ------ ------ "PLUSIEURS p. PLUSIEURS" ------ ------ ! !-<<->>-! ! ------ ------ |
|
Organisation logique des données: 2/ TROUVER LES ENTITES QUI IDENTIFIENT CES RELATIONS Suivant le modele de "CODD" une ENTITE représente un objet concret ou abstrait. Une entité est dite associative si elle exprime un lien (n,m) entre deux entités Une entité est dite descriptive si elle exprime un lien (1,m) entre deux entités Une entité est dite déterminante si elle exprime un lien (n,1) entre deux entités |
|
Organisation logique des données: 3/ CE QUI PERMET DE METTRE EN EVIDENCE LES DEPENDANCES FONCTIONNELLES (DF) On dit QUE X -> Y (X détermine Y ou Y dépend fonctionnellement de X) SI à une valeur de X correspond une valeur de Y et UNE SEULE. Ex: un commercial à un lieu unique de rattachement (COMMERCIA -> AGENCE) un client, n'a qu'un interlocuteur commercial. (CLIENT -> COMMERCIA) à l'inverse un commercial à plusieurs clients ______________________ (COMMERCIA -> CLIENT) |
|
Ces DF suggerent déja des regroupements en sous ensembles: Données liées aux commerciaux Données liées aux agences Données liées aux clients A ce stade il doit être possible de distinguer une clé permettant d'identifier un élément (enregistrement) CLE = ATTRIBUT ou ENSEMBLE PERMETTANT D'IDENTIFIER TOUS LES AUTRES On parle de clé PRIMAIRE On parle de clé candidate pour désigner une clé quelconque. (autre que clé primaire) |
|
LES FORMES NORMALES (proposées par le modele de "CODD") : 1ere forme normale 1NF Une relation est en première forme normale si: tout attribut contient une valeur atomique. ==> PAS D'OCCURRENCE. PAS DE REGROUPEMENT DE DONNEES. Il faut définir les informations au plus fin. 2eme forme normale 2NF Une relation est en deuxieme forme normale si: elle est en 1NF et tout attribut n'appartenant pas à la clé ne depend pas d'une PARTIE de celle ci. -----CLE------- Ex: dans un fichier commande N°cde,N°article,Désignation article |
|
3eme forme normale 3NF Une relation est en troisieme forme normale si: elle est en 2NF et tout attribut n'appartenant pas à la clé ne depend pas d'un attribut non clé. ----CLE------ Ex: dans un fichier commande N°cde,N°ligne,code article,prix EN RESUME: TOUS LES ATTRIBUT DEPENDENT DE LA CLE, DE TOUTE LE CLE, UNIQUEMENT DE LA CLE. |
|
MISE EN APPLICATION SUR AS/400: 1/ dans une relation l'ordre des colones l'ordre des lignes n'importe pas. Ce qui nous pousse à créer des physiques sans clé. et des fichiers logiques pour les définir. Les pgm travaillant avec les logiques,en cas de modif du fichier physique,il suffira de définir une projection sur le logique pour que la modif soit transparente aux yeux des pgms. Pour certaines manips(sauvegarde et surtout copie de fichier) le système va plus vite avec des physiques sans clé. |
|
MISE EN APPLICATION SUR AS/400: 2/ éliminer les synonymes et les polysemes Les synonymes pour utiliser au mieux le MOVE CORR COBOL et la mémoire de travail RPG. Les polysemes, RPG ne vous le pardonnera pas. |
|
MISE EN APPLICATION SUR AS/400: 3/ normalisation Valeurs atomiques: ==> ANNEE,MOIS,JOUR plutot que date DEPART,BDISTRI plutot que code postal + sélection plus simple + contrôles de saisie plus simples + avec SDD : CONCAT plus souple que SST. Respecter les 3 formes normales va nour ammener à "éclater" les fichier (décomposition) Une jonction sur des décompositions doit toujours être capable de reconstituer le schéma d'origine. La jonction fonctionne très bien sur AS (32 avec SDD,QUERY,SQL et 32 x 32 sous réserves avec OPNQRYF) |
