- •Ю. В. Любицкий
- •Базы данных
- •Содержание
- •Предисловие
- •Введение
- •1. Основные понятия баз данных
- •1.1. Банк данных и его компоненты
- •1.2. Модели данных
- •Пользователи
- •Прикладные
- •СУБД
- •Филиал
- •Магазин
- •Склад
- •Товар
- •Дирекция
- •Подразделение
- •Сотрудники
- •Филиал
- •Дирекция
- •Подразделение
- •Магазин
- •Сотрудники
- •Склад
- •Товар
- •2. Целостность баз данных
- •3. Внутренняя организация СУБД
- •3.1. Общие положения
- •3.2. Линейный список
- •3.3. Инвертированный список
- •3.4. Индексы
- •3.5. Хеширование
- •Область переполнения
- •3.6. Кластеризация
- •4. Распределенная обработка данных
- •4.1. Режимы работы с базой данных
- •4.2. Архитектура «клиент-сервер»
- •4.3. Модели «клиент-сервер»
- •4.4. Управление распределенными данными
- •Параллельный
- •СУБД
- •Приложения
- •СУБД
- •СУБД
- •СУБД
- •5. Восстановление баз данных
- •5.1. Транзакции
- •5.2. Журнал транзакций
- •5.3. Выполнение транзакций в многопользовательских системах
- •6. Защита баз данных
- •7. Основы проектирования реляционных баз данных
- •7.1. Этапы проектирования
- •7.2. Построение концептуальной модели предметной области
- •7.3. Логическое проектирование базы данных
- •7.4. Нормализация отношений
- •7.5. Автоматизированные технологии проектирования баз данных
- •Директор
- •Магазин
- •Название
- •Адрес
- •Работник
- •Продавец
- •Адрес
- •Руководит
- •Товар
- •Артикул
- •Название
- •Цена
- •Фасует
- •Магазин
- •Продавец
- •Товар
- •Заключение
- •Библиографический список
75
ду атрибутами отношений, а отражают более тонкие вопросы смыслового содержания предметной области [ 4 ]. Подробную информацию о нормальных формах высших порядков можно найти в книгах [ 1, 2, 4 – 6, 11, 14 ].
Уровень нормализации отношения определяется смысловым содержанием составляющих его данных. Невозможно по схеме отношения (его структуре) или абстрактно рассматриваемым данным оценить, в какой нормальной форме находится отношение. Для решения этой задачи необходимо идентифицировать первичный и вероятные ключи отношения и выполнить анализ всех зависимостей между данными.
7.5. Автоматизированные технологии проектирования баз данных
Средства автоматизации проектирования и разработки информационных систем, в том числе и банков данных, появились относительно недавно (первая версия CASE-системы фирмы Oracle была представлена в 1989 г.) [ 3 ].
Термин «CASE» (Computer Aided Software Engineering) дословно переводит-
ся как разработка программного обеспечения с помощью компьютера. В CASEсистемы входят программные средства, позволяющие выполнять анализ предметной области и построение ее модели, проектирование баз данных, разработку приложений, генерацию кодов, тестирование и т.д.
CASE-системы, применяемые для проектирования баз данных, могут не зависеть от СУБД или встраиваться в них. Независимые системы не входят в состав конкретной СУБД и обычно поддерживают несколько форматов баз данных через интерфейс ODBC. В качестве примеров таких систем можно привести
S-Designor (PowerDesignor) (фирмы SDP, Powersoft), Erwin (LogicWorks), Silverrun (Computer Systems Advisers Inc.) [ 15 ]. Встроенные CASE-системы в основ-
ном поддерживают формат баз данных СУБД, составной частью которой они являются. Пример встроенной системы – Designer/2000 (СУБД Oracle одноименной фирмы) [ 15 ].
Рассмотрим некоторые CASE-системы.
S-Designor (PowerDesigner). Эта система позволяет с помощью графических средств в некоторой степени автоматизировать процесс проектирования реляционных баз данных. Система работает с СУБД Oracle, MS Access, Ingress, Informix, Sybase, MS SQL Server и т. д.
Предварительно создается концептуальная модель базы данных в виде ERдиаграммы (см. рис. 15). В рамках этого процесса можно задать некоторые огра-
76
ничения целостности для полей таблиц (область допустимых значений, значение по умолчанию и т. д.).
На основе концептуальной модели базы данных строится концептуальная схема (логическая модель) базы данных. Имеющиеся сущности преобразуются в таблицы, идентификаторы сущностей становятся ключами таблиц. При наличии между двумя сущностями связи «многие ко многим», автоматически создается дополнительная таблица, связывающая исходные таблицы (см. пример в п. 7.3).
База данных с помощью системы может быть создана двумя способами. В рамках первого из них необходимо подключиться к работающему серверу СУБД через интерфейс ODBC. Другой способ – формирование текстовых файлов (пакетов) SQL-операторов по созданию структуры БД. База данных создается после обработки этих файлов СУБД [ 15 ].
В версии PowerDesigner 6.0 реализовано проектирование многомерных информационных моделей для хранилищ данных (см. Заключение) [ 3 ].
Erwin. Данная система в целом близка по функциональным возможностям системе S-Designor (PowerDesigner), но она менее универсальна и поддерживается меньшим числом СУБД. В системе имеются ограничения на размеры модели (не более 500 сущностей и 1500 атрибутов) [ 3 ].
Silverrun. Система работает с СУБД Oracle, Informix, Ingress, MS SQL Server
ит. д. С помощью системы можно строить два вида моделей: функциональные (в виде диаграмм потоков данных) и информационные (диаграммы типа «сущность – связь», применяемые для создания схем баз данных).
Система включает встроенную экспертную систему, приводящую неполную
инекорректную исходную информацию к виду, необходимому для построения реляционной базы данных [ 15 ].
Designer/2000. Эта система является встроенной в СУБД Oracle.
Система реализует моделирование и анализ деятельности организации, разработку концептуальных (функциональной и информационной) моделей предметной области, проектирование приложений и создание программ [ 15 ].
Процессы моделирования поддерживаются графическими редакторами и средствами мультимедиа, включая звук, видео и анимацию [ 15 ]. Результатом моделирования базы данных является формирование ее структуры. Определяются набор необходимых таблиц, состав полей каждой таблицы, ключевые поля и индексы, ограничения целостности базы данных.