Файл: Тема концепция управления данными в современных информационных системах Цель лекции.docx

Центральной компонентой инфологической модели (ИЛМ) является описание объектов предметной области и связей между ними. ИЛМ является моделью данных, отображающей предметную область в виде совокупности информационных объектов и структурных связей между ними (ER – модель).

Описание предметной области всегда представлено в какой-то знаковой системе. Поэтому при построении ИЛМ должны учитываться такие лингвистические категории (отношения), как синонимия, изоморфизм и др.

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

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

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

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

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

- из каких отношений должна состоять база данных;

- какие атрибуты должны быть у этих отношений;

- какие ограничения должны быть наложены на атрибуты и отношения базы данных, чтобы обеспечить ее целостность.

Требования к выбранному набору отношений и составу их атрибутов должны удовлетворять следующим условиям:

- отношения должны отличаться минимальной избыточностью атрибутов;

- выбранные для отношения первичные ключи должны быть минимальными;

---

- между атрибутами не должно быть нежелательных функциональных зависимостей;

- выбор отношений и атрибутов должен обеспечивать минимальное дублирование данных;

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

- время выполнения запросов на выборку данных должно удовлетворять предъявляемым требованиям;

- перестройка набора отношений при введении новых типов должна быть минимальной.

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

3.Для привязки даталогической модели к среде хранения используется фи­зическая модель. Соответствующий этап проектирования БД называется физическим проектированием. Физическая модель определяет используемые запоминающие устройства, способы физической организации данных в среде хранения. Описание физической структуры БД называется схемой хранения.

К числу работ, выполняемых на этапе физического проектирования, от­носятся:

- выбор типа носителя;

- способы организации данных;

- выбор методов доступа;

- определение размеров физического блока;

- управление размещением данных на внешнем носителе;

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

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

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

---

Использование аппарата подсхем облегчает работу пользователя, т.к. он должен знать структуру не всей БД, а только той ее части, которая имеет непосредственное отношение к нему. Кроме того, эта структура приспособлена к его потребностям.

Физическая и внешняя модели могут строиться в любой последователь­ности.

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

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

Физические структуры организации файлов данных подразделяются на линейные и нелинейные.

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

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

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

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

В результате появились программно-технологические средс­тва, получившие название CASE-средства, реализующие CASE-технологию. Термин CASE (Computer Aided Software Engineering) можно перевести как разработка программного обеспечения с по­мощью компьютера.

CASE-средства - это программные средства, поддерживающие процессы создания и сопровождения информационных систем, такие как: анализ и формулировка требований, проектирование баз данных и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и т.д. Можно выделить следующие основ­ные типы CASE- средства:

---

- средства анализа, предназначенные для построения и анализа предметной области. К ним относятся: Design/IDEF, BPwin;

- средства анализа и проектирования, обеспечивающие созда­ние проектных спецификации, например Vantage Team Builder, Silvemin, PRO-IV:

- средства проектирования баз данных, позволяющие модели­ровать базы данных, разрабатывать схемы. К ним относятся: Erwin, S-designot, DataBase Designer;

- средства разработки приложений, например, Uniface, JAM, PowerBuilder, Developer/2000, New Его, SQL Windоws.

Некоторые CASE-средства поставляются в виде автономных сис­тем, не входящих в состав конкретного CASE. К числу таких неза­висимых CASE-систем относятся S-Designer, ERwin, Silverrun. При­мером встроенной в СУБД CASE-средством является Designer/2000, входящий в состав Oracle.

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

Основная цель CASE- систем и средств состоит в том, чтобы отде­лить проектирование программного обеспечения от его кодирования и последующих этапов разработки, а также автоматизировать весь процесс создания программных систем.

CASE-технология определяется как методология проектирова­ния информационных систем. CASE-технология - это также инс­трументальные средства, позволяющие моделировать предмет­ную область, анализировать ее модель на всех этапах разработки и сопровождения информационной системы и разрабатывать при­ложения для пользователей.

Как правило, современные средства проектирования данных поддерживают несколько типов СУБД (например, ERwin фирмы Computer Associates поддерживает более 20 различных СУБД). Уровень поддержки той или иной платформы в разных средствах проектирования данных может быть различен. Например, конкретное средство может поддерживать или не поддерживать для данной СУБД такие особенности, как создание хранимых процедур, генерация объектов физической памяти (табличных пространств, сегментов отката и др.), задание местоположения объектов базы данных в физических объектах и т.д. Поэтому, выбирая средство проектирования данных для решения конкретной задачи, стоит поинтересоваться, каковы его возможности с точки зрения поддержки особенностей той или иной платформы — при удачном раскладе можно сэкономить немало времени на «ручное» доведение создаваемой базы данных (или DDL-скрипта для ее генерации) до необходимого состояния. При этом, естественно, чем больше возможностей и платформ поддерживает конкретное средство проектирования данных, тем дороже оно стоит (следует отметить, что CASE-средства вообще относятся к не самым дешевым программным продуктам — цены на них составляют обычно от одной до нескольких десятков тысяч условных единиц).

---

Отметим, что физическое проектирование может включать и дополнительную «ручную» работу по доведению базы данных или скрипта для ее генерации до «товарного» вида. Например, нередко в скрипт также включаются SQL-предложения для заполнения некоторых таблиц, данные которых более или менее постоянны, таких, например, как список субъектов РК или справочник телефонных кодов различных стран, а также нестандартные триггеры и процедуры.

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

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

Кроме того, подавляющее большинство средств проектирования данных позволяют восстанавливать физическую модель данных их системного каталога и представлять ее в виде ER-диаграммы (этот процесс называется обратным проектированием — reverse engineering), а также производить синхронизацию системного каталога и физической модели. При создании информационной системы, которая должна использовать унаследованные от предшествующих ей систем данные, такая особенность весьма полезна — в этом случае логическое проектирование можно начать с модификации уже имеющейся модели (этот процесс получил название round-trip engineering).

Наиболее популярные средства проектирования данных, как специализированные, так и входящие в состав комплексных CASE – средств: Designer/2000 (Oracle); ERwin (Computer Associates); PowerDesigner (Sybase); ER/Studio (Embarcadero Technologies); System Architect (Popkin Software); Visible Analyst (Visible Systems Corporation); Visio Enterprise (Microsoft)

Изучение возможностей этих продуктов свидетельствует о том, что все они, обладая своими особенностями и имея в определенной степени различающиеся сферы применения, как правило, имеют и сходные черты, в число которых входят:

---