СУБД как средство автоматизации

Автор работы: Пользователь скрыл имя, 24 Января 2013 в 15:21, контрольная работа

Краткое описание

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

Содержание работы

Задание……………………………………………………………………………....2
Содержание……………………………………………………………………..…...3
Введение……………………………………………………………………………..4
Теоретические аспекты СУБД……………………………………………………..5
Функциональные возможности СУБД…………………………………………...10
BMC Remedy Action Request System (AR System)………………………………12
Сведения о компании ООО «Каскад 24»………………………………………...24
Конструкторская часть……………………………………………………………26
Проектирование БД в среде Microsoft Access……………………………………39
Применение Microsoft Access в БД «Техническая поддержка»………………..42
Заключение…………………………………………………………………………68
Список литературы………………………………………………………………...69

Содержимое работы - 1 файл

Отчет по практике.docx

— 6.19 Мб (Скачать файл)

 

Концептуальное (инфологическое) проектирование

 

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

    4 критерия оценки  эффективности инфологической модели:

  1. Простота – легкость понимания модели разроботщиками и пользователями информационного обеспечения.
  2. Отсутствие избыточности информации – исключение из лишней информации, т.е. любая часть данных должна быть представлена только в одном месте
  3. Расширяемость – способность эволюционировать с целью включения новых требований пользователей.
  4. Целостность – согласовать по способам использования и управления информацией.
  5. Представление в виде диаграммы – способность представления модели с помощью понятных обозначения для всех пользователей.

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

Известны следующие средства создания модели:

  1. Семантические сети
  2. Язык инфологического моделирования
  3. ER – диаграммы.

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

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

Атрибут – неотъемлемое свойство сущности  или связи. Именно по значениям атрибутов можно  идентифицировать экземпляр сущности. Значение атрибутов представляют основную часть сведений хранящихся в БД. На  ER – диаграммах атрибут представляется овалом. Значения атрибутов соединяются с сущностью линией с именем атрибута внутри.

Рассмотрим сущности характерных  для нашей БД и определим атрибуты, которые будут присутствовать в  БД.

 

Таблица 3. Атрибуты сущности «Клиентская база»

Атрибут

Описание

Код

Уникальный номер для  идентификации клиента

Название предприятия

Наименование  фирмы с которой был заключен контракт

Дата последнего обращения

Дата последнего зафиксированного Инцидента

№ рабочей станции

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

Договор тех. поддержки

Условия договора описанные в контракте


 

 

 

Таблица 4. Атрибуты сущности «Операторы»

Атрибут

Описание

Код

Уникальный номер  для идентификации сотрудника

Сотрудник

Ф.И.О. сотрудника службы ТП

№ рабочей станции

Стационарный  ПК который закреплен за сотрудником

Дни работы

Расписание работы сотрудника


 

 

Таблица 5. Атрибуты сущности «Инциденты»

Атрибут

Описание

Код

Уникальный код инцидента

Предприятие

Название предприятия

Дата обращения

Дата обращения в службу ТП

Оказанные услуги

Какие именно услуги были оказаны  в рамках ТО

Статус

Текущий статус инцидента

Оператор

Сотрудник, оказывавший  услуги


 

 

Схема данных:

  

Инфологическое  проектирование

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

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

Рассмотрим основные подходы  к созданию инфологической модели предметной области:

1. Функциональный подход к проектированию 

Этот метод реализует  принцип "от задач" и применяется  тогда, когда известны функции (комплекс задач) объекта управления, для  управления которым  создаётся рассматриваемые  ИО. При реализации этого подхода  необходимо знать методы решения  задач: входные и выходные параметры, применяемые операции по их обработки.

2. Предметный подход к проектированию.

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

Проектирование  с использованием метода "сущность-связь"

Метод "сущность–связь" (entity–relation, ER–method) является комбинацией  двух предыдущих и обладает достоинствами  обоих, так же называют  методом  «ER - диаграмм»; во-первых, ER – аббревиатура от слов ESSENCE (сущность) и RELATION (связь), во-вторых, метод основан на использовании диаграмм, называемых соответственно диаграммы ER – экземпляров и диаграммы ER – типа. Основными понятиями метода сущность – связь являются следующими:

  • Сущность
  • Атрибут сущности
  • Ключ сущности
  • Связь между сущностями
  • Степень связи
  • Класс принадлежности экземпляров сущности
  • Диаграммы ER – экземпляров
  • Диаграммы ER – типа

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

Атрибут представляет собой  свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибут сущности клиент может быть его фамилия, имя, отчество.

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

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

  • Диаграммы ER – экземпляров

Диаграммы ER – типа, или ER – диаграммы

Оператор

Оказал услугу

Клиенту

Смирнов Е. Р.

Замена оборудования

ООО «РосПух»

Молотов И. М.

Посредничество

ЗАО «Пар Риэлти»

Павлов Е. У.

Удаленная наладка связи

ОАО «ПРОТЦ»

Сидоров А. Д.

Замена комплектующих

ИП «Зырянов»


Диаграмма ER – экземпляров



 

 

Рисунок Диаграмма ER – типа

Классификация связей

 

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

Основные виды связи таблиц.

Между таблицами могут  устанавливаться бинарные (2 таблицы), тернарные (3 таблицы) и, в общем случае, n – арные связи.

При связывании двух таблиц выделяют основную и дополнительную  таблицы. Логическое связывание таблиц производится с помощью ключа  связи.

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

  • Один – один (1 : 1);
  • Один – много (1 : М);
  • Много – один (М : 1);
  • Много – много (М : М или М : N).

Связь вида 1:1

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

Связь вида 1:М

Эта связь имеет место  в случае, когда одной записи основной таблицы соответствует несколько  записей вспомогательной таблицы.

Связь вида М:1

Эта связь имеет место  в случае, когда одной или нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы.

Связь вида М:М

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

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

Сущность – это объект, о котором в системе будет накапливаться информация и храниться в БД. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).

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

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

Для каждой сущности выбираются свойства (атрибуты). Различают:

  1. Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
  2. Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
  3. Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности).
  4. Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).

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

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

Информация о работе СУБД как средство автоматизации