Информационная система для предприятия розничной торговли
мобильными телефонами и аксессуарами
Проектирование базы данных
Предприятие ЗАО "Betalink" имеет большое количество торговых точек, в которых большой поток товара, что приводит к созданию автоматизированной СУБД учета прихода и расхода товаров. Заведующий торговой точкой в базе учета может проверить наличие товара на торговой точке, составить заявку на товар, ввести в базу приходную накладную, провести документ, редактировать справочники с поставщиками и лекарственными средствами.
База данных разрабатывается в Microsoft SQL Server. При всем этом Microsoft SQL Server - не просто СУБД. Как реляционная СУБД Microsoft SQL Server обеспечивает доступ ко всем типам данных и позволяет использовать одновременно несколько таблиц базы данных. При этом можно существенно упростить структуру данных, облегчая тем самым выполнение поставленных задач. Таблицу Microsoft SQL Server можно связать с данными, хранящимися на большой ЭВМ или на сервере. С другой стороны, можно использовать таблицы, созданные в среде Paradox или dBASE.
При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.
Инфологическое моделирование.
Модель сущность-связь - ER-модель. Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства.
Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа.
Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).
Как и сущность, связь - это типовое понятие, все экземпляры обеих пар связываемых сущностей подчиняются правилам связывания.
На рисунке 8 представлена ER-модель базы данных информационной системы ЗАО "Betalink" со связями и сущностями. Основной сущность базы данных является сущность товар. Связь между сущностями "товар" и "производитель" связывает товар и производителя. Каждый производитель может производить много товаров, но любой товар может производиться только одним производителем, то есть связь "один-ко-многим".
Сущность "приходная накладная" может включать в себя перечень многих "товаров", также один "товар" может находиться в перечнях многих "приходных накладных", отсюда связь "многие-ко-многим", которая реализована введением сущности ассоциации "запись списка накладной".
Рисунок 8 - ER-модель
Сущность "чек" может включать в себя перечень многих "товаров", также один "товар" может находиться в перечнях многих "чеков", отсюда связь "многие-ко-многим", которая реализована введением сущности ассоциации "запись списка".
Сущность "консультант" может соответствовать многим "чекам", но любой чек может прийти только от одного консультанта, следовательно, связь между сущностями "консультант" - "чек" "один-ко-многим".
Сущность "приходная накладная" имеет следующие атрибуты:
1) номер накладной;
2) дата;
3) сумма;
4) статус;
Сущность "запись списка" имеет следующие атрибуты:
1) количество;
2) дата выпуска.
Сущность "Товар" имеет следующие атрибуты:
1) торговое наименование;
2) EAN13;
3) текущая цена;
4) срок гарантии.
Сущность "производитель" имеет следующий атрибут: наименование.
Сущность "Чек" имеет следующие атрибуты:
1) номер чека;
2) дата;
3) сумма.
Сущность "запись списка" чека имеет атрибут количество.
Сущность "Консультант" имеет следующие атрибуты:
1) ФИО;
2) Ник;
3) Пароль.
Реляционная модель данных
База данных состоит из нескольких таблиц, в которых хранятся определенные данные.
Преобразуем сущности инфологической модели в таблицы реляционной, и получим 7 таблиц: "производитель"
(рисунок 9), "товар" (рисунок 10), "запись списка приходной накладной" (рисунок 11), "приходная накладная"
(рисунок 12), "поставщик" (рисунок 13), "консультант" (рисунок 14), "чек" (рисунок 15), "запись списка в чеке"
(рисунок 16).
Рисунок 9 - Поля и типы данных таблицы "producer" - производитель
Рисунок 10 - Поля и типы данных таблицы "articles" - товар
Рисунок 11 - Поля и типы данных таблицы "recording_reg" - запись списка приходной накладной
Рисунок 12 - Поля и типы данных таблицы "register" - приходная накладная
Рисунок 13 - Поля и типы данных таблицы "consultant" - консультант
Рисунок 14 - Поля и типы данных таблицы "receipt" - чек
Рисунок 15 - Поля и типы данных таблицы "recording_rec" - запись списка в чеке
Ключ или возможный ключ - это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Так, для идентификации вагона можно использовать либо инвентарный номер, либо дополнительный идентификатор, за уникальностью которого будет отвечать СУБД Microsoft SQL Server.
Не допускается, чтобы первичный ключ стержневой сущности (любой атрибут, участвующий в первичном ключе) принимал неопределенное значение. Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью, и, следовательно, не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность первичного ключа.
