Discussion :

[elgafsi86]

Bonjour mes amis,
J'ai des questions différentes sur les BD que je voudrais que vous me clarifiiez. Choisir le(s) bonne(s) réponse(s)
1)Une requête à une BD sert à:
*supprimer des informations dans cette base
*faire un trigger

2)Lorsqu'on manipule une BD,on manipule:
*des tables
*des requêtes

3)Un clé primaire sert à:
*enregistrer une BD
*identifier les informations pour pouvoir les retrouver

4)Une BD est:
*ensemble organisé et structuré d'info portant sur le même thème
*un plan de classement de l'information

5)Un enregistrement correspond à:
*un programme nécessaire pour utiliser une BD
*l'ensemble des caractéristique d'un élément du tableau

6)Une BDR est une BD structuré :
*sous forme de tableau
*sous forme de ligne et de colonnes
suivant les principes de l'algèbre relationnelle
*en tenant compte des relations entre les tables

7)les tables d'une BDR possèdent un certain nombre de colonnes permettant de décrire des éléments appelés :
*n-uplets
*lignes
*tuples
*enregistrement
(QUEL est la différence entre n-uplets et tuple????)

8)La non duplication(absence de redondance ) des éléments dans une table d'un BDR est assurée par le SGBDR à l'aide du contrainte de type:
*clé primaire
*clé étrangère
*clé subrogée
*marqueur NOT NULL

9)Dans un contexte d'une BDR,une jointure naturelle(ou équijointure peut se faire entre 2 tables dont la qualification est une égalité entre les valeurs de 2 colonnes(une de chaque table)de:
*même type
*même type et même nom
*même type et des noms différents
*même nom indépendamment du type

10)Un clé primaire sert à:
*définir d'une manière unique une ligne
*pour identifier un enregistrement
*éviter d'avoir 2 lignes semblables dans une table

11)Dans une requête SQL,La clause distinct sert:
*enlever les répétitions
*ne pas répéter la même ligne
*sélectionner les sorties colonne par colonne

Merci de m'aider
J'attends vos propositions

[CinePhil]

Ça ressemble à un exercice scolaire ton questionnaire !
Dans tous les cas, as-tu cherché avant de poser ces questions ? Certaines sont vraiment simples.

Un petit tour chez SQLPro pour t'aider à répondre.

[aieeeuuuuu]

oui, ca sent l'exo a plein nez, et ca sent aussi le prof de [Math|Chimie|Physique|ouQueSaisJeEncore] qui a été déclaré "Prof de SQL"...

Rien que la première question laisse perplexe, peso, je dirai :
"Les deux mon capitaine"

sous réserve bien sur que l'exercice ait été recopié mot pour mot...

en tout cas quand tu auras la correction, ca serait sympa de la poster avec les commentaires du prof...

car si a la question 7/ le prof attend "tuple" comme réponse, la question 10/ est pour le moins formulée de facon etrange

[elgafsi86]

Bonjour Modérateur,
Oui je sais qu'ils sont simples mais ce qui me met en doute c'est l'approche dans le sens entre les propositions. J'ai bien cherché et les réponses sont très vagues.
Merci de descendre à mon niveau et répondre à mes questions,sincèrement ils vont m'aider à entamer la partie programmation des BDR

[punkoff]

C'est en étudiant et en cherchant que l'on augmente de niveau, pas en se faisant servir sur un plateau des réponses que l'on ne comprend pas.

[elgafsi86]

Bonjour Modérateur,
Désolé si j'ai apparu un peu paresseux car je suis trés débutant en Informatique. En fait je suis un étudiant en mathématique
Avant que je propose mes suggestions, j'ai bien googling mais ce qui me met en doute est l'approche dans les sens des propositions. Merci d'être encourageant pour entamer une autre science très importante

1)je propose la première car je pense que les triggers ne sont pas des requêtes mais des fonctions à part entière utilisé en PL/SQL

2)A moi,je tiens la 1er proposition car les requêtes sont des manipulations sur les tables et les BDR sont basés sur la notion des tables

3)je tiens la deuxième car la sauvegarde d'une BD se fait un autre moyen(que je ne sais pas ) autre qu'une notion de clé primaire

4)Je tiens la première mais je doute dans la deuxième car lorsqu'on regroupe les Info c'est entre autres dessiner un plan de classement de l'info selon le principe de BD

5)Je tiens la deuxième

6)Je tiens la première "sous forme de table" mais les autres sont aussi possibles mais comme j'ai lu, une BDR est structurée sous forme de tables

7)Je tiens la dernière "enregistrement"
Je veux savoir la différence entre ces 3 termes: enregistrement,n-uplet et tuple ?
J'ai trouvé que une ligne d'une table de BDR=n-uplet=tuple
et enregistrement???

8)Je tiens "clé primaire et clé subrogée"
mais je ne sais pas la différence entre clé subrogée et clé primaire

9)A mon avis,une équijointure(==jointure interne???) qui repose sur la jointure entre les éléments communs SEULEMENT entre les tables
donc je suppose que "même type et même nom"

10)je suppose que les 3 sont justes car une clé primaire sert à identifier d'une manière unique un enregistrement dans une table

11)les 2 premières sont les + proches

Merci pour votre compréhension

[CinePhil]

OK alors allons-y...

1)Une requete à une BD sert à:
*supprimer des informations dans cette base
*faire un trigger

Comme a dit aieeeuuuuu, "Les deux mon capitaine !"
Une requête est une instruction plus ou moins complexe envoyée à un SGBD pour exécuter quelque chose.
- CRUD : création (CREATE), modification (ALTER), mise à jour (INSERT, UPDATE), suppression (DELETE) de table, de procédure, de fonction, de trigger, de vue ;
- Interrogation de la bdd (SELECT).

2)Lorsuq'on manipule une BD,on manipule:
*des tables
*des requêtes

On manipule des tables, bien que je n'aime pas ce mot, "manipuler". Comme dit au dessus, les requêtes servent à "manipuler" les tables.

3)Un clé primaire sert à:
*enregistrer une BD
*identifier les informations pour pouvoir les retrouver

Ni l'un ni l'autre ! Ça sert à identifier de manière unique une ligne d'une table. On peut très bien se passer de clé primaire pour retrouver une information. Par exemple, pour trouver quelles sont les personnes nées entre le 01/01/1960 et le 31/12/1970, on fera la requête suivante qui n'utilise pas la clé primaire prs_id de la table :

Code :

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

1
2
3
SELECT prs_nom, prs_prenom
FROM te_personne_prs
WHERE prs_date_naissance BETWEEN '1960-01-01' AND '1970-31-12'

On n'enregistre pas une BDD ! On n'y enregistre des données à l'aide de requêtes INSERT ou UPDATE.

4)Une BD est:
*ensemble organisé et structuré d'info portant sur le même thème
*un plan de classement de l'information

Je dirais plutôt la seconde réponse parce qu'une BDD peut recouvrir plusieurs thèmes. Par exemple, en entreprise, il peut y avoir une BDD unique pour l'ensemble de la gestion, que ce soit celle des clients, des fournisseurs, des commandes, des achats, du personnel, des congés, du matériel... Tous ces domaines étant généralement liés les uns aux autres.

5)Un enregistrement correspond à:
*un programme nécessaire pour utiliser une BD
*l'ensemble des caractéristique d'un élement du tableau

Ni l'un ni l'autre !
Enregistrement est un mauvais terme souvent employé à tort à la place de "ligne". Une table (et pas un tableau !) est composé de colonnes (et pas de champs !) et de lignes (et pas d'enregistrements !)

6)Une BDR est une BD structuré :
*sous forme de tableau
*sous forme de ligne et de colonnes
suivant les principes de l'algébre relationneles
*en tenant compte des relations entre les tables

Une BDR, base de données relationnelle, est composée de tables, elles mêmes composées, comme déjà dit au dessus, de colonnes et de lignes. Si elle est bien conçue, la BDD obéira effectivement aux règles de l'algèbre relationnelle.
Le terme de "relation" de l'algèbre relationnelle est alors à rapprocher à celui de "table" d'une base de données. Ce terme est, malheureusement encore, souvent employé à la place de celui "d'association" entre les tables, lequel terme vient de la méthode Merise et de son célèbre Modèle Conceptuel de Données (MCD).
Voici un morceau de MCD :
Salarié -0,n----Affecter----1,n- Service

Salarié et Service sont deux entités qui vont devenir des tables dans la BDD et seraient dans l'algèbre relationnelle des relations, que le grand spécialiste de la question fsmrel préfère appeler des variables relationnelles, abrégées en relvar.

Affecter est une association entre les deux entités et se transformera, du fait de ces cardinalités maximales toutes deux à n, elle aussi en table associative dans la BDD.

7)les tables d'une BDR possèdent un certain nombre de colonnes permettant de décrire des élements appéles:
*n-uplets
*lignes
*tuples
*enregistrement
(QUEL est la différence entre n-uplets et tuple????)

Comme déjà dit deux fois, une table est composée de colonnes et de lignes.
n-uplets et tuples sont deux termes équivalents qui dérivent du terme "couple" pour exprimer des "couples" à plus de deux éléments.
tuple et n-uplet sont plutôt des termes à employer en dehors du contexte des tables.
Le tuple (en l'occurrence un couple) {'Brad Pitt', 'Angelina Jolie'} peut exister en tant que résultat d'une requête mais n'existera pas sous cette forme dans la base de données.

8)La non duplication(absecence de redondance ) des éléments dans une table d'un BDR est assuré par le SGBDR à l'aide du contrainte de type:
*clé primaire
*clé etrangére
*clé subrogé
*marqueur NOT NULL

Comme déjà dit, la clé primaire permet d'identifier de manière unique une ligne de la table. Une "surrogate key", que tu traduis par "clé subrogée" et que l'on trouve en français plutôt sous le terme de "clé de substitution" est une clé artificielle créée pour la BDD afin d'éviter les défauts de la clé naturelle qui peut changer de valeur ou être inutilement lourde dans les traitements. Voir à ce sujet le papier de SQLPro.

9)Dans un contexte d'une BDR,une jointure naturelle(ou équijointure peut se faire entre 2 tables dont la qualification est une égalité entre les valeurs de 2 colonnes(une de chaque table)de:
*même type
*même type et même nom
*même type et des noms différents
*même nom indépendement du type

Je cite SQLPro :

En utilisant la jointure entre clefs primaires et clefs secondaires basée sur l'égalité des valeurs des colonnes nous exécutons ce que les professionnels du SQL appelle une jointure naturelle.
Il est aussi possible de faire des équi-jointures qui ne sont pas naturelles, soit par accident (une erreur !), soit par nécessité.

Dans une jointure, il faut que le type des colonnes figurant dans la condition de jointure soient de même type, sous peine de faire tousser le SGBD. Par contre, les colonnes peuvent avoir un nom différent mais si on veut faire une NATURAL JOIN, alors il faut que les colonnes aient aussi le même nom car c'est le SGBD qui se débrouille pour faire la condition de jointure.
Je n'utilise jamais le NATURAL JOIN parce que c'est justement moins précis et peut porter à confusion lorsque la requête comporte plusieurs jointures.

10)Un clé primaire sert à:
*définir d'une maniére unique une ligne
*pour identifier un enregistrement
*eviter d'avoir 2 lignes semblables dans une table

Encore ! Comme je bannis le terme "enregistrement", je bannis la deuxième réponse. La bonne réponse est la première. La troisième est plus ambigüe : ça dépend de ce qu'on entend par "semblable" qui ne veut pas dire "identique" !

11)Dans une requête SQL,La clause distinct sert:
*enlever les répétitions
*ne ps répéter la même ligne
*sélectionner les sorties colonne par colonne

La deuxième réponse est plus proche de la vérité.
La première est proche mais là encore ambigüe : répétition de quoi ? Une colonne, X colonnes ? Toute la ligne de résultat ?
La troisième est fausse. Je ne sais même pas ce qu'elle veut dire !

Encore d'accord avec aieeeuuuuu :

quand tu auras la correction, ca serait sympa de la poster avec les commentaires du prof...

Histoire qu'on rigole !

[elgafsi86]

Bonsoir Modérateur
Merci bcpppppp pour votre aide.jai pu conclure de votre réponse que:
*Un trigger est un type de requête sur une BD.

*Pour la 3),j'ai trouvé dans le http://sqlpro.developpez.com/cours/clefs/,qu'un clé doit vérifier l'unicité"car la clef doit permettre de retrouver l’ensemble des informations afférent à un élément individuel et non à un groupe ou un ensemble" ce qui donne que la deuxième est juste.

*Pour la 4) pourquoi dans votre exemple,la BDD gestion est un seul thème en dépit qu'il s'agit d'une gestion de client ,d'achat... c'est un seul théme global qui est la gestion
*Pour la 5) pouquoi peux je ps dire qu'une ligne est l'ensemble de caractéristiques d'un élement du table?
*Pou la 7),je comprend que enregistrement est à éviter à utiliser dans le contexte du BDDR

*Pour 8), Pour la clé subrogé "surrogate key",J'ai pas compris est-ce qu'il s'agit d'une valeur de clé primaire enregistré ou un attribut artifciel qui remplace la clé primaire et généré par the database-generated uuid (par exemple, un HR number pour chaque employé AUPRES de son UUID(clé priimaire) ).La notion de ce type de clé est ambigue encore
S'il un type de clé qui remplace le clé primaire,pourquoi ne peux je pas dire qu'il assure la non duplication?

10)Ok pour les jointures naturelles=equijointure=jointures interne,et s'il s'agit des jointures extrenes(LFET Joint,Right Join)???

Merci d'avance pour les clarifications que vous me donnez

[aieeeuuuuu]

elgafsi

on joue sur les mots, car c'est l'énoncé lui même qui n'est pas clair du tout.
je vais essayer de te donner quelques pistes concernant tes dernières questions :
Un clef primaire, en soit, n'empêche pas de dupliquer les données, d'une certaines façon :
soit la table contact(IDContact, nom, prenom, telephone)
si son contenu est :
1|Codd|Edgar Frank|0102030405
2|Codd|Edgar Frank|0102030405

il y a bien une clef primaire, mais on ne peut pas dire qu'il y a non duplication. D'un point de vue de la base de données, ces deux lignes n'ont rien a voir, mais il est évident qu'elle contiennent en fait les memes données. Ce qu'il faudra pou éviter ca, c'est une contrainte d'unicité sur les colonnes (Nom, Prenom, Telephone)

pour ce qui est des jointures externes, elles te permettent de faire ressortir les lignes des la table 1 qui n'ont pas de ligne correspondante dans la table 2

[CinePhil]

jai pu conclure de votre réponse que:
*Un trigger est un type de requête sur une BD.

On peut dire ça comme ça, même si ce n'est pas tout à fait ce que j'ai dit.
Un trigger s'apparente plutôt à un programme que le SGBD exécutera à la place d'une requête d'insertion ou de mise à jour.

*Pour la 3),j'ai trouvé dans le http://sqlpro.developpez.com/cours/clefs/,qu'un clé doit vérifier l'unicité"car la clef doit permettre de retrouver l’ensemble des informations afférent à un élément individuel et non à un groupe ou un ensemble" ce qui donne que la deuxième est juste.

Le texte de la question était :

3)Un clé primaire sert à:
*enregistrer une BD
*identifier les informations pour pouvoir les retrouver

SQLPro dit :

la clef doit permettre de retrouver

Il y a une nuance.
Je maintiens ma réponse :

Ça sert à identifier de manière unique une ligne d'une table.

Bon OK, la seconde réponse est la plus proche, mais incomplète et légèrement ambigüe.

*Pour la 4) pourquoi dans votre exemple,la BDD gestion est un seul thème en dépit qu'il s'agit d'une gestion de client ,d'achat... c'est un seul théme global qui est la gestion

Oui mais en allant par là, on va finir par dire 42 !
Dans un système d'information d'entreprise, qui sert donc à la gestion de l'entreprise, il peut y avoir beaucoup de domaines différents.
Il n'y a aucun rapport direct entre la prospection des clients et les machines de l'atelier. Pourtant ces deux domaines peuvent être pilotés en utilisant la même BDD parce que de proche en proche, on peut partir de l'un pour arriver à l'autre :
- Prospects => Devis => Commande => Fabrication => Utilisation des machines.
Et à toutes les étapes on peut par exemple faire appel à la table des personnes :
- Le commercial qui prospecte ;
- Le chiffreur du devis ;
- La personne qui reçoit et enregistre la commande ;
- Le chef de production qui lance l'ordre de fabrication ;
- Le chef d'atelier qui planifie l'affectation des machines.

Donc pour moi, prospection et affection des machines sont des domaines différents mais qui peuvent se retrouver pilotés autour de la même BDD. C'est pour ça que j'ai refusé la seconde réponse. Une fois de plus, les réponses proposées sont incomplètes, imprécises, ambigües.

*Pour la 5) pouquoi peux je ps dire qu'une ligne est l'ensemble de caractéristiques d'un élement du table?

Le texte de la qestion était :

5)Un enregistrement correspond à:
*un programme nécessaire pour utiliser une BD
*l'ensemble des caractéristique d'un élement du tableau

Et dans ma réponse, j'ai réfuté le terme "enregistrement", ce qui me faisait refuser les deux réponses proposées.
Et même si on remplace "enregistrement" par "ligne", je trouve que la seconde réponse n'est pas tout à fait exacte. La bonne réponse serait : "Une ligne est un ensemble de valeurs en relation d'une table." Et le terme "relation" est ici à prendre dans le sens de l'algèbre relationnelle : ce sont les relations entre les valeurs d'une ligne qui fait que cette ligne est cohérente.
Les "caractéristiques" évoquées dans la réponse proposées seraient plutôt la définition des colonnes de la table (leur type et leurs éventuelles contraintes).

*Pou la 7),je comprend que enregistrement est à éviter à utiliser dans le contexte du BDDR

*Pour 8), Pour la clé subrogé "surrogate key",J'ai pas compris est-ce qu'il s'agit d'une valeur de clé primaire enregistré ou un attribut artifciel qui remplace la clé primaire et généré par the database-generated uuid (par exemple, un HR number pour chaque employé AUPRES de son UUID(clé priimaire) ).La notion de ce type de clé est ambigue encore
S'il un type de clé qui remplace le clé primaire,pourquoi ne peux je pas dire qu'il assure la non duplication?

Une surrogate key est une clé artificiellement créée pour la base de données.
Je peux par exemple définir un employé de la manière suivante :
Employé (matricule, nom, prénom, date_naissance)
Matricule est une clé candidate car il permet effectivement d'identifier de manière unique chaque employé. Mais c'est une mauvaise clé technique pour la table parce que le matricule sera de type VARCHAR, ce qui est contre-performant, pourra changer de valeur (rachat de l'entreprise => adoption du format de matricule du groupe acheteur), ce qui pose problème pour la mise à jour des clés étrangères à cause du risque d'un oubli de déclaration d'une clé étrangère quelque part.
On créera donc pour la table une clé artifielle, une surrogate key ou en fançais une clé de substitution qui sera de type entier et invariable, utilisée uniquement par le SGBD et non signifiante pour l'utilisateur, auquel d'ailleurs on ne la présentera d'ailleurs jamais. Je te renvoie à l'article de SQLPro qui explique l'avantage des clés auto-incrémentées en détail.

9)Ok pour les jointures naturelles=equijointure=jointures interne,et s'il s'agit des jointures extrenes(LFET Joint,Right Join)???

Ce n'est pas ce qui a été dit !
Revenons à la question :

9)Dans un contexte d'une BDR,une jointure naturelle(ou équijointure peut se faire entre 2 tables dont la qualification est une égalité entre les valeurs de 2 colonnes(une de chaque table)de:
*même type
*même type et même nom
*même type et des noms différents
*même nom indépendamment du type

Il existe en SQL la NATURAL JOIN, avec laquelle c'est le SGBD qui trouve tout seul quelles colonnes doivent être comparées pour réaliser la jointure.

Je cite le livre de SQLPro (je ne l'avais pas sous la main hier) :

La jointure naturelle (NATURAL JOIN) procède d'une équijointure des tables pour les colonnes dont le nom et le type sont identiques.

Il est vrai que ce texte est quelque peu différent de celui de son cours sur Developpez.com et que j'ai cité dans mon précédent message.

La bonne réponse concernant la jointure naturelle est donc "même type et même nom".

Dans toutes les autres jointures, internes ou externes, les types des colonnes doivent être identiques mais les noms des colonnes peuvent être différents.

[elgafsi86]

Bonjour Modérateur,
Tu mérites d'être modérateur Bravo
Merci beaucouppppp pour votre aide
à+