Размещено на http://www.allbest.ru/

Хранение данных пользователя провайдером

Ушакова С. Н., Соловьев И. И., Свиридова И. В.

ФГАОУ ВО «Белгородский государственный национальный

исследовательский университет», Белгород

Белгород, Россия (308015, г. Белгород, ул. Победы, 85)

sviridova@bsu.edu.ru



Аннотация

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

Ключевые слова: данные, пользователь, провайдер.



USER DATA STORAGE PROVIDER

Ushakova S. N., Soloviev I. I., Sviridova I. V.

Federal STATE Autonomous educational institution "Belgorod state national research University", Belgorod

Belgorod, Russia (308015, Belgorod, Pobeda street, 85)

sviridova@bsu.edu.ru

Abstract: in this work was the analysis of the user's data storage provider. The analysis was the scheme of interrelation of the provider with the client. The result was errors in the database, logical and physical database model "service Provider".

Keywords: data, user, provider.



В 21 веке каждый человек без исключения пользуется интернетом. Провайдеры обеспечивают связь между Интернетом и желающими пользоваться им.

Провайдер -- поставщик интернет-услуги; организация, предоставляющая услуги доступа к сетиИнтернети иные связанные с Интернетом услуги.

Пользователь - лицо, заключившее договор с провайдером на предоставление каких-либо услуг.

База данных хранит всю информацию пользователей, а именно текстовые сообщения, аудио- и видео-файлы, документы. Помимо этого база данных обязана хранить историю посещённых сайтов + соответствие времени, IP-адреса и учётной записи пользователя. Информация хранится достаточно долгое время (около 3-х лет). Доступ к этой информации имеют только соответствующие органы. Пользователь не может удалить эту информацию. Удалить ее - значит взломать систему провайдера, что уголовно наказуемо.

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

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

Провайдер хранит все данные пользователя. Каждому пользователю присваивается уникальный номер.В базе данных пользователь может быть передающим и принимающим. В качестве принимающего пользователя может выступать web-страница, так как абоненты могут обмениваться сообщениями не только между собой, но и общаться на различных форумах, поэтому в базе данных хранится ссылка на нее.

Помимо этого в базе данных хранится информация об устройстве, с которого было отправлено сообщение, его ip-адрес и вид связи.

2. СХЕМА ВЗАИМОСВЯЗЕЙ

На рисунке 1.2.1 показана схема взаимосвязей провайдера с клиентом.

Рис.1.2.1. Схема взаимосвязей провайдера с клиентом

Схема взаимосвязей провайдера с клиентом содержит процессы, которые преобразуют данные; потоки данных, которые переносят данные; активные объекты, которые производят и потребляют данные; хранилища данных, которые пассивно хранят данные.

3. РАЗРАБОТКА РЕЛЯЦИОННОЙ МОДЕЛИ БАЗЫ ДАННЫХ

В результате детального анализа предметнойобласти, построения функциональной структуры и схемы потоков данных были выделены следующие объекты:

1. Пользователи

2. Информация

3. Устройства

4. Вид устройства 5. Вид связи

6. Вид сообщения

7. Принимающий пользователь

8. Вид принимающего пользователя

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

Теперь построим реляционную (логическую) модель. У данной модели есть следующие связи:

• Устройства - Вид устройства: У одного устройства может быть несколько разновидностей.

• Вид связи - Устройства: У одного устройства может быть несколько видов связи, а несколько видов связи могут относиться к одному устройству.

• Устройства - Информация: Устройства подразделяются на передающие и принимающие.

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

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

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

• Принимающий пользователь - Вид принимающего пользователя: Каждого пользователя можно отнести к двум категориям.

• Пользователи - Принимающий пользователь: У одного пользователя может быть несколько видов, но у одного вида может быть только один пользователь.

На рисунке 2.1 представлена логическая модель базы данных «Провайдер».

Рис.2.1. Логическая модель базы данных «Провайдер»

4. НОРМАЛИЗАЦИЯ БАЗЫ ДАННЫХ

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

База данных должна быть приведена к третьей нормальной форме. Логическая модель базы данных отображена на рис. 2.1.

На этапе нормализации базы данных «Провайдер» были выявлены некоторые ошибки, вследствие чего реляционная модель была не совсем корректной. В данном случае в роли принимающего пользователя может выступать как частное лицо, так и web-страница. Эти ошибки представлены на рис. 3.1.



Рис. 3.1. Выявленные ошибки в базе данных

Поэтому, целесообразно вместо таблицы «Web-страница» создать две таблицы: «Принимающий пользователь» и «Вид принимающего пользователя».

Рис. 3.2. Приведение таблиц к третьей нормальной форме

На этапе нормализации базы данных «Провайдер» были устранены ошибки и создана физическая модель базы данных (рис.3.3).

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



Рис.3.3. Физическая модель базы данных «Провайдер»

5. ИЗУЧЕНИЕ ORACLE

Пакет OracleDatabase 10gExpressEdition (OracleDatabaseXE) является свободно распространяемой версией СУБДOracle. Работа с СУБД выполняется с помощью интуитивно понятного WEB-интерфейса браузера. С помощью этого интерфейса можно выполнять все основные операции по созданию таблиц баз данных, установлению связей между таблицами, вводу данных, созданию запросов, отчетов, администрированию пользователей.

Версия OracleDatabase 10g. ExpressEditionDemo (XE). является бесплатной и содержит следующие ограничения:

1. Поддерживает БД до 4 Гбайт;

2. На одном сервере может быть запущен только один экземпляр базы OracleXE;

3. При наличии на сервере нескольких процессоров, OracleXE использует только один из них;

4. OracleXE использует не более 1 Гбайта оперативной памяти, не зависимо от объема доступной памяти.

Не смотря на ограничения на основе OracleXE можно создавать приложения для широкого круга задач.



6. РЕАЛИЗАЦИЯ В ORACLE

Для работы с СУБД Oracle нужно установить этот программный продукт. На наш компьютер мы установили OracleDatabase 10g. ExpressEdition. Чтобы получить доступ к OracleXE идем к домашней странице GoToDatabaseHomePage. При этом открывается окно входа в систему (рис.5.1). Мы создали нового пользователя с нашим именем и паролем. Далее будем работать под этим именем.

Рис. 5.1. Вход в систему OracleXE

Приступаем к созданию таблицы нашей базы данных. На рисунке 5.2 представлена физическая модель базы данных «Системы хранения данных пользователей провайдером».

Рис. 5.2. Физическая модель БД

Создадим таблицу USERS. Выбираем вкладку «ObjectBrowser», далее нажимаем Create ->Table. 2. Открывается меню для создания таблицы.

Заполним поля (Columns) таблицы.

Рис. 5.3. Создание таблицы USERS

Далее нажимаем Next. Открывается форма для создания Ключа (PrimaryKey): Выбираем «Populatedfrom a newsequence», задаем ключевое поле - в нашем случае ID_User (рис. 5.4).

Рис. 5.4. Создание первичного ключа в таблице Users

Нажимаем кнопку Next. Открывается форма для задания внешнего ключа (ForeingKey). Пример создания внешнего ключа представлен на рисунках 5.8 и 5.13 таблиц User_Receiving и Informationсоответсвенно. Если внешний ключ не задается, нажимаем Далее. Открывается форма для создания Ограничений (Constraints). При отсутствии ограничений нажимаем Finish. Следующая форма сообщает о том, что пользователем создана таблица (рис. 5.5).



Рис. 5.5. Таблица Users - успешно создана

Таким образом, мы создали все 8 таблиц нашей базы данных (рис. 5.6 - 5.13).

Рис. 5.6. Создание таблицы Type_User_Receiving

Рис. 5.7. Создание таблицы User_Receiving



Рис. 5.8. Создание внешнего ключа в таблице User_Receiving

Рис. 5.9. Создание таблицы Type_Device

Рис. 5.10. Создание таблицы Type_Communication



Рис. 5.11. Создание таблицы Device

Рис. 5.12. Создание таблицы Information

Рис. 5.13. Создание внешних ключей таблицы Information

7. ВВОД ДАННЫХ В ORACLE

После создания всех таблиц - мы заполняем их данными. Запоним данными таблицу Users. Чтобы заполнить таблицу, выбираем вкладку Data, кнопку InsertRow. В появившуюся форму заносим данные (рис. 6.1).

Рис. 6.1. Заполнение данных таблицы Users

Далее нажимаем Create, затем кнопку InsertRow. Заполняем данные на следующего пользователя. В результате заполнения полей таблицы появляется список всех пользователей (рис. 6.2).

Рис. 6.2. Данные таблицы Users

Таким образом, мы заполнили все 8 таблиц данными (рис. 6.3 - 6.9).

Рис. 6.3. Заполнение данных таблицы Type_User_Receiving

Рис. 6.4. Данные таблицы User_Receiving

Рис. 6.5. Данные таблицы Type_Device

Рис. 6.6. Данные Type_Communication



Рис. 6.7. Данные таблицы Device

Рис. 6.8. Заполнение данных таблицы Information

Рис. 6.9. Данные таблицы Information



8. глобальное представление в oracle

Представление - это предопределенный запрос к одной или нескольким связанным таблицам. Результат представления - это таблица, содержащая данные из других таблиц, полученных с помощью выполнения запроса. При изменении данных в базовых таблицах, автоматически меняются данные их представления. Представления не хранятся как физическая таблица. Вместо этого Oracle хранит только определенные представления.

Преимущества представлений:

1. Безопасность - позволяет ограничивать доступ к строкам базовых таблиц.

2. Упрощенная организация запросов.

3. Конфиденциальность - представления позволяют скрывать имена базовых таблиц.

4. Независимость от данных - если интенсивно использовать таблицы реконструктор в несколько таблиц, то изменение структуры можно скрыть за представлением объединений нескольких таблиц.

Для нашей базы данных мы создали два представления, одно из которых является глобальным (состоит из всех таблиц БД).

В первое представление RECORDS_INFORM происходит объединение нескольких таблиц (INFORMATION, USERS, TYPE_USER_RECEIVING, TYPE_DEVICE, DEVICE, MESSAGE, USER_RECEIVING) с помощью where по первичным и вторичным ключам.

Листинг 1. Представление RECORDS_INFORM

CREATE VIEW RECORDS_INFORM(

ID_INFORM,

SENDING_SURNAME,

TYPE_RECEIVING,

RECEIVING_SURNAME,

DEVICE_SENDING,

DEVICE_RECEIVING,

DATE_TRANSFER,

TYPE_MESSEGE)

AS

Select

INFORMATION.ID_INFORMATION, USERS.SURNAME, TYPE_USER_RECEIVING.TYPE_RECEIVING,

USERS.SURNAME, TYPE_DEVICE.NAME_DEVICE, TYPE_DEVICE.NAME_DEVICE, INFORMATION.DATE_TRANSFER, MESSAGE.TYPE_MESSAGE

from INFORMATION, USERS, TYPE_USER_RECEIVING, TYPE_DEVICE, DEVICE, MESSAGE, USER_RECEIVING

where USERS.ID_USER=INFORMATION.ID_USER_SENDING and USER_RECEIVING.ID_USER_RECEIVING=INFORMATION.ID_USER_RECEIVING and

TYPE_USER_RECEIVING.ID_TYPE_USER_RECEIVING=USER_RECEIVING.ID_TYPE_USER_RECEIVING and DEVICE.ID_DEVICE=INFORMATION.ID_DEVICE_SENDING and

TYPE_DEVICE.ID_TYPE_DEVICE=DEVICE.ID_TYPE_DEVICE and

MESSAGE.ID_MESSAGE=INFORMATION.ID_MESSAGE;

Рис. 23. Созданное представление «RECORDS_INFORM»



Второе созданное представление RECORDS_GLOBAL - является глобальным представление. Оно объединяет таблицы: INFORMATION, USERS, TYPE_USER_RECEIVING, TYPE_DEVICE, DEVICE, MESSAGE, USER_RECEIVING с помощью where по первичным и вторичным ключам. В этом представлении выводятся данные из всех созданных таблиц.

Листинг 2. Представление RECORDS_GLOBAL

CREATE VIEW RECORDS_GLOBAL(

ID_INFORM,

SENDING_SURNAME,

TYPE_RECEIVING,

RECEIVING_SURNAME,

DEVICE_SENDING,

IP_DEVICE_SENDING,

DEVICE_RECEIVING,

IP_DEVICE_RECEIVING,

DATE_TRANSFER,

TYPE_MESSEGE) AS

select

INFORMATION.ID_INFORMATION, USERS.SURNAME, TYPE_USER_RECEIVING.TYPE_RECEIVING, USERS.SURNAME, TYPE_DEVICE.NAME_DEVICE, DEVICE.IP_DEVICE, TYPE_DEVICE.NAME_DEVICE,

DEVICE.IP_DEVICE, INFORMATION.DATE_TRANSFER, MESSAGE.TYPE_MESSAGE from INFORMATION, USERS, TYPE_USER_RECEIVING, TYPE_DEVICE, DEVICE, MESSAGE,

USER_RECEIVING where USERS.ID_USER=INFORMATION.ID_USER_SENDING and

USER_RECEIVING.ID_USER_RECEIVING=INFORMATION.ID_USER_RECEIVING and

TYPE_USER_RECEIVING.ID_TYPE_USER_RECEIVING=USER_RECEIVING.ID_TYPE_USER_RECEIVING

and DEVICE.ID_DEVICE=INFORMATION.ID_DEVICE_SENDING and

TYPE_DEVICE.ID_TYPE_DEVICE=DEVICE.ID_TYPE_DEVICE and

MESSAGE.ID_MESSAGE=INFORMATION.ID_MESSAGE;

Рис. 24. Созданное представление «RECORDS_GLOBAL»

9. Схема распределения данных

Для полного представления работы базы данных составим схему распределения базы данных (рис. 8.1).

Условные обозначения:

1. Каждому серверу соответствует свой цвет. Серверу Пользователь соответствует красный цвет, серверу Провайдер - синий.

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

3. Горизонтальная черта цвета сервера соответствует вертикальной фрагментации по столбцам таблицы.

4. Таблица в рамке цвета сервера соответствует дублированию, то есть данные таблицы полностью хранятся на сервере, соответствующего цвета.

5. Стрелка соответствует направлению распространения изменений данных таблицы.

Рис. 8.1. Схема распределения данных

При возникновении проблем проектирования средств Oracle нужно подумать, какие результаты анализа могут оказать нам помощь в определении того, как распределять данные внутри приложения. Шесть свойств сущностей, которые важны для обеспечения распределения данных:

• Готовность. В течении какого времени должна быть доступна информация.

• Достоверность.Насколько важно иметь доступ к актуальному значению.

• Видимость. Насколько широкие полномочия предоставляются при запросе.

• Доступность.Как часто необходимо запрашивать информацию.

• Мутируемость.Насколько широкие полномочия предоставляются при изменении.

• Изменчивость.Как часто требуется изменять информацию.

Если сущность можно разбить на несколько частей, то анализ также должен дать схему фрагментации, которую мы подразделяем на три части:

• Описание. Все соответствия, которые могут использоваться для разбиения сущности на части;

• Анализ свойств сущностей. Порядок определения частей;

• Выводы по распределению. Точка, из которой будет запрашиваться и обновляться каждая часть, т.е. видимость, готовность, мутируемость и изменчивость части сущности.

По указанной схеме для обеспечения распределения данных опишем все 8 таблиц нашей базы данных.

Таблица «Пользователь».

1. Описание

При запросе должны возвращать все значения таблицы. Эти данные используются при отправке и передаче сообщений. Также эти данные могут передаваться по требованию иных служб. Провайдер только может получать доступ к записям, а сами данные о пользователе могут изменяться только самим пользователем вне конкретной базы данных.

2. Анализ свойств сущностей

• Готовность - максимальная

• Достоверность - максимальная

• Видимость - средняя

• Доступность - высокая

• Мутируемость - низкая

• Изменчивость - низкая

3. Выводы по распределению

Экземпляры данных о пользователе могут располагаться на каждом сервере в сети. В этом случае можно также считать все копии этих данных, кроме одной, неизменяемыми -- за исключением ситуации, когда изменения копируются из обновляемой копии в другие.Если распределение данных поможет сократить число обращений по глобальной сети, то такое решение выглядит привлекательно.

Таблица «Принимающий пользователь»

1. Описание

При запросе должны возвращаться либо данные о пользователе или адрес web-страницы, на которую принимающий пользователь передал информацию. Эти данные используются при отправке и передаче сообщений. Также эти данные могут передаваться по требованию иных служб. Провайдер только может получать доступ к записям, а сами данные о пользователе могут изменяться только самим пользователем вне конкретной базы данных.

2. Анализ свойств сущностей

• Готовность - максимальная

• Достоверность - максимальная

• Видимость - средняя

• Доступность - высокая

• Мутируемость - низкая

• Изменчивость - низкая

3. Выводы по распределению

Экземпляры данных о принимающем пользователе могут располагаться на каждом сервере в сети. В этом случае можно также считать все копии этих данных, кроме одной, неизменяемыми -- за исключением ситуации, когда изменения копируются из обновляемой копии в другие. Если распределение данных поможет сократить число обращений по глобальной сети, то такое решение выглядит привлекательно.

Таблица «Вид принимающего пользователя»

1. Описание

Принимающим пользователем может быть частное лицо или webстраница. При запросе должен выводиться актуальный вид принимающего пользователя.

2. Анализ свойств сущностей

• Готовность - максимальная

• Достоверность - средняя

• Видимость - низкая

• Доступность - высокая

• Мутируемость - низкая

• Изменчивость - низкая

3. Выводы по распределению

Эти данные должны находиться только при определении принимающего устройства и выявлять - это web-страница или частное лицо (человек). Если распределение данных поможет сократить число обращений по глобальной сети, то такое решение выглядит привлекательно.

Таблица «Устройства»

1. Описание

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

2. Анализ свойств сущностей

• Готовность - максимальная

• Достоверность - максимальная

• Видимость - средняя

• Доступность - максимальная

• Мутируемость - низкая

• Изменчивость - средняя

3. Выводы по распределению

Эти данные должны находиться только на том сервере, на котором ведется учет связи передачи и ip-адресов. Таким образом, за исключением резервного копирования, никаких требований о наличии копий на других серверах нет. Эти данные горизонтально секционированы, и особой поддержки со стороны БД не требуется. Секционирование обеспечивает также некоторые требования к доступу и безопасности.

Таблица «Вид устройства»

1. Описание

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

2. Анализ свойств сущностей

• Готовность - средняя

• Достоверность - средняя

• Видимость - средняя

• Доступность - максимальная

• Мутируемость - низкая

• Изменчивость - низкая

3. Выводы по распределению

Эти данные должны находиться только при определении принимающего и передающего устройств. Если распределение данных поможет сократить число обращений по глобальной сети, то такое решение выглядит привлекательно.

Таблица «Вид связи»

1. Описание

Категория передачи связи важна для провайдера. Информация пользователем может быть отправлена как через Wi-Fi, так и через Кабельное подключение. При запросе должно выводиться только актуальное значение вида связи.

2. Анализ свойств сущностей ? Готовность - средняя

• Достоверность - средняя

• Видимость - максимальная

• Доступность - максимальная

• Мутируемость - низкая

• Изменчивость - низкая

3. Выводы по распределению

Эти данные должны находиться только на том сервере, на котором определяется способ передачи информации. Таким образом, за исключением резервного копирования, никаких требований о наличии копий на других серверах нет. Эти данные горизонтально секционированы, и особой поддержки со стороны БД не требуется.

Таблица «Вид сообщения»

1. Описание

Вся информация может подразделяться на множество видов. Это сделано для возможности провайдером отслеживать конкретный вид передачи информации. При запросе должен выводиться конкретный вид сообщения.

2. Анализ свойств сущностей

• Готовность - максимальная

• Достоверность - максимальная

• Видимость - средняя

• Доступность - высокая

• Мутируемость - низкая

• Изменчивость - низкая

3. Выводы по распределению

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

Таблица «Информация»

1. Описание

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

Провайдер и иные службы имеют полный доступ ко всем записям.

2. Анализ свойств сущностей

• Готовность - максимальная

• Достоверность - максимальная

• Видимость - высокая

• Доступность - средняя

• Мутируемость - низкая

• Изменчивость - низкая

3. Выводы по распределению

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



ВЫВОД

провайдер база данные oracle

В ходе выполнения проекта была создана база данных «Провайдер» для хранения данных пользователей провайдером. Была проанализирована предметная область, изучены её функции, описаны смысл операций и ограничений с помощью диаграммы потоков данных. На основе выделенных информационных объектов и их атрибутов построены реляционная и физическая модели.Были подробно рассмотрены все аспекты функционирования этой системы, логической, программной и физической ее реализации. База данных была реализована в Oracle, также было сделано глобальное представление из всех данных. И конечно, для распределенной базы данных была создана и описана схема распределения. Таким образом, все задания были выполнены и цель достигнута.

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

Размещено на Allbest.ru

...