- •Содержание
- •Введение
- •1 Общие требования к курсОвому проекту
- •1. 1 Цели и задачи курсового проектирования
- •1.2 Требования к выполнению курсового проекта и представлению результатов
- •1.3 Задание на курсовое проектирование и его анализ
- •1.4 Объем и содержание пояснительной записки
- •2.5 Основная часть
- •2.6 Заключение
- •2.7 Список использованных источников
- •2.8 Приложения
- •3 Рекомендации по проектированию реляционной базы данных
- •3.1 Содержание раздела «Построение инфологической концептуальной модели»
- •Концептуальное проектирование базы данных
- •Символы erd, соответствующие сущностям и отношениям
- •Описание сущности
- •Представление связи «один ко многим» с обязательным участием в связи сущности «Заявка»
- •Представление связи «один к одному» с обязательным участием обеих сущностей в связи
- •Представление необязательной связи «многие ко многим»
- •Различные способы представления бинарной связи типа «один ко многим»
- •Способы представления бинарной связи «один ко многим» с обязательным участием сущности в связи
- •Концептуальная схема (диаграмма Питера Чена) для процесса приема и исполнения заказа
- •3.2 Содержание раздела «Построение логической модели реляционной бд» Логическое проектирование базы
- •Пример транзитивной зависимости: а) отношения между объектами с транзитивной зависимостью; б) отношения между объектами без транзитивной зависимости
- •Фрагмент концептуальной схемы
- •Представление связи «многие ко многим»
- •Логическая схема для процесса приема и исполнения заказа
- •Форма в erWin 4.0 для определения типа данных id с целью последующего использования в описании столбцов таблиц
- •Пример задания свойств связи между сущностями «Заказчик» и «Заявка»
- •3.3 Содержание раздела «Физическое проектирование базы данных»
- •3.4 Содержание раздела «Проектирование запросов на языке sql»
- •3.5 Содержание раздела «Реализация законченного приложения, работающего с созданной базой данных» Разработка приложения
- •Графический интерфейс пользователя модуля администратора
- •Графический интерфейс пользователя клиентского приложения
- •Окно ввода данных, для успешной авторизации и аутентификации
- •Форма для управления учетными записями
- •Форма для управления ролями учетных записей
- •Форма для доступа к клиентскому приложению
- •Сообщение выдаваемое, при попытке входа в заблокированный модуль
- •4 Оформление курсового проекта
- •4.1 Текст пояснительной записки
- •4.2 Нумерация и заголовки
- •1 Построение инфологической концептуальной модели
- •1.1 Анализ предметной области
- •4.3 Таблицы
- •4.4 Требования к иллюстративному материалу пояснительной записки
- •4.5 Оформление библиографического указателя (литература). Ссылки на использованные источники
- •Список использованных источников
- •4.6 Оформление приложений
- •4.7 Оформление графического материала
- •4.8 Требования к оформлению проекта на электронном носителе
- •4.9 Требования к оформлению фрагментов программы
- •5 Рекомендации учащимся при защите курсового проекта
- •5.1. Защита курсового проекта
- •Требования к докладу
- •5.2. Критерии оценки курсового проекта
- •Рекомендуемая литература приложения
- •Календарный план-график
- •Содержание
- •Список использованных источников
- •Список использованных источников
Концептуальное проектирование базы данных
Следующим шагом проектирования базы является создание и согласование со специалистами в ПрО концептуальной схемы данных, используемых в автоматизируемых процессах.
Концептуальная схема должна отражать состав и взаимодействие объектов будущей БД. Одной из наиболее популярных семантических моделей данных на этапе инфологического проектирования является неформальная модель «Сущность-Связь» (Entity-Relationship – ER-модель). Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. Такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Для примера рассмотрим наиболее часто использующуюся нотацию Питера Чена, которая представляет собой граф с двумя типами вершин.
Вершины первого типа – сущности, представляют экземпляры реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.) ПрО, обладающих общими атрибутами или характеристиками. Эти вершины отображают прямоугольниками.
Вершины второго типа – отношения в самом общем виде представляют собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.). Эти вершины изображаются ромбами.
Символы ERD, соответствующие сущностям и отношениям, приведены на рисунке 1.
Символы erd, соответствующие сущностям и отношениям
Независимая сущность представляет данные, которые не зависят от других сущностей в системе. При этом отношения с другими сущностями могут, как существовать, так и отсутствовать.
Зависимая сущность представляет данные, зависящие от других сущностей в системе. Поэтому она должна всегда иметь отношения с другими сущностями.
Ассоциативная сущность (ассоциация) – это связь вида «многие-ко-многим» между двумя или более сущностями. Ассоциации рассматриваются как полноправные сущности: они могут участвовать в других ассоциациях точно так же, как независимые сущности; могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.
Неограниченное отношение представляет собой отношение, между независимыми сущностями.
Ограниченное отношение представляет собой отношение между зависимой и независимой сущностями.
Существенно-ограниченное отношение используется, когда соответствующие сущности взаимно-зависимы в системе.
Сущность (как понятие) образуется типизацией множества объектов, похожих по составу информации, требуемой для выполнения автоматизируемых функций. Объекты, использованные на входах, выходах, условиях выполнения и требуемых ресурсах функций в схемах процессов являются основой для образования сущностей. Таким образом, каждой сущности соответствует множество похожих (однотипных) объектов, которым в базе данных будут соответствовать экземпляры сущности. Так, для процесса выполнения заказов на изготовление окон появятся сущности «Заявка», «Заказчик», «Конструкция окна» и т.д. Каждая из этих сущностей является обобщенным представителем множества реально существующих заявок, заказчиков, конструкций. Важно лишь то, что все объекты, образующие сущность, описываются одинаковыми наборами свойств – атрибутов, различающихся значениями у конкретных объектов.
Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретной сущности, но может быть одинаковым для различных сущностей (например, ЦВЕТ может быть определен для многих сущностей: окно, дверь и т.д.). Атрибуты используются для хранения набора данных об объектах ПрО, включаемых в БД. При этом любой атрибут может быть определен как ключевой. Для идентификации ключевого атрибута используется подчеркивание имени атрибута (см. рисунок 2).