27. Case-средства проектирования бд: назначение, базовые функцио-нальные возможности, примеры современных case-средств.

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

Возможности:

1. Использования визуального конструктора БД

2. Интеграцию этапов проектирования и разработки

3. Возможность многократного использования стандартизованных проектных решений (моделей и их компонентов, DDL-скриптов)

4. Сохранение проектной информации в специальном хранилище

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

6. Поддержка стандартов нотаций ER-моделирования

7. Синтаксическая верификация, обеспечивающая

Примеры современных case-средств:

1. Свободное программное обеспечение (free software) - MySQL Workbench Community Edition

2. Некоммерческие версии программ (free software)

3. Ознакомительные версии программ (trial)

4. Коммерческое программное обеспечение – Navicat, Sybase, Erwin

Тема 5. Проектирование баз данных – логическое и физическое моделирование

28. Состав работ, выполняемых на стадии логического проектирования бд.

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

Этапы логического проектирования:

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

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

3. Проверка модели с помощью правил нормализации.

4. Проверка модели в отношении транзакций пользователей.

5. Создание диаграммы сущность-связь.

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

Этап 2:

1. Слияние локальных моделей в единую глобальную модель данных (анализ имен сущностей и связей,PK).

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

3. Проверка возможностей расширения модели в будущем.

4. Создание окончательного варианта диаграммы сущность-связь

29. Состав работ, выполняемых на стадии физического проектирования БД. Физическое проектирование БД (общие положения):

Образно говоря, при логическом проектировании разработчик сосредоточивается на том, что надо сделать, тогда как при физическом проектировании он ищет способ, как это сделать.

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

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

Этапы физического проектирования:

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

Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД.

Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.

Этап 5. Проектирование физического представления базы данных.

Этап 5.1. Анализ транзакций.

Этап 5.2. Выбор файловой структуры.

Этап 5.3. Определение вторичных индексов.

Этап 5.4. Анализ необходимости введения контролируемой избыточности данных.

Этап 5.5. Определение требований к дисковой памяти.

Этап 6. Разработка механизмов защиты

Этап 6.1. Разработка пользовательских представлений (видов).

Этап 6.2. Определение прав доступа.

Этап 7.

Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД

На данном этапе необходимо принять решение о способе реализации таблиц базы данных.

1. Описание на языке SQL стандарта 1992 (SQL2)

2. Реализация с использованием триггеров.

3. Реализация с использованием уникальных индексов.

Механизм создания доменов:

CREATE DOМAIN рrорertу_type AS CHAR(1)

CHECK (VALUE IN('B', 'С', 'О', 'Е', 'F', 'М', 'S'));

CREATE DOМAIN property_rooms AS INTEGER

CHECK (VALUE BETWEEN 1 AND 15);

CREATE DOМAIN property_rent AS DECIМAL(6,2)

CHECK(VALUE BETWEEN 0 AND 9999);

CREATE TABLE property_for_rent( рnо PROPERTY_NUMBER NOT NULL,

street STREET NOT NULL, area AREA, city CITY NOT NULL, pcode POST_СОDЕ, type PROPERTY_ТУРЕ DEFAULT ‘F’, rooms PROPERTY_ROOMS DEFAULT 4, rent PROPERTY_RENT DEFAULT 600, оnо OWNER_NUMBER NOT NULL, sno STAFF_NUMBER, bno BRANCH_NUMBER NOT NULL,PRIМARY КЕY (рnо)

FOREIGN КЕY (sno) REFERENCES staff оn delete SET NULL оn update CASCADE

FOREIGN КЕY (оnо) REFERENCES owner оn delete NO ACTION оn update CASCADE

FOREIGN КЕY (bno) REFERENCES branch оn delete NO ACTION оn update CASCADE);

Три́ггер — это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации данных: добавлением INSERT, удалением DELETE строки в заданной таблице, или изменением UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики.

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

[Пример: CREATE TRIGGER property_before_update BEFORE UPDATE ON property_for_rent FOR ЕАСН ROW WHEN (:NEW.rent / :OLD.rent > 1.1) BEGIN INSERT INTO property_for_rent_audit VALUES (:OLD.pno, :OLD.street, :OLD.area, :OLD.city, :OLD.pcode, :OLD.ono, :OLD.sno, :OLD.bno, :OLD.type, :OLD.rooms, :OLD.rent) END;

В этом примере для таблицы Property_for_Rent создается триггер типа before uрdate (Перед обновлением). Как следует из его названия, предусмотренные этим триггером действия будут выполняться до фиксации в базе данных результатов выполнения транзакций обновления.

Команды между ключевыми словами BEGIN и END будут выполняться при каждом обновлении строки в таблице Property_for_Rent, которое удовлетворяет условию, указанному в предложении WHEN. Этот триггер предполагает существование таблицы с именем Property_for_Rent_Audit, в которую будут помещаться копии обновленных записей, удовлетворяющих условиям отбора.]

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

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

CREATE UNIQUE INDEX property_no_index ON property_for_rent (pno);

Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД

Цель: Реализация бизнес-правил в среде целевой СУБД.

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

Этап 5. Проектирование физического представления базы данных

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

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

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

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

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

Этап 5.1. Анализ транзакций

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

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

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

Атрибуты, используемые хотя бы в одном из предикатов. (В языке SQL предикатами называют условия, задаваемые в предложениях WHERE)

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

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

Этап 5.2. Выбор файловой структуры.

Цель: Определение наиболее эффективного файлового представления для каждой из таблиц базы данных.

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

• последовательные файлы (heap);

• хешированные файлы (hash);

• индексно-последовательные файлы (ISAM);

• двоичные деревья (В+-Тrее).

Этап 5.3. Определение вторичных индексов.

Цель: Определение того, будет ли добавление вторичных индексов способствовать повышению производительности системы.

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

Этап 5.4. Анализ необходимости введения контролируемой избыточности данных

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

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

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

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

Этап 5.5. Определение требований к дисковой памяти

Цель: Определение объема дискового пространства, необходимого для размещения базы данных.

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

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

Этап 6. Разработка механизмов защиты

Цель: Разработка механизмов защиты базы данных в соответствии с требованиями пользователей.

Этап 6.1. Разработка пользовательских представлений (видов).

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

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

Этап 6.2. Определение прав доступа.

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

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

Этап 7. Организация мониторинга и настройка функционирования системы.

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