Реферат: Проектирование компонентов информационной системы для ООО технический центр «курс»

ОГЛАВЛЕНИЕ


ГЛАВА 2. ПРОЕКТИРОВАНИЕ КОМПОНЕНТОВ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ООО ТЕХНИЧЕСКИЙ ЦЕНТР «КУРС»…………………………....2

Основные объекты предметной области……………………………………3

Концептуальная модель………………………………………………………9

Нормализация базы данных………………………………………………...12

Даталогическая модель базы данных………………………………………14

Ограничения целостности БД………………………………………………25

Структура программы……………………………………………………….33

Алгоритмы…………………………………………………………………...33

Обоснование выбора модели данных………………………………………31

Обоснование выбора СУБД………………………………………………...31

Обоснование выбора среды проектирования……………………………...33



^ ГЛАВА 2. ПРОЕКТИРОВАНИЕ КОМПОНЕНТОВ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ООО ТЕХНИЧЕСКИЙ ЦЕНТР «КУРС»

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

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

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

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

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


2.1. Основные объекты предметной области

Исходя из анализа предметной области ООО Технический Центр «Курс» и документооборота, можно определить основные объекты предметной области:

клиенты;

автомобиль;

сотрудник;

заявка на работы;

заказ-наряд.

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

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

На основе анализа информационных запросов выявляются связи между основными объектами, охарактеризованные и представленные в таблице 2.1.

Таблица 2.1

Связи между основными объектами предметной области

Объекты, участвующие в связи

Краткое описание

Клиент и заявка на работы

(1:М)

Клиент и заказ-наряд

(1:М)

Сотрудник и клиент

(1:М)

Сотрудник и заявка на работы

(1:М)

Сотрудник и заказ-наряд

(1:М)

Клиент и автомобиль

(1:1)

Заявка на работы и автомобиль

(1:1)


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



Концептуальная модель

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

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

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

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

идентификацию характеристик этих сущностей;

идентификацию взаимосвязей между сущностями;

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

Концептуальная модель состоит из следующих трех основных компонентов:

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

Атрибуты. Они описывают сущность. Атрибуты представляются овалами с указанием имен, которые прикреплены к сущности. В данном случае заказ-наряду соответствуют: код заказ-наряда, номер, дата, код клиента, валюта взаиморасчетов, номер дисконтной карты, тип клиента, код автомобиля, пробег автомобиля, код нормо-часа, вид ремонта, скидка на работы, %, скидка на запасные части, %, дата приема в ремонт, дата окончания ремонта, код детали, код работы, количество, единица измерения, цена, сумма, код сотрудника. Клиентам соответствуют: код клиента, фамилия, имя, отчество, улица, дом, квартира, телефон, серия паспорта, номер паспорта, кем выдан паспорт, дата выдачи паспорта, код автомобиля, тип клиента. Сотруднику соответствуют: код сотрудника, фамилия, имя, отчество, адрес прописки, доступный склад, серия паспорта, номер паспорта, кем выдан паспорт, дата выдачи паспорта. Заявке на работы соответствуют: код заявки на работы, код клиента, дата, номер, код детали, код нормо-часа, код работы, количество, цена, сумма.

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

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

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

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

После передачи клиентом документов для оформления ремонта автомобиля приемщик-кассир поручает проведение работ по ремонту автомобиля автомеханику, который становится ответственным за выполнение работ.

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

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

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

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

сотрудник;

автомобиль;

клиент;

заявка на работы;

заказ-наряд.

Взаимоотношения между этими объектами показаны на диаграмме, изображенной в виде концептуальной модели, на рисунке 2.1.



Рисунок 2.1. Концептуальная модель

Объекты, которые имеют связь один-ко-многим (1:М):

один клиент может подать более одной заявки на работы;

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

один сотрудник может обслужить более одного клиента;

один сотрудник может составлять более одной заявки на работы;

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

один сотрудник может формировать более одного заказ-наряда.

Объекты, которые имеют связь один-к-одному (1:1):

один клиент может иметь один автомобиль;

одна заявка на работы может подаваться на один автомобиль.



2.4. Обоснование выбора модели данных

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

Каждая запись таблицы имеет одинаковую структуру.

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

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

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

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



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

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

возможность хранить все необходимые данные в базе данных;

исключение избыточности данных;

необходимость свести количество хранимых таблиц к минимуму.

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

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

Нормальные формы подчиняются правилу вложенности по возрастанию номеров.

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

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

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

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

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

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

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

Нормализация производится по следующему алгоритму:

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

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

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

Ключевым атрибутом для объекта «Клиент» является – код клиента. Этот ключ добавляется, в качестве атрибута, в объект «заказ-наряд».


Таблица 2

Клиент

Код клиента

Фамилия

Имя

Отчество

Улица

Дом

Квартира

Телефон

Серия паспорта

Номер паспорта

Кем выдан паспорт

Дата выдачи паспорта

Код автомобиля

Тип клиента

0001

Акамов

Вячеслав

Викторович

Спортивная

17

361

50-26-10

36 05

951234

АРУВД

21.01.05

0001

Частное лицо

0002

Гарина

Юлия

Николаевна

Голосова

1

111

33-52-25

36 04

314802

ЦРУВД

30.05.06

0002

Частное лицо

0003

Диков

Василий

Иванович

Баныкина

2

3

20-15-05

36 05

915010

ЦРУВД

09.10.07

0003

Частное лицо

0004

Клочко

Рауль

Русланович

Тополиная

40

100

74-22-05

36 09

201752

АРУВД

10.11.06

0004

Частное лицо

0005

Иванов

Рустам

Витальевич

Свердлова

3

365

16-05-51

36 04

554345

АРУВД

27.03.08

0005

Частное лицо

0006

Амуров

Игорь

Аркадьевич

Ленина

30

113

90-58-14

36 04

905641

ЦРУВД

20.02.05

0006

Частное лицо

0007

Кротова

Елена

Сергеевна

Карбышева

6

33

72-05-64

36 05

465458

ЦРУВД

01.01.04

0007

Частное лицо

0008

Токарева

Светлана

Ивановна

Мира

83

10

48-22-50

36 03

215445

ЦРУВД

04.11.06

0008

Частное лицо

0009

Муромова

Наталья

Гавриловна

Победы

55

5

37-04-26

36 09

456872

ЦРУВД

11.12.07

0009

Частное лицо

0010

ЧОП «Форос»

—

—

Жукова

14

—

42-90-63

—

—

—

—

0010

Организация

0011

ООО «Потенциалбанк»

—

—

Революционная

77

—

50-12-90

—

—

—

—

0011

Организация

0012

ОАО «ВолгаТелеком»

—

—

Самарская

68

—

72-08-08

—

—

—

—

0012

Организация



Таблица 3

Сотрудник

Код сотрудника

Фамилия

Имя

Отчество

Адрес прописки

Доступный склад

Серия паспорта

Номер паспорта

Кем выдан паспорт

Дата выдачи паспорта

0001

Окрошкин

Иван

Семенович

Матросова, д. 10, кв. 11

Курс

36 09

574545

КРУВД

01.10.05

0002

Кукушкина

Светлана

Викторовна

Ленина, д. 62, кв. 22

Курс

36 01

156834

ЦРУВД

20.01.08

0003

Ватрушкина

Наталья

Олеговна

Мира, д. 60, кв. 100

Курс

36 09

268457

ЦРУВД

31.11.01

0004

Паймушкина

Галина

Анатольевна

Тополиная, д. 14, кв. 103

Курс

36 05

947745

АРУВД

09.05.05

0005

Ловушкина

Ольга

Николаевна

Жукова, д. 11, кв. 130

Курс

36 06

345545

АРУВД

08.10.07

0006

Копушин

Сергей

Алексеевич

Свердлова, д. 80, кв. 140

Курс

36 02

787878

АРУВД

17.10.08

0007

Наймушин

Петр

Антонович

Мира, д. 101, кв. 100

Курс

36 08

898989

ЦРУВД

07.02.06

0008

Сопрушин

Олег

Владимирович

Комсомольская, д. 3, кв. 8

Курс

36 05

323232

ЦРУВД

29.08.02

0009

Индюшкина

Софья

Владимировна

Матросова, д. 20, кв. 47

Курс

36 09

121212

КРУВД

19.12.04

0010

Хлопушкина

Тамара

Александровна

Революционная, д. 10, кв. 206

Курс

36 04

111222

АРУВД

22.04.01

0011

Ликушкина

Татьяна

Алексеевна

Карла Маркса, д. 47, кв. 36

Курс

36 04

987789

ЦРУВД

24.10.03



Таблица 4

Заказ-наряд

Код заказ-наряда

Номер

Дата

Код клиента

Валюта взаиморасчетов

Номер дисконтной карты

Тип клиента

Код автомобиля

Пробег автомобиля

Код нормо-часа

Вид ремонта

0390

390

01.04.09

0012

Руб.

–

Организация

1023

99207

0106

Текущий ремонт

0411

411

10.04.09

0098

Руб.

3644584

Частное лицо

0706

100020

1108

Текущий ремонт

0527

527

12.04.09

0111

Руб.

–

Организация

0290

80000

0860

Текущий ремонт

0531

531

12.04.09

0078

Руб.

–

Частное лицо

0340

27900

0310

Текущий ремонт

0596

596

14.04.09

0039

Руб.

–

Частное лицо

0109

120700

0576

Текущий ремонт

0644

644

17.04.09

0050

Руб.

1568878

Организация

0400

64700

0900

Текущий ремонт

Продолжение Таблицы 4

Скидка на работы, %

Скидка на запасные части, %

Дата приема в ремонт

Дата окончания ремонта

Код детали

Код работы

Количество

Единица измерения

Цена

Сумма

Код сотрудника

–

–

01.04.09

01.04.09
















15025

0009

10

10

09.04.09

10.04.09
















11250

0003

–

–

10.04.09

12.04.09
















25680

0011

–

–

12.04.09

12.04.09
















1100

0003

–

–

14.04.09

14.04.09
















3280

0003

15

15

15.04.09

17.04.09
















50680

0007



Таблица 5

Автомобиль

Код автомобиля

Наименование

Категория ТС

Код нормо-часа

Государственный номер автомобиля

Номер кузова автомобиля

Номер двигателя внутреннего сгорания автомобиля

Пробег автомобиля

Год выпуска автомобиля

1890










Н 867 ЕМ







10247

2008













О 999 ЛЯ







57454

2000













К 777 ОТ







85855

2003













П 190 ОТ







43544

2007













Н 341 ОС







65235

2006













Р 363 ОТ







45890

2007

0760










Х 666 ХХ







39680

2009



Таблица 6

Заявка на работы

Код заявки на работы

Код клиента

Дата

Номер

Код детали

Код нормо-часа

Код работы

Количество

Цена

Сумма

0280

0560

25.03.09

280



















0306

0970

26.03.09

306



















0311

1100

27.03.09

311



















0360

1182

31.03.09

360



















0391

0808

01.04.09

391





















При проектировании базы данных были соблюдены принципы нормализации:

любое не ключевое поле каждой таблицы функционально зависит только от первичного ключа, а не от его части (если ключ составной);

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




Даталогическая модель базы данных

На основании построенной концептуальной модели разрабатывается реляционная модель данных, которая будет реализована в выбранной СУБД (MySQL). Каждому объекту ставится в соответствие реляционная таблица.

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

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

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

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

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

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

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


Таблица 3

Таблица Spravochnik_Klients даталогической базы данных

Наименование

Комментарий

1

2

Kod_klienta

Код клиента

Familiya

Фамилия клиента

Name

Имя клиента

Otchestvo

Отчество клиента

Street

Улица

House

Дом

Kvartira

Квартира

Phone

Телефон

Seriya_pasport

Серия паспорта клиента

Number_pasport

Номер паспорта клиента

Kem_vidan

Кем выдан паспорт клиента

Date_vidahi

Дата выдачи паспорта клиента

Kod_avto

Код автомобиля клиента

Tip_klienta

Тип клиента


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

Внешним ключом является поле Kod_avto, которое связывается с таблицей Spravochnik_avtomobilei.

Таблица Zakaz_nariad, показанная в таблице 4, содержит сведения о всех заказ-нарядах клиентов, хранящихся в базе данных.


Таблица 4

Таблица Zakaz_nariad даталогической модели базы данных

Наименование

Комментарии

1

2

Kod_zakaz_nariada

Код заказ-наряда

Number

Номер

Date

Дата

Kod_klienta

Код клиента

Valuta_vzaimorachetov

Валюта взаиморасчетов

Number_discontnoi_karti

Номер дисконтной карты

Tipe_klienta

Тип клиента

Kod_avto

Код автомобиля клиента

Probeg_avto

Пробег автомобиля

Kod_normo_chasa

Код нормо-часа

Vid_remonta

Вид ремонта

Skidka_na_rab

Скидка на работы, %

Skidka_na_zapch

Скидка на запасные части, %

Date_priema

Дата приема в ремонт

Date_okonch

Дата окончания ремонта

Kod_rab

Код работы

Kod_det

Код детали

Kolichestvo

Количество

Ed_izm

Единица измерения

Cena

Цена

Summa

Сумма

Kod_sotrud

Код сотрудника


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

Поле Kod_klienta является внешним ключом для таблицы Zakaz_nariad. По этому полю происходит связь этой таблицы с таблицей Spravochnik_Klients.

Поле Kod_avto также является внешним ключом. Он связывается с таблицей Spravochnik_avtomobilei.

Поле Kod_normo_chasa является внешним ключом, который связан с таблицей Spravochnik_kolichestva_normo_chasov, которая является справочной таблицей для таблицы Zakaz_nariad.

Поле Kod_det является внешним ключом, связанным с таблицей Spravochnik_detalei.

Поле Kod_rab является внешним ключом, который связывается с таблицей Spravochnik_rabot.

Поле Kod_sotrud является внешним ключом, связывающим с таблицей Spravochnik_sotrudnikov, которая является в свою очередь справочной таблицей для таблицы Zakaz_nariad.

Таблица Spravochnik_sotrudnikov, изображенная в таблице 5, содержит сведения о всех работниках, хранящихся в базе данных.

Таблица 5

Таблица Spravochnik_sotrudnikov даталогической модели базы данных


Рисунок 2.2. Даталогическая модель данных


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

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

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

Сущность «Заказ-наряд» (атрибуты: код заказ-наряда, номер, дата, код клиента, валюта взаиморасчетов, номер дисконтной карты, тип клиента, код автомобиля, пробег автомобиля, код нормо-часа, вид ремонта, скидка на работы, %, скидка на запасные части, %, дата приема в ремонт, дата окончания ремонта, код работы, код детали, количество, единица измерения, цена, сумма, код сотрудника) содержит информацию обо всех заказ-нарядах, оплачиваемых клиентами за оказанные услуги по техническому обслуживанию и ремонту автомобилей.

Сущность «Справочник работ» (атрибуты: код работы, наименование, цена, код нормо-часа) содержит информацию о выполняемых работах.

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

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

Сущность «Справочник автомобилей» (атрибуты: код автомобиля, категория ТС (A, B, C, D, E), код нормо-часа, государственный номер автомобиля, номер кузова автомобиля, номер двигателя внутреннего сгорания автомобиля, пробег автомобиля, год выпуска автомобиля) содержит сведения обо всех автомобилях клиентов, обслуживаемых станцией технического обслуживания автомобилей.

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

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

Сущность «Расходная накладная» (атрибуты: код расходной накладной, код клиента, номер, дата, код детали, валюта, единица измерения, количество, цена, сумма) содержит данные обо всех продажах автомобильных запасных частей клиентам.

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

Сущность «Заявка на работы» (атрибуты: код заявки на работы, код клиента, дата, номер, код детали, код нормо-часа, код работы, количество, цена, сумма) содержит информацию о требованиях клиентов, обратившихся за оказанием услуг станции технического обслуживания.

Атрибуты сущностей могут быть обязательными для заполнения информацией и необязательны.

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

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

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


Существуют следующие типы связей:

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

При связи «один-ко-многим» (1:М) одному экземпляру информационного объекта А соответствует любое количество экземпляров объекта В, но каждый экземпляр объекта В связан не более, чем с одним экземпляром объекта А. Отношения данного типа являются наиболее часто используемыми.

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

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

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


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

Справочник автомобилей содержит

Справочник работ содержит

Справочник деталей содержит

Справочник количества нормо-часов содержит

Справочник сотрудников содержит


2.6. Ограничения целостности БД

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

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

Ограничения делятся на явные и неявные.

Неявные ограничения определяются самой структурой данных.

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

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

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

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

Также различают статические и динамические ограничения целостности. Статические огра