Information
AI Chat

Database Design Suite 1

Apprendre à concevoir une base de données

Course

DataBase Design

4 Documents

Students shared 4 documents in this course

University

Mit University De Dakar

Academic year: 2022/2023

Uploaded by:

Loïc NGASSAKI

Mit University De Dakar

0followers

3Uploads

2upvotes

Comments

Please sign in or register to post comments.

Preview text

S4-DATABASE DESIGN

I. Supertypes et sous-types

Objectif

Supertypes et sous-types se produisent fréquemment dans le monde

réel--

types de commande alimentaire ( manger , aller ) , les types de sacs

d'épicerie ( papier , plastique), les types de paiement ( chèque, espèces

, crédit). Vous pouvez généralement associer des «choix» de quelque

chose avec supertypes et sous-types. Par exemple, ce que vous aimez

sur votre sandwich? (moutarde, mayonnaise, ketchup, les oignons , les

tomates , les choux , les concombres , la laitue , autre).

Comprendre les exemples du monde réel nous aide à comprendre

comment et quand les modéliser.

Évaluation des entités

Souvent, certaines instances d'une entité peuvent avoir des attributs et

/ ou des relations que d'autres instances n'ont pas.

Imaginez une entreprise qui doit suivre les paiements des clients.

Les clients peuvent payer en espèces, par chèque, ou par carte de

crédit.

Tous les paiements ont des attributs: date de paiement, montant de

paiement, et ainsi de suite. Mais seulement les cartes de crédit auraient

l’attribut "numéro de carte".

Et pour carte de crédit et chèque paiements, nous avons peut-être

besoin de savoir quel client a effectué le paiement, alors que cela ne

soit pas nécessaire pour les paiements en espèces.

Faut-il créer une unique entité paiement ou trois entités séparées

espèces, par chèque, carte de crédit? Et qu'advient-il si à l'avenir nous

introduisons un quatrième mode de paiement?

Subdiviser une Entité

Parfois, il est logique de subdiviser une entité en sous-types. Cela peut

être le cas lorsqu'un groupe des instances a des propriétés spéciales,

comme les attributs ou les relations qui n'existent que pour ce groupe.

Exemple supertype

Examen est un super-type de QUIZ , MI-PARCOURS , et FINAL. Les

sous-types ont plusieurs attributs en commun. Ces attributs

ordinaires sont inscrites au niveau de super-type. La même chose

pour les relations. Les sous-types héritent de tous les attributs et

les relations de l'entité supertype.

Toujours plus d'un Sous-type

Quand un modèle ER est complète, il ne peut y avoir qu’un seul sous-

type. En d'autres termes, si une entité a un sous-type, un second sous-

type doit également exister. Cela a un sens. Un sous-type unique est

exactement le même que le super. Cette idée conduit à deux règles de

sous-type :

Exhaustive : Chaque instance du supertype est aussi une instance de

l'un des sous-types. Tous les sous-types sont répertoriés sans

omission.

Mutuellement exclusives : Chaque instance d'un super-type est une

instance d'un seul sous-type possible.

wallcovering(revêtementmural)wallpaper(fond d’écran)

SUPERTYPE DE REVÊTEMENT MURAL

Au stade de la modélisation conceptuelle , il est de bonne pratique

d'inclure d’ AUTRES sous-type pour vous assurer que vos sous-types

sont exhaustive - que vous manipulez chaque instance de la supertype

Les sous-types existent toujours

Toute entité peut être sous-typés par une règle qui subdivise les

instances en groupes.

Terminologie

Les termes clés utilisés dans cette leçon : • Exhaustive

• mutuellement exclusive

• Sous-type / sous-entité • Supertype

Résumé

Dans cette leçon , vous devriez avoir appris à :

• Définir et donner un exemple de sous-type

• Définir et donner un exemple d'un super- type

• les règles relatives aux entités et sous-types, et de donner des

exemples de chaque

• Appliquer les règles de sous-type supertype et en évaluant

l'exactitude des diagrammes ER qui les représentent

• Appliquer les règles de sous-type et supertype et les inclure dans un

schéma, le cas échéant

S5- DATABASE DESIGN

I. Transférabilité des relations

Objectif

Une fois qu'une classe a été attribuée à un enseignant, plus tard peut-elle être

transférée à un autre enseignant, éventuellement mi-semestre? Généralement

oui, car sinon, que faisons-nous si l'enseignant tombe malade?

Examen des relations

Passons en revue une relation simple entre SONG et TYPE.

Optionalité :

Pouvez-vous avoir un TYPE qui ne classe pas une chanson?

Chaque CHANT doit-il avoir un TYPE?

Cardinalité:

Combien de chansons peuvent être classées dans un TYPE?

Combien de types peuvent avoir une chanson?

Transférabilité :

Une chanson peut être modifiée d'un type à un autre type?

Terminologie

Les termes clés utilisés dans cette leçon : • transférable

transférables

Résumé

Dans cette leçon, vous devriez avoir appris à :

décrire et donner un exemple de relation transférabilité
Comprendre la différence entre transférable et relations non transférables
Illustrer les relations non transférables sur ERDs

II. Types de relations

Une PERSONNE peut-elle posséder plusieurs DVD, ou un seul?

Un DVD peut-il appartenir à plusieurs PERSONNES?

Au fur et à mesure que nous affinons et améliorons notre modèle, nous voulons

s'assurer que nos relations d'entité modélisent correctement les règles de

l’entreprise. N'oubliez pas que vous pouvez éviter de futures erreurs coûteuses

en réfléchir aux détails dès le début.

Relations un-à-plusieurs (1: M)

One-to -One relations pour les processus

Les relations 1: 1 (des trois variantes) se produisent également lorsque

certaines des entités représentent différentes étapes d'un processus.

####### Recipe(recette) ; Dish(plat)

Relations redondantes

Une relation redondante peut être dérivée d'une autre relation dans le modèle.

Dans cet exemple, vous pouvez dériver la relation de PERSON à COUNTRY

des deux autres relations et vous devez les supprimer du modèle.

Cependant, faites attention à en concluant qu'une relation redondante est

basée sur la structure seule. Lisez les relations à vérifier.

Le ERD montré ici ne refléte pas une relation redondante

Hometown of : ville natale de

Living in : vivre dans

Location of : emplacement de

Located in : situé dans

III. Résolution des relations plusieurs-à-plusieurs

Objectifs

Cette leçon porte sur les objectifs suivants :

Identifier les attributs qui appartiennent à la relations plusieurs -à-plusieurs
Démontrer les étapes pour résoudre une relation plusieurs -à-plusieurs à l'aide

d'une entité d'intersection

Identifier l'UID d'une entité d'intersection et représenter dans le diagramme de

la relation entité.

Cette leçon vous aidera à compléter votre modèle - vous pouvez avoir besoin de

créer de nouvelles entités ou de nouvelles relations basées sur les besoins de

l'entreprise.

Cela vous aidera également à définir la portée de votre modèle de données -

vous modélisez uniquement ce qui est important pour l'entreprise.

Relation masquant un attribut

Dans l'entreprise DJ , chaque PARTNER peut être affecté à travailler sur un ou

plusieurs événements. Chaque événement peut être un travail pour un ou

plusieurs partenaires.

EVENT et PARTNER

Lorsqu'un PLANIFICATEUR d’événement, un DJ ou un GESTIONNAIRE DE

PROJET travaille sur un ÉVÉNEMENT, nous voulons qu'il enregistre le statut

du travail.

L’attribut "statut" appartient-il à quelle entité?

Résolution d'une relation M: M

Une troisième entité est nécessaire pour résoudre la relation M: M.

C'est ce qu'on appelle une entité "intersection".

Entité d'intersection

Une entité d'intersection – EMPLOI CESSION – a été ajouté, y compris le statut

attribut. La relation originale M: M devient deux relations 1: M. Quel serait

l'UID de l’entité d’intersection?

PARTNER : Partenaire

EVENT PLANNER : Planificateur

d’évènements

EVENT : Evènement

MANAGER : Directeur(gestionnaire)

Résolution de relation M: M Exemples d'émissions télévisées

Chaque émission de télévision peut être regardée par une ou plusieurs

personnes.

Chaque personne peut regarder un ou plusieurs émissions de télévision.

Résolution de relation M: M Exemples Cleaning Services

Chaque société peut fournir un ou plusieurs services de nettoyage.

Chaque service de nettoyage peut être fourni par une ou plusieurs entreprises.

Terminologie

Les termes clés utilisés dans cette leçon :

relation barrée
entité d’Intersection

Résumé

Dans cette leçon, vous devriez avoir appris à :

Identifier les attributs qui appartiennent aux relations plusieurs à plusieurs.
Démontrer les étapes pour résoudre une relation plusieurs à plusieurs à l'aide

d'une entité d'intersection

Identifier l'UID d'une entité d'intersection et représenter dans le diagramme

entité/relation.

CLEANING SCHEDULE : Programme

de nettoyage

Was this document helpful?

Database Design Suite 1

Course: DataBase Design

4 Documents

Students shared 4 documents in this course

University: Mit University De Dakar

Was this document helpful?

S4-DATABASE DESIGN

I. Supertypes et sous-types

Objectif

Supertypes et sous-types se produisent fréquemment dans le monde

réel--

types de commande alimentaire ( manger , aller ) , les types de sacs

d'épicerie ( papier , plastique), les types de paiement ( chèque, espèces

, crédit) . Vous pouvez généralement associer des «choix» de quelque

chose avec supertypes et sous-types. Par exemple, ce que vous aimez

sur votre sandwich? (moutarde, mayonnaise, ketchup, les oignons , les

tomates , les choux , les concombres , la laitue , autre) .

Comprendre les exemples du monde réel nous aide à comprendre

comment et quand les modéliser.

Évaluation des entités

Souvent, certaines instances d'une entité peuvent avoir des attributs et

/ ou des relations que d'autres instances n'ont pas.

Imaginez une entreprise qui doit suivre les paiements des clients.

Les clients peuvent payer en espèces, par chèque, ou par carte de

crédit.

Database Design Suite 1

DataBase Design

Mit University De Dakar

Comments

Students also viewed

Related documents

Preview text

S4-DATABASE DESIGN

I. Supertypes et sous-types

Objectif

Supertypes et sous-types se produisent fréquemment dans le monde

réel--

types de commande alimentaire ( manger , aller ) , les types de sacs

d'épicerie ( papier , plastique), les types de paiement ( chèque, espèces

, crédit). Vous pouvez généralement associer des «choix» de quelque

chose avec supertypes et sous-types. Par exemple, ce que vous aimez

sur votre sandwich? (moutarde, mayonnaise, ketchup, les oignons , les

tomates , les choux , les concombres , la laitue , autre).

Comprendre les exemples du monde réel nous aide à comprendre

comment et quand les modéliser.

Évaluation des entités

Souvent, certaines instances d'une entité peuvent avoir des attributs et

/ ou des relations que d'autres instances n'ont pas.

Imaginez une entreprise qui doit suivre les paiements des clients.

Les clients peuvent payer en espèces, par chèque, ou par carte de

crédit.

Tous les paiements ont des attributs: date de paiement, montant de

paiement, et ainsi de suite. Mais seulement les cartes de crédit auraient

l’attribut "numéro de carte".

Et pour carte de crédit et chèque paiements, nous avons peut-être

besoin de savoir quel client a effectué le paiement, alors que cela ne

soit pas nécessaire pour les paiements en espèces.

Faut-il créer une unique entité paiement ou trois entités séparées

espèces, par chèque, carte de crédit? Et qu'advient-il si à l'avenir nous

introduisons un quatrième mode de paiement?

Subdiviser une Entité

Parfois, il est logique de subdiviser une entité en sous-types. Cela peut

être le cas lorsqu'un groupe des instances a des propriétés spéciales,

comme les attributs ou les relations qui n'existent que pour ce groupe.

Exemple supertype

Examen est un super-type de QUIZ , MI-PARCOURS , et FINAL. Les

sous-types ont plusieurs attributs en commun. Ces attributs

ordinaires sont inscrites au niveau de super-type. La même chose

pour les relations. Les sous-types héritent de tous les attributs et

les relations de l'entité supertype.

Toujours plus d'un Sous-type

Quand un modèle ER est complète, il ne peut y avoir qu’un seul sous-

type. En d'autres termes, si une entité a un sous-type, un second sous-

type doit également exister. Cela a un sens. Un sous-type unique est

exactement le même que le super. Cette idée conduit à deux règles de

sous-type :

Exhaustive : Chaque instance du supertype est aussi une instance de

l'un des sous-types. Tous les sous-types sont répertoriés sans

omission.

Mutuellement exclusives : Chaque instance d'un super-type est une

instance d'un seul sous-type possible.

wallcovering(revêtementmural)wallpaper(fond d’écran)

SUPERTYPE DE REVÊTEMENT MURAL

Au stade de la modélisation conceptuelle , il est de bonne pratique

d'inclure d’ AUTRES sous-type pour vous assurer que vos sous-types

sont exhaustive - que vous manipulez chaque instance de la supertype

Les sous-types existent toujours

Toute entité peut être sous-typés par une règle qui subdivise les

instances en groupes.

Terminologie

Les termes clés utilisés dans cette leçon : • Exhaustive

• mutuellement exclusive

• Sous-type / sous-entité • Supertype

Résumé

Dans cette leçon , vous devriez avoir appris à :

• Définir et donner un exemple de sous-type

• Définir et donner un exemple d'un super- type

• les règles relatives aux entités et sous-types, et de donner des

exemples de chaque

• Appliquer les règles de sous-type supertype et en évaluant

l'exactitude des diagrammes ER qui les représentent

• Appliquer les règles de sous-type et supertype et les inclure dans un

schéma, le cas échéant

S5- DATABASE DESIGN

I. Transférabilité des relations