- •Содержание
- •Введение
- •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. Критерии оценки курсового проекта
- •Рекомендуемая литература приложения
- •Календарный план-график
- •Содержание
- •Список использованных источников
- •Список использованных источников
Пример транзитивной зависимости: а) отношения между объектами с транзитивной зависимостью; б) отношения между объектами без транзитивной зависимости
Пример графического описания связей между отношениями
На рисунке 10 представлены связи между отношениями, характеризующими контрагента.
Рисунок 10 – Связи с отношением Contractor
Во вновь построенных и преобразованных таблицах проверяются первичные ключи. Если первичный ключ таблицы оказывается слишком длинным, неудобным для идентификации строк и для поддержания связей в БД, то в таблицу вводится дополнительное поле – искусственный первичный ключ. Этот ключ может быть известен пользователю и играть роль кода или номера объекта или быть внутренним ключом, автоматически создаваемым СУБД и обрабатываемым приложением. Изменение первичного ключа в одной таблице распространяется на соответствующие внешние ключи связанных таблиц.
Для всех столбцов нормализованных таблиц, используя описание соответствующего атрибута, задается имя и подбирается формат (тип) данных из поддерживаемых СУБД. Подлежащие контролю ограничения атрибутов оформляются логическими выражениями на языке выбранной СУБД.
Затем в логическую структуру БД вносятся связи, заданные между сущностями концептуальной схемы. Способ представления связи в реляционной модели данных зависит от ее типа. Связь типа «один к одному» при обязательном участии каждого объекта в связи означает, что экземпляры связанных сущностей могут появляться только вместе – парами. Например, договор и его смета в схеме, представленной на рисунке 18. В таком случае обычно нецелесообразно разделять эти сущности по отдельным таблицам. Следует образовать одну таблицу с полным набором столбцом и первичный ключ одной из таблиц считать ключом объединяющей таблицы.
Другой возможный тип связи «один ко многим» реализуется созданием в таблице со многими связанными строками (со стороны связи, помеченной «М») дополнительных столбцов, образующих внешний ключ. Столбцами внешнего ключа должны стать столбцы первичного ключа, таблицы с единственной связываемой записью. Например, для реализации связи «один ко многим» между заказчиком с его заявками (см. рисунок 18) в таблицу «Заявка» следует включить внешний ключ – номер заказчика. Если в связи «один ко многим» сущность со стороны помеченной «М» является слабой и обязательно должна быть связана с одним экземпляром сущности со стороны помеченной «1», то для внешнего ключа такой связи устанавливается свойство контроля ссылочной целостности. Для примера связи заказчика с его заявками проверка ссылочной целостности необходима. Обычно связью «один ко многим» с контролем ссылочной целостности реализуется связь справочной таблицы с информационной. При этом одной строке справочной таблицы может соответствовать ноль или несколько строк в информационной таблице.
Последний тип связи «многие ко многим» (M:М) реализуется с помощью дополнительной связывающей таблицы, с которой каждая из исходных таблиц имеет связь «один ко многим». Для этого в связывающую таблицу вводятся в качестве внешних ключей первичные ключи связанных таблиц. Причем их объединение может стать первичным ключом в связывающей таблице. При необходимости структура связывающей таблицы может быть дополнена столбцами, содержащими атрибуты связи. Например, фрагменту концептуальной схемы вида представленному на рисунке 10 соответствует логическая схема, пред-