Skip to content

Модель данных

Jump to bottom
Манцева Татьяна edited this page Oct 30, 2024 · 4 revisions

Далее используемые обозначения для расчета среднего объёма

  1. $N_{players} = 15$ - количество игроков в одной команде без организатора игры
  2. $L_{name} = 20$
  3. $L_{address} = 60$
  4. $L_{pass} = 20$
  5. $L_{email}= 40$
  6. $L_{wishlist} = 200$
  7. $L_{stoplist} = 100$
  8. $N_{games}$ - количество команд, переменная

Нереляционная модель

Графическое представление

Подробное описание и занимаемый объём данных

БД содержит 3 коллекции - "Game", "User", "Event":

  • Коллекция "Game"

    • id - идентификатор каждой команды/игры в Тайного Санту. 8 байт
    • lowest_price - нижняя граница стоимости подарка. 8 байт
    • highest_price - верхняя граница стоимости подарка. 8 байт
    • form_deadline - срок, к которому нужно заполнить анкету. 8 байт
    • purchase_deadline - срок, к которому нужно купить подарок. 8 байт
    • send_deadline - срок, к которому нужно отправить подарок. 8 байт
    • users - игроки данной команды, в том числе и организатор. $N_{players}*V_{user} + V_{host}= 7319$
    • events - события, относящиеся к этой игре (заполнение анкеты, покупка подарка и т.д.). Верхняя граница(произошли все события для каждого игрока): $5N_{players}*V_{event}= 1300$ байт

    $V_{game} = 8667$ байт

  • Коллекция "User"

    • id - пользователь 8 байт
    • password - пароль $L_{pass} * 1 = 20$ байт
    • email - электронная почта $L_{email} * 1 = 20$ байт
    • is_host - является ли организатором 1 байт
    • name - имя $L_{name} * 1 = 20$ байт
    • address - адрес $L_{address} * 1 = 60$ байт
    • index - индекс 4 байта
    • phone - телефон 8 байт
    • status - статус игрока(ничего не сделал/ заполнил анкету/ купил подарок/ отправил его) 4 байта
    • delivery_type - способ доставки подарка 4 байта
    • wishlist - желания игрока $L_{wishlist} * 1 = 200$ байт
    • stoplist - "стоплист" $L_{stoplist} * 1 = 100$ байт
    • recipient - идентификатор получателя 8 байт
    • santa - идентификатор того, кто будет "Тайным Сантой" данного игрока 8 байт
    • got_gift - получил ли пользователь подарок 1 байт

    $V_{user} = 486$ байта

    Частный случай пользователя организатора - $V_{host} = V_{id} + V_{pass} + V_{email} + V_{name} + V_{is_host} = 8 + 20 + 40 + 20 + 1 = 89$ байт

  • Коллекция "Event"

    • player_id - идентификатор игрока, совершившего определенноё действие 8 байт
    • type - тип события 4 байта
    • date - дата 8 байт

    $V_{event} = 20$ байт

*$V(N_{games}) = 8879 N_{games}$ - занимаемый объём.

Избыточность данных

Дублирующиеся поля - player_id в коллекции Event, recipient, santa в коллекции User - идентификаторы участвующих игроков.
Объём без дублирования информации - 8039.
Избыточность модели = $\frac{8879}{8039} = 1.104$

E. Направление роста модели при увеличении количества объектов каждой сущности

  • Новая запись об игре влечет за собой новую запись о пользователе-организаторе
  • Каждая новая запись об игроке - потенциальные новые записи в коллекции Event
  • Новые документы в таблице Event ни на что не влияют

Примеры данных

  1. Game
{

}
  1. User
{

}
  1. Event
{

}

Примеры запросов

Реляционная модель

Графическое представление

Подробное описание и занимаемый объём данных

БД содержит 4 отношения - "Game", "Host", "Player", "Event":

  • Отношение "Game"

    • id - идентификатор каждой команды/игры в Тайного Санту. Ключ 8 байт
    • lowest_price - нижняя граница стоимости подарка 8 байт
    • highest_price - верхняя граница стоимости подарка 8 байт
    • form_deadline - срок, к которому нужно заполнить анкету 8 байт
    • purchase_deadline - срок, к которому нужно купить подарок 8 байт
    • send_deadline - срок, к которому нужно отправить подарок 8 байт

    $V_{game} = 48$ байт

  • Отношение "Host"

    • id - идентификатор организатора. Ключ 8 байт
    • password - пароль $L_{pass} * 1 = 20 $ байт
    • email - электронная почта $L_{email}* 1 = 40 $ байт
    • game_id - идентификатор игры, в которой данный пользователь является организатором 8 байт
    • name - имя $L_{name} * 1 = 20$ байт

    $V_{host} = 96$ байт

  • Отношение "Player"

    • id - идентификатор игрока. Ключ
    • password - пароль $L_{pass} * 1 = 20 $ байт
    • email - электронная почта $L_{email}* 1 = 40 $ байт
    • game_id - идентификатор команды, в которой находится пользователь 8 байт
    • name - имя $L_{name} * 1 = 20$ байт
    • wishlist - желания игрока $L_{wishlist} * 1 = 200 $ байт
    • stoplist - "стоплист" $L_{stoplist} * 1 = 100$ байт
    • address - адрес $L_{address} * 1 = 60 $ байт
    • index - индекс 4 байта
    • phone - телефон 8 байт
    • got_gift - получил ли пользователь подарок 1 байт
    • status - статус игрока(ничего не сделал/ заполнил анкету/ купил подарок/ отправил его) 1 байт
    • delivery_type - способ доставки подарка 1 байт
    • recipient - идентификатор получателя 8 байт
    • santa - идентификатор игрока, который будет "Тайным Сантой"данного игрока 8 байт

$V_{player} = 479$ байт

  • Отношение "Event"

    • game_id - идентификатор игры, к которой относится данное событие. 8 байт
    • player_id - идентификатор игрока, совершившего определенноё действие. 8 байт
    • type - тип события. game_id + player_id + type - ключ данной таблицы 4 байт
    • date - дата 8 байт

    $V_{event} = 36$ байт

*$V(N_{games}) = 48N_{games} + 479N_{players}N_{games} + 96N_{games} + N_{players}N_{games}5 = N_{games}(48 + 47915 + 96 + 15536) = N_{games}10029$ байт - занимаемый объём.

Избыточность данных

Дублирующиеся поля:

  1. player_id в отношении Event, recipient, santa в отношении Player - идентификаторы участвующих игроков.
  2. game_id в отношении Event, game_id в отношениях Player, Host - идентификаторы игры.
    Объём без дублирования информации - 8413 байт.
    Избыточность модели = $\frac{10029}{8413} = 1.192 $

Направление роста модели при увеличении количества объектов каждой сущности

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

Примеры данных

  1. Отношение Game
id lowest_price highest_price form_deadline purchase_deadline send_deadline
1 1000 2000 18.11.2024 30.11.2024 12.12.2024
  1. Отношение Host
id password email game_id name
1 fiuuhfie [email protected] 1 Ivan
  1. Отношение Player
id password email game_id name wishlist stoplist address index phone got_gift status delivery_type recipient santa
1 fiuuhfe [email protected] 1 Ivan flowers candles Nevsky str. 17 1111 89999999999 false filled_form 2 2 3
2 uuhfe [email protected] 1 Katya books candies Professora Popova str. 16 1111 89129999999 false none 2 3 1
3 udlfwefwefwhfe [email protected] 1 Mary perfume and sweets stationery Nevsky str. 16 1111 89999999999 bought none 2 1 3
  1. Отношение Event
game_id player_id type date
1 1 form 17.11.2024
1 3 form 10.11.2024
1 3 purchase 14.11.2024

G. Примеры запросов

Сравнение моделей

Занимаемый объём

Объём, зависящий от количества зарегистрированных команд в нереляционной БД меньше, чем в реляционной

Избыточность

1.104 в нереляционной и 1.192 в реляционной

Вывод

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

Clone this wiki locally