Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

Проведем инфологическое проектирование базы данных технологического процесса.

Сущность «Продукция» имеет присущие ей экземпляры сущности: код продукции, наименование, срок изготовления, код номенклатуры (рис.1).

Рис.1. Сущность «Продукция»

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

Представим предметную область как взаимодействие двух сущностей – «Продукция» и «График выпуска продукции».

«Продукция» состоит в «Номенклатуре продукции». Сущность «Номенклатура продукции» имеет следующие экземпляры сущности: код номенклатуры, наименование, количество продукции в номенклатуре (рис.2).

Рис. 2. Сущность «Номенклатура продукции»

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

Рис.3. Сущность «График выпуска продукции»

Взаимодействие сущностей «Продукция» и «График выпуска продукции» реализуется с помощью отношения «Номенклатура продукции» (рис.4). Мощность связи – один-ко-многим (1:М).

1 М М 1

Рис.4. Взаимодействие сущностей «Продукция» и «График выпуска продукции»

Заключение

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

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

Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером и Мак Леоном в 1981 году, функциональную модель данных Шипмана, также созданную в 1981 году, модель «сущность-связь», предложенную Ченом в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена «сущность-связь», стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД. Все CASE-системы имеют развитые средства документирования процесса разработки БД. Автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным описанием проектов БД и их отношений, как в графическом виде, так и в виде стандартных готовых печатных отчетов, что существенно облегчает ведение проекта.

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

Список литературы

1. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.

2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.

3. Дейт К. Дж. Введение в системы баз данных, 6-е изд.: Пер. с англ. – К., М., СПб.: Издательский дом «Вильямс», 2000. – 848 с.

4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. – 252 с.

5. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.

6. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

7. Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.

8. Хомоненко А.Д. Циганков В.М. Базы данных: Учебник для вузов /Под ред. А.Д. Хомоненко. – М.: Корона, 2000. – 421 с.

9. Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.

Характеристики

Список файлов курсовой работы