Проектирование компонентов информационной системы для ООО технический центр «курс»
Вид материала | Документы |
СодержаниеГлава 2. проектирование компонентов информационной системы для ооо технический центр «курс» 3 Глава. разработка информационной системы |
- Учебно-методический комплекс дисциплины проектирование информационных систем Специальность, 449.6kb.
- Нп «сибирская ассоциация консультантов», 92.1kb.
- Ооо «Центр информационной безопасности», 11.9kb.
- Российская академия государственной службы при Президенте Российской Федерации Проектирование, 246.7kb.
- «Оценка эффективности внедрения информационной системы управления предприятием ООО, 133.25kb.
- Единая Торговая Система, Воскобойников А. В. Pуководитель отдела компонентов для лкм, 246.5kb.
- Курсовой работы должна соответствовать сельскохозяйственной, промышленной или образовательной, 28.04kb.
- Кемерово, 1188.8kb.
- А. М. Боярков А. Б. Лагутин Информационный центр муниципального музея на основе Информационной, 292.76kb.
- Курс лекций «Проектирование асоИу», «системы реального времени», 521.56kb.
1 2
ОГЛАВЛЕНИЕ
ГЛАВА 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 даталогической модели базы данных
Наименование | Комментарии |
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 приведена даталогическая схема данных, демонстрирующая описание отношений и связи между ними.