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

 

 

 

5. Банки данных и их структура. Назначение и основные функции систем управления базами данных. Модели организации данных.

 

Банк данных- автоматизированная система централизованного хранения и коллективного использования данных. Если в состав БнД входит одна БД, банк принято называть локальным; если БД несколько - интегрированным. Структура: ВС — вычислительная система, включающая технические средства (ТС) и общее программное обеспечение (ОПО); БД — базы данных; СУБД — система управления БД; АБД — администратор баз данных, а также обслуживающий персонал и словарь данных

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

БД- унифицированная совокупность данных, совместно используемая различными задачами в рамках некоторой единой автоматической информационной системы.

1. Иерархическая модель  – все записи образуют иерархически  организованный набор, в котором  все элементы связаны отношением  подчиненности (1 ко многим)2.Сетевая  модель- отношения многие ко многим.3. Реляционная модель-каждая запись в такой базе данных содержит информацию, относящуюся только к одному конкретному объекту. се обрабатываемые данные представляются в виде плоских таблиц. Информация об объектах определенного вида представляется в табличном виде: в столбцах таблицы сосредоточены различные атрибуты объектов, а строки предназначены для сведения описаний всех атрибутов к отдельным экземплярам объектов. Нормальные формы предназначены для уменьшения избыточности информации, поэтому каждая последующая нормальная форма должна удовлетворять требованиям предыдущей и некоторым дополнительным условиям.4. Объектоориентированная модель-объекты можно хранить и использовать непосредственно не раскладывая их по таблицам.

6. Этапы проектирования  базы данных.

Этапы проектирования базы данных:

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

Цель  этапа концептуального проектирования ‒ создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур:

• определение сущностей  и их документирование;

• определение связей между  сущностями и их документирование;

• создание модели предметной области;

• определение атрибутов  и их документирование;

• определение значений атрибутов  и их документирование;

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

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

• выбор модели данных;

• определение набора таблиц и их документирование;

• нормализация таблиц;

• определение требований поддержки целостности данных и  их документирование.

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

• проектирование таблиц базы данных средствами выбранной СУБД;

• проектирование физической организации базы данных;

• разработка стратегии защиты базы данных.

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

II этап. Анализ  объекта.На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу. III этап. Синтез модели.На этом этапе по проведенному выше анализу необходимо выбрать определенную модель БД. Далее рассматриваются достоинства и недостатки каждой модели и сопоставляются с требованиями и задачами создаваемой БД. После такого анализа выбирают ту модель, которая сможет максимально обеспечить реализацию поставленной задачи. После выбора модели необходимо нарисовать ее схему с указанием связей между таблицами или узлами.IV этап. Выбор способов представления информации и программного инструментария.После создания модели необходимо, в зависимости от выбранного программного продукта, определить форму представления информации.В большинстве СУБД данные можно хранить в двух видах:с использованием форм;без использования форм.Форма – это созданный пользователем графический интерфейс для ввода данных в базу.V этап. Синтез компьютерной модели объекта.

7. Логическое проектирование баз данных. Физическая организация баз данных. Индексирование файлов в базах данных.

Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи  между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.) Результатом логического проектирования является логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой. Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Примером может быть сущности Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address. Каждая сущность должна быть полностью определена с помощью текстового описания. 
Каждая сущность может обладать любым количеством связей с другими сущностями модели. Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «Клиент размещает заказ» («A customer places an order» — этой фразой вполне можно описать связь, изображенную на рис. 1), где существительными являются названия связанных между собой сущностей. Подавляющее большинство средств проектирования данных позволяют создавать ER-диаграммы визуально, изображая сущности и соединяя их связями с помощью мыши. Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. 

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

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

Построение индекса и  его обновление выполняется автоматически  самой СУБД. Файл базы данных, для  которого создан хотя бы один индекс, называется индексированным файлом.

Для больших таблиц сами индексы  могут занимать несколько страниц  во внешней памяти. В таких ситуациях  создаются многоуровневые индексы, например, в виде сбалансированных деревьев (B-дерево или Balanced-tree), имеющих иерархическую структуру [ 2, 4 ]. Целью создания B-дерева является ускорение поиска, стремление избежать просмотра всего индекса Недостатком индексирования является необходимость выделения во внешней памяти дополнительного места для хранения индексов. Наиболее эффективным является создание индексов для первичных и внешних ключей, для полей, по которым в основном выполняются запросы.

 

8. Структура хранения и методы доступа к информации в базах данных. Распределенные базы данных

 

 

 

 

 

 

 

 

 

 

 

9. Правила нормализации отношений реляционной базы данных. Ограничения целостности реляционной базы данных

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

Основные свойства нормальной формы: -каждая следующая нормальная форма улучшает свойства предыдущей формы, - при переходе к следующей нормальной форме свойства предыдущей формы сохраняются. Отношение находится в первой нормальной форме (сокращённо 1НФ), если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя разделить на более простые атрибуты, которые соответствуют каким-то другим свойствам описываемой сущности. отношение находится во второй нормальной форме (сокращённо 2НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут полностью зависим от первичного ключа. Для перехода во 2-ю нормальную форму необходимо:1)определить на какие части м разбить первичный ключтак, чтобы некоторые из неключевых полей зависели от одной из этих частей; 2)создать новые таблицы для каждой такой части ключа и группы зависящих от нее ключей. 3-я нормальная форма-для перехода в 3-ю нормальную форму необходимо определить все поля, от которых зависят другие поля, составить новые таблицы для каждого такого поля и группы зависящих от него полей и переместить их в эту таблицу, поля от которого зависят эти поля станет первичным ключом новой таблицы.

На практике обычно процесс  нормализации заканчивается на 3-й  нормальной форме, нов теории есть 4 и 5 нормальные формы.

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

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

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

Пусть, например, даны отношения  ОТДЕЛ (N_ОТДЕЛА, ИМЯ_ОТДЕЛА) и СОТРУДНИК (N_СОТРУДНИКА, N_ОТДЕЛА, ИМЯ_СОТРУДНИКА), в которых хранятся сведения о работниках предприятия и подразделениях, где они работают. Отношение ОТДЕЛ в данной паре является родительским, поэтому его первичный ключ "N_отдела" присутствует в дочернем отношении СОТРУДНИК. Требование целостности по ссылкам означает здесь, что в таблице СОТРУДНИК не может присутствовать кортеж со значением атрибута"N_отдела", которое не встречается в таблице ОТДЕЛ. Если такое значение в отношении ОТДЕЛ отсутствует,  значение внешнего ключа  в отношении СОТРУДНИК считается неопределенным. Как правило, поддержание целостности ссылок также возлагается на систему управления базой данных. Например, она может не позволить пользователю добавить запись, содержащую внешний ключ с несуществующим (неопределенным) значением.