рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Модели данных СУБД

Модели данных СУБД - раздел Программирование, Среда Delphi широко известна и не вызывает дополнительных трудностей при изучении и использовании   Коцептуальной Моделью Данных В Бд Называют Глобальное Логичес...

 

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

· языки описания данных;

· языки запросов;

· физическую организацию данных;

· возможности и свойства СУБД.

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

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

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

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

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

· найти конкретную деталь (правую дверь) по её номеру;

· перейти "вниз" к первому потомку (ручка двери);

· перейти "вверх" к предку (корпус);

· перейти "в сторону" к другому потомку (правая дверь).

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

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

· Простота модели. Принцип построения IMS был легок для понимания. Иерархия БД напоминала структуру компании или генеалогическое дерево.

· Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: "А является частью В" или "А владеет В".

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

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

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

Компания IBM не стала разрабатывать собственную сетевую СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.

Сетевые СУБД обладали рядом преимуществ:

· Гибкость. Множественные отношения предок/потомок позволяли сетевой СУБД хранить данные, структура которых была сложнее простой иерархии.

· Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Конечно, у сетевых СУБД были недостатки. Как и иерархические СУБД, сетевые базе данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперед. Изменение структуры БД обычно означало перестройку всей БД.

Как иерархическая, так и сетевая СУБД были инструментами программистов. Чтобы получить ответ на вопрос типа "Какой товар наиболее часто заказывает компания Acme Manufacturing?", программисту приходилось писать программу для навигации по БД. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.

Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Э.Коддом в 1970 году и вызвавшей всеобщий интерес. Реляционная модель была попыткой упростить структуру БД. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы. Таблицы представляют собой частный случай более общего математичкского понятия – отношения.

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

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

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

Приведенное определение не оставляет места встроенным указателям, имеющимся в иерархических и сетевых СУБД. Несмотря на это, реляционная СУБД также способна реализовать отношения предок/потомок, однако эти отношения представлены исключительно значениями данных, содержащихся в таблицах.

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

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

– Конец работы –

Эта тема принадлежит разделу:

Среда Delphi широко известна и не вызывает дополнительных трудностей при изучении и использовании

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

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Модели данных СУБД

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

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

Двенадцать правил Кодда для реляционных СУБД
В статье, опубликованной в 1985 году [3], Э. Кодд сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная БД. Они являются полуофициальным определением понятия

Нормализация таблиц БД. Первая, вторая и третья нормальные формы
  При проектировании структуры БД естественным желанием бывает минимизировать количество таблиц, а в идеальном случае сосредоточить все данные в одной таблице. Однако это оказывается

Нормальная форма Бойса-Кодда
  Пусть в определенном выше отношении SP присутствует еще и имя поставщика Sname. Будем для удобства считать, что имя однозначно определяет поставщика. Тогда в отношении SP (Sn, Sname

Четвертая нормальная форма
  Рассмотрим таблицу R (Subj, Teach, Book), где Subj – учебный предмет, Teach- преподаватель по этому предмету, Book – книга, рекомендуемая преподавателем Teach для изучения предмета

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

В реляционной СУБД
  Одним из главных достоинств иерархических и сетевых СУБД считают естественность представления данных иерархической и сетевой природы. А как представлять такие данные в реляционных С

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

Основы реляционного исчисления
  Реляционное исчисление это математический аппарат, который позволяет путем использования исчисления предикатов, кванторов и переменных описывать отношения и операции над ними в виде

Общая характеристика и стандарты языка SQL
  Язык SQL (Structered Query Language) впервые появился в рамках проекта разработки экспериментальной реляционной СУБД System R в исследовательской лаборатории фирмы IBM в 1975-1979 г

Многотабличные запросы SQL. Соединения таблиц. Самосоединения. Псевдонимы
  Запросы могут выбирать данные изнескольких таблиц. Эти таблицы должны быть перечислены после слова FROM. Если таблицы не связаны между собой, то результатом запроса будут всевозможн

Внешнее соединение таблиц
  Рассмотренные соединения называют внутренними (INNER JOIN). В некоторых случаях требуются соединения другого вида – внешние соединения (OUTER JOIN). Рассмотрим две таблицы A (Stud,

Для реализации итоговых запросов в SQL имеются следующие стандартные функции, которые называют агрегатными
· MAX (поле) – максимальное значение поля; · MIN (поле) – минимальное значение поля; · AVG (поле) – среднее значение поля; · SUM (поле) – сумма значений поля; ·

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

Целостность данных
  Термин “целостность данных” относится к правильности и полноте информации, содержащейся в БД. Вероятно, корректнее говорить о непротиворечивости данных, поскольку невозможно предотв

Триггеры и хранимые процедуры
  Как уже говорилось, целостность данных часто связана с порядками и правилами в конкретной организации. Например: · клиенты не могут размещать заказы на сумму, превышающую и

Обработка транзакций
  Транзакцией называются несколько последовательных операторов SQL, которые рассматриваются как единое целое. В транзакции каждый оператор решает часть общей задачи, но для того, чтоб

Представления и работа с ними
  Представлением (VIEW) называется SQL-запрос на чтение, которому присвоили имя и сохранили в БД. Представление является виртуальной таблицей, то есть обеспечивает доступ к результата

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

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

Динамический SQL
Рассмотренные возможности SQL реализуются в так называемом статическом SQL. В каждом встроенном операторе программист заранее указывает, на какие таблицы и столбцы он будет ссылать

Элементы языка QBE
  Язык QBE (Query By Example – запрос по образцу) был разработан в компании IBM в 1975 году. Это язык реляционного исчисления с переменными на доменах, рассчитанный на работу в интера

Подходы к оптимизации запросов
  Говоря про оптимизацию запросов в реляционных СУБД, обычно имеют в виду такой способ обработки, когда по начальному представлению запроса путем преобразований вырабатывается процеду

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

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги