Размещено на http://www.allbest.ru/

Курс лекций

Теория экономических информационных систем

Содержание

• 1. Архитектура и основные компоненты ЭИС
• 2. Пользователи, администрирование и схема функционирования ЭИС
• 3. Классификация ИС. Жизненный цикл ИС и его модели
• 4. Этапы проектирования экономических информационных систем
• 5. Исследование предметной области (ПО). Модель «сущность-связь»
• 6. Системы кодирования и классификации экономической информации
• 7. Модели данных: концептуальные, логические и физические
• 8. Инфологические и даталогические модели данных
• 9. Иерархические, сетевые и реляционные модели представления данных
• 10. Множества, отношения, атрибуты, домены и кортежи отношений
• 11. Функциональные и многозначные зависимости между атрибутами
• 12. Нормализация и нормальные формы отношений. Правила проектирования реляционных баз данных. Операции реляционной алгебры. Реляционное исчисление
• 13. Оптимизация запросов к базе данных
• 14. Основные функции и компоненты СУБД
• 15. Клиентские СУБД, примеры, назначение и возможности
• 16. Серверные СУБД, примеры, назначение и возможности
• 17. Основные операторы SQL. Синтаксис и примеры использования оператора SELECT
• 18. Реляционная полнота SQL
• 19. Методология RAD
• 20. Инструментальные средства CASE технологии
• 21. Методы контроля достоверности экономической информации
• 22. Объектно-ориентированные СУБД. Параллельная обработка данных
• 23. Распределенные и полнотекстовые базы данных. Хранилища данных
• Экономическая информационная система представляет собой систему, функционирование которой во времени заключается в сборе, хранении, обработке и распространении информации о деятельности какого-либо экономического объекта реального мира.

1. Архитектура и основные компоненты ЭИС

экономический информационный система администрирование

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

База данных - это набор сообщений, которые

1. являются истинными для соответствующей материальной системы

2. непротиворечивы по отношению друг к другу

Сообщения в БД обычно являются форматированными и хранятся в виде единиц информации.

Единицей информации называется набор символов, которому придается определенный смысл. Это понятие в основном относится к базе данных, хранящей форматированные сообщения.

Минимально необходимы две единицы информации - атрибут и составная единица информации (СЕИ).

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

Составная единица информации представляет собой набор из атрибутов и, возможно, других СЕИ.

Простейшими СЕИ являются таблицы.

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

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

Под вычислительной системой будем понимать серийно выпускаемую электронно-вычислительную машину, либо несколько ЭВМ, соединенных каналами связи в вычислительную сеть.

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

2. Пользователи, администрирование и схема функционирования ЭИС

Пользователей экономической информационной системы можно подразделить на пять типов:

· Случайные пользователи, взаимодействие которых с ЭИС не обусловлено их служебными обязанностями.

· Конечные пользователи, которые работают с ЭИС повседневно, в соответствии с четко определенной областью деятельности, по регламентированным процедурам,

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

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

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

3. Классификация ИС. Жизненный цикл ИС и его модели

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы

1. одиночные;2. групповые;3. корпоративные.

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.

Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Qicrosoft SQL Server, InterBase, Sybase, Inforqix.

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Qicrosoft SQL Server.

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

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы

1. системы обработки транзакций;2. системы принятия решений;

3. информационно-справочные системы; 4. офисные информационные системы.

Классификация по способу организации

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

1. системы на основе архитектуры файл-сервер; 2. системы па основе архитектуры клиент-сервер; 3. системы на основе многоуровневой архитектуры; 4. системы на основе Интернет/интранет-технологий.

Модели ИС.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

· каскадная модель (70-85 г.г.);

· спиральная модель (86-90 г.г.).

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

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

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

Рис. 1.1. Каскадная схема разработки ПО

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 1.3. Спиральная модель ЖЦ

4. Этапы проектирования экономических информационных систем

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

Можно выделить следующие фазы развития информационной системы:

1. формирование концепции;

2. разработка технического задания;

3. проектирование;

4. изготовление;

5. ввод системы в эксплуатацию.

Рассмотрим каждую из них более подробно.

Концептуальная фаза

Главным содержанием работ на этой фазе является определение проекта, разработка его концепции, включающая:

1. формирование идеи, постановку целей;

2. формирование ключевой команды проекта;

3. изучение мотивации и требований заказчика и других участников;

4. сбор исходных данных и анализ существующего состояния;

5. определение основных требований и ограничении, требуемых материальных,

финансовых и трудовых ресурсов;

6. сравнительную оценку альтернатив;

7. представление предложений, их экспертизу и утверждение.

Разработка технического предложения

Главным содержанием этой фазы является разработка технического предложения

переговоры с заказчиком о заключении контракта. Общее содержание работ этой фазы:

1. разработка основного содержания проекта, базовой структуры проекта;

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

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

4. составление сметы и бюджета проекта, определение потребности в ресурсах;

5. разработка календарных планов и укрупненных графиков работ;

6. подписание контракта с заказчиком;

7. ввод в действие средств коммуникации участников проекта и контроля за ходом работ.

Проектирование

На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:

1. выполнение базовых проектных работ;

2. разработка частных технических заданий;

3. выполнение концептуального проектирования;

4. составление технических спецификаций и инструкции;

5. представление проектной разработки, экспертиза и утверждение.

Разработка

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

1. выполнение работ по разработке программного обеспечения;

2. выполнение подготовки к внедрению системы;

3. контроль и регулирование основных показателей проекта.

Ввод системы в эксплуатацию

На этой фазе проводятся испытания, опытная эксплуатация системы в реальных

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

новых контрактах. Основные виды работ:

1. комплексные испытания;

2. подготовка кадров для эксплуатации создаваемой системы

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

4. сопровождение, поддержка, сервисное обслуживание;

5. оценка результатов проекта и подготовка итоговых документов;

6. разрешение конфликтных ситуаций и закрытие работ по проекту;

7. накопление опытных данных для последующих проектов, анализ опыта, состояния, определение направлений развития.

5. Исследование предметной области (ПО). Модель «сущность-связь»

Предметной областью называются элементы материальной системы, информация о которых хранится и обрабатывается в ЭИС.

Одной из наиболее популярных семантических моделей данных является модель «сущность-связь" (часто называемая также ER-моделью -- по первым буквам английских слов Entity (сущность) и Relation (связь)).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом в 1976г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE-средствах, предназначенных для автоматизированного проектирования реляционных баз данных.

Для моделирования структуры данных используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущностями. В соответствии с этим ER-диаграммы получили распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Наиболее распространенными являются диаграммы, выполненные в соответствии со стандартом 1DEF1X, который используют наиболее популярные CASE-системы (в частности, ERwin, Design/IDEF, Power Designer). Основными понятиями ER-диаграммы являются сущность, связь и атрибут.

Сущность

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

1. иметь уникальный идентификатор;

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

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

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

В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности.

Связь

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

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

6. Системы кодирования и классификации экономической информации

Простейшие системы кодирования и классификации:

1. Классификация не требуется, тогда производится нумерация объектов, и кодом каждого объекта является его порядковый номер. Такая система кодирования называется порядковой.

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

3. Используются несколько классификационных признаков, их взаимная подчиненность соответствует выделению классов объектов, подклассов внутри классов и т.д. Здесь удобна разрядная система кодирования.

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

7. Модели данных: концептуальные, логические и физические

Концептуальные модели данных

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

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

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

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

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

Описание хранимой и обрабатываемой информации в ЭИС делается с разной степенью детализации. Различают 3 уровня детализации:

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

2. Концептуальный уровень - описание информационных потребностей на уровне ЭИС.

3. Внутренний уровень - описание способов хранения информации в памяти ЭВМ и методов доступа к ней.

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

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

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

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

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

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

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

Обычно различают концептуальные модели двух видов:

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

· семантические модели, отражающие значения реальных сущностей и отношений.

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

Несмотря на то что в последнее время все большее распространение получают объектно-ориентированные модели, не снижается и значение семантических моделей. Концептуальное моделирование баз данных на основе семантических моделей поддерживается во всех известных CASE-средствах (например, таких как ERWin и Power Designer). Кроме того, семантические модели более просты для понимания, особенно при проектировании сравнительно небольших баз данных. Как и реляционная модель, любая развитая семантическая модель данных ик.'почае структурную, манипуляционную и целостную части. Главным назначением семантических моделей является обеспечение' возможности выражения семантики данных. Цельсемантическою моделирования -- обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому семантическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки в тексте неоднозначности любого естественного языка). Основными конструктивными элементами семантических моделей являются сущности, связи между ними и свойства (атрибуты).

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

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

· физическом размещении в памяти данных и их описаний;

· механизмах поиска запрашиваемых данных;

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

· способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

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

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

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

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

Рис. 1.3. Уровни моделей данных

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

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

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

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

9. Иерархические, сетевые и реляционные модели представления данных

ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

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

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

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

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

1. Иерархия начинается с корневой вершины.

2. Каждая вершина соответствует одному или нескольким атрибутам.

3. Hа уровнях с большим номером находятся зависимые вершины. Вершин предшествующего уровня является начальной для новых зависимых вершин.

4. Каждая вершина, находящаяся на уровне i, соединена с одной и только одной вершиной уровня i-1, за исключением корневой вершины.

5. Корневая вершина может быть связана с одной или несколькими зависимыми вершинами.

6. Доступ к каждой вершине происходит через корневую по единственному пути

7. Существует произвольное количество вершин каждого уровня.

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

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

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

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

· Добавление новой записи (при добавлении новой записи должен быть организован уникальный ключ, значение которого однозначно характеризует ее).

· Изменение значения предварительно извлеченной записи (значение ключа при этом не должно изменяться).

· Удаление некоторых записей, при этом удаляются все записи, находящиеся с ней в групповом отношении.

· Извлечение

o Конкретной записи по значению ключа

o Следующей записи (эта операция выполняется в порядке левостороннего обхода дерева)

СЕТЕВАЯ МОДЕЛЬ ДАННЫХ

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

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

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

· Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.

· Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

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

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

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

· внести запись в БД (в зависимости от типа включения запись может быть внесена в групповое отношение или нет);

· включить запись в групповое отношение (связать запись с каким-либо владельцем);

· переключить (связать подчиненную запись с записью владельца в том же групповом отношении);

· изменить значение элементов предварительно извлеченной записи;

· извлечь запись либо по значению ключа, либо последовательно в рамках группового отношения;

· удалить - при удалении записи необходимо учитывать классы членства;

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

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

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

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

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

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

1. Должны отсутствовать записи-дубликаты

2. Столбцы реляц.таблицы поименованы, поэтому их порядок не важен.

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

4. Каждая запись уникальна и однозначно определяется значением ключа.

5. Каждый элемент таблицы называется полем, может быть однозначно определен.

6. В столбце записываются данные одного типа

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

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

1. Операции над отношениями, к которым относятся проекция, соединение и выбор.

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

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

Домен

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

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

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

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

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

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

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

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

Столбцы отношения называют атрибутами, им присваиваются имена, по которым к ним затем производится обращение.

Список имен атрибутов отношения с указанием имен доменов (или типов, если домены не поддерживаются) называется схемой отношения. Схема нашего отношения СТУДЕНТ запишется так: СТУДЕНТ {№_студенческого_билета Номера_студенческих_билетов

Имя Имена.

Дата_рождения Даты_рождения,

Курс Номера_курсов.

Специальность Специальности}

Степень отношения -- это число его атрибутов. Отношение степени один называют унарным, степени два -- бинарным, степени три -- тернарным,..., а степени п -- п-арным.

Степень отношения СТУДЕНТЫ равна пяти, то есть оно является 5-арным. Схемой базы данных называется множество именованных схем отношении.

Кортеж

Кортеж, соответствующий данной схеме отношения, представляет собой множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена Не поддерживается). Тем самым степень кортежа, то есть число элементов в нем, совпадает со степенью соответствующей схемы отношения. Иными словами, кортеж -- это набор именованных значений заданного типа.

Таким образом, отношение по сути является множеством кортежей, соответствующим одной схеме отношений.

Кардинальным числом или мощностью отношения называется число его кортежей. В отличие от степени отношения кардинальное число отношения изменяется во времени.

11. Функциональные и многозначные зависимости между атрибутами

Одним из методов проектирования БД является метод нормальных форм, основанный на понятии зависимости между атрибутами отношений. Существует три основных вида зависимостей между атрибутами:

· Функциональный.

· Многозначный.

· Транзитивный.

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

Атрибут С зависит от атрибута А транзитивно, если для атрибутов А, В, С выполняются условия, что А>В, В>С, но обратная зависимость отсутствует.

Атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В. Виды многозначных зависмостей:

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

Нормальные формы

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

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

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

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

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

Кроме метода нормальных форм применяется метод ER-диаграмм. Если метод нормальных форм используется обычно при проектировании отношений небольших БД, то метод «сущность-связь» позволяет проектировать большие БД. Каждая сущность (информационный объект) представляется как отношение, а связи между сущностями позволяют установить связи между таблицами (отношения) и ввести ключевой атрибут в таблицу для установления этих связей.

Отношение находится в 4НФ, если оно находится в НФБК и в нем отсутствуют многозначные зависимости, не являющиеся функциональными.

Тот факт, что отношение может быть восстановлено без потерь соединением некоторых его проекций, известен как зависимость по соединению. Говорят, что отношение находится в 5НФ тогда и только тогда, когда любая зависимость по соединению в R определяется возможными ключами R. Другими словами, каждая проекция R содержит не менее одного возможного ключа и по крайней мере один непервичный атрибут.

РЕЛЯЦИОННАЯ АЛГЕБРА

Реляционная алгебра представляет собой набор операторов, использующих отношения в качестве аргументов, и возвращающие отношения в качестве результата. Таким образом, реляционный оператор выглядит как функция с отношениями в качестве аргументов: R = f (R₁, R₂,…, R_n). Реляционная алгебра является замкнутой, т.к. в качестве аргументов в реляционные операторы можно подставлять другие реляционные операторы, подходящие по типу: R = f (f₁ (R₁₁, R₁₂,…),f₂(R₂₁, R₂₂,…). Таким образом, в реляционных выражениях можно использовать вложенные выражения сколь угодно сложной структуры.

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

Оператор переименования атрибутов имеет следующий синтаксис: R RENAME Atr₁, Atr₂,…AS NewAtr₁, NewAtr₂,,…, где R - отношение, Atr₁, Atr₂,… - исходные имена атрибутов, NewAtr₁, NewAtr₂,… - новые имена атрибутов. В результате применения оператора переименования атрибутов получаем новое отношение, с измененными именами атрибутов. Пример. Следующий оператор возвращает неименованное отношение, в котором атрибут City_Num переименован в Cityld: City RENAME City_Num AS Cityld.

ТЕОРЕТИКО-МНОЖЕСТВЕННЫЕ ОПЕРАТОРЫ

Объединение

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

Пример 2. Пусть даны два отношения A и B с информацией о сотрудниках:

Табельный номер	Фамилия	Зарплата
1	Иванов	1000
2	Петров	2000
3	Сидоров	3000

Таблица 1 Отношение A



Табельный номер	Фамилия	Зарплата
1	Иванов	1000
2	Пушников	2500
4	Сидоров	3000

Таблица 2 Отношение B

Объединение отношений и будет иметь вид:

Табельныйномер	Фамилия	Зарплата
1	Иванов	1000
2	Петров	2000
3	Сидоров	3000
2	Пушников	2500
4	Сидоров	3000

Таблица 3 Отношение A UNION B

Пересечение

Пересечением двух совместимых по типу отношений A и B называется отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих одновременно обоим отношениям A и B. Синтаксис операции пересечения: A INTERSECT B.

Пример 3. Для тех же отношений и , что и в предыдущем примере пересечение имеет вид:

Табельный номер	Фамилия	Зарплата
1	Иванов	1000

Таблица 4 Отношение A INTERSECT B

Вычитание

Вычитанием двух совместимых по типу отношений A и B называется отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих отношению A и не принадлежащих отношению B. Синтаксис операции вычитания: A MINUS B.

Пример. Для тех же отношений и , что и в предыдущем примере вычитание имеет вид:

Табельный номер	Фамилия	Зарплата
2	Петров	2000
3	Сидоров	3000

Таблица 5 Отношение A MINUS B

Декартово произведение

Декартовым произведением двух отношений A(A₁,…A_n) и B(B₁,…B_n) называется отношение, заголовок которого является сцеплением заголовков отношений A и B: (A₁, A₂,…,A_n , B₁, B₂,…, B_m), а тело состоит из кортежей, являющихся сцеплением кортежей отношений A и B: (a₁, a₂,…, a_n , b₁, b₂,…, b_m), таких, что(a₁, a₂,…, a_n)ОA, (b₁, b₂,…, b_m)ОB. Синтаксис операции декартового произведения: A TIMES B.

Мощность произведения A TIMES B равна произведению мощностей отношений A и B, т.к. каждый кортеж отношения A соединяется с каждым кортежем отношения B. Если в отношениях A и B имеются атрибуты с одинаковыми наименованиями, то перед выполнением операции декартового произведения такие атрибуты необходимо переименовать. Перемножать можно любые два отношения, совместимость по типу при этом не требуется.

Пример. Пусть даны два отношения и с информацией о поставщиках и деталях:

Номер поставщика	Наименование поставщика
1	Иванов
2	Петров
3	Сидоров

Таблица 6 Отношение A (Поставщики)

Номер детали	Наименование детали
1	Болт
2	Гайка
3	Винт

Таблица 7 Отношение B (Детали)

Декартово произведение отношений A и B будет иметь вид:

Номер поставщика	Наименование поставщика	Номер детали	Наименование детали
1	Иванов	1	Болт
1	Иванов	2	Гайка
1	Иванов	3	Винт
2	Петров	1	Болт
2	Петров	2	Гайка
2	Петров	3	Винт
3	Сидоров	1	Болт
3	Сидоров	2	Гайка
3	Сидоров	3	Винт

Таблица 8 Отношение A TIMES B

CПЕЦИАЛЬНЫЕ РЕЛЯЦИОННЫЕ ОПЕРАТОРЫ

Выборка (ограничение, селекция)

Выборкой (ограничением, селекцией) на отношении A с условием c называется отношение с тем же заголовком, что и у отношения A, и телом, состоящем из кортежей, значения атрибутов которых при подстановке в условие c дают значение ИСТИНА. c представляет собой логическое выражение, в которое могут входить атрибуты отношения A и (или) скалярные выражения. В простейшем случае условие c имеет вид XиY, где и - один из операторов сравнения (<,>,<=,>= и т.д.), а X и Y - атрибуты отношения A или скалярные значения. Синтаксис операции выборки: A WHERE c или A WHERE XиY.

Пример. Пусть дано отношение с информацией о сотрудниках:

Табельный номер	Фамилия	Зарплата
1	Иванов	1000
2	Петров	2000
3	Сидоров	3000

Таблица 9 Отношение A

Результат выборки будет иметь вид:

Табельныйномер	Фамилия	Зарплата
1	Иванов	1000
2	Петров	2000

Таблица 10 Отношение A WHERE Зарплата<3000

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

Проекция

Проекцией отношения A по атрибутам X, Y,…Z, где каждый из атрибутов принадлежит отношению A, называется отношение с заголовком (X, Y,…Z) и телом, содержащим множество кортежей вида (x, y,…z), таких, для которых в отношении A найдутся кортежи со значением атрибута X равным x, значением атрибута Y равным y, …, значением атрибута Z равным z. Синтаксис операции проекции: A[X, Y,…, Z]. Операция проекции дает "вертикальный срез" отношения, в котором удалены все возникшие при таком срезе дубликаты кортежей.

Пример. Пусть дано отношение с информацией о поставщиках, включающих наименование и месторасположение: