Клиент Сервер приложений Сервер БД База данных
Запуск
|
|
|
Результаты
выполнения
процедур
Рис. 14. Модель сервера приложений
Сервер приложений предоставляет некоторые общие услуги клиентам. Сервер баз данных обеспечивает выполнение только непосредственных функций СУБД: создания, ведения, хранения, поддержания целостности баз данных и т. д.
Достоинствами модели сервера приложений являются ее гибкость и универсальность. Основной недостаток – высокие затраты ресурсов серверов.
В качестве примеров программ, поддерживающих работу серверов приложений, можно привести BEA WebLogic Server, Inprise Application Server и IBM WebSphere Application Server [ 15 ].
4.4. Управление распределенными данными
При работе с распределенными базами данных необходимо решать две проблемы:
1) сохранения согласованности БД при одновременных изменениях хранимых данных в нескольких узлах системы;
2) обеспечения совместного доступа нескольких пользователей к общей информации.
Для организации распределенной базы данных могут быть использованы две стратегии.
Фрагментация БД
В рамках этой стратегии база данных делится на фрагменты, размещаемые в разных узлах системы. В полностью фрагментированной системе данные не должны дублироваться (на практике реализовать это требование практически невозможно). Сведения о месте расположения и других характеристиках каждого фрагмента хранятся в глобальном словаре данных, который может распределяться между несколькими узлами или содержаться только в одном из них.
Достоинствами фрагментации БД являются экономное использование внешней памяти (уменьшается дублирование информации) и постоянное поддержание базы данных в актуальном состоянии. Недостаток – высокие требования к пропускной способности и надежности каналов связи, по которым практически непрерывно передаются команды и данные.
Репликация (тиражирование) БД
Эта стратегия допускает хранение одинаковых данных в нескольких узлах системы. В идеальной распределенной базе данных такого дублирования информации не должно быть, тем не менее на практике оно используется достаточно часто для обеспечения требований производительности, доступности и безопасности. Репликация является обоснованной, например, если одни и те же данные регулярно используются в различных узлах.
Каждая копия данных обрабатывается (в том числе и изменяется) пользователями автономно, независимо друг от друга. Идентичность копий обеспечивается передачей сделанных изменений между узлами с помощью компонента системы, называемого репликатором [ 15 ]. Передача изменений выполняется асинхронно, поэтому аналогичные данные, хранящиеся в различных узлах, некоторое время могут различаться между собой (это является основным недостатком метода). Другой недостаток – большие затраты внешней памяти для хранения информации.
По сравнению со стратегией фрагментации БД, репликация обеспечивает более высокую скорость обращения пользователей к данным; уменьшение объема информации, передаваемой по сети; меньшую зависимость качества работы системы от используемых каналов связи.
Сведения о месте расположения и других характеристиках каждого объекта распределенной базы данных хранятся в глобальном словаре данных (каталоге). Хранение глобального словаря данных и управление им могут реализовываться различными способами [ 2, 12 ]:
1. Полностью распределенный подход – в каждом узле системы содержится часть глобального каталога, характеризующая только объекты базы данных, хранящиеся в этом узле. Работа системы не зависит от некоторого центра управления, при необходимости доступа из одного узла к данным, размещенным в другом узле, требуется просмотр всех локальных каталогов, пока не будет найдена необходимая информация.
2. Полностью реплицированный подход – полная копия глобального каталога данных хранится в каждом узле системы. При этом ускоряется поиск нужных данных, но при изменении объекта базы данных в одном узле требуется обновление каталогов, хранящихся во всех узлах.
3. Централизованный подход – глобальный каталог данных хранится только в одном узле системы. Обеспечение работы системы требует более простых средств, чем при реализации других подходов, но качество работы системы во многом зависит от надежности функционирования узла, в котором находится каталог. Кроме того, этот подход предъявляет повышенные требования к ресурсам системы.
4. Комбинированный подход – в каждом узле системы содержится локальный каталог, включающий сведения о части базы данных, размещенной в этом узле, в одном из узлов хранится и глобальный каталог данных. Этот подход более эффективен, чем централизованный, но также требует высокой надежности работы узла, в котором хранится глобальный каталог данных.
На практике перечисленные подходы не используются, в основном применяется метод перманентных идентификаторов [ 2, 12 ]. Идея метода заключается в том, что каждый объект базы данных имеет логическое имя (на которое при работе ссылаются пользователи) и системное имя, включающее идентификаторы узла, в котором был создан объект, и узла, в котором в данное время хранится объект. После создания объекта его системное имя заносится в каталоги данных всех других узлов.
В каталоге каждого узла хранятся сведения о каждом объекте, созданном или хранимом в этом узле. Перемещения объекта базы данных между узлами отслеживаются локальным каталогом узла, в котором был создан объект. Если какому-нибудь узлу системы необходим этот объект, он предварительно обращается к узлу, где объект был создан, и определяет по каталогу этого узла новое место хранения объекта.
При совместной работе нескольких пользователей с общей информацией могут применяться монопольный и коллективный методы доступа к распределенным данным.
Монопольный доступ организуется с помощью полных блокировок, реализуемых непосредственно СУБД или прикладными программами. Монопольный доступ к данным обычно применяется при работе с конфиденциальной информацией или при выполнении фундаментальных преобразований БД (например, изменения ее структуры), когда требуется полностью исключить работу с данными других пользователей [ 15 ].
В режиме коллективного доступа к данным полная блокировка не допускается. Применяется механизм временных блокировок, ограничивающих или запрещающих работу пользователя или приложения с объектами базы данных, когда эти объекты используются другими пользователем или приложением. Например, если реплицированные данные изменяются в одном узле системы, в других узлах они блокируются. После фиксации сделанных обновлений в узле, где они были выполнены, другие узлы пытаются изменить свои реплицированные данные и зафиксировать полученные результаты. Данные в исходном узле остаются заблокированными до тех пор, пока обновления не будут зафиксированы во всех узлах. Если в одном или нескольких узлах реализовать обновления данных не удалось, производится отмена (откат) выполненных действий в масштабах всей системы.
Расширением рассмотренной технологии является метод двухфазной фиксации транзакций (понятие транзакции будет рассмотрено в п. 5) [ 15 ].
На первом этапе регистрируются все изменения, происходящие в отдельных узлах системы. При этом временно сохраняется возможность их отмены. Информация о сделанных изменениях пересылается управляющему компоненту системы, контролирующему данный процесс.
На втором этапе, после получения от всех узлов системы подтверждения о правильности и непротиворечивости выполненных операций, управляющий компонент системы передает всем узлам команду окончательно зафиксировать сделанные изменения.
5. Восстановление баз данных
При работе с базой данных ее целостность может быть нарушена по ряду причин:
1) в результате несогласованности или ошибочности действий, выполняемых при обработке данных СУБД, прикладными программами или пользователями;
2) при аварийном завершении работы прикладной программы;
3) в результате потери содержимого оперативной памяти компьютера (мягкий сбой), например, при отключении питания;
4) при выходе из строя физического устройства внешней памяти, на котором хранится база данных (жесткий сбой).
При возникновении любой из перечисленных ситуаций СУБД должна автоматически выполнить процесс возвращения базы данных в исходное согласованное состояние. Этот процесс называется восстановлением базы данных и поддерживается с помощью журнала, в котором СУБД регистрирует все действия (транзакции), выполняемые с данными.
5.1. Транзакции
Транзакцией называется последовательность элементарных операций, выполняемых над базой данных и переводящих базу данных из одного непротиворечивого состояния в другое. Транзакция – это логическая единица работы с базой данных [ 2 ].
Рассмотрим пример транзакции. Предположим, в базе данных хранятся сведения о наличии товаров на складах и в магазинах торговой фирмы. При перемещении некоторого товара со склада в магазин в базе данных необходимо выполнить несколько изменений: а) уменьшить количество единиц товара, хранящегося на складе, на заданную величину; б) соответственно увеличить количество единиц данного товара в магазине. Следовательно, рассматриваемая транзакция представляет собой не отдельную операцию, реализуемую СУБД, а скорее, согласование нескольких таких операций.
При успешном завершении транзакции полученные результаты сохраняются во внешней памяти (фиксация транзакций).
Если во время выполнения транзакции (до ее завершения) произойдет сбой, база данных останется в несогласованном состоянии. Это является следствием того, что в промежуточных точках выполнения транзакции целостность базы данных нарушается (товар со склада уже отправлен, а в магазин он еще не поступил). Для восстановления базы данных (ее возвращения в исходное состояние), действия, уже выполненные такими транзакциями, отменяются (откат транзакций).
Транзакции должны обладать следующими свойствами:
1) атомарности (Atomicity) – транзакция должна выполняться полностью или не выполняться совсем;
2) согласованности (Consistency) – транзакция переводит базу данных из одного согласованного состояния в другое с возможным нарушением согласованности в промежуточных точках транзакции;
3) изолированности (Isolation) – транзакции должны выполняться автономно друг от друга, при этом изменения, вносимые в базу данных некоторой транзакцией, до ее фиксации должны быть скрыты от других транзакций;
4) долговечности (Durability) – после завершения и фиксации транзакции, все изменения, вызванные этой транзакцией в базе данных, сохраняются даже при возникновении сбоев в системе.
Транзакции, удовлетворяющие перечисленным требованиям, называют ACID-транзакциями.
5.2. Журнал транзакций
Как указывалось ранее, все транзакции регистрируются СУБД в журнале транзакций. Этот журнал недоступен пользователям, хранится во внешней памяти (иногда в виде двух копий на разных физических носителях) и содержит информацию обо всех изменениях базы данных, вызванных выполняемыми транзакциями. Сведения, содержащиеся в журнале транзакций, используются для восстановления последнего по времени согласованного состояния базы данных после аппаратных или программных сбоев.
Процесс восстановления базы данных заключается в отмене результатов незавершенных транзакций при сохранении в БД всех изменений, сделанных зафиксированными транзакциями.
Необходимость выполнения индивидуального отката транзакции может возникнуть в случаях возникновения ошибок при обработке данных, взаимной блокировки параллельно выполняемых транзакций или при аварийном завершении работы прикладной программы, не позволившем зафиксировать транзакцию. В этих ситуациях журнал транзакций используется для последовательной отмены действий (начиная с последнего из них), которые выполнялись в рамках транзакции, откат которой производится.
При внезапной потере содержимого оперативной памяти (мягкий сбой) поражаются все выполнявшиеся в это время транзакции, но физического нарушения базы данных не происходит. Согласованное состояние базы данных восстанавливается СУБД после перезагрузки операционной системы по журналам транзакций, хранящимся во внешней памяти. Если транзакция находилась в состоянии выполнения и не была завершена, все действия, выполненные этой транзакцией, отменяются с помощью рассмотренной ранее технологии индивидуального отката транзакций. В ситуации, когда транзакция успешно завершилась, но ее результаты не были физически сохранены в базе данных, СУБД реализует повторное выполнение этой транзакции.
При жестком сбое (произошли нарушения в работе аппаратных средств) некоторая часть базы данных может быть разрушена физически. В этом случае журнал транзакций не позволяет устранить все возникшие дефекты. Предварительно необходимо восстановить базу данных по ее резервной (архивной) копии, созданной в некоторый предшествующий момент времени, и хранящейся на независимом надежном устройстве внешней памяти. Журнал транзакций используется на втором этапе восстановления, когда предпринимается попытка повторной реализации транзакций, выполнявшихся после создания резервной копии базы данных.
5.3. Выполнение транзакций в многопользовательских системах
В процессе одновременной работы нескольких пользователей с одними и теми же объектами базы данных СУБД параллельно выполняет множество транзакций. При этом могут возникнуть следующие проблемы [ 12 ].
1. Проблема потери обновления.
Предположим, в базе данных хранится запись со сведениями о наличии на складе некоторого товара (поля Название товара – Количество, шт.):
| Костюм |
Эта запись считывается двумя пользователями. У каждого из них имеется одинаковая исходная информация, что на складе хранится 50 костюмов.
Первому пользователю необходимо отобразить в базе данных факт поступления на склад ста костюмов. Он изменяет имеющиеся данные и сохраняет обновленную запись в базе данных. Количество костюмов составляет 150 штук.
Второму пользователю требуется учесть информацию о передаче 20 костюмов со склада в магазин. Он изменяет имеющиеся у него данные и также сохраняет запись.
В результате в базе данных будет храниться ошибочная информация о наличии на складе 30 костюмов (в действительности их должно быть 130), так как изменения, внесенные первым пользователем, утрачены.
2. Проблема зависимости от незафиксированных обновлений.
Эта проблема возникает, когда одна транзакция выполнила обновление данных, но не зафиксировала его, а другая транзакция начинает использовать эти данные. При отмене первой транзакции будет получен неправильный результат.
Для иллюстрации указанной ситуации воспользуемся записью базы данных из предыдущего примера.
С помощью первой транзакции в базе данных необходимо учесть факт передачи со склада в магазин ста костюмов. Так как на складе нет такого количества товаров, очевидно, что произошел сбой. Вероятно, ошибка допущена оператором, вводившим информацию. Возможность возникновения подобной ситуации контролируется СУБД, предусматривающей отмену транзакций, приводящих к ошибочным результатам. Тем не менее временно, до завершения транзакции и последующей ее отмены, количество костюмов в исходной записи базы данных изменится и будет равно минус 50.
Выполняемая параллельно вторая транзакция учитывает поступление на склад двухсот костюмов. В итоге общее количество костюмов на складе составит 150 штук.
СУБД завершает первую транзакцию, отменяет ее и восстанавливает исходное состояние базы данных. В результате количество костюмов на складе равно 50. При этом утрачены сведения о поставке новой партии товаров.
3. Проблема несогласованного анализа.
Данная проблема может возникнуть, когда одна транзакция получает доступ к множеству записей, некоторые из которых в это время обновляются другой транзакцией.
Предположим, что в базе данных хранятся записи о наличии товаров на трех складах торгового предприятия (поля Название склада – Количество, шт.):
| Склад 1 | |
| Склад 2 | |
| Склад 3 |
Первая транзакция подсчитывает суммарное количество товаров на всех складах предприятия, последовательно считывая из БД записи с данными. Вторая транзакция предусматривает перемещение 100 штук товара с третьего склада на первый. Очевидно, что эта транзакция не может изменить суммарное количество товаров.
Допустим, что действия в рамках транзакций выполняются в следующем порядке:
1. Первая транзакция читает первую запись. Количество товаров – 50 штук, следовательно, их суммарное количество также пока равно 50.
2. Вторая транзакция читает третью запись. Количество товаров – 200 штук.
3. Первая транзакция читает вторую запись. Количество товаров – 100 штук, сумма равна 150.
4. Вторая транзакция вычитает 100 штук товара из количества, указанного в третьей записи. Обновленное значение количества товаров в третьей записи составляет 100 штук.
5. Первая транзакция читает третью запись. Количество товаров – 100 штук, сумма равна 250.
6. Вторая транзакция читает первую запись и добавляет к хранящемуся в ней количеству товаров (50 штук) 100 поступивших единиц. Обновленное значение количества товаров в первой записи составляет 150 штук.
В результате несогласованного анализа первая транзакция неправильно вычислила суммарное количество товаров. Оно составило 250 штук при фактическом значении 350 штук.
Рассмотренные примеры свидетельствуют о том, что СУБД должна не только восстанавливать согласованное состояние базы данных после сбоев, но и обеспечивать корректную параллельную работу всех пользователей над одними и теми же данными [ 4 ]. Идеальной является такая организация работы, когда действия одного пользователя не видны другим пользователям, а выполняемые одновременно транзакции изолированы друг от друга.
Для решения этой задачи обычно используется механизм блокировки – если объект базы данных (таблица, страница или отдельная запись) используется некоторой транзакцией, доступ к этому объекту со стороны других транзакций запрещается полностью или ограничивается (блокируется). После завершения транзакции все заблокированные ею объекты становятся доступными другим транзакциям для выполнения любых операций.
Возможны два вида блокировок [ 2 ]:
1. Монопольная блокировка (X-блокировка, eXclusive locks).
В этом режиме объект базы данных, заблокированный некоторой транзакцией, может изменяться и удаляться только этой транзакцией, он недоступен для любых действий (включая чтение), выполняемых другими транзакциями.
2. Блокировка с взаимным доступом (S-блокировка, Shared locks).
Эта блокировка позволяет обращаться к объекту базы данных одновременно нескольким транзакциям, но только в режиме чтения (обновление и удаление информации запрещены).
Если транзакция обращается к объекту, к которому применена блокировка, она переходит в состояние ожидания момента снятия блокировки с этого объекта (исключением является ситуация, когда выполняемые транзакции предусматривают только чтение данных). Поэтому использование механизма блокировок приводит к задержке выполнения транзакций, следовательно, замедляет работу с базой данных.
Блокировки могут привести к возникновению тупиковых ситуаций. Предположим, первая транзакция в монопольном режиме блокирует объект А базы данных. Одновременно вторая транзакция в монопольном режиме блокирует объект В базы данных. Если затем первая транзакция пытается обратиться к объекту В, а вторая к объектуА, обе транзакции переходят в состояние бесконечного ожидания, так как они будут безрезультатно ждать прекращения выполнения другой транзакции и снятия блокировки с нужных им объектов.
Во время работы с базой данных может сложиться ситуация, когда при одновременном выполнении большого количества транзакций возникает множество тупиков. Эта ситуация разрешается непосредственно средствами СУБД. Из общей совокупности выполняемых транзакций выбираются и отменяются полностью или частично транзакции, которыми можно и нужно пожертвовать для устранения тупиков и продолжения работы других транзакций. Выбор транзакции для отката определяется многофакторным критерием, включающим приоритет и время выполнения транзакции, количество блокированных ею объектов.
6. Защита баз данных
Для успешной работы с базами данных, в особенности в многопользовательском режиме, любая СУБД должна включать средства защиты данных от несанкционированного доступа. При этом традиционно используются два подхода обеспечения безопасности данных – избирательный и обязательный [ 2 ].
В рамках избирательного подхода конкретный пользователь имеет разные права (полномочия) для работы с различными объектами базы данных (под объектами базы данных могут подразумеваться база данных полностью, отдельные таблицы, записи или значения данных). Полномочия отдельных пользователей при работе с одним и тем же объектом также могут быть различными. Поэтому избирательный подход достаточно гибок.
При обязательном подходе некоторый классификационный уровень присваивается самому объекту, а каждый пользователь имеет свой фиксированный уровень доступа. При обращении пользователя к объекту контролируется, соответствует ли уровень доступа пользователя классификационному уровню объекта. Обязательный подход применяется к базам данных, которые имеют жесткую или статичную структуру [ 2 ].
В конкретных СУБД могут поддерживаться или один из рассмотренных подходов обеспечения безопасности данных, или оба подхода.
Решения о полномочиях пользователей при доступе к объектам базы данных принимаются при разработке стратегии эксплуатации базы данных и не зависят от СУБД. СУБД только реализует принятые решения на практике. Для этого она должна иметь следующие средства:
1. Правила безопасности, сформулированные в процессе принятия решений о полномочиях пользователей. Эти правила обычно хранятся в словаре базы данных.
2. Механизмы контроля выполняемых действий, использующие имеющиеся правила безопасности.
3. Методы опознания и проверки подлинности пользователя.
Для опознания пользователя при его входе в систему СУБД обычно просит ввести идентификатор (например, фамилию, должность и т. д.) и пароль, известный только системе или сотрудникам с особыми полномочиями (например, администратору банка данных).
Несколько пользователей могут использовать одни и те же идентификатор и пароль. В результате создаются группы пользователей, обладающих одинаковыми правами доступа к данным. Состав группы может изменяться независимо от установленных для этой группы правил безопасности. Один пользователь может одновременно входить в несколько групп.
Рассмотренные проблемы предполагают, что нелегальный пользователь пытается войти в базу данных, используя средства СУБД. Тем не менее возможна ситуация, когда несанкционированные действия реализуются в обход СУБД с помощью копирования фрагмента базы данных или подключения к коммуникационному каналу.
Наиболее надежным способом защиты от таких действий является шифрование данных. Исходные данные шифруются с помощью специального алгоритма шифрования с применением некоторого ключа шифрования. Процедура дешифрирования информации при известном ключе шифрования выполняется достаточно просто. Алгоритм шифрования может быть широко доступен, ключ шифрования обязательно хранится в секрете.
Рассмотренные методы защиты базы данных не решают проблем использования в неправомерных целях похищенных пользовательских паролей и идентификаторов, злоумышленных действий администраторов банков данных или других пользователей, обладающих большими полномочиями. Проблема обеспечения безопасности баз данных является комплексной и должна включать не только программные, но и физические, аппаратные, организационные методы защиты.
В MS Access пароль доступа к базе данных можно создать (только в монопольном режиме работы) с помощью команд Сервис/Защита/Задать пароль базы данных. Для открытия защищенной паролем базы данных пользователь должен будет вводить этот пароль.
В MS Access можно установить многоуровневую защиту данных, определив права доступа к ним (разрешения) для каждого пользователя. Эти действия выполняются только при открытой базе данных. По умолчанию каждый пользователь имеет статус системного администратора без назначенного пароля, следовательно, обладает полными разрешениями на все объекты и данные.
При установке защиты данных для каждого пользователя после выполнения команд Сервис/Защита/Пользователи и группы создается учетная запись, при необходимости – пароль. После установки защиты пользователь может запустить MS Access только в том случае, если укажет свое имя (и пароль).
Пользователей, имеющих аналогичные разрешения, можно объединить в группу. Этим исключается необходимость определения разрешений для каждого пользователя в отдельности.
С помощью команд Сервис/Защита/Разрешения можно установить различные разрешения для каждого объекта базы данных (таблицы, запроса и т. д.). Этим определяется, какие операции может выполнять отдельный пользователь или некоторая группа пользователей над указанным объектом.
База данных MS Access может быть защищена от несанкционированного доступа с помощью шифрования. Для этого предварительно следует выполнить команды Сервис/Защита/Шифровать/дешифровать, затем выбрать базу данных для шифрования. После шифрования база данных будет недоступна для чтения другим приложениям.
7. Основы проектирования реляционных баз данных
7.1. Этапы проектирования
Проектированию баз данных традиционно уделяется большое внимание, так как эта работа во многом определяет успешность эксплуатации созданной базы данных, возможности ее модернизации и усовершенствования в дальнейшем.
В процессе проектирования баз данных часто выделяют три этапа.
Этап 1. Построение концептуальной модели предметной области.
В рамках этого этапа исследуется предметная область – часть реального мира, для которого создается база данных. Изучаются информационные потребности пользователей, выявляются информационные объекты и связи между ними. Исходя из полученной информации строится концептуальная модель предметной области, независимая от модели данных и программных средств (включая СУБД).
Этап 2. Логическое проектирование – преобразование созданной концептуальной модели в концептуальную схему, реализуемую конкретной СУБД.
На этом этапе на основе концептуальной модели разрабатывается структура базы данных, соответствующая выбранной для ее создания СУБД. Для реляционной базы данных информация разбивается на отношения (таблицы); для каждого отношения (таблицы) определяются атрибуты (поля), первичные ключи; отношения приводятся к нормализованному виду; идентифицируются связи между отношениями.
Этап 3. Физическое проектирование базы данных.
На этом этапе решаются проблемы физического размещения базы данных во внешней памяти и организации доступа к ней. Физическое проектирование базы данных реализуется администратором банка данных при конфигурировании и настройке системы. От специалистов, принимавших участие в проектировании базы данных на предыдущих этапах, этот процесс может быть полностью скрыт. Учитывая, что процесс физического проектирования базы данных является узко специализированным, в дальнейшем он рассматриваться не будет.
7.2. Построение концептуальной модели предметной области
В рамках концептуальной модели информационное содержание предметной области выражается некоторыми абстрактными средствами. Основным требованием, предъявляемым к концептуальной модели, является требование адекватного отображения предметной области. Модель должна быть непротиворечивой, отражать взгляды и потребности всех пользователей системы. Модель должна обладать свойством легкой расширяемости, обеспечивающим ввод новой информации.
Рассмотрим некоторые средства концептуального моделирования.
ER-модель
ER-модель (Entity-Relationship – сущность-связь) была предложена П. Ченом в 1976 г. [ 12 ]. Информация о содержании предметной области в рамках модели изображается в структурированном графическом виде (ER-диаграмма).
Основными конструкциями модели являются сущности и связи.
Для ER-модели не существует единой стандартизованной системы обозначений, поэтому приводимые далее характеристики ER-диаграмм могут несколько отличаться от опубликованных в различных книгах [ 3, 4 ].
Под сущностью в ER-модели понимаются объект или явление, информация о которых будет храниться в базе данных (склад, накладная и т. д.). При этом различают тип сущности и экземпляр сущности. Под типом сущности понимают набор однородных объектов, отображаемый как единое целое (магазин, товар и т. д.). Под экземпляром сущности подразумевается конкретный объект (магазины «Светлый», «Восток» и т. д.). На ER-диаграмме сущность изображается прямоугольником, в котором указано его имя (как правило, существительное).
Сущности имеют свойства, называемые атрибутами. Атрибуты должны позволять различать экземпляры сущности. Например, для сущности Магазинатрибутами являются его название, адрес, специализация, площадь торговых залов и т. д. На ER-диаграмме атрибуты изображаются овалами, в которых указаны их имена, соединенными с сущностями прямыми линиями.
Атрибуты, однозначно идентифицирующие сущность, называются ключевыми атрибутами. Например, для сущности Накладная ключевым атрибутом будет ее номер. Ключевые атрибуты на ER-диаграмме выделяются подчеркиванием. В некоторых ситуациях из нескольких простых атрибутов может формироваться составной ключ (для сущности Поставки товаров это могут быть атрибуты Артикул товара и Дата поставки).
С помощью связей на ER-диаграмме отображается взаимодействие между сущностями. Связь изображается ромбом, соединяющим связываемые сущности, внутри которого указывается вид связи (обычно выражается глаголом). Например, сущности Директор и Сотрудникмогут быть соединены связью Руководит. Между двумя сущностями может быть установлено несколько связей: Продавец– Продает – Товар, Продавец – Фасует – Товар, Продавец – Учитывает – Товар. Количество сущностей, участвующих в связи, определяет ее степень. Связь Руководит между сущностями Директор и Сотрудникимеет степень, равную двум.
Связи могут иметь разный характер:
· «один к одному» (1 : 1) – один экземпляр сущности Директорсвязан с одним экземпляром сущности Магазин;
· «один ко многим» (1 : М) – один экземпляр сущности Директорсвязан со многими экземплярами сущности Продавец;
· «многие ко многим» (М : М) – многие экземпляры сущности Продавецсвязаны со многими экземплярами сущности Товар.
Символы, указывающие на характер связи (1 или М), отображаются на ER-диаграммах рядом со связанными сущностями.
Связь любого из перечисленных видов может иметь обязательный и необязательный классы принадлежности. Класс принадлежности связи для некоторой сущности является обязательным, если в данной связи должен участвовать каждый экземпляр сущности (все продавцы продают товары), и необязательным, если некоторые экземпляры сущности не участвуют в связи (не все товары доставлены железнодорожным транспортом). При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. На ER-диаграммах обязательный класс принадлежности может быть обозначен перпендикулярной линией, перечеркивающей линию связи вблизи сущности, необязательный класс принадлежности – пустым кружком на линии связи [ 4 ].
При построении ER-диаграмм могут использоваться генерализация, агрегация и группировка сущностей [ 3, 12 ].
На рис. 15 представлен фрагмент ER-диаграммы, отображающей работу магазина.
Сущность Работникимеет два подтипа – Директор и Продавец. Между сущностями Магазин и Работник связь имеет характер «один ко многим» (один магазин обслуживается многими работниками), между сущностями Директор и Продавец– «один ко многим» (один директор руководит многими продавцами), между сущностями Продавец и Товар – «многие ко многим» (несколько продавцов продает множество разных товаров). Класс принадлежности большинства связей является обязательным. Он является необязательным для связи Фасует между сущностями Продавеци Товар со стороны сущности Продавец(не каждый продавец фасует товары) (см. рис. 15).
Функциональная модель данных
Эта модель была предложена Шипмэном в 1981 г. [ 12 ].
Модель основывается на положении о возможности представления связей между данными, хранящимися в базе данных, в виде математических функций. Поэтому в функциональной модели данных используются два основных понятия: сущность и функция.
Рис. 15. Фрагмент ER-диаграммы, отображающей работу магазина
Сущность может представлять собой объект реального мира (абстрактная сущность) или являться текстовой строкой или числом (простая сущность). Применение математических функций к конкретным сущностям при заданных значениях аргументов дает однозначный результат.
Диаграммы функциональной модели данных во многом аналогичны ER-диаграммам, но связи между ними представлены в виде функций [ 12 ].
Модель семантических объектов
Модель впервые предложена Кренке в 1988 г. [ 12 ].
База данных является совокупностью семантических объектов. Каждый объект отображает некоторый элемент реального мира и характеризуется набором атрибутов. Связи между объектами представляются атрибутами этих объектов.
Рассмотрим диаграммы семантических объектов Магазин, Продавец, Товар (рис. 16):
| |||||
| |||||
Рис. 16. Диаграммы семантических объектов
Рядом с одним из атрибутов каждого семантического объекта приводится указатель ID, означающий, что данный атрибут используется в качестве идентификатора объекта. Для обозначения уникальности значений идентифицирующего атрибута указатель подчеркивается (для семантических объектов требование уникальности идентификатора не является обязательным).
Для каждого атрибута указана его кардинальность (минимальное и максимальное количество вхождений этого атрибута в объект). Например, если для атрибута Ценаобъекта Товар приводится кардинальность 1, 1, это означает, что товар обязательно должен иметь цену, и только одну. Атрибут Производитель объекта Товар имеет кардинальность 1, N. Это указывает на то, что один и тот же товар может изготавливаться одним или несколькими производителями (см. рис. 16). Атрибут Склад объекта Магазин имеет кардинальность 0, N. Следовательно, склад при магазине может отсутствовать, или их имеется несколько. Атрибуты, которые принимают более одного значения, называются многозначными.
В объекте Магазин имеется группированный атрибут Адрес. Атрибуты, входящие в его состав, объединены скобкой (см. рис. 16).
В объекте Магазинсуществует также атрибут объектного типа Продавец с кардинальностью 1, N(см. рис. 16). Это указывает на то, что данный объект связан с одним или несколькими объектами Продавец(в магазине могут работать один или несколько продавцов). Для обеспечения связи между рассматриваемыми объектами в объект Продавец обязательно должен входить атрибут Магазин, характеризующий этот объект (см. рис. 16).
Диаграммы семантических объектов допускают создание агрегированных объектов, подклассов объектов [ 12 ].
7.3. Логическое проектирование базы данных
При проектировании логической структуры реляционной базы данных определяется оптимальный состав таблиц для хранения исходной информации. Для каждой таблицы указывается ее название, перечень полей и первичный ключ. Идентифицируются связи между таблицами. В рамках логического проектирования БД могут формулироваться ограничения целостности, приниматься решения о создании индексов и т. д.
Наиболее часто для решения перечисленных задач используется переход к логической модели базы данных от концептуальной модели, представленной в виде ER-диаграммы [ 3, 4 ]. Существуют методы однозначного преобразования ER-модели в логическую модель реляционной базы данных. Эти методы положены в основу работы многих CASE-систем – инструментальных средств автоматизированного проектирования баз данных (см. п. 7.5).
Рассмотрим основные правила преобразования ER-модели в логическую модель базы данных на примере диаграммы, построенной на рис. 15 (для иллюстрации некоторых правил будут привлекаться дополнительные сущности и связи между ними). Для наглядности полученных результатов заполним таблицы данными.
Для сущности, имеющей только простые атрибуты (например, Магазин), может быть созданы одна таблица. Каждый атрибут сущности становится полем таблицы, ключевые атрибуты сущности – первичным ключом таблицы. Для каждого поля определяется допустимый тип данных и другие ограничения целостности. Названия сущности и таблицы, атрибутов и полей могут совпадать, если используемая СУБД не накладывает на них никаких ограничений (табл. 7.1):
Таблица 7.1
Магазины
| Название | Адрес | Специализация |
| Светлый | Мира, 14 | Хозяйственные товары |
| Восток | Запарина, 2 | Продовольственные товары |
| Факел | Фрунзе, 13 | Хозяйственные товары |
Если между двумя сущностями имеется связь «один к одному», а класс принадлежности связи для обеих сущностей является обязательным, обе сущности можно объединить в одну таблицу. Первичным ключом таблицы может быть первичный ключ любой сущности. Например, имеются связанные сущности Директор и Магазин. В каждом магазине есть директор, и каждый директор руководит только одним магазином. Таблица, включающая атрибуты сущностей Директор и Магазин, может выглядеть следующим образом (табл. 7.2):
Таблица 7.2
Магазины
| Название | Адрес | Специализация | Директор | ИНН |
| Светлый | Мира, 14 | Хозяйственные товары | Деев О.И. | |
| Восток | Запарина, 2 | Промышленные товары | Стогов П.И. | |
| Факел | Фрунзе, 13 | Хозяйственные товары | Репина О.Г. |
Когда между сущностями имеется связь «один к одному», а класс принадлежности связи для одной сущности является обязательным, а для другой необязательным, для каждой сущности формируется отдельная таблица. К таблице, сущность которой имеет обязательный класс принадлежности, добавляется в качестве поля ключ таблицы с необязательным классом принадлежности.
Рассмотрим связь между сущностями Магазин и Автомобиль. Предположим, лишь некоторым магазинам («Светлый», «Восток») принадлежит автомобиль (только один). У других магазинов («Факел») автомобиля нет (класс принадлежности связи для сущности Магазин является необязательным). Каждый автомобиль является собственностью некоторого магазина (класс принадлежности связи для сущности Автомобиль является обязательным). Таблица с информацией о магазинах будет идентична табл. 7.1, а таблица с информацией об автомобилях будет иметь следующий вид (табл. 7.3):
Таблица 7.3
Автомобили
| Номер | Марка | Водитель | Адрес магазина |
| Х 123 МН | ЗИЛ-130 | Андреев Р.С. | Мира, 14 |
| Х 234 РТ | ГАЗ-66 | Реутов С.П. | Запарина, 2 |
При связи между сущностями «один ко многим» в процессе формирования таблиц решающую роль играет класс принадлежности сущности, находящейся со стороны «много». Если он не является обязательным, следует создать три таблицы. Две из них будут соответствовать каждой сущности, ключи сущностей станут первичными ключами этих таблиц. Третья таблица будет связующей, в нее должны входить первичные ключи связываемых таблиц.
В ситуации, когда класс принадлежности сущности, находящейся со стороны «много», обязателен, достаточно создать две таблицы. Ключ таблицы, находящейся со стороны «один», должен быть добавлен в таблицу, находящуюся со стороны «много».
Рассмотрим связь «один ко многим» между сущностями Магазин и Работник (см. рис. 15). Класс принадлежности связи для сущности Работник является обязательным. Таблица с информацией о магазинах будет иметь вид, идентичный табл. 7.1, таблица с информацией о работниках будет включать ключ таблицы Магазин (табл. 7.4):
Таблица 7.4
Работники
| ИНН | ФИО | Должность | Адрес | Адрес магазина |
| Фомин Л.М. | продавец | Боровая, 16 | Мира, 14 | |
| Цыпин Л.Е. | продавец | Мира, 33 | Запарина, 2 | |
| Гейт Ф.П. | грузчик | Осиновая, 5 | Фрунзе, 13 | |
| Ревва С.Р. | кассир | Мира, 67 | Мира, 14 |
Если между двумя сущностями имеется связь «многие ко многим», независимо от класса принадлежности связей этих сущностей, необходимо сформировать три таблицы. Две таблицы соответствуют связываемым сущностям, ключи этих сущностей становятся первичными ключами таблиц. Третья таблица является связующей, в нее должны входить первичные ключи обеих сущностей.
Рассмотрим связь «многие ко многим» между сущностями Продавец и Товар. Таблица Продавцы может иметь структуру, совпадающую со структурой таблицы Работники (см. табл. 7.4), таблица Товары будет иметь вид (табл. 7.5):
Таблица 7.5
Товары
| Артикул | Название | Цена, руб. |
| Туфли | 5 000 | |
| Сапоги | 7 000 | |
| Костюм | 10 000 | |
| Костюм | 8 000 |
Таблица Продажи позволяет связать таблицы Продавец и Товары (табл. 7.6). В результате по данным, хранящимся в трех связанных таблицах, можно получить информацию о том, какие товары продает конкретный продавец.
Таблица 7.6
Продажи
| ИНН | Артикул |
Рассмотренные правила преобразования ER-модели в логическую модель базы данных достаточно просты, наглядны и позволяют получить хорошие результаты. Более подробные сведения о данном процессе приводятся в книге [ 3 ].
7.4. Нормализация отношений
Нормализация отношений* обеспечивает эффективность структур данных в реляционной БД [ 12 ].
Этот процесс уменьшает избыточность данных (хранение одинаковых данных в нескольких местах). В результате более рационально используется внешняя память, уменьшается вероятность нарушения согласованности данных.
Нормализация представляет собой действия по последовательному преобразованию исходной (ненормализованной) таблицы в нормализованные отношения в первой нормальной форме (1НФ), 2НФ, 3НФ, нормальной форме Бойса-Кодда (НФБК), 4НФ, 5НФ [ 2 ].
Основные свойства нормальных форм:
каждая следующая нормальная форма улучшает свойства предыдущей нормальной формы;
при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.
Первая нормальная форма (1НФ)
Рассмотрим таблицу, в которой содержится информация о поставках товаров торговому предприятию (табл. 7.7):
Таблица 7.7
Товары
| Название товара | Артикул | Количество | Цена, руб. | Дата поставки | Поставщик | Способ доставки |
| Костюм | 10 000 | 10.12.05 | Янтарь | а/т | ||
| Сапоги | 5 000 | Факел | ж/д | |||
| Туфли | 4 000 | 11.12.05 | Янтарь | а/т | ||
| Костюм | 10 000 | |||||
| 5 000 | 12.12.05 | |||||
| 4 000 | Остон | ж/д | ||||
| Туфли | Янтарь | а/т |
Такие таблицы нельзя включать в реляционную базу данных, так как для них не соблюдается требование неделимости (атомарности) значений данных, расположенных на пересечении любых строки и столбца (см. п. 1.2).
Приведем исходную таблицу к виду (табл. 7.8):
Таблица 7.8
Товары
| Название товара | Артикул | Количество | Цена, руб. | Дата поставки | Поставщик | Способ доставки |
| Костюм | 10 000 | 10.12.05 | Янтарь | а/т | ||
| Сапоги | 5 000 | 10.12.05 | Факел | ж/д | ||
| Туфли | 4 000 | 11.12.05 | Янтарь | а/т | ||
| Костюм | 10 000 | 11.12.05 | Янтарь | а/т | ||
| Костюм | 5 000 | 12.12.05 | Янтарь | а/т | ||
| Костюм | 4 000 | 12.12.05 | Остон | ж/д | ||
| Туфли | 4 000 | 12.12.05 | Янтарь | а/т |
В результате будет получено отношение в первой нормальной форме.