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

MySQL

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

Поскольку MySQL является отраслевым стандартом, она совместима практически со всеми операционными системами и написана на языках C и C ++. Это решение является отличным вариантом для международных пользователей. Сервер СУБД может выводить клиентам сообщения об ошибках на нескольких языках.

Достоинства

  • Проверка на стороне сервера;
  • Возможность локального использования;
  • Гибкая система привилегий и паролей;
  • Безопасное шифрование всего трафика паролей;
  • Библиотека, которая может быть встроена в автономные приложения;
  • Предоставляет сервер в качестве отдельной программы для сетевого окружения клиент/сервер.

Недостатки практической разработки и администрирования баз данных MySQL Приобретена компанией Oracle:

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

Разработка модели базы данных

В процессе проектирования базы данных выделены следующие сущности:

  • Аптека (Pharmacy);
  • Группа препаратов(Group);
  • Наличие (Availability);
  • Дефицит (Deficit);
  • Сотрудник (Employee);
  • Клиент (Client);
  • Корзина (Basket);
  • Покупка (Buying).

На рисунке ниже
приведено представление модели нашей базы данных с атрибутами сущностей (таблиц) и связями
между таблицами. Для увеличения рисунка можно нажать на него левой кнопкой мыши.
О том, какие атрибуты имеются у сущностей — в статье Создание базы данных, в которой приведены и команды
языка SQL для создания БД и таблиц в ней. На рисунке атрибуты прописаны внутри прямоугольников, отображающих
сущности. А уйти ещё глубже в теорию реляционных баз данных можно на уроке Реляционная модель данных.

Опишем отношения между сущностями.

Сущность «Аптека» связана отношением «Имеет» «один ко многим» с сущностью «Наличие», отношением «Имеет» «один ко многим» с сущностью «Дефицит», отношением «Имеет» «один ко многим» с сущностью «Покупка», отношением «Работает» «один ко многим» с сущностью «Сотрудник».

Сущности «Наличие» и «Дефицит» связаны отношениями «Включает» «многое к одному» с сущностью «Препарат».

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

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

Сущность «Сотрудник» кроме упомянутой связи с сущностью «Аптека» связан отношением «Регистрирует» «один ко многим» с сущностью «Корзина».

Сущность «Клиент» связан отношением «Имеет» «один ко многим» с сущностью «Корзина».

Фундаментальные знания и жесткие конструкции

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

Алгоритм не может быть фиксированным. Все должно быть определено в динамике. Заслуги квалифицированных разработчиков несомненны, но лежат они вовсе не в изящных формах решений от Oracle, MySQL или ограниченного в возможностях Access. Иная таблица Excel может обеспечить динамичный контент и не требовать участия программиста более менее приличное время после завершения работ.

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

Последовательное развитие и/или прыжки в высоту

Windows — не база данных, но в ней есть реликвия — реестр. Файл hosts — это просто идентификация IP-адресов локального компьютера и символических имен. Но через этот файл образуются информационные потоки с различных доменов или в различные СУБД.

Понять многоликий Windows как рабочий компьютер или сервер можно, но обосновать логику версий этого продукта не получится никак. PHP тоже не база данных, но аргументы разработчиков, почему за версией 5 сразу идет версия 7, не последовательны. PHP — это инструмент доступа к MySQL, его синтаксис определяет, как формировать запросы и получать ответы от базы данных при помощи диалекта SQL.

Примеры несовместимости современных инструментов программирования и обеспечения работы баз данных в последние годы стали нормой вещей, но это не самое оригинальное. Что будет за версией Windows 10? Какие перспективы идут вслед за Oracle Database 12c?

Информация разработчика-автора: «Oracle Database 11g Express Edition (Oracle Database XE) — это СУБД начального уровня, основанная на программном коде СУБД Oracle Database 11g Release 2. Данная СУБД бесплатна для разработки, развертывания и продажи, быстро скачивается и проста в администрировании».

Мнение разработчика-пользователя: «В 2013 г. компания Oracle выпустила версию Oracle Database 12c (версия 12.1.0.1), основными достоинствами которой стали снижение стоимости хранения, высокая доступность данных, простота консолидации баз данных и защита доступа к данным».

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

Запросы к базе данных и отчёты

Запросы:

  • доступность выбираемого в селекторе препарата в выбираемой в селекторе аптеке на данный момент времени;
  • группы препаратов, которых нет в выбираемой в селекторе аптеке на данный момент времени;
  • аптеки, в которых есть дефицит любого препарата по введённой дате;
  • покупки препаратов, которые есть на витринах аптек по введённой дате с указанием препаратов и аптек;
  • клиенты, совершившие покупки в выбранной в селекторе аптеке по введённой дате.

Отчёты:

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

Поделиться с друзьями

Реляционные базы данных и язык SQL

Инфологическое проектирование

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

  • описание типов объектов,
  • ограничения целостности, связанные с описанным типом,
  • процессы, приводящие к эволюции предметной области – переходу её в другое состояние.

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

  1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
  2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
  3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

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

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

Инфологический аспект. Модель «сущность-связь»Инфологический аспект. Модель «сущность-связь»

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

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

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

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

Создание процедур

Процедура «Броня»PROCEDURE Броня

@parameter1 varchar (50) = »

AS

select Фамилия, Имя, Отчество, Номер

from «Наличие брони по имени клиента»

where Фамилия = @parameter1

RETURN

Вызов процедурыa = InputBox («Введите фамилию клиента
или название организации»)

Dim db As New DataClasses1DataContextb = db. Броня (a)

Броня. DataGridView1. DataSource = b

Броня. Show ()

Процедура «Клиент»

ALTER PROCEDURE Клиент

@parameter1 varchar (50) = »

AS

select Фамилия, Имя, Отчество, «Дета
рождения», Телефон, Паспорт

from «Информация о клиенте»

RETURN

Вызов процедуры

Dim a = InputBox («Введите фамилию клиента»)

Dim db As New DataClasses1DataContextb = db.
Клиент (a)

клиент. DataGridView1. DataSource = b

клиент. Show ()

Процедура «Номер»PROCEDURE Номер

@parameter1 int = »

AS

select Номер, Категория, «Стоимость за
сутки», «Количество мест»

from «Информация по конкретному номеру»

where Номер = @parameter1

RETURN

Вызов процедурыa = InputBox («Введите значение
номера»)

Dim db As New DataClasses1DataContextb = db. Номер (a)

номер. DataGridView1. DataSource = b

номер. Show ()

Процедура «Счет»PROCEDURE Счет

@parameter1 int = »

AS

select Фамилия, Имя, Отчество, Номер, Сумма

from «Выдача счетов на оплату»

where Номер = @parameter1

RETURN

Вызов процедуры

Dim a = InputBox («Введите значение номера»)

Dim db As New DataClasses1DataContextb = db. Счет
(a)

счет. DataGridView1. DataSource = b

счет. Show ()

2.3
Руководство пользователя

Приложение не требует инсталляции, пользователю необходимо
зaпустить файл Гoстиница. exe. После чего на экран появится главное окно.
Пользователь имеет право редактировать данные, используя формы
«Категории», «Номера», «Персонал»,
«Клиенты».

В каждом диaлогoвом oкне есть кнoпки нaвигации, дoбавления
новой записи и окно поиска нужной записи.

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

Для выхода из программы необходимо закрыть окно.

Заключение

Курсовая работа выполнена в соответствии с техническим
заданием. Разработана и спроектирована автоматизированная информационная
система основанная на базе данных «Магазин продуктовый”, содержащая
необходимые данные. База данных разработана в программной системе разработки
баз данных MS SQL Server Management Studio 2005, что позволяет
легко понять ее организацию и простоту управления. Получить необходимую
информацию из базы данных можно, используя SQL — запросы. На основе данной
автоматизированной информационной системы возможно проектирование подобных баз
данных для схожих целей.

Список
использованной литературы

1.       Visual Studio.net: разработка приложений для баз данных. —
СПб.: БХВ-Петербург, 2011. — 544 с.

2.      Знакомство
с MS SQL Server /В. Вшивцев. — И.:
Русская редакция, — 2009. — 288 с.

.        Базы
данных/А.В. Кузин. — И.: Академия, — 2012. — 320 с.

.        Базы
данных/И.П. Карпова. — И.: Питер, — 2013. — 240 с.

.        Введение
в программирование на языке MS Visual Basic.net/С.Р. Гуриков. — И.: Дрофа, — 2010. — 528 с.

.        Введение
в.net 4.0 и Visual Studio 2010 для профессионалов/Алекс Микки. — И.: Вильямс, — 2010. — 416
с.

2.2.1 Автономные базы данных

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

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

[править] Процедура нормализации

  1. Функциональные зависимости
  2. Нормализация отношений Нормализация — формальная процедура разбиения некоторой реляционной таблицы на две или более с целью получения такого проекта БД, в котором исключено избыточное дублирование информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных, возникающих в результате аномалий обновления, удаления и вставки, и создания структуры, в которой предусмотрена возможность ее будущих изменений и влияние этих изменений на приложения, использующие информацию этой БД, минимально.
  3. Многозначная зависимость В отношении R атpибут Y многозначно зависит от X, если каждому значению X соответствует несколько значений Y.

Физическое проектирование БД

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

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

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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

Проектирование баз данных; Цели и этапы проектированияПроектирование баз данных; Цели и этапы проектирования

Этапы проектирования базы данных

Этап начальной разработки

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

Концептуальное проектирование базы данных

  • анализ требований к базе данных, выявление представлений конечных пользователей и требований к обработке транзакций;
  • определение сущностей, атрибутов и связей;
  • разработка ER-диаграмм (от ER — Entity-Relationship — Сущность-Связь);
  • нормализация;
  • проверка модели данных, выявление основных процессов (правила ввода, обновления и удаления данных);
  • проверка отчётов, запросов, представлений, целостности, совместного использования и безопасности.

Правило 4: Относитесь к дублирующим неоднородным данным как к своему главному врагу.

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

Например, на приведенной ниже таблице вы можете заметить, что «5th Standard» и «Fifth standard» означает то же самое.Возможно данные попали в систему из-за плохого ввода данных или плохой проверки. Если вы когда-либо захотите получить отчет, они будут отображаться как разные объекты, что очень сбивает с толку.

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

В мир плавных форм от точных прямоугольников

С приходом в свет объектно-ориентированного программирования, сериализация данных получила второе дыхание. Действительно, все вокруг — только лишь строки, желательно неопределенной длинны. Числа и даты — тоже строки символов.

Мощь и объективность реляционных отношений — бесспорна, но разве динамика колонок и строк наносит ущерб их репутации? Таблица — это просто данные, которые могут иметь шапку (список колонок) или не иметь строк. Пусть таблица — это просто совокупность данных, не обязательно именованная.

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

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

Предметом работы станет не описание структуры базы данных, а динамика движения информации. Этапы работ распределятся на три центра тяжести:

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

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

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

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

Старое и новое: баланс знаний

Облачные технологии не чета тем базам данных, что делала компания Ashton-Tate. То что когда-то купила Oracle, никак не сопоставимо с тем, что она делает сегодня. Но в программировании с тех давних 80-х годов остались переменные, алгоритмы, функции, циклы и условия. Разве что понятие процедуры кануло в лету, а так все как было в древние времена, так и осталось.

Даже современные идеи объектно-ориентированного программирования облечены в классические синтаксические и семантические «оковы» прошлого века.

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

Информация всегда динамична, ничто не стоит на месте: особенно предметная область задачи и требования пользователей. Каждый исполненный этап работ позволяет на новом уровне оценить уже сделанное и то, что предстоит сделать.

Рассматривать проектирование структуры базы данных как задачу и получить окончательный результат — бесперспективно. Как только БД будет сдана в эксплуатацию, обязательно появится новая идея, даже если инструментом создания базы данных был «простенький» Excel, а не фантастически мощный и многогранный продукт от Oracle, манипулирующий миллионами транзакций, сотнями тысяч одновременно работающих пользователей и террабайтами информации.

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

Современная база данных

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

Таблицы Excel — ничем не отличаются от Oracle и MySQL в контексте прямоугольных (реляционных) конструкций: столбцы и строки = одна ячейка на пересечении имени столбца (поля) и индекса выборки (строка). Если не учитывать меру и объем ручного труда, то, благодаря развитым средствам объединения ячеек по вертикали и горизонтали, Excel опережает даже Oracle!

Excel, по его основной идее, никогда «не светит» динамика, функционал Oracle, и перенести что-то с одного листа на другой «по остаткам» он не может. Здесь Oracle перспективнее, но ее соображения по вопросам миграции больших объемов информации и объединению формализованных позиций из различных источников оставляют желать лучшего. Здесь MySQL перспективнее: она не ставит перед собой глобальных задач, но свою работу исполняет отменно.

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

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

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

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

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

Типы баз данных

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

  • Реляционные базы данных. Реляционные базы данных стали доминирующими в 1980-х годах. Элементы в реляционной базе данных организованы как набор таблиц со столбцами и строками. Технология реляционных баз данных обеспечивает наиболее эффективный и гибкий способ доступа к структурированной информации.
  • Объектно-ориентированные базы данных. Информация в объектно-ориентированной базе данных представлена ​​в виде объектов, как в объектно-ориентированном программировании.
  • Распределенные базы данных. Распределенная база данных состоит из двух или более файлов, расположенных на разных сайтах. База данных может храниться на нескольких компьютерах, находиться в одном физическом месте или разбросана по разным сетям.
  • Хранилища данных. Централизованное хранилище данных, хранилище данных — это тип базы данных, специально разработанный для быстрого запроса и анализа.
  • Базы данных NoSQL. NoSQL, или нереляционная база данных, позволяет хранить и обрабатывать неструктурированные и полуструктурированные данные (в отличие от реляционной базы данных, которая определяет, как должны быть составлены все данные, вставленные в базу данных). Базы данных NoSQL становились популярными по мере того, как веб-приложения становились все более распространенными и сложными.
  • Графовые базы данных. База данных графов хранит данные в терминах сущностей и отношений между сущностями.
  • Базы данных OLTP. База данных OLTP — это быстрая аналитическая база данных, предназначенная для большого количества транзакций, выполняемых несколькими пользователями.

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

  • Базы данных с открытым исходным кодом (OpenSource). Система баз данных с открытым исходным кодом — это система с открытым исходным кодом; такие базы данных могут быть базами данных SQL или NoSQL.
  • Облачные базы данных (Cloud Database). Облачная база данных — это набор структурированных или неструктурированных данных, который хранится на частной, общедоступной или гибридной платформе облачных вычислений. Существует два типа моделей облачных баз данных: традиционные и база данных как услуга (DBaaS). В случае DBaaS административные задачи и обслуживание выполняются поставщиком услуг.
  • Многомодельная база данных. Мультимодельные базы данных объединяют различные типы моделей баз данных в единую интегрированную серверную часть. Это означает, что они могут поддерживать различные типы данных.
  • База данных Документов / JSON. Базы данных документов, разработанные для хранения, извлечения и управления документально-ориентированной информацией, представляют собой современный способ хранения данных в формате JSON, а не в строках и столбцах.
  • Автономные базы данных. Новейший и самый революционный тип базы данных, автономные базы данных (также известные как автономные базы данных) являются облачными и используют машинное обучение для автоматизации настройки базы данных, обеспечения безопасности, резервного копирования, обновления и других рутинных задач управления, традиционно выполняемых администраторами баз данных.
Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий