Discussion :

[escartefigue]

Bonsoir,

Qu'est ce que c'est que ces cardinalités du sous-type vers le sur-type
un sous-type correspond obligatoirement à un et un seul sur-type !

[CinePhil]

Si j'ai bien compris la question, ça devrait être 0,1 côté item.

[noals]

@escartefigue Oui, je n'ai pas trop compris non plus.
@CinePhil Ok, ben j'ai mis ça, je verrais bien.

Je laisse une cardinalité relative coté weapon, armor, usable ?

Et y a-t-il des options particulières que je dois mettre pour la conversion ?
J'ai encore quelques avertissements avec le test d'intégrité mais je ne comprends pas trop pourquoi car c'est pour deux contenant de type TRUC1 - 0,n -- 1,1 - CONTENANT - 1,1 -- 0,n - TRUC2 donc je verrai aussi plus tard avec le MLD.

[CinePhil]

Je laisse une cardinalité relative coté weapon, armor, usable ?

Logiquement, oui.

Pour le reste, je ne sais pas ; ça fait des années que je ne suis pas servi de Open Modelsphere et il a dû changer de version depuis.

[noals]

J'essaierai, je verrai bien.

[noals]

Ça m'a l'air pas trop mal pour l'instant, j'ai du oublier des paramètres ou j'ai peut-être ajouté trop de type d'entité mais c'est un peu trop abstrait pour moi, je rectifierai tout ça quand j'aurai vu ce que ça donne après avoir ajouté des données à la base.

J'ai essayé de générer la base de données pour voir et modelsphere génère bien les tables avec clés primaires et secondaires mais il ne génère pas les autres paramètres.
Comment faut-il faire pour qu'ils soient aussi générés avec le fichier.sql ?

[CinePhil]

Quels autres paramètres ?

[noals]

Je veux dire les autres colonnes dans mes tables qui ne sont pas des clés.
Par exemple, modelsphere va générer la table item avec item_id et les clés secondaires mais il ne va pas mettre item_name, description, ou autre paramètres que j'ai mis dans la table item.

[CinePhil]

Ça, ce n'est pas normal !

On peut voir la description d'une table qui n'a pas toutes les colonnes en SQL ?

[noals]

J'ai ce genre de truc.
Ça génère le sql pour les contraintes et les clés secondaires mais rien d'autre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
***********************************************************
    Génération
    Plugiciel : Moteur pour la génération de DDL ANSI (3.2.0 - 05-12-2009), Grandite

    Nom de la base de données : "Base de données"
    Fichier source : "F:\modelsphere\MazeFighters_bkp4.sms"

    Généré le : 4 avr. 2019 13:03:03
    Généré par Open ModelSphere Version 3.2"
***********************************************************


***********************************************************
    CREATE STATEMENTS
***********************************************************


ALTER TABLE item 
  ADD CONSTRAINT Clé primaire / unique PRIMARY KEY (
    item_type i_type_id, item_id)  ;
ALTER TABLE weapon 
  ADD CONSTRAINT Primary Key PRIMARY KEY (
    item item_type i_type_id, item item_id, weapon_type w_type_id)  ;
ALTER TABLE armor 
  ADD CONSTRAINT Primary Key PRIMARY KEY (
    item item_type i_type_id, item item_id, armor_type a_type_id)  ;
ALTER TABLE usable 
  ADD CONSTRAINT Primary Key PRIMARY KEY (
    item item_type i_type_id, item item_id, usable_type u_type_id)  ;
ALTER TABLE weapon_type 
  ADD CONSTRAINT Primary Key PRIMARY KEY (
    w_type_id)  ;
ALTER TABLE armor_type 
  ADD CONSTRAINT Primary Key PRIMARY KEY (
    a_type_id)  ;
ALTER TABLE usable_type 
  ADD CONSTRAINT Primary Key PRIMARY KEY (
    u_type_id)  ;
ALTER TABLE item_type 
  ADD CONSTRAINT Primary Key PRIMARY KEY (
    i_type_id)  ;


...


ALTER TABLE item
  ADD 
    FOREIGN KEY (item_type i_type_id)
      REFERENCES item_type;

ALTER TABLE item
  ADD 
    FOREIGN KEY (element_type element_id)
      REFERENCES element_type;

ALTER TABLE item
  ADD 
    FOREIGN KEY (sprite sprite_type sprite_type_id, sprite sprite_id)
      REFERENCES sprite;

ALTER TABLE weapon
  ADD 
    FOREIGN KEY (item item_type i_type_id, item item_id)
      REFERENCES item;

ALTER TABLE weapon
  ADD 
    FOREIGN KEY (weapon_type w_type_id)
      REFERENCES weapon_type;

ALTER TABLE armor
  ADD 
    FOREIGN KEY (item item_type i_type_id, item item_id)
      REFERENCES item;

ALTER TABLE armor
  ADD 
    FOREIGN KEY (armor_type a_type_id)
      REFERENCES armor_type;

ALTER TABLE usable
  ADD 
    FOREIGN KEY (item item_type i_type_id, item item_id)
      REFERENCES item;

ALTER TABLE usable
  ADD 
    FOREIGN KEY (usable_type u_type_id)
      REFERENCES usable_type;

[noals]

En même temps c'est pas grave, ça m'aidera quand même.
Je me pose plus de questions sur la notion de calcul dans la base de données.

Est-ce que je peux automatiser une contrainte "addition" ou autre d'une table à une autre ?
Par exemple, est-ce que je peux automatiquement faire que quand l'armure et les bottes sont équipées, leurs valeurs de défense soient ajoutées et que cette valeur soit stocké autre part dans la base de données ?

[CinePhil]

Quand je disais que j'aimerais voir la description de la table, je pensais plutôt à la description visuelle dans le logiciel, sur le MCD ou le MLD. Parce que voir le résultat annoncé comme problématique n'apporte pas grand chose ; j'avais compris le problème !

En principe, on ne stocke pas de calcul dans une base de données, sauf pour un besoin de conservation du calcul si des paramètres peuvent changer ou d'archivage.

Là, s'il s'agit de calculer à l'instant t la puissance d'attaque du personnage, pas besoin de le stocker, le calcul se fait en live. Sauf si vous voulez enregistrer l'historique du combat : à l'instant T, le personnage P avait la puissance d'attaque A (qui a été calculée à l'instant T).

[noals]

Disons que je voulais simplifier les calculs grâce à la base de données un peu à la manière d'excel.
Pendant le combat j'aurai besoin de la valeur de défense d'un personnage par exemple et un personnage ne va pas changer d'équipement ou de statistique pendant chaque combat donc j'aurai voulu une valeur intermédiaire comme ça, à chaque combat, plutôt que de recalculer la défense de base du joueur à chaque début de combat en fonction de ses stats et équipements (qui changent plus rarement) pour ensuite ajouter à l'algo les effets divers propre au combat, j'ai une valeur de défense pré-calculé qui simplifie l'algo.
N'a-t-il pas moyen de faire ça avec la base de données ?

Et pendant que j'y suis, qu'est-ce qu'une règle référentielle et à quoi sert-elle ?

Voilà ce que ça donne dans modelsphere.


Et pendant la génération, il met ça avec tous des points d'interrogation, je ne sais pas trop à quoi ça correspond, j'ai l'impression que je dois tous définir plusieurs fois mais je ne sais pas trop où.

[noals]

Quand je disais que j'aimerais voir la description de la table, je pensais plutôt à la description visuelle dans le logiciel, sur le MCD ou le MLD. Parce que voir le résultat annoncé comme problématique n'apporte pas grand chose ; j'avais compris le problème !

Bonjour, sur le coup, j'ai du mal comprendre, je pense que tu parlais du panneau de paramètre d'une table dans modelsphere mais à part les colonnes, je n'y ai rien ajouté.
Le nom physique, alias, super-table ou autre, ça ne me parle pas du tout.

Mais je vais laissé tomber modelsphere ou autre logiciel pour le sql je pense. C'est déjà très pratique pour avoir un visuel de ce que l'on fait, ça me sera surement utile à ça et ça peut l'être aussi pour pour générer les tables d'un coup mais ça ne m'apprend pas grand chose sur les requêtes ou certains paramètres ou autres automations, et comme je débute pour ça aussi, je préfère faire les choses manuellement ne serait-ce que pour en apprendre d'avantage.

De toute façon, j'ai eu réponse à ma question, je comprends mieux la hiérarchie d'une base, merci.

[noals]

Bonjour,

je m'y suis remis doucement, je construit ma base de donnée manuellement avec l'aide de mon shéma et je me pose une question à propos d'un truc.
Est-ce que les double foreigh keys sont vraiment utiles et si oui, à quoi ?



par exemple ici, si avec sprite_id, je peux récupérer sprite_type_id, pourquoi avoir le deux dans mon autre table ?

merci.

[fsmrel]

Bonsoir,

Est-ce que les double foreign keys sont vraiment utiles et si oui, à quoi ?

Vous n’avez pas des clés étrangères (foreign keys) en double, mais une clé étrangère composée de deux attributs (dont les noms mériteraient d’être raccourcis...) :

FK1 = {sprite_sprite_type_sprite_type_id, sprite_sprite_id}

Selon votre diagramme (qui est un morceau de votre MLD), la table SPRITE est identifiée relativement à la table SPRITE_TYPE (cardinalités soulignées 1,1 pour la patte connectant ces tables), donc (j’abrège les noms...) la table SPRITE a nécessairement pour clé primaire {sprite_type_id, sprite_id}. Comme une clé étrangère fait référence à une clé primaire, il est normal que la table ELEMENT_TYPE hérite à son tour des deux colonnes, puisqu’elle référence la table SPRITE.

Au plan sémantique (donc dans le MCD), utiliser l’identification relative signifie que l’entité-type SPRITE n’est vue que comme une propriété multivaluée de l’entité-type SPRITE_TYPE, tout comme une ligne de facture est vue comme une propriété multivaluée d'une facture. Dans votre cas, une telle perception serait étonnante (ce que confirme votre interrogation...) : pour que les choses rentrent dans l’ordre, n’identifiez pas SPRITE relativement à SPRITE_TYPE, en conséquence de quoi la clé primaire de SPRITE se résumera à {sprite_id} et il en ira de même pour la clé étrangère FK1.

[noals]

Je présume que c'est ce genre d'erreur qu'il faut corriger après le passage du MLD au MCD selon tel ou tel logiciel alors.
Si je comprends bien votre raisonnement sur le plan sémantique, SPRITE_TYPE ne devrait-il pas avoir cette clé primaire à deux paramètres ?
Dans quelles mesures l'utilisation d'une clé primaire à deux paramètres est pertinente ?

Merci.

[escartefigue]

Bonsoir Noals,

Les premières qualités d'une PK sont d'être à la fois stable et concise.

Stable : la valeur ne doit jamais changer, en effet, la PK se propage dans de nombreuses tables liées et, via les contraintes d'intégrité, la modification d'une valeur de PK, unique donc par définition, peut modifier en cascade des milliers, voire des centaines de milliers de lignes dans les tables en relation. Vous imaginez aisément le coût d'une telle cascade de mise à jour dans une base de données.
Pour éviter ce genre de souci, on choisit en général une clef technnique, asémantique et attribuée par le SGBD (il s'agit selon le SGBD d'identity column, de séquence ou d'auto-incrément)
Dans tous les cas, on fuira comme la peste toute colonne fonctionnelle lors du choix de la PK

Concise : la PK est très souvent utilisée comme critère de jointure. Si la PK est concise, la CPU pourra vérifier les jointures facilement, si au contraire cette PK est longue, la CPU sera plus fortement sollicitée.
Ca tombe bien, les pk techniques attribuées par les SGBD sont de type integer, c'est le type le plus performant et le plus concis.

Concernant les PK multi-colonnes (plutôt que multi-paramêtres ), ça dépend

Pour le cas le plus général, une PK mono-colonne et donc qui s'appuie sur un identifiant technique attribué par le SGBD, est la meilleure solution.
Mais, dans le cas de l'identification relative, il en va autrement.

Prenons le cas classique d'une facture et de ses lignes.
On a le MCD suivant (une facture contient au moins une ligne, et une ligne est contenue par une et une seule facture ) :

FACTURE 1,n --- contenir ---(1,1) LIGNE_FACTURE

La ligne est une entité-type dite "faible". En effet, elle n'existe que si la facture existe, elle en est une émanation.
Au niveau conceptuel, cela se matérialise par les parenthèses autour des cardinalités coté ligne, ou par des cardinalités soulignées (tout dépend du logiciel de modélisation)
Au niveau tabulaire, la conséquence est que la table issue de l'entité-type faible, ici donc la table LIGNE_FACTURE, aura pour PK l'identifiant de la facture + l'identifiant de la ligne, soit deux colonnes.

De ce fait, cette PK est moins concise qu'une PK mono-colonne, mais elle présente l'avantage, sous réserve de certains choix techniques au niveau des index, de permettre le stockage de toutes les lignes d'une même facture dans un espace contigu, au bénéfice des accès disques qui en sont réduits et donc des performances qui sont augmentées.
Cette stratégie présente également un intérêt certain avec les SGBD qui autorisent un verrouillage de niveau "page", car il y aura de fortes chances que toutes les lignes d'une même facture soient dans une même page ou dans des pages proches, ce qui limite les contentions avec les applications concurrentes.

Difficile d'expliquer toutes ces notions en quelques phrases, on rentre dans des considérations techniques relativement pointues et dont les explications détaillées dépendent en partie du SGBD, mais il faut retenir que l'identification relative, qui est par nature multi-colonne, est pourtant propice aux performances.

En résumé :
- cas général : privilégier une PK mono-colonne, de type id technique
- cas particulier de l'identification relative : l'identifiant est multi-colonne

[noals]

Ok, je vais faire au plus simple, je pourrais toujours modifier la db selon mes besoins ensuite.
Merci.