База данных. 5

Федеральное агентство  железнодорожного транспорта

Челябинский институт путей  сообщения – филиал

государственного образовательного учреждения высшего профессионального  образования «Уральский государственный  университет путей сообщения»

(ЧИПС УрГУПС)

 

«____» ____________ 20____ г.

                                                         Кафедра ВТ

 

 

 

 

 

 

КУРСОВАЯ РАБОТА

 

по дисциплине: Управление данными.

 

 

 

 

 

 

 

Проверил:                                                                     Выполнил:

преподаватель                                                             студент группы ИТ-3 курса

Попов В. Г.                                                                 Флягин Илья Николаевич

                                                                      шифр: 2010-ИТ-1227

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Челябинск

2013

 

Задание

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

 

Реферат

Курсовая работа содержит 30 страниц, 6 таблиц, 2 источника, 15 рисунков.

База данных, инфологическая модель, сущность, связь, ER-диаграмма, отношение, реляционные СУБД, атрибут, ссылочная целостность.

 

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

При выполнении курсового проекта были использованы программные пакеты Microsoft Visio, Microsoft Office Access.

 

Содержание

 

 

Введение

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

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

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

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

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

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

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

 

1 Теория баз данных

1.1 Реляционная  модель

Реляционная модель данных предложена сотрудником Фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам – атрибуты отношения.

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

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

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

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

1.2 Архитектура реляционных баз данных

Архитектура системы баз данных (БД) состоит из следующих четырех компонентов: аппаратного обеспечения, программного обеспечения, пользователей, данных. Такая архитектура систем БД с достаточной точностью описывает широкий класс систем БД.

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

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

Классом объектов называется совокупность объектов, обладающих одинаковым набором свойств. Объекты и их свойства являются понятиями реального мира, в теории БД говорят об атрибутах объектов.

Атрибут – это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

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

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

Данные в таблицах удовлетворяют  следующим принципам:

1) каждое значение, содержащееся на пересечении строки и столбца, должно быть атомарным (не расчленяемым на несколько значений);

2) значения данных в одной и той же колонке должны принадлежать к одному и тому же типу, доступному для использования в данной СУБД;

3) каждая запись в таблице уникальна (в таблице нет двух записей с совпадающим набором значений её полей);

4) каждое поле имеет уникальное имя;

5) последовательность полей в таблице несущественна;

6) последовательность записей также несущественна (однако любая СУБД позволяет сортировать строки и колонки).

В реляционной модели рассматриваются  три аспекта данных – структура данных, целостность данных и обработка данных.

1.3 Ключи и связи

Поскольку строки в таблице неупорядочены, необходимо иметь колонку (или набор из нескольких колонок) для уникальной идентификации каждой строки. Такая колонка (или их набор) называется первичным ключом (primary key, ПК). ПК любой таблицы обязан содержать уникальные непустые значения для каждой строки. Если ПК состоит более чем из одной колонки, то он называется составным первичным ключом (composite primary key).

Типичная БД обычно состоит из нескольких связанных таблиц. Таблицы связываются по какому-либо полю. Внешний ключ (foreign key, ВК) – это колонка или набор колонок, чьи значения совпадают с имеющимися значениями ПК другой таблицы.

Подобное взаимоотношение между  таблицами называется связью (relationship). Связь между двумя таблицами устанавливается путём присвоения значений ВК одной таблицы значениям ПК другой. Причём связь может быть «один-к-одному» (one-to-one relationship) – если каждое значение поля ПК одной таблицы может встречаться только один раз в поле ВК другой; или «один-ко-многим» (one-to-many relationship) если каждое значение поля ПК одной таблицы может встречаться ноль, один или несколько раз в поле ВК другой. Последняя связь также имеет название master-detail (таблица с ВК – detail-таблица, а таблица с ПК – master-таблица).

Группа связанных данных называется схемой БД (database schema). Информация о таблицах, их колонках (имена, тип данных, длина поля), ПК и ВК, а также иных объектах БД, называется метаданными (metadata). Любые манипуляции с данными в БД называются запросом к БД (query). Обычно запросы формулируются на каком-либо языке (стандартным для разных СУБД или зависящим от конкретной СУБД).

1.4 Ссылочная целостность

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

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

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

1.5 Операции над данными

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

1) операции над множествами:  объединение, пересечение, вычитание  и декартово произведение;

2) специальные реляционные  операции: выборка, проекция, соединение  и деление.

Операторы первой группы.

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

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

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

Операторы второй группы.

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

Проекцией отношения А по атрибутам 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») является описательными.

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

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

База данных. 5