Базы данных для станции технического обслуживания

Всего существует шесть типов страниц:

1. Data-в страницах этого типа хранятся собственно данные, исключая данные типа text, ntext и image.
2. Index-страницы этого типа используются для хранения информации об индексированных таблицах.
3. Text/Image - в страницах этого типа хранятся данные типа text, ntext и image.
4. Global Allocation Map (GAM) - в страницах данного типа хранится информация об использовании экстентов (групп страниц).
5. Page Free Space - в страницах этого типа хранится информация о свободном пространстве на страницах.
6. Index Allocation Map (IAM) - страницы этого типа хранят информацию об экстентах, используемых таблицами или индексами.

На логическом уровне рассматриваются объекты, которые можно создавать в базе данных, а также различные свойства, которые влияют на работу сервера с базой данных. В список этих объектов входят: таблицы (tables), представления (views), индексы (indexes), ключи (keys), правила (rules), ограничения целостности (constraints), хранимые процедуры (stored procedures), триггеры (triggers), умолчания (defaults), определяемые пользователем типы данных (user-define data types, UDDT), определяемые пользователем функции (user-define function). [17]

4. Задачи администратора MS SQL Server

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

1. Архивирование базы данных и восстановление системы после сбоя. Пожалуй, это самая серьезная из всех задач, поскольку ее выполнение обеспечивает целостность и надежную работу базы данных. В рамках этой задачи создаются резервные копии баз данных и проверяется их корректность. Важность архивирования заключается в том, что при отказе системы восстановление баз данных возможно только из резервной копии и, если эти копии выполнялись неправильно или не выполнялись вообще, то это может быть угрозой потери данных. [10,c.742]
2. Планирование емкости. Администратор должен правильно оценивать необходимый объем ОЗУ, дискового пространства и мощность процессора, а также на основе этой информации составлять рекомендации по приобретению дополнительных ресурсов. [10,c.733]
3. Администрирование кластеров. Решение этой задачи требуется не всегда, а только в случае, если SQL Server работает совместно с Microsoft Cluster Server, применяемый для обеспечения отказаустойчивости.
4. Документирование. Администратор должен вести документирование всех аспектов системы базы данных, в том числе за документирование конфигурации аппаратуры и программного обеспечения, процедур инсталляции, задач технической поддержки, обновления программного обеспечения и документирование всех изменений в приложениях.
5. Импорт и экспорт данных. Импорт подразумевает под собой копирование информации SQL Server, хранящейся на различных внешних системах, а экспорт-предоставление внешним системам информации, хранящейся на SQL Server.
6. Мониторинг и настройка производительности. Одной из повседневных обязанностей администратора является контроль за производительностью и работой сервера. При реализации данных задач, как правило, подразумевается проверка нагрузки на сервер.
7. Администрирование репликаций. Технология репликаций позволяет копировать и перемещать любое количество данных в другое место, например из основной базы в тестовую. Процесс репликации должен происходить автоматически. [10. c.814]
8. Безопасность. Администратор отвечает за безопасность системы. Безопасность системы важна, потому что если кто-нибудь вторгнется в систему и разрушит или украдет данные, то фирма понесет серьезный урон. В качестве защиты можно использовать доступ к компьютеру по паролю.

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

 

2. Проектирование и реализация базы данных

1. Анализ предметной области

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

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

Станция технического обслуживания оказывает следующие виды услуг:

1. Ремонт ходовой части.
2. Мойка автомобиля.
3. Кузовной ремонт.
4. Ремонт топливной системы.
5. Ремонт КПП.
6. Ремонт главной передачи.
7. Ремонт и замена стекол.
8. Установка и ремонт сигнализаций.
9. Шиномонтаж.
10. Замена масла.
11. Аэрография.
12. Установка акустических систем.
13. Ремонт ДВС.
14. Ремонт электрооборудования.

Для наглядного представления всего процесса, была построена графическая модель по методологии IDEF0. IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

Описание системы с помощью IDEF0 называется функциональной моделью. Функциональная модель предназначена для описания существующих бизнес-процессов, в котором используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником графического языка является сама методология IDEF0. Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы – диаграммы наиболее абстрактного уровня описания системы в целом. Контекстная диаграмма представляет собой самое общее описание системы и ее взаимодействия с внешней средой. [7, c. 39]

Для разработки функциональной модели был использован AllFusion Process Modeler, поскольку он является мощным программным продуктом, с помощью которого можно  проводить моделирование, анализ, описание и последующую оптимизацию бизнес-процессов, а также создавать их графические модели. Программный продукт AllFusion Process Modeler совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3).

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

На рисунке 1 представлена контекстная диаграмма деятельности станции технического обслуживания.

 

Рисунок 1- Контекстная диаграмма

Так, по контекстной диаграмме деятельности СТО, можно увидеть общий принцип ее работы. Для более детального проектирования воспользуемся DFD (от англ. Data Flow Diagrams) — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. [16]

Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Главная цель такого представления - продемонстрировать, как каждый компонент преобразует свои входные данные в выходные, а также выявит отношения между этими процессами. Стрелки в DFD показывают, как объекты (данные) перемещаются от одного действия к другому. Это представление потока вместе с хранилищами данных и внешними сущностями обеспечивает отражение в DFD-моделях таких физических характеристик системы, как движение объектов (потоки данных), хранение объектов (хранилища данных), источники и потребители объектов (внешние сущности).[15]

 

Рисунок 2 -Диаграмма декомпозиции деятельности станции СТО

Из данной диаграммы декомпозиции видно, что основными процессами, описывающими деятельность СТО, являются:

1. Регистрация клиента. Сотрудник СТО фиксирует фамилию, имя, отчество клиента, а также номер его контактного телефона.
2. Прием заявки на ремонт. Сотрудник принимает от клиента заявку на ремонт, в которой записывает марку автомобиля, производителя, номер кузова, характеристики двигателя, также вносится услуга и ее стоимость.
3. Внесение платы за ремонт. Клиент оплачивает услугу по ремонту.
4. Ремонт автомобиля.

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

2. Концептуальное и логическое проектирование базы данных

Концептуальная модель представляет собой описание основных сущностей (таблиц) и связей между ними без учета принятой модели БД и синтаксиса целевой СУБД. Цель концептуального проектирования – создание концептуальной модели данных на основе представлений о предметной области каждого отдельного типа пользователей.  Часто на такой модели отображаются только имена сущностей (таблиц) без указания их атрибутов. Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания. [13, с. 178]

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

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

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

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

Исходя из диаграммы DFD можно выделить следующие сущности:

1. Список клиентов, куда вводится фамилия, имя, отчество и телефон. Кроме того, в этой сущности должна находиться информация о балансе каждого клиента.
2. Справочник с видами услуг, оказываемых на станции технического обслуживания.
3. Справочник автомобилей, дающий информацию о марке, производителе, кузове, двигателе и приводе.
4. Список заказов. Содержит информацию о заказах на ремонт каждого из клиентов: стоимости работы, внесенной оплате, марке автомобиля, дате заказа.

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

Все сущности имеют связь друг с другом. Связь – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

Связи между объектами могут быть трех типов:

• Один к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот.
• Один ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта первого вида. [12, c.46]
• Многие ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, и наоборот.

Рисунок 3- Концептуальная модель базы данных

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

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

С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. [18]

Рисунок 4- Логическая модель базы данных

3. Физическая реализация базы данных

Разрабатываемая нами реляционная база данных будет представлять собой множество взаимосвязанных двумерных таблиц (отношений), у каждой из которых будет уникальное имя и состоящая из строк-записей (кортежей) и столбцов - полей (атрибутов). Каждая запись представляет объект реального мира. Свойства объекта, его характеристики определяются значениями полей. Каждое поле имеет имя, тип и размер данных, хранимых в нем. Имена полей вынесены в шапку таблицы. Структура реляционной таблицы определяется составом полей. Каждое поле отражает определенную характеристику сущности. [18]