бумажных документов и значительно упростит работу сотрудников организации.
6.2.Требования к БД
1.Состав хранимой в БД информации.
В данном пункте необходимо определить основные объекты рассматриваемой предметной области, информация о которых должна содержаться в базе данных, и состав этой информации. Возможно, перечисление объектов Вы уже сделали в разделе «Цель разработки базы данных», тогда остается только детализировать информацию.
Минимальное количество основных объектов (сущностей), сведения о которых должны храниться в базе данных, определяется учебным планом по курсовому проектированию баз данных.
При выборе объектов Вы должны предусмотреть взаимосвязь между ними, это является одним из обязательных требований.
Пример.
БД должна содержать информацию следующего вида: А. Информация о членах клуба:
фамилия, имя, отчество;
идентификационный номер;
адрес;
домашний телефон
мобильный телефон;
дата рождения.
Б. Сведения о собаках:
кличка;
номер документа
порода;
дата рождения.
В. Данные о результатах участия собак в выставках: название выставки;
31
номер записи;
дата проведения;
места, занятые собаками на выставке.
Важно! Ключевые поля (свойства) должны быть подчеркнуты. Без указания ключевых полей дальнейшая разработка БД невозможна.
2. Выходная информация.
Это содержание запросов для получения полезной информации из базы данных. Минимальное число запросов устанавливается на усмотрение преподавателя, но не может быть менее 6. Рекомендуемое число запросов 10 и 6, для дневной и заочной форм обучения, соответственно. В числе запросов обязательно должны присутствовать запросы следующих типов:
запросы на выборку с расчетом, выводящие информацию по одному из объектов предметной области;
запросы на выборку, выводящие информацию по нескольким объектам предметной области - запросы на основе связанных таблиц;
запросы на выборку с группировкой;
перекрестные запросы;
запрос-объединение;
запросы действия - здесь необходимо разработать, по крайней мере, по одному запросу на обновление, добавление, удаление, создания таблиц, несколько DDL запросов и т.д.
3 Отчеты. По крайней мере, один из них должен содержать группировку строк и итоговые расчеты.
4. Требования к пользовательскому интерфейсу для работы с базой данных.
В данном пункте ТЗ Вы должны предусмотреть необходимость разработки форм для ввода и корректировки информации в базе данных, а также разработкукнопочной формы для запуска всех созданных запросов, отчетов и форм.
32
6.3.Требования к надежности
Вэтом разделе ТЗ необходимо описать, что Вы предпримете для обеспечения целостности и непротиворечивости информации в БД. Достаточно указать те средства MS Access, которые были изучены при выполнении лабораторных работ.
Внимание! Начинать разработку БД следует только после согласования ТЗ с преподавателем.
Вариант ТЗ для согласования темы может содержать краткую формулировку цели проектирования. Задание должно быть оформлено в виде распечатки, содержащей подпись разработчика (студента), которая сдается для проверки. После утверждения ТЗ используется как основа для первого раздела курсовой работы и дополняется теоретическими аспектами.
Внимание! Изменение темы подписанного преподавателем ТЗ курсовой работы не допускается.
Проектирование структуры базы данных
1. Ошибочно было бы думать, что задача правильной организации данных связана с изучением какой-либо конкретной СУБД. В общей постановке она даже не связана с компьютеризацией. Уже много веков заполняются различные учетные книги, журналы, ведомости, списки. Сложились и определенные правила, по которым определяется, какие данные должны в них входить.
Проектирование БД начинается с построения диаграмм ER-типа (Entity-Relation). Их русское название - диаграммы «сущность-связь». ERдиаграммы отражают структуру информации.
33
Внимательно изучите материалы лекций и раздел 3 данного пособия!!!
На основе ТЗ строится предварительная и уточненная ER-диаграммы.
Рекомендуемое число количество сущностей («прямоугольников») 6-9 и 4-5, для дневной и заочной форм обучения, соответственно.
Таким образом, на первом шаге проектирования создается ERдиаграмма. Для этого должна быть определены все сущности, все связи между ними, все классы принадлежности сущностей и все степени связи. В итоге информация, которая будет храниться в БД, будет структурирована.
Рисунки ER-диаграмм формируются в MS Office Visio. Для отчета по курсовому проектированию рисунки сохраняются в виде рисунков векторной графики и импортируются в документ MS Word.
2.Следующий шаг - формирование структуры данных для хранения информации. Такие структуры получили название отношений.
В соответствии с Правилами построения отношений на основе ERдиаграммы, формируется таблица предварительных отношений.
3.После получения предварительных отношений (в них содержатся пока только ключевые атрибуты) полезно подготовить список всех представляющих интерес атрибутов, которые не входят в ключи сущностей и назначить каждый из этих атрибутов одному из предварительных отношений.
4.Проектирование БД тесно связано с понятием
НОРМАЛЬНОЙФОРМЫ ОТНОШЕНИЯ. Это означает, что проектируемые отношения должно удовлетворять определенным условиям (см. раздел 3).
5.После описания процессов нормализации базы данных, дается описание всехотношений, подлежащихреализации
вСУБД MS Access, а также связей между ними. В соответст-
34
вующей таблице (Таблице окончательных отношений) приво-
дится названия отношений, перечень ключевых и неключевых атрибутов с их названием и, перечень атрибутов, участвующих в образовании связей между таблицами.
На этом проектирование структуры баз данных для решения задачи можно считать законченным.
6.4. Создание БД в MS Access
Далее, по полученным отношениям строятся таблицы базы данных. Их количество и перечень полей определяются из окончательного списка отношений. Характеристики полей задаются в соответствии с логикой и форматом хранимых данных.
При создании схемы данных важно обеспечить целостность связей. Для обеспечения целостности необходимо проследить за тем, чтобы связанные поля в главной и подчиненной таблицах имели одинаковые типы полей, например, табельные номера были бы везде текстовыми и т.д. Требования к целостности данных подразумевают очевидные допустимые значения полей: поле для связи в подчиненной таблице не может содержать значения, которые не описаны в главной, а также пустых значений.
Совет. Для создания правильной схемы данных необходимо заполнить в таблицах несколько строк.
После создания схемы данных и заполнения таблиц можно приступать к разработке запросов. Запросы, отчеты и формы разрабатываются в соответствии с техническим заданием.
Запросы можно создавать в конструкторе.
Важно. Минимальным требованием к пользовательскому интерфейсу, является подключение всех созданных запросов к форме.
35