Cette page décrit Calíope 1.5, la version que je construis en ce moment. La 1.4 est sur l'App Store pour Mac, iPad, iPhone, Apple Watch, Apple TV et Apple Vision Pro. Le changelog indique dans quelle version chaque fonction est arrivée.
Ajoute un bouton « Ouvrir dans Calíope » à chaque sujet. Ne fonctionne qu'avec l'app installée.
Visualisez les relations entre les tables d'une base de données.
Où le trouver : Espace de travail › Outils › ER
Ouvrez le Diagramme ER depuis la barre de navigation de l'espace de travail. Sélectionnez la base de données dans le sélecteur supérieur et Calíope chargera les tables avec leurs colonnes et les relations de clé étrangère existantes.
Le diagramme affiche les tables sous forme de nœuds avec les colonnes et les types de données. Les lignes entre les tables représentent les clés étrangères détectées sur le serveur.
SQL Server
Dans SQL Server, chaque schéma est une entrée du sélecteur (demo.dbo, demo.rrhh). Pour voir une clé étrangère qui passe d'un schéma à l'autre, ajoutez l'autre avec + BDD : la ligne entre les deux est tracée en ambre, comme entre deux bases.
Zoomer et dézoomer — sur macOS, la molette de la souris, un pincement à deux doigts sur le trackpad ou les boutons de la barre ; sur iPad, le pincement ou ces mêmes boutons. Le pourcentage entre le − et le + de la barre indique l'échelle courante, et les raccourcis sont ⌘−, ⌘+ et ⌘0. Les limites sont les mêmes sur les trois : de 18 % à 400 %, et le bouton s'éteint une fois la limite atteinte.
Déplacer le canevas — faites glisser sur une zone vide, sur les trois. Sur un nœud, le glissement déplace la table.
Revenir au cadrage — le bouton Ajuster à la fenêtre (⌘0) cadre toutes les tables. Le diagramme se recadre aussi tout seul à l'ouverture et lors d'un redimensionnement de la fenêtre.
Le bouton Disposition automatique réorganise les nœuds pour minimiser les chevauchements.
Dessinez une nouvelle relation de clé étrangère entre deux tables.
Où le trouver : Diagramme ER › clic droit › Créer une relation FK
Ouvrez le menu contextuel d'une table — clic droit sur macOS, appui long sur iPad — et sélectionnez Nouvelle relation FK…. Une boîte de dialogue s'ouvre pour choisir la table et la colonne source, ainsi que la table et la colonne cible. Après confirmation, Calíope exécute le ALTER TABLE … ADD FOREIGN KEY sur le serveur.
Uniquement sur macOS, en plus : maintenez ⌃ (Contrôle) et faites glisser d'une table vers la table cible ; une ligne élastique suit le geste et le relâchement ouvre ce même dialogue. Sur iPad, ce geste n'existe pas : la clé étrangère se crée depuis le menu contextuel.
Conservez la disposition que vous avez donnée au diagramme, une par base de données.
Où le trouver : Diagramme ER › Enregistrer la disposition
Cliquez sur Enregistrer la disposition dans la barre d'outils du Diagramme ER. L'endroit où vous avez fait glisser chaque table est conservé par base de données, donc chaque diagramme garde la sienne.
La prochaine fois que vous ouvrirez le diagramme de cette base, les tables reviennent là où vous les aviez laissées. Une table sans position enregistrée — celles d'une seconde base que vous venez d'ajouter avec + BDD, ou une table créée depuis — est disposée sur une grille à côté des autres, jamais par-dessus.
Dans la barre d'outils du Diagramme ER, le bouton Exporter propose deux formats : PNG (une image, prête à coller dans un document ou une conversation) et PDF (prêt pour l'impression ou la présentation). Chacun propose trois tailles, et le fichier est enregistré à l'emplacement que vous choisissez via la boîte de dialogue système.
Les mêmes formats figurent dans le menu contextuel du canevas, et sur macOS le diagramme peut aussi être imprimé avec ⌘P.
Consultez la structure complète d'une table directement depuis le diagramme.
Où le trouver : Diagramme ER › clic droit › Modifier la structure de la table
Ouvrez le menu contextuel d'un nœud de table dans le diagramme — clic droit sur macOS, appui long sur iPad — et sélectionnez Modifier la structure de la table. Un panneau s'ouvre affichant l'instruction CREATE TABLE complète de la table sélectionnée.
Mots-clés : DDL, CREATE TABLE, structure, voir table, show create, définition de table
Comparez deux bases de données du même serveur — tables, vues, routines, déclencheurs et événements — et générez le script de migration.
Où le trouver : Espace de travail › Outils › Comparaison de schémas
L'outil de comparaison de schémas (Schema Diff) analyse deux bases de données du même serveur et montre exactement ce qui a changé dans les tables, vues, procédures, fonctions et déclencheurs.
MySQLMariaDBAurora
Sous MySQL et MariaDB, il compare aussi les événements.
SQL Server
Sous SQL Server, chaque côté est un schéma d'une base (demo.dbo), et les deux peuvent se trouver dans des bases différentes du même serveur.
PostgreSQL
Sous PostgreSQL, chaque côté est un schéma de la base connectée (demo, ventas).
Ouvrir Schema Diff :
Cliquez sur Comparaison de schémas (icône de flèches opposées) dans la barre latérale. L'outil s'ouvre dans un nouvel onglet.
Utilisation de base :
1. Choisissez la Source et la Cible dans la barre supérieure. Le script modifie la source jusqu'à ce qu'elle corresponde à la cible : ce que seule la cible possède est créé dans la source, et ce que seule la source possède est supprimé.
2. Cliquez sur Comparer. Calíope lit la définition de chaque objet des deux côtés, telle que le serveur lui-même l'écrit.
3. Activez l'option Changements uniquement pour masquer ce qui coïncide.
4. Le rapport est groupé par type d'objet. Dépliez n'importe quelle ligne : une table modifiée montre, changement par changement, la définition actuelle et celle qui la remplacera ; une vue ou une routine modifiée montre les deux définitions complètes ; un objet nouveau ou supprimé montre son DDL.
5. Cliquez sur Copier le SQL pour tout le script, ou sur le bouton de copie d'une ligne pour ce seul objet.
6. Exécutez-le dans l'Éditeur SQL avec Exécuter le script. Avec le Mode sécurisé activé, le script s'arrête avant d'atteindre le serveur. Comparez ensuite de nouveau : les deux côtés doivent ressortir identiques.
MySQLMariaDBAurora
Les définitions sont le SHOW CREATE … de chaque objet, et l'éditeur comprend les blocs DELIMITER dans lesquels arrivent routines et déclencheurs.
SQL Server
Les définitions viennent du catalogue (sys.sql_modules pour les vues, routines et déclencheurs). Chaque vue, routine et déclencheur part dans son propre EXEC … sp_executesql, car T-SQL le veut seul dans son lot : le script s'exécute donc sans lignes GO.
PostgreSQL
Les définitions sont celles que le serveur écrit avec pg_get_viewdef, pg_get_functiondef et pg_get_triggerdef.
Ce qui est généré pour les tables :
MySQLMariaDBAurora
- Un CREATE TABLE IF NOT EXISTS complet pour celles qui manquent dans la source, avec colonnes, index et options.
- DROP TABLE IF EXISTS pour celles qui sont en trop.
- ALTER TABLE avec ADD/DROP/MODIFY COLUMN, en conservant le type, la nullabilité, la valeur par défaut, le commentaire, le jeu de caractères et l'expression d'une colonne générée.
- Ajouts et suppressions de clé primaire, d'index et de contraintes CHECK, ainsi que les changements d'options (ENGINE, DEFAULT CHARSET, COLLATE, ROW_FORMAT, COMMENT).
SQL Server
- IF OBJECT_ID(…) IS NULL CREATE TABLE pour celles qui manquent dans la source, avec colonnes, clés et contraintes, et un CREATE INDEX pour chaque index.
- DROP TABLE IF EXISTS pour celles qui sont en trop.
- ALTER TABLE avec ADD, ALTER COLUMN et DROP COLUMN ; avant de supprimer une colonne, le script supprime la contrainte de valeur par défaut qui en dépend.
- Ajouts et suppressions de clé primaire, d'index et de contraintes CHECK.
PostgreSQL
- CREATE TABLE IF NOT EXISTS pour celles qui manquent dans la source, avec colonnes et contraintes, et un CREATE INDEX pour chaque index.
- DROP TABLE IF EXISTS pour celles qui sont en trop.
- ALTER TABLE avec ADD COLUMN, DROP COLUMN et ALTER COLUMN … TYPE, SET/DROP NOT NULL et SET/DROP DEFAULT.
- Ajouts et suppressions de clé primaire, d'index et de contraintes CHECK, et le commentaire de la table (COMMENT ON TABLE).
Ce qui est généré pour le reste :
Une vue ou une routine ne se corrige pas par morceaux : si sa définition diffère, le script la refait à partir de la cible, en réécrivant les références au schéma d'origine pour qu'elle pointe au bon endroit.
MySQLMariaDBAurora
Il la refait avec DROP + CREATE.
SQL Server
Il la refait avec CREATE OR ALTER, qu'acceptent les vues, procédures, fonctions et déclencheurs.
PostgreSQL
Il la refait avec CREATE OR REPLACE ; un déclencheur ou une vue matérialisée, qui ne l'ont pas, sont supprimés puis recréés.
Ordre du script :
D'abord les tables ; ensuite les clés étrangères, dans leur propre bloc, car lorsque plusieurs tables sont créées l'ordre alphabétique ne respecte pas les dépendances ; puis les autres objets par type, chaque type ordonné par dépendances — une vue construite sur une autre est émise après elle.
MySQLMariaDBAuroraSQL Server
Avant le premier objet qui n'est pas une table, le script fixe la base active avec un USE.
PostgreSQL
Avant les tables viennent les types propres du schéma, avec lesquels leurs colonnes sont déclarées.
Ignoré à dessein :
MySQLMariaDBAurora
Le compteur AUTO_INCREMENT, qui avance à chaque insertion et ne coïncide jamais entre deux copies.
SQL ServerPostgreSQL
La valeur actuelle d'une colonne d'identité, qui avance à chaque insertion et ne coïncide jamais entre deux copies.
Ce qui n'est pas couvert :
Les colonnes d'une table existante ne sont pas réordonnées, et une colonne renommée apparaît comme une suppression suivie d'un ajout. Les vues, routines et déclencheurs sont comparés textuellement : un simple changement de mise en forme compte comme une différence.
MySQLMariaDBAurora
Un changement de partitionnement est détecté et signalé, mais jamais traduit en SQL : repartitionner réécrit toute la table. Un changement de DEFINER compte aussi comme une différence, et sous MariaDB le DDL d'un déclencheur est le texte littéral avec lequel il a été écrit. Un événement dont l'heure de début diffère est également différent, car cette heure fait partie de sa définition.
PostgreSQL
Les types propres — ENUM, domaines, types composites — sont comparés comme une vue, dans leur propre groupe Types. Le script crée ceux qui manquent avant les tables qui les utilisent et supprime tout à la fin ceux que seule la source possède. Un ENUM qui a seulement gagné des étiquettes à la fin est mis à jour avec ALTER TYPE … ADD VALUE ; tout autre changement d'un type reste dans le script comme une note à appliquer à la main, car recréer un type utilisé oblige à réécrire chaque colonne qui l'utilise. Les types créés par une extension, comme ceux de PostGIS, sont laissés de côté : c'est son CREATE EXTENSION qui les apporte.
Vérifiez toujours le script avant de l'exécuter en production.
Cas d'usage typique :
Avant un déploiement, comparer la production (source) avec le schéma de développement (cible) : le script amène la production à ce que le développement possède déjà, sans l'écrire à la main.
Disponible sur macOS, iPad et iPhone.
Mots-clés : schema diff, comparer, schéma, alter table, migration, différences, ADD COLUMN, DROP COLUMN, MODIFY COLUMN, SHOW CREATE TABLE, CREATE TABLE, index, clés étrangères, partitionnement, modifications uniquement
ERD multi-base : visualiser les relations inter-bases
Ajoutez une deuxième base de données au canevas du diagramme ER pour visualiser les relations entre bases de données.
Où le trouver : Diagramme ER › + BD
Le Diagramme ER peut afficher les tables de deux bases de données simultanément sur le même canevas, y compris les clés étrangères qui traversent d'une base à l'autre.
Comment ajouter une deuxième base de données :
1. Avec le Diagramme ER ouvert, sélectionnez la BD principale dans le sélecteur gauche de la barre d'outils.
2. Cliquez sur le bouton + BD dans la barre d'outils pour ajouter une deuxième base de données.
3. Sélectionnez la deuxième BD dans le nouveau sélecteur qui apparaît.
4. Le canevas se met à jour automatiquement en affichant les tables des deux bases.
Codage couleur :
- En-tête bleu — tables de la BD principale.
- En-tête vert sarcelle (teal) — tables de la deuxième BD.
- Flèches orange — relations de clé étrangère traversant d'une base à l'autre.
- Flèches normales — relations au sein de la même base de données.
Prérequis pour les relations inter-bases :
Les clés étrangères doivent être déclarées dans information_schema. MySQL/MariaDB enregistre les FKs dans information_schema.KEY_COLUMN_USAGE. Si les relations inter-bases n'apparaissent pas, vérifiez que les FKs existent formellement sur le serveur (et ne sont pas de simples conventions de nommage).
Navigation et exportation :
Toutes les fonctionnalités du diagramme ER standard s'appliquent au canevas multi-base : zoom, panoramique, mise en page automatique, enregistrement de la mise en page, exportation PNG/PDF et affichage du DDL des tables. Consultez les rubriques Diagramme ER pour plus de détails.