Информационная система автосервиса (стр. 3 из 4)
1. Определение таблиц
2. Определение полей таблиц
3. Определение типов данных в соответствии с выбранной СУБД
4. Определение длины каждого поля таблиц
5. Определение обязательности каждого поля
6. Определение индексации каждого поля
Особое внимание при построении модели уделяют целостности и отсутствию избыточности данных. Избыточность - это многократное повторение одних и тех же данных). Если в БД имеется несколько описаний одного и того же объекта, то все экземпляры этих описаний, кроме одного будут избыточными. При анализе схемы данных было выявлено отсутствие избыточности данных.
Целостность - это непротиворечивость одних данных другим. Целостность зависит от степени избыточности данных. Например, если в БД имеется несколько описаний одного преподавателя, то при изменении принадлежности данного преподавателя к кафедре в одном описании нарушается целостность данных. Однако, даже при не избыточности данных может возникнуть нарушение целостности. Пусть из БД удаляются сведения о некотором преподавателе. Теперь ссылки на этого преподавателя в зарегистрированных до удаления преподаваемых предметах в преподаваемых группах будут неправильными и также квалифицируются как нарушение целостности. Кроме целостности и не избыточности при проектировании БД учитывают возможность быстрого выполнения запросов к БД и оптимального использования ресурсов, а также разграничение доступа для разных групп пользователей.
Для построения БД могут использоваться три модели: иерархическая, сетевая, реляционная. Все эти модели отличаются в основном способами представления связей сущностей.
При проектировании данной базы данных была использована реляционная модель. Основной структурой хранения является отношение – таблица со следующими свойствами:
Каждый столбец содержит информацию одного типа.
Ячейки – поля – таблицы не содержат агрегатов (структур или массивов) данных.
Таблицы не содержат одинаковых строк.
Порядок строк и столбцов не имеет значения. Все операции используют содержательную сторону данных, а не их расположение внутри таблицы.
Для описания связей вводятся первичные ключи, позволяющие указывать ровно одну строку (кортеж) таблицы. Значение ключа используется для ссылки в других таблицах, что и является отображением связей данных. Поскольку первичный ключ играет ведущую роль в описании связей и поиске данных, размер ключа стараются сделать минимальным для оптимизации поиска. Это приводит к использованию номеров или кодов в качестве первичных ключей.
На основании даталогического проектирования в Access были созданы 8 таблиц, которые описаны в таблицах 1-11.
Таблица 1 – Описание полей таблицы Отдел
| Имя поля | Тип данных | Свойства поля |
| ремонт | текстовый | длина 50 символов, ключевое |
| отдел | текстовый | длина 50 символов, обязательное |
Таблица 2 – Описание полей таблицы Сложный Ремонт
| Имя поля | Тип данных | Свойства поля |
| Ремонт | Текстовый | длина 50 символов, ключевое |
| Заявка | Текстовый | длина 50 символов, обязательное |
Таблица 3 – Описание полей таблицы Заявка
| Имя поля | Тип данных | Свойства поля |
| Номер | числовой | Длинное целое, первичный ключ |
| Дата | Дата\время | Краткий формат времени |
| Контрагент | Текстовый | Длина 50 символов, обязательное |
| Срок | Числовой | Длинное целое |
| Аванс | Денежный | Денежный |
Таблица 4 – Описание полей таблицы Состав Ремонта
| Имя поля | Тип данных | Свойства поля |
| Ремонт | Текстовый | длина 50 символов, ключевое |
| Ремонтируемый узел | Текстовый | длина 50 символов, обязательное |
| Работник | Текстовый | длина 50 символов, обязательное |
Таблица 5 – Описание полей таблицы Простой Ремонт
| Имя поля | Тип данных | Свойства поля |
| Заявка | Текстовый | длина 50 символов, обязательное |
| Ремонт | Текстовый | длина 50 символов, ключевое |
| Работник | Текстовый | длина 50 символов, обязательное |
Таблица 6 – Описание полей таблицы Контрагенты
| Имя поля | Тип данных | Свойства поля |
| Фамилия | Текстовый | длина 50 символов, обязательное |
| Скидка | числовой | Длинное целое |
Таблица 7 – Описание полей таблицы Работники
| Имя поля | Тип данных | Свойства поля |
| Ремонт | Текстовый | длина 50 символов, ключевое |
| Отдел | Текстовый | длина 50 символов, обязательное |
| Работник | Текстовый | длина 50 символов, обязательное |
Таблица 8 – Описание полей таблицы Ремонт Узла
| Имя поля | Тип данных | Свойства поля |
| Ремонт | Текстовый | длина 50 символов, ключевое |
| Узел | Текстовый | длина 50 символов, обязательное |
| Цена | Числовой | Длинное целое |
| Срок | Числовой | Длинное целое |
Схема данных
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:
- первая нормальная форма (1NF);
- вторая нормальная форма (2NF);
- третья нормальная форма (3NF);
- нормальная форма Бойса - Кодда (BCNF);
- четвертая нормальная форма (4NF);
- пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).
Была проведена нормализация базы данных до 3 НФ.
Для функциональных зависимостей как фундаментальной основы проекта БД были проведены исследования, позволяющие избежать избыточного их представления.
Множество всех возможных функциональных зависимостей, выводимое из заданного набора исходных функциональных зависимостей, называется его замыканием.
Отношение находится в первой нормальной форме тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. Как видно из таблиц 1-8, каждый атрибут сущностей является элементарным и неделимым.
Отношение находится во второй нормальной форме тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не первичных атрибутов от атрибутов первичного ключа. Сущности проектируемой БД находятся в 1НФ и не содержат неполных зависимостей от не первичных атрибутов.
Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.
2. Разработка клиентской программы на Delphi для взаимодействия с базой данных Access
Разработка любой программы включает в себя несколько этапов. Для начала необходимо определиться – какая функциональность нм необходима и, соответственно, какая структура программного обеспечения сможет это реализовать. Затем, нам необходимо выбрать способ взаимодействия с данными (это основная функция нашей программы) и создать необходимые для этого инструменты. На последнем этапе мы должны обеспечить реализацию пользовательского интерфейса в нашей программе и реализовать вспомогательные функции.
2.1. Разработка структуры программного обеспечения
Согласно поставленного задания, наша программа должна:
Подключаться к базе данных Access (с возможностью выбора файла данных);
Предоставлять возможность просмотра таблиц (включая возможность сортировки);
Обеспечивать возможность редактирования информации в таблицах;
Показывать информацию о программе.