Базы данных и СУБД

Информационные системы

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

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

• хранение данных и их защита;

• изменение (обновление, добавление и удаление) хранимых данных;

• поиск и отбор данных по запросам пользователей;

• обработка данных и вывод результатов.

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

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

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

Приложение представляет собой программу или комплекс программ, использующих БД и обеспечивающих автоматизацию обработки информации из некоторой предметной области. Приложения могут создаваться как в среде СУБД, так и вне СУБД — с помощью системы программирования, к примеру, Delphi или C++ Builder, использующей средства доступа к БД.

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

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

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

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

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

Файловые системы

Развитие основных понятий представления данных

Любой вычислительный процесс представляет собой отображение некоторых входных данных в выходные.

Соотношение сложности представления обрабатываемых данных и алгоритма вычислений определяет два класса задач:

- вычислительные задачи – достаточно простое представление данных и сложный процесс вычислений;

- задачи обработки данных (невычислительные задачи) – простой алгоритм обработки данных и сложное представление обрабатываемых данных.

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

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

Недостатки файловых систем

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

2. Проблемы с авторизацией доступа. Можно использовать средства ОС по разграничению доступа. Такое решение возможно, но неудобно. Нужны централизованные методы доступа к информации.

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

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

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

Системы управления базами данных

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

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

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

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

3. Обеспечение независимости прикладных программ и (логической и физической независимости).

4. Защита логической целостности базы данных.

5. Защита физической целостности.

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

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

8. Управление ресурсами среды хранения.

9. Поддержка деятельности системного персонала.

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

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

3. Обеспечение независимости прикладных программ и данных (логической и физической независимости). Важнейшим свойством СУБД является возможность поддерживать два независимых взгляда на базу данных – «взгляд пользователя», воплощаемый в логическом представлении данных, и его отражения в прикладных программах; и «взгляд системы» – физическое представление данных в памяти ЭВМ. Обеспечение логической независимости данных предоставляет возможность изменения (в определенных пределах) логического представления базы данных без необходимости изменения физических структур хранения данных. Таким образом, изменение логического представления данных в прикладных программах не приводит к изменению структур хранения данных. Обеспечение физической независимости данных предоставляет возможность изменять (в определенных пределах) способы организации базы данных в памяти ЭВМ не вызывая необходимости изменения «логического» представления данных. Таким образом, изменение способов организации базы данных не приводит к изменению прикладных программ.

4. Защита логической целостности базы данных.

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

5. Защита физической целостности. При работе ЭВМ возможны сбои в работе (например, из-за отключения электропитания), повреждение машинных носителей данных. При этом могут быть нарушены связи между данными, что приводит к невозможности дальнейшей работы. Развитые СУБД имеют средства восстановления базы данных. Важнейшим используемым понятием является понятие «транзакции». Транзакция – это единица действий, производимых с базой данных. В состав транзакции может входить несколько операторов изменения базы данных, но либо выполняются все эти операторы, либо не выполняется ни один. СУБД, кроме ведения собственно базы данных, ведет также журнал транзакций.

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

Предположим также, что после выполнения первого из действий (уменьшения суммы денег на счете первого клиента) произошел сбой. Например, могла прерваться связь клиентского компьютера с базой данных или на клиентском компьютере мог произойти системный сбой, что привело к перезагрузке операционной системы. Что в этом случае стало с базой данных? Команда на уменьшение денег на счете первого клиента была выполнена, а вторая команда – на увеличение денег на другом счете – нет, что привело бы к противоречивому, неактуальному состоянию базы данных.

Использование механизма транзакций позволяет находить решение в этом и подобных случаях. Перед выполнением первого действия выдается команда начала транзакции. В транзакцию включается операция снятия денег на одном счете и увеличения суммы на другом счете. Оператор завершения транзакций обычно называется COMMIT. Поскольку после выполнения первого действия транзакция не была завершена, изменения не будут внесены в базу данных. Изменения вносятся (фиксируются) только после завершения транзакции. До выдачи данного оператора сохранения данных в базе не произойдет. В нашем примере, поскольку оператор фиксации транзакции не был выдан, база данных «откатится» в первоначальное состояние – иными словами, суммы на счетах клиентов останутся те же, что и были до начала транзакции. Администратор базы данных может отслеживать состояние транзакций и в необходимых случаях вручную «откатывать» транзакции.

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

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

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

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

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

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

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

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

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

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

8. Управление ресурсами среды хранения.

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

9. Поддержка деятельности системного персонала.

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

Классификация СУБД

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

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

К персональным СУБД относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др. К многопользовательским СУБД относятся, например, СУБД Oracle и Informix. Многопользовательские СУБД включают в себя сервер БД и клиентскую часть, работают в неоднородной вычислительной среде — допускаются разные типы ЭВМ и различные операционные системы. Поэтому на базе СУБДМ можно создать информационную систему, функционирующую по технологии клиент-сервер. Универсальность многопользовательских СУБД отражается соответственно на высокой цене и компьютерных ресурсах, требуемых для их поддержки.

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

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

Управляющим компонентом многих СУБД является ядро, выполняющее следующие функции:

- управление данными во внешней памяти;

- управление буферами оперативной памяти (рабочими областями, в которые осуществляется подкачка данных из базы для повышения скорости работы);

- управление транзакциями.

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

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

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

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

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

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

Поддержка функционирования в сети обеспечивается:

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

•средствами механизма транзакций, обеспечивающими целостность БД при функционировании в сети.

Поддержка взаимодействия с Windows-приложениями позволяет СУБДП внедрять в отчет сведения, хранящиеся в файлах, созданных с помощью других приложений, например, в документе Word или в рабочей книге Excel, включая графику и звук. Для этого в СУБДП поддерживаются механизмы, разработанные для среды Windows, такие как: DDE {Dynamic Data Exchange — динамический обмен данными) и OLE {Object Linking and Embedding — связывание и внедрение объектов).

Уровни представления данных

Современные подходы к созданию БД предполагают их трёхуровневую организацию. Этот способ организации БД был предложен American National Standards Institute (ANSI) и используется повсеместно.

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

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

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

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

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

Классификация моделей данных

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

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

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

Рис.1 Модели данных

Инфологическая (семантическая) модель – это обобщённое, не привязанное к какой-либо ЭВМ и СУБД описание предметной области. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств объединяет частные представления о содержимом базы данных, полученные в результате опроса пользователей, и представления разработчиков о данных, которые могут потребоваться в будущих приложениях.

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

Из инфологических моделей далее рассматривается получившая наибольшее распространение модель «сущность-связь», предложенная П.Ченом.

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

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

Даталогические модели

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

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

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

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

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

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

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

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

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

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

Сетевая модель предложена для обеспечения гибкости в управлении данными. На разработку этой модели большое влияние оказал американский ученый Ч.Бахман.

Основные принципы сетевой модели данных были сформулированы в середине 60-х годов. Эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных CODASYL (COnference on DAta SYstem Languages) в середине 70-х годов.

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

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

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

Основные понятия и определения реляционной модели

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

В 1970 году Е.Ф. Кодд (E.F. Codd) представил реляционную модель БД. Концепция этой модели основана на том, что организация данных в базе должна быть гибкой, динамичной, легко используемой. Пользователь должен работать только с логическим представлением данных, а уж система управления БД позаботится о физической структуре данных. Кодд сформулировал основные положения реляционных баз данных.

Реляционная модель использует таблицы и базируется на двух утверждениях:

· база данных должна состоять из таблиц и только из таблиц. Только содержимое таблиц определяет операции БД;

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

В своём документе Кодд описал язык для оперирования с реляционными структурами. Со временем этот язык превратился в то, что сейчас называют структурированным языком запросов SQL (Structured Query Language).

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

В правилах Кодда можно выделить 4 категории:

1) базовые возможности – описание данных и язык программирования;

2) доступ к данным – правила доступа, хранения и поиска,

3) гибкость – правила изменения (модификации) данных;

4) целостность – правила для обеспечения качества и защищённости данных.

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

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

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

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

Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела.

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

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

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.

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

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

Отношение – Таблица (иногда Файл),
Кортеж – Строка (иногда Запись),
Атрибут – Столбец, Поле.

При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и тип поля».

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

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

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

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

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

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

Ключи

Реляционная теория требует, чтобы данные унифицировались уникально по трём критериям:

· таблицей, где хранится этот элемент данных;

· названием поля в этой таблице;

· значением первичного ключа для записи.

Первичный ключ – это поле или группа полей, которые гарантируют уникальность записи.

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

Построение первичного ключа является обязательным. Данные часто имеют естественный ключ (natural key). Например, номер социального страхования идентифицирует любого налогоплательщика США; банки выдают номера счетов своим клиентам; больницы присваивают пациентам номера в картотеке. Всё это – номер социального страхования, счёт в банке, номер в картотеке – лучшие кандидаты на роль первичного ключа, поскольку они уникально идентифицируют налогоплательщиков, клиентов и пациентов соответственно.

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

Если данные не содержат естественного первичного ключа, то он должен быть создан. Существуют две школы, которые предлагают разные способы создания искусственного ключа (artifical key).

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

Вторая школа считает, что ключ не должен иметь ничего общего с данными, так называемый суррогатный ключ (surrogate key).

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

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

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

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

Индексы

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

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

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

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

Рис. 3. Пример индекса по полю «номер телефона».

Связи

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

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

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

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

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

Тип связи много-ко-многим возникает, если связаны поля, частично входящие в первичный ключ одной и другой таблицы. Например, поле «Наименование продукта» в таблице «Заказы» и поле «Наименование продукта» в таблице «Отчисления». Продукт может быть заказан несколькими клиентами, а отчисления по продукту идут разным специалистам за каждую продажу продукта (если таблица «Отчисления» имеет два поля в первичном ключе – название продукта и специалист или название продута и менеджер).

Выше рассмотрены способы связывания таблиц при помощи полей, входящих в первичный ключ. Однако существует другой способ связывания таблиц, в связи с одной стороны могут участвовать поля, не входящие в первичный ключ, а с другой стороны – поля входящие в первичный ключ. Это делается при помощи вторичных или внешних ключей (foreign key). Вторичный ключ строится по полям, не входящим в первичный ключ.

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

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

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

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

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

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

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

* ограничения, для реализации которых созда1тся триггер;

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

Использование триггеров при проектировании БД даёт следующие преимущества:

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

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

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

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