Автоматизированная система сервисного центра

                                                         Рисунок 2.1 – ER-диаграмма

 

 

 

 

 

 

 

 

 

3 РАЗРАБОТКА ЛОГИЧЕСКОЙ  СХЕМЫ БАЗЫ ДАННЫХ

 

3.1 Построение реляционной  модели

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

Любую простую сетевую  структуру можно преобразовать  в древовидную, введя избыточность.

Сотрудник

Клиент

Бренд

Работа

Изделие

Работа

 

 

 

Рисунок 3.1- Древовидная модель

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

Логическую схему  базы данных будем строить на основании  разработанной ER-диаграммы.

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

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

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

 

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

Приведение  модели к требуемому уровню нормальной формы является основой построения реляционной БД.

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

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

Схема отношений должна удовлетворять  следующим требованиям:

1. Выбранные для отношения первичные ключи должны быть минимальными;
2. Выбранный состав отношений БД должен быть минимален, то есть отличаться минимальной избыточностью атрибутов;
3. При выполнении операций модификации, удаления и включения не должно быть трудностей;
4. Перестройка набора отношений, приведение новых типов данных должна быть минимальной;
5. Разброс времени ответа на различные запросы к БД должен быть небольшим.

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

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

Имеем следующие отношения  в 1НФ:

Работа (Номер работы,вид работы, номер изделия,номер сотрудника)

Клиент (Номер клиента, ФИО клиента, адрес, телефон)

Изделие (Номер изделия, вид изделия, магазин, дата выпуска, дата продажи, номер клиента)

Сотрудники(Номер сотрудника, вид сотрудника, ФИО сотрудника)

Бренд (Название бренда, адрес представителя) 

Теперь все таблицы  рассматриваемой базы данных находятся  в 1НФ, так как выполняется условие  атомарности и выделены первичные  ключи:

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

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

Имеем следующие отношения  во 2 НФ:

Работа (Номер работы,вид работы, номер изделия,номер сотрудника)

Клиент (Номер клиента, ФИО клиента, адрес, телефон)

Изделие (Номер изделия, вид изделия, магазин, дата выпуска, дата продажи,  номер клиента)

Сотрудники(Номер сотрудника, вид сотрудника, ФИО сотрудника)

Бренд (Название бренда, адрес представителя) 

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

Транзитивная  зависимость выявляет дублирование данных в одном отношении. Если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно  зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения  на два.

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

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

В разработанной БД ключевыми  полями являются:

• Номер работы;
• Номер клиента
• Номер изделия;
• Номер сотрудника.
• Название бренда

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

Рисунок 3.2 – БД после нормализации

        

 

 

 

 

 

 

 

 

 

 

 

4 РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ

 

4.1 Разграничение прав  доступа

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

• Администратор;
• Менеджер;
• Инженер.

1. Администратор имеет неограниченный доступ. Он  осуществляет работу с базой данных. Возможности администратора:

• занесение данных;
• обновление данных
• вставка записей;
• удаление некоторой информации;
• поиск необходимой информации.

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

3. Инженер также должен иметь ограниченный доступ к информации, 

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

Администратор

    Таким образом, будет получена следующая системная организация проекта (Рисунок 4.1.):

Менеджер

 

Инженер

 

 

 

Рисунок 4.1. – Разграничение доступа

4.2. Организация  секретности

 

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

В данном проекте характер базы данных предполагает разграничение  доступа на редактирование данных.

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

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

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

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

4.3.   Целостность базы данных

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

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

  Выделяют три группы правил целостности:

1. Целостность по сущностям. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
2. Целостность по ссылкам. Значение внешнего ключа должно либо:

• быть равным значению первичного ключа цели;
• быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным

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

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

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

 

 

 

 

 

 

5 ИССЛЕДОВАНИЕ ИНФОРМАЦИОННЫХ ПАРАМЕТРОВ БАЗЫ ДАННЫХ

       Длина логической записи j-ого файла:

                                        [байт]   

L1=10+70+20+60=160 byte

L2=9+25+15+8+8=65 byte

L3=25+15=40 byte

L4=9+25=34 byte

L5=9+8+70+15+10+15+25+8=160 byte

 

        Объем памяти, необходимый для размещения информационного фонда без учёта системных данных и указателей составит:

                [байт]  где N - количество отношений реляционной базы данных, K _j - количество записей j-го файла.

I=10*160+10*65+10*40+10*34+10*160=4590 byte.

Приращение информационного  фонда

            [байт^-1]  где - число добавленных типов записей, - интенсивность добавления записей в файл j -го :

DI = 20+160+65*20+160*20= 7700.

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

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

                                                            

                                                      T= 0.2*4590/7700=0,11

Количество обращений  к логическим записям

 где  - количество обращений к записям j -го типа в i -м запросе.

N1=4

N2=4

N3=4

N4=2

N4=3

 

Интенсивность обращений  к информационному фонду

  где - частота выполнения i - того запроса, Z - число запросов, обработка которых предусмотрена СУБД.

- данная переменная выражается  константой исходя из соображений  работы                        = 0,95; = 0,8;  = 0,75; = 0,7;  = 0,7;