Социология. Моделирование данных hl. Системы управления базами данных
 Скачать 0.68 Mb.
|
|
3.1. Этапы проектирования Основные этапы проектирования можно отобразить с помощью схемы, представленной на рис. 14. Рассмотрим каждый из этапов подробнее: Первый этап. Планирование разработки базы данных. На этом этапе выделятся наиболее эффективный способ реализации этапов жизненного цикла системы. Второй этап. Определение требований к системе. Производится определение диапазона действий и границ приложения базы данных, а также производится сбор и анализ требований пользователей. Третий этап. Проектирование концептуальной модели БД. Процесс создания БД начинается с определения концептуальной модели, представляющей объекты и их взаимосвязи без указания способов их физического хранения. Усилия на этом этапе должны быть направлены на структуризацию данных и выявление взаимосвязей между ними. Этот процесс можно разбить еще на несколько подэтапов: a) Уточнение задачи. Перед началом работы над конкретным приложением у разработчика наверняка имеются некоторые представления о том, что он будет разрабатывать. В случаях, когда разрабатывается небольшая персональная БД, такие представления могут быть достаточно полными. В других случаях, когда разрабатывается большая БД под заказ, таких представлений может 48 быть очень мало, или они наверняка будут поверхностными. Сразу начинать разработку с определения таблиц, полей и связей между ними будет явно рановато. Такой подход наверняка приведет к полной переделке большей части приложения. Поэтому следует затратить некоторое время на составление списка всех основных задач, которые должны решаться этим приложением, включая и те, которые могут возникнуть в будущем. Рис. 14. Схема проектирования БД b) Уточнение последовательности выполнения задач. Чтобы приложение работало логично и удобно, лучше всего объединить основные задачи в группы и затем упорядочить задачи каждой группы так, чтобы они располагались в порядке их выполнения. Группировка и графическое представление последовательности их выполнения поможет определить естественный порядок выполнения задач. c) Анализ данных. После определения списка задач необходимо для каждой задачи составить полный перечень данных, требуемых для ее решения. После анализа данных можно приступать к разработке 49 Проектирование концептуальной модели Проектирование логической модели Проектирование физической модели Оценка физической модели Реализация базы данных Тестирование Требования СУБД Оценка эксплуатационных характеристик Сопровождение Планирование разработки базы данных Определение требований к системе концептуальной модели, т.е. к выделению объектов, атрибутов и связей. Четвертый этап. Построение логической модели. Построение логической модели начинается с выбора модели данных. При выборе модели важную роль играет ее простота, наглядность и сравнение естественной структуры данных с моделью, ее представляющей. Но зачастую этот выбор определяется успехом (или наличием) той или иной СУБД. Т.е. разработчик выбирает СУБД, а не модель данных. Таким образом, на этом этапе концептуальная модель транслируется в модель данных, совместимую с выбранной СУБД. Возможно, что отображенные в концептуальной модели взаимосвязи между объектами либо некоторые атрибуты объектов окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменение концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью. Иногда процесс определения концептуальной и логической моделей называется определением структуры данных. Пятый этап. Построение физической модели. Физическая модель определяет размещение данных, методы доступа и технику индексирования. На этапе физического проектирования мы привязываемся к конкретной СУБД и расписываем схему данных более детально, с указанием типов, размеров полей и ограничений. Кроме разработки таблиц и индексов, на этом этапе производится также определение основных запросов. При построении физической модели приходится решать две взаимно противоположные по своей сути задачи. Первой из них является минимизация места хранения данных, а второй – достижение максимальной производительности, целостности и безопасности данных. Например, для обеспечения высокой скорости поиска необходимо создание индексов, причем их число будет определяться всеми возможными комбинациями полей, участвующими в поиске; для восстановления данных требуется ведения журнала всех изменений и создание резервных копий БД; для эффективной работы транзакций требуется резервирование места на диске под временные объекты и т.д., что приводит к увеличению (иногда значительному) размера БД. Шестой этап. Оценка физической модели. На этом этапе проводится оценка эксплуатационных характеристик. Здесь можно проверить эффективность выполнения запросов, скорость поиска, правильность и удобство выполнения операций с БД, целостность данных и эффективность расхода ресурсов компьютера. При неудовлетворительных эксплуатационных характеристиках возможен возврат к пересмотру физической и логической моделей данных, выбору СУБД и типа компьютера. 50 Седьмой этап. Реализация БД. При удовлетворительных эксплуатационных характеристиках можно перейти к созданию макета приложения, т.е. набору основных таблиц, запросов, форм и отчетов. Этот предварительный макет можно продемонстрировать перед заказчиком и получить его одобрение перед детальной реализации приложения. Восьмой этап. Тестирование и оптимизация. Обязательным этапом является тестирование и оптимизация разработанного приложения. Этап девятый, заключительный. Сопровождение и эксплуатация. Так как выявить и устранить все ошибки на этапе тестирования не получается, то этап сопровождения является обычным для баз данных. Существует два основных подхода к проектированию схемы данных: нисходящий и восходящий. При восходящем подходе работа начинается с нижнего уровня – уровня определения атрибутов, которые на основе анализа существующих между ними связей группируются в отношения, представляющие объекты, и связи между ними. Процесс нормализации таблиц для реляционной модели данных является типичным примером этого подхода. Этот подход хорошо подходит для проектирования относительно небольших БД. При увеличении числа атрибутов до нескольких сотен и даже тысяч более подходящей стратегией проектирования является нисходящий подход. Начинается этот подход с определения нескольких высокоуровневых сущностей и связей между ними. Затем эти объекты детализируются до необходимого уровня. Примером такого подхода проектирования является использование модели сущность- связь. На практике эти подходы обычно комбинируются. В этом случае можно говорить о смешанном подходе проектирования. 3.2. Средства автоматизированной разработки приложений Проектирование БД можно проводить с помощью автоматизированных систем разработки приложений, так называемых CASE (Computer Aided Software Engineering) систем. Автоматизированные системы разработки приложений представляют собой программные средства, поддерживающие процессы создания и сопровождения информационных систем, такие как анализ и формулировка требований, проектирование приложений, генерация кода, тестирование, управление конфигурацией и проектом. Основная цель CASE систем состоит в том, чтобы отделить процесс проектирования программного обеспечения от его кодирования и последующих этапов разработки (тестирование, документирование и т.д.), а также автоматизировать весь процесс создания программных систем. Процесс разработки баз данных с помощью CASE систем на этапе концептуального проектирования обычно проводится с помощью ER 51 модели. ER модель необходимо рассматривать как способ концептуального проектирования данных, а не как самостоятельную модель данных. Результатом проектирования практически всегда (или до недавнего времени) являлась реляционная модель данных. В последнее время с появлением объектно-ориентированной модели данных, конечным результатом проектирования все чаще стали являться объектно- ориентированная и объектно-реляционная модели данных. Для автоматизации проектирования объектно-ориентированных баз данных CASE системы предоставляют специальный язык Unified Modeling Language (UML), который можно определить как промышленный объектно- ориентированный стандарт моделирования. Его составляющими можно назвать языки OMT (Object Modeling Technique) и OOSE (Object-Oriented Software Engineering). Большую роль в создании этого языка сыграл консорциум OMG (Object Management Group), включающий ряд ведущих производителей программного обеспечения. CASE системы различаются по ориентации, по функциональной полноте и по типу используемой модели. По ориентации можно выделить CASE системы, предназначенные для анализа предметной области, для проектирования баз данных и для полной разработки приложений. К числу последних можно отнести MS Visual Studio. По функциональной полноте разделяются на системы, предназначенные для решения отдельных задач проектирования и на интегрированные системы, поддерживающие весь цикл разработки. По типу используемой модели разделяются на структурные ,объектно-ориентированные и комбинированные. Примерами CASE систем могут служить: ERWin (Logic Works), Rational Rose (Rational Software) (OODBMS), S-Designer (SPD), DataBase Designer, Developer/Designer 2000 (Oracle Corp.). Контрольные вопросы и задания 1. Сформулируйте требования, которым должна удовлетворять БД. 2. На что должны быть направлены усилия разработчиков при построении концептуальной модели. 3. Отобразите схематично основные этапы проектирования БД и дайте их характеристику. 4. Чем отличается логическая модель данных от концептуальной. 5. Какие две противоположные по сути задачи приходится решать при построении физической модели. 6. Что такое CASE системы. 7. Дайте классификацию CASE систем. 52 |