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

Контрольная

Модели баз данных

Банк рефератов / Информатика, информационные технологии

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

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

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

16 Содержание Введение 3 1. Иерархическая мо дель данных 4 1. 1. Структура данн ых 4 1. 2. Операции над данными, определенные в иер архической мо дели 6 1. 3. Ограничения целостности 7 2. Сетевая модель да нных 7 2. 1. Структура данны х 7 2. 2. Операции над данными 10 2. 3. Ограничения целостности 10 3. Реляционная модель данных 11 3. 1. Структура данн ых 11 3. 2. Свойства отношений 15 Заключение 16 Список использованной литературы 17 Введение Ядром любой б азы данных является модель данных. Модель данных представляет собой мно жество структур данных, ограничений целостности и операций манипулиро вания данными. С помощью модели данных могут быть представлены объекты п редметной области и взаимосвязи между ними. Модель данных — совокупность структур данных и операций их обработки. СУБД основывается на использовании иерархической, сетевой или реляцио нной модели, на комбинации этих моделей или на некотором их подмножестве . Рассмотрим три основных типа моделей данных: иерархическую, сетевую и ре ляционную. 1. Иерархичес кая модель данных. 1. 1. Структура данных. Организация данных в СУБД иерархического типа оп ределяется в терминах: элемент, агрегат, запись (гру ппа), групповое отношение, база данных. Атрибут (элемент данных) - наименьшая единица структур ы данных. Обычно каждому элементу при описании базы данных присваиваетс я уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем. Запись - именованная совоку пность атрибутов. Использование записей позволяет за одно обращение к б азе получить некоторую логически связанную совокупность данных. Именн о записи изменяются, добавляются и удаляются. Тип записи определяется со ставом ее атрибутов. Экземпляр записи - конкретная запись с конкретным з начением элементов Групповое отношение - иерар хическое отношение между записями двух типов. Родительская запись (влад елец группового отношения) называется исходной записью, а дочерние запи си (члены группового отношения) - подчиненными. Иерархическая база данны х может хранить только такие древовидные структуры. Корневая запись каждого дерева обязательно должна содержать ключ с уни кальным значением. Ключи некорневых записей должны иметь уникальное зн ачение только в рамках группового отношения. Каждая запись идентифицир уется полным сцепленным ключом, под которым понимается совокупность кл ючей всех записей от корневой по иерархическому пути. При графическом изображении групповые отношения изображают дугами ори ентированного графа, а типы записей - вершинами (диаграмма Бахмана). Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство . Это о значает, что для запоминания любой некорневой записи в БД должна существ овать ее родительская запись . При у далении родительской записи автоматически удаляются все подчиненные. Пример: Рассмотрим следующую мо дель дан ных предприятия ( рис. 1 ): предприятие состоит из отделов, в которых работают со трудники. В каждом отделе может работать несколько сотрудников, но сотру дник не может работать более чем в одном отделе. Поэтому, для информационной системы управления пе рсоналом необходимо создать групповое отношение, состоящее из родител ьской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней за писи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. (а) (Для простоты полагается, что имеются только две дочерние записи). Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры : заказчик - контр акты с ним - сотрудники, задействованные в работе над контрактом. Это дере во будет включать записи ЗАКАЗЧИК(НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРА КТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛ А) (рис. (b) ) . Рис. 1 Из этого прим ера видны недостатки иерархических БД: Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛ Ь (такие записи называют парными), причем в иерархической модели данных н е предусмотрена поддержка соответствия между парными записями. Иерархическая модель реализует отношение между исходной и дочерней за писью по схеме 1:N, то есть одной родительской записи может соответствоват ь любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом слу чае в базу данных необходимо ввести еще одно групповое отношение, в кото ром ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ - дочерней (р ис. (c)). Таким образом, мы опять вынуждены дублировать информацию. 1. 2. Операции над данными, определенн ые в иерархической модели : ДОБАВИТЬ в базу данных новую запись. Для корневой записи обязательно фор мирование значения ключа. ИЗМЕНИТЬ значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям. УДАЛИТЬ некоторую запись и все подчиненные ей записи. ИЗВЛЕЧЬ: извлечь корневую запись по ключевому значению, допускается также после довательный просмотр корневых записей извлечь следующую запись (следующая запись извлекается в порядке левос тороннего обхода дерева) В операции ИЗВЛЕЧЬ допускается задание условий выборки (например, извле чь сотрудников с окладом более 1 тысячи руб.) Как видим, все операции изменения применяются только к одной "текущей" за писи (которая предварительно извлечена из базы данных). Такой подход к ма нипулированию данных получил название "навигационного". 1. 3. Ограничения целостности. Поддерживается только целостность связей между вл адельцами и членами группового отношения (никакой потомок не может суще ствовать без предка). Как уже отмечалось, не обеспечивается автоматическ ое поддержание соответствия парных записей, входящих в раз ные иерархии. 2. Сетевая мо дель данных . 2. 1. Структура данных. На разработку этого стандарта большое влияние ока зал американский ученый Ч.Бахман. Основные принципы сетевой модели данн ых были разработны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.). Сетевая модель данных определяется в тех же терминах, что и иерархическая . Она состоит из множества записей, которые могут быть влад ельцами или членами групповых отношений. Связь между между записью-влад ельцем и записью-членом также имеет вид 1:N . Основное различие этих моделей состоит в том, что в сетевой модели запис ь может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляро м. Тип группового отношения задается его именем и определяет свойства об щие для всех экземпляров данного типа. Экземпляр группового отношения п редставляется записью-владельцем и множеством (возможно пустым) подчин енных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного. Иерархическая структура преобразовывается в сетевую с ледующим образом ( рис. 2): · древья (a) и (b), показанные н а рис. 3.1, заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения; · для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для св язи записей КОНТРАКТ и СОТРУДНИК, см. рис. 3.2.(Отметим, что в этой записи може т храниться и полезная информация, например, доля данного сотрудника в о бщем вознаграждении по данному контракту.) Рис. 2 Каждый экзе мпляр группового отношения характеризуется следующими признаками: - способ упорядочения подчиненных записей : · произвольный, · хронологический /очередь/, · обратный хронологический /стек/, · сортированный. Если запись объявлена подчиненной в нескольких групповых отношениях, то в каждом из них может быть назначен свой способ упорядочивания . - режим включения подчиненных записей : · автоматический - нево зможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем; · ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового о тношения. Эта операция позже инициируется пользователем). - режим исключения Принято выделять три класса членства подчиненных записей в групповых отношениях: Фиксирова нное. Подчиненная запись жестко связана с записью в ладельцем и ее можно исключить из группового отношения только удалив. Пр и удалении записи-владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предпо лагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗ ЧИК", поскольку контракт не может существовать без заказчика. Обязательное. Допускается п ереключение подчиненной записи на другого владельца, но невозможно ее с уществование без владельца. Для удаления записи-владельца необходимо, ч тобы она не имела подчиненных записей с обязательным членством. Таким от ношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывае тся, все его сорудники должны быть либо переведены в другие отделы, либо у волены. Необязательное. Можно исклю чить запись из группового отношения, но сохранить ее в базе данных не при крепляя к другому владельцу. При удалении записи-владельца ее подчиненн ые записи - необязательные члены сохраняются в базе, не участвуя более в г рупповом отношении такого типа. Примером такого группового отношения м ожет служить "ВЫПОЛНЯЕТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в орган изации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорн ых обязательств перед заказчиками. 2. 2. Операции над данными. ДОБАВИТЬ - внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отноше ние, где она объявлена подчиненной, либо не включать ни в какое групповое отношение. ВКЛЮЧИТЬ В ГРУППОВОЕ ОТНОШЕНИЕ - связать существующую подчиненную запись с записью-владельц ем. ПЕРЕКЛЮЧИТЬ - связать сущест вующую подчиненную запись с другой записью-владельцем в том же группово м отношении. ОБНОВИТЬ - изменить значение элементов предварительно извлеченной записи. ИЗВЛЕЧЬ - извлечь записи пос ледовательно по значению ключа, а также используя групповые отношения - от владельца можно перейти к записям - членам, а от подчиненной записи к вл адельцу набора. УДАЛИТЬ - убрать из БД запись. Если эта запись является владельцем группового отношения, то анализиру ется класс членства подчиненных записей. Обязательные члены должны быт ь предварительно исключены из группового отношения, фиксированные уда лены вместе с владельцем, необязательные останутся в БД. ИСКЛЮЧИТЬ ИЗ ГРУППОВОГО ОТНОШЕНИЯ - разорвать связь между записью-владельцем и записью-членом. 2. 3. Ограничения целостности. Как и в иерархической модели обеспечивается тольк о поддержание целостности по ссылкам (владелец отношения - член отношени я). 3. Реляционная модель данных Реляционная модель предложена сотрудником компан ии IBM Е.Ф.Коддом в 1970 г. ( русский перевод статьи , в которой она в первые описана опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактич еским стандартом, на который ориентируются практически все современны е коммерческие СУБД. 3 . 1. Структура данных. В реляционн ой модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф.Кодда утверждае тся, что " реляционная модель п редоставляет средства описания данных на основе только их естественно й структуры, т.е. без потребности введения какой-либо дополнительной стр уктуры для целей машинного представления ". Другими словами, представление данных не зависит от спосо ба их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходи т от английского relation - "отношение"). Перейдем к рассмотрению структурной части реляционной модели данных. П режде всего необходимо дать несколько определений. Определения: · Де картово произведение: Для заданных конечных множе ств (не обязательно разл ичных) декартовым произведением называется множеств о произведений вида: , где Пример: если даны два множества A (a1,a2,a3) и B (b1,b2), их декартово произведение будет иметь вид С=A*B (a1*b1, a2*b1, a3*b1, a1*b2, a2*b2, a3*b2) Отношение: Отношением R , определенным на множествах называется подмноже ство декартова произведения . При этом: o множества называются доменами отношения o элементы декартова произведени я называются кортежами o число n определяет степень отношения ( n=1 - унар ное, n=2 - бинарное, ..., n -арное) o количество кортежей называется мощностью отношения Пример: на множестве С из предыдущего пр имера могут быть определены отношения R1 (a1*b1, a3*b2) или R2 (a1*b1, a2*b1, a1*b2) Отношения удобно представлять в ви де таблиц. На рис. 3 представлена таб лица (отношение степени 5), содержащая некоторые сведения о работниках ги потетического предприятия. Строки таблицы соответствуют кортежам. Каж дая строка фактически представляет собой описание одного объекта реал ьного мира (в данном случае работника), характеристики которого содержат ся в столбцах. Можно провести аналогию между элементами реляционной мод ели данных и элементами модели "сущность-связь". Реляционные отношения с оответствуют наборам сущностей, а кортежи - сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционно е отношение, называют атрибутами . Рис. 3 Основные компоненты реляционного отношения. Каждый атрибут определен на домене, поэтому домен можно рассматривать как множество допустимых значений данного атрибут а. Несколько атрибутов одного отношения и даже атрибуты разных отношений могут быть определены на одном и том же домене. В примере, показанном на ри с. 3 атрибуты "Оклад" и "Премия" оп ределены на домене "Деньги". Поэтому, понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относя тся к одному домену. Таким образом, в рассматриваемом нами примере сравн ение атрибутов "Табельный номер" и "Оклад" является семантически некорре ктным, хотя они и содержат данные одного типа. Именованное множество пар "им я атрибута - имя домена" называется схемой отношения. Мощность этого множ ества - называют степенью или " р а в ностью" отношения. Набор именован ных схем отношений представляет из себя схему базы данных. Атрибут, значение которого однозначно идентифицирует кортежи, называе тся ключевым (или просто ключом). В нашем случае ключом является атрибут "Т абельный номер", поскольку его значение уникально для каждого работника предприятия. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ. Отношение может содержать несколько ключей. Всегда один из ключей объяв ляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами. В отличие от иерархической и сетевой моделей данных в реляционной отсут ствует понятие группового отношения. Для отражения ассоциаций между ко ртежами разных отношений используется дублирование их ключей. Рассмот ренный в параграфах 1 и 2 пример базы данных , содержащей сведения о подразделениях предприятия и р аботающих в них сотрудниках, применительно к реляционной модели будет и меть вид: Рис.4 База дан ных о подразделениях и сотрудниках предприятия. Например, связь между отношениями ОТДЕЛ и СОТРУДНИ К создается путем копирования первичного ключа " Номер отдела" из первого отношения во второе. Таким образом: · для того, чтобы получи ть список работников данного подразделения, необходимо 1. из таблицы ОТДЕЛ ус тановить значение атрибута "Номер_отдела" , соответствующее данному "Наименованию_отдела" 2. выбрать из таблицы СОТРУДНИК все записи, значение атрибута "Номер_отдела" которых равно полученному на предыдушем шаге. · для того, чтобы узнать в каком отделе работает сотрудник, нужно выполнить обратную операцию: 1. определяем "Номер_отдела" из таблицы СОТРУДНИК 2. по полученному значению находим з апись в таблице ОТДЕЛ. Атрибуты, пред ставляющие собой копии ключей других отношений, называются внешними ключами . 3 . 2. Свойства отношений. Отсутствие кортежей-дубликатов. Из этого свойства вытекает наличие у ка ждого кортежа первичного ключа. Для каждого отношения, по крайней мере, полный набор его атрибуто в является первичным ключом. Однако, при определении первичного ключа до лжно соблюдаться требование "минимальности", т.е. в него не должны входить те атрибуты, которые можно отбросить без ущерба для основного свойства п ервичного ключа - однозначно определять кортеж. 1. Отсутствие упорядоче нности кортежей. 2. Отсутствие упор я доченности атрибутов. Для ссылки на значение атриб ута всегда используется имя атрибута. 3. Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться множества зна чений (отношения). Заключение. На сегодняшний день реляционные базы данных остаются сам ыми распространенными, благодаря своей простоте и наглядности как в про цессе создания так и на пользовательском уровне. Основным достоинством реляционных баз данных совместимость с самым по пулярным языком запросов SQL . С помо щью единственного запроса на этом языке можно соединить несколько табл иц во временную таблицу и вырезать из нее требуемые строки и столбцы (сел екция и проекция). Так как табличная структура реляционной базы данных и нтуитивно понятна пользователям, то и язык SQL являе т ся простым и легким д ля изучения. Реляционная модель имеет солидный теоретический фундамен т, на котором были основаны эволюция и реализация реляционных баз данных . На волне популярности, вызванной успехом реляционной модели, SQL стал основным языком для реляционных баз данных. В процессе анализа вышеизложенной информации выявлены с ледующие недостатки рассмотренной модели баз данных: · так как все поля одной таблиц ы должны содержать постоянное число полей заранее определенных типов, п риходится создавать дополнительные таблицы, учитывающие индивидуальн ые особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных; · высокая трудоемкость манипулировани я информацией и изменения связей. Список испо льзованной литературы. 1. Бойко В.В., Савинков В.М . Проектирование баз данных информационных систем. – М.: Финансы и статистика,19 9 9. 2. Конноллн, Том ас, Бегг, Карелии. Базы данных. Проектирование, реализация и сопровождени е. Теория и практик а. 3-е издание.: Пер. с англ. – М . : Издательский дом "Вил ьяме", 2003. – 1440 с. 3. Ко теров Д. В. Самоучитель РНР 4. – С Пб.: БХВ-Петербург, 2003. – 576 с. 4. Кренке Д. Теория и практика постро ения баз данных. 9-е изд. – СПб.: Питер , 2005 – 859c. 5. М акаров А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Уче бник – М.: Финансы и статистика, 2004 – 512 с.
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Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Оказалась, что русофобия лечится!
Всего одна повестка и человек перестает скакать и петь "Ще не вмерла...", надевает георгиевскую ленту и внезапно начинает любить Россию так, что даже едет туда жить...
Anekdot.ru

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

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

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


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