AcceptRejectRule
Définit les règles à appliquer en cas d'appel de la méthode AcceptChanges. Peut prendre la valeur : • None : Aucune action ne se produit
• Cascade : Les actions se répercutent en cascade
Les actions sont définies dans les propriétés DeleteRule et UpdateRule
Columns (DataColumn())
Renvoie le tableau des objets DataColumn contenus dans la contrainte
DeleteRule & UpdateRule(Rule)
Renvoie ou définit la répercussion de l'action lorsqu'une ligne parent est supprimée ou modifiée. Peut prendre une des valeurs suivantes :
Nom Description
Cascade Supprime ou modifie les lignes enfants. Il s'agit de la valeur par défaut. None Aucune action n'est effectuée sur les lignes enfants.
SetDefault Affecte la valeur contenue dans la propriété DefaultValue comme valeur des lignes enfants. SetNull Affecte DBNull comme valeur des lignes enfants.
Attention, mettre ces propriétés à None n'empêche pas la levée d'exceptions.
RelatedColumns (DataColumn())
Renvoie un tableau d'objet DataColumn représentant les colonnes parents de la relation.
RelatedTable (DataTable)
Renvoie la table parente de la relation
La classe DataRelation
Les objets DataRelation appartiennent à l'objet Dataset. Une relation permet de mettre en correspondance les lignes d'une ou de plusieurs tables. Elle se base sur l'utilisation d'une clé étrangère qui permet d'identifier une ligne 'parente'. La mise en relation des informations permet de ne pas dupliquer les données et donc d'alléger considérablement le SGBD. Dans ADO.NET vous pouvez créer des relations entres des objets d'un même Dataset. On distingue quatre types de relation:
o Relation réflexive : Celle-ci n'utilise qu'une seule table. La clé étrangère permet de faire
référence à une ligne de la même table, donc de créer une vision 'hiérarchique' de la table. Dim strConn, strSQL As String
strConn = "packet size=4096;user id=sa;data source= NOM-SZ71L7KTH17\TUTO ;persist security info=False;initial catalog=northwind;password=monpasse" strSQL = "SELECT * FROM Employees"
Dim MonDa As New SqlClient.SqlDataAdapter(strSQL, strConn) Dim MonDataSet As New DataSet
MonDa.Fill(MonDataSet)
Dim maTable As Data.DataTable = MonDataSet.Tables(0) maTable.Constraints.Add("pk1", maTable.Columns(0), True) MonDataSet.Relations.Add("AutoReflex", maTable.Columns(0), maTable.Columns("ReportsTo"), True)
maTable.Columns.Add("NbSubord", Type.GetType("System.Int32"), "Count(child(AutoReflex).ReportsTo)")
o Relation un à un : Une telle relation associe une ligne enfant avec une ligne parent. Dans ce
seul cas la clé étrangère doit être unique. Les relations de ce type sont très rares car il est alors plus simple de mettre tous les champs dans une seule table.
o Relation un à plusieurs : C'est le type le plus courant. Une ligne parent peut avoir plusieurs
lignes enfants, mais une ligne enfant ne peut avoir qu'un seul parent. Celle-ci s'obtient par la recopie d'une ou plusieurs colonnes ayant la contrainte d'unicité dans la table enfants.
o Relation plusieurs à plusieurs : Stricto sensu il ne s'agit plus d'une relation, mais de deux
relations utilisant une table de jointure. Une table de jointure comporte les colonnes composant la clé primaire des deux tables, sa propre clé primaire étant définie sur l'ensemble des colonnes. Les relations présentent aussi l'avantage des performances. Il est souvent moins lourd de créer deux tables puis une relation que de créer une table utilisant une requête avec jointure.
Sachez aussi qu'il est possible de désigner des lignes enfants dans l'expression d'une colonne calculée.
Remarque de Maxence Hubiche
Je ne suis pas d’accord avec cette assertion « Stricto sensu, il ne s’agit pas d’une relation mais de deux relations utilisant une table de jointure ». Sur le plan de la modélisation, il s’agit d’une association entre 2 entités. Il est vrai qu’une telle association nécessitera, au moment de la création de la base de données, la génération d’une table intermédiaire qui est en fait le résultat de l’association entre les 2 entités du modèle. Mais là, nous sommes dans le modèle conceptuel. Par contre, dans la base de données (modèle physique) le cas pourra être légèrement différent : Imagine que tu aies à lier (pour je ne sais quelle raison) 2 champs quelconques (avec doublons), de 2 tables quelconques. Il est plus que probable que tu auras une vraie relation n-n, puisque chaque valeur de la table 1 sera susceptible d’être associée à n valeurs de la table 2, et vice-versa.
Réponse : Je ne saisie pas pourquoi une relation n:n avec des doublons serait plus une vraie relation n:n
que s'il n'y a pas de doublons. Sur le plan conceptuel tu as raison, mais je n'aborde pas le plan conceptuel dans le cadre de ce cours, je décris comment il faudra gérer les objets DataRelation dans ADO.NET.
Réponse de M. Hubiche
C'est le 'Stricto Sensu' qui m'ennuie, parce que tout dépend de l'endroit où l'on se situe : Sur le plan analytique, la relation N-N existe. Qu'il y ait des doublons ou pas !
Maintenant, il est vrai que sur le plan physique, on ne peut la représenter autrement que par 2 relations 1-N. Qu'il y ait des doublons ou pas ...
Remarque de Maxence Hubiche
Puis-je te poser une question ? (Histoire de vraiment t’ennuyer☺) Imagine la table des matériels.
Avec ID, Description, Prix.
Imagine que, maintenant, tu veuilles connaître la quantité de matériels composant d’autres matériels, de telle sorte que tu puisses récupérer les compositions. Cette fois, l’association est une association plusieurs- à-plusieurs sur la même table…
Comment tu gères ?
Pourtant, c’est une relation réflexive aussi ☺ Je t’énerve là ?
Réponse : Une légère contrariété tout au plus . Je ne suis pas bien sur de voir là ou tu veux en venir.
Mais dans le cas que tu cites, il s'agit d'une relation plusieurs à plusieurs. La notion de relation de type n:n n'induit pas l'existence de deux tables. Il s'agit bien d'une relation entre des enregistrements. Tu auras donc une table de jointure faisant référence dans ses champs à la clé primaire de la même table. C'est certes une relation reflexive, mais elle nécessite plus d'une table.
Réponse de M. Hubiche
Ce qui m'a ennuyé c'est que tu limites, dans ta définition, la relation réflexive à une relation 1-N. ALors que dans l'exemple que je te donne, il s'agit aussi d'une relation N-N, et elle est aussi réflexive.
En fait, la réflexivité porte sur le fait que l'association se fait d'une entité sur elle-même. Les cardinalités interviennent peu ici.