Реляционная модель данных

                                                            Содержание

 
 

Введение 4

Глава 1.Базы Данных. Системы управления файлами 5

    1.1.Что  такое базы данных 5

    1.2.Системы управления файлами 5

    1.3.Архитектура  СУБД 6

Глава 2.Модели данных 9

    2.1.Иерархическая модель 9

    2.2.Сетевая модель 10

Глава 3.Реляционная модель данных 13

    3.1.Таблицы 14

    3.2.Первичные ключи 15

    4.1.Отношения предок\потомок 17

    4.2.Внешние ключи 18

    4.3.Двенадцать правил Кодда 19

Глава 4. Манипулирование реляционными данными 24

Заключение 25

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

Приложение 27

Введение

    Основные  идеи современной информационной технологии базируются на концепции, согласно которой  данные должны быть организованы в  базы данных с целью адекватного  отображения изменяющегося реального  мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов, называемых системами управления базами данных (СУБД).

    Увеличение  объема и структурной сложности  хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД. Для обеспечения одновременного доступа к данным множества пользователей, нередко расположенных достаточно далеко друг от друга и от места хранения баз данных, созданы сетевые мультипользовательские версии БД основанных на реляционной структуре. В них тем или иным путем решаются специфические проблемы параллельных процессов, целостности (правильности) и безопасности данных, а также санкционирования доступа.

    Задачами  данной работы являются:

• дать основные понятия баз данных, описать архитектуру СУБД, модели данных;
• раскрыть модель сущность-связь,  описать характеристику связей, классификацию сущностей, структуру первичных и внешних ключей, определить понятие целостности данных;
• описать реляционную структуру данных, реляционные базы данных и  способы манипулирования ими.

Глава 1.Базы Данных. Системы управления файлами.

1.1.Что такое базы данных?

    Восприятие  реального мира можно соотнести  с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать  эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

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

1.2. Системы управления  файлами

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

  Знание  о содержимом файла - какие данные в нём хранятся и какова их структура - было уделом прикладных программ, использующих этот файл, что иллюстрирует рис. 1.1¹. В приложении для начисления зарплаты каждая из программ, обрабатывающих файл с информацией о служащих, содержит в себе описание структуры данных (ОСД), хранящихся в этом файле. Когда структура данных изменялась - например, в случае добавления нового элемента данных для каждого служащего, - необходимо было модифицировать каждую из программ, обращавшихся к файлу. Со временем количество файлов и программ росло, и на сопровождение существующих приложений приходилось затрачивать всё больше и больше усилий, что замедляло разработку новых приложений.

  Проблемы  сопровождения больших систем, основанных на файлах, привели в конце 60-х  годов к появлению СУБД. В основе СУБД лежала простая идея: изъять из программ определение структуры содержимого файла и хранить её вместе с данными в базе данных.

1.3. Архитектура СУБД

    СУБД  должна предоставлять доступ к данным любым пользователям, включая и  тех, которые практически не имеют  и (или) не хотят иметь представления о:

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

    и множестве других функций СУБД.

    При выполнении основных из этих функций  СУБД должна использовать различные  описания данных. А как создавать эти описания?

    Естественно, что проект базы данных надо начинать с анализа предметной области  и выявления требований к ней  отдельных пользователей (сотрудников  организации, для которых создается  база данных). Подробнее этот процесс  будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

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

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

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

    Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.

    Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений. 
 
 
 
 
 
 
 

Глава 2. Модели данных

    Физическая  организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать  наиболее производительные физические модели данных, предлагая пользователям  тот или иной инструментарий для  поднастройки модели под конкретную БД. Разнообразие способов корректировки физических моделей современных промышленных СУБД не позволяет рассмотреть их в этом разделе.

2.1.Иерархическая модель

  Одной из наиболее важных сфер применения первых СУБД было планирование производства для компаний, занимающихся выпуском продукции. Например, если автомобильная компания хотела выпустить 10000 машин одной модели и 5000 машин другой модели, ей необходимо было знать, сколько деталей следует заказать у своих поставщиков. Чтобы ответить на этот вопрос, необходимо определить, из каких деталей состоят эти части и т.д. Например, машина состоит из двигателя, корпуса и ходовой части; двигатель состоит из клапанов, цилиндров, свеч и т.д. Работа со списками составных частей была как будто специально предназначена для компьютеров.

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

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

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

• найти конкретную деталь (правую дверь) по её номеру;
• перейти "вниз" к первому потомку (ручка двери);
• перейти "вверх" к предку (корпус);
• перейти "в сторону" к другому потомку (правая дверь).

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

  Одной из наиболее популярных иерархических  СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже перечислены преимущества IMS и реализованной в ней иерархической модели.

• Простота модели. Принцип построения IMS был легок для понимания. Иерархия базы данных напоминала структуру компании или генеалогическое дерево.
• Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: "А является частью В" или "А владеет В".
• Быстродействие. В СУБД IMS отношения предок/потомок были реализованы в виде физических указателей из одной записи на другую, вследствие чего перемещение по базе данных происходило быстро. Поскольку структура данных в этой СУБД отличалась простотой, IMS могла размещать записи предков и потомков на диске рядом друг с другом, что позволяло свести к минимуму количество операций записи-чтения.

  СУБД  IMS все ещё является одной из наиболее распространённых СУБД для больших ЭВМ компании IBM. Доля мэйнфреймов этой компании, на которых используется данная СУБД, превышает 25%.

2.2.Сетевая модель

  Если  структура данных оказывалась сложнее, чем обычная иерархия, простота структуры иерархической базы данных становилась её недостатком. Например, в базе данных для хранения заказов один заказ мог участвовать в трёх различных отношениях предок/потомок, связывающих заказ с клиентом, разместившим его, со служащим, принявшим его, и с заказанным товаром, что иллюстрирует рис. 1.3. Такие структуры данных не соответствовали строгой иерархии IMS. В связи с этим для таких приложений, как обработка заказов, была разработана новая сетевая модель данных. Она являлась улучшенной иерархической моделью, в которой одна запись могла участвовать в нескольких отношениях предок/потомок, как показано на рис. 1.4. В сетевой модели такие отношения назывались множествами. В 1971 году на конференции по языкам систем данных был опубликован официальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.