Экзаменационный билет № 22

1. Инфологическая модель базы данных

Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:  Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание (п. 1.2) ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

2. Нормализация базы данных

Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.  Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса клиента гораздо легче реализовать, если в базе данных эти сведения хранятся только в таблице Customers и нигде больше.  Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.  Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме». Есть и другие уровни нормализации, однако для большинства приложений достаточно нормализовать базы данных до третьей нормальной формы. Как и в случае со многими другими формальными правилами и спецификациями, обеспечить полное соответствие реальным ситуациям не всегда возможно. Как правило, для выполнения нормализации приходится создавать дополнительные таблицы, и некоторые клиенты считают это нежелательным. Собираясь нарушить одно из первых трех правил нормализации, убедитесь в том, что в приложении учтены все связанные с этим проблемы, такие как избыточность данных и несогласованные зависимости. 

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

Упорядочивание данных в логические группы или наборы.

Нахождение связей между наборами данных. Вы уже видели примеры связей один-ко-многим и многие-ко-многим.

Минимизация избыточности данных.

3. Архитектура базы данных

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

2.3.1 Архитектура схемы

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

Прежде всего, заметьте, что различные сплошные линии на рис. 2.10 показывают, что определенные компоненты в данной архитектуре связаны друг с другом способом, который будет вкратце рассмотрен далее. В частности, обратите внимание, что эти линии не предназначены для того, чтобы указывать поток обработки данных. Как можно видеть, наше упрощение одной схемы заменено тремя видами схем: логической схемой, схемой хранения и схемой пользователей (userschema). Позже мы объясним, чем вызвана эта замена. В верхнюю часть диаграммы мы также включили различные пользовательские процессы. Термин "пользовательский процесс" (user process) вводится для того, чтобы разрешить доступ к системе базы данных с помощью любого вида программного обеспечения от имени пользователя. А теперь мы более подробно исследуем эти концепции.

Логическая схема (logical schema) - это одиночное, центральное описание логических свойств данных в конкретной базе данных. Логическая схема больше описывает какими являются данные, чем то, как их можно хранить и как получить к ним доступ. Для любой данной системы баз данных имеется одна логическая схема. Она является описанием свойств типов данных, которые затем определяют свойства экземпляров данных в базе данных. Она описывается формальным языком, который может быть обработан компьютером. Этот язык иногда называют языком описания данных логической схемы (logical schema data definition language или logical schema DDL).

На этом этапе естественно возникает вопрос: как должна выглядеть реляционная логическая схема. Подробный ответ на этот вопрос приведен в Книгах 2 и 4, где вы узнаете о языках описания данных логической схемы для реляционной базы данных. Проще говоря, эффект создания реляционной схемы заключается в создании различных заголовков таблиц, которые включают частную систему реляционной базы данных. Так, реляционная схема университета будет состоять из определенийзаголовков таблиц, которые составляют реляционную базу данных университета, например, заголовки двух таблиц на рис. 2.8. Важно отметить, что определение этих заголовков будет включать ограничения в отношении экземпляров данных, которые могут появиться под этими заголовками. В качестве иллюстрации заметим, что определение колонки СтудентИд (StudentId) в таблице Студент (Student) гарантирует, что только достоверные однозначные идентификационные номера студентов могут появиться как экземпляры в данной колонке (в отличие от, скажем, имен студентов). Заголовки колонок таблицы Студент (Student) являются "свойствами типов данных", в то время как индивидуальные строки являются экземплярами данных, которые согласуются со свойствами данных.

Схема пользователей (userschema) - это определение логических свойств данных, которые пользовательский процесс должен отсылать тому пользователю, которому необходимы эти данные. Как и логическая схема, схема пользователей представляет собой определения свойств типов данных и они определяются в форме, которая может быть обработана компьютером. Так как, обычно, база данных необходима нескольким пользователям, то существует много схем пользователей, каждая из которых основана на одной и той же единственной логической схеме. Только через пользовательскую схему пользователь может получить доступ к базе данных. Пользовательский процесс может использовать только одну схему пользователя. Обычно, несколько пользовательских процессов могут потребовать одну и ту же схему пользователей - просмотр данных - и поэтому могут совместно использовать одну и ту же схему пользователей.

Схема хранения - это определение того, как хранить и получать доступ к данным, определенным в логической схеме. Определение происходит с помощью языка, который иногда называют языком описания данных схемы хранения (storage schema data definition language (или storage schema DDL). Для наших целей существует одна схема хранения для данной системы базы данных, точно так же как существует одна логическая схема. Подробное рассмотрение структур, определенных в схеме хранения, не входит в задачи данного курса¹⁵, но вы должны представлять себе хранение файлов, структуры файлов и методы доступа. Данные в каждой таблице, описанные в логической схеме, необходимо как-то физически хранить. Это осуществляется путем размещения данных каждой таблицы взапоминающем файле (stored file), который управляется операционной системой компьютера. Каждый хранимый файл хранится в соответствии со структурой (организацией) файла (file organization) (упорядоченной, индексной или хэшированной), поддерживающей метод доступа (access method), с помощью которого хранимые записи (stored records), составляющие данных файл, могут быть сохранены и извлечены. Таким образом, схема хранения применяет методы из технологии массовой памяти (запоминающего устройства большой емкости), используемой в вычислительных системах.