UKOnline

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.

Entité Airport
L'entité Airport représente un aéroport, caractérisé par un code unique, un nom, un pays et les coordonnées géographiques de son point central.

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.

Entité Station
L'entité Station représente une station de mesures de grandeurs physiques, dont le but est d'établir un niveau sonore perçu à une position donnée autour d'un aéroport donné.

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.

Entité Sensor
L'entité faible Sensor représente un capteur caractérisé par sa référence et qui est utilisé pour mesurer une grandeur physique, dans une unité donnée.

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.

Entités Physical quantity et Measure
L'entité faible PhysicalQuantity représente une grandeur physique mesurable dans une certaine unité et l'entité faible Measure représente une mesure avec la valeur et un timestamp qui lui sont associé.

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.

Association Monitors
L'association monitors représente le fait qu'un aéroport est surveillé par une ou des stations et qu'une station peut être impliquée dans la surveillance de un ou plusieurs aéroports.

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.

Association Has
L'association has représente le fait qu'une station est composée d'un ou des capteurs et qu'un capteur se trouve dans une et une seule station.

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$).

Association Measures
L'association measures représente le fait qu'un capteur est capable de mesurer une ou plusieurs grandeurs physiques et qu'une grandeur physique peut être mesurée par un ou plusieurs capteurs différents.

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$).

Association Takes
L'association takes représente le fait qu'une station peut faire plusieurs mesures de différentes quantités physiques.

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.

Modèle Entité-Association complet
Les données utilisées dans le cadre du système de surveillance des niveaux sonores aux alentours d'un aéroport peuvent se représenter par une modélisation entité-association composée de cinq entités liées par quatre associations.