База данных

Автор работы: Пользователь скрыл имя, 30 Мая 2013 в 22:00, курсовая работа

Описание работы

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

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

Введение 5
1 Теория баз данных 6
1.1 Реляционная модель 6
1.2 Архитектура реляционных баз данных 6
1.3 Ключи и связи 7
1.4 Ссылочная целостность 8
1.5 Операции над данными 8
1.6 Объекты баз данных 9
2 Исследование предметной области 12
2.1 Организационная структура предприятия и направление деятельности 12
2.2 Постановка общей задачи курсовой работы 12
3 Проектирование базы данных 14
3.1 Инфологическое проектирование 14
3.2 Логическое проектирование базы данных 17
3.3 Физическое проектирование базы данных 22
Заключение 29
Библиографический список 30

Файлы: 1 файл

Пояснительная записка.doc

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

Проекцией отношения А по атрибутам X,Y,...,Z, где каждый из атрибутов принадлежит отношению А, называется отношение с заголовком {X,Y,...,Z} и телом, содержащим множество всех кортежей атрибутов X,Y,...,Z. Никакой атрибут не может быть указан в списке атрибутов дважды.

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

1.6 Объекты баз данных

Таблицы и поля являются полями базы данных. Таблицы поддерживаются всеми реляционными СУБД, и в их полях могут храниться данные разных типов. Наиболее часто встречающиеся:

1) строка (String) – строки  могут состоять из одно- или  двухбайтовых символов и иметь разную максимально возможную длину;

2) число (Number) – целые,  действительные, натуральные и т.  п.;

3) валюта (Currency) – специальный  тип числовых данных для хранения  денежных величин. Часто имеет  фиксированное число десятичных  знаков;

4) дата и время (Date) – любой реальной дате можно поставить в соответствие целое число, если хранится и время, то число оказывается дробным;

5) MEMO-поле – этот тип данных используется для хранения длинных текстов. Обычно максимальная длина текста ограничена какой-либо величиной;

6) BLOB-поле – представляет собой набор байтов. В таком поле можно хранить любые данные (текст, графику, multimedia-данные, OLE-объекты и т.д.).

В большинстве реляционных  СУБД ключи реализуются с помощью  индексов, которые можно определить как список номеров записей, указывающий в каком порядке их представлять. Хранение индексов требует существенно меньше места, чем хранение по-разному отсортированных версий самой таблицы. Использование индексов снижает время выборки данных. Однако любое изменение данных в таблице влечёт за собой изменение связанных с ней индексов, а это увеличивает время, требующееся СУБД для проведения указанных операций. Поэтому следует создавать только те индексы, которые реально необходимы.

Ограничения и правила  – объекты, содержащие сведенья об ограничениях, накладываемых на возможные значения полей. Например, максимальное или минимальное значение для данного поля. Есть также ссылочные ограничения (referential constraints). Например, связь master-detail может быть организована как ограничение, содержащее требование о том, чтобы значение поля ВК было равно одному из уже имеющихся значений поля ПК другой таблицы.

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

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

Системный каталог. СУБД хранит списки пользователей и ролей, таблиц, индексов, триггеров, процедур, а также сведенья о том, кто  ими владеет. Эти списки называются системными таблицами (system tables), а соответствующая  часть БД называется системным каталогом (system catalog).

Запросы к БД. Модификация  и выбор данных, изменение метаданных и некоторые др. операции осуществляются с помощью запросов (query). Один из способов манипуляции данными называется query by example — запрос по образцу. QBE представляет собой средство для визуального связывания таблиц и выбора полей, которые следует отобразить в результате запроса. Визуальное построение запроса с помощью QBE приводит к генерации текста запроса с помощью специального языка запросов SQL (Structured Query Language). Можно написать запрос непосредственно на языке SQL.

Транзакции – это  группы операций над данными, которые  либо выполняются все вместе, либо все вместе отменяются. Завершение (Commit) транзакций означает, что все  операции, входящие в состав транзакции, успешно завершены и результат их работы сохранён в БД. Откат (Rollback) транзакций означает, что все уже выполненные операции, входящие в состав транзакции, отменяются и все объекты БД, затронутые этими операциями, возвращены в исходное состояние.

Язык SQL – это непроцедурный  язык, используемый для формулировки запросов к БД в большинстве СУБД. Непроцедурность языка означает, что на нём можно указать, что  нужно сделать с БД, но нельзя описать алгоритм этого процесса. Все алгоритмы обработки SQL-запросов генерируются самой СУБД и не зависят от пользователя.

 

2 Исследование  предметной области

2.1 Организационная структура предприятия и направление деятельности

 

Структура региональных центров связи (РЦС) содержит несколько цехов: дорожная лаборатория связи, ЛАЗ (линейно-аппаратный зал), телеграф, АТС, кабельный цех, контрольно-испытательный пункт (КИП) связи, цех кабельной магистрали и другие службы, для оперативной работы на линии, а также обеспечения бесперебойного функционирования всех видов оперативно-технической связи.

Управляет работой  РЦС начальник регионального  центра связи, он имеет двух заместителей. Так же РЦС имеет свой отдел  кадров, бухгалтерию. Цехами же управляют  старшие механики.

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

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

ЮУЖД включает в себя пять региональных центров связи  по станциям Челябинск (РЦС-1), Оренбург (РЦС-2), Курган (РЦС-3), Златоуст (РЦС-4), Карталы (РЦС-5), а так же ШЧ-2 станции Петропавловск. Дорожная лаборатория связи осуществляет контроль, обслуживание и бесперебойность работы всех вышеуказанных центров связи.

При возникновении повреждений линий связи, сбоев и отказов в работе цифрового оборудования в дорожную лабораторию связи из центров технического управления (ЦТУ) и линейно-аппаратных залов (ЛАЗ) поступают заявки о регистрации происшествий по всем РЦС ЮУЖД.

2.2 Постановка общей задачи курсовой работы

Задачей курсовой работы является разработка единой базы повреждений  цифрового оборудования.

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

При поступлении заявки из ЛАЗа или  ЦТУ происходит её регистрация в  единой базе повреждений.

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

БД должна обеспечивать возможности:

– просмотр единой базы повреждений по всем РЦС;

– подсчёт общего количества повреждений по всем РЦС;

– подсчёт количества повреждений  по всем РЦС за требуемый период;

– запрос показателей повреждений  по заданному РЦС;

– запросы количества повреждений  по требуемому типу оборудования;

– подсчёт количества повреждений  по конкретному названию аппаратуры;

– анализ количества неисправностей и отказов;

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

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

 

3 Проектирование  базы данных

Основными требованиями, предъявляемыми к любой БД, являются:

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

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

  1. инфологическое проектирование;
  2. логическое проектирование БД;
  3. физическое проектирование БД.

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

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

С точки зрения инфологического  проектирования, предметная область  дорожной лаборатории – это набор  оборудования, линий связи и обрабатываемых повреждений. При этом нас интересует тип объектов, например, «Тип оборудования», но не интересуют отдельные объекты, например, «Мультиплексор SDH».

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

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

Для определения связи  между сущностями их делят на сильные  и слабые. Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования  сильных. Например, «Тип повреждения» – сильная сущность, а «Количество повреждений» – слабая, поскольку условием её существования является наличие определённого типа повреждения, требующего обработки.

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

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

Например, сущность «Тип оборудования» имеет идентифицирующий атрибут «Условное обозначение», который однозначно указывает на один из типов оборудования. Именно этот атрибут мы будем использовать в качестве ПК. Атрибут «Тип аппаратуры» (класс оборудования, например «Аппаратура SHDSL») является описательными.

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

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

Информация о работе База данных