CASE-технологии в моделировании данных информационной системы

Министерство  сельского хозяйства Российской Федерации

Департамент научно-технологической политики и  образования

Федеральное государственное образовательное  учреждение

высшего профессионального образования

«Красноярский государственный аграрный университет»

Институт  управления и агробизнеса

 

 

Кафедра информационных систем и 

технологий  в экономике

 

 

 

КУРСОВОЙ  ПРОЕКТ

по  дисциплине «Теория экономических  информационных систем»

 

CASE-технологии  в моделировании данных информационной  системы автопредприятие города

 

08.08.01.05.ПЗ

 

 

 

 

 

Выполнил  студент                                                                                 Болтус

Екатерина Юрьевна

                                                  

 

 

 

Принял  доцент                                                                          Миндалёв Игорь                                                

                                                                                                              Викторович                                             

 

 


 

 

 

Красноярск 2011


Содержание:

0. Введение…………………………………………………………….………….3

1. Описание предметной области…………………………………………..….3

1.1. Описание  бизнес-процессов и бизнес-правил  предметной области...........3

1.2. Прототип  предметной области………………………………………………5

2. Обзор CASE-средств…………………………………………………….........5

2.1. Назначение CASE-технологии………………………………………………5

2.2. Исследование  рынка CASE-средств……………………………………….11

2.3. Установка Oracle SQL Developer Data Modeler…………………………...13

3. Диаграмма сущность-связь ………………………………………………..13

3.1. Определение  сущностей……………………………………………………13

3.2. Описание  сущностей………………………………………………………..14

3.3. Определение  связей…………………………………………………………15

3.4. Определение  типов сущностей…………………………………………….16

3.5. Диаграмма  «сущность-связь» на уровне сущностей……………………..16

4. Модель данных, основанная на ключах……………………………….....18

4.1. Определение  доменов……………………………………………………....18

4.2. Определение атрибутов…………………………………………………….18

4.3. Определение первичных ключей…………………………………………..20

4.4. Диаграмма «модель данных, основанная на ключах»……………………21

5. Реляционная модель………………………………………………………...23

5.1. Замена связей многие-ко-многим………………………………………….23

5.2. Нормализация: 1НФ………………………………………………………...23

5.3. Нормализация: 2НФ………………………………………………………...23

5.4. Нормализация: 3НФ………………………………………………………...24

5.5. Проверка модели…………………………………………………………....24

5.6. Диаграмма «Нормализованная логическая модель данных»…………….24

5.7. Стратегия супертипа………………………………………………………..24

5.8. Замена имен связей, столбцов и таблиц…………………………………...24

5.9. Создание реляционной модели…………………………………………….24

5.10. Проверка модели………………………………………….……………….25

5.11. Правила уникальности…………………………………………………….25

5.12. Диаграмма реляционной модели……………………………………...….27

5.13. Генерация DDL…………………………………………………………….27

6. Загрузка данных……………………………………………………………..27

6.1. Установка ORACLE………………………………………………………...27

6.2. Установка ORACLE SQL Developer……………………………………….27

6.3. Генерация БД………………………………………………………………..27

6.4. Загрузка тестовых данных………………………………………………….28

Заключение……………………………………………………………………...28

Список использованной литературы…………………………………….….29

 

 

  1. Введение

«Наибольшую опасность на дорогах представляет машина, которая едет быстрее, чем способен думать ее водитель»

Р. Лембке

 

 

Название проекта: «CASE-технологии в моделировании данных информационной системы автопредприятие города».

Цель проекта: создание атрибутивной и реляционной модели данных информационной системы автопредприятие города.

Основание проекта: задание преподавателя.

Используемые  программные средства: CASE-средство Oracle SQL Developer Data Modeler, Oracle SQL Developer, СУБД Oracle 10gXE.

 

1. Описание предметной области

1.1. Описание бизнес-процессов и  бизнес-правил предметной области

Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей.

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

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

 

 

 Автопредприятие города занимается организацией пассажирских и грузовых перевозок внутри города. В ведении предприятия находится автотранспорт различного назначения: автобусы, такси, маршрутные такси, прочий легковой транспорт, грузовой транспорт, транспорт вспомогательного характера, представленный различными марками. Каждая из перечисленных категорий транспорта имеет характеристики, свойственные только этой категории: например, к характеристикам только грузового транспорта относится грузоподъемность, пассажирский транспорт характеризуется вместимостью и т.д. С течением времени, с одной стороны, транспорт стареет и списывается (возможно, продается), а с другой, - предприятие пополняется новым автотранспортом.  
    Предприятие имеет штат водителей, закрепленных за автомобилями (за одним автомобилем может быть закреплено более одного водителя). Обслуживающий персонал (техники, сварщики, слесари, сборщики и др.) занимается техническим обслуживанием автомобильной техники, при этом различные вышеперечисленные категории также могут иметь уникальные для данной категории атрибуты. Обслуживающий персонал и водители объединяется в бригады, которыми руководят бригадиры, далее следуют мастера, затем начальники участков и цехов. В ведении предприятия находятся объекты гаражного хозяйства (цеха, гаражи, боксы и пр.), где содержится и ремонтируется автомобильная техника.  
    Пассажирский автотранспорт (автобусы, маршрутные такси) перевозит пассажиров по определенным маршрутам, за каждым из них закреплены отдельные единицы автотранспорта. Ведется учет числа перевозимых пассажиров, на основании чего производится перераспределением транспорта с одного маршрута на другой. Учитывается также пробег, число ремонтов и затраты на ремонт по всему автотранспорту, объем грузоперевозок для грузового транспорта, интенсивность использования транспорта вспомогательного назначения. Учитывается интенсивность работы бригад по ремонту (число ремонтов, объем выполненных работ), число замененных и отремонтированных узлов и агрегатов (двигателей, КП, мосты, шасси и т.д.) по каждой автомашине, и суммарно по участку, цеху, предприятию.

 

 

 

1.2. Прототип предметной области

      Адрес: 660020, г. Красноярск, ул. Спандаряна, 10

 

2. ОБЗОР  CASE-СРЕДСТВ

2.1. Назначение CASE-технологии

«Скорость — это разновидность экстаза, подаренная человеку технической революцией»

Милан Кундера. Неспешность.

Аббревиатура CASE расшифровывается, как Computer Aided Software Engineering. Этот термин широко используется в настоящее время. На этапе появления подобных средств, термин CASE употреблялся лишь в отношении автоматизации разработки программного обеспечения. Сегодня CASE средства подразумевают процесс разработки сложных ИС в целом: создание и сопровождение ИС, анализ, формулировка требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Таким образом, CASE-технологии образуют целую среду разработки ИС.      Итак, CASE-технология представляет собой методологию проектирования программных систем, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Главные составляющие CASE-продукта таковы:

методология (Method Diagrams), которая задает единый графический язык и правила работы с ним.

графические редакторы (Graphic Editors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «upper case технологий

генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии).

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

Различные статистические обзоры свидетельствуют сегодня об эффективности  применения CASE средств в процессе разработки программных систем. Однако % неудач все же существует и довольно велик. Разумеется, существуют свои недостатки применения технологий, значимыми являются недостатки со стороны аспектов бизнеса:

CASE-средства не обязательно  дают немедленный эффект; он может  быть получен только спустя  какое-то время; 

реальные затраты на внедрение CASE-средств обычно намного превышают  затраты на их приобретение;

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

Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-либо безоговорочные утверждения  относительно реального удовлетворения тех или иных ожиданий от их внедрения. Можно перечислить следующие  факторы, усложняющие определение  возможного эффекта от использования CASE-средств:

широкое разнообразие качества и возможностей CASE-средств;

относительно небольшое  время использования CASE-средств в различных организациях и недостаток опыта их применения;

широкое разнообразие в практике внедрения различных организаций;

отсутствие детальных  метрик и данных для уже выполненных  и текущих проектов;

широкий диапазон предметных областей проектов;

различная степень интеграции CASE-средств в различных проектах.

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

Технология: понимание ограниченности существующих возможностей и способность принять новую технологию;

Культура: готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;

Управление: четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

Пройдя нелегкий путь изучения рекомендаций по внедрению, анализу  организации, бизнес рекомендаций, удачно использовав CASE-технологии в процессе разработки, группа разработчиков получит ряд преимуществ созданной системы:

высокий уровень технологической  поддержки процессов разработки и сопровождения ПО;

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

приемлемый уровень отдачи от инвестиций в CASE-средства.

2.2. Исследование рынка CASE-средств

Enterprise Architect - это всесторонний набор UML инструментов для анализа и дизайна, охватывающий разработку программного обеспечения через стадии анализа, модели дизайна, испытания и обслуживание. 
Enterprise Architect - это многопользовательский графический инструмент, разработанный для того, чтобы создавать устойчивое и удобное в сопровождении программное обеспечение. 
Enterprise Architect - работает с такими языками программирования как: C++, C#, Java, Delphi, VB.Net, Visual Basic, ActionScript, PHP и Python.

Описание общего характера  
Enterprise Architect 7.1 является высокопроизводительным инструментом, основанном на стандарте UML 2.1, для моделирования и создания программного обеспечения. Покрывает весь процесс разработки от формирования требований к системе до её полной реализации. Представляет собой средства надежной и эффективной визуализации и организации взаимодействия. Это, по настоящему шустрый инструмент для моделирования: низкие издержки на установку, блестящая производительность и интуитивно понятный интерфейс.

Скорость, Надежность и Эффективность  
Unified Modeling Language (унифицированный язык моделирования) предоставляет разработчикам существенные преимущества, позволяя последовательно создавать строгие и вместе с тем наглядные модели программных систем. Enterprise Architect делает этот процесс удобным, простым, быстрым и гибким.

Генерация кода производится с помощью шаблонов (Code generation templates), редактируя их можно управлять процессом генерации кода. Например, в случае генерации функции реализующий некий интерфейс, в качестве заглушки удобно вставить код бросающий (генерирующий) исключение. По умолчанию генерируется функция с пустым телом. Можно подкорректировать формат: кавычки, отступы, прочие мелочи, и т.д. и т.п.

Имеет встроенный редактор с «подсветкой синтаксиса». Благодаря  этому имеется возможность быстро получить доступ к исходному коду модели.

Разработчик: Sparx Systems; 
Сайт программы: Sparx Systems Enterprise Architect; 
UML: The Object Management Group (OMG);

Цена: 4441.28 руб.


                 2.3. Установка Oracle SQL Developer Data Modeler

При установке в Microsoft Windows файл datamodeler-2.0.0-584.zip. был взят в 3-06.

ZIP-файл уже  включал JRE. Далее произвелась распаковка архива на диск D и запустился файл datamodeler.exe.

 

 

 

3. Диаграмма сущность-связь

3.1. Определение сущностей

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

   Сущность (entity) - это "предмет", который может быть идентифицирован некоторым способом, отличающим его от других "предметов". Каждая сущность обладает набором атрибутов. Атрибут - отдельная характеристика сущности.

    В среде CASE-средства datamodeler определились и создались следующие сущности базы данных «Автопредприятие города»: автотранспорт, гараж, бригада, бригадир, персонал, тип персонала, водитель, автобус, такси, вспомогательный транспорт, грузовой транспорт.

 

3.2. Описание сущностей

Сущности  базы данных «Автопредприятие города»:

  1. Сущность Автотранспорт – содержит информацию о некоторых характеристиках автомобилей различного назначения.
  2. Сущность Гараж –содержит информацию об объектах гаражного хозяйства, которыми владеет предприятие.
  3. Сущность Бригада- содержит информацию о бригадах.
  4. Сущность Бригадир- содержит информацию о характеристиках бригадира.
  5. Сущность Персонал – содержит информацию о различных категориях обслуживающего персонала.
  6. Сущность Тип персонала – содержит информацию, непосредственно, типизирующую персонал.
  7. Сущность Водитель – описывает профессиональные характеристики, касающиеся водителя.
  8. Сущность Автобус – описывает характеристики, свойственные категории автобуса.
  9. Сущность Такси – описывает характеристики, свойственные категории такси
  10. Сущность Вспомогательный транспорт – описывает характеристики, свойственные категории вспомогательного транспорта
  11. Сущность Грузовой транспорт – описывает характеристики, свойственные категории грузового транспорта.

 

3.3. Определение  связей

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

     На логическом  уровне можно установить идентифицирующую  связь один-ко-многим, связь многие-ко-многим и неидентифицирующую связь один-ко-многим.

    Определяем связи один- ко- многим :

  • «Бригадир-Бригада»- бригадир может руководить несколькими бригадами, в зависимости от смены и назначения начальства.
  • «Персонал-Тип персонала»- обслуживающий персонал может включать в себя несколько работников различного типа.

   Определяем связи многие- ко- многим:

  • «Персонал-Бригада» - некоторые типы персонала могут находиться в различных бригадах. А в каждой бригаде может быть несколько типов персонала.
  • «Персонал-Автотранспорт»- разные типы персонала могут обслуживать более одного автомобиля, а каждый автомобиль обслуживается несколькими типами персонала.
  • «Водитель-Бригада»- многие водители работают более, чем в одной бригаде, а в каждой бригаде может находиться по несколько водителей.
  • «Водитель-Автотранспорт»- один водитель может управлять различными автомобилями, а за каждым автомобилем может быть закреплено более одного водителя.
  • «Автотранспорт-Гараж»- каждый вид автотранспорта может находиться в различных гаражах, а один гараж может вмещать в себя несколько видов автотранспорта.

 

3.4. Определение  типов сущностей

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

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

2) Иерархия супертип-подтип:

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

    

 

3.5. Диаграмма  «сущность-связь» на уровне сущностей

Диаграмма сущность-связь (ERD) включает сущности и связи, отражающие основные бизнес-правила предметной области.

Диаграммы “сущность-связь” (ERD) предназначены  для разработки моделей данных и  обеспечивают стандартный способ определения  данных и отношений между ними.


Рис.1: Логическая модель в нотации Баркера

 

 

4. Модель данных, основанная на ключах

4.1. Определение  доменов

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

 В среде CASE-средства определены следующие домены:

Имя

Тип

Характеристика

numeric_id

numeric

Precision: 4, Scale: 0

vio

varchar

Size: 50

title

varchar

Size: 50

kol

varchar

Precision: 10, Scale: 0


Таблица 1:Домены


4.2. Определение атрибутов

Атрибутом сущности является любой признак, который  служит для

уточнения, идентификации, классификации, числовой характеристи-

ки или выражения состояния сущности.

Каждый  признак сущности описывается ровно  одним атрибутом в

своей сущности. Атрибуты должны именоваться  в единственном чис-

ле и иметь четкое смысловое значение.

Для большинства сущностей полный набор  признаков неисчерпаем.

Поэтому выбирают только те сведения о сущности, которые необхо-

димы для решения данной практической задачи.

 

1)Определение  атрибутов сущности автотранспорт:

Имя

Тип данных

Ещё

Автотранспорт# (avtotransport)

Domain numeric_id

Primary UID, уникальный идентификатор автотранспорта

Номер транспорта (nomtran)

Domain title

Mandatory

Маршрут (mar)

Logical type:

VARCHAR

(size=15)

 

Пробег(probeg)

Domain kol

 

 

 

 

 

2) Определение  атрибутов сущности Автобус:

Имя

Тип данных

Ещё

Вместимость (vmest )

Domain kol

 

Количество перевозок (kolper)

Domain kol

 

 

3) Определение  атрибутов сущности Такси:

Имя

Тип данных

Ещё

Такса (taxa)

Domain kol

 

 

4) Определение  атрибутов сущности Грузовой транспорт:

Имя

Тип данных

Ещё

Грузоподъемность (gruzpod )

Domain kol

 

Объем  перевозок (obper)

Logical type:

VARCHAR

(size=15)

 

 

5) Определение  атрибутов сущности Вспомогательный транспорт:

Имя

Тип данных

Ещё

Эвакуация (evak )

Logical type:

VARCHAR

(size=15)

 

Буксировка  (buksir )

Logical type:

VARCHAR

(size=15)

 

 

6) Определение  атрибутов сущности Персонал:

Имя

Тип данных

Ещё

Персонал# (personal)

Domain numeric_id

Primary UID, уникальный идентификатор персонала

Фамилия (famil)

Domain vio

Mandatory

Имя (imya)

Domain vio

Mandatory

Отчество (otches)

Domain vio

 

 

7) Определение  атрибутов сущности Тип персонала:

Имя

Тип данных

Ещё

Номер типа#(nomtip)

Domain numeric_id

Primary UID, уникальный идентификатор номера типа

Название  (nazv )

Logical type:

VARCHAR

(size=20)

 

 

8) Определение  атрибутов сущности Бригадир :

Имя

Тип данных

Ещё

Бригадир# (brigadir)

Domain numeric_id

Primary UID, уникальный идентификатор бригадира

Фамилия (famil)

Domain vio

Mandatory

Имя (imya)

Domain vio

Mandatory

Отчество (otches)

Domain vio

 

Компетентность (kompet)

Logical type:

VARCHAR

(size=20)

 

 

9) Определение  атрибутов сущности Бригада :

Имя

Тип данных

Ещё

Бригада# (brigadа)

Domain numeric_id

Primary UID, уникальный идентификатор бригады

Состав (sostav )

Domain kol

 

Количество смен (kolsm )

Logical type:

VARCHAR

(size=15)

 

 

10) Определение атрибутов сущности Водитель:

Имя

Тип данных

Ещё

Водитель# (vodit )

Domain numeric_id

Primary UID, уникальный идентификатор водителя

Категория (kateg)

Logical type:

VARCHAR

(size=20)

 

Стаж (stag)

Logical type:

VARCHAR

(size=20)

 

 

11) Определение атрибутов сущности Грузовой автомобиль:

Имя

Тип данных

Ещё

Гараж# (garaje)

Domain numeric_id

Primary UID, уникальный идентификатор гаража

Вместительность (vmest)

Logical type:

VARCHAR

(size=20)

 


4.3. Определение первичных ключей

Перви́чный ключ (англ. primary key) —один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).

    Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований:

Уникальность – два  экземпляра не должны иметь одинаковых значений возможного ключа.

Компактность – при  выборе первичного ключа предпочтение должно отдаваться более простым  ключам.

каждая строка должна иметь  определенное значение первичного ключа (не NULL).

Значение атрибутов ключа  не должно меняться в течении всего времени существования экземпляра сущности.

          Помимо первичных ключей существуют внешние ключи. Внешний ключ (FK) – атрибут, значение которого соответствует значению первичного ключа другого отношения.

       В среде  CASE-средства для каждой сущности  определились следующие первичные  ключи:

- Сущность Автотранспорт- первичным ключом является суррогатный атрибут «Автотранспорт#»

- для сущности Персонал – первичным ключом является суррогатный атрибут «Персонал#»

- для сущности Тип персонала – первичным ключом является номер типа.

- для сущности Бригада  - первичным ключом является суррогатный атрибут «Бригада#»

- для сущности Бригадир -  первичным ключом является суррогатный атрибут «Бригадир#»

- для сущности Водитель - первичным ключом является суррогатный атрибут «Водитель#»

- для сущности Гараж – первичным ключом является суррогатный атрибут «Гараж#»

4.4.Диаграмма «модель  данных, основанная на ключах»


 Рис.2: Логическая модель в нотации Бахмана


CASE-технологии в моделировании данных информационной системы