2. Принципы реляционной модели
Принципы реляционной модели баз данных, отношение (relation), таблица (table), набор результатов (result set), кортеж, мощность, атрибут, размерность, заголовок, тело, домен
Реляционная модель была разработана в конце 1960-х годов Е.Ф.Коддом (сотрудник IBM) и опубликованы в 1970 г. Она определяет способ представления данных (структуру данных), методы защиты данных (целостность данных), и операции, которые можно выполнять с данными (манипулирование данными).
Реляционная модель - не единственная, которую можно использовать при работе с данными. Существуют также иерархическая модель, сетевая модель, звездообразная модель и т.п. Однако реляционная модель оказалась наиболее удобной и поэтому используется сейчас наиболее широко.
Основные принципы реляционных баз данных можно сформулировать так:
· все данные на концептуальном уровне представляются в виде упорядоченной организации, определенной в виде строк и столбцов и называемой отношением (relation). Более распространенный синоним слова "отношение" - таблица (или "набор записей", или набор результатов - result set. Именно от этого и происходит термин "реляционные базы данных", а вовсе не от отношений между таблицами;
· все значения являются скалярами. Это значит, что для любой строки и столбца любого отношения существует одно и только одно значение;
· все операции выполняются над целым отношением и результатом этих операций также является целое отношение. Этот принцип называется замыканием. Поэтому результаты одной операции (например, запроса), можно использовать в качестве исходных данных для выполнения другой операции (подзапроса).
Теперь - про формальную терминологию:
· отношение (relation ) - это вся структура целиком, набор записей (в обычном понимании - таблица).
· кортеж - это каждая строка, содержащая данные. Более распространенный, но менее формальный термин - запись.
· мощность - число кортежей в отношении (проще говоря, число записей);
· атрибут - это столбец в отношении;
· размерность - это число атрибутов в отношении (в данном случае - 3);
· каждое отношение можно разделить на две части - заголовок и тело . На простом языке заголовок отношения - это список столбцов, а тело - это сами записи (кортежи).
· в нашем примере название каждого столбца (атрибута) состоит из двух слов, разделенных двоеточием. Согласно формальным определениям, первая часть - это имя атрибута (название столбца), а вторая часть - это домен (вид данных, которые представляет данных столбец). Понятия "домен" и "тип данных" не эквиваленты друг другу. На практике домен обычно опускается.
· тело отношения состоит из неупорядоченного набора кортежей (его число может быть любым - от 0 до бесконечно большого).
Свойства реляционной таблицы
ОСНОВНЫЕ ПОНЯТИЯ БАЗ ДАННЫХ
База данных (БД) – именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области данных.
Примеры предметных областей данных: склад, магазин, вуз, больница, учебный процесс и т. д. Именно предметная область определяет совокупность данных, которые должны храниться в базе данных.
Система управления базами данных (СУБД) – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования базы данных многими пользователями.
Другие определения, имеющие отношение к БД и СУБД.
Банк данных (БнД) – это система специальным образом организованных данных – баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и многоцелевого использования данных.
Информационная система (ИС) – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной задачи.
Основой практически любой информационной системы является база данных.
Сервер – компьютер или программа, владеющая определенным информационным ресурсом и предназначенная для обработки запросов от программ-клиентов.
Основными моделями данных, определяющие структуру базы данных, являются:
иерархическая модель;
сетевая модель;
реляционная модель.
РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
Теоретической основой этой модели является теория отношений и основной структурой данных – отношение. Именно поэтому модель получила название реляционной (от английского слова relation - отношение).
Отношение представляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является двумерная таблица . Смысловые значения некоторых элементов реляционной модели приведены в следующей таблице.
Подавляющее число создаваемых и используемых баз данных являются реляционными . Их создание и развитие связано с научными работами известного американского математика, специалиста в области систем баз данных Э. Кодда.
Свойства реляционной таблицы
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
· каждый элемент таблицы - один элемент данных;
· все столбцы (поля, атрибуты) в таблице однородные, т.е. все элементы в одном столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
· каждый столбец имеет уникальное имя;
· одинаковые строки (записи, кортежи) в таблице отсутствуют;
· порядок следования строк и столбцов может быть произвольным.
Каждое поле содержит одну характеристику объекта предметной области. В записи собраны сведения об одном экземпляре этого объекта.
Ключи
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Ключ, состоящий из нескольких полей называется составным ключом . В СУБД Access в качестве ключа может быть использован Счетчик, который автоматически возрастает на единицу при вводе в таблицу новой записи. Такой ключ называют искусственным. Он семантически не связан ни с одним полем таблицы. Из-за этого он допускает повторный ввод одних и тех же записей. Но с помощью него просто устанавливать связь между таблицами. Основное свойство ключа – уникальность, неповторимость.
Типы связей между таблицами
Структура базы данных определяется структурой таблиц и связями между ними.
Связи между таблицами бывают трех типов:
«один-к-одному» (1:1) – одной записи в главной таблице соответствует одна запись в подчиненной таблице,
«один-ко-многим» (1:М) – одной записи в главной таблице соответствует несколько записей в подчиненной таблице,
«многие-ко-многим» (М:М) – нескольким записям в главной таблице соответствуют несколько записей в подчиненной таблице. Или одной записи в первой таблице может соответствовать несколько записей во второй таблице. И одной записи во второй таблице могут соответствовать несколько записей в первой таблице.
Создание связей между таблицами
Связь между таблицами устанавливается с помощью ключей. Главной называют таблицу, первичный ключ которой используется для установления связи с другой таблицей, которая в этом случае называется подчиненной.
Чтобы связать две реляционные таблицы, необходимо ключ главной таблицы ввести в состав подчиненной таблицы. Название ключа может быть другим, но обязательно одинаковыми с первичным ключом должны быть тип и размер вторичного ключа в подчиненной таблице. Для удобства лучше обозначение вторичного ключа оставлять таким же, как и первичного. Однако если ключом выбран Счетчик , то вторичный ключ должен иметь тип Числовой - длинное целое (но не Счетчик !). Вторичный ключ – это или обычное поле, или часть первичного ключа в подчиненной таблице.
СУБД Access для реализации связи «многие-ко-многим» требует создать таблицу связи и ввести в нее в качестве вторичных ключей первичные ключи двух таблиц, которые должны иметь такую связь (М:М). После этого устанавливается связь 1:М каждой из двух таблиц с таблицей связи. Между двумя таблицами таким образом реализуется связь М:М. Если в БД «Моя библиотека» создать таблицы Книги и Авторы, то связь между ними будет вида М:М, так как одной записи в таблице Книги (реквизиты одной книги) может соответствовать несколько записей в таблице Авторы. Потому что у одной книги может быть несколько авторов. В свою очередь, одной записи в таблице Авторы могут соответствовать несколько записей в таблице Книги, так как один автор может написать несколько книг. Таблицу связи можно назвать КнигиАвторы, в которую будут включены ключи обеих таблиц – Книги и Авторы. Если требуется, в таблицу связи можно включить и другие поля.
Среди реляционных баз данных следует различать корпоративные и настольные базы данных.
Из корпоративных реляционных СУБД наиболее распространенными являются: Oracl, IBM DB2, Sybase, Microsoft SQL Server, Informix. Из постреляционных СУБД известна СУБД Cache компании InterSystems.
Наиболее известны в настоящее время следующие настольные БД: Microsoft Access, Paradox (фирмы Borland), FoxPro (Microsoft), dBase IV (IBM), Clarion.
Эти СУБД занимают более 90% всего рынка СУБД.
В следующем разделе дана краткая характеристика СУБД Microsoft Access.
Появление компьютерной техники в нашей современности ознаменовало информационный переворот во всех сферах человеческой деятельности. Но для того, чтобы вся информация не стала ненужным мусором в глобальной сети Интернет, была изобретена система баз данных, в которой материалы сортируются, систематизируются, в результате чего их легко отыскать и представить последующей обработке. Существуют три основные разновидности - выделяют базы данных реляционные, иерархические, сетевые.
Фундаментальные модели
Возвращаясь к возникновению баз данных, стоит сказать, что этот процесс был достаточно сложным, он берет свое начало вместе с развитием программируемого оборудования обработки информации. Поэтому неудивительно, что количество их моделей на данный момент достигает более 50, но основными из них считаются иерархическая, реляционная и сетевая, которые и до сих пор широко применяются на практике. Что же они собой представляют?
Иерархическая имеет древовидную структуру и составляется из данных разных уровней, между которыми существуют связи. Сетевая модель БД представляет собой более сложный шаблон. Ее структура напоминает иерархическую, а схема расширенная и усовершенствованная. Разница между ними в том, что потомственные данные иерархической модели могут иметь связь только с одним предком, а у сетевой их может быть несколько. Структура реляционной базы данных гораздо сложнее. Поэтому ее следует разобрать более подробно.
Основное понятие реляционной базы данных
Такая модель была разработана в 1970-х годах доктором науки Эдгаром Коддом. Она представляет собой логически структурированную таблицу с полями, описывающую данные, их отношения между собой, операции, произведенные над ними, а главное - правила, которые гарантируют их целостность. Почему модель называется реляционной? В ее основе лежат отношения (от лат. relatio) между данными. Существует множество определений этого типа базы данных. Реляционные таблицы с информацией гораздо проще систематизировать и придать обработке, нежели в сетевой или иерархической модели. Как же это сделать? Достаточно знать особенности, структуру модели и свойства реляционных таблиц.
Процесс моделирования и составления основных элементов
Для того чтобы создать собственную СУБД, следует воспользоваться одним из инструментов моделирования, продумать, с какой информацией вам необходимо работать, спроектировать таблицы и реляционные одно- и множественные связи между данными, заполнить ячейки сущностей и установить первичный, внешние ключи.
Моделирование таблиц и проектирование реляционных баз данных производится посредством бесплатных инструментов, таких как Workbench, PhpMyAdmin, Case Studio, dbForge Studio. После детальной проектировки следует сохранить графически готовую реляционную модель и перевести ее в готовый SQL-код. На этом этапе можно начинать работу с сортировкой данных, их обработку и систематизацию.
Особенности, структура и термины, связанные с реляционной моделью
Каждый источник по-своему описывает ее элементы, поэтому для меньшей путаницы хотелось бы привести небольшую подсказку:
- реляционная табличка = сущность;
- макет = атрибуты = наименование полей = заголовок столбцов сущности;
- экземпляр сущности = кортеж = запись = строка таблички;
- значение атрибута = ячейка сущности= поле.
Для перехода к свойствам реляционной базы данных следует знать, из каких базовых компонентов она состоит и для чего они предназначены.
- Сущность. Таблица реляционной базы данных может быть одна, а может быть целый набор из таблиц, которые характеризируют описанные объекты благодаря хранящимся в них данным. У них фиксированное количество полей и переменное число записей. Таблица реляционной модели баз данных составляется из строк, атрибутов и макета.
- Запись - переменное число строк, отображающих данные, что характеризируют описываемый объект. Нумерация записей производится системой автоматически.
- Атрибуты - данные, демонстрирующие собой описание столбцов сущности.
- Поле. Представляет собой столбец сущности. Их количество - фиксированная величина, устанавливаемая во время создания или изменения таблицы.
Теперь, зная составляющие элементы таблицы, можно переходить к свойствам реляционной модели database:
- Сущности реляционной БД двумерные. Благодаря этому свойству с ними легко проделывать различные логические и математические операции.
- Порядок следования значений атрибутов и записей в реляционной таблице может быть произвольным.
- Столбец в пределах одной реляционной таблицы должен иметь свое индивидуальное название.
- Все данные в столбце сущности имеют фиксированную длину и одинаковый тип.
- Любая запись в сущности считается одним элементом данных.
- Составляющие компоненты строк единственны в своем роде. В реляционной сущности отсутствуют одинаковые строки.
Исходя из свойств понятно, что значения атрибутов должны быть одинакового типа, длины. Рассмотрим особенности значений атрибутов.
Основные характеристики полей реляционных БД
Названия полей должны быть уникальными в рамках одной сущности. Типы атрибутов или полей реляционных баз данных описывают, данные какой категории хранятся в полях сущностей. Поле реляционной базы данных должно иметь фиксированный размер, исчисляемый в символах. Параметры и формат значений атрибутов определяют манеру исправления в них данных. Еще есть такое понятие, как "маска", или "шаблон ввода". Оно предназначено для определения конфигурации ввода данных в значение атрибута. Непременно при записи неправильного в поле должно выдаваться извещение об ошибке. Также на элементы полей накладываются некоторые ограничения - условия проверки точности и безошибочности ввода данных. Существует некоторое обязательное значение атрибута, которое однозначно должно быть заполнено данными. Некоторые строки атрибутов могут быть заполнены NULL-значениями. Разрешается ввод пустых данных в атрибуты полей. Как и извещение об ошибке, есть значения, которые заполняются системой автоматически - это данные по умолчанию. Для ускорения поиска любых данных предназначено индексированное поле.
Схема двумерной реляционной таблицы базы данных
Для детального понимания модели с помощью SQL лучше всего рассмотреть схему на примере. Нам уже известно, что представляет собой реляционная БД. Запись в каждой таблице - это один элемент данных. Чтобы предотвратить избыточность данных, необходимо провести операции нормализации.
Базовые правила нормализации реляционной сущности
1. Значение названия поля для реляционной таблицы должно быть уникальным, единственным в своем роде (первая нормальная форма - 1НФ).
2. Для таблицы, которая уже приведена к 1НФ, наименование любого неидентифицирующего столбца должно быть зависимым от уникального идентификатора таблицы (2НФ).
3. Для всей таблицы, что уже находится в 2НФ, каждое неидентифицирующее поле не может зависеть от элемента другого неопознанного значения (3НФ сущности).
Базы данных: реляционные связи между таблицами
Существует 2 основных реляционных табличек:
- «Один-многие». Возникает при соответствии одной ключевой записи таблицы №1 нескольким экземплярам второй сущности. Значок ключа на одном из концов проведенной линии говорит о том, что сущность находится на стороне «один», второй конец линии зачастую отмечают символом бесконечности.
- Связь «много-много» образуется в случае возникновения между несколькими строками одной сущности явного логичного взаимодействия с рядом записей другой таблицы.
- Если между двумя сущностями возникает конкатенация «один к одному», это значит, что ключевой идентификатор одной таблицы присутствует в другой сущности, тогда следует убрать одну из таблиц, она лишняя. Но иногда исключительно в целях безопасности программисты преднамеренно разделяют две сущности. Поэтому гипотетически связь «один к одному» может существовать.
Существование ключей в реляционной базе данных
Первичный и вторичный ключи определяют потенциальные отношения базы данных. Реляционные связи модели данных могут иметь только один потенциальный ключ, это и будет primary key. Что же он собой представляет? Первичный ключ - это столбец сущности или набор атрибутов, благодаря которому можно получить доступ к данным конкретной строки. Он должен быть уникальным, единственным, а его поля не могут содержать пустых значений. Если первичный ключ состоит всего из одного атрибута, тогда он называется простым, в ином случае будет составляющим.
Кроме первичного ключа, существует и внешний (foreign key). Многие не понимают, какая между ними разница. Разберем их более детально на примере. Итак, существует 2 таблицы: «Деканат» и «Студенты». Сущность «Деканат» содержит поля: «ID студента», «ФИО» и «Группа». Таблица «Студенты» имеет такие значения атрибутов, как «ФИО», «Группа» и «Средний бал». Так как ID студента не может быть одинаковым для нескольких студентов, это поле и будет первичным ключом. «ФИО» и «Группа» из таблицы «Студенты» могут быть одинаковыми для нескольких человек, они ссылаются на ID номер студента из сущности «Деканат», поэтому могут быть использованы в качестве внешнего ключа.
Пример модели реляционной базы данных
Для наглядности приведем простой пример реляционной модели базы данных, состоящей из двух сущностей. Существует таблица с названием «Деканат».
Необходимо провести связи, чтобы получилась полноценная реляционная база данных. Запись "ИН-41", как и "ИН-72", может присутствовать не единожды в табличке "Деканат", также фамилия, имя и отчество студентов в редких случаях могут совпадать, поэтому данные поля никак нельзя сделать первичным ключом. Покажем сущность «Студенты».
Как мы видим, типы полей реляционных баз данных совершенно различаются. Присутствуют как цифровые записи, так и символьные. Поэтому в настройках атрибутов следует указывать значения integer, char, vachar, date и другие. В таблице "Деканат" уникальным значением является только ID студента. Данное поле можно взять за первичный ключ. ФИО, группа и телефон из сущности "Студенты" могут быть взяты как внешний ключ, ссылающийся на ID студента. Связь установлена. Это пример модели со связью «один к одному». Гипотетически одна из таблиц лишняя, их можно легко объединить в одну сущность. Чтобы ID-номера студентов не стали всеобще известными, вполне реально существование двух таблиц.
II. Сетевая модель
III. Реляционная модель
запись поле
иерархических и сетевых моделей внешних ключей
4. Реляционная модель данных
Реляционная БД
* Отношение
* Атрибут столбца (поля) таблицы.
* Тип данных
* Связь ключом.
* Объединение
Основными функциями РСУБД являются:
· Определение данных
· Обработка данных
· Управление данными
Microsoft Access
Окно БД в Access
 |
Режимы работы с объектами
Кнопки для работы с объектами БД расположены на Панели инструментов окна БД:
Открыть – позволяет перейти в режим редактирования таблицы, выполнения запроса, загрузки формы, построения отчета, запуска макроса.
Конструктор – обеспечивает переход к режиму настройки выбранного объекта.
Создать – позволяет приступить к созданию нового объекта выбранного типа.
7. Работа с таблицами
Чтобы создать таблицу, нужно перейти к списку таблиц и нажать кнопку Создать . Появится новое диалоговое окно Новая таблица :
Таблицу в Access можно создать несколькими способами:
· построить новую таблицу «с нуля», воспользовавшись Конструктором ;
· запустить Мастер таблиц – специальную программу, предлагающую создать таблицу в пошаговом режиме на базе типовых решений, имеющихся в Access;
· импортировать таблицу БД из файла какой-либо программы, например, FoxPro или Excel.
Задание имени поля
Имя поля задается в столбце Имя поля . Имя может содержать не более 64 знаков, при этом допустимы любые символы, кроме точки, восклицательного знака и угловых скобок. Повторение имен полей не допускается.
Определение типа данных
Для каждого поля необходимо указать тип данных, содержащихся в нем. Тип данных выбирается из списка, который можно вызвать щелчком мыши в столбце Тип данных . Access оперирует следующими типами данных:
Ø Текстовый – для хранения обычного текста с максимальным количеством символов 255.
Ø Поле MEMO – для хранения больших объемов текста до 65 535 символов.
Ø Числовой – для хранения действительных чисел.
Ø Дата/время – для хранения календарных дат и текущего времени.
Ø Денежный – эти поля содержат денежные суммы.
Ø Счетчик – для определения уникального системного ключа таблицы. Обычно используется для порядковой нумерации записей. При добавлении в таблицу новой записи значение этого поля увеличивается на 1 (единицу). Значения в таких полях не обновляются.
Ø Логический – для хранения данных, принимающих значения: Да или Нет.
Ø Поле объекта OLE – для хранения объектов, созданных в других приложениях.
Описание свойств полей
Как уже отмечалось, характеристики отдельных полей определяются в области свойств поля (вкладка Общие ). Каждое поле имеет определенный набор свойств – в зависимости от типа поля. Некоторые типы полей имеют схожие наборы свойств полей. Ниже перечислены основные свойства полей.
Ø Размер поля – максимальная длина текстового поля (по умолчанию 50 знаков) или тип данных числового поля. Рекомендуется задавать минимально допустимое значение этого свойства, потому что обработка данных меньшего размера выполняется быстрее.
Если тип данных – числовой, допустимы следующие значения свойства Размер поля :
Замечание . В случае преобразования поля в меньшее по размеру, может произойти потеря данных.
Ø Формат поля – формат отображения данных на экране или печати. Как правило, используется формат, заданный по умолчанию.
Ø Число десятичных знаков – задает для числового и денежного типа данных число десятичных знаков после запятой.
Ø Маска ввода – определяет форму, в которой данные вводятся в поле (средство автоматизации ввода данных).
Ø Подпись – обозначение для поля, которое будет использоваться для отображения поля в таблице, форме или отчете. Если это значение не определено, в качестве подписи будет взято имя поля.
Ø Значение по умолчанию – стандартное значение, которое автоматически вводится в поле при формировании новой записи данных.
Ø Условие на значение – задает ограничения на вводимые значения, тем самым позволяет осуществлять контроль над правильностью ввода данных.
Ø Сообщение об ошибке – задает текст сообщения, выводимый на экран в случае нарушения условия на значение.
Ø Обязательное поле – определяет, может ли данное поле содержать значения Null (т.е. оставаться пустым), или нужно обязательно вводить в это поле данные.
Ø Индексированное поле – используется для операций поиска и сортировки записей по значению, хранящемуся в данном поле, а также для автоматического исключения дублирования записей. Поля типа MEMO , Объект OLE и Гиперссылка не могут индексироваться.
Определение ключевого поля
После задания характеристик всех полей следует выбрать, по крайней мере, одно ключевое поле. Как правило, в качестве ключевых полей указываются поля, которые имеют неповторяющиеся данные или создаются поля с типом данных Счетчик . В любом случае, поле ключа не должно содержать повторяющихся данных. Чтобы определить ключ, необходимо выделить нужное поле (или поля) и нажать кнопку Ключевое поле Правка . Слева от маркера появится изображение ключа.
Сохранение таблицы
Перед вводом информации спроектированную таблицу необходимо сохранить: нажать кнопку Сохранить на панели инструментов или соответствующую команду в п. м. Файл и ввести название таблицы, после чего на экране появляется вопрос «Создать ключевое поле сейчас?» (Да или Нет)
Если выбирается ответ «Да », то Access создаст автоматически поле с именем «Код» и типом данных Счетчик , если «Нет », – то таблица будет создана без ключевого поля. В этом случае необходимо открыть созданную таблицу в режиме Конструктора и определить «вручную» ключевое поле.
Ввод данных
Чтобы перевести таблицу в режим ввода информации, нужно перейти в режим Таблицы . Поля заполняются последовательно. Переход от одного поля к другому удобно выполнять клавишей Tab (или комбинацией Shift+Tab – в обратном направлении). Если при проектировании таблицы для некоторых полей были предусмотрены значения по умолчанию, эти значения автоматически появятся в соответствующих полях. Записи в таблице можно перемещать, копировать и удалять теми же способами, что и в электронных таблицах, то есть сначала выделить строки, а потом выполнить необходимую операцию. Столбец можно выделить щелчком мыши по заголовку. Столбцы можно перемещать вправо и влево, пользуясь методом drag and drop (перетащить и бросить).
При необходимости можно вернуться в режим Конструктора . Это дает возможность что-либо подправить в структуре таблицы.
Сортировка данных в таблице
Данные, находящиеся в таблице, можно отсортировать в порядке возрастания или убывания. Для этого нужно поместить курсор мыши в любую ячейку столбца, значения которого будут отсортированы и из п. м. Записи выбрать команду Сортировка или нажать на панели соответствующую кнопку.
8. Создание связей между таблицами БД
Связь между таблицами устанавливается путем определения в одной таблице (подчиненной ) поля, соответствующего ключу другой таблицы (главной ). Установленная связь свяжет записи, содержащие в заданном поле одинаковые значения. Созданные связи позднее Access будет использовать в запросах, формах или отчетах.
Замечания.
Ø Оба связываемых поля должны иметь одинаковый тип данных .
Ø Свойства Размер поля для обоих связываемых полей числового типа должны быть одинаковыми.
Ø Если ключевым полем главной таблицы является поле с типом данных Счетчик , то это поле можно связать с числовым полем подчиненной таблицы. При этом для числового поля связанной таблицы для свойства Размер поля должно быть задано значение Длинное целое .
Целостность данных
Целостность данных – это набор правил, которые поддерживают корректность связей между записями в связанных таблицах и обеспечивают защиту данных от случайных изменений или удалений.
Эти правила включают:
Ø В подчиненной таблице нельзя вводить записи, которые не связаны с записью главной таблицы.
Ø В главной таблице нельзя изменять значение ключевого поля, если в подчиненной таблице существуют записи, которые с ней связаны.
Ø В главной таблице нельзя удалять записи, если в подчиненной таблице существуют связанные с ней записи.
Каскадные операции
Целостность данных в связанных таблицах обеспечивают каскадные операции двух видов:
Ø операции каскадного обновления;
Ø операции каскадного удаления.
Эти операции можно включать и выключать путем установки соответствующих флажков: «Каскадное обновление связанных полей» и «Каскадное удаление связанных полей».
Если установлен флажок «Каскадное обновление связанных полей», то любые изменения в значении ключевого поля в главной таблице, которая стоит на стороне «один» в отношениях 1:М, ведут к автоматическому обновлению соответствующих значений во всех связанных записях.
При установке флажка «Каскадное удаление связанных таблиц» при удалении записи из главной таблицы обеспечивается автоматическое удаление связанных записей в подчиненных таблицах.
Удаление (изменение) связей
Ø Открыть окно Схема данных ;
Ø активизировать левой кнопкой мыши связь, которую необходимо удалить (изменить);
Ø правой кнопкой мыши вызвать контекстно-зависимое меню и выбрать команду Удалить (Изменить ) соответственно.
9. Типы отношений между таблицами
Существует три типа отношений между таблицами:
Один-к-одному (1:1). Значению ключа в каждой записи в главной таблице могут соответствовать значения в связанном поле только в одной записи подчиненной таблицы. В этом случае связь между таблицами может быть установлена только через ключевые поля обеих таблиц.
Один-ко-многим (1:М). Значению ключа в каждой записи в главной таблице могут соответствовать значения в связанном поле (полях) в нескольких записях подчиненной таблицы. Этот тип отношения довольно часто используется в реляционных БД.
Много-ко-многим (М:М). Возникает между двумя таблицами, когда одна запись с первой таблицы А (выходная связь) может быть связана больше чем с одной записью другой таблицы В (принимающая), в свою очередь, одна запись с другой таблицы может быть связана больше чем с одной записью первой таблицы. Эта схема реализуется только при помощи третьей соединительной таблицы, ключ связи которой состоит, как минимум, из двух полей. Эти поля являются полями внешнего ключа в таблицах А и В. Первичный ключ для соединительной таблицы – это обычно комбинация из внешних ключей.
Если между таблицами имеются связи типа М:М, создается дополнительная таблица пересечений, с помощью которой связь М:М будет сведена к двум связям типа 1:М. Accеss не позволяет определить прямую связь М:М между двумя таблицами.
10. Формирование запросов
Запуск запроса
Для запуска запроса на исполнение из окна Конструктора надо на панели инструментов нажать кнопку «Запуск » ! или выполнить команду Запрос/Запуск . Результаты выборки данных по запросу выводятся на экран в режиме таблицы.
Формирование Условий отбора
Список операторов используемых при задании выражений следующий:
Ø операторысравнения:
= (равно)
<> (не равно)
> (больше)
>= (не меньше)
< (меньше)
<= (не больше)
BETWEEN – позволяет задать диапазон значений. Синтаксис: Between «Выражение»And «Выражение» (например: BETWEEN 10 And 20 означает тоже, что и логическое выражение>= 10 AND <= 20).
IN – позволяет задавать используемый для сравнения список значений (операндом является список, заключенный в круглые скобки). Например: IN ("Брест", "Минск", "Гродно") означает тоже самое, что и логическое выражение "Брест" OR "Минск" OR "Гродно".
Ø логические операторы:
АND (например: >=10 AND <=20)
OR (например: <50 OR >100)
NOT (например: Is Not Null – поле, содержащее какое-либо значение).
Ø операторLIKE – проверяет соответствие текстового или Memo поля по заданному шаблону символов.
Таблица символов шаблона
Примеры использования оператора Like :
LIKE "С *" – строки, начинающиеся с символа С;
LIKE "[ A - Z ] #" – любой символ от А до Z и цифра;
LIKE "[! 0 - 9 ABC] * # #" – строки, начинающиеся с любого символа кроме цифры или букв А, В, С и заканчивающиеся на 2 цифры;
Сложные критерии выборки
Часто приходится выбирать записи по условию, которое задается для нескольких полей таблицы или по нескольким условиям для одного поля. В этом случае применяются «И-запросы» (выбор записей только при условии выполнения всех условий) и«ИЛИ-запросы» (выбор записей при выполнении хотя бы одного из условий).
При задании «ИЛИ-запроса » каждое условие выборки должно размещаться на отдельной строке Бланка запроса .
При задании «И-запроса » каждое условие выборки должно размещаться на одной строке, но в разных полях Бланка запроса .
Эти операции могут быть заданы явно с помощью операторовOR иAND соответственно.
Функции Iif() и Format()
Функция IIf(условие; еслиИстина; еслиЛожь) – возвращает один из двух аргументов в зависимости от результата вычисления выражения.
Функция Format(выражение; инструкция форматирования) – возвращает строку, содержащую выражение, отформатированное согласно инструкциям форматирования.
Для выражений даты/времени можно применять следующие символы в инструкции форматирования:
I. Иерархическая модель
II. Сетевая модель
III. Реляционная модель
В реляционной модели информация представляется в виде прямоугольных таблиц. Каждая таблица состоит из строк и столбцов и имеет имя, уникальное внутри БД. В свою очередь, каждая строка (запись ) такой таблицы содержит информацию, относящуюся только к одному конкретному объекту, а каждый столбец (поле ) таблицы имеет уникальное для своей таблицы имя.
Реляционные базы данных (РБД), в отличие от иерархических и сетевых моделей , позволяют организовывать связи между таблицами в любой момент. Для этого в РБД реализован механизм внешних ключей . В каждой таблице БД имеется хотя бы одно поле, служащее ссылкой для другой таблицы. В терминологии РБД такие поля называются полями внешних ключей. С помощью внешних ключей можно связывать любые таблицы БД на любом этапе работы с БД.
4. Реляционная модель данных
Реляционная БД (РБД) – это совокупность простейших двумерных логически взаимосвязанных таблиц-отношений, состоящих из множества полей и записей, отражающих некоторую предметную область.
Реляционная модель данных была предложена Е. Коддом, известным американским специалистом в области баз данных. Основные концепции этой модели были впервые опубликованы в 1970 г. Будучи математиком по образованию, Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение (по-английски – relation, отсюда и название – реляционные базы данных).
Одна из главных идей Кодда заключалась в том, что связь между данными должны устанавливаться в соответствии с их внутренними логическими взаимоотношениями. Второй важный принцип, предложенный Коддом, заключается в том, что в реляционных системах одной командой могут обрабатываться целые файлы данных, в то время как ранее одной командой обрабатывалась только одна запись.
Базовые понятия реляционных баз данных (РБД)
* Отношение – информация об объектах одного типа, например, о клиентах, заказах, сотрудниках. В реляционной БД отношение хранится в виде таблицы.
* Атрибут – определенная часть информации о некотором объекте – например, адрес клиента или зарплата сотрудника. Атрибут обычно хранится в виде столбца (поля) таблицы.
* Тип данных – понятие, которое в реляционной модели полностью эквивалентно соответствующему понятию в алгоритмических языках. Набор поддерживаемых типов данных определяется СУБД и может сильно различаться в разных системах.
* Связь – способ, которым связана информация в одной таблице с информацией в другой таблице. Связи осуществляются с помощью совпадающих полей, которые называются ключом.
* Объединение – процесс объединения таблиц или запросов на основе совпадающих значений определенных атрибутов.
Правила (нормализации) построения реляционной БД
Нормализация представляет собой процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществлять непротиворечивое и корректное редактирование данных. Окончательная цель нормализации сводится к получению такого проекта БД, в котором каждый факт появляется только в одном месте, т.е. исключена избыточность информации.
1. Каждое поле любой таблицы должно быть уникальным.
2. Каждая таблица должна иметь уникальный идентификатор (первичный ключ ), который может состоять из одного или нескольких полей таблицы.
3. Для каждого значения первичного ключа должно быть одно и только одно значение любого из столбцов данных, и это значение должно относиться к объекту таблицы (т.е. в таблице не должно быть данных, которые не относятся к объекту, определяемому первичным ключом, а также информация в таблице должна полностью описывать объект).
4. Должна иметься возможность изменять значения любого поля (не входящего в первичный ключ), и это не должно повлечь за собой изменения другого поля (т.е. не должно быть вычисляемых полей).
5. Системы управления базами данных (СУБД)
Поддержание баз данных в компьютерной среде осуществляют программные средства – системы управления базами данных (database management system), которые представляют собой совокупность программных и языковых средств общего или специализированного назначения, необходимых для создания баз данных на машинных носителях, поддержания их в актуальном состоянии и организации доступа к ним различных пользователей в условиях принятой технологии обработки данных.
СУБД – это управляющие программы, которые обеспечивают все манипуляции с базами данных: создание базы, ее ведение, ее использование многими пользователями и др., т. е. реализуют сложный комплекс функций по централизованному управлению базой данных и обслуживают интересы пользователей.
СУБД можно рассматривать как программную оболочку, которая находится между базой данных и пользователем. Она обеспечивает централизованный контроль защиты и целостности данных, доступ к данным, их обработку, формирование отчетов на основе базы данных и другие операции и процедуры.
Реляционная система управления базами данных (РСУБД)
Набор средств для управления РБД называется реляционной системой управления базами данных , которая может содержать утилиты, приложения, службы, библиотеки, средства создания приложений и другие компоненты. Будучи связанной посредством общих ключевых полей, информация в РБД может объединяться из множества таблиц в единый результирующий набор.
Основными функциями РСУБД являются:
· Определение данных – какая информация будет храниться, задать структуру БД и их тип.
· Обработка данных – можно выбирать любые поля, сортировать и фильтровать данные. Можно объединять данные и подводить итоги.
· Управление данными – корректировать и добавлять данные.
6. Общая характеристика СУБД ACCESS
Microsoft Access – это функционально полная реляционная СУБД, в которой предусмотрены все необходимые средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Различные ее версии входят в состав программного пакета MS Office и работают в среде Windows (3.11/95/98/2000/XP).
Окно БД в Access
После создания нового файла БД или открытия существующего в рабочей области окна Access появляется окно базы данных:
| |
Реляционная модель
Реляционная модель базы данных была предложена в 1969 г. математиком и научным сотрудником фирмы IBM Э.Ф. Коддом (E.F. Codd). Некоторые начальные сведения о реляционных базах данных содержатся в обзорной статье “БД и СУБД ” 2. Поскольку в настоящее время именно реляционные базы данных являются доминирующими, в этой статье (а также в статьях “Описание данных ”, “Обработка данных ” и “Проектирование БД ” 2) подробно рассматриваются наиболее существенные понятия реляционной модели.
Сразу отметим, что теория реляционных баз данных изначально была сформулирована на строгом математическом языке, и именно строгие, формально определенные математические понятия наилучшим образом описывают суть вещей. Вместе с тем в большинстве случаев можно без особого ущерба пожертвовать строгостью терминологии в пользу прозрачности изложения, что мы и будем стараться делать.
Основная идея реляционной модели заключается в следующем. База данных состоит из ряда неупорядоченных таблиц (в простейшем случае - из одной таблицы). Таблицами можно манипулировать посредством непроцедурных (декларативных) операций - запросов , результатами которых также являются таблицы.
Нередко слово “реляционная” (relational ) в термине “реляционная модель” трактуют, основываясь на том, что в реляционной базе данных устанавливаются связи (relate ) между таблицами. Такое объяснение удобно, но оно не является точным. В оригинальной системе терминов Кодда термины связи (relations ), атрибуты (attributes ) и кортежи (tuples ) употреблялись там, где большинство из нас пользуется более привычными терминами таблицы, столбцы (поля) и строки (записи).
При построении инфологической модели предметной области (см. “БД и СУБД ”, “Проектирование БД ” 2) выделяются сущности (объекты), описываются их свойств а (характеристики, атрибуты), существенные для целей моделирования, и устанавливаются связи между сущностями. На этапе перехода от инфологической к даталогической реляционной модели как раз и появляются таблицы. Как правило, каждая сущность представляется одной таблицей. Каждая строка таблицы (одна запись) соответствует одному экземпляру сущности, а каждое поле описывает некоторое свойство (атрибут) .
Например, если нам требуется хранить информацию о людях, включающую фамилию каждого, имя, отчество, ИНН, страну проживания и дату рождения, то сущностью является именно человек, а указанные данные - атрибутами. Сама сущность естественным образом становится названием таблицы.
Таблица “Человек”
Реляционная модель требует, чтобы каждая строка таблицы была уникальной, т.е. чтобы любые две строки различались значением хотя бы одного атрибута.
Традиционная табличная форма удобна, когда требуется представить сами данные. Если же, как в приведенном выше примере, интересует лишь структура - имена полей, то с точки зрения наглядности, удобства использования в схемах и экономии места удобнее изображать ее следующим образом:
Ключи
Ключом таблицы называется поле или группа полей, содержащие уникальные в рамках данной таблицы значения . Ключ однозначно определяет соответствующую строку таблицы. Если ключ состоит из одного поля, его часто называют простым , если из нескольких - составным . В приведенном выше примере ключом является поле ИНН (мы считаем известным тот факт, что ИНН в пределах страны являются уникальными).
Рассмотрим пример таблицы с составным ключом. На сайтах прогнозов погоды нередко представляют информацию следующим образом: для каждой даты указывают прогнозируемую температуру ночью, утром, днем и вечером. Для хранения указанной информации можно использовать таблицу следующего вида:
В этой таблице ни поле Дата, ни Время суток, ни Температура не являются ключами - в каждом из этих полей значения могут повторяться. Зато комбинация полей Дата+Время суток является уникальной и однозначно определяет строку таблицы. Это и есть составной ключ.
Нередко встречается ситуация, в которой выбор ключа не является однозначным. Вернемся к первому примеру. Допустим, в дополнение к фамилии, имени, отчеству, ИНН, дате рождения требуется хранить серию и номер общегражданского паспорта и серию и номер заграничного паспорта. Таблица будет иметь следующий вид.
В этой таблице можно выбрать целых три ключа. Один из них - простой (ИНН), два другие - составные (Серия+Номер общегражданского паспорта и Серия+Номер заграничного паспорта). В такой ситуации разработчик выбирает наиболее удобный с точки зрения организации БД ключ (в общем случае - ключ, на поиск значения которого требуется наименьшее время). Выбранный ключ в этом случае часто называют главным, или первичным , ключом, а другие комбинации столбцов, из которых можно сделать ключ, - возможными , или альтернативными, ключами. Отметим, что хотя бы один возможный ключ в таблице имеется всегда, так как строки не могут повторяться и, следовательно, комбинация всех столбцов гарантированно является возможным ключом.
При изображении таблиц первичные ключи таблиц принято выделять. Например, соответствующие поля часто подчеркивают. А Microsoft Access выделяет ключевые поля полужирным шрифтом.
Еще чаще, чем с неоднозначностью выбора ключа, разработчики сталкиваются с отсутствием ключа среди данных, которые требуется хранить. Подобный факт может быть установлен в процессе анализа предметной области. Например, если требуется хранить простой список людей - имена, фамилии, отчества и даты рождения, то ключа в этом наборе атрибутов нет вовсе - мыслимой является ситуация, когда у двух различных людей указанные данные совпадают полностью. В таком случае приходится искусственно вводить дополнительное поле, например, уникальный номер человека. Такой ключ в литературе иногда называют суррогатным . Нередко суррогатный ключ вводят и из соображений эффективности. Если, например, в таблице имеется длинный составной ключ, то разработчики часто вводят дополнительный короткий числовой суррогатный ключ и именно его делают первичным. Нередко так поступают даже при наличии простого ключа, имеющего “неудобный” (неэффективный для поиска) тип данных, например, строковый. Подобные операции уже не имеют отношения к теории, но сплошь и рядом встречаются на практике.
Внимательный читатель, возможно, обратит внимание на то, что ключ практически всегда можно расширить (если только в него не входят все поля таблицы) за счет включения избыточных полей. Формально такой ключ останется ключом, но с практической точки зрения это лишь игра понятиями. Такие ключи и за возможные-то не считают, поскольку всегда необходимо стремиться к минимизации длины (сложности) ключа.
Нормальные формы, нормализация
Не всякая таблица, которую мы можем нарисовать на бумаге или в Word’е, может быть таблицей реляционной базы данных. И не всякая таблица, которая может использоваться в реляционной базе данных, является правильной с точки зрения требования реляционной модели.
Во-первых, требуется, чтобы все данные в пределах одного столбца имели один и тот же тип (о типах см. “Описание данных ” 2). С этой точки зрения приведенный ниже пример не имеет смысла даже обсуждать:
Во-вторых, требуется, чтобы в таблице был назначен первичный ключ .
Указанные требования являются необходимыми, но недостаточными. В теории реляционных баз данных вводятся понятия так называемых “нормальных форм” - требований к организации данных в таблицах. Нормальные формы нумеруются последовательно, по мере ужесточения требований. В правильно спроектированной БД таблицы находятся как минимум в третьей нормальной форме. Соответственно, мы рассмотрим первые три нормальные формы. Напомним, что мы имеем дело с таблицами, удовлетворяющими двум сформулированным выше основным требованиям.
Первая нормальная форма (1НФ)
Первая нормальная форма предписывает, что все данные, содержащиеся в таблице, должны быть атомарными (неделимыми ). Перечень соответствующих атомарных типов данных определяется СУБД. Требование 1НФ совершенно естественное. Оно означает, что в каждом поле каждой записи должна находиться только одна величина, но не массив и не какая-либо другая структура данных. Приведем осмысленный пример таблицы, которая не находится в 1НФ. Пусть у нас имеются списки оценок учеников по некоторому предмету.
Так как значение поля Оценки не является атомарным, таблица не соответствует требованиям 1НФ.
О возможном способе представления списка оценок написано в методических рекомендациях к статье “Проектирование БД” 2.
Вторая нормальная форма (2НФ)
Говорят, что таблица находится во второй нормальной форме, если она находится в 1НФ и каждый не ключевой столбец полностью зависит от первичного ключа. Другими словами, значение каждого поля должно полностью определяться значением первичного ключа. Важно отметить, что зависимость от первичного ключа понимается именно как зависимость от ключа целиком, а не от отдельной его составляющей (в случае составного ключа). Приведем пример таблицы, которая не находится во 2НФ. Для этого вернемся к примеру прогноза погоды и дополним таблицу еще одним столбцом - временем восхода солнца (это вполне правдоподобный пример, такого рода информация часто приводится на сайтах прогноза погоды).
Как мы помним, данная таблица имеет составной ключ Дата+Время суток. Поле Температура полностью зависит от первичного ключа - с ним проблем нет. А вот поле Восход зависит лишь от поля Дата, Время суток на время восхода естественным образом не влияет.
Здесь уместно задаться вопросом: а в чем практический смысл 2НФ? Какая польза от этих ограничений? Оказывается - большая. Допустим, что в приведенном выше примере разработчик проигнорирует требования 2НФ. Во-первых, скорее всего возникнет так называемая избыточность - хранение лишних данных. Ведь если для одной записи с данной датой уже хранится время восхода, то для всех других записей с данной датой оно должно быть таким же и хранить его, вообще говоря, незачем.
Обратим внимание на слова “должно быть”. А если не будет? Ведь на уровне БД это никак не контролируется - ключ в таблице составной, одинаковые даты могут быть (и по смыслу скорее всего будут). И никакие формальные ограничения (а наше понимание, что “такого не может быть”, к таковым не относится) не запрещают указать разное время восхода для одной и той же даты.
Третья нормальная форма (3НФ)
Говорят, что таблица находится в 3НФ, если она соответствует 2НФ и все не ключевые столбцы взаимно независимы.
Взаимную зависимость столбцов удобно понимать следующим образом: столбцы являются взаимно зависимыми, если нельзя изменить один из них, не изменяя другой.
Приведем пример таблицы, которая не находится в 3НФ. Рассмотрим пример простой записной книжки для хранения домашних телефонов людей, проживающих, возможно, в различных регионах страны.
В этой таблице присутствует зависимость между не ключевыми столбцами Город и Код города, следовательно, таблица не находится в 3НФ.
Отметим, что наличие указанной выше зависимости разработчик определяет, анализируя предметную область, - никакими формальными методами подобную коллизию увидеть нельзя. При изменении свойств предметной области зависимость между столбцами может и исчезнуть. Например, если в пределах одного города вводятся различные коды (как 495 и 499 в Москве), соответствующие столбцы перестают быть связанными с точки зрения нарушения требований 3НФ.
В теории реляционных баз данных рассматриваются и формы высших порядков - нормальная форма Бойса - Кодда, 4НФ, 5НФ и даже выше. Большого практического значения эти формы не имеют, и разработчики, как правило, всегда останавливаются на 3НФ.
Нормализация БД
Нормализация представляет собой процесс приведения таблиц базы данных к выбранной нормальной форме. Нормализация до 2НФ, как правило, сводится к декомпозиции - разбиению одной таблицы на несколько. Нормализация до 3НФ обычно может быть выполнена удалением зависимых (вычисляемых) столбцов. В некоторых случаях при нормализации до 3НФ приходится также производить декомпозицию.
Многотабличные БД, связи между таблицами, внешние ключи
На практике однотабличные базы данных встречаются достаточно редко, поскольку с точки зрения моделирования базой данных предметной области наличие одной таблицы означает наличие одной сущности. В свою очередь, наличие нескольких сущностей обычно означает наличие связей между ними.
Не ставя целью полное проектирование БД, рассмотрим пример, позволяющий продемонстрировать связи в многотабличных БД.
Пусть мы имеем дело со школой, в которой есть ученики, сгруппированные по классам, и учителя, преподающие некоторые предметы. У нас сразу выделяются четыре сущности: ученики, учителя, классы и предметы. Эти сущности уже дают нам четыре таблицы.
Далее нам требуется решить вопрос об атрибутах сущностей - какую именно информацию мы будем хранить. Поскольку наш пример носит исключительно демонстрационный характер, постараемся минимизировать объем хранимой информации. Договоримся для каждого ученика хранить фамилию и имя, для класса - номер параллели и букву, идентифицирующую класс внутри параллели, для учителя - фамилию, имя и отчество, для предмета - только его название.
Теперь нам следует решить вопрос с первичными ключами. Таблицы учеников и учителей в принципе не имеют ключа, поэтому мы введем в них суррогатный числовой ключ - номер. Таблицы классов и предметов, вообще говоря, имеют ключи. В таблице классов ключ составной, его образуют атрибуты Номер параллели+Буква, а в таблице предметов простой ключ состоит из единственного поля - названия предмета. Вспомним, что, говоря о ключах, мы упоминали о том, что суррогатные ключи часто добавляют из соображений эффективности, стремясь избавиться от составных ключей или ключевых полей неудобных типов, например, строковых. Так мы и поступим. Добавим в каждую из таблиц суррогатный числовой ключ.
В результате мы получим следующий набор таблиц, соответствующих описываемым сущностям.
Понимая, с какой предметной областью имеем дело, мы знаем, что наши сущности существуют не сами по себе - они связаны некоторыми отношениями, которые мы обозначили выше. Но как их связать технически? Тут не обойтись без введения дополнительных полей и даже дополнительных таблиц. Разберемся с отношениями между сущностями по порядку.
Чтобы отнести ученика к некоторому классу, заведем в таблице “Ученик” дополнительное поле Номер класса. (Понятно, что его тип должен полностью совпадать с типом поля Номер класса в таблице “Класс”.) Теперь мы можем связать таблицы “Ученик” и “Класс” по совпадающим значениям полей Номер класса (мы не случайно назвали эти поля одинаково, на практике так часто поступают, чтобы легко ориентироваться в связывающих полях). Заметим, что одной записи в таблице “Класс” может соответствовать много записей в таблице “Ученик” (и на практике скорее всего соответствует - трудно представить себе класс из одного ученика). О таких таблицах говорят, что они связаны отношением “один ко многим ”. А поле Номер класса в таблице “Ученик” называют внешним ключом . Как видим, назначение внешних ключей - связывание таблиц. Отметим, что внешний ключ всегда ссылается на первичный ключ связанной таблицы (т.е. внешний ключ находится на стороне “многих”). Связанный с внешним первичный ключ называют родительским , хотя этот термин используется реже.
Проиллюстрируем сказанное схемой в стиле Microsoft Access (подробнее о “Схеме данных” Access написано в статье “Описание данных” 2).
Теперь вспомним об учителях и предметах. Анализируя предметную область (только так - ведь истинное положение вещей из самой формальной модели извлечь невозможно), мы замечаем, что тип связи между сущностями “учитель” и “предмет” иной, нежели рассмотренный выше. Ведь не только один предмет могут вести много учителей, но и один учитель может вести много предметов. Таким образом, между этими сущностями имеется связь “многие ко многим ”. Тут уже не обойтись введением дополнительных полей (попробуйте!). Связи “многие ко многим” всегда разрешаются посредством введения дополнительной таблицы. А именно, организуем таблицу “Учитель-Предмет”, имеющую следующую структуру:
Таблица “Учитель-Предмет”
Эта таблица имеет составной ключ, образованный из двух ее полей. И таблица “Учитель”, и таблица “Предмет” связаны с данной таблицей отношением “один ко многим” (разумеется, в обоих случаях “многие” находятся на стороне “Учитель-Предмет”). Соответственно, в таблице “Учитель-Предмет” имеются два внешних ключа (оба - части составного первичного ключа, что не воспрещается), служащие для связи с соответствующими таблицами.
На практике, помимо рассмотренных отношений “один ко многим” и “многие ко многим”, встречается и отношение “один к одному ”. С точки зрения теории такое отношение интереса не представляет, так как две таблицы, связанные отношением “один к одному”, всегда можно просто объединить в одну. Тем не менее в реальных базах данных отношение “один к одному” применяется для оптимизации обработки данных. Проиллюстрируем сказанное примером.
Допустим, мы храним очень много разнообразной информации о людях - данные их всевозможных документов, телефоны, адреса и пр. Скорее всего боRльшая часть этих данных будет использоваться очень редко. А часто нам потребуются лишь фамилия, имя, отчество и телефон. Тогда имеет смысл организовать две таблицы и связать их отношением “один к одному”. В одной (небольшой) таблице хранить часто используемую информацию, в другой - остальную. Естественно, что таблицы, связанные отношением “один к одному”, имеют один и тот же первичный ключ.
Правила целостности
Реляционная модель определяет два общих правила целостности базы данных: целостность объектов и ссылочная целостность.
Правило целостности объектов очень простое. Оно требует, чтобы первичные ключи таблиц не содержали неопределенных (пустых) значений .
Правило ссылочной целостности требует, чтобы внешние ключи не содержали несогласованных с родительскими ключами значений . Возвращаясь к рассмотренному выше примеру, мы должны потребовать, например, чтобы ученики относились лишь к классу, номер которого указан в таблице “Классы”.
Большинство СУБД умеют следить за целостностью данных (разумеется, это требует соответствующих усилий и от разработчика на этапе описания структур данных). В частности, для поддержания ссылочной целостности используются механизмы каскадирования операций. Каскадирование подразумевает, в частности, то, что при удалении записи из “родительской” таблицы, связанной с другой таблицей отношением “один ко многим”, из таблицы “многих” автоматически (самой СУБД, без участия пользователя) удаляются все связанные записи. И это естественно, ведь такие записи “повисают в воздухе”, они более ни с чем не связаны.
Индексация
Индексация - крайне важная с точки зрения практического применения, но факультативная с позиции чистой теории вещь. Основное назначение индексации - оптимизация (убыстрение) поиска (и, соответственно, некоторых других операций с базой данных). Индексация в любом случае требует дополнительных ресурсов (на физическом уровне чаще всего создаются специальные индексные файлы). Операции, связанные с модификацией данных, индексация может даже замедлять, поэтому индексируют обычно редко изменяемые таблицы, в которых часто производится поиск.
Индексный файл очень похож на индекс обычной книги. Для каждого значения индекса хранится список строк таблицы, в которых содержится данное значение. Соответственно, для поиска не надо просматривать всю таблицу - достаточно заглянуть в индекс. Зато при модификации записей может потребоваться перестроить индекс. И на это уходит дополнительное время.
Разумеется, и речи не идет о том, чтобы излагать теорию реляционных баз данных в рамках базового курса информатики! Тем не менее эта статья очень важна для нашей энциклопедии, поскольку в данном случае мы имеем дело с материалом, который не может быть в полном объеме изложен на уроках, но учитель владеть им должен. Почему?
Во-первых, потому что ряд понятий изучаются как раз в рамках базового курса. Это и табличное представление данных, и ключи таблиц. А все мы знаем, что очень трудно грамотно и точно изложить лишь некоторые понятия, не представляя общей картины.
Во-вторых, выполняя с детьми простые запросы к базам данных (соответствующий материал изложен в статье “Обработка данных” 2), необходимо иметь дело с правильными с точки зрения реляционной теории таблицами. Не требуется объяснять ученикам, что эти таблицы правильные, а “вот если бы…, то таблица была бы неправильной”, но недопустимо использовать плохие примеры.
В профильном курсе информатики ситуация может быть принципиально иной. Важнейшая и крайне продуктивная форма работы в профильных классах - проектная. В рамках учебных проектов можно и нужно разрабатывать несложные базы данных, и здесь не обойтись без основ изложенной теории. Необходимо, однако, учитывать следующее:
Моделируемые предметные области должны быть не слишком большими;
Они должны быть очень хорошо знакомы учащимся (в этом смысле изрядно поднадоевший всем проект “Школа” - не худший выбор!);
Наивно ожидать, что, прослушав основы теории, ученики смогут что-то спроектировать сами. Каждый шаг необходимо проходить вместе с ними, подробно аргументируя свои действия.
