Лабораторная работа № 3.
Тема: Обсуждение модели предметной области.
При проектировании базы данных решаются две основных проблемы:
-
Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.). Часто эту проблему называют проблемой логического проектирования баз данных.
-
Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных.
Проблема проектирования реляционной базы данных, в первую очередь, состоит в обоснованном принятии решений о том,
-
из каких отношений должна состоять БД и
-
какие атрибуты должны быть у этих отношений.
Потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных. Любая развитая семантическая модель данных, как и реляционная модель, включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики данных.
Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
Одной из наиболее популярных семантических моделей данных является модель СУЩНОСТЬ-СВЯЗЬ (ENTITY-RELATION). Ключевыми понятиями этой модели являются Сущность – Связь-Атрибут.
Получение реляционной схемы из er-схемы
Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.
Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
Шаг 6.Для реализации связи многие-ко-многим создается отдельная таблица с внешними ключами связываемых сущностей.
Если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей; все эти столбцы могут содержать неопределенные значения.
Проектирование бд оптовой фирмы "Здоровье"
На практике мы будем решать задачу создания базы данных, которая позволит сохранять и анализировать информацию о сбыте товара через свою торговую сеть. Это будет наша предметная область.
Перед созданием базы данных необходимо располагать описанием выбранной предметной области. В нашем случае круг сведений, интересующий нас, будет включать следующую информацию:
-
Товары, которыми располагает фирма
-
Список магазинов, через которые происходит сбыт
-
Форма заказа
Необходимые данные хранятся в следующих документах:
-
Прайс-листы фирмы
-
Бланки заказов
-
Договора с магазинами на сбыт товара и с описанием форм расчета
Д
Типы 1
M N 1 M M
Разберитесь со схемой данных.
Данной диаграмме в реляционной схеме будет соответствовать следующий набор таблиц:
-
Магазины
-
Продукты
-
ТипыПродуктов
-
Заказы
-
ПродуктыЗаказа
Для каждого типа сущностей, которые мы будем представлять таблицей, нам необходимо продумать характеристики (атрибуты), которые для нас важны для построения БД. Это атрибуты, сведения о которых есть в документах, которые являются основой для информационного моделирования.
М
агазины
(КодМагазина,Название, Адрес, Район
города, Директор, Телефон)
Часть Таблицы Магазины
|
Магазины |
|||||
|
КодМагазина |
Название |
Адрес |
РайонГорода |
ДиректорМагазина |
Телефон |
|
1 |
Абрикос |
ул. Макрушина 24 |
Кировский район |
Белова Н.А. |
41-81-91 |
|
2 |
Быстроном |
ул. Учебная 48а |
Кировский район |
Новиков С.Б. |
55-45-06 |
|
3 |
Фог-сити |
ул. Учебная |
Кировский район |
Бабкина С.М. |
53-14-40 |
|
4 |
Лама |
ул. Красноармейская (ТЦ «Садко») |
Кировский район |
Воронова М.Б. |
41-29-15 |
|
5 |
Лама |
ул. Новгородская |
Кировский район |
Кротов С.Б. |
50-52-29 |
|
6 |
Экономный |
ул. Киевская 57 |
Кировский район |
Акбаев И.А. |
412-419 |
|
7 |
Русский |
ул. Советская 46 |
Кировский район |
Кралев С.Н. |
52-69-55 |
|
8 |
Добрыня |
ул. Дзержинского 54а |
Кировский район |
Крылова А.Б. |
50-70-68 |
|
9 |
Лайт |
пр. Кирова 22 |
Кировский район |
Ясенева В.О. |
52-70-68 |
|
10 |
Копеечка |
ул. Киевская 11а |
Кировский район |
Дорошенко |
52-70-68 |
Продукты (КодПродуктаНазвание, ТипПродукта, Белки, Жиры, Углеводы, Калории)
ТипыПродуктов(КодТипа,Название)
Заказы(КодЗаказа,КодМагазина,ДатаРазмещения, ДатаНазначения, ДатаИсполнения, ДатаОплаты)
ПродуктыЗаказа(КодЗаказа, КодТовара, Цена,Количество, Скидка)
После того, как характеристики типов сущностей мы установим, необходимо подумать какими типами данных они будут представлены в Access и какие дополнительные свойства будут иметь поля БД.