База данных

Сетевая модель базы данных

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

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

Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I. Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

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

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

Запись старшего уровня («запись-владелец») также может быть «членом» или «владельцем» в других наборах. Модель данных — это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records, то есть «перекрёстные записи). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

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

Известные сетевые базы данных:

  • TurboIMAGE;
  • IDMS;
  • Встроенная RDM;
  • Серверная RDM.

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

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

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

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

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

Классификация баз данных по обращению к ним

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

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

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

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

Классификация баз данных

Базы данных можно разделить по 4 признакам:

1. Применяемый язык программирования. Открытые базы опираются на один из универсальных языков. В замкнутых базах используются собственный язык программирования.

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

3. Сфера применения. Различают универсальные БД и специализированные, предназначенные для решения конкретных задач.

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

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

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

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

2 Построение концептуальной модели

Выше были отображены основные сущности, но не отображены роли пользователей, хотя их тоже должна хранить система. Они показаны ниже на ER-диаграмме в нотации Чена .

На диаграмме выделены роли кассира и менеджера, а также основные отношения между сущностями. На диаграмме нет роли администратора, но его роль заключается в:

  1. создании всех таблиц базы;
  2. добавлении залов и рядов в них;
  3. добавлении кассиров и менеджеров.

На диаграмме не отражена роль посетителя, так как:

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

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

Для формирования схемы данных необходимо сначала дополнить ER-диаграмму реквизитами сущностей (уточнить ее) — результат приведен на рисунке.

  • система не должна позволять продавать несколько билетов на одно и то же место при одном показе фильма. Это значит, что вторичным ключем для Билета должен быть кортеж (id_screening, row, seat). Однако, тогда нет необходимости в id билета — на билеты не ссылается ни одна таблица, это поле может быть удалено. Изначально id был добавлен потому, что обычно на билетах в кинотеатрах печатается номер;
  • билет хранит поле id_hall, это было сделано для того, чтобы посетитель кинотеатра мог найти свой кинозал. Однако, билет, выдаваемый пользователю — это не тоже самое, что информация о билетах, хранимая в базе данных. Билет базы данных хранит также поле id_screening, а Показ уже ссылается на id_hall. Таким образом, в базе нет смысла хранить id_hall в таблице билетов.

Исправленная ER-диаграмма приведена ниже:

Таблица менеджеров и кассиров не объединены в таблицу Users так как вопросы разграничения прав доступа в различных СУБД решаются по-разному. Так, в MS SQL пользователи добавляются с помощью специальных запросов типа:

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

Сравнение Access и Excel

Какие же преимущества имеют БД перед другими хранилищами информации, например, электронными таблицами, текстовыми редакторами и так далее? Для сравнения лучше всего подходят база данных Access и электронные таблицы Excel. Такой выбор обусловлен тем, что оба приложения входят в один пакет и применяются для хранения данных. Access – это, по сути, бесплатная база данных, идущая бонусом к текстовому редактору Word и таблицам Excel.

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

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

Количество строк в Excel не может превышать 65536, в Access же количество записей вообще не ограничено. Существует только лимит на общий размер файла – не более 2Гб.

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

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

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

  • База данных;
  • Таблица;
  • Запись.

База данных

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

Таблица

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

Запись

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

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

  • Создадим для сайта новую БД и дадим ей название «weather_diary».
  • Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
    • Город (тип: текст);
    • День (тип: дата);
    • Температура (тип: число);
    • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
    • Были ли осадки (тип: истина или ложь);
    • Комментарий (тип: текст).
  • При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

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

Английское слово „relation“ можно перевести как связь, отношение. А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой. Что это за связи? Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации. В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными. Но можно поступить иначе:

  • Создать новую таблицу с именем „cities“.
  • Все города в России известны, поэтому их все можно добавить в одну таблицу.
  • Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
  • При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

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

Связи между таблицами в БД бывают разных видов. В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот! Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.

Это интересно: Трудовая книжка

Определение атрибутов

Атрибут представляет свойство, описывающее сущность. Атрибуты часто бывают числом, датой или текстом. Все данные, хранящиеся в атрибуте, должны иметь одинаковый тип и обладать одинаковыми свойствами.
В физической модели атрибуты называют колонками.
После определения сущностей необходимо определить все атрибуты этих сущностей.
На диаграммах атрибуты обычно перечисляются внутри прямоугольника сущности. На рисунке вы найдете пример базы данных «Дома», только теперь для сущностей из этой базы определены некоторые атрибуты.
Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе — нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.

Ключи

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

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

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

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

Язык структурированных запросов (SQL)

После того, как вы выбрали подходящую для вас СУБД и установили её, следующим шагом было бы создание таблиц и управление данными. Для этого мы можем воспользоваться специальным языком SQL.

Создание БД development:

CREATE DATABASE development;

Создание таблицы Users:

CREATE TABLE users (
  full_name VARCHAR(100),
  username VARCHAR(100)
);

При создании полей нам необходимо указать тип хранимой информации и её размер. Колонки “full_name” и “username” будут типа VARCHAR, который предназначен для хранения строк символов. Размер 100 символов. Список всех типов вы можете найти .

Добавление записи:

INSERT INTO users (full_name, username)
VALUES ("Boris Hadjur", "_DreamLead");

Извлечение всех записей пользователя _DreamLead:

SELECT text, created_at FROM tweets WHERE username="_DreamLead";

Обновление записи:

UPDATE users
SET full_name="Boris H"
WHERE username="_DreamLead";

Удаление записи:

DELETE FROM users
WHERE username="_DreamLead";

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

Иерархическая база данных

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

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

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

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

От прошлого к настоящему

Нет смысла охватывать историю баз данных, цепляясь за любое сходство, поэтому моментом появления баз данных будет не античное время, а 60-е годы 20 века. Именно тогда компьютеры стали эффективным инструментом для коммерческих компаний, а организация COBASYL (COnference on DAta SYstems Language), создавшая в 1959 году язык COBOL и впоследствии наделив его возможностями для управления БД, помогла им управлять резко возросшими потоками информации.

К концу 60-х появилась первая сетевая модель данных, возникло понятие СУБД, а в 1974 году компания IBM стала работать над языком для System R.  Так на свет появился SEQUEL (Structured English QUEry Language). Однако позже, когда стало известно, что такое название используется британской авиастроительной компанией, было решено немного сократить до привычного SQL.

С увеличением доступности компьютеров стали появляться ориентированные на простых пользователей БД (Paradox, RBASE 5000, RIM, Dbase III), API (ODBC, Excel, Access) и средства разработки (VB, Oracle Developer, PowerBuilder). Само-собой, тенденция охватила и интернет, на сегодняшний день эффективное взаимодействие с БД – негласное требование к любому ресурсу с более-менее динамической информацией.

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

Определение сущностей

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

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

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector