Freigeben über

Überlegungen vor dem Umbenennen von Datenbankobjekten

  • Artikel

Bevor Sie in Microsoft Visual Studio Team Edition for Database Professionals ein Datenbankobjekt umbenennen, sollten Sie die folgenden Punkte bedenken:

Verhindern von Datenverlusten beim Umbenennen von Spalten und Tabellen

Umbenennen von Spalten in Sichten

Auswirkungen von Buildfehlern

Auswirkungen auf Datengenerierungspläne

Auswirkungen auf Komponententests

Auswirkungen auf T-SQL-Skripts

Verhindern von Datenverlusten beim Umbenennen von Spalten und Tabellen

Wenn Sie ein Datenbankobjekt umbenennen, wird diese Änderung im Bereitstellungsskript, das beim Erstellen des Projekts generiert wird, übernommen. Beim Umbenennen einer Spalte oder Tabelle löscht das Skript das ursprüngliche Objekt mit dem ursprünglichen Namen und fügt die neue Spalte oder Tabelle mit dem neuen Namen hinzu. Wenn Sie diese Änderung in der vorhandenen Datenbank als Aktualisierung bereitstellen, gehen die Daten in der ursprünglichen Spalte oder Tabelle verloren.

Sie können steuern, ob die ursprüngliche Spalte oder Tabelle gelöscht wird, indem Sie die entsprechende Option in den Projekteigenschaften festlegen. Öffnen Sie hierzu die Projekteigenschaften, klicken Sie auf die Registerkarte Erstellen, und aktivieren bzw. deaktivieren Sie das Kontrollkästchen DROP-Anweisungen für Objekte generieren, die sich in der Zieldatenbank, nicht aber im Datenbankprojekt befinden. Wenn Sie dieses Kontrollkästchen aktivieren, wird die drop-Anweisung für das alte Objekt im Bereitstellungsskript eingeschlossen, das beim Erstellen des Projekts generiert wird. Wenn Sie dieses Kontrollkästchen deaktivieren, wird die drop-Anweisung für das alte Objekt nicht im Bereitstellungsskript eingeschlossen, das beim Erstellen des Projekts generiert wird.

Um mögliche Datenverluste durch die drop-Anweisung zu verhindern, müssen Sie vorausschauend planen. Die folgenden Beispiele zeigen Möglichkeiten zum sicheren Migrieren der Daten:

  • Ersetzen der Drop/Add-Anweisung durch sp_rename-Anweisungen

  • Stellen Sie die drop-Anweisung nicht bereit. Sie verfügen über Kopien des alten und des neuen Objekts und können die Daten zwischen diesen verschieben. Sie können die Daten mithilfe einer select into-Anweisung oder einer anderen T-SQL-Anweisung manuell verschieben. Mit einem Sammelkopierprogramm, Data Transformation Services (SQL 2000) oder SQL Server Integration Services (SQL 2005) können Sie die Daten automatisch verschieben.

  • Bevor Sie die Änderung bereitstellen, verschieben Sie die Daten aus der alten Tabelle an einen temporären Speicherort (beispielsweise in eine Tabelle in einer anderen Datenbank). Stellen Sie die drop-Anweisung und die add-Anweisung bereit. Verschieben Sie die Daten vom temporären Speicherort in das neue Objekt. Sie können die Daten mithilfe einer select into-Anweisung oder einer anderen T-SQL-Anweisung manuell verschieben. Mit einem Sammelkopierprogramm, Data Transformation Services (SQL 2000) oder SQL Server Integration Services (SQL 2005) können Sie die Daten automatisch verschieben.

Weitere Informationen finden Sie unter Schützen von Daten während eines Umbenennungsvorgangs.

Umbenennen von Spalten in Sichten

Eine Sicht besteht aus einer Anweisung, die Spalten in Tabellen oder anderen Sichten auswählt. Die Tabellen, die in der Sicht verwendet werden, werden als Basistabellen oder zugrunde liegende Tabellen bezeichnet. Im folgenden Code wird z. B. eine Sicht auf Grundlage der Tabelle HumanResources.Employee erstellt:

CREATE VIEW dbo.vEmployeeTest
AS 
     SELECT EmployeeID, Title
       FROM HumanResources.Employee

Wenn Sie in einer Sicht eine Spalte umbenennen, wird die Spalte nicht in der zugrunde liegenden Tabelle umbenannt. Stattdessen wird dem Namen in der Sicht ein Alias zugewiesen, wie in den folgenden Beispielen dargestellt:

CREATE VIEW dbo.vEmployeeTest
AS 
     SELECT EmployeeID, Title AS JobTitle
       FROM HumanResources.Employee

CREATE VIEW dbo.vEmployeeTest (EmployeeID, JobTitle)
AS 
     SELECT EmployeeID, Title
       FROM HumanResources.Employee

Hinweis

Wenn in einer Sicht SELECT * zum Abrufen der Daten aus der zugrunde liegenden Tabelle verwendet wird, wird * zum Auflisten der einzelnen Spalten erweitert. Der umbenannten Spalte wird wie in den oben stehenden Beispielen ein Alias zugewiesen.

Wenn Sie die Spalte in der Sicht und in der zugrunde liegenden Tabelle umbenennen möchten, benennen Sie die Spalte in der Tabelle um. So wird die Spalte in der Sicht automatisch aktualisiert.

Auswirkungen von Buildfehlern

Wenn Sie ein Datenbankobjekt in Team Edition for Database Professionals umbenennen, wird versucht, andere Datenbankobjekte, Datengenerierungspläne, Komponententests und Skripts zu aktualisieren, die auf dieses Objekt verweisen. Wenn Sie in einem Datenbankprojekt arbeiten, können Sie eine Aktion ausführen, durch die ein Buildfehler verursacht wird, und dann eine andere Aktion ausführen, die den Buildfehler behebt. Sie könnten beispielsweise eine Tabelle löschen und dann eine Sicht aktualisieren, die von dieser Tabelle abhängt, um den Verweis auf die gelöschte Tabelle zu entfernen. Zwischen dem Löschen der Tabelle und dem Aktualisieren der Sicht enthält das Projekt Buildfehler.

Wenn Sie ein Datenbankobjekt umbenennen und das Projekt Buildfehler enthält, kann das Objekt trotzdem korrekt umbenannt werden. Es ist jedoch möglicherweise nicht möglich, alle Verweise auf das umbenannte Objekt korrekt umzubenennen. Wenn das Projekt Buildfehler enthält, wird eine Warnung im Dialogfeld Vorschau der Änderungen angezeigt. Wenn Sie fortfahren, wird das Objekt umbenannt, und Verweise werden so weit wie möglich aktualisiert. Wenn Sie den Vorgang abbrechen, können Sie zunächst die Buildfehler beheben und dann die Umbenennung erneut ausführen.

Im Dialogfeld Vorschau der Änderungen werden Warnungen für Folgendes angezeigt:

  • Buildfehler im Datenbankprojekt

  • Syntaxfehler in Skripts und Komponententests

  • Fehlerhafte Datengenerierungspläne

Auswirkungen auf Datengenerierungspläne

Wenn Sie ein Datenbankobjekt in Team Edition for Database Professionals umbenennen, wird versucht, Datengenerierungspläne zu aktualisieren, die auf dieses Objekt verweisen. Sie sollten jedoch Folgendes beachten:

  • Bevor Sie ein Objekt umbenennen können, müssen Sie alle Datengenerierungspläne speichern, die im Editor geöffnet sind. Wenn Datengenerierungspläne geöffnet sind und Sie versuchen, ein Objekt umzubenennen, werden Sie aufgefordert, erst die Pläne zu speichern. Wenn Sie fortfahren, werden alle geöffneten Datengenerierungspläne automatisch gespeichert und geschlossen, und der Umbenennungsvorgang wird fortgesetzt. Wenn Sie nicht fortfahren, wird der Umbenennungsvorgang abgebrochen. Alle geöffneten Datengenerierungspläne werden offen gelassen und nicht gespeichert.

  • Sie müssen Datengenerierungspläne, die datengebundene Datengeneratoren verwenden, manuell aktualisieren.

Weitere Informationen finden Sie unter Generieren von Daten mit Datengeneratoren.

Auswirkungen auf Komponententests

Transact-SQL (T-SQL)-Anweisungen in einem Komponententest verweisen normalerweise auf Objekte in der Datenbank, die im Komponententest in ValidationConnectionString und ExecutionConnectionString angegeben werden. Im Folgenden werden zwei Situationen aufgeführt, in denen dies nicht der Fall ist:

  • T-SQL-Anweisungen in einem Komponententest können auf Objekte in anderen Datenbanken verweisen.

  • T-SQL-Anweisungen in einem Komponententest können auf Objekte in der gleichen Datenbank, jedoch in unterschiedlichen Schemas verweisen (SQL Server 2005).

Wenn Sie ein Datenbankobjekt in Team Edition for Database Professionals umbenennen, wird versucht, die Komponententests in der Projektmappe zu aktualisieren, die auf dieses Objekt verweisen. In den zuvor genannten Fällen ist es möglicherweise nicht möglich, die Komponententests zu aktualisieren. Wenn Sie beim Umbenennen eines Datenbankobjekts die Komponententests aktualisieren möchten, müssen Sie sicherstellen, dass in den Komponententests die vollqualifizierten Namen der Objekte verwendet werden. Wenn Sie in den Komponententests vollqualifizierte Namen verwenden, kann das Umgestaltungsmodul diese aktualisieren, wenn ein Schemaobjekt umbenannt wird.

Weitere Informationen über Komponententests finden Sie unter Übersicht über Datenbankkomponententests.

Auswirkungen auf T-SQL-Skripts

T-SQL-Skripts in einem Datenbankprojekt verweisen normalerweise auf die Schemaobjekte in der Datenbank des Datenbankprojekts. Im Folgenden werden zwei Situationen aufgeführt, in denen dies nicht der Fall ist:

  • T-SQL-Anweisungen in einem Skript können auf Objekte in anderen Datenbanken verweisen.

  • T-SQL-Anweisungen in einem Skript können auf Objekte in der gleichen Datenbank, jedoch in unterschiedlichen Schemas verweisen (SQL Server 2005).

Wenn Sie ein Datenbankobjekt in Team Edition for Database Professionals umbenennen, wird versucht, die Skripts in der Projektmappe zu aktualisieren, die auf dieses Objekt verweisen. In den zuvor beschriebenen Fällen ist es möglicherweise nicht möglich, die Skripts zu aktualisieren. Wenn Sie beim Umbenennen eines Datenbankobjekts die Skripts aktualisieren möchten, müssen Sie sicherstellen, dass in den Skripts die vollqualifizierten Namen der Objekte verwendet werden. Wenn Sie in den Skripts vollqualifizierte Namen verwenden, kann das Umgestaltungsmodul diese aktualisieren, wenn ein Schemaobjekt umbenannt wird.

Weitere Informationen über Skripts finden Sie unter Arbeiten mit Datenbankskripts.

Sicherheit

Wenn eine Umgestaltungsoperation aufgrund eines Fehlers nicht abgeschlossen werden kann, werden Informationen über den Fehler in das Anwendungsereignisprotokoll geschrieben. Dort können sie von allen Benutzern mit normalen Benutzerberechtigungen angezeigt werden. Wenn die Schemainformationen vertraulich sind und im Protokoll angezeigt werden könnten, können Sie das Protokoll löschen oder den Zugriff auf den Clientcomputer beschränken.

Siehe auch

Konzepte

Übersicht über die Umgestaltung mit Umbenennung
Übersicht über die Terminologie von Team Edition for Database Professionals

Weitere Ressourcen

Umbenennen von Datenbankobjekten