Реферат: Инфологическая модель баз данных "Сущность-связь" - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Инфологическая модель баз данных "Сущность-связь"

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 194 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Инфологическая модель баз данных "Сущность-связь " Основные понятия Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации , которую предполагается хранить в создаваемой базе данных . Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка ). Основными конструктивными элементами инфологических моделей являются сущности , связи межд у ними и их свойства (атрибуты ). Сущность – любой различимый объект (объект , который мы можем отличить от другого ), информацию о котором необходимо хранить в базе данных . Сущностями могут быть люди , места , самолеты , рейсы , вкус , цвет и т.д . Необходимо разли чать такие понятия , как тип сущности и экземпляр сущности . Понятие тип сущности относится к набору однородных личностей , предметов , событий или идей , выступающих как целое . Экземпляр сущности относится к конкретной вещи в наборе . Например , типом сущности м ожет быть ГОРОД , а экземпляром – Москва , Киев и т.д. Атрибут – поименованная характеристика сущности . Его наименование должно быть уникальным для конкретного типа сущности , но может быть одинаковым для различного типа сущностей (например , ЦВЕТ может быть о пределен для многих сущностей : СОБАКА , АВТОМОБИЛЬ , ДЫМ и т.д .). Атрибуты используются для определения того , какая информация должна быть собрана о сущности . Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП , МАРКА , НОМЕРНОЙ ЗНАК , ЦВЕТ и т.д . Здесь т акже существует различие между типом и экземпляром . Тип атрибута ЦВЕТ имеет много экземпляров или значений : Красный , Синий , Банановый , Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута. Абсолютное различие между типами сущностей и атрибутами отсутствует . Атрибут является таковым только в связи с типом сущности . В другом контексте атрибут может выступать как самостоятельная сущность . Например , для автомобильного завода цвет – это только атрибут продукта про и зводства , а для лакокрасочной фабрики цвет – тип сущности. Ключ – минимальный набор атрибутов , по значениям которых можно однозначно найти требуемый экземпляр сущности . Минимальность означает , что исключение из набора любого атрибута не позволяет идентифиц ировать сущность по оставшимся . Для сущности Расписание (п . 1.2 ) ключом является атрибут Номер _рейса или набор : Пункт _отправления , Время _вылета и Пункт _назначения (при условии , что из пункта в пункт вылетает в каждый момент времени один самолет ). Связь – ассоциирование двух или более сущностей . Если бы назначением базы данных было только хранение отдельных , не связанных между собой данных , то ее структура могла бы быть очень простой . Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других , для чего необходимо установить между ними определенные связи . А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей , то т е оретически между ними может быть установлено более миллиона связей . Наличие такого множества связей и определяет сложность инфологических моделей. Характеристика связей и язык моделирования При построении инфологических моделей можно использовать язык ER-д иаграмм (от англ . Entity-Relationship, т.е . сущность-связь ). В них сущности изображаются помеченными прямоугольниками , ассоциации – помеченными ромбами или шестиугольниками , атрибуты – помеченными овалами , а связи между ними – ненаправленными ребрами , над которыми может проставляться степень связи (1 или буква , заменяющая слово "много ") и необходимое пояснение. Между двумя сущностям , например , А и В возможны четыре вида связей. Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представ ителю (экземпляру ) сущности А соответствует 1 или 0 представителей сущности В : Студент может не "заработать " стипендию , получить обычную или одну из повышенных стипендий. Второй тип – связь ОДИН-КО-МНОГИМ (1:М ): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В. Квартира может пустовать , в ней может жить один или несколько жильцов. Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М :1) и МНОГИЕ-КО-МНОГИМ (М :N). Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК , то существует четыре возможныхпредставления такой связи : Характер связей между сущностями не ограничивается перечисленными . Существуют и более сложные связи : · множество связей между одними и т еми же сущностями (пациент , имея одного лечащего врача , может иметь также несколько врачей-к онсультантов ; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов ); · тренарные связи (врач может назначить несколько пациентов на несколько анализов , анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими в рачами ); · связи более высоких порядков , семантика (смысл ) которых иногда очень сложна . В приведенных примерах для повышения иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах . Так , ввод лишь нескольк их основных атрибутов в описание брачных связей значительно усложнит ER-диаграмму (рис . 2.1,а ). В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших . Чаще же применяется менее наглядный , н о более содержательный язык инфологического моделирования (ЯИМ ), в котором сущности и ассоциации представляются предложениями вида : СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n) АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут 1, атрибут 2 , ..., атрибут n) где S – степень связи , а атрибуты , входящие в ключ , должны быть отмечены с помощью подчеркивания. Так , рассмотренный выше пример множества связей между сущностями , может быть описан на ЯИМ следующим образом : Врач ( Номер _врача , Фамилия , Им я , Отчество , Специальность ) Пациент ( Регистрационный _номер , Номер койки , Фамилия, Имя , Отчество , Адрес , Дата рождения , Пол ) Лечащий _врач [Врач 1, Пациент M] ( Номер _врача , Регистрационный _номер ) Консультант [Врач M,Пациент N] ( Номер _врача , Регистрационный _номер ). Рис . 2.1. Примеры ER-диаграмм Для выявления связей меж ду сущностями необходимо , как минимум , определить сами сущности . Но это не простая задача , так как в разных предметных областях один и тот же объект может быть сущностью , атрибутом или ассоциацией . Проиллюстрируем такое утверждение на примерах , связанных с описанием брачных связей (см . пример 2.1). Пример 2.2. Отдел записей актов гражданского состояния (ЗАГС ) имеет дело не со всеми людьми , а только с теми , кто обратился с просьбой о регистрации брака , рождения или смерти . Поэтому в странах , где допускаются лишь традиционные браки , отделы ЗАГС могут размещать сведения о регистрируемых браках в единственной сущности : Брак ( Номер _свидетельства , Фамилия _мужа , Имя _мужа, Отчество _мужа , Дата _рождения _мужа , Фамилия _жены, ... , Дата _регистрации , Место _рег истрации , ...), ER-диаграмма которой приведена на рис . 2.1,б. Пример 2.3. Теперь рассмотрим ситуацию , когда отдел ЗАГС расположен в стране , допускающей многоженство . Если для регистрации браков использовать сущность "Брак " примера 2.2, то будут дублировать ся сведения о мужьях , имеющих несколько жен (см . табл . 2.1). Таблица 2.1 Номер свидетельства Фамилия мужа ... Фамилия жены ... Дата регистрации 1-ЮБ 154745 Петухов ... Курочкина ... 06/03/1991 1-ЮБ 163489 Петухов ... Пеструшкина ... 11/08/1991 1-ЮБ 169887 Петухов ... Рябова ... 12/12/1992 1-ЮБ 169878 Селезнев ... Уточкина ... 12/12/1992 1-ЮБ 154746 Парасюк ... Свинюшкина ... 06/03/1991 1-ЮБ 169879 Парасюк ... Хаврония ... 12/12/1992 ... ... ... ... ... ... Дублирование можно исключить созданием дополнительной сущности "Мужья " Мужья ( Код _М , Фамилия , Имя , Отчество , Дата рождения , Место рождения ) и заменой сущности "Брак " характеристикой (см . п . 2.3) со ссылкой на соответствующее описание в сущности "Мужья ". Брак ( Номер свидетельства , Код _М , Фам илия жены , ..., Дата регистрации , ...) Мужья . ER-диаграмма связи этих сущностей показана на рис . 2.1,в , а пример их экземпляров в табл . 2.2 и 2.3. Таблица 2.2 Код _М Фамилия Имя Отчество Год /р. Место рожд. 111 Петухов Альфред Остапович 1971 г . Цапел ька 112 Селезнев Вавила Абрамович 1973 г . Гусев 113 Парасюк Гораций Федулович 1972 г . Свиньин ... ... ... ... ... ... Таблица 2.3 Номер свидетельства Код _М Фамилия жены Имя жены Дата регистрации ... 1-ЮБ 154745 111 Курочкина Августина 06/03/1991 ... 1-ЮБ 163489 111 Пеструшкина Мариана 11/08/1991 ... 1-ЮБ 169877 111 Рябова Милана 12/12/1992 ... 1-ЮБ 169878 112 Уточкина Вероника 12/12/1992 ... 1-ЮБ 154746 113 Свинюшкина Эльвира 06/03/1991 ... 1_ЮБ 169879 113 Хаврония Руфина 12/12/1992 ... ... ... ... ... ... ... Пример 2.4. Наконец , рассмотрим случай , когда какой-либо организации потребовались данные о наличии в ней семейных пар , а для хранения сведений о сотрудниках уже имеется сущность Сотрудники ( Табельный _номер , Фамилия , Имя , ...). Использован ие , рассмотренной в примере 2.2, сущности "Брак " нецелесообразно : в "Сотрудники " уже есть фамилии , имена , отчества супругов . Поэтому создадим ассоциацию Брак [Сотрудник 1, Сотрудник 1] (Табельный _номер _мужа , Табельный _номер _жены , ...), связывающую меж ду собой определенные экземпляры сущности "Сотрудники " (рис . 2.1,г ). В заключение отметим , что ER-диаграмма рис . 2.1,а описывает структуру размещения данных о браках в отделах ЗАГС стран , допускающих групповые браки , а ER-диаграммы примера 2.1, описания лю бых видов браков в организациях , где есть сущности "мужчины " и "женщины ", включающие холостых и незамужних. Что же такое "связь "? В ER-диаграммах это линия , соединяющая геометрические фигуры , изображающие сущности , атрибуты , ассоциации и другие информацион ные объекты . В тексте же этот термин используется для указания на взаимозависимость сущностей . Если эта взаимозависимость имеет атрибуты , то она называется ассоциацией. Классификация сущностей Настал момент разобраться в терминологии . К.Дейт [ 3 ] определяет три основные класса сущностей : стержневые , ассоциативные и характеристические , а также подкласс ассоциативных сущностей – обозначения . Стержневая сущность ( стержень ) – это независимая сущность (несколько подробнее она будет определена ниже ). В рассмотренных ранее примерах стержни – это "Студент ", "Квартира ", "Мужчины ", "Врач ", "Брак " (из примера 2.2 ) и другие , названия которых помещены в прямоугольники. Ассоциативная сущность ( ассоциация ) – это связь вида "многие-ко-многим " ("-ко-многим " и т.д .) между двумя или более сущностями или экземплярами сущности (как в примере 2.4 ). Ассоциаци и рассматриваются как полноправные сущности : они могут участвовать в других ассоциациях и обозначениях точно так же , как стержневые сущности ; могут обладать свойствами , т.е . иметь не только набор ключевых атрибутов , необходимых для указания связей , но и лю бое число других атрибутов , характеризующих связь . Например , ассоциации "Брак " из примеров 2.1 и 2.4 содержат ключевые атрибуты "Код _М ", "Ко д _Ж " и "Табельный номер мужа ", "Табельный номер жены ", а также уточняющие атрибуты "Номер свидетельства ", "Дата регистрации ", "Место _регистрации ", "Номер записи в книгу ЗАГС " и т.д. Характеристическая сущность ( характеристика ) – это связь вида "многие-к-од ной " или "одна-к-одной " между двумя сущностями (частный случай ассоциации ). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности . Необходимость в них возникает в связи с те м , что сущности реального мира имеют иногда многозначные свойства . Муж может иметь несколько жен (пример 2.3), книга – несколько характеристик переиздания (исправленное , дополненное , переработанное , ...) и т.д. Существование характеристики полностью зависит от характеризуемой сущности : женщины лишаются статуса жен , если умирает их муж. Для описания характеристики используется новое предложение ЯИМ , имеющее в общем случае вид : ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...) СПИСОК ХАРАКТЕРИЗУЕМЫХ С УЩНОСТЕЙ . Расширим также язык ER-диаграмм , введя для изображения характеристики трапецию (рис . 2.2). Рис . 2.2. Элементы расширенного языка ER-диаграмм Обозначающая сущность или обозначение – это связь вида "многие-к-одной " или "одна-к-одной " между двумя сущностями и отличается от характеристики тем , что не зависит от обозначаемой сущности. Рассмотри м пример , связанный с зачислением сотрудников в различные отделы организации. При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел ) необходимо создать описание с ассоциацией Зачислен ие : Отделы (Номер отдела , Название отдела , ...) Служащие (Табельный номер , Фамилия , ...) Зачисление [Отделы M, Служащие N] (Номер отдела , Табельный номер , Дата зачисления ). Однако , при условии , что каждый из сотрудников должен быть обязательно з ачислен в один из отделов , можно создать описание с обозначением Служащие : Отделы (Номер отдела , Название отдела , ...) Служащие (Табельный номер , Фамилия , ... , Номер отдела, Дата зачисления )[Отделы ] В данном примере служащие имеют независимое су ществование (если удаляется отдел , то из этого не следует , что также должны быть удалены служащие такого отдела ). Поэтому они не могут быть характеристиками отделов и названы обозначениями. Обозначения используют для хранения повторяющихся значений больших текстовых атрибутов : "кодификаторы " изучаемых студентами дисциплин , наименований организаций и их отделов , перечней товаров и т.п. Описание обозначения внешне отличается от описания характеристики только тем , что обозначаемые сущности заключается не в фиг урные скобки , а в квадратные : ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ ]. Как правило , обозначения не рассматриваются как полноправные сущности , хотя это не привело бы к какой-либо ошибке. Обозначения и характеристи ки не являются полностью независимыми сущностями , поскольку они предполагают наличие некоторой другой сущности , которая будет "обозначаться " или "характеризоваться ". Однако они все же представляют собой частные случаи сущности и могут , конечно , иметь свой с тва , могут участвовать в ассоциациях , обозначениях и иметь свои собственные (более низкого уровня ) характеристики . Подчеркнем также , что все экземпляры характеристики должны быть обязательно связаны с каким-либо экземпляром характеризуемой сущности . Однак о допускается , чтобы некоторые экземпляры характеризуемой сущности не имели связей . Правда , если это касается браков , то сущность "Мужья " должна быть заменена на сущность "Мужчины " (нет мужа без жены ). Переопределим теперь стержневую сущность как сущность , которая не является ни ассоциацией , ни обозначением , ни характеристикой . Такие сущности имеют независимое существование , хотя они и могут обозначать другие сущности , как , например , сотрудники обозначают отделы. В заключение рассмотрим пример построения инф ологической модели базы данных "Питание ", где должна храниться информация о блюдах (рис . 2.3), их ежедневном потреблении , продуктах , из которых приготавливаются эти блюда , и поставщиках этих продуктов . Информация будет использоваться поваром и руководител е м небольшого предприятия общественного питания , а также его посетителями. 1. Лобио по грузински Ломаную очищенную фасоль , нашинкованный лук посолить , посыпать перцем и припустить в масле с небольшим количеством бульона ; добавить кинзу , зелень петрушки , рей ган (базилик ) и довести до готовности . Затем запечь в духовке. Фасоль стручковая (свежая или консервированная ) 200, Лук зеленый 40, Масло сливочное 30, Зелень 10. Выход 210. Калорий 725. Рис . 2.3. Пример кулинарного рецепта С помощью указанных пользовател ей выделены следующие объекты и характеристики проектируемой базы : 1. Блюда , для описания которых нужны данные , входящие в их кулинарные рецепты : номер блюда (например , из книги кулинарных рецептов ), название блюда , вид блюда (закуска , суп , горячее и т.п .) , рецепт (технология приготовления блюда ), выход (вес порции ), название , калорийность и вес каждого продукта , входящего в блюдо . 2. Для каждого поставщика продуктов : наименование , адрес , название поставляемого продукта , дата поставки и цена на момент пост авки . 3. Ежедневное потребление блюд (расход ): блюдо , количество порций , дата . Анализ объектов позволяет выделить : · стержни Блюда , Продукты и Города ; · ассоциации Состав (связывает Блюда с Продуктами ) и Поставки (связывает Поставщиков с Продуктами ); · обозначение Поставщики ; · характеристики Рецепты и Расход . ER-диаграмма модели показана на рис . 2.4. а модель на языке ЯИМ имеет следующий вид : Блюда (БЛ , Блюдо , Вид ) Продукты (ПР , Продукт , Калорийность ) Поставщики (ПОС , Город , Поставщик ) [Город ] Сост ав [Блюда M, Продукты N] (БЛ , ПР , Вес (г )) Поставки [Поставщики M, Продукты N] (ПОС , ПР , Дата _П , Цена , Вес (кг )) Города (Город , Страна ) Рецепты (БЛ , Рецепт ) Блюда Расход (БЛ , Дата _Р , Порций ) Блюда В этих моделях Блюдо , Продукт и Поставщик – наименован ия , а БЛ , ПР и ПОС – цифровые коды блюд , продуктов и организаций , поставляющих эти продукты. Ри с . 2.4. Инфологическая модель базы данных "Питание " О первичных и внешних ключах Напомним , что ключ или возможный ключ – это минимальный набор атрибутов , по значениям которых можно однозначно найти требуемый экземпляр сущности . Минимальность означает , что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся . Каждая сущность обладает хотя бы одним возможным ключом . Один из них принимается за первичный ключ . При выборе первичного ключа следует отдавать предпочтение несоста вным ключам или ключам , составленным из минимального числа атрибутов . Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты ). Так , для идентификации студента можно использовать либо уникальный номер зачетной книжки , либо набор из фамилии , имени , отчества , номера группы и может быть дополнительных атрибутов , так как не исключено появление в группе двух студентов (а чаще студенток ) с одинаковыми фамилиями , именами и отчествами . Плохо т а кже использовать в качестве ключа не номер блюда , а его название , например , " Закуска из плавленых сырков "Дружба " с ветчиной и соленым огурцом " или "Заяц в сметане с картофельными крокетами и салатом из красной капусты ". Не допускается , чтобы первичный кл юч стержневой сущности (любой атрибут , участвующий в первичном ключе ) принимал неопределенное значение . Иначе возникнет противоречивая ситуация : появится не обладающий индивидуальностью , и , следовательно не существующий экземпляр стержневой сущности . По т е м же причинам необходимо обеспечить уникальность первичного ключа . Теперь о внешних ключах : · Если сущность С связывает сущности А и В , то она должна включать внешние ключи , соответствующие первичным ключам сущностей А и В . · Если сущность В обозначает су щность А , то она должна включать внешний ключ , соответствующий первичному ключу сущности А . В п . 2.3 рассматривался пример , где "Служащие " обозначали "Отделы " и включали внешний ключ "Номер отдела ", соответствующий п ервичному ключу сущности "Отделы ". Связь между первичными и внешними ключами сущностей иллюстрируется рис . 2.5. Рис . 2.5. Структуры : а - ассоциации ; б - обозначения (характеристики ) Здесь для обозначения любой из ассоциируемых сущностей (стержней , характеристик , обозначений или даже ассоциаций ) используется новый обобщающий термин "Цель " или "Целевая сущность ". Таким образом , при рассмотрении проблемы выбора способа представления ассоциаций и обозначений в базе данных основной вопрос , на который следует получить ответ : "Каковы внешние ключи ?". И далее , для каждого внешнего ключа необходимо решить три вопроса : 1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения )? Иначе говоря , может ли существовать некоторый экземпляр сущности данного типа , для которого неизвестна целевая сущность , указываемая внешним ключом ? В случае постав ок это , вероятно , невозможно – поставка , осуществляемая неизвестным поставщиком , или поставка неизвестного продукта не имеют смысла . Но в случае с сотрудниками такая ситуация однако могла бы иметь смысл – вполне возможно , что какой-либо сотрудник в данный момент не зачислен вообще ни в какой отдел . Заметим , что ответ на данный вопрос не зависит от прихоти проектировщика базы данных , а определяется фактическим образом действий , принятым в той части реального мира , которая должна быть представлена в рассматр и ваемой базе данных . Подобные замечания имеют отношение и к вопросам , обсуждаемым ниже. 2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности , на которую ссылается внешний ключ ? Например , при удалении поставщика , который осуществил по крайней мере о дну поставку . Существует три возможности : КАСКАДИРУЕТСЯ Операция удаления "каскадируется " с тем , чтобы удалить также поставки этого поставщика . ОГРАНИЧИВАЕТСЯ Удаляются лишь те поставщики , которые еще не осуществляли поставок . Иначе операция удаления о твергается . УСТАНАВЛИВАЕТСЯ Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение , а затем этот поставщик удаляется . Такая возможность , конечно , неприменима , если данный внешний ключ не должен содер жать NULL-значений . 3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности , на которую ссылается некоторый внешний ключ ? Например , может быть предпринята попытка обновить номер такого поставщика , для которого имеется по крайне й мере одна соответствующая поставка . Этот случай для определенности снова рассмотрим подробнее . Имеются те же три возможности , как и при удалении : КАСКАДИРУЕТСЯ Операция обновления "каскадируется " с тем , чтобы обновить также и внешний ключ впоставках это го поставщика . ОГРАНИЧИВАЕТСЯ Обновляются первичные ключи лишь тех поставщиков , которые еще не осуществляли поставок . Иначе операция обновления отвергается . УСТАНАВЛИВАЕТСЯ Для всех поставок такого поставщика NULL-значение внешний ключ устанавливаетс я в неопределенное значение , а затем обновляется первичный ключ поставщика . Такая возможность , конечно , неприменима , если данный внешний ключ не должен содержать NULL-значений . Таким образом , для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей , составляющих этот внешний ключ , и целевую таблицу , которая идентифицируется этим ключом , но также и ответы на указанные выше вопроса (три ограничения , которые относятся к этому внешнему ключу ). Н аконец , о характеристиках – обозначающих сущностях , существование которых зависит от типа обозначаемых сущностей . Обозначение представляется внешним ключом в таблице , соответствующей этой характеристике . Но три рассмотренные выше ограничения на внешний кл ю ч для данного случая должны специфицироваться следующим образом : NULL-значения не допустимы УДАЛЕНИЕ ИЗ (цель ) КАСКАДИРУЕТСЯ ОБНОВЛЕНИЕ (первичный ключ цели ) КАСКАДИРУЕТСЯ Указанные спецификации представляют зависимость по существованию характеристических сущностей. Ограничения целостности Целостность (от англ . integrity – нетронутость , неприкосновенность , сохранность , целостность ) – понимается как правильность данных в любой момент времени . Но эта цель может быть достигнута лишь в определенных пределах : СУ БД не может контролировать правильность каждого отдельного значения , вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность ). Например , нельзя обнаружить , что вводимое значение 5 (представляющее номер дня недели ) в действительно с ти должно быть равно 3. С другой стороны , значение 9 явно будет ошибочным и СУБД должна его отвергнуть . Однако для этого ей следует сообщить , что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7). Поддержание целостности базы данных может рассм атриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями , являющимися проблемой безопасности ). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же , как и средств о б еспечения поддержания безопасности ). Выделяют три группы правил целостности : 1. Целостность по сущностям . 2. Целостность по ссылкам . 3. Целостность , определяемая пользователем . В п . 2.4 была рассмотрена мотивировка двух правил целостности , общих для любых реляционных баз данных. 1. Не допускается , чтобы какой-либо атрибут , участвующий в первичном ключе , принимал неопределенное значение . 2. Значение внешнего ключа должно либо : 1. быть равным значению первичного ключ а цели ; 2. быть полностью неопределенным , т.е . каждое значение атрибута , участвующего во внешнем ключе должно быть неопределенным . 3. Для любой конкретной базы данных существует ряд дополнительных специфических правил , которые относятся к ней одной и опр еделяются разработчиком . Чаще всего контролируется : уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 2 до 5), принадлежность набору значений (пол "М " или "Ж "). О построении инфологической модели Читатель , познакомившийся л ишь с материалом данной и предшествующей глав , не сможет правильно воспринять и оценить тех советов и рекомендаций по построению хорошей инфологической модели , которые десятилетиями формировались крупнейшими специалистами в области обработки данных . Для э т ого надо , по крайней мере , изучить последующие материалы . В идеале же необходимо , чтобы читатель предварительно реализовал хотя бы один проект информационной системы , предложил его реальным пользователям и побыл администратором базы данных и приложений ст о ль долго , чтобы осознать хотя бы небольшую толику проблем , возникающих из-за недостаточно продуманного проекта . Опыт автора и всех знакомых ему специалистов по информационным системам показывает , что любые теоретические рекомендации воспринимаются всерьез лишь после нескольких безрезультатных попыток оживления неудачно спроектированных систем . (Хотя есть и такие проектировщики , которые продолжают верить , что смогут реанимировать умирающий проект с помощью изменения программ , а не инфологической модели базы данных .) Основная сложность восприятия рекомендаций , приведенных в четвертой главе и приложении Б , чисто психологического плана. Действительно , для определения перечня и структуры хранимых данных надо собрать информацию о реальных и потенциальных приложен иях , а также о пользователях базы данных , а при построении инфологической модели следует заботиться лишь о надежности хранения этих данных , напрочь забывая о приложениях и пользователях , для которых создается база данных. Это связано с абсолютно различающи мися требованиями к базе данных прикладных программистов и администратора базы данных . Первые хотели бы иметь в одном месте (например , в одной таблице ) все данные , необходимые им для реализации запроса из прикладной программы или с терминала . Вторые же за б отятся о исключении возможных искажений хранимых данных при вводе в базу данных новой информации и обновлении или удалении существующей . Для этого они удаляют из базы данных дубликаты и нежелательные функциональные связи между атрибутами , разбивая базу да н ных на множество маленьких таблиц (см . п . 4.6 ). Так как многолетний мировой опыт использования информационных систем , построенных на основе баз данных , показывает , что недостатки проекта невозможно устранить любыми ух ищрениями в программах приложений , то опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда , когда они сами являются таковыми ). И хотя автор осознает , что большинство людей предпочитает учиться на собственных ошибках , он все же еще раз советует неопытным проектировщикам баз данных : · четко разграничивать такие понятия как запрос на данные и ведение данных (ввод , изменение и удаление ); · помнить , что , как правило , база данных является информационной основой не одного , а нескольких приложений , часть их которых появится в будущем ; · плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных ) приложений . ЛИТЕРАТУРА 1. Атре Ш . Структурный подход к организации баз данных . – М .: Финансы и ста тистика , 1983. – 320 с . 2. Бойко В.В ., Савинков В.М . Проектирование баз данных информационных систем . – М .: Финансы и статистика , 1989. – 351 с . 3. Дейт К . Руководство по реляционной СУБД DB2. – М .: Финансы и статистика , 1988. – 320 с . 4. Джексон Г . Про ектирование реляционных баз данных для использования с микроЭВМ . -М .: Мир , 1991. – 252 с . 5. Кириллов В.В . Структуризованный язык запросов (SQL). – СПб .: ИТМО , 1994. – 80 с . 6. Мартин Дж . Планирование развития автоматизированных систем . – М .: Финансы и с татистика , 1984. – 196 с . 7. Мейер М . Теория реляционных баз данных . – М .: Мир , 1987. – 608 с . 8. Тиори Т ., Фрай Дж . Проектирование структур баз данных . В 2 кн ., – М .: Мир , 1985. Кн . 1. – 287 с .: Кн . 2. – 320 с . 9. Ульман Дж . Базы данных на Паскале . – М .: Машиностроение , 1990. – 386 с . 10. Хаббард Дж . Автоматизированное проектирование баз данных . – М .: Мир , 1984. – 294 с . 11. Цикритизис Д ., Лоховски Ф . Модели данных . – М .: Финансы и статистика , 1985. – 344 с.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Мы, петербуржцы, 12 месяцев в году ждем лета.
Но лето не глупое, чтобы приходить туда, где холодно, сыро и пасмурно.
Поэтому мы на 2 недели сами едем к лету.
И начинаем ждать следующее.
Может оно будет поглупее...
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2017
Рейтинг@Mail.ru