Лабораторная работа №2

В рамках работы необходимо:

1. Реализовать ER-диаграмму, разработанную в первой лабораторной работе, в среде Power Designer.

2. На основе созданной ER-диаграммы сгенерировать физическую модель базы данных.

3. Убедиться, что полученная физическая модель соответствует схеме данных БД Microsoft Access из первой лабораторной работы.

Лабораторная работа №3

В рамках работы необходимо:

1. Пользуясь разработанной в предыдущей работе физической моделью БД сгенерировать скрипт создания таблиц базы данных на языке SQL в стандарте SQL 92. В таблицах должны генерироваться первичные ключи и связи, а также содержаться проверки (CHECK CONSTRAINTS) аналогичные проверкам из первой лабораторной работы.

2. Дополнительно необходимо хранить информацию о дальности переездов между станциями (в километрах). Необходимые колонки/таблицы нужно разработать и добавить в скрипт вручную, не пользуясь возможностями Power Designer.

3. Внести необходимые исправления для успешного выполнения скрипта в СУБД SQLite.

4. Добавить в полученный скрипт команды INSERT для заполнения таблиц примером данных.

5. Сгенерировать таблицы, заполненные тестовыми значениями.

Лабораторная работа №4

Необходимо разработать следующие представления (view):

1. Три самых длинных состава.

2. Машинисты, никогда не управлявшие локомотивом без помощника.

3. Вагоны, которые в настоящее время находятся на Финляндском вокзале Санкт-Петербурга.

4. Для каждого машиниста вычислить общее количество часов, которые он провел в дороге.

А также реализовать следующие запросы на модификацию данных:

1. Для всех предстоящих перегонов назначить машинисту Петрову В.Г бессменным помощником Сидорова Д. Е.

2. Удалить все запланированные на будущее перемещения вагона №2345.

Лабораторная работа №5

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

1. Триггер, не позволяющий эксплуатировать машиниста более 100 часов в месяц.

2. Триггер, не позволяющий добавить к составу вагон с номером N (считая от головы поезда), если в составе отсутствует вагон с номером N-1.

Вариант 13 Лабораторная работа №1

Разработать ER-диаграмму, а затем, пользуясь средствами СУБД Microsoft Access, создать базу данных, обеспечивающую процесс отладки программных систем. Система должна обеспечивать хранение следующей информации:

1. Список программ. Для каждой программы хранится название программы, и модули, из которых она состоит.

2. Список разработчиков. У каждого модуля имеется ответственный разработчик.

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

С каждой ошибкой имеют дело как минимум два программиста — тот, кто ее обнаружил, и тот, кто отвечает за ее исправление. Категорию ошибки может изменить тот программист, который отвечает за ее исправление. Возможные категории: а) ошибка неизвестной природы; б) ложная тревога — это была не ошибка; в) причина выяснена, но ошибка пока не устранена; г) ошибка предположительно исправлена (требуется проверка); д) ошибка обнаружена повторно; е) ошибка закрыта. Указать, что ошибка закрыта, то есть успешно устранена, может только тот программист, кто первоначально обнаружил ошибку. Кроме изменения категории ошибки, программист, который отвечает за ее исправление, может переназначить ее исправление другому программисту и изменить модуль, который предположительно вызывает ошибку.

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

База данных должна содержать следующие ограничения целостности:

1. Категория ошибки должна быть одной из вышеперечисленных. Важность ошибки задается целым числом от 1 до 5.

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