Курсовая работа: Анализ процесса даталогического моделирования и автоматизированные системы ее реализации

Содержание

Введение 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
Введение
Целью моей курсовой работы является анализ процесса даталогического моделирования основанный на использовании 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 (вызывается из меню Edit/UDPs). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т. д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке “+”, и внести имя, тип данных, значение по умолчанию и определение.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.
Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering). Методология IDEF1X была разработана для армии США и широко используется в государственных учреждениях США, финансовых и промышленных корпорациях. Методология IE, разработанная Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами, используется преимущественно в промышленности. Переключение между нотациями можно сделать в закладке Methodology диалога Preferences (меню Option/Preferences). В дальнейшем будет использоваться нотация IDEF1X.
ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями можно с использованием кнопок панели инструментов. Переключиться на другие уровни отображения можно при помощи контекстного меню, которое появляется, если "кликнуть" по любому месту диаграммы, не занятому объектами модели. В контекстном меню следует выбрать пункт Display Level и затем необходимый уровень отображения. ERwin позволяет связать с сущностью большую и малую иконки. При переключении на уровень иконок показывается большая иконка. Для отображения малой иконки следует выбрать.....