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

Вид материалаДокументы

Содержание


Глава 2. проектирование компонентов информационной системы для ооо технический центр «курс»
3 Глава. разработка информационной системы
Подобный материал:
  1   2


ОГЛАВЛЕНИЕ


ГЛАВА 2. ПРОЕКТИРОВАНИЕ КОМПОНЕНТОВ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ООО ТЕХНИЧЕСКИЙ ЦЕНТР «КУРС»…………………………....2
    1. Основные объекты предметной области……………………………………3
    2. Концептуальная модель………………………………………………………9
    3. Нормализация базы данных………………………………………………...12
    4. Даталогическая модель базы данных………………………………………14
    5. Ограничения целостности БД………………………………………………25
    6. Структура программы……………………………………………………….33
    7. Алгоритмы…………………………………………………………………...33
    8. Обоснование выбора модели данных………………………………………31
    9. Обоснование выбора СУБД………………………………………………...31
    10. Обоснование выбора среды проектирования……………………………...33



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

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

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

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

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

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


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

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

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

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

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

Таблица 2.1

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

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

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

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

(1:М)

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

(1:М)

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

(1:М)

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

(1:М)

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

(1:М)

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

(1:1)

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

(1:1)


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


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

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

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

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

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

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

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

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

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

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

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

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

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



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

Объекты, которые имеют связь один-ко-многим (1:М):
  • один клиент может подать более одной заявки на работы;
  • один клиент может получить более одного заказ-наряда;
  • один сотрудник может обслужить более одного клиента;
  • один сотрудник может составлять более одной заявки на работы;
  • один клиент может получить более одного заказ-наряда;
  • один сотрудник может формировать более одного заказ-наряда.

Объекты, которые имеют связь один-к-одному (1:1):
  • один клиент может иметь один автомобиль;
  • одна заявка на работы может подаваться на один автомобиль.



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

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

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

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

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

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

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


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

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

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

Реляционная база данных должна быть подвергнута процедуре нормализации. Нормализованная база данных не подвержена дефектам обновления, добавления и удаления. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме Бойса-Кодда (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





















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



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

На основании построенной концептуальной модели разрабатывается реляционная модель данных, которая будет реализована в выбранной СУБД (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 даталогической модели базы данных

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

Комментарии

1

2

Kod_sotrud

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

Familiya

Фамилия сотрудника

Name

Имя сотрудника

Otchestvo

Отчество сотрудника

Adres_propiski

Адрес прописки сотрудника

Dostup_sklad

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

Seriya_pasport

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

Number_pasport

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

Kem_vidan

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

Date_vidahi

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


Первичным ключом таблицы Spravochnik_sotrudnikov является поле Kod_sotrud.

Таблица Spravochnik_sotrudnikov является справочной таблицей для таблицы Zakaz_nariad. Она содержит перечень всех сотрудников организации.

Таблица Rasxodnaia_nakladnaia, изображенная в таблице 6, содержит сведения о всех реализованных автомобильных запасных частях.


Таблица 6

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

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

Комментарии

1

2

Kod_ rasxodnoi_nakladnoi

Код расходной накладной

Kod_klienta

Код клиента

Number

Номер

Date

Дата

Kod_det

Код детали

Valuta

Валюта

Ed_izm

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

Kolichestvo

Количество

Cena

Цена

Summa

Сумма


В таблице Rasxodnaia_nakladnaia первичным ключом является поле Kod_ rasxodnoi_nakladnoi — номер, уникальный для каждой расходной накладной.

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

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

Таблица Prixodnaia_nakladnaia, показанная в таблице 7, содержит сведения о всех закупленных автомобильных запасных частях.


Таблица 7

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

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

Комментарии

1

2

Kod_ prixodnoi_nakladnoi

Код приходной накладной

Kod_klienta

Код клиента

Number

Номер

Date

Дата

Kod_det

Код детали

Valuta

Валюта

Ed_izm

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

Kolichestvo

Количество

Cena

Цена

Summa

Сумма


В таблице Prixodnaia_nakladnaia первичным ключом является поле Kod_ prixodnoi_nakladnoi — номер, уникальный для каждой приходной накладной.

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

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

Таблица Spravochnik_avtomobilei, показанная в таблице 8, содержит сведения о всех обслуженных автомобилях клиентов.


Таблица 8

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

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

Комментарии

1

2

Kod_avto

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

Naimenovanie

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

Kategoria_TC

Категория ТС (A, B, C, D, E)

Kod_normo_chasa

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

Gos_number_avto

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

Number_kuzova_avto

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

Number_dvig_vnutr_sgorania

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

Probeg_avto

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

God_vipuska_avto

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


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

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

Таблица Spravochnik_rabot, изображенная в таблице 9, содержит сведения о всех выполняемых работах с автомобилями.

Таблица 9

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

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

Комментарии

1

2

Kod_rab

Код работы

Naimenovanie

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

Cena

Цена

Kod_normo_chasa

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


В таблице Spravochnik_rabot первичным ключом является поле Kod_rab. Данная таблица является справочной.

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


Таблица 10

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

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

Комментарии

1

2

Kod_det

Код детали

Naimenovanie

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

Vid_tovara

Вид товара

Minimal_ostatok

Минимальный остаток

Valuta

Валюта

Roznich_cena

Розничная цена

Zakupoch_cena

Закупочная цена

Ed_izm

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


В таблице Spravochnik_detalei первичным ключом является поле Kod_det. Данная таблица является справочной.

Таблица Zaiavka_na_raboti, отображенная в таблице 11, содержит информацию о жалобах клиентов на неисправности своих автомобилей.

Таблица 11

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

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

Комментарии

1

2

Kod_zaiavki_na_rab

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

Kod_klienta

Код клиента

Date

Дата

Number

Номер

Kod_det

Код детали

Kod_normo_chasa

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

Kod_rab

Код работы

Kolichestvo

Количество

Cena

Цена

Summa

Сумма


В таблице Zaiavka_na_raboti первичным ключом является поле Kod_zaiavki_na_rab.

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

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

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

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

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

Таблица 12

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

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

Комментарии

1

2

Kod_tovarnogo_cheka

Код товарного чека

Kod_klienta

Код клиента

Number

Номер

Date

Дата

Number_kass_cheka

Номер кассового чека

Kod_det

Код детали

Ed_izm

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

Kolichestvo

Количество

Cena

Цена

Summa

Сумма


В таблице Tovarny_chek первичным ключом является поле Kod_tovarnogo_cheka.

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

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

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


Таблица 13

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

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

Комментарии

1

2

Identifikation_number

Идентификационный номер

Kod_det

Код детали

Ostatok

Остаток

Cena

Цена


В таблице Nomenklatura_detalei_i_komplektov первичным ключом является поле Identifikation_number.

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

Таблица Spravochnik_kolichestva_normo_chasov, изображенная в таблице 14, содержит информацию об установленных количествах времени на выполняемые работы.

Таблица 14

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

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

Комментарии

1

2

Kod_normo_chasa

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

Sokrahenoe_nazvanie

Сокращенное название

Polnoe_nazvanie

Полное название

Tekuhi_kurs

Текущий курс


В таблице Spravochnik_kolichestva_normo_chasov первичным ключом является поле Kod_normo_chasa. Данная таблица является справочной.


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