Меню

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

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

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

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

Рис. 1.2. Типовая структура таблицы реляционной БД

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

Виртуальным аналогом таблицы является представление, которое ведет себя с точки зрения клиента как обычная таблица, но не существует самостоятельно. Обычная таблица содержит данные. Представление же не содержит никаких данных, а только задает их источники (одну или несколько обычных таблиц, выбираемые строки, выбираемые столбцы). Фактически представление сохраняется в БД как запрос на создание определенного набора данных. Результат выполнения этого запроса является содержанием представления. При изменении данных в таблицах-источниках меняется и содержание представления.

Для выявления в таблице отдельной записи используют ключ. Первичный ключ (Primary Key, РК) имеет каждая таблица. Это столбец, однозначно определяющий каждую запись в таблице. В нашем примере в качестве РК может быть столбец Фамилия. Это правильно до появления, например, еще одного Бендера. Для обеспечения уникальности значения первичного ключа применяются две методики. Во-первых, может использоваться составной первичный ключ (Composite Primary Key), образуемый несколькими столбцами (естественными атрибутами) таблицы. Во-вторых, в качестве РК можно вводить в таблицу дополнительный столбец, не имеющий смысла с точки зрения предметной области. Его называют суррогатным ключом. Например, суррогатным ключом может быть Номер заказчика или Номер заказа.

Важную роль в реляционных БД играет еще один ключ — Внешний ключ. Внешний ключ (Foreign Key, FK) — это столбец одной таблицы, который ссылается на первичный ключ другой таблицы. С помощью внешних ключей устанавливаются связи между различными таблицами БД (пример приведен на рис. 1.3) – ускорение доступа к таблице с помощью индекса.

Рис. 1.3. Внешний ключ

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

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

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

Рис. 1.4. Ускорение доступа к таблице с помощью индекса

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

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

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

Отношение «один-к-одному». В этом случае каждой строке (записи) одной таблицы ставится в соответствие строка другой таблицы (рис. 1.5).

Рис. 1.5. Отношение «один-к-одному»

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

Отношение «один-ко-многим». Одной записи первой таблицы ставятся в соответствие несколько записей во второй таблице (рис. 1.6).

Рис. 1.6. Отношение «один-ко-многим»

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

Отношение «многие-ко-многим». Одной записи первой таблицы могут соответствовать несколько записей во второй таблице, а одной записи второй таблицы — несколько записей первой (рис. 1.7).

Рис. 1.7. Отношение «многие-ко-многим»

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

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

Первая нормальная форма (1НФ) требует, чтобы значения всех элементов данных в столбцах были атомарными. Вторая нормальная форма (2НФ) требует, чтобы каждый неключевой столбец полностью зависел от первичного ключа. Третья нормальная форма (3НФ) требует, чтобы все неключевые столбцы (атрибуты) были взаимно независимы и полностью зависели от первичного ключа. Зависимость существует, если, например, значения одного столбца вычисляются по данным других столбцов. Результатом проведения нормализации является оптимальная структура базы данных, в которой имеется необходимое дублирование данных, но отсутствует избыточное.

Читайте также:  Показать пользователей имеющих доступ к конкретной базе данных

Источник

Руководство по разработке структуры и проектированию базы данных

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

Этапы создания базы данных

Надлежащим образом структурированная база данных:

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

Основные этапы разработки базы данных:

  1. Анализ требований или определение цели базы данных;
  2. Организация данных в таблицах;
  3. Указание первичных ключей и анализ связей;
  4. Нормализация таблиц.

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

Анализ требований: определение цели базы данных

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

Вот несколько способов сбора информации перед созданием базы данных:

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

Начните со сбора существующих данных, которые будут включены в базу. Затем определите типы данных, которые нужно сохранить. А также объекты, которые описывают эти данные. Например:

  • Имя;
  • Адрес;
  • Город, штат, почтовый индекс;
  • Адрес электронной почты.
  • Название;
  • Цена;
  • Количество в наличии;
  • Количество под заказ.
  • Номер заказа;
  • Торговый представитель;
  • Дата;
  • Товар;
  • Количество;
  • Цена;
  • Стоимость.

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

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

Структура базы данных: построение блоков

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

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

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

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

  • CHAR — конкретная длина текста;
  • VARCHAR — текст различной длины;
  • TEXT — большой объем текста;
  • INT — положительное или отрицательное целое число;
  • FLOAT, DOUBLE — числа с плавающей запятой;
  • BLOB — двоичные данные.

Некоторые СУБД также предлагают тип данных Autonumber, который автоматически генерирует уникальный номер в каждой строке.

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

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

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

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

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

Создание связей между сущностями

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

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

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь « один-к одному» ( часто обозначается 1:1). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

Источник



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

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

Отношение. Плоская таблица, состоящая из столбцов и строк.

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

Атрибут. Именованный столбец отношения.

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

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

Степень. Степень отношения определяется количеством атрибутов, которое оно содержит.

Кардинальность. Количество кортежей, которое содержится в отношении.

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

Читайте также:  Футбол Европа Лига чемпионов 2009 2010

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

Реляционная база данных состоит из отношений, структура которых определяется с помощью особых методов, называемых нормализацией (normalization).

Основные определения реляционных СУБД

Реляционная модель данных— Организует и представляет данные в виде таблиц или реляций.

Реляционная база данных (РБД, RDBMS).- База данных, построенная на реляционной модели.

Реляция (таблица-элементарная информационная единица) — Двумерная таблица, содержащая строки и столбцы данных.

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

Кортежи— Строки реляции (таблицы), соответствуют объекта, конкретному событию или явлению.

Атрибуты— Столбцы таблицы, характеризующие признаки, параметры объекта, события, явления.

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

Пустое значение— Значение, приписываемое атрибуту в кортеже, если атрибут неприменим или его значение неизвестно

Ключ— Любой набор атрибутов, однозначно определяющий каждый кортеж реляционной таблицы.

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

Составной ключ- Ключ содержащий два или более атрибута.

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

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

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

Рекурсивный внешний ключ. — Внешний ключ, ссылающийся на свою собственную реляционную таблицу.

Родительская реляция (таблица)- Таблица, поля которой входят в другую таблицу.

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

Отношение один-к-одному- Когда одной записи в родительской таблицы соответствует одна запись в дочерней таблице

Отношение один-ко-многим — Когда одной записи в родительской таблицы соответствует несколько записей в дочерней таблице

Отношение многие-ко-многим — Когда многим записям в родительской таблицы соответствуют несколько записей в дочерней таблице

Рекурсивное отношение.- Отношение, связывающее объектное множество с ним самим.

View (Представления) — Информационная единица РБД (по структуре аналогичная таблице), записи которой сформированы в результате выполнения запросов к другим таблицам.

Ссылочная целостность- Адекватное воспроизведение записей в ссылочных полях таблиц.

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

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

Транзакция— Такое воздействие на СУБД, которое переводит ее из одного целостного состояния в другое.

Источник

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

Для создания структур реляционных баз данных в Visio предусмотрен специальный шаблон диаграмм «Схема модели базы данных», относящийся к категории «Программное обеспечение и базы данных» [5].

Важно В предыдущих версиях Visio шаблон диаграмм, используемый для создания структуры базы данных, расположен в отдельной категории «База данных» (Database).

Для создания новой структуры реляционной базы данных следует выбрать шаблон «Схема модели базы данных» в окне «Приступая к работе» и нажать кнопку «Создать» или выбрать пункт меню «Файл/Создать/Программное обеспечение и базы данных/ Схема модели базы данных». При этом Visio создаст новую модель базы данных, внешний вид которой представлен на рис. 7.5.

Рис. 7.5. Новая модель реляционной базы данных с добавленной сущностью.

Задание свойств сущностей

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

Рис. 7.6. Изменение названия сущности.

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

Рис. 7.7. Изменение атрибутов сущности.

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

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

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

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

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

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

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

Вариант 1. Моделирование обзорной радиолокационной станции управления воздушным движением.

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

Вариант 2. Генератор периодических низкочастотных сигналов.

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

Читайте также:  Как сделать калькуляцию блюда в столовой Расчет стоимости блюда

Вариант 3. Внутриофисная охранная сигнализация.

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

Вопросы для самопроверки

1. Из чего состоят реляционные базы данных?

2. Что такое «сущности»?

3. Что такое «поле»?

4. Какие виды связей позволяет моделировать Visio?

5. Как осуществить моделирование связи многие-ко-многим?

Источник

Реляционные базы данных — определение, структура, примеры

Особенности реляционных БД

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

  1. Уникальное имя для каждой таблицы.
  2. Фиксированное число полей.
  3. На пересечении строки и столбца всегда есть только одно значение.
  4. Записи отличаются друг от друга хотя бы одним значением элемента.
  5. Полям присваиваются индивидуальные имена.
  6. В каждый из столбцов необходимо вставлять однородные данные: целые числа, даты, суммы, имена или фамилии, названия предметов.

Реляционная БД чаще всего не ограничивается одной таблицей. Обычно создаются несколько таблиц со связанной информацией. Это позволяет исполнять более сложные операции над данными. Таблицы реляционной БД обязаны соответствовать требованиям понятия нормализации отношений, то есть ограничениям на формирование, которые позволят избежать дублирования и обеспечат непротиворечивость хранимой информации. Пусть создана таблица «Прокат», содержащая следующие поля: Шифр Клиента, Ф. И. О., Вид устройства, Дата выдачи, Оплата, Срок возврата. Эта организация хранения информации имеет несколько недостатков:

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

Для устранения этих недостатков необходима нормализация с разделением данных на разные таблицы.

Связывание таблиц

Для любой таблицы реляционной БД задаётся первичный ключ (primary key) — поле или сочетание полей, которые определяют каждую запись. Внешний или вторичный ключ (foreign key) — это одно или несколько полей, ссылающихся на поле primary key другой таблицы.

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

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

  • один к одному;
  • один ко многим;
  • многие ко многим.

Связи «один к одному» встречаются довольно редко. «Один ко многим» применяются чаще, например, кассир продаёт много билетов. «Многие ко многим» тоже встречаются часто. Например, студент изучает много предметов. Связи «многие ко многим» нельзя организовывать непосредственно. Для установления отношения необходимо сопоставить каждому primary key внешний ключ, который представляет собой primary key другой таблицы. Реляционные системы базируются на теории реляционной модели, которая включает в себя три аспекта:

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

Управление созданием и использованием БД осуществляется системами управления базами данных (СУБД).

Под их руководством:

  • производится добавление, определение, удаление и поиск записей;
  • изменяются значения полей.

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

Стадии и пример проектирования хранилища

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

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

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

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

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

Атрибутами для сопоставления объектов друг другу должны выступать ячейки с уникальным содержимым. В таблицах есть по одному полю с уникальными данными. В № 1 «Клиент» — это шифр клиента, а в № 3 «Склад» — шифр устройства. Это и будут primary keys. Каждая строка таблицы «Прокат» будет связывать два внешних ключа между собой:

  • Шифр Клиента — foreign key, ссылающийся на primary key в таблице «Клиент».
  • Шифр устройства — foreign key, ссылающийся на первичный ключ в таблице «Склад».

Проблемы модели

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

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

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

Источник

Adblock
detector