Экономическая информационная система. Единицы информации. Инфологическая модель: сущность – связь, страница 3

1.  порожденный сегмент может быть связан только с одним родительским сегментом

2.  корень дерева – сегмент, не имеющий родительского сегмента

3. 

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

Операторы иерархической СУБД:

Здесь используется гораздо меньше операторов.

·  получить уникальный (указать полный путь от корня до листа)

·  получить следующий (перебор сегментов сверху вниз и слева направо) GetNext – последний переход.

Реляционные СУБД

Ключевые элементы при создании БД:

Отношения – подмножество декартова произведения множеств значений реквизитов, входящих в это отношение. Например, R(A,B,C,D).

Недостаток – дублирование информации по кодам объектов в случае связи 1:М и М:М. Например, код продукта и код материала.

Основные операторы:

Создание индексного файла (по заданной примете найти запись в связующем массиве)

Описание данных различных моделях БД

Сетевая модель БД (Vista, InfoБанк)

Трехуровневая модель:

1.  внешний уровень – представление каждого пользователя

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

3.  физический – его использует администратор, решает, где какие данные разместить и к какому ресурсу у кого доступ.

Сетевая модель подходит для производственных предприятий.

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

1.  статья описания схемы БД

2.  статьи описания областей (области эквивалентны набору)

3.  статьи описания записи (типов записи)

4.  статьи описания типов наборов

Параметры каждой из статей:

1.  : имя схемы => несколько человек могут работать одновременно

2.  : имя области, пароль доступа к ней, который обеспечивает автоматический доступ

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

4.  : описание набора из двух статей (подстатей)

·  имя набора, имя владельца набора, порядок постоянен (из стандарта СУБД)

·  имя детальной записи; как указываются в цепочку записи: класс включения (автоматический/ручной); способ исключения записи из БД (обязательный/необязательный/фиксированный);указывается ключ, который используется при описании (*), то есть «ключ есть», его имя, по возрастанию/убыванию сортируется; способ доступа к набору данных, то есть доступ из другого набора.

Реляционная модель БД

2 способа описания.

1.  метод шаблонов

2.  метод использования текстового языка:

·  описание схем

·  статья описания доменов (имя домена, области знаний, допустимые для этого домена

·  статьи описания типов отношений (сначала – отношения-объекты, потом – объекты-связь)

·  статьи описания атрибутов (наименование атрибута, тип данных, область знания, формат)

·  статья наименования процедур обеспечения целостности БД

Иерархические СУБД

Древовидная структура -> надо описывать сегменты и поля.

Операторы (статьи).

1.  ДВД – статья описания схемы

2.  оператор определения (задания) состава набора (распределение сегментов по наборам). Здесь же используется метод организации данных в БД

3.  статья описания сегментов; при описании каждого сегмента – его имя, имя родительского сегмента (если есть), параметр размера сегмента (байт)

4.  статья описания поля – имя, является ли ключевым, если да, то единственное или множественное, с какого байта в сегменте поле начинается, его размер

Нормализация отношений в реляционных СУБД

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

Формы отношений:

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

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

Пример: в предметной области есть БД, которая содержит информацию о выпуске продукции различными фирмами. Атрибуты отношений: код продукции, код предприятия – составной ключ, адрес предприятия, наименование, годовой выпуск. От ключа зависят все атрибуты. Функциональная зависимость: код фирмы + код продукции определяют имя фирмы, его адрес и объем выпуска. Другая функциональная зависимость: код фирмы определяет имя и адрес. Значит, это не вторая нормальная форма, если есть несколько зависимостей, а не одна полная.

Представим в виде двух отношений:

R1: код фирмы, адрес, имя.

R2: код фирмы, код продукции, объем выпуска.

·  Третья нормальная форма – если отношение во второй нормальной форме и в нем исключены транзитивные функциональные зависимости (если а~в, в~с, то а~с)

Пример: Управление ВУЗом: № зачетки, ФИО студента, №группы, специальность, кафедра. Транзитивные зависимости: Студент (N_ZK, N_GR, FIO, SPEC, KAF)

Чтобы избавиться от транзитивной зависимости, надо разбить на отношения без таких зависимостей.