Преподаватель: доцент кафедры «Прикладная математика» Вихорь Наталия Анатольевна
ФИЗИЧЕСКАЯ МОДЕЛЬ БД Физическая модель определяет размещение БД в памяти компьютера ( особенности хранения данных, методы доступа к ним и т. д.) Физическая модель зависит от конкретной СУБД. Одной и той же логической модели может соответствовать несколько разных физических моделей. СУБД MS Access - реляционная система управления базами данных, поэтому БД MS Access - это совокупность взаимосвязанных таблиц, в каждой из которых содержатся сведения об одной сущности. В СУБД Access процесс физического проектирования БД включает : создание таблиц (определение структуры); создание связей между ними с помощью схемы данных. Схема данных - графическое представление физической МД - полный аналог логической модели; разработка удобного интерфейса: например, экранных форм для ввода и отображения данных, отчетов для вывода данных и других объектов для манипулирования данными.
Пример проектирования базы данных Разработать базу данных, предназначенную для составления строительных смет для ремонта квартир, офисов и т.д. Анализ предметной области: необходимо хранить в БД информацию справочного характера о работах и материалах (наименования, единицы измерения, цена), информацию о заказчиках (наименования, адреса объектов, подлежащих ремонту, параметры объектов, объем работы) Разработка концептуальной модели БД Заключается в описании объектов базы данных – сущностей, определении их характеристик (атрибутов) и в установлении связей между сущностями. Концептуальную модель удобно представлять в виде ER- диаграммы
Смета выполняемых работ (без стоимости материалов) в у.е. Наименование работ Кол. Ед. Цена Сумма Демонтажные работы (цена зависит от наполнености проекта) 1 кварт. 200 200 Комплексная отделка стен (оштукатуривание, грунтовка, шпаклевка, наклейка обоев/окраска) 94 м 2 25,7 2415,8 Комплексная отделка потолка (оштукатуривание, грунтовка, шпаклевка, наклейка обоев/окраска) 33,8 м 2 31,8 1074,8 Устройство стяжки выравнивающими смесями "Ветонит" (наливные полы) 34,2 м 2 7 239,4 Укладка паркетной доски 26,5 м 2 9 238,5 Устройство плинтуса 35,8 м/п 3 107,4 Укладка пола из керамической плитки на кухне 7,3 м 2 21 153,3 Комплексный ремонт с/у ("Под ключ") с изменениями стен санузла (цена зависит от наполненности проекта) 1 шт 2000 2000 Полная замена электропроводки по всей квартире с установкой электрощита в квартире (цена зависит от наполненности проекта) 37,8 м 2 35 1323 Комплексная замена радиаторов 2 шт 120 240 Установка дверей (стоимостью до 300$) 3 шт 90 270 Комплексное устройство откосов (оштукатуривание, шпаклёвка со шлифовкой, окраска) 11 м/п 16 176 Замена подоконников (установка новых) 3,8 м/п 10 38 Итого 8476,2 Смета на ремонт однокомнатной квартиры по адресу ул. Ленина 23-10, заказчик Николаев Н.Н. Общая площадь 37,8 м 2 Жилая площадь 18,9 м 2 Количество комнат 1 Высота потолка 2,64 м
Наименование заказчика Объект Площадь, кв.м. Наименование работы Ед. измер. Цена единицы Объем Сумма Иванов И.И. Ул. Герцена, 2-3 54 Демонтаж стен кв.м. 100 р. 10 1000 р. Иванов И.И. Ул. Герцена, 2-3 54 Грунтовка стен кв.м. 30 р. 100 3000 р. Иванов И.И. Ул. Герцена, 2-3 54 Наклейка обоев кв.м. 15 р. 100 1500 р. Рыкова С.С. Ул. Ленина, 34-1 29 Грунтовка стен кв.м. 30 р. 50 1500 р. Рыкова С.С. Ул. Ленина, 34-1 29 Наклейка обоев кв.м. 15 р. 50 750 р. … … … … … … … Если хранить данные в одной таблице, то имеет место огромная избыточность данных. А если хранить данные о заказчике в одной таблице, а о работах – в другой (справочник работ и материалов) и установить связи между таблицами, то избыточность хранимых данных многократно уменьшится без ущерба для логической организации информации.
Для проектируемой базы данных можно выделить два объекта ( сущности ), которые не будут обладать избыточностью: - Справочник работ и материалов, Заказчик. Справочник Наименование Текст Категория Текст Единица измерения Текст Цена единицы Число Зададим следующие атрибуты сущностей: Заказчик Код заказчика Число Наименование заказчика Текст Объект Текст Общая площадь Число
Рассмотрим связь между сущностями Заказчик и Справочник. Каждый заказчик может заказывать несколько работ или материалов из справочника, и каждая работа или материал может заказываться несколькими заказчиками, следовательно, связь между сущностями Заказчик и Справочник – « многие-ко-многим ». Связи между сущностями ЗАКАЗЧИК СПРАВОЧНИК M N Связь « многие-ко-многим » заменим двумя связями «один-ко-многим» путем создания промежуточной сущности – ЗАКАЗ. Для данной сущности введем атрибуты – Номер заказа, Объем заказа. ЗАКАЗЧИК СПРАВОЧНИК M N ЗАКАЗ 1 1 заказывает заказывает заказывается
Концептуальная модель БД ( ER- диаграмма) ЗАКАЗЧИК СПРАВОЧНИК ЗАКАЗ Код заказчика Наименование заказчика Объект Общая площадь Наименование Категория Единица измерения Цена единицы Номер заказа Объем заказа
Разработка логической модели БД 1. На основе концептуальной модели можно создать три таблицы: Заказчик, Справочник, Заказ. 2. В таблицу Заказ введем два дополнительных поля: Код заказчика, которое будет полем внешнего ключа для связи с таблицей Заказчик Наименование, которое тоже будет полем внешнего ключа для связи с таблицей Справочник Для построения логической модели требуется выполнить следующие действия: Создать по одной таблице для каждой сущности. Имя сущности становится именем таблицы. Каждый атрибут становится столбцом таблицы с тем же именем. Экземпляры сущности - строками таблицы. Ключ сущности становится первичным ключом таблицы. 2. Задать внешний ключ для каждой сущности, вступающей во взаимоотношения с другими сущностями как «многие-к-одному» (со стороны многие).
Логическая модель БД 1 N 1 Заказчик Код заказчика Наименование заказчика Объект Общая площадь Заказ Номер заказа Код заказчика Наименование Объем заказа Справочник Наименование Категория Единица измерения Цена единицы N
Код заказчика Наименование заказчика Объект Общая площадь Иванов И.И. Ул. Герцена, 2-3 54 Иванов И.И. Рыкова С.С. Ул. Ленина, 34-1 29 Рыкова С.С. … … … … Схема отношения ЗАКАЗЧИК Заказчик ( Код заказчика -числовой, Наименование заказчика-текстовый, Объект – текстовый, Общая площадь – числовой) Вид будущей таблицы Заказчик и примерное содержимое таблицы
Наименование Категория Единица измерения Цена единицы Демонтаж стен Демонтажные работы кв.м. 100 р. Грунтовка стен Работа со стенами кв.м. 30 р. Наклейка обоев Работа со стенами кв.м. 15 р. Схема отношения СПРАВОЧНИК Справочник ( Наименование - текстовый, Категория - текстовый, Единица измерения – текстовый, Цена единицы – денежный) Вид будущей таблицы Справочник и примерное содержимое таблицы
Номер заказа Код заказчика Наименование Объем 1 Иванов И.И. Демонтаж стен 10 2 Иванов И.И. Грунтовка стен 100 3 Рыкова С.С. Грунтовка стен 50 Схема отношения ЗАКАЗ Заказ ( Номер заказа - числовой, Код заказчика – числовой, Наименование - текстовый, Объем заказа – числовой) Вид будущей таблицы Справочник и примерное содержимое таблицы
Разработка физической модели БД Этот этап представляет реализацию логической модели с помощью конкретной СУБД, например Access. Создаются три таблицы с помощью Конструктора : Справочник работ и материалов, Заказчик, Заказ.
С помощью окна Схема данных устанавливаются связи между таблицами
Ввод данных в таблицы
Разработка интерфейса: Создание экранных форм для ввода данных
Разработка интерфейса: Создание отчета для печати сметы
Разработка интерфейса: Форма-заставка, появляющаяся при запуске БД содержит кнопки, при нажатии на которые выполняется то или иное действие (работа макросов)
Задание: Пусть в базе данных необходимо хранить информацию о преподавателях некоторого ВУЗа ( табельный номер, фамилия, должность, адрес) и о читаемых ими дисциплинах (название дисциплины, количество часов, семестр). При этом предполагается, что одну дисциплину могут читать несколько преподавателей, а один преподаватель читает только одну дисциплину. Составить концептуальную ( ER- диаграмма ) и логическую модели БД (указать схемы отношений и примерное содержимое таблиц)
