• Artykuł

gg495035(v=msdn.10).md     gg495035(v=msdn.10).md

SQL Server 2008 R2 – Data Tier Application widziana oczami programisty oraz administratora, cz.2/2  ![Udostępnij na: Facebook](images/gg670867.udostepnij_fb(pl-pl,MSDN.10).png \\"Udostępnij na: Facebook\\")

Autor: Tomasz Wiśniewski, Damian Widera

Opublikowano: 2010-12-16

DAC dla programisty

Aby rozpocząć pracę z nowym projektem aplikacji, programista musi posiadać Visual Studio 2010
w wersji Professional, Premium lub Ultimate. Pracę tę można rozpocząć w dwóch podstawowych scenariuszach:

  1. importując do projektu wyeksportowany przez administratora baz danych plik .dacpac lub
  2. tworząc projekt DTA (Data-tier Application) od podstaw.

Obydwa opisane scenariusze rozpoczyna się tą samą czynnością, czyli utworzeniem w Visual Studio nowego projektu. Należy kliknąć File -> New -> Project..., rozwinąć sekcję Database, wybrać podsekcję SQL Server, a z listy dostępnych projektów wybrać SQL Server Data-tier Application:

Rysunek 18. Tworzenie nowego projektu Data-tier Application.

Modyfikowanie istniejącego projektu DTA

W przypadku drugiego scenariusza, gdzie tworzy się projekt od podstaw, nazwa projektu jest dowolna.
W przypadku gdy importuje się plik .dacpac, zaleca się, aby projekt nazywał się tak samo jak baza danych na serwerze SQL Server.

Aby zaimportować plik projektu, który dostarcza administrator baz danych, należy otworzyć okno Solution Explorer, kliknąć prawym przyciskiem myszy na nowo utworzony projekt i wybrać opcję Import Data-tier Application...

Rysunek 19. Importowanie pliku .dacpack do projektu w Visual Studio.

Na pierwszym ekranie kreatora, który się pojawi, należy kliknąć Next. Na drugim ekranie dostępne są dwie opcje:

  1. możliwość zaimportowania aplikacji bezpośrednio z serwera bazy danych SQL Server,
  2. import pliku dostarczonego przez administratora baz danych.

W opisywanym przez nas przypadku należy wybrać drugą opcję i nacisnąć Browse oraz wybrać plik .dacpac, który ma być zaimportowany. Dodatkowo kreator umożliwia opcje importowania Server Selection Policies. Są to specjalne polityki, które może zdefiniować zarówno programista tworzący projekt DTA od podstaw, jak i administrator SQL Servera, który eksportuje bazę danych do pliku .dacpac. Polityki określają minimalne wymagania, jakie musi spełnić instancja, aby projekt DAC (Data-tier Application Component) mógł funkcjonować. Może to być minimalna wersja silnika bazodanowego lub wersja systemu operacyjnego, na którym taki silnik działa. Zaleca się zaznaczenie tej opcji podczas importowania pliku.

Rysunek 20. Ekran wyboru importowanego pliku .dacpac.

Na kolejnym ekranie kreatora Visual Studio 2010 przeprowadzi import z pliku .dacpac do nowo stworzonego projektu. Po zakończeniu tej operacji należy kliknąć Finish.

Po pomyślnym zaimportowaniu pliku w projekcie pojawią się nowe obiekty. Można je przeglądać na dwa sposoby.

Z poziomu Solution Explorera. Można rozwinąć np. ścieżkę: Schema Objects -> Schemas -> dbo -> Tables. Dostępne tam będą np. skrypty tworzące poszczególne tabele w bazie danych.

Rysunek 21. Widok obiektów z poziomu Solution Explorera.

To nie jest jednak widok, który pozwala w łatwy i szybki sposób zapoznać się ze strukturą bazy danych. Dlatego też dostępny jest drugi widok, który uruchamia się w oknie Schema View. Jeśli okno to nie jest już otwarte, w Visual Studio należy wybrać opcję View i z dostępnych okien wybrać Database Schema View. Okno to reprezentuje widok podobny do tego, który udostępnia SQL Server Management Studio. Rozwijając np. ścieżkę: Schemas -> dbo -> Tables -> [Nazwa jakiejś tabeli], można zobaczyć kolumny, klucze, indeksy i inne obiekty w ramach tej tabeli. W widoku tym są także dostępne inne obiekty bazodanowe, jak procedury składowane, funkcje itd.

Rysunek 22. Widok projektu w oknie Schema View.

Jedną z podstawowych rzeczy, jaką można chcieć teraz zrobić, jest dodanie nowej kolumny do wybranej tabeli. Należy w takiej sytuacji otworzyć odpowiedni plik .sql z Solution Explorera. Niech to będzie np. tabela Customers: Schema Objects -> Schemas -> dbo -> Tables ->Customers.table.sql, i do tej tabeli dodać kolumnę Email, i zapisać plik.

Rysunek 23. Dodanie nowej kolumny do istniejącej tabeli.

Po wprowadzeniu wielu takich zmian łatwo zapomnieć, co i gdzie zostało zmienione. Visual Studio dostarcza narzędzie, które umożliwia porównywanie schematu bazy danych, która jest dostępna na serwerze, ze schematem, jaki jest obecnie w projekcie. Aby porównać schematy, należy kliknąć na Data -> Schema Compare -> New Schema Comparison...

Rysunek 24. Uruchamianie kreatora porównywania schematów.

Po uruchomieniu się kreatora należy z lewej strony wybrać projekt w Visual Studio, a z prawej strony wybrać jedno z wcześniej zdefiniowanych połączeń do bazy danych lub, jeśli nie ma jeszcze skonfigurowanego połączenia do bazy, z której został wyeksportowany .dacpac, utworzyć je.

Rysunek 25. Wybór obiektów do porównania schematów.

Po wybraniu odpowiednich opcji należy kliknąć OK. Visual Studio nawiąże połączenie z serwerem baz danych oraz porówna schematy i wyświetli wyniki, pokazując różnice, zmiany lub nowe elementy.
W opisywanym przypadku będzie to nowa kolumna w tabeli Customers

Rysunek 26. Wyniki porównania obiektów.

Zarówno Visual Studio, jak i SQL Server Management Studio znane są ze swoich świetnych narzędzi i opcji wspierających rozwój aplikacji. Dla VS są to m.in. Intellisense oraz znakomity debugging. W przypadku SSMS są to plany zapytań i np. statystyki. Jak zatem te opcje zostały udostępnione podczas tworzenia DTA?

Aby je zobaczyć, należy włączyć nowe okno edytora T-SQL, klikając: Data -> Transact-SQL Editor -> New Query Connection...

Rysunek 27. Uruchamianie okna edytora T-SQL.

Zostanie wyświetlone okno nawiązywania połączenia z bazą danych. Należy wybrać istniejące połączenie lub skonfigurować nowe. Po nawiązaniu połączenia zostaje wyświetlone puste okno edytora T-SQL, gdzie można wpisywać polecenia tak samo jak np. w SQL Server Management Studio. Wpisując zatem polecenie: use N., automatycznie uruchomimy Intellisense. Działa ono w jednym z dwóch dostępnych trybów. Ten, który się uruchomił w chwili obecnej, jest nazywany OnlineIntellisense, ponieważ okno edytora T-SQL ma aktywne połączenie z bazą danych. Istnieje także drugi tryb – OfflineIntellisense, o którym w dalszej części artykułu. Dzięki trybowi Online dostępne są podpowiedzi dla obiektów znajdujących się na serwerze SQL, z którym zostało nawiązane połączenie.

Rysunek 28. Intellisense w trybie Online.

W oknie edytora zostały wpisane dwa polecenia:

useNorthwind;

execCustOrderHist'ALFKI';

Pierwsze polecenie wybiera bazę danych Northwind, a drugie uruchamia procedurę składowaną
z parametrem ALFKI. Aby zobaczyć wynik działania tych poleceń, należy uruchomić skrypt poprzez naciśnięcie przycisku  lub skrótu klawiszowego Ctrl+Shift+E. UWAGA! Nie należy pomylić tego przycisku ze znanym z Visual Studio przyciskiem  (Start Debugging F5), ponieważ ten drugi wykona dodatkowe czynności z naszym projektem, które w tej chwili nie są pożądane.

Rysunek 29. Wyniki wykonania poleceń w oknie edytora T-SQL.

Dodatkowo możliwe jest włączenie planów zapytań oraz statystyk poprzez zaznaczenie odpowiednich przycisków . Dzięki temu, po ponownym uruchomieniu skryptu,
w oknie wyników – podobnie jak w SSMS – dostępne będą zakładki z odpowiednimi informacjami.

Rysunek 30. Plan zapytań w oknie wyników edytora T-SQL w Visual Studio 2010.

Ostatnia sprawa, o jakiej wspomniano wcześniej, to debuggowanie. Debuggowanie skryptów T-SQL do tej pory, szczególnie z poziomu Visual Studio, było dość kłopotliwe. Obecnie sytuacja ta uległa zmianie. Załóżmy sytuację, że do projektu zostaje dodany nowy skrypt. Należy zatem kliknąć prawym przyciskiem myszy na katalog Scripts w Solution Explorer i wybrać opcję Add -> Script

Rysunek 31. Dodanie nowego skryptu SQL do projektu.

Jak widać, w sekcji Add są dostępne znane do tej pory elementy, takie jak New Item..., czy Existing Item... . Są one oczywiście w pełni funkcjonalne i klikając np. na New Item... zobaczymy wyświetlone okno Visual Studio z możliwością wybrania wszelkiego rodzaju elementów dla tego typu projektu. Jednak w menu kontekstowym zostały umieszczone najczęściej dodawane elementy, co znacznie upraszcza dodanie nowego obiektu. Po utworzeniu pliku zostanie automatycznie otwarte okno edytora T-SQL, jednak bez nawiązanego połączenia z bazą danych. W oknie tym można wprowadzić dowolny skrypt, jaki akurat trzeba stworzyć, lecz na potrzeby tego artykułu zostaną wpisane te same polecenia, co poprzednio. Warto zauważyć, że podczas wpisywania poleceń, jak np. use N, Intellisense ponownie podpowiada, jakie obiekty są dostępne. Tym razem jednak jest ich znacznie mniej. Wynika to stąd, iż tryb, w jakim obecnie działa Intellisense, to Offline. Intellisense bada jedynie obiekty dostępne w projekcie i daje podpowiedzi z nimi związane.

Aby móc debuggować skrypt, należy zdeployować aplikację na serwer. Jednak do tej pory nigdzie nie zostalo wskazane w projekcie, gdzie ma nastąpić taki deploy. Dlatego należy wejść do właściwości projektu i w zakładce Deploy wskazać ciąg połączenia do bazy danych.

Rysunek 32.  Definiowanie ciągu połączenia dla projektu DTA.

W oknie tym można także zdefiniować, jak ma nazywać się baza danych, która będzie zawierała aplikację. Możliwe jest również włączenie/wyłączenie opcji walidowania Selection Policies, co może być przydatne podczas procesu tworzenia aplikacji. Po zapisaniu zmian w oknie właściwości projektu należy wrócić do okna wcześniej stworzonego skryptu i postawić breakpoint w pierwszej linii.

Rysunek 33. Punkt przerwania w skrypcie SQL.

Teraz można przystąpić do debuggowania aplikacji. Tym razem należy użyć przycisku Start Debugging (F5) . Visual Studio wykonana w tym momencie szereg czynności, których treść da się zobaczyć w oknie Output. Najważniejsze z nich to:

  • Validating upgrade – jeśli zostały wprowadzane jakiekolwiek zmiany w strukturze bazy danych lub nowe obiekty, Visual Studio przed wydaniem takiej zmiany sprawdzi, jak wpłynie ona na spójność bazy danych. W przypadku jej zaburzenia proces wydania zostaje przerwany.
  • Creating database 'Northwind_1_0_0_0__129250604250261203' – zostaje utworzona tymczasowa baza danych, a następnie jej schemat: Creating schema objects in database 'Northwind_1_0_0_0__129250604250261203'.
  • Setting database 'Northwind' to read-only mode – stara wersja bazy danych zostanie przeniesiona do trybu tylko do odczytu, a następnie wszyscy podłączeni użytkownicy zostają od niej odłączeni: Disconnecting users from database 'Northwind'.
  • Disabling constraints on database 'Northwind_1_0_0_0__129250604250261203' before populating data – zostają wyłączone więzy na tymczasowej bazie danych, a następnie z bazy pierwotnej zostają przekopiowane dane: Inserting data from database 'Northwind' to database 'Northwind_1_0_0_0__129250604250261203'.
  • Setting database 'Northwind' to read-write – następnie źródłowa baza danych zostanie przeniesiona w tryb odczytu i zapisu oraz dostaje nową nazwę: Renaming database 'Northwind' to 'Northwind_1_0_0_0__129250605623779764'.
  • Renaming database 'Northwind_1_0_0_0__129250604250261203' to 'Northwind' – w tymczasowej bazie danych zostaje zmieniona nazwa na nazwę bazy, która została uaktualniona.

Taki proces zapewnia nam to, że baza danych jest zawsze w spójnym stanie, a stara wersja jest dostępna, zatem w razie jakichkolwiek problemów można ją przywrócić. Należy jednak pamiętać też o tym, że dane  są przenoszone. Jeśli w developerskiej bazie danych dane testowe zajmują dużo miejsca, to często wydawanie nowych wersji może bardzo szybko zredukować miejsce dostępne na serwerze. Warto także pamiętać o tym, że taki proces wydawania bazy danych nie jest sugerowany dla baz produkcyjnych. Dla takiej bazy powinno się wyeksportować plik .dacpac i przekazać go odpowiedniemu administratorowi bazy danych, o czym w dalszej części artykułu.

Tworzenie projektu DTA od podstaw

Powyższy scenariusz opisywał modyfikację istniejącego projektu, który programista otrzymuje od administratora baz danych. W dalszej części artykułu będzie mowa o tym, jak programista może zacząć tworzyć nowy projekt i jakie, nieopisane do tej pory, narzędzia są dla niego dostępne.

Jak już wspomniano na początku tej części artykułu, praca zarówno z wyeksportowanych projektem, jak i nowym zaczyna się tak samo, czyli od założenia nowej solucji w Visual Studio 2010. Po założeniu nowego projektu pierwszą rzeczą, od jakiej często się zaczyna, to stworzenie nowej tabeli. Można to zrobić, klikając prawym przyciskiem myszy na folder: Schema Objects-> Schemas -> dbo -> Tables. Po wybraniu Add -> Table... zostaje otwarte nowe okno edytora T-SQL, gdzie można zdefiniować, jakie kolumny ma zawierać nowa tabela.

Rysunek 34. Tworzenie nowej tabeli w czystym (nowym) projekcie.

Zostanie założony jeszcze jeden obiekt w przykładowym projekcie. Będzie to procedura składowana, dlatego należy kliknąć prawym przyciskiem myszy w katalog: Schema Objects-> Schemas -> dbo -> Programmability -> Stored Procedures i wybrać Add i Stored Procedure. Przykładowa procedura będzie zawierała taki kod:

Rysunek 35. Przykładowa procedura składowana.

Jest to bardzo często spotykany sposób pisania kodu SQL zarówno wśród programistów, jak i nierzadko administratorów baz danych. Visual Studio wspiera programistę, aby ustrzec go przed wydawaniem takiego kodu na serwer produkcyjny. Został zaimplementowany mechanizm statycznej analizy kodu dla projektów bazodanowych. Aby zobaczyć dostępne opcje dla takiej analizy, należy wejść w menu Data -> Static Code Analysis -> Configure lub we właściwości projektu na zakładkę Code Analysis – zostanie otwarte to samo okno. Na wyświetlonej liście są pokazane dostępne „z pudełka” polityki. Jest to wystarczająca ilość dla podstawowych projektów bazodanowych oraz zabezpieczająca przed najczęstszymi błędami podczas pisania kodu T-SQL. Polityki te można również tworzyć samemu. Jest to bardzo przydatna opcja, jeśli w naszym projekcie mają być utrzymane określone standardy kodu. Możliwe jest też włączenie sprawdzania kodu podczas każdej kompilacji projektu poprzez zaznaczenie opcji Enable Code Analysis on Build. Równie ważną opcją jest (Treat Warning as Error) traktowanie ostrzeżeń (które są domyślnym sposobem informowania o niespełnieniu reguł) jako błędów, co w rezultacie uniemożliwia kompilację aplikacji niespełniającej wymaganych reguł.

Rysunek 36. Okno konfiguracji statycznej analizy kodu.

Jeśli została zaznaczona opcja włączająca analizę podczas kompilacji, można nacisnąć przycisk F6, a jeśli nie została zaznaczona – to zaznaczyć opcję Data -> Static Code Analysis -> Run. Rezultat w obu przypadkach pojawi się w oknie Error List.

Rysunek 37. Wynik statycznej analizy kodu w Visual Studio 2010.

W opisie ostrzeżenia VS podaje dokładnie, jaka reguła została naruszona, w jakim pliku i której linii. Jeśli chcemy przejść do konkretnego miejsca w kodzie, wystarczy dwukrotnie kliknąć na opis. Zostanie otwarty odpowiedni plik, a kursor umieszczony w konkretnym miejscu tam, gdzie występuje naruszenie. W tym przypadku jest to użycie gwiazdki, zamiast konkretnych nazw kolumn. Edytor T-SQL w Visual Studio posiada także przyjazne dymki z podpowiedziami. Po najechaniu kursorem myszy na gwiazdkę zostanie wyświetlony dymek z informacją, jakie kolumny posiada tabela, z której pobierane są dane.

Rysunek 38. Tooltip informujący o kolumnach w tabeli.

Aby naprawić powstały błąd, można oczywiście wpisać ręcznie wszystkie kolumny, jakie posiada obecnie tabela, lub posłużyć się narzędziem do refaktoryzacji, jakie dostarcza Visual Studio 2010. Drogi dojścia do tego okna są dwie. Programista w Solution Explorer może kliknąć prawym przyciskiem myszy na konkretny plik i wybrać opcję Refactor -> Expand Wildcards...

Rysunek 39. Uruchomienie refaktoryzacji dla konkretnego pliku.

Druga droga to kliknięcie w menu Data -> Refactor -> Expand Wildcards...

Rysunek 40. Uruchomienie refaktoryzacji dla całego projektu.

Różnica w tych podejściach polega na tym, że w pierwszym przypadku narzędzie refaktoryzujące będzie analizowało tylko wybrany plik. W drugim natomiast będą wyświetlone wyniki analizy dla całego projektu.

Rysunek 41. Okno wyników analizy narzędzia do re faktoryzacji.

Jeśli zaproponowane zmiany są akceptowalne, wystarczy kliknąć przycisk Apply i zmiany zostaną wprowadzone w danym pliku lub plikach zgodnie z tym, co pokazało okno podglądu.

Podczas importu pliku .dacpac w pierwszym scenariuszu była możliwość zaimportowania polityk serwera. Jak takie polityki można zdefiniować z poziomu Visual Studio? Należy w Solution Explorer rozwinąć folder Properties i dwukrotnie kliknąć na plik ServerSelection.sqlpolicy. Zostanie otwarte okno z poziomu, z którego można wybrać szereg dostępnych polityk.

Rysunek 42. Plik polityk dla projektu.

Rysunek 43. Okno wyboru polityk dla projektu DTA.

Na potrzeby tego artykułu zostanie wybrana polityka Version Major. Po jej wybraniu pojawi się automatycznie drugie okno, w którym możliwe jest ustawienie konkretnych opcji danej polityki. Może to być np. polityka stwierdzająca, że serwer bazy danych ma być w wersji 9, czyli 2005.

Rysunek 44. Ustawienie opcji polityki wersji silnika bazy danych na wersję 2005.

Po zatwierdzeniu opcji polityki i zapisaniu pliku polityk należy przejść do wydania projektu na serwer bazodanowy. Podobnie jak poprzednio, nie został zdefiniowany nigdzie ciąg połączenia do serwera SQL, dlatego należy zdefiniować taki ciąg we właściwościach projektu w zakładce Deploy. Teraz można kliknąć prawym przyciskiem myszy na projekt i wybrać opcję Deploy. Niestety, wydanie aplikacji się nie powiedzie. Patrząc w okno Output, możemy przeczytać: The chosen target instance does not satisfy the selection policy. Wynika to z faktu ustawienia w polityce wersji SQL Servera na 2005. Na maszynie, gdzie następuje wydanie, jest zainstalowana wersja 2008 R2. Drugą natomiast kwestią jest kompatybilność – wersja 2005 SQL Servera nie wspiera projektów typu Data-tier Application. Należy zatem wrócić do edytora polityk i zmienić politykę tak, aby było możliwe wydanie projektu na serwer.

Rysunek 45. Poprawna wersja polityki.

Po zapisaniu polityki można ponowić próbę wydania aplikacji poprzez opcję Deploy, która tym razem się powiedzie. Można to sprawdzić, uruchamiając np. SQL Server Management Studio i wyświetlając dostępne bazy danych.

Rysunek 46. Baza danych DBTest zainstalowana w SQL Server 2008 R2.

Ten sposób jednak nie jest preferowany do wydawania aplikacji na serwery produkcyjne. Dlatego też w katalogu, w którym znajduje się projekt, można znaleźć plik .dacpac oraz skrypty .sql, które muszą być wykonane przez administratora przed i po instalacji .dacpac-a. Ścieżka dla powyższego projektu to: C:\demo\dta\DBTest\DBTest\obj\Debug.

Podsumowanie

W artykule pokazaliśmy, w jaki sposób można rozpocząć pracę z aplikacją DTA. Zarówno administrator baz danych, jak i programista mają do tego celu swoje narzędzia. Rozwiązanie takie pozwala pracować tym osobom w środowiskach, które znają najlepiej w  swojej codziennej pracy.

Wersja V1 aplikacji DTA jest zapewne tylko początkiem dobrego rozwiązania, które będzie rozwijane w kolejnych edycjach SQL Server, co uczyni z niego jeszcze bardziej potężne narzędzie. Dlatego warto już teraz zapoznać się z działaniem DTA.

gg495035(v=msdn.10).md     gg495035(v=msdn.10).md