Programowanie Microsoft SQL Server

Transkrypt

1 Leonard Lobel Andrew Brust Programowanie Microsoft SQL Server 2012 Przekład: Krzysztof Szkudlarek APN Promise, Warszawa 2012

2 Programowanie Microsoft SQL Server APN PROMISE SA Authorized Polish translation of English edition of Programming Microsoft SQL Server 2012, ISBN: Copyright 2012 by Sleek Technologies Inc., and Blue Badge Insights, Inc. This translation is published and sold by permission of O Reilly Media, Inc., which owns or controls all rights to publish and sell the same. APN PROMISE SA, biuro: ul. Kryniczna 2, Warszawa tel , fax mspress@promise.pl Wszystkie prawa zastrzeżone. Żadna część niniejszej książki nie może być powielana ani rozpowszechniana w jakiejkolwiek formie i w jakikolwiek sposób (elektroniczny, mechaniczny), włącznie z fotokopiowaniem, nagrywaniem na taśmy lub przy użyciu innych systemów bez pisemnej zgody wydawcy. Książka ta przedstawia poglądy i opinie autorów. Przykłady firm, produktów, osób i wydarzeń opisane w niniejszej książce są fikcyjne i nie odnoszą się do żadnych konkretnych firm, produktów, osób i wydarzeń, chyba że zostanie jednoznacznie stwierdzone, że jest inaczej. Ewentualne podobieństwo do jakiejkolwiek rzeczywistej firmy, organizacji, produktu, nazwy domeny, adresu poczty elektronicznej, logo, osoby, miejsca lub zdarzenia jest przypadkowe i niezamierzone. Nazwa Microsoft oraz znaki towarowe wymienione na stronie about/legal/en/us/intellectualproperty/trademarks/en-us.aspx są zastrzeżonymi znakami towarowymi grupy Microsoft. Wszystkie inne znaki towarowe są własnością ich odnośnych właścicieli. APN PROMISE SA dołożyła wszelkich starań, aby zapewnić najwyższą jakość tej publikacji. Jednakże nikomu nie udziela się rękojmi ani gwarancji. APN PROMISE SA nie jest w żadnym wypadku odpowiedzialna za jakiekolwiek szkody będące następstwem korzystania z informacji zawartych w niniejszej publikacji, nawet jeśli APN PROMISE została powiadomiona o możliwości wystąpienia szkód. ISBN: Przekład: Krzysztof Szkudlarek Redakcja: Marek Włodarz Korekta: Ewa Swędrowska Skład i łamanie: MAWart Marek Włodarz

3 Skrócony spis treści Wprowadzenie xv Podziękowania xxxiii Część I: Podstawy programowania w SQL Server 1 Omówienie pakietu oprogramowania SQL Server Data Tools Rozszerzenia języka T-SQL Eksploracja środowiska SQL CLR Praca z transakcjami Zabezpieczenia serwera SQL Część II: Zastosowania nierelacyjne 6 Język XML a relacyjna baza danych Dane hierarchiczne a relacyjna baza danych Natywne strumienie plikowe Obsługa danych geoprzestrzennych Część III: Stosowany SQL 10 Technologie dostępu do danych firmy Microsoft Technologie dostępu do danych oparte na platformie WCF Przenoszenie usług do chmury SQL Azure Usługa SQL Azure Data Sync i tworzenie aplikacji dla systemu Windows Phone Szersze spojrzenie na oprogramowanie SQL Server Technologie przetwarzania w pamięci xvelocity Indeks Informacje o autorach iii

4

5 Spis treści Wprowadzenie xv Podziękowania xxxiii Część I: Podstawy programowania w SQL Server 1 Omówienie pakietu oprogramowania SQL Server Data Tools Omówienie pakietu oprogramowania SSDT Narzędzia bazodanowe stworzone dla programistów Programowanie deklaratywne w oparciu o model bazy danych Programowanie w trybie z połączeniem Programowanie w trybie bez połączenia Wersjonowanie i obrazy migawkowe Tworzenie kodu dla różnych platform docelowych Korzystanie z pakietu oprogramowania SSDT Łączenie sie z bazą danych za pomocą eksploratora obiektów SQL Server Object Explorer Zbieranie nowych wymagań Korzystanie z narzędzia Table Designer (w trybie z połączeniem) Praca z projektem typu SQL Server Database w trybie offline Wykonywanie obrazu migawkowego Korzystanie z narzędzia Table Designer (projekt bazy danych w trybie Offline). 33 Omówienie instancji LocalDB Refaktoryzacja bazy danych Testowanie i debugowanie Porównywanie schematów Publikowanie w chmurze SQL Azure Przyzwyczajanie się do korzystania z pakietu oprogramowania SSDT Podsumowanie Rozszerzenia języka T-SQL Parametry o wartościach tablicowych Coś więcej niż kolejne rozwiązanie oparte na tabeli tymczasowej Wysyłanie zamówień Używanie parametrów tablicowych do masowych operacji wstawiania i aktualizowania danych Przekazywanie parametrów tablicowych przy użyciu składnika ADO.NET v

6 vi Spis treści Przekazywanie kolekcji w parametrach tablicowych przy użyciu niestandardowych iteratorów Ograniczenia parametrów tablicowych Typy danych dla dat i godzin Oddzielne typy danych dla dat i godzin Bardziej przenośne typy danych dla dat i godzin Obsługa stref czasowych Dokładność, ilość zajmowanej pamięci oraz format używany do zapisywania dat i godzin Funkcje służące do przetwarzania dat i godzin Instrukcja MERGE Definiowanie źródłowych i docelowych danych dla instrukcji MERGE Klauzula WHEN MATCHED Klauzula WHEN NOT MATCHED BY TARGET Używanie instrukcji MERGE do replikacji tabeli Klauzula WHEN NOT MATCHED BY SOURCE Klauzula OUTPUT w instrukcji MERGE Wybór metody złączenia Działanie instrukcji MERGE jako instrukcji języka DML Składnia instrukcji typu INSERT OVER DML Alternatywa wobec klauzuli OUTPUT INTO, zapewniająca możliwość filtrowania danych Konsumowanie zmian przy użyciu słowa kluczowego CHANGES Operator GROUPING SETS Zestawienia według poziomu Zestawienia według wszystkich możliwych kombinacji poziomów Zwracanie zestawień tylko dla najwyższego poziomu Mieszanie i dopasowywanie Obsługa wartości NULL Rozszerzenia funkcjonalności okna danych (klauzuli OVER) Agregacje przesuwne Porównanie klauzul RANGE i ROWS Nowe funkcje języka T-SQL wprowadzone w wersji SQL Server Nowe funkcje analityczne Nowe funkcje konwersji Nowe funkcje służące do przetwarzania dat i godzin Nowe funkcje logiczne Nowe funkcje służące do przetwarzania łańcuchów znakowych Zmienione funkcje matematyczne Instrukcja THROW Ponowne zgłaszanie wyjątków Stronicowanie po stronie serwera Używanie funkcji ROW_NUMBER

7 Spis treści vii Używanie składni OFFSET/FETCH NEXT Obiekt SEQUENCE Ograniczenia sekwencji Wykrywanie metadanych Podsumowanie Eksploracja środowiska SQL CLR Wprowadzenie: Włączenie integracji ze środowiskiem CLR Integracja programu Visual Studio i serwera SQL Server Projekty typu SQL Server Database Project w programie Visual Studio Automatyczne wdrażanie Atrybuty kodu SQL CLR Nasza pierwsza procedura składowana ze środowiska SQL CLR Procedury składowane CLR oraz dostęp do danych po stronie serwera Potokowe przesyłanie danych za pomocą obiektów klasy SqlDataRecord i SqlMetaData Wdrażanie Przygotowanie Wdrażanie modułu wykonywalnego Wdrażanie procedur składowanych Testowanie procedur składowanych Funkcje CLR Procedury wyzwalane CLR Agregacje CLR Typy danych SQL CLR Zabezpieczenia Badanie i zarządzanie zdefiniowanymi przez użytkownika typami danych CLR. 200 Wskazówki praktyczne dotyczące korzystania ze środowiska SQL CLR Podsumowanie Praca z transakcjami Co to jest transakcja? Omówienie właściwości ACID Obsługa transakcji lokalnych przez serwer SQL Server Tryb z automatycznym zatwierdzaniem transakcji Tryb z transakcją jawną Tryb z transakcją niejawną Tryb transakcji z zakresem ograniczonym do partii zadań Poziomy izolacji Poziom izolacji z odczytem niezatwierdzonym Poziom izolacji z odczytem zatwierdzonym Poziom izolacji z powtarzalnym odczytem Poziom izolacji z serializacją

8 viii Spis treści Poziom izolacji obrazu migawkowego Poziom izolacji obrazu migawkowego z odczytem zatwierdzonych danych Poziomy izolacji w środowisku ADO.NET Transakcje rozproszone Terminologia związana z transakcjami rozproszonymi Reguły i metody rejestrowania się Transakcje rozproszone na serwerze SQL Server Transakcje rozproszone w środowisku.net Framework Użycie menedżera zasobów w transakcji zakończonej powodzeniem Transakcje w środowisku SQL CLR (integracja ze środowiskiem CLR) Podsumowanie dotychczasowych informacji Podsumowanie Zabezpieczenia serwera SQL Cztery filary platformy Security Framework Bezpieczeństwo z założenia Bezpieczne ustawienia domyślne Bezpieczne wdrożenie Bezpieczna komunikacja Omówienie zabezpieczeń serwera SQL Server Loginy serwera SQL Server Użytkownicy bazy danych Konto użytkownika guest Uwierzytelnianie i autoryzacja Sposób nawiązywania połączeń przez klientów Zasady haseł Separacja użytkownika i schematu Kontekst wykonywania Obsługa szyfrowania Szyfrowanie danych w trakcie ich przesyłania Szyfrowanie przechowywanych danych Transparentne szyfrowanie danych Inspekcja serwera SQL Server Tworzenie obiektu inspekcji Opcje inspekcji Rejestrowanie zdarzeń inspekcji w systemie plików Rejestrowanie zdarzeń inspekcji w dzienniku zdarzeń systemu Windows Prowadzenie inspekcji zdarzeń serwera Prowadzenie inspekcji zdarzeń bazy danych Przeglądanie zarejestrowanych zdarzeń inspekcji Odpytywanie widoków katalogu inspekcji Częściowo zawarte bazy danych Tworzenie częściowo zawartej bazy danych

9 Spis treści ix Tworzenie użytkownika zawartego Inne funkcje częściowo zawartych baz danych Metody używane przez hakerów do atakowania serwerów SQL Server Bezpośrednie połączenie z siecią Internet Słabe hasła kont administratorów systemu Usługa SQL Server Browser Wstrzykiwanie kodu SQL Spostrzeżenie Podsumowanie Część II: Zastosowania nierelacyjne 6 Język XML a relacyjna baza danych Dane znakowe jako dane w formacie XML Typ danych xml Używanie zmiennych typu xml Używanie formatu XML w tabelach Definicje schematu XML (XSD) Indeksy XML Polecenia FOR XML FOR XML RAW FOR XML AUTO FOR XML EXPLICIT Dodatkowe funkcje klauzuli FOR XML Opcja TYPE FOR XML PATH Emitowanie elementu ROOT Tworzenie schematu XSD umieszczanego wewnątrz dokumentu XML Tworzenie kodu XML opartego na elementach Rozmontowywanie danych w formacie XML przy użyciu funkcji OPENXML Odpytywanie danych w formacie XML za pomocą zapytań w języku XQuery Omówienie wyrażeń w języku XQuery i XPath Działanie zapytań XQuery na serwerze SQL Server Instrukcje DML dla formatu XML Podsumowanie Dane hierarchiczne a relacyjna baza danych Typ danych hierarchyid Tworzenie tabeli hierarchicznej Metoda GetLevel Wypełnianie hierarchii danymi Metoda GetRoot Metoda GetDescendant

10 x Spis treści Metoda ToString Metoda GetAncestor Strategie indeksowania tabeli hierarchicznej Indeksowanie w głąb Indeksowanie poprzeczne Odpytywanie tabel hierarchicznych Metoda IsDescendantOf Reorganizowanie węzłów wewnątrz hierarchii Metoda GetReparentedValue Przeszczepianie gałęzi drzewa Więcej metod typu danych hierarchyid Podsumowanie Natywne strumienie plikowe Tradycyjne strategie obsługi obiektów typu BLOB Obiekty BLOB w bazie danych Obiekty BLOB w systemie plików Omówienie strumieni plikowych typu FILESTREAM Włączenie obsługi strumieni plikowych typu FILESTREAM Włączanie obsługi strumieni plikowych typu FILESTREAM na poziomie komputera Włączanie obsługi strumieni plikowych typu FILESTREAM na poziomie instancji serwera Tworzenie bazy danych z włączoną obsługą strumieni plikowych typu FILESTREAM Tworzenie tabeli z kolumnami typu FILESTREAM Przechowywanie i pobieranie danych typu FILESTREAM Usuwanie danych typu FILESTREAM Bezpośrednie przesyłanie strumieniowe w środowisku.net przy użyciu klasy SqlFileStream Omówienie klasy SqlFileStream Tworzenie aplikacji klienckiej typu Windows Forms Programowanie dostępu do danych przy użyciu klasy SqlFileStream Tworzenie strumieniowej usługi HTTP Budowanie klienta WPF Ograniczenia i uwagi dotyczące strumieni plikowych typu FILESTREAM Omówienie tabel plikowych typu FileTable Tworzenie tabeli plikowej FileTable Manipulowanie tabelami plikowymi typu FileTable Przeszukiwanie dokumentów Podsumowanie

11 Spis treści xi 9 Obsługa danych geoprzestrzennych SQL Server Spaces Out Modele przestrzenne Model planarny (płaskiej Ziemi) Model geodezyjny (elipsoida) Standardy danych przestrzennych Importowanie danych w formacie WKT (Well-Known Text) Importowanie danych w formacie WKB Importowanie danych w formacie GML (Geography Markup Language) Przestrzenne typy danych Korzystanie z typu danych geometry Korzystanie z typu danych geography Rozszerzenia przestrzenne wprowadzone w wersji SQL Server Nowe klasy danych przestrzennych Nowe metody przestrzenne Inne ulepszenia Integracja z mapami Microsoft Bing Podsumowanie Część III: Stosowany SQL 10 Technologie dostępu do danych firmy Microsoft Ewolucja dostępu do danych na platformie.net Przygotowywanie przykładowej bazy danych Monitorowanie aktywności bazy danych przy użyciu narzędzia SQL Server Profiler Konwencjonalna technologia ADO.NET Korzystanie z surowych obiektów dostępu do danych Praca ze zbiorami danych typu DataSets Zapytania LINQ (Language-Integrated Query) Technologia LINQ to DataSet Mapowanie obiektowo relacyjne (ORM) wkracza do świata.net Zróżnicowana oferta technologii ORM z Redmond LINQ to SQL: przeszłość i teraźniejszość Entity Framework: teraźniejszość i przyszłość Podsumowanie Technologie dostępu do danych oparte na platformie WCF Zdefiniowanie usług Opcje dostępu do danych na platformie WCF Usługa WCF Data Services Tworzenie usługi WCF Data Service Tworzenie modelu danych z encjami

12 xii Spis treści Testowanie działania usługi WCF Data Services przy użyciu przeglądarki Internet Explorer Tworzenie aplikacji klienckich dla usług WCF Data Services Rozszerzanie usługi WCF Data Services Usługa WCF RIA Services Ustanawianie łącza usługi WCF RIA Services Tworzenie modelu danych z encjami Tworzenie klas usługi domenowej oraz klas metadanych Budowanie klienta Silverlight Inspekcja protokołu.net Framing przy użyciu programu Fiddler Testowanie gotowego rozwiązania dla usługi WCF RIA Services Wybór właściwej technologii dostępu do danych opartej na platformie WCF Podsumowanie Przenoszenie usług do chmury SQL Azure Historia Czym właściwie jest usługa SQL Azure? Skąd wynikają ograniczenia? Ceny Początek jest bezpłatny Przygotowanie Po wstępnych przygotowaniach Przygotowanie serwera Przygotowanie bazy danych Zarządzanie bazą danych Tworzenie tabel i wprowadzanie danych Wykonywanie zapytań w oknie przeglądarki Projektowanie indeksów Zarządzanie i wizualizacje Łączenie się z ziemi Przeprowadzanie migracji i synchronizacji pomiędzy ziemią a chmurą Ratunek w plikach typu DACPAC Wyodrębnianie, wdrażanie, eksportowanie i importowanie plików aplikacji warstwy danych Scenariusze Federacje SQL Azure Leksykon federacji SQL Azure Tworzenie federacji Sfederowane tabele Używanie elementów federacji Dzielenie i usuwanie elementów federacji Tabele centralne i tabele odwołań Zapytania rozdysponowujące i scenariusze z wieloma dzierżawcami

13 Spis treści xiii Obsługa federacji w programie SSMS oraz SSDT Zastosowanie federacji w chmurze SQL Azure Reporting Przygotowanie serwera Tworzenie raportów Wdrażanie raportów Rozwiewanie wątpliwości Podsumowanie Usługa SQL Azure Data Sync i tworzenie aplikacji dla systemu Windows Phone Charakterystyka systemu z okazjonalnym połączeniem Zarządzanie danymi Poznajemy usługę SQL Azure Data Sync Możliwości i funkcje Terminologia związana z usługą Data Sync Grupy synchronizacji Agent synchronizacji klienta Uwagi dotyczące usługi SQL Azure Data Sync Tworzenie systemu z okazjonalnym połączeniem Wymagania wstępne Konfigurowanie usługi SQL Azure Data Sync Przygotowanie serwera usługi SQL Azure Data Sync Server Tworzenie grupy synchronizacji Umieszczanie usług WCF Data Services na platformie Windows Azure Informacje o platformie Windows Azure Tworzenie rozwiązania FlixPoll Dodawanie usługi danych FlixPoll Dodawanie modelu danych z encjami Tworzenie klienta FlixPoll Używanie danych w formacie OData w systemie Windows Phone Baza danych SQL Server na telefonie komórkowym Wdrożenie na platformie Windows Azure Podsumowanie Szersze spojrzenie na oprogramowanie SQL Server Stos elementów logiki biznesowej firmy Microsoft: krótkie wprowadzenie Usługi danych głównych Usługi jakości danych Usługi integracji System RDBMS i hurtownie danych Składnice danych i hurtownie danych Schemat gwiaździsty

14 xiv Spis treści Urządzenia z hurtowniami danych SQL Server Usługi analityczne Motor wielowymiarowy Dodatek PowerPivot i tryb tabelaryczny usługi SSAS Wyszukiwanie danych Power View Usługi raportujące Części raportu Wysyłanie alertów Składniki pulpitu nawigacyjnego Program Excel i usługi programu Excel Korzystanie z usług programu Excel StreamInsight Usługa PerformancePoint Services Edycje serwera SQL Server i wymagane wersje oprogramowania SharePoint Podsumowanie Technologie przetwarzania w pamięci xvelocity Bazy danych z magazynem kolumn Technologia magazynu kolumn na rynku rozwiązań logiki biznesowej Technologia xvelocity w systemach RDBMS: Indeksy kolumn Tworzenie indeksu kolumny Czego nie można zrobić Jak działają indeksy kolumn Technologia xvelocity w zastosowaniach analitycznych: PowerPivot i modele tabelaryczne SSAS Uporządkowanie słownictwa związanego z usługami analitycznymi Najważniejsze informacje na temat technologii BISM Przyjaciele, rodacy, dajcie nam swoje dane Tworzenie modelu BISM M jak Modelowanie Modelowanie, Part Deux Odpytywanie modeli danych z poziomu programu Excel Program PowerPivot dla serwera SharePoint Przejście do usługi SSAS w trybie tabelarycznym Nadchodzi program Power View Powrót do motoru VertiPaq Podsumowanie Indeks Informacje o autorach

15 Wprowadzenie Leonard Lobel Zapraszamy! Ta książka o serwerze Microsoft SQL Server 2012 została napisana specjalnie dla programistów. Pokażemy w niej sposób korzystania z tego produktu, który będzie przydatny zarówno dla programistów programujących bezpośrednio na poziomie bazy danych serwera SQL Server, jak również dla programistów programujących w wyższych warstwach, tj. przy użyciu środowiska Microsoft.NET. Najnowsza wersja flagowego, bazodanowego produktu firmy Microsoft oferuje bezprecedensową, wysoce skalowalną platformę danych, zdolną do realizowania nawet najbardziej wymagających zadań i mogącą podołać nawet największym obciążeniom. Jak w każdej nowej wersji, w wersji SQL Server 2012 wprowadzono wiele nowych funkcji i rozszerzeń skierowanych do programistów, administratorów, a także (coraz częściej) zwykłych użytkowników końcowych. Wszystkie te ulepszenia umacniają dotychczasową pozycję serwera SQL Server jako wiodącego produktu na rynku rozwiązań bazodanowych. Wraz z ciągłą ewolucją tego produktu, stos oferowanych przez niego możliwości również ulega ciągłemu poszerzaniu. Ponieważ jednak pełen opis wszystkich możliwości i funkcji oprogramowania SQL Server byłby zbyt obszerny dla każdej książki, więc w tej książce skupimy się na możliwościach tego produktu związanych z programowaniem. W szczególności zapoznamy Czytelników z całą gamą sposobów programowego wykorzystywania serwera SQL Server (oraz jego kuzyna, serwera Microsoft SQL Azure) i budowania w ten sposób własnych aplikacji i usług. Jak ważna jest wersja SQL Server 2012? Oprogramowanie SQL Server, a w szczególności jego motor relacyjnej bazy danych, osiągnęło stan dojrzałości już jakiś czas temu. Oznacza to więc, że ważność każdej nowej wersji ukazującej się w ciągu ostatnich kilku lat jest pod pewnymi względami stosunkowo niewielka. Faktycznie, ostatnią przełomową wersją tego produktu była wersja SQL Server 2005, w której motor relacyjny (od lat faktycznie określający serwer SQL Server) przestał być centrum uwagi, zajmując swoje miejsce obok kilku innych usług, które obecnie wspólnie określają ten produkt. Usługi te obejmują takie składniki logiki biznesowej jak usługa raportująca Reporting Services, usługa analityczna Analysis Services oraz usługa integrująca Integration Services. Funkcjonalność tych usług zaczęła pojawiać się już w roku 1999, ale do wersji SQL Server 2005 były one integrowane tylko sporadycznie, jako mozaika różnych, luźno ze sobą xv

16 xvi Wprowadzenie powiązanych dodatków, kreatorów i konsol zarządzających. Wszystko to uległo radykalnej zmianie w wersji SQL Server Po raz pierwszy produkt znany pod ogólną nazwą SQL Server oferował szerszy, bogatszy i bardziej skonsolidowany zestaw funkcji i usług, które były integralną częścią platformy, a nie jej dodatkowymi elementami. Od tego czasu żadna z kolejnych wersji tj. SQL Server 2008, 2008 R2 i obecna wersja 2012 nie wprowadziła tak radykalnej zmiany architektury całego produktu. Mimo to każda kolejna wersja serwera SQL Server rozwijała się pod wieloma istotnymi względami. Wersja SQL Server 2008 (opublikowana 6 sierpnia 2008 roku) dodała wiele nowych funkcji do motoru relacyjnego, takich jak rozszerzenia języka T-SQL, przechwytywanie zmian danych (CDC Change Data Capture), transparentne szyfrowanie danych (TDE Transparent Data Encryption), inspekcja SQL Audit, strumienie plikowe typu FILESTREAM, a także potężne możliwości w zakresie logiki biznesowej, oferowane w programie Excel za pośrednictwem tabel przestawnych (PivotTable), wykresów i formuł CUBE. Wersja SQL Server 2008 R2 (opublikowana 21 kwietnia 2010 roku), która podczas jej tworzenia była wewnętrznie określana jako odświeżenie składników logiki biznesowej, dodała kompletnie przerobioną wersję usługi raportującej Reporting Services a także dodatek PowerPivot dla programów Excel i SharePoint, usługi danych głównych (Master Data Services), ale w zakresie motoru relacyjnego nie wnosiła nic nowego, poza drobnymi zmianami i poprawkami. Najnowsza wersja SQL Server 2012 została oficjalnie opublikowana 7 marca 2012 roku. Podobnie jak każda nowa wersja tego produktu, ta również poprawia jego kluczowe możliwości (takie jak dostępność, skalowalność, zarządzalność, programowalność itp.). Do głównych ulepszeń niezawodności należy zaliczyć nową funkcjonalność HADR (High Availability Disaster Recovery Wysoka dostępność i przywracanie po katastrofie), stanowiącą alternatywę dla technologii dublowania baz danych. Technologia HADR (znana również pod nazwą Always On, czyli Zawsze włączone ) wykorzystuje kilka serwerów pomocniczych tworzących tzw. grupę dostępności, zapewniającą jednocześnie skalowanie operacji wymagających tylko odczytu danych (zamiast zmuszać je do bezczynnego oczekiwania na wystąpienie awarii). Inną nową i ważną funkcją związaną z zarządzaniem jest technika tworzenia klastrów awaryjnych z serwerów rozmieszczonych w różnych podsieciach (Multisubnet Failover Clustering). W wersji SQL Server 2012 dodano także wiele nowych funkcji do motoru relacyjnego, z których większość została opisana w tej książce. Są bardzo funkcjonalne rozszerzenia języka T-SQL, z których najważniejsze są chyba rozszerzenia dotyczące funkcjonalności okien danych (ang. windowing), a także 22 nowe funkcje języka T-SQL, ulepszona obsługa błędów, stronicowanie po stronie serwera, generatory sekwencji, rozbudowane techniki wykrywania metadanych oraz tzw. zawarte bazy danych (ang. contained database). W wersji tej znalazły się także istotne ulepszenia dotyczące danych nieuporządkowanych, takie jak abstrakcyjna warstwa tabel plikowych typu FileTable oparta na strumieniach plikowych typu FILESTREAM oraz interfejsie API systemu plików Windows, pełnotekstowe przeszukiwanie właściwości oraz statystyczne

17 Dla kogo przeznaczona jest ta książka xvii wyszukiwanie semantyczne (Statistical Semantic Search). Duże zmiany zaszły także w zakresie obsługi danych przestrzennych, przejawiające się wprowadzeniem obsługi dla danych reprezentujących krzywe oraz dla danych reprezentujących całą powierzchnię kuli ziemskiej, zwiększoną wydajnością oraz lepszym wzajemnym dopasowaniem typów danych geometry i geography. Nowa technologia magazynów kolumn pozwoliła na drastyczne zwiększenie wydajności operacji przetwarzających ekstremalnie duże kostki danych (technologia xvelocity dla dodatku PowerPivot oraz usługi Analysis Services) oraz hurtownie danych (poprzez zaimplementowanie w motorze relacyjnym technologii o podobnym działaniu jak technologia xvelocity). Wszystkie wymienione cechy motoru relacyjnego mogą robić wrażenie, ale ciągle znaczą one niewiele więcej niż zwykłe dodatki dla istniejącej już platformy bazodanowej. Nowa wersja musi oferować coś więcej niż tylko dodatkową wisienkę na torcie, by skłonić użytkowników do przeprowadzenia aktualizacji. Mając to na uwadze firma Microsoft włożyła wiele pracy w poszerzenie funkcjonalności wersji SQL Server 2012 w zakresie logiki biznesowej i efekty tych wysiłków są wyraźnie widoczne. Stos składników logiki biznesowej uległ poważnemu rozszerzeniu, oferując znaczny postęp w przewidywaniu trendów. Obejmuje to aktualizację analitycznych możliwości produktu, możliwości w zakresie wizualizacji danych (takich jak możliwość samodzielnego tworzenia raportów przez użytkowników końcowych korzystających z programu Power View), funkcjonalności związanej z zarządzaniem danymi głównymi, a także usługę jakości danych (DQS Data Quality Services), oferującą zupełnie nowy motor jakości danych. Obecna wersja produktu dostępna jest także w nowej wersji Business Intelligence, oferującej wszystkie te możliwości bez konieczności nabywania pełnej licencji dla edycji Enterprise. Na koniec, nowy pakiet narzędziowy SQL Server Data Tools (SSDT) oferuje zupełnie nowy zestaw narzędzi dostępnych z poziomu programu Visual Studio. Pakiet SSDT oferuje nowe deklaratywne i oparte na modelu podejście do programowania, pozwalające na tworzenie i programowanie baz danych w trybie z połączeniem lub w trybie offline zarówno dla baz danych znajdujących się na lokalnych serwerach przedsiębiorstwa, jak również dla baz znajdujących się w chmurze. Dla kogo przeznaczona jest ta książka Niniejsza książka przeznaczona jest dla programistów posiadających podstawową wiedzę z zakresu terminologii i podstaw relacyjnych baz danych. Założenia Przygotowując zawartość tej książki oparliśmy się na kilku założeniach dotyczących jej odbiorcy. Po pierwsze oczekujemy, że czytelnikiem tej książki będzie programista mający już pewną wiedzę z zakresu pojęć związanych z relacyjnymi bazami danych niezależnie od tego, czy jego doświadczenia w tej dziedzinie dotyczą oprogramowania

18 xviii Wprowadzenie SQL Server, czy innych platform bazodanowych, niepochodzących od firmy Microsoft. Zakładamy więc, że Czytelnik wie już, czym są tabele, widoki, klucze główne i klucze obce (relacje), procedury składowane, funkcje definiowane przez użytkownika oraz procedury wyzwalane. Zakładamy, że te podstawy są dobrze znane każdemu odbiorcy tej książki i dlatego nie będziemy ich w niej opisywać. Z podobnych względów nie będziemy również wyjaśniać zasad poprawnego projektowania relacji, reguł normalizacji danych, strategicznych praktyk indeksowania danych, sposobów tworzenia podstawowych zapytań oraz innych podstaw dotyczących danych relacyjnych. Zakładamy również, że Czytelnik posiada przynajmniej podstawową znajomość języka SQL wszystko jedno czy języka T-SQL używanego przez serwer SQL Server, czy dialektów języka SQL używanych na innych platformach bazodanowych oraz podstawowe umiejętności programowania w języku C# na platformie.net. Pomimo tych wszystkich założeń staraliśmy się jednak stosować dość liberalną politykę w tym względzie. Przykładowo, z książki tej mogą korzystać również osoby znające tylko język T-SQL lub takie, które wolą używać języka Microsoft Visual Basic.NET niż języka C#, o ile tylko będą one skłonne wypróbować w praktyce czytane informacje. Większość zamieszczonych w tej książce przykładowych kodów źródłowych jest dość prosta. Wyjaśniając sposób ich działania zakładamy jednak posiadanie przez Czytelnika pewnej podstawowej wiedzy, a więc osoby, którym brakuje takiej wiedzy, mogą być zmuszone do jej samodzielnego poszerzenia przy użyciu innych źródeł. UWAGA Dla zachowania spójności, wszystkie prezentowane w tej książce kody źródłowe dla platformy.net zostały napisane w języku C#. Niniejsza książka nie jest jednak w żaden sposób zorientowana na język C#, a prezentowane kody źródłowe dla platformy.net z pewnością nie zawierają niczego, co byłoby specyficzne wyłącznie dla języka C#. Jak już przed chwilą powiedzieliśmy, przykładowe kody źródłowe nie są zbyt skomplikowane i jeśli ktoś ma większe doświadczenie w pracy z językiem Visual Basic.NET niż z językiem C#, to bez trudu powinien poradzić sobie z przekładaniem kodu w języku C# na kod w języku Visual Basic.NET na bieżąco i w trakcie lektury zamieszczanych przykładów. Opierając się na powyższych założeniach, naszym celem było poszerzenie informacji dostępnych w dokumentacji serwera SQL Server, poprzez dostarczenie Czytelnikom opracowanego z myślą o programistach szczegółowego omówienia różnych funkcji tego produktu, ze szczególnym uwzględnieniem funkcji, które zostały dodane lub ulepszone w wersji SQL Server Zaczniemy od omówienia całkiem nowego zestawu narzędzi oraz wielu ważnych rozszerzeń wprowadzonych do języka T-SQL oraz motoru relacyjnej bazy danych. Następnie przejdziemy do zagadnień bardziej ogólnych, takich jak natywna obsługa strumieni plikowych, danych geoprzestrzennych oraz innych rodzajów danych nieuporządkowanych. W książce tej znajdą się również rozdziały poświęcone zabezpieczeniom, transakcjom, dostępowi do danych z poziomu klienta, tworzeniu aplikacji mobilnych i aplikacji opartych na chmurze oraz wiele innych.

19 Dla kogo nie jest przeznaczona ta książka xix W rozdziałach tych Czytelnik odnajdzie szczegółowe omówienie najnowszych i najważniejszych funkcji związanych z programowaniem dla serwera SQL Server. Pozwolą one na zdobycie praktycznych umiejętności i dostarczą wiedzy technicznej, pozwalającej na tworzenie dla użytkowników końcowych nawet najbardziej złożonych rozwiązań bazodanowych. Książka ta nie jest natomiast przeznaczona dla administratorów systemu, administratorów bazy danych, kierowników projektów lub użytkowników końcowych. W książce tej przyjęliśmy bowiem ogólną zasadę nieomawiania funkcji, które nie są bezpośrednio programowalne. Dla kogo nie jest przeznaczona ta książka Niniejsza książka nie jest przeznaczona dla administratorów serwera SQL Server; jest ona skierowana bezpośrednio do programistów i to programistów mających podstawową wiedzę z zakresu baz danych. Organizacja tej książki Rozdziały tej książki zostały podzielone na trzy części, poświęcone następującym zagadnieniom: Podstawowe funkcje serwera SQL Server Funkcje wykraczające poza zastosowania relacyjne Praktyczne zastosowania języka SQL przy tworzeniu aplikacji i usług W żadnym razie nie należy zakładać, że czytanie tej książki powinno odbywać się w jakiejś określonej kolejności. Można ją przeczytać od początku do końca lub od razu przejść do rozdziałów, które są dla nas interesujące lub zawierają potrzebne nam informacje. W każdym z tych przypadków Czytelnik otrzyma wyczerpujące wskazówki praktyczne, pozwalające na wykonanie stojących przed nim zadań. Poniżej zamieszczone zostało krótkie podsumowanie poszczególnych części tej książki oraz zawartych w nich rozdziałów. Po tym omówieniu znajdują się informacje na temat związanej z tą książką internetowej witryny webowej, z której można pobrać gotowe pliki z kodami źródłowymi dla omawianych w tej książce przykładów. Część I: Podstawy programowania w SQL Server Część I koncentruje się na podstawowych cechach i funkcjach serwera SQL Server. Są to między innymi zupełnie nowe narzędzia do pracy w języku T-SQL (SSDT), rozszerzone możliwości programowania dzięki tworzeniu kodu SQL CLR w takich językach programowania dla platformy.net, jak Microsoft Visual Basic.NET i C#, transakcje i zabezpieczenia.

20 xx Wprowadzenie Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Rozdział rozpoczynający tę książkę poświęcony został w całości omówieniu pakietu narzędziowego SQL Server Data Tools (SSDT). W wersji SQL Server 2012 pakiet SSDT pełni rolę podstawowego środowiska programowania, służącego do tworzenia aplikacji korzystających z serwera SQL Server. Podczas gdy program SQL Server Management Studio (SSMS) nadal pełni rolę podstawowego narzędzia dla administratorów baz danych, pakiet SSDT zapewnia programistom zupełnie nową jakość pracy. Pakiet SSDT stanowi dodatek do programu Microsoft Visual Studio, pozwalający na programowanie w trybie z połączeniem przy użyciu lokalnych baz danych lub baz danych znajdujących się w chmurze SQL Azure, a także na pracę w trybie offline z nowymi typami projektów baz danych. Zamieszczone w tym rozdziale przykłady praktyczne zademonstrują także sposób korzystania z różnych funkcji pakietu SSDT, takich jak nawigowanie po kodzie źródłowym, funkcja podpowiedzi IntelliSense, refaktoryzacja, porównywanie schematów i wiele innych. Rozdział 2: Rozszerzenia języka T-SQL W rozdziale 2 zajmiemy się omówieniem ważnych rozszerzeń języka Transact-SQL (T-SQL) który ciągle pozostaje najlepszym narzędziem służącym do programowania niestandardowych rozwiązań opartych na serwerze SQL Server. W rozdziale tym przypomnimy także kilka ważnych rozszerzeń języka T-SQL wprowadzonych w wersji SQL Server 2008, zaczynając od parametrów tablicowych. Pokażemy, w jaki sposób parametry te pozwalają na przekazywanie całych zbiorów wierszy pomiędzy funkcjami a procedurami składowanymi na serwerze, a także pomiędzy serwerem a klientem używającym platformy Microsoft ADO.NET. Następnie przejdziemy do omówienia funkcji związanych z przetwarzaniem dat i godzin, włącznie z omówieniem typów danych służących do zapisywania dat i godzin, typów danych i funkcji uwzględniających odpowiednią strefę czasową, a także ulepszeń związanych z dopuszczanym zakresem wartości wyrażających daty i godziny oraz ich precyzją i ilością miejsca zajmowanego w pamięci. Dalej pokażemy różne sposoby korzystania z instrukcji MERGE, będącej bardzo elastyczną instrukcją typu DML (Data Manipulation Language Język manipulowania danymi), pozwalającą na umieszczanie w jednej instrukcji wszystkich indywidualnych operacji, związanych z typowymi przypadkami scalania danych. Omówimy również składnię instrukcji typu INSERT OVER DML, pozwalającą na rozszerzone przechwytywanie wyników dostarczanych przez klauzulę OUTPUT z dowolnej instrukcji DML. Zapoznamy się także z operatorem GROUPING SETS, stanowiącym rozszerzenie tradycyjnej klauzuli GROUP BY, zwiększającym możliwości różnego dzielenia danych w zapytaniach agregujących. Następnie przejdziemy do omówienia nowych rozszerzeń języka T-SQL wprowadzonych w wersji SQL Server 2012, zaczynając od funkcjonalności okien danych (ang. windowing). Funkcjonalność okien danych pojawiła się po raz pierwszy w języku T-SQL już w wersji SQL Server 2005, wraz z wprowadzeniem kilku funkcji szeregujących. Od tego czasu możliwości tworzenia okien danych pozostawały

21 Organizacja tej książki xxi dość ograniczone, aż do wprowadzenia w wersji SQL Server 2012 kilku istotnych ulepszeń, które ostatecznie zmieniły ten stan rzeczy. Zaczniemy więc od omówienia koncepcji okien danych oraz podstaw, na których opiera się działanie klauzuli OVER, a następnie wykorzystamy tę wiedzę do wyznaczania wartości różnych agregacji bieżących i przesuwnych, a także do wykonywania innych obliczeń o charakterze analitycznym. W rozdziale tym omówimy 22 nowe funkcje języka T-SQL, na które składa się 8 funkcji analitycznych okien danych, 3 funkcje konwersji, 7 funkcji związanych z przetwarzaniem dat i godzin, 2 funkcje logiczne i 2 funkcje służące do przetwarzania łańcuchów znakowych. Omówimy także ulepszoną obsługę błędów opartą na instrukcji THROW, funkcjonalność stronicowania po stronie serwera uzyskiwaną za pomocą instrukcji OFFSET/FETCH NEXT, generatory sekwencji oraz rozbudowane techniki wykrywania metadanych. Omówienia wszystkich tych nowych funkcji i funkcjonalności zostaną poparte przejrzystymi przykładami kodu źródłowego, demonstrującymi ich użycie. Rozdział 3: Eksploracja środowiska SQL CLR Rozdział 3 zawiera dokładne omówienie zagadnień związanych z programowaniem w środowisku SQL CLR które pozwala na uruchamianie skompilowanego kodu.net na serwerze SQL Server a także wskazówki wyjaśniające, kiedy należy korzystać z tej możliwości. Oprócz omówienia sposobów tworzenia procedur składowanych, procedur wyzwalanych i funkcji, zademonstrujemy także sposób tworzenia w środowisku CLR własnych typów danych i agregacji tj. jednostek programowych, których w ogóle nie można tworzyć w języku T-SQL. Pokażemy także różne metody tworzenia obiektów SQL CRL w projektach programu Visual Studio typu SQL Server Database Projects oraz sposoby wdrażania tych obiektów przy użyciu programu SSDT/ Visual Studio oraz skryptów w języku T-SQL, uruchamianych z poziomu programu SQL Server Management Studio lub w inny sposób. Rozdział 4: Praca z transakcjami Niezależnie od przyjętego sposobu tworzenia i pakowania kodu, zawsze konieczne jest zachowywanie spójności danych, gwarantujące zachowanie ich integralności. Kluczem do zachowania spójności danych są transakcje, które zostaną omówione w rozdziale 4. Podobnie jak w przypadku wielu innych funkcji serwera SQL Server, zarządzanie transakcjami może odbywać się z wielu różnych miejsc. Programiści tworzący kod w języku T-SQL lub kod klienta korzystającego z dostawców danych ADO.NET SqlClient lub System. Transactions powinni zdawać sobie sprawę z istnienia różnych poziomów izolacji obsługiwanych przez serwer SQL Server oraz z konieczności ustalenia odpowiedniego zakresu dla wykonywanych transakcji, a także poznać wskazówki praktyczne dotyczące tworzenia kodu transakcyjnego. Zadaniem rozdziału 4 jest właśnie dostarczenie tych wszystkich informacji. Rozdział 5: Zabezpieczenia serwera SQL Rozdział 5 poświęcony został dokładnemu omówieniu zabezpieczeń, prezentując dostępne możliwości bezpiecznego utrzymywania danych z dala od ciekawskich oczu lub złośliwych intencji. Zaczniemy

22 xxii Wprowadzenie od omówienia podstawowych pojęć zabezpieczeń związanych z loginami, użytkownikami, rolami, uwierzytelnianiem i autoryzacją. Następnie omówimy obsługę szyfrowania danych za pomocą rożnych kluczy, pozwalającą chronić posiadane dane zarówno w stanie spoczynku (tj. w bazie danych) jak również podczas ich przesyłania. Omówimy również inne ważne funkcje związane z bezpieczeństwem danych, takie jak transparentne szyfrowanie danych (TDE Transparent Data Encryption) oraz funkcjonalność inspekcji serwera SQL Server. Funkcjonalność TDE pozwala na zaszyfrowanie w tle całych baz danych, bez żadnych specjalnych wymagań w zakresie tworzenia kodu źródłowego. Funkcjonalność inspekcji serwera SQL Server pozwala natomiast na rejestrowanie w systemie plików lub w dzienniku systemu Windows praktycznie każdej wykonywanej przez użytkowników akcji. W rozdziale tym pokażemy także, w jaki sposób tworzyć tzw. zawarte bazy danych (ang. contained databases). Ta nowa funkcjonalność serwera SQL Server 2012 eliminuje zależność bazy danych od konkretnej instancji serwera dzięki przechowywaniu poświadczeń tożsamości bezpośrednio w bazie danych. Na zakończenie tego rozdziału podane zostaną najważniejsze wskazówki, których przestrzeganie pozwoli uniknąć typowych zagrożeń dla bezpieczeństwa danych. Część II: Zastosowania nierelacyjne Wraz z opublikowaniem wersji SQL Server 2012 firma Microsoft znacząco poszerzyła zakres obsługi dla pseudo-uporządkowanych i nieuporządkowanych danych przechowywanych w relacyjnych bazach danych. W części II tej książki pokażemy więc, w jaki sposób korzystać z nierelacyjnych możliwości serwera SQL Server 2012 tj. z funkcji nabierających coraz większego znaczenia wraz z upowszechnianiem się we współczesnym świecie treści cyfrowych oraz pojawianiem się wysokowydajnych platform bazodanowych określanych terminem No SQL. Rozdział 6: Język XML a relacyjna baza danych Typ danych xml został wprowadzony już w wersji SQL Server 2005, czemu towarzyszyła rozbudowana obsługa formatu XML. Ta innowacja stanowiła olbrzymi postęp wobec przechowywania łańcuchów znakowych w formacie XML w zwykłych kolumnach typu varchar lub text (co było powszechną praktyką we wcześniejszych wersjach serwera SQL Server), który zrewolucjonizował kwestię przechowywania danych w formacie XML w relacyjnych bazach danych. Zmiany te pozwoliły na tworzenie aplikacji bazodanowych mogących używać danych hierarchicznych w natywny sposób całkowicie wewnątrz środowiska systemu relacyjnej bazy danych co było niemożliwe w przypadku posługiwania się kolumnami ze zwykłymi łańcuchami znakowymi. Rozdział 6 zawiera więc dokładne omówienie typu danych xml, rozszerzeń XQuery dla języka T-SQL, tworzonych po stronie serwera kolekcji definicji schematów XML (XSD XML Schema Definition), indeksowania kolumn XML oraz wielu innych funkcji związanych z przetwarzaniem danych w formacie XML.

23 Organizacja tej książki xxiii Rozdział 7: Dane hierarchiczne a relacyjna baza danych Używanie formatu XML nie stanowi jednak jedynej możliwości posługiwania się danymi hierarchicznymi przechowywanymi w bazie danych. W rozdziale 7 zapoznamy się z nowym typem danych hierarchyid, który pozwala na zrzutowanie struktury hierarchicznej na dowolną tabelę relacyjną. Ten typ danych został zaimplementowany jako systemowy typ CLR, który tak naprawdę nie jest niczym innym jak zdefiniowanym przez użytkownika typem danych SQL CLR, którego tworzenie zostało zademonstrowane w rozdziale 3. Wartości zapisane przy użyciu typu danych hierarchyid kodują pełną ścieżkę prowadzącą od węzła głównego do dowolnego węzła struktury drzewiastej, wyznaczającą pozycję tego węzła pomiędzy innymi węzłami, sąsiadującymi z nim na tym samym poziomie. Metody dostarczane przez ten nowy typ danych pozwalają na efektywne tworzenie, odpytywanie i manipulowanie strukturami drzewiastymi, przechowywanymi w tabelach relacyjnych. Ten typ danych odgrywa także istotną rolę w nowej funkcjonalności tabel plikowych typu FileTable serwera SQL Server, która zostanie omówiona w następnym rozdziale poświęconym natywnej obsłudze strumieni plikowych. Rozdział 8: Natywne strumienie plikowe W rozdziale 8 zapoznamy się ze strumieniami typu FILESTREAM, będącymi innowacyjną funkcją integrującą motor relacyjnej bazy danych z systemem plików NTFS, oferując w efekcie bardzo efektywny magazyn dla danych typu BLOB (Binary Large Object Duży obiekt binarny), takich jak zdjęcia, filmy, dokumenty itp. Przed wprowadzeniem obsługi strumieni plikowych typu FILESTREAM konieczne było wybieranie pomiędzy przechowywaniem obiektów typu BLOB w bazie danych przy użyciu kolumn typu varbinary(max) (lub obecnie przestarzałego typu image) a przechowywaniem ich poza bazą danych jako nieuporządkowanych strumieni binarnych (czyli zwykle jako plików w systemie plików). Strumienie plikowe typu FILESTREAM oferują warstwę abstrakcji, która pozwala na logiczne traktowanie danych typu BLOB jako integralnej części bazy danych, podczas gdy faktyczne dane te będą zapisywane przez serwer SQL Server poza bazą danych, w systemie plików NTFS. W rozdziale tym przedstawione zostaną wszystkie informacje potrzebne do programowego korzystania ze strumieni plikowych typu FILESTREAM zarówno z poziomu języka T-SQL, jak również przy użyciu wydajnej klasy środowiska.net o nazwie SqlFileStream. Zamieszczone w tym rozdziale przykłady będą demonstrować sposób tworzenia aplikacji dla systemu Windows, aplikacji webowej oraz aplikacji opartej na platformie WPF (Windows Presentation Foundation), wykorzystującej strumienie plikowe typu FILESTREAM do przechowywania danych typu BLOB. W rozdziale tym omówiona zostanie także nowa funkcjonalność tabel plikowych typu FileTable, która została wprowadzona w wersji SQL Server 2012 i która opiera się na strumieniach plikowych typu FILESTREAM. Tabele plikowe typu FileTable łączą strumienie plikowe typu FILESTREAM, typ danych hierarchyid (omówiony w rozdziale 7) oraz interfejs API systemu plików Windows, ustanawiając nowy

24 xxiv Wprowadzenie poziom zarządzania przechowywanymi w bazie danych obiektami typu BLOB. Zgodnie ze swoją nazwą, jedna tabela plikowa typu FileTable pełni jednocześnie dwie odrębne role: tabeli oraz systemu plików. W rozdziale 8 pokażemy, w jaki sposób można korzystać z tej nowej możliwości z obu tych perspektyw. Rozdział 9: Obsługa danych geoprzestrzennych Rozdział 9 poświęcony został pojęciom goeprzestrzennym oraz rozbudowanej obsłudze danych przestrzennych, oferowanej przez typy danych geometry i geography. Te systemowe typy CLR umożliwiają łatwe wyposażenie tworzonych aplikacji w cechy zależne od położenia. Typy danych geometry i geography służą do przetwarzania dwóch podstawowych modeli geoprzestrzennych, tj. modelu planarnego (płaskiego) i geodezyjnego (kuli ziemskiej). Zapisywanie danych przestrzennych (reprezentowanych przez współrzędne geometryczne lub geograficzne) przy użyciu tych typów danych pozwala na wyznaczanie części wspólnych różnych obszarów oraz obliczanie odległości pomiędzy nimi, ich powierzchni oraz długości ich obwodów. Po krótkim przedstawieniu podstawowych informacji, w rozdziale tym zaprezentowane zostaną szczegółowe procedury tworzenia kilku aplikacji wykorzystujących dane geoprzestrzenne, w tym aplikacji integrującej się z mapami Microsoft Bing Maps. Omówione zostaną także istotne rozszerzenia związane z danymi przestrzennymi i wprowadzone w wersji SQL Server Pomimo faktu, że tej rozległej tematyce poświęcono wiele całych książek, rozdział 9 dostarcza wystarczającej ilości informacji, by możliwe było natychmiastowe rozpoczęcie korzystania z danych geoprzestrzennych. Część III: Stosowany SQL Poświęciwszy tak wiele miejsca omówieniu tego, co można zrobić na serwerze i w bazie danych, w części III zajmiemy się omówieniem różnych technologii, demonstrując techniki tworzenia aplikacji typu klient/serwer, aplikacji wielowarstwowych oraz rozwiązań opartych na chmurze. Rozdziały składające się na tę część powinny dostarczyć informacji pozwalających na rozszerzenie dostępności posiadanych danych, w każdym możliwym scenariuszu. Część tę zakończymy omówieniem platformy SQL Azure, stosu składników logiki biznesowej oraz nowej technologii magazynu kolumn, znanej pod nazwą xvelocity. Rozdział 10: Technologie dostępu do danych firmy Microsoft W rozdziale 10 omówione zostaną wszystkie możliwe strategie dostępu do danych, oferowane obecnie przez platformę.net Framework. Rozdział ten rozpoczniemy od omówienia najstarszych technik opartych na technologii Microsoft ADO.NET i surowych obiektach dostępu do danych, abstrakcji zapewnianej przez zbiory danych typu DataSet oraz znaczenia tych ciągle jeszcze stosowanych technologii opartych na platformie.net 1.0. Następnie omówione zostaną nowsze technologie dostępu do danych, włącznie z omówieniem koncepcji oraz składni języka

25 Organizacja tej książki xxv LINQ (Language-Integrated Query). Najpierw przyjrzymy się technologiom LINQ to DataSet i LINQ to SQL, by następnie zająć się intensywnie platformą ADO.NET Entity Framework (EF), stanowiącą obecnie zalecane przez firmę Microsoft rozwiązanie dostępu do danych na platformie.net. Omówimy również pojęcia związane z modelowaniem obiektowo relacyjnym (ORM Object Relational Modeling) i zademonstrujemy, w jaki sposób tworzenie na platformie EF modeli danych z encjami (EDM Entity Data Model) zapewnia użyteczną warstwę abstrakcji, pozwalającą na drastyczne uproszczenie procesu tworzenia aplikacji. Rozdział 11: Technologie dostępu do danych oparte na platformie WCF Po zapoznaniu się z prezentowanymi w rozdziale 10 technikami tworzenia aplikacji typu klient/serwer, będziemy już gotowi do udostępnienia posiadanych danych w formie ogólnodostępnej usługi. Rozdział 11 zawiera szczegółowe omówienie tego procesu wraz z przykładami kodu źródłowego korzystającego z dwóch technologii opartych na platformie WCF (Windows Communications Foundation). Pierwsza część rozdziału 11 poświęcona została omówieniu usługi WCF Data Services, wykorzystującej protokół REST (Representational State Transfer Protocol) oraz OData (Open Data Protocol) do zaimplementowania usługi opartej na posiadanym źródle danych. Po omówieniu kluczowych koncepcji związanych z tą usługą przedstawione zostaną konkretne przykłady jej praktycznego zastosowania. Monitorowanie podczas korzystania z tej usługi aktywności sieciowej oraz aktywności bazy danych pozwoli nam dotrzeć do wewnętrznych szczegółów działania tej technologii. W drugiej części tego rozdziału zademonstrowana zostanie natomiast technika dostępu do danych oparta na usłudze WCF RIA Services, reprezentującej najnowszą technologię przeznaczoną głównie dla klientów Silverlight (choć może ona obsługiwać także innych klientów). W rozdziale tym przedstawimy także różnice oraz podobieństwa istniejące pomiędzy tymi dwiema technologiami opartymi na platformie WCF wskazując jednocześnie, w jakich sytuacjach należy używać każdej z nich. Rozdział 12: Przenoszenie usług do chmury SQL Azure W rozdziale 12 przyjrzymy się możliwości utrzymywania baz danych w chmurze opartej na platformie SQL Azure. W rozdziale tym wyjaśnimy, czym jest platforma SQL Azure oraz jakie są jej podobieństwa do serwera SQL Server, a co ją od niego różni. Poruszone zostaną także kwestie związane z opłatami za korzystanie z platformy SQL Azure i wyjaśniony zostanie sposób zarejestrowania się na tej platformie, a także sposób przygotowywania na niej własnych serwerów i baz danych SQL Azure. Omówimy również zestaw narzędzi oferowanych przez platformę SQL Azure oraz sposób korzystania z tej platformy z poziomu programów SSMS i SSDT. Wyjaśnimy różne sposoby wykorzystywania tzw. aplikacji warstwy danych (DAC Data-Tier Applications) do przeprowadzania migracji baz danych pomiędzy serwerami SQL Server a serwerami SQL Azure przy użyciu programu SSMS, SSDT a także natywnych narzędzi platformy SQL Azure. Rozdział ten zakończymy omówieniem

26 xxvi Wprowadzenie specjalnej funkcjonalności partycjonowania danych, nazywanej federacjami SQL Azure, a także przyjrzymy się usłudze raportującej SQL Azure Reporting. Rozdział 13: Usługa SQL Azure Data Sync i tworzenie aplikacji dla systemu Windows Phone 7 Rozdział 13 poświęcony został szerokiemu zagadnieniu tzw. systemów z połączeniem okazjonalnym, prezentując kompletny przykład rozwiązania wykorzystującego usługę synchronizacji danych SQL Azure Data Sync, platformę Windows Azure oraz platformę programowania dla systemu Windows Phone 7. W rozwiązaniu tym lokalna baza danych serwera SQL Server synchronizowana będzie przy użyciu usługi SQL Azure Data Sync z udostępnioną publicznie bazą danych SQL Azure. Przechowywana w chmurze baza danych udostępniana będzie za pomocą usługi WCF Data Services (również działając w chmurze poprzez jej wdrożenie na platformie Windows Azure), a zapisane w niej dane będą używane przez aplikację mobilną używającą protokołu OData i działającą na urządzeniu z systemem Windows Phone 7. Zamieszczony w tym rozdziale szczegółowy opis tego pełnego rozwiązania demonstruje sposób współdziałania ze sobą różnych technologii, utrzymujących stan zsynchronizowania danych pomiędzy lokalną bazą danych SQL Server znajdującą się w chmurze bazą danych SQL Azure oraz lokalnym magazynem danych utrzymywanym na urządzeniu z systemem Windows Phone 7. Rozdział 14: Szersze spojrzenie na oprogramowanie SQL Server W rozdziale 14 zaprezentowane zostanie ogólne omówienie całego stosu elementów logiki biznesowej dla serwera SQL Server, obejmujące sprzętowe hurtownie danych z oprogramowaniem SQL Server w edycji Fast Track Data Warehouse, edycję SQL Server Parallel Data Warehouse, usługi integracji SQL Server Integration Services, usługi analityczne Analysis Services, usługi danych głównych Master Data Services, usługę jakości danych Data Quality Services, usługę raportującą Reporting Services, program Power View, dodatek PowerPivot oraz motor StreamInsight. Dla zachowania kompletności tego opisu omówione zostaną także pokrótce usługi programu Excel oraz usługa PerformancePoint Services portalu SharePoint, wraz z wyjaśnieniem sposobu, w jaki usługi te uzupełniają funkcjonalność serwera SQL Server. W rozdziale tym wyjaśnimy, do czego służą poszczególne składniki logiki biznesowej i w jaki sposób mogą one ze sobą współpracować. Prawdopodobnie najważniejsze w tym rozdziale będzie wyjaśnienie znaczenia tych technologii ze świata logiki biznesowej dla pracy z danymi relacyjnymi i pokazanie, jak łatwe może być przetwarzanie tych danych. Technologii tych nie należy traktować jako oddzielnych lub luźno ze sobą związanych elementów. Stanowią one integralną część oprogramowania SQL Server, a celem tego rozdziału jest uczynienie z nich także części rozwiązań tworzonych w oparciu o ten produkt. Rozdział 15: Technologie przetwarzania w pamięci xvelocity W rozdziale 15 przyjrzymy się opracowanej przez firmę Microsoft technologii magazynu kolumn, znanej pod nazwą xvelocity i pokażemy, w jaki sposób można używać

27 Konwencje stosowane w książce xxvii technologii z poziomu relacyjnej bazy danych serwera SQL Server, a także z poziomu dodatku PowerPivot oraz usługi analitycznej Analysis Services. Wyjaśnimy, w jaki sposób działają bazy danych zorientowane na dane kolumn i omówimy wprowadzoną w wersji SQL Server 2012 nową kategorię indeksów kolumn, a także związany z tymi indeksami tryb przetwarzania wsadowego. Zademonstrujemy, jak łatwe dla eksperta w dziedzinie relacyjnych baz danych może być korzystanie z dodatku PowerPivot oraz z trybu tabelarycznego usługi SSAS, a także w jaki sposób można połączyć ze sobą wszystkie te technologie za pomocą programu SQL Server Power View, będącego narzędziem służącym do analizowania, wykrywania i wizualizacji danych. Konwencje stosowane w książce Podczas prezentowania zawartych w tej książce informacji stosowane będą następujące konwencje, służące do poprawy przejrzystości prezentowanych informacji i ułatwiające ich przyswajanie. Elementy umieszczone w ramkach z etykietami, jak np. Uwaga, zawierają dodatkowe informacje lub opis alternatywnych sposobów poprawnego wykonania opisywanej operacji. Tekst, który ma zostać wpisany przez użytkownika (oprócz bloków kodu źródłowego) będzie wyróżniony czcionką pogrubioną. W ten sam sposób wyróżnione są nazwy funkcji i poleceń interfejsu użytkownika. Występujące w tekście elementy kodu źródłowego (oprócz bloków kodu źródłowego) będą wyróżniane czcionką pochyloną. Znak plus (+) występujący pomiędzy nazwami dwóch klawiszy oznacza, że klawisze te muszą zostać wciśnięte równocześnie. Przykładowo, zapis wciśnij klawisze Alt+Tab oznacza, że wciskając klawisz Tab należy przytrzymać wciśnięty klawisz Alt. Pionowa kreska oddzielająca dwa lub większą liczbę elementów menu (np. File Close) oznacza, że należy wybrać z menu najpierw pierwszą wymienioną pozycję, potem drugą, itd. Wymagania systemowe Osobom pragnącym na bieżąco wypróbowywać w praktyce informacje podawane w tej książce oraz uruchamiać zamieszczane przykłady kodu źródłowego, zaleca się zainstalowane na swoim komputerze edycji Developer oprogramowania SQL Server 2012, która jest dostępna dla większości programistów w ramach subskrypcji Microsoft MSDN Premium. Potrzebny będzie także program Visual Studio 2010; zalecane jest użycie edycji Professional lub jednej z wersji edycji Team każda z tych edycji również

28 xxviii Wprowadzenie jest dostępna w ramach odpowiadającej jej subskrypcji biuletynu MSDN Premium. Wszystkie zamieszczone w tej książce przykłady kodu źródłowego będą poprawnie działać także w mającej pojawić się niebawem wersji Visual Studio 11, która w chwili pisania tej książki znajdowała się jeszcze w fazie beta. WAŻNE Chcąc, by niniejsza książka obejmowała możliwie jak największy zakres funkcji, jej treść oparliśmy na edycji Developer oprogramowania SQL Server Edycja Developer dostarcza takiego samego zestawu funkcjonalności jak edycja Enterprise, z tym że warunki licencyjne edycji Developer wykluczają możliwość używania jej w środowisku produkcyjnym. Obie te edycje reprezentują zaawansowane platformy, oferujące pełny zestaw wszystkich funkcjonalności dostępnych w pozostałych edycjach produktu (Standard, Workgroup, Web oraz Express). Wierzymy, że omówienie pełnego zakresu programowej funkcjonalności oprogramowania SQL Server 2012, włącznie z funkcjami dostępnymi wyłącznie w edycjach Enterprise i Developer, leży w najlepszym interesie programistów korzystających z tej książki. Do uruchomienia wymienionych powyżej edycji oprogramowania SQL Server i Visual Studio, a tym samym także do uruchamiania zamieszczanych w tej książce przykładów, koniecznie jest posiadanie następującego oprogramowania i sprzętu w konfiguracji 32-bitowej (wymagania dla konfiguracji 64-bitowej nie zostały wymienione, ale są one bardzo podobne): Procesor taktowany zegarem o częstotliwości 1 GHz lub większej (zalecane 2 GHz). Jeden z następujących systemów operacyjnych: Microsoft Windows Server 2008 R2 SP1 Windows 7 SP1 (32-bitowy lub 64-biowy) Windows Server 2008 SP2 Windows Vista SP2 Dla wszystkich edycji oprogramowania SQL Server 2012 zaleca się posiadanie minimum 4 GB pamięci RAM (z wyjątkiem edycji Express, która wymaga tylko 1 GB). Do przeprowadzenia zalecanej instalacji oprogramowania SQL Server 2012 wymagane jest posiadanie około 1460 MB wolnego miejsca na dysku. Do zainstalowania dokumentacji SQL Server Books Online, dokumentacji SQL Server Mobile Everywhere Books Online oraz przykładowych baz danych wymagane będzie posiadanie dodatkowo jeszcze około 375 MB wolnego miejsca na dysku. Zainstalowanie programu Visual Studio 2010 zajmie na dysku maksymalnie 20 GB. Należy podkreślić, że wielkość ta obejmuje także miejsce potrzebne do zainstalowania pełnego zestawu dokumentacji MSDN.

29 Instalowanie pakietu SQL Server Data Tools xxix Działające połączenie z siecią Internet (wymagane do pobierania przykładowych kodów źródłowych z internetowej witryny powiązanej z książką). Połączenie internetowe jest także wymagane do działania niektórych z zamieszczonych w tej książce przykładów. Monitor i karta graficzna Super VGA o rozdzielczości lub wyższej. Mysz Microsoft Mouse lub inne kompatybilne urządzenie wskazujące. Przeglądarka internetowa Microsoft Internet Explorer 9.0 lub nowsza. Instalowanie pakietu SQL Server Data Tools Pakiet SSDT nie jest instalowany razem z programem Visual Studio ani z oprogramowaniem SQL Server. Pakiet SSDT jest dystrybuowany osobno za pomocą webowej platformy instalacyjnej WebPI (Web Platform Installer). Przyjęcie takiej formy dystrybucji pozwala firmie Microsoft na szybkie publikowanie aktualizacji pakietu SSDT, bez konieczności czekania na kolejną główną wersję oprogramowania Visual Studio lub SQL Server. Przed przystąpieniem do realizacji procedur opisywanych w rozdziale 1 należy pobrać i zainstalować pakiet SSDT korzystając ze strony com/en-us/data/hh Korzystanie z webowej witryny tej książki Webowa witryna tej książki znajduje się pod następującym adresem: Przykładowe kody źródłowe Wszystkie omawiane w tej książce przykładowe kody źródłowe można pobrać z webowej witryny tej książki. Nadrzędny folder z materiałami uzupełniającymi zawiera po jednym folderze podrzędnym dla każdego rozdziału tej książki. Z kolei każdy z tych folderów podrzędnych zawiera kody źródłowe dla przykładów zamieszczonych w danym rozdziale. Ponieważ większość tych przykładów jest szczegółowo omawiana w treści rozdziału, więc część Czytelników może preferować tworzenie ich od zera, zamiast otwierania gotowych wersji z materiałów uzupełniających dla danego rozdziału. Te gotowe wersje mogą jednak nadal być przydatne, np. w przypadku popełnienia niewielkiego błędu lub gdy Czytelnik zechce szybko uruchomić określony przykład, bez czytania jego opisu w treści rozdziału.

30 xxx Wprowadzenie Przykładowe bazy danych AdventureWorks Podobnie jak w przypadku wersji SQL Server 2005, firma Microsoft dostarcza zestaw przykładowych baz danych z popularnej rodziny AdventureWorks, dostosowanych do nowej wersji SQL Server W kilku rozdziałach tej książki występują odwołania do przykładowej bazy danych OLTP (Przetwarzanie transakcji w trybie online) o nazwie AdventureWorks2012, w rozdziale 15 występują odwołania do hurtowni danych o nazwie AdventureWorksDW2012. Chcąc aktywnie wykonywać procedury opisywane w tych rozdziałach, koniecznie będzie pobranie tych przykładowych baz danych bezpośrednio z internetowej witryny tej książki. Zamieszczone na tej witrynie bazy danych są dokładnymi kopiami baz, które były używane podczas pisania tej książki i które zostały pobrane z prowadzonej przez firmę Microsoft witryny ze źródłami typu open source o nazwie CodePlex (w rzeczywistości, na witrynie CodePlex umieszczane są wszystkie przykładowe kody źródłowe udostępniane oficjalnie przez firmę Microsoft). Aby zagwarantować, że wyniki otrzymywane podczas samodzielnego wykonywania opisywanych przykładów będą takie same jak wyniki zamieszczone w tej książce, zaleca się, by bazę danych OLTP AdventureWorks2012 oraz hurtownię danych AdventureWorksDW2012 pobrać z internetowej witryny tej książki, a nie z witryny CodePlex (ponieważ zaktualizowane wersje tych baz danych mogą dawać inne rezultaty niż nich oryginalne wersje). Instrukcje dotyczące sposobu podłączenia (użycia) tych przykładowych baz danych znajdują się na stronie umożliwiającej ich pobranie. Rozdziały z poprzednich edycji tej książki Oprócz kodów źródłowych z przykładami dla wszystkich rozdziałów, na internetowej witrynie tej książki znajduje się także kilka rozdziałów z poprzednich edycji tej książki, poświęconych wersjom 2008 i Treść tych rozdziałów nie została uaktualniona i dostosowana do funkcjonalności obecnej wersji SQL Server Dostępne do pobrania są rozdziały z edycji SQL Server 2005, poświęcone usłudze Service Broker, natywnym usługom XML Web Services, programowi SQL Server Management Studio, edycji SQL Server Express, usługom integracji Integration Services i debugowaniu, a także rozdziały z edycji SQL Server 2008 poświęcone hurtowniom danych, technologii przetwarzania analitycznego w trybie online (OLAP), wyszukiwaniu danych oraz usłudze raportującej Reporting Services.

31 Errata i pomoc techniczna xxxi Errata i pomoc techniczna Dołożono wszelkich starań mających na celu zapewnienie dokładności tej książki oraz towarzyszących jej treści uzupełniających. Informacje o wszelkich błędach, które zostały dostrzeżone i zgłoszone już po opublikowaniu tej książki, dostępne są na stronie wydawnictwa Microsoft Press utrzymywanej w domenie oreilly.com pod następującym adresem: W przypadku wykrycia nowego błędu można go zgłosić za pomocą tej samej, wymienionej powyżej strony. W razie potrzeby uzyskania dodatkowej pomocy technicznej związanej z tą książką, prosimy o skontaktowanie się nami za pomocą następującego adresu mspinput@microsoft.com. Prosimy pamiętać, że pod podanymi adresami nie jest oferowana pomoc techniczna dla oprogramowania firmy Microsoft. Oczekujemy na uwagi Czytelników Satysfakcja Czytelników jest najwyższym priorytetem wydawnictwa Microsoft Press i dlatego komentarze Czytelników są dla nas niezwykle cenne. Prosimy o dzielenie się swoimi opiniami na temat tej książki pod adresem: Pod podanym powyżej adresem dostępna jest krótka ankieta i zapewniamy, że czytamy wszystkie komentarze i pomysły naszych Czytelników. Z góry dziękujemy za czas poświęcony na jej wypełnienie! Pozostańmy w kontakcie Wydawnictwo Microsoft Press obecne jest na Twitterze pod następującym adresem:

32

33 Podziękowania Choć trudno w to uwierzyć, zbieranie materiałów do tej książki rozpocząłem już w październiku 2010 roku, podczas mającej miejsce w Redmond konferencji Software Design Review for SQL Server Denali. Jest to już druga edycja tej książki, której jestem głównym autorem i choć tym razem praca nad nią była dla mnie jeszcze bardziej satysfakcjonująca, to z pewnością nie była łatwiejsza niż praca nad edycją Moim celem było utworzenie najbardziej wyczerpującej (a mimo to przystępnej) pozycji w bibliotece każdego programisty korzystającego z serwera SQL Server 2012, takiej, która dawałaby odpowiedź na pytanie Na ile sposobów można programowo korzystać z serwera SQL Server?. Z pewnością nie mógłbym nawet myśleć o osiągnięciu tego celu bez pomocy wielu innych utalentowanych i bardzo pomocnych osób osób, które zasługują na szczególne uznanie. Kolejność wymienianych poniżej nazwisk w żadnym razie nie odzwierciedla wkładu tych osób w powstanie tej książki; mówiąc wprost bez ich pomocy nie zdołałbym jej napisać. Listę wielu osób, którym chciałbym podziękować, otwiera Craig Branning (dyrektor generalny Tallan, Inc.). Już w połowie roku 2010 Craig podszedł do mnie, żeby porozmawiać o tym projekcie. Zanim się obejrzałem, byłem już członkiem zespołu i jedliśmy razem lunch. Dziękuję Craigowi (a także wszystkim wspaniałym ludziom z firmy Tallan) za przyczynienie się do rozpoczęcia prac nad tą książką, a także za trwałe wsparcie podczas jej tworzenia. Miałem także niezwykłe szczęście znaleźć się w jednym zespole razem z moim kolegą i przyjacielem, Andrew Brustem (Microsoft MVP/RD), który jest jednym ze współautorów tej książki. Faktycznie jest to już trzeci raz, gdy wiedza i doświadczenie Andrew przyczyniają się do powstania książki; był on nie tylko współautorem edycji 2008, ale także głównym autorem pierwszej edycji dotyczącej wersji SQL Server Chciałby więc raz jeszcze podziękować Andrew za napisanie czterech, bardzo dobrych rozdziałów tego nowego wydania dotyczącego wersji Paul Delcogliano (który również miał swój wkład w powstanie edycji 2008) wykonał kawał dobrej roboty, zawierając w zaledwie jednym, lecz doskonałym rozdziale opis całego procesu tworzenia aplikacji opartych na technologiach SQL Azure Data Sync, Windows Azure oraz Windows Phone 7. Paul, Twoja ambicja jest godna podziwu i dziękuję Ci za Twoją niestrudzoną i doskonałą pracę! Na specjalną wzmiankę zasługuje Ken Jones, mój dobry kumpel z wydawnictwa O Reilly Media, za jego cenne wskazówki oraz niewzruszoną cierpliwość. Dziękuję Ci Ken, a także Twojej uroczej żonie Andrei za jej wnikliwą pomoc dotyczącą tematyki danych geoprzestrzennych. Miałem także dużo szczęścia mając okazję blisko współpracować z Russellem Jonesem, Melanie Yarbrough, Johnem Muellerem oraz xxxiii

34 xxxiv Podziękowania Christianem Holdenerem ich doskonała współpraca edytorska, recenzje i ogólne wskazówki przyczyniły się znacząco do ostatecznego wydania tej książki. Wsparcie udzielane mi przez wiele osób z różnych zespołów produktowych w firmie Microsoft pomogło mi uporać się z wyzwaniem, jakim było pisanie o nowym oprogramowaniu, gdy ciągle jeszcze ewoluowało ono przechodząc przez kilka wersji beta. Dziękuję Rogerowi Doherty za zaproszenie mnie w 2010 roku do Redmond na konferencję SDR, a także za skontaktowanie mnie z odpowiednimi osobami, których pomoc była niezbędna do wykonania mojego zadania. Szczególnie pomocni byli Gert Drapers i Adam Mahood, dostarczając mi wielu bardzo ciekawych informacji o zmianach w sposobie działania kolejnych wersji pakietu narzędziowego SSDT. Bezpośrednia komunikacja z Adamem, który zawsze miał dla mnie czas, zmieniła ciężką pracę nad jednym z rozdziałów w prawdziwą przyjemność. Doug Laudenschlager również był źródłem cennych informacji dotyczących nowej funkcjonalności nieuporządkowanych danych typu FILESTREAM. Oczywiście wielkie podziękowania należą się także całemu zespołowi produktowemu w firmie Microsoft za stworzenie jak dotąd najlepszej wersji serwera SQL Server! Jestem również szczególnie dumny z całkowicie nowego potraktowania w tej książce kwestii dostępu do danych z poziomu platformy.net i chciałbym złożyć szczególne podziękowania mojemu holenderskiemu kumplowi i posiadaczowi tytułów Microsoft MVP i RD, Marcelowi de Vries. Marcel jest prawdziwym ekspertem w dziedzinie architektur rozproszonych i jego nieoceniona pomoc miała duży wpływ na ostateczny kształt rozdziału poświęconego dostępowi do danych przy użyciu technologii WCF. Ik ben heel dankbaar voor jouw inbreng! Oczywiście ta książka nigdy by nie powstała bez miłości i wsparcia, jakiego doświadczałem ze strony swojej rodziny. Przez ostatnich osiemnaście miesięcy byłem tak bardzo pochłonięty realizacją tego projektu, że często byłem nieobecny. Mam ogromny dług wdzięczności wobec mojego partnera Marka i naszych fantastycznych dzieci, Adama, Jacqueline, Josha i Sonniego, za okazywaną mi cierpliwość i tolerancję. Ale największe podziękowania należą się mojej kochanej mamie, Panie pobłogosław jej duszę, za to, że zawsze zachęcała mnie do pisania w sposób ekspresyjny. Leonard Lobel Dla kogoś, kto nie jest pełnoetatowym autorem, żaden moment na napisanie książki nie jest dobry. Zawsze jest to zajęcie dodatkowe i zwykle zabierające znacznie więcej czasu, niż przewidywano. Staje się to dużym ciężarem dla wielu osób, a zwłaszcza dla rodziny autora, redaktorów książki, a także jej współautorów. Jeśli jeden z autorów właśnie otwiera nowy biznes, to ciężar ten staje się podwójny. Chciałbym więc podziękować w tym miejscu mojej rodzinie, zespołowi z wydawnictwa Microsoft Press, a zwłaszcza głównemu autorowi tej książki, Lenniemu Lobelowi, za okazywaną mi podczas tego ciężkiego okresu niezwykłą elastyczność i wyjątkową cierpliwość. Andrew Brust

35 CZĘŚĆ I Podstawy programowania w SQL Server 1 Omówienie pakietu oprogramowania SQL Server Data Tools 3 2 Rozszerzenia języka T-SQL 59 3 Eksploracja środowiska SQL CLR Praca z transakcjami Zabezpieczenia serwera SQL 257

36

37 ROZDZIAŁ 1 Omówienie pakietu oprogramowania SQL Server Data Tools Leonard Lobel Wraz z wersją SQL Server 2012, fi rma Microsoft dostarcza rozbudowane, nowe zintegrowane środowisko projektowe (IDE Integrated Development Environment) służące do projektowania, testowania i wdrażania baz danych serwera SQL Server lokalnie, w trybie offline lub w chmurze wprost z poziomu programu Microsoft Visual Studio (zarówno w wersji 2010 jak i przygotowywanej wersji Visual Studio 11, która w chwili pisania tej książki znajdowała się jeszcze w fazie beta). To nowe środowisko IDE nosi nazwę SQL Server Data Tools (SS DT) i oferuje znaczny postęp w stosunku do narzędzi dostępnych w poprzednich wersjach produktu, a zwłaszcza wobec programów SQL Server Management Studio (SSMS) oraz edycji Visual Studio Database Professional (DbPro). Pakiet oprogramowania SSDT nie ma być zamiennikiem programu SSMS, lecz należy traktować go jak o wiele bardziej rozwiniętą implementację programu DbPro. Rzeczywiście, program SSMS ma się całkiem dobrze w wersji SQL Server 2012 i dla administratorów baz danych nadal pozostaje on podstawowym narzędziem zarządzającym, służącym do konfigurowania i utrzymywania w dobrej kondycji działających instalacji serwera SQL Server. Wprawdzie program DbPro stanowił dobry krok w kierunku programowania baz danych w trybie offline, jednak ograniczone możliwości projektowe tego programu uniemożliwiły jego szersze upowszechnienie. Tak więc, przez lata do wykonywania zadań związanych z projektowaniem i programowaniem baz danych programiści używali głównie programu SSMS (a przed pojawieniem się wersji SQL Server 2005 zwykle używali dwóch narzędzi do zarządzania bazami danych programu Enterprise Manager oraz programu Query Analyzer [Analizator zapytań]). Podczas tworzenia aplikacji bazodanowych programiści od zawsze skazani byli na używanie w charakterze podstawowego środowiska programowego i projektowego różnych narzędzi zorientowanych na zarządzanie bazą danych (takich jak program SSMS), zamiast narzędzi przystosowanych do programowania (na przykład Visual Studio) aż do teraz. 3

38 4 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Pakiet oprogramowania SSDT oferuje pojedyncze środowisko osadzone w programie Visual Studio i wyposażone w narzędzia bazodanowe, które zostały specjalnie przystosowane do wymogów procesu tworzenia oprogramowania. Tak więc programiści mogą obecnie projektować i tworzyć swoje bazy danych bez konieczności ciągłego przełączania się pomiędzy programem Visual Studio a innymi narzędziami. W tym rozdziale pokażemy, w jaki sposób używać pakietu SSDT wewnątrz programu Visual Studio, by znacznie podnieść swoją produktywność jako programisty rozwiązań dla serwera SQL Server. Zaczniemy od ogólnego omówienia kluczowych koncepcji i funkcji pakietu SSDT, a następnie przejdziemy do demonstracji różnych scenariuszy pracy z połączeniem lub bez połączenia z bazą danych. Omówienie pakietu oprogramowania SSDT Narzędzia bazodanowe stworzone dla programistów Niewygodna prawda jest taka, że programowanie rozwiązań bazodanowych to trudna i ciężka praca. Zapewnienie prawidłowego działania wszystkich elementów tworzonego rozwiązania jest ogromnym wyzwaniem poprawne zaprojektowanie schematu i relacji, opanowanie wszystkich niuansów języka T-SQL (Transact-SQL), dostrajanie wydajności i wiele innych zadań, są już same w sobie wystarczająco trudne. Uwzględniając jednak specyfikę procesu tworzenia oprogramowania tj. sposobu tworzenia i zmieniania bazy danych istnieje kilka scenariuszy, w których posiadanie właściwych narzędzi może znacznie poprawić jakość i efektywność pracy programisty. Narzędzia te są dostarczane przez pakiet oprogramowania SSDT. Poniżej wymieniono kilka wyzwań, z którymi muszą zmierzyć się programiści podczas projektowania baz danych. Zależności Z samej natury rzeczy, bazy danych są pełne zależności istniejących pomiędzy różnymi rodzajami obiektów schematu. Komplikuje to proces tworzenia oprogramowania, ponieważ zależności te sprawiają, że nawet najprostsze zmiany mogą bardzo szybko stać sie bardzo skomplikowane. Późne wykrywanie błędów Programista może spędzić mnóstwo czasu na tworzeniu skomplikowanych skryptów, a ewentualne problemy mogą zostać dostrzeżone dopiero podczas wdrażania tych skryptów w bazie danych. Możliwe jest również, że przygotowane skrypty zostaną wdrożone bez błędów, lecz istniejący problem nie będzie manifestować się w żaden sposób, dopóki użytkownik nie napotka błędu fazy wykonywania. Wykrywanie dryftu Baza danych jest jak cel znajdujący się w ciągłym ruchu. Często zdarza się, że już po zakończeniu wdrożenia administratorzy instalują lub modyfikują coś w produkcyjnej bazie danych, np. dodają nowe indeksy w celu poprawienia wydajności zapytań kierowanych do konkretnych tabel.

39 Omówienie pakietu oprogramowania SSDT 5 Po rozsynchronizowaniu środowiska baza danych będzie znajdować się w innym stanie niż ten, jaki zakładał programista oraz stworzona przez niego aplikacja i wszelkie takie różnice muszą zostać zidentyfikowane i wyeliminowane. Wersjonowanie Programiści są już tak przyzwyczajeni do używania skryptów zmieniających bazę danych, że może powstać pytanie, gdzie właściwie znajduje się definicja bazy danych? Oczywiście można przyjąć, że definicję bazy danych można odczytać z niej samej, ale gdzie znajduje się definicja pozwalająca na zachowanie i ochronę bazy danych na wypadek jej utraty? W jaki sposób zachowywane są definicje potrzebne do działania różnych wersji stworzonej przez programistów aplikacji? Cofnięcie się do określonego momentu z przeszłości i odtworzenie wcześniejszej wersji bazy danych, która będzie dopasowana do wcześniejszej wersji aplikacji, może być zadaniem bardzo trudnym. Nie ma łatwego sposobu na synchronizowanie wersji oraz ich historii pomiędzy używaną bazą danych a korzystającą z niej aplikacją. Wdrożenie Na etapie wdrożenia pojawiają się nowe wyzwania związane z koniecznością dostosowania się do różnych wersji oprogramowania, obejmujących ostatnio również platformę SQL Azure. Może pojawić się konieczność wdrożenia tej samej bazy danych w różnych lokalizacjach i trzeba być przygotowanym na używanie różnych poziomów kompatybilności, gdyż w różnych lokalizacjach mogą być używane różne wersje oprogramowania SQL Server (takie jak SQL Server 2005, 2008, 2008 R2, 2012 lub SQL Azure). Wachlarz usług i narzędzi pakietu oprogramowania SSDT Pakiet oprogramowania SSDT obejmuje coś więcej niż tylko opisywane w tym rozdziale nowe narzędzia bazodanowe; w rzeczywistości jest to opakowana wersja narzędzia opartego na programie Visual Studio 2008, które poprzednio znane było pod nazwą Business Intelligence Developer Studio (BIDS). Oprócz nowych narzędzi bazodanowych, pakiet SSDT obsługuje tradycyjne typy projektów programu BIDS dla usług analitycznych serwera SQL Server (SSAS SQL Server Analysis Services), usług raportujących (SSRS SQL Server Reporting Services) i usług integracji (SSIS SQL Server Integration Services). Tak więc obecnie wszystkie narzędzia służące do tworzenia rozwiązań opartych na bazie danych SQL Server zostały połączone przez firmę Microsoft w jednej wersji platformy Visual Studio. Pomimo swej szerszej definicji, w tym rozdziale skrót SSDT używany będzie w kontekście nowych narzędzi programistycznych dodawanych przez pakiet SSDT do środowiska IDE programu Visual Studio.

40 6 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Wiele z wymienionych powyżej problemów ma swoje źródło w pojęciu tzw. stanowości bazy danych. Każda operacja kompilowania i uruchamiania aplikacji.net w programie Visual Studio powoduje zawsze zainicjowanie nowego stanu tej aplikacji, lecz baza danych, z której ta aplikacja ma korzystać, będzie wciąż starą bazą danych, z tym samym schematem i tymi samymi danymi. Tak więc programista zmuszony jest myśleć nie tylko o projekcie bazy danych, ale także o sposobie implementacji tego projektu w jaki sposób dokonać przeniesienia projektu do bazy danych, z uwzględnieniem jej aktualnego stanu. Skoro problemy te wynikają z faktu, że baza danych jest obiektem stanowym, to podstawą ich rozwiązania powinna być zmiana stylu pracy z imperatywnego na deklaratywny. Tak więc zamiast zwykłego używania skryptów zmian, pakiet SSDT pozwala na styl pracy oparty na deklaracji tego, jak naszym zdaniem wygląda (lub powinna wyglądać) baza danych. Pozwala to na skoncentrowanie się na projekcie i pozostawienie odpowiednim narzędziom zadania napisania skryptów zmian, które w bezpieczny sposób zastosują przygotowany projekt w faktycznej implementacji docelowej bazy danych. Pakiet SSDT stosuje podejście oparte na modelu deklaratywnym, a w trakcie lektury tego rozdziału przekonamy się, dlaczego takie podejście stanowi remedium na wymienione wcześniej problemy. Programowanie deklaratywne w oparciu o model bazy danych Zaczęliśmy właśnie wyjaśniać, że pakiet oprogramowania SSDT używa podejścia deklaratywnego, opartego na modelu bazy danych. Oznacza to, że w pamięci zawsze znajduje się reprezentacja stanu bazy danych model bazy danych pakietu SSDT i że z modelu tego korzystają wszystkie narzędzia pakietu SSDT (narzędzia projektowe, sprawdzające, moduły podpowiedzi IntelliSense, narzędzia do porównywania schematów itp.). Model ten może zostać utworzony na podstawie aktualnie podłączonej bazy danych (znajdującej się w siedzibie firmy lub na serwerach usługi SQL Azure), na podstawie projektu bazy danych w stanie offline, zapisanego w systemie kontroli wersji lub na podstawie obrazu migawkowego wykonanego dla projektu bazy danych w stanie offline (z obrazów migawkowych korzystać będziemy w ćwiczeniach, zamieszczonych w dalszej części tego rozdziału). Powtórzmy zatem raz jeszcze dla dostępnych narzędzi nie ma znaczenia na jakiej podstawie sporządzony został model bazy danych, narzędzia te korzystają bowiem wyłącznie z samego modelu. Dzięki temu programista może cieszyć się z jednakowych warunków pracy, które będą takie same dla każdego scenariusza, niezależnie od tego czy pracuje on z bazą danych znajdującą się w siedzibie firmy, czy z bazą danych przechowywaną w chmurze, z projektami offline czy z wersjonowanymi obrazami migawkowymi. W języku T-SQL reprezentacja dowolnego obiektu istniejącego w modelu SSDT ma zawsze postać instrukcji CREATE. Instrukcja ALTER nie ma bowiem sensu w kontekście deklaratywnym instrukcja CREATE deklaruje, jak dany obiekt powinien

41 Omówienie pakietu oprogramowania SSDT 7 wyglądać i jest to jedyna rzecz, na której powinien skupiać się programista. Oczywiście, w zależności od aktualnego stanu docelowej bazy danych, poprawne wdrożenie definicji obiektu wymagać będzie użycia w skrypcie zmian instrukcji CREATE (jeśli dany obiekt jeszcze nie istnieje) albo instrukcji ALTER (jeśli obiekt ten już istnieje). Co więcej, jeśli z danym obiektem związane będą jakieś zależności (a bardzo często są), proces wdrożenia może wymagać także usunięcia i ponownego utworzenia również innych obiektów. Na szczęście wykrywanie wszelkich zmian ( różnic ) pomiędzy używaną definicją modelu a faktycznie istniejącą bazą danych, które muszą zostać uwzględnione podczas tworzenia odpowiedniego skryptu zmian, można pozostawić oprogramowaniu SSDT. Dzięki temu programista może skupić się wyłącznie na używanej definicji. Podejście do programowania baz danych oparte na modelu zostało zilustrowane na rysunku 1-1. SQL Server Data Tools (SSDT) Model bazy danych Projekt typu SQL Server Database Project SQL Server 2005, 2008, 2008 R2, 2012 LocalDB SQL Azure Plik migawkowego obrazu bazy danych (.dacpac) RYSUNEK 1-1 Oprogramowanie SSDT pracuje z modelem utworzonym na podstawie podłączonej bazy danych (znajdującej się w siedzibie firmy lub w chmurze), projektów offline bazy danych lub plików z obrazem migawkowym bazy danych. Programowanie w trybie z połączeniem Wprawdzie oprogramowanie SSDT kładzie duży nacisk na model deklaratywny, ale w żadnym razie nie uniemożliwia ono pracy z działającą bazą danych w sposób imperatywny, jeśli istnieje taka potrzeba. Okno zapytań umożliwia tworzenie instrukcji w języku T-SQL i wykonywanie ich bezpośrednio na podłączonej bazie danych, w razie potrzeby także z użyciem debugera, zupełnie tak samo jak w programie SSMS. Praca z pakietem oprogramowania SSDT w trybie z połączeniem opiera się na nowym eksploratorze obiektów (SQL Server Object Explorer) z programu Visual Studio. Okno

42 8 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools tego nowego, dokowalnego narzędzia może być używane do wykonywania typowych zadań związanych z programowaniem baz danych, które poprzednio wymagały użycia programu SSMS. Korzystanie z nowego eksploratora obiektów jest bardzo podobne do pracy z podłączoną bazą danych przy użyciu eksploratora obiektów z programu SSMS ale nie należy zapominać (choć ryzykujemy zbytnie wyolbrzymienie tego faktu), że narzędzia dostępne w pakiecie SSDT działają wyłącznie na modelu bazy danych. Tak więc pracując w trybie z połączeniem oprogramowanie SSDT faktycznie tworzy (w locie) model oparty na prawdziwej bazie danych, a następnie pozwala nam na edytowanie tego modelu. To podejście oparte na buforowaniu stanowi subtelną, lecz istotną różnicę pomiędzy sposobem działania programów SSDT i SSMS. Zapisując zmiany schematu wykonane przy użyciu nowego projektanta tabel, oprogramowanie SSDT opracowuje niezbędne skrypty zmian, potrzebne do uaktualnienia prawdziwej bazy danych w taki sposób, by odzwierciedlała ona zmianę (lub zmiany) wykonaną na modelu. Oczywiście rezultat końcowy będzie taki sam jak w przypadku pracy z programem SSMS i podłączoną bazą danych, więc zrozumienie szczegółów związanych z takim buforowanym działaniem nie jest absolutnie niezbędne. Jednak gdy tylko dobrze poznamy zasadę działania tego mechanizmu, tworzenie projektów w trybie offline oraz możliwość wersjonowania obrazów migawkowych wydadzą się nam natychmiast naturalne i intuicyjne. Wynika to z faktu, że projekty offline oraz obrazy migawkowe to po prostu inne metody uzyskiwania dokładnie tego samego modelu w pakiecie SSDT. Model używany podczas pracy z eksploratorem obiektów serwera SQL Server tworzony jest po prostu na podstawie działającej i podłączonej bazy danych. Z programowaniem baz danych przy użyciu oprogramowania SSDT, używającego podejścia opartego na buforowaniu zmian w trakcie trwania połączenia, wiąże się jeszcze kilka niuansów wartych odnotowania. W procesie stosowania zamian w bazie danych faktycznie wykorzystywane są dwa modele. Tuż przed zastosowaniem przez oprogramowanie SSDT wprowadzonych zmian schematu następuje faktyczne utworzenie nowego modelu aktualnie podłączonej bazy danych. Pakiet SSDT używa tego modelu jako modelu docelowego, porównując go z modelem używanym podczas edycji. Takie podejście oparte na podwójnym modelu zapewnia mechanizm wykrywania dryftu, który jest niezbędny do tego, by operacja porównywania schematów (na której oprogramowanie SSDT opiera przygotowywany skrypt zmian) uwzględniała także wszelkie zmiany schematu, które mogły zostać wprowadzone przez innego użytkownika od chwili rozpoczęcia edycji używanej wersji modelu. Kontrola poprawności wykryje wówczas wszelkie problemy spowodowane przez zmiany dokonane przez innego użytkownika (które w chwili rozpoczęcia edycji mogły jeszcze nie istnieć). Programowanie w trybie bez połączenia Nowy eksplorator obiektów serwera SQL Server (SQL Server Object Explorer) pozwala na połączenie się oraz na interakcję z dowolną bazą danych, wprost z poziomu

43 Omówienie pakietu oprogramowania SSDT 9 programu Visual Studio. Jednak pakiet oprogramowania SSDT oferuje znacznie więcej niż zwykły zamiennik dla programu SSMS używanego w trybie z połączeniem. Oferuje on także bogate możliwości pracy w trybie offline przy użyciu nowego typu projektu (SQL Server Database Project) oraz lokalnego środowiska uruchomieniowego bazy danych (LocalDB). Wszystkie pliki skryptów w języku T-SQL wchodzące w skład projektu typu SQL Server Database Project są z natury skryptami deklaratywnymi (tzn. zawierają wyłącznie instrukcje CREATE i żadnych instrukcji ALTER). Takie podejście jest radykalnie odmienne od tego, do czego przyzwyczajeni są programiści programujący bazę danych za pomocą programu SSMS (gdzie instrukcja ALTER jest używa znacznie częściej niż instrukcja CREATE). Powtórzmy zatem raz jeszcze, programista powinien skoncentrować się na tym jak baza danych powinna wyglądać pozwalając, by używane przez niego narzędzie ustaliło odpowiednią postać skryptu zmian, potrzebną do faktycznego uaktualnienia działającej na żywo bazy danych do stanu, który będzie zgodny z przygotowaną przez programistę definicją. Osoby mające już pewne doświadczenie w pracy z edycją Database Professional (DbPro) programu Visual Studio natychmiast rozpoznają wiele podobieństw pomiędzy projektami programu DbPro typu Database Projects a projektami pakietu SSDT typu SQL Server Database Projects. Pomimo dużych podobieństw, typy projektów pakietu SSDT różnią się jednak od typów projektów programu DbPro i w oknie dialogowym Add New Project (Dodaj nowy projekt) programu Visual Studio są one dostępne jako osobny szablon projektu. Nowe narzędzie projektanta tabel, mechanizm buforowanego połączenia oraz inne opisywane w tym rozdziale funkcje pakietu SSDT działają wyłącznie z projektami pakietu SSDT typu SQL Server Database Projects. Jak można się jednak domyślić, istniejące projekty programu DbPro można łatwo uaktualnić do wersji używanej w pakiecie SSDT. W tym celu wystarczy po prostu kliknąć prawym klawiszem myszy projekt wyświetlany w oknie eksploratora rozwiązań (Solution Explorer) i wybrać z menu kontekstowego polecenie Convert To SQL Server Database Project (Konwertuj na projekt bazy danych serwera SQL Server). Należy pamiętać, że taka aktualizacja możliwa jest tylko w jedną stronę oraz że wszelkie elementy programu DbPro, które nie są jeszcze obsługiwane przez oprogramowanie SSDT (takie jak plany generowania danych patrz notka), nie zostaną przekonwertowane. UWAGA Istnieje kilka ważnych funkcji, które nadal dostępne są tylko w programie DbPro, wśród których najważniejsze to generowanie danych, porównywanie danych, widoki schematu oraz testy jednostkowe bazy danych. Planuje się, że w przyszłości pakiet SSDT dostarczać będzie także kluczowe elementy z zestawu funkcji oferowanych przez program DbPro i całkowicie zastąpi edycję Database Professional programu Visual Studio. Na razie jednak funkcje, które nie zostały jeszcze zaimplementowane w pakiecie oprogramowania SSDT, ciągle jeszcze wymagają korzystania z programu DbPro.

44 10 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Nowy typ projektów SQL Server Database Project (Projekt bazy danych serwera SQL Server) oferuje w większości te same możliwości i funkcje, które dostępne są także dla innych typów projektów programu Visual Studio. Obejmuje to nie tylko kontrolę wersji dla każdej definicji pojedynczego obiektu bazy danych, ale także wiele typowych funkcji służących do refaktoryzacji oraz poruszania się po kodzie źródłowym, których programiści oczekują od nowoczesnego środowiska IDE (takich jak funkcje Rename [Zmień nazwę], Goto Definition [Idź do definicji] lub Find All References [Znajdź wszystkie odwołania]). Rozbudowane metadane modelu bazy danych używanego przez pakiet SSDT zapewniają także znacznie lepsze działanie funkcji IntelliSense w stosunku do tego, co oferował program SSMS od wersji SQL Server 2008, dając programiście znacznie lepsze poczucie silnej kontroli typów w trakcie tworzenia kodu źródłowego. Możliwe jest także ustawianie punktów przerwania (ang. breakpoint), krokowe wykonywanie kodu w języku T-SQL, a także korzystanie z okna Locals (Zmienne lokalne) w bardzo podobny sposób, jak podczas debugowania projektów typu.net. Dzięki pakietowi SSDT, wszystkie aplikacje i narzędzia służące do programowania baz danych zostały w końcu zunifikowane pod jednym wspólnym dachem, którym jest program Visual Studio. Główną zaletą podejścia opartego na modelu bazy danych jest fakt, że używane modele mogą być generowane na podstawie wielu różnych źródeł. Jak już wcześniej wyjaśniliśmy, podczas bezpośredniego połączenia z bazą danych za pomocą eksploratora obiektów oprogramowanie SSDT generuje model na podstawie aktualnie podłączonej bazy danych. Podczas tworzenia nowego projektu typu SQL Server Database Project (który może zostać importowany z dowolnej istniejącej bazy danych, skryptu lub obrazu migawkowego), wewnątrz programu Visual Studio następuje utworzenie objętego kontrolą wersji projektu typu offline, który zawierać będzie pełny opis istniejącej realnie bazy danych. Należy jednak pamiętać, że będzie to tylko projekt, a nie rzeczywista baza danych. Następnie oprogramowanie SSDT wygeneruje model, który będzie używany przez utworzony projekt typu SQL Server Database Project. Jak więc widać, praca w trybie offline nie będzie różnić się od pracy w trybie z połączeniem narzędzia projektowe, funkcja IntelliSense, sprawdzenia poprawności i wszelkie inne narzędzia będą działać dokładnie w taki sam sposób. W trakcie programowania bazy danych w ramach utworzonego projektu będziemy mieć do czynienia z taką samą kompilacją w tle, z jaką zwykle można zetknąć się podczas programowania rozwiązań dla platformy.net, np. w języku C# lub VB.NET. Przykładowo, wykonanie zmiany w projekcie, której nie będzie można zastosować w bazie danych z powodu istniejących zależności, spowoduje wygenerowanie ostrzeżenia w fazie programowania i wyświetlenie odpowiedniego błędu w panelu Error List (Lista błędów). Możliwe jest wówczas kliknięcie komunikatu takiego ostrzeżenia lub błędu, co spowoduje bezpośrednie przejście do odpowiednich zależności, umożliwiając ich rozwiązanie. Gdy wszystkie błędy zostaną już rozwiązane i znikną z panelu błędów, możliwe będzie przesłanie wykonanych zmian i zastosowanie ich w bazie danych.

45 Omówienie pakietu oprogramowania SSDT 11 Wersjonowanie i obrazy migawkowe Projekt bazy danych dostarcza nam definicji offline tej bazy danych. Podobnie jak w przypadku wszystkich projektów programu Visual Studio, każdy obiekt bazy danych (tabela, widok, procedura składowana oraz każdy inny rodzaj obiektu) istnieje w pliku tekstowym, który można umieścić w systemie kontroli kodu źródłowego. System projektu w połączeniu z systemem kontroli kodu źródłowego pozwala zabezpieczyć definicję takiego obiektu w programie Visual Studio, eliminując konieczność polegania na definicji obiektu zapisanej w samej bazie danych. W każdej chwili programista może utworzyć obraz migawkowy bazy danych i może to robić tak często, jak tylko zechce. Obraz migawkowy to nic innego jak plik (w formacie dacpac [Data-tier Application Component Package Pakiet składnika aplikacji warstwy danych]) przechowujący serializowany stan modelu bazy danych, oparty na aktualnym stanie projektu, istniejący w chwili wykonania takiego obrazu migawkowego. Jest to po prostu zapisana w pojedynczym pliku reprezentacja całego schematu bazy danych. Obrazy migawkowe mogą następnie zostać ponownie zdeserializowane i możliwe będzie używanie ich z dowolnymi narzędziami pakietu SSDT (np. z narzędziem do porównywania schematów). Tak więc struktury baz danych można tworzyć, wdrażać i synchronizować pomiędzy bazami lokalnymi lub przechowywanymi w chmurze a projektami offline używającymi różnych systemów wersjonowania, posługując się przy tym spójnym zestawem narzędzi. Zatrzymajmy się na chwilę, aby zastanowić się nad potężnymi możliwościami, jakich dostarczają obrazy migawkowe. Obraz migawkowy umieszcza całą strukturę bazy danych w pojedynczym pliku typu.dacpac, który w każdej chwili może zostać natychmiast zdeserializowany i przekształcony z powrotem w model bazy danych. Tak więc obrazy migawkowe mogą być używane zarówno jako źródło lub jako cel dla operacji porównywania schematu z działającą bazą danych (utrzymywaną w siedzibie firmy lub w chmurze SQL Azure), z projektem offline typu SQL Server Database Project lub z innym obrazem migawkowym, wykonanym w dowolnym innym momencie. Obrazy migawkowe mogą być również pomocne w sytuacji, gdy nie dysponujemy dostępem do docelowej bazy danych, lecz zakładamy jedynie przekazanie administratorowi tej bazy danych odpowiedniego skryptu zmian do wykonania. Oprócz samego skryptu zmian, możliwe jest także wysłanie administratorowi migawkowego obrazu projektu bazy danych, wykonanego tuż przed wprowadzeniem jakichkolwiek zmian w trybie offline. Taki obraz migawkowy reprezentuje założenia przyjęte w utworzonym skrypcie zmian odnośnie faktycznego stanu używanej bazy danych. Dzięki temu administrator bazy danych będzie mógł wykonać kolejną operację porównywania schematu pomiędzy przesłanym mu obrazem migawkowym a działającą bazą danych (operację taką można wykonać z poziomu wiersza poleceń pakietu SSDT lub z poziomu programu Visual Studio). Rezultat porównania tych schematów pozwoli administratorowi zorientować się, czy może on bezpiecznie uruchomić otrzymany skrypt zmian. Jeśli

46 12 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools wynik porównywania ujawni rozbieżności pomiędzy działającą bazą danych a obrazem migawkowym użytym do utworzenia skryptu zmian, administrator bazy danych będzie mógł odrzucić taki skrypt i poinformować programistę o zaistniałym problemie. Tworzenie kodu dla różnych platform docelowych Dla projektów typu SQL Server Database Projects określa się ich platformę docelową, co pozwala na określenie wersji oprogramowania SQL Server, dla której przeznaczony jest dany projekt. Na ustawieniu tym opierają się wszystkie sprawdzenia poprawności wykonywane dla używanego modelu bazy danych, co sprawia, że zadanie testowania i wdrażania bazy danych dla konkretnej wersji oprogramowania SQL Server (2005 lub nowszej), w tym także dla wersji SQL Azure, staje się banalnie proste. Np. aby upewnić się, czy przygotowaną bazę danych można będzie bez problemu wdrożyć w chmurze, wystarczy po prostu wybrać jako platformę docelową wersję SQL Azure. Jeśli przygotowany projekt bazy danych definiować będzie jakiekolwiek elementy, które nie są obsługiwane w wersji SQL Azure (np. tabelę bez indeksu klastrowanego), zostaną one automatycznie oznaczone jako błędne. Korzystanie z pakietu oprogramowania SSDT Po omówieniu zestawu narzędzi oferowanych przez oprogramowanie SSDT pora na zapoznanie się z nimi w praktyce. Pozostała cześć tego rozdziału zawiera opis przykładowego scenariusza, demonstrującego krok po kroku sposób używania wielu z omówionych dotychczas funkcji pakietu SSDT. Praktyczne wykonywanie opisywanych w tym ćwiczeniu czynności pozwoli na ugruntowanie dotychczasowej wiedzy, lepsze poznanie dostępnych narzędzi i przygotowanie się do praktycznego wykorzystywania oprogramowania SSDT podczas pracy z prawdziwymi projektami baz danych. WAŻNE Oprogramowanie SSDT nie jest instalowane razem z programem Visual Studio ani razem z oprogramowaniem SQL Server, lecz jest ono dostarczane osobno za pomocą platformy WebPI (Web Platform Installer Instalator platformy webowej). Pozwala to firmie Microsoft na szybkie dystrybuowanie aktualizacji oprogramowania SSDT (bez konieczności czekania na wydanie kolejnych wersji głównych oprogramowania Visual Studio lub SQL Server). Przed kontynuowaniem lektury dalszej części tego rozdziału należy pobrać i zainstalować oprogramowanie SSDT korzystając z adresu en-us/data/hh

47 Korzystanie z pakietu oprogramowania SSDT 13 Łączenie sie z bazą danych za pomocą eksploratora obiektów SQL Server Object Explorer Nasza podróż rozpoczyna się od utworzenia bazy danych. Zaczniemy od użycia pakietu SSDT do uruchomienia w oknie zapytań przygotowanego skryptu, który utworzy nową bazę danych na podłączonej instancji serwera SQL Server. Następnie korzystając z oprogramowania SSDT będziemy pracować bezpośrednio z podłączoną bazą danych. Taki sposób pracy jest bardzo podobny do pracy z poprzednimi wersjami różnych narzędzi, a więc doskonale nadaje się na początek. Nieco później przejdziemy do pracy w trybie bez połączenia, przy użyciu projektów offline. Po uruchomieniu programu Visual Studio 2010 należy otworzyć menu View (Widok) i wybrać z niego polecenie SQL Server Object Explorer (Eksplorator obiektów serwera SQL Server). Spowoduje to wyświetlenie w oknie programu Visual Studio nowego panelu SQL Server Object Explorer (który domyślnie będzie zadokowany po lewej stronie). Okno tego nowego narzędzia stanowić będzie centralny punkt dla działań wykonywanych za pomocą pakietu SSDT, związanych z programowaniem baz danych w trybie z połączeniem. Eksplorator obiektów umożliwia łatwe łączenie się z dowolną instancją serwera, dla której dysponujemy odpowiednimi poświadczeniami tożsamości. W omawianym scenariuszu instancją tą będzie instancja lokalna (localhost), używająca pełnej instalacji oprogramowania SQL Server 2012 w edycji Developer. Możemy wyobrażać sobie, że instancja ta jest produkcyjnym serwerem bazy danych, znajdującym się w firmowym centrum danych. Naszym kolejnym krokiem będzie więc połączenie się z tym produkcyjnym serwerem bazy danych. Po kliknięciu prawym przyciskiem myszy węzła SQL Server, znajdującego się na szczycie hierarchii wyświetlanej w panelu eksploratora obiektów, należy wybrać z menu kontekstowego polecenie Add SQL Server (Dodaj serwer SQL Server) i jako nazwę serwera wpisać nazwę własnego komputera. Wprawdzie w tym przypadku możliwe jest również użycie nazwy localhost (lub nawet tylko pojedynczego znaku kropki, który jest skrótem dla nazwy localhost), zalecamy jednak użycie nazwy komputera. Wynika to z faktu, że wkrótce zapoznamy się z lokalnym środowiskiem uruchomieniowym bazy danych (LocalDB), które jest oferowane przez instancję LocalDB dla potrzeb testowania i debugowania w trybie offline. Instancja LocalDB zawsze jest instancją lokalną, podczas gdy baza produkcyjna tylko czasami działa na komputerze lokalnym. Ponieważ wyświetlanie przez eksplorator obiektów instancji localhost oraz localdb mogłoby być dezorientujące, użycie konkretnej nazwy komputera zamiast nazwy localhost pozwoli na wyraźne rozróżnienie produkcyjne bazy danych oraz bazy danych używanej do lokalnego programowania (w trybie offline) i testowania przy użyciu oprogramowania SSDT. Zamieszczone w tym rozdziale zrzuty ekranowe zostały wykonane na komputerze z systemem Windows Server 2008 R2 o nazwie SQL2012DEV i nazwa ta będzie używana w dalszej części tego rozdziału jako nazwa produkcyjnej bazy danych, działającej na komputerze lokalnym. Oczywiście Czytelnicy powinni

48 14 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools zastępować każde odwołanie do używanej w tym rozdziale nazwy SQL2012DEV nazwą własnego komputera. Jeśli podczas instalacji oprogramowania SQL Server wybrana została opcja uwierzytelniania mieszanego, a nie zamierzamy korzystać z uwierzytelniania systemu Windows, to przed uzyskaniem połączenia konieczne będzie wybranie opcji uwierzytelniania serwera SQL Server i podanie odpowiednich poświadczeń tożsamości. Po uzyskaniu połączenia, w panelu eksploratora obiektów wyświetlony zostanie nowy węzeł reprezentujący serwer produkcyjny, którego rozwinięcie pozwala na zapoznanie się z listą działających na tym serwerze baz danych, co zostało pokazane na rysunku 1-2. RYSUNEK 1-2 Rozwinięte drzewo nowego eksploratora obiektów z programu Visual Studio pokazujące kilka podłączonych baz danych Jeśli połączenie zostało zestawione bez żadnych błędów, należy kliknąć prawym klawiszem myszy węzeł reprezentujący instancję serwera SQL2012DEV i wybrać z menu kontekstowego polecenie New Query (Nowe zapytanie). Program Visual Studio otworzy wówczas nowe okno edytora kodu w języku T-SQL, które powinno wyglądać podobnie jak to pokazane na rysunku 1-3. RYSUNEK 1-3 Okno zapytań dla trybu z połączeniem

49 Korzystanie z pakietu oprogramowania SSDT 15 Dostępne środowisko powinno być znajome dla wszystkich osób mających już pewne doświadczenie w pracy z programami SSMS lub Query Analyzer (Analizator zapytań). Należy zwrócić uwagę na wyświetlany w dolnej części ekranu pasek statusu informujący, że okno zapytań jest aktualnie połączone z instancją SQL2012DEV (przypomnijmy raz jeszcze, że faktycznie będzie to nazwa używanego komputera). Pasek narzędziowy, znajdujący się w górnej części okna, zawiera rozwijaną listę wskazującą aktualną, domyślną bazę danych dla podłączonej instancji. Podobnie jak to miało miejsce w przypadku poprzednich narzędzi, bazą tą jest baza danych master (co widać na rysunku 1-3). Nadal więc konieczne jest pamiętanie o zmianie tego ustawienia (lub używanie odpowiedniej instrukcji USE), tak by przez pomyłkę nie używać bazy danych master, zamiast bazy danych aplikacji. Ponieważ w tym ćwiczeniu będziemy tworzyć zupełnie nową bazę danych, więc tym razem bieżącą bazą danych może być baza danych master. WSKAZÓWKA Fakt ustawiania dla każdego loginu bazy danych master jako bazy domyślnej może rodzić pewne obawy. Doskonałym sposobem zabezpieczenia się przed przypadkowym użyciem bazy danych master podczas korzystania z pakietu SSDT (lub dowolnego innego narzędzia) jest zmiana domyślnej bazy danych dla używanego loginu na odpowiednią bazę danych aplikacji, która wówczas będzie domyślną bazą danych (zamiast bazy master) w każdym nowym oknie zapytań. Pozwala to poważnie obniżyć ryzyko przypadkowego uszkodzenia danych znajdujących się w bazie danych master, co mogłoby mieć katastrofalne konsekwencje. Po rozwinięciu w eksploratorze obiektów węzła Security (Zabezpieczenia) i otwarciu okna Properties (Właściwości) dla swojego własnego loginu będziemy mogli przekonać się, że domyślną bazą danych tego loginu jest właśnie baza danych master, lecz nie będziemy mogli tego zmienić. Zmiana domyślnej bazy danych jest bowiem zadaniem zarządzającym, które nie jest obsługiwane przez zestaw narzędzi pakietu SSDT, choć nadal możliwe jest użycie okna zapytań pakietu SSDT do wykonania odpowiedniego polecenia ALTER LOGIN. Alternatywnym rozwiązaniem jest wykonanie takiej zmiany za pomocą programu SSMS. W tym celu należy uruchomić program SSMS, połączyć się z odpowiednią instancją serwera i odszukać przy pomocy eksploratora obiektów swój login, rozwijając węzły Security (Zabezpieczenia) i Logins. Następnie należy kliknąć ten login prawym klawiszem myszy i wybrać z menu kontekstowego polecenie Properties (Właściwości), kliknąć pole rozwijanej listy Default Database (Domyślna baza danych), wybrać z tej listy bazę danych używaną przez naszą aplikację i kliknąć przycisk OK. Od tej chwili, we wszystkich nowych oknach zapytań otwieranych w programie SSDT, domyślną bazą danych będzie wskazana przez nas baza danych (a nie baza master). W otwartym wcześniej oknie zapytań należy teraz wpisać kod z listingu 1-1 (lub otworzyć gotowy plik skryptu, który można pobrać z witryny webowej tej książki; szczegóły dotyczące pobierania przykładowych kodów źródłowych znajdują się we wstępie do tej książki, w sekcji zatytułowanej Przykładowe kody źródłowe). Zapewne część

50 16 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Czytelników zechce uruchomić ten skrypt poprzez wciśnięcie klawisza F5, ale w tym przypadku to nie zadziała. W przypadku oprogramowania SSDT osadzonego w programie Visual Studio wciśnięcie klawisza F5 powoduje zbudowanie (skompilowanie) i wdrożenie projektu typu SQL Server Database Project w instancji debugowania (projekt tego typu zostanie utworzony później, ale na razie jeszcze nim nie dysponujemy). Jest to całkiem odmienne od sposobu, w jaki klawisz F5 jest używany w programach SSMS oraz Query Analyzer (Analizator zapytań) do natychmiastowego wykonania bieżącego skryptu (lub aktualnie zaznaczonej części skryptu). Pakiet oprogramowania SSDT używa do tego celu zupełnie innego skrótu klawiaturowego. W rzeczywistości dostępne są nawet dwa takie skróty (odpowiadające przyciskom paska narzędziowego oraz poleceniom menu kontekstowego); jeden służący do wykonywania kodu bez użycia debugera (Ctrl+Shift+E) i jeden do wykonywania kodu z podłączonym debugerem (Alt+F5). Ponieważ debugowanie przećwiczymy praktycznie w dalszej części rozdziału, więc na razie należy po prostu wcisnąć kombinację klawiszy Ctrl+Shift+E, co spowoduje natychmiastowe uruchomienie skryptu i utworzenie nowej bazy danych (możliwe jest również kliknięcie przycisku Execute Query [Wykonaj zapytanie] znajdującego się na pasku narzędziowym lub kliknięcie prawym przyciskiem myszy w dowolnym miejscu okna z kodem skryptu i wybranie z menu kontekstowego polecenia Execute [Wykonaj]). LISTING 1-1 Skrypt w języku T-SQL służący do utworzenia przykładowej bazy danych SampleDb CREATE DATABASE SampleDb GO USE SampleDb GO -- Tworzenie tabel customer i order CREATE TABLE Customer( CustomerId bigint NOT NULL PRIMARY KEY, FirstName varchar(50) NOT NULL, LastName varchar(50) NOT NULL, CustomerRanking varchar(50) NULL) CREATE TABLE OrderHeader( OrderHeaderId bigint NOT NULL, CustomerId bigint NOT NULL, OrderTotal money NOT NULL) -- Tworzenie relacji ALTER TABLE OrderHeader ADD CONSTRAINT FK_OrderHeader_Customer FOREIGN KEY(CustomerId) REFERENCES Customer(CustomerId) -- Dodanie kilku klinetów INSERT INTO Customer (CustomerId, FirstName, LastName, CustomerRanking) VALUES (1, 'Lukas', 'Keller', NULL),

51 Korzystanie z pakietu oprogramowania SSDT 17 (2, 'Jeff', 'Hay', 'Good'), (3, 'Keith', 'Harris', 'so-so'), (4, 'Simon', 'Pearson', 'A+'), (5, 'Matt', 'Hink', 'Stellar'), (6, 'April', 'Reagan', '') -- Dodanie kilku zamówień INSERT INTO OrderHeader(OrderHeaderId, CustomerId, OrderTotal) VALUES (1, 2, 28.50), (2, 2, ), -- Jeff's orders (3, 3, 12.99), -- Keith's orders (4, 4, ), (5, 4, ), -- Simon's orders (6, 5, ), (7, 5, ), -- Matt's orders (8, 6, 18.50), (9, 6, 10.00), (10, 6, 18.00) -- April's orders GO -- Tworzenie podręcznego widoku podsumowującego zamówienia klienta CREATE VIEW vwcustomerordersummary WITH SCHEMABINDING AS SELECT c.customerid, c.firstname, c.lastname, c.customerranking, ISNULL(SUM(oh.OrderTotal), 0) AS OrderTotal FROM dbo.customer AS c LEFT OUTER JOIN dbo.orderheader AS oh ON c.customerid = oh.customerid GROUP BY c.customerid, c.firstname, c.lastname, c.customerranking GO Jest to bardzo prosty skrypt, którego działanie zostanie omówione za chwilę. Najpierw jednak zwrócimy uwagę na to, co się stało. Pakiet SSDT wykonał ten skrypt bezpośrednio na podłączonej instancji serwera SQL Server, a następnie podzielił okno kodu na dwie części, wyświetlając w dolnym panelu komunikaty zwracane przez serwer. Wyświetlana w lewym dolnym rogu zielona ikona oznaczona etykietą Query Executed Successfully (Zapytanie zostało wykonane pomyślnie) informuje, że wykonywanie skryptu przebiegło bez problemów. Ponieważ skrypt zawierał dwie wielowierszowe instrukcje INSERT, które zostały użyte do wstawienia przykładowych danych klientów i ich zamówień, więc w dolnej części panelu Message (Komunikat) widoczne będą dwa komunikaty typu rows affected (informujące o liczbie wierszy, których dotyczyła wykonana instrukcja), co zostało pokazane na rysunku 1-4. Jak dotąd, sposób pracy z pakietem SSDT nie różni się zbytnio od tego, co oferowały poprzednie narzędzia, dzięki czemu programiści przyzwyczajeni do starszego zestawu narzędzi będą mogli łatwo przestawić się na pracę z oprogramowaniem SSDT. Ten prosty skrypt utworzył bazę danych o nazwie SampleDb, zawierającą dwie tabele: Customer (Klient) i OrderHeader (Nagłówek zamówienia). Zdefiniował on również na kolumnach CustomerId z obydwu tabel klucz obcy tworzący pomiędzy tymi tabelami relację typu nadrzędny-podrzędny (jeden-do-wielu). Następnie do utworzonych tabel dodanych zostało kilku klientów wraz z kilkoma zamówieniami. Na koniec utworzony został widok podsumowujący zamówienia poszczególnych klientów poprzez zagregowanie całkowitych wartości wszystkich ich zamówień.

52 18 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools RYSUNEK 1-4 Okno zapytań po pomyślnym wykonaniu skryptu w języku T-SQL Wykonamy teraz dwa zapytania zwracające pewne dane. W dolnej części okna kodu należy wpisać następujące dwie instrukcje SELECT: SELECT * FROM Customer SELECT * FROM vwcustomerordersummary Należy zwrócić uwagę na podpowiedzi funkcji IntelliSense, wyświetlane w trakcie wpisywania tych instrukcji. Jeśli po wpisaniu powyższego kodu zatrzymamy kursor myszy nad nazwą tabeli Customer, a następnie nad nazwą widoku vwcustomerordersummary, to program Visual Studio wyświetli odpowiednie podpowiedzi z opisem tej tabeli lub widoku. Zatrzymanie kursora myszy nad symbolem gwiazdki w każdej z wpisanych instrukcji SELECT spowoduje natomiast wyświetlenie podpowiedzi z listą wszystkich pól reprezentowanych w danym zapytaniu przez symbol gwiazdki. Funkcjonalność ta zapewniana jest przez działające w tle usługi bazy danych oprogramowania SSDT, które ciągle odpytują model bazy danych utworzony na podstawie podłączonej bazy SampleDb. Zaznaczmy teraz (poprzez podświetlenie) tylko podane powyżej dwie instrukcje SELECT (pozostawiając niezaznaczoną całość skryptu znajdującego się powyżej tych instrukcji) i wciśnijmy kombinację klawiszy Ctrl+Shift+E. Rezultat będzie podobny do wciśnięcia klawisza F5 w programie SSMS lub w programie Query Analyzer: wykonany zostanie tylko zaznaczony tekst (czyli tak jak należało się tego spodziewać). Program SSDT wykona oba zapytania i wyświetli ich rezultat tak, jak to zostało pokazane na rysunku 1-5.

53 Korzystanie z pakietu oprogramowania SSDT 19 RYSUNEK 1-5 Przeglądanie wyników wykonania instrukcji zaznaczonych w oknie zapytań Ponieważ okno zapytań nie będzie już nam potrzebne, możemy je zamknąć (nie ma również potrzeby zapisywania skryptu). Po kliknięciu prawym przyciskiem myszy węzła Databases, wyświetlanego w panelu eksploratora obiektów, należy wybrać z menu kontekstowego polecenie Refresh (Odśwież). Spowoduje to wyświetlenie nowego węzła bazy danych SampleDb, którego rozwijanie pozwala schodzić na niższe poziomy szczegółowości. Jak widać z rysunku 1-6, dostępne środowisko jest bardzo podobne to tego, które oferuje eksplorator obiektów w programie SSMS i pozwala na wykonywanie większości (jednak nie wszystkich) zadań związanych z programowaniem, które można było wykonywać w programie SSMS. Po wykonaniu opisanych czynności na serwerze SQL2012DEV znajdować się będzie gotowa i działająca baza danych. Wszystko wyglądało doskonale aż do czasu odebrania a z działu sprzedaży, którego zespół właśnie sformułował dla nas kilka nowych wymagań oznaczających, że czeka nas więcej pracy do wykonania.

54 20 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools RYSUNEK 1-6 Węzeł bazy danych SampleDb rozwinięty w oknie eksploratora obiektów i ukazujący kilka obiektów tej bazy danych Zbieranie nowych wymagań Nowe wymagania związane są ze sposobem szeregowania klientów w tabeli Customer. Pierwotnie dział sprzedaży zażądał dodania kolumny CustomerRanking, która miała pełnić rolę prostego mechanizmu, pozwalającego operatorowi wprowadzającemu dane na określanie pozycji danego klienta w ogólnym rankingu klientów. Takie doraźne szeregowanie klientów z założenia miało być luźno oparte na całkowitej wartości wszystkich zamówień danego klienta, ale jak widać z wartości widocznych na rysunku 1-5 w kolumnie CustomerRanking, podczas wprowadzania danych nie została zachowana żadna spójność pomiędzy wartościami tej kolumny a wartościami zamówień klienta (co nie powinno nas dziwić). Kolumna ta zawiera między innymi takie wartości jak np. A+, so-so (taki sobie) lub Good (Dobry). Dla części klientów kolumna ta nie dostarcza w ogóle żadnych sensownych informacji, zawierając takie dane jak np. pusty łańcuch znakowy, spacje lub wartości NULL.

55 Korzystanie z pakietu oprogramowania SSDT 21 Aby poprawić tę sytuację zespół działu sprzedaży chce usunąć kolumnę z danymi wprowadzanymi przez operatora na bieżąco i zastąpić ją sformalizowanym systemem szeregowania klientów, który będzie lepiej dostosowany do pierwotnych założeń. Do wiadomości z żądaniem zmiany (która naturalnie opatrzona jest flagą Pilne), dołączony został arkusz kalkulacyjny pokazany na rysunku 1-7, zawierający dane bazowe dla nowych, wstępnie zdefiniowanych poziomów w rankingu klientów. Wiadomość ta zawiera także wzmiankę o wdrożeniu rozwiązania na platformie SQL Azure i uzupełniona jest dopiskiem P.S. Opisane zmiany są potrzebne na piątek (co również nie powinno nas dziwić). RYSUNEK 1-7 Dane bazowe dla nowego systemu szeregowania klientów Po dokładnym przemyśleniu całej sprawy, sporządzamy sobie listę ogólnych zadań do wykonania. Lista ta wyszczególnia planowane kroki, mające na celu spełnienie wymagań działu sprzedaży: 1. Usunąć kolumnę CustomerRanking z tabeli Customer. 2. Utworzyć nową tabelę CustomerRanking w oparciu o dane z arkusza kalkulacyjnego, pokazanego na rysunku 1-7, z kolumną klucza głównego o nazwie CustomerRankingId, przechowującą wartości z zakresu od 1 do Dodać nową kolumnę CustomerRankingId do tabeli Customer. 4. Utworzyć klucz obcy na kolumnie CustomerRankingId w celu ustalenia relacji pomiędzy tabelą Customer a nową tabelą CustomerRanking. 5. Uaktualnić widok vwcustomerordersummary tak, by korzystał ze złączenia z nową tabelą CustomerRanking. 6. Utworzyć nową procedurę składowaną o nazwie usprankcustomers, służącą do aktualizowania nowej kolumny klucza obcego w tabeli Customer, w oparciu o całkowitą wartość wszystkich zamówień danego klienta. 7. Sprawdzić poprawność rozwiązania pod kątem jego kompatybilności z platformą SQL Azure, a następnie wdrożyć je w chmurze.

56 22 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Pozostała część tego rozdziału zawierać będzie szczegółowy opis poszczególnych kroków powyższej procedury. Przy okazji poznamy wiele ważnych funkcji oprogramowania SSDT oraz zaznajomimy się ze sposobem działania nowego zestawu narzędzi. Czas zatem na rozpoczęcie realizacji pierwszego kroku naszej procedury: usunięcie kolumny z tabeli. UWAGA Prezentowany tu scenariusz jest oczywiście nieco sztuczny. Nie upieramy się, że przedstawione kroki stanowią najlepszy sposób rozwiązania tego konkretnego problemu i mamy nadzieję, że Czytelnicy zastosują w swoich własnych bazach danych lepsze rozwiązania. Jednakże dla celów tego ćwiczenia tj. poznania sposobów korzystania z oprogramowania SSDT prosimy Czytelników, by zastosowali opisywane w tym rozdziale rozwiązania. Założenia opisywanego ćwiczenia są być może nieco nienaturalne, ale poszczególne kroki jego rozwiązania dobrze reprezentują typowe czynności, wykonywane codziennie przez typowego programistę baz danych serwera SQL Server. Korzystanie z narzędzia Table Designer (w trybie z połączeniem) W oknie eksploratora obiektów SQL Server Object Explorer należy kliknąć prawym klawiszem myszy tabelę Customer i wybrać z menu kontekstowego polecenie View Designer (Pokaż projektanta), aby otworzyć okno projektanta tabel pakietu SSDT, pokazane na rysunku 1-8. RYSUNEK 1-8 Nowy projektant tabel z pakietu SSDT W górnym, lewym panelu okna tego projektanta wyświetlana jest siatka z listą zdefiniowanych kolumn, zupełnie taka sama jak w projektancie tabel programu SSMS, ale na tym kończą się podobieństwa obu tych narzędzi. Nowy projektant z pakietu

57 Korzystanie z pakietu oprogramowania SSDT 23 SSDT wykorzystuje zupełnie inny mechanizm, którego działanie powinno być jednak łatwe do zrozumienia po dotychczasowym opisie podejścia opartego na modelu deklaratywnym. Wątpliwości budzi instrukcja CREATE TABLE, znajdująca się w dolnej części okna z kodem w języku T-SQL. Skoro wiemy, że tabela istnieje już w bazie danych, to dlaczego projektant używa instrukcji CREATE? Otóż wynika to z faktu, że kod w języku T-SQL, który jest wyświetlany w tym oknie, nie jest faktycznie tym samym kodem, który ma zostać wykonany w istniejącej bazie danych w niezmienionej postaci (co oczywiście skończyłoby się błędem, ponieważ taka tabela istnieje już w bazie danych). Kod ten stanowi raczej rodzaj deklaracji w języku T-SQL, mówiącej jak ta tabela powinna wyglądać, niezależnie od tego czy ona już istnieje w docelowej bazie danych, czy nie a także niezależnie od tego czy tabela ta istnieje w innym schemacie, czy nie. W rzeczywistości projektant operuje na modelu bazy danych przechowywanym w pamięci, wewnątrz swojego środowiska roboczego. Ponieważ pracujemy z podłączoną bazą danych, model ten został faktycznie utworzony na podstawie działającej bazy danych SampleDb. Jeśli jednak przełączymy się na pracę z projektem typu SQL Server Database Project w trybie offline (co uczynimy w kolejnej części tego rozdziału), będziemy korzystać z dokładnie tego samego narzędzia projektanta, które tym razem będzie korzystać z modelu utworzonego na podstawie projektu, a nie na podstawie prawdziwej bazy danych. Używany model może również zostać utworzony na podstawie obrazu migawkowego bazy danych. Ponieważ projektant tabel operuje właśnie na modelu, te same narzędzia będą działać jednakowo w każdym z tych scenariuszy. Chcemy usunąć z tabeli kolumnę CustomerRanking, co można zrobić usuwając tę kolumnę z siatki wyświetlanej w górnym panelu lub poprzez edycję deklaratywnego kodu w języku T-SQL, znajdującego się w dolnym panelu. Oba te panele są jedynie widokiem tej samej tabeli, a więc wszelkie zmiany wykonywane w jednym panelu będą uwidaczniane w drugim panelu. Podczas realizacji opisywanego w tym rozdziale ćwiczenia będziemy eksperymentować z różnymi technikami edycji przy użyciu projektanta tabel, zaczynając od metody najszybszej, polegającej po prostu na kliknięciu prawym przyciskiem myszy wyświetlanej w górnym panelu kolumny CustomerRankingin i wybraniu z menu kontekstowego polecenia Delete (Usuń). Spowoduje to usunięcie kolumny z siatki i jak można się było tego spodziewać, zmiana zostanie także odzwierciedlona poprzez odpowiednią aktualizację kodu w języku T-SQL. To była całkiem prosta zmiana. Zastosowanie tej zmiany w bazie danych również powinno być proste. W tym celu wystarczy po prostu kliknąć znajdujący się na pasku narzędziowym przycisk Update (Aktualizuj). Niestety, zamiast oczekiwanego rezultatu kliknięcie tego przycisku spowoduje wyświetlenie następującego komunikatu błędu: Update cannot proceed due to validation errors. Please correct the following errors and try again. (Aktualizacja nie może zostać wykonana z powodu błędów walidacji. Proszę skorygować poniższe błędy i spróbować ponownie.)

58 24 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools SQL71501 :: View: [dbo].[vwcustomerordersummary] contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects: [dbo].[customer]. [c]::[customerranking], [dbo].[customer].[customerranking] or [dbo].[orderheader]. [c]::[customerranking]. SQL71501 :: View: [dbo].[vwcustomerordersummary] contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects: [dbo].[customer]. [c]::[customerranking], [dbo].[customer].[customerranking] or [dbo].[orderheader]. [c]::[customerranking]. SQL71558 :: The object reference [dbo].[customer].[customerid] differs only by case from the object definition [dbo].[customer].[customerid]. SQL71558 :: The object reference [dbo].[orderheader].[customerid] differs only by case from the object definition [dbo].[orderheader].[customerid]. (SQL71501 :: Widok: [dbo].[vwcustomerordersummary] zawiera nierozwiązane odwołanie do obiektu. Obiekt ten albo nie istnieje, albo odwołanie do niego jest niejednoznaczne, ponieważ może ono oznaczać dowolny z wymienionych poniżej obiektów: [dbo].[customer].[c]::[customerranking], [dbo].[customer].[customerranking] lub [dbo].[orderheader].[c]::[customerranking]. SQL71501 :: Widok: [dbo].[vwcustomerordersummary] zawiera nierozwiązane odwołanie do obiektu. Obiekt ten albo nie istnieje, albo odwołanie do niego jest niejednoznaczne, ponieważ może ono oznaczać dowolny z wymienionych poniżej obiektów: [dbo].[customer].[c]::[customerranking], [dbo].[customer].[customerranking] lub [dbo].[orderheader].[c]::[customerranking]. SQL71558 :: Odwołanie do obiektu [dbo].[customer].[customerid] różni się jedynie wielkością liter od definicji obiektu [dbo].[customer].[customerid]. SQL71558 :: Odwołanie do obiektu [dbo].[orderheader].[customerid] różni się jedynie wielkością liter od definicji obiektu [dbo].[orderheader].[customerid].) Co poszło źle? Jeśli cofniemy się z powrotem do kodu z listingu 1-1, zauważymy, że definicja widoku vwcustomerordersummary zawiera klauzulę WITH SCHEMABINDING. Oznacza to, że kolumny tego widoku są powiązane z używanymi przez widok tabelami, co chroni nas przed zepsuciem widoku w wyniku zmian schematu co właśnie usiłowaliśmy zrobić. Zgodnie z informacjami podanymi w dwóch pierwszych komunikatach błędów, problem polega na tym, że kolumna CustomerRanking związanego ze schematem widoku została nagle usunięta z używanej przez ten widok tabeli Customers. Pozostałe dwa błędy to faktycznie jedynie ostrzeżenia związane z wielkością liter w nazwach obiektów, które same w sobie nie stanowiłyby przeszkody do pomyślnej aktualizacji bazy danych. Znaczenie tych ostrzeżeń zostanie wyjaśnione nieco później; na razie skoncentrujemy się na problemie zależności, uniemożliwiających przeprowadzenie aktualizacji bazy danych. Interesującą rzeczą, na którą warto zwrócić uwagę w tym miejscu, jest fakt, że oprogramowanie SSDT wychwyciło całą sytuację jeszcze przed podjęciem faktycznej próby zastosowania wprowadzonych zmian w działającej bazie danych (co oczywiście zakończyłoby się błędem). W rzeczywistości, gdyby panel Error List (Lista błędów) został otwarty już wcześniej, to wykrycie tego problemu byłoby możliwe nawet jeszcze przed kliknięciem przycisku Update, ponieważ w trakcie edycji bazy danych za pomocą

59 Korzystanie z pakietu oprogramowania SSDT 25 narzędzi projektowych oprogramowanie SSDT przeprowadza w tle ciągłą walidację wszystkich zmian pod kątem ich zgodności z używanym modelem. Kliknięcie przycisku Cancel (Anuluj) spowoduje zamknięcie okna błędów. Następnie należy kliknąć menu View (Widok) i wybrać z niego polecenie Error List (Lista błędów), aby ponownie otworzyć panel błędów. Należy zwrócić uwagę na sposób wyświetlania błędów i ostrzeżeń, który jest taki sam jak sposób wyświetlania błędów kompilacji dla projektów w języku C# i VB.NET. Podobnie jak w przypadku projektów w wymienionych językach programowania, dwukrotne kliknięcie elementów wyświetlanych w panelu Error List spowoduje natychmiastowe przejście do fragmentu kodu powodującego dany błąd, umożliwiając jego poprawienie. W tym przypadku oba błędy spowodowane są zależnościami związanymi z widokiem vwcustomerorder- Summary, a więc dwukrotne kliknięcie któregokolwiek z nich spowoduje otwarcie edytora kodu z definicją tego widoku, tak jak to zostało pokazane na rysunku 1-9. RYSUNEK 1-9 Wykrywanie i nawigowanie po błędach walidacji Powinniśmy przedefiniować ten widok tak, by korzystał z nowej tabeli CustomerRanking, ale musimy z tym poczekać aż do punktu 4 na naszej liście zadań. Na razie więc dokonamy minimalnej edycji tego widoku, koniecznej do wyeliminowania błędów walidacji (które są sygnalizowane podkreśleniem czerwoną falistą linią, podobnie jak w innych oknach programu Visual Studio służących do edycji kodu źródłowego), co pozwoli na zaktualizowanie bazy danych i przejście do kolejnego kroku. Z widoku należy usunąć oba odwołania (poprzez ich wykomentowanie) do kolumny c.customerranking

60 26 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools (jedno występuje na liście kolumn, a drugie w klauzuli GROUP BY). Proszę zwrócić uwagę na fakt, że poprawianie kodu powodować będzie znikanie błędów z panelu Error List. Jest to jeden z efektów wykorzystywania modelu bazy danych, używanego przez narzędzia pakietu SQL Server Data Tools w programie Visual Studio. Pusty panel Error List oznacza, że wszystkie wprowadzone zmiany są prawidłowe. Dotychczas zmodyfikowaliśmy już tabelę oraz widok, ale zmiany te zostały wykonane tylko na przechowywanym w pamięci modelu bazy danych. Zmienione obiekty są aktualnie otwarte w osobnych oknach programu Visual Studio i w obu tych oknach znajdują się przyciski Update. Nie ma jednak znaczenia, który z tych przycisków zostanie kliknięty w każdym przypadku kliknięcie przycisku Update oznacza wysłanie do bazy danych wszystkich, zbuforowanych dotychczas zmian. Tak więc niezależnie od tego, który z tych dwóch przycisków zostanie kliknięty, zmiany wprowadzone podczas edycji tabeli oraz podczas edycji widoku zostaną jednocześnie zastosowane w bazie danych. W jaki sposób ma się to odbyć? Wykonane przez nas zmiany są dość proste, ale skrypt zmian w języku T-SQL, którego zadaniem będzie zastosowanie tych zmian, jest nieco bardziej złożony. Na tym właśnie polega piękno nowego zestawu narzędzi całą złożoność tego skryptu bierze na siebie oprogramowanie SSDT. Odpowiednie narzędzie porównuje zmieniony przez nas model bazy danych z zupełnie nowym modelem opartym na działającej bazie danych i na tej podstawie tworzy automatycznie odpowiedni skrypt zmian. Tworzenie świeżego modelu bazy danych gwarantuje, że będziemy używać najnowszego stanu bazy danych, na wypadek wystąpienia dryftu od chwili utworzenia modelu używanego w bieżącej sesji edycji. Następnie narzędzie to wykonuje wewnętrzną operację porównywania schematów pomiędzy zmienionym modelem (źródłowym) a najnowszym modelem opartym na działającej bazie danych (docelowym) i identyfikuje wszystkie różnice pomiędzy tymi modelami. Ostatecznie oprogramowanie SSDT generuje skrypt zmian, który może zostać wykonany na działającej bazie danych w celu zastosowania wprowadzonych przez nas zmian. Kliknijmy zatem przycisk Update, aby wygenerować skrypt zmian. Przed uruchomieniem skryptu zmian oprogramowanie SSDT wyświetli raport informujący o wszystkich działaniach, które zostaną wykonane przez skrypt zmian. Kliknięcie przycisku Update spowoduje wyświetlenie okna Preview Database Updates (Podgląd aktualizacji bazy danych), pokazanego na rysunku Należy zawsze przeglądać informacje podawane w tym oknie, aby upewnić się, że są one spójne z tym, czego oczekujemy w wyniku przeprowadzonej edycji bazy danych. W tym przypadku zostaniemy ostrzeżeni o utracie danych z tabeli Customer, spowodowanej usunięciem kolumny CustomerRanking. Okno to zawiera także informacje, że powiązanie ze schematem widoku vwcustomerordersummary zostanie usunięte i ponownie utworzone przed oraz po zmodyfikowaniu tabeli. Ponieważ wszystkie te zmiany są zgodne z naszymi oczekiwaniami, więc możemy kliknąć przycisk Update Database (Aktualizuj bazę danych), aby spowodować natychmiastowe uruchomienie

61 Korzystanie z pakietu oprogramowania SSDT 27 skryptu zmian lub kliknąć przycisk Generate Script (Generuj skrypt), aby załadować skrypt zmian do okna edytora kodu, co pozwoli na przejrzenie zawartości skryptu, jego ewentualną modyfikację i zdecydowanie, czy należy wykonać ten skrypt, czy nie. RYSUNEK 1-10 Okno podglądu dla planowanych aktualizacji bazy danych W większości przypadków można jednak spokojnie kliknąć przycisk Update Database, zwłaszcza jeśli wcześniej zostały przejrzane ostrzeżenia i akcje raportowane w oknie podglądu planowanej aktualizacji bazy danych (zgodnie z wcześniejszym zaleceniem). Kliknięcie tego przycisku spowoduje natychmiastowe wykonanie skryptu zmian i zaktualizowanie działającej bazy danych. Jednakże biorąc pod uwagę fakt, że jest to nasza pierwsza operacja aktualizacji bazy danych, kliknijmy przycisk Generate Script, co pozwoli nam na zapoznanie się z treścią skryptu przed jego uruchomieniem. Treść tego skryptu została przedstawiona w listingu 1-2 (dla skrócenia listingu część kodu służąca do sprawdzania błędów została wykomentowana). LISTING 1-2 Skrypt zmian dla zmodyfikowanej tabeli i widoku, wygenerowany automatycznie przez oprogramowanie SSDT /* Deployment script for SampleDb */ //... :setvar DatabaseName "SampleDb" GO //... USE [$(DatabaseName)]; GO //... BEGIN TRANSACTION

62 28 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools GO PRINT N'Removing schema binding from [dbo].[vwcustomerordersummary]...'; GO ALTER VIEW [dbo].[vwcustomerordersummary] AS SELECT c.customerid, c.firstname, c.lastname, c.customerranking, ISNULL(SUM(oh.OrderTotal), 0) AS OrderTotal FROM dbo.customer AS c LEFT OUTER JOIN dbo.orderheader AS oh ON c.customerid = oh.customerid GROUP BY c.customerid, c.firstname, c.lastname, c.customerranking; //... GO PRINT N'Altering [dbo].[customer]...'; GO ALTER TABLE [dbo].[customer] DROP COLUMN [CustomerRanking]; GO //... PRINT N'Adding schema binding to [dbo].[vwcustomerordersummary]...'; GO -- Utworzenie przydatnego widoku podsumowującego zamówienia klientów ALTER VIEW vwcustomerordersummary WITH SCHEMABINDING AS SELECT c.customerid, c.firstname, c.lastname, ISNULL(SUM(oh.OrderTotal), 0) AS OrderTotal FROM dbo.customer AS c LEFT OUTER JOIN dbo.orderheader AS oh ON c.customerid = oh.customerid GROUP BY c.customerid, c.firstname, c.lastname GO //... BEGIN PRINT N'The transacted portion of the database update succeeded.' COMMIT TRANSACTION END ELSE PRINT N'The transacted portion of the database update failed.' GO DROP TABLE #tmperrors GO PRINT N'Update complete.' GO To naprawdę wspaniałe, że nie musimy samodzielnie tworzyć skryptu zmian, nadal jednak ważne jest, abyśmy rozumieli sposób jego działania. Przyjrzyjmy się zatem pokrótce zawartości tego skryptu.

63 Korzystanie z pakietu oprogramowania SSDT 29 Najpierw skrypt wykonuje podstawienie wartości do zmiennej i używa tej zmiennej w instrukcji USE, która ustala jako bieżącą bazę danych bazę SampleDbas, a następnie następuje otwarcie nowej transakcji. Transakcja ta zostanie zatwierdzona tylko wówczas, gdy cały skrypt zostanie wykonany bez błędów. Kolejną instrukcją skryptu jest instrukcja ALTER VIEW, która usuwa z widoku vwcustomerordersummary jego powiązanie ze schematem, jednak nie zmieniając jeszcze definicji tego widoku. Tak więc widok ten nadal zawiera dwa odwołania do kolumny CustomerRanking, która za chwilę zostanie usunięta z tabeli Customer, ponieważ jednak z definicji widoku usunięta została klauzula WITH SCHEMABINDING, nie stanowi to już problemu. Kolejna instrukcja to instrukcja ALTER TABLE, która dokonuje faktycznego usunięcia kolumny z tabeli. Po usunięciu kolumny, wykonana zostaje kolejna instrukcja ALTER VIEW ustalająca nową wersję widoku vwcustomerordersummary, która nie odwołuje się już do usuniętej kolumny i tworząca ponowne powiązanie tego widoku ze schematem. Na końcu skryptu następuje zatwierdzenie transakcji, co kończy cały proces aktualizacji bazy danych. Wciśnijmy teraz kombinację klawiszy Ctrl+Shift+E. Spowoduje to wykonanie skryptu i wyświetlenie w panelu Messages (Komunikaty) informacji opisujących wykonywane przez skrypt działania: Removing schema binding from [dbo].[vwcustomerordersummary]... Altering [dbo].[customer]... Adding schema binding to [dbo].[vwcustomerordersummary]... The transacted portion of the database update succeeded. Update complete. (Usuwanie powiązania schematu z [dbo].[vwcustomerordersummary]... Modyfikowanie [dbo].[customer]... Dodawanie powiązania schematu do [dbo].[vwcustomerordersummary]... Objęta transakcją część operacji aktualizowania bazy danych zakończyła się powodzeniem. Aktualizacja zakończona.) Możemy teraz zamknąć wszystkie otwarte okna. Program Visual Studio wyświetli monit z pytaniem, czy ma zapisać wykonane zmiany, ale nie ma takiej potrzeby, ponieważ baza danych została właśnie zaktualizowana. Po kliknięciu bazy danych prawym przyciskiem myszy należy wybrać z menu kontekstowego polecenie Refresh (Odśwież), a następnie korzystając z eksploratora obiektów odszukać węzeł bazy danych SampleDb, aby potwierdzić, czy wprowadzone zmiany tabeli i widoku zostały faktycznie zastosowane. Przekonamy się wówczas, że kolumna CustomerRanking została usunięta z tabeli Customer, co kończy krok numer 1 na naszej liście.

64 30 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Praca z projektem typu SQL Server Database w trybie offline Projekty typu SQL Server Database Project pozwalają na programowanie bazy danych bez połączenia z jakąkolwiek instancją serwera SQL Server. Projekt typu SQL Server Database Project jest projektem zawierającym swoje własne, deklaratywne pliki z kodem źródłowym w języku T-SQL. Te pliki źródłowe wspólnie definiują strukturę całej bazy danych. Dzięki przechowywaniu definicji bazy danych w tej formie wewnątrz projektu programu Visual Studio, możliwe jest zachowywanie tej definicji w systemie kontroli kodu źródłowego zupełnie w taki sam sposób, w jaki odbywa się we wszystkich innych typach projektów programu Visual Studio. Oprogramowanie SSDT generuje model bazy danych na podstawie struktury projektu w taki sam sposób, w jaki model ten generowany jest na podstawie działającej bazy danych podczas pracy w trybie z połączeniem. Pozwala to na używanie tych samych narzędzi z pakietu SSDT niezależnie od tego, czy pracujemy w trybie offline, czy w trybie z połączeniem. Nasze pierwsze zadanie wykonaliśmy w trybie online, dysponując bezpośrednim połączeniem z działającą bazą danych. Tym razem utworzymy dla bazy danych projekt typu SQL Server Database Project, który pozwoli nam na kontynuowanie pracy w trybie offline. Wprawdzie (jak mogliśmy się przekonać) oprogramowanie SSDT pozwala na łatwe programowanie w trybie z połączeniem, ale programowanie baz danych powinno odbywać się w trybie offline przy użyciu projektów typu SQL Server Database Projects, a wykonane zmiany powinny być publikowane na działających serwerach dopiero po zakończeniu pracy nad projektem. Takie postępowanie pozwala na korzystanie z zalet systemu kontroli wersji kodu źródłowego, wersjonowania obrazów migawkowych oraz integracji z pozostałym kodem aplikacji, tworzonym w ramach systemu projektów i rozwiązań programu Visual Studio. Istnieje kilka sposobów tworzenia projektu typu SQL Server Database Project. Można zacząć od pustego projektu, zaprojektować strukturę bazy danych od podstaw i opublikować tę strukturę w nowej bazie danych na lokalnej instancji serwera SQL Server lub w chmurze opartej na oprogramowaniu SQL Azure. Możliwe jest także, tak jak to ma miejsce w opisywanym tu scenariuszu, wygenerowanie projektu typu SQL Server Database Project na podstawie bazy danych istniejącej w lokalnej instancji serwera SQL Server. Projekt taki może zostać wypełniony plikami źródłowymi, definiującymi za pomocą deklaracji w języku T-SQL pełną strukturę istniejącej bazy danych. Zadanie to można łatwo wykonać przy pomocy okna dialogowego Import Database (Importowanie bazy danych). W celu otwarcia okna dialogowego Import Database należy kliknąć prawym przyciskiem myszy bazę danych SampleDb, znajdującą się w węźle instancji SQL2012DEV, widocznym w oknie eksploratora obiektów i wybrać z menu kontekstowego polecenie Create New Project (Utwórz nowy projekt), tak jak to pokazano na rysunku 1-11.

65 Korzystanie z pakietu oprogramowania SSDT 31 RYSUNEK 1-11 Tworzenie projektu typu SQL Server Database Project na podstawie istniejącej bazy danych Połączenie ze źródłową bazą danych potwierdza, że nasz nowy projekt zostanie wygenerowany na postawie bazy danych SampleDb z serwera SQL2012DEV. Zmieńmy nazwę projektu z Database1 na SampleDb (a jeśli chcemy także jego lokalizację). Zaznaczamy pole wyboru opcji Create New Solution (Utwórz nowe rozwiązanie), a jeśli dysponujemy dostawcą systemu kontroli wersji kodu źródłowego dla programu Visual Studio, zaznaczamy także pole wyboru opcji Add To Source Control (Dodaj do kontroli kodu źródłowego), a następnie klikamy przycisk Start. Jeśli zaznaczone zostało pole wyboru opcji Add To Source Control, zostaniemy poproszeni o podanie poświadczeń tożsamości oraz wskazanie odpowiedniego serwera (szczegóły zależą od domyślnego dostawcy systemu kontroli kodu źródłowego dla programu Visual Studio). Przeanalizowanie całej bazy danych, wykrycie jej schematu i wygenerowanie deklaratywnych plików źródłowych w języku T-SQL dla nowo tworzonego projektu zajmie programowi Visual Studio kilka chwil. Po zakończeniu tego zadania program Visual Studio wyświetli okno z informacjami opisującymi wszystkie działania podjęte w celu utworzenia nowego projektu. Należy wówczas kliknąć przycisk Finish (Zamknij), aby zamknąć to okno. Nowy projekt zostanie wówczas automatycznie otwarty w oknie eksploratora rozwiązań (które domyślnie będzie zadokowane po prawej stronie). Istniejący w bazie danych schemat dbo reprezentowany jest przez folder dbo. Należy rozwinąć ten folder, a następnie rozwinąć foldery Tables (Tabele) i Views (Widoki), tak jak to zostało pokazane na rysunku 1-12.

66 32 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools RYSUNEK 1-12 Objęty kontrolą wersji projekt typu SQL Server Database Project po jego importowaniu z bazy danych Oprogramowanie SSDT skonfigurowało nasz projekt w ten sposób, ponieważ ustawienie Folder Structure (Struktura folderów) znajdujące się w oknie dialogowym Import Database (rysunek 1-11) miało wartość Schema\Object Type (Schemat\Typ obiektu). Taka wartość tego ustawienia informuje oprogramowanie SSDT, że należy utworzyć osobny folder dla każdego schematu, a następnie osobny folder dla każdego typu istniejących w tym schemacie obiektów (tabel, widoków itd.). Podczas pracy nad projektem można jednak swobodnie tworzyć dodatkowe foldery. Jeśli jednak nie stosujemy żadnej konkretnej ani indywidualnej konwencji, zaleca się zachowanie spójnej struktury projektu opartej na pokazanej tu organizacji schematu bazy danych. DODATKOWE INFORMACJE Schematy informacyjne serwera SQL Server wykazują pewne podobieństwo do przestrzeni nazw w środowisku.net. Nasza prosta baza danych zawiera tylko jedną przestrzeń nazw (dbo, co jest skrótem od słów database owner, oznaczających właściciel bazy danych ), jednak bardziej złożone bazy danych zwykle konsolidują swoje obiekty przy użyciu kilku różnych schematów. W taki sam sposób w jaki przestrzenie nazw są używane do porządkowania wielu klas w dużych aplikacjach korzystających z platformy.net, tak samo schematy ułatwiają zarządzanie wieloma obiektami zdefiniowanymi w dużych bazach danych. Podobnie jak w przypadku klas i przestrzeni nazw, dwa obiekty bazy danych mogą mieć taką samą nazwę, jeśli znajdują się w dwóch różnych schematach. Przykładowo, nazwy Sales.Person i Billing.Person odnoszą się do dwóch zupełnie różnych tabel o nazwie Person (z których jedna istnieje w schemacie Sales, a druga w schemacie Billing). Schematy serwera SQL Server pozwalają jednak na definiowanie jedynie jednego poziomu obiektów, podczas gdy przestrzenie nazw środowiska.net mogą być zagnieżdżane, tworząc wielopoziomowe i skomplikowane hierarchie klas.

67 Korzystanie z pakietu oprogramowania SSDT 33 Wykonywanie obrazu migawkowego Przed wykonaniem jakichkolwiek zmian w bazie danych znajdującej się w trybie offline należy wykonać obraz migawkowy tej bazy. Operacja ta spowoduje utworzenie pojedynczego pliku zawierającego bieżący obraz schematu bazy danych, do którego będzie można odwoływać się w przyszłości lub który będzie mógł zostać użyty do przywrócenia bazy danych do jej poprzedniego stanu. Po zakończeniu wszystkich modyfikacji bazy danych wykonamy jeszcze jeden obraz migawkowy, dzięki czemu będziemy dysponowali zapisem stanu tej bazy z dwóch momentów czasowych tuż przed oraz tuż po wykonaniu zmian. A ponieważ obrazy migawkowe zachowywane są jako część projektu, więc zostaną one także objęte ochroną systemu kontroli wersji. Należy teraz kliknąć prawym przyciskiem myszy projekt SampleDb znajdujący się w oknie eksploratora rozwiązań i wybrać z menu kontekstowego polecenie Snapshot Project (Wykonaj obraz migawkowy projektu). Po przeprowadzeniu walidacji projektu program Visual Studio utworzy nowy folder o nazwie Snapshots (Obrazy migawkowe), w którym umieści nowy plik typu.dacpac o nazwie zawierającej aktualną datę i godzinę. Zwykle obrazom migawkowym nadaje się lepsze nazwy, więc możemy zmienić nazwę pliku z tym obrazem na Version1Baseline.dacpac. Korzystanie z narzędzia Table Designer (projekt bazy danych w trybie Offline) Dysponując zapisanym bazowym obrazem migawkowym możemy przystąpić do tworzenia nowej tabeli CustomerRanking. Jak pamiętamy, ma to być nowa tabela referencyjna oparta na danych z arkusza kalkulacyjnego, pokazanego na rysunku 1-7. Korzystając z eksploratora rozwiązań klikamy prawym klawiszem myszy folder projektu o nazwie Tables (znajdujący się w folderze schematu o nazwie dbo) i wybieramy z menu kontekstowego menu podrzędne Add (Dodaj), a następnie polecenie Table (Tabelę). Nadajemy nowej tabeli nazwę CustomerRanking i klikamy przycisk Add. Spowoduje to otwarcie nowego okna projektanta tabel. Jak możemy się przekonać, okno to wygląda i działa dokładnie tak samo jak to pokazane na rysunku 1-8, z którego korzystaliśmy podczas pracy w trybie online. Dzieje się tak, ponieważ jest to dokładnie to samo narzędzie, tylko tym razem korzysta ono z modelu utworzonego na podstawie pliku projektu objętego kontrolą wersji kodu źródłowego (Customer- Ranking.sql), zamiast z modelu utworzonego na podstawie działającej bazy danych. Ponieważ w naszym projekcie nie ma żadnej podłączonej bazy danych, więc okno projektanta tabel nie zawiera przycisku Update podczas pracy w trybie offline wszelkie zmiany schematu zapisywane są w pliku projektu zawierającym skrypt przeznaczony dla danej tabeli. To z kolei powoduje aktualizację używanego modelu i podczas pracy z projektem wykonywana jest taka sama walidacja oraz wyświetlane są takie same podpowiedzi systemu IntelliSense jak podczas pracy w trybie z połączeniem. Tak więc

68 34 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools możliwe jest natychmiastowe wykrywanie niedozwolonych zmian, jeszcze przed ich wdrożeniem w rzeczywistej bazie danych. Wcześniej, podczas usuwania kolumny CustomerRanking z tabeli Customer, wspominaliśmy, że projektowanie tabeli może odbywać się przy użyciu siatki wyświetlanej w górnym panelu lub przy użyciu okna kodu w języku T-SQL, znajdującego się w dolnym panelu. Elementy definicji schematu można również przeglądać i modyfikować przy użyciu siatki Properties (Właściwości). Podczas ustalania wyglądu nowej tabeli CustomerRanking zademonstrujemy sposób korzystania ze wszystkich tych technik. Oprogramowanie SSDT najpierw utworzy nową tabelę zawierającą tylko jedną kolumnę: kolumnę klucza głównego typu int o nazwie Id. W celu zmiany nazwy tej kolumny na CustomerRankingId należy zaznaczyć nazwę kolumny (Id), wyświetlaną na siatce z górnego panelu, zastąpić ją nazwą CustomerRankingId, a następnie wcisnąć klawisz Enter. Dodajmy teraz poniżej jeszcze jedną kolumnę o nazwie RankName, ustawiając dla niej typ danych varchar(20) i czyszcząc pole wyboru opcji Allow Nulls (Zezwalaj na wartości NULL). Pakiet SSDT uaktualni wówczas kod w języku T-SQL, wyświetlany w dolnym panelu, modyfikując instrukcję CREATE TABLE w sposób odzwierciedlający zmiany wykonane w górnym panelu. Trzecią kolumnę tabeli dodamy poprzez edycję w dolnym panelu kodu w języku T-SQL. W tym celu należy dopisać przecinek w linii z definicją drugiej kolumny i dopisać po niej nową linię z tekstem [Description] VARCHAR(200) NOT NULL. Jak należało się tego spodziewać, spowoduje to uaktualnienie siatki w górnym panelu i wyświetlenie w niej nowej kolumny o nazwie Description, która właśnie została dodana do kodu źródłowego. Na koniec zmienimy jeszcze typ danych nowej kolumny przy użyciu siatki Properties. W tym celu należy kliknąć w górnym panelu kolumnę Description, a następnie przewinąć zawartość siatki Properties, odszukując w niej właściwość Length (Długość) (jeśli siatka Properties nie jest aktualnie wyświetlana, należy kliknąć menu View [Widok] i wybrać z niego polecenie Properties Window [Okno właściwości]). Kliknięcie strzałki skierowanej w dół i wybranie z rozwijanej listy wartości MAX spowoduje zmianę typu kolumny z varchar(200) na varchar(max). Po wykonaniu wszystkich tych czynności okno projektanta tabel powinno wyglądać podobnie jak na rysunku Zapiszemy teraz plik CustomerRanking.sql i zamkniemy okno projektanta tabel, kończąc tym samym krok numer 2. Jesteśmy teraz gotowi do dodania do tabeli Customer kolumny klucza obcego (krok 3), która będzie łączyć tę tabelę z nową tabelą CustomerRanking. W tym celu należy dwukrotnie kliknąć w oknie eksploratora rozwiązań plik Customer.sql, aby otworzyć narzędzie projektanta tabel dla tabeli Customer. Stosując dowolną z opisanych technik należy dodać do tej tabeli nową kolumnę typu int o nazwie CustomerRankingId, dopuszczającą używanie wartości NULL (na tym etapie kolumna ta musi dopuszczać wartości NULL, ponieważ nie zawiera ona jeszcze żadnych danych).

69 Korzystanie z pakietu oprogramowania SSDT 35 RYSUNEK 1-13 Okno projektanta tabel na nowej tabeli CustomerRanking w projekcie offline typu SQL Server Database Project Możemy teraz przystąpić do utworzenia relacji klucza obcego z tabelą CustomerRanking (krok 4). W górnym prawym rogu okna Table Designer (Projektant tabel) znajduje się obszar o nazwie Context View (Widok kontekstu), zawierający podsumowanie innych obiektów mających istotny związek z edytowaną tabelą. W obszarze tym należy kliknąć prawym klawiszem myszy element Foreign Keys (Klucze zewnętrzne) i wybrać z menu kontekstowego polecenie Add New Foreign Key (Dodaj nowy klucz obcy). Nazwijmy ten nowy klucz FK_Customer_CustomerRanking (zaleca się, by nazwy kluczy zewnętrznych zawierały nazwy tabel uczestniczących w relacji ustanawianej za pomocą tego klucza). Następnie należy przeprowadzić edycję szablonowego kodu FOREIGN KEY, dodanego do dolnego panelu z kodem w języku T-SQL, zmieniając tę klauzulę do postaci FOREIGN KEY (CustomerRankingID) REFERENCES Custo merranking(customerrankingid). Okno projektanta tabel powinno wówczas wyglądać podobnie jak na rysunku Po przejrzeniu i sprawdzeniu schematu tabeli należy zapisać plik Customer.sql i zamknąć okno projektanta.

70 36 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools RYSUNEK 1-14 Okno projektanta tabel dla tabeli Customer po utworzeniu klucza obcego na kolumnie CustomerRankingId Omówienie instancji LocalDB Naszym następnym zadaniem będzie zmodyfikowanie widoku (krok 5) i utworzenie procedury składowanej (krok 6). Podczas implementowania tych kroków bardzo pomocne byłoby posiadanie testowego środowiska serwera SQL Server. Nie chcemy w tym charakterze używać serwera SQL2012DEV, ponieważ jest to nasz działający serwer produkcyjny. Potrzebujemy zatem innego serwera SQL Server, którego moglibyśmy używać do przeprowadzania testów w trybie offline. Takim środowiskiem testowym jest instancja LocalDB. Jest to nowa, lekka, jednoużytkownikowa instancja serwera SQL Server, która jest uruchamiana w razie potrzeby podczas budowania projektu. Jest to wyjątkowo przydatne podczas pracy w trybie offline, gdy nie dysponujemy żadnym innym serwerem, który mógłby zostać użyty do celów tworzenia oprogramowania. Oficjalna nazwa tego nowego wariantu serwera SQL Server brzmi SQL Express LocalDB, co może być mylące, ponieważ jest to inny produkt niż edycja Express serwera SQL Server. Aby więc uniknąć nieporozumień, będziemy nazywać tę instancję po prostu LocalDB. UWAGA Nowa instancja serwera LocalDB nie obsługuje wszystkich funkcji serwera SQL Server feature (nie może ona np. być używana ze strumieniami plikowymi typu FILE- STREAM). Instancja ta obsługuje jednak większość funkcji niezbędnych w typowym procesie programowania baz danych. Należy teraz wcisnąć klawisz F5, aby rozpocząć proces budowy projektu. Najpierw przeprowadzona zostanie walidacja całej, zdefiniowanej w projekcie struktury bazy danych, a następnie struktura ta zostanie wdrożona w instancji LocalDB. Należy

71 Korzystanie z pakietu oprogramowania SSDT 37 jednak pamiętać, że jest to działanie domyślnie i jeśli instancja LocalDB nie obsługuje potrzebnej nam funkcji (np. omawianej w rozdziale 8 funkcjonalności strumieni plikowych typu FILESTREAM), to możliwe jest zmodyfikowanie właściwości projektu i wskazanie innego serwera docelowego. Proces wdrożenia polega na przeprowadzeniu operacji porównywania schematów pomiędzy projektem a instancją LocalDB na serwerze docelowym. Mówiąc dokładniej, zgodnie z wcześniejszymi wyjaśnieniami, wygenerowany zostaje model oparty na projekcie źródłowym oraz model oparty na docelowej bazie danych i operacja porównywania schematów zostanie faktycznie przeprowadzona dla tych dwóch modeli. Ponieważ jest to nasza pierwsza operacja budowy projektu, więc baza danych nie istnieje jeszcze na serwerze docelowym i operacja porównywania schematów wygeneruje skrypt, który utworzy całą bazę danych od zera. W trakcie modyfikowania istniejącego projektu kolejne kompilacje będą generować skrypty zmian, określające jedynie działania konieczne do przywrócenia docelowej bazy danych do stanu zsynchronizowanego z projektem. Jeśli przyjrzymy się teraz zawartości okna eksploratora obiektów, to zauważymy, że oprogramowanie SSDT uruchomiło nową instancję bazy danych LocalDB. Instancja ta używa nazwy hosta (localdb)\sampledb i jest to całkowicie odrębna instancja od instancji znajdującej się na serwerze SQL2012DEV (w której nie została jeszcze utworzona nowa tabela CustomerRanking ani klucz obcy CustomerRankingId w tabeli Customer). Rysunek 1-15 przedstawia rozwinięty węzeł bazy danych SampleDb ukazujący tabele tej bazy po jej wdrożeniu w instancji LocalDB. Należy zwrócić uwagę na fakt, że baza ta zawiera nową tabelę CustomerRanking. Dysponujemy teraz testową bazą danych, z której możemy korzystać, ale oczywiście baza ta nie zawiera żadnych danych. Dodamy więc do niej niewielką ilość danych tak, by możliwe było przetestowanie zmodyfikowanego widoku oraz utworzonej procedury składowanej. Posługując się prostą techniką typu kopiuj/wklej, pakiet SSDT pozwala na importowanie niewielkich zbiorów wierszy z dowolnej tabeli źródłowej (w tym także z plików programu Word i Excel) do tabeli bazy danych mającej kompatybilne kolumny. Najpierw wprowadzimy do bazy dane referencyjne definiujące ranking klientów. Dane te znajdują się w arkuszu kalkulacyjnym pokazanym na rysunku 1-7. Możliwe jest łatwe pobranie tych danych wprost z arkusza kalkulacyjnego i prowadzenie ich do nowej tabeli CustomerRanking. W tym celu należy otworzyć arkusz kalkulacyjny w programie Excel, zaznaczyć w nim pięć wierszy z danymi (należy zaznaczyć pełne wiersze, a nie tylko poszczególne komórki lub kolumny), kliknąć zaznaczony obszar prawym przyciskiem myszy i wybrać z menu kontekstowego polecenie Kopiuj. Następnie należy powrócić do okna eksploratora obiektów, kliknąć prawym klawiszem myszy tabelę CustomerRanking i wybrać z menu kontekstowego polecenie View Data (Pokaż dane). Spowoduje to otwarcie przez pakiet SSDT siatki umożliwiającej edytowanie danych tabeli (Editable Data Grid) z szablonem służącym do wstawiania nowych wierszy. Należy kliknąć prawym klawiszem myszy selektor wiersza

72 38 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools z szablonem nowego wiersza i wybrać z menu kontekstowego polecenie Paste (Wklej) (kliknięcie prawym klawiszem myszy musi koniecznie zostać wykonane w szarym obszarze marginesu znajdującego się z lewej strony selektora wiersza, a nie w obszarze którejkolwiek komórki). Jak pokazano na rysunku 1-16, oprogramowanie SSDT wiernie skopiuje do tabeli CustomerRanking dane pobrane z programu Excel. RYSUNEK 1-15 Lokalne środowisko uruchomieniowe bazy danych (LocalDB) po zbudowaniu i wdrożeniu projektu typu SQL Server Database Project RYSUNEK 1-16 Dane referencyjne importowane do tabeli bazy danych z programu Excel za pośrednictwem schowka

73 Korzystanie z pakietu oprogramowania SSDT 39 Do pracy z testową bazą danych potrzebować będziemy także dane kilku klientów. Posługując się taką samą techniką typu kopiuj/wklej przeniesiemy wiersze z tabeli Customer, istniejącej w produkcyjnej bazie danych, do naszej testowej bazy danych w instancji LocalDB (na potrzeby tego ćwiczenia nie będziemy jednak przenosić danych dotyczących zamówień klientów, zapisanych w tabeli OrderHeader). Ponieważ w bazie źródłowej istnieje zaledwie kilku klientów, więc skopiujemy ich wszystkich. Zwykle jednak wskazane jest wyodrębnienie jedynie pewnego podzbioru danych, będącego reprezentatywną próbką wystarczającą do celów testowych. W tym celu rozwijamy w oknie eksploratora obiektów węzeł serwera produkcyjnego (SQL2012DEV), odszukujemy w nim tabelę Customer i po kliknięciu tej tabeli prawym przyciskiem myszy wybieramy z menu kontekstowego polecenie View Data (Pokaż dane). Zaznaczamy wszystkie wiersze z danymi klientów, klikamy zaznaczony obszar prawym klawiszem myszy i wybieramy z menu kontekstowego polecenie Copy. Następnie klikamy prawym klawiszem myszy tabelę Customer z testowej bazy danych (localdb)\sampledband i wybieramy z menu kontekstowego polecenie View Data. Klikamy prawym klawiszem myszy selektor nowego wiersza i wybieramy z menu kontekstowego polecenie Paste, aby skopiować do tej tabeli sześć wierszy z danymi klientów. Doszliśmy już do kroku numer 5, który ma polegać na uaktualnieniu widoku vwcustomerordersummary. Jak pamiętamy, jest to ten sam widok, który edytowaliśmy podczas realizacji kroku numer 1 (pracując wówczas w trybie z połączeniem), usuwając powiązane ze schematem odwołania do nieistniejącej już kolumny CustomerRanking z tabeli Customer. Teraz, gdy dysponujemy już nową tabelą referencyjną oraz relacją opartą na kluczu obcym, dokonamy ponownej edycji tego widoku (tym razem w trybie offline), wprowadzając połączenie z tabelą CustomerRanking w oparciu o kolumnę CustomerRankingId, aby uzyskać w ten sposób nazwę rankingu przechowywaną w tabeli referencyjnej w kolumnie RankNamecolumn. Przechodzimy do okna eksploratora rozwiązań i klikamy dwukrotnie plik vwcustomerordersummary.sql, znajdujący się w folderze projektu o nazwie Views (folder ten jest folderem podrzędnym folderu schematu o nazwie dbo). Spowoduje to otwarcie widoku w nowym oknie kodu, w którym naszą uwagę może przyciągnąć kilka falistych linii, którymi program Visual Studio podkreślił niektóre partie kodu. Linie te nie są w kolorze czerwonym, ponieważ definicja widoku nie zawiera żadnych poważnych błędów są to jedynie ostrzeżenia. Zatrzymanie wskaźnika myszy nad jednym z podkreślonych słów powala zapoznać się z tekstem ostrzeżenia, wyświetlanym w formie wyskakującej podpowiedzi (wszystkie te ostrzeżenia są również wyświetlane w panelu Error List). Ostrzeżenia te wskazują na fakt, że odwołując się do kolumny o nazwie CustomerId (z małą literą d na końcu) widok używa nazwy CustomerID (z dużą literą D na końcu). Są to te same ostrzeżenia dotyczące wielkości liter, które widzieliśmy już wcześniej podczas próby aktualizacji bazy danych, zakończonej niepowodzeniem z powodu istniejących zależności pomiędzy obiektami. Normalnie w nazwach obiektów serwera SQL Server nie są rozróżniane małe i duże

74 40 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools litery (podobnie jak w języku VB.NET), ale stosowanie innych niż domyślne ustawień porządku sortowania może to zmienić powodując, że w nazwach obiektów będą rozróżniane małe i duże litery (podobnie jak w języku C#). Wdrożenie takiego projektu na instancji serwera SQL Sever używającej dla nazw obiektów ustawień sortowania rozróżniających małe i duże litery mogłoby więc powodować problemy. Dodamy teraz do widoku jeszcze jedną klauzulę LEFT OUTER JOIN, wprowadzającą połączenie tabeli CustomerRanking z tabelą Customer na podstawie kolumny Customer- RankingId i dodamy kolumnę RankName do listy kolumn występujących w klauzulach SELECT oraz GROUP BY. Ponieważ nie chcemy, by nasz kod generował niepotrzebne ostrzeżenia, więc jest to odpowiednia okazja do tego, by poprawić również sygnalizowane problemy związane z wielkością liter. Występującą czterokrotnie w definicji widoku nazwę kolumny CustomerID (jeden raz na liście kolumn klauzuli SELECT, dwa razy w pierwszej klauzuli JOIN i jeden raz na liście kolumn klauzuli GROUP BY) należy zmienić na CustomerId. Listing 1-2 pokazuje, jak powinna wyglądać definicja widoku po wykonaniu tych zmian. LISTING 1-3 Uaktualniona definicja widoku vwcustomerordersummary, używająca złączenia z tabelą CustomerRanking -- Tworzenie podręcznego widoku podsumowującego zamówienia klienta CREATE VIEW vwcustomerordersummary WITH SCHEMABINDING AS SELECT c.customerid, c.firstname, c.lastname, r.rankname, ISNULL(SUM(oh.OrderTotal), 0) AS OrderTotal FROM dbo.customer AS c LEFT OUTER JOIN dbo.orderheader AS oh ON c.customerid = oh.customerid LEFT OUTER JOIN dbo.customerranking AS r ON c.customerrankingid = r.customerrankingid GROUP BY c.customerid, c.firstname, c.lastname, r.rankname Po wykonaniu tych zmian należy zapisać plik vwcustomerordersummary.sql, aby uaktualnić nasz projekt typu offline. Jak wiemy, wciśnięcie na tym etapie klawisza F5 spowodowałoby wdrożenie zmienionego widoku w testowej bazie danych na instancji LocalDB. Co jednak się stanie, jeśli spróbujemy wykonać ten skrypt bezpośrednio z okna kodu, poprzez wciśnięcie kombinacji klawiszy Ctrl+Shift+E? Śmiało, proszę spróbować! Otrzymamy wówczas w odpowiedzi następujący komunikat błędu: Msg 2714, Level 16, State 3, Procedure vwcustomerordersummary, Line 2 There is already an object named 'vwcustomerordersummary' in the database. (W bazie danych istnieje już obiekt o nazwie 'vwcustomerordersummary'.) A oto wyjaśnienie co się stało. Najpierw oprogramowanie SSDT połączyło okno zapytań z instancją (localdb)\sampledb, a następnie podjęło próbę wykonania skryptu na podłączonej bazie danych w sposób imperatywny, dokładnie tak samo jak poprzednio,

75 Korzystanie z pakietu oprogramowania SSDT 41 gdy wcisnęliśmy kombinację klawiszy Ctrl+Shift+E. Ponieważ jednak skrypt ten jest częścią projektu typu offline, ma on charakter deklaratywny, co przejawia się użyciem instrukcji CREATE VIEW. Ponieważ widok istnieje już w bazie danych, więc komunikat o błędzie jest całkowicie uzasadniony. Powtórzmy zatem raz jeszcze, że prawidłowym sposobem uaktualnienia bazy danych jest wdrożenie zmian za pomocą przyrostowego skryptu, generowanego w trybie debugowania po wciśnięciu klawisza F5. Jednakże pomimo faktu, że korzystamy z okna zapytań w projekcie typu offline, który nie został jeszcze wdrożony w instancji LocalDB, to faktycznie dysponujemy połączeniem z testową bazą danych z instancji LocalDB. Oznacza to, że mamy możliwość przetestowania naszego widoku przed jego wdrożeniem. W tym celu należy zaznaczyć cały tekst od słowa SELECT aż do końca skryptu (tzn. pozostawić niezaznaczoną tylko tę część okna, która zawiera instrukcję CREATE VIEW) i ponownie wcisnąć kombinację klawiszy Ctrl+Shift+E. Tym razem otrzymamy znacznie lepszy rezultat. Wykonana zostanie tylko zaznaczona instrukcja SELECT, która dla podłączonej bazy danych jest całkowicie poprawną instrukcją w języku T-SQL. Okno wyników zapytania pokaże nam, jak będą wyglądać dane zwracane przez zmodyfikowany widok, pozwalając nam na sprawdzenie poprawności utworzonego widoku bez konieczności jego uprzedniego wdrażania. Pracując w tym trybie faktycznie korzystamy jednocześnie z trybu z połączeniem oraz z trybu offline! Możemy zaznaczać dowolne instrukcje w języku T-SQL w celu ich natychmiastowego wykonania, testować i debugować procedury składowane, a nawet sprawdzać plany wykonywania, pozostając przy tym przez cały czas w trybie offline. Refaktoryzacja bazy danych Nasz widok jest już gotowy do wdrożenia, zanim to jednak nastąpi, zdecydowaliśmy się na zmianę kilku nazw. Ponieważ klienci są jedynymi obiektami podlegającymi szeregowaniu, więc skrócenie nazwy tabeli CustomerRanking do samego Ranking oraz nazw kolumn CustomerRankingId do RankingId, uczyni nasz kod w języku T-SQL bardziej przejrzystym (a to ważne!). Bez odpowiednich narzędzi zmienianie nazw obiektów istniejących w bazie danych może być zajęciem bardzo nużącym. Jednak oferowana przez oprogramowanie SSDT funkcjonalność refaktoryzacji sprawia, że jest to zadanie wyjątkowo łatwe. W dodanej przed chwilą nowej klauzuli LEFT OUTER JOIN należy kliknąć prawym przyciskiem myszy odwołanie do tabeli CustomerRanking, a następnie wybrać z menu kontekstowego menu podrzędne Refactor (Refaktoryzuj), z niego polecenie Rename (Zmień nazwę). Wpisujemy nazwę Ranking jako nową nazwę tabeli i klikamy przycisk OK. Zostanie wówczas wyświetlone okno podglądu (pokazane na rysunku 1-17), które powinno wyglądać znajomo dla wszystkich osób, które kiedykolwiek korzystały z funkcji refaktoryzacji w programie Visual Studio podczas pracy ze zwykłymi projektami typu.net.

76 42 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools RYSUNEK 1-17 Okno pozwalające na zapoznanie się ze zmianami przed zastosowaniem refaktoryzacji w bazie danych To okno dialogowe pokazuje wszystkie odwołania do tabeli CustomerRanking, które po kliknięciu przycisku Apply (Zastosuj) zostaną zamienione na Ranking (należy zwrócić uwagę na pola wyboru, które pozwalają na dokonanie wyboru, które z odwołań powinny zostać zmienione, a które nie). Należy przewinąć zawartość tego okna przeglądając po kolei wszystkie odwołania, a następnie kliknąć przycisk Apply, co spowoduje natychmiastowe rozpoczęcie operacji zmieniania nazw. Wszystkie pliki projektu zawierające zmienianą nazwę zostaną odpowiednio uaktualnione, jednak nazwy samych plików nie zostaną zmienione przez program Visual Studio. Skrypt projektu definiujący przemianowaną przed chwilą tabelę Ranking nadal nosi nazwę CustomerRanking.sql. Aby zmienić nazwę tego pliku, należy kliknąć go prawym klawiszem myszy w oknie eksploratora rozwiązań, wybrać z menu kontekstowego polecenie Rename, a następnie wpisać nową nazwę Ranking.sql. Kolejna operacja polegać będzie na zmianie nazwy kolumny klucza głównego z tabeli Ranking, a także odpowiadającej jej kolumny klucza obcego z tabeli Customer. Aktualnie obie te kolumny noszą nazwę CustomerRankingId. Ponieważ obie te kolumny klucza występują w tej samej linii z klauzulą LEFT OUTER JOIN, więc operacja zmiany ich nazwy będzie łatwa. Klikamy prawym klawiszem myszy występującą w złączeniu kolumnę klucza r.customerrankingid, a następnie wybieramy z menu kontekstowego pozycje Refactor i Rename. Wpisujemy nową nazwę RankingId, klikamy przycisk OK, przeglądamy proponowane zmiany i klikamy przycisk Apply, aby zmienić nazwę kolumny klucza w tabeli Ranking. Następnie powtarzamy tę operację dla kolumny klucza c.customerrankingid, aby zmienić nazwę kolumny klucza obcego w tabeli Customer (faktyczna kolejność, w jakiej wykonane zostaną operacje zmiany nazw kolumn w tych tabelach, jest bez znaczenia).

77 Korzystanie z pakietu oprogramowania SSDT 43 Pozostał jeszcze jeden element wymagający zmiany nazwy, a jest nim definicja klucza obcego w tabeli Customer. Oczywiście nie jest to operacja absolutnie niezbędna, ale zgodnie z przyjętą konwencją (którą sami sobie narzuciliśmy), jeśli definicja klucza obcego ma odzwierciedlać nazwy tabel łączonych przy pomocy tego klucza, to powinniśmy zmienić nazwę FK_Customer_CustomerRanking na FK_Customer_Ranking. Nazwa tabeli Customer występuje po raz pierwszy w klauzuli widoku FROM, a więc należy kliknąć tę nazwę prawym klawiszem myszy i wybrać z menu kontekstowego polecenie Goto Definition (Idź do definicji). Spowoduje to przejście bezpośrednio do definicji tabeli Customer, która zostanie otwarta w nowym oknie zapytań. Klikamy prawym przyciskiem myszy nazwę FK_Customer_CustomerRanking występującą w klauzuli CONSTRAINT i wybieramy z menu kontekstowego pozycje Refactor i Rename. Wpisujemy nową nazwę FK_Customer_Ranking, klikamy przycisk OK, przeglądamy proponowane zmiany (w tym przypadku tylko jedną) i klikamy przycisk Apply. Jesteśmy teraz gotowi do wdrożenia wykonanych zmian w kolejnej operacji budowania projektu, a więc należy raz jeszcze wcisnąć klawisz F5. Po zakończeniu operacji budowania projektu klikamy przycisk Refresh (Odśwież) znajdujący się na pasku narzędziowym eksploratora obiektów i przeglądamy testową bazę danych uruchomioną w instancji (localdb)\sampledb, aby potwierdzić, czy faktycznie nazwa tabeli CustomerRanking została zmieniona na Ranking. Następnie klikamy prawym klawiszem myszy tabelę Ranking i wybieramy z menu kontekstowego polecenie View Data, aby przekonać się, czy wszystkie dane tabeli pozostały niezmienione. Dokonując zmiany nazw obiektów w projekcie typu SQL Server Database Project pakiet SSDT generuje skrypt zmian, który zamiast usuwania tych obiektów i ich ponownego tworzenia (co w przypadku tabeli prowadziłoby do nieodwracalnej utraty danych) używać będzie odpowiednich instrukcji EXECUTE sp_rename. Tak więc używane przez nas narzędzie wykonuje prawidłową operację, wykorzystując ostatecznie do zmiany nazw obiektów istniejących w bazie danych procedurę składowaną serwera SQL Server o nazwie sp_rename. Nadszedł czas na utworzenie procedury składowanej, która będzie określać pozycję klientów w rankingu. Najpierw korzystając z eksploratora rozwiązań należy utworzyć nowy folder Stored Procedures (Procedury składowane) jako folder podrzędny folderu dbo (w tym celu należy kliknąć prawym klawiszem myszy folder dbo i wybrać z menu kontekstowego pozycje Add i New Folder). Folder ten zostałby utworzony automatycznie, gdyby podczas importowania bazy danych do projektu istniała w niej jakakolwiek procedura składowana. Następnie klikamy folder Stored Procedures prawym klawiszem myszy i wybieramy z menu kontekstowego pozycje Add i Stored Procedure. Podajemy nazwę procedury składowanej usprankcustomers i klikamy przycisk Add. Oprogramowanie SSDT utworzy wówczas nowy plik o nazwie usprankcustomers. sql i otworzy go w nowym oknie edytora kodu w języku T-SQL. Należy zastąpić szablonowy kod tej procedury kodem pokazanym w listingu 1-3 i zapisać zmieniony plik, pozostawiając jednak okno otwarte. Wciskamy teraz klawisz F5, aby wykonać kolejną

78 44 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools operację budowania projektu i umieścić nową procedurę składowaną w testowej bazie danych na instancji LocalDB. LISTING 1-4 Procedura składowana służąca do szeregowania klientów na podstawie całkowitej wartości ich zamówień CREATE PROCEDURE usprankcustomers AS int money int DECLARE curcustomer CURSOR FOR SELECT CustomerId, OrderTotal FROM vwcustomerordersummary OPEN curcustomer FETCH NEXT FROM = 0 BEGIN = 0 = 1 ELSE < 100 = 2 ELSE < 1000 = 3 ELSE < = 4 ELSE = 5 UPDATE Customer SET RankingId WHERE CustomerId END FETCH NEXT FROM CLOSE curcustomer DEALLOCATE curcustomer Powyższa procedura składowana ustala pozycję klientów w rankingu, badając każdego klienta z osobna i przypisując mu odpowiednią wartość w zależności od całkowitej wartości jego zamówień. Procedura robi to otwierając kursor na widoku z podsumowaniem zamówień, który zwraca dla każdego klienta jeden wiersz zawierający zagregowaną wartość wszystkich zamówień danego klienta. W zależności od kwotowej wartości wszystkich zamówień, procedura aktualizuje pozycję klienta w rankingu, przypisując mu odpowiednią wartość z przedziału od 1 do 5. Następnie procedura przechodzi do następnego klienta, aż do napotkania końca kursora. Jak już wspomnieliśmy wcześniej, rozwiązanie to jest może nieco nienaturalne (Czytelnicy z pewnością mogliby zaproponować lepsze rozwiązanie), ale służy ono wyłącznie do celów demonstracyjnych.

79 Korzystanie z pakietu oprogramowania SSDT 45 Testowanie i debugowanie Czy należysz Czytelniku do tych osób, które mają zwyczaj uruchamiania nowego i nieprzetestowanego kodu w działających, produkcyjnych bazach danych? Mamy nadzieję, że nie. Choć moglibyśmy po prostu przenieść wszystkie zmiany wykonane w naszym projekcie (kroki od 2 do 6) do działającej bazy danych na serwerze SQL2012DEV, a następnie po raz pierwszy uruchomić w tej bazie naszą nową procedurę składowaną, ale z pewnością nie powinniśmy tego robić. Znacznie bezpieczniej będzie przetestować najpierw działanie tej procedury w trybie offline przy użyciu instancji LocalDB. Pokażemy teraz, jak można to zrobić przy użyciu zintegrowanego ze środowiskiem Visual Studio debugera z pakietu SSDT. Po takim teście będziemy mogli śmiało wdrożyć wszystko na serwerze SQL2012DEV, a na końcu (krok 7) także w chmurze! Procedura składowana usprankcustomers nadal jest otwarta w oknie edytora kodu. Klikamy więc lewy margines na wysokości linii z instrukcją OPEN curcustomer, aby ustanowić punkt przerwania (ang. breakpoint) tuż przed otwarciem kursora. Punkty przerwania są oznaczane dużą czerwoną kropką, wstawianą na marginesie w miejscu jego kliknięcia. Sposób ustalania punktów przerwania jest więc dokładnie taki sam jak w przypadku kodu w językach C# lub VB.NET i pakiet oprogramowania SSDT oferuje także podobne możliwości debugowania kodu napisanego w języku T-SQL. Korzystając z okna eksploratora obiektów należy teraz rozwinąć węzeł Stored Procedures (będący węzłem podrzędnym węzła Programmability, tak samo jak w programie SSMS) dla bazy danych SampleDb z instancji LocalDB, kliknąć ten węzeł prawym klawiszem myszy, wybrać z menu podrzędnego polecenie Refresh, aby przekonać się, że procedura składowana usprankcustomers została właśnie wdrożona w tej bazie danych. Klikamy więc prawym klawiszem myszy tę procedurę składowaną i wybieramy z menu kontekstowego polecenie Debug Procedure. Oprogramowanie SSDT wygeneruje wówczas instrukcję EXEC wywołującą procedurę usprankcustomers i otworzy ją w nowym oknie zapytań. Debuger będzie już uruchomiony i wstrzymany na instrukcji USE [SampleDb], poprzedzającej instrukcję EXEC. DODATKOWE INFORMACJE W tym przypadku uruchomienie sesji debugowania jest natychmiastowe, ponieważ debugowana procedura składowana usprankcustomers, nie ma żadnych parametrów. Jeśli procedura składowana oczekiwałaby jakichś parametrów, to oprogramowanie SSDT wyświetliłoby najpierw okno dialogowe pozwalające na podanie wartości tych parametrów, które następnie zostałyby wstawione do instrukcji EXEC, jeszcze przed uruchomieniem debugera. Aby kontynuować wykonywanie kodu, należy wcisnąć klawisz F5. Debuger po osiągnięciu instrukcji EXEC wejdzie do procedury składowanej, a następnie zatrzyma się na instrukcji OPEN curcustomer, na której poprzednio ustawiliśmy punkt przerwania. Od tego miejsca możemy krokowo kontynuować wykonywanie procedury

80 46 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools składowanej, wciskając klawisz F10. Wciskamy zatem trzykrotnie klawisz F10, aby wykonać trzy kolejne instrukcje. Instrukcje te otwierają kursor, pobierają z niego dane pierwszego klienta. Debuger jest teraz zatrzymany na pierwszej instrukcji IF, która sprawdza, czy całkowita wartość wszystkich zamówień klienta jest równa zeru. Wcześniej skopiowaliśmy sześć wierszy z danymi klientów z bazy danych SQL- 2012DEV do LocalDB, ale wyraźnie zastrzegliśmy, aby nie kopiować żadnych danych zamówień. Tak więc pętla procedury składowanej dokona iteracji poprzez wszystkich klientów i (na podstawie całkowitej wartości ich zamówień, która będzie równa zeru) przypisze wszystkim klientom wartość pozycji w rankingu równą 1. Zamiast przerywać w tym miejscu sesję debugowania w celu importowania przykładowych danych z zamówieniami klientów, skorzystamy z okna debugera o nazwie Locals (Zmienne lokalne) i przy jego pomocy zasymulujemy niezerową wartość wszystkich zamówień dla pierwszych dwóch klientów. W tym celu należy wybrać z menu Debug menu podrzędne Windows, a następnie wybrać z tego menu polecenie Locals. Korzystając z okna Locals możemy odczytać, że ma wartość 1 (to jest pierwszy klient), a ma wartość 0 (tj. zgodną z naszymi oczekiwaniami, ponieważ w bazie danych nie ma żadnych przykładowych danych z zamówieniami). Wartość nie została jeszcze ustawiona, ale gdybyśmy pozwolili na dalsze wykonywanie kodu bez żadnych ingerencji z naszej strony, klient otrzymałby wartość pozycji w rankingu równą 1. Klikamy dwukrotnie wartość wyświetlaną w oknie Locals dla wpisujemy wartość 5000 i wciskamy klawisz Enter. Po takim zabiegu procedura składowana będzie sądzić, że całkowita wartość wszystkich zamówień tego klienta wynosi 5000 $. Wciskamy klawisz F10, aby wykonać pojedynczy krok procedury. Ponieważ wartość nie jest już równa zeru, wykonywanie przejdzie do następnego warunku IF sprawdzającego, czy wartość zamówień jest mniejsza od 100 $. Wciskamy raz jeszcze klawisz F10 i wykonywanie przechodzi do warunku IF sprawdzającego, czy wartość zamówień jest mniejsza od 1000 $. Kolejne wciśnięcie klawisza F10 spowoduje przejście do warunku IF sprawdzającego, czy wartość zamówień jest mniejsza od $. Ten warunek zwróci wartość true (całkowita wartość zamówień jest przecież równa 5000 $), a więc kolejne wciśnięcie klawisza F10 spowoduje przejście do instrukcji SET, przypisującej klientowi wartość rankingu równą 4. Jest to prawidłowa wartość dla zamówień z przedziału od 1000 $ do $. Wygląd wstrzymanej w tym miejscu sesji debugowania został przedstawiony na rysunku Kontynuując wciskanie klawisza F10 wykonujemy krokowo pozostałe instrukcje SET, UPDATE oraz FETCH NEXT, aż do ponownego osiągnięcia pierwszej instrukcji IF sprawdzającej, czy całkowita wartość zamówień drugiego klienta jest równa zeru. Korzystając z okna Local ponownie wprowadzimy nieprawdziwą wartość zamówień, tym razem zmieniając wartość na 150. Wykonujemy jeszcze kilka kroków, aby upewnić się, że tym razem procedura składowana przypisze klientowi wartość rankingu równą 3, co również jest prawidłową wartością dla zamówień

81 Korzystanie z pakietu oprogramowania SSDT 47 o wartości z przedziału od 100 $ do 1000 $. Następnie wciskamy klawisz F5, pozwalając na dokończenie wykonywania procedury składowanej bez żadnych dalszych interwencji z naszej strony. Po zakończeniu wykonywania procedury składowanej klikamy prawym klawiszem myszy tabelę Customer w oknie eksploratora obiektów (należy pamiętać, aby wybrać instancję LocalDB, a nie SQL2012DEV) i wybieramy z menu kontekstowego polecenie View Data. Wyświetlone dane tabeli potwierdzają, że pierwszy klient otrzymał wartość rankingu równą 4, drugi wartość równą 3, a wszyscy pozostali mają wartość równą 1 (jeśli używane poprzednio okno z danymi tabeli Customer nie zostało zamknięte i nadal jest otwarte, to w oknie tym nadal wyświetlane będą poprzednie wartości; aby zaktualizować wyświetlane dane, należy kliknąć znajdujący się na pasku narzędziowym przycisk Refresh). RYSUNEK 1-18 Sesja debugowania w programie Visual Studio procedury składowanej, napisanej w języku T-SQL Przeprowadzonych przez nas testów w żadnym razie nie można uznać za wyczerpujące, jednak były one wystarczające do celów demonstracyjnych. Kluczową sprawą, na którą chcieliśmy zwrócić uwagę, jest fakt, że oprogramowanie SSDT dostarcza środowisko, które może być używane do debugowania i testowania tworzonych rozwiązań bazodanowych w trybie offline, zanim rozwiązania te będą gotowe do wdrożenia w środowisku produkcyjnym (tak jak nasze rozwiązanie, które teraz jest już gotowe do wdrożenia).

82 48 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Porównywanie schematów Jesteśmy teraz gotowi do wdrożenia naszego projektu w produkcyjnej bazie danych działającej na serwerze SQL2012DEV. Jak można się domyślać na podstawie dotychczas wykonywanych czynności, proces ten zasadniczo nie różni się od tego co następuje po wciśnięciu klawisza F5 podczas pracy w trybie offline z instancją LocalDB: oprogramowanie SSDT wykona operację porównywania schematów i wygeneruje skrypt zmian. Właściwości projektu zawierają ciąg połączenia, który (domyślnie) wskazuje na instancję LocalDB. Tak więc podczas budowania projektu po wciśnięciu klawisza F5 nastąpi porównywanie schematu projektu jako źródła i schematu bazy testowej jako schematu docelowego, a następnie wygenerowany skrypt zmian zostanie wykonany na testowej bazie danych z instancji LocalDB. Wszystkie te operacje będą wykonywane całkowicie bez żadnego udziału ze strony użytkownika, po każdym wciśnięciu klawisza F5. Wykonamy teraz dokładnie te same kroki, tyle że tym razem będziemy mieć większy wpływ na cały proces. W szczególności jako obiekt docelowy dla operacji porównywania schematów wskażemy instancję SQL2012DEV, zamiast instancji LocalDB. Ponadto przed zastosowaniem rezultatów operacji porównywania schematów przejrzymy te rezultaty, co da nam możliwość selektywnego wdrażania poszczególnych wykrytych zmian. Na koniec, zamiast automatycznego wykonania wygenerowanego skryptu zmian, będziemy mieli możliwość jego przejrzenia, edytowania, zapisania i ewentualnego wykonania. Jak zatem widać, tym razem cały proces wymagać będzie znacznie większej interwencji z naszej strony, ale tego właśnie chcemy. Sam proces porównywania schematów będzie przebiegać tak samo jak podczas budowania projektu po wciśnięciu klawisza F5 chodzi jedynie o przećwiczenie sposobu przeprowadzania tej operacji w sposób dający większą kontrolę i pozwalający na obsługę różnych scenariuszy wdrożenia. Klikamy teraz prawym klawiszem myszy projekt SampleDb wyświetlany w oknie eksploratora rozwiązań i wybieramy z menu kontekstowego polecenie Schema Compare (Porównywanie schematów), aby otworzyć okno porównywania schematów. Naturalnie w oknie tym należy wskazać schemat źródłowy i docelowy dla operacji porównywania. Ponieważ okno to zostało otwarte przy użyciu menu kontekstowego, wyświetlonego przez eksploratora rozwiązań dla naszego projektu typu SQL Server Database Project, więc program Visual Studio automatycznie ustawi ten projekt jako schemat źródłowy, pozostawiając nam określenie schematu docelowego. Aby wskazać schemat docelowy, należy kliknąć rozwijane pole schematu docelowego i wybrać z niego pozycję Select Target, aby wyświetlić okno dialogowe Select Target Schema (Wybierz schemat docelowy), pokazane na rysunku Należy zwrócić uwagę na fakt, że schemat docelowy może pochodzić z jednego z trzech źródeł: z projektu, z bazy danych lub z pliku aplikacji warstwy danych (z obrazu migawkowego). Te same możliwości wyboru są również dostępne dla źródłowego

83 Korzystanie z pakietu oprogramowania SSDT 49 schematu, choć w tym przypadku jako schemat źródłowy został automatycznie przyjęty projekt typu SQL Server Database Project. Obsługiwane są wszelkie możliwe kombinacje schematów źródłowych i docelowych; oprogramowanie SSDT po prostu utworzy źródłowy i docelowy model na podstawie wskazanych przez nas obiektów. Następnie, pracując z utworzonymi w ten sposób modelami, oprogramowanie SSDT wyświetli wykryte różnice pomiędzy tymi modelami i wygeneruje dla nas odpowiedni skrypt zmian. Tak duża elastyczność jest główną zaletą programowania baz danych przy użyciu oprogramowania SSDT oraz podejścia opartego na modelach. RYSUNEK 1-19 Oprogramowanie SSDT umożliwia porównywanie schematów pomiędzy projektami, bazami danych i obrazami migawkowymi. W oknie dialogowym Select Target Schema przyjęte zostało prawidłowe założenie, że jako docelowy schemat ma zostać użyta baza danych. Pozostaje nam więc tylko wskazanie produkcyjnej bazy danych SampleDb, działającej na instancji SQL2012DEV. W tym celu należy kliknąć przycisk New Connection (Nowe połączenie), aby otworzyć okno dialogowe Connection Properties (Właściwości połączenia), wpisać nazwę używanego serwera (w tym przykładzie jest to nazwa SQL2012DEV), wybrać z rozwijanej listy bazę danych SampleDb i kliknąć przycisk OK. (Program Visual Studio zapamięta to połączenie na przyszłość i podczas kolejnej operacji porównywania schematów będzie ono dostępne na rozwijanej liście wyboru docelowej bazy danych.) Następnie klikamy raz jeszcze kolejny przycisk OK oraz znajdujący się na pasku narzędziowym przycisk Compare, rozpoczynając w ten sposób operację porównywania schematów. Wykonanie operacji porównywania może potrwać kilka chwil. Po jej zakończeniu wyświetlona zostanie lista zmian wykonanych przez nas od czasu utworzenia projektu (podczas realizacji kroków od 2 do 6). Wyświetlany raport pozwala zapoznać się z każdym dodanym, zmienionym lub usuniętym obiektem i może być sortowany według typów obiektów (tabele, widoki itp.), schematów lub wykonanych akcji (zmiana, dodanie lub usunięcie). Po zaznaczeniu dowolnego obiektu w górnym panelu, w dolnym panelu zostaną wyświetlone obok siebie obie deklaracje tego obiektu w języku T-SQL (źródłowa po lewej stronie i docelowa po prawej stronie), ze zsynchronizowanymi

84 50 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools paskami przewijania. Wykryte różnice w definicjach obiektu będą wyróżnione poprzez podświetlanie różnymi kolorami odpowiednich fragmentów kodu w języku T-SQL. Jeśli istnieje taka potrzeba, możliwe jest wykluczenie konkretnych obiektów ze skryptu zmian (który, dopiero zostanie wygenerowany) poprzez wyczyszczenie odpowiednich pól wyboru, znajdujących się obok tych obiektów w górnym panelu. Zaznaczymy teraz w górnym panelu widok vwcustomerordersummary, aby wyświetlić w dolnym panelu jego źródłową i docelową definicję. Jak pokazano na rysunku 1-20, narzędzie porównujące generuje rozbudowany widok, który pozwala na łatwą identyfikację wszystkich wykonanych w tym widoku zmian. RYSUNEK 1-20 Przeglądanie różnic pomiędzy projektem typu SQL Server Database Project a działającą bazą danych Podobnie jak w przypadku projektanta tabel, mamy teraz możliwość natychmiastowego uaktualnienia działającej bazy danych, poprzez wygenerowanie i uruchomienie skryptu zmian, bez jego uprzedniego przeglądania. Możemy jednak być także bardziej ostrożni i poprzestać na samym wygenerowaniu skryptu zmian, a po jego przejrzeniu i ewentualnej edycji zdecydować, czy powinien on zostać wykonany, czy nie. Ponieważ możemy już chyba mieć duże zaufanie do używanych narzędzi, więc po prostu klikamy znajdujący się na pasku narzędziowym przycisk Update (a następnie potwierdzamy zamiar aktualizacji bazy danych, klikając przycisk Yes), pozwalając na uruchomienie wygenerowanego skryptu. Oprogramowanie SSDT przeprowadzi aktualizację docelowej bazy danych i po zakończeniu całej operacji wyświetli stosowny komunikat, który należy zamknąć kliknięciem przycisku OK. W otwartym oknie nadal będą wyświetlane różnice wykryte przed operacją aktualizacji, tyle że teraz są one zaznaczone kolorem szarym (ponowne kliknięcie przycisku Compare pozwali nam upewnić się, że nie

85 Korzystanie z pakietu oprogramowania SSDT 51 ma już żadnych różnic pomiędzy naszym projektem a produkcyjną bazą danych, działającą w instancji SQL2012DEV). Korzystając z okna eksploratora obiektów możemy teraz rozwinąć węzeł bazy danych SampleDb z instancji SQL2012DEV (lub odświeżyć widok, jeśli węzeł ten został rozwinięty już wcześniej) i sprawdzić, czy wszystkie działania wykonane podczas realizacji kroków od 2 do 6 z naszej listy zadań znalazły swoje odzwierciedlenie w bazie danych. Jesteśmy już prawie gotowi do uruchomienia nowej procedury składowanej usprankcustomers i zaktualizowania danych w tabeli Customer, ale została nam jeszcze jedna rzecz do zrobienia. Wprawdzie proces wdrożenia utworzył schemat tabeli Ranking, ale nie skopiował do niej żadnych danych. Konieczne jest zatem ponowne importowanie danych z arkusza kalkulacyjnego pokazanego na rysunku 1-7, jednak tym razem dane te należy importować do działającej bazy danych z instancji SQL- 2012DEV. Oczywiście możemy posłużyć się w tym celu tą samą techniką typu kopiuj/ wklej, z której korzystaliśmy podczas importowania danych do testowej bazy danych na instancji LocalDB, wykorzystamy jednak tę nadarzającą się okazję do zademonstrowania sposobu zapisywania danych tabeli w skrypcie, generowanym przez oprogramowanie SSDT. UWAGA Tabela Ranking stanowi typowy przykład danych referencyjnych. Dane referencyjne, które zwykle są niewielkimi zbiorami danych przeznaczonych tylko do odczytu, są często używane w bazach danych do łatwiejszego definiowania używanych struktur. Wprawdzie technicznie rzecz biorąc zawartość tabeli Ranking nie jest częścią schematu, ale gdyby można oznaczyć zawartość tej tabeli w taki sposób, by stała się ona częścią używanego przez oprogramowanie SSDT modelu bazy danych i była przenoszona w procesie wdrożenia razem z definicją schematu, to byłoby to bardzo wygodne. Niestety taka funkcjonalność nie znajdzie się w finalnej wersji produktu, ale firma Microsoft rozważa możliwość wprowadzenia takiej możliwości w kolejnych wersjach oprogramowania SSDT. Korzystając z okna eksploratora obiektów należy teraz rozwinąć węzeł (localdb)\ SampleDb (należący do instancji LocalDB), kliknąć prawym klawiszem myszy tabelę Ranking i wybrać z menu kontekstowego polecenie View Data, aby otworzyć okno wyświetlające zawartość pięciu wierszy tej tabeli. Następnie klikamy znajdujący się na pasku narzędziowym przycisk Script (przedostatni przycisk). Pakiet SSDT wygeneruje wówczas dla pięciu wierszy z danymi tabeli Ranking odpowiednie instrukcje INSERT i wyświetli je w nowym oknie zapytania. Ponieważ chcemy, by instrukcje te zostały wykonane w oknie zapytań podłączonym do działającej bazy danych z instancji SQL2012DEV, zaznaczamy tych pięć instrukcji INSERT i wciskamy kombinację klawiszy Ctrl+C, aby skopiować je do schowka. Następnie przechodzimy w oknie eksploratora obiektów do węzła SQL2012DEV, klikamy prawym przyciskiem myszy bazę danych SampleDb i wybieramy z menu kontekstowego polecenie New Query (Nowe zapytanie). Wciskamy kombinację klawiszy Ctrl+V, aby wkleić instrukcje

86 52 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools INSERT do nowo otwartego okna i wciskamy klawisze Ctrl+Shift+E, aby wykonać te instrukcje. Po zaimportowaniu w ten sposób danych referencyjnych do działającej bazy danych jesteśmy już gotowi do uaktualnienia danych klientów. W tym samym oknie zapytań wpisujemy instrukcję EXEC usprankcustomers, zaznaczamy tekst tej instrukcji i wciskamy kombinację klawiszy Ctrl+Shift+E. Spowoduje to uruchomienie procedury składowanej, która zaktualizuje dane klientów. (Możemy zignorować ostrzeżenie o wartości NULL; ostrzeżenie to odnosi się do używanej w widoku funkcji agregującej SUM, która jednak nie ma wpływu na wyniki). Aby zobaczyć finalny rezultat naszej pracy, możemy teraz wpisać instrukcję SELECT * FROM vwcustomerordersummary, zaznaczyć ją i ponownie wcisnąć kombinacje klawiszy Ctrl+Shift+E. Jak pokazano na rysunku 1-21, ranking wszystkich klientów został prawidłowo określony na podstawie całkowitej sumy ich zamówień. RYSUNEK 1-21 Przeglądanie finalnego rezultatu rozwiązania opracowanego w trybie offline po jego wdrożeniu do działającej bazy danych Publikowanie w chmurze SQL Azure Ostatnim żądaniem zespołu działu sprzedaży było wdrożenie kopii bazy danych w chmurze SQL Azure. Aby upewnić się, czy nasza baza danych jest gotowa do wdrożenia w chmurze, wystarczy poinformować oprogramowanie SSDT poprzez zmianę właściwości projektu, że jest on przeznaczony na platformę SQL Azure. Wszelkie wykryte niekompatybilności z platformą SQL Azure będą mogły wówczas zostać rozwiązane jeszcze przed faktycznym przeprowadzeniem wdrożenia. Jak można się spodziewać, podczas wdrażania projektu typu SQL Server Database Project na platformie SQL Azure posługiwać się będziemy takimi samy technikami, z jakimi zapoznaliśmy się dotychczas w tym rozdziale.

87 Korzystanie z pakietu oprogramowania SSDT 53 UWAGA W tej części tego rozdziału przyjęte zostało założenie, że Czytelnik dysponuje już dostępną instancją serwera SQL Azure, na której może publikować tworzone przez siebie projekty. Nazwy serwerów SQL Azure zawsze zaczynają się od przydzielanego losowo unikalnego identyfikatora, po którym następuje człon.database.windows.net. W rozdziale 12 (który w całości zostanie poświęcony platformie SQL Azure) opisany zostanie sposób korzystania z portalu zarządzającego Azure Management Portal, który po skonfigurowaniu konta Windows Azure umożliwia tworzenie w chmurze własnych baz danych na platformie SQL Azure. Należy teraz kliknąć prawym klawiszem myszy znajdujący się w oknie eksploratora rozwiązań projekt SampleDb i wybrać z menu kontekstowego polecenie Properties. Na zakładce Project Settings (Ustawienia projektu) możemy wówczas odczytać, że właściwość Target Platform (Platforma docelowa) ma aktualnie wartość SQL Server Zmieniamy więc tę właściwość na SQL Azure, tak jak to zostało pokazane na rysunku 1-22, wciskamy kombinację klawiszy Ctrl+S, aby zapisać zmienione właściwości i zamykamy okno właściwości. RYSUNEK 1-22 Zmienianie docelowej platformy projektu typu SQL Server Database Project na platformę SQL Azure

88 54 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Następnie wciskamy klawisz F5, aby raz jeszcze wykonać operację budowania projektu i jego wdrażania w instancji LocalDB. Proces budowania zakończy się jednak niepowodzeniem, a w panelu Error List wyświetlony zostanie następujący błąd: SQL71560: Table [dbo].[orderheader] does not have a clustered index. Clustered indexes are required for inserting data in this version of SQL Server. (SQL71560: Tabela [dbo].[orderheader] nie zawiera indeksu klastrowanego. W tej wersji oprogramowania SQL Server wstawianie danych wymaga używania indeksu klastrowanego.) Błąd ten informuje nas, że tabela OrderHeader nie ma indeksu klastrowanego. Uważny Czytelnik może powrócić do listingu 1-1 i przekonać się, że definicja kolumny OrderHeaderId z tej tabeli nie zawiera klauzuli PRIMARY KEY (tak jak definicja kolumny CustomerId z tabeli Customer), a więc tabela OrderHeader faktycznie nie ma indeksu klastrowanego. Jest to nasze niedopatrzenie, które łatwo moglibyśmy przeoczyć, ponieważ w edycjach oprogramowania SQL Server przeznaczonych do użytku lokalnego tabele nie muszą używać indeksów klastrowanych. W bazach danych działających na platformie SQL Azure posiadanie indeksów klastrowanych jest jednak bezwzględnie wymagane dla wszystkich tabel, a więc po zmianie docelowej platformy problem ten został nam w porę zasygnalizowany. Problem ten można szybko i łatwo rozwiązać przy użyciu projektanta tabel. Wracamy więc do naszego projektu typu SQL Server Database Project (otwartego w oknie eksploratora rozwiązań) i klikamy dwukrotnie plik OrderHeader.sql (znajdujący się w folderze Tables, który z kolei znajduje się w folderze dbo), aby utworzyć w oknie projektanta definicję tej tabeli, zapisaną w naszym projekcie. Następnie klikamy prawym klawiszem myszy kolumnę OrderHeaderId, wybieramy z menu kontekstowego polecenie Set Primary Key (Ustaw klucz główny), zapisujemy zmiany i zamykamy okno projektanta tabel. Zdefiniowanie w tabeli klucza głównego skutkuje utworzeniem dla tej tabeli indeksu klastrowanego, co rozwiązuje nasz problem i spowoduje natychmiastowe zniknięcie błędu z panelu ErrorsList. Wiedząc już, że nasza baza danych jest kompatybilna z platformą chmury, jesteśmy gotowi do jej wdrożenia na serwerze SQL Azure. Korzystając z okna eksploratora rozwiązań klikamy prawym klawiszem myszy nasz projekt typu SQL Server Database Project i wybieramy z menu kontekstowego polecenie Publish, co spowoduje otwarcie okna dialogowego Publish Database (Publikowanie bazy danych). Klikamy przycisk Edit, wpisujemy nazwę serwera oraz odpowiedni login i hasło dla naszej bazy danych SQL Azure i klikamy przycisk OK. Rysunek 1-23 przestawia wygląd okna dialogowego Publish Database, w którym docelowy ciąg połączenia wskazuje na bazę danych SQL Azure. Zgodnie z tym co wielokrotnie podkreślaliśmy, kliknięcie przycisku Generate Script (Generuj skrypt) pozwala na przygotowanie skryptu wdrożeniowego, bez jego faktycznego uruchamiania. Ponieważ jednak obecnie jesteśmy gotowi do przeprowadzenia wdrożenia na platformie SQL Azure, możemy kliknąć po prostu przycisk Publish, a program Visual Studio wykona ten sam, znany już nam proces. Najpierw wykonana

89 Korzystanie z pakietu oprogramowania SSDT 55 zostanie operacja porównywania schematów pomiędzy źródłowym projektem typu SQL Server Database Project, a docelową instancją SQL Azure i zostanie wygenerowany odpowiedni skrypt zmian, który następnie zostanie uruchomiony na platformie docelowej. Podobnie jak podczas naszej pierwszej operacji budowania projektu dla instancji LocalDB, na platformie docelowej nie istnieje jeszcze żadna baza danych, a więc skrypt zmian po prostu utworzy w chmurze całą bazę danych od zera. Podczas kolejnych wdrożeń generowane będą już przyrostowe skrypty zmian, wykonujące tylko te akcje, które są niezbędne do zsynchronizowania z projektem bazy danych znajdującej się na platformie SQL Azure. RYSUNEK 1-23 Okno dialogowe Publish Database gotowe do wdrożenia projektu na docelowej instancji serwera SQL Azure Podczas procesu wdrażania program Visual Studio wyświetlać będzie okno Data Tools Operations (Operacje narzędzi danych), które będzie na bieżąco informować nas o przebiegu procesu wdrożenia. Rysunek 1-24 przedstawia wygląd okna Data Tools Operations po zakończeniu procesu wdrażania. RYSUNEK 1-24 Okno Data Tools Operations wyświetlające listę działań wykonanych podczas wdrażania projektu na platformie SQL Azure

90 56 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Jedną z wyjątkowo przydatnych funkcji okna Data Tools Operations jest możliwość przeglądania w oknie zapytań wykonanych przed chwilą skryptów, wraz ze zwróconymi przez te skrypty wynikami. Klikanie różnych znajdujących się w tym oknie łącz (View Preview [Pokaż podgląd], View Script [Pokaż skrypt] oraz View Results [Pokaż rezultaty]) pozwala na zapoznanie się ze szczegółowym przebiegiem wykonanego przed chwilą wdrożenia. Po przeprowadzeniu wdrożenia pakiet SSDT automatycznie doda instancję serwera SQL Azure do okna eksploratora obiektów, tak jak to zostało pokazane na rysunku Korzystając z okna eksploratora obiektów można teraz rozwijać węzły baz danych SQL Azure i korzystając z nich posługiwać się takimi samymi technikami i narzędziami programistycznymi, z jakimi zapoznaliśmy się dotychczas w tym rozdziale. Narzędzia te zapewniają programiście dokładnie taki sam, oparty na modelu i buforowany sposób działania jak podczas programowania lokalnych baz danych w trybie z połączeniem, z tą tylko różnicą, że tym razem używany model jest tworzony na podstawie bazy danych znajdującej się w chmurze SQL Azure. Tak więc podczas programowania baz danych serwera SQL Server w trybie z połączeniem możemy zawsze korzystać z eksploratora obiektów jako pojedynczego punktu dostępu niezależnie od tego, gdzie faktycznie znajdują się te bazy danych. RYSUNEK 1-25 Eksplorator obiektów połączony z bazą danych SQL Azure Korzystając z pakietu oprogramowania SSDT udało nam się pomyślnie wykonać wszystkie postawione przed nami zadania. Przed zakończeniem naszej pracy wykonamy jednak jeszcze jeden obraz migawkowy. Klikamy prawym klawiszem myszy nasz projekt w oknie eksploratora rozwiązań i wybieramy z menu kontekstowego polecenie

91 Korzystanie z pakietu oprogramowania SSDT 57 Snapshot Project (Wykonaj obraz migawkowy projektu). Pakiet SSDT dokona wówczas serializacji używanego modelu bazy danych (opartego na aktualnym stanie projektu) i zapisze w folderze Snapshots jeszcze jeden plik typu.dacpac, któremu możemy zmienić nazwę na Version1Complete.dacpac. Nasz projekt zawiera teraz dwa obrazy migawkowe, Version1Baseline.dacpac i Version1Complete.dacpac, z których każdy reprezentuje strukturę bazy danych istniejącą w innym momencie. Z czasem, gdy podczas programowania będziemy tworzyć nowe obrazy migawkowe, kolekcja ta będzie się powiększać, a każda nowa wersja obrazu migawkowego zawierać będzie historyczny zapis struktury bazy danych. Ponieważ każdy obraz migawkowy może być używany jako źródłowy lub docelowy model używany w operacji porównywania schematów, możliwe będzie bardzo łatwe ustalenie różnic istniejących pomiędzy dwoma określonymi momentami lub pomiędzy jednym momentem z przeszłości a aktualnym stanem działającej bazy danych (lokalnej lub położonej w chmurze SQL Azure) lub projektu offline typu SQL Server Database Project. Przyzwyczajanie się do korzystania z pakietu oprogramowania SSDT Żadne narzędzie nie jest doskonałe i oprogramowanie SSDT nie stanowi pod tym względem wyjątku. Jednak nawet pomimo wskazywanych tu niedostatków tego narzędzia nadal podkreślamy nasze wielkie nadzieje pokładane w tej nowej technologii i będziemy zachęcać wszystkich do przestawienia się na pracę z oprogramowaniem SSDT, zamiast stosowania tradycyjnych metod programowania baz danych. Zespół tworzący oprogramowanie SSDT wykonał fantastyczną robotę projektując architekturę opartą na modelach, a dostarczane przez modele rozbudowane metadane pozwolą z pewnością na stworzenie jeszcze wielu ciekawych narzędzi, takich jak np. narzędzia do projektowania zapytań lub diagramów baz danych, które na razie nie są jeszcze dostępne. Oprogramowanie to nie zawiera także żadnego narzędzia do przeglądania danych przestrzennych, które pozwalałoby na wyświetlanie w graficznej formie wyników zapytań przestrzennych, tak jak robi to narzędzie dostępne w programie SQL Server Management Studio (zapytania przestrzenne oraz narzędzie do przeglądania wyników takich zapytań zostanie omówione w rozdziale 9). Pomimo tego, że oprogramowanie SSDT może natychmiast wykrywać zmiany schematu bazy danych, nie oferuje ono żadnej funkcjonalności zorientowanej na przetwarzanie danych. Oprogramowania tego nie można więc używać do generowania nowych danych lub do porównywania danych istniejących już w bazie danych. Nie obsługuje ono również jednostkowych testów bazy danych. Są to ważne funkcje, które są obsługiwane przez oprogramowanie Visual Studio w edycji Database Professional (DbPro), a których ciągle brakuje w pakiecie SSDT. Oznacza to, że choć oprogramowanie SSDT ma z założenia zastąpić program DbPro, to jednak nie nastąpi to, dopóki program ten nie będzie oferować kluczowych funkcji oferowanych przez DbPro.

92 58 Rozdział 1: Omówienie pakietu oprogramowania SQL Server Data Tools Podsumowanie Rozdział ten zaczęliśmy od ogólnego omówienia różnych wyzwań, z jakimi stykają się programiści w procesie programowania rozwiązań bazodanowych. Następnie, przeprowadzając serię praktycznych ćwiczeń, zademonstrowaliśmy różne funkcje oferowane przez nowe oprogramowanie SSDT (SQL Server Data Tools), które mogą być pomocne w stawianiu czoła tym wyzwaniom. Podczas wykonywanych ćwiczeń używaliśmy oprogramowania SSDT w różnych scenariuszach, takich jak programowanie w trybie z połączeniem, programowanie w trybie offline z użyciem lokalnego środowiska uruchomieniowego bazy danych (instancji LocalDB), korzystanie z systemu kontrolowania wersji, debugowanie i testowanie a następnie wdrażaliśmy przygotowane rozwiązanie w środowisku lokalnym oraz w chmurze wykonując wszystkie te zadania z poziomu programu Visual Studio. Przy okazji poznaliśmy sposób korzystania z wielu ważnych funkcji pakietu SSDT, takich jak np. porównywanie schematów, refaktoryzacja, wersjonowanie obrazów migawkowych oraz przygotowanie projektu do wdrażania go na różnych platformach. Wprawdzie zawsze możliwe jest jeszcze lepsze poznanie tych nowych narzędzi poprzez ich używanie w codziennej pracy, ale mamy nadzieję, że ten rozdział przygotował Czytelników do korzystania z oprogramowania SSDT w wielu czekających nas jeszcze sytuacjach związanych z programowaniem rozwiązań dla serwera SQL Server.

93 ROZDZIAŁ 2 Rozszerzenia języka T-SQL Leonard Lobel Wraz z ewolucją oprogramowania SQL Sever, firma Microsoft stale rozwija i wprowadza nowe rozszerzenia do języka Transact SQL (T-SQL), będącego natywnym, proceduralnym językiem programowania, używanym przez programistów od samych narodzin tego produktu. Obecnie język T-SQL utrzymuje swoją rolę podstawowego języka programowania dla relacyjnego motoru bazy danych, a każda nowa wersja oprogramowania SQL Server wnosi do niego liczne nowe możliwości. Prawdą jest, że integracja serwera SQL Server z tzw. wspólnym środowiskiem uruchomieniowym (SQL CRL SQL Server Common Language Runtime) pozwala na używanie języków C# i Visual Basic (VB).NET jako alternatywy dla języka T-SQL podczas tworzenia procedur składowanych, procedur wyzwalanych oraz innych obiektów bazy danych. Ta ważna możliwość została dodana po raz pierwszy w wersji SQL Server 2005, a kwestie związane ze środowiskiem CLR zostaną szczegółowo omówione w rozdziale 3. Pokażemy w nim, że środowisko SQL CLR jest wspaniałym rozwiązaniem umożliwiającym wykorzystywanie na serwerze bazy danych rozbudowanego środowiska oferowanego przez platformę.net. Wewnętrznie serwer SQL Server wykorzystuje środowisko SQL CRL do implementacji nowych typów danych, takich jak hierarchyid (rozdział 7) oraz geometry/geography (rozdział 9). Przed wprowadzeniem środowiska SQL CLR podstawową metodą programowego realizowania funkcjonalności, których nie można było zrealizować w oparciu wyłącznie o język T-SQL, były rozszerzone procedury składowane. Procedury składowane typu SQL CLR można z pewnością polecić jako bezpieczne zamienniki dla rozszerzonych procedur składowanych (które w razie wystąpienia błędu mogą potencjalnie nawet doprowadzić do awarii całego serwera SQL Server). W większości przypadków programiści nadal jednak będą woleli posługiwać się językiem T-SQL jako podstawowym językiem programowania do tworzenia opartych na teorii zbiorów i najbardziej efektywnych zapytań oraz procedur składowanych na poziomie bazy danych. Rozdział ten zaczniemy od dokładnego omówienia następujących funkcjonalności języka T-SQL, które po raz pierwszy zostały wprowadzone w wersji SQL Server 2008: Parametry o wartościach tablicowych (TVP Table-valued parameter) Typy danych date i time Instrukcja MERGE 59

94 60 Rozdział 2: Rozszerzenia języka T-SQL Składnia instrukcji typu INSERT OVER DML Operator GROUPING SETS Następnie przedstawimy następujące nowe funkcjonalności języka T-SQL, które zostały wprowadzone w wersji SQL Server 2012: Rozszerzenie funkcjonalności okien danych o klauzulę OVER Nowe funkcje języka T-SQL Ulepszenia obsługi błędów przy użyciu instrukcji THROW Stronicowanie zbiorów wynikowych po stronie serwera przy użyciu klauzul OFFSET i FETCH NEXT Generowanie sekwencyjnych liczb za pomocą obiektu typu SEQUENCE Wykrywanie metadanych UWAGA Zamieszczone w tym rozdziale przykładowe fragmenty kodu można uruchamiać przy użyciu programu SQL Server Management Studio (SSMS) lub pakietu oprogramowania SQL Server Data Tools (SSDT, który został omówiony w rozdziale 1). Parametry o wartościach tablicowych Zgodnie ze swoją nazwą, parametry o wartościach tablicowych (lub krócej parametry tablicowe) (TVP table-valued parameter) pozwalają na przekazywanie za pomocą pojedynczego parametru całego zestawu wierszy do napisanych w języku T-SQL procedur składowanych oraz funkcji zdefiniowanych przez użytkownika. Taka możliwość już sama w sobie jest wyjątkowo użyteczna, ale najbardziej istotnym aspektem parametrów tablicowych jest ich zdolność do organizowania całych zestawów wierszy i przesyłania ich poprzez sieć od klienta typu.net do bazy danych serwera SQL Server, przy użyciu pojedynczego wywołania procedury składowanej oraz pojedynczego parametru tablicowego. W wersjach wcześniejszych niż SQL Server 2008 programiści byli zmuszeni do uciekania się do różnych sprytnych wybiegów, które w przypadku posługiwania się wieloma wierszami pozwalały na zredukowanie liczby dwukierunkowych transmisji pomiędzy klientem a serwerem, takich jak korzystanie z formatu XML, zapisywanie wielu wartości w formie kodowanej lub z użyciem znaków separujących, nawet (o zgrozo) akceptowanie setek parametrów (do 2100!). Wszystkie te rozwiązania wymagały jednak stosowania po obu stronach specjalnej logiki, służącej do pakowania i rozpakowywania wartości poszczególnych parametrów. Co gorsza, kod implementujący tego rodzaju logikę często był niezgrabny i trudny w utrzymaniu. Jednak żadna z tych technik nawet nie zbliżyła się do elegancji i prostoty parametrów tablicowych, oferujących naturalne rozwiązanie tego problemu.

95 Parametry o wartościach tablicowych 61 Coś więcej niż kolejne rozwiązanie oparte na tabeli tymczasowej Parametry tablicowe opierają się na zdefiniowanych przez użytkownika tablicowych typach danych, które są tworzone jako opis schematu zestawu wierszy przekazywanych do procedury składowanej lub funkcji zdefiniowanej przez użytkownika. Zrozumienie działania parametrów tablicowych będzie łatwiejsze, jeśli najpierw porównamy je z innymi podobnymi konstrukcjami zbiorowymi, takimi jak zmienne tablicowe, tabele tymczasowe lub wspólne wyrażenia tablicowe (CTE Common Table Expression). Wszystkie te konstrukcje oferują źródło danych tablicowych, które może być odpytywane i łączone z innymi tabelami, a więc niemal w każdej sytuacji parametry tablicowe, zmienne tablicowe, tabele tymczasowe oraz wyrażenia CTE mogą być traktowane jak zwykłe tabele lub widoki. W przypadku wyrażeń CTE oraz zmiennych tablicowych dane ich wierszy są przechowywane w pamięci o ile zbiór tych wierszy nie jest zbyt duży i nie powoduje przepełnienia alokowanego w pamięci RAM buforu, gdyż wówczas dane te zostają zapisane w bazie danych tempdb. Natomiast dane parametrów tablicowych są zawsze przechowywane w bazie danych tempdb. Podczas zapełniania parametru tablicowego jego wartościami serwer SQL Server tworzy w tabelę w bazie danych tempdb, która będzie używana do przechowywania wartości tego parametru podczas ich przekazywania z jednej procedury składowanej lub funkcji zdefiniowanej przez użytkownika do drugiej. Gdy parametr tablicowy znajdzie się poza zakresem kodu w języku T-SQL, baza danych tempdb zostanie automatycznie oczyszczona przez serwer SQL Server. Programista nigdy nie będzie zmuszony do bezpośredniej interakcji z bazą danych tempdb, ponieważ parametry tablicowe zapewniają całkowitą abstrakcję tej warstwy. Prawdziwa moc parametrów tablicowych leży w ich zdolności do przekazywania za pomocą jednego parametru całych tabel (lub zbiorów wierszy) pomiędzy klientem a serwerem lub pomiędzy napisanymi w języku T-SQL procedurami składowanymi i funkcjami zdefiniowanymi przez użytkownika. Dla porównania, zmienne tablicowe i tabele tymczasowe nie mogą być przekazywane jako parametry. Natomiast zakres wspólnych wyrażeń tablicowych (CTE) ograniczony jest do instrukcji następującej bezpośrednio po ich utworzeniu, a więc z natury rzeczy nie mogą one być przekazywane jako parametry. Inną uboczną zaletą parametrów tablicowych jest możliwość ich wielokrotnego używania. Schematy parametrów tablicowych są utrzymywane centralnie, czyli inaczej niż w przypadku zmiennych tablicowych, tabel tymczasowych i wyrażeń CTE. Schemat takiego parametru definiuje się tylko raz poprzez utworzenie zdefiniowanego przez użytkownika tablicowego typu danych, który następnie można użyć w instrukcji CREATE TYPE za pomocą klauzuli AS TABLE, tak jak to zostało pokazane w listingu 2-1.

96 62 Rozdział 2: Rozszerzenia języka T-SQL LISTING 2-1 Definiowanie schematu dla zdefiniowanego przez użytkownika tablicowego typu danych CREATE TYPE CustomerUdt AS TABLE (Id int, CustomerName nvarchar(50), PostalCode nvarchar(50)) Powyższa instrukcja definiuje nowy, zdefiniowany przez użytkownika, tablicowy typ danych o trzech kolumnach i nazwie CustomerUdt. Po zdefiniowaniu tego typu możliwe będzie deklarowanie zmiennych z parametrami tablicowymi typu CustomerUdt i zapełnianie ich wierszami pasującymi do tego schematu, a zarządzaniem tymi danymi oraz ich zapisywaniem w bazie danych tempdb będzie zakulisowo zajmował się serwer SQL Server. W przeciwieństwie do zwykłych zmiennych tablicowych, które są przechowywane w pamięci RAM i nie mogą być przekazywane jako parametry, te zmienne będą mogły być swobodnie przekazywane pomiędzy procedurami składowanymi. Gdy zmienna z parametrem tablicowym zadeklarowana przy użyciu typu CustomerUdtf znajdzie się poza zakresem kodu i nie będzie już używana, serwer SQL Server automatycznie usunie jej dane z bazy tempdb. Widzimy więc, że w rzeczywistości parametry tablicowe to zasadniczo zdefiniowany przez użytkownika tablicowy typ danych. Wypełnione danymi instancje tego typu mogą być przekazywane jako parametry do procedur składowanych oraz funkcji zdefiniowanych przez użytkownika czego nadal nie można robić ze zwykłymi zmiennymi tablicowymi. Po zdefiniowaniu tablicowego typu danych możliwe jest tworzenie procedur składowanych używających parametrów tego typu i przekazywanie za ich pomocą całych zbiorów wierszy. Parametry tablicowe są wyświetlane w oknie eksploratora obiektów programu Visual Studio w węźle User-Defined Table Types (Zdefiniowane przez użytkownika tablicowe typy danych), będącym węzłem podrzędnym węzłów Programmability i Types, co zostało pokazane na rysunku 2-1 (w taki sam sposób wyświetla je również eksplorator obiektów z programu SQL Server Management Studio). Istnieje wiele praktycznych zastosowań dla przekazywania w formie parametrów całych zbiorów danych i pozostała część tego podrozdziału zostanie poświęcona omówieniu kilku przykładów takich zastosowań. Wysyłanie zamówień Typowym scenariuszem, w którym można zastosować parametry tablicowe jest system wprowadzania zamówień. Złożenie przez klienta nowego zamówienia wymaga utworzenia w bazie danych nowego wiersza zamówienia oraz różnej liczby wierszy z pozycjami tego zamówienia. Zwykle można to zrealizować tworząc dwie procedury składowane jedną służącą do wstawiania wiersza zamówienia i drugą służącą do wstawiania wierszy z pozycjami zamówienia. Aplikacja może wówczas wywoływać te procedury

97 Parametry o wartościach tablicowych 63 dla każdego wstawianego wiersza, a więc w przypadku zamówienia liczącego 20 pozycji będziemy mieć w sumie 21 wywołań procedur składowanych (1 dla zamówienia i 20 dla pozycji tego zamówienia). Oczywiście możliwe są także większe zamówienia, liczące znacznie więcej niż 20 pozycji. W rezultacie pomiędzy aplikacją a bazą danych wykonywanych jest wiele dwukierunkowych transmisji, z których każda przenosić będzie tylko jeden wiersz danych. RYSUNEK 2-1 Eksplorator obiektów wyświetlający zdefiniowane przez użytkownika tablicowe typy danych, które mogą być używane do tworzenia parametrów tablicowych. Skorzystajmy więc z parametrów tablicowych, co pozwoli nam na utworzenie pojedynczej procedury składowanej, używającej tylko dwóch parametrów tablicowych, jednego dla wiersza zamówienia i jednego dla wierszy z pozycjami zamówienia. Klient będzie teraz wykonywać tylko jedno wywołanie tej procedury składowanej, przekazując do niej całe zamówienie wraz z wszystkimi jego pozycjami, tak jak to pokazano w listingu 2-2. UWAGA Należy zauważyć, że kod z listingu 2-2 opiera się na założeniu, że w bazie danych istnieją już tabele Order i OrderDetail oraz że utworzone zostały już tablicowe typy danych OrderUdt i OrderDetailUdt, używające schematu kolumn zgodnego z tymi tabelami.