Основные задачи проектирования баз данных

Основные задачи:

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

Основные этапы проектирования баз данных

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

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

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

Физическое проектирование

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

Нормализация

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

Модели «сущность-связь»

Модель «сущность-связь» (англ. “Entity-Relationship model” ), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма , либо с использованием других графических нотаций (Crow"s Foot , Information Engineering и др.).

Основные преимущества ER-моделей:

• наглядность;
• модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
• ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

• объекты (сущности);
• атрибуты объектов;
• связи между объектами.

Сущность - объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

• типом связи (1:1, 1:N, N:М);
• классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности - обязательный, иначе - необязательный.

Семантические модели

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

Дейт К. Дж. Введение в системы баз данных. - 8-е изд. - М.: «Вильямс», 2006:

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

Наиболее известным представителем класса семантических моделей является модель «сущность-связь» (ER-модель).

Литература

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М .: «Вильямс», 2006. - 1328 с. - ISBN 0-321-19784-4
• Когаловский М.Р. Перспективные технологии информационных систем. - М .: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4
• Когаловский М.Р. Энциклопедия технологий баз данных. - М .: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4
• Кузнецов С. Д. Основы баз данных. - 2-е изд. - М .: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с. - ISBN 978-5-94774-736-2
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. - 3-е изд. - М .: «Вильямс», 2003. - 1436 с. - ISBN 0-201-70857-4
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М .: «Вильямс», 2003. - 1088 с. - ISBN 5-8459-0384-X

См. также

• Методы проектирования

Ссылки

• Модель "сущность-связь" – шаг к единому представлению о данных - Citforum
• Расширение реляционной модели для лучшего отражения семантики - Citforum
• Пособие по проектированию баз данных сайтов "для начинающих"
• Метод проектирования логической структуры реляционной БД без нормализации таблиц

Примечания

Wikimedia Foundation . 2010 .

Смотреть что такое "Проектирование баз данных" в других словарях:

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

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

ПРОЕКТИРОВАНИЕ - одна из форм опережающего отражения действительности, процесс создания прообраза (прототипа) предполагаемого объекта, явления или процесса посредством специфич. методов. П. является конкретной формой проявления прогностич. функции управления,… … Российская социологическая энциклопедия

Запрос «БД» перенаправляется сюда; см. также другие значения. База данных представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов),… … Википедия

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

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

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

1. Определение назначения базы данных.

2. Принятие решения о том, какие исходные данные база данных должна содержать.

3. Определение исходных таблиц базы данных.

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

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

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

7. Создание форм, отчетов и запросов для операций с введенными данными.

Определение назначения базы данных

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

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

Выбор информации, включаемой в базу

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

2. Название книги.

3. Место издания (город).

4. Издательство (название издательства).

5. Год выпуска.

6. Аннотация.

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

1. Номер комнаты (помещения для хранения книг).

2. Номер стеллажа в комнате.

3. Номер полки на стеллаже.

4. Номер (инвентарный номер книги).

5. Дата приобретения.

6. Дата размещения конкретной книги на конкретном месте.

7. Дата изъятия книги с установленного места.

К атрибутам, позволяющим охарактеризовать читателей, можно отнести:

1. Номер читательского билета (формуляра).

2. Фамилия читателя.

3. Имя читателя.

4. Отчество читателя.

5. Адрес читателя.

6. Телефон читателя.

7. Дата выдачи читателю конкретной книги.

8. Срок, на который конкретная книга выдана читателю.

9. Дата возврата книги.

Определение исходных таблиц

Анализ определенных выше объектов и атрибутов позволяет определить для проектируемой базы данных следующие таблицы для построения базы данных:

2. Книги . Таблица предназначена для хранения сведений о книгах.

3. Издательства .Таблица предназначена для хранения сведений об издательствах.

4. Хранилище . Таблица предназначена для описания места хранения книг.

5. Выдача .Таблица предназначена для хранения сведений о выданных книгах.

6. Читатели .Таблица предназначена для хранения сведений о читателях библиотеки.

Выбор необходимых полей таблиц

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

Исходя из вышесказанного, определяем поля в выбранных таблицах и тип хранимых данных.

Книги:

· код книги – числовое поле, предназначено для однозначного определения каждой конкретной книги в базе данных;

· название книги

· аннотация – текстовое поле;

· дата издания ;

· дата поступления в библиотеку ;

· место хранения .
Издательства:

· код издательства – числовое поле, предназначено для однозначного определения каждого конкретного издательства в базе данных;

· название издательства – символьное поле, не более 256 символов;

· город, где расположено издательство – символьное поле, не более 25 символов.

Хранилище:

· код места – числовое поле, предназначено для однозначного определения каждой конкретной полки в базе данных;

· номер комнаты – числовое поле;

· номер стеллажа – числовое поле;

· номер полки – числовое поле.

Выдача:

· код выдачи – числовое поле, предназначено для однозначного определения каждой конкретной выдачи в базе данных;

· номер выданной книги – числовое поле;

· код читателя – числовое поле;

· дата выдачи ;

· срок выдачи (количество дней);

· дата возврата .

Читатели:

· номер читательского билета – числовое поле, предназначено для однозначного определения каждого конкретного читателя в базе данных;

· фамилия

· имя – символьное поле, не более 50 символов;

· отчество – символьное поле, не более 50 символов;

· адрес – символьное поле, не более 256 символов;

· телефон – символьное поле, не более 20 символов.

Выбор уникальных полей

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

Для нашей базы данных первичными ключами являются следующие поля:

· Книги – код книги .

· Издательства – код издательства .

· Хранилище – код места .

· Выдача – код выдачи .

· Читатели – номер билета .

Назначение связей между таблицами

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

· один-к-одному – каждая запись таблицы А не может быть связана более чем с одной записью таблицы Б;

· один-ко-многим – одна запись в таблице А может быть связана со многими записями таблицы Б (например, в каждом классе может быть много учеников);

· многие-ко-многим – каждая запись в таблице А может быть связана со многими записями в таблице Б, а каждая запись в таблице Б – со многими записями в таблице А (например, у каждого учащегося может быть несколько преподавателей, а у каждого преподавателя может быть много учеников).

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

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

В нашей базе данных установим следующие типы связей между таблицами:

1. Авторы – Книги. Здесь связь многие-ко-многим , у любого автора может быть более одной книги, и любая книга может быть написана несколькими авторами. Поэтому вводим вспомогательную таблицу «Авторы–книги» со следующими полями:

· код книги .

2. Книги – Издательства. Здесь связь многие-ко-многим , любая книга может быть издана несколькими издательствами и любое издательство издает не одну книгу. Поэтому вводим еще одну вспомогательную таблицу «Книги–издательства» со следующими полями:

· код книги ;

· код издательства .

3. Хранилище – Книги. Здесь связь один-ко-многим , на одной полке можно расставить множество книг, но любая книга может быть только на одной полке в хранилище. Поэтому поле «Место хранения» в таблице «Книги» определяем как внешний ключ, и связываем таблицы «Хранилище» и «Книги» первичным ключом «Код места» и внешним ключом «Место хранения».

4. Книги – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз в разные даты разным читателям. Поэтому поле «Номер выданной книги» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Книги» и «Выдача» первичным ключом «Код книги» и внешним ключом «Номер выданной книги».

5. Читатели – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз разным читателям в разные сроки. Поэтому поле «Код читателя» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Читатели» и «Выдача» первичным ключом «Номер читательского билета» и внешним ключом «Код читателя».

Нормализация отношений

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

Правило 1: каждое поле таблицы должно представлять уникальный тип информации.

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

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

В спроектированной нами базе данных все таблицы (за исключением вспомогательных «Авторы – книги» и «Издательства – книги») содержат первичный ключ.

Правило 3: для каждого значения первичного ключа значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.

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

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

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

Наполнение базы данных, создание форм и отчетов

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

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

Полученная схема данных разработанной БД в MS Access представлена на рис. 4.1.

Рис. 4.1. Схема данных разработанной БД в Microsoft Access

Контрольные вопросы

1. Дайте определение информационной системы.

2. Поясните понятие базы данных.

3. Что такое предметная область?

4. Дайте определение СУБД.

5. Что такое модель данных?

6. Поясните основные принципы реляционной модели данных.

7. Поясните особенности СУБД Microsoft Access.

8. Каковы основные объекты базы данных Access?

9. Поясните структуру таблицы Access.

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

11. Каковы основные этапы проектирования базы данных?

12. Каким образом осуществляется выбор информации, включаемой в базу данных?

13. Поясните понятия: первичный ключ, внешний ключ.

14. Каково назначение связей между таблицами?

15. Поясните основные типы связей между таблицами.

16. В чем заключается нормализация отношений базы данных?

Этапы проектирования баз данных

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

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

Можно выделить пять основных этапов проектирования БД:

1. Сбор сведений и системный анализ предметной области.

2. Инфологическое проектирование.

3. Выбор СУБД.

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

5. Физическое проектирование.

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

В общем случае выделяют два подхода к выбору состава и структуры предметной области:

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

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

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

Инфологическое проектирование – частично формализованное описание объектов предметной области в терминах некоторой семантической модели.

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

На сегодняшний день наиболее широкое распространение получила модель Чена «Сущность-связь» (Entity Relationship), она стала фактическим стандартом в инфологическом моделировании, и получило название ER – модель.

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

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

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

· Описание концептуальной схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности БД.

· Разработка процедур поддержки семантической целостности БД.

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

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

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

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

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

Лекция

Проектирование БД.

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

1. Модели многоуровневой архитектуры систем баз данных

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

Опубликованный в 1975 году отчет ANSI/X3/SPARC зафиксировал не только широкое признание концепций многоуровневой архитектуры систем баз данных, но и необходимость явного выделения специального концептуального уровня представления базы данных, единого для всех ее приложений и независимого от них. Кроме этого уровня предусматривались еще два уровня: внутренний уровень, который должен обеспечивать поддержку представления хранимой базы данных, и внешний, поддерживающий представления базы данных “с точки зрения” приложений. На каждом архитектурном уровне предполагалось использование той или иной модели данных. Кроме того, на внешнем (прикладном, пользовательском) уровне таких моделей может быть несколько. Модели, а также схемы, специфицируемые на их основе, называются, соответственно, внешней, концептуальной и внутренней.

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

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

7.2. Типология моделей

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

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

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

Однако в большинстве систем, если говорить, например, о базах данных, типы данных являются более статичным элементом, чем способы их обработки. Поэтому получили интенсивное развитие такие методы системного анализа, как диаграммы массивов данных (Data Flow Diagram). Развитие реляционных баз данных в свою очередь стимулировало развитие методик построения моделей данных, и в частности, ER -диаграмм (Entity Relationship Diagram ). Но и функциональная декомпозиция и диаграммы данных дают только некоторый срез исследуемой предметной области, но не позволяют получить представление системы в целом.

Различаются и методы отображения, используемые на этапе построения даталогических моделей, отражающих способ идентификации элементов и связей, но, что особенно важно, в контексте их будущего представления в одномерном пространстве памяти вычислительной машины. Модели подразделяются на фактографические - ориентированные на представление хорошо структурированной информации, и документальные - представляющие наиболее распространенный способ отражения слабоструктурированной информации. Если в первом случае говорят о реляционной, иерархической или сетевой моделях данных, то во втором – о семантических сетях и документальных моделях. Хотя, разделение на фактографические и документальные в этой группе моделей является достаточно условным. Документ, как последовательность полей может быть представлен, в том числе, и реляционной моделью. И в этом случае выбор специализированного решения чаще всего обуславливается требованием общей эффективности.

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

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

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

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

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

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

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

7.3. Этапы проектирования и объекты моделирования

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

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

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

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

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

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

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

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

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

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

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

7.4. Подходы к проектированию базы данных

Можно выделить два основных подхода к проектированию баз данных: нисходящий и восходящий (слайд 7)

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

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

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

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

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

- для многих приложений трудно моделировать предметную область на основе плоских таблиц;

- хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не имеет средств представления (отражения семантики) этих зависимостей;

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

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

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

7.5. Инфологические модели (системный анализ) предметной области

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

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

В общем случае существуют два подхода к определению состава и структуры предметной области.(Слайд 9 Функциональный – объектный подходы)

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

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

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

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

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

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

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

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

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

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

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

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

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

7.7. Физические модели

Стадия физического проектирования базы данных в общем случае включает:

- выбор способа организации базы данных;

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

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

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

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

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

7.8. Средства автоматизации проектирования

Формализованные знания о предметной области в общем случае могут быть представлены в виде текстовых описаний: наборов должностных инструкций, правил ведения дел и т.п. Однако текстовый способ представления модели предметной области не эффективен. Более информативным и полезным при разработке баз данных и информационных систем являются описания предметной области, выполненные при помощи специализированных графических нотаций, реализующих методики представления знаний о предметной области. Наиболее известными на сегодняшний день являются методика структурного анализа SADT (Structured Analysis and Design Technique ) и основанная на ней нотация IDEF 0, диаграммы массивов данных, методика объектно-ориентированного анализа UML (Unified Modeling Language ) и др. Любая из этих моделей описывает, с одной стороны, процессы, происходящие в предметной области, а с другой – данные, используемые этими процессами.

Наиболее полная система моделей, на которую опираются методики функционального, информационного и поведенческого моделирования ПрО, представлена в семействе стандартов IDEF (Integrated DEFinition )(слайд 10).

Методология концептуального проектирования, основанная на наглядной графической технике, предоставила в распоряжение разработчиков информационных систем строгие формализованные методы описания ИС и принимаемых технических решений. Эти модели по существу представляют собой систему соглашений, обеспечивающих взаимопонимание бизнес-аналитика, представляющего реалии предметной области, и программиста (или программного средства), создающего модель данных для отражения состояния этой ПрО. Если соглашения в точности будут реализованы в программных продуктах, основанных на этой методологии, то такая автоматизированная система, умеющая «читать» разработанные аналитиком модели, позволит контролировать синтаксис модели и в итоге сгенерировать схему данных.

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

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

CASE-средства в соответствии с их функциональной ориентацией на те или иные процессы жизненного цикла ИС можно подразделить на следующие группы (слайд 11 – СА SE ).

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

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