Система управления базами данных (СУБД) как программная система для создания общей базы данных. Создание СУБД для управления поставкой и реализацией ювелирных изделий. Типы данных, физическая и логическая модели. Разработка интерфейса пользователя.
Аннотация к работе
Анализ предметной области Разработка интерфейса пользователя.
Список литературы
Приложения
Введение
В современном мире ни одно предприятие не обходится без использования баз данных. Они являются удобным средством хранения информации о видах продукции, клиентах, поставщиках, работниках и т.д.
В связи с этим, в области разработки программного обеспечения выделяют отдельное направление - проектирование баз данных.
На ранних этапах развития этого направления вся ответственность за целостность хранимых данных, защиту от несанкционированного доступа к ним, добавление новых данных или обновления существующих возлагалась на программиста. Однако впоследствии стали создаваться специальные программные комплексы, способные решать эти задачи самостоятельно.
Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей базы данных, используемой для решения множества задач. Подобные системы служат для поддержания базы данных в актуальном состоянии и обеспечивают эффективный доступ пользователей к содержащимся в ней данным в рамках предоставленных пользователям полномочий.
СУБД предназначена для централизованного управления базой данных в интересах всех работающих в этой системе.
По степени универсальности различают два класса СУБД: системы общего назначения;
специализированные системы.
Специализированные СУБД создаются в редких случаях при невозможности или нецелесообразности использования СУБД общего назначения. [2]
СУБД общего назначения - это сложные программные комплексы, предназначенные для выполнения всей совокупности функций, связанных с созданием и эксплуатацией базы данных информационной системы. [4]
Используемые в настоящее время СУБД обладают средствами обеспечения целостности данных и надежной безопасности, что дает возможность разработчикам гарантировать большую безопасность данных при меньших затратах сил на низкоуровневое программирование. Продукты, функционирующие в среде WINDOWS, выгодно отличаются удобство пользовательского интерфейса и встроенными средствами повышения производительности. [4]
СУБД, ориентированные на разработчиков, обладают развитыми средствами для создания приложений. К элементам инструментария разработки приложений можно отнести: мощные языки программирования;
средства реализации меню, экранных форм ввода-вывода данных и генерации отчетов;
средства генерации приложений (прикладных программ);
генерацию исполнимых файлов.
Функциональные возможности моделей данных доступны пользователю СУБД благодаря ее языковым средствам. [2]
Реализация языковых средств интерфейсов может быть осуществлена различными способами. Для высококвалифицированных пользователей (разработчиков сложных прикладных систем) языковые средства чаще всего представляются в их явной синтаксической форме. В других случаях функции языков могут быть доступны косвенным образом, когда они реализуются в форме различного рода меню, диалоговых сценариев или заполняемых пользователем таблиц. По таким входным данным интерфейсные средства формируют адекватные синтаксические конструкции языка интерфейса и передают их на исполнение или включают в генерируемый программный код приложения. Интерфейсы с неявным использованием языка широко используются в СУБД для персональных ЭВМ. [4]
Анализ предметной области
Рассмотрим следующую предметную область: поставка и реализация ювелирных изделий.
Существуют поставщики и производители продукции. Продукция поставляется в магазины и делится на типы (кольца, серьги, цепочки и т.д.), а также может изготавливаться из различных металлов и камней. Клиенты покупают изделия в магазинах.
1. Разработка модели данных
В предыдущем пункте была проанализирована предметная область и выделены сущности для проектирования базы данных. Теперь рассмотрим структуру таблиц, описывающих эти сущности, и разработаем модель данных "сущность-связь".
В таблице "Продукция" должны содержаться поля: Идентификатор продукции;
Имя продукции;
Идентификатор поставщика;
Идентификатор производителя;
Цена продукции;
Кроме этого, продукция будет иметь определенный тип, и материал из которого изготовлена. Поэтому таблица будет иметь три внешних ключа.
В таблице "Магазины" будут поля: "Идентификатор магазина" как первичный ключ и "Имя магазина". В нее должен входить внешний ключ из таблицы "Shop_ex".
В таблицах "Поставщики" и "Производители" будут такие поля как "Имя" и "Идентификатор". В них должны входить внешние ключи из таблицы "Продукция".
Рассмотрим таблицы "Металлы", "Камни" и "Типы". В них должны входить внешние ключи из таблицы "Type_ex" и иметь следующие поля: "Идентификатор" и "Имя".
После определения типов данных физическая и логическая модели будут выглядеть следующим образом: управление база интерфейс пользователь
Рис.1. Логическая модель базы данных
Рис.2. Физическая модель базы данных
2. Разработка интерфейса пользователя
Интерфейс пользователя разработан на языке С#. Работа с пользователем происходит следующим образом. Пользователь загружает приложение и на экран выводится окно авторизации, в котором можно ввести имя пользователя, пароль доступа к базе данных и IP-адрес сервера MYSQL, на котором хранится база данных (см. рис.3).
Рис.3. Вкладка авторизации
После нажатия на кнопку "Подключиться" производится обращение к БД. В случае правильного ввода логина и пароля, появляется сообщение "Подключение произошло успешно!!!", что означает о разрешении дальнейшей работы.
После корректного подключения переходим ко вкладке "Представления".
На этой странице можно просмотреть все имеющиеся представления (см. рис.4).
Рис.4. Просмотр представлений
На вкладке "Продукция" можно просмотреть данные о типе, поставщиках и производителях продукции, а также добавить или удалить данные из таблицы "Продукция" (см. рис.4).
Рис.4. Вкладка "Продукция"
Для удаления данных необходимо указать идентификатор продукта и нажать кнопку "Удалить".
Аналогичным образом происходит добавление или удаление записей в других таблицах.
Во вкладке "Хранимая процедура" отображен пример работы с хранимыми процедурами. (см. рис.6)
Рис.6. Пример работы хранимой процедуры
3. Отладка, анализ результатов
В ходе данной рабы возникало множество проблем с приведением типов, что отобразилось на скорости выполнения работы.
Также наблюдается большое количество недостатков, в частности нет логической связи хранимой процедуры с предметной областью.
Все эти факторы повлияли на результат выполнения работы и на ее качество. Приложение нельзя назвать завершенным, можно лишь сказать, что оно положило начало программированию на С# для автора этой работы.
Заключение
В результате проделанной работы получилась реляционная база данных, поддерживаемая СУБД MYSQL, в которой содержится 10 таблиц, 2 представления, 1 хранимая процедура (см. приложение 1). В этих таблицах содержатся сведения о сущностях предметной области "Поставка и реализация ювелирных изделий": продукции, магазинах, клиентах, поставщиках, производителях и т.д. В каждой из этих таблиц содержится некоторое количество записей, необходимых для проверки работоспособности приложения, разработанного на С# специально для администрирования созданной базы данных.
Это приложение содержит в себе множество уязвимостей в исходном коде. Однако целью данной работы не является идеализировать конечный результат, а лишь глубже изучить технологии проектирования баз данных и разработки приложений для управления их содержимым.
На текущий момент эта цель достигнута, поэтому выполнение данной работы завершено.
Список использованных источников
Агуров П.В. С#. Разработка компонентов в MS Visual Studio 2005/2008,-СПБ.: БХВ-Петербург, 2008. - 480с.: ил.
Астахова И.Ф. SQL в примерах и задачах: Учеб. Пособие / И.Ф. Астахова, А.П. Толстобров, В.М. Мельников. - Мн.: Новое знание, 2002. - 176 с.
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`%` SQL SECURITY DEFINER VIEW `v_prod` AS select `production`. `ID` AS `ID`,`production`. `Name` AS `Name`,`manufacturer`. `Name_manufacturer` AS `Name_manufacturer`,`metall`. `Name_metall` AS `Name_metall`,`type_ex`. `Metall_weight` AS `Metall_weight`,`stone`. `Name_stone` AS `Name_stone`,`type_ex`. `Stone_weight` AS `Stone_weight`,`suppliers`. `Name_suppliers` AS `Name_suppliers`,`type`. `Name_type` AS `Name_type` from ( ( ( ( ( (`production` join `manufacturer`) join `suppliers`) join `type_ex`) join `type`) join `metall`) join `stone`) where ( (`production`. `Type_ex_ID` = `type_ex`. `ID`) and (`production`. `ID_supplier` = `suppliers`. `ID`) and (`production`. `ID_manufacturer` = `manufacturer`. `ID`) and (`type_ex`. `Type_ID` = `type`. `ID`) and (`type_ex`. `Metall_ID` = `metall`. `ID`) and (`type_ex`. `Stone_ID` = `stone`. `ID`) and (_utf8"" = _utf8""));
---------------------------
View structure for v_shop_ex
---------------------------
DROP VIEW IF EXISTS `v_shop_ex`;
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`%` SQL SECURITY DEFINER VIEW `v_shop_ex` AS select `shop_ex`. `ID` AS `ID`,`shop`. `Name_shop` AS `Name_shop`,`production`. `Name` AS `Name`,`production`. `Price` AS `Price` from ( (`shop_ex` join `shop`) join `production`) where ( (`shop_ex`. `Shop_ID` = `shop`. `ID`) and (`production`. `ID` = `shop_ex`. `Production_ID`)) order by `shop`. `Name_shop`;