Анализ процесса даталогического моделирования и автоматизированные системы ее реализации
Введение 3
1.Теоретическая часть 4
1.1.Построение даталогических моделей 4
1.2.Исходные данные для даталогического проектирования 5
1.3.CASE.средства 5
1.4.CASE.средство Erwin 7
1.5.Создание модели данных с помощью ERwin 7
1.5.1.Создание логической модели данных 7
1.6.Сущности и атрибуты 8
1.7.CASE.средство фирмы ORACLE. DESIGNER/2000 10
1.8. Проблемы проектирования 13
1.8.1. Ограничение целостности модели данных 15
1.9. Подход к даталогическому моделированию 15
1.9.1. Особенности даталогических моделей 16
1.9.2. Особенности проектирования 17
1.10. Способы выделения подклассов. 18
1.10.1. Определение состава базы данных 19
1.10.2. Введение искусственных идентификаторов. 19
1.11. Результат даталогического проектирования 20
2.Аналитическая часть. 21
Заключение 24
Список литературы 25
Приложение 26
1.Теоретическая часть 4
1.1.Построение даталогических моделей 4
1.2.Исходные данные для даталогического проектирования 5
1.3.CASE.средства 5
1.4.CASE.средство Erwin 7
1.5.Создание модели данных с помощью ERwin 7
1.5.1.Создание логической модели данных 7
1.6.Сущности и атрибуты 8
1.7.CASE.средство фирмы ORACLE. DESIGNER/2000 10
1.8. Проблемы проектирования 13
1.8.1. Ограничение целостности модели данных 15
1.9. Подход к даталогическому моделированию 15
1.9.1. Особенности даталогических моделей 16
1.9.2. Особенности проектирования 17
1.10. Способы выделения подклассов. 18
1.10.1. Определение состава базы данных 19
1.10.2. Введение искусственных идентификаторов. 19
1.11. Результат даталогического проектирования 20
2.Аналитическая часть. 21
Заключение 24
Список литературы 25
Приложение 26
Целью моей курсовой работы является анализ процесса даталогического моделирования основанный на использовании CASE-технологии.
Несмотря на высокие потенциальные возможности CASE-технологии (увеличение производительности труда, улучшение качества программных продуктов, поддержка унифицированного и согласованного стиля работы) далеко не все разработчики информационных систем, использующие CASE-средства, достигают ожидаемых результатов.
Существуют различные причины возможных неудач, но, видимо, основной причиной является неадекватное понимание сути программирования информационных систем и применения CASE-средств. Всегда следует быть готовым к новым трудностям, связанным с освоением новой технологии.
В связи с поставленной целью в курсовой работе решаются следующие задачи:
рассматриваются проблемы процесса даталогического моделирования
проводится анализ схемы данных
приводится сравнение и выявляются проблемы даталогического проектирования
Тема является актуальной так как, для повышения качества, надежности и производительности компьютерных технологий способствовало появление программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
В теоретической части описываются основные понятия в даталогическом моделировании.
В основной части изложены проблемы процесса даталогического моделирования.
В аналитической дан анализ схемы данных.
Несмотря на высокие потенциальные возможности CASE-технологии (увеличение производительности труда, улучшение качества программных продуктов, поддержка унифицированного и согласованного стиля работы) далеко не все разработчики информационных систем, использующие CASE-средства, достигают ожидаемых результатов.
Существуют различные причины возможных неудач, но, видимо, основной причиной является неадекватное понимание сути программирования информационных систем и применения CASE-средств. Всегда следует быть готовым к новым трудностям, связанным с освоением новой технологии.
В связи с поставленной целью в курсовой работе решаются следующие задачи:
рассматриваются проблемы процесса даталогического моделирования
проводится анализ схемы данных
приводится сравнение и выявляются проблемы даталогического проектирования
Тема является актуальной так как, для повышения качества, надежности и производительности компьютерных технологий способствовало появление программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
В теоретической части описываются основные понятия в даталогическом моделировании.
В основной части изложены проблемы процесса даталогического моделирования.
В аналитической дан анализ схемы данных.
1. Диго С.М. Проектирование баз данных (учебник).- М.: Финансы и статистика,1988.
2. Диго С.М. Проектирование и использование баз данных. Учебник. - М.: Финансы и статистика, 1995.
3. Неверова Е.Г. Технология проектирования баз данных и знаний: Учебное пособие. – Алматы:Ин-т развития Каз-на, 2000.
2. Диго С.М. Проектирование и использование баз данных. Учебник. - М.: Финансы и статистика, 1995.
3. Неверова Е.Г. Технология проектирования баз данных и знаний: Учебное пособие. – Алматы:Ин-т развития Каз-на, 2000.
Дисциплина: Автоматизация, Техника
Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 30 страниц
В избранное:
Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 30 страниц
В избранное:
МИНИСТЕРСТВО ОБРАЗОВАНИЯ
И НАУКИ РЕСПУБЛИКИ КАЗАХСТАН
КАЗАХСКИЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ
им. Т. Рыскулова
Кафедра Прикладная информатика
Курсовая работа
по дисциплине “Системы баз данных”
на тему Анализ процесса даталогического моделирования и
автоматизированные системы ее реализации
Выполнил:
Студентка 3 курса
306 группы, специальности ИС
Асылбек Гулим
Проверил: Неверова Е.Г.
Алматы, 2008
Содержание
Введение 3
1.Теоретическая часть 4
1.1.Построение даталогических моделей 4
1.2.Исходные данные для даталогического проектирования 5
1.3.CASE-средства 5
1.4.CASE-средство Erwin 7
1.5.Создание модели данных с помощью ERwin 7
1.5.1.Создание логической модели данных 7
1.6.Сущности и атрибуты 8
1.7.CASE-средство фирмы ORACLE. DESIGNER2000 10
1.8. Проблемы проектирования 13
1.8.1. Ограничение целостности модели данных 15
1.9. Подход к даталогическому моделированию 15
1.9.1. Особенности даталогических моделей 16
1.9.2. Особенности проектирования 17
1.10. Способы выделения подклассов. 18
1.10.1. Определение состава базы данных 19
1.10.2. Введение искусственных идентификаторов. 19
1.11. Результат даталогического проектирования 20
2.Аналитическая часть. 21
Заключение 24
Список литературы 25
Приложение 26
Введение
Целью моей курсовой работы является анализ процесса даталогического
моделирования основанный на использовании CASE-технологии.
Несмотря на высокие потенциальные возможности CASE-технологии
(увеличение производительности труда, улучшение качества программных
продуктов, поддержка унифицированного и согласованного стиля работы) далеко
не все разработчики информационных систем, использующие CASE-средства,
достигают ожидаемых результатов.
Существуют различные причины возможных неудач, но, видимо, основной
причиной является неадекватное понимание сути программирования
информационных систем и применения CASE-средств. Всегда следует быть
готовым к новым трудностям, связанным с освоением новой технологии.
В связи с поставленной целью в курсовой работе решаются следующие
задачи:
✓ рассматриваются проблемы процесса даталогического
моделирования
✓ проводится анализ схемы данных
✓ приводится сравнение и выявляются проблемы даталогического
проектирования
Тема является актуальной так как, для повышения качества, надежности и
производительности компьютерных технологий способствовало появление
программно-технологических средств специального класса - CASE-средств,
реализующих CASE-технологию создания и сопровождения ИС. Термин CASE
(Computer Aided Software Engineering) используется в настоящее время в
весьма широком смысле. Первоначальное значение термина CASE, ограниченное
вопросами автоматизации разработки только лишь программного обеспечения
(ПО), в настоящее время приобрело новый смысл, охватывающий процесс
разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются
программные средства, поддерживающие процессы создания и сопровождения ИС,
включая анализ и формулировку требований, проектирование прикладного ПО
(приложений) и баз данных, генерацию кода, тестирование, документирование,
обеспечение качества, конфигурационное управление и управление проектом, а
также другие процессы. CASE-средства вместе с системным ПО и техническими
средствами образуют полную среду разработки ИС.
В теоретической части описываются основные понятия в даталогическом
моделировании.
В основной части изложены проблемы процесса даталогического
моделирования.
В аналитической дан анализ схемы данных.
1.Теоретическая часть
1.1.Построение даталогических моделей
Глобальная даталогическая модель представляет собой отражение общего
содержания баз данных, структурированное на логическом уровне и
ориентированное на конкретную СУБД. Любая СУБД оперирует с допустимыми для
нее типами логических структур данных, которые представляют собой базисный
набор типов структур. Даталогические модели различаются наименованиями
используемых информационных единиц, правилами композиции структур более
высокого уровня из составляющих их структур младшего уровня, возможностями
просмотра модели. Кроме того, СУБД накладывает количественные ограничения
на логическую структуру базы данных. Все это оказывает влияние на
проектирование даталогических моделей. Поэтому, прежде чем приступить к
построению даталогической модели, необходимо детально изучить особенности
СУБД, уточнить ограничения, определить факторы, влияющие на выбор
логических структур данных, ознакомиться с существующими методиками
проектирования. Если для данной СУБД имеется система автоматизации
проектирования БД, то с целью оценки качества проекта и целенаправленного
воздействия на создаваемую структуру базы данных желательно знать алгоритм
проектирования, положенный в ее основу.
При проектировании даталогической модели используется графическая
(диаграмма логической структуры) и аналитическая (описание на ЯОД схемы)
формы ее представления. При ручном проектировании построение даталогической
модели начинают с графического представления структуры базы данных, так как
оно обладает большей наглядностью. При автоматизированном проектировании,
наоборот, обычно сначала получается аналитическое представление структуры,
а затем по нему для удобства пользователей воссоздается графическое
представление.
Графическое представление структуры БД. Диаграммы логической структуры
БД должны быть наглядными, легко читаемыми, не допускать неоднозначного их
толкования; они должны нести полную информацию о логической структуре БД,
давать возможность различать все типы элементов данных и структур,
допустимых в данной системе, обеспечивать взаимно однозначное соответствие
между ними и описанием на ЯОД. Направление связей между элементами
структуры надо указывать на диаграмме только в случае, если оно не
определено однозначно типом модели. Все элементы даталогической модели,
которые должны быть поименованы при описании на ЯОД, должны быть
поименованы и при графическом изображении структуры БД.
Для реляционных систем не принято давать графическую интерпретацию
структуры БД, это вызвано тем, что до последнего времени не было крупных
реализаций реляционных банков данных, для которых трудно было бы
проанализировать их структуру, не пользуясь графической интерпретацией. Но
можно считать, что в реляционных моделях отношения связаны между собой
символическими связями. При большом числе отношений отследить все
потенциально имеющиеся связи не просто, и здесь может помочь диаграмма
структуры БД.
1.2.Исходные данные для даталогического проектирования
Даталогическое проектирование является проектированием логической
структуры базы данных, но на него оказывают влияние возможности физической
организации данных, предоставляемые конкретной СУБД. Поэтому знание
особенностей физической организации данных является полезным при
проектировании логической структуры.
Логическая структура базы данных, а также сама заполненная данными
база данных являются отображением реальной предметной области. Поэтому на
выбор проектных решений самое непосредственное влияние оказывает специфика
отображаемой предметной области, отраженная в инфологической модели.
1.3.CASE-средства
Тенденции развития современных информационных технологий приводят к
постоянному возрастанию сложности информационных систем (ИС), создаваемых в
различных областях экономики. Современные крупные проекты ИС
характеризуются, как правило, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов,
элементов данных и сложные взаимосвязи между ними), требующая тщательного
моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем),
имеющих свои локальные задачи и цели функционирования (например,
традиционных приложений, связанных с обработкой транзакций и решением
регламентных задач, и приложений аналитической обработки (поддержки
принятия решений), использующих нерегламентированные запросы к данным
большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования каких-
либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню
квалификации и сложившимся традициям использования тех или иных
инструментальных средств;
существенная временная протяженность проекта, обусловленная, с одной
стороны, ограниченными возможностями коллектива разработчиков, и, с другой
стороны, масштабами организации-заказчика и различной степенью готовности
отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть
прежде всего адекватно описан, должны быть построены полные и
непротиворечивые функциональные и информационные модели ИС.
В 70-х и 80-х годах при разработке ИС достаточно широко применялась
структурная методология, предоставляющая в распоряжение разработчиков
строгие формализованные методы описания ИС и принимаемых технических
решений. Она основана на наглядной графической технике: для описания
различного рода моделей используются схемы и диаграммы. Наглядность и
строгость средств структурного анализа позволяла разработчикам и будущим
пользователям системы с самого начала неформально участвовать в ее
создании, обсуждать и закреплять понимание основных технических решений.
Появлению CASE-технологии и CASE-средств предшествовали исследования в
области методологии программирования. Программирование обрело черты
системного подхода с разработкой и внедрением языков высокого уровня,
методов структурного и модульного программирования, языков проектирования и
средств их поддержки, формальных и неформальных языков описаний системных
требований и спецификаций и т.д.
CASE-технология представляет собой методологию проектирования ИС, а также
набор инструментальных средств, позволяющих в наглядной форме моделировать
предметную область, анализировать эту модель на всех этапах разработки и
сопровождения ИС и разрабатывать приложения в соответствии с
информационными потребностями пользователей.
CASE-технология в настоящее время попала в разряд наиболее стабильных
информационных технологий.
1.4.CASE-средство Erwin
Рассматриваемое CASE-средство ERwin было разработано фирмой Logic Works.
После слияния в 1998 году Logic Works с PLATINUM technology оно выпускается
под логотипом PLATINUM technology.
На основе существующих БД с помощью ERwin возможно восстановление моделей
(обратное проектирование), которые в процессе анализа пригодности их для
новой системы могут объединяться с типовыми моделями из библиотек моделей.
Клиентское приложение ERwin реализовывает доступ к хранилищу моделей
через API, что позволяет постоянно наращивать возможности интегрированной
среды путем включения новых инструментов моделирования и анализа.
Модуль ERwin Translation Wizard (PLATINUM technology) позволяет
перегружать объектную модель в модель данных ERwin (и обратно) и, с помощью
ERwin, сгенерировать схему БД на любой из поддерживаемых в ERwin СУБД.
1.5.Создание модели данных с помощью ERwin
ERwin имеет два уровня представления модели - логический и физический.
Логический уровень - это абстрактный взгляд на данные, на нем данные
представляются так, как выглядят в реальном мире, и могут называться так,
как они называются в реальном мире, например "Постоянный клиент", "Отдел"
или "Фамилия сотрудника". Объекты модели, представляемые на логическом
уровне, называются сущностями и атрибутами. Логическая модель данных может
быть построена на основе другой логической модели, например на основе
модели процессов. Логическая модель данных является универсальной и никак
не связана с конкретной реализацией СУБД.
1.5.1.Создание логической модели данных
Различают три уровня логической модели, отличающихся по глубине
представления информации о данных:
o диаграмма сущность-связь (Entity Relationship Diagram, ERD);
o модель данных, основанная на ключах (Key Based model, KB);
o полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных верхнего уровня.
Она включает сущности и взаимосвязи, отражающие основные бизнес-правила
предметной области. Такая диаграмма не слишком детализирована, в нее
включаются основные сущности и связи между ними, которые удовлетворяют
основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может
включать связи многие-ко-многим и не включать описание ключей. Как правило,
ERD используется для презентаций и обсуждения структуры данных с экспертами
предметной области.
Модель данных, основанная на ключах, - более подробное представление
данных. Она включает описание всех сущностей и первичных ключей и
предназначена для представления структуры данных и ключей, которые
соответствуют предметной области.
Полная атрибутивная модель - наиболее детальное представление структуры
данных: представляет данные в третьей нормальной форме и включает все
сущности, атрибуты и связи.
1.6.Сущности и атрибуты
Основные компоненты диаграммы Erwin - это сущности, атрибуты и связи.
Каждая сущность является множеством подобных индивидуальных объектов,
называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться
от всех остальных экземпляров. Атрибут выражает определенное свойство
объекта. С точки зрения БД (физическая модель) сущности соответствует
таблица, экземпляру сущности - строка в таблице, а атрибуту -колонка
таблицы.
Построение модели данных предполагает определение сущностей и
атрибутов, т. е. необходимо определить, какая информация будет храниться в
конкретной сущности или атрибуте. Сущность можно определить как объект,
событие или концепцию, информация о которых должна сохраняться. Сущности
должны иметь наименование с четким смысловым значением, именоваться
существительным в единственном числе, не носить "технических" наименований
и быть достаточно важными для того, чтобы их моделировать. Именование
сущности в единственном числе облегчает в дальнейшем чтение модели.
Фактически имя сущности дается по имени ее экземпляра. Примером может быть
сущность Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия
заказчика и Адрес заказчика. На уровне физической модели ей может
соответствовать таблица Customer с колонками Customer_number, Customer_name
и Customer_address.
Для внесения сущности в модель необходимо (убедившись предварительно,
что вы находитесь на уровне логической модели - переключателем между
логической и физической моделью служит раскрывающийся список в правой части
панели инструментов) "кликнуть" по кнопке сущности на панели инструментов
(ERwin Toolbox) , затем "кликнуть" по тому месту на диаграмме, где
необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по
сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать
диалог Entity Editor, в котором определяются имя, описание и комментарии
сущности .
Каждая сущность должна быть полностью определена с помощью текстового
описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User
Defined Properties - Свойства, определенные пользователем) служат для
внесения дополнительных комментариев и определений к сущности. Закладка
Definition используется для ввода определения сущности. Эти определения
полезны как на логическом уровне, поскольку позволяют понять, что это за
объект, так и на физическом уровне, поскольку их можно экспортировать как
часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name).
Закладка Note позволяет добавлять дополнительные замечания о сущности,
которые не были отражены в определении, введенном в закладке Definition.
Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-
правило или соглашение по организации диаграммы.
В закладке Note 2 можно задокументировать некоторые возможные запросы,
которые, как ожидается, будут использоваться по отношению к сущности в БД.
При переходе к физическому проектированию, записанные запросы помогут
принимать такие решения в отношении проектирования, которые сделают БД
более эффективной.
Закладка Note 3 позволяет вводить примеры данных для сущности (в
произвольной форме).
В закладке Icon каждой сущности можно поставить в соответствие
изображение, которое будет отображаться в режиме просмотра модели на уровне
иконок. В этой закладке можно задать как большую иконку, которая будет
отображаться на уровне Icon, так и малую иконку, которая будет отображаться
на всех уровнях просмотра модели. Для связывания изображения с сущностью
необходимо щелкнуть по кнопке, в появившемся диалоге ERwin Icon Editor
щелкнуть по кнопке Import и выбрать соответствующий файл формата bmp. После
выбора иконки она отображается в закладке Icon диалога Entity Editor . Для
определения UDP служит диалог User-Defined Property Editor (вызывается из
меню EditUDPs). В нем необходимо указать вид объекта, для которого
заводится UDP (диаграмма в целом, сущность, атрибут и т. д.) и тип данных.
Для внесения нового свойства следует щелкнуть в таблице по кнопке “+”, и
внести имя, тип данных, значение по умолчанию и определение.
Физическая модель данных, напротив, зависит от конкретной СУБД,
фактически являясь отображением системного каталога. В физической модели
содержится информация о всех объектах БД. Поскольку стандартов на объекты
БД не существует (например, нет стандарта на типы данных), физическая
модель зависит от конкретной реализации СУБД. Следовательно, одной и той же
логической модели могут соответствовать несколько разных физических
моделей. Если в логической модели не имеет значения, какой конкретно тип
данных имеет атрибут, то в физической модели важно описать всю информацию о
конкретных физических объектах - таблицах, колонках, индексах, процедурах и
т. д. Разделение модели данных на логические и физические позволяет решить
несколько важных задач.
Для создания моделей данных в ERwin можно использовать две нотации:
IDEF1X и IE (Information Engineering). Методология IDEF1X была разработана
для армии США и широко используется в государственных учреждениях США,
финансовых и промышленных корпорациях. Методология IE, разработанная
Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами,
используется преимущественно в промышленности. Переключение между нотациями
можно сделать в закладке Methodology диалога Preferences (меню
OptionPreferences). В дальнейшем будет использоваться нотация IDEF1X.
ERwin имеет несколько уровней отображения диаграммы: уровень
сущностей, уровень атрибутов, уровень определений, уровень первичных ключей
и уровень иконок. Переключиться между первыми тремя уровнями можно с
использованием кнопок панели инструментов. Переключиться на другие уровни
отображения можно при помощи контекстного меню, которое появляется, если
"кликнуть" по любому месту диаграммы, не занятому объектами модели. В
контекстном меню следует выбрать пункт Display Level и затем необходимый
уровень отображения. ERwin позволяет связать с сущностью большую и малую
иконки. При переключении на уровень иконок показывается большая иконка. Для
отображения малой иконки следует выбрать в контекстном меню пункт Display
OptionsEntities и в каскадном меню включить опцию Entity Icon. Малая
иконка будет показана слева от имени сущности на всех .уровнях отображения
модели. В табл. 2 2 показаны уровни отображения модели.
1.7.CASE-средство фирмы ORACLE. DESIGNER2000
Первая версия CASE-инструментария фирмы ORACLE, ORACLE*CASE появилась
в 1989 году с ориентацией на символьный режим для конечного пользователя.
Существенные изменения потребовались в следующей версии, ORACLE*CASE 5.1
(1993г.), в связи с реализацией нового сервера и перехода к графическому
интерфейсу конечного пользователя. В настоящее время завершена работа по
выпуску в промышленную эксплуатацию новой CASE-среды под названием
DESIGNER2000, работающей в среде MS WINDOWS. Этот продукт вместе со
средствами разработки DEVELOPER2000 реализуют новый подход фирмы ORACLE к
общей среде создания и сопровождения прикладных систем.
В CASE-методологии фирмы ORACLE используется некоторый специальный вид
модели Чена (Чен в 1976 году ввел модель "сущность-связь"), близкий к
бинарной ER-модели. В этом случае взаимосвязи могут быть определены только
между двумя сущностями. Для наглядного представления общей структуры
предметной области все такие спецификации изображаются в графическом виде -
в виде ER-диаграммы. На этой диаграмме объекты изображаются
прямоугольниками, а связи - линиями, соединяющими соответствующие
прямоугольники. Задание типа связи ("один к одному", "многие к одному" и
т.д.) означает введение некоторого семантического ограничения. На диаграмме
для каждого типа взаимосвязи используется свое графическое изображение:
если любой экземпляр сущности A может быть связан с несколькими
экземплярами сущности B, то со стороны прямоугольника-сущности A линия,
выражающая взаимосвязь, дополняется специальным символом . Кроме того, для
связи можно указать, является ли она обязательной для входящих в нее
сущностей. Если любой экземпляр сущности A обязательно должен быть связан с
каким-либо экземпляром сущности B, то прилегающая к прямоугольнику "A"
половина линии - сплошная, в противном случае она - пунктирная.
Функциональные аспекты предметной области описываются с помощью
диаграмм иерархии функций и потоков данных. Эти диаграммы отражают
деятельность существующих организационных структур, технологические
особенности процессов переработки информации и строятся по методологии
проектирования "сверху вниз". Начиная с самой общей функции, описывающей
деятельность всей организации в целом, аналитик последовательно разбивает
это описание на более детальные функции, в совокупности составляющие
исходную; в дальнейшем этот процесс продолжается применительно к новым,
полученным на предыдущем уровне функциям. Такая декомпозиция функций
завершается, когда функции, полученные на самом нижнем уровне иерархии, не
поддаются дальнейшему разложению, т.е. являются элементарными. Для них
специфицируется, с какими объектами они работают, какие типы действий при
этом производятся (создание, удаление, модификация) как на уровне объектов,
так и на уровне отдельных их параметров. Кроме этого, могут быть описаны
события, вызывающие выполнение той или иной функции.
Кроме собственно изображения диаграммы каждый из редакторов позволяет
вводить дополнительную уточняющую информацию об отдельных элементах
диаграммы. Например, для любой сущности, представленной на ER-диаграмме
прямоугольником с названием, можно вызвать специальное окно для задания
всевозможных характеристик этой сущности, включая атрибуты, первичные
ключи, уникальные идентификаторы, ограничения или правила проверки для
значений атрибутов, частотные характеристики и т.д. Аналогично, для любой
взаимосвязи можно специфицировать, является ли она идентифицирующей (входит
в состав какого-либо уникального идентификатора), переносимой ( можно
динамически переопределять для любого экземпляра сущности типа "деталь",
какому экземпляру "мастера" он подчиняется) и т.д.
Дополнительно повышает наглядность и выразительность концептуальных
моделей широкие возможности использования цвета и различных шрифтов для
обозначения названий отдельных элементов.
Для одного и того же приложения предусматривается возможность
построения нескольких ER- диаграмм и нескольких иерархий функций: это может
быть полезно для сложных задач с огромным количеством объектов и связей. В
этом случае естественно декомпозировать общую задачу и для каждой части
рисовать свою ER-диаграмму.
Кроме средств ввода данных и построения графических изображений каждый
редактор предоставляет возможность выполнять различные семантические
проверки построенных диаграмм на полноту и корректность, а также
генерировать разнообразные отчеты для документирования концептуального
уровня разработки.
Проектирование. На этапе проектирования формируются все спецификации,
описывающие структуру и основные компоненты будущей системы. Как и на
предыдущем уровне эти спецификации разделяются на информационные и
функциональные - на описание базы данных и описание состава программных
модулей системы.
При описании базы данных указывается, какие таблицы в нее входят,
специфицируются основные характеристики этих таблиц, состав столбцов каждой
из них, уточняются параметры столбцов (тип значений, ограничения на
допустимые значения, значения, принятые по умолчанию, статистические
характеристики использования и многие другие), задаются ограничения
целостности - логические условия, которые должны выполняться при любом
содержании таблиц. Кроме того, описываются дополнительные объекты базы
данных ORACLE, такие как индексы, кластеры, последовательности, основное
назначение которых связано с повышением эффективности работы с базой
данных, ускорением доступа к часто используемой информации.
Использование на этом уровне графических моделей - диаграмм, является
важной новой особенностью CASE-средств фирмы ORACLE. В предыдущих версиях,
как и в CASE- системе Erwin , графические диаграммы используются обычно
только на концептуальном уровне для ER-моделей, функциональных иерархий и
т.д. В то же время, опыт практической деятельности в области CASE-
технологий показывает, что использование графических изображений полезно и
для представления структуры базы данных, схем взаимодействия программных
модулей.
В DESIGNER2000 для этой цели предусмотрены:
редактор схем баз данных
редактор диаграмм взаимосвязей между модулями
Особенности DESIGNER2000. Генераторы приложений
Входящие в состав DESIGNER2000 генераторы разбиваются на две группы:
генератор сервера
генераторы клиентской части
Генератор серверной части автоматически строит по спецификациям базы
данных тексты программ на языке SQL, используя все средства определения баз
данных, включая триггеры, хранимые процедуры и т.д.
Генераторы клиентской части обеспечивают автоматическое формирование
текстов программных модулей по их спецификациям, записанным в репозитарии.
Все модули приложения классифицируются по типам, основными из которых
являются экранные формы, отчеты, процедуры. Для каждого типа имеется свой
генератор, результатом работы которого является программа, написанная на
языке, соответствующем этому типу: генератор форм создает приложения для
ORACLEForms, генератор отчетов позволяет получать процедуры на PLSQL либо
приложения для ORACLEReport.
Исходной информацией для работы любого генератора служат спецификации
таблиц базы данных и спецификации модулей. В спецификации модуля
указываются такие его параметры, как наименование, тип, некоторые
характеристики внешнего представления (заголовки, параметры). Кроме того,
перечисляются используемые таблицы базы данных и для каждой из них
специфицируется, какие операции к ней могут применяться (выборка, ввод
записей, корректировка, удаление), какие ее столбцы и каким образом
участвуют в работе модуля. С помощью утилиты автоматической генерации
проекта базы данных по ER-диаграмме будут построены спецификации будущей
базы данных - ее состав таблиц, перечень столбцов каждой из них, уточнение
характеристик столбцов, описание ограничений целостности
1.8. Проблемы проектирования
Несмотря на все потенциальные возможности CASE-средств, существует
множество примеров их неудачного внедрения. В связи с этим необходимо
отметить следующее:
CASE-средства не обязательно дают немедленный эффект; он может быть получен
только спустя какое-то время;
реальные затраты на внедрение CASE-средств обычно намного превышают затраты
на их приобретение;
CASE-средства обеспечивают возможности для получения существенной выгоды
только после успешного завершения процесса их внедрения.
Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-
либо безоговорочные утверждения относительно реального удовлетворения тех
или иных ожиданий от их внедрения. Можно перечислить следующие факторы,
усложняющие определение возможного эффекта от использования CASE-средств:
широкое разнообразие качества и возможностей CASE-средств;
относительно небольшое время использования CASE-средств в различных
организациях и недостаток опыта их применения;
широкое разнообразие в практике внедрения различных организаций;
отсутствие детальных метрик и данных для уже выполненных и текущих
проектов;
широкий диапазон предметных областей проектов;
различная степень интеграции CASE-средств в различных проектах.
Вследствие этих сложностей доступная информация о реальных внедрениях
крайне ограничена и противоречива. Она зависит от типа средств,
характеристик проектов, уровня сопровождения и опыта пользователей.
Пользователи CASE-средств должны быть готовы к необходимости долгосрочных
затрат на эксплуатацию, частому появлению новых версий и возможному
быстрому моральному старению средств, а также постоянным затратам на
обучение и повышение квалификации персонала.
Несмотря на все высказанные предостережения и некоторый пессимизм,
грамотный и разумный подход к использованию CASE-средств может преодолеть
все перечисленные трудности. Успешное внедрение CASE-средств должно
обеспечить такие выгоды как:
высокий уровень технологической поддержки процессов разработки и
сопровождения ПО;
положительное воздействие на некоторые или все из перечисленных факторов:
производительность, качество продукции, соблюдение стандартов,
документирование;
приемлемый уровень отдачи от инвестиций в CASE-средства.
Логического проектирования - объекты предметной области не отображают
в абстрактные объекты модели данных, чтобы это отображение не противоречило
семантики предметной области и было лучшим.
Физического проектирования - не обеспечивает эффект выполнения
запросов к БД, не располагает данные во внешней памяти, требуется создание
дополнительных структур.
Даталогического проектирования
✓ избыточности информации
✓ аномалии при добавлении
✓ аномалии редактирования
✓ аномалии удаления
Избыточность появляется в следующем: активную роль процессе передачи
текста играют только некоторые ключевые слова. Имеет место неоднозначность
выражения.
Аномалиями называются такие ситуации в таблицах БД, которые приводят к
противоречиям в БД или существенно усложняют обработку данных.
Аномалии модификации (редактирования) проявляются в том, что изменение
значения атрибута может повлечь за собой пересмотр всей таблицы с
соответствующим изменением значений этого атрибута в других записях
таблицы.
Аномалии удаления проявляются в том, что при удалении какого-либо значения
атрибута исчезнет другая информация, которая не связана напрямую с
удаляемым значением.
Аномалии добавления проявляются в том, что невозможно добавить запись в
таблицу, пока не будут известны значения всех ее атрибутов, а также в том,
что вставка новой записи потребуют пересмотра всей таблицы.
Для устранения избыточности проводится нормализация которая приводит к
аномалиям обработки данных. Различают не избыточное и избыточное
дублирование данных. Избыточное дублирование приводит к проблемам
обработки кортежей отношения. Способом устранения избыточного дублирования
и нейтрализации аномалий является декомпозиция, то есть разбиение исходного
отношения (таблицы).
1.8.1. Ограничение целостности модели данных
1) целостность по сущностям (не допускается, чтобы какой либо атрибут,
участвовавший в первичном ключе, принимал неопределенное значение)
2) целостность по ссылкам (это такое состояние БД, при котором каждому
значению внешнего ключа подчиненно отношение, соответствующий кортеж (поле)
главного отношения с таким же отношением первичного ключа)
3) определяемая пользователем.
Ссылочная целостность может нарушаться в результате: вставки,
удаления, обновления.
Основные функции: Анализ предметной области, проектирование структуры
данных, задание ограниченной целостности при описании структур БД,
первоначальная загрузка и ведение БД, защита данных от несанкционированного
доступа
Суть даталогического моделирования заключается в разработке такой
структуры данных, которые удовлетворяли бы следующим требованиям:
1) ... продолжение
Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.
И НАУКИ РЕСПУБЛИКИ КАЗАХСТАН
КАЗАХСКИЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ
им. Т. Рыскулова
Кафедра Прикладная информатика
Курсовая работа
по дисциплине “Системы баз данных”
на тему Анализ процесса даталогического моделирования и
автоматизированные системы ее реализации
Выполнил:
Студентка 3 курса
306 группы, специальности ИС
Асылбек Гулим
Проверил: Неверова Е.Г.
Алматы, 2008
Содержание
Введение 3
1.Теоретическая часть 4
1.1.Построение даталогических моделей 4
1.2.Исходные данные для даталогического проектирования 5
1.3.CASE-средства 5
1.4.CASE-средство Erwin 7
1.5.Создание модели данных с помощью ERwin 7
1.5.1.Создание логической модели данных 7
1.6.Сущности и атрибуты 8
1.7.CASE-средство фирмы ORACLE. DESIGNER2000 10
1.8. Проблемы проектирования 13
1.8.1. Ограничение целостности модели данных 15
1.9. Подход к даталогическому моделированию 15
1.9.1. Особенности даталогических моделей 16
1.9.2. Особенности проектирования 17
1.10. Способы выделения подклассов. 18
1.10.1. Определение состава базы данных 19
1.10.2. Введение искусственных идентификаторов. 19
1.11. Результат даталогического проектирования 20
2.Аналитическая часть. 21
Заключение 24
Список литературы 25
Приложение 26
Введение
Целью моей курсовой работы является анализ процесса даталогического
моделирования основанный на использовании CASE-технологии.
Несмотря на высокие потенциальные возможности CASE-технологии
(увеличение производительности труда, улучшение качества программных
продуктов, поддержка унифицированного и согласованного стиля работы) далеко
не все разработчики информационных систем, использующие CASE-средства,
достигают ожидаемых результатов.
Существуют различные причины возможных неудач, но, видимо, основной
причиной является неадекватное понимание сути программирования
информационных систем и применения CASE-средств. Всегда следует быть
готовым к новым трудностям, связанным с освоением новой технологии.
В связи с поставленной целью в курсовой работе решаются следующие
задачи:
✓ рассматриваются проблемы процесса даталогического
моделирования
✓ проводится анализ схемы данных
✓ приводится сравнение и выявляются проблемы даталогического
проектирования
Тема является актуальной так как, для повышения качества, надежности и
производительности компьютерных технологий способствовало появление
программно-технологических средств специального класса - CASE-средств,
реализующих CASE-технологию создания и сопровождения ИС. Термин CASE
(Computer Aided Software Engineering) используется в настоящее время в
весьма широком смысле. Первоначальное значение термина CASE, ограниченное
вопросами автоматизации разработки только лишь программного обеспечения
(ПО), в настоящее время приобрело новый смысл, охватывающий процесс
разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются
программные средства, поддерживающие процессы создания и сопровождения ИС,
включая анализ и формулировку требований, проектирование прикладного ПО
(приложений) и баз данных, генерацию кода, тестирование, документирование,
обеспечение качества, конфигурационное управление и управление проектом, а
также другие процессы. CASE-средства вместе с системным ПО и техническими
средствами образуют полную среду разработки ИС.
В теоретической части описываются основные понятия в даталогическом
моделировании.
В основной части изложены проблемы процесса даталогического
моделирования.
В аналитической дан анализ схемы данных.
1.Теоретическая часть
1.1.Построение даталогических моделей
Глобальная даталогическая модель представляет собой отражение общего
содержания баз данных, структурированное на логическом уровне и
ориентированное на конкретную СУБД. Любая СУБД оперирует с допустимыми для
нее типами логических структур данных, которые представляют собой базисный
набор типов структур. Даталогические модели различаются наименованиями
используемых информационных единиц, правилами композиции структур более
высокого уровня из составляющих их структур младшего уровня, возможностями
просмотра модели. Кроме того, СУБД накладывает количественные ограничения
на логическую структуру базы данных. Все это оказывает влияние на
проектирование даталогических моделей. Поэтому, прежде чем приступить к
построению даталогической модели, необходимо детально изучить особенности
СУБД, уточнить ограничения, определить факторы, влияющие на выбор
логических структур данных, ознакомиться с существующими методиками
проектирования. Если для данной СУБД имеется система автоматизации
проектирования БД, то с целью оценки качества проекта и целенаправленного
воздействия на создаваемую структуру базы данных желательно знать алгоритм
проектирования, положенный в ее основу.
При проектировании даталогической модели используется графическая
(диаграмма логической структуры) и аналитическая (описание на ЯОД схемы)
формы ее представления. При ручном проектировании построение даталогической
модели начинают с графического представления структуры базы данных, так как
оно обладает большей наглядностью. При автоматизированном проектировании,
наоборот, обычно сначала получается аналитическое представление структуры,
а затем по нему для удобства пользователей воссоздается графическое
представление.
Графическое представление структуры БД. Диаграммы логической структуры
БД должны быть наглядными, легко читаемыми, не допускать неоднозначного их
толкования; они должны нести полную информацию о логической структуре БД,
давать возможность различать все типы элементов данных и структур,
допустимых в данной системе, обеспечивать взаимно однозначное соответствие
между ними и описанием на ЯОД. Направление связей между элементами
структуры надо указывать на диаграмме только в случае, если оно не
определено однозначно типом модели. Все элементы даталогической модели,
которые должны быть поименованы при описании на ЯОД, должны быть
поименованы и при графическом изображении структуры БД.
Для реляционных систем не принято давать графическую интерпретацию
структуры БД, это вызвано тем, что до последнего времени не было крупных
реализаций реляционных банков данных, для которых трудно было бы
проанализировать их структуру, не пользуясь графической интерпретацией. Но
можно считать, что в реляционных моделях отношения связаны между собой
символическими связями. При большом числе отношений отследить все
потенциально имеющиеся связи не просто, и здесь может помочь диаграмма
структуры БД.
1.2.Исходные данные для даталогического проектирования
Даталогическое проектирование является проектированием логической
структуры базы данных, но на него оказывают влияние возможности физической
организации данных, предоставляемые конкретной СУБД. Поэтому знание
особенностей физической организации данных является полезным при
проектировании логической структуры.
Логическая структура базы данных, а также сама заполненная данными
база данных являются отображением реальной предметной области. Поэтому на
выбор проектных решений самое непосредственное влияние оказывает специфика
отображаемой предметной области, отраженная в инфологической модели.
1.3.CASE-средства
Тенденции развития современных информационных технологий приводят к
постоянному возрастанию сложности информационных систем (ИС), создаваемых в
различных областях экономики. Современные крупные проекты ИС
характеризуются, как правило, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов,
элементов данных и сложные взаимосвязи между ними), требующая тщательного
моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем),
имеющих свои локальные задачи и цели функционирования (например,
традиционных приложений, связанных с обработкой транзакций и решением
регламентных задач, и приложений аналитической обработки (поддержки
принятия решений), использующих нерегламентированные запросы к данным
большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования каких-
либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню
квалификации и сложившимся традициям использования тех или иных
инструментальных средств;
существенная временная протяженность проекта, обусловленная, с одной
стороны, ограниченными возможностями коллектива разработчиков, и, с другой
стороны, масштабами организации-заказчика и различной степенью готовности
отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть
прежде всего адекватно описан, должны быть построены полные и
непротиворечивые функциональные и информационные модели ИС.
В 70-х и 80-х годах при разработке ИС достаточно широко применялась
структурная методология, предоставляющая в распоряжение разработчиков
строгие формализованные методы описания ИС и принимаемых технических
решений. Она основана на наглядной графической технике: для описания
различного рода моделей используются схемы и диаграммы. Наглядность и
строгость средств структурного анализа позволяла разработчикам и будущим
пользователям системы с самого начала неформально участвовать в ее
создании, обсуждать и закреплять понимание основных технических решений.
Появлению CASE-технологии и CASE-средств предшествовали исследования в
области методологии программирования. Программирование обрело черты
системного подхода с разработкой и внедрением языков высокого уровня,
методов структурного и модульного программирования, языков проектирования и
средств их поддержки, формальных и неформальных языков описаний системных
требований и спецификаций и т.д.
CASE-технология представляет собой методологию проектирования ИС, а также
набор инструментальных средств, позволяющих в наглядной форме моделировать
предметную область, анализировать эту модель на всех этапах разработки и
сопровождения ИС и разрабатывать приложения в соответствии с
информационными потребностями пользователей.
CASE-технология в настоящее время попала в разряд наиболее стабильных
информационных технологий.
1.4.CASE-средство Erwin
Рассматриваемое CASE-средство ERwin было разработано фирмой Logic Works.
После слияния в 1998 году Logic Works с PLATINUM technology оно выпускается
под логотипом PLATINUM technology.
На основе существующих БД с помощью ERwin возможно восстановление моделей
(обратное проектирование), которые в процессе анализа пригодности их для
новой системы могут объединяться с типовыми моделями из библиотек моделей.
Клиентское приложение ERwin реализовывает доступ к хранилищу моделей
через API, что позволяет постоянно наращивать возможности интегрированной
среды путем включения новых инструментов моделирования и анализа.
Модуль ERwin Translation Wizard (PLATINUM technology) позволяет
перегружать объектную модель в модель данных ERwin (и обратно) и, с помощью
ERwin, сгенерировать схему БД на любой из поддерживаемых в ERwin СУБД.
1.5.Создание модели данных с помощью ERwin
ERwin имеет два уровня представления модели - логический и физический.
Логический уровень - это абстрактный взгляд на данные, на нем данные
представляются так, как выглядят в реальном мире, и могут называться так,
как они называются в реальном мире, например "Постоянный клиент", "Отдел"
или "Фамилия сотрудника". Объекты модели, представляемые на логическом
уровне, называются сущностями и атрибутами. Логическая модель данных может
быть построена на основе другой логической модели, например на основе
модели процессов. Логическая модель данных является универсальной и никак
не связана с конкретной реализацией СУБД.
1.5.1.Создание логической модели данных
Различают три уровня логической модели, отличающихся по глубине
представления информации о данных:
o диаграмма сущность-связь (Entity Relationship Diagram, ERD);
o модель данных, основанная на ключах (Key Based model, KB);
o полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных верхнего уровня.
Она включает сущности и взаимосвязи, отражающие основные бизнес-правила
предметной области. Такая диаграмма не слишком детализирована, в нее
включаются основные сущности и связи между ними, которые удовлетворяют
основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может
включать связи многие-ко-многим и не включать описание ключей. Как правило,
ERD используется для презентаций и обсуждения структуры данных с экспертами
предметной области.
Модель данных, основанная на ключах, - более подробное представление
данных. Она включает описание всех сущностей и первичных ключей и
предназначена для представления структуры данных и ключей, которые
соответствуют предметной области.
Полная атрибутивная модель - наиболее детальное представление структуры
данных: представляет данные в третьей нормальной форме и включает все
сущности, атрибуты и связи.
1.6.Сущности и атрибуты
Основные компоненты диаграммы Erwin - это сущности, атрибуты и связи.
Каждая сущность является множеством подобных индивидуальных объектов,
называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться
от всех остальных экземпляров. Атрибут выражает определенное свойство
объекта. С точки зрения БД (физическая модель) сущности соответствует
таблица, экземпляру сущности - строка в таблице, а атрибуту -колонка
таблицы.
Построение модели данных предполагает определение сущностей и
атрибутов, т. е. необходимо определить, какая информация будет храниться в
конкретной сущности или атрибуте. Сущность можно определить как объект,
событие или концепцию, информация о которых должна сохраняться. Сущности
должны иметь наименование с четким смысловым значением, именоваться
существительным в единственном числе, не носить "технических" наименований
и быть достаточно важными для того, чтобы их моделировать. Именование
сущности в единственном числе облегчает в дальнейшем чтение модели.
Фактически имя сущности дается по имени ее экземпляра. Примером может быть
сущность Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия
заказчика и Адрес заказчика. На уровне физической модели ей может
соответствовать таблица Customer с колонками Customer_number, Customer_name
и Customer_address.
Для внесения сущности в модель необходимо (убедившись предварительно,
что вы находитесь на уровне логической модели - переключателем между
логической и физической моделью служит раскрывающийся список в правой части
панели инструментов) "кликнуть" по кнопке сущности на панели инструментов
(ERwin Toolbox) , затем "кликнуть" по тому месту на диаграмме, где
необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по
сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать
диалог Entity Editor, в котором определяются имя, описание и комментарии
сущности .
Каждая сущность должна быть полностью определена с помощью текстового
описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User
Defined Properties - Свойства, определенные пользователем) служат для
внесения дополнительных комментариев и определений к сущности. Закладка
Definition используется для ввода определения сущности. Эти определения
полезны как на логическом уровне, поскольку позволяют понять, что это за
объект, так и на физическом уровне, поскольку их можно экспортировать как
часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name).
Закладка Note позволяет добавлять дополнительные замечания о сущности,
которые не были отражены в определении, введенном в закладке Definition.
Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-
правило или соглашение по организации диаграммы.
В закладке Note 2 можно задокументировать некоторые возможные запросы,
которые, как ожидается, будут использоваться по отношению к сущности в БД.
При переходе к физическому проектированию, записанные запросы помогут
принимать такие решения в отношении проектирования, которые сделают БД
более эффективной.
Закладка Note 3 позволяет вводить примеры данных для сущности (в
произвольной форме).
В закладке Icon каждой сущности можно поставить в соответствие
изображение, которое будет отображаться в режиме просмотра модели на уровне
иконок. В этой закладке можно задать как большую иконку, которая будет
отображаться на уровне Icon, так и малую иконку, которая будет отображаться
на всех уровнях просмотра модели. Для связывания изображения с сущностью
необходимо щелкнуть по кнопке, в появившемся диалоге ERwin Icon Editor
щелкнуть по кнопке Import и выбрать соответствующий файл формата bmp. После
выбора иконки она отображается в закладке Icon диалога Entity Editor . Для
определения UDP служит диалог User-Defined Property Editor (вызывается из
меню EditUDPs). В нем необходимо указать вид объекта, для которого
заводится UDP (диаграмма в целом, сущность, атрибут и т. д.) и тип данных.
Для внесения нового свойства следует щелкнуть в таблице по кнопке “+”, и
внести имя, тип данных, значение по умолчанию и определение.
Физическая модель данных, напротив, зависит от конкретной СУБД,
фактически являясь отображением системного каталога. В физической модели
содержится информация о всех объектах БД. Поскольку стандартов на объекты
БД не существует (например, нет стандарта на типы данных), физическая
модель зависит от конкретной реализации СУБД. Следовательно, одной и той же
логической модели могут соответствовать несколько разных физических
моделей. Если в логической модели не имеет значения, какой конкретно тип
данных имеет атрибут, то в физической модели важно описать всю информацию о
конкретных физических объектах - таблицах, колонках, индексах, процедурах и
т. д. Разделение модели данных на логические и физические позволяет решить
несколько важных задач.
Для создания моделей данных в ERwin можно использовать две нотации:
IDEF1X и IE (Information Engineering). Методология IDEF1X была разработана
для армии США и широко используется в государственных учреждениях США,
финансовых и промышленных корпорациях. Методология IE, разработанная
Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами,
используется преимущественно в промышленности. Переключение между нотациями
можно сделать в закладке Methodology диалога Preferences (меню
OptionPreferences). В дальнейшем будет использоваться нотация IDEF1X.
ERwin имеет несколько уровней отображения диаграммы: уровень
сущностей, уровень атрибутов, уровень определений, уровень первичных ключей
и уровень иконок. Переключиться между первыми тремя уровнями можно с
использованием кнопок панели инструментов. Переключиться на другие уровни
отображения можно при помощи контекстного меню, которое появляется, если
"кликнуть" по любому месту диаграммы, не занятому объектами модели. В
контекстном меню следует выбрать пункт Display Level и затем необходимый
уровень отображения. ERwin позволяет связать с сущностью большую и малую
иконки. При переключении на уровень иконок показывается большая иконка. Для
отображения малой иконки следует выбрать в контекстном меню пункт Display
OptionsEntities и в каскадном меню включить опцию Entity Icon. Малая
иконка будет показана слева от имени сущности на всех .уровнях отображения
модели. В табл. 2 2 показаны уровни отображения модели.
1.7.CASE-средство фирмы ORACLE. DESIGNER2000
Первая версия CASE-инструментария фирмы ORACLE, ORACLE*CASE появилась
в 1989 году с ориентацией на символьный режим для конечного пользователя.
Существенные изменения потребовались в следующей версии, ORACLE*CASE 5.1
(1993г.), в связи с реализацией нового сервера и перехода к графическому
интерфейсу конечного пользователя. В настоящее время завершена работа по
выпуску в промышленную эксплуатацию новой CASE-среды под названием
DESIGNER2000, работающей в среде MS WINDOWS. Этот продукт вместе со
средствами разработки DEVELOPER2000 реализуют новый подход фирмы ORACLE к
общей среде создания и сопровождения прикладных систем.
В CASE-методологии фирмы ORACLE используется некоторый специальный вид
модели Чена (Чен в 1976 году ввел модель "сущность-связь"), близкий к
бинарной ER-модели. В этом случае взаимосвязи могут быть определены только
между двумя сущностями. Для наглядного представления общей структуры
предметной области все такие спецификации изображаются в графическом виде -
в виде ER-диаграммы. На этой диаграмме объекты изображаются
прямоугольниками, а связи - линиями, соединяющими соответствующие
прямоугольники. Задание типа связи ("один к одному", "многие к одному" и
т.д.) означает введение некоторого семантического ограничения. На диаграмме
для каждого типа взаимосвязи используется свое графическое изображение:
если любой экземпляр сущности A может быть связан с несколькими
экземплярами сущности B, то со стороны прямоугольника-сущности A линия,
выражающая взаимосвязь, дополняется специальным символом . Кроме того, для
связи можно указать, является ли она обязательной для входящих в нее
сущностей. Если любой экземпляр сущности A обязательно должен быть связан с
каким-либо экземпляром сущности B, то прилегающая к прямоугольнику "A"
половина линии - сплошная, в противном случае она - пунктирная.
Функциональные аспекты предметной области описываются с помощью
диаграмм иерархии функций и потоков данных. Эти диаграммы отражают
деятельность существующих организационных структур, технологические
особенности процессов переработки информации и строятся по методологии
проектирования "сверху вниз". Начиная с самой общей функции, описывающей
деятельность всей организации в целом, аналитик последовательно разбивает
это описание на более детальные функции, в совокупности составляющие
исходную; в дальнейшем этот процесс продолжается применительно к новым,
полученным на предыдущем уровне функциям. Такая декомпозиция функций
завершается, когда функции, полученные на самом нижнем уровне иерархии, не
поддаются дальнейшему разложению, т.е. являются элементарными. Для них
специфицируется, с какими объектами они работают, какие типы действий при
этом производятся (создание, удаление, модификация) как на уровне объектов,
так и на уровне отдельных их параметров. Кроме этого, могут быть описаны
события, вызывающие выполнение той или иной функции.
Кроме собственно изображения диаграммы каждый из редакторов позволяет
вводить дополнительную уточняющую информацию об отдельных элементах
диаграммы. Например, для любой сущности, представленной на ER-диаграмме
прямоугольником с названием, можно вызвать специальное окно для задания
всевозможных характеристик этой сущности, включая атрибуты, первичные
ключи, уникальные идентификаторы, ограничения или правила проверки для
значений атрибутов, частотные характеристики и т.д. Аналогично, для любой
взаимосвязи можно специфицировать, является ли она идентифицирующей (входит
в состав какого-либо уникального идентификатора), переносимой ( можно
динамически переопределять для любого экземпляра сущности типа "деталь",
какому экземпляру "мастера" он подчиняется) и т.д.
Дополнительно повышает наглядность и выразительность концептуальных
моделей широкие возможности использования цвета и различных шрифтов для
обозначения названий отдельных элементов.
Для одного и того же приложения предусматривается возможность
построения нескольких ER- диаграмм и нескольких иерархий функций: это может
быть полезно для сложных задач с огромным количеством объектов и связей. В
этом случае естественно декомпозировать общую задачу и для каждой части
рисовать свою ER-диаграмму.
Кроме средств ввода данных и построения графических изображений каждый
редактор предоставляет возможность выполнять различные семантические
проверки построенных диаграмм на полноту и корректность, а также
генерировать разнообразные отчеты для документирования концептуального
уровня разработки.
Проектирование. На этапе проектирования формируются все спецификации,
описывающие структуру и основные компоненты будущей системы. Как и на
предыдущем уровне эти спецификации разделяются на информационные и
функциональные - на описание базы данных и описание состава программных
модулей системы.
При описании базы данных указывается, какие таблицы в нее входят,
специфицируются основные характеристики этих таблиц, состав столбцов каждой
из них, уточняются параметры столбцов (тип значений, ограничения на
допустимые значения, значения, принятые по умолчанию, статистические
характеристики использования и многие другие), задаются ограничения
целостности - логические условия, которые должны выполняться при любом
содержании таблиц. Кроме того, описываются дополнительные объекты базы
данных ORACLE, такие как индексы, кластеры, последовательности, основное
назначение которых связано с повышением эффективности работы с базой
данных, ускорением доступа к часто используемой информации.
Использование на этом уровне графических моделей - диаграмм, является
важной новой особенностью CASE-средств фирмы ORACLE. В предыдущих версиях,
как и в CASE- системе Erwin , графические диаграммы используются обычно
только на концептуальном уровне для ER-моделей, функциональных иерархий и
т.д. В то же время, опыт практической деятельности в области CASE-
технологий показывает, что использование графических изображений полезно и
для представления структуры базы данных, схем взаимодействия программных
модулей.
В DESIGNER2000 для этой цели предусмотрены:
редактор схем баз данных
редактор диаграмм взаимосвязей между модулями
Особенности DESIGNER2000. Генераторы приложений
Входящие в состав DESIGNER2000 генераторы разбиваются на две группы:
генератор сервера
генераторы клиентской части
Генератор серверной части автоматически строит по спецификациям базы
данных тексты программ на языке SQL, используя все средства определения баз
данных, включая триггеры, хранимые процедуры и т.д.
Генераторы клиентской части обеспечивают автоматическое формирование
текстов программных модулей по их спецификациям, записанным в репозитарии.
Все модули приложения классифицируются по типам, основными из которых
являются экранные формы, отчеты, процедуры. Для каждого типа имеется свой
генератор, результатом работы которого является программа, написанная на
языке, соответствующем этому типу: генератор форм создает приложения для
ORACLEForms, генератор отчетов позволяет получать процедуры на PLSQL либо
приложения для ORACLEReport.
Исходной информацией для работы любого генератора служат спецификации
таблиц базы данных и спецификации модулей. В спецификации модуля
указываются такие его параметры, как наименование, тип, некоторые
характеристики внешнего представления (заголовки, параметры). Кроме того,
перечисляются используемые таблицы базы данных и для каждой из них
специфицируется, какие операции к ней могут применяться (выборка, ввод
записей, корректировка, удаление), какие ее столбцы и каким образом
участвуют в работе модуля. С помощью утилиты автоматической генерации
проекта базы данных по ER-диаграмме будут построены спецификации будущей
базы данных - ее состав таблиц, перечень столбцов каждой из них, уточнение
характеристик столбцов, описание ограничений целостности
1.8. Проблемы проектирования
Несмотря на все потенциальные возможности CASE-средств, существует
множество примеров их неудачного внедрения. В связи с этим необходимо
отметить следующее:
CASE-средства не обязательно дают немедленный эффект; он может быть получен
только спустя какое-то время;
реальные затраты на внедрение CASE-средств обычно намного превышают затраты
на их приобретение;
CASE-средства обеспечивают возможности для получения существенной выгоды
только после успешного завершения процесса их внедрения.
Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-
либо безоговорочные утверждения относительно реального удовлетворения тех
или иных ожиданий от их внедрения. Можно перечислить следующие факторы,
усложняющие определение возможного эффекта от использования CASE-средств:
широкое разнообразие качества и возможностей CASE-средств;
относительно небольшое время использования CASE-средств в различных
организациях и недостаток опыта их применения;
широкое разнообразие в практике внедрения различных организаций;
отсутствие детальных метрик и данных для уже выполненных и текущих
проектов;
широкий диапазон предметных областей проектов;
различная степень интеграции CASE-средств в различных проектах.
Вследствие этих сложностей доступная информация о реальных внедрениях
крайне ограничена и противоречива. Она зависит от типа средств,
характеристик проектов, уровня сопровождения и опыта пользователей.
Пользователи CASE-средств должны быть готовы к необходимости долгосрочных
затрат на эксплуатацию, частому появлению новых версий и возможному
быстрому моральному старению средств, а также постоянным затратам на
обучение и повышение квалификации персонала.
Несмотря на все высказанные предостережения и некоторый пессимизм,
грамотный и разумный подход к использованию CASE-средств может преодолеть
все перечисленные трудности. Успешное внедрение CASE-средств должно
обеспечить такие выгоды как:
высокий уровень технологической поддержки процессов разработки и
сопровождения ПО;
положительное воздействие на некоторые или все из перечисленных факторов:
производительность, качество продукции, соблюдение стандартов,
документирование;
приемлемый уровень отдачи от инвестиций в CASE-средства.
Логического проектирования - объекты предметной области не отображают
в абстрактные объекты модели данных, чтобы это отображение не противоречило
семантики предметной области и было лучшим.
Физического проектирования - не обеспечивает эффект выполнения
запросов к БД, не располагает данные во внешней памяти, требуется создание
дополнительных структур.
Даталогического проектирования
✓ избыточности информации
✓ аномалии при добавлении
✓ аномалии редактирования
✓ аномалии удаления
Избыточность появляется в следующем: активную роль процессе передачи
текста играют только некоторые ключевые слова. Имеет место неоднозначность
выражения.
Аномалиями называются такие ситуации в таблицах БД, которые приводят к
противоречиям в БД или существенно усложняют обработку данных.
Аномалии модификации (редактирования) проявляются в том, что изменение
значения атрибута может повлечь за собой пересмотр всей таблицы с
соответствующим изменением значений этого атрибута в других записях
таблицы.
Аномалии удаления проявляются в том, что при удалении какого-либо значения
атрибута исчезнет другая информация, которая не связана напрямую с
удаляемым значением.
Аномалии добавления проявляются в том, что невозможно добавить запись в
таблицу, пока не будут известны значения всех ее атрибутов, а также в том,
что вставка новой записи потребуют пересмотра всей таблицы.
Для устранения избыточности проводится нормализация которая приводит к
аномалиям обработки данных. Различают не избыточное и избыточное
дублирование данных. Избыточное дублирование приводит к проблемам
обработки кортежей отношения. Способом устранения избыточного дублирования
и нейтрализации аномалий является декомпозиция, то есть разбиение исходного
отношения (таблицы).
1.8.1. Ограничение целостности модели данных
1) целостность по сущностям (не допускается, чтобы какой либо атрибут,
участвовавший в первичном ключе, принимал неопределенное значение)
2) целостность по ссылкам (это такое состояние БД, при котором каждому
значению внешнего ключа подчиненно отношение, соответствующий кортеж (поле)
главного отношения с таким же отношением первичного ключа)
3) определяемая пользователем.
Ссылочная целостность может нарушаться в результате: вставки,
удаления, обновления.
Основные функции: Анализ предметной области, проектирование структуры
данных, задание ограниченной целостности при описании структур БД,
первоначальная загрузка и ведение БД, защита данных от несанкционированного
доступа
Суть даталогического моделирования заключается в разработке такой
структуры данных, которые удовлетворяли бы следующим требованиям:
1) ... продолжение
Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.
Похожие работы
Дисциплины
- Информатика
- Банковское дело
- Оценка бизнеса
- Бухгалтерское дело
- Валеология
- География
- Геология, Геофизика, Геодезия
- Религия
- Общая история
- Журналистика
- Таможенное дело
- История Казахстана
- Финансы
- Законодательство и Право, Криминалистика
- Маркетинг
- Культурология
- Медицина
- Менеджмент
- Нефть, Газ
- Искуство, музыка
- Педагогика
- Психология
- Страхование
- Налоги
- Политология
- Сертификация, стандартизация
- Социология, Демография
- Статистика
- Туризм
- Физика
- Философия
- Химия
- Делопроизводсто
- Экология, Охрана природы, Природопользование
- Экономика
- Литература
- Биология
- Мясо, молочно, вино-водочные продукты
- Земельный кадастр, Недвижимость
- Математика, Геометрия
- Государственное управление
- Архивное дело
- Полиграфия
- Горное дело
- Языковедение, Филология
- Исторические личности
- Автоматизация, Техника
- Экономическая география
- Международные отношения
- ОБЖ (Основы безопасности жизнедеятельности), Защита труда
