[MPD] Modélisation des artistes

[pachot]

Bonjour dba01,

Je me souviens d'avoir paramétré un 13ème puis un 14ème mois pour des comptables il y a longtemps...
Il faudrait avoir tout le contexte fonctionnel et en discuter avec le business.
D'une part, un report me semble devoir être identifié clairement, avec un flag, ou un type d'opération. C'est même peut-être quelque chose à stocker dans une autre table. et on doit savoir ce qu'on interroge vraiment.
D'autre part, on trouve souvent plusieurs dates. En compta, on peut avoir des périodes comptables par mois et ce n'est pas un format DATE mais une foreign key sur une table des périodes comptables. Celle-là peut avoir des périodes spéciales si ça a un sens au niveau du business.

Mais c'est mieux de ne pas tout mélanger. Une colonne qui contient plusieurs informations (une date, un type d'opération, etc.) posera des problèmes.

Cordialement,
Franck.

[fsmrel]

Hello,

A propos des dates floues.

Envoyé par CinePhil

Je ne connais pas les dates de naissance de tous les artistes et encore moins leur date de décès puisque beaucoup sont encore en vie.

Si vous voulez par exemple calculer l’âge d’un artiste même sans tout connaître de sa date de naissance, calculer l’âge qu’il avait au moment de son décès (sans là non plus tout connaître de la date), vous pouvez vous substituer à SQL pour simuler un type DATE et définir vos propres fonctions.

Une proposition parmi d’autres ; Considérez l’instruction ci-dessous (j’utilise ici SQL Server) :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE ARTISTE 
(
        PsnId               INT              NOT NULL
      , PsnNom              VARCHAR(64)      NOT NULL
      , DateNaiss           CHAR(10)         NOT NULL
    , CONSTRAINT ARTISTE_PK PRIMARY KEY (PsnId) 
    , CONSTRAINT ARTISTE_CK02 CHECK 
       (
        ISDATE(DateNaiss) = 1 
        OR SUBSTRING (DateNaiss, 6, 2) = '??' AND ISDATE(SUBSTRING (DateNaiss, 1, 5)+ '01' + SUBSTRING (DateNaiss, 8, 3)) = 1
        OR SUBSTRING (DateNaiss, 9, 2) = '??' AND ISDATE(SUBSTRING (DateNaiss, 1, 8)+ '01') = 1
        OR SUBSTRING (DateNaiss, 6, 5) = '??-??' AND ISDATE(SUBSTRING (DateNaiss, 1, 5)+ '01-01') = 1
       )
) ;

La date de naissance est contrainte à être du type Date (à cause de la fonction ISDATE), mais avec la possibilité que le jour de naissance soit inconnu (marqué '??'), même chose pour le mois.

On peut aussi programmer une fonction de contrôle du type (Est_Valide_Date ci-dessous), qui puisse être appelée en d’autres endroits (par d’autres fonctions ou des CREATE TABLE).

Exemple. Prenons en compte en passant la date de décès :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE ARTISTE 
(
        PsnId               INT              NOT NULL
      , PsnNom              VARCHAR(64)      NOT NULL
      , DateNaiss           CHAR(10)         NOT NULL
      , DateDeces           CHAR(10)         NOT NULL
    , CONSTRAINT ARTISTE_PK PRIMARY KEY (PsnId) 
    , CONSTRAINT ARTISTE_CK02 CHECK 
       (dbo.Est_Valide_Date(DateNaiss) = 1 AND SUBSTRING (DateNaiss, 1, 4) <> '????')
    , CONSTRAINT ARTISTE_CK03 CHECK 
       (dbo.Est_Valide_Date(DateDeces) = 1)
;

Pour généraliser, on accepte de ne pas connaître l’année pour une date, auquel cas on autorise le marqueur '????' (que l’on peut récuser pour la date de naissance).

Fonction :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE FUNCTION Est_Valide_Date (@Date1 CHAR(10))
    RETURNS INT
    AS 
     BEGIN
      DECLARE @OK INT
      SET @OK = 0 ; 
      IF
        ISDATE(@Date1) = 1 
        OR SUBSTRING (@Date1, 6, 2) = '??' AND ISDATE(SUBSTRING (@Date1, 1, 5)+ '01' + SUBSTRING (@Date1, 8, 3)) = 1
        OR SUBSTRING (@Date1, 9, 2) = '??' AND ISDATE(SUBSTRING (@Date1, 1, 8)+ '01') = 1
        OR SUBSTRING (@Date1, 6, 5) = '??-??' AND ISDATE(SUBSTRING (@Date1, 1, 5)+ '01-01') = 1
        OR @Date1 = '????-??-??'
        SET @OK = 1 
      RETURN (@OK) ;
      END

On peut définir d’autres fonctions, par exemple pour calculer la différence entre dates (calculer par exemple l’âge d’un artiste), pour savoir si une date est postérieure une autre date, etc., tout en tenant compte des marques '??'.

Exemple (je ne prétends pas avoir testé tous les cas de figure...) :

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
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
-------------------------------------------------------------------------------
-- Fonction pour calculer le nombre d'années entre deux dates 
-- (calcul de l'âge d'une personne aujourd'hui, 
-- (Calcul de l'âge au moment du décès, etc.
--------------------------------------------------------------------------------
CREATE FUNCTION AGE_PERSONNE (@Date1 CHAR(10), @Date2 CHAR(10))
    RETURNS CHAR(128)
    AS 
      BEGIN
          DECLARE @Age CHAR(3)
          DECLARE @Remarque CHAR(128)
          SET @Age = '??'
          DECLARE @a INT 
          DECLARE @b INT 
          DECLARE @c INT 
          DECLARE @d INT 
          DECLARE @e INT 
          DECLARE @f INT 
          DECLARE @g INT 
          DECLARE @h INT 
          DECLARE @i INT 
          SET @a = 0
          SET @b = 0
          SET @c = 0
          SET @d = 0
          SET @e = 0
          SET @f = 0
          SET @g = 0
          SET @h = 0
          SET @i = 0
          DECLARE @TheJour   CHAR(2)
          DECLARE @TheMois   CHAR(2)
          DECLARE @TheAnnee  CHAR(4)
 
          SET @TheJour  = SUBSTRING (@Date2, 9, 2)  
          SET @TheMois  = SUBSTRING (@Date2, 6, 2)
          SET @TheAnnee = SUBSTRING (@Date2, 1, 4)
 
          IF dbo.Est_Valide_Date(@Date1) = 0 OR dbo.Est_Valide_Date(@Date2) = 0
             BEGIN
                SET @Age = '!!'
                SET @Remarque = 'Erreur structure de date'
             END
 
        IF @Age <> '!!' 
           BEGIN
              IF SUBSTRING (@Date1, 6, 2) = '??'  -- Mois naissance
                 SET @a = 1 ;
              IF SUBSTRING (@Date1, 9, 2) = '??' -- Jour naissance  
                 SET @b = 1 ;
              IF SUBSTRING (@Date1, 1, 4) < @TheAnnee -- Année naissance  
                 SET @c = 1 ;
              IF SUBSTRING (@Date1, 6, 2) < @TheMois -- Mois naissance  
                 SET @d = 1 ;
              IF SUBSTRING (@Date1, 6, 2) = @TheMois -- Mois naissance  
                 SET @e = 1 ;
              IF SUBSTRING (@Date1, 9, 2) > @TheJour -- Jour naissance  
                 SET @f = 1 ;
              IF SUBSTRING (@Date2, 1, 4) = '????'  
                 SET @g = 1 ;
              IF SUBSTRING (@Date2, 6, 2) = '??'  
                 SET @h = 1 ;
              IF SUBSTRING (@Date2, 9, 2) = '??'  
                 SET @i = 1 ;
 
              IF @c = 0 
                 SET @Age = 0 ;
              ELSE
                 BEGIN  
                   IF NOT  (@g = 1 OR @h = 1 OR @i = 1 AND @e = 1)
                      BEGIN  
                        IF (@e = 1 AND @f = 1 AND @b = 0) OR @a = 0 AND @d  = 0 AND @e = 0
                          SET @Age = (CAST (@TheAnnee AS INT) - CAST (SUBSTRING (@Date1, 1, 4) AS INT) - 1) ;
                        ELSE
                        IF @e = 1 AND @f = 0 AND @b = 0 OR @c = 1 AND @a = 0 AND (@d  = 1 OR @e = 0)   
                         SET @Age = (CAST (@TheAnnee AS INT) - CAST (SUBSTRING (@Date1, 1, 4) AS INT)) ;
                        ELSE
                         IF @e = 1 AND @b = 0 AND @f = 0  
                           SET @Age = (CAST (@TheAnnee AS INT) - CAST (SUBSTRING (@Date1, 1, 4) AS INT) + 1) ;
                     END
                END
              ----------------------------------------------
              -- Pour les tests...                  
              ----------------------------------------------
              SET @Remarque = ' @a=' + CAST(@a AS CHAR(1)) + ' @b=' + CAST(@b AS CHAR(1)) + ' @c=' + CAST(@c AS CHAR(1))
                            + ' @d=' + CAST(@d AS CHAR(1)) + ' @e=' + CAST(@e AS CHAR(1)) + ' @f=' + CAST(@f AS CHAR(1))
                            + ' @TheAnnee=' + CAST(@TheAnnee AS CHAR(4))
                            + ' @TheMois='  + CAST(@TheMois AS CHAR(2))
                            + ' @TheJour='  + CAST(@TheJour AS CHAR(2))
          END                        
          RETURN (@Age + @Remarque)    
      END ;

Un début de jeu d'essai (pour les besoins de tests, certains artistes sont très jeunes et d’autres beaucoup plus vieux !) :

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
INSERT INTO ARTISTE VALUES (1,  'p01', '2012-04-16', '????-??-??') ;  
INSERT INTO ARTISTE VALUES (3,  'p03', '2012-04-15', '????-??-??') ;   -- Age = 0   
INSERT INTO ARTISTE VALUES (5,  'p05', '2012-04-14', '????-??-??') ;   -- Age = 0   
INSERT INTO ARTISTE VALUES (7,  'p07', '2012-??-15', '????-??-??') ;   -- Age = 0   
INSERT INTO ARTISTE VALUES (9,  'p09', '2012-04-??', '????-??-??') ;   -- Age = 0   
INSERT INTO ARTISTE VALUES (10, 'p10', '2011-05-01', '????-??-??') ;   -- Age = 0 
INSERT INTO ARTISTE VALUES (11, 'p11', '2011-05-??', '????-??-??') ;   -- Age = 0 
INSERT INTO ARTISTE VALUES (12, 'p12', '2011-??-16', '????-??-??') ;   -- Age = ?? 
INSERT INTO ARTISTE VALUES (13, 'p13', '2011-04-16', '????-??-??') ;   -- Age = 0 
INSERT INTO ARTISTE VALUES (14, 'p14', '2011-04-??', '????-??-??') ;   -- Age = 0 
INSERT INTO ARTISTE VALUES (15, 'p15', '2011-04-15', '????-??-??') ;   -- Age = 1 
INSERT INTO ARTISTE VALUES (17, 'p17', '2011-04-14', '????-??-??') ;   -- Age = 1 
INSERT INTO ARTISTE VALUES (18, 'p18', '2011-03-??', '????-??-??') ;   -- Age = 1 
INSERT INTO ARTISTE VALUES (19, 'p19', '2011-03-31', '????-??-??') ;   -- Age = 1 
INSERT INTO ARTISTE VALUES (20, 'p20', '2010-05-01', '????-??-??') ;   -- Age = 1 
INSERT INTO ARTISTE VALUES (21, 'p21', '2010-05-??', '????-??-??') ;   -- Age = 1 
INSERT INTO ARTISTE VALUES (22, 'p22', '2010-04-16', '????-??-??') ;   -- Age = 1 
INSERT INTO ARTISTE VALUES (23, 'p23', '2010-04-??', '????-??-??') ;   -- Age = 0 
INSERT INTO ARTISTE VALUES (24, 'p24', '2010-04-15', '????-??-??') ;   -- Age = 2 
INSERT INTO ARTISTE VALUES (25, 'p25', '2010-04-14', '????-??-??') ;   -- Age = 2 
INSERT INTO ARTISTE VALUES (27, 'p27', '2012-??-16', '????-??-??') ;   -- Age = 0 
INSERT INTO ARTISTE VALUES (29, 'p29', '2012-04-??', '????-??-??') ;   -- Age = 0 
INSERT INTO ARTISTE VALUES (31, 'p31', '2011-??-16', '????-??-??') ;   -- Age = ?? 
INSERT INTO ARTISTE VALUES (33, 'p33', '2011-??-15', '????-??-??') ;   -- Age = ?? 
INSERT INTO ARTISTE VALUES (35, 'p35', '2011-??-14', '????-??-??') ;   -- Age = ?? 
  
INSERT INTO ARTISTE VALUES (51, 'p51', '1924-04-14', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (52, 'p53', '1924-04-15', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (53, 'p55', '1924-04-16', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (54, 'p57', '1924-12-31', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (55, 'p59', '1925-01-01', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (56, 'p61', '1925-01-14', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (57, 'p63', '1925-02-28', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (58, 'p65', '1926-??-15', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (59, 'p67', '1926-01-??', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (60, 'p68', '1926-??-??', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (71, 'p71', '1912-04-17', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (73, 'p73', '1912-04-16', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (75, 'p73', '1912-04-15', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (77, 'p75', '1912-04-14', '????-??-??') ;   
INSERT INTO ARTISTE VALUES (80, 'p80', '1912-04-14', '2012-05-01') ;   
INSERT INTO ARTISTE VALUES (81, 'p81', '1912-04-14', '2012-05-??') ;
INSERT INTO ARTISTE VALUES (82, 'p82', '1912-04-14', '2012-??-31') ;   
INSERT INTO ARTISTE VALUES (83, 'p83', '1912-04-14', '2012-04-??') ;   
INSERT INTO ARTISTE VALUES (84, 'p84', '1912-04-14', '2012-04-15') ;   
INSERT INTO ARTISTE VALUES (85, 'p85', '1912-04-14', '2012-04-14') ;   
INSERT INTO ARTISTE VALUES (86, 'p86', '1912-04-14', '2012-04-13') ;   
INSERT INTO ARTISTE VALUES (87, 'p87', '1912-04-14', '2012-03-??') ;   
INSERT INTO ARTISTE VALUES (88, 'p88', '1912-04-14', '2012-03-31') ;

Calcul de l’âge des artistes au 15 avril 2012 :

Code SQL :

1
2
SELECT PsnId, DateNaiss, '2012-04-15' AS 'Aujourd''hui', dbo.AGE_PERSONNE(DateNaiss, '2012-04-15') AS Age
FROM   ARTISTE ;

=>

Quand il y a un doute, la fonction valorise l’âge à '??' , mais si une date est incomplète, on détermine malgré tout l'âge quand c'est faisable.

Certains artistes n’on pas encore soufflé leur 1re bougie...

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
PsnId DateNaiss   Aujourd'hui Age
1     2012-04-16  2012-04-15  0   
3     2012-04-15  2012-04-15  0 
5     2012-04-14  2012-04-15  0 
7     2012-??-15  2012-04-15  0        
9     2012-04-??  2012-04-15  0    
10    2011-05-01  2012-04-15  0 
11    2011-05-??  2012-04-15  0   
12    2011-??-16  2012-04-15  ??     
13    2011-04-16  2012-04-15  0         
14    2011-04-??  2012-04-15  ??  
15    2011-04-15  2012-04-15  1    
17    2011-04-14  2012-04-15  1
18    2011-03-??  2012-04-15  1
19    2011-03-31  2012-04-15  1  
20    2010-05-01  2012-04-15  1
21    2010-05-??  2012-04-15  1 
22    2010-04-16  2012-04-15  1 
23    2010-04-??  2012-04-15  ?? 
24    2010-04-15  2012-04-15  2 
25    2010-04-14  2012-04-15  2 
27    2012-??-16  2012-04-15  0  
29    2012-04-??  2012-04-15  0 
31    2011-??-16  2012-04-15  ??
33    2011-??-15  2012-04-15  ?? 
35    2011-??-14  2012-04-15  ?? 
51    1924-04-14  2012-04-15  88  
52    1924-04-15  2012-04-15  88   
53    1924-04-16  2012-04-15  87 
54    1924-12-31  2012-04-15  87 
55    1925-01-01  2012-04-15  87 
56    1925-01-14  2012-04-15  87 
57    1925-02-28  2012-04-15  87    
58    1926-??-15  2012-04-15  ??
59    1926-01-??  2012-04-15  86  
60    1926-??-??  2012-04-15  ?? 
71    1912-04-17  2012-04-15  99  
73    1912-04-16  2012-04-15  99   
75    1912-04-15  2012-04-15  100  
77    1912-04-14  2012-04-15  100  
80    1912-04-14  2012-04-15  100    
81    1912-04-14  2012-04-15  100  
82    1912-04-14  2012-04-15  100   
83    1912-04-14  2012-04-15  100  
84    1912-04-14  2012-04-15  100  
85    1912-04-14  2012-04-15  100    
86    1912-04-14  2012-04-15  100          
87    1912-04-14  2012-04-15  100     
88    1912-04-14  2012-04-15  100

Calcul de l’âge de l’artiste à son décès :

Code SQL :

1
2
SELECT *, dbo.AGE_PERSONNE(DateNaiss, DateDeces) AS AgeDeces
FROM   ARTISTE

Etc.

Dans tout ça, il doit rester quelques fonctions à mettre en œuvre, cette approche n’est pas la meilleure à cause de la programmation, mais bon...

[Richard_35]

Bonjour Fsmrel (et à tous ceux qui suivent),

Pourrais-tu donner ton avis sur le sujet évoqué par Franck dans le post #13, commenté par le post #15 ?

Merci d'avance de tes observations.

[fsmrel]

Bonsoir,

Envoyé par Richard_35

Pourrais-tu donner ton avis sur le sujet évoqué par Franck dans le post #13, commenté par le post #15 ?
Merci d'avance de tes observations.

On commence par modéliser au niveau conceptuel (MCD Merise, diagramme de classes UML, etc.), c'est-à-dire qu’on s’intéresse au quoi et pas au comment. C’est seulement au niveau physique que l’on fait mention des index et autres raffinements turbotiques (qui par parenthèses ne sont pas non plus l’objet de la norme SQL). Quand un projet échoue et doit être repris à son début, ça n’est pour des raisons de tuyauterie, mais parce que les règles de gestion sont notablement incomplètes et/ou que la modélisation est approximative. En tout cas, c’est mon constat depuis que j’ai commencé (au début des années soixante-dix) à pratiquer l’audit et le sauvetage des bases de données, qu’elles soient de type hiérarchique, réseau, liste inverse ou SQL, et ce dans tous les secteurs d’activité.

Parler d’index, construction physique populaire s’il en est, à l’occasion de la recherche d’une solution conceptuelle est parfaitement incongru. Chaque éditeur de SGBD offre ses solutions quant à la technologie ès matière, évoluant au fil des versions et releases. Qu’Oracle et PostgreSQL permettent d’obtenir des gains en n’indexant pas les marques nulles, soit, mais ça me fait une belle jambe quand j’utilise DB2 for z/OS qui indexe tout (je ne suis plus guère les évolutions de ce SGBD, aussi serait-il préférable de demander confirmation dans le forum DB2, je pense que quelqu’un comme Luc Orient se fera un plaisir de donner toute information utile...) Quoi qu’il en soit, baser sa modélisation — voire tout miser — sur une possibilité offerte par tel SGBD et pas tel autre est non seulement choquant, mais c’est en plus un truc à s’en rendre prisonnier. Par exemple, une machine base de données « massivement parallèle » comme Teradata où l’on parallélise à mort pour exploiter sa technologie YNET et ses UPI (unique primary index), offre des possibilités qu’on ne retrouve pas ailleurs mais qui peuvent nous ligoter (j’ai donné).

Maintenant, rien n’empêche (et c’est même recommandable) de mettre en œuvre un prototypage des performances en parallèle avec la conception, en amont des développements, pour apprécier l’efficacité de la future base de données en relation avec le palmarès des requêtes que l’on saura être les plus sensibles (prise de commande, appel des cotisations ...), de comparer les résultats et de faire part des conclusions à la Production, aux Études, à la Maîtrise d’œuvre, sans oublier son cheval (of course). Cela dit, élever au rang de quasi paradigme une technique susceptible d’être frappée d’obsolescence suite à des évolutions décisives n’est pas une très bonne chose. Quand on voit la performance des disques SSD (temps d’accès divisé par un facteur de l’ordre de 100 d'après ce qu’on lit), on peut commencer à rêver, regarder de plus près, même si aujourd’hui la technologie SSD coûte cher (mais souvenez-vous du prix des écrans plats il y a 15 ans) et n’est pas mature, comme le font observer SQLpro et mikedavem. Qu’en sera-t-il dans cinq ans, dix ans ?

[fsmrel]

Richard,

Vous m’avez demandé mon avis, mais il n’a pas l’air d’être partagé par tous !

[Richard_35]

Bonsoir Fsmrel,

Envoyé par Fsmrel

Vous m’avez demandé mon avis, mais il n’a pas l’air d’être partagé par tous !

==> peut-être, mais il est éminemment respectable.

L'argument est donc qu'il vaut mieux se placer "au niveau le plus bas", ne sachant pas la capacité d'un SGBD à indexer les NULL. "Qui peut le plus, peut le moins", en quelque sorte. En conséquence, en limitant les NULL, cela ne dérange pas les SGBD qui ne les indexent pas, et arrange bien ceux qui les indexent.

Comme il très difficile de connaître, dans le détail, tous les SGBD, l'argument se tient.

Il est vrai que si, pour une raison ou pour une autre, la base de données de Franck (qui n'indexent pas des NULL) doit être migrée vers un autre SGBD (qui indexe les NULL), alors il y aura une perte d'efficacité.

Néanmoins, je reste persuadé qu'il y a un équilibre à trouver : créer une table spécifique à chaque fois qu'il y a risque d'un champ NULL, me paraît être un excès. En revanche, si ce champ est une clé étrangère, cela peut être judicieux.

[fsmrel]

Envoyé par Richard_35

Créer une table spécifique à chaque fois qu'il y a risque d'un champ NULL, me paraît être un excès.

On est bien d'accord. Ainsi, dans la proposition que j’ai faite, il n’y a qu’une table (ARTISTE), l’attribut DateNaiss n’est pas morcelé (mais Null en est absent). On verra bien du reste ce qu’en pense CinePhil...

Maintenant, je vous soumets un sujet de méditation concernant la modélisation. Null signifie « information absente », mais ceci est trop générique et en creusant un peu on peut percevoir une grande différence quant au motif de cette absence selon la situation. Ainsi, dans le cas de la date de naissance de l’artiste, si l’information est absente c'est parce qu’on n’en a pas connaissance, mais le jour où elle est connue, on complète et on met à jour la base de données : l'utilisation de la date de naissance est applicable à tout artiste (c'est pourquoi je n'avais pas de raison d'évacuer l'attribut Datnaiss de la table ARTISTE). En revanche, si dans la table des opérations le numéro de chèque est absent, c’est parce que — du point de vue de la modélisation — l’information est en l’occurrence inapplicable (par hypothèse un chèque n’a pas à être associé à un crédit). La présence du numéro de chèque dans le cas des opérations de crédit étant pour le moins suspicieuse (euphémisme), il est légitime de refuser de modéliser un mariage contre nature...

[dba01]

@ pachot : non ce n'était pas qu'un simple report à nouveau, c'était plus compliqué que ça.
Enfin, passons.

La question était de voir si la fonction "date" dont on a l'habitude n'était pas trop contraignante, et s'il ne valait pas mieux, parfois, gérer la chose en numérique afin d'avoir d'autres possibilités. Les exemples sont nombreux, comme la cathédrale du XIIe siècle, les dates de naissance aux environs de..., les 14 mois de l'année, les péremptions au delà du...
Je ne vois pas un historien se contenter d'un ordinateur qui commencerait à compter à partir de 1900. Et les historiens astronomes préfèrent le calendrier Julien qui porte sur 7000 ans environ. Quant aux préhistoriens ou archéologues !...

Mais hélas ces particularités sont à programmer par chacun car il n'existe aucune fonction préfabriquée en la matière.
Donc : ne pas se contenter systématiquement de la fonction Date-Heure définie par les éditeurs.


Autre problème : la notion de débit/crédit ne doit jamais s'inscrire sous la forme +/-. Ne pas signer les sommes. D'une part, il existe des systèmes (USA) dans lesquels le crédit porte le signe moins, et le débit le signe plus. D'autre part, j'ai déjà eu à gérer des débits tombant sur des comptes créditeurs, et d'autres sur des comptes débiteurs, etc... Résultats : quatre colonnes d'utilisations différentes. Autant prévoir dès la conception, pour permettre les évolutions sans révolutions.

PS : comme disait un collègue : "quand la paye arrive, le solde de mon compte diminue".

[Richard_35]

Bonjour à tous,

Envoyé par fsmrel

Maintenant, je vous soumets un sujet de méditation concernant la modélisation. Null signifie « information absente », mais ceci est trop générique et en creusant un peu on peut percevoir une grande différence quant au motif de cette absence selon la situation.

==> exact. Et il est intéressant de creuser le "pourquoi" d'un attribut pouvant être NULL : de là, pourra découler la création d'une entité à part entière ou pas.

Concernant une quelconque entité :

une Date de naissance
Nous sommes certains que cette information existe, mais nous ne la connaissons pas et elle peut être renseignée dès que nous en avons pris connaissance. Cette date n'a pas de vie propre.

un Numéro de chèque
Un chèque peut exister, mais nous ne connaissons pas encore son n°, ou bien, ce chèque n'existe pas. Ce n° peut avoir une vie propre.

une Observation
Un utilisateur peut estimer qu'il est judicieux de saisir une observation quelconque dans un cas, alors que, dans un autre cas, cela ne présente aucun intérêt (obliger à saisir une observation serait absurde). Cette observation n'a pas de vie propre.

La notion de "vie propre" est une notion qui pourrait faire pencher la balance du côté de la chasse au NULL.

[CinePhil]

Tout ceci est décidément très intéressant !

En lisant ta proposition François, je me disais que ça donnait des traitements bien lourds pour de simples dates mais comme c'est pour un (relativement) petit projet personnel, j'ai bien envie de l'essayer... quand j'en trouverai le temps.

Je me mets derrière l'oreille aussi le cas des observations ou autres commentaires facultatifs. Dans le premier modèle que j'avais fait, presque toutes mes tables avaient une colonne nullable pour les commentaires. Par exemple, pour signaler que Julie Depardieu est la fille de Gérard ou que Studio Magazine et ciné Live ont fusionné pour devenir Studio Ciné Live ou que "Apocalypse Now" a eu la Palme d'or à Cannes ex-aequo avec "Le Tambour"...

Je sens que ça va encore ajouter des tables à mon modèle cette histoire !

============

L'autre sujet à l'origine de cette discussion concernait aussi la modélisation du nom des artistes. J'ai relu la semaine dernière la partie de la discussion qui y est consacrée mais je reste hésistant quant à la solution.

D'autres avis sont les bienvenus.

[fsmrel]

Bonsoir,

Envoyé par Richard_35

La notion de "vie propre" [...]

C’est dans les vieilles marmites qu’on fait les meilleures soupes : en 1979, Ted Codd et Yannis Vassiliou (dont je n’ai pas l’article, mais qui est référencé par Codd dans Extending the Database Relational Model to Capture More Meaning) ont traité des deux types d’absence de l’information : applicable et inapplicable (cf. ce que j’ai rapidement évoqué à ce sujet). Pour ma part, suite aux écrits de Codd de 1990 (The Relational Model for Database Management: Version 2) ça fait plus de 20 ans que j’utilise ces termes qui d'ailleurs ont suscité pas mal de littérature et de polémiques (problème de la mise en œuvre de la logique quadrivalente, mais qui sort de notre champ). Quoi qu'il en soit, je vous propose de les utiliser à votre tour, d’autant que Date de naissance, Numéro de chèque, Observation ne sont pas à proprement parler des entités, mais font plutôt l’objet d’attributs d’entité et ne sont donc pas autonomes, n’ont pas de vie propre. Façon Boileau, qu’un numéro de chèque puisse faire l’objet d’un marqueur de type inapplicable pour l’attribut NoCheque de la table OPERATION est à mon sens quelque chose qui se conçoit bien et les mots pour le dire me viennent (assez) aisément : « applicable ! », « inapplicable ! » sont des mots un peu longs, mais qui claquent quand même et qu’on n’oublie pas.
Comme dirait : évitons les périphrases, droit au but !

[fsmrel]

Bonsoir Philippe,

Envoyé par CinePhil

En lisant ta proposition François, je me disais que ça donnait des traitements bien lourds pour de simples dates.

Ce sont des dates un peu sophistiquées quand même, puisque lorsqu’elles sont incomplètes, elles peuvent malgré tout servir à calculer des valeurs exactes. Par exemple, si l’on sait seulement qu’Oscar Kardekopek est né en mars 1912 et mort en avril 2012, selon la fonction AGE_PERSONNE il est mort sans ambiguïté à 100 ans. La fonction pourrait du reste être aménagée pour répondre au cas où l’on ne connaît que les années de ces dates (1912 et 2012 en l’occurrence), qu’il est mort à 99 ou 100 ans...

En tout état de cause, la fonction AGE_PERSONNE peut être réutilisée pour plein de contextes, à condition de respecter la structure imposée par la fonction Est_Valide_Date (à laquelle AGE_PERSONNE fait appel)...

Envoyé par CinePhil

Je me mets derrière l'oreille aussi le cas des observations ou autres commentaires facultatifs.

Tout comme la date de naissance des personnes, les observations et commentaires sont à ranger dans la catégorie des informations du type applicable : pas de table dédiée.

La structure de la table ARTISTE ci-dessus devient par exemple la suivante :

Code sql :

1
2
3
4
5
        PsnId               INT              NOT NULL
      , PsnNom              VARCHAR(64)      NOT NULL
      , DateNaiss           CHAR(10)         NOT NULL
      , DateDeces           CHAR(10)         NOT NULL
      , Observation         VARCHAR(254)     NOT NULL DEFAULT ''

Insertion d’une ligne pour laquelle il n’y a pas d’observation :

Code sql :

1
2
INSERT INTO ARTISTE (PsnId, PsnNom, DateNaiss, DateDeces) 
       VALUES (1,  'p01', '2012-04-16', '????-??-??') ;

Insertion d’une ligne pour laquelle il y a une observation :

Code sql :

1
2
INSERT INTO ARTISTE (PsnId, PsnNom, DateNaiss, DateDeces, Observation) 
       VALUES (3,  'p03', '2012-04-15', '????-??-??', 'Oscar Kardekopek est cousin de Balthazar Picsou') ;

Ce scénario vous convient-il ?

[CinePhil]

Oui, le NOT NULL DEFAULT '' me plaît assez.

Je reste par contre indécis quant au nom d'artiste et nom réel.

Envoyé par CinéPhil

2) Plus compliqué peut-être : les noms.
Si j'ai, dans ma table actuelle, séparé les noms et prénoms réels et publics, c'est parce que certains artistes sont connus sous un pseudonyme. Détail qui complique encore la chose, certains pseudonymes sont composés d'un nom et d'un prénom (Marylin Monroe) et d'autres seulement d'un nom (Arletty, Miou-Miou).

Alors quoi mettre dans la table des personnes et quoi mettre dans une table séparée ?

Première solution : Sortir le nom réel.
Les artistes sont connus sous leur nom d'artiste, figurant au générique des films, que ce nom soit leur nom réel ou un pseudonyme.

MCD :
personne -0,1----avoir----(1,1)- nom_reel

Mais si je sépare le nom et le prénom dans les deux tables résultant de ces deux entités types, je peux de nouveau voir apparaître le bonhomme NULL, par exemple pour Miou-Miou qui n'a pas de prénom dans son nom d'artiste.
"Ben, t'as qu'à faire une seule colonne pour le nom d'artiste qui contiendra le nom et le prénom !
- Oui mais, quand je vais vouloir afficher une liste d'artistes, j'aimerais que Marilyn Monroe soit classée à Monroe et pas à Marylin !"
Il y aurait la solution d'écrire dans cette colonne unique "Monroe (Marylin)" et de reconstituer par programme le joli nom de "Marylin Monroe" lors de la présentation de la donnée, mais je trouve ça un peu moyen comme solution et pas très naturel à la saisie... bref, j'aime pas trop.

Deuxième solution : Sortir le pseudonyme.
Le nombre d'artiste ayant un pseudonyme est relativement faible. On pourrait alors suivre la majorité et externaliser les quelques fantaisistes qui ne sont pas assez fiers de leur patronyme !

MCD :
personne -0,1----avoir----(1,1)- pseudonyme

Les problèmes soulevés précédemment sont là aussi présents (prénom optionnel) auquel s'ajoute le fait que je ne connais pas forcément le nom réel de certains artistes à pseudonyme, ce qui reviendrait à avoir des anonymes dans la table des personnes !

==================

État de ma réflexion pour le moment...

1) Dans la table des artistes, une colonne pour le nom d'artiste en entier tel qu'on le donne habituellement (Arletty, François Truffaut, Gérard Depardieu, Louis De Funes, Miou-Miou...) et une colonne pour le classement (Arletty, De Funes Louis, Depardieu Gérard, Miou-Miou, Truffaut François...).
Ça fait redondance de données mais je ne vois pas comment faire autrement pour le classement.

2) Une table des vrais noms identifiée relativement à la table des artistes avec une colonne nom et une colonne prénom.

En même temps, je me dis que je m'embête peut-être pour pas grand chose avec cette histoire de classement, surtout pour une application personnelle. Je réfléchis à l'ancienne en pensant à mes (environ) 10 000 fiches Bristol accumulées successivement par mes frères et moi-même depuis les années 1970 et classées par ordre alphabétique dans des tiroirs, ou à mes deux classeurs de filmographies, classées elles aussi dans l'ordre alphabétique du nom d'artiste sans tenir compte de l'éventuel prénom d'artiste.

Avec les outils informatiques modernes, si je cherche Gérard Depardieu, je commence à taper "Depar" dans une zone de saisie à auto-complétion et j'aurai probablement la famille Depardieu qui apparaîtra. Il est peut-être peu probable que je cherche une personne par un système de lettres cliquables, comme si je cherchais un mot à la lettre D du dictionnaire.

À suivre...

[Richard_35]

Bonjour Fsmrel et CinePhil,

Merci, de ta réponse, Fsmrel, je ne connaissais pas les termes "applicable" et "inapplicable" dans ce contexte.

D'autre part, personnellement, je préfère (syntaxe NUMERIC() à vérifier, mais bon, nous sentons l'esprit) :

Code :

1
2
3
4
5
6
7
8
9
        PsnId               INT              NOT NULL
      , PsnNom              VARCHAR(64)      NOT NULL
      , DateNaiss_J         NUMERIC(2)
      , DateNaiss_M         NUMERIC(2)
      , DateNaiss_A         NUMERIC(4)
      , DateDeces_J         NUMERIC(2)
      , DateDeces_A         NUMERIC(2)
      , DateDeces_M         NUMERIC(4)
      , Observation         VARCHAR(254)     NOT NULL DEFAULT ''

à

Code :

1
2
3
4
5
        PsnId               INT              NOT NULL
      , PsnNom              VARCHAR(64)      NOT NULL
      , DateNaiss           CHAR(10)         NOT NULL
      , DateDeces           CHAR(10)         NOT NULL
      , Observation         VARCHAR(254)     NOT NULL DEFAULT ''

En effet, il me semble préférable de concaténer J/M/A en format "date" quand on en a besoin, que de dé-concaténer (avec exclusion du caractère "-"). Mais bon, sur ce point particulier, les deux solutions comportent des avantages et des inconvénients : il n'y a donc pas de vérité universelle...

[dba01]

J'ai aussi eu des problèmes avec un outil de fabrication US qui était au format MM-JJ-AAAA au lieu du JJ-MM-AAAA Européen.
Tandis que le format AAAAMMJJ se manipule sans utiliser la notion de date. Je l'ai même vu dans des prgrammes publiques.