Salut tout le monde,
 
J'ai quelque questions (2) à vous posée consernant des generalité sur les base de donée:
 
1) Reduction et Elimination de redandance:
Comment trouvé une couverture irréductible d'un ensemble de DFs ? je ne comprend pas ce qu'il faut faire, y a il des démarches à suivre pour le faire ? sinon quelle sont les cas possible ?
 
 
2) Comment rendre un relation en 2eme et en 3eme forme normale ?
 
j'ai chercher et lu quelque définitions, comme ceci:
http://www.claroline.net/wiki/index....uring_database
etc...
 
et voilà ce que j'ai pu résumé (mais je ne comprend pas trop...):
 
1ère forme normale : (c'est facile)
 
chaque attribut est représenté par un identifiant unique (les valeurs ne sont pas des ensembles, des listes,…)
exemple: s'il y a un atribut num_de_vol qui prend 2 valeurs dans une meme ligne, alors c'est pas en 1ere forme normale.
 
 
2eme forme normale:
 
Elle est en 1ere forme normale + Tout les autres Attribut (différant de la clé
primaire) ne dépendants que des attributs de la clé primaire.
 
 
 
3eme forme normale:
 
Tout autre attribut (différant de la clé primaire) il faut qu'il ne dépend que des
attribut de la clé primaire.
 
 
NB: je ne vois pas trop la différence entre la 2eme et la 3eme forme normale.
 
Merci pour votre aide...

Oublie les mots techniques à la con.
 
Très franchement, je pige absolument rien à tes questions. Euthanasie ton prof, c'est de la haute voltige d'abrutissage. Y'a rien de plus simple que l'analyse des données ainsi que la conception de bases de données... Je sais pas comment il a fait ton prof, mais là il a réussi à transformer ça en un bordel infâme imbittable.
 
 
"Comment trouvé une couverture irréductible d'un ensemble de DFs"
Mais lol !
 
"NB: je ne vois pas trop la différence entre la 2eme et la 3eme forme normale."
Moi non plus... Elles veulent autant rien dire l'une que l'autre.
 
Demande en français ce que ça donne. Trouves un exemple, et tu verras que rien que de traduire la chose en français avec un exemple, t'aura trouvé la réponse...

En fait ça c'est la troisième forme normale ...
 
"Un schéma relationnel R est en 2FN si chaque attribut non primaire A de R est complètement dépendant fonctionnellement de la clé primaire de R"
Autrement dit, si la clé primaire A de R est composée de plusieurs attributs, le fait d'en ôter un ne permet plus de déterminer les autres attributs non clé.
NB: si la clé primaire de R ne contient qu'un attribut alors R est automatiquement en 2FN.
 
 
 
Sinon j'essaye de comprendre tout ça pour faire la conception d'une petite base de données qui traite la gestion des livres d'une bibliothèque ...
Je vais essayé de construire les Relations nécessaire et les normalisé, puis je reposte...
 
 
 

Je note, lol.

 
Hé mais il est sous quoi ton prof ?
 
J'aimerais bien qu'il nous donne sa vision des choses pour découper en tables :
- commande
- lignes de commande
- cadencement de lignes de commande
- jalons
- commentaires de commande (tous niveaux confondus)
 
le truc limpide à la base, j'imagine même pas comment il défini ça ton prof. c'est plus de la masturbation intellectuelle ton cours, c'est de la sodomie de neurronne...
 
 
en fait, je pige pas trop. c'est quel niveau d'études là ? quelle branche ?
on dirait que vous étudiez la modélisation de base de données comme si ça devait être automatisable. master d'ai ou quoi ? parcequ'un tel niveau d'abstraction, c'est le meilleur moyen de partir sur un truc totalement bancal, perdre des heures pour trouver des cas évidents, et passer à côté de cas évidents qui sont bien plus complexes que ça... (notamment les clés composites partielles -c'est à dire le cas des commentaires dans mon exemple-, autant c'est évident qu'il suffit d'une table avec des champs nullables dans la PK, autant avec votre super système à deux balles
on se retrouve avec... 1, 2, 3... 4 tables absolument redondantes).
 
une bête approche merise ou UML c'est si simple...
 
votre prof, il de ce genre là non ?

Mdr

Bah, non, Info 2eme (LMD),
C'est dans ce semestre qu'on a commencé le module de Base de donnée, et j'ai même avis que toi sur la façon de voir du prof etc... Mais je m'en fiche, je dois comprendre tout ça pour faire le TP à 2 balle qu'il nous as donné...
 
 

Ben c'est les définitions "Merise" des formes normales.
C'est toujours pareil, tu les apprends pour ton partiel, et le reste du temps tu raisonne sur des exemples...
 
moi j'ai ca, c'est pas beaucoup mieux
1ère forme normale
 
Elle est susceptible de concerner toute entité et toute association. Une entité ou une association est dite en "première Forme Normale" si toutes ses propriétés sont :  
 
- "Élémentaires" (non subdivisables, au vu du contexte en question).
- "Non répétitives"
- "Significative pour toutes les occurrences"
Exemple : dans une entité Salarié, "voiture de fonction (oui/non)" est significatif pour toutes les occurrences. Mais pas "type de la voiture de fonction".
 
 
 
2nde forme normale
 
Elle ne concerne que les objets ayant un identifiant concaténé (c'est-à-dire : les associations).  
Une association est dite en 2ème Forme Normale si :  
 
- Elle est en 1ere Forme Normale
- Toutes ses propriétés sont en dépendances fonctionnelle avec tout l'identifiant de cette association  
 
 
3ème forme normale
 
Elle est susceptible de concerner toute entité et toute association.
Une association est dite en 3ème Forme Normale si :
 
- Elle est en 2ème Forme Normale
- Il n'existe pas de dépendance fonctionnelle entre les propriétés non-identifiantes. (une propriété ne doit dépendre que de l'identifiant, qu'il soit concaténé ou non).  
 
 
 

J'ai pourtant fait 2 ans de Merise à l'IUT, j'ai pas souvenir d'avoir eu des définitions pareilles (quoique c'est peut-être pour ça que j'avais des bâches aux partiels )
 
Y sont fous vos profs

En tout cas, ce que j'adore, c'est que je pige aucune de vos définitions... C'est quoi ces histoires de forme normales ?

comment on peut faire 2 ans de merise ? on a du faire le cursus en 20h ... on nous aurait menti ?

5h par semaine pendant deux ans -dont les 9/10 étaient des TD/TP, parceque si Merise tiens en 2 feuilles de PQ, c'est en forgeant qu'on devient forgeron- (bon, pas tous les trimestres, ok)
 
Et je ne pense pas que ce soit de trop... L'analyse, c'est de loin aussi important que l'algo. Tu pars d'une modélisation bancale, tu peux être un dieu en algo, tu va être coincé tout pareil. Dans un gros projet, l'analyse est de loin ce qui nécessite la plus grande attention, car TOUT se base sur l'analyse par la suite. Donc la moindre merde, et c'est la catastrophe pour l'ensemble du projet.

J'suis d'accord, mais j'avais pas l'impression qu'il y ait tant de "concepts" que ca dans la méthodologie... mise à part ces fameuses formes normales auquelles personne ne comprend rien  
 
edit : le bougre il a édité, en effet tout se joue sur les TD/TP, et là on en a pas fait des masses

Ben aussi, je sais pas trop ce que vous avez le temps de voir en 20 heures...
 
Faut quand même plus de 20 heures je pense pour faire le tour des DAF, MCT, MLT, MCD, MLD, MPD, Dictionnaire des données, etc. (j'ai ai d'ailleurs oublié la moitié )
 
Parceque rien que l'isolation des acteurs/flux, des acteurs/traîtements et des données/relations/règles ça me semble quand même un peu limite en 20 heures... M'enfin bon si vos profs noient ça dans des définitions matheuses de la sorte, je comprends mieux... Mais c'est criminel en tout cas !

Re-Salut,

En analysant un petit texte (en bas) qui definie la gestion d’une bibliothèque pour la conséption d'une petite base de données: "bibliothèque",
j'ai tiré les relations suivantes:
Nb: les attributs qui sont souligné font parti de la clée primaire...

Livre ( côte CHAR, numExemplaires NUMERIQUE, nbrExemplaires NUMERIQUE, titre CHAR, langue CHAR, editeur CHAR, annéEdition ).

Thése ( côte, nbrExemplaires, typeThese, titre, auteur, dirThése, datSoutn, lieu ).

Memoire ( La_meme_chose_que_Thése ).

Emprunteur ( numEmp, nom, prénom, type_Etd_Ens_Admin, BonMaivaiEmp ).

Prêt ( côte, numEmp, datePrêt, dateRetour ).

Mais je suis sure qu'il y a plein de modification et d'amelioration et de Relations à ajouté...

"ouvrage".
 
thèse, livre et mémoire sont des ouvrages.
 
99% des infos sont identiques entre les 3, et sont propres à un ouvrage.
 
donc une entité "ouvrage" avec un type d'ouvrage... pas 1 entité par type et une FK impossible à vérifier dans ton "pret".
 
ps : y'a pas que ça certainement. j'ai même pas lu ton énoncé. juste que tes 3 entités me semble particulièrement redondantes, et que je mot ouvrage est présent 12 fois par ligne dans le texte d'analyse donc à priori...

Donc je définie une table Ouvrage qui contiendra tout les infos sur livres/memoires/theses,
et une table TypeOuvrage qui va dire si l'ouvrage est un livre/memoire/these ?
 
c'est ce que tu veu dire ?
 
Genre:
 
Ouvrage ( ISBN VARCHAR(25), cote INT, codeTypeOuvrage, titre VARCHAR(25), auteurs VARCHAR(25), editeur, lieuEdit, dateEdit,langue, thémeCode, themeDesignation, numExemplaires NUMERIQUE, nbrExemplaires NUMERIQUE, dirThése, datSoutn, ... )
 
TypeOuvrage ( codeTypeOuvrage INT, nom VARCHAR(25) )

Effectivement.
 
Ensuite, vu que tu vas avoir des champs nuls dans la table Ouvrage car typiques à l'un ou l'autre des types d'ouvrage, tu peux commencer à dénormaliser, et créer une table "attributs", qui permet de lier à une ligne d'ouvrage et un code attribut une valeur d'attribut : ainsi quand y'a pas d'attribut pour un ouvrage, y'a simplement pas de ligne dans cette table.
 
De la même façon, tu peux refactoriser certaine informations. Par exemple "directeur de thèse", c'est valable que pour une thèse. "Editeur", c'est valable que pour un livre. Jusqu'où est-il intéressant d'avoir deux champs exclusifs, alors qu'un même champ pourrait regrouper la même information, puisqu'on peut déterminer son sens grace au type d'ouvrage.
 
Attention, la dénormalisation est le travail de base de l'analyse une fois le modèle établi (ne jamais entâmer la dénormalisation avant d'avoir fini... sinon tu vas avoir la bulle -et contente-toi d'un paragraphe en fin de devoir sur le sujet, sinon c'est pareil, les profs n'aiment pas la dénormalisation... c'est pour ça qu'ils sont profs d'ailleurs )

Ok,
Mais je croie que la dé normalisation va permettre une optimisation de la mémoire, mais est ce qu'elle ne va pas crée une complexité des données accrue  
?
(Sauver beaucoup d'espace disque, mais la complexité de l'application va tripler :$)
les puristes tendent à dire que la normalisation est sacré... d'autre disent que l'optimisation est sacrée... plus le temps avance il disent que la normalisation l'emporte parce qu'on a de moins en moins "BESOIN" d'optimiser a cause de la puissance des machines, évidemment ça empêche pas de le faire, mais c'Est pas aussi nécessaire que ya 15 ans...  Et faut alors savoir si mon prof est un puriste, lol.
 

La dénormalisation, c'est loin d'être de l'optimisation.
Du moins, elle ne doit pas être effectuée dans cette optique.
 
Elle doit au contraire être effectuée dans une optique de simplification du modèle (notamment réduction du nombre de champs spécifique, au profit d'une généricité accrue) et ça s'accompagne souvent d'optimisations, mais surtout la plupart du temps d'une généricité accrue de la solution toute entière : non seulement je peux gérer ton problème avec le modèle que je viens de pondre, mais en plus tes problèmes à venir et ceux de ton voisin.
 
La dénormalisation, c'est par exemple, suite à l'analyse, la détection des entités suivantes :
- Client
- Fournisseur
- Commande de vente
- Livraison
- Facture de vente
- Commande d'achat
- Réception
- Facture d'achat
- (plus autres, stocks, produits, tarifs, etc.)
 
Donc une fois que j'ai un MCD qui tiens pas sur une page en A2, je m'apperçoit que...
Un client ça a :
- Raison sociale
- Des contacts
- Des adresses commerciales, de livraison, de facturation, etc.
- Une domiciliation bancaire
- Etc.
 
Un fournisseur ça a...
Un peut tout pareil que le client !
 
=> Une unique table "tiers" avec un champ "type de tiers" et hop ! Je viens de virer une table, et ainsi grandement simplifier la gestion. En plus de ça, le jour où je veux gérer un catalogue de prospects, de transporteurs, etc. j'ai déjà une jolie table toute prête qui les attends, j'ai juste à rajouter un type de tiers.
 
Une commande de vente et une commande d'achat c'est... Un peu pareil... Quand à une facture, ou une livraison/réception, toujours, c'est un peu comme une commande ! Hop, je passe de 6 tables à une seule table, avec juste deux champs, l'un pour la direction du flux (achat/vente) et un pour le type d'évènement (commande, livraison, facture).
 
Non seulement ça simplifie de nouveau la chose, mais si demain je veux faire des avoirs, des devis, des contrats ou autres appels d'offre, j'ai déjà une table toute prête pour les stocker !
 
Bref, le gars qui veut pas dénormaliser, il devient prof, il trouvera jamais de boulot dans une équipe. Les MPD de 600 tables (déjà vu) dont 90% des entités redondantes, c'est le mal.

   , J'aime bien ta vision des choses, pour les profs.

Bref,
J'ai Quelque question à posé:

1) Faut définir quoi comme clé primaire pour mais relations (tables) ?
Par exemple pour Ovrage(...), la clé serai l'ISBN d'après moi, mais à quoi servira alors le côte ? (la clé primaire serai-elle l'ISBN et la cote ? ), vu que la cote et mentionné dans le texte d'analyse...
Ou faut-il à chaque fois mettre un champ ID en tant que clé primaire, (dans chaque relation) ?
Car aussi, il faut bien que dans ma table Prêt, je dois avoir la clée primaire de Ouvrage, non ?

2) Pour la relation Emprunteur(...), dois-je la lesse comme étant un attribut (champ) dans la relation emprunteur, ou bien faire une autre relation TypeEmprunteur(), comme pour TypeOuvrage(...) ? je croie que non, mais bon...

3) En fait je coie qu'il y a un probléme avec ces relations (tables):
Je croie qu'il faut faire une table Exemplaire(), qui porte un numéro, et une Clé étrangère (Forgein key) vers Ouvrage. Et l'emprunteur emprunte un Exemplaire pas un Ouvrage... Vous ne trouvez pas ?

Faut voir dans l'énoncé si le numéro ISBN est présenté comme clé unique et toujours présent ou non. Ma soeur travail à la BNF, et ils n'utilisent pas le numéro ISBN comme identifiant, car tous les textes qu'ils ont n'en ont pas : une revue à le même numéro pour une année de parution par exemple, ou aussi ils ont des documents du moyennage et à l'époque l'ISBN...
Ensuite, je ne suis pas du tout du métier, et cela est absolument spécifique au métier. La réponse serait dans un entretient complémentaire avec le client, ainsi qu'une étude d'un panel d'ouvrages (un thèse a-t-elle un numéro d'ISBN ? Une cote unique ?)
Dans l'absolu, une clé unique (ID autoincrément) est toujours une solution envisageable, par contre elle pose le problème de l'intégration dans un système de coopération entres SI.
 

Dans la tabel "prêt", je verrais bien un identifiant unique, car un client peut emprunter plusieurs fois le même livre, donc la relation livre/client est inssuffisante. Par contre, évidement, l'identifiant du livre et du client doivent être présents dans cette table.
 

Pas pigé ta question. T'as des types d'emprunteurs ?
 

Effectivement, je suis d'accord avec ce point
 
 
PS : Une "table", c'est une ENTITE. Un "champ" c'est un "attribut". Un tuple d'attributs (clé) permettant d'identifier un élément dans une entité, c'est un "identifiant". Et enfin, une "relation" ça peut donner lieu dans le MPD à une clé étrangère (si l'attribut n'a que deux pattes et qu'une de ces pattes a une cardinalité de 0,1 ou 1,1 -c'est à dire une CIF = Contrainte d'Intrégrité Fonctionnelle). Dans le cas contraire, une "relation" donne lieu à une table de correspondante qui prend comme identifiant un tuple formé de l'ensemble des identifiant des entités reliées.

Re,
Bon alors voilà le petit MCD (en fait c'est un MPD) que j'ai fait rapidement, et j'aimerai voir votre avie, et correction si il y on a :
 

 
merci.

Je ne vois pas d'incohérence flagrande.
 
Par contre, chelou le MPD mélangé à un MCD, faudra que tu change ça

Dans le texte d'analyse, on as les phrases comme :
"Tout individu peut devenir emprunteur à condition q'il n'ait pas été un MAUVAIS emprunteur au cours d'une période précédente"
comment on peut les utilisé dans notre conception ?
Avant l'insertion dans la table Pret(), je check si cé un mauvais emprunteur, si oui, je raise une application error ... ou un truc du genre... Mais comment faire .. là ?
 
 
Et aussi, je ne vois pas trop comment utilisé, cette partie dans ma concéption (si on peut apeler ça comme ça lol) :
"Le bibliothécaire enregistre le prêt en précisant la date du prêt et la date prévue de retour après avoir effectué les vérifications principales suivantes :
- disponibilité de l’emprunteur : vérifier si l’emprunteur n’est pas un mauvais emprunteur.
- Dépassement du quota de livres empruntés.
Lors de la restitution d’ouvrage, le bibliothécaire enregistre la date réelle de retour de l’ouvrage. En cas de restitution ayant dépassée le délai de prêt accordé, le bibliothécaire peut introduire une pénalité à l’emprunteur."

Là, c'est 100% au choix de l'analyste et du développeur.
Ton idée de flag associé à un contrôle (par trigger qui raise une error si possible) est bonne.
Une autre idée, serait d'avoir une table "black list" dans laquelle tu recopies les utilisateurs lorsque tu les flag comme mauvais, avant de les supprimer de la table des emprunteurs. Lors de la tentative d'insertion d'une ligne dans "emprunteur", tu peux alors faire un trigger provoquant le même comportement si les infos correspondent (homonyme, même email, etc.).
 
Dans les deux cas, on peut indiquer sur le modèle une contrainte d'exclusivité, qui sera plus lisible si tu fais une table "black list" : un tuple "nom prénom" ne peut être présent que dans l'une ou l'autre des deux tables.
 
Très franchement, je ne l'ai jamais utilisé autrement qu'en TP... De mémoire, c'est une sorte de CIF, avec un gros X à l'intérieur et des "pattes" en pointillé, et sans cardinalités. Par contre, je ne sais pas comment l'attacher visuellement au tuple à contraindre. Vérifie dans ta doc.
 

Ca, ça va être dans le MCT, au niveau MPD y'a rien qui peut indiquer quoi que ce soit au niveau de ces règles, qui sont purement... euh... (adjectif de "traitement" )
Le fait que tu aies modélisé les informations "quota" et "bon_mauvais" est suffisant à mon avis.