Контрольная работа по "Базы данным"

ЭКАЗАМЕНАЦИОННЫЙ  БИЛЕТ №1 

Дисциплина: Базы данных 

1. Определение реляционной модели (РМ) и реляционной  базы данных. Место  реляционных баз  данных в современных  компьютерных технологиях. Сопостовление терминологии РМ, объектно-ориентированного подхода, СУБД. Базовые понятия РМ: домен, отношения, таблица, кортеж. Свойства отношений.

 

   Реляционная модель данных –  логическая модель данных. Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd) в 1970 году в статье "A Relational Model of Data for Large Shared Data Banks" (русский перевод статьи, в которой она впервые описана, опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

   В реляционной модели достигается  гораздо более высокий уровень  абстракции данных, чем в иерархической  или сетевой. В упомянутой статье Е.Ф. Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation – "отношение").  

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

Применение  реляционной модели данных.  

     Пример  базы данных, содержащей сведения о  подразделениях предприятия и работающих в них сотрудниках, применительно  к реляционной модели будет иметь  вид:

 

База  данных о подразделениях и сотрудниках  предприятия. 

     Например, связь между отношениями ОТДЕЛ  и СОТРУДНИК создается путем  копирования первичного ключа "Номер_отдела" из первого отношения во второе. Таким образом:

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

из таблицы  ОТДЕЛ установить значение атрибута "Номер_отдела", соответствующее данному "Наименованию_отдела"

выбрать из таблицы СОТРУДНИК все записи, значение атрибута "Номер_отдела" которых равно полученному на предыдущем шаге

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

определяем "Номер_отдела" из таблицы СОТРУДНИК

по полученному  значению находим запись в таблице  ОТДЕЛ 

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

Сопоставление объектов и данных. 

     При использовании объектно-ориентированного программирования для взаимодействия с системами хранения данных возникают  сложности. Безусловно, организация  классов часто напоминает организацию  таблиц реляционной базы данных, но такое соответствие неидеально. Несколько  нормализованных таблиц часто соответствуют  единственному классу, а связи  между классами представлены не так, как связи между таблицами. Например, для представления клиенту заказа на продажу в классе Order может использоваться свойство, содержащее ссылку на экземпляр класса Customer, но строка таблицы Order базы данных содержит столбец внешнего ключа (или набор столбцов) со значением, которое соответствует первичному ключу в таблице Customer. Класс Customer может включать свойство с именем Orders, содержащее коллекцию экземпляров класса Order, но таблица Customer базы данных не содержит сравнимого столбца. В этом случае Entity Framework предоставляет разработчикам гибкость в представлении связей или более полные связи модели (такие, как в базе данных). Дополнительные сведения см. в разделе Определение отношений и управление отношениями (платформа Entity Framework).

     В существующих решениях была предпринята  попытка устранить этот разрыв, часто  называемый «несоответствием типов  данных» (impedance mismatch), путем сопоставления с реляционными таблицами и столбцами только объектно-ориентированных классов и свойств. Вместо данного традиционного подхода в Entity Framework реляционные таблицы, столбцы и ограничения внешнего ключа логических моделей преобразуются в сущности и связи концептуальных моделей. Это позволяет достичь большей гибкости при определении объектов и оптимизации логической модели. С помощью инструментов Entity Data Model формируются расширяемые классы данных, основанные на концептуальной модели. Эти классы являются разделяемыми классами, которые могут быть расширены с помощью дополнительных членов, добавленных разработчиком. По умолчанию классы, сформированные для определенной концептуальной модели, являются производными от базовых классов, предоставляющих службы для материализации сущностей в виде объектов, а также для отслеживания и сохранения изменений. Разработчики могут использовать эти три класса для работы с сущностями и связями как с объектами, относящимися к ассоциациям. Разработчики смогут также настраивать классы, сформированные для концептуальной модели. Дополнительные сведения см. в разделах Работа с объектами (платформа Entity Framework) и Как настроить создание кода уровня объекта (конструктор моделей EDM). 

Домены

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

    Домен - это семантическое понятие. Домен  можно рассматривать как подмножество значений некоторого типа данных имеющих  определенный смысл. Домен характеризуется  следующими свойствами:

    Домен имеет уникальное имя (в пределах базы данных).

    Домен определен на некотором простом  типе данных или на другом домене.

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

    Домен несет определенную смысловую нагрузку.

    Например, домен  , имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:

    

    Если  тип данных можно считать множеством всех возможных значений данного  типа, то домен напоминает подмножество в этом множестве.  

Отношения, атрибуты, кортежи  отношения

    Фундаментальным понятием реляционной модели данных является понятие отношения. В определении  понятия отношения будем следовать  книге К. Дейта.

    Атрибут отношения есть пара вида <Имя_атрибута : Имя_домена>.

    Имена атрибутов должны быть уникальны  в пределах отношения. Часто имена  атрибутов отношения совпадают  с именами соответствующих доменов.

    Отношение , определенное на множестве доменов (не обязательно различных), содержит две части: заголовок и тело.

    Заголовок отношения содержит фиксированное  количество атрибутов отношения:

    

    Тело  отношения содержит множество кортежей отношения. Каждый кортеж отношения  представляет собой множество пар  вида <Имя_атрибута : Значение_атрибута>:

    

    таких что значение атрибута принадлежит домену

    Отношение обычно записывается в виде:

     ,

    или короче

     ,

    или просто

     .

    Число атрибутов в отношении называют степенью (или -арностью) отношения. Мощность множества кортежей отношения называют мощностью отношения. Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем). Тело отношения представляет собой набор кортежей, т.е. подмножество декартового произведения доменов. Таким образом, тело отношения собственно и является отношением в математическом смысле слова. Тело отношения может изменяться во время работы с базой данных - кортежи могут изменяться, добавляться и удаляться.

    Рассмотрим  отношение "Сотрудники" заданное на доменах "Номер_сотрудника", "Фамилия", "Зарплата", "Номер_отдела". Т.к. все домены различны, то имена атрибутов отношения удобно назвать так же, как и соответствующие домены. Заголовок отношения имеет вид:

    Сотрудники (Номер_сотрудника, Фамилия, Зарплата, Номер_отдела)

    Пусть в данный момент отношение содержит три кортежа:

    (1,Иванов, 1000, 1)

    (2, Петров, 2000, 2)

    (3, Сидоров, 3000, 1)

    такое отношение естественным образом  представляется в виде таблицы1:

    Таблица 1 Отношение "Сотрудники"

    Реляционной базой данных называется набор отношений.

    Схемой  реляционной базы данных называется набор заголовков отношений, входящих в базу данных.

    Хотя  любое отношение можно изобразить в виде таблицы, нужно четко понимать, что отношения не являются таблицами. Это близкие, но не совпадающие понятия. Различия между отношениями и  таблицами будут рассмотрены  ниже.

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

    Свойства  отношений непосредственно следуют  из приведенного выше определения отношения. В этих свойствах в основном и  состоят различия между отношениями  и таблицами.

    В отношении нет одинаковых кортежей. Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки.

    Кортежи не упорядочены (сверху вниз). Действительно, несмотря на то, что мы изобразили отношение "Сотрудники" в виде таблицы, нельзя сказать, что сотрудник Иванов "предшествует" сотруднику Петрову. Причина та же - тело отношения есть множество, а  множество не упорядочено. Это вторая причина, по которой нельзя отождествить отношения и таблицы - строки в  таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых  строки идут в различном порядке.