Разработка БД для АСУ Спортивный магазин ООО "Атлет"

Объект-экземпляр  класса принадлежит своему классу и  имеет одного родителя. Родовые

отношения образуют в БД связную иерархию объектов.

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

Недостатками  объектно-ориентированной модели являются высокая сложность,

неудобство  обработки данных и низкая скорость выполнения запросов [9].

 

Обоснование выбора

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

 

2.3 Логическое  проектирование

После проведённого анализа в предыдущем пункте, была выбрана реляционная модель данных, т. к. определенные нами сущности в главе 2.1 удобнее и проще всего использовать в реляционной модели данных.

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

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

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

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

Процесс разработки корректной схемы РБД и является датологическим проектированием. Возможны 2-а способа:

• Декомпозиция (разбиение);
• Синтез;

Для перехода от инфологической модели к реляционной  существует специальный алгоритм:

1. каждой сущности ставится в соответствие отношение;
2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;
3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);
4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);
5. по умолчанию, все атрибуты, не входящие в PK, необязательны;
6. для отражения категоризации сущностей возможны несколько вариантов;
7. все связи М:М должны быть раскрыты;

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

• Продукт
• id продукта;  int    NOT NULL PK
• тип товара;             varchar(20)  NOT NULL
• бренд;              varchar(10)  NOT NULL
• количество;  int   NOT NULL
• цена;              decimal  NOT NULL
• модель;              varchar(20)  NOT NULL
• дата;   date  NOT NULL
• id товара   int  NOT NULL FK
• События
• id события;  int   NOT NULL PK
• текст события;        varchar(50)  NOT NULL
• id продукта;        int   NOT NULL FK
• Поставщики
• id поставщика;  int    NOT NULL PK
• данные о товаре;  varchar(50) NOT NULL
• количество товара; int  NOT NULL
• данные о поставщике; varchar(80)  NOT NULL
• id сотрудника;  int    NOT NULL FK
• Покупка
• id покупки;  int    NOT NULL PK
• id сотрудника;  int   NOT NULL FK
• тип оплаты;  varchar(50) NOT NULL
• дата;   date   NOT NULL
• id продукта;  int   NOT NULL FK
• Сотрудник
• id сотрудника;  int    NOT NULL PK
• ФИО;   varchar(30)    NOT NULL
• дата рождения;  date    NOT NULL
• смена;   date   NOT NULL
• оклад;   decimal  NOT NULL
• премия;   decimal NULL
• образование;   varchar(30)  NOT NULL
• должность.  varchar(30)  NOT NULL
• id поставщика;  int    NOT NULL FK
• Склад
• id товара;   int   NOT NULL PK
• количество;        int   NOT NULL
• дата;         date   NOT NULL

При переходе от инфологической модели к реляционной была раскрыта связь М:М между отношениями «Поставщики» и «Сотрудник». Отношением-связкой в данном случае стало отношение «Заказ», в котором будет информация о заказах, которые были сделаны сотрудниками от поставщиков;

• Заказ
• id заказа;   int    NOT NULL PK
• id поставщика;  int   NOT NULL FK
• id сотрудника;  int    NOT NULL FK
• дата;   date    NOT NULL

 

Исходя из приведённых  выше отношений, на рис. 2.2 показана построенная  схема получившейся БД.

Рис 2.2. Схема реляционной модели БД до нормализации

 

2.4 Нормализация, схема базы данных.

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

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

Понятие нормализации тесно связано с понятием функциональной зависимости. Функциональная зависимость (ФЗ) определяет отношения между объектами и их свойствами в рассматриваемой ПО.

1. Все таблицы находятся в 1НФ, так как ни одна из строк не содержит в любом своем атрибуте более одного значения, и ни один из ключевых атрибутов не пуст.
2. Таблицы находится в 2НФ, так как они находятся в 1НФ и не содержат неполных ФЗ не первичных атрибутов от первичного ключа (так как у них не составной ключ).
3. В отношении «Продукт» есть транзитивная зависимость. В связи с этим отношение «Продукт» распадается на 3:

• Продукт

• id продукта;  int    NOT NULL PK
• тип товара;             varchar(20)  NOT NULL
• бренд;              varchar(10)   NOT NULL
• количество;  int   NOT NULL
• цена;              int   NOT NULL
• модель;              varchar(20)  NOT NULL
• дата;   date  NOT NULL
• id товара   int  NOT NULL
• Тип товара
• id типа товара;  int    NOT NULL
• данные о товаре             varchar(20)   NOT NULL
• Бренд
• id бренда;   int    NOT NULL
• данные о бренде; varchar(20)  NOT NULL
• страна;              varchar(10)   NOT NULL

В отношении  «Покупка» тоже есть транзитивная зависимость. В связи с этим

отношение «Покупка» распадается на 2:

• Покупка
• id покупки;  int    NOT NULL PK
• id сотрудника;  int   NOT NULL FK
• тип оплаты;  varchar(50) NOT NULL
• дата;   date   NOT NULL
• id продукта;  int   NOT NULL FK
• Тип оплаты
• id оплаты;   int    NOT NULL PK
• данные об оплате; varchar(50) NOT NULL
• цена;   decimal NOT NULL

Теперь все  отношения данной модели находятся  в 3НФ, т.к. ни в одном из них нет  транзитивных зависимостей.

Таким образом, изначальная схема реляционной модели БД преобразуется в следующую схему (рис. 2.3).

 

Выводы.

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

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

Затем на основании  инфологической модели построена даталогическая модель данных, дан список атрибутов ее отношений и проведена нормализация до третьей 3НФ. Таким образом, завершено проектирование базы данных и получена вся информация, необходимая для реализации проектируемой информационной системы в реляционной СУБД.

 

 

Рис. 2.3. Схема реляционной модели БД после нормализации

 

 

 

Глава 3. Программная  реализация

3.1. Анализ и  выбор СУБД

Для программной  реализации информационной системы  выбрана СУБД PostgreSQL. В последнее время эта СУБД начала активно вырываться вперед относительно своих Open Source конкурентов. PostgreSQL обладает высокой надежностью, она удобна и гибка в использовании. Также присутствует поддержка огромной базы языков программирования, написано множество плагинов-коннекторов для работы с данной СУБД. На оффициальном сайте присутствует обширная документация и активный форум, на котором всегда работает поддержка пользователей и разработчиков [13].

Ruby on Rails – Фреймворк,  написанный на языке программирования Ruby. Ruby on Rails предоставляет архитектурный образец Model-View-Controller(модель-представление-контроллер) для веб-приложений, а также обеспечивает их интеграцию с веб-сервером и сервером базы данных. Ruby on Rails является открытым программным обеспечением и распространяется под лицензией MIT [14].

Ruby on Rails определяет  следующие принципы разработки  приложений:

• Ruby on Rails предоставляет механизмы повторного использования, позволяющие минимизировать дублирование кода в приложениях (принцип Don’t Repeat Yourself).
• По умолчанию используются соглашения по конфигурации, типичные для большинства приложений (принцип Convention over configuration). Явная спецификация конфигурации требуется только в нестандартных случаях.

Основными компонентами приложений Ruby on Rails являются модель (model), представление (view) и контроллер (controller).

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

Представление создает пользовательский интерфейс для отображения полученных

от контроллера  данных. Представление также передает запросы пользователя на манипуляцию  данными в контроллер (как правило, представление не изменяет непосредственно модель). В Ruby on Rails представление описывается при помощи шаблонов ERB.Они представляют собой файлы HTML с дополнительными включениями фрагментов кода Ruby (Embedded Ruby или ERb). Вывод, сгенерированный встроенным кодом Ruby, включается в текст шаблона, после чего получившаяся страница HTML возвращается пользователю. Кроме ERb возможно использовать еще около 20 шаблонизаторов.

Контроллер в Rails – это набор логики, запускаемой после получения HTTP-запроса сервером. Контроллер отвечает за вызов методов модели и запускает формирование представления. Контроллером в Ruby on Rails является класс, наследованный от ActionController::Base. Открытые методы контроллера являются так называемыми действиями (actions). Action часто соответствует отдельному представлению. Например, по запросу пользователя admin/list будет вызван метод list класса AdminController и затем использовано представление list.html.erb [15].

 

3.2. Физическое  проектирование БД.

Во время  физического проектирования базы данных были созданы следующие таблицы:

• Сотрудник;
• Поставщики;
• Заказ;
• Покупка;
• Склад;
• События;
• Тип оплаты;
• Продукт;
• Бренд;
• Тип товара.

Схема, в которую  связаны данные таблицы, повторяет схему БД после нормализации, описанную в пункте 2.4., и изображенную на рисунке 2.3.