ПЗ (1190987), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

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

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

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

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

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

Система баз данных может основываться на нескольких всевозможных подходах. Сетевая и иерархическая модели данных стали использоваться в СУБД в начале 60-х годов. В начале 70-х годов появилась первая реляционная модель данных. Эти три модели отличаются в основном методом представления взаимосвязей между объектами.

Иерархическая модель данных базируется по принципу иерархии типов объектов, то есть один образ объектов является ключевым, а иные, оказавшиеся на низших уровнях – подчинёнными [21]. Между подчинёнными и главным типами объекта устанавливается связь «один ко многим». Другими словами, для нынешнего главного типа объекта есть некоторое количество подчинённых типов объекта.

Иерархическую древовидную структуру можно строить из узлов и ветвей. Узел – объединение атрибутов данных, которые описывают какой-либо объект. Зависимые узлы размещаются на невысоких уровнях дерева.

Плюсы иерархической модели данных:

1. доступность и простота использования и понимания;

2. обеспечение конкретного уровня независимости данных;

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

Минусы модели:

1. слишком большое хранение данных;

2. из-за жесткой иерархической упорядоченности объектов модели очень усложняются операции подключения и удаления;

3. процедурность операций манипулирования данными;

4. удаление исходных объектов влечёт удаление порождённых;

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

В сетевой модели данных определения главного и подчинённых объектов расширены. Любой объект может быть как главным, так и подчинённым. Главный объект классифицируется термином «владелец набора», а подчинённый – «член набора». Один объект в одно и тоже время может быть и в роли обладателя и в роли члена набора. Это значит, что объект участвует во всяком случае взаимосвязей.

В сетевой модели объекты соединяются в «сеть». Любой образ записи может содержать нуль, один или же несколько атрибутов.

Плюсы сетевой модели:

1. допустимость ручного построения действенных прикладных систем;

2. возможность экономии памяти за счет деления подобъектов;

3. простая реализация нередко встречающихся в нынешнем мире взаимосвязей «многие ко многим».

Минусы сетевой модели:

1. возможная утрата информации при реорганизации базы данных;

2. сложность модели.

Реляционные системы основаны на формальной теории, именуемой реляционной моделью данных, предпологающая следующее:

1. данные представлены при помощи строк в таблицах, и эти строчки могут быть именно интерпретированы как настоящие высказывания;

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

К количеству плюсов реляционного подхода возможно отнести:

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

2. доступность ненавигационного манипулирования данными без необходимости знания определенной физической организации баз данных во внешней памяти;

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

Реляционные системы далеко не сразу получили широкое распространение [19]. Главные теоретические итоги в данной области были получены ещё в 70-х, и тогда же появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Впрочем указанные выше отличительные качества и постепенное накопление способов и алгоритмов организации табличных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы буквально вытеснили с мирового рынка ранние СУБД.

Любое отношение содержит заголовок и тело. Заголовок – это набор пар «имя столбца: имя типа», а тело отношения состоит из набора строк, соответствующих заголовку. Заголовок всякого отношения возможно рассматривать как предикат, а всякую строку в теле отношения –некоторое истинное высказывание, которое образовалось в результате подстановки определённых значений аргументов соответственного типа взамен параметров или место держателей этого предиката.

Исходные переменные ­­­– отношения в какой-либо БД именуются базовыми переменными – отношениями, а их значения называются базовыми отношениями. Отношение, полученное из таких базовых отношений путём вычисления какого-либо реляционного выражения, являются производными. Представление – это переменная-отношение, смысл которой во всякий нынешний момент является некоторым производным отношением. Значение такой переменной-отношения во всякий момент представляет собой итог вычисления соответственного реляционного выражения, которое определяет это представление. В следствие этого, возможно сказать, что базовые переменные-отношения существуют независимо, а представления – нет.

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

Существует некоторое количество уровней представления данных:

• описание физической организации БД;

• общее логическое описание, интегрирующее описание локальных пользователей;

• описание определенного конечного пользователя, который имеет локальное описание.

Описание модели на определенном языке называется схемой. В соответствии с уровнями представления различают:

1. подсхема (внешняя схема) – представление локального пользователя;

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

3. физическая (внутренняя схема).

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

На этапе проектирования можно выделить логическое пользовательское представление и информационную схему предметной области (рисунок 1).

Рисунок 1 – Логическое пользовательское представление и информационная схема

Такие разные уровни описания можно соотнести с понятием архитектура СУБД.

Описание предметной области, которое выполняется без ориентации на используемые в дальнейшем технические и программные средства –инфологическая модель предметной области, а этап проектирования — инфологическим проектированием. Концептуальная модель БД считается моделью логического уровня, т.е. обрабатывает логические связи между элементами данных безотносительно к их среде хранения и содержанию.

Данная модель строится в соответствии с терминами какой-либо конкретной СУБД, в среде которой проектируется БД. Такой этап имеет название – даталогическое проектирование.

Описание физической структуры БД называется схемой хранения. Данный этап имеет название - физическое проектирование. На данном этапе могут выполняться вот такие работы:

• метод доступа;

• выбор методов сжатия или отказ от них;

• метод организации данных;

• выбор типа носителя;

• определение размера физического блока;

• проблема уничтожения и т.д.

В большинстве настольных СУБД данный период проектирования скрыт от пользователя.

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

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

1.6 Работа СУБД

Рисунок 2 – Последовательность действий в СУБД

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

1. Прикладная программа А выдает запрос СУБД на чтение записи.

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

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

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

5. СУБД выдает операционной системе команду чтения требуемой записи.

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

7. Запрошенные данные передаются из памяти в системный буфер.

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

9. СУБД передает данные из системного буфера в рабочую область прикладной программы А.

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

2. . Прикладная программа обрабатывает данные, помещенные в рабочую область.

1.7 Организация данных

1.7.1 Физическая организация данных

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

Аспекты проблемы:

1. нахождение нужной записи между большого количества данных: группа битов, прочитываемая с поддержкой одной машинной инструкции, имеет название ­– одна физическая запись. Программы идентифицируют логическую запись с помощью ключа.

Ключ машинный адрес.

Переход от ключа к адресу определяет суть метода адресации;

1. древовидные сетевые структуры: представление в виде последовательности битов;

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

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

Ключ БД – RID (Record IDentificator)

Характеристики

Список файлов ВКР