Проектирование БД «Производство мебели»
В этой базе заказчик хотел бы хранить информацию
· о различных типах производимой мебели (диваны, столы, шкафы, стулья и т.п.)
· о различных предметах производимой мебели (например, диванов разных моделей)
· о типах деталей, которые необходимы для производства мебели (гайки, шайбы, болты, винты и т.п.)
· о характеристиках каждой поставляемой детали (вес, металл, диаметр и т.п.)
· о поставщиках деталей
Некоторые условия, существенные для проектирования базы данных:
· каждый поставщик может поставлять несколько различных деталей
· одна и та же деталь может поставляться разными поставщиками
· возможна поставка детали одного и того же типа, но с различными характеристиками
· в производстве одного предмета мебели может использоваться несколько различных деталей с разными характеристиками
Этапы проектирования базы данных:
1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
2. определение атрибутов каждой сущности, первичных ключей
3. выявление связей между сущностями
4. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
5. построение ER-диаграмм, отображающих выявленные связи
6. формирование таблиц базы данных по ER-диаграммам:
§ определение нужного количества таблиц
§ определение вторичных ключей таблиц, их связи с соответствующими первичными ключами.
1 и 2 этапы: объекты, их атрибуты и первичные ключи
Список объектов (сущностей):
· тип мебели
· предметы мебели
· тип деталей
· детали
· поставщики
Сущности изображаются в виде прямоугольника, атрибуты вписываются внутрь прямоугольника, изображающего сущность:
 | |||||
 | |||||
| |||||
Атрибут или набор атрибутов, используемый для идентификации экземпляра сущности, называется ключом сущности. Ключевые атрибуты каким-либо образом выделяются на диаграмме (например, подчеркиванием, более жирным шрифтом или курсивом).
Если значения ни одного из атрибутов не обладают уникальностью, то вместо набора уникальных атрибутов можно ввести дополнительный атрибут – код экземпляра (его номер).
 | |||||||
 | |||||||
 |  |  | |||||
3, 4 и 5 этапы: выявление степени связей и классов принадлежности, их фиксация с помощью диаграмм
В этой диаграмме отражены свойства связи двух объектов нашей предметной области (типа мебели и предмета мебели):
· может производиться много различных предметов мебели одного типа (например, много различных диванов)
· каждый предмет мебели – это мебель одного определенного типа
· в базе не будет храниться информация о типах мебели, которая не производится мебельным комбинатом
В этой диаграмме отражены следующие свойства связи двух других объектов нашей предметной области (типа детали и деталей):
· каждая деталь – это деталь одного определенного типа
· возможна поставка нескольких деталей одного типа, но с разными характеристиками
· в базе данных допускается информация о типах деталей, которые еще не используются
· «бестиповых» деталей не бывает
 |
Свойства связи двух объектов нашей предметной области (деталей и поставщиков) таковы:
· каждую деталь может поставлять несколько поставщиков
· каждый поставщик может поставлять несколько разных деталей
· в базе данных допускается наличие поставщиков, которые в данный момент ничего не поставляют
· возможно хранение информации о деталях, которые никто не поставляет
6 этап: формирование таблиц базы данных по ER-диаграммам
В связи сущностей ТИП МЕБЕЛИ Û ПРЕДМЕТЫ МЕБЕЛИ степень связи «один-ко-многим», n-связная сущность имеет обязательный класс принадлежности; следовательно, в соответствии с ER-методом
Достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.
Но у нас в таблице ПРЕДМЕТЫ МЕБЕЛИ уже есть такой атрибут – Тип(он и будет вторичным ключом, соответствующим первичному ключу Наименование).
ТИП МЕБЕЛИ
| Наименование | Описание |
| Диван | … |
| Стол | … |
| Стул | … |
| … | … |
ПРЕДМЕТЫ МЕБЕЛИ
| Код предмета | Тип | Модель | Описание | Изображение | Стоимость |
| Диван | Колибри | … | … | … | |
| Стол | Прима | … | … | … | |
| Диван | Увертюра | … | … | … | |
| … | … | … | … | … | … |
Итак, через первичный ключ Наименование в таблице ТИП МЕБЕЛИ и вторичный ключ Тип в таблице ПРЕДМЕТЫ МЕБЕЛИ будет фиксироваться связь двух сущностей нашей предметной области – ТИПА МЕБЕЛИ и ПРЕДМЕТОВ МЕБЕЛИ.
Аналогично, в связи сущностей ТИП ДЕТАЛЕЙ Û ДЕТАЛИ степень связи «один-ко-многим», n-связная сущность имеет обязательный класс принадлежности; следовательно, в соответствии с ER-методом
Достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.
Но у нас в таблице ДЕТАЛИ уже есть такой атрибут – Тип(он и будет вторичным ключом, соответствующим первичному ключу Наименование).
ТИП ДЕТАЛЕЙ
| Наименование | Изображение | Описание |
| Гайка | … | … |
| Шайба | … | … |
| Гвоздь | … | … |
| … | … | … |
ДЕТАЛИ
| Код детали | Тип | Вес | Диаметр | Металл | Цвет |
| Гайка | Сталь | Серый | |||
| Шайба | Сплав №1 | Черный | |||
| Гайка | Латунь | Желтый | |||
| … | … | … | … | … | … |
Итак, через первичный ключ Наименование в таблице ТИП ДЕТАЛЕЙ и вторичный ключ Тип в таблице ДЕТАЛИ будет фиксироваться связь двух сущностей нашей предметной области – ТИПА ДЕТАЛЕЙ и ДЕТАЛЕЙ.
В связи сущностей ДЕТАЛИ Û ПОСТАВЩИКИ степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц; следовательно,
Необходимо формирование трех таблиц – по одной для каждой сущности (ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы), а также таблицы для связи. Таблица, создаваемая для связи, должна иметь по одному вторичному ключу от каждой сущности.
ПОСТАВЩИКИ
| Код пост | Фамилия И.О. | Страна | Город | Адрес | Телефон | Надежность |
| Орлов А.С. | Россия | Москва | Лесная 34-1-75 | 263-67-89 | ||
| Станов О.Т. | Россия | Курск | Новая 23-56 | 23-45-12 | ||
| Рыбаков И.И. | Украина | Ровно | Рыбная 2-34 | 34-54-12 | ||
| … | … | … | … | … | … | … |
ДЕТАЛИ
| Код детали | Тип | Вес | Диаметр | Металл | Цвет |
| Гайка | Сталь | Серый | |||
| Шайба | Сплав №1 | Черный | |||
| Гайка | Латунь | Желтый | |||
| … | … | … | … | … | … |
ПОСТАВКИ
| Кто | Что | Сколько | Цена изделия | Цена доставки | Дата доставки | Оформлено |
| 234,56р. | 4,56р. | 29.10.03 | да | |||
| 254,90р. | 2,90р. | 5.12.03 | да | |||
| 294,00р. | 4,00р. | 12.01.04 | нет | |||
| 136,58р. | 6,58р. | 20.11.03 | да | |||
| 504,77р. | 5,77р. | 15.11.03 | да |
В таблице-связке ПОСТАВКИ поле Кто является вторичным ключом, соответствующим первичному ключу Код поставщика таблицы ПОСТАВЩИКИ; поле Что является вторичным ключом, соответствующим первичному ключу Код детали таблицы ДЕТАЛИ. С помощью этих вторичных ключей фиксируется связь сущностей ДЕТАЛИ и ПОСТАВЩИКИ. Дополнительные поля в таблице ПОСТАВКИ могут использоваться для уточнения характеристик этой связи.
В связи сущностей ДЕТАЛИ Û ПРЕДМЕТЫ МЕБЕЛИ степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц; следовательно,
Необходимо формирование трех таблиц – по одной для каждой сущности (ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы), а также таблицы для связи. Таблица, создаваемая для связи, должна иметь по одному вторичному ключу от каждой сущности.
ПРЕДМЕТЫ МЕБЕЛИ
| Код предмета | Тип | Модель | Описание | Изображение | Стоимость |
| Диван | Колибри | … | … | … | |
| Стол | Прима | … | … | … | |
| Диван | Увертюра | … | … | … | |
| … | … | … | … | … | … |
ДЕТАЛИ
| Код детали | Тип | Вес | Диаметр | Металл | Цвет |
| Гайка | Сталь | Серый | |||
| Шайба | Сплав №1 | Черный | |||
| Гайка | Латунь | Желтый | |||
| … | … | … | … | … | … |
ИСПОЛЬЗОВАНИЕ ДЕТАЛЕЙ
| Где | Что | Сколько |
Поле Где является вторичным ключом, соответствующим первичному ключу Код предмета таблицы ПРЕДМЕТЫ МЕБЕЛИ; поле Что является вторичным ключом, соответствующим первичному ключу Код детали таблицы ДЕТАЛИ. Таким образом, в таблице-связке ИСПОЛЬЗОВАНИЕ ДЕТАЛЕЙ с помощью двух вторичных ключей Где и Что отражена связь сущностей ПРЕДМЕТЫ МЕБЕЛИ и ДЕТАЛИ. Поле Сколько уточняет одно из свойств этой связи – количество деталей, используемых в производстве конкретного предмета мебели.
Таким образом, проектирование базы данных «Производство мебели» завершено.
База данных «Лесничество»
Требуется создать базу данных для небольшого лесничества. В этой базе заказчик хотел бы хранить информацию
· о лесниках, работающих в этом лесничестве
· о наличии в питомнике саженцев разных пород
· об участках, работу на которых ведут лесники
· в чем эта работа заключается (саженцы какой породы и в каком количестве должны быть посажены на конкретных участках)
Некоторые условия работы лесничества, существенные для проектирования базы данных:
· каждый участок может обслуживать несколько лесников
· на каждом участке возможны посадки саженцев разных пород в разном количестве.
Замечание: если при проектировании базы данных разработчику пришлось принимать дополнительные соглашения об информации, которая должна храниться в базе данных, то эти соглашения должны быть описаны в отчете.
Этапы проектирования базы данных:
1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
2. определение атрибутов каждой сущности
3. выявление связей между сущностями
4. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
5. построение ER-диаграмм, отображающих выявленные связи
6. формирование таблиц базы данных по ER-диаграммам:
§ определение нужного количества таблиц
§ определение первичных и вторичных ключей таблиц
Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.
· выявленные объекты
· их атрибуты
· связи между объектами
· классы принадлежности (с обоснованием принятых решений)
· соответствующие ER-диаграммы
· описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)
Этапы реализации базы данных в Access:
1. создание описания таблиц (обычно в режиме конструктора)
2. создание схемы базы данных
3. создание форм, удобных для ввода данных в таблицу
4. создание кнопочной формы-заставки
5. заполнение таблиц (с использованием форм)
Форма отчета: показ на машине всех элементов созданной базы данных.
База данных «Библиотека»
Требуется создать базу данных библиотеки. В этой базе заказчик хотел бы хранить информацию
· о книгах, которые есть в этой библиотеке, и о том, к какому разделу относится каждая книга
· об авторах, чьи книги есть в этой библиотеке
· о читателях, которые берут книги в этой библиотеке
Некоторые условия работы библиотеки, существенные для проектирования базы данных:
· каждая книга принадлежит какому-то разделу; может быть много книг, относящихся к одному разделу; возможен раздел, в котором нет книг
· в библиотеке может быть много книг одного автора
· каждый читатель может взять в библиотеке несколько книг
Замечание: если при проектировании базы данных разработчику пришлось принимать дополнительные соглашения об информации, которая должна храниться в базе данных, то эти соглашения должны быть описаны в отчете.
Этапы проектирования базы данных:
1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
2. определение атрибутов каждой сущности
3. выявление связей между сущностями
4. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
5. построение ER-диаграмм, отображающих выявленные связи
6. формирование таблиц базы данных по ER-диаграммам:
§ определение нужного количества таблиц
§ определение первичных и вторичных ключей таблиц
Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.
· выявленные объекты
· их атрибуты
· связи между объектами
· классы принадлежности (с обоснованием принятых решений)
· соответствующие ER-диаграммы
· описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)
Этапы реализации базы данных в Access:
1. создание описания таблиц (обычно в режиме конструктора)
14. создание схемы базы данных
15. создание форм, удобных для ввода данных в таблицу
16. создание кнопочной формы-заставки
17. заполнение таблиц (с использованием форм)
Форма отчета: показ на машине всех элементов созданной базы данных.
База данных «Автопарк»
Требуется создать базу данных для автобусного парка. В этой базе заказчик хотел бы хранить информацию
· о том, какие водители на каких маршрутах могут работать (т.е. знают эти маршруты)
· о наличии и состоянии подвижного состава автобусного парка
· о том, какие автобусы закреплены за какими водителями
Некоторые условия работы автобусного парка, существенные для проектирования базы данных:
· каждый водитель может знать несколько маршрутов; каждый маршрут обслуживается несколькими водителями
· один автобус может быть закреплен за несколькими водителями; но каждый водитель всегда ездит на одном и том же автобусе (хотя, возможно, по разным маршрутам).
Замечание: если при проектировании базы данных разработчику пришлось принимать дополнительные соглашения об информации, которая должна храниться в базе данных, то эти соглашения должны быть описаны в отчете.
Этапы проектирования базы данных:
1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
2. определение атрибутов каждой сущности
3. выявление связей между сущностями
4. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
5. построение ER-диаграмм, отображающих выявленные связи
6. формирование таблиц базы данных по ER-диаграммам:
§ определение нужного количества таблиц
§ определение первичных и вторичных ключей таблиц
Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.
· выявленные объекты
· их атрибуты
· связи между объектами
· классы принадлежности (с обоснованием принятых решений)
· соответствующие ER-диаграммы
· описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)
Этапы реализации базы данных в Access:
1. создание описания таблиц (обычно в режиме конструктора)
2. создание схемы базы данных
3. создание форм, удобных для ввода данных в таблицу
4. создание кнопочной формы-заставки
5. заполнение таблиц (с использованием форм)
Отчет: показ на машине всех элементов созданной базы данных.