Modèle de base de données spatiales multiple SQL Server

D’origine :

Le modèle de base de données spatiales multiple d'une géodatabase dans SQL Server représente le mode d'implémentation initial des géodatabases ArcSDE dans SQL Server. Ce modèle est encore pris en charge, mais ESRI recommande d'utiliser le modèle de base de données spatiales unique, dans lequel toutes les tables de géodatabase sont stockées dans une seule base de données SQL Server.

Pour stocker des données spatiales dans une géodatabase ArcSDE, un ensemble de tables, de procédures stockées, de vues et de fonctions (collectivement connues sous le nom de référentiel ArcSDE) doit être présent. L'ensemble des données définies par l'utilisateur et du référentiel ArcSDE associé constitue une géodatabase.

Avant ArcSDE 9, les géodatabases dans SQL Server étaient toujours stockées à l'aide du modèle de bases de données spatiales multiple. Pour ArcSDE 9 et versions ultérieures, vous devez utiliser le modèle de base de données spatiales unique. Toutefois, le modèle de base de données spatiales multiple étant toujours pris en charge (bien que déconseillé), nous en fournissons une description ci-dessous.

Dans le modèle de base de données spatiales multiple, le référentiel ArcSDE est stocké dans une base de données appelée sde. Les données définies par l'utilisateur, telles que les classes d'entités, les données raster et les tables non spatiales, résident dans d'autres bases de données. Le référentiel ArcSDE de la base de données sde stocke des références indiquant l'emplacement de toutes les données définies par l'utilisateur pour une certaine instance ArcSDE. La base de données sde et toute autre base de données associée forment une seule géodatabase. Ce modèle de stockage de données est appelé modèle de base de données spatiales multiple parce qu'il prend plusieurs bases de données SQL Server pour faire une géodatabase ArcSDE.

Le modèle de base de données spatiales unique présenté dans la section précédente est la méthode recommandée pour le stockage des géodatabases. Toutefois, si vous souhaitez utiliser le modèle de base de données spatiales multiple, vous trouverez ci-dessous les règles et principes pour son utilisation et sa création.

Règles d'utilisation d'une instance de base de données spatiales multiple

• La base de données qui stocke les métadonnées ArcSDE doit être nommée sde. Les bases de données supplémentaires stockant des données définies par l'utilisateur peuvent porter n'importe quel nom conforme aux règles SQL Server concernant les identifiants et ne commencent jamais par un numéro.
• Chaque instance de SQL Server ne peut héberger qu'une seule instance de base de données spatiales multiple. Les noms de base de données SQL Server doivent être uniques et ne peuvent donc prendre en charge qu'une base de données nommée sde. Si vous souhaitez stocker plusieurs géodatabases dans la même instance de SQL Server, vous pouvez avoir une instance de base de données spatiales multiple et plusieurs instances de bases de données spatiales uniques.
• Dans les instances de bases de données spatiales multiples, le référentiel ArcSDE doit résider dans la structure sde. Ces instances ne prennent pas en charge les référentiels ArcSDE sur un schéma dbo. Vous trouverez sous Comparaison entre propriétaires de géodatabase dans SQL Server une présentation des deux types de structure pouvant être utilisées pour le référentiel de géodatabase ArcSDE.
• Les tables système de géodatabase ArcSDE doivent avoir pour propriétaire un utilisateur nommé sde. (Dans SQL Server 2005 ou versions ultérieures, veillez à ce que la structure par défaut de l'utilisateur sde soit aussi nommée sde.)
• L'utilisateur sde doit être autorisé à accéder à chaque base de données stockant des données ArcSDE définies par l'utilisateur.
• Tous les utilisateurs se connectant à cette instance de géodatabase doivent être ajoutés à la base de données sde, même si les données définies par l'utilisateur ne sont pas stockées dans cette base de données. Si un utilisateur a l'intention de stocker des données dans la base de données sde, il faut lui créer une nouvelle structure dans cette dernière. Là encore, le nom de l'utilisateur et le nom de la structure doivent être les mêmes.
• Lorsque vous vous connectez à l'une des bases de données, vous avez accès à toutes les classes d'entités de toute base de données à laquelle vous êtes autorisé à accéder, à condition que le paramètre CROSS_DB_QUERY_FILTER de la table SDE_dbtune soit défini sur 0. Toutefois, vous pouvez accéder uniquement aux tables non spatiales se trouvant dans la base de données spécifiée dans votre connexion à la base de données spatiales, quelle que soit la valeur sur laquelle est défini le paramètre CROSS_DB_QUERY_FILTER.
• Les requêtes entre bases de données sont autorisées et les vues ArcSDE peuvent référencer des données de plusieurs bases de données, à condition que le paramètre CROSS_DB_QUERY_FILTER de la table SDE_dbtune soit défini sur 0.
• Les instructions SELECT, INSERT, UPDATE, et DELETE (également connues sous le nom de langage de manipulation de données (DML)) peuvent être utilisées par-delà les limites des bases de données. Par exemple, si vous vous connectez à la base de données public_works, vous pouvez afficher et modifier des données de la base de données de planification. Toutefois, vous ne pouvez pas exécuter les instructions CREATE, ALTER, et DROP (DDL) par-delà les limites des bases de données.
• Lorsque vous vous connectez à une géodatabase de base de données spatiales multiple en passant par une connexion directe, vous devez spécifier la base de données à laquelle vous avez l'intention de vous connecter. Si vous vous connectez en passant par un service ArcSDE, la base de données sde est définie comme la base de données par défaut de la connexion, dans le registre de serveur ; vous n'avez donc pas à spécifier de base de données, à condition que le paramètre CROSS_DB_QUERY_FILTER de la table SDE_dbtune soit défini sur 0.
• La base de données sde et toute autre base de données associée forment globalement une seule géodatabase. Un ensemble de tables système de géodatabase ArcSDE prend en charge toutes les données définies par l'utilisateur qu'il référence. Par conséquent, les opérations de sauvegarde et de restauration doivent s'appliquer à la géodatabase entière. Si toutes les bases de données ne sont pas sauvegardées et restaurées simultanément, la géodatabase peut se corrompre.
• Les bases de données sde et autres bases de données associées doivent utiliser le même regroupement.
• Toutes les bases de données spatiales qui contiennent une colonne XML ArcSDE ou une colonne XML SQL Server native indexée doivent avoir leur propre catalogue de texte intégral.
• Pour obtenir la liste des autorisations nécessaires pour l'utilisateur sde et d'autres utilisateurs, reportez-vous à Autorisations utilisateur pour les géodatabases dans SQL Server.

Principes pour créer une instance de base de données spatiales multiple

Voici quelques principes à respecter pour créer une base de données permettant de stocker des données spatiales.

• Utilisez l'assistant de post-installation ArcSDE pour créer la base de données de stockage du référentiel ArcSDE. L'assistant crée la base de données sde, accorde l'accès à la connexion sde et installe les tables système ArcSDE. N'oubliez pas de nommer cette base de données sde.
• Attribuez aux fichiers de données une taille initiale élevée, puis utilisez SQL Server Management Studio pour augmenter l'incrément de croissance automatique de la base de données et du fichier journal des transactions. A ce stade, effectuez une sauvegarde initiale.
• Pour créer des bases de données supplémentaires qui stockent des données définies par l'utilisateur, utilisez des outils SQL Server tels que Management Studio. L'utilisateur sde doit être ajouté à chaque base de données supplémentaire que vous créez. Cet utilisateur n'a besoin d'aucune autorisation spéciale pour ces bases de données. Les autorisations sont accordées automatiquement à l'utilisateur sde lorsque des jeux de données sont créés ou inscrits comme versionnés.

Effectuer une migration du modèle de base de données spatiales multiple vers le modèle de base de données spatiales unique

Comme mentionné ci-dessus, le modèle de base de données unique est le modèle recommandé à utiliser pour les géodatabases. Si vous avez une géodatabase existante stockée grâce au modèle de base de données multiple et que vous voulez effectuer une migration vers le modèle de base de données unique, suivez les étapes ci-dessous :

1. Créez une sauvegarde complète de toutes les bases de données ArcSDE.
2. Créez une géodatabase du modèle de base de données unique à l'aide de l'assistant de post-installation. Vérifiez que vous utilisez l'assistant de post-installation de la même version. Par exemple, si vous utilisez le modèle de base de données multiple avec ArcSDE 9.1 et que vous souhaitez passer au modèle de base de données unique, exécutez l'assistant de post-installation 9.1 pour créer la géodatabase unique. Vérifiez également que vous effectuez ces étapes dans la même instance de SQL Server.
   Remarque :

   si vous utilisez actuellement ArcSDE 8.3, commencez par installer au moins la version 9, puis effectuez une migration vers le modèle de base de données unique.

3. Utilisez l'interface Catalog pour transférer les données vers votre nouvelle géodatabase associée au modèle de base de données unique.

   L'assistant de post-installation crée une base de données dans SQL Server. Créez un service ou établissez une connexion directe pour accéder à la nouvelle géodatabase. Démarrez ensuite ArcMap, ouvrez la fenêtre Catalogue et établissez une connexion à la fois avec l'ancien modèle de base de données multiple et avec le nouveau modèle de base de données unique. Ensuite, transférez les données entre les géodatabases en les copiant/collant, important, exportant ou en utilisant toute autre méthode de migration des données.

   Remarque :

   L'utilisateur qui est connecté à la nouvelle géodatabase au moment du transfert des données vers celle-ci devient propriétaire des données. Par conséquent, si vous souhaitez que chaque utilisateur reste propriétaire des mêmes données qu'auparavant, chacun doit transférer ses propres données.