Mourad Gridach

Department of Computer Science

High Ins6tute of Technology - Agadir
 About Mini-Project 1 - Obligatory

• Compute the “closure” of a set of attributes in C language

• Inputs à Relation R with a set of functional dependencies

• Outputs à closure of the given attributes

2
 About Mini-Project 2 - Optional

• Determine the key of a relation in C language

• Inputs à Relation R with a set of functional

dependencies

• Outputs à key (s) of the relation R

3
 Plan – Part 2

• Le système d’information (Very short Introduction)

• Digramme Entité – Association (ERD)

• Développement des Modèles de Donnés

• Schéma de Conversion

4
 Today’s Lecture

• Introduction au système d’information

• Le diagramme entité association (Entity-Relationship Diagram)

• Concepts de bases

• Notation d’un ERD

5
Introduction au Système
d’Information
 Introduc8on

Entreprise

Administration Equipements Service informatique

Ouvriers Base de données Service comptabilité

Fournisseurs Clients Autres entreprises

Solution ?? Système d’Information

7
 Systèmes de l’Entreprise (1)

Flux de données Flux de données

entrantes sortantes

8
 Systèmes de l’entreprise (2)
ü Chaque système apporte des services et des fonctionnalités pour l’autre

9
 Système de Pilotage
Appelé aussi « Système de Décision »

Définir les missions Fixer les objectifs Contrôler leur réalisation

Système de
pilotage

Organiser l’emploi Contrôler l’exécution Corriger (selon des

des moyens des travaux contraintes prédéfinies)
10
 Système Opérant
Ordres du système Exécuter SO (Moyens humains,
de pilotage matériels et organisationnels)

• Reçoit les informa6ons émises par le système de pilotage

• Se charge de réaliser les tâches qui lui sont confiées
• Génère à son tour des informa6ons en direc6on du système de pilotage
• Il englobe toutes les fonc6ons liées à l’ac6vité propre de l’entreprise :
ü Facturer les clients, régler les salaires, gérer les stocks, etc.
• Système opéra6onnel où :
ü Les ma6ères premières sont transformées
ü Les produits finaux sont fabriqués.
11
 Le Système d’Informa5on (SI)

• Pour organiser son fonc6onnement, le système (l’organisa6on ou l’entreprise) a

besoin de mémoriser des informa6ons
ü Pour comparer, prévoir, etc.
• Ce rôle est joué par le Système d’Informa6on
• Ce système a aussi la charge de :
ü U6liser, compiler et diffuser l’informa6on
ü Réaliser tous les traitements nécessaires au fonc6onnement du système

Le SI est un lien obligatoire pour toutes les informations de

l’entreprise 12
 Système d’Information - Exemple
Dans le SI de l’EST, on trouvera :
• Toutes les informations sur les étudiants de l’EST :
ü Nom et prénom
ü CNE et CIN
ü Date de naissance,
ü Parcours scolaire précèdent,
ü Etc.
• Mais
ü Ni la couleur des yeux
ü Ni le groupe sanguin
à Informations non appropriées pour le fonctionnement de l’école.
13
 Rappel
• Par?e équivalente de la méthode « Merise »

• C’est la par?e équivalente de ce qu’il font la plupart des professeurs dans

les universités/cours francophones

14
 Merise – MeDre en Place un Système d’Informa6on
ü Niveau conceptuel
o Modèle conceptuel de Données (MCD)
o Modèle conceptuel de communication (MCC)
o Modèle conceptuel de traitement (MCT)
ü Niveau organisationnel
o Modèle organisationnel de traitement (MOT)
ü Niveau logique
o Modèle logique de données (MLD)
ü Niveau physique
o Modèle physique de données (MPD) 15
 Processus de Conception d’une Base de Données

Modèle conceptuel

Modèle rela6onnel
Tables + contraintes
Dépendances fonc6onnelles

Normalisation :
Eliminer les anomalies
Schéma conceptuel

Stockage physique:
Schéma physique
16
 Objectifs
• Question: Pourquoi le développement d’une base de données est un
challenge?

• Gagner un contexte pour la suite des modules de bases de données

• Expliquer le but du développement d’une base de données
• Expliquer la position de cette partie dans le processus général du
développement d’une base de données

17
 Introduc:on (1)
• Changement considérable par rapport à la par6e précédente
• La par6e précédente suppose l’existence d’une base de données
• L’ambiguïté est un caractère principal pour le développement d’une base de
données
• Développer une base de données est un challenge
ü Ambiguïté: une par6e science, par6e art
ü Opportunité pour la résolu6on de quelques problèmes
ü Se concentrer sur la concep6on et non pas l’u6lisa6on d’une base de
données
18
 Système d’Information - Rappel

• Accepte les données depuis son environnement, ensuite traitement et sortir

des résultats pour une prise de décision ultérieure.

• Interaction avec son environnement

• Une base de données fournit une mémoire à long terme

• Base de données est un composant clé mais pas unique

• Autres composants: entrées, sorties, processus, software, hardware,

utilisateurs
19
ObjecGfs du développement d’une BD (1)

Développer un vocabulaire commun

Définir les règles de gesGon

Assurer la qualité des données

Fournir une implémentation efficace

20
 Objectifs du développement d’une BD (2)
• Une BD fournit un vocabulaire commun pour une organisation
ü Avant l’implémentation de la BD, les parties d’une organisation peuvent
avoir une terminologie différente
ü Exemple : différents format des adresses, plusieurs manières d’identifier
les clients, différentes méthodes de calculer le taux d’intérêt, choix de clé
primaire (CIN ou CNE), etc.
ü Apres l’implémentation de la BD, la communication est améliorée entre les
parties de l’organisation.
ü Par conséquent, une BD peut unifier une organisation en établissant un
vocabulaire commun.
21
 Phases de Développement d’une BD

Modélisa.on Conceptuelle
Données de Données
Nécessaire
ERD

Conception Logique de la
Base de Données

Tables

Concep.on Physique de la Schéma Interne,

Base de Données DB

22
Nota5on pour les Diagrammes

En5té - Associa5on
 Objectifs
• ObjecKfs : comprendre la notaKon

ü EnKté type (EnKty Type)

ü AssociaKon (RelaKonship)

ü AOributs (AOributes)

ü Cardinalités (CardinaliKes)

ü UKlisé une notaKon correct

ü Expliquer la différence entre un ERD et un diagramme de BD relaKonnelle

• La modélisaKon des données est un challenge (Rappel)

24
 Symboles de Bases
Entity Type Entity Type
symbol Relationship name
symbol

Course Offering
Primary Key CourseNo OfferNo
Has
CrsDesc OffLocatio n
CrsUnits OffTime
Attributes
Relationship
name

ü Course to Offering (when we offer the course, etc.): Has, Provides

ü Offering to Course: IsProvidedFor
25
 En:té type (En:ty Type)
• Collec?on de choses intéressantes : personnes, endroits, objets,
évènements, etc.

• Con?ent des aKributs : comme les colonnes

• Clé primaire (Primary key)

• En#té : instance ou membre d’une en?té type.

• Exemple : les deux en?tés « Base de données » et « Structure de

données » sont des instances de l’en?té type “Course”.
26
 Associa1on (Rela1onship)
• Nommé association entre les entités: le nom est significative (il donne plus de
statut)

• Liaison entre deux entités types (plus de deux entités types dans certains cas)

• Bidirectionnelle:

ü Peut être utilisé pour naviguer dans les deux sens

ü Les verbes sont souvent utilisés pour nommer une association

27
 Attributs (Attributes)

ü Propriétés des en?tés types ou associa?ons

ü Type de données pour indiquer le type des valeurs et les opéra?ons

autorisées sur l’aKribut

ü Ajouté à l’intérieur d’une en+té type ou au dessous de l‘associa+on

28
 Cardinalités (1)
Course Offering
Course1 Offering1

Diagramme Course2 Offering2

d’instance
Course3 Offering3

Offering4

ü Un “Course” est lié au minimum à 0 “Offering” et maximum à plusieurs “Offering”

ü Un “Offering” est lié exactement à un seul “Course”

29
 Cardinalités (2)
• Définition

ü Une contrainte sur le nombre des entités participant dans une association

ü Indique les cardinalités minimum et le maximum dans les deux sens

• Diagramme d’instance

ü Indique les occurrences des entités type

ü Très utile pour la compréhension des associations

ü Les lignes montre les associations entre les entités

30
Hi my name is Crow, I will be with you friend throughout this part of the
course

Crow’s foot
31
 Nota:on des Cardinalités (1)
Perpendicular line: Crow's foot: many
one cardinality cardinality
Inside symbol:
minimum cardinality

Course Offering
CourseNo Has OfferNo
CrsDesc OffLocation
CrsUnits OffTime

Circle: zero
Outside symbol: cardinality
maximum cardinality

ü Course is related to a min of 0 and max of many offerings

ü Offering is related to a min of 1 and max of 1 courses (exactly one)
32
 Notation des Cardinalités (2)
• Symboles

ü Ovale: veux dire 0

ü Ligne Perpendiculaire : veux dire 1

ü Crow's foot: veux dire plusieurs (0 or more)

• Emplacement

ü Symbole à l’intérieur : cardinalité minimale

ü Symbole à l’extérieur : cardinalité maximale

33
 Notation des Cardinalités (3)
Classifica(on Restrictions des Cardinalités

Obligatoire Cardinalité minimale ≥ 1 (Existence dependency)

Optionnel Cardinalité minimale = 0

Valeur unique Cardinalité minimale = 1

1-M (one to many) Cardinalité maximale = 1 dans un sens; Cardinalité maximale > 1 dans l’autre
sens

M-N (many to many) Cardinalité maximale > 1 dans les 2 sens

1-1 (one to one) Cardinalité maximale = 1 dans les 2 sens

ü Dépendance de l’existence (Existence dependency) : une entité qui ne peut pas exister
sans l’existence d’une autre entité. Une association obligatoire produit la “dépendance
de l’existence”.
34
 Conclusion
• Modélisation des données

ü Compétence importante dans la conception des BDs

ü Comprendre la notation avant de l’utiliser

• La notation “Crow’s Foot ERD” est largement utilisée

• Faire la différence entre la notation ERD et celle du Modèle relationnel

• Comprendre la notation ERD est un prérequis pour son application sur les
problèmes de l'entreprise
35
 What’s Next?

ü Autre type d’associaDons

ü Rappel sur la notaDon ERD

ü La concepDon logique des bases de données

ü Règles de conversion

36
Notation pour les Diagrammes
Entité - Association

Part 3: Type des Associa:ons I

 Objectifs
• Compréhension profonde de la notation ERD
• Expliquer un exemple utilisant le concept “identification dependency”
• Appliquer la relation d’équivalence entre l’association M-N et l’entité-type
associative
• Se familiariser avec les associations spécialisées en minimisant les erreurs de
conception
• Associations spécialisées: “identification dependency”, association M-N avec des
attributs, l’association M-way,
• Sources communs d’erreurs
38
 Iden:fica:on Dependency
Identification Dependency Symbols:
Ÿ Solid relationship line for identifying
relationships
Ÿ Diagonal lines in the corners denote
weak entities.

Building
Room
BldgID
BldgName Contains RoomNo
BldgLocation RoomCapacity

ü L’idenKficaKon de l’enKté type « Room » est enKèrement dépendante de l’enKté type

« Building »
39
 Identification Dependency - Concept

• Quelques enDtés types empruntent une parDe ou la totalité du PK

• Similaire au FK qui est parDe d’un PK dans un modèle relaDonnel
• EnDtés liées: contenance physique
– Une chambre est physiquement contenue dans un bâ6ment
– L’iden6fica6on de la chambre con6ent celle du bâ6ment

• Autres exemple: pays-états ou région

40
 Identification Dependency - Symbols

• Entité faible (weak entity)

ü Emprunte une partie ou la totalité de PK

ü Lignes diagonales dans les coins

41
 Iden1fica1on Dependency - Example

• La clé primaire d’une chambre est la combinaison de RoomNo (clé local)

et BuildingID (clé emprunté)

• La cardinalité d’un entité faible dans l’association identifié doit être 1-1

• Une chambre ne peut exister sans l’existence d’un bâtiment associé

42
 M-N Rela:onships with ASributes

Offering
Course
Student OfferNo
CourseNo
StdNo EnrollsIn OffLocation
CourseLocation
StdName OffTime
EnrGrade
attribute of relationship

¤ Exemple
ü EnrGrade: grade recorded for a student in a par<cular course
ü Depends on the combina<on of Student and Course
ü EnrGrade is not part of the Student or Course en<ty types 43
 Associa:on M-N avec des ASributs

• Les associations sont les citoyens de première classe J

ü Possibilité d’avoir des attributs

ü Les attributs dépendent des deux entités types, et non pas une seule
entité

ü Une association 1-M avec des attributs nécessite une révision

44
 M-N Rela:onships with ASributes (II)
a) Provides relationship

Supplier Part
SuppNo Provides PartNo
SuppName PartName
Qty

b) Writes relationship

Author Book
AuthNo Writes ISBN
AuthName Title
AuthOrder
45
Notation pour les Diagrammes
Entité - Association

Part 3: Type des Associations II

 Nota:on ERD pour les Associa:ons Réflexives

a) manager-subordinate b) course prerequisites

Faculty
Professor Supervises Course PrereqTo
ProfNo
FacNo CourseNo
FacName CrsDesc
ProfName

47
 Nota:on ERD pour une Associa:on Réflexive

• Association liant une entité type à elle même

• Position des cardinalités est moins important: association nécessitant

la même entité type

• Sinon, le reste est le même pour une association réflexive.

• Point clé :

ü 1-M vs. M-N

ü Utiliser les diagrammes d’instance pour faciliter la tache

48
Diagrammes d’Instance pour une Association Réflexive
(a) Supervises (b) PreReqTo

Professor 1
Faculty1 IS300

IS320
Professor
Faculty2 2 Professor
Faculty33

IS480 IS460
Professor
Faculty4 4 Professor
Faculty55

IS461

a) manager-subordinate b) course prerequisites

Professor
Faculty Supervises Course PrereqTo
ProfNo
FacNo CourseNo
FacName CrsDesc
ProfName
49
Concep1on Logique d’une Base de
Données
 Objec5f

• Soit le schéma de la base de données Bibliothèque suivante :

ü Etudiant (NumEtd, NomEtd, AdresseEtd)
ü Livre (NumLivre, TitreLivre, NumAuteur, NumEditeur, NumTheme,
AnneeEdition) (confusion)
ü Auteur (NumAuteur, NomAuteur, AdresseAuteur)
ü Editeur (NumEditeur, NomEditeur, AdresseEditeur)
ü Theme (NumTheme, IntituléTheme)
ü Prêt (NumEtd, NumLivre, DatePret, DateRetour) (confusion)
– Comment établir un tel schéma ? 51
 Phases de Développement d’une BD - Rappel

Modélisation Conceptuelle
Données de Données
Nécessaire
ERD

Conception Logique de la
Base de Données

Tables

Conception Physique de la Schéma Interne,

Base de Données DB
 Symboles de Bases - Rappel
Symbole de
Symbole de Nom de l’EnKté
l’Entité Type
l’Association Type

Clé
Primaire

Attributs

Nom de
l’AssociaKon

ü Professor to Course : Teach

ü Course to Professor : IsTaughtBy
Buts et Etapes de la Concep1on
Logique d’une Base de Données
 Phases de Développement d’une BD

Données Modélisation Conceptuelle

Nécessaire de Données

ERD

Conception Logique de la
Base de Données

Tables

Concep.on Physique de la Schéma Interne,

Base de Données DB
 Règles de Conversion

Règle de
• Tables
l’Entité type

Règles d’une
AssociaKon • FKs dans les tables fils
1-M

Règles d’une • L’association est convertit

Association en table
M-N • PK = combinaison des FKs
 Exemple 1 – Associa:on 1-M

ü Convertir ce digramme ERD en modèle logique ?

ü Professor (professorID, pName, salary)

ü Course (courseID, courseName, enrollment, #professorID)

q CREATE TABLE Professor (…, PRIMARY KEY (professorID) )

q CREATE TABLE Course (…, PRIMARY KEY (courseID), FOREIGN KEY (professorID)
REFERENCES Professor, CONSTRAINT professorID NOT NULL)
q Pourquoi on a : “CONSTRAINT professorID NOT NULL” ?
 Exemple 2 – Association M-N

¤ Convertir ce digramme ERD en modèle logique ?

¤ Student (studentID, StudentName)
¤ Course (courseID, courseName, enrollment)
¤ EnrollsIn (studentID, courseID, EnrMark)
 Exemple 2 – Association M-N

q CREATE TABLE Student (…, PRIMARY KEY (StudentNo) )

q CREATE TABLE Course (…, PRIMARY KEY (CourseID) )

q CREATE TABLE EnrollsIn (…, PRIMARY KEY (StudentNo, CourseID), FOREIGN

KEY (StudentNo) REFERENCES Student, FOREIGN KEY (CourseID)
REFERENCES Course)

q Pourquoi on a pas : “CONSTRAINT … NOT NULL” ?

 Exemple Pratique
• Soit le schéma de la base de données Bibliothèque suivante :
ü Etudiant (NumEtd, NomEtd, AdresseEtd)
ü Livre (NumLivre, TitreLivre, NumAuteur, NumEditeur, NumTheme,
AnneeEdi<on)
ü Auteur (NumAuteur, NomAuteur, AdresseAuteur)
ü Editeur (NumEditeur, NomEditeur, AdresseEditeur)
ü Theme (NumTheme, In<tuléTheme)
ü Prêt (NumEtd, NumLivre, DatePret, DateRetour)

– Etablir le diagramme En<té-Associa<on correspondant

60
 Solution
ü Livre (NumLivre, TitreLivre, NumAuteur, NumEditeur, NumTheme, AnneeEdition)

ü Auteur (NumAuteur, NomAuteur, AdresseAuteur)

61
 Solu:on

ü Livre (NumLivre, TitreLivre, NumAuteur, NumEditeur, NumTheme, AnneeEdi6on)

ü Editeur (NumEditeur, NomEditeur, AdresseEditeur)

62
 Solu5on
ü Livre (NumLivre, TitreLivre, NumAuteur, NumEditeur, NumTheme, AnneeEdition)

ü Theme (NumTheme, IntituléTheme)

63
 Solution

ü Etudiant (NumEtd, NomEtd, AdresseEtd)

ü Livre (NumLivre, TitreLivre, NumAuteur, NumEditeur, NumTheme,

AnneeEdition)

ü Prêt (NumEtd, NumLivre, DatePret, DateRetour)

64
Solu8on

65
 Conclusion
• La conception logique des bases de données

• Règles de conversion

• Règle de conversion 1-M

• Règle de conversion M-N

66
End of Database Course J

Thank you

67