Студопедия.Орг Главная | Случайная страница | Контакты | Мы поможем в написании вашей работы!  
 

Модель данных в реляционных СУБД



Прежде чем сохранять какие-либо данные в СУБД – необходимо описать модель этих данных. По типу модели данных СУБД делятся на сетевые, иерархические и реляционные. СУБД реляционного типа являются наиболее распространенными и часто используемыми. В качестве примеров можно привести Oracle и Microsoft SQL Server.

Теория реляционных СУБД была разработана Коддом из IBM в 60-х годах 20-го века и базируется на математической теории отношений. Важнейшие понятия этой теории – таблица, строка, столбец, отношение, первичный и вторичный ключ.

Реляционная СУБД представляет собой совокупность именованных двумерных таблиц данных, логически связанных (находящихся в отношении) между собой. Таблицы состоят из строк и именованных столбцов, строки представляют собой экземпляры информационного объекта, столбцы – атрибуты объекта. В рассмотренном ранее примере таблица (назовем ее “Склад”) состоит из информационных объектов-строк, отдельная строка содержит сведения об отдельном товаре. Каждый товар характеризуется некими параметрами-атрибутами (“Наименование”, “Цена” и т.д.). Строки иногда называют записями, а столбцы – полями записи.

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

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

Пример логически взаимосвязанных таблиц:

Сотрудники  
Табельный № Фамилия Должность № отдела
  Иванов Начальник  
  Петров Инж.  
  Сидоров Менеджер  
Отделы  
№ отдела Наименование
  Производственный отдел
  Отдел продаж

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

Если какая-либо таблица содержит вторичный ключ, то она считается логически взаимосвязанной с таблицей, содержащей соответствующий первичный ключ. В общем случае эта связь имеет характер “один ко многим” (одному значению первичного ключа может соответствовать несколько значений вторичного, пример – отдел № 15). Возможны варианты, когда вторичный ключ входит в состав первичного ключа. Все зависит от предметной области, которую описывает модель. В общем случае СУБД ничего “не знает” о логической взаимосвязи таблиц модели. При обращении к СУБД с запросом пользователь должен в явном виде указать условия связывания двух таблиц. В нашем примере условие будет выглядеть примерно так: “Сотрудники”.”№ отдела” = “Отделы”.”№ отдела”. Следовательно, в процессе написания запроса возможно связать две таблицы по любым произвольным полям (не только по первичным и вторичным ключам), которые в принципе могут быть сравнимы друг с другом. В этом случае связь носит характер “многие ко многим”. Иногда это бывает необходимо делать при написании сложных и специфических запросов, но в общем случае не рекомендуется и свидетельствует об ошибках при проектировании логической модели БД.

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





Дата публикования: 2014-11-18; Прочитано: 334 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!



studopedia.org - Студопедия.Орг - 2014-2024 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.005 с)...