2.3. Уровни представления данных. Этапы проектирования
Ситуация реального проекта обследования предприятия характеризуется в первую очередь сложностью выделения и формализации процессов, описания форматов данных.
Принята следующая классификация уровней представления данных:
1. Логический уровень соответствует такому взгляду на данные, при котором они представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
2. Физический уровень представления данных, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д
3. Уровень документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом).
Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области.
Разделение модели на логическую и физическую позволяет решить проблему анализа группой специалистов. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов.
Например, таблице CUST_A12 может соответствовать сущность «Постоянный клиент». Такое соответствие позволяет лучше документировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.
Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и применить информационную среду автоматической генерации физической модели, например Design IDEF, Erwin или др. На основе физической модели в среде может быть выполнена генерация системного каталога СУБД или соответствующего SQL-скрипта. Этот процесс называется прямым проектированием (Forward Engineering).
Тем самым достигается масштабируемость - создав одну логическую модель данных, можно провести генерацию физической модели для поддерживаемой средой моделирования СУБД.
С другой стороны, среда моделирования дает возможность по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering).
На основе полученной логической модели данных можно выполнить генерацию физической модели для другой СУБД и затем провести генерацию системного каталога для этой СУБД.
Следовательно, информационное моделирование в принципе позволяет решить задачу переноса структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной информационной системе.
Рис. 11. Уточненная диаграмма для сбытового подразделения.
Заметим, что формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен; для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать.
При разработке ER-моделей создается следующий набор формализованных сведений о предметной области:
список сущностей предметной области.
список атрибутов сущностей.
списание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным.
Разработав первый приближенный вариант диаграмм, далее этот вариант уточняется на основании результатов опросов экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Предположим, что поставлена задача разработать информационную систему по заказу сбытового подразделения предприятия. В первую очередь необходимо изучить предметную область и процессы, происходящие в ней. Для этого опрашиваютя сотрудники, анализируется документация, изучаются формы заказов, накладных и т.п.
Например, в ходе беседы с менеджером по продажам выяснилось, что с точки зрения менеджера проектируемая система должна обеспечивать следующие функции:
хранить информацию о покупателях;
распечатывать накладные на отпущенные товары;
позволять отслеживать наличие товаров на складе.
Сущностями могут быть «покупатель», «накладная», «товар». Если предприятие имеет несколько складов, то «склад» также может являться новой сущностью.
Связь между сущностями может быть быть описана следующим образом:
"покупатели могут покупать много товаров";
"товары могут продаваться многим покупателям".
Соответствующий вариант диаграммы представлен на рис.10.
Внесем дополнительную информацию. Например, в ходе обследования территории предприятия выяснилось, что имеетсыя несколько складов, причем каждый товар может храниться на любом из складов и может быть продан с любого склада.
Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя.
Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма примет вид, изображенный на рис.11.
Определим атрибуты сущностей:
каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты;
каждый товар имеет наименование, цену, а также характеризуется единицами измерения;
каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной; накладная выписывается с определенного склада и на определенного покупателя;
каждый склад имеет свое наименование.
Проанализируем полученные описания следующим образом:
«юридическое лицо» - предприятие не работает с физическими лицами, поэтому данный термин не является существенной характеристикой;
наименование покупателя - является характеристикой покупателя;
адрес - является характеристикой покупателя;
банковские реквизиты - являются характеристикой покупателя;
наименование товара - является характеристикой товара;
единица измерения - является характеристикой товара;
номер накладной - является характеристикой накладной, причем уникальной характеристикой;
дата накладной - является характеристикой накладной, причем уникальной характеристикой;
список товаров в накладной - нужно выделить список в отдельную сущность;
сумма накладной - является характеристикой накладной, однако эта характеристика не независима (сумма накладной равна сумме стоимостей всех товаров, входящих в накладную);
наименование склада - является характеристикой склада.
Предположим, что в ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен.
Рис. 12. Диаграмма для сбытового подразделения с учетом результата анализа дополнительных данных.
Оказалось, что каждый товар имеет некоторую текущую цену. Это цена, по которой товар продается в данный момент.
Цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара.
С понятием "Список товаров в накладной"имеется ясность. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа «многие-ко-многим». Такая связь должна быть раскрыта как две связи типа «один-ко-многим». Для этого требуется дополнительная сущность.
Этой сущностью может являться сущность "Список товаров в накладной".
Связь этой новой сущности с сущностями "Накладная" и "Товар" характеризуется следующим образом:
"каждая накладная обязана иметь несколько записей из списка товаров в накладной";
"каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную";
"каждый товар может включаться в несколько записей из списка товаров в накладной";
"каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром".
Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности "Список товаров в накладной".
Аналогично проанализируем связь, соединяющую сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
На рис.12 представлена диаграмма для рассмотренного примера.
Следует отметить, что возникающие при реструктуризации предприятий задачи разработки информационной модели и реляционных баз данных с особенностями именно конкретного подразделения относятся к числу новых технических реализаций; они могут дополнять типовые контуры MRP, ERP или CRM. Новизны научной или методической в таких технических реализациях не имеется.
Для случаев, когда данные не могут быть описаны средствами бинарной алгебры, общая теория и модель применимы с ограничениями, или вообще не работают; оптимизатор запроса в такой среде также не может быть спроектирован по стандартной технологии. Обеспечение качества и целостности данных в таких задачах является открытой научной проблемой.