Реляционная база это: Что такое реляционная база данных?

Содержание

Реляционная база данных (РБД)

Другие статьи

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

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

Структура РБД

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

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

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

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

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

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

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

Сильные стороны реляционной базы данных

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

Вообще сами РБД появились ещё в 70-х. Однако сегодня благодаря своим сильным сторонам они стали самыми распространёнными моделями для организации баз данных на планете.

Целостность

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

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

Фиксация перемен и атомарность

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

Хранимые процедуры и РБД

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

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

РБД и ACID

Транзакции в РБД отличаются 4 важными свойствами:

  • атомарность или неразрывность;
  • целостность;
  • неизменность;
  • изолированность.

Эти свойства в комплексе получили название ACID. Неразрывность касается всех частей структуры, которые нужны, чтобы осуществить транзакцию в БД. Целостность или согласованность устанавливает правила сохранения данных после того, как транзакция сделана. Изолированность — это гарантия того, что транзакция не скажется на другие данные до того, как все изменения будут сохранены. А неизменность гарантирует сохранность данных после того, как изменения были уже сохранены в результате транзакции.

Блокировка БД и параллельный доступ

С данными одновременно могут работать несколько пользователей или приложений. И вполне реалистична ситуация, когда поступит сразу несколько запросов на изменение одной и той же информации. Причём изменения могут быть различного характера. Это вызывает конфликт в БД. В такой ситуации система сохраняет функциональность благодаря функциям «параллельный доступ» и «блокировка».

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

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

СУРБД – система управления реляционными базами данных

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

При выборе конкретного типа БД и продуктов на основе РБД нужно принимать во внимание ряд факторов. В частности, подбор СУРБД зависит от потребностей компании или предпринимателя. Нужно ответить на ряд вопросов:

  • Насколько важна точность данных?
  • Нужно ли поддерживать многопользовательский режим работы?
  • Есть ли разделение по степени точности для конкретных блоков информации?
  • Планируется ли применять бизнес-логику для работы с БД?
  • Каковы объёмы данных, с которыми будет происходить работа?
  • Важна ли масштабируемость?
  • Должна ли модель БД поддерживать зеркальные копии?
  • Насколько важна целостность применительно к копиям?
  • Важно ли наличие параллельного доступа?
  • Нужен ли одновременный доступ нескольким приложениям?
  • Должно ли ПО поддерживать параллельный доступ без риска для сохранности данных?
  • Насколько важна эффективность и надёжность РБД?
  • Насколько быстрым должен быть отклик на поступающий запрос?
  • Есть ли какая-то специфика в тех данных, с которыми предстоит работать?
  • Будет ли пиковая нагрузка на базу данных?
  • Планируется ли постепенное наращивание объёма информации, с которой предполагается работа?
  • Возможен ли незапланированный простой?

Это стандартные вопросы. Возможно, у вас появятся какие-то свои. Перечень вопросов нужно тщательно продумать. Вам не нужна идеальная СУРБД. Вам необходима система, которая будет оптимально отвечать поставленным задачам.

SQL сервер является СУБД, работающей с реляционной базой данной.

Автономность РБД

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

Поэтому было решено найти выход. И им стали автономные технологии. Они позволили нарастить возможности реляционной модели. Так появилась РБД нового типа. Автономная или же самоуправляемая БД — это система, которая сохраняет возможности и преимущества реляционной модели, а также добавляет к ним средства на базе искусственного интеллекта, автоматизации и машинного обучения для оптимизации и мониторинга скорости осуществления запросов и управления.

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

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

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

Получить помощь в работе с РБД

Подписаться на канал новостей и инструкций 1С

Другие статьи

    Структура реляционной базы данных | Основы реляционных баз данных

    Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

    PostgreSQL — это СУБД, созданная для работы с реляционными базами данных. Что такое «реляционная», мы рассмотрим в будущем уроке. А в этом разберем, как устроены такие базы данных.

    Структура реляционной базы данных

    Данные в реляционных базах данных хранятся в таблицах. Их структура напоминает Microsoft Excel. Каждая строка в таблице — это связанный набор данных, который относится к одному предмету. Например, в таблице можно посмотреть все детали об одном сотруднике — его фамилию, имя, номер, отдел, зарплату, год рождения, адрес и телефон:

    Разные таблицы предназначены для хранения информации о различных сущностях, например, пользователи, статьи или заказы в интернет-магазине. В типичных веб-приложениях таблиц десятки и сотни, в больших — тысячи. Например, в Хекслете их несколько сотен.

    У таблиц в базе данных есть определенная структура. Она включает:

    • Название таблицы
      — уникально в рамках одной базы данных. Имя таблицы и ее структура задаются при создании, но их можно изменить впоследствии
    • Столбцы или поля — располагаются в строго определенном порядке, и у каждого поля уникальное имя в рамках одной таблицы
    • Тип данных — сопоставляется каждому столбцу. Тип данных ограничивает набор допустимых значений, которые можно присвоить столбцу, и определяет смысловое значение данных для вычислений. Например, в столбец числового типа нельзя записать обычные текстовые строки, но его данные можно использовать в математических вычислениях, и наоборот
    • Строки — их число переменно и отражает текущий объем данных. В отличие от таблиц в Exсel, в таблицах реляционных баз данных нет никаких гарантий относительно порядка строк в таблице. Он может быть любым, и его можно задать с помощью языка SQL, который рассмотрим позже. Объем данных в разных таблицах сильно отличается — от нескольких штук до миллиардов записей

    Пример таблицы с именем users:

    Структура

    Включает в себя имена полей и их типы. Структура определяет столбцы:

    first_name string
    last_name  string
    email      string
    created_at datetime
    

    Содержание

    Включает в себя данные. Содержание определяет строки:

    | first_name | last_name |       email       | created_at |
    |------------|-----------|-------------------|------------|
    | Сергей     | Петров    | [email protected]    | 11.10.2005 |
    | Иван       | Сидоров   | [email protected] | 03.08.2000 |
    | Виктор     | Курганов  | [email protected]  | 23.12.2011 |
    

    first_name, last_name, email и created_at — это имена столбцов. Строки содержат данные по каждому столбцу, а в поле created_at установлен тип данных

    datetime, поэтому туда нельзя записать текст.

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

    Правила именования сущностей базы данных

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

    В этом курсе мы используем именование, принятое во фреймворке Rails и его ORM (ActiveRecord). Оно состоит из нескольких правил:

    • Все имена в нижнем регистре
    • Для имен из нескольких слов используется snake_case — когда слова разделяются подчеркиванием _ без пробелов
    • Имя таблицы во множественном числе

    В отличие от Excel, где ввод данных и отображение визуальные, в СУБД у данных нет никакого представления. Они вводятся и выбираются с помощью команд. При этом существуют специальные клиенты, которые используются, чтобы визуализировать управление базами данных. Они бывают платными и бесплатными. Из бесплатных в мире PostgreSQL наиболее популярен PgAdmin:

    Рекомендуем поставить его и поэкспериментировать внутри.

    Управлять структурой базы данных и данными внутри таблиц — две разные задачи. При этом они выполняются одним инструментом — языком SQL.

    Язык SQL

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

    -- Пример запроса, который извлекает
    -- информацию о пользователях из таблицы users
    SELECT * FROM users;
    

    SQL разрабатывается независимо от баз данных и имеет собственный стандарт, который реализуют конкретные базы данных. Поэтому на базовом уровне все реляционные базы работают примерно одинаково.

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

    Выводы

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

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


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

    Остались вопросы? Задайте их в разделе «Обсуждение»

    Вам ответят команда поддержки Хекслета или другие студенты.

    Для полного доступа к курсу нужен базовый план

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

    Получить доступ


    130

    курсов

    1000

    упражнений

    2000+

    часов теории

    3200

    тестов

    Открыть доступ

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

    • 130 курсов, 2000+ часов теории
    • 1000 практических заданий в браузере
    • 360 000 студентов

    Электронная почта *

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

    Наши выпускники работают в компаниях:

    Концепции реляционных баз данных

    Концепции реляционных баз данных

      

    Глава 2 Термины и концепции баз данных


    Система управления реляционными базами данных (RDBMS) хранит и извлекает данные, представленные в таблицах. Реляционная база данных состоит из набора таблиц, в которых хранятся взаимосвязанные данные.

    В этом разделе представлены некоторые термины и понятия, важны в разговоре о реляционных базах данных.

    Таблицы базы данных

    В реляционной базе данных все данные хранятся в таблицах , которые состоят из строк и столбцов .

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

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

    emp_ID

    emp_lname

    emp_fname

    emp_phone

    10057

    Хуонг

    Чжан

    1096

    10693

    Дональдсон

    Энн

    7821

    Таблицы реляционной базы данных имеют некоторые важные характеристики:

    • Не имеет значения порядок столбцов или строк.
    • Каждая строка содержит одно и только одно значение для каждого столбец.
    • Каждое значение для данного столбца имеет один и тот же тип.

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

    Формальный относительный термин

    Неформальный родственный термин

    Эквивалентный нереляционный термин

    Связь

    Стол

    Файл

    Атрибут

    Столбец

    Поле

    Кортеж

    Ряд

    Запись

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

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

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

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

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

    Таблицы имеют первичный ключ

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

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

    Примеры

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

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

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

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

    Таблицы связаны внешними ключами

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

    Пример

    Образец базы данных содержит одну таблицу с информацией о сотрудниках. и одна таблица с информацией об отделе. Стол отдела имеет следующие столбцы:

    • dept_id Идентификационный номер отдела. Это основное ключ от стола.
    • dept_name Столбец, содержащий название отдела.
    • dept_head_id Идентификатор сотрудника для руководителя отдела.

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

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

    Другие объекты базы данных

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

    • Индексы Индексы позволяют быстро находить информацию. Концептуально, индекс в базе данных подобен индексу в книге. В книге, индекс связывает каждый проиндексированный термин со страницей или страницами, на которых появляется слово. В базе данных индекс связывает каждый индексированный столбец значение физическому местоположению, в котором строка данных, содержащая индексированное значение сохраняется.
      Индексы являются важным элементом дизайна для обеспечения высокой производительности, однако их использование прозрачно для пользователя.
    • Представления Представления — это вычисляемые или виртуальные таблицы. Они выглядят как таблицы для клиентских приложений, но не содержат данных. Вместо этого всякий раз, когда к ним обращаются, информация в них вычисляется из базовых таблиц.
      Таблицы, фактически содержащие информацию, иногда назвал базовых таблиц , чтобы отличить их от Просмотры.
    • Хранимые процедуры и триггеры Это процедуры, содержащиеся в самой базе данных, которые действовать на основе информации в базе данных.
      Вы можете создавать и называть свои собственные хранимые процедуры для выполнения определенные запросы к базе данных и выполнять другие задачи базы данных. Сохранено процедуры могут принимать параметры. Например, вы можете создать хранимая процедура, которая возвращает имена всех клиентов, потрачено больше, чем сумма, которую вы указываете в качестве параметра в вызов на процедуру.

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

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

    Запросы

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

    Проекция является подмножеством столбцов в таблице. Ограничение (также называемое выбором ) — это подмножество строк в таблице, основанное на некоторых условиях.

    Например, следующий оператор SELECT получает названия и цены всех продуктов, стоимость которых превышает 15 долларов США:

     ВЫБЕРИТЕ имя, цена_единицы 
    ИЗ продукта
    ГДЕ цена_единицы > 15

    Этот запрос использует как ограничение (WHERE unit_price > 15), и прогноз (SELECT name, unit_price)

    СОЕДИНЕНИЕ связывает строки в двух или более таблицах, сравнивая значения в ключевых столбцах и возвращаемые строки с совпадающими значениями. Например, вы можете выбрать идентификационные номера элементов и названия продуктов для всех предметов, для которых более дюжины отправлено:

     ВЫБЕРИТЕ sales_order_items.id, product.name 
    FROM product KEY JOIN sales_order_items
    ГДЕ sales_order_items.quantity > 12

    Таблица продуктов и sales_order_items таблицы объединяются на основе отношений внешнего ключа между ними.

    Другие операторы SQL

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

    Системные таблицы

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

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

     


    Copyright © 2000 Sybase, Inc. Все права защищены.

    Структурированные данные, SQL и реляционные базы данных

    «Чем больше мы можем организовать, найти и управлять информацией, тем эффективнее мы сможем функционировать в нашем современном мире». — Vint Cerf

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

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

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

    Это видео Ханса Рослинга. Собирая данные о 200 странах за 200 лет, он дает представление о человеческом прогрессе.

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

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

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

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

    Предположим, нам нужно сохранить имя и адрес электронной почты рецензентов популярного веб-сайта. Самый простой подход — открыть электронную таблицу, например, в Google Docs или Microsoft Excel, и ввести несколько имен.

    1. Джон, [email protected]
    2. Алиса, [email protected]

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

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

    Как вы могли заметить, рабочий лист Users имеет три столбца с именами id , имя пользователя и электронная почта , а рабочий лист «Отзывы» имеет три столбца с именами id , имя пользователя и контент . Большинство электронных таблиц будут использовать несколько рабочих листов для организации данных. Каждый рабочий лист имеет уникальные столбцы, в которых должны храниться данные одного типа (на которые ссылается имя столбца).

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

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

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

    Электронная таблица База данных
    Рабочий лист Стол
    Столбец рабочего листа Столбец таблицы
    Строка рабочего листа Запись таблицы

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

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

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

    Существует множество систем управления реляционными базами данных, таких как SQLite, MS SQL, PostgreSQL и MySQL. Некоторые из них легковесны, просты в установке и использовании, в то время как другие надежны, масштабируемы, но сложны в установке. Эти различные СУБД могут различаться определенным образом, и некоторые из используемых ими команд могут иметь небольшие синтаксические различия. Однако у них есть одна общая черта — это базовый язык, который они все используют: SQL.

    Стоит отметить, что реляционная модель — не единственная модель структурированных данных, используемая программным обеспечением баз данных. Например, такая программа, как MongoDB, использует документно-ориентированную модель хранения данных. Эта и другие системы, использующие нереляционные модели хранения и извлечения данных, часто объединяются под термином «NoSQL». Однако для целей этой книги нас интересует только реляционная модель и то, как можно использовать SQL для взаимодействия с реляционными базами данных.

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

    SQL может произноситься как «Sequel» или как «Ess-Queue-Ell». Люди могут быть весьма педантичны в отношении того, что правильно. Однако лучше просто использовать то, что помогает лучше общаться, перенимая произношение окружающих вас людей.

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

    Цель этой книги — научить вас SQL, который позволит вам использовать любую из упомянутых выше СУБД и даже другие, не упомянутые. Чтобы научить вас SQL, мы выбрали СУБД PostgreSQL из-за ее широкой применимости и открытого исходного кода. Однако после прочтения этой книги у вас должны быть базовые знания о SQL и реляционных базах данных, а также навыки использования любой реляционной базы данных по вашему выбору.

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

    Краткая история SQL

    SQL восходит к 1970-м годам, когда он был задуман Э. Ф. Коддом в его статье «Реляционная модель для больших банков данных» . В документе заложены основы того, что станет реляционными базами данных. Вы можете слышать термин «реляционная алгебра», иногда используемый при работе с базами данных. Математические модели, лежащие в основе реляционных баз данных, выходят за рамки этой книги, но, по сути, это теория, на которой строятся реляционные базы данных. Со временем компании увидели ценность концепций, описанных в статье Кодда, и в 1970-х годах многие из них начали разрабатывать язык SQL и производить продукты, называемые реляционными базами данных.

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

    Другой способ, которым вы могли использовать SQL, — это язык программирования, такой как Python или Ruby. Например, если вы когда-либо делали учебник по Ruby on Rails, скорее всего, код, который вы написали, за кулисами сгенерировал для вас SQL. Независимо от того, какой язык вы используете, база данных и ее данные, скорее всего, переживут большую часть кода приложения в вашей программе.

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

Оставить комментарий

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

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