Проектирование логической и физической модели — КиберПедия 

История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...

Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...

Проектирование логической и физической модели

2017-11-17 1182
Проектирование логической и физической модели 0.00 из 5.00 0 оценок
Заказать работу

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

Инструментальноесредство Erwin позволяет создавать ER-модели для описания объектов и связей между ними.

Erwin имеет два уровня моделирования: логический и физический. На логическом уровне данные представляются так, как они выглядят в реальном мире. Объектами логического уровня являются сущности и атрибуты.

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

Исходными сведениями об объектах моделирования являются хранилища данных, полученные на предыдущем этапе проектирования диаграмм потоков данных [2].

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

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


2.5.1 Создание логической модели данных

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

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

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

После определения сущностей, связей между сущностями и атрибутов сущностей можно спроектировать локальные концептуальные модели [2].

Все локальные модели должны удовлетворять следующим условиям:

- первой нормальной форме (сущность находится в 1НФ тогда и только тогда, когда все атрибуты содержат атомарные значения; среди атрибутов не должно встречаться повторяющихся групп, т.е. нескольких значений для каждого атрибута);

- второй нормальной форме (сущность находится во 2НФ, если она находится в 1НФ и каждый неключевой атрибут полностью зависит от ПК (не должно быть зависимости от части ключа); 2НФ имеет смысл только для сущностей, имеющих сложный ПК);

- третьей нормальной форме (сущность находится в ЗНФ, если она находится во 2НФ и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимосвязи между неключевыми атрибутами)).

Логическая модель должна правильно отражать представление о реальной деловой обстановке, которое имеет пользователь, для которого эта модель разрабатывается.

Проанализируем разработанныеDFD-диаграммы и построим логическую модель.

На основании разработанных DFD-диаграмм были выявлены следующие сущности («хранилища»):

1. Воспитанники.

2. Работники.

3. Должности.

4. Группы.

5. Занятия.

6. Нагрузка работников.

Следующий шаг – определение отношений между сущностями (рис. 9-11).

Рис.9 - Локальная логическая модель «Организовать учет воспитанников»

Рис.10 - Локальная логическая модель «Организоватькадровый учет, управление персоналом»

Рис. 11 - Локальная логическая модель «Подготовить отчет»

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

1. Слияние сущностей с одинаковыми именами и одинаковыми первичными ключами.

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

Сущность «Занятия» содержится в двух локальных логических моделях. Они имеют одинаковые имена и совпадающие первичные ключи. Все атрибуты в обеих сущностях являются общими. Следовательно, при объединении данная сущность будет включать в себя все атрибуты, которые присутствовали в каждой из сущностей. Точно так же объединяются другие сущности из рассматриваемых локальных моделей с одинаковыми именами и одинаковыми первичными ключами.

Включение сущностей, уникальных для каждого локального представления.

2.Слияние общих связей из отдельных локальных моделей.

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

3.Включение связей, уникальных для каждого локального представления.

Все связи включаются в глобальную модель без каких-либо изменений.

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

Рис. 12 - Глобальная логическая модель данных

2.5.2 Создание физической модели данных

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

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

Так как логическая модель данных уже была создана, то для просмотра физической модели можно воспользоваться списком выбора, расположенным в правой части панели инструментов ERwin (вместо Logical выбрать Phisical).

Построение физической модели на основе логической предполагает ряд действий:

1.Задание правил валидации и значений по умолчанию для значений колонок таблиц.

2.Распределение атрибутов по ключевым группам, то есть определение, наряду с первичным ключом, альтернативных ключей и инверсных входов.

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

1.Создание генераторов, триггеров и хранимых процедур. Тексты созданных в проекте триггеров и процедур можно просмотреть в меню TriggerEditor и TableEditor \ StoredProcedure соответственно.

2.Существуют также триггеры ссылочной целостности для поддержания целостности между двумя связанными таблицами. Если в данной таблице выполняется вставка (Insert), изменение (Update) или удаление (Delete), то триггер ссылочной целостности сообщает СУБД, что нужно делать с теми строками у других таблиц, у которых значения внешнего ключа совпадают со значениями первичного ключа вставляемой, изменяемой или удаляемой строки.

ERwin автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграмму. Режимы RI, присваиваемые ERwin по умолчанию, могут быть изменены в редактореReferentIntegrityDefaultкоторый вызывается, если щелкнуть по кнопке RI Defaults диалога TargetServer.

Определение доменов для всех атрибутов логической модели, или создание собственных доменов, создать который можно в подменю Edit\DomainDictionary.

Определим правила ссылочной целостности между связанными таблицами. Связи между сущностями моделируются посредством помещения в дочернюю сущность копии первичного ключа родительской сущности. Понятие ссылочной целостности означает, что если внешний ключ дочерней таблицы содержит некоторое значение, то это значение должно ссылаться на существующее и корректное значение ключа в родительской таблице.

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

Правила ссылочной целостности – это логические конструкции, которые выражают бизнес-правила использования данных. Они определяют, какие действия должна выполнить СУБД при удалении, вставке или изменении строки таблицы (экземпляра сущности). Заданные таким образом действия используются впоследствии при автоматической генерации триггеров, поддерживающих целостность данных [2].

Существуют следующие виды действий или правил, определяемых в логической модели:

- RESTRICT – запрет удаления, вставки или изменения экземпляра сущности.

- CASCADE – при удалении экземпляра родительской сущности удаление всех экземпляров дочерней сущности, ссылающихся на удаляемый родительский экземпляр.

- SET NULL – при удалении экземпляра родительской сущности атрибутам внешнего ключа всех экземпляров дочерней сущности присваивается значение NULL.

- SET DEFAULT – то же самое, что и в предыдущем случае, только вместо значения NULL присваивается значение по умолчанию.

- NONE – никаких действий не предпринимается.

Эти правила задаются на вставку, удаление и изменение экземпляра как родительской, так и дочерней сущности. Таким образом, каждая связь должна обладать набором из шести правил, которые вводятся в поля, объединенные общим заголовком «RI Actions». При добавлении связи в диаграмму Erwin по умолчанию устанавливает для нее набор правил, которые можно редактировать.

Завершающим этапом подготовки логической модели является проведение нормализации данных. Erwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных:

- Erwin отмечает повторное использование имени сущности и атрибута;

- запрещает присвоение неуникальных имен атрибутов внутри одной модели (при соответствующей установке опции UniqueName), соблюдая правило «в одном месте – один факт». При создании физической модели необходимо задать название сущностей и их атрибутов только латинскими буквами, так как иначе при последующей передаче в базу данных возможно возникновение ошибок. Поэтому все сущности логической модели при переходе на физическую модель были переименованы.

Физическая модель данных представлена на рис. 13.

Рис. 13 - Физическая модель данных

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

Выводы по второму разделу

В данном разделе были созданы и описаны бизнес-процессы, которые протекают на предприятии.

В результате проектирования была разработана функциональная модель IDEF0. Она описываетбизнес-процессы, которые формируют значимый для потребителя результат, представляют ценность. Для построения такой модели были собраны необходимые данные об объекте, определены его границ; определены цели и точки зрения модели. В результате была спроектирована контекстная диаграмма и ее декомпозиция.

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

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

 

 


 


Поделиться с друзьями:

Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...

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

Индивидуальные и групповые автопоилки: для животных. Схемы и конструкции...

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰)...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.026 с.