Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Лекции - Проектирование информационных систем - файл Проектирование базы данных.doc


Загрузка...
Лекции - Проектирование информационных систем
скачать (89.2 kb.)

Доступные файлы (9):

1-4Основные компоненты технологии проектирования.doc39kb.09.03.2007 12:24скачать
2-4Организация разработки технического и рабочего проектов.doc43kb.09.03.2007 12:24скачать
Введение. Понятие проекта ИС.doc52kb.02.03.2007 21:50скачать
Жизненный цикл информационных систем.doc57kb.02.03.2007 21:56скачать
Каноническое проектирование.doc28kb.02.03.2007 21:55скачать
Классификация информационных систем.doc47kb.25.12.2005 19:11скачать
Методы проектирования информационных систем.doc25kb.02.03.2007 21:53скачать
Проектирование базы данных.doc54kb.26.12.2005 14:16скачать
Типовое проектирование ИС.doc28kb.25.12.2005 19:05скачать

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

Реклама MarketGid:
Загрузка...

Построение модели данных


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

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

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

  • разрешение всех дуг, подтипов и супертипов;

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

  • проектирование и реализация денормализации базы данных в целях повышения производительности;

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

  • реализация ограничений (ограничений и триггеров), отражающих все централизованно определенные бизнес-правила, генерация ограничений и триггеров;

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

  • определение необходимых индексов, кластеров (если таковые реализованы в СУБД), определение горизонтальной фрагментации таблиц (если это реализовано в СУБД);

  • оценка размеров всех таблиц, индексов, кластеров;

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

  • определение пользователей базы данных, их уровней доступа, разработка и внедрение правил безопасности доступа, аудита (если это необходимо), создание пакетированных привилегий (в зависимости от реализации СУБД это роли или группы), синонимов;

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

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


^

Создание базы данных для разработчика


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


^

Проектирование процессов и кода


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


^

Выбор средств разработки


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


^

Отображение функций на модули


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


^

Интерфейсы программ


При проектировании модулей определяют разметку меню, вид окон, горячие клавиши и связанные с ними вызовы. Существуют два вида перемещения по программам:

  • с контекстом, когда целевая экранная форма частично или полностью заполняется автоматически данными, связанными с теми, что находятся в исходной экранной форме;

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

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


^

Интегрирование и наследование механизмов обмена данными


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

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


^

Определение спецификаций модулей


Это основная часть функционального проектирования. Здесь решаются следующие задачи:

  • преобразование функциональных определений анализа в реализуемые модули;

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

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

  • определение последовательности реализации модулей и зависимостей модулей.

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

В начало


^

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


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

Раздел: распределение данных

10.01.2000

Есть мнение, что…

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

На данный момент существует централизованная система обработки информации. Основной сервер — мэйнфрейм.

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

Плюсы:

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

Минусы:

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

Что сделано:

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

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



Скачать файл (89.2 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru