Шпаргалка по "Информационным системам в экономике"

16. Инфологические  и даталогические модели данных.

   СУБД  должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

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

   и множестве других функций СУБД.

   При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?

   Естественно, что проект базы данных надо начинать с анализа предметной области  и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

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

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

17. Иерархическая модель данных

   ИМД основана на понятии деревьев, состоящих из вершин и ребер.  Вершине  дерева  ставится в соответствие  совокупности атрибутов данных,  характеризующих некоторый объект.  Вершины и ребра  дерева  как бы образуют иерархическую древовидную структуру, состоящую из n уровней.

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

   Первую  вершину называют корневой вершиной.

    Она  удовлетворяет условиям:

1. Иерархия начинается с корневой вершины.
2. Каждая  вершина  соответствует одному или нескольким атрибутам.
3. Hа уровнях с большим номером находятся зависимые вершины. Вершин  предшествующего уровня является начальной для новых зависимых вершин.
4. Каждая вершина, находящаяся на уровне i, соединена с одной и только одной вершиной уровня i-1, за исключением корневой вершины.
5. Корневая  вершина   может быть  связана с одной или несколькими зависимыми вершинами.
6. Доступ  к  каждой вершине происходит через корневую по единственному пути
7. Существует  произвольное  количество вершин каждого уровня.

   Иерархическая модель  данных состоит из нескольких деревьев, т.е.  является лесом.  Каждая корневая вершин  образует начало записи логической базы данных.  В ИМД вершины, находящиеся на уровне i, называют порожденными вершинами на уровне i-1.

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

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

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

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

18. Сетевая модель  данных

   В СМД  элементарные  данные  и  отношения  между  ними представляются в  виде  ориентированной  сети (вершины - данные, дуги - отношения).

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

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

• Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.
• Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.
• Быстродействие.  Вопреки своей большой сложности, сетевые базы данных достигали быстродействия, сравнимого с быстродействием иерархических баз данных. Множества были представлены указателями на физические записи данных, и в некоторых системах администратор мог задать кластеризацию данных на основе множества отношений.

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

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

   Над данными сетевой модели можно  выполнять следующие действия:

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

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

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

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

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

   Ограничения реляционной модели данных:

1. Должны отсутствовать записи-дубликаты
2. Столбцы реляц.таблицы поименованы, поэтому их порядок не важен.
3. порядок записей может быть произвольным
4. Каждая запись  уникальна и однозначно определяется значением ключа.
5. Каждый элемент таблицы называется полем, может быть однозначно определен.
6. В столбце записываются данные одного типа

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

   Все операции, выполняемые над отношениями, можно разделить на две группы:

1. Операции над отношениями, к которым относятся проекция, соединение и выбор.
2. Операции над множеством, то есть над несколькими отношениями (объединение, пересечение, разность, деление, декартово произведение).

20. Множества, отношения, атрибуты, домены и кортежи  отношений.

Домен

Наименьшая  единица данных реляционной модели — это отдельное атомарное (неразложимое) для данной модели значение данных. Доменом называется множество атомарных значений одного и того же типа. Иными словами, домен представляет собой допустимое потенциальное множество значений данного типа.

В нашем  примере можно для каждого  столбца таблицы определить домен:

- домены  «Имена» и «Специальности» для столбцов «Имя» и «Специальность» соответственно будут базироваться на строковом типе данных — в число их значений могут входить только те строки, которые могут изображать имя и название специальности (в частности, такие строки не должны начинаться с мягкого знака);

- домен  «Даты_рождения» для столбца «Дата_рождения»  определяется на базовом временном  типе данных — данный домен  содержит только допустимый диапазон дат рождения студентов;

- домены  «Номера_курсов» и «Номера_студенческих_билетов»  базируются на целочисленном типе — в число его значений могут входить только те целые числа, которые могут обозначать номер курса университета (обычно от 1 до 6) и номер студенческого билета (обязательно положительное число).

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

лишено  смысла. В нашем примере значения доменов «Номера_курсов» и "Номера_студенческих_билетов" основаны на одном типе данных - целочисленном, но не являются сравнимыми.

Атрибуты, схема отношения, схема базы данных