Разработка базы данных по продаже в магазине одежды

Плюсы и минусы есть у любой СУБД. Поэтому не надо думать, что одна СУБД лучше  другой.

Плюсы:

• нет ограничений на размер базы 
• нет ограничителя запросов, это позволяет одновременно обслуживать десятки пользователей
• хорошая бесплатная техподдержка
• с конфигурациями 1С: Предприятие в автоматическом режиме блокировок работает лучше, чем PostgreSQL (речь а параллельности, область блокировок на уровне строк, а не таблиц)
• хорошая производительность
• меньше проблем с неуникальностью индексов (фактически для решения проблемы рекомендуется временно базы загружать в DB2)
• лучше обрабатывает ситуации вроде "не хватает памяти для сервера 1С"
• нет ограничения на 256 таблиц, что расширяет возможности при работе с RLS

Минусы:

• мало специалистов и высокая стоимость Хороших специалистов
• небольшая распространенность (со всеми вытекающими последствиями)
• в отличии от MS SQL Server, для новых версий 1С выпускает "адаптированные" версии (в прочем, тоже самое верно и для постгресса)
• размер баз больше, чем в других СУБД
• медленная загрузка dt-файла
• требуется "тонкая" настройка параметров СУБД, автоподстройка системы есть, но неполная
• некоторые сообщения платформой могут неверно обрабатываться, для решения приходиться "понижать уровень" легирования ошибок.

Paradox

         Paradox - это мощный инструмент для хранения обработки и передачи информации посредством простого и интуитивно понятного администрирования реляционных баз данных. Paradox доступен новичкам, только собирающимся работать с базами данных и в то же время, предоставляет широкие возможности специалистам и экспертам в этой области. Paradox позволяет систематизировать информацию, анализировать большие объемы разрозненных данных и находить в них закономерности, облегчая принятие оптимальных решений. В первую очередь, этот продукт ориентирован на корпоративных пользователей, которые работают с автономными базами данных, а также на пользователей, работающих дома или же в малом бизнесе, причем среди них могут быть и только начинающие работать с базами данных, и настоящие асы в этой области. Paradox - наилучший выбор для пользователей, заинтересованных в надежности и эффективности продукта, с которым они работают. Paradox распределяет информацию между несколькими файлами, относящимися к каждому объекту (таблица, формы, запросы и отчеты). Эта структура поддерживает быстрое обновление файлов, уменьшает сетевой трафик и в случае повреждения данных позволяет легко восстановить эти данные через индивидуальные файлы. 
        Благодаря совместимости с другими приложениями, Paradox позволяет без проблем обмениваться данными из различных приложений или же напрямую помещать данные в Internet. Мощные инструменты, в число которых входит и ObjectPAL, позволяют разработчикам и продвинутым пользователям создавать собственные приложения. Paradox может работать как на отдельном компьютере, так и в многопользовательской сети, что дает этому продукту дополнительные возможности для наиболее полного удовлетворения изменяющихся запросов пользователей.

    Проанализировав все плюсы и  минусы представленных систем  управления, мой выбор пал   СУБД Paradox, который будет выполнен в Delphi. 

                                   Требования к СУБД: 

1. Предоставление для процесса принятия решений непротиворечивой информации;
2. Минимизация избыточности;
3. Обеспечение безопасности;
4. Эффективность выполнения различных функций предметной области;
5. Централизованное управление;
6. Упрощение эксплуатации ЭВМ;
7. Реорганизация БД;
8. Обеспечение пользователю возможности создавать новые БД с идентичной логической структурой данных;
9. Обеспечение модификации БД;

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

           В формирование базы данных  основным является ее проектирование. Под проектирование БД понимают  разработку структуру информационной  модели предметной области и  разработку особенностей реализации  данной модели.

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

Шаги  проектирования базы данных: 

1. Определение информационных потребностей БД.

         Следует выяснить следующие вопросы:  какие данные используются приложениями; в какой форме будут вводиться  данные;

2. Анализ объектов необходимых смоделировать в базе данных.

Формирование  сущности и характеристики этих сущностей.

3. Установление соответствия между сущностями и характеристиками предметной области и отношениями, в выбранной СУБД.

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

4. Определение атрибутов идентифицирующих каждый объект.

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

5. Выбор правил устанавливающих и поддерживающих целостность данных.

Такие правила, будучи определенными, поддерживаются автоматически – сервером базы данных. 

Правила включают в себя:

• установку значений по умолчанию;
• создание полей по умолчанию;
• определение типа данных;
• определение проверочных условий;
• выбор набора символов;

6. Установление связей между объектами.

     Каждый тип связи должен быть  смоделирован в базе данных. Существует  несколько типов связей:

• «один-к-одному»
• «один-ко-многим»
• «многие-ко-многим»

       Отношение «один-к-одному» простейший  вид связи, каждой записи соответствует  одна запись другой таблицы.  Первичный ключ является в  то же время внешним ключом.

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

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

7. Планирование вопроса для надежности данных и при необходимости сохранения секретности информации.

 
 

2. Характеристика  организационной структуры предметной области

 

     При поступлении нового товара в магазин,  его данные заносятся в базу.

     Основными задачами, требующими автоматизации  являются:

• Ввод и хранение данных об одежде;
• Ввод и хранение данных о поставщиках;
• Создание отчётов;
• Вывод необходимых  данных, для последующего принятия решений руководством.

     Все данные вводятся в программу, путём  прямого ввода через определённые диалоговые окна автоматизированной информационной системы.

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

1.3. Назначение  и цели разработки системы

      Целью разработки информационной системы является автоматизация деятельности магазина по продаже одежды.

     Исходя  из цели основными процессами являются:

1. Учет товара.
2. Учет работы с поставщиками.
3. Учет продажи.
4. Отчеты.

     Основными задачами, требующими автоматизации, являются:

• Ввод и хранение данных о товарах;
• Ввод и хранение данных о поставщиках;
• Создание отчётов;

     Главной возможностью программы должно является создания отчётов по различным данным. 
 
 
 
 

Глава 2. Описание информационной системы 

1. Схема функциональной структуры системы с кратким  описанием.

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

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

     К моделям предметных областей предъявляются  следующие требования:

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

                    

     Рис.2.1.1. Схема функциональной структуры магазина одежды 

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

     Данные  о поставщиках будут содержать  в себе: название фирмы, его адрес, город, телефон,e-mail и контактное лицо. Первичный ключ – код поставщика.

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

     На  этом процесс логического моделирования  заканчивается, а сама модель приобретает  вид, представленный на рис.2.1.1.

2. Описание информационных функций и комплекса решаемых задач

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

Для создания БД используем следующие таблицы:

• Ассортимент
• Поставщики
• Накладные