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

Продолжить читать "Обмен данными с внешними системами"

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

Продолжить читать "Защита данных"

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

• размер табличных пространств для хранения таблиц;
• размер табличных пространств для хранения индексов;
• размер табличных пространств для хранения BLOB;
• кластеры и их параметры;
• размер словаря данных, включая код всех хранимых процедур, функций, триггеров, пакетов, статического SQL (реализован только в DB2);
• управляющие файлы;
• файлы журнала;
• интенсивность потока запросов, модифицирующих данные и индексы;
• фалы временных табличных пространств (для хранения временных таблиц, которые строятся, например, при выполнении group by, а также других временных объектов);
• интенсивность потока запросов, инициирующих создание временных таблиц;
• потоки транзакций read-write, read-only, объем модифицируемых и считываемых ими данных, характеристики параллельной работы транзакций (какие и сколько их);
• количество приложений, работающих параллельно с базой данных;
• количество соединений с базой данных для каждого приложения;
• файлы параметров старта ядра СУБД;
• загрузочные модули ядра СУБД и утилиты СУБД;
• входные и выходные данные, генерируемые пользовательскими программами;
• скрипты управления СУБД.

Продолжить читать "Хранение объектов данных"

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

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

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

Продолжить читать "Временные данные"

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

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

Продолжить читать "Индексы, кластеры"

Как правило, СУБД поддерживают небольшой набор базовых типов данных: числовые типы (целые, вещественные с плавающей и фиксированной точкой), строки (символов и байт), дата и время (или комбинированный тип datetime), BLOB (и его разновидности, например BLOB-поля для хранения только текста). В информационной модели каждому атрибуту соответствует домен. Поскольку не все реализации СУБД поддерживают домены, то в этом случае при определении модели данных ограничения домена описывают как ограничения столбца таблицы (если такое возможно); в частности используют check constraints, триггеры. Следует отметить, что при определении типов столбцов таблиц нужно учитывать, какие типы данных поддерживаются в словаре данных СУБД. Например, в Oracle ключевые слова integer, smallint, real поддерживаются транслятором SQL, но в словаре данных им соответствуют number(38), number(38), float(63), так как Oracle хранит данные в двоично-десятичном формате с плавающей точкой, а не в двоичном формате с плавающей точкой, и 38-восьмизначное число никак нельзя назвать словом smallint.

Продолжить читать "Типы данных"

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

Продолжить читать "ER-модель и ее отображение на схему данных"

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

Полнота проектирования

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

Переход к реализации

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

Продолжить читать "Составление спецификаций"

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

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

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

Когда генерация модуля завершена, выполняют автономный тест, который преследует две основные цели:

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

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

Продолжить читать "Проектирование процесса тестирования"