МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

Пензенский государственный университет

Институт информатики и вычислительной техники

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

Методические указания по курсовому проектированию

Кафедра «Информационное обеспечение управления и производства»

Разработал: к.т.н., доцент

Усманова И.В.

2005

В рамках курсового проектирования по дисциплине «Проектирование баз данных систем документооборота» выполняется разработка интерфейса пользователя для работы с БД некоторой предметной области. Для конечного пользователя должна быть обеспечена возможность хранения данных, обработки по крайней мере трех запросов пользователя и средства автоматизированной подготовки хотя бы двух документов.

Примерный перечень предметных областей для курсового проектирования

1. Отдел сбыта хлебозавода

2. Кафедра университета

3. Диспетчерская вуза

4. Продовольственный магазин

5. Зоопарк

6. Библиотека

7. Архив

8. Отдел кадров производственной фирмы

9. Отдел маркетинга коммерческого предприятия

10. Поликлиника

11. Деканат вуза

12. Аэропорт

13. ЖЭУ

14. Негосударственный учебный центр

15. АТС

16. Автосалон

17. Магазин игрушек

18. Оптовая торговая фирма

19. Фонотека радиостанции

20. Агрофирма

21. Футбольный клуб

22. Троллейбусное депо

23. Косметический салон

24. БД управляющего складом

25. Канцелярия университета

26. Отдел маркетинга фирмы, занимающейся производством мебели

27. БД менеджера туристической фирмы

28. Информационно-справочная система для издательства

Тема курсовой работы может быть выбрана самостоятельно и обязательно должна быть согласована с руководителем курсового проектирования. В курсовой работе может быть рассмотрен любой аспект деятельности выбранной организации. Поэтому единственными требованиями к формируемым с помощью БД документам являются: использование в документе данных одной из таблиц БД в табличной форме представления; наличие текстовой составляющей в тексте документа.

Частные ограничения целостности задаются в соответствии с особенностями выбранной предметной области.

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

В процессе выполнении курсовой работы необходимо знание следующего теоретического материала (таблица 1).

Таблица 1 – Основные этапы выполнения курсовой работы

Раздел курсовой работы	Тема лекции	Тема практического занятия	Тема лабораторной работы
Структура БД	2. Моделирование системы баз данных 6 Функциональные зависимости 7 Нормализация отношений базы данных	1. Основы семантического моделирования 2. Проектирование БД на основе модели типа объект/отношение	1. Разработка структуры базы данных
Ограничения целостности данных	3 Введение в реляционные базы данных 4 Целостность реляционных данных	2. Проектирование БД на основе модели типа объект/отношение 3. Поддержка ограничений целостности в стандарте языка SQL	1. Разработка структуры базы данных 2. Частные ограничения целостности данных БД
Вопросы надежности взаимодействия	-	-	3. Надежность программ обработки данных
Разработка и реализация запросов пользователя	5. Реляционная алгебра	4. Основы реляционной алгебры	4. Средства автоматизации работы конечных пользователей 5. Обработка данных с помощью запросов 6. Работа с отчетами 7. Работа с главной кнопочной формой
Безопасность данных	1. Система баз данных и ее структура	-	7. Работа с главной кнопочной формой

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

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

Ниже приведен типовой бланк задания на курсовое проектирование.

Пензенский государственный университет

К афедра ИнОУП

УТВЕРЖДАЮ

Зав. кафедрой ______________

«____» _______________ 20 г.

Задание на курсовое проектирование по курсу п роектирование баз данных систем документооборота

С туденту Группа

Т ема проекта Разработка интерфейса пользователя для работы с базой данных

Исходные данные (технические требования) на проектирование

Д ано: предметная область базы данных:

Р азработать: 1. Для заданной предметной области разработать структуру базы данных, включающей не менее 5 отношений. Каждое отношение должно содержать 3-5 атрибутов, определенных на доменах различных типов. Диаграмма объект/отношение должна содержать не менее 4 правильных объектов, хотя бы__ одно смысловое отношение типа М-М и типа М-1.___________________________

2 . Выделить имеющиеся в базе данных функциональные зависимости и выполнить нормализацию полученных отношений (если это необходимо).

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

а ) обработка запросов пользователей, реализующих все операции реляционной алгебры;_______________________________________________________________

б ) организация надежного способа взаимодействия пользователя и системы;

в) поддержание общих и частных ограничений целостности данных;

г ) автоматизация подготовки двух документов.

Объем работы по курсу

1. Расчетная часть

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

2. Графическая часть

3. Экспериментальная часть

Р езультаты решения контрольного примера.

Р аспечатки образцов подготовленных документов.

Срок выполнения проекта по разделам

1 Структура БД к 20 г.

2 Ограничения целостности данных к 20 г.

3 Вопросы надежности взаимодействия к 20 г.

4 Разработка и реализация запросов пользователя к 20 г.

5 Безопасность данных к 20 г.

6 к 20 г.

7 ____________________________________________________ к _________ 20 г.

8 ____________________________________________________ к _________ 20 г.

Дата выдачи задания « » 20 г.

Дата защиты проекта « » 20 г.

Руководитель_____________________

З адание получил « » 20 г.

Студент _________________________

Методические указания к выполнению разделов курсовой работы

1 Разработка структуры бд

Разработать структуру БД – значит определить, какие таблицы входят в БД и из каких атрибутов состоит каждая из них, а также выяснить, каким образом таблицы БД связаны между собой.

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

Они должны быть обеспечены в первую очередь при проектировании и использовании любой БД. Однако прежде чем их привести, дадим еще несколько важных определений.

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

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

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

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

Существуют два общих ограничения целостности: правило целостности и правило ссылочной целостности.

Правило целостности утверждает, что среди значений потенциального ключа не должно быть null-значений. Null-значение – это неопределенное, пропущенное значение в столбце.

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

Проектирование структуры БД до сих пор остается субъективным процессом, т.к. качество полученного результата во многом зависит от интуиции разработчика. Однако существенную помощь в решении этой проблемы могут оказать идеи семантического моделирования, основной задачей которого является выяснение смысловых взаимосвязей между элементами данных. Эти взаимосвязи должны быть отражены на диаграмме «объект/отношение».

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

Данная ситуация отражается на диаграмме «объект/отношение» следующим образом. Сначала выделяются объекты, сведения о которых участвуют в приведенном выше описании. Как правило, они мало меняются с течением времени и не зависят от существования других объектов. Такие объекты называются правильными и изображаются на диаграмме «объект/отношение» в виде прямоугольников. К ним относятся объекты «Отдел», «Сотрудник», «Документ» (Рис. 1).

Если существование некоторого объекта зависит от существования другого объекта, то такой объект называется слабым.

Затем для каждого объекта указывается в виде эллипса ключевое свойство, которое в дальнейшем будет использоваться в качестве первичного ключа таблицы (см. определение выше), и помечается специальным отличительным знаком, например, «#». Для объекта «Отдел» в качестве ключевого будем рассматривать свойство «Нотд#» (номер отдела), для «Сотрудник» - «Табн#» (табельный номер), для «Документ» - «Рег#» (регистрационный номер документа).

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

Если одному экземпляру первого объекта соответствует один и только один экземпляр второго объекта, а одному экземпляру второго объекта – один и только один экземпляр первого объекта, то говорят об отношении типа один-к-одному (1-1) между двумя объектами.

Если одному экземпляру первого объекта могут соответствовать несколько экземпляров второго объекта, а одному экземпляру второго объекта – один и только один экземпляр первого объекта, то речь идет об отношении типа один-ко-многим (1-М). Например, для рассматриваемой в примере БД архива один сотрудник может работать только в одном отделе (в случае, если в организации не

Диаграмма «ОБЪЕКТ- ОТНОШЕНИЕ»

1 М

М

М

Список условных обозначений

Нотд# - номер отдела;

Назв – название отдела;

Руков – руководитель отдела;

Табн# - табельный номер сотрудника;

Фио – фамилия и инициалы сотрудника;

Долж – должность сотрудника;

Годрож – год рождения сотрудника;

Рег – регистрационный номер документа;

Тип – тип документа;

Заголовок – заголовок документа;

Коллист – количество листов в документе;

Дата – дата принятия документа в отдел;

Колдок – количество документов.

Рисунок 1 – Диаграмма объект/отношение

разрешено совместительство), но в одном отделе работают несколько сотрудников. Поэтому между объектами «Сотрудник» и «Отдел» указано отношение типа М-1 (Рис. 1).

Если одному экземпляру первого объекта могут соответствовать несколько экземпляров второго объекта, а одному экземпляру второго объекта – несколько экземпляров первого объекта, то говорят об отношении типа многие-ко-многим (М-М). В рассматриваемом примере один документ, хранящийся в архиве, может использоваться для работы в разных отделах, а в одном отделе могут обрабатываться сведения из разных документов. Поэтому между объектами «Отдел» и «Документ» существует смысловое отношение типа М-М (Рис. 1).

После того, как на диаграмме «Объект/отношение» определены объекты данных, их ключевые свойства, смысловые отношения между объектами и их типы, для каждого смыслового отношения указываются внешние ключи для связи с соответствующими объектами. Затем для всех объектов и отношений задаются неключевые свойства (Рис. 1).

На основании построенной диаграммы «Объект/отношение» выполняется проектирование структуры БД. Для этого может быть рекомендовано использование простейшего алгоритма, состоящего из пяти этапов:

1. Выделяются правильные объекты. Им ставятся в соответствие базовые отношения, для каждого из которых определяется первичный ключ. Базовое отношение – это именованная таблица, создаваемая пользователем, причем данные в этой таблице не являются результатом обработки данных из других таблиц. Для БД архива объекту «Отдел» поставим в соответствие таблицу О с первичным ключом Нотд, «Сотрудник» - таблицу С с первичным ключом Табн, «Документ» - Д(Рег). В курсовой работе это оформляется следующим образом:

Сотрудник– С (Табн #)

Отдел – О (Нотд#)

Документы – Д (Рег#)

2. Выделяются отношения многие-ко-многим. Им ставятся в соответствие базовые отношения, для каждого из которых определяются внешние ключи. После этого формируется первичный ключ отношения; как правило, он является комбинацией внешних ключей, если не возражают конечные пользователи, которые будут работать с БД. В противном случае в базовое отношение вводится дополнительный атрибут, который и будет играть роль первичного ключа. Для БД архива отношению ОД поставим в соответствие таблицу ОД с внешними ключами Нотд (для связи с таблицей О) и Рег (для связи с таблицей Д); первичным ключом таблицы будет являться комбинация внешних ключей (Нотд, Рег). Эти соображения документируются на языке определения данных следующим образом:

ОД – ОД (Нотд#, Рег#)

PRIMARY KEY (Нотд#, Рег#)

FOREIGN KEY (Нотд#) REFERENCES О

ON DELETE NO ACTION

ON UPDATE CASCADE

FOREIGN KEY (Рег#) REFERENCES Д

ON DELETE NO ACTION

ON UPDATE CASCADE .

Здесь PRIMARY KEY (Нотд#, Рег#) – описание составного первичного ключа {Нотд#, Рег#}; FOREIGN KEY (Нотд#) REFERENCES О – описание внешнего ключа Нотд#, обеспечивающего связь с таблицей О; ON DELETE NO ACTION – одно из правил внешних ключей, согласно которому нельзя удалять значение первичного ключа Нотд# таблицы О до тех пор, пока на него есть ссылка из внешнего ключа Нотд# таблицы ОД; ON UPDATE CASCADE – при обновлении значения первичного ключа Нотд# таблицы О необходимо одновременно обновить значение внешнего ключа Нотд# таблицы ОД.

3. Выделяются отношения многие-к-одному, в которых участвуют только правильные объекты. Для них новые базовые отношения не создаются. Но в базовое отношение, соответствующее стороне «многие», добавляется внешний ключ для доступа к базовому отношению, соответствующему стороне «один». В качестве внешнего ключа используется первичный ключ базового отношения стороны «один». В БД архива для отношения ОС новой таблицы создавать не будем. Но в таблицу С (сторона «многие») добавляется внешний ключ Нотд для связи с таблицей О (сторона «один»). Эти соображения документируются на языке определения данных следующим образом:

ОС – С (Нотд#, Табн#)

PRIMARY KEY (Табн#)

FOREIGN KEY (Нотд#) REFERENCES О

ON DELETE NO ACTION

ON UPDATE CASCADE

4. Выделяются отношения многие-к-одному, в которых участвуют слабые объекты. Для каждого слабого объекта создается базовое отношение и определяется первичный ключ. Для отношений многие-к-одному новые базовые отношения не создаются, но ставится внешний ключ со стороны «многие» к стороне «один». При указании правил внешних ключей разрешается удаление значений первичных ключей (даже при наличии ссылок на них) вместе с соответствующими значениями внешних ключей. Это означает, что указываются следующие правила:

ON DELETE CASCADE

ON UPDATE CASCADE

На диаграмме «Объект/отношение» для БД архива слабых объектов нет.

5. Каждому неключевому свойству объектов и отношений во всех созданных базовых отношениях ставится в соответствие неключевой атрибут. В БД архива добавляются неключевые атрибуты в каждую созданную таблицу.

На основании всех выше приведенных рассуждений получаем следующую структуру фрагмента БД архива:

О (Нотд, Назв, Руков), первичный ключ – Нотд;

С (Табн, Нотд, Фио, Годрож, Долж), первичный ключ – Табн, внешний ключ – Нотд для связи с таблицей О;

Д (Рег, Назв, Заголовок, Вид, Коллист), первичный ключ – Рег;

ДО (Рег, Нотд, Дата), первичный ключ – (Рег, Нотд), внешний ключ – Нотд для связи с таблицей О, Рег – для связи с таблицей Д, где:

Нотд - номер отдела;

Назв – название отдела;

Руков – руководитель отдела;

Табн - табельный номер сотрудника;

Фио – фамилия и инициалы сотрудника;

Долж – должность сотрудника;

Годрож – год рождения сотрудника;

Рег – регистрационный номер документа;

Вид – вид документа;

Заголовок – заголовок документа;

Коллист – количество листов в документе;

Дата – дата принятия документа в отдел;

Колдок – количество документов.