Как создать реляционную базу данных
Система управления реляционными базами данных Microsoft Access позволяет создавать реляционные базы данных, а также обеспечивать их обработку с помощью запросов, форм и отчетов.
Создадим реляционную базу данных «Компьютер», в качестве основных объектов которой будут использованы три таблицы: «Комплектующие», «Поставщики» и «Цена». Таблицы «Комплектующие» и «Поставщики» должны быть связаны отношением «многие-ко-многим» с помощью таблицы «Цена».
Итак, прежде всего необходимо создать три таблицы: «Комплектующие» «Поставщики» и «Цена».
Создание реляционной базы данных «Компьютеры»
1. Создать в приложении Access новую базу данных с помощью команды [Файл-Создать базу данных. ] и присвоить ей имя «Компьютеры».
2. В окне Компьютеры: база данных выбрать группу объектов Таблицы и пункт Создание таблицы в режиме конструктора.
Таблица «Комплектующие» должна содержать три текстовых поля: «Код комплектующих», «Наименование» и «Описание». Ключевым полем является поле «Код комплектующих».
3. В окне Комплектующие: таблица ввести имена полей, тип данных и параметры полей.
В качестве ключевого поля задать поле «Код комплектующих».
Для сохранения таблицы ввести команду [Файл-Сохранить].
Присвоить таблице имя «Комплектующие».
4. Для ввода данных в таблицу щелкнуть на значке Комплектующие. Ввести данные в таблицу.
Таблица «Поставщики» должна содержать три текстовых поля: «Код поставщика», «Название фирмы» и «Адрес». Ключевым полем является поле «Код поставщика».
5. Создать таблицу «Поставщики», выполнив рассмотренную выше последовательность действий. Ввести данные.
Таблица «Цена» должна содержать поля Счетчик, Код комплектующих, Код поставщика, а также поле Цена. В качестве ключа этой таблицы будет использоваться поле Счетчик.
6. С помощью аналогичных действий создать таблицу «Цена» и ввести данные. В полях внешних ключей не могут содержаться значения, отсутствующие в соответствующих ключевых полях главных таблиц.
Таблицы «Комплектующие» и «Поставщики» должны быть связаны отношением «один-ко-многим» с таблицей «Цена». Таблица «Цена» содержит однотипные с полями первых двух таблиц поля «Код комплектующих» и «Код поставщика», являющиеся внешними ключами исходных таблиц.
Установим связи между таблицами с помощью окна Схема данных.
7. Ввести команду [Сервис-Схема данных]. Появится диалоговая панель Добавление таблицы. Выделить в этом окне нужные таблицы и щелкнуть по кнопке Добавить.
8. Выделенные таблицы будут добавлены в специальное окно — Схема данных.
Для установки между таблицами «Комплектующие» и «Поставщики» связи в отношении «многие-ко-многим» необходимо связать их с таблицей «Цена» в отношении » один-ко-многим «.
9. Перетащить мышью из таблицы «Комплектующие» ключевое поле — «Код комплектующих» (оно выделено жирным шрифтом) к одноименному полю внешнего ключа таблицы «Цена».
10. На появившейся диалоговой панели Связи установить опцию Обеспечение целостности данных, а затем опции каскадное обновление связанных полей и каскадное удаление связанных записей. В завершение щелкнуть по кнопке Создать.
Теперь установим связь в отношении «один-ко-многим» между таблицами «Поставщики» и «Цена».
11. Перетащить мышью из таблицы «Поставщики» ключевое поле — «Код поставщика» (оно выделено жирным шрифтом) к одноименному полю — внешнему ключу таблицы «Цена».
12. На появившейся диалоговой панели Связи установить опцию Обеспечение целостности данных, а затем опции каскадное обновление связанных полей и каскадное удаление связанных записей. В завершение щелкнуть на кнопке Создать.
Теперь связь в отношении «многие-ко-многим» между таблицами «Комплектующие» и «Поставщики» через таблицу «Цена» установлена.
13. Это наглядно представлено в окне Схема данных.
Созданная реляционная база данных «Компьютеры» состоит из трех связанных таблиц и поэтому обладает целостностью данных. Это значит, что можно создавать запросы, формы и отчеты, которые используют данные из разных таблиц.
Создадим, например, запрос, который осуществляет выбор информации, необходимой для закупки дешевого системного блока.
Создание запроса в реляционной базе данных » Компьютеры «
1. На диалоговой панели Новый запрос выбрать опцию Конструктор и щелкнуть по кнопке ОК.
Что такое реляционная база данных?
Реляционная база данных – это набор данных с предопределенными связями между ними. Эти данные организованны в виде набора таблиц, состоящих из столбцов и строк. В таблицах хранится информация об объектах, представленных в базе данных. В каждом столбце таблицы хранится определенный тип данных, в каждой ячейке – значение атрибута. Каждая стока таблицы представляет собой набор связанных значений, относящихся к одному объекту или сущности. Каждая строка в таблице может быть помечена уникальным идентификатором, называемым первичным ключом, а строки из нескольких таблиц могут быть связаны с помощью внешних ключей. К этим данным можно получить доступ многими способами, и при этом реорганизовывать таблицы БД не требуется.
Важные аспекты реляционных БД
SQL (Structured Query Language) – основной интерфейс работы с реляционными базами данных. SQL стал стандартом Национального института стандартов США (ANSI) в 1986 году. Стандарт ANSI SQL поддерживается всеми популярными ядрами реляционных БД. Некоторые из ядер также включают расширения стандарта ANSI SQL, поддерживающие специфичный для этих ядер функционал. SQL используется для добавления, обновления и удаления строк данных, извлечения наборов данных для обработки транзакций и аналитических приложений, а также для управления всеми аспектами работы базы данных.
Целостность данных
Целостность данных – это полнота, точность и единообразие данных. Для поддержания целостности данных в реляционных БД используется ряд инструментов. В их число входят первичные ключи, внешние ключи, ограничения «Not NULL», «Unique», «Default» и «Check». Эти ограничения целостности позволяют применять практические правила к данным в таблицах и гарантировать точность и надежность данных. Большинство ядер БД также поддерживает интеграцию пользовательского кода, который выполняется в ответ на определенные операции в БД.
Транзакция в базе данных – это один или несколько операторов SQL, выполненных в виде последовательности операций, представляющих собой единую логическую задачу. Транзакция представляет собой неделимое действие, то есть она должна быть выполнена как единое целое и либо должна быть записана в базу данных целиком, либо не должен быть записан ни один из ее компонентов. В терминологии реляционных баз данных транзакция завершается либо действием COMMIT, либо ROLLBACK. Каждая транзакция рассматривается как внутренне связный, надежный и независимый от других транзакций элемент.
Соответствие требованиям ACID
Для соблюдения целостности данных все транзакции в БД должны соответствовать требованиям ACID, то есть быть атомарными, единообразными, изолированными и надежными.
Атомарность – это условие, при котором либо транзакция успешно выполняется целиком, либо, если какая-либо из ее частей не выполняется, вся транзакция отменяется. Единообразие – это условие, при котором данные, записываемые в базу данных в рамках транзакции, должны соответствовать всем правилам и ограничениям, включая ограничения целостности, каскады и триггеры. Изолированность необходима для контроля над согласованностью и гарантирует базовую независимость каждой транзакции. Надежность подразумевает, что все внесенные в базу данных изменения на момент успешного завершения транзакции считаются постоянными.
Что такое реляционная база данных (РСУБД)?
Реляционные базы данных представляют собой базы данных, которые используются для хранения и предоставления доступа к взаимосвязанным элементам информации. Реляционные базы данных основаны на реляционной модели — интуитивно понятном, наглядном табличном способе представления данных. Каждая строка, содержащая в таблице такой базы данных, представляет собой запись с уникальным идентификатором, который называют ключом. Столбцы таблицы имеют атрибуты данных, а каждая запись обычно содержит значение для каждого атрибута, что дает возможность легко устанавливать взаимосвязь между элементами данных.
Пример реляционной базы данных
В качестве примера рассмотрим две таблицы, которые небольшое предприятие использует для обработки заказов продукции. Первая таблица содержит информацию о заказчиках: каждая запись в ней включает в себя имя и адрес заказчика, платежные данные и информацию о доставке, номер телефона и т. д. Каждый элемент информации (атрибут) помещен в отдельный столбец базы данных, которому назначен уникальный идентификатор (ключ) для каждой строки. Во второй таблице (с информацией о заказе) каждая запись содержит идентификатор заказчика, совершившего заказ, название заказанного продукта, его количество, размер или цвет и т. д. Записи в этой таблице не содержат таких данных, как имя заказчика или его контактные данные.
У обеих таблиц есть только один общий элемент — идентификатор столбца (ключ). Благодаря наличию этого общего столбца реляционные базы данных могут устанавливать взаимосвязи между двумя таблицами. Когда приложение для обработки заказов передает заказ в базу данных, база данных обращается к таблице со сведениями о заказах, извлекает сведения о продукции и использует идентификатор заказчика из этой таблицы, чтобы найти сведения об оплате и доставке в таблице с информацией о нем. Затем на складе подбирают нужный продукт, заказчик своевременно получает свой заказ и производит оплату.
Структура реляционных баз данных
Реляционная модель подразумевает логическую структуру данных: таблицы, представления и индексы. Логическая структура отличается от физической структуры хранения. Такое разделение дает возможность администраторам управлять физической системой хранения, не меняя данных, содержащихся в логической структуре. Например, изменение имени файла базы данных не повлияет на хранящиеся в нем таблицы.
Разделение между физическим и логическим уровнем распространяется в том числе на операции, которые представляют собой четко определенные действия с данными и структурами базы данных. Логические операции дают возможность приложениям определять требования к необходимому содержанию, в то время как физические операции определяют способ доступа к данным и выполнения задачи.
Чтобы обеспечить точность и доступность данных, в реляционных базах должны соблюдаться определенные правила целостности. Например, в правилах целостности можно запретить использование дубликатов строк в таблицах, чтобы устранить вероятность попадания неправильной информации в базу данных.
Реляционная модель
В первых базах данных данные каждого приложения хранились в отдельной уникальной структуре. Если разработчик хотел создать приложение для использования таких данных, он должен был хорошо знать конкретную структуру, чтобы найти необходимые данные. Такой метод организации был неэффективен, сложен в обслуживании и затруднял оптимизацию эффективности приложений. Реляционная модель была разработана, чтобы устранить потребность в использовании разнообразных структур данных.
Она обеспечила стандартный способ представления данных и отправки запросов, которые могли быть использованы в любых приложениях. Разработчики уяснили, что таблицы являются ключевым преимуществом реляционных баз данных, так как обеспечивают интуитивно понятный, эффективный и гибкий способ хранения структурированной информации и получения к ней доступа.
Со временем, когда разработчики стали использовать язык структурированных запросов (SQL) для записи данных в базу и отправки запросов, стало очевидным и другое преимущество реляционной модели. Вот уже на протяжении многих лет SQL широко используется в качестве языка запросов в базах данных. Он основан на алгоритмах реляционной алгебры и четкой математической структуре, что обеспечивает простоту и эффективность при оптимизации любых запросов к базе данных. Для сравнения: при использовании других подходов приходится создавать отдельные, уникальные запросы.
Преимущества системы управления реляционными базами данных
Компании всех типов и размеров используют простую, но функциональную реляционную модель для обслуживания разнообразных информационных потребностей. Реляционные базы данных применяются для отслеживания товарных запасов, обработки торговых транзакций через Интернет, управления большими объемами критически важных данных заказчиков и т. д. Реляционные базы данных можно рекомендовать для обслуживания любых информационных потребностей, где элементы данных связаны между собой и необходимо обеспечивать безопасное и надежное управление ими на основе правил целостности.
Реляционные базы данных появились в 1970-х годах. На сегодняшний день преимущества реляционного подхода сделали его самой распространенной моделью для баз данных в мире.
Реляционная модель и согласованность данных
Реляционная модель наиболее эффективно поддерживает целостность данных во всех приложениях и копиях (экземплярах) базы данных. Например, когда заказчик кладет деньги на счет с помощью банкомата, а затем проверяет баланс на мобильном телефоне, он ожидает, что поступившие средства сразу же отобразятся на счете. Реляционные базы данных отлично подходят для обеспечения целостности данных в различных экземплярах базы в одно и то же время.
Другие типы баз данных не могут одновременно поддерживать целостность больших объемов данных. Некоторые современные типы баз данных, такие как NoSQL, обеспечивают только так называемую окончательную целостность. Это значит, что, когда выполняется масштабирование данных или несколько пользователей одновременно используют одни и те же данные, необходимо некоторое время на внесение изменений. В некоторых случаях окончательная целостность вполне приемлема (например, для обновления позиций в товарном каталоге), однако для критически важной операционной деятельности бизнеса (например, транзакций с использованием корзины) реляционные базы представляют собой фундаментальный стандарт.
Фиксация изменений и атомарность
В реляционных базах данных используются очень детальные и строгие бизнес-правила и политики в отношении фиксации изменений в базе данных (то есть сохранения изменений в данных на постоянной основе). Рассмотрим для примера складскую базу данных, в которой отслеживаются три запчасти, всегда использующиеся в комплекте. Когда одну из них извлекают из товарных запасов, две другие также должны извлекаться. Если одна из трех запчастей недоступна, две другие также не могут быть проданы отдельно, то есть, чтобы в базу данных можно было внести изменения, должны быть доступны все три запчасти. Реляционная база данных не разрешит сохранять изменения, если они не касаются всех трех запчастей. Эту особенность реляционных баз данных называют атомарностью или неразрывностью. Неразрывность необходима для сохранения точности данных в базе и обеспечения соответствия с правилами, нормативными положениями и бизнес-политиками.
Свойства ACID и РСУБД
Транзакции реляционных баз данных определяются четырьмя основными свойствами: : атомарность, согласованность, изоляция и долговечность, которые обычно обозначаются аббревиатурой ACID.
- Неразрывность определяет все элементы, которые необходимы для совершения транзакции в базе данных.
- Согласованность или целостность определяет правила сохранения состояния данных после выполнения транзакции.
- Изолированность гарантирует, что во избежание путаницы транзакция не повлияет на другие элементы до окончательного сохранения изменений.
- Неизменность обеспечивает неизменность данных после сохранения изменений в результате транзакции.
Хранимые процедуры и реляционные базы данных
Доступ к данным включает в себя множество повторяющихся действий. Например, иногда для получения нужного результата простой запрос для получения информации из таблицы необходимо повторить сотню или тысячу раз. Для таких сценариев доступа к базе данных необходимо что-то вроде программного кода. Разработчикам каждый раз писать стандартный код доступа к данным для нового приложения было бы утомительно. К счастью, реляционные базы данных поддерживают хранимые процедуры, представляющие собой блоки кода, к которым можно получить доступ с помощью обычного вызова со стороны кода приложения. Например, одну и ту же хранимую процедуру можно использовать для последовательной маркировки записей в целях удобства пользователей для различных приложений. Хранимые процедуры также помогают разработчикам убедиться в правильной реализации определенных функций данных в приложении.
Блокировки базы данных и параллельный доступ
Когда несколько пользователей или приложений пытаются одновременно изменить одни и те же данные, это может вести к возникновению конфликта в базе. Блокировки и параллельный доступ снижают вероятность конфликтов и способствуют сохранению целостности данных.
Блокировка не разрешает другим пользователям и приложениям получать доступ к данным во время их обновления. В некоторых базах данных блокировка может применяться к целой таблице, что негативно отражается на эффективности приложения. В других типах баз данных, например реляционных базах Oracle, блокировка выполняется на уровне одной записи, оставляя другие записи в таблице доступными. Такой подход помогает сохранить эффективность приложения.
Инструмент параллельного доступа используется, когда несколько пользователей или приложений пытаются одновременно выполнить запросы к одной базе данных. Он обеспечивает доступ пользователей и приложений к базе данных в соответствии с политиками контроля.
Характеристики, на которые следует обратить внимание при выборе реляционной базы данных
Программное обеспечение, которое используется для сохранения, контроля и извлечения данных в базе, а также выполнения к ней запросов, называют системой управления реляционной базой данных (РСУБД). РСУБД обеспечивает интерфейс между пользователями и приложениями и базой данных, а также административные функции для управления хранением данных, их эффективностью и доступом к ним.
При выборе типа базы данных и продуктов на основе реляционных баз данных необходимо учитывать несколько факторов. Выбор РСУБД зависит от потребностей Вашей компании. Задайте себе следующие вопросы.
- Каковы наши требования к точности данных? Будем ли мы использовать бизнес-логику для хранения и обеспечения точности данных? Предъявляются ли к нашим данным более строгие требования в отношении точности (например, если Вы работаете с финансовыми данными и отчетностью)?
- Нужна ли нам масштабируемость? Какими объемами данных требуется управлять и каков прогнозируемый рост этих объемов? Должна ли модель базы данных поддерживать зеркальные копии (как отдельные экземпляры) в целях масштабирования? Если да, сможем ли мы обеспечивать целостность данных в этих экземплярах?
- Насколько важно наличие параллельного доступа? Потребуется ли пользователям и приложениям одновременный доступ к данным? Поддерживает ли ПО базы данных параллельный доступ без ущерба для безопасности?
- Каковы наши потребности в эффективности и надежности баз данных? Требуется ли нам высокоэффективная и надежная система? Каковы требования к скорости выполнения запросов? Какие гарантии дает поставщик услуг в соответствии с соглашением об уровне обслуживания (SLA) или на случай незапланированного простоя?
Реляционная база данных будущего: автономная база данных
На протяжении лет реляционные базы данных улучшали производительность, надежность и безопасность и становились проще в обслуживании. Однако их структура становилась все более сложной, и, как следствие, администрирование такой базы данных начало требовать немалых усилий. Вместо того чтобы использовать свои навыки для разработки инновационных приложений, которые будут приносить прибыль организации, разработчики вынуждены посвящать львиную долю времени на управление базой данных для оптимизации ее эффективности.
Сегодня автономные технологии используются, чтобы расширить возможности реляционной модели, технологии облачных баз данных и машинного обучения и создать реляционную базу данных нового типа. Самоуправляемая база данных (которую также называют автономной) сохраняет все преимущества и возможности реляционной модели и добавляет к ним средства на основе искусственного интеллекта, машинного обучения и автоматизации для мониторинга и оптимизации скорости выполнения запросов и управления. Например, чтобы улучшить скорость выполнения запросов, самоуправляемая база данных строит прогнозы и проверяет индексы, а затем применяет лучшие результаты на практике — и все это без участия администратора. Самоуправляемые базы данных постоянно вносят такие улучшения в собственную работу без человеческого вмешательства.
Автономные технологии дают возможность разработчикам больше не тратить время на рутинные задачи обслуживания. Например, больше не нужно заблаговременно определять требования к инфраструктуре. При использовании самоуправляемой базы данных можно расширять системы хранения и добавлять вычислительные ресурсы по мере возникновения необходимости в них. Разработчики могут создавать автономные реляционные базы данных всего за несколько шагов, ускоряя процесс разработки приложений.
Как создать реляционную базу данных
Создание базы данных
Создание новой нормализованной реляционной базы данных Access осуществляется в соответствии с ее структурой, полученной в результате проектирования. Процесс проектирования реляционной базы данных был рассмотрен в предыдущей главе. Структура реляционной базы данных определяется составом таблиц и их взаимосвязями. Взаимосвязи между двумя таблицами реализуются через ключ связи, входящий в состав полей связываемых таблиц. Напомним, что в нормализованной реляционной базе данных таблицы находятся в отношениях типа «один-ко-многим» или «один-к-одному». Для одно-многозначных отношений в качестве ключа связи, как правило, используется уникальный ключ главной таблицы, в подчиненной таблице это может быть любое из полей, которое называется внешним ключом.
Создание реляционной базы данных начинается с формирования структуры таблиц. При этом определяется состав полей, их имена, тип данных каждого поля, размер поля, ключи, индексы таблицы и другие свойства полей. После определения структуры таблиц создается схема данных, в которой устанавливаются связи между таблицами. Access запоминает и использует эти связи при заполнении таблиц и обработке данных.
При создании базы данных важно задать параметры, в соответствии с которыми Access будет автоматически поддерживать целостность данных. Для этого при определении структуры таблиц должны быть заданы ключевые поля таблиц, указаны ограничения на допустимые значения данных, а при создании схемы данных на основе нормализованных таблиц должны быть заданы параметры поддержания целостности связей базы данных.
Завершается создание базы данных процедурой загрузки, т. е. заполнением таблиц конкретными данными. Особое значение имеет технология загрузки взаимосвязанных данных. Удобным инструментом загрузки данных во взаимосвязанные таблицы являются формы ввода/вывода, обеспечивающие интерактивный интерфейс для работы с данными базы. Формы позволяют создать экранный аналог документа источника, через который можно вводить данные во взаимосвязанные таблицы.
ВНИМАНИЕ!
Пользователь может начинать работу с базой при любом количестве созданных таблиц еще до создания полной базы, отображающей все объекты модели данных предметной области. База данных может создаваться поэтапно, и в любой момент ее можно дополнять новыми таблицами и вводить связи между таблицами в схему данных, существующие таблицы могут дополняться новыми полями.
Создание базы данных в MS Access 2010
На открывшейся после запуска Access странице отображено представление Microsoft Office Backstage — набор команд на вкладке Файл (File) — которое предназначено для выполнения команд, применяемых ко всей базе данных. При этом на вкладке Файл (File) выбрана команда Создать (New). Область этой команды содержит Доступные шаблоны (Available Templates), позволяющие создать базу данных с использованием многочисленных шаблонов, размещенных на вашем компьютере или доступных через Интернет.
Шаблон — это готовая к использованию база данных, содержащая все таблицы, запросы, формы и отчеты, необходимые для выполнения определенной задачи. Эти готовые базы данных позволяют быстро создать приложения, ориентированные на поддержку широкого спектра задач. Непрерывно появляются новые шаблоны приложений, которые можно загрузить с веб-узла Microsoft Office Online. Эти стандартные приложения можно использовать без какой-либо модификации и на-стройки либо, взяв их за основу, приспособить шаблон к вашим нуждам и создать новые поля и таблицы, формы, отчеты и другие объекты базы данных.
Команда Открыть (Open) предназначена для открытия любой ранее созданной базы данных. Здесь же доступен список из 4 последних открываемых баз данных. Команда Последние (Recent) открывает более длинный список недавно открываемых баз данных. Щелчком на значке кнопки можно добавить базу данных в список последних, а щелчком на значке удалить из списка.
Команда Открыть (Open) предназначена для открытия любой ранее созданной базы данных. Здесь же доступен список из 4 последних открываемых баз данных. Команда Последние (Recent) открывает более длинный список недавно открываемых баз данных.
И у нас видео на эту тему:
Про создание файла базы данных Access читаем в следующей статье.