Avantages d'une base de donn�es relationnelle (SGBDR)

Les bases de donn�es relationnelles ont �t� invent�es en 1970 par CODD. La premi�re a �t� Ingres. Les premiers syst�mes commerciaux sont apparus au d�but des ann�es 80. Cela fait donc plus de 20 ans que l'industrie et la Haute technologie utilisent et am�liorent ces syst�mes qui sont maintenant largement � maturit�. Les plus connues sont SYBASE, ORACLE, INFORMIX, DB2, SQL SERVEUR.

Les plus utilis�s sur Internet sont SQL SERVER et ORACLE. Elles b�n�ficient d'un support clairement identifi�. Leurs avantages sont surtout �valu�s en terme de performances, d'int�grit� des donn�es. Elles poss�dent des syst�mes �volu�s de sauvegarde et de v�rifications de coh�rences. Ces bases sont pr�vues pour les syst�mes d'informations compliqu�s n�cessitant de hauts rendements. Voici une explication en d�tail avec des exemples simples.

Contrainte d'Int�grit� R�f�rentielle (CIF) entre deux relations

Un d�partement est identifi� par son id_departement et poss�de un nom. Un employ� est identifi� par son id_employe, appartient � un d�partement, poss�de un nom, une adresse et une fonction. Un employ� appartient � un et un seul d�partement, un d�partement contient de 0 à n employ�s.

D'o� le Mod�le Conceptuel de Donn�e (MCD)

Il entra�ne le MLDR (Mod�le Logique) suivant

Ces deux entit�s sont li�es par une CIF. On ne peut cr�er un Employ� si le D�partement lui correspondant n'a pas �t� cr��. De m�me, on ne peut supprimer un d�partement qui contient encore des employ�s. L'utilisation d'une base de donn�e relationnelle permet dans ce cas de confier les v�rifications correspondantes � la base elle-m�me. Sinon, il faut bien se rappeler de le faire tout le temps � la main dans chaque partie du programme qui aura � cr�er, � supprimer ou � modifier un employ� ou un d�partement, au risque d'avoir des donn�es aberrantes.

Cl�s primaires multiples

Un produit est unique, il a un nom et un prix. Pareil pour le d�p�t. Un produit peut �tre dans 0 ou n d�p�t. Un d�p�t contient 0 ou n produits.
D'o� le Mod�le Conceptuel de Donn�e (MCD)

Qui entra�ne le MLDR (Mod�le Logique)

Produit (id_produit, nom, prix)
Depot (id_depot, adresse, volume)
Stock (#id_produit, #id_depot, quantit�)

Le mod�le physique ainsi g�n�r� est

La table Stock sert � savoir combien il y a de produits par d�p�t. Chaque enregistrement de Stock est caract�ris� par une association produit/d�p�t. Cette association DOIT �tre unique, la cl� primaire �tant ici la concat�nation des deux cl�s �trang�res. Une base de donn�es relationnelle permettra de mettre une telle contrainte, et d'emp�cher toute duplication. Elle permettra aussi d'interdire automatiquement la suppression d'un d�p�t ou d'un produit utilis� dans Stock (CIF). Sinon, il faudra, lors de chaque insertion, aller v�rifier manuellement que l'association produit/d�p�t que l'on rajoute n'est pas d�j� pr�sente dans la table. De m�me, lors de chaque suppression d'un produit ou d'un d�p�t, il faudra v�rifier dans chaque partie correspondante du programme que ce produit ou que ce d�p�t n'est pas utilis� dans Stock, au risque d'avoir des donn�es aberrantes.

Proc�dures stock�es

Une proc�dure stock�e est un ensemble d'instructions SQL qui s'ex�cute � la demande. On peut lui passer des param�tres et elle peut retourner un r�sultat au programme. Une proc�dure stock�e est compil�e au sein m�me du moteur de base de donn�e : elle s'ex�cute toujours plus rapidement qu'un script PHP. Lors de leur ex�cution, un seul �change se produit avec la base, lors de l'appel de la proc�dure et de la r�cup�ration de son r�sultat, alors que l'ex�cution de chaque commande SQL en n�cessite plusieurs. D�s que plusieurs requ�tes doivent s'encha�ner, l'emploi de proc�dures stock�es est toujours pr�f�rable au SQL dynamique. Dans le cas d'une s�paration du serveur de base de donn�e du serveur frontal, elles permettent aussi de diminuer le trafic r�seau entre les deux machines.

Triggers

Un Trigger est un ensemble d'instructions SQL appel� aussi proc�dure dont l'ex�cution est li�e � un �v�nement dans la base de donn�e. Cet �v�nement peut �tre une insertion, un enregistrement ou une modification.
Le trigger peut �tre lanc� par la base avant l'�v�nement, ou apr�s. Lors d'une suppression, cela permet par exemple d'aller automatiquement supprimer les clefs correspondantes l� o� elles sont utilis�es. Lors d'un ajout ou d'une modification, cela permet d'AUTOMATISER toutes les mises � jours qui en d�coulent. Sinon, � chaque fois, lors de chaque �criture d'une insertion, modification ou suppression dans la base, programmer � la main toutes les cons�quences de cet �v�nement, sous peine d'avoir des donn�es aberrantes � la moindre petite erreur.

Transactions

Une transaction est un ensemble d'actions permettant de prendre une base donn�e dans un �tat coh�rent et de la rendre dans un �tat coh�rent. Il s'agit d'�viter par exemple que l'on puisse lire une information que l'on est en train de modifier par ailleurs ou de mettre � jour, ou m�me que deux utilisateurs mettent � jour simultan�ment la m�me information.
Chaque transaction se termine par un COMMIT si la transaction a r�ussi, ou par un ROLLBACK qui la ram�ne � l'�tat initial si la transaction �choue pour une raison ou pour une autre. Une transaction est en fait un comportement atomique d'une s�quence d'action (elle s'effectue avec succ�s ou elle est annul�e).
L'exemple le plus r�pandu est celui du magasin : le magasinier re�oit ses livraisons, et remplis la base. La caissi�re passe les codes bars, et vide la base. Le chef de rayon modifie ses marges, fixe ses prix, et consulte ses statistiques. Si les trois font cela simultan�ment sur les m�me donn�es, la base sera corrompue et aberrante dans l'heure qui suivra : les donn�es seront fausses, et les informations affich�s � l'�cran n'auront aucunes significations car entre la lecture et la r��criture, elles auront chang�.
Un des avantages de la transaction est que si une transaction s'ex�cute toute seule, dans une base de donn�es coh�rente, alors elle va laisser la base de donn�es dans un �tat coh�rent.