Проектирование стола и эффективность

Question

Я проектирую базу данных в oracle 12c для своего университетского задания и достиг своего уровня в проекте, где я не могу получить много информации об этом.

Сценарий моего назначения

Британский провайдер интернет-услуг заключил с вами контракт на полную реконструкцию их собственных систем программного обеспечения. Эта организация предоставляет широкополосные, оптоволоконные, телефонные, IPTV и 4G соединения, а также несколько специальных пользовательских разработок. Клиентская база - это, прежде всего, студенты с услугами, предоставляемыми через их университет. В настоящее время они работают с некоторыми устаревшими базами данных MySQL, использующими ядро ​​базы данных MyISAM, в результате чего нет подходящих взаимосвязей.

Мой вопрос

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

RIPA запрос

По сути, запрос RIPA - это когда политика хочет знать все, чем занимался определенный человек, используя Интернет, звонки и т. Д.

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

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

Интернет-провайдеру требуется следующее для пользователей:

Студенты

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

• Учащиеся смогут просматривать доску объявлений в приложении, на веб-сайте, в интранете и на платформах IPTV.

• Студенты должны получать счета за использование повторяющихся продуктов.

• Активность студентов должна отслеживаться при использовании Интернета и телефона. Маршрутизаторы в Университете выдают настраиваемый запрос API REST, в котором указывается доступный URL-адрес, а также сведения о студенте и местонахождении. Телефонные звонки также отслеживаются по телефонным номерам, длительность и время звонка также предоставляются через настраиваемый запрос REST API.

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

• Учащиеся могут комментировать элементы доски объявлений, а другие студенты могут комментировать эти комментарии.

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

• Просматриваемый телевизионный контент должен записываться в рекламных целях. Система IPTV запросит настраиваемый API, который предоставит просматриваемый канал, электронную почту студента и время.

• Студентам необходимо войти в систему, чтобы получить доступ к доске объявлений, широкополосной связи, телефону, IPTV и соединению 4G; оно сохраняется на отдельном устройстве после первого входа в систему.

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

Сотрудники университета

• Университет должен иметь возможность добавлять элементы доски объявлений.

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

• Доска объявлений cОн может быть нацелен на определенные слои, начиная с определенных университетов, затем общежитий внутри университетов и, наконец, пользовательских студенческих групп (по курсу, по клубу и т. д.), эти группы должны быть определены Университетом.

•Персоналу университета потребуется статистика использования.

• Персоналу университета потребуется внести изменения в административную область

Персонал интернет-провайдера

• Интернет-провайдер должен уметь управлятьограничения на подключение

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

• ISPобеспечивает поддержку с помощью трех методов, электронной почты, телефона и мгновенных сообщенийПоддержка электронной почты и ответы управляются на существующем сервере;при этом будет выполнен настраиваемый запрос API REST, в котором будет указан адрес электронной почты учащегося, тема письма, тело письма, дата и время.Телефонные звонки записываются вручную с помощью программного обеспечения для настольных ПК, включая сведения о звонившем студенте и характере запроса.Мгновенные сообщения записываются в базу данных и используются для управления системой мгновенных сообщений.

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

• Руководству интернет-провайдера потребуется статистика об использовании и продажах.

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

• Персонал интернет-провайдера должен использовать программное обеспечение для настольных ПК для внесения любых изменений.

Включение следующих дополнительных расширений позволит вам получить более высокую оценку (см. Критерии оценки - внедрение).

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

• Бесплатный WIFI для гостей - гости могут зарегистрироваться, чтобы получить доступ к WIFI бесплатно.Гостям необходимо предоставить домашний адрес, адрес электронной почты и номер телефона.Телефонный номер должен быть подтвержден, прежде чем они смогут получить доступ к WIFI, он управляется с помощью существующего сервера, который отправляет текстовое сообщение на основе запроса REST API, и после подтверждения выдает запрос REST API.

Answer 1

В общем, я бы начал с создания «чистой» реляционной модели, основанной на том, что вы знаете. Затем вы можете увидеть, нужно ли вам что-то делать умнее, чтобы удовлетворить это конкретное требование запроса RIPA.

Объекты, которые вы описали:

• Система имеет много клиентов
• клиент имеет одну или несколько услуг
• услуга имеет тип (широкополосный, ТВ, 4G и т. Д.)
• служба имеет 0 или более контролируемых событий
• событие имеет тип (сделать телефонный звонок, посмотреть телепередачу, запросить URL и т. Д.)
• событие имеет данные; каждый тип события имеет свою схему для этих данных

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

Если указанные выше объекты верны, ваша схема довольно очевидна:

Customer
-----------------
CustomerID (PK)
Name
...

Service
--------------
ServiceID (PK)
Name
Type
.....

CustomerService
--------------------------
CustomerID (FK)
ServiceID (FK)


Event
-------------------------
CustomerID (FK)
ServiceID (FK)
Type
Date
Event_Data

Остается проблема «как мы храним данные о событиях»? Поскольку вы не указали никаких требований, кроме «перечислить его», я бы предложил либо текстовое поле для хранения необработанных данных, либо XML / JSON, чтобы разрешить более умные запросы (например, «найти все события, когда кто-то начал смотреть Родину на» IPTV ") - но поскольку вы не указали это требование, вам может не потребоваться это делать.

Ваш запрос RIPA будет выглядеть примерно так:

select customer.*, 
       service.*, 
       customer_service.*,
       event.*
from customer
inner join customer_service on customer.customerID = customer_service.customer_id
inner join service on customer_service.service_id = service_service_id
inner join event on customer.customer_id = event.customer_id
inner join event on service.service_id = event.service_id
where customer_id = ?

Answer 2

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

Это позволит вам легко добавлять / обновлять / удалять службы.Удаление можно сделать, пометив службу как неактивную, используя флаг.Это позволит сохранить старые данные, в то время как новые не будут использовать эти службы.

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

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