2.2. Арм руководителя ооо «Амрита»

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

У руководителя установлена программа «АРМ Руководителя», которая обслуживается компанией «ЭОС» (Электронные Офисные Системы) – это ведущий российский производитель и поставщик систем автоматизации документооборота и делопроизводства, ECM-систем.

Адрес месторасположения компании: 107113, Москва, ул.Шумкина, д. 20 .

Программа «АРМ Руководитель» дает возможность генеральному директору ООО «Амрита» работать с документами как с помощью компьютера, так и с помощью мобильного планшетного устройства. 

С помощью «АРМ руководителя» генеральный директор ООО «Амрита» имеет возможность:

- работать с большим объемом документов, поступающих на рассмотрение, согласование и подписание;

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

- работать в системе, где все интуитивно просто и понятно – присутствует только достаточное количество функций, необходимых руководящему работнику;

- может накладывать на документы текстовые, графические и аудиорезолюции;

- быстро искать нужные документы (из тех документов, что уже были получены руководителем в подсистеме).

Глава 3. Проектирование и разработка базы данных автоматизированного рабочего места руководителя торговой фирмы ооо «Амрита» в субд ms Access

3.1. Построение базы данных автоматизированного рабочего места руководителя торговой фирмы ооо «Амрита»

Описание предметной области

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

Блок ЗАКАЗЫ КЛИЕНТОВ

• Сущность Клиенты

• Сущность Заказы

• Сущность Заказано

• Сущность Доставка

Блок ПЕРСОНАЛ КОМПАНИИ

• Сущность Сотрудники

• Сущность Обслуживание клиентов

Блок ПОСТАВКИ

• Сущность Поставщики

• Сущность Товары

• Сущность Получатель

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

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

Концептуальная модель

П оставщики

Название Адрес Телефон Город Должность ИНН поставщика

Заказано

Цена Кол-во товаров Скидка

Доставка

Стоимость Название Телефон Дата доставки

Товары Название Цена М инимальный запас		Заказы
		Дата заказа Оплачено(в руб)
С отрудники
Фамилия Имя Должность Дата рождения Адрес Город Телефон Семейное положение Стаж работы Паспорт серия Паспорт номер Оклад

Получатель Название компании Руководитель компании Фамилия Имя Отчество Адрес компании ИНН руководителя Город Телефон компании		Клиенты
		Название Должность Адрес Город Телефон
Обслуживание клиентов
Название клиента

Логическая структура базы данных

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

Процесс разработки модели базы данных состоит в создании сущностей и их атрибутов, а также в задании связей между различными сущностями. Для создания логической модели воспользуемся Erwin Data Modeler(см. рис. 3.1).

Рис. 3.1. Логическая модель БД.

Описательная таблица логической модели(см. рис. 3.2).

Название сущности	Атрибуты	Описание
Поставщики	Название Адрес Телефон Город Должность ИНН поставщика	Первичный ключ: Код поставщика(PK)
Товары	Название Цена Минимальный запас(шт)	Первичный ключ: Код товара(PK) Вторичный ключ: Код получателя(FK), Код поставщика(FK)
Заказы	Дата заказа Оплачено(в руб)	Первичный ключ: Код заказа (PK) Вторичный ключ: Код доставки(FK), Код клиента(FK)
Заказано	Цена Кол-во товаров Скидка	Вторичный ключ: Код товара(FK), Код заказа(FK)
Сотрудники	Фамилия Имя Должность Дата рождения Адрес Город Телефон Семейное положение Стаж работы Паспорт серия Паспорт номер Оклад	Первичный ключ: Код сотрудника(PK)
Обслуживание клиентов	Название клиента	Вторичный ключ: Код сотрудника(FK), Код заказа(FK)
Получатель	Название компании Руководитель компании Фамилия Имя Отчество Адрес компании ИНН руководителя Город Телефон компании	Первичный ключ: Код получателя (PK)
Клиенты	Название Должность Адрес Город Телефон	Первичный ключ: Код клиента (PK)
Доставка	Стоимость Название Телефон Дата доставки	Первичный ключ: Код доставки (PK)

Рис. 3.2. Описательная таблица логической модели.

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

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

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

Для создания физической модели, перенесём созданную в Erwin Data Modeler логическую модель в Microsoft Access (см. рис. 3.3).

Рис. 3.3. Физическая модель БД.