Шпаргалка по "Информатике"

данных относятся: DBMS, IDMS, TOTAL, VISTA, СЕТЬ, СЕТОР, КОМПАС и др.

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

 

 

27. Перекрестный запрос

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

Перекрестные запросы обладают следующими достоинствами:

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

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

 

9. Реляционная модель данных

Концепция реляционной модели данных была предложена в 1969 году Эдгаром Коддом, известным специалистом в области баз данных, а в 1970 году она была им опубликованы. Реляционная модель представляет собой совокупность  данных, состоящую из набора двумерных таблиц. В теории множеств таблице соответствует термин отношение (relation), физическим представлением которого является таблица, отсюда и название модели – реляционная. Реляционная модель является удобной  и наиболее привычной формой представления данных.

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

Любая таблица в реляционной базе состоит из строк, которые называют записями, и столбцов, которые называют полями. На пересечении строк и столбцов находятся конкретные значения данных. Для каждого поля определяется множество его значений, например, поле «Месяц» может иметь двенадцать значений.

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

· она состоит из совокупности столбцов;

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

· последовательность столбцов в таблице не существенна;

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

· в таблице нет одинаковых строк;

· количество строк в таблице практически не ограничено;

· последовательность строк в таблице не существенна;

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

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

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

В настоящее время многие известные системы управления базами данных используют именно реляционную  модель представления данных –:это  dBase, FoxBase, FoxPro, Paradox, Oracle, Microsoft Access, Clarion, Clipper, Ingres; отечественные: ПАЛЬМА, HyTech и др.

 

 

 

 

 

 

 

 

 

 

 

 

10. Постреляционная модель данных

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

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

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

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

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

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

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

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

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

Постреляционная модель данных реализована в СУБД uniVers, Bubba и Dasdb.

 

11. Объектно-ориентированная модель данных

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

Базовыми понятиями  этой модели являются следующие: объекты, классы,  методы, инкапсуляция, наследование, полиморфизм.

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

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

можно сказать следующее:

§ объектно-ориентированная база данных – это попытка применить идеологию объектно-ориентированного программирования к технологии баз данных;

§ объектно-ориентированная база данных состоит из объектов, причем каждый объект принадлежит к определенному классу;

§ поведение объекта полностью определяется его принадлежностью к определенному классу;

§ процесс проектирования объектно-ориентированной базы основан на выявлении классов объектов.

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

       12. Многомерная модель данных

Одновременно  с реляционной моделью данных появилась многомерная модель. Однако хоть идеи многомерной модели возникли одновременно с реляционной, но в ту пору практической реализации таких моделей не было. И лишь в 90-х годах ХХ века к ним стал проявляться интерес. Это было вызвано появлением статьи Э. Кодда, в которой он сформулировал 12 требований к системам класса OLAP (Online Analytical Processing – оперативная аналитическая обработка), связанных с возможностью представления и обработки многомерных массивов.

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

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

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

Многомерные модели поддерживают следующие системы: Essbase (фирма Arbor Software), Media Multi-matrix (фирма Speedware), Oracle Express Server (фирма Oracle), Cache (фирма InterSystems). Некоторые системы поддерживают одновременно реляционную и многомерную модель, например, Media/MR (фирма Speedware).

 

24. Типы полей таблиц

СУБД Access  может обрабатывать данные полей следующих типов:

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

Поле MEMO. Длинный текст (до 65535) символов.

Числовой. Числовые данные, используемые в математических вычислениях, за исключением денежных расчётов. Размеры числовых полей – 1,2,4,8,12 байтов.

Дата/вермя. Значения даты и времени. Даты из диапазона 100 по 9999 год.

Денежный. Денежные значения. Их макс. точность сост-ет 15 знаков слева от десятичной запятой и 4 знака справа от неё.

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

Логический. Поле этого типа моет иметь только одно значение из пары значений, таких как Да/Нет, Истина/Ложь или Вкл/Выкл.

Поле объекта OLE. Объекты других приложений, которые могут быть связаны или внедруны в таблицу БД Access.