Разработка клиентского приложения информационной системы проекта интернет–фотоцентра

По степени их универсальности различаются два вида СУБД – системы общего назначения и специализированные системы.

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

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

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

Однако в некоторых случаях доступные СУБД общего назначения не позволяют добиться требуемых характеристик производительности и(или) удовлетворить заданные ограничения по объему памяти, предоставляемой для хранения БД.

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

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

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

Логическое проектирование – преобразование требований к данным в структуры данных. На выходе получаем СУБД – ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.

Физическое проектирование – создание описания конкретной реализации базы данных (с помощью выбранной СУБД): описание структуры хранения данных и методов доступа.

Реляционные базы данных.

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

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

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

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

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

Объектно-ориентированные базы данных.

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

Преимуществом ООБД является упрощенный код. Приложения получают возможность интерпретировать данные в контексте того языка программирования, на котором они написаны. Реляционная база данных возвращает значения всех полей в текстовом виде, а затем они приводятся к локальным типам данных. В ООБД этот этап ликвидирован. Методы манипулирования данными всегда остаются одинаковыми независимо от того, находятся данные на диске или в памяти.

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

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

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

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

Объектно-реляционные базы данных.

Объектно-реляционные СУБД объединяют в себе черты реляционной и объектной моделей. Их возникновение объясняется тем, что реляционные базы данных хорошо работают со встроенными типами данных и гораздо хуже – с пользовательскими, нестандартными. Когда появляется новый важный тип данных, приходится либо включать его поддержку в СУБД, либо заставлять программиста самостоятельно управлять данными в приложении.

Перестройка СУБД с целью включения в нее поддержки нового типа данных не лучший выход из положения. Вместо этого объектно-реляционная СУБД позволяет загружать код, предназначенный для обработки "нетипичных" данных. Таким образом, база данных сохраняет свою табличную структуру, но способ обработки некоторых полей таблиц определяется извне, т.е. программистом.

 

 

 

 

 

 

 

2 Проектирование и разработка клиентского приложения информационной системы проекта интернет – фотоцентр

2.1 Создание структуры базы данных MySQL проекта интернет – фотоцентр

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

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

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

После рассмотрения некоторых вариантов реализации БД, был выбран наиболее оптимальный, соответственно требованиям (рисунок 2.1).

Рисунок 2.1 – Диаграмма базы данных

Затем происходила непосредственная реализация БД в среде MySQL с помощью выполнения необходимых команд на языке SQL.

Структура базы данных информационной системы интернет – фотоцентра:

Покупатели (customers) – физические и юридические лица- покупатели фототоваров (фотопринадлежностей) и фотоуслуг (печать фотографий путем заказа с сайта фотоцентра):

Номер_покупателя/id_customer;

ФИО_покупателя/name;

Эл_почта_покупателя/email.

 

Поставщики (vendors):

Номер_поставщика/id_vendor;

Юридическое_название_поставщика/name;

Город_поставщика/city;

Юридический_ адрес _поставщика/address.

 

Покупки (sale):

Номер_покупки/id_sale;

Номер_покупателя/id_customer;

Дата/data_sale.

 

Поставки (incoming):

Номер_поставки/id_incoming;

Номер_поставщика/id_vendor;

Дата/date_incoming.

 

Журнал покупок (magazine_sales):

Номер_покупки/id_sale;

Номер_продукта/id_product;

Количество/quantity.

 

Журнал поставок (magazine_incoming):

Номер_поставки/id_incoming;

Номер_продукта/id_product;

Количество/quantity.

 

Товары (products):

Номер_товара/id_product;

Имя_товара/name;

Наименование/case_name (в таблице Товары столбец case_name (наименование)- если печать, проявка и т.д. фотографий (т.е. предоставление услуги) то прописываем «yslyga», если товар – указываем  краткое наименование торговой марки товара).

 

Цены (prices):

Номер_продукта/id_product;

Дата/date_price_changes;

Цена/price.

Базу данных с описанием всех полей и ключей можно увидеть в листинге 2.1.

Листинг 2.1 – Создание таблиц и ключей в БД

SET NAMES `cp866`;

create database phcen;

use phcen;

 

create table customers (

id_customer int NOT NULL AUTO_INCREMENT,

name char(50) NOT NULL,

email char(50) NOT NULL,

PRIMARY KEY (id_customer)

);

 

create table vendors (

id_vendor int NOT NULL AUTO_INCREMENT,

name char(50) NOT NULL,

city char(30) NOT NULL,

address char(100) NOT NULL,

PRIMARY KEY (id_vendor)

);

 

create table sale (

id_sale int NOT NULL AUTO_INCREMENT,

id_customer int NOT NULL,

date_sale date NOT NULL,

PRIMARY KEY (id_sale),

FOREIGN KEY (id_customer) REFERENCES customers (id_customer)

);

 

create table incoming (

id_incoming int NOT NULL AUTO_INCREMENT,

id_vendor int NOT NULL,

date_incoming date NOT NULL,

PRIMARY KEY (id_incoming),

FOREIGN KEY (id_vendor) REFERENCES vendors (id_vendor)

);

 

create table products (

id_product int NOT NULL AUTO_INCREMENT,

name char(100) NOT NULL,

case_name char(50) NOT NULL,

PRIMARY KEY (id_product)

);

 

create table prices (

id_product int NOT NULL,

date_price_changes date NOT NULL,

price double NOT NULL,

PRIMARY KEY (id_product, date_price_changes),

FOREIGN KEY (id_product) REFERENCES products (id_product)

);

 

create table magazine_sales (

id_sale int NOT NULL,

id_product int NOT NULL,

quantity int NOT NULL,

PRIMARY KEY (id_sale, id_product),

FOREIGN KEY (id_sale) REFERENCES sale (id_sale),

FOREIGN KEY (id_product) REFERENCES products (id_product)

);

 

create table magazine_incoming (

id_incoming int NOT NULL,

id_product int NOT NULL,

quantity int NOT NULL,

PRIMARY KEY (id_incoming, id_product),

FOREIGN KEY (id_incoming) REFERENCES incoming (id_incoming),

FOREIGN KEY (id_product) REFERENCES products (id_product)

);

2.2 Реализация проекта интернет – фотоцентр в Qt

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

В заголовочном файле mainwindow.h подключаются все необходимые библиотеки, впоследствии здесь происходит описание выбранного класса, конструктора, указателей, функций, автоматически описываются слоты. В конечном виде файл выглядит как в листинге 2.2.

Листинг 2.2 – файл mainwindow.h

#ifndef MAINWINDOW_H

#define MAINWINDOW_H

 

#include <QMainWindow>                      //подключается Qmainwindow

 

namespace Ui {

class MainWindow;

}

 

class MainWindow : public QMainWindow  // описывается класс и наследование

 

{

    Q_OBJECT

 

public:

    explicit MainWindow(QWidget *parent = 0);

                      // конструктр   

~MainWindow();                                 //деструктор

 

private slots:

    void on_actionTableCustomers_triggered();

 

    void on_actionTableVendors_triggered();

 

    void on_actionTableSale_triggered();

 

    void on_actionTableIncoming_triggered();