Пункт 19. Автоматическая генерация базы данных

Пункт 19. Автоматическая генерация базы данных

http://www.sqlmanager.net/ru/tools/free

https://downloads.embarcadero.com/free

 

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

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

В CASE-средстве ER/Studio генерация физической модели осуществляется по команде Create Physical Model за восемь шагов.

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

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

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

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

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

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

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

8. Выбирается способ проверки целостности индексов таблицы (проверка таблиц без индексов, проверка таблиц с индексами, превышающими пределы).

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

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

1. Выбираются таблицы и представления для включения в генерацию кода БД.

2. Определяется, как будут реализованы первичные и альтернативные ключи.

3. Определяется, будут ли генерироваться неуникальные индексы и триггеры и как будет осуществляться ссылочная целостность.

4. Определяются параметры имеющихся в наличии физических хранилищ.

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

6. Выбирается вариант генерации исходного текста SQL или генерации объектов БД. Генерация SQL-скрипта позволяет создать БД в любое другое время.

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

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

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

Распределенная база данных (DDB – Distributed DataBase) – это совокупность множества взаимосвязанных БД, распределенных в компьютерной сети. БД распределена физически, но логически едина (имеет общую схему данных).

В системах с распределенными БД используются разные технологии распределения данных по узлам сети – фрагментация и тиражирование.

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

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

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

Ведущими поставщиками СУБД сформулированы следующие свойства идеальной системы управления распределенными БД:

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

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

· прозрачность относительно сети – СУБД должна одинаково работать в условиях разнородных сетей;

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

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

· поддержка распределенных транзакций – СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность БД при возникновении отказов как в системах, так и в сети;

· безопасность – СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа;

· универсальность доступа – СУБД должна обеспечивать единую методику доступа ко всем данным.

Ни одна из существующих СУБД не достигает этого идеала поскольку:

· низкая и несбалансированная производительность сетей снижает общую производительность обработки в распределенных транзакциях;

· обеспечение целостности данных в распределенных транзакциях базируется на принципе «все или ничего» и требует специального протокола, что приводит к длительной блокировке изменяемых данных;

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

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

· необходимо обеспечить совместимость СУБД разных типов и поставщиков;

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

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

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

· системы распределенной обработки данных;

· системы распределенных баз данных.

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

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

· презентационная логика (PL – Presentation Logic): ввод и отображение данных – внешний (пользовательский) уровень реализации функциональной обработки и представления;

· бизнес-логика (BL – Business Logic): функциональная обработка, реализующая алгоритм решения задач пользователя;

· манипулирование данными БД в рамках приложения, которое обычно реализуется средствами SQL (DL – Database Logic);

· управление данными и другими ресурсами БД, реализуемое внутренними средствами конкретной СУБД обычно в рамках файловой системы ОС;

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

Пункт 22. Транзакции

Транзакция – это законченная совокупность действий над БД, которая переводит ее из одного целостного состояния в другое. Если операторы транзакции выполняются, происходит ее нормальное завершение и БД переходит в обновленное (целостное) состояние (ситуация COMMIT на рис.). При сбое происходит откат к исходному состоянию БД (ситуация ROLLBACK на рис.).

Рис. Выполнение и откат транзакции

 

К транзакциям предъявляется набор требований, известный под названием ACID (Atomicity, Consistency, Isolation, Durability).

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

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

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

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

Рассмотрим две модели транзакций, используемые в большинстве коммерческих СУБД: модель автоматического выполнения транзакций и модель управляемого выполнения транзакций, основанные на инструкциях языка SQL – COMMIT и ROLLBACK.

Автоматическое выполнение транзакций. Модель создана на основе схемы, принятой в СУБД DB2. Транзакция автоматически начинается с выполнения пользователем или программой первой инструкции. Далее происходит последовательное выполнение инструкций, пока транзакция не завершится (см. рис. ниже).

Транзакция заканчивается одним из двух способов:

· инструкцией COMMIT, которая выполняет завершение транзакции (внесенные в БД изменения становятся постоянными, а новая транзакция начинается сразу после инструкции COMMIT);

· инструкцией ROLLBACK, которая отменяет выполнение текущей транзакции (БД возвращается к состоянию начала транзакции, новая транзакция начинается сразу после инструкции ROLLBACK).

Рис. Модель автоматического выполнения транзакций

 

Управляемое выполнение транзакций. Модель используется в СУБД Sybase, где применяется диалект Transact-SQL, в котором для обработки транзакций служат четыре инструкции:

· инструкция BEGIN TRANSACTION сообщает о начале транзакции (начало транзакции задается явно);

· инструкция COMMIT TRANSACTION сообщает об успешном выполнении транзакции (при этом новая транзакция автоматически не начинается);

· инструкция SAVE TRANSACTION позволяет создать внутри транзакции точку сохранения и присвоить сохраненному состоянию имя точки сохранения, указанное в инструкции;

· инструкция ROLLBACK отменяет выполнение текущей транзакции и возвращает БД к состоянию, где была выполнена инструкция SAVE TRANSACTION (если в инструкции указана точка сохранения – ROLLBACK TO имя_точки_сохранения) или к состоянию начала транзакции.

Пункт 19. Автоматическая генерация базы данных

http://www.sqlmanager.net/ru/tools/free

https://downloads.embarcadero.com/free

 

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

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

В CASE-средстве ER/Studio генерация физической модели осуществляется по команде Create Physical Model за восемь шагов.

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

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

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

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

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

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

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

8. Выбирается способ проверки целостности индексов таблицы (проверка таблиц без индексов, проверка таблиц с индексами, превышающими пределы).

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

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

1. Выбираются таблицы и представления для включения в генерацию кода БД.

2. Определяется, как будут реализованы первичные и альтернативные ключи.

3. Определяется, будут ли генерироваться неуникальные индексы и триггеры и как будет осуществляться ссылочная целостность.

4. Определяются параметры имеющихся в наличии физических хранилищ.

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

6. Выбирается вариант генерации исходного текста SQL или генерации объектов БД. Генерация SQL-скрипта позволяет создать БД в любое другое время.

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

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

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

Распределенная база данных (DDB – Distributed DataBase) – это совокупность множества взаимосвязанных БД, распределенных в компьютерной сети. БД распределена физически, но логически едина (имеет общую схему данных).

В системах с распределенными БД используются разные технологии распределения данных по узлам сети – фрагментация и тиражирование.

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

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

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

Ведущими поставщиками СУБД сформулированы следующие свойства идеальной системы управления распределенными БД:

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

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

· прозрачность относительно сети – СУБД должна одинаково работать в условиях разнородных сетей;

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

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

· поддержка распределенных транзакций – СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность БД при возникновении отказов как в системах, так и в сети;

· безопасность – СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа;

· универсальность доступа – СУБД должна обеспечивать единую методику доступа ко всем данным.

Ни одна из существующих СУБД не достигает этого идеала поскольку:

· низкая и несбалансированная производительность сетей снижает общую производительность обработки в распределенных транзакциях;

· обеспечение целостности данных в распределенных транзакциях базируется на принципе «все или ничего» и требует специального протокола, что приводит к длительной блокировке изменяемых данных;

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

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

· необходимо обеспечить совместимость СУБД разных типов и поставщиков;

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

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

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

· системы распределенной обработки данных;

· системы распределенных баз данных.

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

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

· презентационная логика (PL – Presentation Logic): ввод и отображение данных – внешний (пользовательский) уровень реализации функциональной обработки и представления;

· бизнес-логика (BL – Business Logic): функциональная обработка, реализующая алгоритм решения задач пользователя;

· манипулирование данными БД в рамках приложения, которое обычно реализуется средствами SQL (DL – Database Logic);

· управление данными и другими ресурсами БД, реализуемое внутренними средствами конкретной СУБД обычно в рамках файловой системы ОС;

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