Разработка серверной части ИС

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

• 1) нормализация сущностей предметной области:
  • · получить список атрибутов сущности;
  • · определить возможные ключи отношения;
  • · определить функциональные зависимости (ФЗ) в сущности;
• 2) проверка правильности логической модели реляционной базы данных, проверка отношений на соответствие нормальным формам.

Выявим атрибуты сущностей и назначим первичные ключи:

• 1) Сущность Клиенты содержит атрибуты: Код клиента, Ф.И.О. полностью, Пол, Дата рождения, E-Mail, Город, Код региона, Адрес, Семейное положение, Материальное положение, Род занятий, Откуда узнали, Примечание. Первичный ключ — Код клиента.
• 2) Сущность Контакты содержит атрибуты: Код контакта, Тип контакта, Контакт, Код клиента. Первичный ключ — Код контакта.
• 3) Сущность Типы контактов содержит атрибуты: Код типа контакта, Тип контакта. Первичный ключ — Код типа контакта.
• 4) Сущность Дисконтные карты содержит атрибуты: Номер дисконтной карты, Тип дисконтной карты, Код клиента. Первичный ключ — Номер дисконтной карты.
• 5) Сущность Типы дисконтных карт содержит атрибуты: Код типа дисконтной карты, Тип дисконтной карты. Первичный ключ — Код типа дисконтной карты.
• 6) Сущность Средства массовой информации (СМИ) содержит атрибуты: Код СМИ, Тип СМИ, Название СМИ, Код клиента. Первичный ключ — Код СМИ.
• 7) Сущность Тип СМИ содержит атрибуты: Код типа СМИ, Тип СМИ. Первичный ключ — Код типа СМИ.
• 8) Сущность Анкеты содержит атрибуты: Код анкеты, Тип вопроса, Ответ, Код клиента. Первичный ключ — Код Анкеты.
• 9) Сущность Тип вопроса содержит атрибуты: Код типа вопроса, Тип вопроса. Первичный ключ — Код типа вопроса.
• 10) Сущность Род занятий содержит атрибуты: Код рода занятия, Род занятий. Первичный ключ — Код рода занятия.
• 11) Сущность Источники знаний содержит атрибуты: Код источники знаний, Источники знаний. Первичный ключ — Код источники знаний.
• 12) Сущность Материальное положение содержит атрибуты: Код материального положения, Материальное положение. Первичный ключ — Код материального положения.
• 13) Сущность Регионы содержит атрибуты: Код региона, Регион, Страна. Первичный ключ — Код региона.
• 14) Сущность Продажи содержит атрибуты: Код продажи, Артикул, Дата продажи, Цена, Код клиента. Первичный ключ — Код продажи.
• 15) Сущность Товар содержит атрибуты: Артикул, Код фасона, Код модели, Код сезона, изображение. Первичный ключ — Артикул.
• 16) Сущность Фасоны содержит атрибуты: Код фасона, Фасон. Первичный ключ — Код фасона.
• 17) Сущность Модели содержит атрибуты: Код модели, Модель. Первичный ключ — Код фасона.
• 18) Сущность Сезоны содержит атрибуты: Код сезона, Сезон. Первичный ключ — Код сезона.

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

1) Связь Клиенты — Контакты. Получим отношение:

Рис. 2.18. Отношение Клиенты — Контакты

2)Связь Типы контактов — Контакты. Получим отношение:

Рис. 2.19. Отношение Типы контактов — Контакты

3) Связь Клиенты — Дисконтные карты. Получим отношение:

Рис. 2.20. Отношение Клиенты — Дисконтные карты

4) Связь Типы дисконтных карт — Дисконтные карты. Получим отношение:

Рис. 2.21. Отношение Типы дисконтных карт — Дисконтные карты

5)Связь Клиенты — СМИ. Получим отношение:

Рис. 2.22. Отношение Клиенты — СМИ

6) Связь Тип СМИ — СМИ. Получим отношение:

Рис. 2.23. Отношение Тип СМИ — СМИ

7) Связь Клиенты — Анкеты. Получим отношение:

Рис. 2.24. Отношение Клиенты — Анкеты

8)Связь Тип вопроса — Анкеты. Получим отношение:

Рис. 2.25. Отношение Тип вопроса — Анкеты

9) Связь Клиенты — Род занятий. Получим отношение:

Рис. 2.26. Отношение Клиенты — Род занятий

10) Связь Клиенты — Материальное положение. Получим отношение:

Рис. 2.27. Отношение Клиенты — Материальное положение

11)Связь Клиенты — Источник знаний. Получим отношение:

Рис. 2.28. Отношение Клиенты — Источник знаний

12) Связь Клиенты — Регионы. Получим отношение:

Рис. 2.29. Отношение Клиенты — Регионы

13) Связь Клиенты — Продажи. Получим отношение:

Рис. 2.30. Отношение Клиенты — Продажи

14)Связь Продажи — Товары. Получим отношение:

Рис. 2.31. Отношение Продажи — Товары

15) Связь Фасоны — Товары. Получим отношение:

Рис. 2.32. Отношение Фасоны — Товары

16) Связь Модели — Товары. Получим отношение:

Рис. 2.33. Отношение Модели — Товары

17)Связь Сезоны — Товары. Получим отношение:

Рис. 2.34. Отношение Сезоны — Товары

Различают несколько типов нормальных форм (НФ). Каждая из них ограничивает присутствие определенного класса функциональных зависимостей (ФЗ) в отношении.

Выделяют 1НФ, 2НФ, 3НФ, БКНФ, 4НФ, 5НФ, НФБК. Каждая нормальная форма сохраняет свойства предыдущих нормальных форм. Переход к более высокой НФ выполняется путем декомпозиции исходного отношения на два или более отношений, удовлетворяющих требованиям этой НФ.

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

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

Отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и все неключевые атрибуты отношения функционально полно зависят от составного ключа отношения. Иными словами, 2НФ требует, чтобы отношение не содержало частичных ФЗ.

Все отношения (таблицы), первичный ключ которых не является составным, в рассматриваемой базе также находятся в 2НФ.

Отношение находится в третьей нормальной форме (3НФ), если оно находится во 2НФ, и все неключевые атрибуты отношения зависят только от первичного ключа. Иными словами, 3НФ требует, чтобы отношение не содержало транзитивных ФЗ неключевых атрибутов от ключа, т. е. отсутствуют ФЗ между неключевыми атрибутами.

Отношение находится в нормальной форме Бойса-Кодда (НФБК), если оно находится в 3НФ, и в нем отсутствуют зависимости ключевых атрибутов от неключевых атрибутов.

Проверим принадлежность каждого из отношений к НФБК.

1) Отношение «Clients»:

Рис. 2.35. Диаграмма функциональной зависимости «Clients»

2) Отношение «Contacts»:

Рис. 2.36. Диаграмма функциональной зависимости «Contacts»

3)Отношение «ContactType»:

Рис. 2.37. Диаграмма функциональной зависимости «ContactType»

4) Отношение «Discounts»:

Рис. 2.38. Диаграмма функциональной зависимости «Discounts»

5) Отношение «DiscountType»:

Рис. 2.39. Диаграмма функциональной зависимости «DiscountType»

6) Отношение «SMI»:

Рис. 2.40. Диаграмма функциональной зависимости «SMI»

7) Отношение «SMIType»:

Рис. 2.41. Диаграмма функциональной зависимости «SMIType»

8)Отношение «Blanks»:

Рис. 2.42. Диаграмма функциональной зависимости «Blanks»

9) Отношение «BlankType»:

Рис. 2.43. Диаграмма функциональной зависимости «BlankType»

10) Отношение «LifeStatus»:

Рис. 2.44. Диаграмма функциональной зависимости «LifeStatus»

11) Отношение «FamilyPosition»:

Рис. 2.45. Диаграмма функциональной зависимости «FamilyPosition»

12) Отношение «Knows»:

Рис. 2.46. Диаграмма функциональной зависимости «Knows»

13)Отношение «Regions»:

Рис. 2.47. Диаграмма функциональной зависимости «Regions»

14) Отношение «Sales»:

Рис. 2.48. Диаграмма функциональной зависимости «Sales»

15) Отношение «Article»:

Рис. 2.49. Диаграмма функциональной зависимости «Article»

16) Отношение «Fashion»:

Рис. 2.50. Диаграмма функциональной зависимости «Fashion»

17)Отношение «Model»:

Рис. 2.51. Диаграмма функциональной зависимости «Model»

18) Отношение «Season»:

Рис. 2.52. Диаграмма функциональной зависимости «Season»

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

Схема реализованной базы данных представлена в Приложении 3.

При разработке данной программной системы был обеспечен контроль целостности данных по 3-уровневой схеме:

• 1) Контроль целостности связи.
• 2) Уровень хранимых процедур. Чтобы ограничить возможности пользователя по доступу к базе данных, в том числе и к совершению нежелательных и вредоносных действий, все операции, доступные пользователю, были оформлены в виде хранимых процедур.
• 3) Уровень клиентского приложения. Перед вызовом хранимых процедур приложение самостоятельно проверяет семантику некоторых передаваемых параметров. И после проверки передает управление хранимым процедурам, которые в свою очередь возвращают коды ошибок в случае нарушения целостности базы данных.

Частные ограничения целостности данных приведены в таблице 2.1.

Таблица 2.1.

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

• 1) sp_Add_Clients (@FIO (char (50)), @Sex (char (7)), @BirthDate (datetime), @EMail (char (30)), @City (char (30)), @Region (int), @Address (char (50)), @FamilyStatus (char (20)), @FamilyPosition (int), @Knows (int), @LifeStatus (int), @Node (char (100)), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о новых клиентах. Если введены некорректные данные, то процедура возвращает соответствующее значение параметра Returns, на основании которого пользователю будет выдано сообщение. Если данные корректны — запись будет добавлена.
• 2) sp_Add_Article (@Article (char (10)), @Fashion (int), @Model (int), @Season (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о новых товарах. Принцип действия аналогичен sp_Add_Clients.
• 3) sp_Add_Blanks (@BlankType (int), @Answer (char (45)), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации об ответах клиентов на вопросы анкет. Принцип действия аналогичен sp_Add_Clients.
• 4) sp_Add_Contact (@ContactType (int), @Contact (char (15)), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о контактах клиентов. Принцип действия аналогичен sp_Add_Clients.
• 5) sp_Add_Discount (@IDDiscount (int), @DiscountType (int), @DiscountSize (int), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о дисконтных картах клиента. Принцип действия аналогичен sp_Add_Clients.
• 6) sp_Add_Sales (@Article (char (10)), @Article (char (10)), @Price (int), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о новых продажах клиентам. Принцип действия аналогичен sp_Add_Clients.
• 7) sp_Add_SMI (@SMIType (int), @SMI (char (30)), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о предпочитаемых клиентами СМИ. Принцип действия аналогичен sp_Add_Clients.
• 8) sp_Update_Client (@ID (int), @FIO (char (50)), @Sex (char (7)), @BirthDate (datetime), @EMail (char (30)), @City (char (30)), @Region (int), @Address (char (50)), @FamilyStatus (char (20)), @FamilyPosition (int), @Knows (int), @LifeStatus (int), @Node (char (100)), Returns (int)). Процедура предназначена для проверки целостности данных при изменении информации о товарах. Если введены некорректные данные, то процедура возвращает соответствующее значение параметра Returns, на основании которого пользователю будет выдано сообщение. Если данные корректны — запись будет изменена.
• 9) sp_Update_Article (@Article (char (10)), @Fashion (int), @Model (int), @Season (int), Returns (int)). Процедура предназначена для проверки целостности данных при изменении информации о клиентах. Принцип действия аналогичен sp_Update_Client.