2.4.1 Гибкость, отсутствие избыточности и масштабируемость модели

Лучшая модель, или,
по крайней мере, наиболее успешная / наиболее распространенная — это реляционная, в которой записи заменены
на строки, сгруппированные в таблицах, которые между собой связаны
частями содержания строк в самих строках. То, что называется сущностью в
ER-модели, является строкой в реляционной модели и таблица в
реляционной таблице отвечает совокупности (набору) сущностей (группе) в ER-модели. Столбцы реляционной модели соответствуют
атрибутам ER-модели. Термин связь (отношение) используется в обеих
моделях для того, чтобы показать, как сущности / строки и / или группы сущностей
/ таблицы связаны между собой. Также путь создания отношений похож, поскольку
используются атрибуты / столбцы как
обычно в таблице.

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

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

Хотя эти два аспекта совпадают, они расходятся
классификационно, как показано в следующей таблице:

Реляционная база данных состоит из таблиц, каждая из которых представляет
информацию, связанную с группой «субъектов», например, клиент компании (покупатель).
Таблица состоит из строк, каждая из которых содержит информацию, которая находится в связи с четко определенным субъектом, например, с конкретным покупателем. Таблица состоит из столбцов,
представляющих разную, но однотипную информацию (бизнес-имя, финансовый код,
…) по субъектам. Уникальный индекс
(также известный как первичный ключ, или первоначальный ключ) используется для различения специфической строки в таблице. Две таблицы могут быть связаны друг
с другом столбцами с одинаковым
содержанием, существующими в обеих таблицах, например, таблица «покупатель» и
«счет» могут иметь отношения
(взаимодействовать) через столбец, что содержит код для покупателя, так как эти
данные доступны в обеих таблицах.

Хорошо спроектированная реляционная база данных имеет ряд важных и полезных признаков:

• Отсутствует избыточность данных. Это означает, что существующие данные
  в базе данных не могут быть образованы путем объединения или
  комбинирования прочих данных той же
  базы данных. Примером избыточности являются столбцы или строки с
  повторными данными. Существуют различные методы и меры по устранению
  избыточности, и они рассматриваются более близко в разделе более «нормальной
  формы». Очевидно, что может существовать желаемые или необходимые
  дублирования, но они связаны с резервным копированием базы данных или с
  сохранением в RAID-системе. Такое дублирование не влияет на логический
  уровень, независимо от того, как это создается, оно связано с физическим уровнем.
• Снижение дублирования. Определенный уровень дублирования необходим при
  создании отношений, или связей. Хорошим примером может служить
  существование в таблице столбца кода покупателя, как в вышеприведенном примере:
  он имеется как в таблице покупателей для различения одной строки от
  другой, так и в таблице счетов, показывая для какого покупателя, каждый счет выставлен.
• Ссылочная целостность. Должно быть невозможно удалить информацию,
  которая необходима для квалифицирования другой информации. Используя опять
  предыдущий пример, ссылочная целостность избегает удаления покупателя,
  кому выписан счет, исключая счета
  недействительных покупателей. Ссылочная целостность может работать и в
  обратном направлении, удаляя все счета конкретного покупателя, если
  покупатель сам себя удалил (как правило, описанный случай не
  представляется возможным из-за существующего закона, который запрещается удаление
  отчетных данных).

Высокая
скорость исследования данных, которую получают путем определения индексов. Не только
уникальный индекс (или уникальный ключ) является полезным для увеличения
скорости поиска, но также и неуникальный индекс является полезным для ускорения поиска. Примером неуникального индекса является индекс,
который создан, например, с использованием
фамилии руководителя компании: он не является уникальным, поскольку различные
руководители могут обладать одинаковыми фамилиями. Несмотря на это, этот индекс допускает быстрое нахождение
данных фирмы, если известна только
фамилия руководителя.

Базы данных

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

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

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

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

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

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

Отношения обладают следующими свойствами:

—       каждый элемент – один элемент данных;

—       повторяющиеся группы отсутствуют;

—       элементы столбца имеют одинаковую природу;

—       в таблице не повторяются строки;

—       строки и столбцы можно просматривать в любом порядке.

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

—       простота логической модели;

—       гибкость системы;

—       независимость данных;

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

Если прикладная информационная система опирается на некоторую систему управления данными, обладающую свойствами: поддержание логически согласованного набора файлов; обеспечение языка манипулирования данными; восстановление информации после разного рода сбоев; реально параллельная работа нескольких пользователей, то эта система управления данными является системой управления базами данных (СУБД).

Основные функции СУБД:

1. Непосредственное управление данными во внешней памяти

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

2. Управление буферами оперативной памяти

СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся (система будет работать со скоростью устройства внешней памяти.

Практически единственным (способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены
буферов.

3. Управление транзакциями

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

4. Журнализация

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции. Поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.

Журнал — это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД.

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия — это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. Можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка — язык определения схемы БД (SDL) и язык манипулирования данными (DML). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language), который сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.

Получить бесплатную консультацию можно  по телефону +7 (4862) 442-770, +7 (960) 648-72-21.

Для расчёта стоимости услуг  воспользуйтесь калькулятором.

Гибкость данных — данные, информация и аналитика

Гибкость данных, безусловно, является целью. Не могу поверить, что я так долго писал об этом пост! Сколько времени мы потратили на «перетаскивание» только для того, чтобы создать жесткие шаблоны, которые исчезают в течение нескольких месяцев? К счастью, теперь у нас есть варианты!

Гибкость данных — это способность решения увеличиваться, уменьшаться или изменяться в соответствии с пересмотренным набором потребностей или требований к данным. Изменения настолько распространены, что мы должны убедиться, что данные, которыми мы управляем, справятся с ними.

В сообщении объясняется гибкость с точки зрения:

• Платформа
• Интеграция
• Хранение
• Доступ

В конце концов, как нам избежать жесткости?

Платформа

Это простой ответ из одного слова, это Облако. На помощь пришли AWS, AZURE и GCP. Ниже приведены некоторые распространенные сценарии, в которых поставщики облачных услуг предоставляют возможность:

• Добавить новых служб одним щелчком мыши. Например, клиенту Azure необходимо более полно обнаружить и понять свои источники данных. В течение нескольких часов они могут добавить Каталог данных Azure , чтобы облегчить это.
• Автоматически Масштаб как по горизонтали, так и по вертикали. Примером может служить клиент AWS с периодическими пиковыми нагрузками, которые требуют запуска автоматического масштабирования EC2 для соответствия ожидаемой производительности.
• Создать временных сред для выполнения периодических действий. Например, клиент GCP должен протестировать свою процедуру аварийного восстановления (DR) и поэтому запускает реплики Compute Engines, чтобы проверить процедуру восстановления.

Интеграция

Буду честен; это мой любимый! Слишком долго мы создавали жесткие шаблоны интеграции «точка-точка», которые ломаются, если происходят изменения. Шаблоны извлечения, преобразования и загрузки (ETL), закодированные вручную, были параметром по умолчанию.

Гибкость интеграции теперь обеспечивается:

• Быстрая загрузка структур данных, не требующая сложных бизнес-правил (например, Landing, Staging, Raw Data Vault или Data Lake) с минимальным ручным кодированием. Необходима платформа или инструмент, управляемый метаданными.
• Использование шаблона Pub/Sub , если для интеграции требуется «много» точек системной интеграции, несколько протоколов (например, FTP, HTTP и т. д.) и маршрутизация сообщений. Это поможет избежать:
  • проблем с интеграцией, когда либо издатель, либо подписчик периодически отключаются от сети.
  • Узкие места в производительности из-за клиентского процесса подписчика, который не может подтверждать сообщения так же быстро, как издатель может отправлять.

• Использование микросервиса для предоставления сервис-ориентированной архитектуры (SOA) целенаправленным, гибким и поэтапным образом. Это означает, что клиент может избежать традиционного монолитного подхода, когда все яйца в одной корзине.

Хранилище

Гибкость данных была бы невозможна без недавнего изменения параметров хранения. Прежде для сохранения данных требовалось определение схемы. Это означало, что прием был дорогостоящим и медленным из-за накладных расходов на моделирование. Теперь мы можем выбирать из целого ряда подходов, в которых схема действительно актуальна только при чтении данных. К ним относятся Amazon S3 или хранилище BLOB-объектов Azure.

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

Архитектура данных

Моделирование данных и количество используемых слоев данных в прошлом были более простым выбором. Теперь у нас есть Lake, Vault, Lake House, Warehouse, Mart, ODS и т. д. Каждый из подходов имеет свои достоинства и может обеспечить гибкость данных в большей или меньшей степени. Независимо от ваших предпочтений в моделировании, гибкость поддерживается:

• Необработанные слои (например, «Земля», «Сцена», «Необработанное хранилище», «Озеро» и т. д.), которые легко и очень быстро создавать и изменять. Каждый из них добавляет жесткости и стоимости.
• Стандартная схема нагрузки. Вариация препятствует быстрому изменению.

Доступ

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

Гибкость данных в заключение

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

• Теперь мы можем хранить любые данные, какие захотим, однако есть ли в этом смысл? Хранение «на всякий случай» не является достаточной причиной.
• Архитектура данных — это одна из областей, где легко потерять гибкость. Я не говорю, что приведенные ниже пункты не имеют достоинств, я говорю, что они, тем не менее, создадут жесткость данных:
  • Количество уровней (например, озеро, этап, хранилище данных операций, хранилище данных, архив, презентация и т. д.)
  • Изменения в парадигме моделирования (например, от 3NF к Raw Vault, затем к Business Vault, затем к Dimensional)
  • Бизнес-правила:
    • Согласованность реализации (например, некоторые в Staging, некоторые в Presentation и некоторые в инструменте визуализации данных?)
    • Метод создания (например, ручное кодирование или управление метаданными) Доступ к необработанным данным звучит как идеальное решение, однако он представляет собой набор уникальных проблем управления, конфиденциальности и бюджета, которые могут очень сильно затруднить оправдание расходования денег на «правильное» моделирование позже.
    • Только потому, что поставщик облачных услуг позволяет нам добавлять дополнительные услуги одним нажатием кнопки, гарантирует ли это решение? С искушением добавить их может быть очень трудно бороться, особенно если вы не любите рисковать или склонны рассчитывать на будущее.

    Изображение Sofie Zbořilová с сайта Pixabay

    Необходимость гибкого управления данными: почему гибкость данных так важна?

    Нажмите, чтобы узнать больше об авторе Дэвиде Лейвсли.

    Мы живем в эпоху больших данных. Удивительно,
    статистика показывает, что около 90% этих данных имеют возраст всего два года. Что
    указывает на то, что компаниям, продвигающимся вперед, необходимо будет предвидеть использование большего
    и многое другое.

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

    Гибкость данных становится серьезной проблемой. В то время как автоматизированные сервисы данных становятся все более популярными, качество данных также имеет отношение к большому бизнесу. К 2022 году большие данные будут стоить не менее 274 миллиардов долларов. Поэтому само собой разумеется, что такими данными стоит правильно управлять и обрабатывать их.

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

    Больше гибкости = больше возможностей для анализа

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

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

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

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

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

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

    Больше гибкости = больше масштабируемости

    Это может быть очевидно, но масштабируемое управление данными сразу же масштабируется. Ежедневно генерируются данные объемом до 2,5 квинтиллионов байт. Дальнейшие исследования показывают, что для хранения данных потребуется освободить место для более чем 44 ZB по всему миру.

    ZB — это зеттабайт. Для масштаба один
    зеттабайт равен примерно секстиллиону байтов. Это действительно
    невероятное количество, и если статистике стоит верить, цифры
    становится все больше.

    Таким образом, управление корпоративными данными должно
    быть масштабируемым. Система образования должна каждый год освобождать место для новых студентов.
    Спортивная индустрия должна освободить место для продажи билетов и места на стадионе.
    индустрии здравоохранения, пожалуй, труднее всего, так как в стране рождается примерно 250 детей.
    минута.

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

    Больше гибкости сейчас = больше гибкости
    Позже

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

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

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

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

    Обеспечение ясности и гибкости данных

    Качество данных зависит от точности и гибкости.
    Мы всегда обсуждаем способы очистки данных и смены управления.
    помогая компаниям соответствовать новым требованиям. Больших данных не стоит бояться. Фактически,
    многие согласны с тем, что его рост неизбежен.

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

    This entry was posted in Популярное