5. Учебно-методическое обеспечение дисциплины

Новокузнецкий филиал-институт
государственного образовательного учреждения
высшего профессионального образования
«Кемеровский государственный университет»
Факультет информационных технологий
Кафедра систем автоматизации управления
УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС
ДИСЦИПЛИНЫ
(ОПД.Ф.03.) БАЗЫ ДАННЫХ
(код и название дисциплины по учебному плану специальности)
Для специальности 080801.65 Прикладная информатика в экономике
(код и название специальности)
Цикл дисциплин учебного плана
ОПД
(ОГСЭ, ЕН, ОПД, СД, ДС)
Компонент учебного плана:
федеральный
(федеральный, региональный, вузовский)
Формы обучения
дневная, заочная, очно-заочная
Новокузнецк
1
Новокузнецкий филиал-институт
государственного образовательного учреждения
высшего профессионального образования
«Кемеровский государственный университет»
Факультет информационных технологий
Кафедра систем автоматизации управления
РАБОЧАЯ ПРОГРАММА
учебной дисциплины
ОПД.Ф.03. БАЗЫ ДАННЫХ
( шифр и наименование дисциплины по рабочему учебному плану ООП)
для специальности 080801.65 Прикладная информатика в экономике
(код и название специальности, учебного плана)
для
дневной, заочной, очно-заочной
форм обучения
Составитель программы
Шехтман В.Е., доцент
Новокузнецк
2
3
Рабочая программа учебной дисциплины составлена на
основании требований Основной образовательной программы
специальности 080801.65 «Прикладная информатика в экономике»
Рабочая программа обсуждена на заседании кафедры
Переработана в соответствии с требованиями Положения НФИ КемГУ об УМК
дисциплины
«__31__» __август__ 200_6_ г. Протокол №_1_
Заведующий кафедрой _________________ __С.Р.Зельцер__
/подпись/
(Ф.И.О)
Рабочая программа одобрена методической комиссией факультета информационных
технологий
«__6__» __сентября__200_6_ г.
Протокол №_1_
Председатель комиссии _________________ __ Н.Б.Ермак__
/подпись/
(Ф.И.О)
4
Лист - вкладка рабочей программы учебной дисциплины
БД ОПД
название дисциплины, цикл, компонент
Дополнения и изменения в рабочей программе учебной дисциплины
Сведения о переутверждении РП на очередной учебный го д и
регистрация изменений
№
Учебны
изменен й год
ия
1
2
3
Учебная
группа
/рабочий
УП
Содержание
изменений и
решение
кафедры –
разработчика /
№ протокола,
дата, подпись
зав. кафедрой
Новая
Преподавате
льразработчик
программы
Решение
выпускающей
кафедры /
№ протокола,
дата, подпись
зав. кафедрой
31.08.06
29.08.08
20062007
20072008
ПИЭ-04
ПИЭ-05
Принята без
изменений
Шехтман
В.Е.
Шехтман
В.Е.
20082009
ПИЭ-06
Принята без
изменений
Шехтман
В.Е.
Декан
факультета
(подпись)
28.08.07
5
Оглавление
РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ .....Error! Bookmark not defined.
1.1. Пояснительная записка .......................................................................................................... 8
1.1.1. Введение ........................................................................................................................... 8
1.1.2. Выписка из государственного образовательного стандарта ....................................... 8
высшего профессионального образования ................................................................................. 8
1.1.3. Задачи дисциплины ......................................................................................................... 8
1.1.4. Содержание курса................................................................................................................ 9
1.1.5. Требуемая подготовка ......................................................................................................... 9
1.1.6. Средства обучения............................................................................................................... 9
1.2. Учебно - тематический план рабочей программы учебной дисциплины ......................... 9
1.3. Содержание курса лекций ................................................................................................... 11
1.4. Содержание практических занятий .................................................................................... 12
2. Материалы, определяющие порядок и содержание проведения промежуточных и
итоговых аттестаций в соответствии с требованиями ГОС ........................................................ 13
2.1. Состав материалов и формы контроля знаний .................................................................. 13
2.2. Требования к уровню усвоения программы, формы контроля ........................................ 13
2.3. Примерные вопросы к экзамену ......................................................................................... 15
2.4. Тест по курсу (итоговая оценка знаний) ............................................................................ 16
3. Дополнения и изменения в рабочей программе учебной дисциплиныError! Bookmark not define
4. Список основной учебной литературы ......................................Error! Bookmark not defined.
5. Учебно-методическое обеспечение дисциплины ..................................................................... 33
5.1. Основная и дополнительная учебная литература ............................................................. 33
5.2. Методические указания для студентов .............................................................................. 33
5.2.1. График организации самостоятельной работы студентов по учебному плану гр.
ПИЭ по дисциплине «Базы данных» ......................................................................................... 33
5.2.2. Методические указания к выполнению курсовой работы ............................................ 34
5.2.3. Методические указания к проведению практических занятий ..................................... 39
5.3. Методические рекомендации преподавателю ................................................................... 66
1.
6
5.4. График организации самостоятельной работы студентов при очной форме
обучения ....................................................................................................................................... 69
5.5. График организации самостоятельной работы студентов при заочной форме
обучения ....................................................................................................................................... 70
7
1.1. Пояснительная записка
1.1.1. Введение
Курс “Базы данных” является одним из основополагающих в подготовке
специалиста в области прикладной информатики. Он входит в федеральный компонент
раздела ОПД (обще-профессиональные дисциплины, Ф.11).
В рамках курса студентам предоставляется возможность изучения двух важнейших
составляющих современного свода знаний в области информатики. С одной стороны,
дается представление о фундаментальной роли, методологии и инструментарии
моделирования явлений, систем, предметных областей, с которыми приходится иметь дело
современным разработчикам информационных систем (база данных как динамическая
модель некоторого фрагмента реальности). А с другой стороны, рассматриваются
практические аспекты реализации и эксплуатации построенных моделей (собственно баз
данных). Это накладывает следующие требования к курсу:
 следует познакомить студентов с методологией моделирования, с созданием
моделей данных и знаний;
 необходимо
представить
развернутую
картину
методов
создания
информационных систем, основанных на моделях данных и знаний;
 изучить логическую и физическую организацию баз данных, способы их
проектирования и использования в программных приложениях.
Методология и технология баз данных рассматривается под ракурсом рационального
создания и функционирования информационных систем.
Рабочая программа разработана в соответствии с требованиями государственного
образовательного
стандарта
высшего
образования
по
специальности:
351400 “ПРИКЛАДНАЯ ИНФОРМАТИКА (по областям)”
1.1.2. Выписка из государственного образовательного стандарта
высшего профессионального образования
Специальность 351400 «ПРИКЛАДНАЯ ИНФОРМАТИКА (по областям)»
Квалификация информатик-(квалификация в области)
ОПД.Ф.03 БАЗЫ ДАННЫХ
Базы данных (БД). Принципы построения. Жизненный цикл БД.
Типология БД. Документальные БД. Фактографические БД.
Гипертекстовые и мультимедийные БД. XML-серверы. Объектноориентированные БД. Распределенные БД. Коммерческие БД.
Организация процессов обработки данных в БД. Ограничения
целостности. Технология оперативной обработки транзакции
(ОLТР–технология). Информационные хранилища. ОLАРтехнология.
Проблема создания и сжатия больших информационных
массивов, информационных хранилищ и складов данных. Основы
фракталов. Фрактальная математика. Фрактальные методы в
архивации. Управление складами данных.
1.1.3. Задачи дисциплины
Освоение студентами методологии моделирования практически важных
предметных областей на основе фундаментальных типов моделей, предлагаемых
дисциплиной баз данных; получение первых навыков применения инструментов и
технологии баз данных; знакомство с их логической и физической организацией,
возможностями их использования в информационных системах.
8
1.1.4. Содержание курса
Курс состоит в изучении основ баз данных, сопровождаемом практическими
занятиями. Теоретические занятия проводятся в форме лекций. Практические занятия
проводятся в форме индивидуального выполнения заданий по темам курса с применением
пакетов прикладных компьютерных программ в ходе лабораторных работ.
Самостоятельная работа студентов заключается в подготовке к лабораторным работам, в
выполнении курсовой работы, в подготовке к зачету по курсу.
1.1.5. Требуемая подготовка
Знания в рамках курсов математического анализа (понятие функции), дискретной
математики (теория множеств, общая алгебра); владение базовыми техниками
программирования (например, на языке PASCAL, в системе программирования DELPHI);
знакомство с практикой применения СУБД Access в рамках практикума на ЭВМ (Базы
данных).
1.1.6. Средства обучения
В ходе проведения лабораторных работ в компьютерном классе используются
следующие пакеты прикладных программ:
 СУБД Access из состава Microsoft Office
 Система программирования Borland Delphi
 СУБД Microsft SQL Server (или др. СУБД, по согласованию)
 Платформа бизнес-анализа ActiveX Trading House (разработка автора)
В качеств примеров приложений баз данных используются программы и базы
данных, разработанные автором и реально используемые в бизнесе, здравоохранении,
промышленности.
Для целей контроля знаний может быть использована тестовая среда QuickTutor
(разработка автора).
1.2. Учебно - тематический план рабочей программы учебной
дисциплины
Объем часов
Аудиторная
работа
№
Название и содержание
разделов, тем, модулей
Общий
Лекции
1
1
2
3
4
2
3
4
Очная форма обучения
Базы данных и модели
10
4
данных.
Введение
в
реляционную модель данных.
Реляционная алгебра
16
4
Инфологическое
20
4
проектирование.
Нормализация данных.
16
4
Лабора Самостоя
торны тельная
работа
е
заняти
я
5
6
Примечания,
дополнительн
ые указания,
методические
материалы,
технические
средства и
др.,
необходимые
для учебной
работы
7
6
4
6
6
8
4
6
9
Физическая организация баз
7
3
данных и СУБД.
6 Язык SQL.
24
6
7 Параллельная работа с базами
9
3
данных. Транзакции.
8 Архитектуры доступа к БД.
8
2
Системные аспекты.
9 Информационные хранилища.
22
4
OLAP-технология.
Полуструктурированная
модель данных.
10 Перспективы
развития
8
2
технологий БД
Итого
130
36
Очно - заочная форма обучения
1 Базы данных и модели
10
1
данных.
Введение
в
реляционную модель данных.
2 Реляционная алгебра
16
2
3 Инфологическое
20
2
проектирование.
4 Нормализация данных.
18
1
5 Физическая организация баз
7
1
данных и СУБД.
6 Язык SQL.
20
2
7 Параллельная работа с базами
9
1
данных. Транзакции.
8 Архитектуры доступа к БД.
10
Системные аспекты.
9 Информационные хранилища.
20
2
OLAP-технология.
Полуструктурированная
модель данных.
10 Перспективы
развития
10
2
технологий БД
Итого
130
14
Заочная форма обучения
1 Базы данных и модели
13
1
данных.
Введение
в
реляционную модель данных.
2 Реляционная алгебра
17
1
3 Инфологическое
26
2
проектирование.
4 Нормализация данных.
18
1
5 Физическая организация баз
8
данных и СУБД.
6 Язык SQL.
18
1
7 Параллельная работа с базами
7
1
данных. Транзакции.
8 Архитектуры доступа к БД.
10
Системные аспекты.
5
4
6
2
8
4
4
4
6
10
2
4
34
60
8
2
4
12
14
2
12
6
2
2
14
6
2
6
2
14
2
6
18
98
12
2
4
14
20
1
16
8
3
14
6
10
10
Информационные хранилища.
OLAP-технология.
Полуструктурированная
модель данных.
10 Перспективы
развития
технологий БД
Итого
9
17
1
16
6
130
6
10
12
108
1.3. Содержание курса лекций
1. Базы данных (БД) и модели данных.
Области приложений баз данных.
Основные функциональные требования к базам данных:
Понятие модели данных.
Ранние модели данных – иерархическая и сетевая.
Введение в реляционную модель данных.
2. Реляционная модель
Отношения – основной структурный элемент.
Операции над отношениями и реляционная алгебра. Язык запросов.
Поддержка целостности.
3.Инфологическое проектирование
Концептуальные модели данных и семантические модели данных.
Анализ предметной области.
Модель “сущность-связь”.
Отношения между таблицами.
Рекурсивное отношение.
Устранение избыточности и неоднозначности при хранении данных.
CASE-средства разработки баз данных.
4. Нормализация данных.
Функциональная зависимость.
Нормальные формы (первая, вторая, третья, Бойса-Кодда), их иерархия и
требования к ним.
Многозначная зависимость.
Четвертая нормальная форма.
Процесс совершенствования модели данных на основе нормализации.
5. Язык SQL
Основные средства манипулирования данными.
Стандарты SQL.
Средства управления и изменения схемы базы данных, определения ограничений
целостности, представлений, привилегий пользователей.
Типы данных.
Определение данных с ограничениями целостности.
Оператор select, вложенные запросы, внешние объединения.
Встроенные функции.
Использование агрегатных функций и группировка.
Задание способа сортировки.
Операторы изменения данных.
SQL на стороне сервера: триггеры и загружаемые процедуры
Встраивание SQL в прикладную программу.
Динамический SQL.
6. Параллельная работа с базами данных. Транзакции, журнализация.
Связь с понятием целостности базы данных и изолированности пользователей.
11
Методы управления транзакциями.
Связь с управлением буферами оперативной памяти.
Методы восстановления баз данных после сбоев.
7. Физическая организация баз данных и СУБД
Способы хранения отношений, индексов, журналов.
Хешированные, индексированные файлы, бинарные деревья, инвертированные
списки.
Структура хранения данных при бесфайловой организации (на примере одной из
СУБД).
8. Архитектуры доступа к БД. Системные аспекты
Двухуровневые модели доступа к базе данных: модель файлового сервера, модель
удаленного доступа, модель сервера баз данных с бизнес-логикой на сервере.
Реализация систем с бизнес-логикой на сервере.
Типы организации серверов баз данных.
Модель с сервером приложений.
Интерфейсы доступа к базам данных.
Распределение данных на нескольких серверах баз данных, репликация данных,
двухфазная фиксация транзакций.
Стандарты SQL.
Язык загружаемых модулей.
9. Информационные хранилища. OLAP-технология..
Различия требований к аналитической и оперативной обработке данных.
Многомерная модель данных (“многомерный куб”).
Многомерные, реляционные и гибридные системы OLAP.
Язык MDX.
Хранилища данных, витрины данных, извлечение данных.
Интеграция информации в хранилище данных.
Полуструктурированная модель данных и язык XML.
10. Перспективы развития баз данных
Перспективы развития БД.
Объектно-ориентированные БД, XML-серверы.
Объединение технологий БД и экспертных систем. Дедуктивные БД.
Гипертекстовые, мультимедийные БД.
1.4. Содержание практических занятий
Подробно содержание практических занятий изложено в учебном пособии “Базы
данных, SQL и все такое. Лабораторный практикум” (на электронном носителе, входит в
состав электронного УМК “Базы данных и технология SQL”, Шехтман В. Е., 2005). Эти
темы могут быть использованы при проведении лабораторных занятий в компьютерном
классе (см. раздел 5.2.3. настоящего УМК).
Работа №1. Знакомство с принципами программирования доступа к базам данных в
Delphi. Работа №2. Разработка первого приложения баз данных.
Работа №3. Разработка утилиты для выполнения SQL-запросов.
Работа №4. Построение инфологической модели базы данных.
Работа №5. Выбор сквозного задания (тема курсового проекта).
Работа №6. Проектирование структуры приложения сквозного задания.
Работа №7. Работа со справочниками.
Работа №8. Формирование твердой копии справочника.
Работа №9. Просмотр справочников иерархической структуры.
Работа №10. Редактирование справочников иерархической структуры.
Работа №11. Разработка программы для ввода основных фактов о предметной области.
Работа №12. Разработка системы регламентированной отчетности.
12
Работа №13. Перенос базы данных на Microsoft SQL Server 2000.
Работа №14. Хранимые процедуры и триггеры.
Работа №15. Разработка системы нерегламентированной отчетности (аналитическая
система) на основе OLAP. Первый подход.
Работа №16. Разработка системы нерегламентированной отчетности на основе OLAP.
Второй подход.
В идеале, в рамках практических занятий следует, разобрав очередную тему, тут же
применить полученные знания к реализации очередной задачи курсового проекта (см.
далее). Таким образом, курсовой проект может рассматриваться как сквозное задание на
все практические занятия курса.
2. Материалы, определяющие порядок и содержание
проведения промежуточных и итоговых аттестаций в
соответствии с требованиями ГОС
Материалы, определяющие порядок и содержание проведения промежуточных и
итоговых аттестаций, соответствуют требованиям ГОС, приказам, распоряжениям и
рекомендациям МО РФ, учебно-методического управления КемГУ и учебнометодического отдела НФИ КемГУ.
2.1. Состав материалов и формы контроля знаний
Контроль знаний студентов проводится по следующей схеме:
 промежуточная аттестация знаний и умений в течение семестра;
 защита курсового проекта;
 аттестация по итогам семестра в форме зачета.
Материалы, определяющие порядок и содержание промежуточных и итоговой
аттестаций, включают:



контрольные вопросы по темам дисциплины, вопросы на зачет;
фонд тестовых заданий по дисциплине в целом;
методические указания к выполнению курсового проекта (см. раздел 5).
2.2. Требования к уровню усвоения программы, формы контроля
В результате изучения курса студенты должны:
знать понятие модели данных; основные модели представления их; типы баз
данных в исторической перспективе; реляционную модель данных; способы
инфологического моделирования; нормализацию как метод оптимизации структур
данных; как организована работа баз данных во времени при наличии нескольких
пользователей (транзакции); основы физической организации баз данных (таблицы и
индексы); ограничения реляционной модели и их преодоление в логической модели
данных и знаний;
уметь применять соответствующие методы, технологии и инструменты для
создания образцов информационных систем в т. ч. разработать инфологическую модель;
преобразовать ее в даталогическую модель с одновременной оптимизацией структур
данных с помощью нормализации; формировать запросы на языке SQL с представлением
о том, как они будут реализованы ядром СУБД (перевод их алгебраическую форму);
13
использовать универсальные интерфейсы доступа к базе данных из прикладной
программы для обеспечения независимости о платформы;
иметь представление о развитии реляционной модели (объектно-реляционная
модель), полуструктурированных данных; аналитических системах и интегрированных
хранилищах данных; о языках описания знаний и о методах разработки интеллектуальных
информационных системах; о сфере применения интеллектуальных систем.
Знания итогово оцениваются при защите курсового проекта и сдаче экзамена. Умения
итогово оцениваются при защите курсового проекта.
Защита курсового проекта должна осуществляться всеми членами проектной команды
(если она есть). Оценка зависит от качества проекта базы данных и разработанного
приложения, отчета, наличия подготовленной презентации (последнее в меньшей
степени), ответа на дополнительные вопросы. Обязательные составляющие курсового
проекта:
 Словесное описание предметной области;
 Инфологическая модель данных;
 Даталогическая модель;
 Обсуждение степени нормальности предложенных структур;
 Физическая модель.
Дополнительно, курсовой проект может включать следующие разделы:
 диаграммы использования на языке UML для объяснения условий применения
и функций разработанного прототипа системы;
 диаграммы классов и диаграммы компонентов на языке UML для объяснения
устройства программной системы;
 демонстрационный ролик (формата PowerPoint) для объяснения целей создания,
путей решения и результатов разработки.
Программное приложение должно содержать следующие необходимые компоненты
 модуль для работы со справочной информацией;
 модуль формирования твердой копии справочников;
 модуль описания данных;
 модуль ввода фактических данных;
 модуль формирования отчета.
“Отлично” выставляется при наличии безукоризненно выполненных всех
составных частей курсового проекта и при условии демонстрирования полного владения
предметом в ходе ответа на связанные с тематикой проекта теоретические и практические
вопросы.
“Хорошо” может быть выставлено при наличии всех указанных составных частей
курсового проекта в случае некоторых недочетов или неполноты описания.
«Удовлетворительно» выставляется студенту, показавшему фрагментарный,
разрозненный характер знаний и умений, выразившийся в неполном составе частей
проекта, неточном и неполном описании соответствующих разделов проекта. При этом
владение основными разделами учебной программы, необходимыми для дальнейшего
обучения не должно вызывать сомнения – студент должен применять их по образцу в
стандартной ситуации.
Знания студента положительно оцениваются на экзамене при условии наличия
защищенного курсового проекта и достаточно полного и точного ответа на вопросы.
14
Возможно проведение зачета с использованием компьютерной тестовой системы,
включенной в состав электронного УМК по дисциплине. В этом случае ”отлично”
выставляется при наборе не менее 80 баллов.
2.3. Примерные вопросы к экзамену
1.
Области приложений СУБД.
2.
Интерфейсы СУБД для обеспечения интерактивного доступа к данным и
создания программ.
3.
Языки запросов, запросы через формы, генераторы отчетов, языки быстрого
прототипирования приложений.
4.
Жизненный цикл БД.
5.
Согласованное хранение независимых наборов данных.
6.
Независимый от прикладной задачи интерфейс по управлению данными.
7.
Ограничение прав доступа.
8.
Управление транзакциями, журнализация изменений базы данных,
восстановление после сбоев.
9.
Управление данными во внешней памяти, управление буферами
оперативной памяти,
10.
Концептуальные модели данных и семантические модели данных.
Иерархическая модель данных, сетевая модель данных.
11.
Анализ
предметной
области.
Даталогическое
проектирование.
Инфологическое моделирование, модель “сущность-связь”. Отношения между
таблицами, рекурсивное отношение.
12.
Устранение избыточности и неоднозначности при хранении данных.
13.
Реляционная алгебра и реляционное исчисление.
14.
Нормальные
формы
отношений.
Функциональные
зависимости,
декомпозиция отношений, транзитивные зависимости.
15.
Способы хранения отношений, индексов, журналов.
16.
Хешированные, индексированные файлы, бинарные деревья,
инвертированные списки.
17.
Структура хранения данных при бесфайловой организации (на примере
одной из СУБД).
18.
Понятие транзакции. Журнализация. Связь с понятием целостности базы
данных и изолированности пользователей.
19.
Методы управления транзакциями. Связь с управлением буферами
оперативной памяти.
20.
Методы восстановления баз данных после сбоев.
21.
Язык SQL. Основные средства манипулирования данными. Стандарты
SQL.
22.
Средства управления и изменения схемы базы данных, определения
ограничений целостности, представлений, привилегий пользователей.
23.
Типы данных.
24.
Определение данных с ограничениями целостности.
25.
Оператор select, вложенные запросы, внешние объединения.
Встроенные функции.
26.
Использование агрегатных функций и группировка. Задание способа
сортировки.
27.
Операторы изменения данных.
28.
SQL на стороне сервера: триггеры и загружаемые процедуры
29.
Встраивание SQL в прикладную программу. Динамический SQL.
30.
Двухуровневые модели доступа к БД: модель файлового сервера, модель
удаленного доступа, модель сервера БД.
15
31.
Типы организации серверов БД
32.
Модель сервера приложений.
33.
Распределение данных на нескольких серверах БД, репликация данных,
двухфазная фиксация транзакций.
34.
Информационные хранилища. OLAP-технология.
35.
Различия требований к аналитической и оперативной обработке данных.
36.
Многомерная модель данных (“многомерный куб”). Многомерные,
реляционные и гибридные системы olap
37.
Хранилища данных, витрины данных, извлечение данных.
38.
Объектно-ориентированные БД. XML-серверы.
39.
Объединение технологий БД и экспертных систем. Дедуктивные БД.
Гипертекстовые, мультимедийные БД.
2.4. Тест по курсу (итоговая оценка знаний)
Вопросы теста, а также автоматизированная система тестирования и оценки знаний
QuickTutor (разработка автора) приведены в электронном УМК “Базы данных и
технология SQL”, Шехтман В. Е., 2005. Образцы вопросов теста, входящие в курс
тестирования на основе автоматизированной системы, представлены ниже. Они даны в
нотации, воспринимаемой компилирующим модулем тестовой системы.
Вопрос т:О Б:100
ER-диаграмма это:#
диаграмма производительности базы данных#
диаграмма “сущность – связь” #+
диаграмма потоков данных#
функциональная диаграмма #
##
Вопрос т:О Б:100
База данных, основанная на модели “сущность-связь”, представленной ниже,
Зарплата по штатному расписанию
Отделы
Месяц
Сумма
Отдел
Числится в
Сотрудники
ФИО
Дата рожд.
Работает над
Зарплата за проект
Месяц
Сумма
Проекты
Проект
НЕ позволит ответить на вопрос#
Какую суммарную зарплату получили сотрудники отдела Y за месяц Z за работу в отделе
(не за участие в проектах)?#
Сколько денег выплачено сотрудникам, работавшим над проектом X за месяц Z?#
Сотрудники каких отделов работают над проектом X?#
Сколько денег заработали сотрудники отдела Y работая над проектом X за месяц Z? #+
##
Вопрос т:О Б:100
Диаграмма “сущность-связь”, представленная ниже, является
16
Отделы
Отдел
Проекты
Сотрудники
ЗарплатаПоШтатномуРасписанию
Проект
ФИО
Месяц
Сумма
ЗарплатаЗаПроект
Зарплата
#
некорректной, т. к. набор сущностей Сотрудники связан сразу с четырьмя другими
наборами сущностей.#
некорректной, т. к. наборы сущностей Проекты и Сотрудники связаны отношением
“многие ко многим”.#
некорректной, т. к. набор сущностей Отделы связан только с набором сущностей
Сотрудники, хотя “Зарплата по штатному расписанию” выплачивается сотруднику в связи
с его работой в конкретном отделе#
корректной. #+
##
Вопрос т:О Б:100
Как лучше всего описать структуру базы данных, которую разрабатывает Ваша проектная
команда, для каждого из ее членов?#
С помощью карты зависимостей данных #
С помощью диаграммы использования (Use case) #
С помощью ER-диаграммы #+
Путем формирования словаря данных #
Путем определения отношений и зависимостей между ними #
##
Вопрос т:О Б:100
К какому типу связи относится связь между сущностями A и C?#
Один к одному#
Ни одного к одному#
Один ко многим#
Многие к одному#+
Многие ко многим#
##
Вопрос т:О Б:100
Что из следующего является начальной стадией в проектировании базы данных?#
Анализ предметной области#+
Определение системных требований #
Определение структур данных#
Определение ограничений #
Выявление рисков #
17
##
Вопрос т:О Б:100
Что может означать обязательная связь типа “один к одному” между таблицами?#
Модель не может быть реализована физически #
Требуются большее количество атрибутов #
Таблицы неправильно проиндексированы #
Следует объединить сущности с такой связью в одну #+
Требуется большее число сущностей #
##
Вопрос т:О Б:100
Что может означать необязательная связь типа “один к одному” между таблицами?#
Эта связь реализует отношение наследования одной таблицы от другой #+
Такая связь не имеет смысла #
Таблицы неправильно проиндексированы #
Следует объединить сущности с такой связью в одну #
Требуется большее число сущностей #
##
Вопрос т:О Б:100
Имеются две таблицы: A(ФИО, ГодРожд, Адрес) и B(ФИО, ГодРожд, Адрес,
КатегорияВодителя). В каком отношении они находятся друг к другу?#
В отношении наследования, причем наследником является таблица B #+
В отношении наследования, причем наследником является таблица A #
В отношении “один ко многим” #
В отношении “многие ко многим” #
В отношении “многие к одному” #
##
Вопрос т:О Б:100
Имеются две таблицы: A(ID, ФИО, ГодРожд, Адрес) и B(ID, КатегорияВодителя)
Какую зависимость они реализуют?#
Зависимость наследования, причем таблица B наследует свойства таблицы A #+
Зависимость наследования, причем таблица A наследует свойства таблицы B #
В отношении “один ко многим” #
В отношении “многие ко многим” #
В отношении “многие к одному” #
##
Вопрос т:О Б:100
Каким образом следует реализовать связи между наборами сущностей СТУДЕНТ(ФИО,
ДатаРожд, Адрес), ДИСЦИПЛИНА(Название), ПРЕПОДАВАТЕЛЬ(ФИО, Факультет)? #
Ввести еще один набор сущностей ЭКЗАМЕН(ФИОСтудента, ФИОПреподавателя,
НазваниеДисциплины, Дата, Оценка) #+
Ввести еще один набор сущностей ЭКЗАМЕН(ФИОСтудента, ФИОПреподавателя,
НазваниеДисциплины) а атрибуты Дата и Оценка разместить среди ранее определенных
наборов сущностей#
Набор сущностей ДИСЦИПЛИНА расширить атрибутами, характеризующими понятие
“экзамен по дисциплине”#
Атрибут Оценка добавить в набор сущностей СТУДЕНТ, атрибут ДатаЭкзамена добавить
в наборы сущностей ДИСЦИПЛИНА и ПРЕПОДАВАТЕЛЬ#
18
##
Вопрос т:О Б:100
Каким образом лучше реализовать связи между наборами сущностей РЕЙС(Номер, Дата),
САМОЛЕТ(Номер, Тип), НАПРАВЛЕНИЕ(Номер, АэропортНазначения),
ПАССАЖИР(ФИО)? #
Ввести еще один набор сущностей БИЛЕТ(ФИОПассажира, НомерРейса,
НомерТипаСамолета, НомерНаправления) #
Сделать такие преобразования: ввести набор сущностей БИЛЕТ(ФИОПассажира,
НомерРейса) а набор сущностей РЕЙС расширить до следующего: РЕЙС(Номер, Дата,
НомерНаправления, НомерТипаСамолета) #+
##
Вопрос т:О Б:100
Можно ли провести нормализацию таблиц базы данных на уровне инфологической
модели? #
Можно #+
Нельзя, т. к. при нормализации имеют дело с отношениями, а в инфологической модели
есть только наборы сущностей #
Нельзя #
Если инфологическая модель включает наборы сущностей, имена которых совпадают с
именами будущих таблиц базы данных, то можно (если очень хочется) #
##
Вопрос т:М Б:100
Укажите все верные высказывания: #
Даталогическая модель включает типы данных, а инфологическая нет #+
В даталогической модели определены первичные ключи, а в инфологической не
определены #
В даталогической модели обязательно указано, как реализуются связи типа “многие ко
многим” а в инфологической модели это не требуется #+
##
Вопрос т:М Б:100
Укажите все верные высказывания: #
Даталогическая модель зависит от СУБД #
Даталогическая модель не зависит от СУБД #+
Даталогическая модель содержит определения индексов #
Даталогическая модель не содержит определения индексов, т. к. они не значимыми для
отражения логических аспектов модели #+
##
Вопрос т:М Б:100
Укажите все верные высказывания: #
Физическая модель зависит от СУБД #+
Физическая модель не зависит от СУБД #
Физическая модель не содержит определения индексов #
Физическая модель содержит определения индексов, т. к. они важны для обеспечения
приемлемого быстродействия #+
##
Вопрос т:О Б:100
Результатом полной нормализации универсального отношения
19
Счета <Город, Банк, Клиент, АдресКлиента, №счета, Сумма, Валюта>
является его декомпозиция на следующие отношения (с учетом оптимизации структуры)#
<Клиент, КодКлиента, АдресКлиента>
<Город, КодГорода>
<Банк, КодБанка>
<КодГорода, КодБанка>
<КодКлиента, №счета>
<№счета, Сумма>#
<Клиент, КодКлиента, АдресКлиента>
<Город, КодГорода>
<КодГорода, Банк>
<КодКлиента, №счета, Банк>
<№счета, Банк, Сумма>#
<Клиент, КодКлиента, АдресКлиента>
<Город, КодГорода>
<Банк, КодБанка>
<КодГорода, КодБанка>
<КодКлиента, №счета, КодБанка>
<№счета, КодБанка, Сумма>#+
##
Вопрос т:О Б:100 №:1 П:2
В отношении ЗВЕРИ со схемой <ЗООПАРК, ЖИВОТНОЕ, ЕСТЕСТВЕННАЯ ЗОНА
ОБИТАНИЯ> атрибут ЕСТЕСТВЕННАЯ ЗОНА ОБИТАНИЯ #
функционально полно зависит от совокупности атрибутов ЗООПАРК, ЖИВОТНОЕ#
функционально полно зависит от ЖИВОТНОЕ #+
функционально полно зависит от ЗООПАРК#
не зависит функционально полно ни от какой совокупности атрибутов отношения.#
##
Вопрос т:О Б:100 №:2
Отношение ЗВЕРИ, схема которого <ЗООПАРК, ЖИВОТНОЕ, ЕСТЕСТВЕННАЯ
ЗОНА ОБИТАНИЯ> находится#
в первой нормальной форме #+
во второй нормальной форме #
в третьей нормальной форме#
в нормальной форме Бойса-Кодда.#
##
Вопрос т:О Б:100
Отношение ПРЕДПРИЯТИЯ со схемой
<ГОРОД, УПРАВЛЯЮЩАЯ КОМПАНИЯ, ПРЕДПРИЯТИЕ, ТОВАР>
можно нормализовать, выполнив его декомпозицию на отношения#
<ГОРОД, ПРЕДПРИЯТИЕ>
<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ПРЕДПРИЯТИЕ>
<ПРЕДПРИЯТИЕ, ТОВАР>#+
<ГОРОД, ПРЕДПРИЯТИЕ>
<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ГОРОД>
<ПРЕДПРИЯТИЕ, ТОВАР>#
<ГОРОД, ТОВАР>
<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ПРЕДПРИЯТИЕ>
<ПРЕДПРИЯТИЕ, ТОВАР>#
20
<ГОРОД, ПРЕДПРИЯТИЕ>
<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ТОВАР>
<ПРЕДПРИЯТИЕ, ТОВАР>#
##
Вопрос т:О Б:100
A
1
2
3
4
5
6
7
B
Гвозди
Гвозди
Гвозди
Шурупы
Шурупы
Доски
Доски
C
Молоток
Молоток
Молоток
Отвертка
Отвертка
Рубанок
Рубанок
Отношение, изображенное в таблице, имеет первичный ключ, основанный на атрибуте A.
Какой нормальной форме противоречат данные в отношении?#
1NF#
2NF#
3NF#+
4NF#
5NF#
##
Вопрос т:О Б:100
A
1
1
1
2
2
B
Бананы
Фейхоа
Помела
Мандарины
Апельсины
C
Южная Америка
Южная Америка
Южная Америка
Африка
Африка
Отношение, изображенное в таблице, имеет первичный ключ, основанный на атрибутах A
и B. Какой нормальной форме противоречат данные в отношении?#
1NF#
2NF#+
3NF#
4NF#
5NF#
##
Вопрос т:О Б:100
Требуется устранить избыточность в проекте базы данных. Это делается в рамках
процесса, который можно назвать: #
Планирование оптимизации #
Определение требований #
Устранение ошибок #
Логическое проектирование #+
Физическое проектирование #
##
21
Вопрос т:О Б:100
Укажите наиболее правильное описание степени нормализации отношения со схемой
ПРОИЗВОДИТЕЛИ <ПРЕДПРИЯТИЕ, ТОВАР, НАЧАЛЬНИК_ЦЕХА> :#
Отношение находится в третьей нормальной форме, т. к. НАЧАЛЬНИК_ЦЕХА находится
в полной функциональной зависимости от ключа и не зависит ни от какого другого
неключевого поля (т. к. само и является единственным неключевым). Но отношение не в
нормальной форме Бойса-Кодда, т. к. кроме того, имеется функциональная зависимость
атрибута ПРЕДПРИЯТИЕ от атрибута НАЧАЛЬНИК_ЦЕХА, который не является
суперключом (или ключом-кандидатом).#+
Отношение находится во второй нормальной форме т. к. атрибут НАЧАЛЬНИК_ЦЕХА
функционально полно зависит от ключа отношения#
Отношение очевидно удовлетворяет условиям первой нормальной формы. Кроме того,
оно удовлетворяет требованиям второй нормальной формы. Более того, отношение
находится в третьей нормальной форме т. к. единственный неключевой атрибут
функционально полно зависит от первичного ключа. С другой стороны, атрибут
ПРЕДПРИЯТИЕ функционально полно зависит от атрибута НАЧАЛЬНИК_ЦЕХА,
который, следовательно, является ключом-кандидатом отношения.#
Отношение находится во второй нормальной форме т. к. ключ отношения составлен из
двух атрибутов.#
##
Вопрос т:М Б:100
Выберите среди перечисленных функций те, которые характерны для СУБД (несколько
ответов). #
Обеспечить анализ данных для принятия верных управленческих решений.#
Обеспечить согласованное хранение независимых наборов данных. #+
Извлекать данные с помощью простого языка запросов без необходимости описывания
сложных алгоритмов доступа и переработки данных. #+
Осуществлять удобное для пользователя графическое представление результатов запроса
к базе данных.#
Обеспечить независимый от прикладной задачи интерфейс по управлению данными. #+
##
Вопрос т:М Б:100
Выберите среди перечисленных функций те, которые характерны для СУБД (несколько
ответов). #
Обеспечить
возможность
одновременного
доступа
к
данным
нескольким
пользователям.#+
Осуществлять ограничение прав пользователей с целью обеспечения безопасности и
секретности данных. #+
Обеспечить надежное хранение данных даже не смотря на возможность сбоя в программе
или технических средствах. #+
Обеспечить удобный интерфейс с человеком-оператором при работе с приложением баз
данных.#
Обеспечить возможность формирования “твердой” копии результата запроса к базе
данных. #
##
Вопрос т:М Б:100
Какие утверждения относительно системы управления файлами (СУФ) верны? (несколько
ответов)#
22
СУФ (в отличии от СУБД) не может обеспечить высокопроизводительный поиск #+
СУФ (в отличии от СУБД) не способна выполнять сложные запросы, сформулированные
на высокоуровневом языке запросов. #+
СУФ (в отличии от СУБД) не поддерживает транзакции #+
СУФ (в отличии от СУБД) не обеспечивает многопользовательского доступа #+
СУФ (в отличии от СУБД) не может предоставить единый интерфейс, независимый от
прикладной задачи.#
##
Вопрос т:М Б:100
Что следует отнести к преимуществам централизованного подхода к хранению и
управлению данными? (Несколько ответов)#
поддержка целостности данных #+
сокращение избыточности #+
возможность общего одновременного доступа к данным #+
возможность устранения противоречивости #+
##
Вопрос т:М Б:100
На чем основаны принципиальные различия в требованиях к структуре данных для систем
OLTP (оперативной обработки) и систем OLAP (аналитической обработки)? Выберите
несколько правильных ответов.#
В OLTP необходимо обеспечить выполнение многих мелких транзакций по изменению
данных а в OLAP – немного длинных транзакций, читающих данные #+
В OLTP приходится использовать индексы а в OLAP нет#
В OLTP необходимо обеспечить выполнение параллельных изменений в базе данных а в
OLAP как правило нет #+
В OLTP используется реляционная модель данных а в OLAP “многомерная” модель
данных, хотя не всегда для хранения – иногда только для представления данных #+
Для OLTP достаточно обычного сервера баз данных а для OLAP необходим сервер,
основанный на “многомерной” модели данных #
Для OLTP необходимо обеспечить запись информации с максимальной подробностью в
то время как в OLAP обычным является интерес к агрегированным данным #+
##
Вопрос т:О Б:100
Какое утверждение относительно “хранилищ данных” НЕВЕРНО?#
Они, в отличие от обычных баз данных, предназначены для надежного хранения наиболее
важной информации, объем которой превышает возможности обычных СУБД. #+
Они предназначены для интегрирования информации из разных источников в единую
базу данных.#
Они позволяют проводить “разработку” данных с целью выявления закономерностей. #
Они не применяются для реализации систем оперативного учета.#
##
Вопрос т:О Б:100
Что из перечисленного более всего повышает вероятность тупиков в системах OLTP?#
Использование триггеров#
Использование хранимых процедур#
Использование оптимистической блокировки#
Пользовательский ввод в ходе выполнения транзакции#+
Использование неявных транзакций#
23
##
Вопрос т:О Б:100
При каких условиях следует использовать денормализацию?#
При проектировании базы данных, которая будет работать в условиях частых обновлений
#
При проектировании базы данных для учета операций на торговом складе, которые
состоят из очень коротких и частых обновлений#
При проектировании базы данных для системы поддержки принятия решений#+
При проектировании базы данных для OLTP-системы#
##
Вопрос т:О Б:100
Что из перечисленного записывается в журнал транзакций?#
Момент начала транзакции #
ID пользователя, инициировавшего транзакцию #
Сумма транзакции (в валюте) #
Признаки начала и окончания транзакции #+
##
Вопрос т:О Б:100
Имеется прикладная система, использующая СУБД. Для этой системы одинаково важны
производительность и надежность. Сервер, на котором располагается база данных, имеет
2 процессора, ОЗУ размером 512Мгб и дисковую подсистему с RAID 5. На этом же
компьютере развернут WEB-сервер. Что следует в первую очередь предпринять для того,
чтобы уменьшить время реакции прикладной системы? #
Увеличить размер ОЗУ #
Перенести WEB-сервер на другой компьютер #+
Установить более производительную системную шину#
Перезапустить сервис СУБД #
Установить более производительные процессоры#
##
Вопрос т:О Б:100
Какой тип триггеров срабатывает первым – сразу после издания SQL - запроса?#
AFTER#
IN#
BEFORE #+
DURING #
BETWEEN #
##
Вопрос т:О Б:100
Предотвращение какой проблемы позволяет избежать механизм блокировок СУБД?#
Срабатывания триггеров#
Возникновения тупиков#
Применения долго выполняющихся запросов#
Нарушения целостности данных за счет потери изменений#+
Несанкционированного доступа к колонкам и таблицам#
##
Вопрос т:О Б:100
24
Что из следующего НЕ характеризует блокировку на уровне записи по сравнению с
блокировкой страницы?#
Она уменьшает конкуренцию между параллельными процессами за доступ к данным #
Она увеличивает производительность СУБД #+
Она допускает увеличение количества блокировок #
Она уменьшает вероятность тупика #
Она поддерживает более высокий уровень параллелизма #
##
Вопрос т:О Б:100
В базе данных о персонале предприятия имеется таблица о сотрудниках, индексированная
по атрибуту ФАМИЛИЯ. В какой ситуации выгодно иметь такой индекс?#
Когда большинство записей содержат NULL в поле ФАМИЛИЯ #
Когда большинство записей содержат различные и уникальные значения в поле
ФАМИЛИЯ #+
Когда большинство записей содержат одинаковые значения в поле ФАМИЛИЯ #
Нет особых условий, при которых это выгодно #
##
Вопрос т:О Б:100
Как известно, сетевая модель данных позволяет установить связи между объектами,
описанными в базе данных. Будем называть связываемые объекты исходным и связанным.
Как осуществляется связывание?#
В явном виде с помощью адресных ссылок на связанный объект. При этом ссылки
хранятся в исходном объекте.#
В явном виде с помощью адресных ссылок на исходный объект. При этом ссылки
хранятся в связанном объекте.#
Неявно. Адресных ссылок нет, связь осуществляется по значению атрибутов объектов.#
В явном виде с помощью адресных ссылок в обоих направлениях: ссылки на связанный
объект хранятся в исходном объекте; ссылки на исходный объект хранятся в связанном
объекте.#+
##
Вопрос т:О Б:100
Имеется база данных, основанная на сетевой модели. Необходимо осуществить
связывание объектов, хранимых в базе данных, по типу “многие ко многим”. Для этого
следует#
для первого объекта явно задать ссылки на все связанные с ними записи другого объекта#
для обоих объектов явно задать ссылки на все связанные с ними записи другого объекта#+
не нужно предпринимать никаких дополнительных усилий#
приходится вводить третий объект, роль которого заключается в хранении ссылок#
##
Вопрос т:О Б:100
В отношении
Продукт
Поставщик
Цена за ящик
Бананы
Глобус
150
Помидоры
Глобус
230
Бананы
Центрпродсервис
170
Лук
Плодовощторг
50
колонка Продукт является (с точки зрения реляционной модели)#
кортежем#
25
доменом#
атрибутом#+
множеством#
##
Вопрос т:О Б:100
Два отношения со схемами
Налогоплательщик <ИНН, ФИО>
и
Доход <ИНН, Источник дохода, Дата, Сумма дохода >
связаны между собой. Какой вид связи между ними существует?#
один к одному#
один ко многим#+
многие ко многим#
многие к одному#
##
Вопрос т:О Б:100
Таблица, приведенная ниже, является
Улица
Дом, квартира
Металлургов
Курако
15, 77
11а, 10
Количество
комнат
3
2
#
отношением#
совокупностью атрибутов#
упорядоченным набором доменов#
просто набором строк #+
##
Вопрос т:О Б:100
Множество всех возможных цветовых оттенков автомобилей является (с точки зрения
реляционной модели)#
доменом#+
перечнем#
отношением#
кортежем#
##
Вопрос т:О Б:100
Реляционная модель позволяет установить связи между двумя отношениями по типу
“один к одному” или “один ко многим”#
в явном виде с помощью ссылок на записи из подчиненного отношения. Ссылки хранятся
в записях основного отношения.#
неявно, на основе значений атрибутов, по которым происходит связывание #+
в явном виде с помощью ссылок на записи из основного отношения. Ссылки хранятся в
записях подчиненного отношения.#
##
Вопрос т:О Б:100
Возможно ли при помощи реляционной модели данных описать иерархическую
структуру?#
26
нет, не возможно#
зависит от решаемой задачи#
да, возможно #+
##
Вопрос т:О Б:100
Возможно ли при помощи реляционной модели данных описать сетевую структуру?#
нет, не возможно#
зависит от решаемой задачи#
да, возможно#+
##
Вопрос т:О Б:100
Для осуществления связывания двух отношений между собой по типу “многие ко
многим” в реляционной модели#
особых усилий не требуется – связывание происходит неявно на основе значений
атрибутов, по которым устанавливается связь#
следует для каждой записи одного отношения явно перечислить все связанные с ней
записи другого отношения#
не нужно предпринимать никаких дополнительных усилий#
приходится вводить третье отношение#+
##
Вопрос т:О Б:100
Что является базовым (или основным) множеством реляционной алгебры#
множество доменов#
множество атрибутов#
множество отношений #+
множество связей между отношениями#
##
Вопрос т:О Б:100
Действие операции проектирования отношения заключается в#
переименовании атрибутов исходного отношения#
получении декартова произведения данного отношения на самого себя#
получении нового отношения, содержащего лишь кортежи, удовлетворяющие условию
фильтрации, при этом дубликатные кортежи удаляются#
получении нового отношения, содержащего только некоторые из атрибутов исходного,
при этом дубликатные кортежи удаляются. #+
##
Вопрос т:О Б:100
Даны отношения
Предметы < Код Предмета, Наименование >
и
Группы < Группа, Код Предмета >
Какое выражение позволяет определить предметы, имеющиеся в учебных программах
групп ПИЭ или ПМИ?
(В задании приняты следующие обозначения:
joinусловие
- операция условного соединения отношений
πимена атрибутов
- операция проектирования отношения на его атрибуты
σусловие фильтрации - операция горизонтальной фильтрации отношения
27

\

- операция декартова произведения отношений
- операция взятия разности двух отношений
- операция объединения двух отношения)#
πГруппы.КодПредмета ( Группы )#
R1
= σГруппы.Группа = ‘ПИЭ’ OR Группы.Группа = ‘ПМИ’ (Предметы  Группы)
R2
= R1 \ (Предметы joinПредметы.КодПредмета = Группы.КодПредмета Группы)#
R1
= Предметы joinПредметы.КодПредмета = Группы.КодПредмета Группы
R2
= πR1.Наименование (σR1.Группа = ‘ПИЭ’ OR R1.Группа = ‘ПМИ’ R1 ) #+
πПредметы.Наименование (Предметы  Группы) #
##
Вопрос т:М Б:100
Что следует задать для реализации ссылочной целостности в реляционной базе данных?
(несколько ответов)#
Ограничение целостности на уровне отношения. #
Ограничение внешнего ключа. #+
Ограничение первичного ключа. #+
Ограничение на значение атрибута отношения. #
##
Вопрос т:О Б:100
Что следует задать для обеспечения того, чтобы внешний ключ в ссылающейся таблице
всегда ссылался бы на конкретную запись в таблице, на которую ссылается?#
Соответствующий тип данных#
Связь #
Ключ #
Ограничение #+
Триггер #
##
Вопрос т:О Б:100
Даны таблицы
R1 <Код_товара, Имя_товара>
R2 <Код_поставщика, Имя_поставщика>
R3 <Код_товара, Код_поставщика, Кол-во_товара>
Какой запрос позволит включить в результирующее множество все товары из справочника
товаров R1 а не только те, которые действительно поставлялись? #
SELECT R3.Кол-во_товара, R1.Имя_товара, R2.Имя_поставщика
FROM (R3 INNER JOIN R1 ON R3.Код_товара = R1.Код_товара)
INNER JOIN R2 ON R3.Код_поставщика = R2.Код_поставщика#
SELECT R3.Кол-во_товара, R1.Имя_товара, R2.Имя_поставщика
FROM (R1 LEFT OUTER JOIN R3 ON R3.Код_товара = R1.Код_товара)
LEFT OUTER JOIN R2 ON R3.Код_поставщика = R2.Код_поставщика#+
SELECT R3.Кол-во_товара, R1.Имя_товара, R2.Имя_поставщика
FROM R3, R1, R2
WHERE R3.Код_товара = R1.Код_товара AND
R3.Код_поставщика = R2.Код_поставщика#
SELECT R3.Кол-во_товара, R1.Имя_товара, R2.Имя_поставщика
FROM (R1 RIGHT OUTER JOIN R3 ON R3.Код_товара = R1.Код_товара)
INNER JOIN R2 ON R3.Код_поставщика = R2.Код_поставщика#
##
28
Вопрос т:О Б:100
Даны таблицы
R1 <Студент, Дисциплина, Oценка>
R2 <Студент, Группа>
R3 <Группа, Дисциплина>
Какой SQL-запрос позволит перечислить множество всех дисциплин ВУЗа?#
SELECT R1.Дисциплина FROM R1#
SELECT R3.Дисциплина FROM R3#
SELECT DISTINCT R3.Дисциплина FROM R3 #+
SELECT R3.Дисциплина FROM R3 ORDER BY R3.Дисциплина#
##
Вопрос т:О Б:100
Для таблиц
R1 <Студент, Дисциплина, Oценка>
R2 <Студент, Группа>
R3 <Группа, Дисциплина>
укажите SQL-запрос, позволяющий сформировать множество дисциплин, по которым
была получена хотя бы одна положительная оценка.#
SELECT R1.Дисциплина FROM R1 WHERE R1.Оценка>3#
SELECT DISTINCT R1.Дисциплина, R3.Группа FROM R1, R3
WHERE R3.Дисциплина=R1.Дисциплина
AND R1.Оценка>3 AND R1.Оценка IS NOT NULL#
SELECT R1.Дисциплина, COUNT(R1.Оценка) FROM R1
WHERE R1.Оценка>3
HAVING COUNT(R1.Оценка)>0#
SELECT DISTINCT R1.Дисциплина FROM R1 WHERE R1.Оценка>3#+
##
Вопрос т:О Б:100
Пусть таблица T (a, b, c, d) содержит 100 записей и на основе поля b создан индекс.
Сколько записей придется просканировать СУБД при выполнении запроса
SELECT a, b, c, d FROM T WHERE a=5 ?#
0#
1#
5#
100#+
От 1 до 100 (заранее не известно)#
##
Вопрос т:О Б:100
Что такое хранимая процедура?#
Заранее скомпилированная совокупность запросов SQL и операторов управления
вычислениями#+
Заранее скомпилированная совокупность триггеров #
Заранее скомпилированная программа на языке Java #
Заранее скомпилированный объектный файл #
Заранее скомпилированная .dll библиотека #
##
29
Вопрос т:О Б:100
Требуется написать SQL-запрос, который должен возвращать все записи из левой таблицы
соединения, независимо от того, имеются ли соответствующие им записи в правой
таблице соединения. Какой из типов соединения следует использовать?#
FULL INNER JOIN #
FULL OUTER JOIN #
LEFT INNER JOIN #
LEFT OUTER JOIN #+
RIGHT JOIN #
##
Вопрос т:О Б:100
Что из перечисленного входит в стандарт SQL-92 в качестве расширения языка?#
Шифрование ключей #
Работа с сетевыми сокетами #
Управление потоками #
Графический интерфейс #
Операторы IF/THEN, FOR, DO/WHILE#+
##
Вопрос т:О Б:100
Как лучше всего поступить для изменения типа атрибута таблицы из INTEGER во
FLOAT, если таблица содержит миллионы записей?#
Использовать команду ALTER TABLE #+
Ничего делать не надо т. к. тип FLOAT не отличается от типа INTEGER по способу
хранения #
Создать архив базы данных, уничтожить таблицу, создать таблицу с измененным типом
атрибута, восстановить базу данных из архива #
Создать новую таблицу с измененным типом атрибута, скопировать в нее данные из
старой таблицы, уничтожить старую таблицу, дать новой таблице имя старой таблицы #
Переименовать старую колонку, создать новую колонку правильного типа, скопировать
данные старой колонки в новую#
##
Вопрос т:О Б:100
Какое новое свойство поддерживается в стандарте SQL-92? #
Агрегирование данных #
Настройка производительности #
Хранимые процедуры #+
Контрольные точки в ходе протоколирования #
Индексы на основе сбалансированных деревьев (B-trees) #
##
Вопрос т:О Б:100
Пусть таблица T (a, b, c, d) содержит 100 записей и на основе поля b создан индекс. Кроме
того, на поле a наложено условие уникальности. Сколько записей придется
просканировать СУБД при выполнении запроса
SELECT a, b, c, d FROM T WHERE a=5 ?#
0#
1#
5#
100#
30
От 1 до 100 (заранее не известно)#+
##
Вопрос т:М Б:100
Какие SQL-операторы имеют правильный синтаксис (несколько ответов)?#
CREATE TABLE TBL (FL1 CHAR(10), FL2 INT)#+
CREATE TABLE TBL (FL1 CHAR(10) NOT NULL, FL2 INTEGER DEFAULT 10)#+
CREATE TABLE TBL (FL1 CHAR(10), FL2 INTEGER, DEFAULT 10)#
##
Вопрос т:О Б:100
Даны таблицы
R1 <Код_товара, Имя_товара>
R2 <Код_поставщика, Имя_поставщика>
R3 <Код_товара, Код_поставщика, Кол-во_товара>
Какой запрос позволит указать товар (товары), разовая поставка которого была
наибольшей за всю историю поставок? #
SELECT R1.Имя_товара FROM R1
LEFT JOIN R3 ON R3.Код_товара=R1.Код_товара
WHERE R3.Кол-во_товара = (SELECT MAX(R3.Кол-во_товара) FROM R3)#+
SELECT R1.Имя_товара FROM R1
LEFT JOIN R3 ON R3.Код_товара=a.Код_товара
WHERE R3.Кол-во_товара = (SELECT SUM(R3.Кол-во_товара) FROM R3)#
SELECT R1.Имя_товара FROM R1
LEFT JOIN R3 ON R3.Код_товара=a.Код_товара
WHERE MAX(R3.Кол-во_товара) = (SELECT R3.Кол-во_товара FROM R3)#
##
Вопрос т:О Б:100
Даны таблицы
R1 <Код_товара, Имя_товара>
R2 <Код_поставщика, Имя_поставщика>
R3 <Код_товара, Код_поставщика, Кол-во_товара>
Какой запрос позволит сформировать множество поставщиков, осуществивших хотя бы
одну поставку бананов?#
SELECT R2.Имя_поставщика FROM R2
LEFT JOIN R3 ON R3.Код_поставщика=R2.Код_поставщика
LEFT JOIN R1 ON R1.Код_товара=R3.Код_товара
WHERE R1.Имя_товара LIKE ‘%банан%’#+
SELECT a.Имя_поставщика FROM R2 a
LEFT JOIN R3 ON a.Код_поставщика=b.Код_поставщика
LEFT JOIN R1 ON b.Код_товара=c.Код_товара
WHERE R1.Имя_товара LIKE ‘%банан%’#
SELECT R2.Имя_поставщика FROM R3
LEFT JOIN R1 ON R1.Код_товара=R3.Код_товара
LEFT JOIN R2 ON R2.Код_поставщика=R3.Код_поставщика
WHERE R1.Имя_товара LIKE ‘%банан%’#
##
Вопрос т:О Б:100
Даны таблицы
R1 <Код_товара, Имя_товара>
31
R2 <Код_поставщика, Имя_поставщика>
R3 <Код_товара, Код_поставщика, Кол-во_товара, Дата>
Какой запрос позволит найти поставщика (поставщиков), выполнившего наибольшую
разовую поставку товара? #
SELECT R2.Имя_поставщика FROM R3
LEFT JOIN R2 ON R3.Код_поставщика=R2.Код_поставщика
WHERE R3.Кол-во_товара = (SELECT MAX(R3.Кол-во_товара) FROM R3)
#+
SELECT MAX(R3.Кол_во_товара), R2.Имя_поставщика FROM R2
LEFT JOIN R3 ON R3.Код_поставщика=R2.Код_поставщика
GROUP BY R2.Имя_поставщика
ORDER BY 1 DESC
#
SELECT MAX(R3.Кол_во_товара), R2.Имя_поставщика FROM R3
LEFT JOIN R3 ON R3.Код_поставщика=R2.Код_поставщика
GROUP BY R2.Имя_поставщика
ORDER BY 1 DESC
#
##
Вопрос т:О Б:100
Даны таблицы
R1 <Код_товара, Имя_товара>
R2 <Код_поставщика, Имя_поставщика>
R3 <Код_товара, Код_поставщика, Кол-во_товара, Дата>
Какой запрос позволит проранжировать поставщиков по суммарному количеству
поставленного ими товара за все время? #
SELECT SUM(R3.Кол-во_товара), R2.Имя_поставщика FROM R3
LEFT JOIN R2 ON R3.Код_поставщика=R2.Код_поставщика
GROUP BY R2.Имя_поставщика
ORDER BY 1
#+
SELECT SUM(R3.Кол-во_товара), R2.Имя_поставщика FROM R3
LEFT JOIN R2 ON R3.Код_поставщика=R2.Код_поставщика
GROUP BY R2.Имя_поставщика
ORDER BY 2
#
SELECT COUNT(*), R2.Имя_поставщика FROM R3
LEFT JOIN R2 ON R3.Код_поставщика=R2.Код_поставщика
GROUP BY R2.Имя_поставщика
ORDER BY 1
#
SELECT COUNT(*), R2.Имя_поставщика FROM R3
LEFT JOIN R2 ON R3.Код_поставщика=R2.Код_поставщика
GROUP BY R2.Имя_поставщика
ORDER BY 2
#
##
Вопросы теста, а также автоматизированная система тестирования и оценки знаний
приведены в электронном УМК “Базы данных и технология SQL”, Шехтман В. Е., 2005.
32
5. Учебно-методическое обеспечение дисциплины
5.1. Основная и дополнительная учебная литература
Основная литература
1. Гарсия-Молина Г. Системы баз данных. Полный курс [Текст]: пер. с англ./Г. ГарсияМолина, Джеффри Ульман, Дж. Уидом. – М.: Вильямс , 2003. – 1088 с.
2. Джеффри Ульман. Материалы сайта www-db.stanford.edu/~ullman/dscb.html
3. Малыхина М. П. Базы данных: основы, проектирование, использование [Текст]/М. П.
Малыхина. – СПб.: БХВ – Петербург, 2004. – 512 с.
4. Мамаев Е. В. MS SQL Server 7.0: проектирование и реализация баз данных [Текст]/Е.
В. Мамаев – СПб.: БХВ, 2000. – 416 с.
5. Хоторн Р. Разработка Microsoft SQL Server 2000 на примерах [Текст]:пер. с англ./Р.
Хоторн. – М.: Вильямс, 2001. – 464 с.
6. Грабер М. SQL [Текст]:пер. с англ./ М. Грабер. – М.: ЛОРИ, 2001. – 643 с.
7. Селко Джо. Программирование на SQL для профессионалов [Текст]: пер. с англ./
Джо Селко/ – 2-е изд. – М.: ЛОРИ, 2004. – 478 с.
8. Карпова Т. Базы данных: модели, разработка, реализация [Текст]/Т. Карпова. – СПб.:
Питер 2001. – 304 с.: ил.
9. С. Д. Кузнецов. Основы современных баз данных. Материалы сайта www.citforum.ru
Дополнительная литература
10. Глушков М. Основы безбумажной информатики [Текст] / М. Глушков. – М.: Наука.
1987. – 552 с.
11. Ульман Джулиан. Базы данных на Паскале [Текст] : пер. с англ. / Джулиан Ульман. –
М.: Машиностроение, 1990. – 386 с.
12. Пирогов В. Ю. MS SQL Server 2000. Управление и программирование [Текст]/
В. Ю. Пирогов. – СПб.: БХВ-Петербург, 2005. – 608 с.
13. Конноли Томас. Базы данных: проектирование, реализация и сопровождение. Тероия
и практика [Текст]: учеб. пособие:пер. с англ./ Томас Конноли, Каролин Бегг, Анна
Страган. – 2-е изд. – М.:Вильямс, 2000. – 1120 с.
14. Роланд Ф. Д. Основные концепции баз данных [Текст]: пер. с англ./Ф. Д. Роланд. –
М.: Вильямс, 2002. – 256 с.
15. В. В. Кириллов. Основы проектирования реляционных баз данных. Материалы сайта
www.citforum.ru
16. Дюк В.А. Data Mining [Текст]: учеб. курс / В. А. Дюк, А. П. Самойленко. – СПб.:
Питер, 2001. – 368 с.
17. Материалы сайта Королевство Delphi www.delphikingdom.com
18. Материалы сайта www.sql.ru
19. Материалы сайта aspnetmania.com. Александр Уз. Работа с множествами в TransactSQL.
20. Window functions.: RSDN Magazine vol. 6, 2004.
21. Дейт, К. Дж. Введение в системы баз данных [Текст]: пер. с англ./ К. Дж. Дейт. – 6-е
изд. – К.; М.; СПб.: Вильямс, 2000. – 848 с.
22. Диго С. М. Базы данных: проектирование и использование[Текст]: учебник/
С. М. Диго. – М.: Финансы и статистика, 2005. – 592 с.
5.2. Методические указания для студентов
5.2.1. График организации самостоятельной работы студентов по
учебному плану гр. ПИЭ по дисциплине «Базы данных»
Очная форма обучения
33
Общее кол-во часов по учебному плану - 102 час.
48 час. Аудиторная работа
54 час. Самостоятельная работа
Виды самостоятельной учебной
Формы аудиторных учебных занятий (час.)
работы (час.)
№
неде
ли
1
2
3
3
4
5
6
6
7
8
9
10
11
12
13
№ и тема лекции
Базы данных и модели данных.
Введение в реляционную модель
данных
Реляционная алгебра
Инфологическое проектирование
Нормализация данных
Язык SQL
Параллельная работа с базами
данных. Транзакции
Физическая организация баз
данных и СУБД
Архитектуры доступа к БД.
Системные аспекты
Информационные хранилища.
OLAP-технология.
Полуструктурированная модель
данных
Искусственный
интеллект
и
экспертные системы Представление
знаний
14
14
15
Экспертные системы
16
Перспективы развития баз данных и
экспертных систем
ИТОГО
32 часа
Лекции
16 часа
Лаборато
рные
работы
20 час.
Изучение
теоретического
материала
14 час.
Решение
практических задач
2
0
1
3
0
1
2
3
1
1
3
1
2
2
2
1
1
2
2
2
2
1
2
1
1
1
1
1
2
0
1
2
2
1
2
2
1
2
3
20 час.
Индивидуальн
ые задания
3
2
20
1
2
1
1
1
1
2
1
2
32
1
1
1
1
1
1
1
16
20
14
20
5.2.2. Методические указания к выполнению курсовой работы
Проект можно выполнять в одиночку или группой до 2 человек (проектная
команда). Для овладения техническими навыками разработки баз данных и создания
информационных приложений на их основе служит практикум, изложенный в разделе 6
настоящего УМК.
В ходе выполнения курсовой работы необходимо спроектировать базу данных и
реализовать ее физически с использованием одного из доступных СУБД. Кроме того,
необходимо разработать приложение для обслуживания базы данных. Желательно иметь
34
несколько типов пользователей, тогда
идентифицироваться своим именем и паролем.
каждый
из
пользователей
может
Последовательность действий по шагам:
1. Выбрать предметную область, на описание которой будет направлен проект. Она
должна быть достаточно богата (но не чрезмерно, от 5 до 15 наборов сущностей).
Описать ее на содержательном уровне, перечислить основные вопросы, на которые
должно отвечать программное приложение, которое будет разработано.
2. Разработать для этой предметной области модель “сущность-связь”
(инфологическую модель). Обосновать мощность и обязательность или
необязательность связей, выбор ключей. Представить и обсудить модель на
лабораторных занятиях.
Срок окончания первой фазы разработки (п. 1,2) – 10-15 марта.
3. Превратить эту модель в даталогическую. Обосновать при этом выбор того или
иного способа реализации схем отношений и связей между ними, выбор типов для
атрибутов отношений. Реализовать модель в виде физической базы данных.
Позаботится об отсутствии в базе данных избыточности и аномалий изменения и
удаления. Для этого обосновать уровень нормализации соответствующих отношений.
Обеспечить ссылочную целостность и целостность на уровне таблицы, записи,
атрибута (первичные и внешние ключи, другие ограничения).
4. Указать последовательность команд SQL для создания базы данных со всеми
необходимыми объектами (см. пример скрипта в приложении).
В качестве СУБД можно использовать Microsoft Access, Microsoft SQL Server 2000
или др. по согласованию с преподавателем.
Наполнить базу данных осмысленным содержанием (это можно отложить до
выполнения п. 5).
Срок окончания второй фазы разработки (п. 3,4) – 15-20 марта. (Параллельно с этим
следует заниматься и следующей фазой).
5. Разработать приложение (например, на Delphi) для ввода и редактирования данных
и построения отчетов, основываясь на проекте базы данных, разработанной в ходе
выполнения п.п. 1.-4.
Желательно, чтобы приложение имело стандартную архитектуру (главная форма,
модуль данных, универсальная форма просмотра нормативно-справочной информации
с возможностью формирования твердой копии справочников, формы ввода данных и
формы построения отчетов).
При необходимости, реализовать форму просмотра-редактирования справочника
иерархической структуры. В качестве интерфейса доступа к данным следует (если
возможно) использовать Microsoft ADO. Человеко-машинный интерфейс может быть
любым.
6. Отчет должен содержать:
 название проекта, имя (имена) исполнителей, группу.
 оглавление с номерами страниц.
35
 описание вклада каждого члена проектной команды.
 функциональные требования к системе (может включать меню, экраны, описания
на русском языке и (или) UML-диаграммы, например диаграммы USE CASE
содержащие описание способов взаимодействия с системой).
 ER-диаграмму с обсуждением особенностей и обоснованием конкретных решений
 даталогическую модель данных с описанием степени нормализации
 скрипт на языке SQL для создания базы данных “с нуля”
 описание структуры приложения (можно с использованием UML диаграммы
компонентов)
 краткая инструкция по работе с приложением (если необходимо).
При желании можно подготовить небольшую презентацию, изготовленную с помощью
PowerPoint, объясняющую цели разработки, требования к функциональности, модель
интерфейса с пользователем.
Срок окончания разработки – середина апреля.
Защита курсового проекта должна осуществляться всеми членами проектной команды
(если она есть). Оценка зависит от качества проекта базы данных и разработанного
приложения, отчета, наличия подготовленной презентации (последнее в меньшей
степени), ответа на дополнительные вопросы.
Выбор предметной области
Предметной областью может быть любая на Ваш выбор: регистрация и лечение
пациентов в стоматологической клинике; система заказа – резервирования билетов;
интернет – магазин и т. д.
Примеры словесного описания предметных областей:
1. Спортивный комплекс предоставляет несколько видов услуг. Пользователи могут
оплачивать один сеанс (100 руб.) или приобретать абонемент на 8 сеансов (640
руб.) на определенное время и день недели. Каждый сеанс длится 1 час.
…
Надо ответить на вопросы типа:
1.1. Сколько денег заплатил пользователь за период?
1.2. Какие пользователи имеют абонемент в тренажерный зал за указанный период?
1.3. Есть ли свободное место на теннисном корте (клиент заранее не позаботился о
приобретении абонемента) на определенное время и дату?
1.4. Сколько свободных мест в плавательном бассейне на определенное время и дату?
1.5. Сколько денег поступило в кассу за период?
и т. д.
2. Медицинское учреждение состоит из стационара и поликлиники. На каждого
пациента ведется “карточка”, куда заносятся паспортные данные. В поликлинике
на каждый курс лечения пациента ведется амбулаторная карта, куда заносятся
диагнозы, объективные данные, жалобы, факт каждого посещения, лечебные
назначения. В стационаре на каждый курс лечения пациента формируется “карта
больного”, куда заносятся диагнозы, лечебные назначения, объективные данные.
При выписке в карту добавляется исход болезни.
…
Надо иметь возможность отвечать на вопросы типа:
36
2.1. Какие диагнозы (и классы диагнозов) наиболее часто встречаются среди всех
пациентов?
2.2. Как лечили пациента …?
2.3. Пациенты, пролеченные в стационаре за период … .
2.4. Какие пациенты имеют диагноз …?
2.5. Пациенты, лечившиеся за период … в поликлинике и стационаре.
и т. д.
Далее представлены образцы схем баз данных типовых проектов.
Внимание: это не инфологические модели, а даталогические!
Рисунок 1. Примерный вид схемы базы данных курсового проекта (СУБД Access).
37
PATI ENT
PATH
FN
SN
POLIS
BORN
ADR1
ADR2
ADR3
LABOR
UNIT
PRICE
PRICEN
PROG
PARENT
PATH
NAME
SON
UNIT
PRICEN
PRICE
QUANT
ART
UNIT1
UNIT2
INTRV
DOC0
KORR0
DOC
OPERAKLASS
DATD
DATF
OPERA
NUM
SUMMC
SUMMA
SUMMB
OBJ0
OBJ1
OBJ2
ID
OPERAKLASS
DOC
DAT
OBJ0
OBJ1
OBJ2
OBJ3
OBJ4
OBJ5
OBJ6
OBJ7
CASH0
ID
OPERAKLASS
DOC
IDCOURSE
OPERA
DATD
DATF
PRICE
PRICEN
QUANT
QUANTA
SUMMA
OPERA0
COURSE0
ID
DOC
OPERAKLASS
DATD
DATF
DISCO
SUMMA
SUMMB
SUMMT
SUMMO
SUMML
ID
OPERAKLASS
DOC
OPERA
DATD
DATF
QUANT
QUANTA
PRICE
PRICEN
SUMMA
OBJ0
CONDI 0
ID
OPERAKLASS
DOC
OPERA
ID1
SUMMA
SUMMB
OBJ0
PAR4
ART4
DEP4
IDCOURSE
1- 1
Рисунок 2. Еще один пример схемы базы данных курсового проекта (СУБД MS SQL 2000).
Ниже представлен фрагмента скрипта для создания таблиц и связей между ними, для
базы данных, схема которой (даталогическая модель) изображенна на рис. 2. Скрипт
может быть получен автоматически или написан вручную. Наличие скрипта желательно,
т. к. он дает детальное описание базы данных (по сути, является воплощением физической
модели):
CREATE TABLE [dbo].[PROG] (
[PARENT] [int] NULL ,
[PATH] [char] (15) COLLATE Cyrillic_General_CI_AS NOT NULL ,
[NAME] [varchar] (50) COLLATE Cyrillic_General_CI_AS NULL ,
[SON] [int] NULL ,
[UNIT] [varchar] (25) COLLATE Cyrillic_General_CI_AS NULL ,
[PRICEN] [float] NULL ,
[PRICE] [float] NULL ,
[QUANT] [float] NULL ,
[ART] [int] NULL ,
[UNIT1] [varchar] (25) COLLATE Cyrillic_General_CI_AS NULL ,
[UNIT2] [varchar] (25) COLLATE Cyrillic_General_CI_AS NULL ,
[INTRV] [int] NULL ,
[HIDE] [smallint] NULL
) ON [PRIMARY]
CREATE TABLE [dbo].[DOC0] (
[DOC] [int] NOT NULL ,
[OPERAKLASS] [char] (15) COLLATE Cyrillic_General_CI_AS NOT NULL ,
[DATD] [datetime] NULL ,
[DATF] [datetime] NULL ,
[OPERA] [int] NULL ,
[NUM] [varchar] (25) COLLATE Cyrillic_General_CI_AS NOT NULL ,
[SUMMC] [money] NULL ,
[SUMMA] [money] NULL ,
[SUMMB] [money] NULL ,
[OBJ0] [char] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[OBJ1] [char] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[OBJ2] [char] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[OBJ3] [char] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[OBJ4] [char] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[SYS] [smallint] NULL ,
38
[SUMMT] [money] NULL ,
[SUMMO] [money] NULL ,
[SUMML] [money] NULL ,
[DATS] [datetime] NULL ,
[TREATY] [int] NULL ,
[DATA] [datetime] NULL
) ON [PRIMARY]
………………………
ALTER TABLE [dbo].[PROG] WITH NOCHECK ADD
PRIMARY KEY CLUSTERED
(
[PATH]
) ON [PRIMARY]
ALTER TABLE [dbo].[DOC0] WITH NOCHECK ADD
PRIMARY KEY CLUSTERED
(
[OPERAKLASS],
[DOC]
) ON [PRIMARY]
ALTER TABLE [dbo].[PATIENT] WITH NOCHECK ADD
PRIMARY KEY CLUSTERED
(
[PATH]
) ON [PRIMARY]
………………………….
CREATE INDEX [PROG] ON [dbo].[PROG]([PARENT], [PATH]) ON [PRIMARY]
CREATE INDEX [PNAME] ON [dbo].[PROG]([PARENT], [NAME]) ON [PRIMARY]
CREATE INDEX [PART] ON [dbo].[PROG]([PARENT], [ART]) ON [PRIMARY]
CREATE INDEX [SON] ON [dbo].[PROG]([SON]) ON [PRIMARY]
CREATE INDEX [DKLASS0] ON [dbo].[DOC0]([OPERAKLASS], [DATF], [DOC]) ON [PRIMARY]
CREATE INDEX [DNUM0] ON [dbo].[DOC0]([NUM], [DOC]) ON [PRIMARY]
CREATE UNIQUE INDEX [COURSEDOC0] ON [dbo].[COURSE0]([OPERAKLASS], [DOC], [ID]) ON [PRIMARY]
CREATE INDEX [KORRIO0] ON [dbo].[KORR0]([OPERAKLASS], [DOC]) ON [PRIMARY]
………………………………
CREATE INDEX [CASHC0] ON [dbo].[CASH0]([OPERAKLASS], [DOC], [IDCOURSE]) ON [PRIMARY]
CREATE INDEX [CINDIO0] ON [dbo].[CONDI0]([OPERAKLASS], [DOC], [IDCOURSE]) ON [PRIMARY]
CREATE INDEX [OPERAD0] ON [dbo].[OPERA0]([OPERAKLASS], [DOC]) ON [PRIMARY]
ALTER TABLE [dbo].[DOC0] ADD
CONSTRAINT [FK_DOC0_PROG] FOREIGN KEY
(
[OPERAKLASS]
) REFERENCES [dbo].[PROG] (
[PATH]
)
ALTER TABLE [dbo].[PATIENT] ADD
CONSTRAINT [FK_PATIENT_PROG] FOREIGN KEY
(
[PATH]
) REFERENCES [dbo].[PROG] (
[PATH]
)
………………………
5.2.3. Методические указания к проведению практических занятий
Приведенный ниже практикум может быть использован для проведения
лабораторных и практических занятий при изучении курсов “Базы данных”. Основной
теоретический материал, необходимый для успешного выполнения практикума изложен в
курсе лекций “Базы данных, SQL и все такое”, на который в соответствующих местах есть
ссылки, обычно с точностью до главы. Такие ссылки помечены значком . Кроме того,
здесь приведены необходимые технические знания, требуемые для выполнения
лабораторных работ студентами.
Большинство разделов практикума имеют следующую структуру:
 приводится материал, являющийся предпосылкой для выполнения заданий
лабораторной работы со ссылками на теоретический курс
 приводятся задания на лабораторную работу (они помечены значком ).
Таким образом, практикум предназначен для использования студентами в ходе
выполнения лабораторных работ в компьютерном классе под руководством
39
преподавателя. Однако он может быть использован студентами и в ходе самостоятельных
занятий.
Работа №1. Знакомство с принципами программирования доступа к базам данных в
Delphi
Для доступа к данным при разработке программ в системе Delphi воспользуемся
интерфейсом ADO. ADO (Active Data Objects) - это высокоуровневые компоненты доступа
к данным, разработанные Microsoft. (инсталляционный файл – MDAC.EXE (Microsoft Data
Access Components)). Другие способы доступа:
 ODBC – открытый интерфейс доступа к базам данных, довольно старый,
надежный, но уступающий своим новым конкурентам
 Borland BDE – закрытый, “фирменный” интерфейс доступа к базам данных
 низкоуровневый интерфейс OLE DB, надстройкой над которым и является ADO
ADO позволяет обратиться как к “настольным” (desktop) базам данных (таким как
Access, Paradox, FoxPro) так и к “настоящим”, серверным базам данных (Microsoft SQL,
Oracle, Interbase). Кроме того, через этот интерфейс возможен доступ к нереляционным
источникам данных, таким как XML-файлы, данные почтовой службы и др.
ADO - более новая, по сравнению с ODBC и BDE технология, работает через
интерфейс OLE DB. Впрочем, можно использовать ADO и при подключении к
источникам ODBC-данных. Однако OLE DB превосходит ODBC по скорости, хотя,
будучи относительно молодой, не может пока покрыть весь спектр источников данных,
для которых написаны драйверы ODBC.
Что касается операционной системы Windows, то MDAC входит в нее, начиная с
Windows 98. Поэтому, в отличие от интерфейса Borland BDE, обычно не требуется
установка компонентов ADO на компьютере (по крайней мере в той части, которая
касается доступа к СУБД Access и Microsoft SQL Server).
Начиная с версии 5 компоненты для работы с ADO (вкладка ADO на палитре
компонентов) включены в инструментальную палитру Delphi. Это VCL-компоненты,
разработанные Borland. Они примерно соответствуют старым компонентам доступа к
данным, использующим BDE, которые ранее осуществляли основной доступ к данным в
Delphi. Вот названия типов новых компонентов: TADOConnection, TADOCommand,
TADODataSet, TADOTable, TADOQuery, TADOStoredProc и TRDSConnection.
TADOConnection - это класс, объекты которого инкапсулируют всю
функциональность, необходимую для установления связи с конкретным источником
данных. Один объект этого класса может использоваться многими объектами классов
TADOCommand, TADODataSet, TADOTable, TADOQuery, TADOStoredProc для доступа к
данным. Он позволяет управлять параметрами доступа к данным путем задания значений
его свойств (схема блокировки (пессимистическая или оптимистическая), тип курсора и
его расположение (на сервере или клиенте), уровень изоляции транзакций, тайм-аут и др.).
Кроме того, этот класс содержит методы для управления транзакциями и извлечения
метаданных о базе данных, с которой установлена связь.
Главное его свойство - ConnectionString (строка подключения) - это несколько
подстрок вида «имя параметра = значение», которые описывают, где находятся данные и
как к ним подключаться. Значения, которые всегда должны быть в строке подключения это имя поставщика данных (Data Provider) и имя базы данных.
Пример: фрагмент строки подключения к базе данных Access:
Provider = Microsoft.Jet.OLE DB.4.0;Data Source = C:\db1.mdb
Здесь Microsoft.Jet.OLEDB.4.0 - это “OLE DB поставщик” или “провайдер” данных для баз
данных Microsoft Access. Существует множество других провайдеров, например
SQL OLE DB.1 - провайдер для СУБД Microsoft SQL. Кроме имени поставщика данных
40
строка подключения может хранить другие параметры (например, имя пользователя и
пароль, величину тайм-аута, права доступа и т.п.). Перечень этих свойств зависит от
конкретного поставщика данных.
В поставку Windows входит специальный редактор строк подключения. Довольно
гибким является решение хранить строку подключения в отдельном файле (а не в тексте
программы на Delphi) - это позволит, при необходимости, изменить параметры
подключения (например, путь к базе данных или даже тип СУБД) без внесения изменений
в программное приложение. Для хранения строк подключения предназначены файлы с
расширением UDL (universal data link). Создать UDL-файл просто – в контекстном меню
Проводника (Explorer) Windows имеется пункт меню NEW -> Microsoft Data Link File.
Если такой пункт отсутствует, можно поступить еще проще - создать пустой текстовый
файл с расширением ”UDL”. При попытке открыть такой файл автоматически запускается
редактор строк подключения.
Рисунок 1.1. Редактор строк подключений ADO
Выберите провайдер (для баз Access - провайдер называется Microsoft JET 4.0 OLE
DB Provider, для MS SQL - OLE DB Provider for SQL server). Нажмите кнопку Далее. На
рисунке внешний вид редактора для баз данных Access - введите путь к базе данных, имя
пользователя и пароль (если нужно) и нажмите кнопку «Проверить подключение», чтобы
убедиться, что все сделано правильно.
41
Рисунок 1.2. Назначение базы данных в редакторе строк подключений.
После того как UDL-файл готов, можно использовать его в Delphi - создайте новый
проект, поместите на форму (или на Data Module) компонент ADOConnection, щелкните
по свойству ConnectionString и укажите путь к UDL-файлу, откуда эту строку соединения
нужно взять:
Рисунок 1.3. Редактор строк подключений для компонента TADOConnection.
Все остальные компоненты ADO также имеют свойство ConnectionString. Поэтому в
принципе можно вообще обойтись без компонента ADOConnection - просто в каждом из
используемых компонентов ADOQuery, ADOCommand и т.д. указать путь к этому UDLфайлу. Однако компонент ADOConnection содержит и другие полезные свойств и методы,
да и кроме того весьма удобно сосредоточить описание всех особенностей подключения
приложения к базе данных в одном месте!
Работа №2. Разработка первого приложения баз данных
Базовый объект ADO – ADOCommand. Он содержит функциональность для
передачи команды на сервер (команда может заставить сервер читать или изменить
данные). ADO всегда работает в режиме клиент-сервер, даже с локальными (или
“настольными”) СУБД. После выполнения команды база данных может вернуть записи
(если это была команда на чтение данных) или ничего не вернуть (если это, скажем, была
команда на удаление данных). Очевидно, что команды - это строки, написанные на языке
SQL.
42
Компоненты TADOTable и TADOQuery предназначены для того, чтобы
программистам, привыкшим работать с BDE и компонентами TTable и TQuery, было бы
легче перейти на ADO. Они имеют сходные с TTable и TQuery методы - но не совпадают с
ними полностью - поэтому автоматически преобразовать проект, использующий BDE в
ADO как правило не получается.
Компонент TADODataset - это компонент, который имеет возможности TADOTable
и TADOQuery одновременно - т.е. может быть использован как для выполнения SQLзапроса так и для “прямого” (точнее упрощенного) обращения к какой-либо таблице.
Компонент TADOStoredProc - компонент для работы с хранимыми процедурами.
 Задание:
Первое приложение баз данных должно позволить просматривать и редактировать
любую таблицу из имеющихся в базе данных. Шаги по созданию первого приложения баз
данных:
1. Создать новый проект. Он состоит из модуля проекта, главной формы и модуля
главной формы.
2. Добавить к проекту модуль DataModule. К проекту должны добавиться форма
модуля данных и собственно модуль данных. Изменить имя модуля данных на DM.
3. Добавить на DM компонент TADOConnection. Изменитьего имя на DBC.
4. Сформировать с помощью редактора строк подключения к базе данных (для его
вызова следует дважды щелкнуть на компонент DBC, размещенный на DM) строку
соединения.
5. Добавить на DM компонент TADOTable. Изменить его имя на DBT.
6. Подсоединить DBT к существующему соединению с базой данных путем
установки его свойства Connection равным ссылке на уже существующий
компонент DBC.
7. Указать имя таблицы, которую будет представлять DBT, путем задания свойства
TableName.
8. Перейти к главной форме приложения. Разместить на ней компонент TDBGrid.
Изменить его имя на DBG.
9. Разместить на ней же компонент TDataSource. Изменить его имя на DBS.
10. Свойство DBG.DataSource должно указывать на компонент DBS.
11. Свойство DBS.DataSet должно указывать на компонент DM.DBT.
12. В обработчик события OnShow главной формы приложения вставить код:
DM.DBT.Open;
13. В обработчик события OnClose главной формы приложения вставить код:
DM.DBT.Close;
14. Скомпилировать проект и вызвать его на выполнение.

В общем виде, модель взаимодействия объектов доступа к базе данных, в рамках
приложения на Delphi, можно изобразить в виде диаграммы:
43
ADOConnection
ADOTable
DataSource
DBGrid
Рисунок 2.1. Модель взаимодействия объектов доступа к базе данных.
 Задание: воспользуйтесь методом GetTableNames объекта DBC чтобы получить список
всех таблиц, имеющихся в Вашей базе данных. Разработайте интерфейсную форму,
позволяющую выбирать любую таблицу из имеющихся. Можно воспользоваться готовым
приложением для того, чтобы просматривать и редактировать любые таблицы.

Работа №3. Разработка утилиты для выполнения SQL-запросов
Кроме компонента TDBGrid в палитре Delphi имеются и другие визуальные
компоненты, чувствительные к данным (data aware components). Таким является
компонентом TDBNavigator. Его достаточно подключить к источнику данных, указав
значение свойства DataSource. Этот компонент позволяет c помощью соответствующих
кнопок перемещаться по записям таблицы (первая, последняя, предыдущая, следующая),
переходить в режим редактирования, сохранять результаты или отменять редактирование
без сохранения. Каждую кнопку можно выключить, или включить, для чего просто
поменять значение свойства VisibleButtons.
Еще один визуальный компонент - TDBImage. Этот компонент отображает
графический образ, которая может хранится в базе данных. Установив свойства
DataSource и DataField этого компонента (DataField следует задать равным имени поля
таблицы, в котором хранятся графические изображения), получим возможность
отражения картинок на форме.
Упомянем и компонент TDBMemo. Этот компонент очень похож на обычный
компонент TMemo. Как обычно, следует установить свойства DataSource и DataField
(DataField надо установить равным имени поля таблицы, в котором хранятся текстовые
данные переменной длины).
 Задание: воспользуйтесь компонентом TADOQuery чтобы получить доступ к данным,
извлекаемым SQL-запросом. Такой запрос должен возвращать результирующий набор.
Для этого разработайте утилиту, позволяющую ввести текст SQL-запроса (например, в
компонент TMemo) и выполнить его с визуализацией результата (например, с помощью
TDBGrid). Поэкспериментируйте с различными запросами на чтение.


Более подробно принципы построения компонентов доступа к базе данных
описаны в главе 12 Курса лекций. В частности, интерфейс ADO описан в п. 12.5.
Работа №4. Построение инфологической модели базы данных
44

Принципы и техника инфологического моделирования изложены в главе 4 курса
лекций.
 Задание:
Разработать диаграмму “сущность-связь” для моделирования следующей
предметной области:
1. В университете имеются факультеты, на факультетах – группы, в группах –
студенты.
Надо ответить на вопросы типа (составить соответствующие SQL-запросы):
Какие студенты учатся на факультете …?
На каком факультете учится студент …?
Какие группы на факультете …?

 Задание:
Разработать диаграмму “сущность-связь” для моделирования следующей
предметной области:
2. Предприятие работает над выполнением нескольких проектов. Для выполнения
проекта формируется проектная группа, куда входит несколько сотрудников. Один
сотрудник может входить в несколько проектных групп. Надо ответить на вопросы
типа:
Какие сотрудники входят в проектную группу …?
В какие группы входит сотрудник …?

 Задание:
Разработать диаграмму “сущность-связь” для моделирования следующей
предметной области:
3. На предприятии установлена сменная работа. Одновременно в смену работает до
10 человек.
Надо ответить на вопросы типа:
Какие сотрудники работают в 1 смену 3 числа?
Сколько сотрудников работает во 2 смену 10 числа?
Когда работает сотрудник …?

Работа №5. Выбор сквозного задания
При выборе сквозного задания следует предложить несколько более богатую
проблемную область (по количеству сущностей и связей между ними), чем те, которые
рассматривались в предыдущей работе. Можно при оценке “достаточного богатства”
ориентироваться на такие примеры:
3. Спортивный комплекс предоставляет несколько видов услуг. Пользователи могут
оплачивать один сеанс (100 руб.) или приобретать абонемент на 8 сеансов (640
руб.) на определенное время и день недели. Каждый сеанс длится 1 час.
Надо ответить на вопросы типа:
1.1. Сколько денег заплатил пользователь за период?
1.2. Какие пользователи имеют абонемент в тренажерный зал за указанный период?
1.3. Есть ли свободное место на теннисном корте (нет абонемента) на определенное
время и дату?
1.4. Сколько свободных мест в плавательном бассейне на определенное время и дату?
1.5. Сколько денег поступило в кассу за период?
45
4. Медицинское учреждение состоит из стационара и поликлиники. На каждого
пациента ведется “карточка”, куда заносятся паспортные данные. В поликлинике
на каждый курс лечения пациента ведется амбулаторная карта, куда заносятся
диагнозы, объективные данные, жалобы, факт каждого посещения, лечебные
назначения. В стационаре на каждый курс лечения пациента формируется “карта
больного”, куда заносятся диагнозы, лечебные назначения, объективные данные.
При выписке в карту добавляется исход болезни.
Надо иметь возможность отвечать на вопросы типа:
2.1. Какие диагнозы (и классы диагнозов) наиболее часто встречаются среди всех
пациентов?
2.2. Как лечили пациента …?
2.3. Пациенты, пролеченные в стационаре за период.
2.4. Какие пациенты имеют диагноз …?
2.5. Пациенты, лечившиеся за период в поликлинике и стационаре.
 Задание:
Разработать проект базы данных для сквозного задания. При разработке проекта
базы данных необходимо сначала реализовать инфологическую, а затем и физическую
модели базы данных. В явной следует форме выделить таблицы фактов и справочников,
обосновать выбор того или иного способа реализации отношений между таблицами (1:1,
1:N, M:N, рекурсивная иерархия) и выбор естественных или искусственных ключей.
Обосновать уровни нормализации таблиц: они должны быть не ниже 3НФ.
Далее на основе выбора предметной области и соответствующих инфологической и
физической модели базы данных потребуется разработать приложение на Delphi для ввода
и редактирования данных и построения отчетов, основываясь на предложенном проекте
базы данных.


Принципы нормализации изложены в главе 5 курса лекций.
Работа №6. Проектирование структуры приложения сквозного задания
Разработайте главную форму приложения и модуль данных. В главной форме
реализуйте главное меню приложения иерархической структуры, примерный вид
которого:
Данные
Справочники
Справочник 1
Справочник 2
…
Данные
…
Окна
Отчеты
Отчет 1
Отчет 2
…
Рисунок 6.1. Примерная структура главного меню приложения.
 Задание:
В модуле данных по имени DM (который необходимо добавить в проект) описать
соединение с базой данных с помощью компонента DBC (класса TADOConnection) и все
таблицы базы данных (TADOTable). В таблицах описать поля базы данных (TField),
задать необходимые свойства этих полей.

46

Более подробно принципы построения и свойства компонентов доступа к базе
данных описаны в главе 12 Курса лекций. В частности, интерфейс ADO описан в п. 12.5.
Работа №7. Работа со справочниками
 Задание:
Разработать универсальный класс (TCatalog) для редактирования справочников, и
на его основе реализовать окна просмотра и редактирования справочников. Этот класс
должен быть основан на модальной форме. Основной интерфейсный элемент в этой
форме – компонент класса TDBGrid (назовем его Grid). Форма должна создаваться
динамически по мере запроса на вывод окна просмотра-редактирования справочника. В
компоненте Grid должны присутствовать необходимые для просмотра поля справочника
(искусственные коды, уникально идентифицирующие запись в справочнике, не должны
быть видны по умолчанию, однако следует создать элемент управления, позволяющий
сделать их видимыми).
Другой компонент, необходимый на форме – DS класса TDataSource. Необходимо
установить свойство Grid.DataSource равным DS.

Для вызова формы, позволяющей просматривать и редактировать справочники
необходимо определить обработчик выбора пункта меню, соответствующего показу
справочника, в виде:
procedure TMain.N11Click(Sender: TObject);
var f:TCatalog;
begin
f := TCatalog.Create(Self);
f.DS.DateSet := DM.Spr1;
DM.Spr1.Open;
// Обеспечить правильное отражение полей-счетчиков и других полей,
генерируемых на стороне СУБД
DM.Spr1.Properties['Update Resync'].Value:=adResyncAll;
f.Caption
:= <Наименование справочника>;
f.ShowModal;
DM.Spr1.Close;
end;
Необходимо обеспечить возможность показа (или скрытия) искусственных ключей
(если они есть) справочника. По умолчанию, поля, соответствующие искусственным
ключам, должны быть невидимы, т. к. они не нужны рядовому пользователю. Однако
разработчику и администратору базы данных зачастую бывает необходимо их увидеть.
Для этого следует дополнить форму показа и редактирования справочников новым
элементом управления – кнопкой (например, класса TButton). Далее следует написать
программу - обработчик события нажатия на эту кнопку, который должен изменять
свойство видимости соответствующего поля таблицы - справочника. Здесь имеется
несколько возможностей.
Если бы мы писали специальные программы отдельно для каждого справочника, то
в таком обработчике можно было бы ограничиться кодом вида
procedure TCatalog.Button1Click( Sender: TObject );
47
begin
DM.Spr1.FieldByName(‘ID’).Visible
DM.Spr1.FieldByName(‘ID’).Visible;
end;
:= not
Однако в универсальной программе придется поступить иначе (в предположении, что все
поля-ключи во всех справочниках называются одинаково):
procedure TCatalog.Button1Click( Sender: TObject );
begin
DS.DataSet.FieldByName(‘ID’).Visible := not
DS.DataSet.FieldByName(‘ID’).Visible;
end;
Если поля-ключи в разных справочниках называются по разному, но все они определены
первыми по порядку в наборе полей таблицы, можно воспользоваться другой формой:
procedure TCatalog.Button1Click( Sender: TObject );
begin
DS.DataSet.Fields[0].Visible
:= not DS.DataSet.Fields[0].Visible;
end;
 Задание:
Добавьте в программу просмотра и редактирования справочников возможность скрытия и
показа искусственных ключей (или других атрибутов по смыслу Вашего приложения).
Теперь, основываясь на только что разработанной форме показа и редактирования
справочников, внести данные в справочники системы.

Работа №8. Формирование твердой копии справочника.
Разработать подпрограмму формирования твердой копии справочника как метод
универсального класса просмотра и редактирования справочников. Добавить элемент
управления на форме для вызова этого метода. Подпрограмма формирования твердой
копии должна реализовать одну из следующих возможностей:
сформировать текстовый файл, содержащий все данные таблицы-справочника;
сформировать в текстовом файле html-код для последующей демонстрации его в
браузере Интернета;
выдать содержимое таблицы-справочника в таблицу Excel.
Пример.
Результатом работы такой подпрограммы может быть следующая таблица,
содержащая данные таблицы-справочника о пользователях некоторой информационной
системы:
Пользователи системы
Полное имя пользователя
Администратор
Алипова О. Н.
Гонохов Е.А.
…
Ершова Г.И
Сидоренко Н. А.
Сидоренко-Нормы
Роль
ADM
ПЛАНОВИК
ТЕХНОЛОГ
…
ТЕХНОЛОГ
ТЕХНОЛОГ
НОРМИРОВЩИК
Рисунок 8.1. Пример печатной формы справочника.
48
Для создания такого представления можно сгенерировать примерно следующий html-код,
находящийся в текстовом файле с расширением .htm:
<html><head><title>Пользователи системы</title>
<meta name=GENERATOR content=ATH>
</head>
<body topmargin=0 leftmargin=0 bgproperties=fixed link=#669966 alink=#669966
vlink=#669966>
<TABLE WIDTH=100% CELLSPACING=0 BORDER=0><TR><TH>Пользователи
системы</TH></TR></TABLE><BR>
<TABLE WIDTH=100% CELLSPACING=0 BORDER=1 style='border-collapse:collapse'>
<TR>
<TH bgcolor=White WIDTH=50%><font size=1 color=Black>Полное имя
пользователя</TH>
<TH bgcolor=White WIDTH=50%><font size=1 color=Black>Роль</TH>
</TR>
<TR>
<TD>Администратор</TD>
<TD>ADM</TD>
</TR>
<TR>
<TD>Алипова О. Н.</TD>
<TD>ПЛАНОВИК</TD>
</TR>
…
<TR>
<TD>Сидоренко Н. А.</TD>
<TD>ТЕХНОЛОГ</TD>
</TR>
<TR>
<TD>Сидоренко-Нормы</TD>
<TD>НОРМИРОВЩИК</TD>
</TR>
<TR>
</TR>
</TABLE>
</body> </html>
 Задание:
Разработайте универсальную процедуру для формирования твердой копии содержимого
таблицы базы данных в виде html-кода в текстовом файле. Добавьте возможность вызова
этой процедуры в Вашу программу просмотра и редактирования справочников

Другая возможность – выдать содержимое справочника в электронную таблицу Microsoft
Excel. Примерный код требуемой универсальной процедуры следующий:
procedure TCatalog.Print;
var ExcelApp, Sheet, c: Variant;
i,k,j:Integer;
f:TField;
49
begin
Grid.DataSource.DataSet.DisableControls; // Отключение набора данных от
визуальных
// компонентов, связанных с ним
k:=Grid.Columns.Count-1;
соответствующем
try
Grid.DataSource.DataSet.First;
// номер последнего столбца в
// компоненте TDBGrid
// Перейти к первой записи справочника
// Получить доступ к приложению Excel с помощью OLE-automation
ExcelApp := CreateOleObject('Excel.Application');
// Добавить рабочую книгу
ExcelApp.Workbooks.Add(1);
// Получить ссылку на первый лист первой рабочей книги
Sheet:=ExcelApp.Workbooks[1].Worksheets[1];
Try
// Попытаться задать имя листа совпадающим с заголовка окна
формы
Sheet.Name:=Caption;
except
end;
// В верхнюю левую ячейку листа записать содержимое заголовка окна
формы
c:=Sheet.Cells[1,1];
c.Font.Bold:=True; c.Font.Size:=15;
c.Value:=Caption;
// В следующую ячейку листа записать дату формирования твердой копии
c:=Sheet.Cells[2,1];
c.Font.Italic:=True;
c.Value:='Сформировано '+DateTimeToStr(Now);
Sheet.Cells[3, 1].Value:='¹№п/п';
for i:=0 to k do
// Перечислить имена полей справочника в том
порядке,
begin
// как они заданы в соответсвующем компоненте TDBGrid
c:=Sheet.Cells[3, 2+i];
c.Value := Grid.Columns[i].Title.Caption;
end;
j:=1;
while not Grid.DataSource.DataSet.Eof do
begin
// Организовать цикл по всем записям справочника
Sheet.Cells[j+2, 1].Value:=j;
for i:=0 to k do
begin
// Организовать цикл по всем полям записи справочника
c:=Sheet.Cells[j+2, 2+i];
try
// Получить ссылку на очередное поле
f:=Grid.DataSource.DataSet.FieldByName(Grid.Columns[i].FieldName );
// Занести значение поля в очередную клетку листа
50
c.Value:=f.Value;
except
end;
end;
// Перейти к следующей записи справочника
Grid.DataSource.DataSet.Next;
// Перейти к следующей строке листа электорнной таблицы Excel
j:=j+1;
end;
except
on e:Exception do ShowMessage('Ошибка:'+e.Message);
end;
Grid.DataSource.DataSet.EnableControls; // Подключение набора данных к
визуальным
// компонентам
ExcelApp.Visible := True;
// Сделать Excel видимой для
пользователя
end;
 Задание:
Реализуйте подпрограмму выдачи результата произвольного SQL-запроса в таблицу Excel.

Работа №9. Просмотр справочников иерархической структуры
Иерархический справочник – это таблица в базе данных, между записями которой
устанавливается (рекурсивное) отношение 1:N. Пример иерархического справочника –
справочник диагнозов болезней или справочник клиентов торговой фирмы, в частности:
Физические лица
Местные
Иванов
Петров
Иногородние
Сидоров
…
Организации
ООО
Гарант-Сервис
…
ОАО
КМК
ЗСМК
…
Прочие
…
1 уровень иерархии
2 уровень иерархии
3 уровень иерархии
2 уровень иерархии
3 уровень иерархии
1 уровень иерархии
2 уровень иерархии
3 уровень иерархии
…
Рисунок 9.1. Справочник иерархической структуры.
Для отражения такой иерархии в структуру таблицы в дополнение к
идентификатору записи вводятся еще два поля: Родитель (PARENT), Потомок (CHILD).
51
Таблица 9.1. Отображение иерархической структуры в реляционной таблице.
ID
1
2
3
4
5
6
7
9
10
11
12
13
14
15
16
17
PARENT
0
1
2
2
1
5
5
6
7
8
6
9
9
9
9
10
CHILD
1
2
3
4
5
0
0
7
0
0
9
0
0
0
10
11
NAME
Физические лица
Местные
Иванов
Петров
Иногородние
Сидоров
…
ООО
Гарант-Сервис
…
ОАО
КМК
ЗСМК
…
Прочие
…
 Задание:
Разработайте универсальный класс (THCatalog) для просмотра иерархических
справочников, и на его основе реализуйте формы просмотра (а в последствии и
редактирования) справочников.

Этот класс должен быть основан на модальной форме. Основной интерфейсный
элемент в этой форме – компонент класса TDBGrid (по имени Grid). Форма должна
создаваться динамически по мере запроса на вывод окна просмотра-редактирования
справочника. В элементе Grid должны присутствовать необходимые для просмотра поля
справочника (искусственные коды, уникально идентифицирующие запись в справочнике,
не должны быть видны по умолчанию, однако следует создать элемент управления,
позволяющий сделать их видимыми).
Для просмотра такого справочника следует использовать не TADOTableкомпонент, а TADOQuery. Для него следует задать выражение SQL-запроса, которое
позволит извлечь записи только одного уровня иерархии. Для этого придется ввести в
SQL-запрос параметр, задающий значение поля PARENT, по которому будет
осуществляться выборка.
SELECT PARENT, CHILD, NAME FROM CLIENTS WHERE PARENT = :p
В этом выражении :p – обозначение параметра запроса по имени ‘p’.
После вставки этого кода в свойство SQL компонента TADOQuery (договоримся, что его
имя – Q), в свойстве Parameters образуется один элемент, соответствующий параметру ‘p’.
Необходимо в редакторе параметров TADOQuery определить его тип – в нашем случае
Integer.
Для выборки записей самого верхнего уровня иерархии следует задать значение
параметра p равным 0. Значение параметра SQL-запроса можно задать следующим
образом (компонент TADOQuery по имени Q):
Q.Close;
Q.Parameters.ParamByName(‘p’).Value := 0;
Q.Open;
Для перехода на один уровень иерархии вниз необходимо задать соответствующее
значение того же параметра:
52
Var i:Integerl
…
i := Q.FieldByName(‘CHILD’).AsInteger;
//Определить
уровень
текущей записи
Q.Close;
Q.Parameters.ParamByName(‘p’).Value:= i; // Перейти на уровень
сделать его текущим
Q.Open;
потомков
потомков,
Для возврата на предыдущий уровень иерархии придется использовать еще один
компонент TADOQuery (по имени Q1) (см. таблицу 2.), свойство SQL которого должно
содержать код
SELECT PARENT FROM CLIENTS WHERE CHILD = :p1
а параметр ‘p1’ должен будет задаваться в момент, когда нам захочется вернуться на
уровень назад (см. Таблица №2):
Q1.Parameters.ParamByName(‘p1’).Value := Q.FieldByName(‘PARENT’).Value;
Q1.Open;
Q.Close;
Q.Parameters.ParamByName(‘p’).Value :=
Q1.FieldByName(‘PARENT’).AsInteger;
Q1.Close;
Q.Open;
Работа №10. Редактирование справочников иерархической структуры
Имеются 4 случая редактирования справочника, задевающие его иерархическую
структуру.
1.
Для осуществления ввода новой записи на уже существующем уровне необходимо
в поле PARENT новой записи записать общее для всех записей данного уровня значение, а
в поле CHILD занести значение 0.
Level := Q.FieldByName(‘PARENT’).AsInteger;
Q2.SQL.Clear;
Q2.SQL.Add(‘INSERT INTO CLIENTS (PARENT, CHILD) VALUES (:p, 0)’);
// Можно задать тип параметра динамически!
Q2.Parameters.ParamByName(‘p’).DataType := ftInteger;
// Задать значение параметра
Q2.Parameters.ParamByName(‘p’).Value
:= level;
Q2.ExecSQL;
После выполнения этого SQL-запроса, в таблице появиться соответствующая запись, но ее
нельзя будет увидеть на форме просмотра-редактирования справочника до тех пор, пока
SQL-запрос компонента Q не будет выполнен повторно!
Q.Close;
Q.Open;
53
2.
Для создания записи-потомка для записи, которая еще не имеет детей, необходимо
выполнить более сложную работу. Во первых, надо определить значение идентификатора
для записей нового уровня (поле PARENT), во вторых это значение занести в поле CHILD
родительской записи, в третьих в поле PARENT новой записи-потомка записать это
значение, а в поле CHILD занести значение 0:
Q2.SQL.Clear;
Q2.SQL.Add(‘SELECT MAX(PARENT) AS MP FROM CLIENTS’);
Q2.Open;
Level := Q2.FieldByName(‘MP’).AsInteger + 1;
Q2.Close;
Q.Edit;
Q.FieldByName(‘CHILD’).AsInteger
Q.Post;
:= level;
Q2.SQL.Clear;
Q2.SQL.Add(‘INSERT INTO CLIENTS (PARENT, CHILD) VALUES (:p, 0)’);
Q2.Parameters.ParamByName(‘p’).DataType := ftInteger;
Q2.Parameters.ParamByName(‘p’).Value
:= level;
Q2.ExecSQL;
Так как описанные действия достаточно сложны, следует выполнить их в рамках явной
транзакции для того, чтобы обеспечить целостность данных.
Try
DM.AdoConnection1.BeginTrans;
Q2.SQL.Clear;
Q2.SQL.Add(‘SELECT MAX(PARENT) AS MP FROM CLIENTS’);
Q2.Open;
Level := Q2.FieldByName(‘MP’).AsInteger + 1;
Q2.Close;
Q.Edit;
Q.FieldByName(‘CHILD’).AsInteger
Q.Post;
:= level;
Q2.SQL.Clear;
Q2.SQL.Add(‘INSERT INTO CLIENTS (PARENT, CHILD) VALUES (:p, 0)’);
Q2.Parameters.ParamByName(‘p’).DataType := ftInteger;
Q2.Parameters.ParamByName(‘p’).Value
:= level;
Q2.ExecSQL;
Except
DM.AdoConnection1.CommitTrans;
On e:Exception do
begin
DM.AdoConnection1.RollBack;
ShowMessage(e.Message);
End;
54
End;
3.
Для удаления записи справочника, не последней на текущем уровне,
просто удалить ее из таблицы
следует
Q2.SQL.Clear;
Q2.SQL.Add(‘DELETE FROM CLIENTS WHERE ID = :t’);
Q2.Parameters.ParamByName(‘t’).DataType := ftInteger;
Q2.Parameters.ParamByName(‘t’).Value
:= Q.FieldByName(‘ID’).AsInteger;
Q2.ExecSQL;
Q.Close;
Q.Open;
4.
Для удаления последней на текущем уровне справочника записи следует
выполнить более сложную последовательность действий: во первых удалить запись из
таблицы, во вторых записать 0 в поле CHILD родительской записи, в третьих перейти к
записям родительского уровня
// Запомнить уровень удаляемой записи
level := Q.FieldByName(‘PARENT’).AsInteger;
// Удалить ее
Q2.SQL.Clear;
Q2.SQL.Add(‘DELETE FROM CLIENTS WHERE ID = :t’);
Q2.Parameters.ParamByName(‘t’).DataType := ftInteger;
Q2.Parameters.ParamByName(‘t’).Value
:= Q.FieldByName(‘ID’).AsInteger;
Q2.ExecSQL;
// Определить уровень родительской записи
Q2.SQL.Clear;
Q2.SQL.Add(‘SELECT PARENT FROM CLIENTS WHERE CHILD = :t’);
Q2.Parameters.ParamByName(‘t’).DataType := ftInteger;
Q2.Parameters.ParamByName(‘t’).Value
:= Q.FieldByName(‘ID’).AsInteger;
Q2.Open;
// Запомнить его
newLevel
:= Q2.FieldByName(‘PARENT’).AsInteger;
// Обнулить ссылку на детей – их больше нет у родительской записи
Q2.SQL.Clear;
Q2.SQL.Add(‘UPDATE CLIENTS SET CHILD = 0 WHERE CHILD = :t’);
Q2.Parameters.ParamByName(‘t’).DataType := ftInteger;
Q2.Parameters.ParamByName(‘t’).Value
:= level;
Q2.ExecSQL;
// Открыть уровень, который содержит родительскую запись (теперь она
уже не родительская!)
Q.Close;
Q.Parameters.ParamByName(‘p’).Value := newLevel;
Q.Open;
55
Разумеется, весь код следует выполнить в рамках явной транзакции.
Возникает вопрос: а как определить, является ли удаляемая запись последней на текущем
уровне? Для этого можно, например, узнать количество записей, возвращенных SQLзапросом, вызвав свойство RecordCount соответсвующего объекта класса TADOQuery:
i
:= Q.RecordCount;
либо выполнить соответсвующий SQL-запрос с помощью еще одного объекта класса
TADOQuery (назовем его qKOL). Такой компонент можно создать динамически,
воспользоваться им, а затем уничтожить:
qKol := TADOQuery.Create;
qKol.Connection
:= DM.DBC;
qKol.SQL.Add(‘SELECT COUNT(*) AS KOL_VO
PARENT=:p ‘);
with qKol.Parameters(‘p’) do begin
DataType
:= ftInteger;
Value := …
End;
qKol.Open;
i
:= qKOL.FieldByName(‘KOL_VO).AsInteger;
q.Kol.Close;
FreeAndNil(qKol);
FROM
CLIENTS
WHERE
 Задание:
Реализуйте возможность редактирования справочника иерархической структуры в своей
программе.

Работа №11. Разработка программы для ввода основных фактов о предметной
области
Под фактами предметной области будем понимать то, ради чего собственно и
создается приложение. Например, для спорткомплекса таким фактом является то, что
клиент Иванов, проживающий по ул. Металлургов 33, 41 и работающий в ОАО НКМК
купил абонемент на 8 посещений тренажерного зала по пятницам, в 17.00, заплатив за
него 1000 руб.
 Задание:
Реализуйте программу для ввода в базу данных фактов, наблюдаемых в Вашей
предметной области. Для этого следует использовать возможность задания свойств с
помощью таблиц-справочников. Программа должна поддерживать ввод новых фактов,
исправление ошибочно введенных и удаление неверных фактов. Интерфейс программы –
на Ваш вкус.

Работа №12. Разработка системы регламентированной отчетности
Система регламентированной отчетности является основой для анализа и принятия
решений в стандартных ситуациях. Поэтому набор отчетов, входящих в
регламентированную отчетность, должен быть достаточно широк и полон. Такие отчеты
строятся регулярно, часть из отчетов должна включать только сильно агрегированные
56
данные, дающие обобщенное представление о ситуации в предметной области а часть
более детальны. Т. к. регламентированная отчетность формируется персоналом,
работающим с приложением как пользователи (операторы, администрация, аналитики), то
отчеты должны быть хорошо продуманы как с точки зрения внешнего вида, так и с точки
зрения содержащейся в них информации.
Средства для построения отчетов в Delphi:
1. Компоненты QuickReport.
2. Комбинация SQL-запросов с экспортом их результатов в Excel (по аналогии
с формированием твердой копии справочников).
3. В Delphi 7 включены новый генератор отчетов RAVE.
4. Имеются несколько внешних генераторов отчетов, наиболее известные
(хотя и являющиеся представителями продуктов двух совершенно разных
классов) FastReport и Crystal Reports.
 Задание:
Сформируйте несколько отчетов (2-3), дающих представление о состоянии предметной
области, поддерживаемой Вашим приложением. При этом можно воспользоваться любым
из доступных средств формирования отчетов. Включить отчеты в главное меню
приложения.

Работа №13. Перенос базы данных на Microsoft SQL Server 2000
На настоящий момент база данных и соответствующая прикладная
информационная система в основном реализованы. Для обеспечения работы в
многопользовательской среде и для повышения масштабируемости прикладной системы
может потребоваться преобразование формата базы данных из файл-серверной СУБД
Access в клиент-серверную СУБД. Целевой СУБД естественно выбрать СУБД
Microsoft SQL Server 2000. Такой выбор обусловлен наличием удобных средств миграции
в нее и минимальными потребностями в переделке прикладной системы.
 Задание:
Произведите преобразование базы данных в формат SQL Server. Для этого
воспользуйтесь мастером Access. Узнайте у администратора имя сервера, на котором
развернут SQL Server, идентификатор и пароль пользователя. Проанализируйте разные
режимы преобразования, изучите отчет о процессе преобразования, формируемый
мастером.

 Задание:
С помощью утилиты Enterprise Manager, установленной на Вашем компьютере,
соединитесь с только что полученной базой данных и проанализируйте ее отличия от базы
данных на Access. Обратите внимание на отличия в типах данных (например, во что
преобразовался тип данных “счетчик” и др.)

 Задание:
Обеспечьте наличие диаграммы Вашей базы данных в SQL Server (создайте ее).
Проанализируйте средства отображения диаграммы и сравните их с аналогичными для
схемы данных в Access.

57
 Задание:
Получите скрипт на языке T-SQL для создания (развертывания) Вашей базы
данных “с нуля”.

 Задание:
Выполните настройку UDL-файла, используемого в Вашем приложении для
доступа к базе данных Access посредством интерфейса ADO, для доступа к новой базе
данных SQL Server.
Подсказка: основные параметры, которые следует изменить – провайдер данных, имя
сервера и имя базы данных.
Проверьте функционирование Вашего приложения с новой базой данных. В случае
неудовлетворительного функционирования следует разобраться в причинах этого
(сначала самостоятельно, если не удастся – с преподавателем).

Работа №14. Хранимые процедуры и триггеры
Хранимые процедуры – это объект SQL Server, содержащий
откомпилированных операторов для выполнения некоторого алгоритма.

набор
Более подробно хранимые процедуры и триггеры описаны в главе 11 Курса лекций.
Пример.
Пусть имеется 2 таблицы:
Person(PersonID INTEGER IDENTITY(1,1),
FirstName VARCHAR(50),
SurName VARCHAR(50),
BIRTHDATE DATETIME)
и
Adress(PersonID INTEGER, Adress VARCHER(50))
Тогда для ввода данных за раз в обе таблицы можно воспользоваться загружаемой
процедурой:
CREATE PROCEDURE PersonInsert
@FirstName VarChar(50),
@SurName VarChar(50),
@BIRTHDATE DateTime = NULL,
@PersonAdress VARVHAR(50)
AS
DECLARE @PersonID INT
INSERT INTO Person (FirstName, SurName, BIRTHDATE)
VALUES (@FirstName, @SurName, @ BIRTHDATE)
SET @PersonID = IDENT_CURRENT(‘Person’)
INSERT INTO Adress(PersonID, PersonAdress)
VALUES (@PersonID, PersonAdress)

Для запуска процедуры на выполнение из интерактивной утилиты (например, Query
Analyser) можно написать:
58
EXEC PersonInsert ‘Коля’, ‘Иванов’, ’15.05.1988’,
‘Новокузнецк пр.Металлургов, 33, 41’
В программе на Delphi для этого следует воспользоваться компонентом TADOStoredProc.
Триггер – это особый вид хранимой процедуры, способный реагировать на события.
Создадим триггер для отслеживания и запрета ввода дублей имен людей в таблицу
PERSON. Кроме того, этот же триггер будет использоваться для отметки о вводе сведений
о новом человеке в таблицу протокола. Данный триггер относится к категории AFTER, т.
е. выполняется после осуществления модификации данных. Но до завершения
транзакции! Поэтому, единственный способ отменить ошибочные действия (например,
ввод дубликатной информации) заключается в откате транзакции. (Вспомним, что
существуют и триггеры BEFORE (перед, до выполнения операции). (Имеются также и
триггеры INSTEAD OF, выполняющиеся вместо …).
Пример.
В дополнение к имеющимся таблицам введем еще одну:
LOG(PERSONID INTEGER, DAT DATETIME, UN VARCHAR(50))
Она будет использоваться для протоколирования операций добавления/изменения данных
в таблице PERSON. Поле PERSONID содержит идентификатор человека, DAT – время
операции ввода/изменеия, UN – имя оператора, выполнившего изменение.
CREATE TRIGGER LOGNEWS
ON PERSON
FOR INSERT, UPDATE
AS
BEGIN TRANSACTION
DECLARE @PERSONID INTEGER
DECLARE @C INTEGER
DECLARE @SURNAME VARCHAR(50)
DECLARE @FIRSTNAME VARCHAR(50)
SELECT @C = COUNT(*)
FROM PERSON, inserted i
WHERE PERSON.SURNAME = i.SURNAME AND
i.FIRSTNAME
PERSON.FIRSTNAME =
IF @C >1
BEGIN
RAISERROR(‘Вы пытаетесь ввести данные о
зафиксированном в базе данных!’, 16, 1)
ROLLBACK TRANSACTION
END
ELSE
BEGIN
SELECT @PERSONID = i.PERSONID FROM inserted i
человеке,
уже
INSERT INTO LOG(PERSON, DAT, UN)
59
VALUES (@PERSONID, GETDATE(), USER)
COMMIT TRANSACTION

END
 Задание:
Реализуйте в своей базе данных хранимую процедуру и триггер, имеющие смысл в
Вашей конкретной предметной области. Обеспечьте вызов хранимой процедуры в
программе на DELPHI. Проверьте результаты работы хранимой процедуры и факт
срабатывания триггера.

Работа №15. Разработка системы нерегламентированной отчетности (аналитическая
система) на основе OLAP. Первый подход
Система нерегламентированной отчетности – это система, позволяющая
формировать заранее не предусмотренные, разнообразные отчеты, которые могут помочь
при ответе на заранее не предвиденные вопросы. Что особенно важно, такая система
должна позволить аналитикам, т. е. специалистам в конкретной прикладной области а не
ИТ-персоналу, оперативно получать доступ к данным с целью удовлетворения
собственных информационных запросов. Основой системы нерегламентированной
отчетности обычно является технология OLAP (online analytical processing), в основе
которой, в свою очередь, лежит многомерная модель данных.

Более подробно принципы OLAP описаны в главе 13 Курса лекций.
В данной работе воспользуемся Microsoft Excel в качестве программы-сервера для
организации анализа.
В работе необходимо
1.
Сформировать SQL-запрос или представление для анализируемой базы
данных.
2.
Подключиться к SQL-запросу или представлению через Excel и
сформировать сводную таблицу на основе
2.1. результата SQL-запроса или представления
2.2. локального (его еще называют клиентским) куба OLAP для чего
предварительно его создать.
3.
Произвести анализ путем отображения данных из куба в сводной таблице
Excel в разных ракурсах и с разными степенями агрегации.
4.
Построить графическую диаграмму по данным сводной таблицы.
Пример:
Пусть на сервере Microsoft SQL Server 2000 имеется база данных SportSQL,
структура которой представлена на рис.15.1. База данных содержит сведения о клиентах
спортивного комплекса. При этом таблица USERS описывает клиентов, таблица
ABONEMENT – абонементы клиентов, таблица TIPS – виды и атрибуты занятий, таблица
TIPSP – классы занятий, таблица ABOTIME – посещения занятий, таблица PAYMENTS –
платежи клиентов, таблица PURPOSE – цели платежей.
1. Создадим представление для использования в целях анализа платежей клиентов
по следующим измерениям: по временным интервалам, по целям платежей, по видам
занятий, по классам занятий, по клиентам. Это означает, что в представление должны
60
войти все перечисленные измерения, а также поле SUMMA из таблицы PAYMENTS,
которое мы будем рассматривать как меру:
CREATE VIEW PAYS AS
SELECT dbo.Users.Name AS Клиент, dbo.TIPS.NAME AS ЗАнятие,
TIPS1.NAME AS КлассЗанятий, dbo.PAYMENTS.SUMMA AS Сумма,
dbo.PAYMENTS.DAT AS Дата, dbo.PURPOSE.NAME AS Цель
FROM dbo.PAYMENTS
LEFT OUTER JOIN dbo.Users ON dbo.Users.ID = dbo.PAYMENTS.USERID
LEFT OUTER JOIN dbo.PURPOSE ON dbo.PURPOSE.ID =
dbo.PAYMENTS.PURPOSEID
LEFT OUTER JOIN dbo.Abonement ON dbo.Abonement.ID =
dbo.PAYMENTS.ABONEMID
LEFT OUTER JOIN dbo.TIPS ON dbo.TIPS.ID = dbo.Abonement.TipID
LEFT OUTER JOIN dbo.TIPS TIPS1 ON TIPS1.ID = dbo.TIPS.IDPARENT

По поводу терминов измерение и мера а также о схеме “звезда” см. Курс лекции,
глава 13.
Рисунок 15.1. Схема базы данных.
2. Создать сводную таблицу в Excel.
2.1. Для создания сводной таблицы в Excel, запустить мастер сводных таблиц
(Данные/Сводная таблица). В мастере выбрать “Создать таблицу на основе данных,
находящихся во внешнем источнике данных”:
61
Рисунок 15.2. Выбор источника данных
2.2. На втором шаге мастера нажать кнопку “Получить данные” и выбрать “Новый
источник данных”. Задать имя нового источника, выбрать подходящий драйвер
(SQL Server, например), и, нажав кнопку “Связь”, задать имя компьютера, на
котором работает сервер СУБД и имя Вашей базы данных на этом сервере.
Рисунок 15.3. Параметры соединения с базой данных
a.
2.3.
b.
2.4.
В открывшемся окне Microsoft Query выбрать представление PAYS, которое в
нашем примере служит основой для анализа.
Перенести все поля представления в область таблицы данных. В результате на
экране появится результат открытия запроса:
62
Рисунок 15.4. Результат запроса
После этого можно выйти из Microsoft Query, указав, что построенный запрос должен
быть передан в сводную таблицу.
2.5.
В мастере сводных таблиц нажать кнопку “Готово”.
Рисунок 15.5. Заготовка для сводной таблицы
В Excel возникнет заготовка для сводной таблицы и список полей, с которыми можно в
ней работать. Перетаскивая поля сводной таблицы в колонки, строки и область данных
можно организовать формирование самых разнообразных отчетов.
63
Например:
Рисунок 15.6. Сводка по целям платежей и видам занятий
 Задание:
Изучите самостоятельно возможности сводной таблицы по проведению анализа
деталей и формированию графической диаграммы.

 Задание:
Если, выполняя п. 2.4. не закрыть окно Microsoft Query, как рекомендуется, а
воспользоваться пунктом меню (Файл/Создать куб OLAP), то открывается ряд новых
возможностей. Выполните мастер создания кубов и сохраните куб для сводной таблицы
Excel.

 Задание:
Проведите анализ (сформируйте сводную таблицу) на основе полученного
локального куба. Попробуйте выявить различия в возможностях сводных таблиц,
основанных на данных из запроса и на данных из куба.

Работа №16. Разработка системы нерегламентированной отчетности на основе
OLAP. Второй подход
Рассмотрим альтернативный способ разработки системы нерегламентированной
отчетности. В данной работе воспользуемся инструментом “BI-клиент для ATH”
(программа MLibQu и OLE-сервер LibQu) для организации анализа.
В работе необходимо
1.
Сформировать аналитическую схему и аналитическое решение для
анализируемой базы данных.
2.
Провести анализ с использованием гибких запросов, сводной таблицы
(кросс-таблицы) и диаграммы.
Пример:
64
Пусть на сервере Microsoft SQL Server 2000 имеется база данных SportSQL, о
которой упоминалось в предыдущей работе. При этом таблица USERS описывает
клиентов, таблица ABONEMENT – абонементы клиентов, таблица TIPS – виды и
атрибуты занятий, таблица TIPSP – прайс-листы по занятиям, таблица ABOTIME –
посещения занятий, таблица PAYMENTS – платежи клиентов, таблица PURPOSE – цели
платежей, таблица COACHES – тренеров, таблица COACHTIME – сеансы работы
тренеров.
1.
Создадим аналитическую схему для анализа посещений занятий клиентами по
видам занятий и тренерам. Для этого следует:
Запустить MLibQu.
Воспользоваться пунктом меню Выбрать ADO-источник данных, указав в качестве
такового UDL-файл Вашего приложения.
Создать аналитическую схему типа “снежинка”, представленную на рис. 16.1. Этого
можно достичь путем вызова контекстного меню, из которого можно выбрать
требуемые таблицы базы данных. После того, как нужные таблицы выбраны,
следует задать связи между ними примерно также, как это делается в инструменте
“Схема данных” Access или “Диаграмма” Enterprise Manager SQL Server. Не
забудьте указать центральную таблицу аналитической схемы (контекстное меню
заголовка таблицы); она выделяется цветом заголовка.
Рисунок 16.1. Описанная аналитическая схема. (На ней показано и контекстное
меню добавления таблиц.)
2.
3.
Сгенерировать аналитическое решение (выбрав пункт меню или кнопку на
инструментальной панели).
Для верификации схемы и решения можно выполнить SQL-запрос, на котором
основана схема, применив соответствующие инструменты.
65
4.
Сохранить аналитическое решение.
После этого можно приступать собственно к анализу.
5.
Протестировать аналитическое решение. Для этого следует воспользоваться
одноименными инструментами. В результате открывается инструмент анализа –
“гибкие запросы” и OLAP.
Рисунок 16.2. Панель “гибких запросов”.
 Задание:
Изучите самостоятельно возможности извлечения данных с помощью “гибких
запросов” (в том числе фильтрацию, отбор групп (касается только агрегированных
данных) и сортировку).

 Задание:
Проведите самостоятельно анализ с помощью кросс-таблицы и диаграммы (в
частности сравните возможности кросс-таблицы по работе с календарными датами и
возможности сводной таблицы Excel).

 Задание:
Изучите возможности сохранения различных аналитических представлений “на
потом” и способы их вызова для повторного использования.

5.3. Методические рекомендации преподавателю
Преподавателю необходимо изложить материал в доступной для студентов форме. В
тоже время, не следует опускаться на уровень упрощенных подходов, необходимо
сохранить научную основу содержания курса и логику изложения.
66
При изучении дисциплины следует использовать ЭВМ и соответствующие средства
обучения (см. раздел 1.1.6.) в ходе проведения лабораторных занятий. Это необходимо
для того, чтобы студенты могли овладеть практическими приемами моделирования
данных и знаний и соответствующими инструментами.
Вообще, главный акцент при изучении курса делается на соотнесении его
теоретического содержания (модели данных, инфологическое моделирование, теория
нормализации, модели знаний) с практической стороной дела – ведь только на основе
практики можно действительно глубоко овладеть весьма сложными фундаментальными
понятиями и начать ориентироваться в современных подходах и достижениях в данной
области.
Методы обучения
Обучение студентов осуществляется по традиционной технологии (лекции,
лабораторные занятия) с включением инновационных элементов – применение
тестирующих программ в текущей и итоговой аттестациях а также элементов проектного
метода обучения при выполнении курсовой работы (см. разделы 5.2.2., 5.2.3.).
С точки зрения методов чтения лекций, наиболее целесообразным представляется
использование информационно-объяснительной и проблемной лекций.
Методика чтения лекций
Методика чтения учебной лекции включает ряд практически важных вопросов,
касающихся формы изложения материала: способ его подачи, темп чтения лекции, язык и
словарный запас лектора, освещение дискуссионных вопросов.
Для лекций наиболее приемлемым следует признать средний темп изложения
материала, так как это связано с новизной понятий дисциплины и множеством формул,
которые студент должен записать. Также необходимо делать отступления по ходу лекции
с целью приведения практических примеров.
Что касается манеры изложения, то наиболее приемлемой является так называемый
академический стиль, для которого характерна четкость и ясность формулировок,
хорошая литературная форма, владение голосом, хорошая дикция, умение держаться
перед аудиторией и устанавливать с ней контакт, поддержание дисциплины.
Лабораторные занятия наиболее целесообразно проводить по схеме:
 изложение базовых технических основ, касающихся инструментария и методов,
применяемых на занятии
 самостоятельное выполнение заданий по теме занятия
Проведение занятий следует соотнести с выполнением курсовой работы. Поэтому на
нескольких первых занятиях приобретаются технические навыки и проверяются на
практике теоретические положения, а на последующих занятиях они закрепляются и
используются для выполнения проекта в рамках курсовой работы (см. разделы 5.2.2.,
5.2.3.).
Важно, чтобы темы курсовой работы, избранные студентами, часть из которых
объединяется в проектные группы, были всесторонне обсуждены как с преподавателем,
так и с прочими студентами, входящими в учебную группу – можно использовать форму
защиты темы проекта перед учебной группой. Кроме того, первостепенное значение имеет
качество инфологической модели, разработанной в рамках избранной темы, поэтому
приступать к практической реализации баз данных и знаний, а также информационных
систем на их основе студентам следует только после того, как эта модель будет обсуждена
и признана преподавателем.
Цель лабораторных занятий – научить студентов применять теоретические знания
при решении практических задач, возникающих в ходе выполнения проекта в рамках
курсовой работы. Таким образом, оказывается возможным предельно приблизить условия
выполнения заданий к тем, которые характерны для реальной ситуации разработки
информационной системы в рамках коллектива профессионалов. Это максимально
67
способствует более тесному знакомству студента с методами проектирования и
разработки информационных систем на основе баз данных и баз знаний.
На практических занятиях должны преобладать следующие методы:
 практические (выполнение конкретных заданий на первых 2-3 занятиях,
выполнение заданий связанных с темой курсовой работы на следующих
занятиях);
 вербальные (преобладающим методом должно быть объяснение).
Подготовка преподавателя к проведению занятия имеет первостепенное значение.
Каким бы опытом преподаватель не обладал, он все равно должен готовиться к каждому
лабораторному занятию.
Во-первых, преподавателю необходимо проработать тему занятия.
Во-вторых, преподаватель должен владеть техникой выполнения всех заданий.
Преподаватель должен быть готов ответить на любые вопросы, относящиеся к
содержанию каждого задания.
В-третьих, желательно на каждом занятии выполнять тотальный контроль
выполнения заданий всеми студентами.
68
5.4.
График организации самостоятельной работы студентов при
очной форме обучения
Общее кол-во часов по учебному плану - 130час.
70 часа Аудиторная работа
60 час. Самостоятельная работа
Виды самостоятельной учебной
Формы аудиторных учебных занятий (час.)
работы (час.)
№
неде
ли
36 часа
Лекции
№ и тема лекции
1
Базы данных и модели данных.
Введение в реляционную модель
данных.
2
3
Реляционная алгебра
4
36 часа
Лаборато
рные
работы
20 час.
Изучение
теоретического
материала
2
2
2
2
2
2
2
2
2
2
20 час.
Решение
практических задач
2
Инфологическое
проектирование.
2
2
2
6
7
Нормализация данных.
2
2
2
2
2
2
2
2
2
1
1
2
2
1
1
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
36
34
20
20
9
10
10
11
12
13
13
Физическая организация
данных и СУБД.
баз
Язык SQL.
Параллельная работа с базами
данных. Транзакции.
14
15
16
Архитектуры доступа к БД.
Системные аспекты.
Информационные
хранилища.
OLAP-технология.
Полуструктурированная модель
данных.
17
Перспективы
технологий БД
ИТОГО
18
развития
Индивидуальн
ые задания
2
5
8
28 час.
2
2
2
2
28
2
2
2
2
2
2
2
28
69
5.5.
График организации самостоятельной работы студентов при
заочной форме обучения
Объем часов
Аудиторная работа
№
Название и содержание
разделов, тем, модулей,
видов учебной работы
Общи
й
(час.)
1
2
3
140
Учебный план групп
APC-06
Лабораторные
занятия
(час.)
Самостоя
тельная
работа
(час.)
4
5
6
8
10
122
Лекции
(час.)
Примечания,
дополнительные
указания,
методические
материалы,
технические
средства и др.
7
Порядок организации самостоятельной работы
Контрольная работа:
Задание 1
План-конспект теоретического материала
по вопросам к экзамену.
Требования по написанию курсовой работы
Задание 2
Тест по теме «Реляционная теория»
Задание 3
Тест по теме «Инфологическое
моделирование»
Задание 4
Тест по теме «Нормализация»
Задание 5
Тест по теме «Язык SQL»
ИТОГО по контрольной работе
Аудиторные занятия
ИТОГО
Формы контроля
36
Консультации
преподавателя по графику
Вопросы
к зачету
(экзамену)
См. п. 4 Рабочей
программы
10
20
22
См. п. 7 Рабочей
программы
Контрольная
работа Задания
№№ 2-5
20
108
8
10
8
10
Экзамен или зачет.
Допуск к зачету
122
Условие допуска:
1.
Представление письменных тезисов по вопросам
изучения теоретического материала.
2.
Представление отчетов о выполнении письменных
практических работ.
Курсовая работа в учебном плане группы.
Самостоятельную работу по дисциплине следует начать сразу же после установочной лекции и получения
задания. Для работы необходимо ознакомиться с учебным планом и установить, какое количество часов отведено
учебным планом в целом на изучение дисциплины, на аудиторную работу с преподавателем на лекционных и
практических (семинарских) занятиях, а также на самостоятельную работу.
Затем нужно познакомиться с заданиями письменных практических работ и примерным объемом времени,
предполагаемым на их выполнение, составить в отдельной тетради (можно выполнить план работы в тетради для
теоретического материалы по дисциплине) понедельный план работы и установить минимальные еженедельные
результаты и их вид.
К началу сессии студент выполняет все задания по плану, оформляет их и сдает на проверку не позднее, чем
за 2 недели до начала занятий. Кроме того, готовит к аудиторной работе с преподавателем список вопросов,
которые не удалось разобрать самостоятельно в межсессионный период, а также тетрадь с планами-конспектами
по теоретическому материалу дисциплины.
70