Разработка базы данных для объекта автоматизации: гомеопатическая аптека (стр. 2 из 4)

Рассмотрим выходные вектора:

=(номер сотрудника, номер договора, дата договора, номер поставщика, растение, количество растений, цена) – договор с поставщиком.

=(номер сотрудника, номер договора, дата договора, номер покупателя, растение, количество растений, цена) – договор с покупателем.

На основании этих векторов можно выделить следующие функции объекта автоматизации:

- функции заключения нового договоров с покупателем и поставщиком.

- поиск заключенных договоров.

- редактирование договоров (только на стадии выполнения заказа).

- функции администратора базы данных – добавление, редактирование и удаление данных в словарях.

3.2. Структура экранных форм пользовательского интерфейса.

В соответствии с функциями объекта, структуру экранных форм можно представить следующим образом:

4. Концептуальная модель базы данных

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

, где

- структурный аспект.

- функциональный аспект.

- аспект управления.

Функциональный аспект информационной страты объекта автоматизации уже рассмотрели. Структурный аспект будет разобран далее. Аспект управления в данном курсовом проекте рассматриваться не будет.

4.1. Первый уровень структурного аспекта информационной страты объекта

Рассмотрим первый уровень структурного аспекта информационной страты объекта автоматизации:

, где

- информационные элементы объекта автоматизации.

- связи между информационными элементами.

- конфигурация связей.

- параметр связи между элементами.

- параметр, определяющий изменение элементов структурного аспекта во времени.

Анализируя деятельность аптеки можно выделить следующие информационные элементы:

- Е₁ – Данные по договорам.

- Е₂ – Сотрудники.

- Е₃ – Поставщики.

- Е₄ – Покупатели.

- Е₅ – Растения.

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

4.2. Второй уровень структурного аспекта информационной страты объекта.

Второй уровень структурного аспекта информационной страты объекта представляется так:

, где

- компонент информационного элемента Е_i.

- связи между е_ij и е_ik.

- конфигурация связей между информационными элементами.

- параметр связи между элементами е_ij и е_ik.

- параметр, определяющий изменение элементов структурного аспекта во времени.

Раскроем содержание информационных элементов и покажем связи между ними.

Е₁:

е₁₁– номер договора.

е₁₂ – номер сотрудника.

е₁₃– номер клиента.

е₁₄ – дата договора.

е₁₅ – название растения.

е₁₆ – количество растений.

е₁₇ – цена растений.

Е₂:

е₂₁ – номер сотрудника.

е₂₂ – фамилия сотрудника.

е₂₃– имя сотрудника.

е₂₄ – отчество сотрудника.

е₂₅ – телефон сотрудника.

е₂₆ – адрес сотрудника.

е₂₇ – должность сотрудника.

е₂₈ – оклад сотрудника.

Е₃:

е₃₁ – номер поставщика.

е₃₂ – фамилия поставщика.

е₃₃– имя поставщика.

е₃₄ – отчество поставщика.

е₃₅ – телефон поставщика.

е₃₆ – адрес поставщика.

е₃₇ – счет поставщика.

Е₄:

е₄₁ – номер покупателя.

е₄₂ – фамилия покупателя.

е₄₃– имя покупателя.

е₄₄ – отчество покупателя.

е₄₅ – телефон покупателя.

е₄₆ – адрес покупателя.

е₄₇ – счет покупателя.

Е₅:

е₅₁ – номер растения.

е₅₂ – название растения.

е₅₃ – действие, оказываемое растением.

е₅₄ – применение растения.

е₅₅ – изображение растения.

е₅₆ – количество на складе.

е₅₇ – цена растения.

4.3. Функционально-структурный аспект информационной страты объекта

В общем виде информационную страту объекта можно представить так:

Между компонентами входных векторов Х_i и компонентами информационных элементов Е_j должно быть однозначное соответствие. Например:

х₁₁ = е₂₁

х₂₄ = е₃₄

х₃₆ = е₄₆

Между компонентами выходных векторов Y_j и компонентами информационных элементов Е_i должно быть соответствие, которое можно сформулировать следующим образом: множество элементов е_k, принадлежащих информационным элементам Е_i должно быть достаточным для получения множества элементов у_m векторов Y_i. Например:

у₁₁ = е₁₂

у₁₃ = е₁₄

у₂₄ = е₁₃

4.4. Нормализация отношений

Анализ второго уровня концептуальной модели показывает, что в отношении Е₁ существует множественная зависимость, поэтому его следует нормализовать. Это отношение следует представить в четвертой нормальной форме. Таким образом исходное отношение разлагается на три отношения: Е₆ = (номер договора, номер сотрудника, номер клиента), Е₇ = (номер договора, название растения) и Е₈ = (номер договора, количество растений, цена растений):

Прежде чем использовать полученные зависимости их нужно проверить на отсутствие соединения без потерь, то есть при обратном соединении отношений Е₆, Е₇, Е₈ в отношение Е₁ не должна пропадать или появляться новая информация. Для проверки можно использовать метод табло. Этот метод позволяет в табличной форме увидеть отсутствие соединения без потерь.

Метод табло – заполнение таблицы:

е₁₁	е₁₂	е₁₃	е₁₄	е₁₅	е₁₆	е₁₇
Е₆	а₁	а₂	а₃	а₄	b₆₅	b₆₆	b₆₇
Е₇	а₁	b₇₂	b₇₃	b₇₄	а₅	b₇₆	b₇₇
Е₈	b₈₁	b₈₂	b₈₃	b₈₄	а₅	а₆	а₇

Метод табло – проверка функциональных зависимостей из Е₆:

е₁₁	е₁₂	е₁₃	е₁₄	е₁₅	е₁₆	е₁₇
Е₆	а₁	а₂	а₃	а₄	b₆₅	b₆₆	b₆₇
Е₇	а₁	а₂	а₃	а₄	а₅	b₇₆	b₇₇
Е₈	а₁	а₂	а₃	а₄	а₅	а₆	а₇

Метод табло – проверка функциональных зависимостей из Е₇:

е₁₁	е₁₂	е₁₃	е₁₄	е₁₅	е₁₆	е₁₇
Е₆	а₁	а₂	а₃	а₄	а₅	b₆₆	b₆₇
Е₇	а₁	а₂	а₃	а₄	а₅	b₇₆	b₇₇
Е₈	а₁	а₂	а₃	а₄	а₅	а₆	а₇

Метод табло – проверка функциональных зависимостей из Е₈: