Forum Security-X > Programmation
Base de données Cours de rattrapage
labougie:
salut Xtrem,
Pour la clé secondaire, ben j'ai sans doute pas eu le bon terme :NNN.
--- Citer ---il faut éviter de créer des clés dites artificiels (un numéro client, numéro de magasin), il faut respecter le cahier des charges pour les attributs, si on ne te demande pas de mettre un ID n'en met pas (tu verras qu'on peut ajouter ce type de clé lorsqu'on crée le modèle physique, qui te donnera ton code SQL), sauf si tu es obligé.
--- Fin de citation ---
Pourquoi? c'est quand même plus simple d'identifier quelque chose ou quelqu'un par un n° unique.
Si il y a plusieurs Xtrem, pour les différencier, le N° de Sécu Social le fera, non!!!
--- Citer ---La clé étrangère te permet de lier des tables entre elles, c'est un truc que tu verras tout le temps.
--- Fin de citation ---
Cette clé étrangère, elle est donc dans la table principale (mère) puis dans la table (fille). C'est elle qui fait la liaison entre les deux, c'est bien cela?
Je vais regardé l'exo et poster ce soir ou demain un fichier xlsx.
Désolé si mon vocabulaire n'est pas encore précis :AAM
labougie
xtrem47:
Salut,
--- Citer ---
--- Citer ---il faut éviter de créer des clés dites artificiels (un numéro client, numéro de magasin), il faut respecter le cahier des charges pour les attributs, si on ne te demande pas de mettre un ID n'en met pas (tu verras qu'on peut ajouter ce type de clé lorsqu'on crée le modèle physique, qui te donnera ton code SQL), sauf si tu es obligé.
--- Fin de citation ---
Pourquoi? c'est quand même plus simple d'identifier quelque chose ou quelqu'un par un n° unique.
Si il y a plusieurs Xtrem, pour les différencier, le N° de Sécu Social le fera, non!!!
--- Fin de citation ---
Un peu trop simple même ;D
Non assez souvent tu peux te passer de clé artificielle, et lorsque tu le peux, fais-le.
Sinon oui, c'est tellement plus simple, souvent plus performant, ça t'évite d'avoir des clés étrangères sur plusieurs champs, que des avantages, mais ça ne représente rien, c'est artificiel, conceptuellement ça ne signifie rien. Est-ce que c'est grave de les utiliser systématiquement, non la plupart du temps, mais il va t'arriver d'avoir des clés naturelles (non artificielles) qui feraient très bien l'affaire comme clé primaire, ça fait doublons avec une clé artificielles que tu viendrais ajouter.
Je te laisse regarder : http://bdd.crzt.fr/rel/www/co/relUC022.html
--- Citer ---
--- Citer ---La clé étrangère te permet de lier des tables entre elles, c'est un truc que tu verras tout le temps.
--- Fin de citation ---
Cette clé étrangère, elle est donc dans la table principale (mère) puis dans la table (fille). C'est elle qui fait la liaison entre les deux, c'est bien cela?
--- Fin de citation ---
Oui, c'est une colonne (ou plusieurs) d'une table qui est utilisée pour faire référence à une colonne (ou plusieurs) d'une autre table, et ainsi cela crée un lien entre les tables. Je pense que ça sera plus clair après que tu ais vu les différents types d'associations et la cardinalité.
:AAC
labougie:
J'apprécie beaucoup la qualité de tes liens :AAN :AAN :AAN.
J'ai balbutié un modèle conceptuel de données (MCD), le vocabulaire rentre :NNN.
J'ai facilité mon travail en prenant des clés Artificielles, type Num_
Les attributs des entités sont normalement corrects, pas de doublon. Par contre, beaucoup de mal pour ficeler les associations.
En cherchant j'ai trouvé ce lien, très instructif aussi ==> http://cyril-gruau.ftp-developpez.com/ConceptionBD.pdf
C'est expliquer de façon encore plus simple que dans mes cours, j'arrive un peu mieux à me faire donc au vocabulaire.
Je n'arrive pas à représenter ceci
--- Citer ---- périodiquement, on veut obtenir la liste des retardataires; on veut pour chaque cassette non retournée à temps les informations suivantes : nom et adresse du client, date de l'emprunt, numéro(s) de cassette et titre du (des) film(s) concerné(s);
--- Fin de citation ---
La phrase est pourtant simple est hyper explicite, mais la mise en oeuvre, bien moins :hi:
labougie
Edit
J'ai retravaillé le MCD
dispo 21 jours
xtrem47:
Salut,
Pour cette phrase de l'énoncé j'en ais parlé dans une réponse plus haut, ne t'en préoccupe pas.
Ton lien a expiré. J'avais regardé vite fait ce matin, de ce que je me souviens, les flèches c'est uniquement pour l'héritage, n'oublie pas que tes associations sont dans les deux sens là, il en va donc de même pour la cardinalité, deux par association (sauf exception dont on parlera plus tard). Je n'ai pas compris ta logique avec les clés étrangères, par exemple si je me trompe pas pour adresse :
Dans la table tu me mets un id_adresse, un id_client et un id_magasin, ok pour l'ID adresse très bien, après il faut en effet que ta table adresse soit liée au client et au magasin, d'ailleurs tu pourras mettre ça en évidence avec les associations, par contre ID_client et ID_magasin n'ont rien à priori rien à faire dans la table adresse, je ne vois pas comment l'expliquer c'est simplement illogique, ce n'est pas ton adresse qui a un client ET un magasin, non, c'est un client qui a une adresse et un magasin qui a une adresse.
Donc tu aurais plutôt Adresse avec ID_adresse, dans client, ID_client et ID_adresse, dans magasin, ID_magasin et ID_adresse.
D'ailleurs tiens pour revenir sur les clés primaires et les clés artificielles, ID_magasin c'est bien, mais par exemple si tu as nom_magasin et adresse, ne pense-tu pas que ces deux attributs pourraient faire office de clé primaire ? (je connais pas deux magasins du même nom qui ont la même adresse :P) Je ne vois aucun problème à ce que tu utilises des clés artificiels mais il reste très important que tu comprenne bien la notion de clé, la facilité peut mener à l'incompréhension. Je verrais très bien un examen où on te donne des tables, et en première question "dans chaque table souligner la clé primaire".
J'avais aussi noté, pour Etat comme je te l'ai dis, vu l'énoncé il serait certainement bien vu que tu utilise une énumération, sauf si tu penses que dans le temps, on pourrait vouloir modifier (ajouter, modifier ou supprimer un type d'état) la table. A toi de voir.
Sinon ça me paraissait pas mal du tout :sup:
:AAC
Edit : j'avais pas vu ton edit, donc mes remarques concernent ce que tu avais posté hier soir.
labougie:
Bonsoir Xtrem,
--- Citer ---D'ailleurs tiens pour revenir sur les clés primaires et les clés artificielles, ID_magasin c'est bien, mais par exemple si tu as nom_magasin et adresse, ne pense-tu pas que ces deux attributs pourraient faire office de clé primaire ? (je connais pas deux magasins du même nom qui ont la même adresse :P) Je ne vois aucun problème à ce que tu utilises des clés artificiels mais il reste très important que tu comprenne bien la notion de clé, la facilité peut mener à l'incompréhension. Je verrais très bien un examen où on te donne des tables, et en première question "dans chaque table souligner la clé primaire".
--- Fin de citation ---
Si ton magasin et un nom d'enseigne nationale "Labougie Location". Chaque magasin porte donc le même nom, mais pas la même adresse, alors l'id_Magasin pourrait se construire de la sorte.
nombredemagasin_département cela donnant ceci:
* 0130 magasin 01 du département 30
* 0230 magasin 02 du département 30
* 0330 magasin 03 du département 30
* Etc... pour chaque magasins de chaque département
Voici la raison pour laquelle l'ID me semble important, ainsi, d'un simple coup d'oeil, l'on sait d'où provient le produit. Que cela soit pour mon exo ou pour mon cas de tout les jours (grosse enseigne internationale)
--- Citer ---J'avais aussi noté, pour Etat comme je te l'ai dis, vu l'énoncé il serait certainement bien vu que tu utilise une énumération, sauf si tu penses que dans le temps, on pourrait vouloir modifier (ajouter, modifier ou supprimer un type d'état) la table. A toi de voir.
--- Fin de citation ---
Que nommes tu une énumération? (une liste de choix dans un soft, mais ici c'est la même chose, mais comment m'y prendre).
Le lien avec les corrections suite à ton dernier post
labougie
Navigation
[#] Page suivante
[*] Page précédente
Sortir du mode mobile