
- •Описание предметной области «Кулинария»
- •Описание предметной области
- •Функции системы
- •Определение связей между сущностями
- •Составление тз
- •Задание на этап
- •Общие сведения о системе
- •Общие сведения
- •Цели создания и назначения системы
- •Цели создания мультимедийной системы
- •Назначения системы
- •Требования к системе в целом
- •Требования к функциональности системы
- •Требования к надежности системы
- •Требования по эргономике и технической эстетике
- •Требования к доступности
- •Требования к эксплуатации, техническому обслуживанию, ремонту и хранению
- •Архитектура системы
- •Требования к обеспечению защиты персональных данных
- •Требования к защите информации от несанкционированного доступа
- •Требования по сохранности информации
- •Требования средств защиты от внешнего воздействия
- •Авторское право
- •3.4 Состав и содержание работ по созданию системы
- •Архитектура мис
- •Уровень представления
- •Уровень Бизнес-логики
- •Уровень данных
- •Разработка бд
- •Ход работы
- •Построение инфологической модели бд
- •Построение единой таблицы
- •Приведение таблицы к первой нормальной форме
- •Приведение таблицы ко второй нормальной форме
- •Приведение таблицы к третьей нормальной форме
- •Построение даталогической модели бд
- •Выбор субд
- •Построение физической модели бд
- •Определение запросов к бд
- •Задание на этап
- •Ход работы
- •Заключение этапа
- •7. Проектирование пользовательского интерфейса
- •7.1 Задание на этап
- •7.2 Ход работы
- •7.2.1 Основные задачи Web-приложения
- •7.2.2 Разработка структуры графического интерфейса системы
- •7.2.4 Общая структура интерфейса разделов
- •Приложение 1 Пользовательское соглашение
Приведение таблицы к третьей нормальной форме
Таблица находится в третьей нормальной форме, если она удовлетворяет определению второй нормальной формы, и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. То есть, каждое не ключевое поле не транзитивно зависит от первичного ключа. То есть, в третьей нормальной форме все не ключевые поля зависят только от первичного ключа.
В таблице 5.6 представлена 3НФ сущности “Блюдо”. Первичным ключом является “Код блюда” и представляет собой счетчик.
Код блюда |
ID пользователя |
Код категория блюда |
История создания блюда |
Время приготовления |
Время на кухне |
Острота |
Сложность |
Аллерген |
Пищевая ценность |
Прикрепленный медиа-файл |
Рейтинг |
Код автора |
Дата |
Продукты |
Вес |
В данной таблице все не ключевые поля не зависят друг от друга, они зависят только от ключевого поля. Благодаря внешнему ключу у нас есть информация об авторе статьи. Кроме того, таблица находится в 1-ой и во 2-ой нормальных формах. Из этого можно сделать вывод, что таблица также находится в 3НФ. Кроме того, таблица находится в 1-ой и во 2-ой нормальных формах. Из этого можно сделать вывод, что таблица также находится в 3НФ.
В таблице 5.7 представлены данные о сущности “Блюдо”. Первичным ключом является “ID пользователя” и представляет собой счетчик.
Таблица 5.7 - 2НФ сущности “Пользователь”
ID пользователя |
Логин |
Пароль |
Отображаемое имя |
Избранное |
Код блюда (если пользователь-автор) |
В данной таблице не ключевые поля “Логин”, “Пароль”, “Отображаемое имя” не зависят друг от друга, они зависят только от ключевого поля. В то время как поля “Избранное” и “Код блюда(если пользователь-автор” зависят друг от друга. Поэтому было принято решение создать отдельную связующую таблицу “Избранное”.
В таблице 5.8 представлена связь между пользователем и блюдом, которое он добавил в раздел “Избранное”
Таблица 5.8 - Раздел “Избранное”
ID пользователя |
ID блюда |
В таблице 5.9 представлена 3НФ сущности “Комментарии”.
Таблица 5.9 - 3НФ сущности “Комментарии”
ID комментария |
Код блюда |
ID пользователя |
Дата |
Текст |
В данной таблице не ключевые поля не зависят друг от друга, они зависят только от ключевого поля. Кроме того, таблица находится в 1-ой и во 2-ой нормальных формах. Из этого можно сделать вывод, что таблица также находится в 3НФ.
Построение даталогической модели бд
Даталогическая модель базы данных «Кулинария» представлена на рисунке 5.1
Рисунок 5.1 – Даталогическая модель «Кулинария»
Структура данных даталогической модели:
Всего таблиц: 6
Количество связей 1:М – 7.
Выбор субд
В ходе обсуждения лабораторной работы с группой БСТ2001 и, исходя из опыта предыдущего года, где были проведены тщательные анализ и сравнение СУБД, группой было принято решение выбрать MySQL в качестве основной СУБД, на которой будут выполняться дальнейшие лабораторные работы в бригадах БСТ2001.