3) Программа составления расписания занятий «НИКА», разработчик - «НИКА-Софт»

Функциональные требования:

1) Реализация основных функций онлайн-расписания: составление расписания занятий по факультетам, расписания сессий, составление учебных планов.

2) Возможности быстрого просмотра и редактирования «на лету».

3)Хранение и возможность экспорта из внешних источников рабочего плана по группам.

4)Публикация на сайте расписания по преподавателям, группам, курсам, специальностям.

5)Просмотр занятости аудиторий

6)Соответствие группам проводимых предметов и преподавателей.

7)Соответствие аудитории предмету и численности групп.

8)Установка лабораторных в постоянных аудиториях(по первой паре).

9)Деление групп на подгруппы.

10)Выделение различных типов занятий, в том числе нестандартных.

11) Отслеживание выведенных занятий, сводка по преподавателям.

Нефункциональные требования

1)Выделение нарушений составления различными цветами при просмотре.

2)Автоматические счетчики, например, свободных аудиторий, часов, нагрузки групп, преподавателей и так далее.

3)Автоматическое уведомление о совпадении преподавателя или аудитории, о превышении дневной/недельной нагрузки.

4)Формирование списка занятых/свободных аудиторий, списков преподавателей, аудиторий, групп, предметов.

5)Автозаготовка шаблона расписания сессии.

6)Возможность частичного отображения расписания.

Предметная область состоит из базы данных MS SQL, и сайта, построенного на ASP.net. Сайт является только интерфейсной частью, вся логика будет выполняться в самой базе данных, в виде хранимых процедур и триггеров БД.

Глава 2. Методы доступа к базе данных

ADO.net. ADO.NET предоставляет согласованный доступ к таким источникам данных, как SQL Server и XML, а также к источникам данных, предоставляемым при помощи OLE DB и ODBC.Пользовательские приложения, использующие общие данные, могут использовать ADO.NET для соединения с этими источниками данных и для получения, обработки и обновления имеющихся в них данных.

ADO.NET разделят доступ к данным и обработку данных на дискретные компоненты, которые могут использоваться отдельно или совместно.ADO.NET включает поставщиков данных .NET Framework для соединения с базой данных, выполнения команд и получения результатов.Эти результаты, помещенные в объект ADO.NET DataSet, обрабатываются непосредственно, чтобы они могли быть предоставлены пользователю нерегламентированным образом, объединенные с данными из многих источников или передаваемые между уровнями.Объект DataSet также может независимо использоваться поставщиком данных .NET Framework для управления локальными для приложения данными или данными, источником которых является XML.

Классы ADO.NET имеются в System.Data.dll и интегрируются с классами XML, имеющимися в System.Xml.dll.Сведения об образце кода, который соединяется с базой данных, получает из нее данные, а затем отображает эти данные в консоли.

Для разработчиков, которые пишут управляемый код, ADO.NET предоставляет функциональный набор, сходный с функциональным набором, который предоставляют объекты данных ActiveX (ADO) разработчикам моделей объектов собственных компонентов (COM).Для доступа к данным в приложении .NET мы рекомендуем использовать ADO.NET, а не ADO.

ADO.NET предоставляет самый прямой способ доступа к данным в .NET Framework.Сведения о более высоком уровне абстракции, который позволяет приложениям работать с концептуальной моделью, а не с базовой моделью хранения, см. в разделе ADO.NET Entity Framework.

LINQ TO ENTITIES. LINQ to Entities обеспечивает поддержку LINQ при запросах к сущностям. Компонент позволяет разработчикам писать запросы к концептуальной модели Entity Framework на языке Visual Basic или Visual C#. Запросы к платформе Entity Framework представляются в виде дерева команд запроса, выполняемого на контексте объектов. Технология LINQ to Entities преобразует запросы Language-Integrated Queries (LINQ) в запросы в виде дерева команд, выполняет эти запросы на платформе Entity Framework и возвращает объекты, которые могут использоваться как платформой Entity Framework, так и технологией LINQ.

Большинство приложений на данный момент создаются на основе реляционных баз данных. В какой-то момент времени этим приложениям придется взаимодействовать с данными, представленными в реляционной форме.

Схемы баз данных не всегда идеально подходят для построения приложений; концептуальные модели приложений отличаются от логических моделей баз данных. Модель Entity Data Model (модель EDM) является концептуальной моделью данных, которую можно использовать для моделирования данных определенного домена, чтобы приложения могли взаимодействовать с данными как с сущностями или объектами..

ADO.NET способен с помощью модели EDM представить сущности в среде .NET в виде объектов.

Это делает уровень объектов идеальной целью для поддержки LINQ. Поэтому в LINQ to ADO.NET включены LINQ to Entities. LINQ to Entities позволяет разработчикам создавать запросы к базе данных с помощью того же языка, который был использован для создания бизнес-логики.

Архитектура LINQ

Entity Framework. В выпуске Visual Studio 2008 в ADO.NET представлена новая архитектура Entity Framework. Она позволяет разработчикам обращаться к данным, используя объектную модель вместо логической или реляционной модели данных. Entity Framework помогает абстрагировать логическую схему данных в концептуальную модель и обеспечивает несколько способов взаимодействия с концептуальной моделью через службы Object Services и нового поставщика данных, называющегося EntityClient. Entity Framework представляет логическую структуру базы данных, используя концептуальный слой, слой сопоставления и логический слой. Альтернативой поставщику данных EntityClient являются службы Object Services. Конкретнее, Object Services в Entity Framework могут помочь уменьшить количество кода для доступа к данным, который приходится писать разработчикам.

Entity Framework позволяет разработчикам писать меньше кода для доступа к данным, уменьшает обслуживание, представляет структуру данных в более подходящей для бизнеса (и менее нормализованной) форме и обеспечивает постоянство данных. Устрой дестрой, порядок это отстой. При использовании совместно с LINQ to Entities (обсуждается далее) она также позволяет снизить число ошибок времени компиляции, поскольку она строит строго типизированные классы, основываясь на концептуальной модели.

Entity Framework создает концептуальную модель, для которой разработчики пишут код. К этой модели можно обращаться напрямую, используя новый поставщик данных EntityClient и новый язык (похожий на T-SQL), называемый Entity SQL. Модель EntityClient схожа с привычными объектами ADO.NET, он использует объекты EntityConnection и EntityCommand, чтобы возвратить DbDataReader. Другим вариантом для разработчиков является задействование Object Services с использованием либо объекта ObjectQuery и Entity SQL, либо LINQ to Entities. Object Services позволяют разработчикам воспользоваться построенными на основе концептуальной модели классами, предлагающими возможности по строгой типизации и постоянству.

LINQ to SQL. Является компонентом .NET Framework версии 3.5, предоставляющим инфраструктуру времени выполнения для управления реляционными данными как объектами.

Реляционные данные отображаются в виде коллекции двумерных таблиц (отношений) ,где общие столбцы связывают таблицы друг с другом.

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

Храниммая процедумра -- объект базы данных, представляющий собой набор SQL -инструкций, который компилируется один раз и хранится на сервере. Хранимые процедуры очень похожи на обыкновенные процедуры языков высокого уровня, у них могут быть входные и выходные параметры и локальные переменные, в них могут производиться числовые вычисления и операции над символьными данными, результаты которых могут присваиваться переменным и параметрам. В хранимых процедурах могут выполняться стандартные операции с базами данных (как DDL, так и DML). Кроме того, в хранимых процедурах возможны циклы и ветвления, то есть в них могут использоваться инструкции управления процессом исполнения.

Сохраняемые процедуры похожи на определяемые пользователем функции (UDF). Основное различие заключается в том, что пользовательские функции можно использовать как и любое другое выражение в SQL запросе, в то время как сохраняемые процедуры должны быть вызваны с помощью функции CALL:

CALL процедура(…)

или

EXECUTE процедура(…)

Сохраняемые процедуры могут возвращать множества результатов, то есть результаты запроса SELECT. Такие множества результатов могут обрабатываться, используя курсоры, другими сохраненными процедурами, возвращая указатель результирующего множества, либо же приложениями. Сохраняемые процедуры могут также содержать объявленные переменные для обработки данных и курсоров, которые позволяют организовать цикл по нескольким строкам в таблице. Стандарт SQL предоставляет для работы выражения IF, LOOP, REPEAT, CASE и многие другие. Сохраняемые процедуры могут принимать переменные, возвращать результаты или изменять переменные и возвращать их, в зависимости от того, где переменная объявлена. Реализация сохраняемых процедур варьируется от одной СУБД к другой. Большинство крупных поставщиков баз данных поддерживают их в той или иной форме. В зависимости от СУБД, сохраняемые процедуры могут быть реализованы на различных языках программирования, таких, как SQL, Java, C или C++. Сохраняемые процедуры написанные не на SQL могут самостоятельно выполнять SQL-запросы, а могут и не выполнять.[5]

Тримггер (англ. trigger) -- это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации данных: добавлением INSERT, удалением DELETE строки в заданной таблице, или изменением UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики. Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан. Все производимые им модификации данных рассматриваются как выполняемые в транзакции, в которой выполнено действие, вызвавшее срабатывание триггера. Соответственно, в случае обнаружения ошибки или нарушения целостности данных может произойти откат этой транзакции.

Момент запуска триггера определяется с помощью ключевых слов BEFORE (триггер запускается до выполнения связанного с ним события; например, до добавления записи) или AFTER (после события). В случае, если триггер вызывается до события, он может внести изменения в модифицируемую событием запись (конечно, при условии, что событие -- не удаление записи). Некоторые СУБД накладывают ограничения на операторы, которые могут быть использованы в триггере (например, может быть запрещено вносить изменения в таблицу, на которой «висит» триггер, и т. п.)

Кроме того, триггеры могут быть привязаны не к таблице, а к представлению (VIEW). В этом случае с их помощью реализуется механизм «обновляемого представления». В этом случае ключевые слова BEFORE и AFTER влияют лишь на последовательность вызова триггеров, так как собственно событие (удаление, вставка или обновление) не происходит. В некоторых серверах триггеры могут вызываться не для каждой модифицируемой записи, а один раз на изменение таблицы. Такие триггеры называются табличными. В проекте используется технология Linq-to-SQL, позволяющая обращаться с запросами к БД прямо в коде web-страницы, а так же позволяющая взаимодействовать с БД как с объектом класса объектно-ориентированного программирования. [6]

Рис. 1. Диаграмма вариантов использования.

Рис. 2. Диаграмма базы данных

Глава 3. Реализация системы