Файл: Курсовая работа по курсу Информационное обеспечение систем управления.docx
Добавлен: 26.10.2023
Просмотров: 43
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Тогда общий объем памяти будет равен:
Мд=1488+2640+3472+1428+1652+672+1652+1960+1512=164,76Кб
Общий объем памяти, отводимый под БД составляет 164,74 Кб. Такой объем памяти приемлем для работы с БД MS Access
3 ВЫБОР СИСТЕМЫ УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ (СУБД)
Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».
MS Access имеет самый богатый набор визуальных средств для собственного создания запросов и отчетов даже непрофессионалом. СУБД Access имеет русифицированный интерфейс и частично переведенный на русский язык файл контекстной помощи. Также в этой среде осуществляется целостность данных, что дает возможность корректно редактировать данные.
VisualFoxPro отличается высокой скоростью, имеет встроенный объектно-ориентированный язык программирования с использованием xBase и SQL, диалекты которых встроены во многие СУБД. Имеет высокий уровень объектной модели. При использовании в вычислительных сетях обеспечивает как монопольный, так и раздельный доступ пользователей к данным. Применяется для приложений масштаба предприятия для работы на различных платформах: Windows 3.x, Windows 95, Macintosh...
VisualBasic – это универсальный объектно-ориентированный язык программирования, диалекты которого встроены в Access, Visual FoxPro. Преимущества: универсальность, возможность создания компонентов OLE, невысокие требования к аппаратным ресурсам ЭВМ. Применяется для создания приложений средней мощности, не связанных с большой интенсивностью обработки данных, разработки компонентов OLE, интеграция компонентов Microsoft Office. VisualC++ – наиболее мощный объектно-ориентированный язык программирования, обладает неограниченной функциональностью. Предназначен для создания компонентов приложений для выполнения операций, критичных по скорости.
SQLServer – сервер баз данных, реализует подход «клиент-сервер» и взаимодействует с указанными пакетами. Главные достоинства: высокая степень защиты данных, мощные средства для обработки данных, высокая производительность. Область применения: хранение больших объемов данных, хранение высокоценных данных или данных, требующих соблюдения режима секретности.
Из всех рассмотренных СУБД, мы будим использовать для создания базы данных Microsoft Аccess, который кроме перечисленных особенностей обладает таким достоинством как распространенность, что является также важным фактором при выборе БД.
Составим сравнительную характеристику основных критерий для выбора СУБД:
Таблица 3 - Характеристики СУБД
СУБД | VisualBasic | Microsoft Access | Microsoft FoxPro | SQLServer |
Целостность данных | -- | ++ | -- | ++ |
безопасность данных | ++ | + | + | + |
производительность | - | + | ++ | - |
работа в многопользовательских средах | ++ | ++ | + | ++ |
импорт-экспорт | + | | | |
ресурсоемкость | - | + | - | + |
Низкая стоимость разработки и лицензирования | + | - | - | + |
Легкость освоения | - | ++ | - | + |
+ поддерживает критерий;
++ является лидером по этому критерию;
- слабая поддержка данного критерия;
-- не поддерживает данный критерий.
4 ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
4.1 Создание таблиц
Б аза данных создаётся на основании схемы базы данных. Инфологическую модель данных, построенную в виде ER–диаграммы, следует преобразовать в схему БД. Преобразование ER–диаграммы в схему БД выполняется путем сопоставления каждой сущности и каждой связи, имеющей атрибуты, в отношения (таблицы БД).
Рисунок 1 – Таблица «Вид ремонта»
Таблица 4 – Сущность «Вид ремонта»
Имя поля | Тип данных | Свойства поля |
Тип ремонта | Текстовый | Размер поля – 50 Обязательное поле – Да |
Срок ремонта | Числовой | Размер поля – Длинное целое Обязательное поле – Да |
Цена ремонта | Денежный | Формат поля – # ##0,00" руб." Условие на значение – >0 Сообщение об ошибке – Цена >0! |
Рисунок 2 – Таблица «Завод изготовитель»
Таблица 5 – Сущность «Завод изготовитель»
Имя поля | Тип данных | Свойства поля |
Название завода | Текстовый | Размер поля – 40 Обязательное поле – Да |
Адрес | Текстовый | Размер поля – 40 Обязательное поле – Да |
Телефон | Текстовый | Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_ |
Факс | Текстовый | Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_ |
Рисунок 3 – Таблица «Заказ»
Таблица 6 – Ассоциация «Заказ»
Имя поля | Тип данных | Свойства поля |
№ заказа | Числовой | Размер поля – Длинное целое Обязательное поле – Да |
Состояние ремонта | Логический | Формат поля – ;" Выполнен"[Синий];" Находится на ремонте"[Красный] |
ФИО | Текстовый | Размер поля – 20 Обязательное поле – Да |
Дата заказа | Дата/время | Формат поля – dd\ mmm", "yyyy |
Гарантия | Логический | Формат поля – ;"На гаранти"[Синий];"Гарантия истекла"[Красный] |
Тип ремонта | Текстовый | Размер поля – 50 Обязательное поле – Да |
Поломка | Текстовый | Размер поля – 40 Обязательное поле – Да |
Рисунок 4 – Таблица «Заказ деталей»
Таблица 7 – Ассоциация «Заказ деталей»
Имя поля | Тип данных | Свойства поля |
Название запчасти | Текстовый | Размер поля – 50 Обязательное поле – Да |
Название завода | Текстовый | Размер поля – 40 Обязательное поле – Да |
Дата | Дата/время | Формат поля – dd\ mmm", "yyyy |
Рисунок 5 – Таблица «Запчасти»
Таблица 8 – Сущность «Запчасти»
Имя поля | Тип данных | Свойства поля |
Название запчасти | Текстовый | Размер поля – 50 Обязательное поле – Да |
Цена запчасти | Денежный | Формат поля – # ##0,00" руб." Условие на значение – >0 Сообщение об ошибке – Цена >0! |
Наличие | Логический | Формат поля – ;"Имеется"[Синий];"Отсутствует"[Красный] |
Рисунок 6 – Таблица «Исполнение ремонта»
Таблица 9 – Ассоциация «Исполнение ремонта»
Имя поля | Тип данных | Свойства поля |
ФИО | Текстовый | Размер поля – 20 Обязательное поле – Да |
№ заказа | Числовой | Размер поля – Длинное целое Обязательное поле – Да |
Рисунок 7 – Таблица «Исполнители»
Таблица 10 – Сущность «Исполнители»
Имя поля | Тип данных | Свойства поля |
ФИО | Текстовый | Размер поля – 20 Обязательное поле – Да |
Образование | Текстовый | Размер поля – 20 Обязательное поле – Да |
Стаж | Числовой | Маска ввода - 99 |
Телефон (сот) | Текстовый | Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_ |
Рисунок 8 – Таблица «Клиенты»
Таблица 11 – Сущность «Клиенты»
Имя поля | Тип данных | Свойства поля |
ФИО | Текстовый | Размер поля – 20 Обязательное поле – Да |
Телефон (сот) | Текстовый | Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_ |
Телефон (дом) | Текстовый | Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_ |
Адрес | Текстовый | Размер поля – 40 Обязательное поле – Да |
Рисунок 9– Таблица «Требуемые запчасти»
Таблица 12 – Ассоциация «Требуемые запчасти»
Имя поля | Тип данных | Свойства поля |
№ заказа | Числовой | Размер поля – Длинное целое Обязательное поле – Да |
Название запчасти | Текстовый | Размер поля – 50 Обязательное поле – Да |
О бъединяя все таблицы, получим схему базы данных. Каждая таблица связана с другой, и при этом наложено ограничение целостности данных.
Рисунок 10– База данных «Ремонт бытовой техники»
4.2. Нормализация отношений
Проведем нормализацию полученных отношений. Проверим отношения на первую нормальную форму (1НФ). Отношение находится в 1НФ, если все его атрибуты простые. «Дата заказа», «ФИО исполнителя», «ФИО клиента», «Адрес» являются составными атрибутами. Рассматривая на примере таблицы Клиенты, мы видим, что атрибут «ФИО клиента» является составным, так как он состоит из трёх значений (Фамилия, Имя, Отчество), которые можно разделить на 3 независимых атрибута, но мы это не используем, а берём его как простой. Проверяем это условие и убеждаемся, что все отношения находятся в 1НФ.
Проверим отношения на вторую нормальную форму (2НФ). Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от первичного ключа. В таблице Заказ деталей, неключевой атрибут «Дата» зависит от каждой части составного ключа в целом, а не по отдельности .