Моделирование данных
Одной из главных частей информационного обеспечения есть информационная база. Как было выяснено выше (см. лекцию 9), информационная база (ИБ) является совокупностью данных, организованную определенным методом и хранимую в памяти вычислительной совокупности в виде файлов, благодаря которым удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется посредством моделирования данных. Цель моделирования данных пребывает в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели либо нескольких локальных моделей, каковые довольно легко смогут быть отображены в любую совокупность баз данных. Самый распространенным средством моделирования данных являются диаграммы сущность-связь (ERD). Посредством ERD осуществляется детализация накопителей данныхDFD – диаграммы, и документируются информационные нюансы бизнес-совокупности, включая идентификацию объектов, ответственных для предметной области ( сущностей ), особенностей этих объектов ( атрибутов ) и их связей с другими объектами (взаимоотношений).
Базисные понятия ERD
Сущность (Entity) — множество экземпляров настоящих либо абстрактных объектов (людей, событий, состояний, идей, предметов и др.), владеющих неспециализированными атрибутами либо чертями. Любой объект совокупности возможно представлен лишь одной сущностью, которая должна быть уникально идентифицирована. Наряду с этим имя сущности должно отражать тип либо класс объекта, а не его конкретный экземпляр (к примеру, АЭРОПОРТ, а не ВНУКОВО).
Любая сущность обязана владеть неповторимым идентификатором. Любой экземпляр сущности обязан конкретно идентифицироваться и различаться от всех других экземпляров данного типа сущности. Любая сущность обязана владеть некоторыми особенностями:
- иметь неповторимое имя; к одному и тому же имени должна в любой момент применяться одинаковая интерпретация; одинаковая интерпретация не имеет возможности использоваться к разным именам, в случае, если лишь они не являются псевдонимами;
- иметь один либо пара атрибутов, каковые или принадлежат сущности, или наследуются через сообщение ;
- иметь один либо пара атрибутов, каковые конкретно идентифицируют любой экземпляр сущности.
Любая сущность может владеть любым числом связей с другими сущностями модели.
Сообщение (Relationship) — поименованная ассоциация между двумя сущностями, значимая для разглядываемой предметной области. Связь — это ассоциация между сущностями, при которой любой экземпляр одной сущностиассоциирован с произвольным (а также нулевым) числом экземпляров второй сущности, и напротив.
Атрибут (Attribute) — каждая черта сущности, значимая для разглядываемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной чёрта либо выражения состояния сущности . Атрибут воображает тип черт либо особенностей, ассоциированных с множеством настоящих либо абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная черта отдельного элемента множества. Экземпляратрибута определяется ее значением и типом характеристики, именуемым значениематрибута. На диаграмме сущность-связь атрибуты ассоциируются с конкретными сущностями. Так, экземпляр сущности обязан владеть единственным определенным значением для ассоциированного атрибута.
Способ IDEFI
Самый распространенными способами для построения ERD-диаграмм являются способ Баркера и способ IDEFI.
Способ Баркера основан на нотации, предложенной автором, и употребляется в case-средстве Oracle Designer.
Способ IDEFI основан на подходе Чена и разрешает выстроить модель данных, эквивалентную реляционной модели в третьей обычной форме. На базе совершенствования способа IDEFI создана его новая версия — способ IDEFIX, созданный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы употребляются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).
В способе IDEFIX сущность есть свободной от идентификаторов либо легко свободной, в случае, если любой экземпляр сущности возможно конкретно идентифицирован без определения его взаимоотношений с другими сущностями.Сущность именуется зависимой от идентификаторов либо легко зависимой, в случае, если однозначная идентификация экземпляра сущности зависит от его отношения к второй сущности (рис. 10.1, 10.2).
Рис. 10.1.Свободные от идентификации сущности
Рис. 10.2.Зависимые от идентификации сущности
Каждой сущности присваиваются неповторимые номер и имя, разделяемые косой чертой / и помещаемые над блоком.
Сообщение может дополнительно определяться посредством указания степени либо мощности (количества экземпляров сущности-потомка, которое может порождать любой экземпляр сущности-родителя). В IDEFIX смогут быть выражены следующие мощности связей:
- любой экземпляр сущности-родителя может иметь ноль, один либо более одного связанного с ним экземпляра сущности-потомка;
- любой экземпляр сущности-родителя должен иметь не меньше одного связанного с ним экземпляра сущности-потомка;
- любой экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
- любой экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
В случае, если экземпляр сущности-потомка конкретно определяется собственной связью с сущностью-родителем, то сообщение именуется идентифицирующей, в другом случае — неидентифицирующей.
Сообщение изображается линией, проводимой между сущностью-сущностью потомком и-родителем, с точкой на финише линии у сущности-потомка (рис. 10.3). Мощность связей может принимать следующие значения: N — ноль, один либо более, Z — ноль либо один, Р — один либо более. По умолчанию мощность связей принимается равной N.
Рис. 10.3.Графическое изображение мощности связи
Идентифицирующая связь между сущностью-сущностью потомком и-родителем изображается целой линией. Сущность-потомок в идентифицирующей связи есть зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи возможно как свободной, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями ).
Пунктирная линия изображает неидентифицирующую сообщение (рис. 10.4). Сущность-потомок в неидентифицирующей связи будет свободной от идентификатора, если она не есть кроме этого сущностью-потомком в какой-либо идентифицирующей связи.
Атрибуты изображаются в виде перечня имен в блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху перечня и отделяются от вторых атрибутов горизонтальной чертой (рис. 10.4 ).
Сущности смогут иметь кроме этого внешние ключи (Foreign Key), каковые смогут употребляться в качестве части либо целого первичного ключа либо неключевого атрибута. Для обозначения внешнего ключа вовнутрь блока сущности помещают имена атрибутов, по окончании которых следуют буквы FK в скобках (рис. 10.4).
Рис. 10.4.Неидентифицирующая сообщение
Документирование модели
Многие СУБД имеют ограничение на именование объектов (к примеру, ограничение на длину имени таблицы либо запрет применения особых знаков — пробела и т. п.). Обычно разработчики ИС имеют дело с нелокализованными предположениями СУБД. Это указывает, что объекты БД смогут именоваться маленькими словами, лишь латинскими знаками и без применения особых знаков (т. е. нельзя назвать таблицу, применяя предложение — ее возможно назвать лишь одним словом). Помимо этого, проектировщики БД часто злоупотребляют техническими наименованиями, в следствии колонки и таблица приобретают наименования типа RTD_324 либо CUST_A12 и т.д. Взятую в следствии структуру смогут осознать лишь эксперты (а значительно чаще — лишь авторы модели), ее нереально обсуждать с специалистами предметной области. Разделение модели на логическую и физическую разрешает решить эту проблему. На физическом уровне объекты БД смогут именоваться так, как того требуют ограничения СУБД. На логическом уровне возможно этим объектам дать синонимы — имена более понятные неспециалистам, а также на кириллице и с применением особых знаков. К примеру, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие разрешает лучше документировать модель и позволяет обсуждать структуру данных с специалистами предметной области.
Масштабирование
Создание модели данных, в большинстве случаев, начинается с разработки логической модели. По окончании описания логической модели проектировщик может выбрать нужную СУБД, и ERwin машинально создаст соответствующую физическую модель. На базе физической модели ERwin может сгенерировать системный каталог СУБД либо соответствующий SQL-скрипт. Данный процесс именуется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость — создав одну логическую модель данных, возможно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. Иначе, ERwin способен по содержимому системного каталога либо SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На базе взятой логической модели разрешённых можно сгенерировать физическую модель для второй СУБД и после этого создать ее системный каталог. Следовательно, ERwin разрешает решить задачу по переносу структуры данных с одного сервера на другой. К примеру, возможно перенести структуру данных с Oracle на Informix (либо напротив) либо перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив переход от файл-серверной к клиент-серверной ИС. Но, формальный перенос структуры плоских таблиц на реляционную СУБД в большинстве случаев неэффективен. Чтобы извлечь пользы от перехода на клиент-серверную разработку, структуру разрешённых следует модифицировать.
Для переключения между логической и физической моделью данных помогает перечень выбора в центре панели инструментов ERwin (рис. 10.5).
В случае, если при переключении физической модели еще не существует, она будет создана машинально.
Рис. 10.5.Переключение между логической и физической моделью
Интерфейс ERwin. Уровни отображения модели
Интерфейс выполнен в стиле Windows-приложений, достаточно несложен и интуитивно понятен. Разглядим коротко главные функции ERwin по отображению модели.
Каждому уровню отображения модели соответствует собственная палитра инструментов. На логическом уровне палитра инструментов имеет следующие кнопки:
- кнопку указателя (режим мыши) — в этом режиме возможно установить фокус на каком-либо объекте модели;
- кнопку внесения сущности ;
- кнопку категории (категория, либо категориальная сообщение, — особый тип связи между сущностями, которая будет рассмотрена ниже);
- кнопку внесения текстового блока;
- кнопку перенесения атрибутов в сущностей и между ними;
- кнопки создания связей: идентифицирующую, многие-ко-многим и неидентифицирующую.
На физическом уровне палитра инструментов имеет:
- вместо кнопки категорий — кнопку внесения представлений (view);
- вместо кнопки связи многие-ко-многим — кнопку связей представлений.
Для моделей данных в ERwin возможно применять две нотации: IDEFIX и IE (Information Engineering). В будущем будет рассматриваться нотация IDEFIX.
ERwin имеет пара уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями возможно с применением кнопок панели инструментов. Переключиться на другие уровни отображения возможно при помощи контекстного меню, которое появляется, в случае, если кликнуть по любому месту диаграммы, не занятому объектами модели. В контекстном меню направляться выбрать пункт Display Level (рис. 10.6) и после этого — нужный уровень отображения.
Рис. 10.6.Выбор уровней отображения диаграммы
Уровни логической модели
Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
- диаграмма сущность-связь (Entity Relationship Diagram, ERD);
- модель данных, основанная на ключах (Key Based model, KB);
- полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь является моделью данных верхнего уровня. Она включает взаимосвязи и сущности, отражающие главные бизнес-правила предметной области. Такая диаграмма не через чур детализирована, в нее включаются связи и основные сущности между ними, каковые удовлетворяют главным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. В большинстве случаев, ERD употребляется для обсуждения и презентаций структуры данных с специалистами предметной области.
Модель данных, основанная на ключах, — более подробное представление данных. Она включает описание всех первичных ключей и сущностей и предназначена для представления структуры данных и ключей, каковые соответствуют предметной области.
Полная атрибутивная модель — самоё детальное представление структуры данных: воображает данные в третьей обычной форме и включает все сущности, связи и атрибуты .
Сущности и атрибуты
Главные компоненты диаграммы ERwin — это сущности, связи и атрибуты. Любая сущность есть множеством аналогичных личных объектов, именуемых экземплярами. Любой экземпляр личен и обязан различаться от всех остальных экземпляров. Атрибут высказывает определенное свойство объекта. С позиций БД (физическая модель) сущности соответствует таблица, экземпляру сущности — строчок в таблице, а атрибуту — колонка таблицы.
Построение модели данных предполагает определение атрибутов и сущностей, т. е. нужно выяснить, какая информация будет храниться в конкретной сущности либо атрибуте. Сущность возможно выяснить как объект, событие либо концепцию, информация о которых обязана сберигаться. сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить технических наименований и быть достаточно ответственными чтобы их моделировать. Именование сущности в единственном числе облегчает в будущем чтение модели. Практически имя сущности дается по имени ее экземпляра. Примером может бытьсущности Клиент (но не Клиенты!) с атрибутами Номер клиента, Адрес заказчика и Фамилия заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number,Customer_name и Customer_address. Любая сущность должна быть абсолютно выяснена посредством текстового описания. Для внесения дополнительных определений и комментариев к сущности помогают свойства, определенные пользователем (UDP). Применение (UDP) подобно их применению в BPwin.
Как было указано выше, любой атрибут хранит данные об определенном свойствесущности, а любой экземпляр сущности должен быть неповторимым. Атрибут либо несколько атрибутов, каковые идентифицируют сущность, именуется первичным ключом .
Крайне важно дать атрибуту верное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила разрешает частично решить проблему нормализации данных уже на этапе определения атрибутов. К примеру, создание в сущности Сотрудник атрибута Телефоны сотрудника противоречит требованиям нормализации, потому, что атрибут должен быть атомарным, т. е. не содержать множественных значений. В соответствии с синтаксису IDEFIX имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его.
Любой атрибут должен быть выяснен, наряду с этим направляться избегать циклических определений, к примеру, в то время, когда термин 1 определяется через термин 2, термин 2 — через термин 3, а термин 3 со своей стороны — через термин 1. Довольно часто приходится создавать производные атрибуты, т. е. атрибуты, значение которых возможно вычислить из вторых атрибутов. Примером производного атрибута может служить Возраст сотрудника, что возможно вычислен из атрибутаДата рождения сотрудника. Таковой атрибут может привести к конфликтам; вправду, в случае, если одновременно с не обновить значение атрибута Возраст сотрудника, он может противоречить значению атрибута Дата рождения сотрудника. Производные атрибуты — неточность нормализации, но их вводят для увеличения производительности совокупности, дабы не проводить вычисления, каковые на практике смогут быть сложными.
Связи
Сообщение есть логическим соотношением между сущностями. Любая сообщение обязана именоваться глаголом либо глагольной фразой. Имя связи высказывает некое ограничение либо бизнес-правило и облегчает чтение диаграммы. По умолчанию имя связи на диаграмме не показывается. На логическом уровне возможно установить идентифицирующую сообщение один-ко-многим, сообщение многие-ко-многим и неидентифицирующую сообщение один-ко-многим.
В IDEFIX различают зависимые и свободные сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между свободной (родительский финиш связи ) и зависимой (дочерний финиш связи ) сущностями. В то время, когда рисуется идентифицирующая сообщение, не сильный машинально преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется лишь через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности машинально переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи именуется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ — FK.
При установлении неидентифицирующей связи дочерняя сущность остается свободной, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая сообщение помогает для связывания свободных сущностей.
Идентифицирующая сообщение показывается на диаграмме целой линией с жирной точкой на дочернем финише связи, неидентифицирующая – пунктирной (см. рис. 10.6).
Мощность связей (Cardinality) — помогает для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа сущности:
- неспециализированный случай, в то время, когда одному экземпляру родительской сущности соответствуют 0, 1 либо довольно много экземпляров дочерней сущности ; не помечается каким-либо знаком;
- знаком Р помечается случай, в то время, когда одному экземпляру родительской сущности соответствуют 1 либо довольно много экземпляров дочерней сущности (исключено нулевое значение);
- знаком Z помечается случай, в то время, когда одному экземпляру родительской сущности соответствуют 0 либо 1 экземпляр дочерней сущности (исключены множественные значения);
- цифрой помечается случай правильного соответствия, в то время, когда одному экземпляру родительской сущности соответствует заблаговременно заданное число экземпляров дочерней сущности.
Имя связи (Verb Phrase) — фраза, характеризующая отношение между родительской и дочерней сущностями . Для связи один-ко-многим, идентифицирующей либо неидентифицирующей, достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим направляться показывать имена как Parent-to-Child, так и Child-to-Parent.
Ключи
Как было сообщено выше, любой экземпляр сущности должен быть неповторим и обязан различаться от вторых атрибутов.
Первичный ключ (primary key) — это атрибут либо несколько атрибутов, конкретно идентифицирующая экземпляр сущности . атрибуты первичного ключа на диаграмме не требуют особого обозначения — это те атрибуты, каковые находятся в перечне атрибутов выше горизонтальной линии (см., к примеру, рис. 10.9).
В одной сущности могут быть пара атрибутов либо комплектов атрибутов, претендующих на роль первичного ключа. Такие претенденты именуются потенциальными ключами (candidate key).
Ключи смогут быть сложными, т. е. содержащими пара атрибутов. Сложные первичные ключи не требуют особого обозначения — это перечень атрибутов, расположенных выше горизонтальной линии.
Разглядим кандидатов на роль первичного ключа сущности Сотрудник (рис. 10.10).
Рис. 10.10.Определение первичного ключа для сущности Сотрудник
Тут возможно выделить следующие потенциальные ключи:
1. Табельный номер ;
2. Номер паспорта ;
3. Фамилия + Имя + Отчество.
Чтобы стать первичным, потенциальный ключ обязан удовлетворять последовательности требований:
Уникальность. Два экземпляра не должны иметь однообразных значений вероятного ключа. потенциальный ключ № 3 ( Фамилия + Имя + Отчество ) есть нехорошим кандидатом, потому, что в организации смогут трудиться полные тезки.
Компактность. Сложный вероятный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к потере уникальности. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения иЦвет волос. В случае, если бизнес-правила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос выясняется лишним, т. е. ключФамилия + Имя + Отчество + Дата рождения + Цвет волос не есть компактным.
При выборе первичного ключа предпочтение должно отдаваться более несложным ключам, т. е. ключам, содержащим меньшее количество атрибутов. В приведенном примере ключи № 1 и 2 предпочтительней ключа № 3.
Атрибуты ключа не должны иметь нулевых значений. Значение атрибутов ключа не должно изменяться В течение всего существования экземпляра сущности. Сотрудница организации может выйти замуж и поменять как фамилию, так и паспорт. Исходя из этого ключи № 2 и 3 не подходят на роль первичного ключа.
Любая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют лишь один потенциальный ключ. Таковой ключ делается первичным. Кое-какие сущности смогут иметь более одного вероятного ключа. Тогда один из них делается первичным, а остальные — другими ключами.
Другой ключ (Alternate Key) — это потенциальный ключ, не ставший первичным.
Нормализация данных
Нормализация данных — процесс проверки и реорганизациисущностей иатрибутов с целью удовлетворения требований к реляционноймодели данных. Нормализация разрешает быть уверенным, что любой атрибут выяснен для собственной сущности, и существенно снизить количество памяти для хранения информации и устранить странности в организации хранения данных. В следствии проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится лишь в одном месте. Процесс нормализации сводится к последовательному приведению структуры данных к обычным формам — формализованным требованиям к организации данных. Известны шесть обычных форм.
На практике в большинстве случаев ограничиваются приведением данных к третьей обычной форме. Для углубленного изучения нормализации рекомендуется книга К. Дж. Дейта Введение в совокупности баз данных (Киев; М.: Диалектика, 1998).
ERwin не содержит полного метода нормализации и не имеет возможности проводить нормализацию машинально, но его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных именатрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила один факт — в одном месте. Имена ролей атрибутов внешних ключей и унификация атрибутов кроме этого облегчают построение нормализованной модели.
Домены
Домен возможно выяснить как совокупность значений, из которых берутся значения атрибутов . Любой атрибут возможно выяснен лишь на одном домене, но на каждом домене возможно выяснено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных. К примеру, возможно выяснить домен Возраст как хорошее целое число и выяснить атрибут Возраст сотрудника как принадлежащий этомудомену.
В ERwin домен возможно выяснен лишь один раз и употребляться как в логической, так и в физической модели.
Домены разрешают уменьшить работу с данными как разработчикам на этапе проектирования, так и администраторам БД на этапе эксплуатации совокупности. На логическом уровне домены возможно обрисовать без конкретных физических особенностей. На физическом уровне они машинально приобретают своеобразные особенности, каковые возможно поменять вручную. Так, домен Возраст может иметь на логическом уровне тип Number, на физическом уровне колонкам домена будет присвоен тип INTEGER.
Любой домен возможно обрисован, снабжен комментарием либо свойством, определенным пользователем (UDP).
Индексы
В БД эти в большинстве случаев сохраняются в том порядке, в котором их ввели в таблицу. Многие реляционные СУБД имеют страничную организацию, при которой таблица может храниться фрагментарно в различных областях диска, причем строки таблицы находятся на страницах неупорядоченно. Таковой метод разрешает скоро вводить новые эти, но затрудняет поиск данных.
Дабы решить проблему поиска, СУБД применяют объекты, именуемые индексами. Индекс содержит упорядоченную по колонке либо нескольким колонкам данные и говорит о строках, в которых хранится конкретное значение колонки. Потому, что значения в индексе сохраняются в определенном порядке, при поиске просматривать необходимо намного меньший количество данных, что значительно уменьшает время исполнения запроса. Индекс рекомендуется создавать для тех колонок, по которым довольно часто производится поиск.
При генерации схемы физической БД ERwin машинально формирует индекс на базе первичного ключа каждой таблицы, и на базе всех альтернативных и внешних ключей , потому, что эти колонки чаще всего употребляются для поиска данных. Возможно отказаться от генерации индексов по умолчанию и создать личные индексы. Для повышения эффективности поиска администратор БД обязан разбирать довольно часто делаемые запросы и на базе анализа создавать личные индексы.
Вычисление размера БД
ERwin разрешает вычислить приблизительный размер БД в целом, и таблиц, индексов и других объектов через определенный период времени по окончании начала эксплуатации ИС. Расчет строится на базе следующих параметров: начальное количество строчков; предельное число строчков; прирост количества строчков в месяц. Результаты расчетов сводятся в отчет.
Расширенные атрибуты
ERwin поддерживает не только проектирование сервера БД, но и автоматическую генерацию клиентского приложения в средах разработки MS Visual Basic и Power Builder. Разработка генерации пребывает в том, что на этапе разработкифизической модели данных каждой колонке присваиваются расширенные атрибуты, которые содержат данные о особенностях объектов клиентского приложения (среди них и визуальных), каковые будут отображать данные, хранящуюся в соответствующей колонке. Эта информация записывается в файле модели. На базе информации, содержащейся в расширенных атрибутах, генерируются экранные формы. Полученный код возможно откомпилирован и выполнен без дополнительного ручного кодирования.
Каждой колонке в модели ERwin возможно задать предварительно обрисованные и именованные особенности:
- правила валидации (проверка значений);
- начальные значения, устанавливаемые по умолчанию;
- стиль визуального объекта (к примеру, радиокнопка, поле ввода и др.);
- формат изображения.
Для описания каждого свойства ERwin содержит соответствующие редакторы.
Создание отчетов
Для генерации отчетов в ERwin имеется несложной и действенный инструмент – Report Browser. По умолчанию Report Browser содержит предварительно определенные отчеты, разрешающие наглядно представить данные об главных объектах модели данных – как логической, так и физической. Посредством особого редактора существующие отчеты возможно поменять либо создать личный отчет. Любой отчет возможно настроен лично, данные в нем смогут быть упорядочены и отфильтрованы. Browser Report разрешает сохранять результаты исполнения отчетов, печатать и экспортировать их в распространенные форматы.
Генерация словарей
Для управления громадными проектами ERwin имеет особый инструмент – ERwin Dictionary, что снабжает коллективную работу над диаграммами и разрешает сохранять и документировать разные предположения моделей данных. ERwin Dictionary представляет собой особую БД, которая разрешает урегулировать вопросы документирования и хранения моделей, но не абсолютно отвечает требованиям многопользовательской работы.
Моделирование данных
Одной из главных частей информационного обеспечения есть информационная база. Как было выяснено выше (см. лекцию 9), информационная база (ИБ) является совокупностью данных, организованную определенным методом и хранимую в памяти вычислительной совокупности в виде файлов, благодаря которым удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется посредством моделирования данных. Цель моделирования данных пребывает в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели либо нескольких локальных моделей, каковые довольно легко смогут быть отображены в любую совокупность баз данных. Самый распространенным средством моделирования данных являются диаграммы сущность-связь (ERD). Посредством ERD осуществляется диаграммы и детализация – накопителей, и документируются информационные нюансы бизнес-совокупности, включая идентификацию объектов, ответственных для предметной области ( сущностей ), особенностей этих объектов ( атрибутов ) и их связей с другими объектами (взаимоотношений).
Базисные понятия ERD
Сущность (Entity) — множество экземпляров настоящих либо абстрактных объектов (людей, событий, состояний, идей, предметов и др.), владеющих неспециализированными атрибутами либо чертями. Любой объект совокупности возможно представлен лишь одной сущностью, которая должна быть уникально идентифицирована. Наряду с этим имя сущности должно отражать тип либо класс объекта, а не его конкретный экземпляр (к примеру, АЭРОПОРТ, а не ВНУКОВО).
Любая сущность обязана владеть неповторимым идентификатором. Любой экземпляр сущности обязан конкретно идентифицироваться и различаться от всех других экземпляров данного типа сущности. Любая сущность обязана владеть некоторыми особенностями:
- иметь неповторимое имя; к одному и тому же имени должна в любой момент применяться одинаковая интерпретация; одинаковая интерпретация не имеет возможности использоваться к разным именам, в случае, если лишь они не являются псевдонимами;
- иметь один либо пара атрибутов, каковые или принадлежат сущности, или наследуются через сообщение ;
- иметь один либо пара атрибутов, каковые конкретно идентифицируют любой экземпляр сущности.
Любая сущность может владеть любым числом связей с другими сущностями модели.
Сообщение (Relationship) — поименованная ассоциация между двумя сущностями, значимая для разглядываемой предметной области. Связь — это ассоциация между сущностями, при которой любой экземпляр одной сущностиассоциирован с произвольным (а также нулевым) числом экземпляров второй сущности, и напротив.
Атрибут (направляться) — каждая черта сущности, значимая для разглядываемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной чёрта либо выражения состояния сущности . Атрибут воображает тип черт либо особенностей, ассоциированных с множеством настоящих либо абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная черта отдельного элемента множества. Экземпляратрибута определяется ее значением и типом характеристики, именуемым значениематрибута. На диаграмме сущность-связь атрибуты ассоциируются с конкретными сущностями. Так, экземпляр сущности обязан владеть единственным определенным значением для ассоциированного атрибута.
Способ IDEFI
Самый распространенными способами для построения ERD-диаграмм являются способ Баркера и способ IDEFI.
Способ Баркера основан на нотации, предложенной автором, и употребляется в case-средстве Oracle Designer.
Способ IDEFI основан на подходе Чена и разрешает выстроить модель данных, эквивалентную реляционной модели в третьей обычной форме. На базе совершенствования способа IDEFI создана его новая версия — способ IDEFIX, созданный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы употребляются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).
В способе IDEFIX сущность есть свободной от идентификаторов либо легко свободной, в случае, если любой экземпляр сущности возможно конкретно идентифицирован без определения его взаимоотношений с другими сущностями.Сущность именуется зависимой от идентификаторов либо легко зависимой, в случае, если однозначная идентификация экземпляра сущности зависит от его отношения к второй сущности (рис. 10.1, 10.2).