Question sur l'atomicité

Bonjour,

Après avoir lu un article du blog de sqlpro, je me pose une question sur l'atomicité (je me rends compte en l'écrivant que ce n'est p-e pas le bon terme).

Voici le lien de l'article : http://blog.developpez.com/sqlpro/p1...ances-petites/

Et voici ma question (que vous pourrez trouvez en commentaire de l'article mais que je poste ici pour toucher un public plus large) :

Dans le cadre d'une base de donnée servant à gérer les privilèges d'accès des utilisateurs à certaines applications propre à l'entreprise, il existerait la table suivante :

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE DBO.tbl_UM_Demand_UMD( ID INT IDENTITY(1,1) NOT NULL, USER_ID INT NOT NULL, APP_ID INT NOT NULL, RIGHT_ID INT NOT NULL, ASK_DATE DATETIME NOT NULL CONSTRAINT DF_tbl_UM_Demande_UMD_ASK_DATE DAFAULT (getdate()), VALIDATED BIT NOT NULL CONSTRAINT DF_tbl_UM_Demande_UMD_VALIDATED DAFAULT ('false'), VALIDATION_DATE DATETIME NULL )

---

Dans cette table, les colonnes USER_ID, APP_ID et RIGHT_ID sont bien sûr des clefs étrangères vers les tables adéquates.

Ma question porte sur les colonnes VALIDATED et VALIDATION_DATE.
À partir du moment où une date de validation est présente, on peut en déduire à 100% que la demande est bien validée. De ce fait, la colonne VALIDATED est-elle nécessaire ? Est-ce une "grave" faute de conception ou cela peut-il être envisagé dans certains cas ?

Griftou.

Bonjour,

Pour répondre à cette question, il serait mieux de connaître l'usage de la base.
S'agit-il d 'une base décisionnelle, transactionnelle ou les deux?

Cordialement,

Arkhena

Euh... En français ça donne quoi ta question ? :aie:

Je ne suis DBA que par la force des choses. J'ai bien reçu une formation à sql serveur 2005 fin de l'année dernière mais bon... DBA, c'est tout un métier et ce n'est pas avec une formation que je vais combler mes lacunes...

Du coup, même si je sais ce que les termes décision et transaction signifient (et encore, pour décision, dans le cadre d'une DB, je ne suis pas sûr), je ne comprends pas le sens de ta question :aie:

Bonjour,

On appelle communément "base transactionnelle" une base de données qui reçoit beaucoup de requêtes d'insertion et/ou de modification.
On appelle "base décisionnelle" une base qui après un gros chargement de données gère beaucoup de requêtes de lecture.

Ma question en française est donc comment est utilisée cette base en général et le champ validated de cette table en particulier ?

Si vous ne savez pas, vous pouvez utiliser SQL Profiler pour essayer de savoir.

Cordialement,

Arkhena

C'est une table sur laquelle vont être faite pas mal de requête de type INSERT (toutes les demandes d'accès aux applications en fait).

Et pour chaque ligne, au moins une requête UPDATE sera faite (pour dire si on valide la demande où si on la rejette (j'ai oublié la colonne DEL de type BIT dans ma description))

Et bien sûr, elle fera également l'objet de requête de type SELECT qui devraient être en nombre assez important.

VALIDATED sera mis à vrai si la demande est validée et DEL restera à NULL.
Si la demande est rejetée, VALIDATED restera à NULL et DEL sera mis à vrai.

Je pense que "VALIDATED" ne peut pas découler de "VALIDATION_DATE".
=> En effet, si aujourd'hui, tu passes "VALIDATED" à 1, tu vas allimenter "VALIDATION_DATE".
Mais si tu décides de pouvoir révoquer la validation, quelle sera la règle ? Vider "VALIDATION_DATE", et ainsi perdre la date de la première validation ?
Allimenter "VALIDATION_DATE" et ainsi connaitre la date de révocation ?

Selon la règle, on ne pourra peut-être plus déduire "VALIDATED" aussi facilement.
En revanche, si il est possible de valider/invalider plusieurs fois le droit, ou gérer par exemple des plages d'accès, alors je mettrais une seconde table avec "date début validité / date fin validité". Ou bien "validation_status" / "validation_status_date".
=> Et comme ça, tu ne te pose plus de question ;)

En tout cas, je trouve dangereux de se dire "je peux déduire ça de ce truc donc je le stock pas" quand il ne s'agit pas d'un simple comptage. En effet, les règles tacites ne sont pas forcément évidentes pour tous, et surtout, demain le modèle peut évoluer, et un telle modélisation risque de mettre en péril la reprise des données (car on fini toujours pas tomber sur un cas pas prévu, et on sait pas quoi faire de la donnée)

C'est bien pour cela que je pose la question :ccool:

Bon en fait ça ne va pas. Je me rends compte que je n'arrive pas à modéliser correctement mon besoin...

Ce que je dois faire :
Enregistrer les demandes de droits supplémentaires (ou en moins) pour des applications par des utilisateurs et pouvoir dire ce qui a été demandé pour qui et quand (gardé un historique quoi).

J'ai donc fait ceci pour le moment :
- Une table user qui contient les infos du user dont la clef est une colonne de type Int Identity 1,1 et dont le nom est USR_ID.

- Une table application qui contient les des applications dont la clef est une colonne de type Int Identity 1,1 et dont le nom est APP_ID.

- Une table right qui contient les différents droits existants (utilisateur, administrateur, etc.) dont la clef est une colonne de type Int Identity 1,1 et dont le nom est RGT_ID.

- Une table de jointure entre application et right qui défini quels droits sont disponibles pour chaque application avec juste RGT_ID et APP_ID comme colonnes qui servent de clef primaire composite et sont bien entendu également des clefs étrangères vers leur table respective. (Est-ce d'ailleurs correcte de faire ce genre de chose ou bien vaut-il mieux ajouter une id pour cette table?)

- Et enfin une table demande qui contient donc les demandes d'accès des utilisateurs (c'est donc cette table qui me pose problème à priori). En voici la structure :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

CREATE TABLE [UserManagement].[LinkUserApplicationRight]( [id] [int] IDENTITY(1,1) NOT NULL, [USR_ID] [int] NOT NULL, [APP_ID] [int] NOT NULL, [RGT_ID] [int] NOT NULL, [grant_or_deny] [bit] NOT NULL, [demand_date] [datetime] NOT NULL, [accepted] [bit] NULL, [accepted_date] [datetime] NULL, [user_edit] [varchar](100) NOT NULL, [date_edit] [datetime] NULL, [del] [bit] NOT NULL, CONSTRAINT [PK_LinkUserApplicationRight] PRIMARY KEY CLUSTERED ( [id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

---

J'ai viré la partie du script qui définit les clefs étrangères, je pense que c'est assez clair.
Cette table n'est pour le moment qu'un brouillon donc ne vous prenez pas le choux pour les noms de colonnes, c'est du provisoire. Je mettrai tout au propre quand je serai convaincu.

J'ai donc un id pour la demande et la date de la demande. J'ai les id des infos indispensables à savoir user, application et droit. Je peux savoir si c'est une demande de type grant ou deny (si jamais un user ne doit plus avoir accès à une application, ça passe par là aussi). Ensuite il y a les colonnes accepted qui me permet de savoir si la demande a été acceptée ou refusée par les gestionnaires ainsi que la date de la décision (accepted_date).

Les 3 dernières colonnes ne sont là que pour me permettre de faire un petit tracking pour savoir qui accorderait éventuellement des privilèges à des personnes qui n'y ont pas droit.

Voilà donc à quoi je suis arrivé jusqu'à présent.



Seulement je ne suis pas convaincu de cette table. Je n'arrive à mettre le doigt précisément sur ce qui me dérange mais j'ai la ferme impression qu'il y a quelque chose qui ne va pas du tout avec la conception de cette table (mis à part les noms de colonnes...).

Pourrais-je avoir quelques avis la concernant ?

Comment auriez-vous fait cela ?

Merci d'avance,

Griftou.