- •Содержание
- •Общие положения
- •1. Цели и задачи курсовой работы
- •2. Тематика курсовых работ
- •3. Структура и содержание курсовой работы
- •3.1. Пояснительная записка
- •4. Рекомендации по порядку выполнения курсовой работы
- •4.1. Содержание основных разделов работы:
- •5. Методические указания по оформлению пояснительной записки
- •6. Защита курсовойработы
- •Список литературы
- •Образец оформления титульного листа курсовойработы
3. Структура и содержание курсовой работы
Курсовая работа независимо от выбранной темы должна состоять из пояснительной записки и разработанного приложения для работы с базой данных на машинном носителе.Программная среда для разработки базы данных определяется руководителем курсовой работы.
3.1. Пояснительная записка
Материалы в пояснительной записке следует располагать в следующем порядке:
Титульный лист (приложение 1);
Аннотация;
Содержание;
Введение;
Основная часть, включающая несколько разделов:
Системный анализ и анализ требований к базе данных;
Концептуальная (инфологическая) модель предметной области, ER-диаграмма создаваемой базы данных;
Даталогическая модель;
Описание форм, запросов и отчетов в программной среде, выбранной студентом;
Заключение;
Список использованных источников;
Приложения.
4. Рекомендации по порядку выполнения курсовой работы
Стадии
и этапы проектирования баз данных
представлены на рис. 1.
Объекты и связи предметной области
Системный анализ
Определение вида информационной модели (структурированность и динамичность информации; способ представления и характер использования)







Прикладные
задачи
пользователей
Инфологическое проектирование
Определение:
системы атрибутов;
типовых запросов;
типовых процедур обработки





Инфологическая модель

Выбор модели данных (иерархическая, сетевая, реляционная);
Выбор методики (средств) моделирования


Даталогическое проектирование
Разработка
концептуальной схемы БД;
внешних схем;
правил семантической целостности



Логика СУБД
(модель данных)
Даталогическая
(логическая) модель

Физическое проектирование
Отображение даталогической модели в модель данных выбранной СУБД:
Проектирование структур данных и связей
ЯОД и ЯМД
конкретной СУБД


Физическая модель БД
Рис.1 Стадии и этапы процесса проектирования
При написании курсовой работы следует весь процесс разделитьна определенные этапы с точным указанием сроков выполнения работы.Данный график следует согласовать с научным руководителем.
4.1. Содержание основных разделов работы:
Аннотация состоит из трёх ‑ четырех предложений, в которых указывается краткое описание работы. Аннотация должна быть представлена на отдельном листе.
Введениеопределяет мотивы выбора темы курсовойработы, ее актуальность, предмет и объект исследования, краткую постановку проблемы для исследования, определение цели и задач,которые надо решить в ходе работы. Общий объем введения 1-2 страницы.
Основная частьвключает:
4.1.1.Системный анализ и анализ требований, являются первыми выполняемыми задачами, которые закладывают фундамент для решения последующих задач. В этой части курсовой работы предметная область должна быть представлена как система объектов и их взаимосвязей, при этом должны быть определены функционально-информационные требования к их последующему представлению в виде системы взаимосвязанных данных.
На основе анализа определяются:
Функции и характеристики разрабатываемой базы данных;
Интерфейс продукта с другими системными элементами;
Ограничения, которые должны быть учтены при разработке;
Состав и характеристики входной и выходной информации.
4.1.2. Описание концептуальной (инфологической) модели. Важнейшая цель проектирования - выработка непротиворечивой структурированной интерпретации реально существующей информации изучаемой предметной области и взаимодействия между ее структурными компонентами.
Начальной стадией проектирования системы баз данных является построение семантической модели предметной области, которая базируется на анализе свойств и природы объектов предметной области и информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а ее результат — концептуальной (инфологической)моделью предметной области (объектом моделирования здесь является предметная область будущей системы).
Такие модели обобщенно представляют информационные потребности пользователей создаваемой системы в части использования хранимых данных и по существу являются средством коммуникации как разработчиков, так и пользователей на разных стадиях жизненного цикла базы данных.
Назначение инфологических моделей определяет и некоторые специфические требования к средствам их представления. Такие модели не зависят от технических и программных средств их реализации и должны быть адекватны предметной области, при их разработке должны соблюдаться требования формализованности, обеспечивающие возможность автоматизированной обработки, в том числе, например, автоматический контроль непротиворечивости; дружественности, обеспечивающие возможность использования наглядных графических средств отображения и обработки их пользователем.
Одним из наиболее популярных средств формализованного представления предметной области систем, ориентированных на обработку фактографической информации, является модель «сущность — связь», которая положена в основу значительного количества коммерческих CASE-продуктов, поддерживающих полный цикл разработки систем баз данных или отдельные его стадии.
Моделирование предметной области в этом случае базируется на использовании графических диаграмм, включающих сравнительно небольшое число компонентов. Семантическую основу ER-модели составляют следующие предположения:
та часть реального мира (совокупность взаимосвязанных объектов), сведения о которых должны быть помещены в базу данных, может быть представлена как совокупность сущностей;
каждая сущность обладает характеристическими свойствами (атрибутами), отличающими ее от других сущностей и позволяющими ее идентифицировать;
взаимосвязи объектов могут быть представлены как связи - сущности.
Сущность. Сущность, с помощью которой моделируется класс однотипных объектов, определяется в как «предмет, который может быть четко идентифицирован». Так же как каждый объект уникально характеризуется набором значений свойств, сущность должна определяться таким набором атрибутов, который позволял бы различать отдельные экземпляры сущности. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах). Например, для однозначной идентификации каждого экземпляра сущности «Сотрудник» вводится атрибут «Табельный номер», который вследствие своей природы будет всегда иметь уникальное значение в рамках предприятия. То есть, уникальным идентификатором сущности может являться атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, однозначно отличающая любой экземпляр сущности от других экземпляров сущности того же типа.
Сущность имеет имя, уникальное в пределах модели.
Атрибут – любая характеристика (свойство) сущности, значимая для рассматриваемой предметной области. Атрибуты предназначены для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
Правила для атрибутов сущности:
Каждый атрибут должен иметь уникальное имя.
Сущность может обладать любым количеством атрибутов.
Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута.
Если наличие некоторого свойства для всех экземпляров сущности не является обязательным, то такое свойство называется условным. Например, не все сотрудники обладают свойством «ученая степень».
Связи. Кроме связей между объектом и его свойствами, инфологическая модель отражает связи между объектами предметной области.Связьопределяется как «ассоциация, объединяющая несколько сущностей».
4.1.2.1. Построение ER-диаграммы
Одна из основных целей семантического моделирования состоит в том, чтобы результаты анализа предметной области были отражены в достаточно простом, наглядном, но в то же время формализованном и достаточно информативном виде.
В этом смысле ER-диаграмма является очень удачным решением. В ней сочетаются функциональный и информационный подходы, что позволяет представлять как совокупность выполняемых функций, так и отношения между элементами системы, задаваемые структурами данных. При этом графическая форма позволяет отобразить в компактном виде (за счет наглядных условных обозначений) типологию и свойства сущностей и связей, а формализмы, положенные в основу ER-диаграмм, позволяют использовать на следующем шаге проектирования логической структуры базы данных строгий аппарат нормализации.
Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. В качестве имени обычно используются существительные (или обороты существительного) в единственном числе.
Свойства. Свойства служат для уточнения, идентификации, характеристики или выражения состояния сущности или связи. Свойства отображаются в виде прямоугольников со скругленными краями, содержащих имя свойства. Эллипс соединяется с соответствующей сущностью линией. Свойства, являющиеся условными, соединяются с сущностями пунктирной линией.
Имена ключевых свойств подчеркиваются, например, свойство «Табельный номер» сущности СОТРУДНИК.
Договор
Название клиента
Контактное лицо
Признак группы
Телефон
Код клиента
Адрес клиента






Заключает и оплачивает оплачивает
КЛИЕНТ
№ договора
Дата начала тура
Дата окончания
Дата платежа
Код клиента
Код тура
Число туристов
Цена тура





Код сотрудника


Выполняет
Сотрудник
ФИО
Должность
Телефон
Дата найма
Дата рождения
Код сотрудника
Размер оклада






Определяет
Страна
Код тура
Регион
Название страны


1
М
М
М
1
1
Рис.2 ER-диаграмма БД «Туристическое агентство»
4.1.3. Описание даталогической модели. Задачей следующей стадии проектирования системы базы данных является выбор подходящей СУБД и отображение в ее среду (структуру данных) спецификаций инфологической модели предметной области. Эту стадию называют логическим (или даталогическим) проектированием базы данных, а ее результатом является даталогическая модель базы данных, включающая определение всех информационных элементов и связей, в том числе задание типов, характеристик и имен.
Получение реляционной схемы из ER-диаграммы выполняется по следующим правилам:
каждая простая сущность превращается в таблицу. Имя сущности становится именем таблицы;
компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы.
связи «многие ко одному» и «один к одному» становятся внешними ключами;
индексы создаются для первичного ключа, а также внешних ключей и тех атрибутов, которые будут часто использоваться в запросах.
Рис.3 Даталогическая модель БД. «Туристическое агентство»
На рис.3 в графической форме изображены таблицы, соответствующие отношениям, приведенным на ER-диаграмме на рис.2. Определены столбцы, первичные и внешние ключи таблиц.
Все таблицы находятся в третьей нормальной форме, т.е.:
каждый столбец таблицы неделим, и в рамках одной таблицы нет столбцов с одинаковыми по смыслу значениями (1НФ);
первичные ключи однозначно определяют запись, все поля каждой из таблиц зависят от ее первичного ключа(2НФ);
значение любого неключевого поля не зависит от значения другого неключевого поля, а зависит от первичного ключа таблицы.
Кроме структуры таблиц, в разделе должны быть определены домены(типы) данных, хранящихся в столбцах таблиц. Параллельно необходимо сформулировать ограничения целостности и перечень допустимых значений поля.
Исходя из особенностей данных и их функционального назначения, требуется задать способ представления, максимальную длину, границы возможных изменений для каждого из столбцов таблиц.
В каждой из таблиц должны быть выделены столбцы, которые обязательно должны быть заполнены, кроме того, для незаполненных столбцов могут быть определены значения по умолчанию.
Пример определения параметров атрибутов таблицы «Студент» представлен в таблице 3.
Таблица 3
|
Наименование столбца |
Тип данных |
Ограничения и комментарии |
|
Код студента |
Целое число |
Значение уникально |
|
ФИО студента |
Строка символов длиной 30 |
Значение не должно быть пустым |
|
Дата рождения |
Дата/время |
краткий формат даты |
|
Код группы |
Целое число |
Значение не должно быть пустым |
4.1.4. В разделе «Описание форм, запросов и отчетов в программной среде», выбранной студентом должно быть представлено описание объектов, разработанных студентом с целью удовлетворения информационных потребностей потребителя, выявленных при проведении системного анализа предметной области. Описание структуры объектов (форм, запросов и отчетов) приводится по методологии и в терминологии выбранной студентом программной среды.
