Discussion :

[GlabGlab21]

Bonjour,

Pour un devoir en NoSQL mon professeur nous à fournis un dossiers contenant plus de 100 000 fichier '.log'.

Ici le lien pour télécharger le dossier contenant tout les fichiers.

Ci-joint un dossier contenant que 10 fichiers. 10 fichiers.zip

Devoir :

Pourriez-vous produire les éléments suivants :

Un MCD avec l’explication détaillée de votre modèle.
Pour chaque entité veuillez apporter le détail de chaque attribut ? (type, origine,….)
Créer les modèles suivants sur votre base SQL
Relationnel (Appelé un MPD)

Créer un programme avec le langage/outil de votre choix qui vous permet de transférer les fichiers vers votre base SQL en opérant les transformations nécessaires

Pourriez-vous répondre aux questions suivantes en se basant uniquement sur des requêtes SQL ?
Pour chaque aéroport fournir le nombre de départ ?
Fournir le nombre de vol entre deux aéroports.
Le prix le moins cher entre deux destinations et deux dates.
Le prix le moins cher entre deux destinations et intervalle de dates.
Le prix le moins cher entre deux destinations et deux dates en distinguant les vols directs et vol avec escales.
Le prix le moins cher entre deux destinations et intervalle en distinguant les vols directs et vol avec escales.
Présenter l’évolution des prix par jour de semaine entre deux dates.


---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


J'ai créer le modèle relationnel suivant sur ma base de données SQL:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
-- Table Places
CREATE TABLE Places (
    placeId INT PRIMARY KEY,
    parentId INT,
    name NVARCHAR(255),
    type NVARCHAR(50),
    iata NVARCHAR(10),
    coordinates NVARCHAR(255)
);
 
-- Table Itineraries
CREATE TABLE Itineraries (
    itineraryId INT PRIMARY KEY,
    sessionId NVARCHAR(255),
    duration INT,
    totalPrice DECIMAL(18, 2),
    currency NVARCHAR(3),
    legs NVARCHAR(MAX), 
    placeId INT,  -- Clé étrangère vers la table Places
    agentId NVARCHAR(10)  -- Clé étrangère vers la table Agents
);
 
-- Table Legs
CREATE TABLE Legs (
    legId INT PRIMARY KEY,
    itineraryId INT,  -- Clé étrangère vers la table Itineraries
    departurePlace INT,
    arrivalPlace INT,
    departureTime DATETIME,
    arrivalTime DATETIME,
    carrier NVARCHAR(50),
    segmentId INT
);
 
-- Table Segments
CREATE TABLE Segments (
    segmentId INT PRIMARY KEY,
    legId INT,  -- Clé étrangère vers la table Legs
    carrier NVARCHAR(50),
    origin INT,
    destination INT,
    departureTime DATETIME,
    arrivalTime DATETIME
);
 
-- Table Agents
CREATE TABLE Agents (
    agentId NVARCHAR(10) PRIMARY KEY,
    name NVARCHAR(255),
    type NVARCHAR(50),
    imageURL NVARCHAR(MAX),
    feedbackCount INT,
    rating DECIMAL(3, 2),
    customerService INT,
    reliablePrices INT,
    clearExtraFees INT,
    easeOfBooking INT,
    other INT,
    isOptimisedForMobile BIT,
    allianceid INT  -- Clé étrangère vers la table Alliances
);
 
-- Table Alliances
CREATE TABLE Alliances (
    allianceId INT PRIMARY KEY,
    name NVARCHAR(255),
    memberAirlineId INT
);

J'ai pu remarqué que les données dans les fichiers '.log' sont au format JSON et quelques un en HTML.
J'ai pensé à créer un programme qui transforme les données afin de créer des fichier csv qui correspondent à mes tables que je pourrais ensuite utiliser pour remplir mes tables avec ssis. Mais je ne sais pas comment créer le programme.

J'ai besoin d'aide pour créer le programme, je ne sais pas comment faire.

Je vous remercie d'avance pour votre aide.

[escartefigue]

bonjour,

Pourriez-vous produire les éléments suivants :

Un MCD avec l’explication détaillée de votre modèle.
Pour chaque entité veuillez apporter le détail de chaque attribut ? (type, origine,….)

Vous n'avez pas communiqué votre MCD, or c'est la première des choses à faire, le modèle tabulaire en dépend.
De plus, dans votre script SQL, il n'y a aucune contrainte d'intégrité (aucune référence de clef étrangère). C'est la porte ouverte à bien des incohérences.
Si vous utilisez un logiciel de modélisation pour réaliser votre MCD, la dérivation du modèle tabulaire (MLD et MPD) est automatique, et elle inclut les contraintes d'intégrité, ce qui évite ce type d'erreurs et bien d'autres, et facilite la maintenance.

L'étape de chargement des tables par programme dépend évidemment de la stabilisation du modèle de données, donc c'est prématuré de s'en préoccuper pour l'instant

[GlabGlab21]

Bonjour,

Merci pour votre réponse.

voici mon MCD :




J'ai essayé de faire un MCD le plus détaillé possible. Est-il correcte ?

[Paprick]

Bonjour,

Plusieurs remarques avant d'aller plus loin :

• Votre MCD ne semble pas correspondre au schéma relationnel de votre premier message.
• Votre MCD n'en est d'ailleurs pas un... il s'agit d'un MLD graphique (présence des clés étrangères, représentation crow's foot).
• Vos ID sont des "varchar", ce qui est fortement déconseillé.

Tant que cette étape, avec un véritable MCD, n'est pas correcte réalisée, il parait difficile d'aller plus loin...

Bonne continuation !

[GlabGlab21]

Bonjour,

Je ne pense pas avoir compris comment se constitue un MCD, pourriez vous m'expliquer comment faire. Afin que je puisse réaliser un MCD correct.

[escartefigue]

Comme il s'agit d'un devoir, il est très probable que la notion de MCD soit expliquée dans vos cours.

Cela étant dit, voyez dans ce fil de discussion

La réponse n° 5 propose un MCD réalisé avec Power AMC (payant)
Les réponses n° 8 et 17 proposent des MCD réalisés avec Looping (excellent et gratuit, et que vous pouvez télécharger ICI)

[GlabGlab21]

Bonjour,

j'ai produit cet MCD



Est-il correct ?

[escartefigue]

Bonjour,

Un MCD n'est valide ou pas qu'en regard d'un cahier des charges stipulant des règles de gestion (voyez comment les formuler dans le fil de discussion que j'ai communiqué plus haut).
Comme vous n'avez communiqué aucune règle de gestion, on ne peut que faire que des remarques d'ordre général.



Choix de la langue :
Soit le projet est national, auquel cas on choisit le français comme unique langue pour la documentation projet (cahier des charges, spécifications détaillées...) y compris le MCD, soit le projet est international et on utilise en ce cas le plus souvent l'anglais, voire une autre langue dans certains contexte. En tout cas, il ne faut pas mélanger du français et d'autres langues. Là, vous avez nommé certains types d'entité en français (prix, agent, compagnie) d'autres en anglais (itineraries, pricing_options...), ça ne va pas. Il en va de même pour les attributs bien sûr.



Nom des types d'entité et d'associations
L'usage est d'utiliser le singulier pour les types d'entités : AGENT plutôt que AGENTS, car il s'agit de types d'entité qui bien évidemment caractérisent plusieurs occurrences d'entités (et donc plusieurs lignes dans la table résultante au stade SQL°. Et il est préférable d'utiliser des verbes à l'infinitif pour nommer les associations, car l'association matérialise les interactions mentionnées dans les règles de gestion entre les types d'entités.

Par exemple, plutôt que de modéliser :
[itineraries] 1,n --- (prix) --- 1,n [pricing_option]

On modélisera plutôt :
[ITINERAIRE] 1,n --- (tarifer) --- 0,n [OPTION_TARIFAIRE]

Notez la cardinalité 0,n plutôt que 1,n coté [OPTION_TARIFAIRE], car en général, coté typologies, on autorise d'enregistrer une occurrence même si celle-ci n'est pas utilisée à un instant "t".
Ici, il est probable qu'une option tarifaire puisse être présente en base alors qu'aucun itinéraire ne l'utilise à un instant "t" (option utilisée par le passé ou qui sera utilisée dans le futur).

Attention aussi à l'orthographe : arrivée s'écrit avec un "e", mais cette erreur devrait disparaitre si vous utilisez un infinitif comme recommandé



Choix du type de données
Le VARCHAR n'est pas recommandé pour un identifiant : à cause de l'intégrité référentielle, l'identifiant se propage en cascade dans les entités associées sous forme de clefs étrangères (foreign keys). Or, le varchar est le plus souvent associé à des valeurs signifiantes susceptibles de changer. Ce faisant, toute modification d'un identifiant provoquera des mises à jour en masse dans les tables liées (à cause des FK) ce qui plombe la BDD inutilement. De plus, le varchar est beaucoup plus encombrant à nombre de valeurs distinctes égal que de l'intéger. Enfin, le VARCHAR est sensible à la collation, contrairement à l'integer. C'est pourquoi on choisit le plus souvent un type integer pour tous les identifiants (voir small integer ou big integer en fonction du nombre de lignes maxi estimé).
Par ailleurs, on voit que la quasi totalité des attributs sont de type varchar(50). La longueur doit être adaptée au réel besoin.



Un type d'entité ne doit avoir qu'un seul identifiant
Dans le type d'entité [LEGS], on trouve à la fois des attributs id (déclaré comme identifiant puisque souligné), origin_place_id et destination_place_id. Ces deux derniers attributs sont les clefs étrangère, ils n'ont rien à faire dans le MCD.
La notion de clef étrangère n'apparait qu'au stade tabulaire (MLD et MPD) et puisque vous utilisez un logiciel de modélisation, en l'occurrence Looping, les clefs étrangères sont automatiquement déclarées par l'outil.
Il en va de même dans les entités-type [SEGMENTS] et [PLACES]



Pensez à communiquer vos règles de gestion pour qu'on puisse commenter plus en détail votre MCD (les fichiers que vous avez joints sont inutilisables).

[SQLpro]

Je rajouterais qu'il faut aussi éviter de donner des noms identiques aux différents attributs. par exemple id, id, id, id, id...... Que se passera t-il lors d'une jointure ???
Dans les bonnes pratique, chaque information stockée doit avoir un nom unique au sein du SI !

A +

[GlabGlab21]

Bonjour,

On ne m'a indiqué aucune règle de gestion, seul les fichiers on était fournis et l'énoncé du devoir.

On observant les fichiers j'ai pu remarqué que :

Chaque itinéraire est associé à un ou plusieurs leg qui correspond au trajet entre le point de départ original et le point d'arrivé final.

Un leg peut être divisé en un ou plusieurs segment qui représentent des portions spécifiques du trajet avec des points de départ et d'arrivé.

Un itinéraire peut avoir des prix différents.

Un itinéraire peut avoir un ou plusieurs agent.

[escartefigue]

J'ajoute aussi que les associations du MCD ne doivent jamais avoir d'identifiant.
Il ne faut pas confondre le modèle conceptuel (le MCD) et les modèles logiques (MLD) ou physiques (MPD). C'est dans les MLD et MPD que les identifiants sont propagés sous forme de clefs étrangères dans les tables issues des associations et dans les tables issues des types d'entité coté 1 des associations.