Использование деталей

Где	Что	Сколько

Поле Где является вторичным ключом, соответствующим первичному ключу Код предмета таблицы ПРЕДМЕТЫ МЕБЕЛИ; поле Что является вторичным ключом, соответствующим первичному ключу Код детали таблицы ДЕТАЛИ. Таким образом, в таблице-связке ИСПОЛЬЗОВАНИЕ ДЕТАЛЕЙ с помощью двух вторичных ключей Где и Что отражена связь сущностей ПРЕДМЕТЫ МЕБЕЛИ и ДЕТАЛИ. Поле Сколько уточняет одно из свойств этой связи – количество деталей, используемых в производстве конкретного предмета мебели.

Таким образом, проектирование базы данных «Производство мебели» завершено.

База данных «Лесничество»

Требуется создать базу данных для небольшого лесничества. В этой базе заказчик хотел бы хранить информацию

· о лесниках, работающих в этом лесничестве

· о наличии в питомнике саженцев разных пород

· об участках, работу на которых ведут лесники

· в чем эта работа заключается (саженцы какой породы и в каком количестве должны быть посажены на конкретных участках)

Некоторые условия работы лесничества, существенные для проектирования базы данных:

· каждый участок может обслуживать несколько лесников

· на каждом участке возможны посадки саженцев разных пород в разном количестве.

Замечание: если при проектировании базы данных разработчику пришлось принимать дополнительные соглашения об информации, которая должна храниться в базе данных, то эти соглашения должны быть описаны в отчете.

Этапы проектирования базы данных:

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. заполнение таблиц (с использованием форм)

Отчет: показ на машине всех элементов созданной базы данных.

Краткое описание ER–метода проектирования реляционных баз данных

(метод, использующий схему «сущность-связь» -«Entity-Relationship»)

Одним из наиболее понятных и практически используемых методов проектирования реляционных баз данных является метод семантического моделирования. В качестве инструмента используются различные варианты диаграмм.

ОПРЕДЕЛЕНИЯ:

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

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

Связь – это некоторая ассоциация между двумя сущностями.

Атрибут – это свойство сущности.

Сущность – это, как правило, существительное; связь чаще всего выражается глаголом.

Например, проектируется база данных издательства, предназначенная для хранения информации о книгах и авторах, которые их написали. Тогда два главных объекта (две сущности, информация о которых должна быть отражена в базе данных) – это книга и автор. Эти сущности содержательно соединены с помощью связи пишет. Атрибуты сущности книга – это название, количество страниц, тираж, дата выхода сигнального экземпляра, цена и т.д. Атрибуты сущности автор – это фамилия, адрес, телефон, №счета и т.д.

Сущности изображаются в виде прямоугольника, атрибуты вписываются внутрь прямоугольника, изображающего сущность:

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

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

В нашем примере в качестве ключевого атрибута сущности АВТОР было решено взять фамилию, а в качестве ключевого атрибута сущности КНИГА взять её название. Первое решение заведомо не является бесспорным: возможно появление авторов-однофамильцев (тогда атрибут Фамилия И.О. теряет уникальность и не может быть использован в качестве ключа). В принципе, допустимо появление книг с одинаковыми названиями.

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

Если окажется, что ни один содержательный атрибут не может быть использован как ключевой, то существует (по меньшей мере) два способа решения этой проблемы:

· подобрать набор атрибутов, значения которых будут уникальными для каждого экземпляра сущности;

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

Для нашего примера выберем второй способ:

Связь между двумя сущностями может быть представлена графически в виде ER-диаграммы:

Важной характеристикой связи является степень связи. Возможны следующие степени связи: один-к-одному, один-ко-многим и многие-ко-многим.

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

Связь ОДИН-К-ОДНОМУ:

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

Если все экземпляры сущности должны участвовать в связи, то участие называется обязательным, и изображается на ER-диаграмме кружком, помещенным в блок, изображающий сущность (при словесной формулировке такой связи обычно используется глагол «должен»):

В этой диаграмме отражено правило: «каждый автор должен писать книгу, причем только одну, и каждую книгу должен писать только один автор», т.е. в базе данных не будет информации об авторах, не пишущих ни одной книги, а также информации о книгах, которые пока никто не пишет.

Если не все экземпляры сущности должны участвовать в связи, то участие называется необязательным, и кружок на ER-диаграмме располагается вне блока сущности (при словесной формулировке такой связи обычно используется глагол «может»):

В этой диаграмме отражено правило: «каждый автор может писать не более одной книги, и каждую книгу должен писать только один автор», т.е. в базе данных допускается наличие авторов, не пишущих ни одной книги, но нет информации о книгах, которые пока никто не пишет.

Для сущностей АВТОР - КНИГА возможны еще два типа связи один-к-одному, отражающих два оставшихся варианта обязательности включения экземпляров:

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

«Каждый автор пишет не более одной книги, и каждая книга пишется не более чем одним автором», т.е. в базе данных допускается наличие авторов, не пишущих сейчас ни одной книги, и наличие книг, которые еще никто не пишет.

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

Связь ОДИН-КО -МНОГИМ:

Связь один-ко-многим подразумевает, что один экземпляр сущности, расположенной в левой части диаграммы, связан с несколькими экземплярами сущности, расположенной в правой части диаграммы.

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

Следующая диаграмма отражает связь один-ко-многим сущностей АВТОР – КНИГА, где экземпляры обеих сущностей вступают в обязательную связь:

Таким образом, в этой диаграмме отражено правило: «каждую книгу пишет только один автор, но каждый автор может писать несколько книг»; обязательность включения экземпляров говорит о том, что в базе данных не будет информации об авторах, не пишущих ни одной книги, а также информации о книгах, которые пока никто не пишет.

В этой диаграмме отражено правило: «каждую книгу пишет только один автор, каждый автор может писать несколько книг либо не писать их вовсе», т.е. в базе данных допускается наличие авторов, не пишущих ни одной книги, но нет информации о книгах, которые пока никто не пишет.

Для сущностей АВТОР - КНИГА возможны еще два типа связи один-ко-многим, отражающих два оставшихся варианта обязательности включения экземпляров:

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

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

Аналогично анализируются и фиксируются все варианты связи один-ко-многим сущностей КНИГА - АВТОР (с учетом обязательности / необязательности участия в связи всех экземпляров этих сущностей).

Например, в этой диаграмме отражено правило: «каждую книгу пишут несколько авторов, каждый автор должен писать только одну книгу»; обязательность включения экземпляров говорит о том, что в базе данных не будет информации об авторах, не пишущих ни одной книги, а также информации о книгах, которые пока никто не пишет.

Связь МНОГИЕ-КО -МНОГИМ:

Связь многие-ко-многим подразумевает, что один экземпляр сущности, расположенной в левой части диаграммы, связан с несколькими экземплярами сущности, расположенной в правой части диаграммы, и один экземпляр сущности, расположенной в правой части диаграммы, связан с несколькими экземплярами сущности, расположенной в левой части диаграммы.

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

Следующая диаграмма отражает связь многие-ко-многим сущностей АВТОР – КНИГА, где экземпляры обеих сущностей вступают в обязательную связь:

Таким образом, в этой диаграмме отражено правило: «каждую книгу пишут несколько авторов, каждый автор пишет несколько книг»; обязательность включения экземпляров говорит о том, что в базе данных не будет информации об авторах, не пишущих ни одной книги, а также информации о книгах, которые пока никто не пишет.

В этой диаграмме отражено правило: «каждую книгу пишут несколько авторов, каждый автор может писать несколько книг либо не писать их вовсе», т.е. в базе данных допускается наличие авторов, не пишущих ни одной книги, но нет информации о книгах, которые пока никто не пишет.

Для сущностей АВТОР - КНИГА возможны еще два типа связи многие-ко-многим, отражающих два оставшихся варианта обязательности включения экземпляров:

«Каждую книгу может писать несколько авторов; каждый автор может писать несколько книг (но должен писать хотя бы одну)», т.е. в базе данных не будет информации об авторах, которые не пишут ни одной книги, но допускается хранить информацию о книгах, которые еще никто не пишет.

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