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

Объекты могут быть реальными или абстрактными. Объекты объединяются в классы объектов - совокупность объектов, имеющих одинаковый набор свойств. При этом ER-модель строится не для отдельных экземпляров объектов, а именно для классов объектов. В ER-модели каждому классу присваивается уникальное имя - существительное в единственном числе, дополненное при необходимости прилагательным или предлогом (ПРЕДМЕТ, ПРЕДМЕТ_ИЗУЧАЕМЫЙ). Уникальное имя объекта называется его идентификатором.

Каждый объект обладает набором свойств. В совокупности эти свойства описывают все возможные состояния объекта. Экземпляры объекта различаются как раз тем, что конкретные значения их свойств отличаются (объект СТУДЕНТ, свойства ФИО, Группа).

Если каждый объект может обладать только одним значением данного свойства в каждый момент времени (свойство Дата_Рождения), то такие свойства называются единичными. Если же одновременно у объекта имеется несколько значений свойства (свойство Изучаемый_Предмет у объекта СТУДЕНТ), то такие свойства называются множественными.

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

Есть такие свойства, которые могут одновременно присутствовать не у всех объектов данного класса (например, свойство Ученая_Степень у объекта ПРЕПОДАВАТЕЛЬ). Такие свойства называются условными.

Иногда вводится понятие составного свойства. Например, свойство Адрес может состоять из составных частей Город, Улица, Дом и т.д.

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

Составной объект используется для отображения “целое-часть” (ГРУППА-СТУДЕНТ).

Обобщенный объект используется для отображения связи “род-вид” между разными объектами предметной области. Например, для некоторого предприятия обобщенный объект СОТРУДНИК (родовой объект) составляют объекты ДИРЕКТОР, БУХГАЛТЕР. МЕНЕДЖЕР и т.д., (видовые объекты) которые называются категориями обобщенного объекта). Здесь впервые встречается понятие наследования свойств, поскольку все видовые объекты должны обладать всеми свойствами родового объекта (наследуют его свойства), а также индивидуальными, присущими только данному видовому объекту свойствами.

Агрегированными называются такие объекты, которым соответствует некий процесс. Примером такого объекта может быть объект СЕССИЯ, который объединяет в себе такие объекты, как ДАТА_ЭКЗАМЕНА, ОЦЕНКА, ПРЕДМЕТ, СТУДЕНТ.

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

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

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

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

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

4 случай. Связь 1:М (М:1), класс принадлежности М-связной сущности обязательный. Достаточно сформировать два отношения для каждой из сущностей так же как и в случае 2. После этого ключ 1 - связной сущности добавляется в качестве атрибута в отношение, соответствующее М - связной сущности, в качестве внешнего ключа.

5 случай. Связь 1:М (М:1), класс принадлежности М - связной сущности необязательный. Здесь по тому же принципу, как и в случае 3, необходимо сформировать три отношения.

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

6 случай. Связь М:М. Вне зависимости от классов принадлежности каждой из сущностей формируется три отношения таким же образом как и в случаях 3 и 5.

В настоящее время существует целый ряд автоматизированных средств проектирования ER-моделей, называемых CASE-средствами. Среди них следует отметить Design/IDEF, Power Designer (S-Designor), Oracle, ERWin. Использование этих средств дает ряд преимуществ, к которым относятся: снижаются требования к знанию языков описания данных и конкретных СУБД; автоматически контролируются целостность и согласованность схемы описания БД; сокращается в целом время проектирования; появляется возможность автоматического тестирования проекта на разных стадиях его проектирования.

Подводя итоги, сформулируем основные этапы проектирования БД в рамках инфологического моделирования.

1. Определение сущностей и выявление связей между ними.

2. Построение ER-диаграммы с учетом всех сущностей и связей между ними.

3. Формирование набора предварительных отношений с указанием предполагаемых первичных и внешних ключей.

4. Добавление неключевых атрибутов в отношения.

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

Тема 6. Даталогическое проектирование

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

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

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

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

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

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

1. Наличие синонимов в предметной области. Это означает, что естественное свойство объекта, наиболее подходящее для использования его в качестве первичного ключа, не обладает свойством уникальности. Например, в списке сотрудников может быть по каким-то причинам не предусмотрено наличие таких свойств, как табельный номер или номер паспорта (эти поля, очевидно, были бы уникальными и могли бы использоваться в качестве ключей). Естественный идентификатор сотрудника - ФИО - при наличии полных однофамильцев в этом случае теряет свойство уникальности и не может быть использован в качестве ключа. Единственным выходом из ситуации становится искусственное добавление дополнительного ключевого (например, автоинкрементного) поля.

2. Второй случай рассмотрен выше - значения естественного идентификатора объекта могут меняться со временем.

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

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

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

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

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

Отдельного анализа требует задача создания отношений в случае наличия в ER-модели сложных объектов.

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

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

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

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

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

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

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

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

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

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

2. Одним из проявлений адекватности БД является ее полнота - возможность удовлетворения потребностей различных категорий пользователей не только на данный момент времени, но и в дальнейшем. Под этим понимается также и то, что потребности пользователей могут быть самыми разнообразными и не всегда на стадии проектирования БД можно их все заранее спрогнозировать. Поэтому БД может хранить в себе большое количество детализированных описаний объектов и связей между ними.

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

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

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

Еще одним аспектом является возможность адаптации системы к изменениям в программном обеспечении. Это означает, что программное обеспечение должно быть стандартизированным и широко распространенным.

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

6. Объем необходимой памяти.

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

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

Тема 7. Физические модели БД

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

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

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

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

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

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

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

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

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

1. Выбор хэш-функции. Признаком “хорошей” хэш-функции является возвращение ею не более 10 синонимов.

2. Выбор стратегии разрешений коллизий.

Далеко не всегда удается найти подходящую хэш-функцию. Поэтому в таких случаях предпочтительным является использование индексных файлов. Такие файлы состоят из двух частей - индексной и основной. Физически, как правило, эти части реализуются в отдельных файлах. Индексная часть строится для основной части, в которой размещены непосредственно сами записи. Различаются файлы с плотным индексом (индексно-прямые файлы), файлы с неплотным индексом (индексно-последовательные файлы) и В-деревья. Все типы перечисленных индексных файлов предназначены для поиска записей по значению первичного ключа.

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждая страница имеет вполне определенную структуру, которая включает в себя следующие элементы:

1. Заголовок страницы содержит в себе номер данной страницы, номера предыдущей и следующей страниц, а также информацию о наличии свободного пространства.

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

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

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

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

Тема 8. CASE-технологии

В последнее время широкое распространение получила технология автоматизированного проектирования информационных систем (ИС) и программных продуктов, называемая CASE-технологией (Computer Aided System Engirneering). Понятие CASE включает в себя совокупность регламентно-методических материалов, автоматизированных методов и инструментальных средств разработки, поддерживающих все этапы Жизненного Цикла Системы (ЖЦС, Bysiness System Life Cycle) начиная от первоначального формирования технических требований и спецификаций до получения и сопровождения готового программного продукта. Таким образом, понятие CASE охватывает всевозможные методические и программно-инструментальные средства, объединенные общей целью эффективной поддержки любых процессов создания прикладного программного обеспечения. Использование CASE - технологии при проектировании сложных ИС обеспечивает существенное увеличение производительности труда на всех этапах разработки и значительно сокращает затраты на сопровождение и модификацию по сравнению с проектированием ИС вручную.

Любая CASE-система включает в себя следующие компоненты: метод, нотация и средство. Под методом подразумевается методология проектирования. Нотацией называется выбранное для описания системы средство, которым является программный продукт либо компьютерный инструмент, предназначенный для поддержки и усиления методов проектирования (то есть та среда, в которой работает пользователь).

Основными функциональными компонентами CASE-систем являются следующие:

- централизованное хранилище информации о проекте (БД проекта);

- средства ввода данных в БД;

- средства анализа и редактирования информации в БД;

- средства вывода (средства документирования и верификации).

CASE-средства обеспечивают необходимый для проектирования ИС набор средств. Эти средства включают технологии и стандарты построения диаграмм БД, методы автоматического определения ошибок, а также комплекс технологий для конструирования программных систем.

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

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

Наиболее общими характеристиками CASE-систем являются следующие: поддержка единой БД проекта, поддержка одновременной работы группы разработчиков, поддержка полного ЖЦС, поддержка визуальных методов проектирования, автоматизация кодирования, информационное обеспечение разработчиков, документирование проекта, управление проектом, возможности тестирования и отладки, возможности повторной разработки системы и интеграции различных систем, открытая архитектура.

К сожалению, ни одна из существующих в настоящее время CASE-систем не имеет всех возможностей из этого списка.

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

Методологии классифицируют также по их принадлежности различным этапам ЖЦС. В соответствии с этим они делятся на верхние, средние и нижние.

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

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

Нижние CASE - это средства, поддерживающие системы разработки программного обеспечения. Они используют компоненты генерации программ, создания документации и тестирования.

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

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

В каскадной модели предполагается строгое последовательное выполнение перечисленных этапов. Несмотря на то, что при таком подходе обычно проще осуществлять контроль над процессом проектирования ИС, регулировать затраты и планировать мероприятия, сам процесс создания ИС является итерационным: после выполнения определенного этапа происходит пересмотр принятых решений и возврат к предыдущим этапам проектирования. Это является одним из основных недостатков каскадной модели.

Для того, чтобы максимально согласовать ЖЦС с реальным процессом проектирования ИС, используется модель с промежуточным контролем, в которой допускается возврат к более ранним этапам. Однако в этом случае недостатком становится увеличение длительности процесса проектирования.

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

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

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

Данный метод строится на наглядной диаграммной технике - для описания модели проектируемой системы используются диаграммы, схемы и структурограммы.

Чаще всего в структурном анализе применяются следующие диаграммы:

- диаграммы потоков данных - описание движения информационных потоков между различными подсистемами, накопителями информации, внешними источниками и потребителями информации;

- ER-диаграммы - выявление основных объектов ПО, отношений между ними и их свойств;

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

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

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

На стадии реализации создается и тестируется реальная система.

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

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

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

В результате CASE-средства позволили автоматизировать разработку полного ЖЦС. Такие средства получили название Интегрированный CASE (Integrated CASE). Термин “интегрированный” означает, что различные CASE-средства, поддерживающие ЖЦС, работают согласованно, как если бы они были компонентами одной и той же среды.

Современные CASE-средства реализуют следующие группы функций:

- ведение всех видов проектных описаний для различных этапов разработки в режиме их “ручного” определения (через графические диаграммы и/или экранные формы);

- верификация проектных спецификаций;

- документирование;

- автоматическая генерация некоторых видов проектных описаний;

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

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

- разграничение доступа проектировщиков;

- простой и удобный интерфейс.

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

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

1. Системы Design/IDEF и BPwin используются как средства анализа и предназначены для исследования всевозможных моделей предметной области.

2. Основными средствами проектирования баз данных являются такие технологии, как ERwin, S-Designоr, DataBase Designor.

3. Технологии PRO-IV, Vantage Team Builder применяются для решения задач создания различных проектных спецификаций в качестве средств анализа и проектирования.

4. Технологии Oracle, JAM, Delphi, C++ Duilder, Uniface, Power Builder, SQL являются основными средствами для разработки приложений. Эти средства могут быть предназначены как для решения задач на одном или нескольких этапах ЖЦС (такие как Erwin, S-Designor), так и являться интегрированными, поддерживающими весь ЖЦС (Vantage Team Builder, Oracle).

Среди перечисленных CASE-технологий можно выделить структурные CASE-системы (такие как Vantage Team Builder), основанные на используемых в них методах структурного анализа и программирования, объектно-ориентированные (Object Team) и комбинированные CASE-системы (Oracle).

Тема 9. Целостность БД

банк база данный case технология

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

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

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

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

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

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

- кортежи подчиненного отношения должны уничтожаться при удалении кортежа основного отношения, связанного с ними;

- кортежи основного отношения можно удалять только при отсутствии связанных с ними кортежей подчиненного отношения;

- кортежи подчиненного отношения при удалении кортежа основного отношения, связанного с ними, не удалаются, но модифицируются таким образом, что на месте ключа родительского отношения устанавливается значение NULL.

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

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

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

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

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

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

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

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

Признак определенного значения (обязательность заполнения) не допускает пустого значения атрибута.

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

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

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

4. Ограничения целостности взаимосвязанных отношений - ограничения целостности связи и ограничения по существованию.

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

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

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

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

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

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

6. Запрет на обновления. Этот запрет может относиться к любому объекту - атрибуту, строке или таблице. Так, во многих СУБД этот запрет распространяется на значения первичных ключей.

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

По режиму проверки корректности БД проверка на ограничение целостности может выполняться в момент осуществления операций над данными (оперативный режим) или независимо в заданный момент времени (аудит БД).

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

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

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

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

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

1. Ограничение на уникальность. Ключи таблиц являются уникальными идентификаторами.

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

3. При наличии связи между сущностями могут присутствовать ограничения по связи. Тип связи и класс ее принадлежности определяет ограничение целостности на связь между сущностями.