Conception d'une base selon un "méta modèle" [Résolu]

[Immobilis]

Salut,

J'ai fait ce petit méta modèle pour créer des entités, des propriétés, des types de données, des instances et les valeurs associées:

J'aimerai recevoir vos critiques à son sujet. Dites moi tout ce qui ne vous parait pas correct.

Merci d'avance

Ci-dessous le code de génération:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
 
-- --------------------------------------------------
-- Entity Designer DDL Script for SQL Server 2005, 2008, and Azure
-- --------------------------------------------------
-- Date Created: 11/24/2011 10:49:50
-- Generated from EDMX file: C:\Users\...\Model.edmx
-- --------------------------------------------------
SET QUOTED_IDENTIFIER OFF;
GO
USE [MetaDatabase];
GO
IF SCHEMA_ID(N'dbo') IS NULL EXECUTE(N'CREATE SCHEMA [dbo]');
GO
-- --------------------------------------------------
-- Dropping existing FOREIGN KEY constraints
-- --------------------------------------------------
IF OBJECT_ID(N'[dbo].[FK_EntiteInstance]', 'F') IS NOT NULL
    ALTER TABLE [dbo].[InstanceJeu] DROP CONSTRAINT [FK_EntiteInstance];
GO
IF OBJECT_ID(N'[dbo].[FK_EntitePropriete]', 'F') IS NOT NULL
    ALTER TABLE [dbo].[ProprieteJeu] DROP CONSTRAINT [FK_EntitePropriete];
GO
IF OBJECT_ID(N'[dbo].[FK_TypeDonneePropriete]', 'F') IS NOT NULL
    ALTER TABLE [dbo].[ProprieteJeu] DROP CONSTRAINT [FK_TypeDonneePropriete];
GO
IF OBJECT_ID(N'[dbo].[FK_ProprieteInstance_Propriete]', 'F') IS NOT NULL
    ALTER TABLE [dbo].[ProprieteInstance] DROP CONSTRAINT [FK_ProprieteInstance_Propriete];
GO
IF OBJECT_ID(N'[dbo].[FK_ProprieteInstance_Instance]', 'F') IS NOT NULL
    ALTER TABLE [dbo].[ProprieteInstance] DROP CONSTRAINT [FK_ProprieteInstance_Instance];
GO
IF OBJECT_ID(N'[dbo].[FK_ProprieteValeur]', 'F') IS NOT NULL
    ALTER TABLE [dbo].[ValeurJeu] DROP CONSTRAINT [FK_ProprieteValeur];
GO
IF OBJECT_ID(N'[dbo].[FK_InstanceValeur]', 'F') IS NOT NULL
    ALTER TABLE [dbo].[ValeurJeu] DROP CONSTRAINT [FK_InstanceValeur];
GO
-- --------------------------------------------------
-- Dropping existing tables
-- --------------------------------------------------
IF OBJECT_ID(N'[dbo].[EntiteJeu]', 'U') IS NOT NULL
    DROP TABLE [dbo].[EntiteJeu];
GO
IF OBJECT_ID(N'[dbo].[ProprieteJeu]', 'U') IS NOT NULL
    DROP TABLE [dbo].[ProprieteJeu];
GO
IF OBJECT_ID(N'[dbo].[TypeDonneeJeu]', 'U') IS NOT NULL
    DROP TABLE [dbo].[TypeDonneeJeu];
GO
IF OBJECT_ID(N'[dbo].[InstanceJeu]', 'U') IS NOT NULL
    DROP TABLE [dbo].[InstanceJeu];
GO
IF OBJECT_ID(N'[dbo].[ValeurJeu]', 'U') IS NOT NULL
    DROP TABLE [dbo].[ValeurJeu];
GO
IF OBJECT_ID(N'[dbo].[sysdiagrams]', 'U') IS NOT NULL
    DROP TABLE [dbo].[sysdiagrams];
GO
IF OBJECT_ID(N'[dbo].[ProprieteInstance]', 'U') IS NOT NULL
    DROP TABLE [dbo].[ProprieteInstance];
GO
-- --------------------------------------------------
-- Creating all tables
-- --------------------------------------------------
-- Creating table 'EntiteJeu'
CREATE TABLE [dbo].[EntiteJeu] (
    [ID] int IDENTITY(1,1) NOT NULL,
    [Nom] nvarchar(max)  NOT NULL
);
GO
-- Creating table 'ProprieteJeu'
CREATE TABLE [dbo].[ProprieteJeu] (
    [ID] int IDENTITY(1,1) NOT NULL,
    [Title] varchar(50)  NOT NULL,
    [Entite_ID] int  NOT NULL,
    [TypeDonnee_ID] int  NOT NULL
);
GO
-- Creating table 'TypeDonneeJeu'
CREATE TABLE [dbo].[TypeDonneeJeu] (
    [ID] int IDENTITY(1,1) NOT NULL,
    [Nom] nvarchar(max)  NOT NULL
);
GO
-- Creating table 'InstanceJeu'
CREATE TABLE [dbo].[InstanceJeu] (
    [ID] int IDENTITY(1,1) NOT NULL,
    [Nom] varchar(50)  NOT NULL,
    [Entite_ID] int  NOT NULL
);
GO
-- Creating table 'ValeurJeu'
CREATE TABLE [dbo].[ValeurJeu] (
    [ID] int IDENTITY(1,1) NOT NULL,
    [Val] nvarchar(max)  NOT NULL,
    [Propriete_ID] int  NOT NULL,
    [Instance_ID] int  NOT NULL
);
GO
-- Creating table 'sysdiagrams'
CREATE TABLE [dbo].[sysdiagrams] (
    [name] nvarchar(128)  NOT NULL,
    [principal_id] int  NOT NULL,
    [diagram_id] int IDENTITY(1,1) NOT NULL,
    [version] int  NULL,
    [definition] varbinary(max)  NULL
);
GO
-- Creating table 'ProprieteInstance'
CREATE TABLE [dbo].[ProprieteInstance] (
    [Propriete_ID] int  NOT NULL,
    [Instance_ID] int  NOT NULL
);
GO
-- --------------------------------------------------
-- Creating all PRIMARY KEY constraints
-- --------------------------------------------------
-- Creating primary key on [ID] in table 'EntiteJeu'
ALTER TABLE [dbo].[EntiteJeu]
ADD CONSTRAINT [PK_EntiteJeu]
    PRIMARY KEY CLUSTERED ([ID] ASC);
GO
-- Creating primary key on [ID] in table 'ProprieteJeu'
ALTER TABLE [dbo].[ProprieteJeu]
ADD CONSTRAINT [PK_ProprieteJeu]
    PRIMARY KEY CLUSTERED ([ID] ASC);
GO
-- Creating primary key on [ID] in table 'TypeDonneeJeu'
ALTER TABLE [dbo].[TypeDonneeJeu]
ADD CONSTRAINT [PK_TypeDonneeJeu]
    PRIMARY KEY CLUSTERED ([ID] ASC);
GO
-- Creating primary key on [ID] in table 'InstanceJeu'
ALTER TABLE [dbo].[InstanceJeu]
ADD CONSTRAINT [PK_InstanceJeu]
    PRIMARY KEY CLUSTERED ([ID] ASC);
GO
-- Creating primary key on [ID] in table 'ValeurJeu'
ALTER TABLE [dbo].[ValeurJeu]
ADD CONSTRAINT [PK_ValeurJeu]
    PRIMARY KEY CLUSTERED ([ID] ASC);
GO
-- Creating primary key on [diagram_id] in table 'sysdiagrams'
ALTER TABLE [dbo].[sysdiagrams]
ADD CONSTRAINT [PK_sysdiagrams]
    PRIMARY KEY CLUSTERED ([diagram_id] ASC);
GO
-- Creating primary key on [Propriete_ID], [Instance_ID] in table 'ProprieteInstance'
ALTER TABLE [dbo].[ProprieteInstance]
ADD CONSTRAINT [PK_ProprieteInstance]
    PRIMARY KEY NONCLUSTERED ([Propriete_ID], [Instance_ID] ASC);
GO
-- --------------------------------------------------
-- Creating all FOREIGN KEY constraints
-- --------------------------------------------------
-- Creating foreign key on [Entite_ID] in table 'InstanceJeu'
ALTER TABLE [dbo].[InstanceJeu]
ADD CONSTRAINT [FK_EntiteInstance]
    FOREIGN KEY ([Entite_ID])
    REFERENCES [dbo].[EntiteJeu]
        ([ID])
    ON DELETE NO ACTION ON UPDATE NO ACTION;
-- Creating non-clustered index for FOREIGN KEY 'FK_EntiteInstance'
CREATE INDEX [IX_FK_EntiteInstance]
ON [dbo].[InstanceJeu]
    ([Entite_ID]);
GO
-- Creating foreign key on [Entite_ID] in table 'ProprieteJeu'
ALTER TABLE [dbo].[ProprieteJeu]
ADD CONSTRAINT [FK_EntitePropriete]
    FOREIGN KEY ([Entite_ID])
    REFERENCES [dbo].[EntiteJeu]
        ([ID])
    ON DELETE NO ACTION ON UPDATE NO ACTION;
-- Creating non-clustered index for FOREIGN KEY 'FK_EntitePropriete'
CREATE INDEX [IX_FK_EntitePropriete]
ON [dbo].[ProprieteJeu]
    ([Entite_ID]);
GO
-- Creating foreign key on [TypeDonnee_ID] in table 'ProprieteJeu'
ALTER TABLE [dbo].[ProprieteJeu]
ADD CONSTRAINT [FK_TypeDonneePropriete]
    FOREIGN KEY ([TypeDonnee_ID])
    REFERENCES [dbo].[TypeDonneeJeu]
        ([ID])
    ON DELETE NO ACTION ON UPDATE NO ACTION;
-- Creating non-clustered index for FOREIGN KEY 'FK_TypeDonneePropriete'
CREATE INDEX [IX_FK_TypeDonneePropriete]
ON [dbo].[ProprieteJeu]
    ([TypeDonnee_ID]);
GO
-- Creating foreign key on [Propriete_ID] in table 'ProprieteInstance'
ALTER TABLE [dbo].[ProprieteInstance]
ADD CONSTRAINT [FK_ProprieteInstance_Propriete]
    FOREIGN KEY ([Propriete_ID])
    REFERENCES [dbo].[ProprieteJeu]
        ([ID])
    ON DELETE NO ACTION ON UPDATE NO ACTION;
GO
-- Creating foreign key on [Instance_ID] in table 'ProprieteInstance'
ALTER TABLE [dbo].[ProprieteInstance]
ADD CONSTRAINT [FK_ProprieteInstance_Instance]
    FOREIGN KEY ([Instance_ID])
    REFERENCES [dbo].[InstanceJeu]
        ([ID])
    ON DELETE NO ACTION ON UPDATE NO ACTION;
-- Creating non-clustered index for FOREIGN KEY 'FK_ProprieteInstance_Instance'
CREATE INDEX [IX_FK_ProprieteInstance_Instance]
ON [dbo].[ProprieteInstance]
    ([Instance_ID]);
GO
-- Creating foreign key on [Propriete_ID] in table 'ValeurJeu'
ALTER TABLE [dbo].[ValeurJeu]
ADD CONSTRAINT [FK_ProprieteValeur]
    FOREIGN KEY ([Propriete_ID])
    REFERENCES [dbo].[ProprieteJeu]
        ([ID])
    ON DELETE NO ACTION ON UPDATE NO ACTION;
-- Creating non-clustered index for FOREIGN KEY 'FK_ProprieteValeur'
CREATE INDEX [IX_FK_ProprieteValeur]
ON [dbo].[ValeurJeu]
    ([Propriete_ID]);
GO
-- Creating foreign key on [Instance_ID] in table 'ValeurJeu'
ALTER TABLE [dbo].[ValeurJeu]
ADD CONSTRAINT [FK_InstanceValeur]
    FOREIGN KEY ([Instance_ID])
    REFERENCES [dbo].[InstanceJeu]
        ([ID])
    ON DELETE NO ACTION ON UPDATE NO ACTION;
-- Creating non-clustered index for FOREIGN KEY 'FK_InstanceValeur'
CREATE INDEX [IX_FK_InstanceValeur]
ON [dbo].[ValeurJeu]
    ([Instance_ID]);
GO
-- --------------------------------------------------
-- Script has ended
-- --------------------------------------------------

[vmolines]

C'est jeopardy ? Sans problème exposé un modèle n'est ni bon ni mauvais.

[fsmrel]

Bonsoir,

vmolines a raison...

Le lecteur est invité à émettre des hypothèses quant à la sémantique qui transpire du diagramme. En logique, les termes entité et instance sont synonymes. On va supposer que par entité vous voulez dire entité-type.

Remontons au niveau conceptuel, disons Merise (mais ça peut être au niveau diagramme de classes UML, mutatis mutandis).

L’entité-type ValeurJeu est en réalité une association-type entre les entités-types ProprieteJeu et InstanceJeu : elle a pour identifiant la paire {Propriete_ID, Instance_ID}. Au niveau logique vous avez préféré mettre en œuvre ex nihilo un attribut ID pour servir de clé primaire : libre à vous, vous avez certainement un motif pour procéder ainsi, mais cet attribut n’offre a priori aucun intérêt et devrait passer au rasoir d’Ockham (en plus on ferait l’économie d’un index). Si vous le conservez, en toute logique la paire {Propriete_ID, Instance_ID} devrait faire l’objet d’une clé alternative (clause UNIQUE), à moins que vous n’ayez décidé que cette paire puisse engendrer des doublons, auquel cas l’attribut Val participerait à la clé primaire.


Si les valeurs prises par la paire {Propriete_ID, Instance_ID} de l’entité-type ValeurJeu doivent être des valeurs prises par la paire {Propriete_ID, Instance_ID} de l’entité-type ProprieteInstance, alors il existe une contrainte d’inclusion faisant qu’il faut rompre les liens entre ValeurJeu et ProprieteJeu d’une part et InstanceJeu d’autre part, au bénéfice d’un lien (clé étrangère) entre ValeurJeu et ProprieteInstance (cf. proposition ci-dessous).

Je relève que les table ValeurJeu et ProprieteInstance peuvent contenir des incohérences. Supposons que la base de données ait la valeur suivante à un instant t :

Code :

1
2
3
4
5
EntiteJeu  ID    ...
           --    ---
           e1    ...
           e2    ...
           e3    ...

Code :

1
2
3
ProprieteJeu  ID    Entite_ID    ...
              --    ---------    ---
              p1           e1    ...

Code :

1
2
3
4
5
InstanceJeu  ID    Entite_ID    ...
             --    ---------    ---
             i1           e1    ...
             i2           e2    ...
             i3           e3    ...

Code :

1
2
3
ProprieteInstance  Propriete_ID    Instance_ID 
                   ------------    ----------- 
                             p1             i3

Code :

1
2
3
ValeurJeu  ID    Propriete_ID    Instance_ID    ...
           --    ------------    -----------    ---
           v1              p1             i2    ...

Autrement dit, par un chemin la valeur <p1> de ValeurJeu détermine la valeur <e1> de EntiteJeu et la valeur <e2> par un autre chemin.

Cela est peut-être normal, mais si ça ne l’est pas, la modélisation est à revoir. Si sémantiquement parlant ProprieteJeu et InstanceJeu sont des propriétés multivaluées de EntiteJeu, alors on fait jouer l’identification relative et les clés primaires seraient les suivantes :

ProprieteJeu : {Entite_ID, Propriete_ID} ;
InstanceJeu : {Entite_ID, Instance_ID} ;

Les tables ProprieteInstance et ValeurJeu seraient alors dotées d’un attribut supplémentaire Entite_ID (un et un seul bien entendu). Les clés primaires seraient les suivantes :

ProprieteInstance : {Entite_ID, Propriete_ID, Instance_ID} ;
ValeurJeu : {Entite_ID, Propriete_ID, Instance_ID}, ou {Entite_ID, Propriete_ID, Instance_ID, Val_Id} si ça ne suffit pas.

Une proposition (ne faites pas attention au changement du type des attributs en char(8) et autres incongruités, je me simplifie simplement la vie au sujet des jeux d'essai...) :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
CREATE TABLE TypeDonneeJeu (
      ID char(8)  NOT NULL
    , Nom varchar(32)  NOT NULL
 , CONSTRAINT PK_TypeDonneeJeu PRIMARY KEY (ID)
);
CREATE TABLE EntiteJeu (
      ID char(8)  NOT NULL
    , Nom varchar(32)  NOT NULL
  , CONSTRAINT PK_EntiteJeu PRIMARY KEY (ID)
);
CREATE TABLE ProprieteJeu (
      Entite_ID char(8)  NOT NULL
    , Propriete_ID char(8)  NOT NULL
    , TypeDonnee_ID char(8)  NOT NULL
    , Title varchar(32)  NOT NULL
 , CONSTRAINT PK_ProprieteJeu PRIMARY KEY (Entite_ID, Propriete_ID)
 , CONSTRAINT ProprieteJeu_FK1 FOREIGN KEY (Entite_ID) 
              REFERENCES EntiteJeu(ID)
 , CONSTRAINT ProprieteJeu_FK2 FOREIGN KEY (TypeDonnee_ID) 
              REFERENCES TypeDonneeJeu(ID)
);
CREATE TABLE InstanceJeu (
      Entite_ID char(8)  NOT NULL
    , Instance_ID char(8)  NOT NULL
    , Nom varchar(32)  NOT NULL
 , CONSTRAINT PK_InstanceJeu PRIMARY KEY (Entite_ID, Instance_ID)
 , CONSTRAINT FK_EntiteInstance FOREIGN KEY (Entite_ID) 
              REFERENCES EntiteJeu (ID)
);
CREATE TABLE ProprieteInstance (
      Entite_ID char(8)  NOT NULL
    , Propriete_ID char(8)  NOT NULL
    , Instance_ID char(8)  NOT NULL
 , CONSTRAINT PK_ProprieteInstance PRIMARY KEY (Entite_ID, Propriete_ID, Instance_ID)
 , CONSTRAINT ProprieteInstance_FK1 FOREIGN KEY (Entite_ID, Propriete_ID) 
              REFERENCES ProprieteJeu (Entite_ID, Propriete_ID)
 , CONSTRAINT ProprieteInstance_FK2 FOREIGN KEY (Entite_ID, Instance_ID) 
              REFERENCES InstanceJeu (Entite_ID, Instance_ID)
);
CREATE TABLE ValeurJeu (
      Entite_ID char(8)  NOT NULL
    , Propriete_ID char(8)  NOT NULL
    , Instance_ID char(8)  NOT NULL
    , Val varchar(32)  NOT NULL
    , CONSTRAINT PK_ValeurJeu PRIMARY KEY  (Entite_ID, Propriete_ID, Instance_ID, Val)
    , CONSTRAINT ValeurJeu_FK FOREIGN KEY (Entite_ID, Propriete_ID, Instance_ID) 
                 REFERENCES ProprieteInstance (Entite_ID, Propriete_ID, Instance_ID)
) ;

Du métabolisme.

Vous utilisez systématiquement la clause ON DELETE NO ACTION. Le défi sémantique est d’utiliser la clause ON DELETE CASCADE quand elle est pertinente. Par exemple, autant il serait mal venu de retenir CASCADE pour la contrainte (FK_TypeDonneePropriete), autant pour les autres contraintes il y a une réflexion à mener.

[iberserk]

Salut immobilis...

Je ne connais pas les volumétries mises en jeu mais je t'encourage juste à réfléchir à tes typages, aspect souvent négligé chez les développeurs(j'entends par développeur les non DBA...).

A savoir: Est'il pertinent pour toi d'utiliser un NVARCHAR qui est je le rappel deux fois plus coûteux que le VARCHAR? (internationalisation avec plusieurs langues différentes à gérer....).


Vas tu avoir plus de 32767 type de propriétés? (en clair un SMALLINT ne suffit-il pas)

etc...

[Immobilis]

Salut à tous et merci pour vos interventions.

@fsmrel merci pour ton analyse et j'apprécie beaucoup la qualité de ta rédaction

@iberserk Salut j'avoue que je n'ai pas fait attention au typage car pour le moment j'en suis au stade de la conception

@vmolines tu pourrais au moins dire bonjour

@vous_trois mes excuses. Je suis allé un peu vite dans la création de mon fil. Je vous dois plus d'explications. Je cherche à réaliser une base de données dont l'architecture est faite sur des métadonnées. Puis-je l'appeler métamodèle?

L'url ci-dessus renvoi vers le tuto de sqlpro. C'est un bon point de départ. J'aimerai aller plus loin. J'ai donc réalisé ce premier modèle.

L'idée est donc de pouvoir enregistrer en base des structures de Types avec leurs propriétés typées et d'enregistrer des instances.

Dans une seconde version, afin d'optimiser la base (pour iberserk ), j'aimerai utiliser une table par type de données de base (chaine, entier, décimaux, date, etc.). L'enregistrement d'une instance doit répartir les valeurs dans chacune des tables.

Pour réaliser ce modèle, j'ai utilisé un Entity Data Model. Le typage obtenu n'est pas le plus adapté. Pour le coup cela suffit dans un premier temps pour faire des brouillons.

Je me sert aussi de Dynamic Data pour tester le modèle.

@fsmrel je vais continuer de décortiquer ta proposition.

S'agissant d'un stade de conception, j'aurai pu poster dans le forum idoine mais je voulais un avis de DBA.

Merci à tous. Je me permet de garder le fil ouvert pour vous faire un retour.

Si un modo juge que le fil doit être déplacé pas de soucis.

[iberserk]

L'enregistrement d'une instance doit répartir les valeurs dans chacune des tables.

Avec un TRIGGER bien entendu hein? pas côté client (dis moi que ce n'est pas ce que tu voulais faire :-)).

j'aimerai utiliser une table par type de données de base (chaine, entier, décimaux, date, etc.).

Je travaille actuellement sur une application basée sur une modélisation par métamodèle.

Quand je suis arrivé ils avaient mis en place une table avec 4 colonnes (une par type les booléen 0 et 1 étant stockée dans la colonne int)

Nous revenons maintenant en arrière et migrons vers une seule colonne VARCHAR, les TRIGGERS se chargeant de vérifier l'intégrité des données.

Nous gagnons sur tous les tableaux: volumétrie, nombre d'index moindres etc.

[vmolines]

Bonjour à tous,

@immobilis
désolé pour mon entrée en matière un peu brutale, tu as raison de le faire remarquer.

@iberserk
Le choix d'opter pour le non-typage des valeurs (toutes en varchar) est-il possible car vous n'avez pas de traitements qui nécessitent un typage fort de vos valeurs dans votre projet (écriture/restitution telles quelles) ?
Si oui, auriez-vous opté pour ce typage simple si vous aviez eu des traitements comme des sommes, des opérations sur des dates, ... ?

[fsmrel]

Bonsoir,

Envoyé par Immobilis

Je cherche à réaliser une base de données dont l'architecture est faite sur des métadonnées. Puis-je l'appeler métamodèle?

A priori, oui. Mais votre métamodèle ressemble plutôt à celui d’une métabase (le catalogue des objets constituant une base de données). Les objets que vous faites figurer sont-ils vraiment caractéristiques de l'univers « Jeux » ?

Par exemple, Merise a un métamodèle pour décrire les objets de la méthode, et eux seuls. En voici une vue partielle :



Voici une autre vue, représentant le métamodèle des contraintes avec Merise (extrait de l’article d’Yves Tabourier in afcet - Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris).



Au sujet des contraintes (pivot, portée, etc.) Voir par exemple ici, notamment la figure 9.

[iberserk]

Le choix d'opter pour le non-typage des valeurs (toutes en varchar) est-il possible car vous n'avez pas de traitements qui nécessitent un typage fort de vos valeurs dans votre projet (écriture/restitution telles quelles) ?
Si oui, auriez-vous opté pour ce typage simple si vous aviez eu des traitements comme des sommes, des opérations sur des dates, ... ?

En partie oui, pour notre exemple, c'est la modélisation de caractéristiques d'articles et utilisateurs qui ne nécessitent pour la plupart que de l'affichage.

Mais nous avons malgré tout des traitements nécessitant des typages fort (CAST) sans que cela pose de problème, les CAST sont effectués à la volée dans les requêtes.

A partir du moment ou tu met en place un modèle qui assurent sa propre cohérence des données (et donc ne pas déléguer cela à la couche métier du code client comme c'était le cas avant...) le requetage se fait les yeux fermés sans se demander si le CAST va exploser...

[Immobilis]

Envoyé par iberserk

Avec un TRIGGER bien entendu hein? pas côté client (dis moi que ce n'est pas ce que tu voulais faire :-)).

Euh, tu connais mon penchant pour tout mettre dans la couche métier

Quelle utilisation fais-tu d'un trigger dans ce cas? Comment passes-tu un objet à la base pour qu'elle le décompose et le stock?

Envoyé par iberserk

Nous revenons maintenant en arrière et migrons vers une seule colonne VARCHAR, les TRIGGERS se chargeant de vérifier l'intégrité des données.

Nous gagnons sur tous les tableaux: volumétrie, nombre d'index moindres etc.

Ne serait-ce pas mieux d'utiliser des tables pour chaque type de données? Une table avec que les entiers serait certainement plus adaptée qu'une table de caractères pour stocker un nombre de cacahuètes.

Envoyé par fsmrel

Les objets que vous faites figurer sont-ils vraiment caractéristiques de l'univers « Jeux » ?

"Jeu" est la traduction de "Set". J'ai une version FR de VS2010 L'idée est de pouvoir stocker des données de n'importe quel univers.

Envoyé par iberserk

A partir du moment ou tu met en place un modèle qui assurent sa propre cohérence des données (et donc ne pas déléguer cela à la couche métier du code client comme c'était le cas avant...) le requetage se fait les yeux fermés sans se demander si le CAST va exploser...

Ok, mais si cela permet d'économiser en volumétrie et index, je doute que cela améliore les performance. Aurais-tu quelques métriques? Par exemple la recherche de toutes les personnes nées avant le 16 mai 2007 dans une liste de 1 million. J'espère tout de même que c'est plus rapide quand c'est correctement typé.

@fsmrel Je continue de décortiquer ta première proposition. J'ai une première question. Pourquoi utiliser des ID sur 8 caractères plutôt qu'un entier autoincrémenté?

A+

[fsmrel]

Bonsoir,

Envoyé par Immobilis

"Jeu" est la traduction de "Set".

Dans le monde des bases de données relationnelles, le terme approprié est plutôt celui d’« ensemble ». En effet, l’algèbre relationnelle opère sur des relations (cf. les opérateurs UNION, INTERSECTION, etc.) Je cite Georges Gardarin : « Le concept de relation découle directement de la théorie des ensembles. » (G. Gardarin. Bases de données. Les systèmes et leurs langages. (Eyrolles, 1988), page 66). Cela dit, les relations du Modèle Relationnel de Données se distinguent des relations telles quelles sont perçues en mathématiques, par exemple parce qu’elles ont un en-tête et que les attributs composant celui-ci ont un nom et peu importe leur ordre. Je vous renvoie à The Database Relational Dictionary.

Envoyé par Immobilis

Pourquoi utiliser des ID sur 8 caractères plutôt qu'un entier autoincrémenté?

Quand je modélise dans le but de mettre en œuvre une base de données en production, j’utilise le type INT, puisque les valeurs des clés primaires doivent être invariantes et tant qu’à faire non porteuses de sens. Comme je l'ai dit dans mon premier message, quand il s’agit de discuter sur des exemples j’utilise volontiers le type CHAR car les valeurs des attributs sont alors plus faciles à visualiser, c'est quand même plus parlant. Ça ne va pas plus loin que ça...

[iberserk]

Ne serait-ce pas mieux d'utiliser des tables pour chaque type de données? Une table avec que les entiers serait certainement plus adaptée qu'une table de caractères pour stocker un nombre de cacahuètes.

C'était une autre piste explorée, vite abandonnée du fait de sa complexité (multiplication des tables et des triggers etc...) notamment sur des requêtes faisant intervenir plusieurs tables, et se posait le problème de comment savoir dans quel table aller 'taper' en fonction des caractéristiques demandées...

Mais cette solution est faisable bien entendu.

De toute façon il faut que tu te pose des questions sur l'usage que tu va faire de ta base...

Pour rappel nos données sont essentiellement utilisées à des fins d'affichage...

Le données sont récupérées telles qu'elles sont en base puis nous passons par des mapper de DomainModel pour créer des objets structurés.

[iberserk]

Euh, tu connais mon penchant pour tout mettre dans la couche métier

Je ne reviendrais pas là dessus... surtout ici c'est trop facile j'ai déjà gagné

il y a deux semaines... déploiement chez un client, évolution du lot d'import des données...

Insertions de plus d'un million de caracteristiques...
Le client avait fait une erreur sur ses fichiers plats... le TRIGGER lui a tout de suite réglé son compte...
Or ici ton code client n'est pas appelé (un import de cette volumétrie en code non ensembliste n'est pas viable...).

Quelle utilisation fais-tu d'un trigger dans ce cas? Comment passes-tu un objet à la base pour qu'elle le décompose et le stock?

Je n'ai pas compris ta question?
Le rôle du TRIGGER est essentiellement de vérifier lors d'INSERT ou d'UPDATE que les données insérées sont bien du type de la caractéristique auquel il est rattaché...

[iberserk]

J'espère tout de même que c'est plus rapide quand c'est correctement typé.

Assurément ton modèle physique dépendra de ce que tu attends de lui
mais nous ne faisons pas ce genre d'opération... nous avons des objets 'de base' qui contiennent des colonnes 'de base' (exemple pour un article: date de création ou prix...)

[Immobilis]

Envoyé par iberserk

Je n'ai pas compris ta question?
Le rôle du TRIGGER est essentiellement de vérifier lors d'INSERT ou d'UPDATE que les données insérées sont bien du type de la caractéristique auquel il est rattaché...

Aah ok... Et bien tout dépend encore du cas d'utilisation. Dans celui que tu cites, il s'agit d'un import en masse d'un fichier déjà traité. Pour vraiment comparer, il faudrait faire le test avec un code métier qui utilise un reader et teste les variables. Il ne s'agit pas de monter une collection d'entités en mémoire évidement.
Probablement que la base de données gagnerait tout de même, mais je ne suis pas certain que la différence entre les deux serait si grande. Si en plus tu ajoutes SQL Service Brooker on peut faire un pari sur la différence de temps

Envoyé par iberserk

Avec un TRIGGER bien entendu hein? pas côté client (dis moi que ce n'est pas ce que tu voulais faire :-)).

Ben si. Dans le cas de mise à jour manuelle sur des quantités normales, mon code le fera. Pourquoi? Parce que j'ai plus de facilités à rédiger une méthode qui appellera la bonne procédure stockée pour insérer mes valeurs dans la table typée correspondante. De plus, si je dispose déjà d'objets métier typés, je vois pas l'intérêt d'ajouter une deuxième vérification en base.

En plus, si j'ai une erreur sur une ligne, je saurai facilement la mettre de côté, traiter les autres et informer l'utilisateur final (pas un technicien) des erreurs.

Envoyé par iberserk

C'était une autre piste explorée, vite abandonnée du fait de sa complexité (multiplication des tables et des triggers etc...) notamment sur des requêtes faisant intervenir plusieurs tables, et se posait le problème de comment savoir dans quel table aller 'taper' en fonction des caractéristiques demandées...

C'est justement celle là qui m'intéresse au final. As-tu essayé l'approche code client justement?

A+

[iberserk]

Pour vraiment comparer, il faudrait faire le test avec un code métier qui utilise un reader et teste les variables.

Donc tu repasses à un traitement ligne par ligne?

C'est justement celle là qui m'intéresse au final. As-tu essayé l'approche code client justement?

Bien sûr que non il est évident que des vérifications sont faites côté client sur les données saisies par exemple.

Mais encore une fois tu pars du principe que seule ton application modifiera ta base de données...

C'est un pari bien audacieux!
Qu'adviendra t'il quand une autre application, un DBA (un développeur) viendra faire une petite requête de modification 'qui ne risque rien'.

Pour la modélisation, il serait intéressant d'avoir l'avis de SQLPRO par exemple qui est l'auteur d'un tutoriel sur cette modélisation.

[Immobilis]

Envoyé par iberserk

Donc tu repasses à un traitement ligne par ligne?

Pour tenir le pari oui. Sinon, dans la vrai vie, j'essaierai de passer par un package SSIS.

Envoyé par iberserk

Bien sûr que non il est évident que des vérifications sont faites côté client sur les données saisies par exemple.

Mais encore une fois tu pars du principe que seule ton application modifiera ta base de données...

C'est un pari bien audacieux!

Audacieux... Ca me va tout à fait comme qualificatif Plus serieusement, la question de la qualité des données se place à tous les niveaux. Est-ce à la méthode appelée ou au code appelant de vérifier les données? Je n'ai pas encore d'avis tranché sur la question. J'aurai tendance à laisser une bonne part de cette résponsabilité sur l'appelant. Maintenant, on peut placer des check points à tous les étages. C'est un peu comme les incidents qui se sont produit sur les centrales nucléaires. Y'a un risque que certaines personnes passent malgré les contrôles. Augmenter les contrôles pour éviter le risque à des impacts. Comment tu gères les développeurs qui utilisent SQL Server Mgt Studio pour lancer des requêtes de mise à jour et oublient de mettre la clause "where"? Comme il n'a pas accès à la base de prod, il en est quitte pour mettre un euro dans le cochon

Envoyé par iberserk

Qu'adviendra t'il quand une autre application, un DBA (un développeur) viendra faire une petite requête de modification 'qui ne risque rien'.

Il y a toujours des risques et c'est pour cela qu'il y a des personnes censées vérifier les bonnes pratiques. Placer des triggers permet de diminuer ce risque c'est certain.
A+

[vmolines]

Vos applications présentent et permettent de saisir des données qui finissent dans une base de données. Si c'est la base de données qui les stocke, qui de mieux placé pour garantir leur qualité et leur intégrité ? Pensez vous sincèrement que séparer le stockage des données de leur garantie qualité est la meilleure assurance ?

Vous trouverez toujours un moyen de casser un système mis en place mais ça ne justifie pas d'avoir de plus mauvaises pratiques qui augmentent les problèmes potentiels. Vous justifiez l'absence de contrôle au niveau BDD en disant qu'il est toujours possible de casser une BDD qui dispose de contrôle. De plus, vous prenez un exemple qui traite d'une mise à jour indésirable de données faite par un développeur qui passe une requête update. Où est la perte de qualité et de cohérence des données avec une requête update ? Je ne vois qu'une mise à jour. Ma BDD avec tous ses contrôles sera toujours cohérente malgré cette requête update.

Vous traitez d'un problème d'accès aux données qui est différent de la cohérence de celles ci. Un développeur qui accède à une base de prod pour faire du développement, c'est un tout autre problème.

[Immobilis]

Bon c'était pas trop le sujet de départ...

Envoyé par vmolines

Si c'est la base de données qui les stocke, qui de mieux placé pour garantir leur qualité et leur intégrité ?

Je ne suis pas certain que répondre à cette question dans le forum SGBDD soit le meilleur endroit. Je suis en minorité Perso, je pense pas que ce soit le rôle de la BD. La vérification ayant été faite par le code. Il n'est pas nécessaire de faire cette vérification une deuxième fois. C'est tout ce que je dis Vous faites comme vous voulez Pour ma culture, connaissez-vous la différence de temps pour insérer un million d'enregistrements avec et sans trigger?

Envoyé par vmolines

Pensez vous sincèrement que séparer le stockage des données de leur garantie qualité est la meilleure assurance ?

Je dirai simplement que un SI n'est pas constitué que d'un seul élément. Si les données sont une part importante de l'édifice ce n'est pas la seule. La BD peut se reposer sur une couche applicative pour ça. Cela peut vous paraître une mauvaise pratique mais bon... En tous les cas, une application peut le faire (j'ai déjà vu cela fonctionner) alors que avec une BD

Envoyé par iberserk

C'était une autre piste explorée, vite abandonnée du fait de sa complexité (multiplication des tables et des triggers etc...) notamment sur des requêtes faisant intervenir plusieurs tables, et se posait le problème de comment savoir dans quel table aller 'taper' en fonction des caractéristiques demandées...

@iberserk, j'espère ne pas détourner le fond de ta pensée.

Envoyé par vmolines

Ma BDD avec tous ses contrôles sera toujours cohérente malgré cette requête update.

Je parlais d'une requête sans clause where par exemple. J'ai bien compris le principe du trigger

A+

[iberserk]

@iberserk, j'espère ne pas détourner le fond de ta pensée.

En l’occurrence si, la phrase que tu cite ne faisait qu'expliquer pourquoi une solution FULL BDD avait été choisie à une autre solution FULL BDD, je ne vois donc pas le rapport

Pour ma culture, connaissez-vous la différence de temps pour insérer un million d'enregistrements avec et sans trigger?

Tu veux dire avec et sans vérification du typage?

Je suis à moins de 4 minutes avec TRIGGER dans mon cas avec environ 1 million d'enregistrements sur un simple serveur de test (4 GIGA, sous système disque banal 2 coeurs...).
Pas essayé sans TRIGGER...

Perso, je pense pas que ce soit le rôle de la BD.

Désolé mais c'est quand même une sacré aberration ce que tu dis...
Pour ma part je vais en rester là... argumenter ne semble pas servir à grand chose de toute façon...

Je dirai simplement que un SI n'est pas constitué que d'un seul élément. Si les données sont une part importante de l'édifice ce n'est pas la seule. La BD peut se reposer sur une couche applicative pour ça.

Tu te mets une épine dans le pieds... si justement ton SI est constitué de plusieurs éléments tapant tous dans ta base... rien ne te garantie que toutes les applications exploitant ta base de données auront la même rigueur que ton code....