Информатика и выч. техника \ Базы данных и системы управления базами данных

Разработка базы данных ”Продажа мобильных телефонов” и приложения для работы с ней, страница 4

На физическом уровне:

Между сущностями Модели телефонов и Покупки устанавливаем связь 1:М. Так как купить модель могут много клиентов (1:М), но только одна конкретная модель является покупкой. (1:1).

Модели телефонов – родительская сущность, Покупки – дочерняя.

Связь идентифицирующая.

Между сущностями Модели телефонов и Поставки также устанавливается связь 1:М, так как поставщик может поставить много моделей(1:М), но только конкретная модель является поставкой. (1:1) Связь также идентифицирующая. Модели телефонов-родительская, Поставки-дочерняя сущность.

Между сущностями Модели телефонов и Фирмы производители устанавливается связь М:М, так как у модели много производителей(1:М), и производитель производит много моделей.(1:М) Это связь на логическом уровне.

При переходе же к физическому уровню автоматически будет создана связующая сущность Модели тел_Фирмы произ, которая будет находиться в отношении 1:М к данным сущностям. При этом первичные ключи связываемых сущностей Модели телефонов (Код модели) и Фирмы производители(Код фирмы) мигрируют в связующую сущность, образуя в ней первичный ключ.

На логическом уровне:

На физическом уровне:

Между сущностями Поставщики и Поставки устанавливается связь 1:М, так как поставщик поставляет много поставок, но лишь конкретная модель является поставкой. Связь идентифицирующая.

Поставщики - родительская сущность, Поставки– дочерняя.

Между сущностями Клиенты и Покупки также связь идентифицирующая 1:М. Клиенты - родительская сущность, Покупки - дочерняя.

Между сущностями Клиенты и Звонить устанавливается неидентифицирующая связь. Тогда при связывании сущностей ключевое поле родительской сущности Звонить(Город) мигрирует в состав неключевых атрибутов дочерней сущности и помечается как внешний ключ (FK).

Сущности Поставщики и Звонить также связываются неидентифицирующей связью.

Тогда при связывании сущностей также ключевое поле родительской сущности Звонить(Город) мигрирует в состав неключевых атрибутов дочерней сущности и помечается как внешний ключ (FK).

Свойства каждой из связей можно отредактировать, задав соответствующие имена, мощность.

Например, для связи сущностей Покупки и Модели телефонов(связь 1:М) указываем имя, характеризующее отношение родительской к дочерней сущности (Parent - to - Child):

Модели телефонов Покупки

Для сущностей Поставщики и Модели телефонов (связь М:М) указываем имя связи Parent - to - Child\ Child - to - Parent:

Модели телефонов Поставщики

Аналогично определяются и все остальные оставшиеся связи.

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

Создание физической модели данных.

На физическом уровне необходимо предусмотреть создание правил валидации, представлений.

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

Правила валидации.

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

Для сущности Модель телефона правило валидации задано на атрибут Цена модели, с целью определить ценовой диапазон на модель телефонов, так как мобильный телефон не может стоит 1 р, 20 р…

Таким образом можно ввести только значение из промежутка от 1000 до 30000.

Аналогичное правило валидации задано на атрибут Поставленное Количество сущности Поставки.

Можно ввести только значения от 5 до 10.

Список правил валидации :

Для атрибута Телефон сущности Клиенты( а также сущности Поставщики)установлена маска ввода для удобного ввода телефона.

Создание представлений.

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

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

О модели.

Данное представление содержит информацию о моделях мобильных телефонов из 2х сущностей : Модели телефонов и Фирмы производители.

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

Сумма покупок.

В этом представлении присуствует вычисляемое поле Сумма покупок.

Функция f(n) вводится в New Expression окна Views.

Сумма покупок : [Покупки.Количество]*[Покупки.Цена модели]

Сумма поставок.

Функция f (n)выглядит так :

Суммапоставок:

[Поставки.Поставленное количество]*[Поставки.ЦенаМодели]

Последним этапом создания модели является перенос ее в СУБД (Access). Для этого предварительно создается пустая база данных (закрывается), а из ERWin осуществляется связь с данной базой (при указании полного имени доступа к ней).

Генерируется база данных :

Теперь, открыв в Access свою базу данных, можно увидеть таблицы, созданные на основе сущностей, схему базу данных, на основе связей и запросы на основе представлений.

Схема базы данных :