Проектирование приложения. 
Разработка мобильного приложения для отображения извещений об изменениях на сайте образовательной программы

В процессе работы над главой 2 предстоит произвести проектирование мобильного приложения. Результаты, полученные в процессе работы над главой 2, будут использованы для реализации мобильного приложения.

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

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

Описание данных.

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

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

Процессы и необходимые для выполнения процессов данные, представлены ниже:

1. Настройка мобильного приложения.

a. Регулярность проверки.

2. Подписки на страницы определенных образовательных программ.

a. Кампус.

b. Академическая степень.

c. Наименование факультета.

d. Наименование образовательной программы.

e. Ссылка на образовательную программу.

f. Раздел.

g. Рубрика.

3. Мониторинг сайта и отображение информации.

a. Ссылка на статью.

b. Дата выхода статьи.

c. Наименование статьи.

d. Статус.

Приведение данных к первой нормальной форме.

Для того, чтобы отношение находилось в 1НФ, значения всех атрибутов должны быть атомарны. Данные представлены ниже:

• · кампус;
• · академическая степень;
• · наименование факультета;
• · наименование образовательной программы;
• · регулярность проверки;
• · ссылка на образовательную программу;
• · раздел;
• · рубрика;
• · ссылка на статью;
• · дата выхода статьи;
• · наименование статьи;
• · статус;

Все представленные значения являются атомарными, следовательно, отношение находится в первой нормальной форме.

Приведение данных ко второй нормальной форме.

Чтобы отношение находилось во второй нормальной форме, необходимо, чтобы оно находилось в 1НФ, и все не ключевые атрибуты функционально полно зависели от потенциального ключа.

Используем отношения в соответствии с процессами, для которых предназначаются хранилище данных: настройки, подписки, мониторинг.

В отношении «Настройки», имеется лишь один атрибут. Добавим к нему ключ «ID», который не будет составным. Таким образом, отношение «Настройки» находится во второй нормальной форме.

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

В отношении «Мониторинг» важнейшим атрибутом является «Ссылка на статью», т.к. именно по ней будет происходить фильтрация статей на прочитанные и не прочитанные пользователем. Существуют одинаковые статьи, доступ к которым предоставляется по разным ссылкам, т.к. они находятся на страницах разных образовательных программ. Необходимо создать дополнительный атрибут «ID статьи», который будет являться первичным ключом. Таким образом, отношение находится во второй нормальной форме, т.к. все атрибуты таблицы функционально полно зависят от первичного ключа.

Отношения представлены в таблице 2.1. Первичные ключи выделены курсивом с подчеркиванием.

Таблица 2.1. Описание данных для настройки приложения

Приведение данных к третьей нормальной форме.

Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится в 2НФ и отсутствуют транзитивные функциональные зависимости не ключевых атрибутов от ключевых.

В отношении «Настройки» отсутствуют транзитивные функциональные зависимости. Можно считать, что отношение находится в третьей нормальной форме.

В отношении «Подписки» отслеживаются следующие транзитивные функциональные зависимости:

• 1. ID образовательной программы — ID кампуса, ID кампуса — кампус.
• 2. ID образовательной программы — ID академической степени, ID академической степени — академическая степень.
• 3. ID образовательной программы — ID факультета, ID факультета — факультет.
• 4. ID образовательной программы — ID раздела, ID раздела — раздел.
• 5. ID образовательной программы — ID рубрики, ID рубрики — рубрика.

Для избавления от этих зависимостей, декомпозируем отношение «Подписки», получив отношения «Кампус», «Академическая степень», «Факультет», «Образовательная программа», «Подписки», «Разделы», «Рубрики». Вид этих отношений представлен в табл.2.1. — 2.2. Ключевые поля выделены курсивом с подчеркиванием.

Таблица 2.2. Результат декомпозиции отношения «Подписки». Часть 1.

Таблица 2.3. Результат декомпозиции отношения «Подписки». Часть 2.

Отношение «Факультет» связано с отношением «Образовательная программа» связью 1: М по атрибуту «ID факультета».

Отношение «Академическая степень» связано с отношением «Факультет» связью 1: М по атрибуту «ID академической степени».

Отношение «Кампус» связано с отношением «Факультет» связью 1: М по атрибуту «ID кампуса».

Отношение «Разделы» связано с отношением «Подписки» связью 1: М по атрибуту «ID раздела».

Отношение «Рубрики» связано с отношением «Подписки» связью 1: М по атрибуту «ID рубрики».

В отношении «Мониторинг» отсутствуют транзитивные функциональные зависимости. Таким образом, можно считать, что отношение находится в третьей нормальной форме.

В процессе проектирования, база данных была спроектирована и нормализована до третьей нормальной формы. Проект базы данных представлен на рис. 2.1.

Рисунок 2.1. ER-диаграмма базы данных.

Результатом работы в данном параграфе является ER-диаграмма базы данных, которая в последствии будет воплощена, как физическая модель данных и будет использована в мобильном приложении для хранения данных.