Разработка технического задания на создание аис "Магазин косметической продукции"

@ВЫХОД=<НАКЛАДНАЯ>

ВЫПОЛНИТЬ Подготовка накладной

@КОНЕЦ  СПЕЦИФИКАЦИИ А7 

Спецификация  процесса А8

@ВХОД=<ЛОГИН>

@ВХОД=<ПАРОЛЬ>

ЕСЛИ  ЛОГИН=ЛОГИН из базы данных  и ПАРОЛЬ=ПАРОЛЬ из базы данных

ВЫПОЛНИТЬ ВХОД

ИНАЧЕ Выдать сообщение об ошибке

@КОНЕЦ  СПЕЦИФИКАЦИИ А8 

    1.6 Декомпозиция процессов

     Декомпозиция  процессов представляет собой структурный подход к анализу деятельности предприятия через рассмотрение бизнес-процессов и их внутренней структуры.

     Метод декомпозиции процессов имеет следующие общие характеристики:

     

- выделяет  отдельные компоненты процесса (например, на рис.5 ввод нового поставщика); 
- обеспечивает представление о структуре и основном содержании областей (или групп) процессов;

- по мере продолжения декомпозиции к более низким уровням позволяет обнаружить более мелкие детали;

- его можно продолжать до тех пор, пока не будет получено необходимое количество подуровней;

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

    

Рис 5.1- Декомпозиция процесса “Ввод нового поставщика” А1

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

    

 

    Рис 5.2-Декомпозиция процесса “Ввод нового поставщика” А2 

    Входной информацией является данные о товаре и из таблицы Поставщики – код поставщика, выходные данные – данные о товаре. Вся информация записывается в таблицу Товары. 

    

    Рис.5.3-Декомпозиция процесса “Осуществление продажи” А3 

    Входной информацией являются данные о продаже, из таблицы Покупатели – код покупателя, из таблицы Сотрудники – продавец, из таблицы Товары – код товара. Выходная информация – данные о  продаже. Вся информация записывается  в таблицу Продажи. 

    Декомпозиция  процессов А4-А6 производится по аналогии декомпозиции А1 

    

    

    

    Рис.5.4-Декомпозиция процесса “Накладная” А7 

    Входной информацией будет из таблицы  Поставщики – данные о поставщике; из таблицы Товары – данные о товаре. Выходной информацией будет накладная.

 

     2 Концептуальное проектирование

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

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

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

    2.1 Перечень сущности

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

• типом связи (1:1, 1:N, N:N)
• классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности - обязательный, иначе - необязательный.

     В базе данных магазина имеются сущности: поставщики, товары, продажи, сотрудники, покупатели (представлены на рисунке 8).

     

     

     

     Рисунок 6 – Сущности магазина косметической продукции

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

    2.2 Перечень атрибутов

    Сущность  – «Поставщики» имеет следующие атрибуты: код поставщика, название, город, почтовый индекс, адрес электронной почты, номер телефона (Рис.6)

    Сущность  – «Товары» имеет следующие атрибуты: код товара, наименование, код поставщика, цена, количество в наличии, серийный номер (Рис.6).

    Сущность  – «Продажи» имеет следующие  атрибуты: код продажи, код товара, код покупателя, цена, оплата, продавец (Рис.6).

    Сущность  – «Сотрудники» имеет следующие атрибуты: код сотрудника, табельный номер, фамилия, имя, отчество, должность, дата рождения, зарплата, рабочий телефон (Рис.6).

    Сущность  – «Покупатели» имеет следующие  атрибуты: код покупателя, ФИО, адрес, номер телефона, паспортные данные (Рис.6).

 

3 Инфологическое проектирование

    3.1 Модель «сущность-связь»

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

    На  использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER – модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER – моделей одна из наиболее развитых применяется в системах CASE  фирмы ORACLE.

    Основными понятиями ER – модели являются сущность, связь и атрибут.

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

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

    Класс сущностей – это совокупность сущностей, которая описывается  структурой, либо форматом сущностей, составляющих этот класс.

    Связи – это взаимоотношения сущностей  выраженная связями.

    Модель  «сущность – связь» включает в себя классы связей и экземпляры связей.

    

Рисунок 7- Диаграмма ER-типа магазина косметической продукции

    Между товарами и поставщиком связь  – N:1, у товаров и продаж связь-1:N, между продажами и сотрудниками связь 1:N, между продажами и покупателями связь – N:1. 

    3.2 Классификация связей

    Могут существовать следующие связи:

    - один  к одному (обозначается 1 : 1 ). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью.

    - один  ко многим ( 1 : n ). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Такова связь Товары- Продажи. Один товар может участвовать в нескольких продажах. Графически степень связи n отображается "древообразной" линией, так это сделано на следующем рисунке.

    - много  к одному (n : 1 ). Эта связь аналогична отображению 1 : n. Такая связь представлена между таблицами Товары – Поставщики. У многих товаров, может быть только один поставщик, и у одного поставщика может быть много товаров.

    

- многие ко  многим ( n : n ). В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров.  
4 Датологическое проектирование

    4.1 Средства поддержания  целостности данных

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

    С поддержанием целостности связаны следующие основные требования:

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

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

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

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

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

    Целостность данных – соответствие информационной модели программного обеспечения, хранимой в БД, объектам реального мира и их взаимосвязям в каждый момент времени

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

    Поддержка целостности в РМД: