БД Автосервис

     Там же – вводится состав выполняемых  работ и ФИО сотрудников автосервиса, их выполняющих. А также – сведения о составе и количестве использованных запчастей.

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

Категории пользователей  

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

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

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

Введем следующие  понятия и условные обозначения:  

Сущности  

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

Сущности будем обозначать прямоугольниками,  

Атрибуты  сущности 
 

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

 

Имена атрибутов будем заносить в прямоугольник,

обозначающий  сущность, под именем сущности, и писать

малыми буквами.   

Взаимосвязи   

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

  
 

Связи – обозначим линиями, над которыми будем проставлять степень связи («1» или «∞», обозначающую "много") и ее характеристики.

 
 
 

Ключевые  поля  

Определим понятие  первичных и внешних ключей

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

Один из них  принимается за первичный ключ.

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

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

Внешние ключи

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

 

Примечание:   

1. Поскольку разработчики СУБД MS Access изначально учли проблемы, возникающие с первичными и внешними ключами, в Access был введен специальный тип поля – КЛЮЧЕВОЕ ПОЛЕ. Его тип – СЧЕТЧИК.

     Access не требует его обязательного включения в таблицу. Но настоятельно предлагает.

Особенности этого  типа поля таковы:

• При вводе новой записи – в этом поле АВТОМАТИЧЕСКИ формируется новое, уникальное, неповторяющееся числовое значение.
• Поле не может принимать неопределенное значение.
• Поле – автоматически индексируется.
• Ручное изменение значения этого поля невозможно.

 

 

Поэтому проблема ключевых полей и внешних ключей в Access решается просто:

• В главной таблице (сущности) создаем специальное ключевое поле. Оно и будет у нас первичным ключем.
• В подчиненные таблицы вводим его копию (с тем же названием). Это будет их внешний ключ.
• Связываем по этим полям главную и подчиненную таблицы. Вот и все. Связь реализована!

2. Ввели в Access разработчики и инструмент, который называется «Схема данных»           

 Которая позволяет  не только связать таблицы, но и указать для каждой связи:

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

 

 

Что необходимо указывать и при построении ER – модели базы данных.  

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

 При реализации нашей ER – модели в Access мы всеми этими возможностями и воспользуемся.  

Индексы   

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

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

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

 Поэтому при  использовании индексов полезно  «знать меру».  

Схема данных  

     Одной из важнейших целей при разработке Схемы данных БД является нормализация сущностей (или «объектов», или «таблиц»), поэтому полезно будет определить также понятие нормализации и определения нормальных форм ER – моделей  

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

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

     Всякая  нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ.

     Таким образом, строго говоря, "нормализованная" и "находящаяся в 1НФ" означают одно и то же.  

В первой нормальной форме ER-модели устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.

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

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.

И т.д.

Чисто практически основные этапы разработки схемы данных выглядят так:  

Шаг I: Считаем единственной «сущностью» - предприятие «Автосервис».

Все остальное  – ее атрибуты.

Шаг II: Проведем ее анализ на предмет – что из перечисленных атрибутов можно выделить в отдельный информационный объект (таблицу). И что после этого в исходной сущности останется.             

 Сразу видно,  что в первую очередь таких  объектов как минимум три:

• «Mechanics»
• «Orders»
• «Requests»

 

  

Примечания:

1. Чтобы в  дальнейшем их было легче связать,  одновременно введем в объект  «Mechanics» ключевое поле «MechanicId» (это – первичный ключ), а в выделенные нами новые таблицы - его копии с тем же названием. Это будут внешние ключи.

     Access такие возможности предоставляет. Вот и воспользуемся ими!           

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

     Оформление  полностью соответствует правилам оформления ER – моделей. Ключевые атрибуты (первичные ключи) уже выделены жирным шрифтом.

     А поскольку для таблиц был проведен первый этап нормализации, таблица  «Requests» автоматически становится таблицей в первой нормальной форме (1НФ).

А вновь появившиеся  таблицы 

     «Orders».

     «Mechanics»

таблицами во второй нормальной форме (2НФ). 

Вот как выглядит наша схема сейчас  

  

Особенности реализации  

Учет  специфики предметной области  

     Сфера услуг автосервиса – достаточно специфична.

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

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

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

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

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

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

 Как следствие  – реализованная БД «Автосервис» в достаточной мере отражает специфику выбранной предметной области.