Базы данных в естественных ресурсных системах |
23-02-2023 |
2. Подготовка отчета о логической модели. Для отслеживания процесса проектирования логической модели используются отчеты.
3. Они полезны также для согласования требований с заказчиками. В уво-тах, как правило, перечисляются сущности, их атрибуты, правила и ограничения, которые содержат в базу данных. Хорошие средства подго-товки отчетов содержат различные виды информации о логическую модель, способствуют гибкому размещению и форматированию, а также по-данью отчета в файл или его экспорта в другие приложения. При узго-ждении требований с заказчиками стоит результат оформлять отдель-мым протоколом.
Преобразование логической модели в физическую. В процессе раз-работки физической модели сущности, атрибуты и связи составляют физическую модель, отображаются в таблице и столбцах. В ра-ниш заданных свойств столбцов (типов данных, длительностей и неопределенных значений) добавляются новые - первичные и внешние ключи, индексы, проверочные ограничения и правила поддержания по-силковои целостности. Чтобы правильно и хорошо выполнить этот этап проектирования, средства моделирования данных должны работать с несколькими популярными СУБД SQL-типа, графически отображать физические характеристики, позволять назначать и изменять триггери1 по умолчанию, создавать собственные триггера, денормализуваты физическую модель, не касаясь при этом логической.
Подготовка отчета о физическую модель. Как правило, для то-го, чтобы получить какую-то таблицу или все таблицы одновременно, вместе с деталями (столбики, их характеристики, индексы, внешне-шные ключи и триггера) применяют отчет о физическую модель. Хорошие средства подготовки таких отчетов просты в использовании, ма-ют гибкий интерфейс для задания элементов включаются в отчет, организации отчета и его формирование. Они долж-не предоставлять подробную информацию о реализации ограничений, пра-вил посылочной целостности, включая назначение и содержание триг-гер.
Генерация схемы базы данных. Схема описывает реализацию базы данных с учетом специфики конкретной СУБД. Схема может создаваться или языке определения данных (файлы DDL), или при обращении к СУБД. Программные продукты, которые хорошо под-выдерживают генерацию схемы, дают средства контроля генерирую-ственными элементами схемы, что позволяет сделать этот процесс Итера-тивным. Стоит искать инструменты, которые подключаются к нашей целевой СУБД и дают возможность переключаться между различными СУБД, минимизируя при этом ручное редактирование.
Сопровождение разрабатываемой модели данных. Большинство баз данных в течение своего жизненного цикла эволюционирует. Для того, чтобы упростить этот процесс, рекомендуется синхронно менять модель и базу данных. Следует обращать внимание на средства синхрониза-ции, утилиты управления версиями и защиты. С помощью найзруч-ных в работе инструментов переносить изменения в оба бо-ки: из модели в схему, и наоборот. Если раньше заказчик после сдачи СУБД в эксплуатацию отказывался от сопровождения, то теперь, как правило, проектировщики сопровождают эксплуатацию СУБД. Это накладывает на них дополнительную ответственность за качество проекта-ния, поскольку все проблемы приходится ликвидировать им самим.
Обращено проектирования, выходит из существующей базы да-них. Воспроизведение схемы существующей базы данных служит нескольким эти-лям. Оно дает возможность построить модель этой базы данных, перенес-ти существующую базу данных из одной СУБД на другую, а также достаточно просто модифицировать схему базы данных, функционирует. Ключевой ными параметрами для выполнения такого задания является точность и гибкость. Мы должны иметь возможность задать элементы схемы, с которыми будет работать программа, и ожидается, что в результате гене-рации схемы базы данных по восстановленной модели должна появиться тождественна копия исходной схемы.
Как видим, второй вариант определяет более общий подход к проектированию баз данных и учитывает отношения с заказчиком про-екта.




