МОДЕЛЬ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ: ЭЛЕМЕНТЫ, КАК ЭТО СДЕЛАТЬ, ПРИМЕР - ТЕХНОЛОГИЯ - 2024

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

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

Источник: pixabay.com

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

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

Управление базами данных

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

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

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

Большинство реляционных баз данных используют язык SQL для запроса и определения данных. В настоящее время существует множество систем управления реляционными базами данных или СУБД (система управления реляционными базами данных), таких как Oracle, IBM DB2 и Microsoft SQL Server.

Особенности и элементы

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

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

- Все значения являются скалярами. То есть в любой позиции строки / столбца в таблице есть только одно значение.

-элементов

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

Кортеж

Каждая строка данных представляет собой кортеж, также известный как запись. Каждая строка представляет собой набор из n элементов, но «n-» обычно отбрасывается.

колонка

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

ключ

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

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

-Правила честности

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

Ключевая целостность

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

Для ключа с несколькими столбцами ни один из этих столбцов не может содержать NULL.

Ссылочная целостность

Каждое значение внешнего ключа должно соответствовать значению первичного ключа ссылочной или первичной таблицы.

Строку с внешним ключом можно вставить во вторичную таблицу, только если это значение существует в первичной таблице.

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

Как сделать реляционную модель?

-Собирать информацию

Необходимые данные должны быть собраны для хранения в базе данных. Эти данные разделены на разные таблицы.

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

-Определить первичные ключи

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

-Создание отношений между таблицами

База данных, состоящая из независимых, не связанных между собой таблиц, не имеет большого смысла.

Наиболее важным аспектом при разработке реляционной базы данных является определение отношений между таблицами. Типы отношений:

Один ко многим

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

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

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

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

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

Создайте две таблицы

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

Затем можно создать отношение «один ко многим», сохранив первичный ключ из главной таблицы (Master_Id) в таблице классов, как показано ниже.

Столбец Master_Id в таблице классов известен как внешний ключ или вторичный ключ.

Для каждого значения Master_Id в таблице Master может быть ноль или более строк в таблице классов. Для каждого значения Class_Id в таблице Classes есть только одна строка в таблице Teachers.

Многие для многих

В базе данных «Продажа продуктов» заказ клиента может содержать несколько продуктов, а продукт может фигурировать в нескольких заказах. Этот тип отношений известен как многим.

Вы можете начать базу данных «Продажи продукции» с двух таблиц: «Товары» и «Заказы». Таблица Products содержит информацию о продуктах с productID в качестве первичного ключа.

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

Вы не можете хранить заказанные продукты в таблице «Заказы», ​​поскольку не знаете, сколько столбцов зарезервировать для продуктов. По той же причине заказы не могут храниться в таблице «Товары».

Для поддержки отношения «многие ко многим» вам необходимо создать третью таблицу, известную как таблица соединений (OrderDetails), где каждая строка представляет элемент в определенном порядке.

Для таблицы OrderDetails первичный ключ состоит из двух столбцов: orderID и productID, однозначно идентифицирующих каждую строку.

Столбцы orderID и productID в таблице OrderDetails используются для ссылки на таблицы Orders и Products. Следовательно, они также являются внешними ключами в таблице OrderDetails.

По одному

В базе данных «Продажа товаров» товар может иметь дополнительную информацию, такую ​​как дополнительное описание и его изображение. Если оставить его внутри таблицы Products, будет образовано много пустых пространств.

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

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

преимущество

Структурная независимость

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

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

Концептуальная простота

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

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

Простота проектирования, реализации, обслуживания и использования

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

Емкость специальных запросов

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

Язык запросов модели реляционной базы данных, называемый языком структурированных запросов или SQL, делает специальные запросы реальностью. SQL - это язык четвертого поколения (4GL).

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

Недостатки

Затраты на оборудование

Модель реляционной базы данных скрывает сложность ее реализации и детали физического хранения пользовательских данных.

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

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

Легкость дизайна может привести к плохому дизайну

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

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

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

Феномен «информационных островов»

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

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

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

пример

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

Каждая строка в таблице «Поставщики» идентифицируется уникальным номером поставщика (SNo), однозначно определяющим каждую строку в таблице. Точно так же каждая деталь имеет уникальный номер детали (PNo).

Кроме того, не может быть более одной отгрузки для данной комбинации Поставщик / Деталь в таблице Отгрузки, поскольку эта комбинация является первичным ключом Отгрузки, которая служит объединенной таблицей, поскольку это отношение «многие ко многим».

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

Анализируя таблицу «Отгрузки», можно получить информацию о том, что всего от поставщиков Suneet и Ankit отправлено 500 орехов, по 250 у каждого.

Точно так же в общей сложности 1100 болтов были отправлены от трех разных поставщиков. От поставщика Suneet было отправлено 500 синих винтов. Поставок красных винтов нет.

Ссылки

1. Википедия, бесплатная энциклопедия (2019). Реляционная модель. Взято с: en.wikipedia.org.
2. Техопедия (2019). Реляционная модель. Взято с: потолокpedia.com.
3. Динеш Такур (2019). Реляционная модель. Электронный компьютер Заметки. Взято с: ecomputernotes.com.
4. Гики для гиков (2019). Реляционная модель. Взято с: geeksforgeeks.org.
5. Наньянский технологический университет (2019). Краткое руководство по проектированию реляционных баз данных. Взято с: ntu.edu.sg.
6. Адриенн Ватт (2019). Глава 7 Реляционная модель данных. До н.э. Открытые учебники. Взято с сайта: opentextbc.ca.
7. Топпр (2019). Реляционные базы данных и схемы. Взято с: toppr.com.