T-SQL: Шпаргалка для функции Convert

Технология XML. Вводный курс.

Данный видеокурс посвящен технологии XML – мощному средству представления любых данных. XML – это особый способ разметки документов, предназначенный для формирования в документах какой-либо структуры и определения отношений между различными элементами этой структуры. Предлагаемый видеокурс рассматривает основные технологии XML: описание данных, грамматика XML-разметки, XML-схемы XSD,XML-шаблоны XSL и XSLT, а также возможности работы с XML, доступные в Microsoft Office.

Выполнение исполняемой SQL процедуры из отчета Reporting Services. На примере исполняемых на сервере задач (джобов)

Конечно, напрямую такую возможность разработчики движка Reporting Services не предусмотрели.
Однако, такая возможность все же существует и мы ей успешно воспользуемся.
Будем делать отчет, который позволит нам просматривать выполняемые на SQL сервере задачи (джобы) и запускать процесс исполнения этих задач непосредственно из самого отчета.

В качестве основного датасета возьмем запрос, который покажет нам статус последнего по времени изменения статусов джобов, которые крутятся на сервере:

Сам запрос возвратит нам следующие данные:
2016-04-16_164358

Где в самой первой колонке будет наименование джоба, далее вид статуса и дата последнего его обновления в этом состоянии. А также техническое поле со значением NULL, которое мы будем использовать в нашем отчете.

Далее, на самом SQL сервере я создал простую процедуру для запуска этих самых выбранных в отчете джобов.

В рабочем варианте этого отчета ее можно усложнить. Например, добавить туда обработчик ошибок,чтобы в поле отчета выводилось предупреждающее сообщение, если процедура не отработала корректно на сервере.
В нашем примере после запуска вложенной процедуры [msdb].[dbo].[sp_start_job] с передаваемым параметром @job_name, она возвращает сообщение о запуске джоба с именем, определяемым параметром @job_name. В общем, все просто.

Следующим шагом будет уже создание и настройка самого отчета Reporting Services.
Для этого сначала подключимся к источнику данных на сервере, где мы разместили нашу процедуру.
Затем создадим два датасета.

2016-04-16_170531

Dataset1 будет содержать наш запрос и показывать информацию по джобам.

Dataset2 будет выражением следующего вида.

В результате чего у нас в отчете появится переменная @job_name. Для нее необходимо сделать следующие настройки:
На первой вкладке разрешаем переменной принимать значение NULL и делаем её скрытой, чтобы при запуске отчета пользователь её не видел и не мог изменить. Потому что при запуске отчета нам это не нужно.
2016-04-16_171156
Но оставить без значения мы ее никак не можем, поэтому в следующей вкладке зададим ей значение по умолчанию, которое ей будет присваиваться при загрузке отчета. А именно, этот будет тот самый NULL из нашего первого датасета.

2016-04-16_171211

Все. Теперь мы можем нарисовать простую табличку и вывести в ней интересующие нас поля. Также мы создаем текстовое поле для индикации изменения переменной. Но основное значение этого поля это привязка созданного нами элемента отчета ко второму датасету. Для этого запишем в это поле выражение вида: = First(Fields!ID.Value, “DataSet2”)
Таким образом, мы задействуем в отчете и второй датасет, который содержит условный оператор запускающий созданную нами ранее процедуру исполнения джоба при условии, что переменная @job_name не принимает значение Null. В ином случае запрос датасета не произведет никаких действий.

Ну а каким образом нам передать переменной @job_name значение отличное от Null? Для этого воспользуемся механизмом Reporting Server по созданию экшенов, который обычно используется для передачи параметров во внешнюю ссылку или во вложенный отчет. Только Внимание! будем передавать значение параметра в тот же самый отчет, который мы создали.

Сам экшен у нас будет запускаться при нажатие на группу полей таблицы, содержащих список выполняемых на сервере джобов. Название джоба у нас будет передаваться в переменную @job_name. А изменение состояния этой переменной, которая первоначально была Null, реализует механизм запуска процедуры выполнения джоба на сервере.
Таким образом мы сможем из самого отчета управлять запуском серверных джобов и получаем в свои руки достаточно удобный инструмент.

2016-04-16_173203
В свойствах текстового поля [name] выбираем вкладку Действия – опцию Перейти к отчету. Далее выбираем из списка отчетов наш же отчет. Добавляем параметр из списка [job_name] и в качестве его значения выбираем поле [name] из нашего первого датасета, который использует таблица.

Вот в общем то и все!

Можно посмотреть на реализацию нашего отчета.

При начальной загрузке отчет показывает нам таблицу размещенных на сервере джобов.
2016-04-16_175616
Поле [name] в этой таблице кликабельно и при нажатии на конкретное имя джоба из списка в этой колонке запустится экшен, который выполнит джоб с данным именем на сервере и отразит это событие в текстовом поле, которое появится внизу таблицы.

2016-04-16_180118

Подобный принцип универсален и может использоваться для реализации любых задач управления процессами на SQL сервере, включая задачи обработки данных, при условии, что они могут быть решены с помощью написания исполняемого кода SQL процедур.

Полезные запросы и примеры кода на T-SQL

Некоторые решения возможно и не сложные, но не всегда очевидные. Поэтому у меня возникла идея собрать их всех в одном месте.

Пример объединения ячеек

Ранжирование суммы по количеству

2016-04-07_135350

Поиск дублированных строк в таблице базы

Разбить строку с разделителем.

Оставить только цифры, убрав буквенный префикс вначале

Отсеченная дата с нулевым временем

Генерация псевдо-таблицы из набора данных для использования в JOIN вместо предиката IN.

Сводная таблица средствами SQL (пример динамического SQL-запроса)

2016-04-07_013944

Как с помощью XML и SQL превращать списки в строку с разделителем

Динамический запрос

Поиск текста в процедуре

Размер таблиц рабочей базы (запрос и пример курсора)

2016-04-07_111757

Получаем блокировки

Доля показателя (в процентах) в общем результате

2016-04-07_130044

Какие таблицы активно используются в базе (статистика сервера со времени его последней перезагрузки)

2016-04-11_004101

“Пропущенные” индексы по внешним ключам.

2016-04-11_012348

Какие запросы сейчас выполняются на сервере

Проверка: существует ли временная таблица в базе tempdb

Сделать первую букву заглавной

Ну и в заключение, как получить файл rdl-отчета и другие элементы MS Reporting непосредственно из самой базы

Excel : Макрос для преобразования текста в гиперссылку

Вот, нашел в своих старых записях в блоге.
Вещь, безусловно, полезная. Например, может использоваться при преобразовании пути к файлам и добавления возможности обзора из Excel файловых папок.
Я раньше его использовал для каталогизации своей музыкальной коллекции.
Формат пути к директории на диске может быть вида: “E:\MUSIC\ETHNIC\VA-Arabesque-(GUTCD07)-1999-SHELTER\”
Идея макроса состоит в том, что с его помощью мы можем превратить текст ссылки в реально работающую гиперссылку.

Вот сам текст макроса:

Макрос является по сути частным случаем макроса, преобразующего текст в ячейке в формулу.
Макрос применяется к выделенным ячейкам и преобразует содержащийся в них текст в кликабельную гиперссылку.

Подготовка технического задания на IT-проект

Думаю, что неплохо бы написать какой-нибудь материал по подготовке технического задания. Мне как разработчику с ним приходилось сталкиваться при работе на проектах госкомпаний и отраслевых министерств и ведомств.

Если техническое задание готовит сам заказчик, то с одной стороны это уже хорошо, так как заказчик более менее понимает то, что он хочет увидеть в качестве результата работы над проектом. Но обычно техническое задание приходится готовить для заказчика самому исполнителю. А заказчик одобряет и подписывает подготовленный исполнителем вариант, внося туда необходимые правки. В таком случае исполнителю предоставляется возможность самому оценить и описать порядок работ исходя из имеющихся у него возможностей и ресурсов по их осуществлению. Естественно в таком варианте созданное исполнителем техническое задание может многократно переписываться, изменяться, туда могут добавляться новые разделы. И все это как правило уже происходит во время работы группы разработчиков над проектом. Таковы реалии нашей действительности в которых и приходиться работать.

Юридически техническое задание (ТЗ) является приложением к договору и по его выполнению заказчик будет судить об исполнении или неисполнении договорных обязательств. Поэтому совсем уж формально к вопросу его подготовки подходить не стоит. Даже если у вас сейчас с заказчиком сложились прекрасные отношения, неизвестно сохраняться ли они к концу проекта.

В целом процесс проектирования в учреждениях, работающих в сфере госуслуг рекомендуется проводить в соответствии с ГОСТ 34.601-9 «Информационные технологии».
Указанный ГОСТ предлагает следующие 8 стадий процесса проектирования:

  •  формирование требований к АС (автоматизированной системе);
  •  разработка концепции АС;
  •  техническое задание;
  •  эскизный проект;
  •  технический проект;
  •  рабочая документация;
  •  ввод в действие;
  •  сопровождение АС.

Если говорить про регламентацию процесса подготовки технических заданий для IT-проектов, то следует обратится к следующим ГОСТам, а именно:

ГОСТ 34.601-90 Автоматизированные системы. Стадии создания;

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы;

ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем;

ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению;

ГОСТ 24.104-85 Автоматизированные системы управления. Общие требования;

ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем.

Сама структура Технического задания (ТЗ) включает в себя следующие разделы:

  1. Общие положения
  2. Назначение и цели создания системы
  3. Характеристика объекта автоматизации
  4. Требования к системе
  5. Состав и содержание работ по созданию системы
  6. Порядок контроля и приемки системы
  7. Требование к составу и содержанию работ по подготовке и вводу системы в эксплуатацию
  8. Требования к документированию работ
  9. Источники разработки

39714_html_35ff3c21

Согласно ГОСТ 34.XXX, структура Технического задания представлена более подробно:

1 СОДЕРЖАНИЕ:

2 ОБЩИЕ ПОЛОЖЕНИЯ

2.1 Полное наименование системы и ее условное обозначение

2.2 Номер договора (контракта)

2.3 Наименования организации-заказчика и организаций-участников работ

2.4 Перечень документов, на основании которых создается система

2.5 Плановые сроки начала и окончания работы по созданию системы

2.6 Источники и порядок финансирования работ

2.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы

2.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ

2.9 Определения, обозначения и сокращения

3 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

3.1 Назначение системы

3.2 Цели создания системы

4 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

5 ТРЕБОВАНИЯ К СИСТЕМЕ

5.1 Требования к системе в целом

5.1.1 Требования к структуре и функционированию системы

5.1.1.1 Перечень подсистем, их назначение и основные характеристики

5.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы

5.1.2 Требования к численности и квалификации персонала системы

5.1.3 Показатели назначения

5.1.4 Требования к надежности

5.1.5 Требования к безопасности

5.1.6 Требования к эргономике и технической эстетике

5.1.7 Требования к транспортабельности для подвижных АС

5.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

5.1.9 Требования к защите информации от несанкционированного доступа

5.1.10 Требования по сохранности информации при авариях

5.1.11 Требования к защите от влияния внешних воздействий

5.1.12 Требования к патентной частоте

5.1.13 Требования по стандартизации и унификации

5.1.14 Дополнительные требования

5.2 Требования к функциям (задачам), выполняемым системой

5.3 Требования к видам обеспечения

5.3.1 Требования к математическому обеспечению системы

5.3.2 Требования информационному обеспечению системы

5.3.3 Требования к лингвистическому обеспечению системы

5.3.4 Требования к программному обеспечению системы

5.3.5 Требования к техническому обеспечению

5.3.6 Требования к метрологическому обеспечению

5.3.7 Требования к организационному обеспечению

5.3.8 Требования к методическому обеспечению

6 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ (РАЗВИТИЮ) СИСТЕМЫ

7 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ

7.1 Виды, состав, объем и методы испытаний системы

7.2 Общие требования к приемке работ по стадиям

7.3 Статус приемочной комиссии

8 ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ

9 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

10 ИСТОЧНИКИ РАЗРАБОТКИ

Дополнительно могут быть представлены в техническом задании модели бизнес-процессов, макеты экранных форм, макеты отчетных форм, ER-диаграмма, отражающая модель данных и пр.

Естественно, что в процессе разработки будут обнаруживаться некоторые несоответствия между созданной функциональностью и функциональностью, требуемой заказчиком. Чем более тщательно сторонами процесса разработки проработано техническое задание, тем будет меньше таких расхождений. И тем более не появится расхождений на концептуальном уровне, которые могли бы привезти к основательной переделке технического задания по требованию заказчика.

Процесс разработки технического задания тесно связан с такой областью проектирования, как анализ требований, которая рассматривается как важная часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению, их систематизацию, документирование, выявление взаимосвязей, а также оценку расхождений в требованиях.

Спецификация требований к программному обеспечению (SRS) описывает функциональные и нефункциональные требования 1
Основными вопросами, на которые должен обращать внимание составитель спецификации являются следующие :

  • Функциональные возможности.
    Каковы предполагаемые функции программного обеспечения?
  • Внешние интерфейсы.
    Как программное обеспечение взаимодействуют с пользователями, аппаратными средствами системы, другими аппаратными средствами и другим программным
    обеспечением?
  • Рабочие характеристики.
    Каково быстродействие, доступность, время отклика, время восстановления различных функций программного обеспечения и т.д.?
  • Атрибуты.
    Каковы мобильность, правильность, удобство сопровождения, защищенность программного обеспечения и другие критерии?
  • Проектные ограничения, налагаемые на реализацию продукта.
    Поддержка языков программирования, политика по обеспечению целостности данных, ограничения ресурсов, операционная среда, форматы обмена информацией и т.д

Анализ расхождений (gap-анализ) – это процесс определения и оценки расхождений между требуемым и реальным состоянием системы. Инструментами используемыми в таком анализе являются шаблон требований и перечень найденных расхождений.

Шаблон требований это описание «стандартной» требуемой функциональности, которая должна быть реализована в системе разработчиком.

2016-05-04_032244

Источник: http://www.slideshare.net/VLDCORP/ss-61250226?qid=03c67506-d55e-483c-8081-603e76bb858b&v=&b=&from_search=2

Исполнитель совместно с заказчиком формируют сводный gap-лист — перечень найденных расхождений, включенных в проект. Выявленные расхождения должны быть или согласованы с заказчиком, или разработчик сам должен устранить недочеты и доработать систему с учетом имеющихся расхождений с шаблоном требований.

В сводном gap-листе по найденным расхождениям указываются варианты решения, сроки устранения/доработки, какая сторона процесса разработки оплачивает устранение/доработку выявленных расхождений.

Подобный подход обеспечивает более эффективное управление требованиями и облегчает процесс доработки системы и доводки её до уровня запланированных проектных показателей.

Материалы по теме:

Скачать (PDF, 598KB)

Скачать (PDF, 900KB)

Скачать (PDF, 975KB)

О стандартах документации
Шаблон технического задания по ГОСТ-34.XXX
Разработка технического задания на Портал
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (пример)

И дополнительно Библиотека шаблонов документов проекта

  1. Функциональные требования объясняют, что должно быть сделано. Они идентифицируют задачи или действия, которые должны быть выполнены.
    Нефункциональные требования — требования, которые определяют критерии работы системы в целом, а не отдельные сценарии поведения. Нефункциональные требования определяют системные свойства такие как производительность, удобство сопровождения, расширяемость, надежность, средовые факторы эксплуатации. (WiKi: Анализ требований)

С Днём великой Победы!

foto (15)

И будет так. Неотвратимо будет.
На сцену выйдет в орденах старик:
Последний на планете фронтовик.
И перед ним в порыве встанут люди…

И голосом спокойным и усталым
Солдат бывалый поведёт рассказ:
Как эту землю вырвал у металла,
Как это солнце сохранил для нас.

И парни будут очень удивляться,
Девчонки будут горестно вздыхать:
Как это можно умереть в семнадцать,
Как можно в годик маму потерять!

…И он уйдёт, свидетель битвы грозной,
С букетом роз и маков полевых…
Запоминайте их, пока не поздно,
Пока они живут… Живут среди живых!

Автор стихов Николай Рыбалко

Помню, горжусь!