Modèle entité-association
Afin d'analyser les données qu'il va falloir stocker au sein de notre application, et pour établir les liens qui seront faits entre ces dernières, on va d'abord réaliser un modèle entité-association du système. Ce type de modèle permet de réaliser une description de haut niveau de modèles conceptuels de données, en distinguant les objets de gestion, appelés entités, et les relations entre ces derniers, appelées associations.
Entité
Pour rappel, le système que l'on veut mettre en place est une plateforme de surveillance des niveaux sonores aux alentours d'un aéroport. Pour cela, on va disposer d'une série de stations, tout autour de l'aéroport, qui vont en permanence mesurer la température et l'humidité relative de l'air et tester si le niveau sonore dépasse un certain seuil fixé, grâce à différents capteurs. On va donc devoir manipuler au moins quatre entités pour ce projet : l'aéroport, les stations, les capteurs et les mesures.
Le modèle entité-association que l'on va produire a pour but de décrire précisément ces quatre entités, avec les attributs qui les définissent, ainsi que les relations entre elles, comme le fait qu'un capteur se trouve dans une station ou le fait qu'une station donnée prend des mesures pour un ou plusieurs aéroports, par exemple.
Aéroport
Notre système pouvant s'appliquer à n'importe quel aéroport, on va définir une entité Airport
pour représenter ce concept. La figure 1 montre cette entité, qui est définie par quatre attributs. De nombreuses notations peuvent être utilisées pour réaliser une modélisation entité-association et on va principalement utiliser la notation originale proposée par Peter Chen, le créateur de cette modélisation.
Chaque aéroport est identifié de manière unique par un code (nous utiliserons le code IATA dans ce cours, un code international composé de trois lettres identifiant de manière unique les aéroports, mais également utilisé pour des gares ferroviaires et pour les entités de manutention des aéroports), représenté par un attribut clé et est caractérisé par son nom et le pays dans lequel il se trouve, représentés par les attributs Name
et Country
. Enfin, ses coordonnées géographiques sont représentées par l'attribut composite Location
, formé de la latitude et de la longitude de son centre.
Par exemple, le code IATA « BRU » désigne l'aéroport national belge, situé à Zaventem, et qui a pour nom commercial Brussels Airport, depuis le 19 octobre 2016. Son point central est situé à 50°54'05" de latitude nord et 4°39'04" de longitude est.
Station
Autour de chaque aéroport pour lequel le système de surveillance des niveaux sonores sera déployé, des stations seront installées. Le rôle de ces dernières consiste à mesurer des grandeurs physiques et à envoyer régulièrement les données collectées vers un serveur central. La figure 2 montre l'entité Station
représentant ce concept. Chaque station est caractérisée par un nom unique, représenté par l'attribut clé Name
, et par sa position géographique représentée par l'attribut composite Location
, formé par une latitude et longitude, comme pour l'aéroport.
On pourrait, par exemple, avoir une station nommée « BRU-S01 » qui serait située dans la commune de Steenokkerzeel, près de l'école communale à 50°54'31" de latitude nord et 4°30'49" de longitude est.
Capteur
Chaque station est équipée d'un ou de plusieurs capteurs. Dans notre cas, il y en aura au moins trois, pour mesurer la température et l'humidité relative de l'air et pour détecter si le niveau sonore ambiant dépasse un seuil configuré. Chaque capteur est simplement caractérisé par sa référence propre. La figure 3 montre l'entité faible Sensor
qui permet de représenter les capteurs d'une station. Il n'est pas possible d'identifier un capteur de manière unique, d'où le fait que l'entité ne possède pas d'attribut clé et qu'elle est faible. On pourrait, par exemple, avoir un capteur dont la référence est LM35.
Grandeur physique et mesure
Enfin, il reste deux entités à définir, montrées sur la figure 4. Chaque capteur va pouvoir mesurer une ou plusieurs grandeurs physiques, chacune caractérisée par un nom et une unité. L'entité PhysicalQuantity
représentant ce concept est caractérisée par l'attribut clé Name
et l'attribut Unit
. Chaque capteur prend des mesures représentées par l'entité faible Measure
, caractérisée par les deux attributs Timestamp
et Value
indiquant le moment où la mesure a été faite et sa valeur.
On aurait, par exemple, la température ambiante de l'air à mesurer en degrés Celsius comme grandeur physique et une mesure faite le samedi 16 mai 2020 à 16h52 donnant une valeur de 17 °C.
Association
Une fois toutes les entités définies, il faut établir les liens qu'il y a entre elles, en définissant des associations. Quatre associations lient les entités précédemment définies et on va maintenant les définir et établir leurs propriétés et caractéristiques.
Surveillance
La première association lie l'entité Airport
à l'entité Station
et représente le fait qu'un aéroport est surveillé par des stations. La figure 5, où les attributs des entités ne sont pas montrés pour raison de clarté, montre l'association binaire monitors
en question. Un aéroport pouvant être surveillé par une ou plusieurs stations ($N$) et une station pouvant être impliquée dans la surveillance d'un ou plusieurs aéroports ($M$), on a une association de type plusieurs-à-plusieurs.
Constitution
Les entités Station
et Sensor
sont liées par une association indiquant qu'une station est composée d'une série de capteurs. La figure 6 montre l'association binaire has
, de type un-à-plusieurs, car une station peut être composée d'un ou plusieurs capteurs ($N$), mais un capteur donné ne peut se trouver que dans une et une seule station ($1$).
De plus, il s'agit d'une association faible, car l'existence de l'une des entités dépend de celle de l'autre entité. Un capteur ne peut en effet exister sans station et les capteurs peuvent être uniquement identifiés au sein d'une même station, par leur référence. Enfin, l'association est totale des deux côtés, car toutes les stations et tous les capteurs du système doivent être impliquées dans cette association.
Mesure
Il y a aussi un lien entre les capteurs et les grandeurs physiques, représenté par une association measures
reliant les entités Sensor
et PhysicalQuantity
. La figure 7 montre cette association binaire, de type plusieurs-à-plusieurs, représentant le fait qu'un capteur est capable de mesurer une ou plusieurs grandeurs physiques ($N$) et qu'une même grandeur physique peut-être mesurée par un ou plusieurs capteurs ($M$).
Prise de mesure
Enfin, la dernière association, un peu plus complexe, relie les trois entités Station
, Measure
et PhysicalQuantity
. La figure 8 montre cette association ternaire faible takes
, représentant le fait que les stations prennent différentes mesures correspondant à des grandeurs physiques.
Les cardinalités ont été déterminées sachant qu'une station donnée peut avoir plusieurs mesures pour une même grandeur physique ($N$), qu'une mesure faite au sein d'une station ne concerne qu'une et une seule grandeur physique ($1$) et qu'une même mesure d'une grandeur physique peut être prise par plusieurs stations différentes ($M$).
Modèle complet
La figure 9 montre le diagramme entité-association complet du système de surveillance des niveaux sonores aux alentours d'un aéroport, suivant la notation de Chen. Ce modèle se compose de cinq entités, dont deux faibles qui ne peuvent pas exister indépendamment des autres, et de quatre associations, dont deux faibles.