Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Образец КП

.pdf
Скачиваний:
9
Добавлен:
24.03.2015
Размер:
978.02 Кб
Скачать

21

4.4 Нормализация базы данных

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

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

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

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

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

Все атрибуты всех сущностей атомарны, у каждой сущности выделены первичные ключи, следовательно, отношения находятся в 1 НФ.

Сущность «Корпус» имеет первичный ключ «ID корпуса».

22

Сущность «Помещение» имеет первичный ключ «ID помещения». Сущность «Вид помещения» имеет первичный ключ «ID вида помещения. Сущность «Опасность» имеет составной первичный ключ «ID корпуса», «ID

вида опасности», «ID категории опасности».

Сущность «Категория опасности» имеет первичный ключ «ID категории опасности».

Сущность «Вид опасности» имеет первичный ключ «ID вида опасности». Сущность «Проведённые работы» имеет первичный ключ «Код ремонта». Сущность «Вид ремонта» имеет первичный ключ «ID вида ремонта».

Сущность «Работы по ремонту» имеет первичный ключ «ID работы». Сущность «Состав ремонта» имеет составной первичный ключ «Код

ремонта», «ID работы».

Сущность «Наличие мощных электроустановок» имеет составной первичный ключ «ID электроустановки», «ID корпуса».

Сущность «Электроустановки» имеет первичный ключ «ID электроустановки».

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

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

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

23

Рассмотрим сущность «Наличие мощных электроустановок», первичный ключ состоит из атрибутов «ID электроустановки» и «ID корпуса». Неключевые атрибуты отсутствуют, поэтому можно сделать вывод, что данное отношение находится во 2НФ.

Рассмотрим сущность «Состав ремонта», первичный ключ состоит из атрибутов «Код ремонта» и «ID работы». Неключевые атрибуты отсутствуют, поэтому можно сделать вывод, что данное отношение находится во 2НФ.

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

Нормализация 2НФ-отношения с образованием 3НФ-отношения осуществляется путем устранения транзитивных зависимостей - транзитивнозависимые атрибуты удаляются из отношения и помещаются в новое отношение вместе с их детерминантом.

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

На основе приведенной нормализации можно сделать вывод о том, что отношение находится в 4НФ.

4.5 Физическое проектирование системы

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

В качестве последующей среды создания базы данных заказчиком была выбрана СУБД Firebird 2.1.

На основании логического проектирования были созданы следующие таблицы, описание которых приведено в таблицах 2-13.

24

Таблица 2 - Типы данных полей таблицы «Корпус»

 

Корпус

Атрибут

Тип данных

Атрибут

Числовой, целый

ID корпуса

Текстовый (20)

Адрес

Дата

Год постройки

Числовой, целый

Общая площадь

Числовой, целый

Учебная площадь

Числовой, целый

Общий объём

Текстовый (20)

Конструкторские особенности

Числовой, целый

Потребление электроэнергии в

Числовой, целый

летнее время

 

Потребление электроэнергии в

Числовой, целый

зимнее время

 

Пиковое потребление

Текстовый (20)

электроэнергии

 

Наличие мощных электрических

Числовой, целый

установок

 

Потребление тепла

Числовой, целый

Таблица 3 - Типы данных полей таблицы «Помещение»

 

Помещение

Атрибут

Тип данных

ID помещения

Числовой, целый

ID корпуса

Числовой, целый

ID вида помещения

Числовой, целый

Этаж

Числовой, целый

Площадь

Числовой, целый

Объём

Числовой, целый

Конструкторские особенности

Числовой, целый

Таблица 4 - Типы данных полей таблицы «Вид помещения»

 

Вид помещения

Атрибут

Тип данных

ID вида помещения

Числовой, целый

Вид помещения

Текстовый (20)

Таблица 5 - Типы данных полей таблицы «Опасность»

 

Опасность

Атрибут

Тип данных

ID корпуса

Числовой, целый

ID вида опасности

Числовой, целый

ID категории опасности

Числовой, целый

25

Таблица 6 - Типы данных полей таблицы «Вид опасности»

 

Вид опасности

Атрибут

Тип данных

ID вида опасности

Числовой, целый

Вид опасности

Текстовый(20)

Таблица 7 - Типы данных полей таблицы «Категория опасности»

 

Категория опасности

Атрибут

Тип данных

ID категории опасности

Числовой, целый

Степень опасности

Числовой, целый

Таблица 8 - Типы данных полей таблицы «Проведённые работы»

 

Проведённые работы

Атрибут

Тип данных

Код ремонта

Числовой, целый

ID вида ремонта

Числовой, целый

ID корпуса

Числовой, целый

ID помещения

Числовой, целый

Дата начала

Дата

Дата окончания

Дата

Таблица 9 - Типы данных полей таблицы «Вид ремонта»

 

Вид ремонта

Атрибут

Тип данных

ID вида ремонта

Числовой, целый

Вид ремонта

Текстовый(20)

Таблица 10 - Типы данных полей таблицы «Состав ремонта»

 

Состав ремонта

Атрибут

Тип данных

ID работы

Числовой, целый

Код ремонта

Числовой, целый

Таблица 11 - Типы данных полей таблицы «Работы по ремонту»

 

Работы по ремонту

Атрибут

Тип данных

ID работы

Числовой, целый

Наименование работы

Текстовый(20)

Цена работы

Числовой, целый

26

Таблица 12 - Типы данных

полей таблицы

«Наличие мощных

электроустановок»

 

Наличие мощных электроустановок

 

Атрибут

Тип данных

 

ID элетроустановки

Числовой, целый

 

ID корпуса

Числовой, целый

 

Таблица 13 - Типы данных полей таблицы «Электроустановки»

Электроустановки

 

Атрибут

Тип данных

 

ID элетроустановки

Числовой

 

Название электроустановки

Текстовый(20)

 

Физическая модель информационной системы приведена на рисунке Б.2 приложения Б.

5 Анализ целесообразности использования заданных средств разработки

Разработка АИС «Корпуса и аудитории» по требованию технического задания должна быть произведена с использованием технологии клиент-сервер.

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

Клиент, получив ответ от сервера, отображает полученные данные пользователю.

Тип архитектуры клиент-сервер был выбран, потому что он обладает приведенными ниже преимуществами:

- обеспечивает более эффективный доступ к базе данных;

27

-повышается общая производительность системы (клиенты и серверы находятся на разных компьютерах, на сервере выполняется только работа с БД);

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

-сокращаются коммуникационные расходы (существенно сокращается объем пересылаемых по сети данных);

-повышается уровень непротиворечивости данных (все ограничения определяются и проверяются только в одном месте – на сервере, каждому приложению не надо выполнять собственную проверку).

В качестве СУБД заказчиком был предложен FireBird 2.1. Firebird - это полнофункциональная, мощная СУБД способная обслуживать базы данных размером от нескольких килобайт до многих гигабайт.

Firebird полностью поддерживает стандартны ANSI в синтаксисе языка SQL

иможет работать под управлением многих операционных систем - Windows, Linux, MacOS, Solaris и различных Unix-платформах. Среди достоинств этой системы использование развитого языка для хранимых процедур и триггеров /2/.

Основные характеристики Firebird:

-полная поддержка хранимых процедур и триггеров;

-транзакции, полностью совместимые с концепцией ACID;

-ссылочная целостность;

-мощный внутренний язык для написания хранимых процедур и триггеров (PSQL);

-поддержка внешних пользовательских функций (UDF);

-безопасная запись данных (careful write) - быстрое восстановление после сбоев, отсутствие необходимости в журналировании транзакций;

-большое количество средств доступа к базе данных: native/API, драйверы dbExpress, ODBC, OLEDB, .Net provider, JDBC-драйвер, модули для Python, PHP, Perl, и так далее;

-поддержка большинства распространенных операционных систем, включая Windows, Linux, Solaris, MacOS.

28

В качестве среды разработки клиентского приложения была предложена среда Borland Delphi 7.

Borland Delphi 7 представляет собой уникальную систему разработки, в которой технология высокопроизводительной оптимизирующей компиляции сочетается с визуальными средствами разработки и масштабируемым процессором баз данных. Это позволяет создавать эффективные приложения Windows, работающие с базами данных, в том числе и приложения для систем клиент/сервер. Разработанные с помощью Delphi приложения, могут функционировать под практически любой 32 разрядной операционной системой типа Windows 95, 98, 2000, NT, XP.

Delphi - среда быстрого создания приложений и на данный момент является самой популярной средой разработки. Преимущества разработки на Delphi:

-быстрота разработки приложения;

-высокая производительность разработанного приложения;

-низкие требования разработанного приложения к ресурсам компьютера;

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

-высокопроизводительный компилятор в машинный код;

-объектно-ориентированная модель компонент;

-визуальное и скоростное построение приложений из программных прототипов;

-масштабируемые средства для построения баз данных.

Еще одним важным преимуществом разработки приложений в среде Delphi является то, что уровень абстракции данных позволяет легко переносить саму БД на любую другую платформу, например Interbase или Oracle. Т.е., при переходе от распределенных таблиц к серверу баз данных или SQL-серверу, изменения в самой программе оказываются ничтожно малы, либо вообще необязательны. Что безусловно уменьшит затраты и время в случае необходимости доработки приложения либо необходимости переноса БД на другую платформу /3/.

Основной упор Delphi делается на максимальном реиспользовании кода. Это позволяет строить приложения весьма быстро из заранее подготовленных

29

объектов, а также дает возможность создавать свои собственные объекты для среды Delphi. Никаких ограничений по типам объектов, которые могут создаваться, не существует. Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений, поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix, InterBase, а также FireBird происходит с высокой эффективностью.

Таким образом, предложенаая заказчиком СУБД FireBird 2.1 и среда разработки Borland Delphi 7 являются целесообразными в разработке АИС «Корпуса и аудитории».

30

6 Описание программы

6.1 Общие сведения

Информационная система называется «Корпуса и аудитории». Она разработана в среде Delphi 7 под управлением СУБД Firebird 2.1. Программа работает в операционных системах Windows 2000/NT/XP.

6.2 Функциональное назначение

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

6.3 Входные данные

Входные данные системы:

а) по корпусам – год основания, полная площадь, учебная площадь, дополнительная учебная площадь, объём, особенности конструкции, энергопотребление летом, энергопотребление зимой, пиковое энергопотребление, потребление тепла;

б) по помещениям – номер аудитории, корпус, этаж, тип помещения, площадь, объём, особенности конструкции;

г) по электроустановкам – корпус, электроустановка; д) по опасностям – корпус, вид опасности, степень опасности;

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]